lettuce icon indicating copy to clipboard operation
lettuce copied to clipboard

The New Parser

Open danni opened this issue 11 years ago • 8 comments

This is a tracking bug for the new Lettuce parser I've been working on.

https://github.com/infoxchange/lettuce/tree/new-parser

This branch includes:

  • rebuild of the parser using pyparsing
  • rebuild of the lettuce core to clean up execution, makes extensive use of try/except/finally.
  • rebuild of the coloured shell outputter using blessings (much easier to read)

Where is it at:

  • unit tests pass
  • functional tests appear to be failing out outputting errors
  • need to completely rebuild tests for coloured outputter, again if we use blessings, we should be able to write much easier to understand tests
  • should add more unit tests to exercise all parts of the parser
  • need to start testing against some real Lettuce examples

danni avatar Feb 12 '14 12:02 danni

@danni Timer on test_xunit_output.py:test_xunit_output_with_no_steps has increased. It used to be ~0 and now it is ~0.0003 any ideas on speed improvements?

adaschevici avatar Feb 13 '14 14:02 adaschevici

I haven't profiled it yet but there seems to be an initialisation cost now. My guesses are loading the i18n.json or initialising the grammar. Have started running the branch on real projects, will profile.

On Friday, 14 February 2014, Artur Daschevici [email protected] wrote:

@danni https://github.com/danni Timer on test_xunit_output.py:test_xunit_output_with_no_steps has increased. It used to be ~0 and now it is ~0.0003 any ideas on speed improvements?

— Reply to this email directly or view it on GitHubhttps://github.com/gabrielfalcao/lettuce/issues/429#issuecomment-34980621 .

danni avatar Feb 13 '14 20:02 danni

This scenario is the one where there are no steps defined, it kind of makes sense to have a really short fail time.

adaschevici avatar Feb 14 '14 07:02 adaschevici

I agree, but for the moment I'm focused on robustness and stability before I profile the code. This said there's not heaps of difference between 0s and 0.0003s, that doesn't phase me too much. Especially as my focus is on making big files much faster. I do notice though that the unit tests take approximately 20x as long though, so it's possible the setup and teardown time is quite high.

danni avatar Feb 14 '14 08:02 danni

So...resolution would be to change the test slightly (increase fail time)for now and open an issue for it?

adaschevici avatar Feb 14 '14 09:02 adaschevici

I'd blank the timings out from the tests.

danni avatar Feb 14 '14 15:02 danni

I think we should keep the test but increase the time, add a new performance issue.

adaschevici avatar Feb 17 '14 16:02 adaschevici

The pull request is #430

danni avatar Feb 18 '14 12:02 danni