Recent changes to bugs

Use of Generators is not thread safe

2012-05-31T23:56:32Z

An instance of generator.Generator is not safe to use in multiple threads simultaneously, because its buildParser method mutates its parserList state. This in itself is not a problem, but simpleparsegrammar.Parser.buildTagger and objectgenerator.LibraryElement.toParser re-use the same generators even among separate parser.Parser instances.

I'm no expert in simpleparse, but my testing shows that this can be remedied with two small changes: first, for simpleparsegrammar.Parser.buildTagger, copy the SPGenerator object instead of using it directly:

def buildTagger( self, name=None, processor = None ):
"""Build the tag-table for parsing the EBNF for this parser"""
gen = generator.Generator()
gen.names = SPGenerator.names[:]
gen.rootObjects = SPGenerator.rootObjects[:]
gen.methodSource = SPGenerator.methodSource
gen.definitionSources = SPGenerator.definitionSources[:]

return gen.buildParser( name, processor )

Second, for objectgenerator.LibraryElement.toParser, make a new Parser instance for each LibraryElement() instance created in common/*.py, instead of re-using a common "_p" variable. For example, in numbers.py:

for name in ["int","hex", "int_unsigned", "number", "float", "binary_number", "float_floatexp", "imaginary_number", "number_full"]:
c[ name ] = objectgenerator.LibraryElement(
generator = Parser( declaration )._generator,
production = name,
)

The project is a bit complicated for me to know if this preserves semantics, but it works in my tests.

Fatal Python error: GC object already tracked

2005-11-17T23:54:50Z

Apperently python >=2.3 exposes garbage collection
bugs in C python API code.

Setup:
Activestate Python 2.4.2 for windows
egenix-mx-base-2.1.0-2005-05-01.zip
SimpleParse-2.0.1a3.win32.exe

Im not sure if this is a bug in SimpleParse or MxBase

C:\Python24\Lib\site-
packages\simpleparse\tests>python test.py
None :
Word : '[' : jne=+0 : je=+1
'CHARBRACE' :
Word : ']' : jne=+1 : je=+1
'CHARDASH' : Word : '-
' : jne=+1 : je=+1
None : SubTable :
<table> : jne=+2 : je=+1
None : EOF :
1 : jne=-1 : je=+1
'CHARDASH' : Word : '-
' : jne=+1 : je=+1
None :
Word : ']' : jne=+0 : je=+1

mxVersion: ('2', '1', '0')
..............................Fatal Python error: GC
object already tracked

This application has requested the Runtime to
terminate it in an unusual way.
Please contact the application's support team for
more information.

Optional children of repeating f/o group

2002-06-30T21:20:41Z

Currently the engine cannot distinguish between a
compound item (such as a Table) that fails, but is
satisfied, and one that succeeds. As a result, there's
an endless loop generated when trying to parse a
repeating group (f/o with a single optional or seq with
all optional).

The approaches I can see:

Make the objectgenerator code try to figure out when
the situation would occur and raise an error. (This is
going to be ugly code: determine whether children are
optional (recursively (which is a problem with
self-referencing items)), or more precisely, whether an
item can match a 0-width string)

Make the engine capable of reporting success, failure
and contentment explicitly. Alter tag-table generators
to allow the third state jumps (which completely
changes the mx.TextTools API). Not a great solution
either.