Bug in c:nc, R13B01

View: New views
5 Messages — Rating Filter:   Alert me  

Bug in c:nc, R13B01

by Alex Suraci :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Excerpt from lib/stdlib/src/c.erl: http://paste.pocoo.org/show/140752/

On line 7, Fname is naively assumed to be a .beam file compiled
to the same directory where the source .erl file resided. However, this
is often false, for example when there is an `outdir' option, or when
calling `nc()' from the shell with a path to a file like "foo/bar" (in which
case compile:file just plops it in the cwd of the shell).

For example. when you call `make:all([netload])' and your Emakefile
specifies `ebin' as your outdir, it will call `c:nc' and it'll compile fine,
but the modules won't update and you'll have no idea why (until you
dig a little deeper).

So, really, the only way for this function to work properly is when
compiling with the shell's cwd being the same directory as the .erl file.

--
Alex

________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org


Re: Bug in c:nc, R13B01

by Alex Suraci :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Potential fix?: http://paste.pocoo.org/show/142193/

I'll submit a patch but I'd prefer having some input as this is kind of
a low-level part of Erlang (being in the stdlib and all).

Description of changes: if an outdir is specified, Fname should be prefixed
with that, otherwise it should be the cwd, as that's where compile:file will
put the .beam file.

- Alex

On Sun, Sep 20, 2009 at 6:33 PM, Alex Suraci <i.am@...> wrote:

> Excerpt from lib/stdlib/src/c.erl: http://paste.pocoo.org/show/140752/
>
> On line 7, Fname is naively assumed to be a .beam file compiled
> to the same directory where the source .erl file resided. However, this
> is often false, for example when there is an `outdir' option, or when
> calling `nc()' from the shell with a path to a file like "foo/bar" (in which
> case compile:file just plops it in the cwd of the shell).
>
> For example. when you call `make:all([netload])' and your Emakefile
> specifies `ebin' as your outdir, it will call `c:nc' and it'll compile fine,
> but the modules won't update and you'll have no idea why (until you
> dig a little deeper).
>
> So, really, the only way for this function to work properly is when
> compiling with the shell's cwd being the same directory as the .erl file.
>
> --
> Alex
>



--
Alex

________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org


Re: Re: Bug in c:nc, R13B01

by Mazen Harake-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I would suggest to replace

{ok, Cwd} = file:get_cwd(),
Dir = case lists:keyfind(outdir, 1, Opts) of
        {outdir, Out} -> Out;
        false -> Cwd
end,

with:

Dir = proplists:get_value(outdir, Opts, element(1, file:get_cwd())),
...

Easier to read imho.

/Mazen


Alex Suraci wrote:

> Potential fix?: http://paste.pocoo.org/show/142193/
>
> I'll submit a patch but I'd prefer having some input as this is kind of
> a low-level part of Erlang (being in the stdlib and all).
>
> Description of changes: if an outdir is specified, Fname should be prefixed
> with that, otherwise it should be the cwd, as that's where compile:file will
> put the .beam file.
>
> - Alex
>
> On Sun, Sep 20, 2009 at 6:33 PM, Alex Suraci <i.am@...> wrote:
>  
>> Excerpt from lib/stdlib/src/c.erl: http://paste.pocoo.org/show/140752/
>>
>> On line 7, Fname is naively assumed to be a .beam file compiled
>> to the same directory where the source .erl file resided. However, this
>> is often false, for example when there is an `outdir' option, or when
>> calling `nc()' from the shell with a path to a file like "foo/bar" (in which
>> case compile:file just plops it in the cwd of the shell).
>>
>> For example. when you call `make:all([netload])' and your Emakefile
>> specifies `ebin' as your outdir, it will call `c:nc' and it'll compile fine,
>> but the modules won't update and you'll have no idea why (until you
>> dig a little deeper).
>>
>> So, really, the only way for this function to work properly is when
>> compiling with the shell's cwd being the same directory as the .erl file.
>>
>> --
>> Alex
>>
>>    
>
>
>
>  


________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org


Re: Re: Bug in c:nc, R13B01

by Mazen Harake-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

EErrr... element(2, ...) I meant :D

/Mazen

Mazen Harake wrote:

> I would suggest to replace
>
> {ok, Cwd} = file:get_cwd(),
> Dir = case lists:keyfind(outdir, 1, Opts) of
>     {outdir, Out} -> Out;
>     false -> Cwd
> end,
>
> with:
>
> Dir = proplists:get_value(outdir, Opts, element(1, file:get_cwd())),
> ...
>
> Easier to read imho.
>
> /Mazen
>
>
> Alex Suraci wrote:
>> Potential fix?: http://paste.pocoo.org/show/142193/
>>
>> I'll submit a patch but I'd prefer having some input as this is kind of
>> a low-level part of Erlang (being in the stdlib and all).
>>
>> Description of changes: if an outdir is specified, Fname should be
>> prefixed
>> with that, otherwise it should be the cwd, as that's where
>> compile:file will
>> put the .beam file.
>>
>> - Alex
>>
>> On Sun, Sep 20, 2009 at 6:33 PM, Alex Suraci <i.am@...>
>> wrote:
>>  
>>> Excerpt from lib/stdlib/src/c.erl: http://paste.pocoo.org/show/140752/
>>>
>>> On line 7, Fname is naively assumed to be a .beam file compiled
>>> to the same directory where the source .erl file resided. However, this
>>> is often false, for example when there is an `outdir' option, or when
>>> calling `nc()' from the shell with a path to a file like "foo/bar"
>>> (in which
>>> case compile:file just plops it in the cwd of the shell).
>>>
>>> For example. when you call `make:all([netload])' and your Emakefile
>>> specifies `ebin' as your outdir, it will call `c:nc' and it'll
>>> compile fine,
>>> but the modules won't update and you'll have no idea why (until you
>>> dig a little deeper).
>>>
>>> So, really, the only way for this function to work properly is when
>>> compiling with the shell's cwd being the same directory as the .erl
>>> file.
>>>
>>> --
>>> Alex
>>>
>>>    
>>
>>
>>
>>  
>
>
> ________________________________________________________________
> erlang-bugs mailing list. See http://www.erlang.org/faq.html
> erlang-bugs (at) erlang.org
>


________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org


Re: Re: Bug in c:nc, R13B01

by Ulf Wiger-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Mazen Harake wrote:
> EErrr... element(2, ...) I meant :D
>
> /Mazen

...and I was just about to suggest that

{ok, Cwd} = file:get_cwd(),
Dir = proplists:get_value(outdir, Opts, Cwd),

would be even more readable. ;-)

This would also cover the case where get_cwd() returns
{error,Reason} (which can happen "in rare circumstances"
on Unix, according to the manual) - it covers it in the
sense that it fails in an understandable way, rather than
setting Dir to something unusable (a POSIX error such as
'eacces'), which would trigger a failure somewhere else.

"Make things as simple as possible, but not simpler."
(A Einstein)

BR,
Ulf W


>
> Mazen Harake wrote:
>> I would suggest to replace
>>
>> {ok, Cwd} = file:get_cwd(),
>> Dir = case lists:keyfind(outdir, 1, Opts) of
>>     {outdir, Out} -> Out;
>>     false -> Cwd
>> end,
>>
>> with:
>>
>> Dir = proplists:get_value(outdir, Opts, element(1, file:get_cwd())),
>> ...
>>
>> Easier to read imho.
>>
>> /Mazen


--
Ulf Wiger
CTO, Erlang Training & Consulting Ltd
http://www.erlang-consulting.com

________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org