Re: fopen always returns fid=-1 since revision 8380

[Jaroslav Hajek]

On Mon, Dec 8, 2008 at 4:56 PM, Thomas Treichl <address@hidden> wrote:
> Jaroslav Hajek schrieb:
>>
>> Thomas,
>>
>> I guess that by 8380 you meant 8379, because 8380 in savannah is "fix
>> & improve speed of diagonal matrix multiplication". Or is it the other
>> way around? Please clarify.
>
> Hi Jaroslav,
>
> thank you for your quick answer. It was this one (8379) that I meant, you're
> right:
>
>  http://hg.savannah.gnu.org/hgweb/octave/rev/ad8ed668e0a4
>
> Now I've to say that I learned something new. I always do
>
>  hg update -C
>
> where '-C' stands for "-C --clean  overwrite locally modified files". I took
> 8380 from my local machine repository but commited something else before
> locally (that's why I was talking about my local 8380 but meant savannah
> 8379).
>
> What I would expect if I do 'hg update -C' is that 8375 in my local
> repository is thrown to nirvana - but it's still there. Now I've got another
> question, which hg subcommand must I take to completely overwrite all my
> changes with the savannah sources? Is there any subcommand, or must I always
> clone a repository to get the original files?
>

No, a changeset can never disappear this way. When you committed your
8375, and then pulled, you created a branch. `hg heads` will show you
two heads in that repo. Head is a "tree leaf", a changeset with no
child. Now yo have two branches of code ni your repo, and you can
switch between them, or merge them using `hg merge`.

>> Did you rerun ./autogen.sh to regenerate the configure scripts? That
>> is probably necessary, because the old definition
>> of macro OCTAVE_LOCAL_BUFFER was directly in config.h.
>
> Twice a year I forget about 'autogen.sh'.

You're not alone :)

> This time I did forget about it,
> too. I also cloned the savannah repository and created a new one on my
> computer. Then the problem disappeared.
>

Some time ago I suggested that configure could warn if it finds that
configure.in exists and is newer, using  test -nt. JWE, however,
pointed out that test -nt is not portable.

>> In any case OCTAVE_LOCAL_BUFFER now *should* work with bools (as
>> opposed to the old one), therefore your patch is not the right way to
>> do (unless we become really desperate).
>
> Yes right.
>
>> If the answer to the above question is yes, please check for
>> HAVE_DYNAMIC_AUTO_ARRAYS in config.h.
>
> My lines in config.h look like
>
>  /* Define if C++ supports dynamic auto arrays */
>  #define HAVE_DYNAMIC_AUTO_ARRAYS 1
>
> No need to set it '0', right?

Only if you kept seeing the failure after correct rebuilding (and I
read it above that you didn't). When this option is on, a more
complicated version of OCTAVE_LOCAL_BUFFER macro using stack arrays
for small buffers will be used.

>
>> If it's defined, please try disabling it and compile again (will
>> recompile just about everything apart from libcruft, unfortunately). I
>> suspect that dynamic stack arrays can be buggy with some compilers.
>> What's your compiler, anyway?
>
> A self made f2c/fort77 combination together with gcc/g++ 4.0.1.
>

Huh. Why aren't you using gfortran?

> Sorry for the noise, thanks for your tips and best regards,
>
>  Thomas
>

you're welcome.

-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz