gmane.comp.lang.erlang.general

Re: term_to_binary and record improvements

Matthew Dempsky — 2008-08-29T18:10:13

term_to_binary/2 already exists to take a list of options.

Re: [HOWTO] For newbies: print any term withoutellipsis in shell using rp()

Edwin Fine — 2008-08-29T17:27:56

Re: [HOWTO] For newbies: print any term without ellipsis in shell using rp()

Mazen Harake — 2008-08-29T15:43:37

Believe me you are not the first to comment on this :) Our intention has been to go down that road eventually AFAIK but it has simply been a lack of resources... First step was a major overhaul which was done a year ago where we gave trapexit a huge facelift + some tuning. Until then I guess we will have to live with LAMP until we replace it with perhaps LYCE (Linux, Yaws, CouchDB, Erlang-web) :) /Mazen Edwin Fine wrote:

Erlang + SMTP + TLS/SSL

Dmitrii Dimandt — 2008-08-29T14:36:46

Does anyone know of an erlang library that can send mail through smtp with TLS/SSL enabled (like through gmail). I'm currently using http://www.lshift.net/~tonyg/erlang-smtp/ (http://www.lshift.net/blog/2007/12/28/erlang-smtp-code-updated ), and it's super easy to use and works :) I'd like to have some TLS as well, though Thank you

Re: [HOWTO] For newbies: print any term withoutellipsis in shell using rp()

Daniele Varrazzo — 2008-08-29T12:50:52

2008/8/29 Edwin Fine usa.net>: If you find this tip useful (it is), you may want to add it to the Erlang wiki: http://www.trapexit.org/Erlang_Wiki for instance as an HowTo.

Re: [HOWTO] For newbies: print any term withoutellipsis in shell using rp()

Edwin Fine — 2008-08-29T14:35:35

Re: elrc "implementation limit"?

Bjorn Gustavsson — 2008-08-29T12:34:51

elrc "implementation limit"?

Dimitry Golubovsky — 2008-08-29T12:08:18

Hi, Given this Erlang module: http://code.haskell.org/yc2erl/erlang/yc2erl.erl and a file it includes (precompiled from an external source): http://code.haskell.org/yc2erl/erlang/unitable.hrl erlc gave this error message after several minutes of compilation (CPU at 99%, but size in memory remained stable): ============================================= [dima< at >erldev hugs_yc]$ erlc yc2erl.erl yc2erl: function char_block/0+7: An implementation limit was reached. Try reducing the complexity of this function. Instruction: {move,{x,0},{y,2558}} ============================================= This is basically the same "large indexable structure" I asked couple days ago about (how to get the most efficient indexed access). If compilation of such a large tuple fails, what is the other way to build such a structure into a program (other than reading it from an external file)? Thanks. PS Implementation of the same in C (Hugs, GHC) and Javascript had no problems at all. See e. g. http://darcs.haskell.org

Re: Some mnesia oddity

Dan Gudmundsson — 2008-08-29T11:20:07

Chandru wrote: I was just checking it out and came to the same conclusion. It is not valid, but I agree about the mystery..will fix as soon as possible. Thanks /Dan

Re: Some mnesia oddity

Chandru — 2008-08-29T11:02:12

Re: term_to_binary and record improvements

Joe Armstrong — 2008-08-29T10:07:03

2008/8/29 Bjorn Gustavsson gmail.com>: So exactly why is it slower? - I assume you'd need two passes - and have to toggle some "this word has been moved" bit in the original term (is this correct) on the plus side the output term will be smaller so have better cache behavior. Traversing a term twice should be no problem for a small term, since it is small it will be fast - but for a large term will take a long time, but here the cache advantages could help. Only the programmer knows if a term shares much data, so we could have two bifs term_to_shared_binary and term_to_binary both of which can be unpacked with binary_to_term. Both are declaratively correct, but the hint will help performance. Would this be a solution? - if so we could then implement records with slightly more complex data structures. ie #foo{name,age} might internally be the tuple {{'foo-name-age',[name,age]}, Name, Age} (or something in line with Richard's proposal http://www.erlang.org/pipermail/erlang-questions/2005-Sep

Re: term_to_binary and record improvements

Kenneth Lundin — 2008-08-29T09:54:55

