Forum: GNU Radio grc should warn, not fail with malformed xml

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
C0ba64b9e5a62ed77295b79b63ab87c0?d=identicon&s=25 Dimitris Symeonidis (Guest)
on 2009-04-03 11:45
(Received via mailing list)
I am creating xml files for my RDS block, in order to be able to use
it together with GRC.
I had forgotten to close a tag in an xml file that I had put into
/usr/local/share/gnuradio/grc/platforms/python/blocks/
The result was that I couldn't run GRC anymore, it would exit with
these messages on the console:

Traceback (most recent call last):
  File "/usr/local/bin/grc", line 45, in <module>
    ActionHandler(args, Platform())
  File
"/usr/local/lib/python2.6/dist-packages/gnuradio/grc/platforms/python/Platform.py",
line 61, in __init__
    generator=Generator,
  File
"/usr/local/lib/python2.6/dist-packages/gnuradio/grc/platforms/base/Platform.py",
line 63, in __init__
    self._load_blocks(os.path.join(dirpath, filename))
  File
"/usr/local/lib/python2.6/dist-packages/gnuradio/grc/platforms/base/Platform.py",
line 74, in _load_blocks
    try: ParseXML.validate_dtd(f, self._block_dtd)
  File
"/usr/local/lib/python2.6/dist-packages/gnuradio/grc/utils/ParseXML.py",
line 38, in validate_dtd
    xml = etree.parse(xml_file, parser=parser)
  File "lxml.etree.pyx", line 2583, in lxml.etree.parse
(src/lxml/lxml.etree.c:25057)
  File "parser.pxi", line 1465, in lxml.etree._parseDocument
(src/lxml/lxml.etree.c:63523)
  File "parser.pxi", line 1494, in lxml.etree._parseDocumentFromURL
(src/lxml/lxml.etree.c:63767)
  File "parser.pxi", line 1394, in lxml.etree._parseDocFromFile
(src/lxml/lxml.etree.c:62923)
  File "parser.pxi", line 968, in
lxml.etree._BaseParser._parseDocFromFile (src/lxml/lxml.etree.c:60309)
  File "parser.pxi", line 542, in
lxml.etree._ParserContext._handleParseResultDoc
(src/lxml/lxml.etree.c:56659)
  File "parser.pxi", line 628, in lxml.etree._handleParseResult
(src/lxml/lxml.etree.c:57504)
  File "parser.pxi", line 568, in lxml.etree._raiseParseError
(src/lxml/lxml.etree.c:56902)
lxml.etree.XMLSyntaxError: Opening and ending tag mismatch: doc line
23 and block, line 29, column 9


Josh, shouldn't GRC ignore malformed xml files (or maybe warn),
instead of failing to run?
Sorry, I am not yet familiar enough to submit a patch for this...

Dimitris Symeonidis
"If you think you're too small to make a difference, try sleeping with
a mosquito!" - Amnesty International
4252201ac30d6dd44d8090ce1070e35f?d=identicon&s=25 Josh Blum (Guest)
on 2009-04-03 17:33
(Received via mailing list)
> lxml.etree.XMLSyntaxError: Opening and ending tag mismatch: doc line
> 23 and block, line 29, column 9
>
>
> Josh, shouldn't GRC ignore malformed xml files (or maybe warn),
> instead of failing to run?
> Sorry, I am not yet familiar enough to submit a patch for this...
>

It was intentional. If the block definition is bad, it prints out the
problem and exits. The other possibility is to print the error, not
parse that block which contained the error, and continue loading.

My worry was that if somebody (including myself) makes a bad block, the
error would be missed or overlooked when the program opens, so rather,
it just exits with error.

Any strong opinions on this (error vs warn)? Either way is ok with me, I
just want it to be most useful for the majority of users.

-Josh
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2009-04-03 17:48
(Received via mailing list)
On Fri, Apr 03, 2009 at 08:32:50AM -0700, Josh Blum wrote:
>
> Any strong opinions on this (error vs warn)? Either way is ok with me, I
> just want it to be most useful for the majority of users.

Error seems fine to me.

Eric
28a4af15b4d496d7900593255ea9c8a3?d=identicon&s=25 Ed Criscuolo (Guest)
on 2009-04-05 16:05
(Received via mailing list)
Josh Blum wrote:
> It was intentional. If the block definition is bad, it prints out the
> problem and exits. The other possibility is to print the error, not
> parse that block which contained the error, and continue loading.
>
> My worry was that if somebody (including myself) makes a bad block, the
> error would be missed or overlooked when the program opens, so rather,
> it just exits with error.
>
> Any strong opinions on this (error vs warn)? Either way is ok with me, I
> just want it to be most useful for the majority of users.


Why not have it both ways? :)  I suggest a preferences option to specify
the behavior.  That way you make it most useful to ALL the users!

@(^.^)@  Ed
This topic is locked and can not be replied to.