From patrickdlogan@REDACTED Sat Jun 1 20:34:36 2002 From: patrickdlogan@REDACTED (Patrick Logan) Date: Sat, 1 Jun 2002 11:34:36 -0700 Subject: XML-RPC and Erlang Message-ID: A web search turned up a couple mentions of an implementation of XML-RPC in Erlang. I have not been able to locate any implementations, though. Anyone know of an implementation? If not, I'll volunteer to do one. Thanks, Patrick Logan From targetemailextractor@REDACTED Mon Jun 3 03:27:52 2002 From: targetemailextractor@REDACTED (targetemailextractor@REDACTED) Date: Mon, 3 Jun 2002 09:27:52 +0800 Subject: Direct Email Blaster, Email extractor, email downloader, email verify ........... Message-ID: <200206030127.g531Rvj86556@hades.cslab.ericsson.net> An HTML attachment was scrubbed... URL: From Erik.Reitsma@REDACTED Mon Jun 3 13:15:36 2002 From: Erik.Reitsma@REDACTED (Erik Reitsma (ELN)) Date: Mon, 3 Jun 2002 13:15:36 +0200 Subject: XML-RPC and Erlang Message-ID: Hi Partick (and others), > A web search turned up a couple mentions of an > implementation of XML-RPC in > Erlang. I have not been able to locate any > implementations, though. > Anyone know of an implementation? > If not, I'll volunteer to do one. I know of e-soap, by IDEALX (http://www.idealx.org/prj/idx-esoap/dist/). I have used that, but had to make some modifications in order to let it work with Microsoft Visual Studio .NET. It does its own HTTP stuff, which means that it does not do HTTP/1.1, for example. It does use xmerl, however. I have started (in my spare time) on an implementation of the server side as a module in inets. I think that this would be a better approach. I can make calls to it with simple parameters (i.e. no XML-encoded parameters, just ints and strings), but it does work. If you'd like to work on this with me (or perhaps take over), I can gather the code and send it to you. *Erik. From klacke@REDACTED Mon Jun 3 13:23:08 2002 From: klacke@REDACTED (Klacke) Date: Mon, 3 Jun 2002 13:23:08 +0200 Subject: yaws Message-ID: <20020603132308.A17976@bluetail.com> Folks, New yaws release again called 0.40 - I've added full SSL support - Fixed some serious performance bugs - Various other minor bugfixes. Info at http://yaws.hyber.org /klacke -- Claes Wikstrom -- Caps lock is nowhere and Alteon WebSystems -- everything is under control http://www.bluetail.com/~klacke cellphone: +46 70 2097763 From luke@REDACTED Mon Jun 3 14:57:55 2002 From: luke@REDACTED (Luke Gorrie) Date: 03 Jun 2002 14:57:55 +0200 Subject: crash node with debugger Message-ID: Bug report: $ erl Erlang (BEAM) emulator version 5.1.1 [source] [hipe] Eshell V5.1.1 (abort with ^G) 1> ii(test). {module,test} 2> ii(test). The code server called the unloaded module `dbg_debugged' .. then the emulator exits. (Not specific to the 'test' module) Any ideas? Cheers, Luke From enano@REDACTED Mon Jun 3 15:10:11 2002 From: enano@REDACTED (Miguel Barreiro Paz) Date: Mon, 3 Jun 2002 15:10:11 +0200 (CEST) Subject: crash node with debugger In-Reply-To: Message-ID: > Eshell V5.1.1 (abort with ^G) > 1> ii(test). > {module,test} > 2> ii(test). > The code server called the unloaded module `dbg_debugged' > > .. then the emulator exits. > > (Not specific to the 'test' module) BTW, some time ago I was trying HIPE and when starting nodes from the unix commandline beam often died with "The code server called the unloaded module `hipe_converters'" (I'm quoting from memory). I blamed it on the runtime (early R8 IIRC) and regarded it as normal given the then premature hipe support. Maybe it wasn't hipe's fault at all. Just in case it's related. BTW2 - I've had an R8B HIPE coredump on SPARC, is anybody interested in the core? Regards, Miguel From joe@REDACTED Mon Jun 3 16:22:07 2002 From: joe@REDACTED (Joe Armstrong) Date: Mon, 3 Jun 2002 16:22:07 +0200 (CEST) Subject: forget In-Reply-To: Message-ID: On Wed, 29 May 2002, C.Reinke wrote: > > foo(Value) -> > > Value2 = bar(Value), > > Value3 = baz(Value2), > > Value4 = zab(Value3), > > {ok, Value4}. > > DCGs and other preprocessing have been suggested, but > in contrast to Prolog, Erlang is higher order, so why not: > > do (Value,[]) -> {ok,Value}; > do (Value,[F|Fs]) -> V = F(Value), do(V,Fs). > > foo(Value) -> > do (Value,[ > fun bar/1, > fun baz/1, > fun zab/1 > ]). > > A more lightweight syntax for funs would make that a lot nicer, of > course, and "do" might not be the most suggestive name, but it > avoids names for intermediates as well as language extensions.. > > Btw, why can't variables be passed unbound to functions (that > would make more complex utilities easy)? I think you have invented monads AND dataflow variables :-) This is *very* difficult to implement :-) suppose foo(?X) means create an unbound variable and call foo then we say foo(X) -> abc ! X, def ! X. Then we send the unbound variable to two *different* processes - imagine they are on different machines (just to make it more fun). They now both try to bind X at the same time :-) - one should succeed the other should fail - and it should work in the presence of errors ... << this is what Oz does (see http://www.mozart-oz.org/) >> /Joe > > Claus > > From bertil.karlsson@REDACTED Mon Jun 3 16:40:09 2002 From: bertil.karlsson@REDACTED (Bertil Karlsson) Date: Mon, 03 Jun 2002 16:40:09 +0200 Subject: Regarding a data repository for ASN1 data. References: <007801c2085d$7d3c4dc0$993210ac@laxeri105493> <3CF79699.24ABAD03@uab.ericsson.se> Message-ID: <3CFB7FC9.F17494C5@uab.ericsson.se> I had problem sending this mail last Friday (it left my netscape mail but didn't leave Ericsson), so I try again. Bertil Karlsson wrote: > > Hello Vijay, > > The files you get when using the asn1 compiler is: > > File.asn1db, a data base file used by the asn1 compiler only. > File.erl, the Erlang file generated by the asn1 compiler. This file > contains encode and decode functions that encodes/decodes asn1 messages > to/from BER,PER or DER encoding. > File.hrl, an Erlang .hrl file. This file is only generated when there > exists a SEQUENCE or a SET type or an asn1 value definition in the asn1 > file. For each SEQUENCE and SET type the compiler generates a record > with the same name as the type. For each value a macro is defined in the > .hrl file, so that you can retrive the asn1 value. > File.beam. The asn1 compiler calls the erlang compiler on the generated > files, and the result is a beam file. When you compile an erlang file > with the erlang compiler you will get a beam file. > > You'll find documentation on the asn1 compiler at: > http://www.erlang.org/doc/r8b/lib/asn1-1.3.2/doc/html/index.html > There you'll find a User's Guide and a Reference Manual for asn1ct and > asn1rt. > > Regarding your need for a data storage Erlang OTP has more than one > possibility. Mnesia is a powerful and fast data base application in > Erlang OTP. If you want to use an ODBC data base Erlang has a driver to > communicate with it. Perhaps you don't need a real data base but a > simpler storing facility, then take a look at ets tables. You can read > more about it in the Erlang documentation. > > /Bertil Karlsson > > > Vijay Sarathy Upparapalli wrote: > > > > Hi, > > I am working on "asn1ct" and "asn1rt". > > I have a ASN1 file compiled using "erlc" which resulted in four other > > files. > > For instance, if my ASN1 file is myfile.asn-- > > myfile.erl > > myfile.beam > > myfile.hrl > > myfile.asn1db > > are generated. > > Can anyone tell me the inherent details of these generated files. > > Also I am looking to storing the ASN1 specified data. > > Putting in a nutshell, I am looking towards realizing a database > > implementation for ASN1 specified data. > > Any help on this would be appreciated. > > Vijay. > > > > Name: Wipro_Disclaimer.txt > > Wipro_Disclaimer.txt Type: Plain Text (text/plain) > > Encoding: 7bit > > -- > ------------------------ > Bertil Karlsson > > Ericsson Utvecklings AB > Box 1505 > SE-125 25 ?lvsj? > SWEDEN > > Phone: +46 8 727 3927 > ------------------------ From bjorn@REDACTED Mon Jun 3 16:58:33 2002 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 03 Jun 2002 16:58:33 +0200 Subject: crash node with debugger In-Reply-To: Luke Gorrie's message of "03 Jun 2002 14:57:55 +0200" References: Message-ID: Here is a patch that solves the problem. /Bjorn *** /clearcase/otp/erts/lib/debugger/src/int.erl@@/main/release/r9_dev/7 Fri Feb 22 15:35:41 2002 --- /clearcase/otp/erts/lib/debugger/src/int.erl@@/main/release/r9_dev/8 Mon Jun 3 16:56:07 2002 *************** *** 498,503 **** --- 498,504 ---- everywhere(Dist, fun() -> code:purge(Mod), + erts_debug:breakpoint({Mod,'_','_'}, false), {module,Mod} = code:load_abs(filename:rootname(Beam)) end), {ok, SrcBin} = file:read_file(Src), Luke Gorrie writes: > Bug report: > > $ erl > Erlang (BEAM) emulator version 5.1.1 [source] [hipe] > > Eshell V5.1.1 (abort with ^G) > 1> ii(test). > {module,test} > 2> ii(test). > The code server called the unloaded module `dbg_debugged' > > .. then the emulator exits. > > (Not specific to the 'test' module) > > Any ideas? > > Cheers, > Luke > -- Bj?rn Gustavsson Ericsson Utvecklings AB bjorn@REDACTED ?T2/UAB/F/P BOX 1505 +46 8 727 56 87 125 25 ?lvsj? From C.Reinke@REDACTED Tue Jun 4 00:59:32 2002 From: C.Reinke@REDACTED (C.Reinke) Date: Mon, 03 Jun 2002 23:59:32 +0100 Subject: forget In-Reply-To: Your message of "Mon, 03 Jun 2002 16:22:07 +0200." Message-ID: > > A more lightweight syntax for funs would make that a lot nicer, of > > course, and "do" might not be the most suggestive name, but it > > avoids names for intermediates as well as language extensions.. > > > > Btw, why can't variables be passed unbound to functions (that > > would make more complex utilities easy)? > > I think you have invented monads AND dataflow variables :-) Hey, you can't blame me for everything, you know!-) Btw, I explicitly avoided monads, because with Erlang's heavy-weight syntax, they would look even less usable than the more primitive compose-a-list-of-funs definition I suggested. > This is *very* difficult to implement :-) You wouldn't by any chance know whether that's why Erlang's designers chose not to have it in the language?-) Instantiation of "logical" variables used to be the standard means of communication between and-parallel threads in the various non-sequential prologs (5th generation, etc.), and is still not dead for logic-based concurrent calculi. But you know that because you looked at many of those before and during the evolution of Erlang, and the mailbox/send/receive-model has proven to be practical (so far, more practical than 5th gen ideas;). [it shouldn't be difficult to define a naive variant of a distributed single-assignment construct on top of Erlang's mailboxes: a thread with mailbox receives assignments from writers and answers with success (first write commits) or failure (consecutive incompatible write attempts); synchronization of writers (all fail or all succeed) would be more difficult; Erlang didn't inherit non-deterministic user-defined rules, so dealing with or-parallelism is not an issue - hmm, could that be modeled via supervisors?-] I wasn't suggesting to go back to that (well, at least not for Erlang), but banning unbound variables from function calls might be overly restrictive (given the, now remote, relation to prologs). Why not permit unbound variables in function calls, and only outlaw them in inter-thread communications? I looked at logic vs functional languages a while ago, and most of the examples where logic languages won where down to this late, but still single-assignment use of variables. And its a lot easier (almost trivial?) to implement within thread-boundaries. > Then we send the unbound variable to two *different* processes - imagine > they are on different machines (just to make it more fun). > > They now both try to bind X at the same time :-) - one should succeed > the other should fail - and it should work in the presence of errors ... > > << this is what Oz does (see http://www.mozart-oz.org/) >> It's been a long time since I visited Oz;) but the general ideas go back a lot farther (though I don't recall to what extend those early parallel "logic" languages dealt with distribution, as in Oz). Cheers, Claus PS. I notice two aspects of Erlang that tend to aggravate the problem discussed in the original thread (beyond the problems most functional languages used to have with this): - non-nesting variable scope (fortunately not adopted for the higher-order extensions) so one cannot reuse the same variable name, as one usually can with non-recursive lets. - relatively heavy-weight syntax making the use of higher-order functions less convenient than in Haskell (MLs have the same problem). So instead of defining their own higher-order control constructs (which otherwise tends to be home ground for functional languages), people are asking for language extensions (the same happened with behaviours). From vlad_dumitrescu@REDACTED Tue Jun 4 08:59:20 2002 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Tue, 04 Jun 2002 08:59:20 +0200 Subject: forget Message-ID: Hi, Please correct me if I am just confused. Language extensions are grat :-) but in this particular case, would they solve more than a small part of the problem? It was pointed out earlier that in practice, the successive calls tend to look something like: {ok, A} = foo(Q), {B, C} = bar(A), {value, [D]} = baz(B, C), which is difficult to encapsulate in a shortened variant. Unless, of course, a new set of programming rules are written and OTP is rewritten and everybody uses it. C. Reinke wrote: >Why not permit unbound variables in function calls, and only outlaw >them in inter-thread communications? I looked at logic vs functional >languages a while ago, and most of the examples where logic >languages won where down to this late, but still single-assignment >use of variables. And its a lot easier (almost trivial?) to >implement within thread-boundaries. Could you please explain in short why would this be a good idea? It is a long time since I used Prolog... Would these variables function as "out" parameters? Isn't it clearer to read and write code that returns all values as the result, not intermix them with the arguments? I know Prolog uses that for neat stuff, but it is a different world (or so I see it). > - non-nesting variable scope (fortunately not adopted for > the higher-order extensions) > so one cannot reuse the same variable name, as one usually > can with non-recursive lets. I am not sure if this would be very useful, since there is no construct similar to "let". How would the nested scope be defined? Usually now one uses an auxiliary function - this may be seen as heavyweight, but what I find more of a problem than that is that with many aux funs one easily loses the local context. > - relatively heavy-weight syntax > making the use of higher-order functions less convenient > than in Haskell (MLs have the same problem). So instead > of defining their own higher-order control constructs > (which otherwise tends to be home ground for functional > languages), people are asking for language extensions > (the same happened with behaviours). I am not very familiar with Haskell, but aren't it's capabilities for composing high-order funs (mostly) a result of currying and the syntax without parentheses? This might be introduced in Erlang, but would it still be Erlang afterwards? (*deep thought ;-) best regards, Vlad _________________________________________________________________ MSN Foto ?r det enklaste s?ttet att dela eller skaffa papperskopior av dina foton: http://photos.msn.com/support/worldwide.aspx From klacke@REDACTED Tue Jun 4 09:55:55 2002 From: klacke@REDACTED (Klacke) Date: Tue, 4 Jun 2002 09:55:55 +0200 Subject: forget In-Reply-To: ; from C.Reinke@ukc.ac.uk on Mon, Jun 03, 2002 at 11:59:32PM +0100 References: Message-ID: <20020604095554.A18465@bluetail.com> On Mon, Jun 03, 2002 at 11:59:32PM +0100, C.Reinke wrote: > > Why not permit unbound variables in function calls, and only outlaw > them in inter-thread communications? I looked at logic vs functional > languages a while ago, and most of the examples where logic > languages won where down to this late, but still single-assignment > use of variables. And its a lot easier (almost trivial?) to > implement within thread-boundaries. > I remember the wild days when we were adding stuff to the languange in a complete ad-hoc manner. The process worked a bit along the lines: 1. Somebody implements a funky feature and just adds it to the language. a) More than one other person says: this is a good feature - it stays. b) no feed back at all - the feature goes For example I remember I had an implementation of process migration from one node to another that nobody cared about, so I removed it. Anyway, here's my reply to your suggestion above. When we were discussing and implementing different features, there was always one limiting factor, and that was that a feature shouldn't rely on whether we were having a shared heap implementation or an implementation with private heaps per process. Having logical (unbound) variables in everything but message passing is just such a feature. If we're to ban unbound vars in messages, we must scan the message before sending it. This is bad if we're having a unified heap. Cheers /klacke -- Claes Wikstrom -- Caps lock is nowhere and Alteon WebSystems -- everything is under control http://www.bluetail.com/~klacke cellphone: +46 70 2097763 From joe@REDACTED Tue Jun 4 10:56:14 2002 From: joe@REDACTED (Joe Armstrong) Date: Tue, 4 Jun 2002 10:56:14 +0200 (CEST) Subject: forget In-Reply-To: Message-ID: On Mon, 3 Jun 2002, C.Reinke wrote: > > > > A more lightweight syntax for funs would make that a lot nicer, of > > > course, and "do" might not be the most suggestive name, but it > > > avoids names for intermediates as well as language extensions.. > > > > > > Btw, why can't variables be passed unbound to functions (that > > > would make more complex utilities easy)? > > > > I think you have invented monads AND dataflow variables :-) > > Hey, you can't blame me for everything, you know!-) > > Btw, I explicitly avoided monads, because with Erlang's heavy-weight > syntax, they would look even less usable than the more primitive > compose-a-list-of-funs definition I suggested. > > > This is *very* difficult to implement :-) > > You wouldn't by any chance know whether that's why Erlang's > designers chose not to have it in the language?-) Erlang grew out of Prolog - firstly by adding a notion of processes, secondly by adding mechanisms for fault-tolerance and hot code swapping. Erlang is *basically* a concurrent language - it was designed to have fast process spawning, context switching and message passing. Anything that worked on one processor should work in a distributed system with minimal changes to the program. The sequential part of Erlang was just a simple functional language - any language could do I guess, the fact it was functional was more or less an accident it could equally well have been an imperative or logic language (provided it was garbage collected :-). We deliberately stayed clear of *anything* that involved "dangling references", we didn't want messages between machines to contain pointers, so we insisted that messages were copied between machines. This was because we wanted the system to work reasonable in the presence of machine failures and we wanted message passing to have transaction semantics (i.e. all the message gets transfered on nothing) - In the *language* we want to create loosely coupled systems without strong data bindings between data components. > > Instantiation of "logical" variables used to be the standard means > of communication between and-parallel threads in the various > non-sequential prologs (5th generation, etc.), and is still not > dead for logic-based concurrent calculi. But you know that > because you looked at many of those before and during the evolution > of Erlang, and the mailbox/send/receive-model has proven to be > practical (so far, more practical than 5th gen ideas;). > We rejected stream communication with logic variables - there are a few problems with this. - out of order messages can cause deadlocks. - setting up the splitter/merger networks to get the right streams the the right places is messy - code is more difficult to understand (this is subjective). i.e. message passing can be achieved "invisibly" just by binding a variable. > [it shouldn't be difficult to define a naive variant of a > distributed single-assignment construct on top of Erlang's > mailboxes: a thread with mailbox receives assignments from > writers and answers with success (first write commits) or > failure (consecutive incompatible write attempts); > synchronization of writers (all fail or all succeed) would > be more difficult; Erlang didn't inherit non-deterministic > user-defined rules, so dealing with or-parallelism is not > an issue - hmm, could that be modeled via supervisors?-] I think this would be valuable in a library module. It would be nice to have a library that did something like: NewVar = logic_var:create() % create a logic variable Pid ! ... NewVar ... % you can send it *anywhere* logic_var:bind(Var, Value) % bind it % returns a boolean % true if you were the first to bind it % false otherwise logic_var:send_message(Pid, Var) % send Pid a {bound,Var,Val} % message when Var is bound (This is give an Erlang flavor to things) logic_var:wait(Var) % wait for Var to be bound *then* you could write things like V = new_var(), Pid1 ! Pid2 ! Pid3 ! Pid4 ! {who_wants_to_buy_my_car_for_10_dollars, V} sell_to(wait(V)). etc. Now make my day and tell me that somebody has already written this. [tricky bit - what happens when remote nodes crash ...] > I wasn't suggesting to go back to that (well, at least not for > Erlang), but banning unbound variables from function calls might > be overly restrictive (given the, now remote, relation to prologs). > > Why not permit unbound variables in function calls, and only outlaw > them in inter-thread communications? Because we want things to work the same way in *all* circumstances. > I looked at logic vs functional > languages a while ago, and most of the examples where logic > languages won where down to this late, but still single-assignment > use of variables. And its a lot easier (almost trivial?) to > implement within thread-boundaries. > > > Then we send the unbound variable to two *different* processes - imagine > > they are on different machines (just to make it more fun). > > > > They now both try to bind X at the same time :-) - one should succeed > > the other should fail - and it should work in the presence of errors ... > > > > << this is what Oz does (see http://www.mozart-oz.org/) >> > > It's been a long time since I visited Oz;) but the general ideas > go back a lot farther (though I don't recall to what extend those > early parallel "logic" languages dealt with distribution, as in Oz). Oz was designed after Erlang. The Oz group had previous done a lot of work with parallel prolog dialects. Interestingly - we can discern a Swedish school of parallel programming - the "processes in the language" school - to this belong (Erlang, Oz, Eri-pascal, PLEX). Most programmers (I think) view processes as "operating system things" NOT "language things". Processes in most languages are not processes but threads - and the threads are a thinly disguised layer over the OSs threads. Threads are claimed by some to be "light weight" - but Erlang processes are (say) 100 times faster to create & destroy than the appallingly bad Java or C# threads. The fact that (say) java threads are so badly designed (and green threads so appallingly implemented) gives the whole idea of concurrent programing a bad name. The Erlang/Oz school is more about concurrency than FP/logic programming - the trade-offs in the Erlang design decisions were always to make sure the languages were good at concurrency - and *not* that it was a fully fledged FP languages. FP was essential "bolted onto" a concurrent language - not the other way round. In Java/C#/C++ and the concurrent dialects of the popular FPs it is the other way round - concurrency is added as an afterthought - usually as a thin layer to OS threads. That's why threads suck in most languages - because they were added as an afterthought. Try creating 1000 parallel threads in C# on windows 2000 - (joke) Sorry - I rambled off subject here ... I am becoming more and more convinced that Erlang should be judged as a concurrent language than as an FP langauge. If you compare Erlang *as an FP* it may or may not be marginally better than Haskell, ML, ... If it is better (or worse) then the difference is marginal. If you compare Erlang as a *concurrent* langauge with Java/C#/C++ is is a *lot* better - it is not marginally better - the *only* discussion here is "are we 100 times better or 1000 times better at process handling that Java threads? /Joe > Cheers, > Claus > > PS. I notice two aspects of Erlang that tend to aggravate the > problem discussed in the original thread (beyond the problems > most functional languages used to have with this): > > - non-nesting variable scope (fortunately not adopted for > the higher-order extensions) > > so one cannot reuse the same variable name, as one usually > can with non-recursive lets. > > - relatively heavy-weight syntax > > making the use of higher-order functions less convenient > than in Haskell (MLs have the same problem). So instead > of defining their own higher-order control constructs > (which otherwise tends to be home ground for functional > languages), people are asking for language extensions > (the same happened with behaviours). > > From vijay.usarathy@REDACTED Tue Jun 4 11:14:32 2002 From: vijay.usarathy@REDACTED (Vijay Sarathy Upparapalli) Date: Tue, 4 Jun 2002 14:44:32 +0530 Subject: Regarding a data repository for ASN1 data. References: <007801c2085d$7d3c4dc0$993210ac@laxeri105493> <3CF79699.24ABAD03@uab.ericsson.se> <3CFB7FC9.F17494C5@uab.ericsson.se> Message-ID: <00af01c20ba8$3d5977c0$993210ac@laxeri105493> Hello Bertil, Thanks for the response. Vijay. ----- Original Message ----- From: "Bertil Karlsson" To: "Vijay Sarathy Upparapalli" ; Sent: Monday, June 03, 2002 8:10 PM Subject: Re: Regarding a data repository for ASN1 data. I had problem sending this mail last Friday (it left my netscape mail but didn't leave Ericsson), so I try again. Bertil Karlsson wrote: > > Hello Vijay, > > The files you get when using the asn1 compiler is: > > File.asn1db, a data base file used by the asn1 compiler only. > File.erl, the Erlang file generated by the asn1 compiler. This file > contains encode and decode functions that encodes/decodes asn1 messages > to/from BER,PER or DER encoding. > File.hrl, an Erlang .hrl file. This file is only generated when there > exists a SEQUENCE or a SET type or an asn1 value definition in the asn1 > file. For each SEQUENCE and SET type the compiler generates a record > with the same name as the type. For each value a macro is defined in the > .hrl file, so that you can retrive the asn1 value. > File.beam. The asn1 compiler calls the erlang compiler on the generated > files, and the result is a beam file. When you compile an erlang file > with the erlang compiler you will get a beam file. > > You'll find documentation on the asn1 compiler at: > http://www.erlang.org/doc/r8b/lib/asn1-1.3.2/doc/html/index.html > There you'll find a User's Guide and a Reference Manual for asn1ct and > asn1rt. > > Regarding your need for a data storage Erlang OTP has more than one > possibility. Mnesia is a powerful and fast data base application in > Erlang OTP. If you want to use an ODBC data base Erlang has a driver to > communicate with it. Perhaps you don't need a real data base but a > simpler storing facility, then take a look at ets tables. You can read > more about it in the Erlang documentation. > > /Bertil Karlsson > > > Vijay Sarathy Upparapalli wrote: > > > > Hi, > > I am working on "asn1ct" and "asn1rt". > > I have a ASN1 file compiled using "erlc" which resulted in four other > > files. > > For instance, if my ASN1 file is myfile.asn-- > > myfile.erl > > myfile.beam > > myfile.hrl > > myfile.asn1db > > are generated. > > Can anyone tell me the inherent details of these generated files. > > Also I am looking to storing the ASN1 specified data. > > Putting in a nutshell, I am looking towards realizing a database > > implementation for ASN1 specified data. > > Any help on this would be appreciated. > > Vijay. > > > > Name: Wipro_Disclaimer.txt > > Wipro_Disclaimer.txt Type: Plain Text (text/plain) > > Encoding: 7bit > > -- > ------------------------ > Bertil Karlsson > > Ericsson Utvecklings AB > Box 1505 > SE-125 25 ?lvsj? > SWEDEN > > Phone: +46 8 727 3927 > ------------------------ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Wipro_Disclaimer.txt URL: From Bruce@REDACTED Tue Jun 4 11:14:38 2002 From: Bruce@REDACTED (Bruce Fitzsimons) Date: Tue, 4 Jun 2002 21:14:38 +1200 Subject: yaws References: <20020603132308.A17976@bluetail.com> Message-ID: <016501c20ba8$454694e0$4021970a@norris> Hey Klacke. Nice debug functions! Mind if I reuse them in my GPLed server (http://www.neolineas.com/aplio.htm)? My existing debug macros are a bit lacking... Have you every thought about run-time switchable debug? Probably not amazingly useful for this situation, but I've found it very useful in production systems (C++ though...) where you can selectively debug things on the fly without stopping/recompiling anything. I'm not sure there is a good way to implement the switch(es) in Erlang, an ets table maybe? Its also a nice sample of a small application (eg .app file) that I must learn from :-) Thanks again for releasing it. Bruce From eleberg@REDACTED Tue Jun 4 11:24:44 2002 From: eleberg@REDACTED (Bengt Kleberg) Date: Tue, 4 Jun 2002 11:24:44 +0200 (MET DST) Subject: yaws Message-ID: <200206040924.g549Oir00129@cbe.ericsson.se> > From: "Bruce Fitzsimons" > To: "Klacke" , > Subject: Re: yaws > Have you every thought about run-time switchable debug? Probably not > amazingly useful for this situation, but I've found it very useful in what about the dbg module? it works on a production system, without recompilation. (or is this module internal to ericsson?) bengt From kenneth@REDACTED Tue Jun 4 12:39:18 2002 From: kenneth@REDACTED (Kenneth Lundin) Date: Tue, 04 Jun 2002 12:39:18 +0200 Subject: yaws References: <200206040924.g549Oir00129@cbe.ericsson.se> Message-ID: <3CFC98D6.670CB5E8@erix.ericsson.se> Bengt Kleberg wrote: > > > From: "Bruce Fitzsimons" > > To: "Klacke" , > > Subject: Re: yaws > > > Have you every thought about run-time switchable debug? Probably not > > amazingly useful for this situation, but I've found it very useful in > > what about the dbg module? it works on a production system, without > recompilation. (or is this module internal to ericsson?) > > bengt The trace support in Erlang is very good, and a lot of new features have been added in the recent releases. The interface for activating trace is in the dbg module. A new feature that Klacke might not be very familiar with is the function call trace very you can trace on both local and exported functions in selected modules and for selected processes (or all). The trace output can be directed to different trace ports which either stores on disc or send to a socket. With these trace capabilities all types of debug macros can be removed. If you want specific information at certain points just call a dummy function like this: ... my_debug:info(Var1,Var2,Var3,,VarN), ... Implement info/N like this: info(Var1,Var2,Var3,VarN) -> true. Then if you want to activate tracing dynamically just specify tracing on my_debug:info/N. The call to info is very cheap, i.e acceptable to have in production code. The possibility to trace on functions does not cost anything extra when not used and is very efficient when used. Of course you can trace on all the other functions too if you like. There is no need to call specific debug functions like the 'info' above. The trace features are not specific for Ericsson, they are available in the Open Source Erlang. The tracing is however very much used within Ericsson , it is designed specifically to be useful in a live production system and even possible to use at customer site if necessary. Of course you can load the system to it's nees if you select tracing on all function calls and the trace output will soon fill up your disc, so you have to a bit careful. Regards Kenneth Lundin (Product Manager for Erlang/OTP within Ericsson) From eleberg@REDACTED Tue Jun 4 13:32:40 2002 From: eleberg@REDACTED (Bengt Kleberg) Date: Tue, 4 Jun 2002 13:32:40 +0200 (MET DST) Subject: yaws Message-ID: <200206041132.g54BWer25676@cbe.ericsson.se> > To: erlang-questions@REDACTED > Date: Tue, 04 Jun 2002 12:39:18 +0200 > From: Kenneth Lundin > send to a socket. With these trace capabilities all types of debug > macros > can be removed. If you want specific information at certain points just this is correct, and IMHO, deserves its own post like this. :-) bengt From mike@REDACTED Tue Jun 4 13:36:32 2002 From: mike@REDACTED (Mike Williams) Date: 4 Jun 2002 11:36:32 GMT Subject: forget References: , Message-ID: In article , joe@REDACTED (Joe Armstrong) writes: |> I am becoming more and more convinced that Erlang should be judged |> as a concurrent language than as an FP langauge. A concurrent language like OCCAM???? :-) /mike From jamesh@REDACTED Tue Jun 4 15:48:32 2002 From: jamesh@REDACTED (James Hague) Date: Tue, 4 Jun 2002 08:48:32 -0500 Subject: forget Message-ID: > I am becoming more and more convinced that Erlang should be >judged as a concurrent language than as an FP langauge. I disagree, though the concurrency is invaluable. The original point of functional programming, at least as I've always seen it, was that computation was done in a referentially transparent way (see Backus's FP articles, for example). In the last decade or more, this has changed into functional programming being entirely about: 1. Higher order functions. 2. Type systems. While these are both useful, they're more icing than the core of functional programming: programming without destructive updates. As such, I find writing functional programs more approachable in Erlang than in Haskell or ML. Haskell lends itself to a dense style of function composition, which I find obtuse. And both Haskell and ML put correct typing above writing the most succint and obvious code. There's a good paper by Aiken, et al, about the successor to Backus's FP: FL. One of the design goals was to avoid a static type system because it was one extra thing to stand in the way of someone learning the language. A very interesting read: http://citeseer.nj.nec.com/183013.html (Section 4.2 is about the decision to be be dynamically typed, even though "Within the functional programming community, an overwhelming majority supports static typing.") I need to write an FL interpreter in Erlang , I think :) From thomas.lindgren@REDACTED Tue Jun 4 18:01:40 2002 From: thomas.lindgren@REDACTED (Thomas Lindgren) Date: Tue, 4 Jun 2002 18:01:40 +0200 Subject: forget In-Reply-To: Message-ID: [James Hague:] >I disagree, though the concurrency is invaluable. > > The original point of functional programming, at least as I've always seen > it, was that computation was done in a referentially transparent way (see > Backus's FP articles, for example). In the last decade or more, this has > changed into functional programming being entirely about: > > 1. Higher order functions. > 2. Type systems. Good point. The interesting thing about Erlang in this respect is that concurrency encapsulates side effects. Ets-tables, ports and all that can all be viewed as _other_ processes changing state, while your own process is entirely pure (if you forget about timeouts). (The process dictionary, etc. can be viewed as passing an implicit state, much like the DCG transformation discussed before.) This is, it seems to me, much nicer than our siblings ML or Lisp, where you have visible side-effects to data. (Though ML at least marks the places where this can occur clearly.) Haskell's approach (encapsulating side-effects in monads) appears orthogonal to Erlang's, though I haven't studied it closely enough to say. It is much nicer, because you can rely on all data being referentially transparent inside a process. In short: the "opaqueness" of your code is limited to process communication, or if we also consider monitors and links, process interactions. Best, Thomas From kostis@REDACTED Tue Jun 4 19:05:09 2002 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 4 Jun 2002 19:05:09 +0200 (MET DST) Subject: crash node with debugger In-Reply-To: Mail from 'Miguel Barreiro Paz ' dated: Mon, 3 Jun 2002 15:10:11 +0200 (CEST) Message-ID: <200206041705.TAA26195@harpo.it.uu.se> Miguel Barreiro Paz wrote: > BTW2 - I've had an R8B HIPE coredump on SPARC, is anybody > interested in the core? We are not interested in the core (feel free to delete it ;-) but on the other hand, we are definitely interested if you can try to isolate the problematic functions and send us a (preferably small) piece of code that illustrates it. Cheers, Kostis. From yrashk@REDACTED Wed Jun 5 11:28:08 2002 From: yrashk@REDACTED (Yurii Rashkovskii) Date: Wed, 5 Jun 2002 12:28:08 +0300 Subject: ssl_esock.exe Message-ID: <000101c20c73$4ec01a20$bc64a8c0@softerra.int> Gentlemen, I've found that there is no ssl_esock.exe in my Windows distribution of Erlang/OTP R8B0. Where can I get it? (I've failed trying to build it from priv/obj/Makefile) P.S. It is very *urgent*. From kchandrashekhar@REDACTED Wed Jun 5 11:46:30 2002 From: kchandrashekhar@REDACTED (K Chandra Shekhar) Date: Wed, 5 Jun 2002 15:16:30 +0530 Subject: Declaring Variables. Message-ID: <02060515163004.01235@abacus102> Hello everyone, Is there any method by which i can use variables globally. I am developing a roaming solution for mobile phones and am totally stuck at a point where i have to pass the values of some variables form one p[roces to the other.....and i cant use the "Proces ! {parameters} " feature. I wouls be extremely greateful if somebody could suggest some method of doing so. Thanks in advance Chandra Shekhar Hyderabad, India From eleberg@REDACTED Wed Jun 5 12:02:32 2002 From: eleberg@REDACTED (Bengt Kleberg) Date: Wed, 5 Jun 2002 12:02:32 +0200 (MET DST) Subject: Declaring Variables. Message-ID: <200206051002.g55A2Xr16656@cbe.ericsson.se> > From: K Chandra Shekhar > To: erlang-questions@REDACTED > Is there any method by which i can use variables globally. no. > I am developing a roaming solution for mobile phones and am > totally stuck at a point where i have to pass the values of > some variables form one p[roces to the other.....and i cant > use the "Proces ! {parameters} " feature. > > I wouls be extremely greateful if somebody could suggest > some method of doing so. use ets. create a table. write the variable into it in one process, and read from the other. bengt From peter@REDACTED Wed Jun 5 11:54:58 2002 From: peter@REDACTED (Peter H|gfeldt) Date: Wed, 5 Jun 2002 11:54:58 +0200 (MET DST) Subject: ssl_esock.exe In-Reply-To: <000101c20c73$4ec01a20$bc64a8c0@softerra.int> Message-ID: There are instructions on how to build ssl_esock.exe in the SSL application manual page (man -s 6 ssl). You have to download the SSLeay package. /Peter ------------------------------------------------------------------------- Peter H?gfeldt e-mail : peter@REDACTED Open Telecom Platform Phone: : +46 (8) 727 57 58 Ericsson AB > > I've found that there is no ssl_esock.exe in my Windows distribution of > Erlang/OTP R8B0. > > Where can I get it? > (I've failed trying to build it from priv/obj/Makefile) > > P.S. It is very *urgent*. > From peter@REDACTED Wed Jun 5 12:22:26 2002 From: peter@REDACTED (Peter H|gfeldt) Date: Wed, 5 Jun 2002 12:22:26 +0200 (MET DST) Subject: ssl_esock.exe In-Reply-To: <000201c20c78$841b84c0$bc64a8c0@softerra.int> Message-ID: To provide an interface in Erlang to SSLeay and to ask users to aquire the SSLeay package themselves, is a device that we have found to fulfil both the restrictions put on cryptographic software by the legislation of the European Union, and the requirements in the SSLeay license. So I am sorry, as an Ericsson employee, I dare not help you with this matter, due to the quagmire of legal restrictions. /Peter On Wed, 5 Jun 2002, Yurii Rashkovskii wrote: > > I know about it. > > Bu as how it is said in documentation the process is not trivial and may > have problems. I'm very limited in time (*very*!), and it will be very > good if someone will send me already built ssl_esock.exe :) > > > -----Original Message----- > From: Peter H|gfeldt [mailto:peter@REDACTED] > Sent: Wednesday, June 05, 2002 12:55 PM > To: Yurii Rashkovskii > Cc: erlang-questions@REDACTED > Subject: Re: ssl_esock.exe > > > There are instructions on how to build ssl_esock.exe in the SSL > application manual page (man -s 6 ssl). You have to download the > SSLeay package. > > /Peter > > ------------------------------------------------------------------------ > - > Peter H?gfeldt e-mail : peter@REDACTED > Open Telecom Platform Phone: : +46 (8) 727 57 58 > Ericsson AB > > > > > I've found that there is no ssl_esock.exe in my Windows distribution > of > > Erlang/OTP R8B0. > > > > Where can I get it? > > (I've failed trying to build it from priv/obj/Makefile) > > > > P.S. It is very *urgent*. > > > From klacke@REDACTED Wed Jun 5 12:58:12 2002 From: klacke@REDACTED (Klacke) Date: Wed, 5 Jun 2002 12:58:12 +0200 Subject: ssl_esock.exe In-Reply-To: ; from peter@erix.ericsson.se on Wed, Jun 05, 2002 at 12:22:26PM +0200 References: <000201c20c78$841b84c0$bc64a8c0@softerra.int> Message-ID: <20020605125812.B8799@bluetail.com> On Wed, Jun 05, 2002 at 12:22:26PM +0200, Peter H|gfeldt wrote: > > To provide an interface in Erlang to SSLeay and to ask users to aquire > the SSLeay package themselves, is a device that we have found to fulfil > both the restrictions put on cryptographic software by the legislation > of the European Union, and the requirements in the SSLeay license. > > So I am sorry, as an Ericsson employee, I dare not help you with this > matter, due to the quagmire of legal restrictions. > > /Peter Hmmm Peter, I though that the "quagmire" was gone by now. I do remember that there was a quagmire regarding the export issues for crypto software .. at least a couple of years ago. US (and the European Union) did a radical change regarding export of crypto several years ago if I recall correctly. At Nortel, we ship SSL based products and we have had zero problems with the export of crypto software. (Our product is entirely based on openssl) So, to my knowledge, swedish, EU, and US export restrictons are just plain gone. (Notable exceptions of Libya, Cuba and some other not so very cool countries :-) Correct me if I'm wrong. /klacke -- Claes Wikstrom -- Caps lock is nowhere and Alteon WebSystems -- everything is under control http://www.bluetail.com/~klacke cellphone: +46 70 2097763 From enano@REDACTED Wed Jun 5 13:08:49 2002 From: enano@REDACTED (Miguel Barreiro Paz) Date: Wed, 5 Jun 2002 13:08:49 +0200 (CEST) Subject: ssl_esock.exe In-Reply-To: <20020605125812.B8799@bluetail.com> Message-ID: > So, to my knowledge, swedish, EU, and US export restrictons are > just plain gone. (Notable exceptions of Libya, Cuba and some other not so > very cool countries :-) Certainly not cool, usually above 40C :-) Seriously, what's the legal situation in France and other EU countries wrt crypto? Regards, Miguel From mike@REDACTED Wed Jun 5 13:09:10 2002 From: mike@REDACTED (Mike Williams) Date: 5 Jun 2002 11:09:10 GMT Subject: Declaring Variables. References: <02060515163004.01235@abacus102> Message-ID: In article <02060515163004.01235@REDACTED>, kchandrashekhar@REDACTED (K Chandra Shekhar) writes: |> some variables form one p[roces to the other.....and i cant |> use the "Proces ! {parameters} " feature. Out of curiousity, why can you use Erlang's normal message passing? The whole philosphy behind Erlang is to *avoid* having global variables. The ets table solution is possible, but only as a last resort. A more common solution is a client server solution where the server is implemented as an erlang process which stores the global data. OTP supports this as "gen_server" which is well documented in the Erlang/OTP manuals. /mike From klacke@REDACTED Wed Jun 5 12:51:40 2002 From: klacke@REDACTED (Klacke) Date: Wed, 5 Jun 2002 12:51:40 +0200 Subject: ssl_esock.exe In-Reply-To: <000101c20c73$4ec01a20$bc64a8c0@softerra.int>; from yrashk@telcos.net.ua on Wed, Jun 05, 2002 at 12:28:08PM +0300 References: <000101c20c73$4ec01a20$bc64a8c0@softerra.int> Message-ID: <20020605125140.A8799@bluetail.com> On Wed, Jun 05, 2002 at 12:28:08PM +0300, Yurii Rashkovskii wrote: > Gentlemen, > > I've found that there is no ssl_esock.exe in my Windows distribution of > Erlang/OTP R8B0. > > Where can I get it? > (I've failed trying to build it from priv/obj/Makefile) > > P.S. It is very *urgent*. Seems to me that there are some problems with the build of ssl in r8b1 1. ssl_esock isn't even included in the build targets # diff Makefile.in Makefile.in~ 108c108 < debug opt: $(OBJDIR) $(BINDIR) $(SSL_BASE) $(EXTRA_SSL_OBJS) $(SSL_BINS) $(SSL_MAKEFILE) --- > debug opt: $(OBJDIR) $(BINDIR) $(SSL_BASE) $(EXTRA_SSL_OBJS) $(SSL_MAKEFILE) 2. The DEBUGF macros in debuglog.h doesn't build on linux (rh7.3 gcc 2.96) # diff debuglog.h debuglog.h~ 29,31c29,31 < #define DEBUGF(x) < #define DEBUGMSGF(x) < #define LOGF(fp, x) --- > #define DEBUGF(x) if (debug) __debugprintf ## x; > #define DEBUGMSGF(x) if (debugmsg) __debugprintclistf ## x; > #define LOGF(fp, x) if (fp) { __locallogfp = fp; __debuglogf ## x; } I just commented them out. -- Claes Wikstrom -- Caps lock is nowhere and Alteon WebSystems -- everything is under control http://www.bluetail.com/~klacke cellphone: +46 70 2097763 From Sean.Hinde@REDACTED Wed Jun 5 13:00:00 2002 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Wed, 5 Jun 2002 12:00:00 +0100 Subject: ssl_esock.exe Message-ID: <04D356A3B172D611981B0008C791C3126BF086@imp02mbx.t-mobile.co.uk> I have had OK experience using openssl with this www.openssl.org Create the two library files libcrypto.a and libssl.a using the openssl standard build procedure Copy them into the lib/ssl-x.y.z/priv/bin directory Adjust the paths in the Makefile referred to in the documentation make Give it a go Sean > -----Original Message----- > From: Peter H|gfeldt [mailto:peter@REDACTED] > Sent: 05 June 2002 11:22 > To: Yurii Rashkovskii > Cc: erlang-questions@REDACTED > Subject: RE: ssl_esock.exe > > > > To provide an interface in Erlang to SSLeay and to ask users to aquire > the SSLeay package themselves, is a device that we have found > to fulfil > both the restrictions put on cryptographic software by the legislation > of the European Union, and the requirements in the SSLeay license. > > So I am sorry, as an Ericsson employee, I dare not help you with this > matter, due to the quagmire of legal restrictions. > > /Peter > > On Wed, 5 Jun 2002, Yurii Rashkovskii wrote: > > > > > I know about it. > > > > Bu as how it is said in documentation the process is not > trivial and may > > have problems. I'm very limited in time (*very*!), and it > will be very > > good if someone will send me already built ssl_esock.exe :) > > > > > > -----Original Message----- > > From: Peter H|gfeldt [mailto:peter@REDACTED] > > Sent: Wednesday, June 05, 2002 12:55 PM > > To: Yurii Rashkovskii > > Cc: erlang-questions@REDACTED > > Subject: Re: ssl_esock.exe > > > > > > There are instructions on how to build ssl_esock.exe in the SSL > > application manual page (man -s 6 ssl). You have to download the > > SSLeay package. > > > > /Peter > > > > > -------------------------------------------------------------- > ---------- > > - > > Peter H?gfeldt e-mail : peter@REDACTED > > Open Telecom Platform Phone: : +46 (8) 727 57 58 > > Ericsson AB > > > > > > > > I've found that there is no ssl_esock.exe in my Windows > distribution > > of > > > Erlang/OTP R8B0. > > > > > > Where can I get it? > > > (I've failed trying to build it from priv/obj/Makefile) > > > > > > P.S. It is very *urgent*. > > > > > > NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From yrashk@REDACTED Wed Jun 5 12:05:25 2002 From: yrashk@REDACTED (Yurii Rashkovskii) Date: Wed, 5 Jun 2002 13:05:25 +0300 Subject: ssl_esock.exe In-Reply-To: Message-ID: <000201c20c78$841b84c0$bc64a8c0@softerra.int> I know about it. Bu as how it is said in documentation the process is not trivial and may have problems. I'm very limited in time (*very*!), and it will be very good if someone will send me already built ssl_esock.exe :) -----Original Message----- From: Peter H|gfeldt [mailto:peter@REDACTED] Sent: Wednesday, June 05, 2002 12:55 PM To: Yurii Rashkovskii Cc: erlang-questions@REDACTED Subject: Re: ssl_esock.exe There are instructions on how to build ssl_esock.exe in the SSL application manual page (man -s 6 ssl). You have to download the SSLeay package. /Peter ------------------------------------------------------------------------ - Peter H?gfeldt e-mail : peter@REDACTED Open Telecom Platform Phone: : +46 (8) 727 57 58 Ericsson AB > > I've found that there is no ssl_esock.exe in my Windows distribution of > Erlang/OTP R8B0. > > Where can I get it? > (I've failed trying to build it from priv/obj/Makefile) > > P.S. It is very *urgent*. > From klacke@REDACTED Wed Jun 5 13:49:20 2002 From: klacke@REDACTED (Klacke) Date: Wed, 5 Jun 2002 13:49:20 +0200 Subject: ssl_esock.exe In-Reply-To: ; from enano@fi.udc.es on Wed, Jun 05, 2002 at 01:08:49PM +0200 References: <20020605125812.B8799@bluetail.com> Message-ID: <20020605134920.A11971@bluetail.com> On Wed, Jun 05, 2002 at 01:08:49PM +0200, Miguel Barreiro Paz wrote: > > > > So, to my knowledge, swedish, EU, and US export restrictons are > > just plain gone. (Notable exceptions of Libya, Cuba and some other not so > > very cool countries :-) > > Certainly not cool, usually above 40C :-) > > Seriously, what's the legal situation in France and other EU > countries wrt crypto? > To my knowledge France now has similar rules as the rest of the EU countries. (They used to have even more restrictive rules than the other countries) The EU rules are _very_ similar to the US rules. I haven't ever exported anything *out* of France though, only into. The only country that I know of that has rules governing which crypto can be brought into the country (a opposed to out from) is India. Besides, wasn't the entire discussion of crypto export weird. Remember, during the days when crypto export actually was regulated, the openssl sources were always available from a large number of ftp sites all over the world. So exporting closed products was regulated, whereas giving away the "Real Mc Coy" wasn't. ... I never groked that. Still don't. /klacke -- Claes Wikstrom -- Caps lock is nowhere and Alteon WebSystems -- everything is under control http://www.bluetail.com/~klacke cellphone: +46 70 2097763 From peter@REDACTED Wed Jun 5 14:19:17 2002 From: peter@REDACTED (Peter H|gfeldt) Date: Wed, 5 Jun 2002 14:19:17 +0200 (MET DST) Subject: ssl_esock.exe In-Reply-To: <20020605125812.B8799@bluetail.com> Message-ID: Please find below what I wrote less than two months ago about cryptographic software. I am not a lawyer, but I am of the (perhaps odd) opinion that an ordinary citizen can read and understand the laws of his country. However, if you want to find out what is allowed for your specific application, you have to go to court (get sued by the government). Legislation is still in force and not void. However, the maximal allowable "free" key sizes have been increased over the years (it seems as if the US first sets a size to 1024 bits, say, then the EU is a good boy by setting it to 512 bits, and Sweden, being a very good boy, sets it to 128). Erlang/OTP relies on the "public domain" exception to the EU legislation (see below). Beware of petty corporate bureaucrats. They may mess things up for you by making every little detail a big issue. They typically do not even understand that you are free to export within the EU (one of the cornerstones of the union). /Peter On Wed, 5 Jun 2002, Klacke wrote: > On Wed, Jun 05, 2002 at 12:22:26PM +0200, Peter H|gfeldt wrote: > > > > To provide an interface in Erlang to SSLeay and to ask users to aquire > > the SSLeay package themselves, is a device that we have found to fulfil > > both the restrictions put on cryptographic software by the legislation > > of the European Union, and the requirements in the SSLeay license. > > > > So I am sorry, as an Ericsson employee, I dare not help you with this > > matter, due to the quagmire of legal restrictions. > > > > /Peter > > > Hmmm Peter, I though that the "quagmire" was gone by now. I do remember > that there was a quagmire regarding the export issues for crypto > software .. at least a couple of years ago. > > US (and the European Union) did a radical change regarding export > of crypto several years ago if I recall correctly. At Nortel, we ship > SSL based products and we have had zero problems with the > export of crypto software. (Our product is entirely based on openssl) > > So, to my knowledge, swedish, EU, and US export restrictons are > just plain gone. (Notable exceptions of Libya, Cuba and some other not so > very cool countries :-) > > > > Correct me if I'm wrong. Export Control and OTP R8B -------------------------- April 15, 2002 Introduction OTP R8 provides cryptography, which is subjected to export control according to legislation of the European Union (and other countries as well, notably the United States). The export control classification number (ECCN) for OTP is 5D002. Only the following parts of OTP provides cryptography: the Crypto and SSL applications. Legislation There is a general authorisation for export from member states of the EU to other states of the EU. This also holds true, according to Council Regulation (EC) No 2432/2001, for export to the following states: Australia, Canada, Czech Republic, Hungary, Japan, New Zealand, Norway, Poland, Switzerland, and United States of America. Hence, for export to those states, no further authorisation is needed. According to the same regulation, authorisation for export to other states than those listed above is required for cryptographic software containing: a. A "symmetric algorithm" employing a key length in excess of 56 bits; or b. An "asymmetric algorithm" where the security of the algorithm is based on any of the following: 1. Factorisation of integers in excess of 512 bits (e.g., RSA); 2. Computation of discrete logarithms in a multiplicative group of a finite field of size greater than 512 bits (e.g., Diffie-Hellman over Z/pZ); or 3. Discrete logarithms in a group other than mentioned in b.2. in excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve). For products containing cryptographic software fulfilling a. or b. authorisation for export is required. Authorisation is granted by authorities of the member states of the EU. An export authorisation issued in one member state is valid in all other member states. Crypto The Crypto application provides a symmetric crypto algorithm (DES) with a 56 bits key, and is thus not subject to export restrictions. SSL The SSL application can provide arbitrarily strong cryptography and is therefore subject to restrictions. The measure to take is either to i) obtain authorisation for export, or to ii) remove the SSL application completely from the OTP release. The SSL application of the OTP distribution does not contain the cryptographic libraries needed (they have to be aquired by the user of OTP). The SSL application without those libraries, still falls under the above rules, according to the Swedish National Inspectorate of Strategic Products, since it makes the capabilities possible nevertheless. Goods generally available to the public According the regulation referred to above, there is no export control for goods a. Generally available to the public by being sold, without restriction, from stock at retail selling points by means of any of the following: 1. Over-the-counter transactions; 2. Mail order transactions; 3. Electronic transactions; or 4. Telephone call transactions; b. The cryptographic functionality cannot easily be changed by the user; c. Designed for installation by the user without further substantial support by the supplier; and d. When necessary, details of the goods are accessible and will be provided, upon request, to the competent authorities of the Member State in which the exporter is established in order to ascertain compliance with conditions described in paragraphs a. to c. above. Open Source There is yet an other way to avoid the requirement of authorisation: by providing the code as open source (the legislative term is "in the public domain"). From per@REDACTED Wed Jun 5 15:48:04 2002 From: per@REDACTED (Per Bergqvist) Date: Wed, 05 Jun 2002 14:48:04 +0100 Subject: =?iso-8859-1?q?ssl=5Fesock.exe?= In-Reply-To: <20020605134920.A11971@bluetail.com> Message-ID: <200206051248.g55Cm5v29369@raven.levonline.com> Found the following on the net: .... The Commerce/NSA report states that "France has the most comprehensive cryptologic control and use regime in Europe, and possibly worldwide." On December 29, 1990, France enacted a new law (90-1170) regulating the telecommunications industry. Article 28 of the law specifically addresses encryption and adopts a control and export regime that is far more restrictive than that applied by Wassenaar and its predecessor, COCOM. The law, in order to "preserve the interests of national defense and of internal or external State security" regulates the "supply, export, or use of cryptologic methods or devices." Thus, although foreign cryptographic products may be imported into France without a license they may not be supplied to French users nor used in France without authorization by the Prime Minister. .... Don't know wether this is still in force or not but I haven't been able to find something that says that restrictions have been lifted. As late as 18 months ago at least some restrictions where still there. (We had to mess up a product completely to comply with the french requirements ...) /Per ========================================================= Per Bergqvist Synapse Systems AB Phone: +46 709 686 685 Email: per@REDACTED From per@REDACTED Wed Jun 5 16:01:17 2002 From: per@REDACTED (Per Bergqvist) Date: Wed, 05 Jun 2002 15:01:17 +0100 Subject: =?iso-8859-1?q?ssl=5Fesock.exe?= In-Reply-To: <200206051248.g55Cm5v29369@raven.levonline.com> Message-ID: <200206051301.g55D1Hv06091@raven.levonline.com> And here is an indication on at least eased policy ... http://www.oreilly.com/~andyo/ar/crypto_reversal.html Also found this great site on the topic: http://rechten.kub.nl/koops/cryptolaw /Per From klacke@REDACTED Wed Jun 5 15:39:11 2002 From: klacke@REDACTED (Klacke) Date: Wed, 5 Jun 2002 15:39:11 +0200 Subject: ssl_esock.exe In-Reply-To: ; from peter@erix.ericsson.se on Wed, Jun 05, 2002 at 02:19:17PM +0200 References: <20020605125812.B8799@bluetail.com> Message-ID: <20020605153911.A15319@bluetail.com> On Wed, Jun 05, 2002 at 02:19:17PM +0200, Peter H|gfeldt wrote: > > > Please find below what I wrote less than two months ago about > cryptographic software. I am not a lawyer, > However, if you want to find out what is allowed for your > specific application, you have to go to court (get sued by the > government). > > Legislation is still in force and not void. However, the maximal allowable > "free" key sizes have been increased over the years (it seems as if the > US first sets a size to 1024 bits, say, then the EU is a good boy by > setting it to 512 bits, and Sweden, being a very good boy, sets it to > 128). > I still find this unclear, how can all the other companies ship openssl but we (in sweden) cannot. There are lots of companies that ship products (open on the internet to download) that contain openssl. Companies from many contries, (even France). All the linux distros, all the browser manufacturers. Unclear. I still think that the laws in Europe now are so relaxed so that its ok to ship products with openssl. That is *think*, I definitely don't know. > but I am of the (perhaps odd) > opinion that an ordinary citizen can read and understand the laws of his > country. Ho ho, Cheers /klacke -- Claes Wikstrom -- Caps lock is nowhere and Alteon WebSystems -- everything is under control http://www.bluetail.com/~klacke cellphone: +46 70 2097763 From C.Reinke@REDACTED Fri Jun 7 20:46:48 2002 From: C.Reinke@REDACTED (C.Reinke) Date: Fri, 07 Jun 2002 19:46:48 +0100 Subject: forget In-Reply-To: Message from Klacke of "Tue, 04 Jun 2002 09:55:55 +0200." <20020604095554.A18465@bluetail.com> Message-ID: > For example I remember I had an implementation of process migration > from one node to another that nobody cared about, so I removed it. Being able to send funs and code between threads is no complete replacement for that, as one would still need to snapshot the current thread into a closure, then send that along. Looks like a useful feature to me. > Anyway, here's my reply to your suggestion above. When we were > discussing and implementing different features, there was always > one limiting factor, and that was that a feature shouldn't rely on whether > we were having a shared heap implementation or an implementation > with private heaps per process. > > Having logical (unbound) variables in everything but message passing > is just such a feature. If we're to ban unbound vars in messages, we > must scan the message before sending it. This is bad if we're having > a unified heap. Okay, I was misled by the similarity to Prolog - you don't actually check for non-instantiated variables at the point of use, but at the point of definition, only that it may not be immediately obvious whether "..,X=value,.." is a definition or an equality check. Assuming logical variables, would it be sufficient to replace the runtime check by a static check, ruling out all *potentially* uninstantiated variables in messages? Claus From bob@REDACTED Fri Jun 7 21:22:26 2002 From: bob@REDACTED (bob) Date: Fri, 7 Jun 2002 09:22:26 -1000 Subject: starting httpd non-root Message-ID: <200206071922.JAA01346@mapcohawaii.com> Aloha, Sorry to ask, since I know I've seen the answer. Just can't find it when I need it. Attempting to start httpd as non-root returns; HTTPD MANAGER INFO: failed socket listen operation: eaccess Thanks, bob From C.Reinke@REDACTED Fri Jun 7 21:15:27 2002 From: C.Reinke@REDACTED (C.Reinke) Date: Fri, 07 Jun 2002 20:15:27 +0100 Subject: forget In-Reply-To: Message from mike@erix.ericsson.se (Mike Williams) of "04 Jun 2002 11:36:32 GMT." Message-ID: > |> I am becoming more and more convinced that Erlang should be judged > |> as a concurrent language than as an FP langauge. > > A concurrent language like OCCAM???? > > :-) > > /mike I used to think little of OCCAM, because it didn't seem to be designed for the things I expected from a programming language. But with that background, I kept running into surprises when talking to folks in our local concurrency group - they looked at me as if they had no idea what language I might be complaining about, until they finally realised: "oh, you mean _normal_ occam..". Here's a relevant excerpt from their group projects page: http://www.cs.ukc.ac.uk/research/groups/crg/research_interests.html Occam has also been made considerably more flexible, enabling it to be used way beyond its original target application area (embedded systems). Extensions include user-defined operators, native thread support, dynamic process loading, persistence and mobile processes - a key research issue being to achieve all this without compromising parallel security or efficiency. Would be nice if new-Occam (or whatever they may call it) and Erlang folks would know more about each other's work ;-) Claus PS. I guess they are talking about Kent Retargetable occamTM Compiler (KRoC) http://www.cs.ukc.ac.uk/projects/ofa/kroc/ Both pages refer to a conference on "Communicating Process Architectures" you might be interested in - the reference on the KRoC page seems to be the recent one.. From C.Reinke@REDACTED Fri Jun 7 20:37:37 2002 From: C.Reinke@REDACTED (C.Reinke) Date: Fri, 07 Jun 2002 19:37:37 +0100 Subject: forget In-Reply-To: Message from "Vlad Dumitrescu" of "Tue, 04 Jun 2002 08:59:20 +0200." Message-ID: > Please correct me if I am just confused. Language extensions are grat :-) You mean: extensible languages are great!-) Languages should be general enough to let you do what you need, conveniently, without having to ask someone else for extensions. That could mean convenient meta-programming facilities, as in Lisps, or it could mean convenient higher-order programming facilities, as in more recent functional languages. Both allow you to extend your general-purpose language by domain-specific languages, in which it becomes easier to tackle problems in your domain. If programmers can't do this, extensions have to be added centrally. And after patching too many extensions into a language spec, you'll find yourself with an unmanageable language, lacking any remainders of clear design, but offering a bewildering variety of features that never quite cooperate in the way you'd like them to. But that's an old problem (Dijkstra wrote about it in his "Humble Programmer";-). > but in this particular case, would they solve more than a small > part of the problem? It was pointed out earlier that in practice, > the successive calls tend to look something like: > > {ok, A} = foo(Q), > {B, C} = bar(A), > {value, [D]} = baz(B, C), This still has some regularity, which one could try to capture: uncurry(F,{X}) -> F(X). uncurry(F,{X,Y}) -> F(X,Y). uncurry(F,{X,Y,Z}) -> F(X,Y,Z). do_with (Values, []) -> Values; do_with (Values, [H|T]) -> V = (uncurry(H))(Values), do_with(V, T). Then your calls could become: do_with({Q},[ fun foo/1, fun (ok,A) -> bar(A) end, fun baz/2 ]), Note: with Erlang's syntax, this isn't much shorter, but it still reduces the mental clutter - you don't have to think about whether the code conforms to the pattern, it's obvious from the call to the higher-order function encapsulating the pattern (giving the benefits familiar from behaviours, for user-defined patterns). It's the irregularity of Ulf's example that reduces the gains from such an approach. Variable-arity functions are straightforward in Erlang (no static type system trying to get in the way), but back-references to results returned earlier in the chain would already require something more like monads, and then Erlang's prefix calls, parentheses and end's would start to pile up somewhere. But if there's no or little regularity in the chain of calls, there's little one could abstract into a higher-order control construct. Of course, one might ask whether the code should be that irregular in the first place (but who am I to say?-), as that means there is no other way to read and understand the code than looking at all the details and carefully tracking the changes in usage from call to call. It's not just the variable names, it's that each part of the code does its own thing, and has to be understood on its own and in all its connections to the usage context. > >Why not permit unbound variables in function calls, .. I looked > >at logic vs functional languages a while ago, and most of the > >examples where logic languages won where down to this late, but > >still single-assignment use of variables. > > Could you please explain in short why would this be a good idea? > It is a long time since I used Prolog... Would these variables > function as "out" parameters? Isn't it clearer to read and write > code that returns all values as the result, not intermix them with > the arguments? I know Prolog uses that for neat stuff, but it is a > different world (or so I see it). It's been a long time for me as well, but the worlds are not so different in practice (I used to read the acronym as PROgraming xor LOGic:). Passing uninstantiated variables in Prolog is similar to "out" variables in other languages (cleaner, though, as there can be only a single value in each branch, and variables are still simply placeholders for values, as in Erlang, not storage locations, as in other languages). There is no need for the callee to instantiate them, either - they can be put whereever you need them, as placeholders for the single value which you give them when it becomes available to you. So it is not so much about mixing results with arguments (which is necessary in Prolog as predicates only return success, at best) but about being able to delay the instantation to a more convenient time - it's still single-assignment, as in Erlang, but you gain flexibility. There's no need for non-determinism, no conflict with fp ideas, no different world (as Joe and Klacke have pointed out, you might want to rule out potentially uninstantiated variables in message passing constructs to avoid runtime checks). Some of the typical examples are traversals of data structures (lists/trees/..) containing definitions and uses of items, where you may encounter places of usage before places of definition. With logical variables, or with recursion and lazy evaluation, you can handle these with a single traversal, otherwise you need two (one to extract the definitions, the second to replace the uses). Very few functional languages have experimented with the "neat stuff" one can do with logical variables independent of other logic programming concepts, but as Erlang grew out of Prolog, I was interested to learn why logical variables were dropped almost completely (the odd flat scoping, and the resultant need for forget(), are perhaps the only reminders). The focus on concurrency and simplicity was the answer to that question. > > - non-nesting variable scope (fortunately not adopted for > > the higher-order extensions) > > so one cannot reuse the same variable name, as one usually > > can with non-recursive lets. > > I am not sure if this would be very useful, since there is no construct > similar to "let". How would the nested scope be defined? I guess I'd prefer something like "..,let =,.." to stand for an implicit "..,forget(),=,.." instead of having an explicit forget bif or the current f() in the shell. > > - relatively heavy-weight syntax > > making the use of higher-order functions less convenient > > than in Haskell (MLs have the same problem). So instead > > of defining their own higher-order control constructs > > (which otherwise tends to be home ground for functional > > languages), people are asking for language extensions > > (the same happened with behaviours). > > I am not very familiar with Haskell, but aren't it's capabilities for > composing high-order funs (mostly) a result of currying and the syntax > without parentheses? Currying, no needless parentheses, user-definable infix operators (function composition is just an infix dot, so that doesn't impede readability). That's the nice/simple part of Haskell - no spectacular features responsible for the advantage, just a carefully considered mix of small things that tend to work together well and ensure that the language syntax stays "out of the way". > This might be introduced in Erlang, but would it still be Erlang > afterwards? (*deep thought ;-) Why not? Erlang shines in other areas, it's "Erlang-ness" doesn't come from these things, does it?-) And if such general improvements could remove the need for ad-hoc extensions that make the language more complex, wouldn't that be preferable? Claus From thomas@REDACTED Fri Jun 7 22:24:15 2002 From: thomas@REDACTED (Thomas Lange) Date: Fri, 07 Jun 2002 22:24:15 +0200 Subject: starting httpd non-root References: <200206071922.JAA01346@mapcohawaii.com> Message-ID: <3D01166F.D8841A63@corelatus.com> The user is not allowed to open the port you have choosen ( probably port 80 ). Choosing another port ( e.g. 8888 ) would be an easy solution. /Thomas bob wrote: > > Aloha, > Sorry to ask, since I know I've seen the answer. Just can't find it when I need it. > Attempting to start httpd as non-root returns; > HTTPD MANAGER INFO: failed socket listen operation: eaccess > > Thanks, > bob From robert.virding@REDACTED Sat Jun 8 10:42:17 2002 From: robert.virding@REDACTED (Robert Virding) Date: Sat, 08 Jun 2002 10:42:17 +0200 Subject: forget References: Message-ID: <3D01C369.2030506@telia.com> Joe Armstrong wrote: > On Mon, 3 Jun 2002, C.Reinke wrote: > ... LONG discussion on logical variables and other stuff > > Well said Joe, you took the words right out of my mouth. :-) Robert From laheadle@REDACTED Sun Jun 9 18:05:46 2002 From: laheadle@REDACTED (Lyn A Headley) Date: 09 Jun 2002 12:05:46 -0400 Subject: debugger Message-ID: <87fzzwo2sl.fsf@chead.hyttsvll1.md.home.com> Hello List, I've been playing with erlang a little bit and I would like to get to know the debugger, since I tend to write buggy code. Luckily, it didn't take me long to write a little program which doesn't work. So I fired up the debugger just like it says in the users manual, compiled my module with debug_info, and tried a Modules -> interpret. The interpret request fails and says the module must be purged before loading. Ok fine. code:purge(cothink). Try again. Same error! Any ideas? I saw another posting back in february with the same question. Is it a bad sign that nobody answered? thanks, -Lyn (lyn@REDACTED)1> c(cothink, debug_info). {ok,cothink} (lyn@REDACTED)2> debugger:start(). <0.40.0> (lyn@REDACTED)3> =ERROR REPORT==== 9-Jun-2002::11:30:53 === Module cothink must be purged before loading =ERROR REPORT==== 9-Jun-2002::11:30:53 === Loading of /home/lyn/src/erlang/cothink/cothink.beam failed: not_purged =ERROR REPORT==== 9-Jun-2002::11:31:00 === Module cothink must be purged before loading =ERROR REPORT==== 9-Jun-2002::11:31:05 === Module cothink must be purged before loading =ERROR REPORT==== 9-Jun-2002::11:31:05 === Loading of /home/lyn/src/erlang/cothink/cothink.beam failed: not_purged =ERROR REPORT==== 9-Jun-2002::11:31:13 === Module cothink must be purged before loading (lyn@REDACTED)3> code:purge(cothink). false (lyn@REDACTED)4> code:purge(cothink). false (lyn@REDACTED)5> c(cothink, debug_info). {ok,cothink} (lyn@REDACTED)6> debugger:start(). <0.73.0> (lyn@REDACTED)7> =ERROR REPORT==== 9-Jun-2002::11:32:27 === Module cothink must be purged before loading =ERROR REPORT==== 9-Jun-2002::11:32:27 === Loading of /home/lyn/src/erlang/cothink/cothink.beam failed: not_purged =ERROR REPORT==== 9-Jun-2002::11:32:32 === Module cothink must be purged before loading From etxuwig@REDACTED Sun Jun 9 21:51:48 2002 From: etxuwig@REDACTED (Ulf Wiger) Date: Sun, 9 Jun 2002 21:51:48 +0200 (MET DST) Subject: debugger In-Reply-To: <87fzzwo2sl.fsf@chead.hyttsvll1.md.home.com> Message-ID: On 9 Jun 2002, Lyn A Headley wrote: >The interpret request fails and says the module must be purged before >loading. Ok fine. code:purge(cothink). Try again. Same error! >(lyn@REDACTED)4> code:purge(cothink). >false >(lyn@REDACTED)5> c(cothink, debug_info). >{ok,cothink} >(lyn@REDACTED)6> debugger:start(). ><0.73.0> >(lyn@REDACTED)7> >=ERROR REPORT==== 9-Jun-2002::11:32:27 === >Module cothink must be purged before loading When you run c(cothink, debug_info), the module is automatically loaded. The c() function compiles _and_ loads the file. >From c.erl: c(File, Opt) when atom(Opt) -> c(File, [Opt]); c(File, Opts0) -> Opts = [report_errors,report_warnings|Opts0], case compile:file(File, Opts) of {ok,Mod} -> %Listing file. machine_load(Mod, File, Opts); {ok,Mod,Ws} -> %Warnings ... machine_load(Mod, File, Opts); Other -> %Errors go here Other end. If you want to compile, but not load, a file, use compile:file(File, Options) - in this case: compile:file(File, [debug_info]). (I know that compile:file(File, debug_info) works, but I don't like it, partly because compile.erl only recognizes singleton options that are atoms -- so it's inconsistent -- and partly because it is, as far as I can tell, an undocumented feature.) /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From kchandrashekhar@REDACTED Mon Jun 10 09:50:08 2002 From: kchandrashekhar@REDACTED (K Chandra Shekhar) Date: Mon, 10 Jun 2002 13:20:08 +0530 Subject: How to calculate Time Message-ID: <02061013200801.02541@abacus102> hi guys, Is there any BIF to calculate the time(in secs or mins) for which an alarm is active ? I am stuck up trying to find the solution. I dtored the starting time in one variable and the time at which the alaram is cleared in another.... Subtracting the two does not give any results... Please help me. Chandra Shekhar From etxuwig@REDACTED Mon Jun 10 10:01:07 2002 From: etxuwig@REDACTED (Ulf Wiger) Date: Mon, 10 Jun 2002 10:01:07 +0200 (MET DST) Subject: How to calculate Time In-Reply-To: <02061013200801.02541@abacus102> Message-ID: On Mon, 10 Jun 2002, K Chandra Shekhar wrote: >hi guys, > >Is there any BIF to calculate the time(in secs or mins) for >which an alarm is active ? No BIF, but take a look at calendar:time_difference(T1, T2). If you store the times using erlang:now(), you may use the following formula: diff({M,S,U}, {M,S1,U1}) -> ((S-S1) * 1000) + ((U-U1) div 1000); diff({M,S,U}, {M1,S1,U1}) -> ((M-M1)*1000000+(S-S1))*1000 + ((U-U1) div 1000). /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From Chandrashekhar.Mullaparthi@REDACTED Mon Jun 10 10:04:04 2002 From: Chandrashekhar.Mullaparthi@REDACTED (Chandrashekhar Mullaparthi) Date: Mon, 10 Jun 2002 09:04:04 +0100 Subject: How to calculate Time Message-ID: <04D356A3B172D611981B0008C791C3124047CD@imp02mbx.t-mobile.co.uk> Checkout the manpage for calendar. It has a function calendar:time_difference/2 If you want to calculate the difference between two values of now() - the following code will return the difference in milliseconds. now_diff(Then, Now) -> {M, S, U} = Then, Then_ms = trunc(M*1000000000+S*1000+U/1000), {M1, S2, U2} = Now, Now_ms = trunc(M1*1000000000+S2*1000+U2/1000), Now_ms - Then_ms. cheers Chandru -----Original Message----- From: K Chandra Shekhar [mailto:kchandrashekhar@REDACTED] hi guys, Is there any BIF to calculate the time(in secs or mins) for which an alarm is active ? I am stuck up trying to find the solution. I dtored the starting time in one variable and the time at which the alaram is cleared in another.... Subtracting the two does not give any results... Please help me. Chandra Shekhar NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From gunilla@REDACTED Tue Jun 11 07:53:24 2002 From: gunilla@REDACTED (Gunilla Arendt) Date: Tue, 11 Jun 2002 07:53:24 +0200 Subject: debugger References: <87fzzwo2sl.fsf@chead.hyttsvll1.md.home.com> Message-ID: <3D059054.2A4189BC@arendt.se> Hi Lyn, You can ignore the error message. When you have selected Modules-> Interpret, check the Modules menu again. cothink should now be visible there. However, I recommend you to fetch the R8B-1 release of OTP instead. This release contains a new and much improved version of Debugger. / Gunilla Lyn A Headley wrote: > > Hello List, > > I've been playing with erlang a little bit and I would like to get to > know the debugger, since I tend to write buggy code. Luckily, it > didn't take me long to write a little program which doesn't work. So > I fired up the debugger just like it says in the users manual, > compiled my module with debug_info, and tried a Modules -> interpret. > > The interpret request fails and says the module must be purged before > loading. Ok fine. code:purge(cothink). Try again. Same error! > > Any ideas? I saw another posting back in february with the same > question. Is it a bad sign that nobody answered? > > thanks, > > -Lyn > > (lyn@REDACTED)1> c(cothink, debug_info). > {ok,cothink} > (lyn@REDACTED)2> debugger:start(). > <0.40.0> > (lyn@REDACTED)3> > =ERROR REPORT==== 9-Jun-2002::11:30:53 === > Module cothink must be purged before loading > > =ERROR REPORT==== 9-Jun-2002::11:30:53 === > Loading of /home/lyn/src/erlang/cothink/cothink.beam failed: not_purged > > =ERROR REPORT==== 9-Jun-2002::11:31:00 === > Module cothink must be purged before loading > > =ERROR REPORT==== 9-Jun-2002::11:31:05 === > Module cothink must be purged before loading > > =ERROR REPORT==== 9-Jun-2002::11:31:05 === > Loading of /home/lyn/src/erlang/cothink/cothink.beam failed: not_purged > > =ERROR REPORT==== 9-Jun-2002::11:31:13 === > Module cothink must be purged before loading > > (lyn@REDACTED)3> code:purge(cothink). > false > (lyn@REDACTED)4> code:purge(cothink). > false > (lyn@REDACTED)5> c(cothink, debug_info). > {ok,cothink} > (lyn@REDACTED)6> debugger:start(). > <0.73.0> > (lyn@REDACTED)7> > =ERROR REPORT==== 9-Jun-2002::11:32:27 === > Module cothink must be purged before loading > > =ERROR REPORT==== 9-Jun-2002::11:32:27 === > Loading of /home/lyn/src/erlang/cothink/cothink.beam failed: not_purged > > =ERROR REPORT==== 9-Jun-2002::11:32:32 === > Module cothink must be purged before loading From joe@REDACTED Tue Jun 11 08:50:50 2002 From: joe@REDACTED (Joe Armstrong) Date: Tue, 11 Jun 2002 08:50:50 +0200 (CEST) Subject: A programming convention Message-ID: Here's an idea for a programming convention.... This convention has to do with the return value/exception problem. The standard example is from dict.erl. Suppose you search for a keyed value in a dictionary. Not finding a value means one of precisely two things: 1) A logical error in the program 2) An expected behaviour of the application In case 1) the application should terminate with an exception. In case 2) the application should deal with the return value. For this reason there are two functions which search for keys in dict. They are dict:fetch(Key, Dict) -> Value | EXIT dict:find(Key, Dict) -> {ok,Value}| error I can never remember which is which so I always have to consult the manual page. The programmer should use fetch if not finding a key is a logical programming error otherwise find. <