Re: compiling development sources

[Jaroslav Hajek]

On Wed, Feb 10, 2010 at 10:44 PM, John W. Eaton <address@hidden> wrote:
> On 10-Feb-2010, Jaroslav Hajek wrote:
>
> | I checked in the following patch:
> | http://hg.savannah.gnu.org/hgweb/octave/rev/2ceae0b40515
> |
> | hope this solves the problem for you.
>
> The last hunk of that change is
>
> @@ -530,7 +537,13 @@
>    3.39            if (btyp != btyp_unknown)
>    3.40              dispatch_type = btyp_class_name[btyp];
>    3.41            else
>    3.42 -            builtin_class = false;
>    3.43 +            {
>    3.44 +              // Basically, this should never happen if all values 
> are defined.
>    3.45 +              // If not, that's an internal inconsistency.
>    3.46 +              builtin_class = false;
>    3.47 +              error ("internal error: undefined or invalid value in 
> argument list");
>    3.48 +            }
>    3.49 +
>    3.50          }
>    3.51      }
>
> If this is an internal error, is there some reason to not use
> panic_impossible?
>

It doesn't matter any more. I partially reverted the patch and
implemented a better solution. This should even play more nicely with
compiled extensions like "fixed". One should be even able to put some
fixed-point methods to @fixed.

> Or, do you think we should consider removing panic_impossible in favor
> of error so that internal errors don't cause Octave to abort?
>
> In addition to calls to panic_impossible, we also have some direct
> calls to assert and abort.
>
> I guess I'd like to be consistent in the way we handle internal "this
> can't happen" kinds of errors.
>

You're right, it should have been a panic_impossible, I just thought
that it might be not so impossible.
Generally, I think the asserts and aborts are OK. In some places, you
really can't do better.

regards

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