The New Parser #429

Open
danni opened this Issue Feb 12, 2014 · 8 comments

Comments

Projects
None yet
2 participants
@danni
Collaborator

danni commented Feb 12, 2014

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
@adaschevici

This comment has been minimized.

Show comment
Hide comment
@adaschevici

adaschevici Feb 13, 2014

Collaborator

@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?

Collaborator

adaschevici commented Feb 13, 2014

@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 adaschevici referenced this issue in infoxchange/lettuce Feb 13, 2014

Closed

changed xunit reasons to fail so that it passes #7

@danni

This comment has been minimized.

Show comment
Hide comment
@danni

danni Feb 13, 2014

Collaborator

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 notifications@github.com
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
.

Collaborator

danni commented Feb 13, 2014

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 notifications@github.com
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
.

@adaschevici

This comment has been minimized.

Show comment
Hide comment
@adaschevici

adaschevici Feb 14, 2014

Collaborator

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

Collaborator

adaschevici commented Feb 14, 2014

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

@danni

This comment has been minimized.

Show comment
Hide comment
@danni

danni Feb 14, 2014

Collaborator

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.

Collaborator

danni commented Feb 14, 2014

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.

@adaschevici

This comment has been minimized.

Show comment
Hide comment
@adaschevici

adaschevici Feb 14, 2014

Collaborator

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

Collaborator

adaschevici commented Feb 14, 2014

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

@danni

This comment has been minimized.

Show comment
Hide comment
@danni

danni Feb 14, 2014

Collaborator

I'd blank the timings out from the tests.

Collaborator

danni commented Feb 14, 2014

I'd blank the timings out from the tests.

@adaschevici

This comment has been minimized.

Show comment
Hide comment
@adaschevici

adaschevici Feb 17, 2014

Collaborator

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

Collaborator

adaschevici commented Feb 17, 2014

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

@danni

This comment has been minimized.

Show comment
Hide comment
@danni

danni Feb 18, 2014

Collaborator

The pull request is #430

Collaborator

danni commented Feb 18, 2014

The pull request is #430

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment