#394 error CS1525: Unexpected symbol `

[Antonio Trande]

Hi all.

"error CS1525: Unexpected symbol `" are errors which appear when i build API for C# (Fedora 21 x86_64) (please, see tarball attached).

csharp-files/ASTBase.cs(1,14): error CS1525: Unexpected symbol `
using'

Thanks.

[Frank Bergmann]

Sorry for the inconvenience

Can you please attach one of the .cs files? According to your build log, swig was run first to create them, and later a make command that would patch them. It would be good if we could see the files that were generated.

Generally, we are moving away from a gnumake build in favor of cmake, which is for us easier to support across multiple platforms.

could you please remove the src/binding/csharp/csharp-files folder, along with src/binding/csharp/libsbml_wrap* and run make again, just to see whether that improves the result? (And send us the log)

thanks
Frank

[Antonio Trande]

Can you please attach one of the .cs files? According to your build log, >swig was run first to create them, and later a make command that would >patch them. It would be good if we could see the files that were >generated.

Attached (XMLOutputStream.cs)

Generally, we are moving away from a gnumake build in favor of cmake, >which is for us easier to support across multiple platforms.

Okay. This means I will change build command entirely.

could you please remove the src/binding/csharp/csharp-files folder, along >with src/binding/csharp/libsbml_wrap* and run make again, just to see >whether that improves the result? (And send us the log)

Nothing is changed.

[Frank Bergmann]

Thanks, the Makefile.in in the src/bindings/csharp/ folder on your system will need to be modified:

Index: Makefile.in
===================================================================
--- Makefile.in (revision 21868)
+++ Makefile.in (working copy)
@@ -483,7 +483,9 @@

 patch-swig-output:
    @list='$(wildcard $(outpath)/*.cs)'; for file in $$list; do \
-     echo 'using System;\nusing System.Runtime.InteropServices;\n\n' >     $(outpath)/.tmpfile; \
+     echo 'using System;' > $(outpath)/.tmpfile; \
+     echo 'using System.Runtime.InteropServices;' >> $(outpath)/.tmpfile; \
+     echo ' ' >> $(outpath)/.tmpfile; \
      cat $$file >> $(outpath)/.tmpfile; \
      mv -f $(outpath)/.tmpfile $$file; \
    done

that should solve the problem. It will be fixed in the next release ... it is odd that the \n was expanded on other systems but not yours. But the new version ought to be more compatible.

Frank

[Antonio Trande]

Fixed.

Thank you.

[Zbigniew Jędrzejewski-Szmek]

So, this fix isn't complete. Python bindings test for the same thing now fails.
The following change makes the tests pass
{{{
diff --git libsbml/src/bindings/python/test/xml/TestXMLError.py libsbml/src/bindings/python/test/xml/TestXMLError.py
index bfc2e5761f..3439b4d1f2 100644
--- libsbml/src/bindings/python/test/xml/TestXMLError.py
+++ libsbml/src/bindings/python/test/xml/TestXMLError.py
@@ -47,7 +47,7 @@ class TestXMLError(unittest.TestCase):
self.assert_( error.getSeverityAsString() == "Error" )
self.assert_( error.getCategory() == libsbml.LIBSBML_CAT_XML )
self.assert_( error.getCategoryAsString() == "XML content" )
- self.assert_( error.getMessage() == "Duplicate XML attribute." )
+ self.assert_( error.getMessage() == "Duplicate XML attribute.\n" )
self.assert_( error.getShortMessage() == "Duplicate attribute" )
error = None
error = libsbml.XMLError(12345, "My message")
}}}
but I think it is backwards. The message should not include a newline, if this is necessary, the user of this function should do the formatting as necessary.

PERL bindings tests fail too, but since I don't know too much about PERL, I didn't investigate :)

[Lucian Smith]

The messages used to sometimes contain a newline and sometimes not contain a newline (and sometimes contain two newlines!), depending on the error. This has now been regularized so that all the messages now end with a single newline, since this was the case for the majority of messages. Thanks for noticing that the python tests needed to be changed!

[Zbigniew Jędrzejewski-Szmek]

Of course consistency and passing tests are paramount.

But Python exception messages almost never contain a newline (*). The reason is that if you want to embed the message in a larger message, you cannot do it as nicely. If you print the exception in a log line, you have to strip it too, etc.

(*) The only exception is exceptions which are not designed to be caught, but instead to show prominently on the console, e.g. if there's a missing import. But this is not the case here.

[Sarah Keating]

Hi

Thanks for the report.

This is now fixed in svn.

[Sarah Keating]

Hi

With respect to newlines in the error messages:

We do not consider these to be 'exceptions' in the usual sense. Errors logged into the SBMLErrorLog may be only warnings. We provide two messages associated with each Error. The ShortMessage does not have newlines and is, as the name suggests, a very brief description of the issue. The longer Message includes text from the relevant SBML specification, a Reference to that specification and possible a further sentence giving more detailed information about the problem. This does include newlines in order to make the output readable.

Do you see a particular issue with newlines ?

Thanks

Sarah

[Zbigniew Jędrzejewski-Szmek]

I didn't see that there's a getShortMessage() too. If getMessage() is supposed to give a longer explanation, then yes, this seems fine.

[Michael Hucka]

When you say "I don't see that there's a getShortMessage()", do you mean that you cannot access the method on the API for some reason?

Here's more info about getShortMessage(): http://goo.gl/YAepnM

[Zbigniew Jędrzejewski-Szmek]

I meant "didn't see" instead of "don't see". Sorry.