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

[Torben Hoffmann]

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).

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?

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.

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.

If I understand you right you are no longer using gen_fsm, right?
How do you piece together your software then?
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!!

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/
>



-- 
http://www.linkedin.com/in/torbenhoffmann