Hi, We have discussed if we should implement sharing of data structures while copying and when creating the external representation. Our thoughts goes like this: - The lack of sharing has never been brought up as a significant problem for telecom and other com or HA products built with erlang. Therefore we have not prioritized a solution for this. - Keeping the sharing while copying has impact on: - Message passing - insertion in ets-tables - the external format for Erlang terms among other things used in the Erlang distribution and produced by term_to_binary. A sharing preserving solution for the cases above will be more costly than the current implementation since it is not possibly to destroy the source term as can be done in the GC case. Because of the negative impact on performance in cases where there is no sharing or need for sharing, which definitely is the dominating case we don't think it is feasible to implement and use a sharing solution as default for the cases above. What coul

Some mnesia oddity

Nicolas Thauvin — 2008-08-29T09:47:53

Hi folks, We found a strange mnesia behavior here... Some mnesia:write operations after a mnesia:delete_object seem to not have the expected result when executed in the same transaction. See attached example file: 1 - We fill a test_table 2 - In the same transaction, we read all records, delete them, and write them back (do not ask why :)) 3 - Surprise! Only a subset of them can be read afterwards Same result in R11 and R12. It works if the delete_object and write operations are in separate transactions... But who knows what can happen between them... Can someone explain this? Thanks, -- Nicolas Thauvin

Re: term_to_binary and record improvements

Ulf Wiger — 2008-08-29T09:25:57

2008/8/29 Bjorn Gustavsson gmail.com>: I'm not surprised. Otherwise, I'm sure you'd have made message passing sharing-preserving long ago. ;-) BR, Ulf W

Re: term_to_binary and record improvements

Christian — 2008-08-29T09:22:09

And if it is not possible to get both, there is the erlang:term_to_binary/2 where an option could be provided to be explicit on how powerful sharing-detection one wants (as per the list Richard A. O'Keefe provided for example). Maximal sharing detection could be useful for dets-tables where the explosion also matters, and where maximal detection still takes much less time than the actual writing to disk. (another semi-related issue is to optimize the size of atoms occuring in several places in the same dets file) Personally I'm having trouble seeing how one can get smaller AND faster term_to_binary, but i see how a smaller result from it could make binary_to_term faster (and needing to allocate less). That is, faster binary_to_term at the cost of slower term_to_binary.

Re: term_to_binary and record improvements

Bjorn Gustavsson — 2008-08-29T08:38:27

Re: term_to_binary and record improvements

Ulf Wiger (TN/EAB — 2008-08-29T08:03:57

Richard A. O'Keefe skrev: Having a sharing-preserving term_to_binary() would be a start, but as long as local message passing doesn't preserve sharing (neither does spawn()), we would need some big fat warning labels on the deliberate use of sharing in data structures. Come to think of it, we need those warning labels even today. There are very few corners in Erlang where a seemingly innocent code modification can cause havoc, but accidental serialization of a complex data structure is one of them. I can say from experience, as can John Hughes, that it's no fun at all when a seemingly well-working program suddenly blows up, rendering your computer useless for minutes while it tries to allocate an enormous glob of memory. In both cases, sharing was deliberately used, and in both cases the fact that the data structure is flattened when sent to another local process came as a surprise. In my case, a subtle mistake (inheriting the whole record in a fun, instead of just a single attribute) caused the blowup.

Re: : order-preserving send?

Raimo Niskanen — 2008-08-29T07:47:39

: : I'd say it is true enough. Since for this to happen, the receiving node has to be restarted 2 (or was it 3) times to wrap the node incarnation counter, and Erlang was designed under the assumption that the distributed application must detect the first node restart anyway and handle it. Plus, it is a new receiving process that receives B. A went to the old receiver. The horrible situation where you send A, B, C to a reciever and B vanishes can not happen. The receiver gets all before a certain point or all after. You are supposed to use links or monitors if you are interested in the other side's death.

Re: term_to_binary and record improvements

Joe Armstrong — 2008-08-29T07:35:44

But you don't need to *internally* a tuple {Big,Big,Big} is a pointer to a tuple on heap which is four words, the first word is {arity,3}, then the next three words are identical pointers to Big. The code for tuple_to_list should therefore look very much like the code for garbing a process heap onto a new heap. Just for fun I'll write term_to_binary in Erlang and also make a new version that shares (in Erlang) - unless somebody has already written this Actually we could use UBF as the external format! For compatibility we could write term_to_new_binary and the inverse I'm think we can make it smaller and faster ... /Joe

Re: Undirected graph Library in Erlang

Geevarghese Philip — 2008-08-29T07:22:35

Re: Undirected graph Library in Erlang

Richard Carlsson — 2008-08-29T06:51:53

You could probably implement everything you need as a simple layer on top of the digraph and digraph_utils modules. See http://www.erlang.org/doc/apps/stdlib/index.html /Richard