[erlang-questions] Fw: ct_cover broken when using packages

Andreas Stenius erlang@REDACTED
Tue Dec 16 10:58:25 CET 2008


Ops, was sent with wrong account...

----- Original Message ----- 
From: "Andreas Stenius"
To: "Tim Watson" <watson.timothy@REDACTED>; <erlang-questions@REDACTED>
Sent: Tuesday, December 16, 2008 9:47 AM
Subject: Re: [erlang-questions] ct_cover broken when using packages


> Hi,
>
> I've run into similar problems when using packages, when including for 
> instance the eunit.hrl file, which has defines that will run into the same 
> problem of referring to global packages without the needed leading dot.
>
> In my opinion, the package system is broken, in that code is dependent on 
> the package layout for accessing the global scope, so I dropped it. 
> Doesn't look like the Erlang/OTP distro uses the package functionality at 
> all any way..
>
> But I'd rather like seeing this issue addressed and fixed, since now all 
> my modules resides in only one dir, and with quite extensive names, which 
> should rather be a path..
>
> Sorry, no help here, just want to add my view to let out that we're more 
> with similiar issues.
>
> Best regards,
> Andreas Stenius
>
> ----- Original Message ----- 
> From: "Tim Watson" <watson.timothy@REDACTED>
> To: <erlang-questions@REDACTED>
> Sent: Tuesday, December 16, 2008 1:16 AM
> Subject: Re: [erlang-questions] ct_cover broken when using packages
>
>
>> Hi all,
>>
>> I've noticed that the cover tool seems to break when using packages.
>> It appears that the cover tool inserts executable code into your
>> functions such as this:
>>
>> myfunction() ->
>>    %% do something
>>    ets:<some_function>,       %% inserted by cover
>>    %% etc
>>
>> This would be fine except that in a module module 1 contained within a
>> package package1, the atom ets is resolved to 'package1.module1.ets'
>> which doesn't exist (hopefully!). The correct behaviour would be to
>> insert '.ets' or to dynamically add an "-import(ets)." to the module
>> so that 'ets' resolves to '.ets' instead.
>>
>> Has anyone else come across this? Is there a planned fix?
>>
>> Many thanks,
>>
>> Tim Watson
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>
> 







More information about the erlang-questions mailing list