Activity for lrparsing
-
lrparsing released /lrparsing-1.0.17-1/lrparsing_1.0.17-1_amd64.buildinfo
-
-
-
-
-
-
-
-
Russell Stuart committed [00afec]
Release lrparsing-1.0.17-1 - see ChangeLog.txt
-
Added tag lrparsing-1.0.17-1 for changeset 00afece5ee3b
-
Tomasz Lis posted a comment on ticket #4
Just noticed that using pre-compiled grammar fixes the issue. So a bug might be in compile_grammar(), not in the actual parsing.
-
LUA parser example, timing issues?
-
-
-
-
-
-
-
-
-
Release lrparsing-1.0.16-1 - see ChangeLog.txt
-
Added tag lrparsing-1.0.14-1 for changeset e10504d64239
-
Added tag lrparsing-1.0.16-1 for changeset 529a67684216
-
Release lrparsing-1.0.14-1 - see ChangeLog.txt
-
it would compile the grammar every time I call parse. I could check for grammar.parser.parsing_table, Ah, well in 1.0.14 I added a check to compile_grammar to make it lazy too. So you can safetly call it as many times as you like - the grammar will only be compiled once. Appologies for not mentioining that. I'm sure that kind of solution shouldn't be too hard to implement (the most annoying part would be encapsulating all the data created by compilation to a class/dictionary, then you just do a single...
-
Peter Dolak modified a comment on ticket #3
The code snippet you have provided is no good - I want to lazy compile the grammar when I first do parsing. If I included the code before my call to parse, it would compile the grammar every time I call parse. I could check for grammar._parser_.parsing_table, but that includes access to a private property, which is ugly. For people who want to use locks, a method that compiles the grammar only when necessary would be a much better solution. Or unless there is some issue I'm not seeing, that could...
-
The code snippet you have provided is no good - I want to lazy compile the grammar when I first do parsing. If I included the code before my call to parse, it would compile the grammar every time I call parse. I could check for grammar._parser_.parsing_table, but that includes access to a private property, which is ugly. For people who want to use locks, a method that compiles the grammar only when necessary would be a much better solution. Or unless there is some issue I'm not seeing, that could...
-
The code snippet you have provided is no good - I want to lazy compile the grammar when I first do parsing. If I included the code before my call to parse, it would compile the grammar every time I call parse. I could check for grammar._parser_.parsing_table, but that includes access to a private property, which is ugly. For people who want to use locks, a method that compiles the grammar only when necessary would be a much better solution. Or unless there is some issue I'm not seeing, that could...
-
The code snippet you have provided is no good - I want to lazy compile the grammar when I first do parsing. If I included the code before my call to parse, it would compile the grammar every time I call parse. I could check for grammar._parser_.parsing_table, but that includes access to a private property, which is ugly. For people who want to use locks, a method that compiles the grammar only when necessary would be a much better solution. Or unless there is some issue I'm not seeing, that should...
-
The code snippet you have provided is no good - I want to lazy compile the grammar when I first do parsing. If I included the code before my call to parse, it would compile the grammar every time I call parse. I could check for grammar._parser_parsing_table, but that includes access to a private property, which is ugly. For people who want to use locks, a method that compiles the grammar only when necessary would be a much better solution. Or unless there is some issue I'm not seeing, that should...
-
-
-
-
-
-
-
-
-
I'm closing this at fixed in 1.0.14. Unfortunately the fix is a documentation change that merely says "don't do that". Fixing it would impose too much overhead on people who don't use threads, while people who do use threads can work around it, even if you insist on lazily compiling the grammar, with 3 lines of code: grammar_lock = threading.RLock() : : with grammar_lock: grammar.compile_grammar()
-
Thread safety of lazy grammar compilation
-
I'm closing this at fixed in 1.0.14. Unfortunately the fix is a documentation change that merely says "don't do that". Fixing it would impose too much overhead on people who don't use threads, while people who do use threads can work around it, even if you insist on lazily compiling the grammar, with 5 lines of code: grammar_lock = threading.RLock() : : with grammar_lock: grammar.compile_grammar()
-
I don't consider this to be a bug. lrparsing was never intended to be thread safe and this particular issue is easy enough to work around, as you have done in your example. If you wanted the compile_grammar() to be done lazily you could wrap it in a threading.Lock() inside def run(). That said, I will look to see if I can get rid of the exception it in a few lines of code that don't introduce any new dependencies. Note the careful choice of the words get rid of the exception here. A true fix of the...
-
Thread safety of lazy grammar compilation
-
-
-
-
-
-
-
-
Added tag lrparsing-1.0.13-1 for changeset 6518...
-
Release lrparsing-1.0.13-1 - see ChangeLog.txt
-
Unicode Tokens in Python 2.7
-
Done in 1.0.13. Thank you for your suggestion.
-
Ray Lehtiniemi created ticket #2
Unicode Tokens in Python 2.7
-
-
-
-
-
-
-
-
Release lrparsing-1.0.12-1 - see ChangeLog.txt
-
Added tag lrparsing-1.0.12-1 for changeset 6c10...
-
Added tag lrparsing-1.0.11-1 for changeset 954a...
-
Release lrparsing-1.0.11-1 - see ChangeLog.txt
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Release 1.0.9 - see ChangeLog.txt
-
Added tag lrparsing-1.0.9-1 for changeset 38a56...
-
Placidate pep8, move debian/watch to sf redirector
-
Added tag lrparsing-1.0.8-1 for changeset d0cd9...
-
-
-
-
-
Parse failure with simple recursive grammar
-
It was a bug in calculating the LR(1) state closures. Fixed in 1.0.8.
-
-
-
1 >