And thanks for your work in looking into this!  I'm sure *everyone*
will appreciate it. =)

steven

On Dec 1, 2007 11:52 AM, Anthony Kozar <anthonykozar@sbcglobal.net> wrote:
> Steven Yi wrote on 11/30/07 5:34 PM:
>
> > As for the new parser, having good error reporting is definitely a
> > goal, but as of yet it has not been worked on in the sleightest.
> > (When there is an error now in the parser, you get a segfault...).
>
> Ah ... thanks for the info, Steven.  I guess fixing the current error
> messages should be a worthwhile investment then.
>
> > I see you're already working on things with the older parser.
> > Regardless of old or new, what we need to handle better line numbering
> > I think is a stack of linenumber structs that just have filename and
> > line number.  That way when we're in an included file, we'd get
> > something like:
>
> Sure.  I was thinking of something along these lines.  The score parser may
> already do this to some extent -- there is a "line" member of the IN_STACK
> struct that gets incremented.  But those numbers are not used to report
> errors.  Instead a global lincnt variable is used and it maintains a count
> of all score lines that have been processed (including macro expansions and
> section repeats, I believ).  Perhaps using the IN_STACK count would be a
> better solution already.
>
> > In file xxx.csd line 80:
> > In included file yyy.inc line 3:
> > Error: something went horribly awry!
>
> I was not going to modify the format of the existing error messages, at
> least not without the permission of other developers.  A sort of "backtrace"
> for error locations -- or at least a simple line X in file Y -- would be a
> big improvement though.  Sometimes the location of the error could be in a
> macro expansion too, so we might want to do (if possible):
>
> In expansion of macro $MYMACRO, line 2:
> In file myfile.csd, line 34:
>
> What does everyone think about changing the messages.  They could also be
> made more uniform (especially the score errors, some of which do not provide
> any context info).
>
> > Or any number of levels deep. We could also have an offset field so
> > that those can handle the offset lines when reading a CSD.
>
> I thought this would be the simple solution for correcting the CSD line
> numbers.  (And a simple offset would allow maintaining the orc/sco relative
> numbering as requested by Matt).
>
> > I would imagine adding some functions to encapsulate all of this too,
> > to push and pop linenumber structs.
>
> Sure.  I will want to make it all structured so that future additions only
> need to make the right function call.  (Currently, the score error reporting
> is not like this).
>
> Thanks for your suggestions, Steven!
>
> Anthony Kozar
> anthonykozar AT sbcglobal DOT net
> http://anthonykozar.net/
>
>
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net