WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
161789
W3C test downloader should be able to import specific files/sub-directories in a skipped directory
https://bugs.webkit.org/show_bug.cgi?id=161789
Summary
W3C test downloader should be able to import specific files/sub-directories i...
youenn fablet
Reported
2016-09-09 02:29:52 PDT
W3C test downloader should be able to import specific files/sub-directories in a skipped directory
Attachments
Patch
(10.33 KB, patch)
2016-09-09 02:40 PDT
,
youenn fablet
no flags
Details
Formatted Diff
Diff
Patch for landing
(10.85 KB, patch)
2016-10-10 02:55 PDT
,
youenn fablet
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
youenn fablet
Comment 1
2016-09-09 02:40:38 PDT
Created
attachment 288396
[details]
Patch
Ryosuke Niwa
Comment 2
2016-10-07 12:38:26 PDT
Comment on
attachment 288396
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=288396&action=review
r=me assuming both problems are addressed.
> Tools/Scripts/webkitpy/w3c/test_downloader.py:137 > + potential_copy_paths = [copy_directory for copy_directory in copy_paths if copy_directory in relative_path]
I don't think "copy_directory in relative_path" is right. We should do relative_path.startswith(copy_directory) instead. If there is / differences, then we should be using filesystem helper functions instead.
> Tools/Scripts/webkitpy/w3c/test_downloader.py:141 > + longest_copy_path_length = len(max(potential_copy_paths, key=len)) > + return not any([skip_directory for skip_directory in self.paths_to_skip if skip_directory in relative_path and len(skip_directory) > longest_copy_path_length])
This is such a convoluted way of checking the condition we need to be checking. Relying on the length to check that skip_directory is more specific than a path in potential_copy_paths is not obvious at all. I think it's better to just have two nested loops instead for clarify unless the performance is actually important.
youenn fablet
Comment 3
2016-10-10 02:55:50 PDT
Created
attachment 291083
[details]
Patch for landing
youenn fablet
Comment 4
2016-10-10 02:57:57 PDT
Thanks for the review. (In reply to
comment #2
)
> Comment on
attachment 288396
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=288396&action=review
> > r=me assuming both problems are addressed. > > > Tools/Scripts/webkitpy/w3c/test_downloader.py:137 > > + potential_copy_paths = [copy_directory for copy_directory in copy_paths if copy_directory in relative_path] > > I don't think "copy_directory in relative_path" is right. We should do > relative_path.startswith(copy_directory) instead. > If there is / differences, then we should be using filesystem helper > functions instead.
Right. Fixed.
> > Tools/Scripts/webkitpy/w3c/test_downloader.py:141 > > + longest_copy_path_length = len(max(potential_copy_paths, key=len)) > > + return not any([skip_directory for skip_directory in self.paths_to_skip if skip_directory in relative_path and len(skip_directory) > longest_copy_path_length]) > > This is such a convoluted way of checking the condition we need to be > checking. > Relying on the length to check that skip_directory is more specific than a > path in potential_copy_paths is not obvious at all. > I think it's better to just have two nested loops instead for clarify unless > the performance is actually important.
I updated the patch by getting the longest matching copy path, the longest matching skip path, and checking whether the copy path starts with the skip path.
WebKit Commit Bot
Comment 5
2016-10-10 03:30:01 PDT
Comment on
attachment 291083
[details]
Patch for landing Clearing flags on attachment: 291083 Committed
r206993
: <
http://trac.webkit.org/changeset/206993
>
WebKit Commit Bot
Comment 6
2016-10-10 03:30:05 PDT
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug