Hi everyone. I have a question with a problem I am having regarding the 
csound console output and the API. When I run my csd file from the 
command line using the latest csound.exe with an error it tells me the 
correct line the error is on. If I run the .csd file through my own 
software, calling the same dll csound.exe does, and output the message 
using the message callback routine I get a different/wrong number? Any 
ideas what might be causing this? Here is the message callback code 
although I don't think it has anything to do with that...

void csoundMessageCall(CSOUND* csound, int attr, const char* format, 
va_list valist)
{
AnsiString csoundMess;
csoundMess.vprintf(format, valist);
RichEdit1->Lines->Add(csoundMess);
}

Rory.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

No wonder beginners often get confused! It does seem to work fine for me 
on the few things I tried from the command line. It's weird that I get a 
problem when running using API. Thanks for the pointer.

Rory.

Istvan Varga wrote:
> On Thursday 13 April 2006 18:01, Rory Walsh wrote:
> 
>> Hi everyone. I have a question with a problem I am having regarding the 
>> csound console output and the API. When I run my csd file from the 
>> command line using the latest csound.exe with an error it tells me the 
>> correct line the error is on. If I run the .csd file through my own 
>> software, calling the same dll csound.exe does, and output the message 
>> using the message callback routine I get a different/wrong number? Any 
>> ideas what might be causing this? Here is the message callback code 
>> although I don't think it has anything to do with that...
> 
> While I do not know exactly why you get this difference, it is a well
> known and long existing problem that line numbers are often not printed
> correctly in syntax errors. Even worse, fixing the line numbers is
> probably not easy without major code changes.
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Saying that, there is still plenty of info there to help sort the 
problem. It's not going to be a problem for what I'm doing, I was just 
curious.

Rory Walsh wrote:
> No wonder beginners often get confused! It does seem to work fine for me 
> on the few things I tried from the command line. It's weird that I get a 
> problem when running using API. Thanks for the pointer.
> 


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

My guess would be that somewhere in the callback code, there may be an
integer type being incorrectly coerced to the wrong type.  The extra
parameters in valists are of void* type and thus could be interpreted as
anything without a compiler warning being issued.

Are the wrong numbers reasonable?  In other words, are they small positive
integers that are reasonably close to the correct value that you get with
the console?  Or are they completely bogus ( -246790098, or 56700094, etc.).
The later would indicate that a valist parameter is being incorrectly
interpreted.  (But the former would not necessarily indicate that it is OK).

My suggestion is to set a breakpoint on your callback and see what values
are being passed to it from Csound.  If the passed values are correct, then
step through your code until you see where it is changing.

Anthony Kozar
anthonykozar AT sbcglobal DOT net


Istvan Varga wrote on 4/13/06 11:45 AM:

> On Thursday 13 April 2006 18:01, Rory Walsh wrote:
> 
>> Hi everyone. I have a question with a problem I am having regarding the
>> csound console output and the API. When I run my csd file from the
>> command line using the latest csound.exe with an error it tells me the
>> correct line the error is on. If I run the .csd file through my own
>> software, calling the same dll csound.exe does, and output the message
>> using the message callback routine I get a different/wrong number? Any
>> ideas what might be causing this? Here is the message callback code
>> although I don't think it has anything to do with that...
> 
> While I do not know exactly why you get this difference, it is a well
> known and long existing problem that line numbers are often not printed
> correctly in syntax errors. Even worse, fixing the line numbers is
> probably not easy without major code changes.



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

There fairly close, but not consistent as far as I can make out. For 
some csd's they could be three out and for others they could be more. 
I'll look into it again, thankfully it's not going to affect my work in 
the least bit.

Rory.


Anthony Kozar wrote:
> My guess would be that somewhere in the callback code, there may be an
> integer type being incorrectly coerced to the wrong type.  The extra
> parameters in valists are of void* type and thus could be interpreted as
> anything without a compiler warning being issued.
> 
> Are the wrong numbers reasonable?  In other words, are they small positive
> integers that are reasonably close to the correct value that you get with
> the console?  Or are they completely bogus ( -246790098, or 56700094, etc.).
> The later would indicate that a valist parameter is being incorrectly
> interpreted.  (But the former would not necessarily indicate that it is OK).
> 
> My suggestion is to set a breakpoint on your callback and see what values
> are being passed to it from Csound.  If the passed values are correct, then
> step through your code until you see where it is changing.
> 
> Anthony Kozar
> anthonykozar AT sbcglobal DOT net
> 
> 
> Istvan Varga wrote on 4/13/06 11:45 AM:
> 
>> On Thursday 13 April 2006 18:01, Rory Walsh wrote:
>>
>>> Hi everyone. I have a question with a problem I am having regarding the
>>> csound console output and the API. When I run my csd file from the
>>> command line using the latest csound.exe with an error it tells me the
>>> correct line the error is on. If I run the .csd file through my own
>>> software, calling the same dll csound.exe does, and output the message
>>> using the message callback routine I get a different/wrong number? Any
>>> ideas what might be causing this? Here is the message callback code
>>> although I don't think it has anything to do with that...
>> While I do not know exactly why you get this difference, it is a well
>> known and long existing problem that line numbers are often not printed
>> correctly in syntax errors. Even worse, fixing the line numbers is
>> probably not easy without major code changes.
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The lines containing CSD tags  and  
are not being counted.  I think the parser starts counting line numbers after
 and that's part of the reason why error line #'s seem to be off.

Davis

--- Rory Walsh  wrote:

> There fairly close, but not consistent as far as I can make out. For 
> some csd's they could be three out and for others they could be more. 
> I'll look into it again, thankfully it's not going to affect my work in 
> the least bit.
> 
> Rory.



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

i would think also #includes and macros might throw things off

but if this problem is tackled, may i request
please keep the ability (as an option?) to report error lines per orc  
(ignoring csd tags)
for host applications that display the orc portion of a csd alone.

-m

On Apr 13, 2006, at 3:29 PM, Davis Pyon wrote:

> The lines containing CSD tags  and 
> are not being counted.  I think the parser starts counting line  
> numbers after
>  and that's part of the reason why error line #'s  
> seem to be off.
>
> Davis
>
> --- Rory Walsh  wrote:
>
>> There fairly close, but not consistent as far as I can make out. For
>> some csd's they could be three out and for others they could be more.
>> I'll look into it again, thankfully it's not going to affect my  
>> work in
>> the least bit.
>>
>> Rory.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the  
> live webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Yes I noticed this alright. Seems fair enough to start counting lines 
from the start of the instrument section. Following Anthony's advice I 
checked to see what line numbers are actually being passed to my 
csoundMessageCallBack. It seems the error is taking place before my 
callback function as the numbers being passed as arguments to my 
function are incorrect. I don't really have time to investigate this 
more, for me this is a big red herring. Cheers,

Rory.



matt ingalls wrote:
> i would think also #includes and macros might throw things off
> 
> but if this problem is tackled, may i request
> please keep the ability (as an option?) to report error lines per orc 
> (ignoring csd tags)
> for host applications that display the orc portion of a csd alone.
> 
> -m
> 
> On Apr 13, 2006, at 3:29 PM, Davis Pyon wrote:
> 
>> The lines containing CSD tags  and 
>> are not being counted.  I think the parser starts counting line 
>> numbers after
>>  and that's part of the reason why error line #'s seem 
>> to be off.
>>
>> Davis
>>
>> --- Rory Walsh  wrote:
>>
>>> There fairly close, but not consistent as far as I can make out. For
>>> some csd's they could be three out and for others they could be more.
>>> I'll look into it again, thankfully it's not going to affect my work in
>>> the least bit.
>>>
>>> Rory.
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
>> language
>> that extends applications into web and mobile media. Attend the live 
>> webcast
>> and join the prime developer group breaking into this new coding 
>> territory!
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live 
> webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Istvan,

It would be very worth putting some time into this... it is hard  
enough for a beginner to deal with
all the errors in their code, but then for the little *clues* that  
the language gives to point you to
the wrong line, place, opcode, scorecode - it's another of Csound's  
discouragers...  Hate to loose
even a single new user.

