Feature, not bug

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Feature, not bug

Heber Farnsworth
Here is a little thing I noticed which is not really a problem but could
probably be handled better.  Suppose you type the name of a file in your
load path which is not a function file.  I did this when I accidentally
typed

octave:2> non2.oct

when I meant to type 'load non2.oct'.  I got the following

non2.oct =

panic: impossible state reached in file `tc-rep.cc' at line 1764
error: Illegal instruction -- stopping myself...

This is not a problem since Octave quits nice and cleanly (thanks to good
programming by jwe) but perhaps it could be handled better.  This would
have been very frustrating if I had spent a long time manipulating some
data but had not saved it.  It would be flushed because of a silly typing
error.

Just a thought.

  Heber Farnsworth                               | Department of Finance
  Univerity of Washington                        | Box 353200
  tele:  (206) 528-0793 home                     | Seattle, WA 98195-3200
  tele:  (206) 543-4773 finance     web: http://weber.u.washington.edu/~heberf
  fax:   (206) 685-9392             email: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Feature, not bug

Ted.Harding
( Re Message From: Heber Farnsworth )

>
> Here is a little thing I noticed which is not really a problem but could
> probably be handled better.  Suppose you type the name of a file in your
> load path which is not a function file.  I did this when I accidentally
> typed
>
> octave:2> non2.oct
>
> when I meant to type 'load non2.oct'.  I got the following
>
> non2.oct =
>
> panic: impossible state reached in file `tc-rep.cc' at line 1764
> error: Illegal instruction -- stopping myself...
>
> This is not a problem since Octave quits nice and cleanly (thanks to good
> programming by jwe) but perhaps it could be handled better.  This would
> have been very frustrating if I had spent a long time manipulating some
> data but had not saved it.  It would be flushed because of a silly typing
> error.

This does not occur in the circumstances Heber suggests (i.e. giving the
name of a file as a command to octave, where the file extension looks like
a structure member):

    octave:25> save -binary non2.oct data_seg
    octave:26> non2.oct
    error: `non2' undefined near line 26 column 1
    error: evaluating expression near line 26, column 1
    octave:27>

which is what I would have expected anyway. Octave stays up. Octave also
survives attempts to address structure members of variables which are not
structures ("error: invalid structure access attempted").

It DOES occur if you do it using the name of a function (user-defined or
built-in):

    octave:10> erf.oct
    erf.oct =

    panic: impossible state reached in file `tc-rep.cc' at line 1764
    error: IOT trap/Abort -- stopping myself...

So I guess that Heber had a function "non2" which generated data that he
saved to "non2.oct". The mishap, therefore, seems to be due to how octave
handles attempts to address structure members of functions. Given the
error message ("impossible state ... "), this suggests an unforeseen
case of parsing error.

On the other hand, octave does manage to trap attempts to define
"structure-like" function names:

    octave:3> function y = non2.oct(x)
    parse error:

    >>> function y = non2.oct(x)
                         ^


Cheers,
Ted.                                    ([hidden email])

Reply | Threaded
Open this post in threaded view
|

Re: Feature, not bug

John W. Eaton-6
On 28-Nov-1996, Ted Harding <[hidden email]> wrote:

: It DOES occur if you do it using the name of a function (user-defined or
: built-in):
:
:     octave:10> erf.oct
:     erf.oct =
:
:     panic: impossible state reached in file `tc-rep.cc' at line 1764
:     error: IOT trap/Abort -- stopping myself...
:
: So I guess that Heber had a function "non2" which generated data that he
: saved to "non2.oct". The mishap, therefore, seems to be due to how octave
: handles attempts to address structure members of functions. Given the
: error message ("impossible state ... "), this suggests an unforeseen
: case of parsing error.

In any case, this problem appears to be fixed in the current sources:

  octave:1> erf.oct
  error: can't perform structure reference operations for <unknown type> type
  error: evaluating expression

Thanks,

jwe