[chromium-dev] Re: Skia is moving
Ok, the Skia move is done. I've had some reports that you need to clean/rebuild skia.lib, but that a full clobber is not necessary. Thanks to maruel, thomasvl, and nsylvain for helping out with mop-up. Let me know if you have any further problems. Stephen On Tue, May 12, 2009 at 5:22 PM, Stephen White senorbla...@chromium.orgwrote: I'm in the process of updating chromium to use tip-of-tree skia, and in the same CL, moving skia to a third_party directory, retrieved via DEPS. What this means for you: 1) Any outstanding CL's in which you've added #include skia/include/... will have to be changed to the corresponding path in third_party/skia/include/... (be warned that the subdirectory layout is also slightly different). 2) Going forward, any changes to skia will have to be done via commits to skia.googlecode.com, and then rolling DEPS in chromium (much the same as we now do for WebKit). 3) The new version of skia appears to render rects whose coordinates are backwards (ie., x2 x1 or y2 y1), which were formerly culled. There were a couple obvious instances of this in the code which I fixed, but there may be more. After this change, the local skia directory will contain only .gyp files, ext/ (chromium-specific skia utilities), and config/ (new directory, containing SkUserConfig.h). Everything else will live in third_party/skia. There were ~35 layout test failures due to minor pixel differences which I rebaselined on Windows and Linux, and 8 genuine failures related to masks and stroked text, which I have put in text_expectations.txt and assigned to myself. (There was another change which broke ~1700 tests on each platform, but I put that change behind an #ifdef for now). Unless I hear otherwise, I'm planning to do this Wednesday morning, 10AM EST (7AM PST). Stephen -- All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. -- Schopenhauer -- All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. -- Schopenhauer --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chrome's Accelerators (alternative to IE8 Accelerators) is here
Hi Nick, Thanks for your feedback. My understanding is that Chrome is actively working on an official user preference system based on HTML 5 local storage. In the meantime, I was suggested trying bookmarks as a workaround. I haven't tried the new release yet, but in last week it didn't work out because it seemed the communication between the content script and extension (namely chromium.extension.connect() blabla) was not ready yet. As for cookie, unless I missed sth, I think it is not a decent solution because of its strict security/domain restriction (to keep in mind user preference should work browser-wide instead of domain-wide). Any comments are welcome. -Jack On May 13, 8:16 am, Nick Baum nickb...@chromium.org wrote: Hey Jack, This is super cool, thanks for sharing! Matt (cc'd) is working on letting extensions store cookies. Is that what you're missing? Cheers, -Nick 2009/5/12 jack js2...@gmail.com Thanks for your feedback and glad to know it worked for you. Your guess is correct. Although such features are OK in Cleeki's IE/Firefox addons, I haven't figure out a way for Chrome yet. I tried the trick using bookmarking and script/extension communication but it didn't work so far. If anybody here knows how to do this, I'd love to know and integrate it into the add-on. -Jack On 5月12日, 下午10时11分, PhistucK phist...@gmail.com wrote: Works for me. The IE8 Accelerator importing and the preferences work only in the corresponding pages, because the lack of Extensions cookie support, I assume, right? Great job! ☆PhistucK On Tue, May 12, 2009 at 20:47, jack js2...@gmail.com wrote: I recently migrated the Firefox add-on, called Cleeki, into Google Chrome. Cleeki can be used as Google Chrome's Accelerators, only superior to IE8 accelerators. Basically you select any text to search/ share/publish on the Internet, and preview the results in the same page instantly. Installation guideline:http://blog.cleeki.com/?p=70 A quick overview:http://blog.cleeki.com/?p=112 Based on the discussion last week, there is a known issue in current Chrome that the first page might not load the add-on script. Also there is no (easy) user customization yet because of the lack of an official user preference system. I would like to share the add-on in this community in case it is helpful for testing any new release of Chrome. I will actively test it in the up-to-date Chrome and report any bugs. Any of your bug reporting is also welcome. I hope when Chrome add-on system becomes official, this add-on will also be ready (or almost). Thanks for your attention and any of your comments are welcome. -Jack --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chrome's Accelerators (alternative to IE8 Accelerators) is here
Hi Jack, We're indeed working on HTML5 local storage, which should meet your needs. Great to see your progress on this! -Nick 2009/5/13 jack js2...@gmail.com Hi Nick, Thanks for your feedback. My understanding is that Chrome is actively working on an official user preference system based on HTML 5 local storage. In the meantime, I was suggested trying bookmarks as a workaround. I haven't tried the new release yet, but in last week it didn't work out because it seemed the communication between the content script and extension (namely chromium.extension.connect() blabla) was not ready yet. As for cookie, unless I missed sth, I think it is not a decent solution because of its strict security/domain restriction (to keep in mind user preference should work browser-wide instead of domain-wide). Any comments are welcome. -Jack On May 13, 8:16 am, Nick Baum nickb...@chromium.org wrote: Hey Jack, This is super cool, thanks for sharing! Matt (cc'd) is working on letting extensions store cookies. Is that what you're missing? Cheers, -Nick 2009/5/12 jack js2...@gmail.com Thanks for your feedback and glad to know it worked for you. Your guess is correct. Although such features are OK in Cleeki's IE/Firefox addons, I haven't figure out a way for Chrome yet. I tried the trick using bookmarking and script/extension communication but it didn't work so far. If anybody here knows how to do this, I'd love to know and integrate it into the add-on. -Jack On 5月12日, 下午10时11分, PhistucK phist...@gmail.com wrote: Works for me. The IE8 Accelerator importing and the preferences work only in the corresponding pages, because the lack of Extensions cookie support, I assume, right? Great job! ☆PhistucK On Tue, May 12, 2009 at 20:47, jack js2...@gmail.com wrote: I recently migrated the Firefox add-on, called Cleeki, into Google Chrome. Cleeki can be used as Google Chrome's Accelerators, only superior to IE8 accelerators. Basically you select any text to search/ share/publish on the Internet, and preview the results in the same page instantly. Installation guideline:http://blog.cleeki.com/?p=70 A quick overview:http://blog.cleeki.com/?p=112 Based on the discussion last week, there is a known issue in current Chrome that the first page might not load the add-on script. Also there is no (easy) user customization yet because of the lack of an official user preference system. I would like to share the add-on in this community in case it is helpful for testing any new release of Chrome. I will actively test it in the up-to-date Chrome and report any bugs. Any of your bug reporting is also welcome. I hope when Chrome add-on system becomes official, this add-on will also be ready (or almost). Thanks for your attention and any of your comments are welcome. -Jack --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chrome's Accelerators (alternative to IE8 Accelerators) is here
2009/5/13 jack js2...@gmail.com: Thanks for your feedback. My understanding is that Chrome is actively working on an official user preference system based on HTML 5 local storage. In the meantime, I was suggested trying bookmarks as a workaround. I haven't tried the new release yet, but in last week it didn't work out because it seemed the communication between the content script and extension (namely chromium.extension.connect() blabla) was not ready yet. As for cookie, unless I missed sth, I think it is not a decent solution because of its strict security/domain restriction (to keep in mind user preference should work browser-wide instead of domain-wide). The content script communication stuff works in the current release. The name has changed to 'chrome.extension.connect()' (not chromium). - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Changes to FilePath?
(ping) So, I had another idea. How about a separate file path manipulation class that has a well defined character encoding, so that we can do filename manipulations like with FilePath (and a few more). It could convert from a FilePath if given an encoding, and convert back to a FilePath with the platform's default encoding (using LC_*/LANG on Linux, falling back to ASCII), or a given encoding. It could touch the filesystem so that it could know what ecoding methods and manipulations were valid for the platform/drive combination. Since it seems like this is not really something that Chromium needs or wants right now (and it doesn't belong in base anyhow because of needing to touch the filesystem), I think I'll work on this for O3D, and later you can see if you want to use it for Chromium. -Greg. On Wed, Apr 29, 2009 at 3:58 PM, Greg Spencer gspen...@google.com wrote: On Wed, Apr 29, 2009 at 12:22 PM, Mark Mentovai m...@chromium.org wrote: I understand your problem. You're saying I have user-supplied data that I want to build a filename from, and I have this pathname that I want to display back to the user. I agree that it would be good to have a way to handle these cases in base. I don't know if FilePath proper is the right place to do it. If we do it in FilePath, it still won't really be right. OK, so it sounds like you're telling me not to use FilePath to represent file paths from a disk for my purposes because they can't ever be converted reliably to a particular encoding on Linux (which is a requirement for me, because of the third party libraries that require a particular encoding). That's fine, but what do I do instead? Roll my own FilePath clone that has some encoding assumptions? I can do that, but it has the same issues as the ones you're worried about with FilePath, so it seems better to solve the issue in one place rather than have two versions that are both insufficient. Man, it would be better if FilePath could reliably know its encoding! (I realize that Linux makes this impossible, it just seems like it would be better that way. :-) Since Linux is the only platform where the encoding is unclear, what if we did the best we could on Linux: When constructing a FilePath from a char* string on Linux: - Test the input string for values 127 to determine if it's really just ASCII (and if so, we're out of the woods). - Then check LANG, LC_CTYPE, LC_ALL (through appropriate Linux APIs) for an encoding that we can support, and note the encoding for later if we are requested to do a conversion. - If we run into an invalid sequence during a conversion, or an encoding we can't convert from, then use a CHECK to crash. This should work on most filenames, in almost all situations -- I'll bet most filenames are ASCII, even on foreign systems, and the ones that aren't ASCII have set LANG to something in /etc/profile, so all filenames created by any app running on that machine should match that encoding. Where they don't do that correctly, they're already getting garbage (and should expect garbage) from any application they use, not just Chrome, since there is no way *any *app can decode a path with multiple encodings in it, or where the encoding is different than LANG (or LC_*) says it is. Chrome already crashes like this when it encounters situations where it's just impossible to know what's right, so it's consistent with Chrome's behavior in other areas. it should be the caller's responsibility to only deal with user-created names with this interface. What do you mean here? Isn't that the case now with FilePath? (It's the file_util routines that actually read the filesystem and make FilePaths out of them, afterall). As for your suggestion to only deal with path components, how would you propose to parse user-supplied paths into one of these? 2) I'd like to make it possible to instantiate a POSIX FilePath object on Windows and a Windows FilePath on POSIX platforms. This is because some libraries (e.g. the zip library, or tar files), use POSIX semantics for their paths even on Windows (I haven't seen a use case for Windows paths on POSIX yet, actually). This would make it possible to use the nice API that FilePath has to manipulate paths appropriately for these other libraries. This could be easily accomplished by having POSIX and Windows versions of FilePath, and then typedef'ing FilePath differently on different platforms to one of these versions. Sounds pretty Pythonic. FilePath already sort of has some support for this - it does a bunch of things based on feature macros, mostly so that as I was writing it, I could test the Windows semantics without having to (shudder) resort to running on Windows. These could probably be adapted to do what you're asking. Cool. 3) It would be helpful to have real path normalization for each of the platforms (although I know what a testing nightmare
[chromium-dev] Re: Chrome's Accelerators (alternative to IE8 Accelerators) is here
Cookies will not help user scripts, but they will help you with toolstrips and background pages. Both of the latter pages run in an extension process under a common origin, so you can access your extension's cookies from those contexts just fine. You'd need to use the content script communication if you need to inform content scripts about stored settings, though. (Note that cookie support is not in yet.) 2009/5/13 jack js2...@gmail.com Hi Nick, Thanks for your feedback. My understanding is that Chrome is actively working on an official user preference system based on HTML 5 local storage. In the meantime, I was suggested trying bookmarks as a workaround. I haven't tried the new release yet, but in last week it didn't work out because it seemed the communication between the content script and extension (namely chromium.extension.connect() blabla) was not ready yet. As for cookie, unless I missed sth, I think it is not a decent solution because of its strict security/domain restriction (to keep in mind user preference should work browser-wide instead of domain-wide). Any comments are welcome. -Jack On May 13, 8:16 am, Nick Baum nickb...@chromium.org wrote: Hey Jack, This is super cool, thanks for sharing! Matt (cc'd) is working on letting extensions store cookies. Is that what you're missing? Cheers, -Nick 2009/5/12 jack js2...@gmail.com Thanks for your feedback and glad to know it worked for you. Your guess is correct. Although such features are OK in Cleeki's IE/Firefox addons, I haven't figure out a way for Chrome yet. I tried the trick using bookmarking and script/extension communication but it didn't work so far. If anybody here knows how to do this, I'd love to know and integrate it into the add-on. -Jack On 5月12日, 下午10时11分, PhistucK phist...@gmail.com wrote: Works for me. The IE8 Accelerator importing and the preferences work only in the corresponding pages, because the lack of Extensions cookie support, I assume, right? Great job! ☆PhistucK On Tue, May 12, 2009 at 20:47, jack js2...@gmail.com wrote: I recently migrated the Firefox add-on, called Cleeki, into Google Chrome. Cleeki can be used as Google Chrome's Accelerators, only superior to IE8 accelerators. Basically you select any text to search/ share/publish on the Internet, and preview the results in the same page instantly. Installation guideline:http://blog.cleeki.com/?p=70 A quick overview:http://blog.cleeki.com/?p=112 Based on the discussion last week, there is a known issue in current Chrome that the first page might not load the add-on script. Also there is no (easy) user customization yet because of the lack of an official user preference system. I would like to share the add-on in this community in case it is helpful for testing any new release of Chrome. I will actively test it in the up-to-date Chrome and report any bugs. Any of your bug reporting is also welcome. I hope when Chrome add-on system becomes official, this add-on will also be ready (or almost). Thanks for your attention and any of your comments are welcome. -Jack --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Skia is moving
I think that's a good point, and it would make for a much easier to understand and enforce policy. It means some potential pain if we ever wish to fork a top-level directory off into a separate opensource project. -Darin On Wed, May 13, 2009 at 10:56 AM, Ben Goodger (Google) b...@chromium.orgwrote: I do think this distinction is fairly arbitrary in the world of open source projects. It is not hard to imagine a time when some of these dependencies may have more non-Google contributors than Googlers. It is also possible that licensing may change over time. In addition, it makes it harder to distinguish what top level dirs we have that aren't provided by deps. My personal preference is that everything that isn't hosted in our repo goes into third_party regardless of whether its license agrees with ours at this moment. -Ben On Tue, May 12, 2009 at 3:55 PM, Darin Fisher da...@chromium.org wrote: On Tue, May 12, 2009 at 3:06 PM, Brett Wilson bre...@chromium.org wrote: On Tue, May 12, 2009 at 2:48 PM, Nicolas Sylvain nsylv...@chromium.org wrote: On Tue, May 12, 2009 at 2:22 PM, Stephen White senorbla...@chromium.org wrote: I'm in the process of updating chromium to use tip-of-tree skia, and in the same CL, moving skia to a third_party directory, retrieved via DEPS. What this means for you: Hi, Why do you want to move it to third party? The other projects developed at google that we fetch through DEPS like googleurl, breakpad, gtests and courgette are all living in src, not third_party.. Nicolas If our repo is not the canonical representation, they should all be in thierd party. So I think that all your examples are in the wrong place. Brett src/courgette is the canonical representation. we placed googleurl, breakpad, and v8 in src and not third_party because they are developed by our team, so we do not have licensing / copyright concerns. the rule we have been following is to put items in third_party that do not conform to our licensing or that are developed by another group. i think by this measure it is correct for googleurl, breakpad, and v8 to live in src. same goes for gtest. skia seems like a borderline case to me. the point of third_party is to make ease the job of a licensing lawyer who has to figure out what they need to worry about. -darin --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Skia is moving
Really? I don't think we include anything in third_party using third_party in the include path - or is this not what you mean by pain? -Ben On Wed, May 13, 2009 at 12:32 PM, Darin Fisher da...@chromium.org wrote: I think that's a good point, and it would make for a much easier to understand and enforce policy. It means some potential pain if we ever wish to fork a top-level directory off into a separate opensource project. -Darin On Wed, May 13, 2009 at 10:56 AM, Ben Goodger (Google) b...@chromium.org wrote: I do think this distinction is fairly arbitrary in the world of open source projects. It is not hard to imagine a time when some of these dependencies may have more non-Google contributors than Googlers. It is also possible that licensing may change over time. In addition, it makes it harder to distinguish what top level dirs we have that aren't provided by deps. My personal preference is that everything that isn't hosted in our repo goes into third_party regardless of whether its license agrees with ours at this moment. -Ben On Tue, May 12, 2009 at 3:55 PM, Darin Fisher da...@chromium.org wrote: On Tue, May 12, 2009 at 3:06 PM, Brett Wilson bre...@chromium.org wrote: On Tue, May 12, 2009 at 2:48 PM, Nicolas Sylvain nsylv...@chromium.org wrote: On Tue, May 12, 2009 at 2:22 PM, Stephen White senorbla...@chromium.org wrote: I'm in the process of updating chromium to use tip-of-tree skia, and in the same CL, moving skia to a third_party directory, retrieved via DEPS. What this means for you: Hi, Why do you want to move it to third party? The other projects developed at google that we fetch through DEPS like googleurl, breakpad, gtests and courgette are all living in src, not third_party.. Nicolas If our repo is not the canonical representation, they should all be in thierd party. So I think that all your examples are in the wrong place. Brett src/courgette is the canonical representation. we placed googleurl, breakpad, and v8 in src and not third_party because they are developed by our team, so we do not have licensing / copyright concerns. the rule we have been following is to put items in third_party that do not conform to our licensing or that are developed by another group. i think by this measure it is correct for googleurl, breakpad, and v8 to live in src. same goes for gtest. skia seems like a borderline case to me. the point of third_party is to make ease the job of a licensing lawyer who has to figure out what they need to worry about. -darin --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Skia is moving
Yes... that's what I'd imagine us doing... just because we suck in projects A, B, C doesn't mean they need to conform to our include starts at the root convention - as far as they're concerned the root is src/ in their repo. -Ben On Wed, May 13, 2009 at 12:39 PM, Darin Fisher da...@chromium.org wrote: That is what I meant by pain It only applies to third party code that conforms to the google style guide, which says that all include paths must be relative to the root. Come to think of it, I think this could cause problems for such projects, since I'm sure the V8 developers don't think of V8 as a third party piece of code, and in their world, V8 is not checked out into a directory named third_party. We'd probably end up having to add src/third_party to the include path or something like that. -Darin On Wed, May 13, 2009 at 12:35 PM, Ben Goodger (Google) b...@chromium.org wrote: Really? I don't think we include anything in third_party using third_party in the include path - or is this not what you mean by pain? -Ben On Wed, May 13, 2009 at 12:32 PM, Darin Fisher da...@chromium.org wrote: I think that's a good point, and it would make for a much easier to understand and enforce policy. It means some potential pain if we ever wish to fork a top-level directory off into a separate opensource project. -Darin On Wed, May 13, 2009 at 10:56 AM, Ben Goodger (Google) b...@chromium.org wrote: I do think this distinction is fairly arbitrary in the world of open source projects. It is not hard to imagine a time when some of these dependencies may have more non-Google contributors than Googlers. It is also possible that licensing may change over time. In addition, it makes it harder to distinguish what top level dirs we have that aren't provided by deps. My personal preference is that everything that isn't hosted in our repo goes into third_party regardless of whether its license agrees with ours at this moment. -Ben On Tue, May 12, 2009 at 3:55 PM, Darin Fisher da...@chromium.org wrote: On Tue, May 12, 2009 at 3:06 PM, Brett Wilson bre...@chromium.org wrote: On Tue, May 12, 2009 at 2:48 PM, Nicolas Sylvain nsylv...@chromium.org wrote: On Tue, May 12, 2009 at 2:22 PM, Stephen White senorbla...@chromium.org wrote: I'm in the process of updating chromium to use tip-of-tree skia, and in the same CL, moving skia to a third_party directory, retrieved via DEPS. What this means for you: Hi, Why do you want to move it to third party? The other projects developed at google that we fetch through DEPS like googleurl, breakpad, gtests and courgette are all living in src, not third_party.. Nicolas If our repo is not the canonical representation, they should all be in thierd party. So I think that all your examples are in the wrong place. Brett src/courgette is the canonical representation. we placed googleurl, breakpad, and v8 in src and not third_party because they are developed by our team, so we do not have licensing / copyright concerns. the rule we have been following is to put items in third_party that do not conform to our licensing or that are developed by another group. i think by this measure it is correct for googleurl, breakpad, and v8 to live in src. same goes for gtest. skia seems like a borderline case to me. the point of third_party is to make ease the job of a licensing lawyer who has to figure out what they need to worry about. -darin --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Skia is moving
On Wed, May 13, 2009 at 12:39 PM, Darin Fisher da...@chromium.org wrote: That is what I meant by pain It only applies to third party code that conforms to the google style guide, which says that all include paths must be relative to the root. Come to think of it, I think this could cause problems for such projects, since I'm sure the V8 developers don't think of V8 as a third party piece of code, and in their world, V8 is not checked out into a directory named third_party. We'd probably end up having to add src/third_party to the include path or something like that. We already do this for all third_party code, but from chrome we include it with the third_party prefix. I think this is a good approach. In serverland, they actually change the includes in the third party files which I don't think we should do. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Changes to FilePath?
If you've got a file that begins its life as something on-disk, and
you just need to carry the path to it around, then that's fine, it
should live its life as a FilePath.
If you've got to create a file using some name where the name is some
constant in code, use FilePath with ASCII constants. AppendASCII
exists to stick new ASCII components onto existing FilePaths. This is
fine and is considered safe because ASCII is a subset of any rational
filesystem encoding.
If you've got to take an arbitrary FilePath and convert it for display
to the user, or take an arbitrary string in a known encoding and
re-encode it for the filesystem, then we don't have anything in
FilePath for this. I believe that if we do add something, it should
strictly operate only on single pathname components at a time, and not
entire pathnames. We could add it to FilePath or we could add it
somewhere else, because it is sort of distinct from what FilePath is
really supposed to be, which is just a container for ferrying around
native paths.
It's also a specification and implementation nightmare. Everyone has
a different idea of what normalization means. What's your idea?
Yes, I know it's a nightmare all around, but I think it would be useful to
have something that addresses this. My idea would be the same as Python's
os.path.normpath, mainly because it's a well-tested, seasoned example with
test cases. Windows also has a routine for this (PathCanonicalize) that
could be used (but I know it doesn't work for UNC paths).
Why would it be useful? Do you want to compare paths for equality?
Then we should have an API that compares paths for equality. It would
have to hit the disk to do so. You might need general-purpose
canonization to implement that on some systems. Great, you need to
hit the disk to do that too. It's fine if you want these things, but
we can't put them into FilePath. It's important that FilePath remain
lightweight and not make any system calls, because system calls can
block and FilePath is just a data carrier.
os.path.normpath is known to be buggy. It might be well-tested and
seasoned, but only within the confines of its known limitations.
Watch this.
m...@anodizer bash$ ls -l a/b/../c
-rw-r--r-- 1 mark staff 0 May 13 15:47 a/b/../c
m...@anodizer bash$ python
Python 2.5.1 (r251:54863, Feb 6 2009, 19:02:12)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type help, copyright, credits or license for more information.
import os.path
os.path.normpath('a/b/../c')
'a/c'
^D
m...@anodizer bash$ ls -l a/c
ls: a/c: No such file or directory
Probably the same as os.path.normcase in Python. I want this stuff so that
I can make sure that I can at least semi-reliably compare/manipulate
FilePaths to do things like absolute-relative path conversion, or store
FilePaths in a set or map and be sure I don't have multiple entries pointing
to the same file. Without these kinds of operations, doing these things is
pretty much impossible.
I don't think os.path.normcase does what you're asking for either.
m...@anodizer bash$ ls -lid /System/Library
81 drwxr-xr-x 64 root wheel 2176 May 12 18:37 /System/Library
m...@anodizer bash$ ls -lid /system/LIBRARY
81 drwxr-xr-x 64 root wheel 2176 May 12 18:37 /system/LIBRARY
m...@anodizer bash$ python
Python 2.5.1 (r251:54863, Feb 6 2009, 19:02:12)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type help, copyright, credits or license for more information.
import sys
sys.platform
'darwin'
import os.path
os.path.normcase('/System/Library')
'/System/Library'
os.path.normcase('/system/LIBRARY')
'/system/LIBRARY'
^D
Even os.path.realpath returns the same results.
Again, it sounds like what you really want is a pathname comparator
that hits the disk. You really can't do this stuff correctly on most
systems without talking to the filesystem. You can't even do
general-purpose canonization without talking to the filesystem.
Let me make clear: I'm not trying to shoot down the idea of needing to
be able to compare paths or even necessarily canonize them. I'm
arguing primarily against doing it in FilePath, but I'm also also
trying to illustrate that doing proper comparisons and canonization is
harder than it seems, that even seasoned and well-tested APIs are
limited in ways that developers don't necessarily expect, and that the
semantics and expectations need to be well-defined.
Mark
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Chrome's Accelerators (alternative to IE8 Accelerators) is here
Thanks for your tips, Matt. I will check the update and try your suggestion. -jack On May 13, 12:07 pm, Matt Perry mpcompl...@chromium.org wrote: Cookies will not help user scripts, but they will help you with toolstrips and background pages. Both of the latter pages run in an extension process under a common origin, so you can access your extension's cookies from those contexts just fine. You'd need to use the content script communication if you need to inform content scripts about stored settings, though. (Note that cookie support is not in yet.) 2009/5/13 jack js2...@gmail.com Hi Nick, Thanks for your feedback. My understanding is that Chrome is actively working on an official user preference system based on HTML 5 local storage. In the meantime, I was suggested trying bookmarks as a workaround. I haven't tried the new release yet, but in last week it didn't work out because it seemed the communication between the content script and extension (namely chromium.extension.connect() blabla) was not ready yet. As for cookie, unless I missed sth, I think it is not a decent solution because of its strict security/domain restriction (to keep in mind user preference should work browser-wide instead of domain-wide). Any comments are welcome. -Jack On May 13, 8:16 am, Nick Baum nickb...@chromium.org wrote: Hey Jack, This is super cool, thanks for sharing! Matt (cc'd) is working on letting extensions store cookies. Is that what you're missing? Cheers, -Nick 2009/5/12 jack js2...@gmail.com Thanks for your feedback and glad to know it worked for you. Your guess is correct. Although such features are OK in Cleeki's IE/Firefox addons, I haven't figure out a way for Chrome yet. I tried the trick using bookmarking and script/extension communication but it didn't work so far. If anybody here knows how to do this, I'd love to know and integrate it into the add-on. -Jack On 5月12日, 下午10时11分, PhistucK phist...@gmail.com wrote: Works for me. The IE8 Accelerator importing and the preferences work only in the corresponding pages, because the lack of Extensions cookie support, I assume, right? Great job! ☆PhistucK On Tue, May 12, 2009 at 20:47, jack js2...@gmail.com wrote: I recently migrated the Firefox add-on, called Cleeki, into Google Chrome. Cleeki can be used as Google Chrome's Accelerators, only superior to IE8 accelerators. Basically you select any text to search/ share/publish on the Internet, and preview the results in the same page instantly. Installation guideline:http://blog.cleeki.com/?p=70 A quick overview:http://blog.cleeki.com/?p=112 Based on the discussion last week, there is a known issue in current Chrome that the first page might not load the add-on script. Also there is no (easy) user customization yet because of the lack of an official user preference system. I would like to share the add-on in this community in case it is helpful for testing any new release of Chrome. I will actively test it in the up-to-date Chrome and report any bugs. Any of your bug reporting is also welcome. I hope when Chrome add-on system becomes official, this add-on will also be ready (or almost). Thanks for your attention and any of your comments are welcome. -Jack --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Changes to FilePath?
On Tue, Apr 28, 2009 at 2:47 PM, Greg Spencer gspen...@google.com wrote: On Tue, Apr 28, 2009 at 2:41 PM, Amanda Walker ama...@chromium.orgwrote: On Tue, Apr 28, 2009 at 4:39 PM, Greg Spencer gspen...@google.com wrote: 1) I'd like to add some explicit routines for converting to/from UTF8 and UTF16. While it's nice (and important) that FilePath uses the platform's native string, we've found that many third party libraries have made other assumptions, where they always expect UTF8 (char) or UTF16 (wchar_t) paths regardless of platform, and converting a FilePath to and from those forms is a platform-dependent exercise which should be centralized into the class (i.e. adding ToUTF8 and ToWide functions to the class, and explicit constructors that take each type). One thing many of us have found, across multiple projects, is that wchar_t is fraught with complication as soon as more than one platform is involved. wchar_t == UTF16 is a Windowsism (gcc defaults to 4 bytes, for example, and Lmumble gets stored in UCS-4, not UTF-16). Chrome started with more or less what you are suggesting, and we moved off of it after much pain. I understand those issues quite well (but I probably should call the conversion method ToUTF16, now that you mention it). And char* isn't necessarily UTF8 on all platforms either. OK, so what's the currently recommended path for converting to UTF16 or UTF8 from a FilePath? That conversion is not defined. If you are on Linux, the contents of the file path is just an array of bytes. It might be UTF-8, in which case you can convert to UTF-16. However, it may also be some crazy encoding or it may not match any encoding. This OS does not require it to match an encoding. When we need to convert a FilePath to Unicode, we use the SysWideToNativeMB and SysNativeMBToWide functions from base. This works by inspecting what the system thinks the current multi-byte encoding is. On Mac that is UTF-8. On Linux, it depends on the value of $LANG. Each time we do such a conversion, we are introducing a potential bug in the product (on Linux at least), so we try hard to avoid them. -Darin --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Why is the Mac Omnibox stealing focus?
OK. Will update my bug with that blocker info. Avi On Wed, May 13, 2009 at 2:34 PM, Scott Hess sh...@chromium.org wrote: The why is probably because I misunderstood something. With an NSTextField there, we can't set the selection without having focus, which may have confused me into grabbing focus in cases where it isn't needed (or requested). I've been spending some time figuring out where all that code can get called from. Now that some of the other code is more fleshed out, the original reason for it to be there might be completely gone. http://crbug.com/11920 -scott On Wed, May 13, 2009 at 2:27 PM, Avi Drissman a...@google.com wrote: OK, so this was r15790. The code already exists to set the focus to the location bar if it already had it, though. Avi On Wed, May 13, 2009 at 2:24 PM, Avi Drissman a...@google.com wrote: I'm implementing save/restore focus when switching tabs, and a recent checkin on the Mac omnibox is causing it to steal the focus. To see this: (gdb) b -[NSWindow makeFirstResponder:] Then switch tabs: #5 0x961f7f7b in -[NSTextField becomeFirstResponder] () #6 0x000c209f in AutocompleteEditViewMac::UpdateAndStyleText (this=0x595a220, display_te...@0x595a260, user_text_length=0) at /Users/avi/Source/chrome/src/chrome/browser/autocomplete/ autocomplete_edit_view_mac.mm:281 #7 0x000c24d7 in AutocompleteEditViewMac::SetWindowTextAndCaretPos (this=0x595a220, te...@0x595a260, caret_pos=0) at /Users/avi/Source/chrome/src/chrome/browser/autocomplete/ autocomplete_edit_view_mac.mm:203 #8 0x000bcd36 in AutocompleteEditModel::Revert (this=0x595a250) at /Users/avi/Source/chrome/src/chrome/browser/autocomplete/autocomplete_edit.cc:174 #9 0x000c23bd in AutocompleteEditViewMac::RevertAll (this=0x595a220) at /Users/avi/Source/chrome/src/chrome/browser/autocomplete/ autocomplete_edit_view_mac.mm:215 #10 0x000c25b4 in AutocompleteEditViewMac::Update (this=0x595a220, tab_for_state_restoring=0x619da00) at /Users/avi/Source/chrome/src/chrome/browser/autocomplete/ autocomplete_edit_view_mac.mm:125 #11 0x001862bf in LocationBarViewMac::Update (this=0x5959720, contents=0x619da00, should_restore_state=true) at /Users/avi/Source/chrome/src/chrome/browser/cocoa/ location_bar_view_mac.mm:62 #12 0x00197ac8 in -[ToolbarController updateToolbarWithContents:shouldRestoreState:] (self=0x59554a0, _cmd=0x169a0a8, tab=0x619da00, shouldRestore=1 '\001') at /Users/avi/Source/chrome/src/chrome/browser/cocoa/ toolbar_controller.mm:102 #13 0x00181465 in -[BrowserWindowController updateToolbarWithContents:shouldRestoreState:] (self=0x5944880, _cmd=0x169a0a8, tab=0x619da00, shouldRestore=1 '\001') at /Users/avi/Source/chrome/src/chrome/browser/cocoa/ browser_window_controller.mm:305 #14 0x0017f1ff in BrowserWindowCocoa::UpdateToolbar (this=0x5949b10, contents=0x619da00, should_restore_state=true) at /Users/avi/Source/chrome/src/chrome/browser/cocoa/ browser_window_cocoa.mm:145 #15 0x00127b49 in Browser::UpdateToolbar (this=0x59432c0, should_restore_state=true) at /Users/avi/Source/chrome/src/chrome/browser/browser.cc:2257 UpdateToolbar ends up in AutocompleteEditViewMac::UpdateAndStyleText() which, on lines 280-3 insists on becoming the keyboard focus. Why? Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Why is the Mac Omnibox stealing focus?
OK, so this was r15790http://src.chromium.org/viewvc/chrome?view=revrevision=15790. The code already exists to set the focus to the location bar if it already had it, though. Avi On Wed, May 13, 2009 at 2:24 PM, Avi Drissman a...@google.com wrote: I'm implementing save/restore focus when switching tabs, and a recent checkin on the Mac omnibox is causing it to steal the focus. To see this: (gdb) b -[NSWindow makeFirstResponder:] Then switch tabs: #5 0x961f7f7b in -[NSTextField becomeFirstResponder] () #6 0x000c209f in AutocompleteEditViewMac::UpdateAndStyleText (this=0x595a220, display_te...@0x595a260, user_text_length=0) at /Users/avi/Source/chrome/src/chrome/browser/autocomplete/ autocomplete_edit_view_mac.mm:281 #7 0x000c24d7 in AutocompleteEditViewMac::SetWindowTextAndCaretPos (this=0x595a220, te...@0x595a260, caret_pos=0) at /Users/avi/Source/chrome/src/chrome/browser/autocomplete/ autocomplete_edit_view_mac.mm:203 #8 0x000bcd36 in AutocompleteEditModel::Revert (this=0x595a250) at /Users/avi/Source/chrome/src/chrome/browser/autocomplete/autocomplete_edit.cc:174 #9 0x000c23bd in AutocompleteEditViewMac::RevertAll (this=0x595a220) at /Users/avi/Source/chrome/src/chrome/browser/autocomplete/ autocomplete_edit_view_mac.mm:215 #10 0x000c25b4 in AutocompleteEditViewMac::Update (this=0x595a220, tab_for_state_restoring=0x619da00) at /Users/avi/Source/chrome/src/chrome/browser/autocomplete/ autocomplete_edit_view_mac.mm:125 #11 0x001862bf in LocationBarViewMac::Update (this=0x5959720, contents=0x619da00, should_restore_state=true) at /Users/avi/Source/chrome/src/chrome/browser/cocoa/ location_bar_view_mac.mm:62 #12 0x00197ac8 in -[ToolbarController updateToolbarWithContents:shouldRestoreState:] (self=0x59554a0, _cmd=0x169a0a8, tab=0x619da00, shouldRestore=1 '\001') at /Users/avi/Source/chrome/src/chrome/browser/cocoa/ toolbar_controller.mm:102 #13 0x00181465 in -[BrowserWindowController updateToolbarWithContents:shouldRestoreState:] (self=0x5944880, _cmd=0x169a0a8, tab=0x619da00, shouldRestore=1 '\001') at /Users/avi/Source/chrome/src/chrome/browser/cocoa/ browser_window_controller.mm:305 #14 0x0017f1ff in BrowserWindowCocoa::UpdateToolbar (this=0x5949b10, contents=0x619da00, should_restore_state=true) at /Users/avi/Source/chrome/src/chrome/browser/cocoa/ browser_window_cocoa.mm:145 #15 0x00127b49 in Browser::UpdateToolbar (this=0x59432c0, should_restore_state=true) at /Users/avi/Source/chrome/src/chrome/browser/browser.cc:2257 UpdateToolbar ends up in AutocompleteEditViewMac::UpdateAndStyleText() which, on lines 280-3 insists on becoming the keyboard focus. Why? Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Changes to FilePath?
On Wed, May 13, 2009 at 1:03 PM, Mark Mentovai m...@chromium.org wrote: If you've got to take an arbitrary FilePath and convert it for display to the user, or take an arbitrary string in a known encoding and re-encode it for the filesystem, then we don't have anything in FilePath for this. I believe that if we do add something, it should strictly operate only on single pathname components at a time, and not entire pathnames. We could add it to FilePath or we could add it somewhere else, because it is sort of distinct from what FilePath is really supposed to be, which is just a container for ferrying around native paths. OK, I can see the allure of dealing in terms of lists of encoded strings so that you can encode them separately. For my purposes, I need to get a string encoded as UTF16 (on Windows) or UTF8 (on other platforms) that represents a filename so that I can pass it to third party APIs, so it has to include the path separators. But that can be done as a join operation when I get the string out. It's also a specification and implementation nightmare. Everyone has a different idea of what normalization means. What's your idea? Yes, I know it's a nightmare all around, but I think it would be useful to have something that addresses this. My idea would be the same as Python's os.path.normpath, mainly because it's a well-tested, seasoned example with test cases. Windows also has a routine for this (PathCanonicalize) that could be used (but I know it doesn't work for UNC paths). Why would it be useful? Do you want to compare paths for equality? Yes, for instance to be able to place them into a map or set and be sure I only have one entry for a particular file. And I want to be able to do absolute to relative path conversions (as far as possible, anyhow). And yes, I know that those are *really hard* to do properly, which argues even more for implementing one in a common library so that individual developers don't roll their own all the time, thinking that it is easy (and consequently producing buggy implementations). Then we should have an API that compares paths for equality. It would have to hit the disk to do so. You might need general-purpose canonization to implement that on some systems. Great, you need to hit the disk to do that too. It's fine if you want these things, but we can't put them into FilePath. It's important that FilePath remain lightweight and not make any system calls, because system calls can block and FilePath is just a data carrier. Which is why I proposed in my last message not putting them into FilePath, since I can see that it is not your intention that it support anything that hits the filesystem (and I can see why you would want that). os.path.normpath is known to be buggy. It might be well-tested and seasoned, but only within the confines of its known limitations. Watch this. [...] Yes, I'm aware that you can create situations (especially with symbolic links) where the same path conversions will succeed or fail depending on the filesystem contents. This is why the class would have to have access to the filesystem. Again, it sounds like what you really want is a pathname comparator that hits the disk. You really can't do this stuff correctly on most systems without talking to the filesystem. You can't even do general-purpose canonization without talking to the filesystem. Yep. Totally agreed. (and normcase is probably not the behavior I'm looking for, you're right). Let me make clear: I'm not trying to shoot down the idea of needing to be able to compare paths or even necessarily canonize them. I'm arguing primarily against doing it in FilePath, but I'm also also trying to illustrate that doing proper comparisons and canonization is harder than it seems, that even seasoned and well-tested APIs are limited in ways that developers don't necessarily expect, and that the semantics and expectations need to be well-defined. Very well illustrated, and I assure you that I'm well aware that it's a bitch to do right. -Greg. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Why is the Mac Omnibox stealing focus?
The why is probably because I misunderstood something. With an NSTextField there, we can't set the selection without having focus, which may have confused me into grabbing focus in cases where it isn't needed (or requested). I've been spending some time figuring out where all that code can get called from. Now that some of the other code is more fleshed out, the original reason for it to be there might be completely gone. http://crbug.com/11920 -scott On Wed, May 13, 2009 at 2:27 PM, Avi Drissman a...@google.com wrote: OK, so this was r15790. The code already exists to set the focus to the location bar if it already had it, though. Avi On Wed, May 13, 2009 at 2:24 PM, Avi Drissman a...@google.com wrote: I'm implementing save/restore focus when switching tabs, and a recent checkin on the Mac omnibox is causing it to steal the focus. To see this: (gdb) b -[NSWindow makeFirstResponder:] Then switch tabs: #5 0x961f7f7b in -[NSTextField becomeFirstResponder] () #6 0x000c209f in AutocompleteEditViewMac::UpdateAndStyleText (this=0x595a220, display_te...@0x595a260, user_text_length=0) at /Users/avi/Source/chrome/src/chrome/browser/autocomplete/autocomplete_edit_view_mac.mm:281 #7 0x000c24d7 in AutocompleteEditViewMac::SetWindowTextAndCaretPos (this=0x595a220, te...@0x595a260, caret_pos=0) at /Users/avi/Source/chrome/src/chrome/browser/autocomplete/autocomplete_edit_view_mac.mm:203 #8 0x000bcd36 in AutocompleteEditModel::Revert (this=0x595a250) at /Users/avi/Source/chrome/src/chrome/browser/autocomplete/autocomplete_edit.cc:174 #9 0x000c23bd in AutocompleteEditViewMac::RevertAll (this=0x595a220) at /Users/avi/Source/chrome/src/chrome/browser/autocomplete/autocomplete_edit_view_mac.mm:215 #10 0x000c25b4 in AutocompleteEditViewMac::Update (this=0x595a220, tab_for_state_restoring=0x619da00) at /Users/avi/Source/chrome/src/chrome/browser/autocomplete/autocomplete_edit_view_mac.mm:125 #11 0x001862bf in LocationBarViewMac::Update (this=0x5959720, contents=0x619da00, should_restore_state=true) at /Users/avi/Source/chrome/src/chrome/browser/cocoa/location_bar_view_mac.mm:62 #12 0x00197ac8 in -[ToolbarController updateToolbarWithContents:shouldRestoreState:] (self=0x59554a0, _cmd=0x169a0a8, tab=0x619da00, shouldRestore=1 '\001') at /Users/avi/Source/chrome/src/chrome/browser/cocoa/toolbar_controller.mm:102 #13 0x00181465 in -[BrowserWindowController updateToolbarWithContents:shouldRestoreState:] (self=0x5944880, _cmd=0x169a0a8, tab=0x619da00, shouldRestore=1 '\001') at /Users/avi/Source/chrome/src/chrome/browser/cocoa/browser_window_controller.mm:305 #14 0x0017f1ff in BrowserWindowCocoa::UpdateToolbar (this=0x5949b10, contents=0x619da00, should_restore_state=true) at /Users/avi/Source/chrome/src/chrome/browser/cocoa/browser_window_cocoa.mm:145 #15 0x00127b49 in Browser::UpdateToolbar (this=0x59432c0, should_restore_state=true) at /Users/avi/Source/chrome/src/chrome/browser/browser.cc:2257 UpdateToolbar ends up in AutocompleteEditViewMac::UpdateAndStyleText() which, on lines 280-3 insists on becoming the keyboard focus. Why? Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Changes to FilePath?
On Wed, May 13, 2009 at 2:05 PM, Darin Fisher da...@chromium.org wrote: That conversion is not defined. If you are on Linux, the contents of the file path is just an array of bytes. It might be UTF-8, in which case you can convert to UTF-16. However, it may also be some crazy encoding or it may not match any encoding. This OS does not require it to match an encoding. When we need to convert a FilePath to Unicode, we use the SysWideToNativeMB and SysNativeMBToWide functions from base. This works by inspecting what the system thinks the current multi-byte encoding is. On Mac that is UTF-8. On Linux, it depends on the value of $LANG. Each time we do such a conversion, we are introducing a potential bug in the product (on Linux at least), so we try hard to avoid them. Yes, I know that this is how it works (see earlier messages in this thread), but can you tell me if there are any Linux apps that manage to do this correctly (e.g. without having this bug), and how they do it? I can't see how any Linux app can do any better than looking at LANG and LC_CHAR and hoping that they're set correctly. Certainly there's no way to decode a pathname that includes multiple encodings, and I have no idea what happens with NFS mounts between machines with different settings. I'm just saying why not just do as well as can be done by the best app out there, and punt after that? -Greg. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Changes to FilePath?
This post made me think that we should have infrastructure so that
certain unit tests can opt to run in a restricted environment to
enforce that someone doesn't come along and add filesystem-access code
or other known-bad synchronous APIs.
I realize that that is probably hard, and that patches would be
welcome. Just throwing it out there in hopes that someone says Hey,
I know how to do that and someone else says Hey, do that.
-scott
[It could also be a rathole that only seems like a good idea until you
actually try it, like getting const-ness propagation thoroughly
correct.]
On Wed, May 13, 2009 at 1:03 PM, Mark Mentovai m...@chromium.org wrote:
If you've got a file that begins its life as something on-disk, and
you just need to carry the path to it around, then that's fine, it
should live its life as a FilePath.
If you've got to create a file using some name where the name is some
constant in code, use FilePath with ASCII constants. AppendASCII
exists to stick new ASCII components onto existing FilePaths. This is
fine and is considered safe because ASCII is a subset of any rational
filesystem encoding.
If you've got to take an arbitrary FilePath and convert it for display
to the user, or take an arbitrary string in a known encoding and
re-encode it for the filesystem, then we don't have anything in
FilePath for this. I believe that if we do add something, it should
strictly operate only on single pathname components at a time, and not
entire pathnames. We could add it to FilePath or we could add it
somewhere else, because it is sort of distinct from what FilePath is
really supposed to be, which is just a container for ferrying around
native paths.
It's also a specification and implementation nightmare. Everyone has
a different idea of what normalization means. What's your idea?
Yes, I know it's a nightmare all around, but I think it would be useful to
have something that addresses this. My idea would be the same as Python's
os.path.normpath, mainly because it's a well-tested, seasoned example with
test cases. Windows also has a routine for this (PathCanonicalize) that
could be used (but I know it doesn't work for UNC paths).
Why would it be useful? Do you want to compare paths for equality?
Then we should have an API that compares paths for equality. It would
have to hit the disk to do so. You might need general-purpose
canonization to implement that on some systems. Great, you need to
hit the disk to do that too. It's fine if you want these things, but
we can't put them into FilePath. It's important that FilePath remain
lightweight and not make any system calls, because system calls can
block and FilePath is just a data carrier.
os.path.normpath is known to be buggy. It might be well-tested and
seasoned, but only within the confines of its known limitations.
Watch this.
m...@anodizer bash$ ls -l a/b/../c
-rw-r--r-- 1 mark staff 0 May 13 15:47 a/b/../c
m...@anodizer bash$ python
Python 2.5.1 (r251:54863, Feb 6 2009, 19:02:12)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type help, copyright, credits or license for more information.
import os.path
os.path.normpath('a/b/../c')
'a/c'
^D
m...@anodizer bash$ ls -l a/c
ls: a/c: No such file or directory
Probably the same as os.path.normcase in Python. I want this stuff so that
I can make sure that I can at least semi-reliably compare/manipulate
FilePaths to do things like absolute-relative path conversion, or store
FilePaths in a set or map and be sure I don't have multiple entries pointing
to the same file. Without these kinds of operations, doing these things is
pretty much impossible.
I don't think os.path.normcase does what you're asking for either.
m...@anodizer bash$ ls -lid /System/Library
81 drwxr-xr-x 64 root wheel 2176 May 12 18:37 /System/Library
m...@anodizer bash$ ls -lid /system/LIBRARY
81 drwxr-xr-x 64 root wheel 2176 May 12 18:37 /system/LIBRARY
m...@anodizer bash$ python
Python 2.5.1 (r251:54863, Feb 6 2009, 19:02:12)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type help, copyright, credits or license for more information.
import sys
sys.platform
'darwin'
import os.path
os.path.normcase('/System/Library')
'/System/Library'
os.path.normcase('/system/LIBRARY')
'/system/LIBRARY'
^D
Even os.path.realpath returns the same results.
Again, it sounds like what you really want is a pathname comparator
that hits the disk. You really can't do this stuff correctly on most
systems without talking to the filesystem. You can't even do
general-purpose canonization without talking to the filesystem.
Let me make clear: I'm not trying to shoot down the idea of needing to
be able to compare paths or even necessarily canonize them. I'm
arguing primarily against doing it in FilePath, but I'm also also
trying to illustrate that doing proper comparisons and canonization is
harder than it seems, that even seasoned and well-tested APIs
[chromium-dev] Re: Changes to FilePath?
Perhaps what we need is a companion to FilePath. For example: FilePath: much as it is now, lightweight, alternative to string manipulation. FileReference: heavierweight, can talk to the file system and have carnal knowledge of platform specifics for things like resolving / canonicalizing pathnames, determining whether or not they refer to the same files, generating C strings that can be passed to 3rd party libraries, etc. --Amanda On Wed, May 13, 2009 at 5:22 PM, Greg Spencer gspen...@google.com wrote: On Wed, May 13, 2009 at 1:03 PM, Mark Mentovai m...@chromium.org wrote: If you've got to take an arbitrary FilePath and convert it for display to the user, or take an arbitrary string in a known encoding and re-encode it for the filesystem, then we don't have anything in FilePath for this. I believe that if we do add something, it should strictly operate only on single pathname components at a time, and not entire pathnames. We could add it to FilePath or we could add it somewhere else, because it is sort of distinct from what FilePath is really supposed to be, which is just a container for ferrying around native paths. OK, I can see the allure of dealing in terms of lists of encoded strings so that you can encode them separately. For my purposes, I need to get a string encoded as UTF16 (on Windows) or UTF8 (on other platforms) that represents a filename so that I can pass it to third party APIs, so it has to include the path separators. But that can be done as a join operation when I get the string out. It's also a specification and implementation nightmare. Everyone has a different idea of what normalization means. What's your idea? Yes, I know it's a nightmare all around, but I think it would be useful to have something that addresses this. My idea would be the same as Python's os.path.normpath, mainly because it's a well-tested, seasoned example with test cases. Windows also has a routine for this (PathCanonicalize) that could be used (but I know it doesn't work for UNC paths). Why would it be useful? Do you want to compare paths for equality? Yes, for instance to be able to place them into a map or set and be sure I only have one entry for a particular file. And I want to be able to do absolute to relative path conversions (as far as possible, anyhow). And yes, I know that those are *really hard* to do properly, which argues even more for implementing one in a common library so that individual developers don't roll their own all the time, thinking that it is easy (and consequently producing buggy implementations). Then we should have an API that compares paths for equality. It would have to hit the disk to do so. You might need general-purpose canonization to implement that on some systems. Great, you need to hit the disk to do that too. It's fine if you want these things, but we can't put them into FilePath. It's important that FilePath remain lightweight and not make any system calls, because system calls can block and FilePath is just a data carrier. Which is why I proposed in my last message not putting them into FilePath, since I can see that it is not your intention that it support anything that hits the filesystem (and I can see why you would want that). os.path.normpath is known to be buggy. It might be well-tested and seasoned, but only within the confines of its known limitations. Watch this. [...] Yes, I'm aware that you can create situations (especially with symbolic links) where the same path conversions will succeed or fail depending on the filesystem contents. This is why the class would have to have access to the filesystem. Again, it sounds like what you really want is a pathname comparator that hits the disk. You really can't do this stuff correctly on most systems without talking to the filesystem. You can't even do general-purpose canonization without talking to the filesystem. Yep. Totally agreed. (and normcase is probably not the behavior I'm looking for, you're right). Let me make clear: I'm not trying to shoot down the idea of needing to be able to compare paths or even necessarily canonize them. I'm arguing primarily against doing it in FilePath, but I'm also also trying to illustrate that doing proper comparisons and canonization is harder than it seems, that even seasoned and well-tested APIs are limited in ways that developers don't necessarily expect, and that the semantics and expectations need to be well-defined. Very well illustrated, and I assure you that I'm well aware that it's a bitch to do right. -Greg. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Changes to FilePath?
On Wed, May 13, 2009 at 3:51 PM, Amanda Walker ama...@chromium.org wrote: Perhaps what we need is a companion to FilePath. For example: FilePath: much as it is now, lightweight, alternative to string manipulation. FileReference: heavierweight, can talk to the file system and have carnal knowledge of platform specifics for things like resolving / canonicalizing pathnames, determining whether or not they refer to the same files, generating C strings that can be passed to 3rd party libraries, etc. I think this is very dangerous. I think Greg should not be talking to the filesystem when inserting filenames into a set. We don't allow filesystem access from the UI thread of Chrome, and I think other parts of our system should also not do filesystem access on their critical threads, especially if they want to be more part of Chrome in the future. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Changes to FilePath?
On Wed, May 13, 2009 at 7:07 PM, Brett Wilson bre...@chromium.org wrote: On Wed, May 13, 2009 at 3:51 PM, Amanda Walker ama...@chromium.org wrote: Perhaps what we need is a companion to FilePath. For example: FilePath: much as it is now, lightweight, alternative to string manipulation. FileReference: heavierweight, can talk to the file system and have carnal knowledge of platform specifics for things like resolving / canonicalizing pathnames, determining whether or not they refer to the same files, generating C strings that can be passed to 3rd party libraries, etc. I think this is very dangerous. I think Greg should not be talking to the filesystem when inserting filenames into a set. We don't allow filesystem access from the UI thread of Chrome, and I think other parts of our system should also not do filesystem access on their critical threads, especially if they want to be more part of Chrome in the future. But in context, he's passing these things to 3rd party libraries that will be doing plenty of file system access (importing and exporting data, for example). That's why I was suggesting something separate from FilePath for such use. --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Changes to FilePath?
On Wed, May 13, 2009 at 2:20 PM, Greg Spencer gspen...@google.com wrote: On Wed, May 13, 2009 at 2:05 PM, Darin Fisher da...@chromium.org wrote: That conversion is not defined. If you are on Linux, the contents of the file path is just an array of bytes. It might be UTF-8, in which case you can convert to UTF-16. However, it may also be some crazy encoding or it may not match any encoding. This OS does not require it to match an encoding. When we need to convert a FilePath to Unicode, we use the SysWideToNativeMB and SysNativeMBToWide functions from base. This works by inspecting what the system thinks the current multi-byte encoding is. On Mac that is UTF-8. On Linux, it depends on the value of $LANG. Each time we do such a conversion, we are introducing a potential bug in the product (on Linux at least), so we try hard to avoid them. Yes, I know that this is how it works (see earlier messages in this thread), but can you tell me if there are any Linux apps that manage to do this correctly (e.g. without having this bug), and how they do it? I can't see how any Linux app can do any better than looking at LANG and LC_CHAR and hoping that they're set correctly. Certainly there's no way to decode a pathname that includes multiple encodings, and I have no idea what happens with NFS mounts between machines with different settings. I'm just saying why not just do as well as can be done by the best app out there, and punt after that? -Greg. Sorry to repeat information. This is a long thread! The solution is to not convert to UTF-16 unless you are trying to generate a string to display to the user. Then you should use the LANG information to determine how best to render the text for display to the user. The program should try its best to preserve the file path in the original form and not try to convert to UTF-16 and back again since that conversion may be lossy. I know this doesn't really help. I think it is reasonable to have a utility somewhere to perform a conversion to UTF-16 (or UTF-8), but it should come with a stern warning, and I kind of prefer it not being a method on FilePath since I would prefer people not be tempted to overuse it. -Darin --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Changes to FilePath?
On Wed, May 13, 2009 at 4:34 PM, Amanda Walker ama...@chromium.org wrote: On Wed, May 13, 2009 at 7:07 PM, Brett Wilson bre...@chromium.org wrote: On Wed, May 13, 2009 at 3:51 PM, Amanda Walker ama...@chromium.org wrote: Perhaps what we need is a companion to FilePath. For example: FilePath: much as it is now, lightweight, alternative to string manipulation. FileReference: heavierweight, can talk to the file system and have carnal knowledge of platform specifics for things like resolving / canonicalizing pathnames, determining whether or not they refer to the same files, generating C strings that can be passed to 3rd party libraries, etc. I think this is very dangerous. I think Greg should not be talking to the filesystem when inserting filenames into a set. We don't allow filesystem access from the UI thread of Chrome, and I think other parts of our system should also not do filesystem access on their critical threads, especially if they want to be more part of Chrome in the future. But in context, he's passing these things to 3rd party libraries that will be doing plenty of file system access (importing and exporting data, for example). That's why I was suggesting something separate from FilePath for such use. Then he doesn't need canonicalization at all. He needs to know how the third party library is going to use the string for filesystem access and then do the corresponding transformations. That does not involve filesystem access. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] New Jank label in issue tracker
Though I've upgraded my desktop PC to fancy hardware, I still use a Core 2 Duo 2.4GHz laptop with 2GB RAM. This is still a pretty typical configuration for even high end laptops today. Sad to say under heavy load (several windows, many tabs in each), the amount of jank I'm experiencing is pretty high. To help identify and triage these issues, I've added a Jank label in the bug system. I feel like we should focus on reducing these issues in the next release cycle - this is an area where we have historically had a good performance, we should not lose it. It's hard to write tests for jankiness because time and entropy are typically the key inputs more than any specific set of pages. But if you experience jank in your own use of Chrome I encourage you to try and identify causes and file bugs with this new label. http://code.google.com/p/chromium/issues/list?can=2q=label%3AJank -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium Valgrind Fixit Day!
And the award goes to... % git log origin --since=yesterday --grep=valgrind -i --pretty='format:%an %s' thes...@chromium.org Split NetUtilTest.IDNToUnicode into IDNToUnicodeFast e...@chromium.org valgrind: print the gtest suppression list on startup. Wait, we've had *one* fix so far? :~( (Mine doesn't count, as it's a one-liner for logging.) I guess there's room for some others where someone didn't mention valgrind in their commit message. I've made progress on two more bugs, but that leaves pretty much all the rest unclaimed. http://code.google.com/p/chromium/issues/list?can=2q=label:valgrind On Mon, May 11, 2009 at 2:20 PM, Dan Kegel daniel.r.ke...@gmail.com wrote: We've been using Valgrind to find memory leaks, pointer errors, and race conditions in Chromium on Mac and Linux for a while now. (See the valgrind bots at http://build.chromium.org.) That's cool, but it would be even cooler if we actually fixed the problems Valgrind has found. According to http://code.google.com/p/chromium/issues/list?q=valgrind we've fixed 24 Valgrind issues already, but there are 60 still open. So let's do something about it! The first step is for you to visit http://dev.chromium.org/developers/how-tos/using-valgrind and learn about how to use Valgrind to find problems in Chromium. A few Chromium developers (playmobil, jhawkins, thestig, and myself) are going to host a Valgrind Fixit this Wednesday and Thursday, May 13th and 14th. We'll be available on the chromium irc channel (irc.freenode.net/#chromium) to help you get started using Valgrind with Chromium. The page linked above also has suggestions for what to do during the Fixit. (For instance, be sure to put a note in the bug report saying you've started fixing the bug, so nobody else duplicates your effort.) As incentive for people to help out, we will send a Valgrind mug to whoever contributes the best Valgrind-related fixes, bug reports, and/or triage during those two days (winner will be chosen at the discretion of the valgrind fixit judging panel). Thanks, and see you at the Fixit! - Dan p.s. And thanks to Julian Seward of http://valgrind.org for providing such a wonderful tool! --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium Valgrind Fixit Day!
A few of these, where root cause is the same (leaking of tasks, for example 11462, 6, 11144 among others) should get fixed once http://codereview.chromium.org/115328 gets committed. On Wed, May 13, 2009 at 5:23 PM, Evan Martin e...@chromium.org wrote: And the award goes to... % git log origin --since=yesterday --grep=valgrind -i --pretty='format:%an %s' thes...@chromium.org Split NetUtilTest.IDNToUnicode into IDNToUnicodeFast e...@chromium.org valgrind: print the gtest suppression list on startup. Wait, we've had *one* fix so far? :~( (Mine doesn't count, as it's a one-liner for logging.) I guess there's room for some others where someone didn't mention valgrind in their commit message. I've made progress on two more bugs, but that leaves pretty much all the rest unclaimed. http://code.google.com/p/chromium/issues/list?can=2q=label:valgrind On Mon, May 11, 2009 at 2:20 PM, Dan Kegel daniel.r.ke...@gmail.com wrote: We've been using Valgrind to find memory leaks, pointer errors, and race conditions in Chromium on Mac and Linux for a while now. (See the valgrind bots at http://build.chromium.org.) That's cool, but it would be even cooler if we actually fixed the problems Valgrind has found. According to http://code.google.com/p/chromium/issues/list?q=valgrind we've fixed 24 Valgrind issues already, but there are 60 still open. So let's do something about it! The first step is for you to visit http://dev.chromium.org/developers/how-tos/using-valgrind and learn about how to use Valgrind to find problems in Chromium. A few Chromium developers (playmobil, jhawkins, thestig, and myself) are going to host a Valgrind Fixit this Wednesday and Thursday, May 13th and 14th. We'll be available on the chromium irc channel (irc.freenode.net/#chromium) to help you get started using Valgrind with Chromium. The page linked above also has suggestions for what to do during the Fixit. (For instance, be sure to put a note in the bug report saying you've started fixing the bug, so nobody else duplicates your effort.) As incentive for people to help out, we will send a Valgrind mug to whoever contributes the best Valgrind-related fixes, bug reports, and/or triage during those two days (winner will be chosen at the discretion of the valgrind fixit judging panel). Thanks, and see you at the Fixit! - Dan p.s. And thanks to Julian Seward of http://valgrind.org for providing such a wonderful tool! --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Changes to FilePath?
On Wed, May 13, 2009 at 4:35 PM, Darin Fisher da...@chromium.org wrote: The solution is to not convert to UTF-16 unless you are trying to generate a string to display to the user. Then you should use the LANG information to determine how best to render the text for display to the user. Yeah, that would be nice, and I agree, but the reason I need it is that some third party APIs (probably wrongly) take UTF16 to represent an input file in their API. So in order for the third party API to load the file properly, I need a UTF16 version of the file path. Also, in all of the O3D code, we assume that strings are encoded in UTF8 (which is fine and correct for any string except for filenames on Linux), so any string that might come from the user would come in as UTF8, and I'd have to translate it into a FilePath (somehow). I know this doesn't really help. I think it is reasonable to have a utility somewhere to perform a conversion to UTF-16 (or UTF-8), but it should come with a stern warning, and I kind of prefer it not being a method on FilePath since I would prefer people not be tempted to overuse it. Yeah, I think we've beat that to death: it won't be in FilePath. -Greg. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Changes to FilePath?
On Wed, May 13, 2009 at 4:07 PM, Brett Wilson bre...@chromium.org wrote: On Wed, May 13, 2009 at 3:51 PM, Amanda Walker ama...@chromium.org wrote: Perhaps what we need is a companion to FilePath. For example: FilePath: much as it is now, lightweight, alternative to string manipulation. FileReference: heavierweight, can talk to the file system and have carnal knowledge of platform specifics for things like resolving / canonicalizing pathnames, determining whether or not they refer to the same files, generating C strings that can be passed to 3rd party libraries, etc. I think this is very dangerous. I think Greg should not be talking to the filesystem when inserting filenames into a set. We don't allow filesystem access from the UI thread of Chrome, and I think other parts of our system should also not do filesystem access on their critical threads, especially if they want to be more part of Chrome in the future. Well, so the use I have for this in O3D at the moment is in our importer, which currently is a separate command-line tool that reads Collada files and writes out our wire format for geometry. So it isn't meant to be occuring in a UI thread, but I could see times when it might be useful to know for sure if two files reference the same file in the UI thread (dragging and dropping a file onto a drop zone, for instance). I do need to know if I have the same file more than once in a set because the COLLADA file might reference the same texture multiple times, or (more dangerous) it might reference a file that is one file on Windows, but (incorrectly) maps to two different files in the (Unix-path-format) .tgz files. To detect that, I need canonicalization. I also need to convert paths in the Collada file to relative paths in our tgz files. In order to do that, I need to be able to normalize the path to the Collada file so I can normalize the paths to the referenced texture files and strip off common base directories. I'd really like to avoid the filesystem access too -- it's a real pain in the ass to do, which is why it hasn't been done yet. Currently, the user has to tell me the string to strip off of the pathnames to make them relative, and if files collide or split, then the output is just 2x bigger, or just doesn't work. I'd like to fix those things, but to do it right, I need a better set of tools, and it seemed to me that if I was needing these tools, then someone else could use them too. -Greg. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Changes to FilePath?
On Wed, May 13, 2009 at 6:12 PM, Greg Spencer gspen...@google.com wrote: On Wed, May 13, 2009 at 4:07 PM, Brett Wilson bre...@chromium.org wrote: On Wed, May 13, 2009 at 3:51 PM, Amanda Walker ama...@chromium.org wrote: Perhaps what we need is a companion to FilePath. For example: FilePath: much as it is now, lightweight, alternative to string manipulation. FileReference: heavierweight, can talk to the file system and have carnal knowledge of platform specifics for things like resolving / canonicalizing pathnames, determining whether or not they refer to the same files, generating C strings that can be passed to 3rd party libraries, etc. I think this is very dangerous. I think Greg should not be talking to the filesystem when inserting filenames into a set. We don't allow filesystem access from the UI thread of Chrome, and I think other parts of our system should also not do filesystem access on their critical threads, especially if they want to be more part of Chrome in the future. Well, so the use I have for this in O3D at the moment is in our importer, which currently is a separate command-line tool that reads Collada files and writes out our wire format for geometry. So it isn't meant to be occuring in a UI thread, but I could see times when it might be useful to know for sure if two files reference the same file in the UI thread (dragging and dropping a file onto a drop zone, for instance). I do need to know if I have the same file more than once in a set because the COLLADA file might reference the same texture multiple times, or (more dangerous) it might reference a file that is one file on Windows, but (incorrectly) maps to two different files in the (Unix-path-format) .tgz files. To detect that, I need canonicalization. You can't actually canonicalize a filename on Windows, so I think it's dangerous to write a component that claims to do it. I think you just need to come up with some simple rules that makes it work most of the time. Personally I would do ASCII lowercasing and stop worrying about it. If you use ICU to lower-case correctly, Windows won't necessarily agree and you won't be able to use that file. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Changes to FilePath?
On Wed, May 13, 2009 at 7:24 PM, Brett Wilson bre...@chromium.org wrote: On Wed, May 13, 2009 at 6:12 PM, Greg Spencer gspen...@google.com wrote: On Wed, May 13, 2009 at 4:07 PM, Brett Wilson bre...@chromium.org wrote: On Wed, May 13, 2009 at 3:51 PM, Amanda Walker ama...@chromium.org wrote: Perhaps what we need is a companion to FilePath. For example: FilePath: much as it is now, lightweight, alternative to string manipulation. FileReference: heavierweight, can talk to the file system and have carnal knowledge of platform specifics for things like resolving / canonicalizing pathnames, determining whether or not they refer to the same files, generating C strings that can be passed to 3rd party libraries, etc. I think this is very dangerous. I think Greg should not be talking to the filesystem when inserting filenames into a set. We don't allow filesystem access from the UI thread of Chrome, and I think other parts of our system should also not do filesystem access on their critical threads, especially if they want to be more part of Chrome in the future. Well, so the use I have for this in O3D at the moment is in our importer, which currently is a separate command-line tool that reads Collada files and writes out our wire format for geometry. So it isn't meant to be occuring in a UI thread, but I could see times when it might be useful to know for sure if two files reference the same file in the UI thread (dragging and dropping a file onto a drop zone, for instance). I do need to know if I have the same file more than once in a set because the COLLADA file might reference the same texture multiple times, or (more dangerous) it might reference a file that is one file on Windows, but (incorrectly) maps to two different files in the (Unix-path-format) .tgz files. To detect that, I need canonicalization. You can't actually canonicalize a filename on Windows, so I think it's dangerous to write a component that claims to do it. I guess you could call GetShortPathName every time you see a name. But I think that's a crazy solution. I still think you should do my suggestion below. I think you just need to come up with some simple rules that makes it work most of the time. Personally I would do ASCII lowercasing and stop worrying about it. If you use ICU to lower-case correctly, Windows won't necessarily agree and you won't be able to use that file. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Changes to FilePath?
FYI: Don't use GetShortPathName. It isn't supported on some Windows systems. We had a significant number of users that could not use Firefox until we stopped using it. -Darin On Wed, May 13, 2009 at 7:29 PM, Brett Wilson bre...@chromium.org wrote: On Wed, May 13, 2009 at 7:24 PM, Brett Wilson bre...@chromium.org wrote: On Wed, May 13, 2009 at 6:12 PM, Greg Spencer gspen...@google.com wrote: On Wed, May 13, 2009 at 4:07 PM, Brett Wilson bre...@chromium.org wrote: On Wed, May 13, 2009 at 3:51 PM, Amanda Walker ama...@chromium.org wrote: Perhaps what we need is a companion to FilePath. For example: FilePath: much as it is now, lightweight, alternative to string manipulation. FileReference: heavierweight, can talk to the file system and have carnal knowledge of platform specifics for things like resolving / canonicalizing pathnames, determining whether or not they refer to the same files, generating C strings that can be passed to 3rd party libraries, etc. I think this is very dangerous. I think Greg should not be talking to the filesystem when inserting filenames into a set. We don't allow filesystem access from the UI thread of Chrome, and I think other parts of our system should also not do filesystem access on their critical threads, especially if they want to be more part of Chrome in the future. Well, so the use I have for this in O3D at the moment is in our importer, which currently is a separate command-line tool that reads Collada files and writes out our wire format for geometry. So it isn't meant to be occuring in a UI thread, but I could see times when it might be useful to know for sure if two files reference the same file in the UI thread (dragging and dropping a file onto a drop zone, for instance). I do need to know if I have the same file more than once in a set because the COLLADA file might reference the same texture multiple times, or (more dangerous) it might reference a file that is one file on Windows, but (incorrectly) maps to two different files in the (Unix-path-format) .tgz files. To detect that, I need canonicalization. You can't actually canonicalize a filename on Windows, so I think it's dangerous to write a component that claims to do it. I guess you could call GetShortPathName every time you see a name. But I think that's a crazy solution. I still think you should do my suggestion below. I think you just need to come up with some simple rules that makes it work most of the time. Personally I would do ASCII lowercasing and stop worrying about it. If you use ICU to lower-case correctly, Windows won't necessarily agree and you won't be able to use that file. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Changes to FilePath?
I mean.. there's a registry setting or something that can be set to disable it.-darin On Wed, May 13, 2009 at 8:40 PM, Darin Fisher da...@chromium.org wrote: FYI: Don't use GetShortPathName. It isn't supported on some Windows systems. We had a significant number of users that could not use Firefox until we stopped using it. -Darin On Wed, May 13, 2009 at 7:29 PM, Brett Wilson bre...@chromium.org wrote: On Wed, May 13, 2009 at 7:24 PM, Brett Wilson bre...@chromium.org wrote: On Wed, May 13, 2009 at 6:12 PM, Greg Spencer gspen...@google.com wrote: On Wed, May 13, 2009 at 4:07 PM, Brett Wilson bre...@chromium.org wrote: On Wed, May 13, 2009 at 3:51 PM, Amanda Walker ama...@chromium.org wrote: Perhaps what we need is a companion to FilePath. For example: FilePath: much as it is now, lightweight, alternative to string manipulation. FileReference: heavierweight, can talk to the file system and have carnal knowledge of platform specifics for things like resolving / canonicalizing pathnames, determining whether or not they refer to the same files, generating C strings that can be passed to 3rd party libraries, etc. I think this is very dangerous. I think Greg should not be talking to the filesystem when inserting filenames into a set. We don't allow filesystem access from the UI thread of Chrome, and I think other parts of our system should also not do filesystem access on their critical threads, especially if they want to be more part of Chrome in the future. Well, so the use I have for this in O3D at the moment is in our importer, which currently is a separate command-line tool that reads Collada files and writes out our wire format for geometry. So it isn't meant to be occuring in a UI thread, but I could see times when it might be useful to know for sure if two files reference the same file in the UI thread (dragging and dropping a file onto a drop zone, for instance). I do need to know if I have the same file more than once in a set because the COLLADA file might reference the same texture multiple times, or (more dangerous) it might reference a file that is one file on Windows, but (incorrectly) maps to two different files in the (Unix-path-format) .tgz files. To detect that, I need canonicalization. You can't actually canonicalize a filename on Windows, so I think it's dangerous to write a component that claims to do it. I guess you could call GetShortPathName every time you see a name. But I think that's a crazy solution. I still think you should do my suggestion below. I think you just need to come up with some simple rules that makes it work most of the time. Personally I would do ASCII lowercasing and stop worrying about it. If you use ICU to lower-case correctly, Windows won't necessarily agree and you won't be able to use that file. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