Dr. B.


On Apr 13, 2006, at 11:45 AM, Istvan Varga wrote:

> On Thursday 13 April 2006 18:01, Rory Walsh wrote:
>
>> Hi everyone. I have a question with a problem I am having  
>> regarding the
>> csound console output and the API. When I run my csd file from the
>> command line using the latest csound.exe with an error it tells me  
>> the
>> correct line the error is on. If I run the .csd file through my own
>> software, calling the same dll csound.exe does, and output the  
>> message
>> using the message callback routine I get a different/wrong number?  
>> Any
>> ideas what might be causing this? Here is the message callback code
>> although I don't think it has anything to do with that...
>
> While I do not know exactly why you get this difference, it is a well
> known and long existing problem that line numbers are often not  
> printed
> correctly in syntax errors. Even worse, fixing the line numbers is
> probably not easy without major code changes.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the  
> live webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hello everyone,

I have been looking into adding a command-line flag like
"--check-syntax-only" at the request of Joakim Verona.  This is fairly
trivial but also fairly useless for his purposes since Csound frequently
reports the wrong line numbers for syntax errors.

I have identified at least six causes for incorrect line numbers:

1. Using a CSD.  (Csound reports the line # in the temporary .orc).
2. Including another file with #include.
3. #include-ing a non-existent file.  (That line is not counted).
4. Defining a macro.  (All lines in the definition count as one line).
5. Invoking a macro. (Counts as the number of lines in the macro).
6. Using a backslash \ to continue a statement on the next line.
   (All lines in the continuation count as one line).

I am interested in trying to correct at least some of these issues.  My
question is how worthwhile is it to invest time on them?  (For example, I
think a solution to #1 may not be too difficult).

Steven has been making progress on the new parser.  Will the new parser be
able to report correct line numbers (and files for #includes) for errors?

I am very interested to hear your thoughts.

Anthony Kozar
anthonykozar AT sbcglobal DOT net
http://anthonykozar.net/

PS.  I've included a CSD below that shows all of these issues -- the
comments indicate how Csound is reporting line numbers.

Istvan Varga wrote on 4/13/06 11:45 AM:

> it is a well
> known and long existing problem that line numbers are often not printed
> correctly in syntax errors. Even worse, fixing the line numbers is
> probably not easy without major code changes.




#include "error-lines.inc"                ; lines 1-3
#include "dummyfile"                      ; not counted

instr 1                                   ; line 5
            oscili  15000, \              ; line 6
                    440.0, \              ; line 6
                    1                     ; line 6
            out     aoscleft, \           ; line 7
                    aoscright             ; line 7
; endin

#define MACRO #   aconst  init  0.707     ; line 10
   out     aconst, abogus                 ; line 10
#                                         ; line 10

instr 2                                   ; line 12
$MACRO                                    ; lines 13-14
                                          ; line 15


f1 0 4096 10 1

i1 0 2
e




-----------------------------------
file "error-lines.inc" has 3 lines:
-----------------------------------
instr 3
    out  adummy
endin


-------------------------------------------------------------------------
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

I would love to see this issue resolved, and so would my students.

Rory.





Anthony Kozar wrote:
> Hello everyone,
> 
> I have been looking into adding a command-line flag like
> "--check-syntax-only" at the request of Joakim Verona.  This is fairly
> trivial but also fairly useless for his purposes since Csound frequently
> reports the wrong line numbers for syntax errors.
> 
> I have identified at least six causes for incorrect line numbers:
> 
> 1. Using a CSD.  (Csound reports the line # in the temporary .orc).
> 2. Including another file with #include.
> 3. #include-ing a non-existent file.  (That line is not counted).
> 4. Defining a macro.  (All lines in the definition count as one line).
> 5. Invoking a macro. (Counts as the number of lines in the macro).
> 6. Using a backslash \ to continue a statement on the next line.
>    (All lines in the continuation count as one line).
> 
> I am interested in trying to correct at least some of these issues.  My
> question is how worthwhile is it to invest time on them?  (For example, I
> think a solution to #1 may not be too difficult).
> 
> Steven has been making progress on the new parser.  Will the new parser be
> able to report correct line numbers (and files for #includes) for errors?
> 
> I am very interested to hear your thoughts.
> 
> Anthony Kozar
> anthonykozar AT sbcglobal DOT net
> http://anthonykozar.net/
> 
> PS.  I've included a CSD below that shows all of these issues -- the
> comments indicate how Csound is reporting line numbers.
> 
> Istvan Varga wrote on 4/13/06 11:45 AM:
> 
>> it is a well
>> known and long existing problem that line numbers are often not printed
>> correctly in syntax errors. Even worse, fixing the line numbers is
>> probably not easy without major code changes.
> 
> 
> 
> 
> #include "error-lines.inc"                ; lines 1-3
> #include "dummyfile"                      ; not counted
> 
> instr 1                                   ; line 5
>             oscili  15000, \              ; line 6
>                     440.0, \              ; line 6
>                     1                     ; line 6
>             out     aoscleft, \           ; line 7
>                     aoscright             ; line 7
> ; endin
> 
> #define MACRO #   aconst  init  0.707     ; line 10
>    out     aconst, abogus                 ; line 10
> #                                         ; line 10
> 
> instr 2                                   ; line 12
> $MACRO                                    ; lines 13-14
>                                           ; line 15
> 
> 
> f1 0 4096 10 1
> 
> i1 0 2
> e
> 
> 
> 
> 
> -----------------------------------
> file "error-lines.inc" has 3 lines:
> -----------------------------------
> instr 3
>     out  adummy
> endin
> 
> 
> -------------------------------------------------------------------------
> 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

I have finished adding the new flag --syntax-check-only (committed last
night) and I am looking at some problems with handling score errors now.

There seem to be more reasons for incorrect line numbers being reported than
I realized.  When sread finds an illegal opcode, it flushes the rest of the
line and I think it forgets to increment the line count.  Also, I
encountered a situation that seems like poor error handling to me because it
keeps processing a line after an error was found:


f1 0 4096 10 1

i1 0 2
i1 1 1.1

this is bogus score text!

e


This produces the following messages:

sorting score ...
sread: unexpected char h, sect 1 line 6
sread: illegal opcode h, sect 1 line 6
      remainder of line flushed
twarp: t has extra or disordered beat value
    ... done

As you can see, after identifying that "his" is not a valid p-field value,
sread does not flush the rest of the line, and trys to process it again as a
"new line" starting with the second character.  An additional error is
created in twarp() because the bogus "t" statement was not deleted.

I am going to try to remedy both of these problems along with the line
counting issue in sread.

Finally, I've noticed that sread reports line numbers relative to the
current score section.  Does anybody find this useful?  It would be much
easier to locate a problem with an absolute line number.  And it would allow
for Csound editors with automatic syntax checking to correctly identify the
lines with problems.  (This is the functionality that Joakim is trying to
add to Emacs).

Anthony Kozar
anthonykozar AT sbcglobal DOT net
http://anthonykozar.net/

Anthony Kozar wrote on 11/29/07 1:34 AM:

> I have been looking into adding a command-line flag like "--check-syntax-only"
> at the request of Joakim Verona.  This is fairly trivial but also fairly
> useless for his purposes since Csound frequently reports the wrong line
> numbers for syntax errors.
> 
> I have identified at least six causes for incorrect line numbers:


-------------------------------------------------------------------------
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

Thanks for working on this Anthony, it would be great if it could be 
sorted. I tried adding a syntax checker to Lettuce but gave up when I 
saw how erroneous the line numbering was. In the end I found a work 
around by looking the offensive string in the csd and then highlighting 
the line on which it appears. It works ok for about 60% of errors but 
it's not ideal.

Rory.




Anthony Kozar wrote:
> I have finished adding the new flag --syntax-check-only (committed last
> night) and I am looking at some problems with handling score errors now.
> 
> There seem to be more reasons for incorrect line numbers being reported than
> I realized.  When sread finds an illegal opcode, it flushes the rest of the
> line and I think it forgets to increment the line count.  Also, I
> encountered a situation that seems like poor error handling to me because it
> keeps processing a line after an error was found:
> 
> 
> f1 0 4096 10 1
> 
> i1 0 2
> i1 1 1.1
> 
> this is bogus score text!
> 
> e
> 
> 
> This produces the following messages:
> 
> sorting score ...
> sread: unexpected char h, sect 1 line 6
> sread: illegal opcode h, sect 1 line 6
>       remainder of line flushed
> twarp: t has extra or disordered beat value
>     ... done
> 
> As you can see, after identifying that "his" is not a valid p-field value,
> sread does not flush the rest of the line, and trys to process it again as a
> "new line" starting with the second character.  An additional error is
> created in twarp() because the bogus "t" statement was not deleted.
> 
> I am going to try to remedy both of these problems along with the line
> counting issue in sread.
> 
> Finally, I've noticed that sread reports line numbers relative to the
> current score section.  Does anybody find this useful?  It would be much
> easier to locate a problem with an absolute line number.  And it would allow
> for Csound editors with automatic syntax checking to correctly identify the
> lines with problems.  (This is the functionality that Joakim is trying to
> add to Emacs).
> 
> Anthony Kozar
> anthonykozar AT sbcglobal DOT net
> http://anthonykozar.net/
> 
> Anthony Kozar wrote on 11/29/07 1:34 AM:
> 
>> I have been looking into adding a command-line flag like "--check-syntax-only"
>> at the request of Joakim Verona.  This is fairly trivial but also fairly
>> useless for his purposes since Csound frequently reports the wrong line
>> numbers for syntax errors.
>>
>> I have identified at least six causes for incorrect line numbers:
> 
> 
> -------------------------------------------------------------------------
> 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

Comment lines in the score are not counted either ...

I think incrementing the line count in flushlin() will fix both of these
issues.  I am going to do some more testing though before committing ...

Anthony

Anthony Kozar wrote on 11/30/07 12:42 PM:

> There seem to be more reasons for incorrect line numbers being reported than I
> realized.  When sread finds an illegal opcode, it flushes the rest of the line
> and I think it forgets to increment the line count.


-------------------------------------------------------------------------
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

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

I do not think that this will be too hard to do.  So, I will take it into
consideration.  Thanks.

Anthony

matt ingalls wrote on 11/30/07 6:32 PM:

> my thanks as well!
> 
> i should mention that MacCsound strips out all the .csd tag stuff
> for the user -- so if error code is changed to use original csd
> file it
> will break MacCsound line #s (if you could add a flag to to retain
> the orc/sco lines - but with all the other errors fixed -- that would
> be fabulous!)


-------------------------------------------------------------------------
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

OK. I have made several improvements to the line counts for error reporting
in the score.  There are still some more difficult fixes needed however.
What does everyone think about changing the score line counts to be relative
to the beginning of the file instead of the current score section?

Also, I made several other fixes to sread.c; most notably, I think that the
{} repeat opcodes now work (so they now need to be added to the manual).
Another change is that getpfld() now flushes the rest of a line after
finding an illegal character in a pfield.  Previously, that character was
processed again as if it were the beginning of a new score line.

Regarding reading pfields:  are score statements supposed to be allowed to
continue on to the next line without a backslash?  Currently, getpfld()
ignores newlines when searching for the beginning of the next pfield.  (This
was actually the source of the problem with {}).

Anthony Kozar
anthonykozar AT sbcglobal DOT net
http://anthonykozar.net/

Anthony Kozar wrote on 11/30/07 1:21 PM:

> Comment lines in the score are not counted either ...
> 
> I think incrementing the line count in flushlin() will fix both of these
> issues.  I am going to do some more testing though before committing ...
> 
> Anthony
> 
> Anthony Kozar wrote on 11/30/07 12:42 PM:
> 
>> There seem to be more reasons for incorrect line numbers being reported than
>> I 
>> realized.  When sread finds an illegal opcode, it flushes the rest of the
>> line 
>> and I think it forgets to increment the line count.


-------------------------------------------------------------------------
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