New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Preparser gets lost with iterated ellipsis_range #17378
Comments
comment:1
I think we're really out of our depth here.
and
The code in question is presently (see sage.misc.preparser line 520)
The problem is in the line marked (*). It really does need to be prepared to make multiple substitutions, but it should leave ".." that are enclosed in some kind of bracket for later substitutions. This is really one of those cases where string-substitutions aren't really powerful enough. It we'd start with a '..' that has a containing block that isn't properly contained in a containing block of any other '..', rather than the first '..' we find, then we'd be ok. (because inside that containing block all the '..' do belong to the same I'm a little worried about cost with that approach: what happens if a whole ".sage" file gets preparsed that has a whole lot of '..' in it? does this routine then execute on that huge string? execution time quadratic (or worse) in the number of '..' might be problematic. EDIT: correction: what we should do is: after we have found our initial
This should be pretty quick because it simply zooms in on the block that's under consideration. Those blocks should be pretty small, even in a big file. This code should probably be edited a bit because there are apparently some occurrences of '...' that need to be treated differently and I'm not doing that here at the moment. |
comment:2
Incidentally, the comma handling is perhaps a little too permissive:
Running preparse_ellipsis has the side effect for turning something that should be a syntax error into valid code. |
Commit: |
comment:4
OK, I did not deal with the extra comma replacements (which seem relatively harmless). i think the "..." detection is simply a matter that those "..." can be replaced by New commits:
|
Author: nbruin |
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
|
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
|
Reviewer: Thierry Monteil |
Changed author from nbruin to Nils Bruin |
comment:8
This makes sense and fixes the problem. Could you just replace |
New commits:
|
comment:11
Conflicts with #17396 |
comment:13
hard rebase to resolve conflict New commits:
|
Changed reviewer from Thierry Monteil to Thierry Monteil, Marc Mezzarobba |
Changed branch from u/nbruin/preparser_gets_lost_with_iterated_ellipsis_range to |
Here is a bug reported during a workshop at Villetaneuse today:
After a quick look, it seems that there is a preparsing problem,
[1..len([1..10])]
should be preparsed as something like:but it is currently preparsed as:
(the second
ellipsis_range
disappeared).Component: user interface
Author: Nils Bruin
Branch/Commit:
7748c7c
Reviewer: Thierry Monteil, Marc Mezzarobba
Issue created by migration from https://trac.sagemath.org/ticket/17378
The text was updated successfully, but these errors were encountered: