http://blog.gmane.org/gmane.comp.lang.erlang.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lang.erlang.general/32325 Charles Thompson 2008-08-21T17:11:32 http://permalink.gmane.org/gmane.comp.lang.erlang.general/32324 Olivier BOUDEVILLE 2008-08-21T13:34:12 http://permalink.gmane.org/gmane.comp.lang.erlang.general/32323 You are absolutely right! Typing message too quickly without thinking is quite embarrassing. :-( What I really should have asked was whether the limit was 0xffffFFFF (2^32-1) or 0x7FFFffff (2^31-1). Though your comment below explained my main concern regarding bignums. Thank you very much! Serge Serge Aleynikov 2008-08-21T11:57:08 http://permalink.gmane.org/gmane.comp.lang.erlang.general/32322 Jos Visser 2008-08-21T11:39:57 http://permalink.gmane.org/gmane.comp.lang.erlang.general/32321 I'm (very slowly) working on one here: http://github.com/tim/erlang-protobuf/tree/master And there's another here: http://github.com/bwbuchanan/erl_pb/tree/master Tim Fletcher 2008-08-21T11:35:36 http://permalink.gmane.org/gmane.comp.lang.erlang.general/32320 Mikael Kais 2008-08-21T10:48:18 http://permalink.gmane.org/gmane.comp.lang.erlang.general/32319 This is completely against current Erlang practice. Currently if a module A uses module B, noone checks if B contains the used functions or not. Neither at compile time, nor at module load time. I think because the check would make module upgrades way more difficult. Think about a module B using a function AF from module A. In the next version of the modules, the function A:AF is removed and B is not using it any more. Currently you just load the two modules. In the presence of a load-time check, you'd have to load module B first, then A. No problem here. Now think about a module A using B's BF and B using A's AF. When both functions are removed, there is no legal upgrade order. The same problem exists with checked pure functions. Module A using B's pure BF (and expects it to be pure), and B using A's pure AF (and expects it to be pure). In the next version both the functions switch to impure, together with their consumers. There is no legal upgrade order :-( There probably are solutions (simultaneous atomic loading of several modules? using extra transition module versions to make the upgrade possible?), but current module upgrading technology/practice must change radically. Georgy Andras Georgy Bekes 2008-08-21T10:16:23 http://permalink.gmane.org/gmane.comp.lang.erlang.general/32318 Matt Williamson 2008-08-21T09:27:15 http://permalink.gmane.org/gmane.comp.lang.erlang.general/32317 Mapping monitor references to context value is the obvious way, I do it over and over again and want to avoid repeating it. Having a single monitor service process might be worthwhile, but it smells like premature optimization compared to a process for each monitor. I'll keep it in mind though, since it would be a reusable component. Christian S 2008-08-21T08:42:43 http://permalink.gmane.org/gmane.comp.lang.erlang.general/32316 Also, you already have the quite specific "ref" associated with the monitor, which you could use as a key in a dict or ets table for the extra information. Or combine the two ideas, having a single process that hides the refs, the 'DOWN' messages, and the table, acting as a "user-friendly monitor service". /Richard Richard Carlsson 2008-08-21T08:31:33 http://permalink.gmane.org/gmane.comp.lang.erlang.general/32315 Since the process that monitors get the {'DOWN',,,,} message, containing an unique ref, it can just as well keep the context value itself and look it up from the ref. This decreases the size of the messages involved. On Wed, Aug 20, 2008 at 11:11:13PM +0200, Christian S wrote: Raimo Niskanen 2008-08-21T08:16:16 http://permalink.gmane.org/gmane.comp.lang.erlang.general/32314 That's *smack-forehead* easy! :) I can also hide the (to me) somewhat ugly looking 'DOWN' message with something more specific. Iz nice! Christian S 2008-08-21T08:01:57 http://permalink.gmane.org/gmane.comp.lang.erlang.general/32313 Greetings, Perhaps it is possible to use another process? Give this process a "context" value, let it monitor the target process. When the monitor message arrives just send the monitor message and the value to the ''original process'' (the one that wanted to monitor in the beginning). bengt On Wed, 2008-08-20 at 23:11 +0200, Christian S wrote: Bengt Kleberg 2008-08-21T07:08:28 http://permalink.gmane.org/gmane.comp.lang.erlang.general/32312 devdoer bird 2008-08-21T06:30:27 http://permalink.gmane.org/gmane.comp.lang.erlang.general/32311 Bjorn Gustavsson 2008-08-21T03:45:49 http://permalink.gmane.org/gmane.comp.lang.erlang.general/32310 After looking at your code for the second time, I see that the init function is wrong - it should be: init([StartArgs]) -> ... Try that. You are not indicating here what the error is, but if it is function_clause, then that's it. Serge Matt Williamson wrote: Serge Aleynikov 2008-08-20T22:06:55 http://permalink.gmane.org/gmane.comp.lang.erlang.general/32309 Christian S 2008-08-20T21:11:13 http://permalink.gmane.org/gmane.comp.lang.erlang.general/32308 Dear CouchDB Folks, sorry for the shameless self-promotion: This is a bit of a short notice, and I apologise, but things moved quickly here. I'll be spending three couchy days in London next week. On Tuesday night, that is the 26th, I'll be speaking about CouchDB[1] at Erlang Training and Consulting[2] starting 6:30 pm. And you are all invited! The event is free! You just need to register[3]. If you can't make it and want to grab a cold beverage or anything, just drop me a line. Cheers Jan -- [1] http://www.erlang-consulting.com/erlang/events.html#63 [2] http://www.erlang-consulting.com/ [3] http://www.erlang-consulting.com/erlang/usergroup/erlanglondon/lugregister.html?event=Couch%20DB%20at%2010,000%20ft Jan Lehnardt 2008-08-20T18:46:50 http://permalink.gmane.org/gmane.comp.lang.erlang.general/32307 Matt Williamson 2008-08-20T18:01:01 http://permalink.gmane.org/gmane.comp.lang.erlang.general/32306 In your implementation it's possible that the init/1 call returns: {ok, State, StateData} | ok The second return type is not valid (the Else clause in case statement). (I doubt that this is actually the error you are hitting as if the init function is not called it means that you are not starting gen_fsm correctly via gen_fsm:start_link(Module, Args::list(), [])). Also, before you start debugging processes based on gen behaviors enable SASL so that the error reports are more verbose: erl -boot start_sasl Serge Matt Williamson wrote: Serge Aleynikov 2008-08-20T17:03:47 http://permalink.gmane.org/gmane.comp.lang.erlang.general/32305 Hi Matt, Sorry this might be a stupid question but did you send it an event? /Mazen Matt Williamson wrote: Mazen Harake 2008-08-20T17:00:51 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.erlang.general