[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Obsolete warning IDs
From: |
Rik |
Subject: |
Re: Obsolete warning IDs |
Date: |
Tue, 08 Nov 2011 13:13:07 -0800 |
On 11/08/2011 10:25 AM, John W. Eaton wrote:
> On 8-Nov-2011, Rik wrote:
>
> | On 11/05/2011 01:07 PM, John W. Eaton wrote:
> | > imag-to-real and num-to-str are used in various matrix functions, so
> | > they should probably not be removed. But if they are used
> | > inconsistently, then maybe we should decide whether to try to be
> | > consistent or just remove the warnings. I guess it depends on whether
> | > the inconsistent warnings are helpful.
> | I couldn't get these warnings to "fire" which is why I thought they might
> | need deletion. The documentation for num-to-str in warning_ids even gives
> | an example --- that doesn't do anything.
> |
> | [ "f", 111, 111 ]
>
> The num-to-str warning is still present for character string + numeric
> cat op functions, but those don't seem to be called because the cat
> function in data.cc and the matrix building code in pt-mat.cc are both
> intercepting these kinds of concatenation and not calling the
> individual op functions. I think we could bring back the warning
> fairly easily (see diff attached below).
The patch works for me.
> | > reload-forces-clear is used in dynamic-ld.cc, so it should probably
> | > not be removed.
> | I couldn't figure out a way to get this one to fire either. I tried
> | setting breakpoints but I never got the code to execute. This could be
> | wrapped up in the whole inability to clear command-line functions. When I
> | created a test file with multiple functions in it, and either executed or
> | sourced it, the list of functions were reported as command-line functions
> | rather than having come from a file. This warning is supposedly about
> | multiple functions coming from the same filename and that information may
> | have been lost.
>
> I think this warning only happens when reloading a .oct file that
> contains multiple function definitions.
Still no luck provoking this, although I did discover that the docstring
for bitunpack was calling itself bitpack.
For testing I randomly selected typecast.oct. The file itself has 3
functions in it: typecast, bitpack, bitunpack. I tried various
combinations of 'clear' and 'clear -f' for the three functions but never
got a warning. I then tried to create a .oct file with two functions in it
using mkoctfile, but I can only get Octave to see the first function which
has the same name as the .cc file.
--Rik