Re: New parser and command line functions

[John W. Eaton]

On 03/13/2013 04:52 PM, Michael D. Godfrey wrote:
> On 03/13/2013 12:58 PM, John W. Eaton wrote:
> > On 03/13/2013 12:02 PM, Rik wrote:
> > > 3/13/13
> > >
> > > John,
> > >
> > > You might want to take a look at the parsing of command line
> > > functions. I
> > > tried this,
> > >
> > > octave:1> function y = mysin (x)
> > > > y = sin (x);
> > > > endfunction
> > > �: interpfcn/symtab.h:2039: static void
> > > symbol_table::set_curr_fcn(octave_user_function*, int): Assertion
> > > `scope !=
> > > xtop_scope&& scope != xglobal_scope' failed.
> > > Abort
> > >
> > > and got thrown back to the shell.
> >
> > It seems to work for me, so I'm not sure how to debug the problem.
> >
> > > Not that I want to invest the time, but this bug and the previous one
> > > with
> > > debugging, could only be caught by an interactive test suite such as one
> > > written with expect. Our current m-file based strategy doesn't get at
> > > these.
> >
> > The test suite used to be in expect (DejaGNU) but it was somewhat
> > harder to write tests than it is now. And, as I remember it, slower to
> > run the tests, because each one started a new Octave process. Maybe
> > those problems could be avoided by automatically generating the tests
> > for expect from the current tests we have and using some other method
> > of running them with expect that what we were using. But as you imply,
> > it would take some time to make that work...
> >
> > jwe
> Well, on fc18 x86 and latest devel:
> octave:1> function y = mysin (x)
>  > y = sin (x);
>  > endfunction
> octave: interpfcn/symtab.h:2039: static void
> symbol_table::set_curr_fcn(octave_user_function*,
> symbol_table::scope_id): Assertion `scope != xtop_scope && scope !=
> xglobal_scope' failed.
> Abort (core dumped)
> [pbdsl3:octave]
>
> So, there does seem to be a problem.
> Is there more information that I could provide?

32-bit system?

GCC version?

Maybe I could try to reproduce on a 32-bit system.

Rik, is your OS also 32-bit?

Can you duplicate the problem when running with gdb and generate a stack 
trace?

jwe