Re: [Pharo-dev] Path >> fullName should not be the same as printString

so how can we make progress? Stef Le 14/10/16 à 14:57, Damien Pollet a écrit : While we're at it, canonicalizing paths at creation time seems wrong also: First because those two expressions do not return the same thing: Path from: 'a/b/c/../d' Path * / 'a' / 'b' / 'c' / '..' / 'd' Second

Re: [Pharo-dev] Path >> fullName should not be the same as printString

While we're at it, canonicalizing paths at creation time seems wrong also: First because those two expressions do not return the same thing: Path from: 'a/b/c/../d' Path * / 'a' / 'b' / 'c' / '..' / 'd' Second because if c happens to be a symlink, then the operating system will not find the same

Re: [Pharo-dev] Path >> fullName should not be the same as printString

All this already works (although maybe not perfectly in edge cases). Consider: 'file:///C:/Users/tempfile.txt' asUrl. 'file:///C:/Users/tempfile.txt' asUrl asFileReference. FileLocator C / 'Users' / 'tmpfile.txt'. Where the last two are identical. Note that relative file URLs do not

Re: [Pharo-dev] Path >> fullName should not be the same as printString

At least Chrome uses this: file:///C:/Users/tempfile.txt On Fri, Oct 14, 2016 at 1:45 AM, Martin McClure wrote: > On 10/13/2016 10:35 AM, Damien Pollet wrote: > >> Could you give an example what the file:// URLs look like when they >> contain a drive letter? >> >> I'm

Re: [Pharo-dev] Path >> fullName should not be the same as printString

On 10/13/2016 10:35 AM, Damien Pollet wrote: Could you give an example what the file:// URLs look like when they contain a drive letter? I'm afraid I don't have any Windows machines handy to see what Internet Explorer does, but as far as I can tell an absolute URL compliant with RFC 3986

Re: [Pharo-dev] Path >> fullName should not be the same as printString

Yes, I knew about the per-drive current directory… Could you give an example what the file:// URLs look like when they contain a drive letter? For context, my goal looking at this was to make Path instances able to output a string representation of themselves that is useable independently of a

Re: [Pharo-dev] Path >> fullName should not be the same as printString

Its awkward to deal with. Some notes here... https://pharo.fogbugz.com/default.asp?13094#154946 On Fri, Oct 14, 2016 at 12:05 AM, Damien Pollet wrote: > I explored a bit more and I'm stumped. Fixing it for Unix is easy, but it > breaks Windows paths, because those use

Re: [Pharo-dev] Path >> fullName should not be the same as printString

I explored a bit more and I'm stumped. Fixing it for Unix is easy, but it breaks Windows paths, because those use their first element to store the drive name (c: d: etc) which shouldn't be preceded by a /. I'm starting to think the Absolute/Relative dichotomy is either wrong or incomplete and we

Re: [Pharo-dev] Path >> fullName should not be the same as printString

It's a breaking change and I don't know if there's a way to do it with proper deprecation… my hope is that there are not many users of it, but I haven't checked yet. Any opinions among users of FileSystem? On 8 October 2016 at 19:12, stepharo wrote: > So damien what is the

Re: [Pharo-dev] Path >> fullName should not be the same as printString

So damien what is the solution? Le 7/10/16 à 18:18, Damien Pollet a écrit : Path >> printString returns a self-evaluating representation, which is fine. Its symmetric is thus Compiler >> evaluate: aString. (Path from: aString) parses the unix/url representation of a path and results in a

[Pharo-dev] Path >> fullName should not be the same as printString

Path >> printString returns a self-evaluating representation, which is fine. Its symmetric is thus Compiler >> evaluate: aString. (Path from: aString) parses the unix/url representation of a path and results in a Path instance. As far as I understand, #fullName should be the symmetric of that, so