[erlang-questions] Extracting detailed information from TypEr/Dialyzer

[Edmond Begumisa]

On Wed, 03 Nov 2010 20:35:13 +1100, Torben Hoffmann  
<torben.lehoff@REDACTED> wrote:

> Hi Edmond,
>
> I am a bit confused by your statements since my problem was about
> documentation of an _existing_ gen_fsm.
> It might be my ignorance about what UBF can offer that is causing this  
> (read
> Joe's payer a while ago).
>

Sorry, I probably should have first asked what you're using gen_fsm for  
before commenting :)

My comment would only helpful *if* you are using gen_fsm for socket IPC  
between two Erlang nodes or between an Erlang node and a non-Erlang  
client. In which case I was suggesting, as a point of information, that  
you consider using UBF for this in the *future* because the Erlang UBF  
contract checker's state-machine provides the exact information you are  
looking for (there's no need to go digging for it.)

> As I understand UBF it allows you to specify what a component does so  
> that
> others can interact with it in a sensible manner and you can figure out  
> if a
> given component implements a given contract - or am I missing the point
> here?
>

Yes. But along with it comes a state machine that you can use in  
situations where you'd normally use gen_fsm to "regulate" socket-based IPC  
(ie: the UBF contract *is* a set of states and what events/transitions can  
occur). I asked about this on this list recently...

http://groups.google.com/group/erlang-programming/browse_thread/thread/017db73ba5fd15d9/169c3a3afe855049?#169c3a3afe855049

> I actually thought about using UBF, but when I looked at it it seemed a  
> bit
> to immature for a mission critical system, maybe that have changed by  
> now.
>

Joseph Norton/Gemini Mobile have very robust UBF implementations (2nd link  
in previous e-mail is one of many great open-source implementations  
they've released.) These are well tested and (I understand) used in  
mission critical systems. Joseph would be in a better position to describe  
to you how they are using them. I'm using two of them -- the standard UBF  
for Erlang-to-Erlang IPC and the UBF-JSON for Erlang-to-JavaScript IPC --  
I haven't had any problems so far.

> Do not get me wrong, I firmly believe in specifying protocols and UBF  
> seems
> like a very interesting thing to use, but in a real life situation you
> sometimes have code that you want to extract information about and this  
> was
> the problem I was faced with.
>

This doesn't solve your current problem, but for future reference, I  
thought it might be good to take note that the UBF(C) state machine  
handles the information you're looking to extract very nicely so you don't  
have the problem to begin with.

> If I understand you right you are no longer using gen_fsm, right?
> How do you piece together your software then?

I was using gen_fsm only for socket IPC, but faced the exact problem you  
describe -- it was too difficult to keep track/document possible state  
transitions, events, etc. Though my initial attraction to UBF was mainly  
for other reasons (compactness and debuggability on the wire being the  
major ones as my apps need to be able to go mobile), I was pleasantly  
surprised how the UBF(C) contract checker managed state transitions and  
events more declaratively and thus more clearly than gen_fsm.

I was initially tempted to use the UBF wire protocol (UBF-A) together with  
gen_fsm and discard the state-machine provided by the UBF contract checker  
(UBF-C) under the mistaken belief that gen_fsm was somehow more robust,  
but Joe Armstrong quickly pointed out that there's nothing the gen_fsm can  
do that a well-implemented UBF(C) contract checker can't in this regard.

> I use the OTP supervisor structure all the time due to the obvious  
> benefits
> of a battle tested framework, but I would not mind adding another tool  
> to my
> tool box!!
>

Norton/Gemini UBF implementations are pretty solid and you can plug things  
into your supervision tree. For socket-based IPC, the UBF(C) contract  
checker gives you far far more that gen_fsm can simply because, as Joe  
pointed out to me, it is specialised for that sort of thing while gen_fsm  
is generic. You won't be missing anything in terms of robustness and  
reliability, if anything you increase these because states transitions and  
events are defined nicely in one place and everything is easier to debug.

Regards.

- Edmond -


> Cheers,
> Torben
>
> On Wed, Nov 3, 2010 at 10:20, Edmond Begumisa
> <ebegumisa@REDACTED>wrote:
>
>> Hi,
>>
>> I don't know how immediately useful this is (perhaps something to keep  
>> in
>> mind), but one of the attractive understated things about UBF is that  
>> you
>> define all this information in one place for both easy
>> configuration/protocol-definition and reading/self-documentation...
>>
>> http://www.sics.se/~joe/ubf/site/quick.html<http://www.sics.se/%7Ejoe/ubf/site/quick.html>
>> https://github.com/norton/ubf
>>
>> So far, I haven't regretted switching from gen_fsm to UBF(C)
>>
>> - Edmond -
>>
>>
>>
>> On Mon, 01 Nov 2010 05:58:35 +1100, Tomas Abrahamsson <
>> tomas.abrahamsson@REDACTED> wrote:
>>
>>  On Tue, Oct 12, 2010 at 09:00, Torben Hoffmann  
>> <torben.lehoff@REDACTED>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I want to extract the following information from a gen_fsm:
>>>>
>>>>  - all the states
>>>>  - the incoming events
>>>>  - possible next states
>>>>
>>>> but I want to do it per function clause and not only on the function
>>>> level
>>>> as TypEr and Dialyzer does it.
>>>>
>>>
>>> One way to do that is to copy each function clause into a
>>> separate function.  Then one can run TypEr on the expanded
>>> code.  Attached is an escript that does such an expansion
>>> of exported functions of arity 2 and 3, and also of
>>> handle_event, handle_sync_event and handle_info. The script
>>> accepts -I and -D options for include paths and macro
>>> definitions, just like erlc,and prints the expanded program
>>> on stdout.
>>>
>>> I've tried plotting state machines from the output of TypEr
>>> when run on the expanded results, and it seems to do reasonably
>>> well. I haven't done any thorough verification.
>>>
>>> It doesn't solve all of your problems: it doesn't find any
>>> outgoing messages, and it has the same limitations you
>>> already indicated when returning from a function clause in
>>> different ways, so I guess the results are roughly what
>>> you already seems to have, or what Vance's drawing tool
>>> already produces.
>>>
>>> Somehow being able to make more use of TypEr's
>>> knowledge about a file would be really interesting,
>>> for example to be able to query it for type information
>>> given various execution paths through the program,
>>> if it would be possible.
>>>
>>> BRs
>>> Tomas
>>>
>>
>>
>> --
>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>>
>
>
>


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/