- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] About icon: and iconNamed:

by Denis Kudriashov

2016-10-14 16:06 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > yes, that was me providing a compatibility/traduction layer :) > you will find a couple more of them in the image. I call them > ânormalisation methodsâ: they are meant to translate names into something > we can interpretâ¦ there is also some like that in the menu building if I > remember well :P > And here idea to slowly remove ~Icon or ~Form suffix from icons names?

Oct. 14, 2016

Re: [Pharo-dev] About icon: and iconNamed:

by Esteban Lorenzano

yes, that was me providing a compatibility/traduction layer :) you will find a couple more of them in the image. I call them ânormalisation methodsâ: they are meant to translate names into something we can interpretâ¦ there is also some like that in the menu building if I remember well :P Esteban > On 14 Oct 2016, at 15:34, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Oh!!! I just found this method: > > iconNamed: aSymbol ifNone: aBlock > > self icons at: aSymbol asSymbol ifPresent: [ :icon | ^ icon ]. > "Trying the old way" > > ((aSymbol endsWith: 'Icon') or: [ (aSymbol endsWith: 'Form') ]) ifTrue: [ > self icons > at: (aSymbol allButLast: 4) asSymbol > ifPresent: [ :icon | ^ icon ] > ]. > > ^ aBlock value > > > > 2016-10-14 11:42 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: > > 2016-10-13 20:27 GMT+02:00 stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>>: > Denis > You can have a look the changes I did. There is more work to be done but I started. > https://pharo.fogbugz.com/f/cases/19201/iconNamed-part-4 <https://pharo.fogbugz.com/f/cases/19201/iconNamed-part-4> > Done. New slice committed >

Oct. 14, 2016

Re: [Pharo-dev] About icon: and iconNamed:

by Denis Kudriashov

Oh!!! I just found this method: iconNamed: aSymbol ifNone: aBlock self icons at: aSymbol asSymbol ifPresent: [ :icon | ^ icon ]. "Trying the old way" ((aSymbol endsWith: 'Icon') or: [ (aSymbol endsWith: 'Form') ]) ifTrue: [ self icons at: (aSymbol allButLast: 4) asSymbol ifPresent: [ :icon | ^ icon ] ]. ^ aBlock value 2016-10-14 11:42 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2016-10-13 20:27 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> Denis >> >> You can have a look the changes I did. There is more work to be done but >> I started. >> >> https://pharo.fogbugz.com/f/cases/19201/iconNamed-part-4 >> > > Done. New slice committed >

Oct. 14, 2016

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

by Damien Pollet

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 thing as Pharo. The semantics is that you follow the symlink first, and follow .. in the directory you end up in. So that goes to the parent of the actual directory pointed to by the symlink, not back one level in the path. On 14 October 2016 at 13:59, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > 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 exist. > > > On 14 Oct 2016, at 13:28, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > > > At least Chrome uses this: > > > > file:///C:/Users/tempfile.txt > > > > On Fri, Oct 14, 2016 at 1:45 AM, Martin McClure <martin(a)hand2mouse.com> > 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 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 might look something like > > > > file:/c:/foo/bar > > > > A relative URL that fits the URL syntax would be > > > > file:c:/foo/bar > > > > But I'm finding it difficult to tell precisely how RFCs 1738 and 3986 > currently interact. > > > > The discussion in this proposed RFC is somewhat interesting: > https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-02, as it > directly addresses Windows file naming. In appendix B.2, it says > > > > "When mapping a DOS- or Windows-like file path to a URI, use the drive > > letter (e.g. "c:") as the first path segment. Some implementations > leave the leading slash off before the drive letter. " > > > > and appendix C.1 deals with DOS file paths. > > > > > > I hope this is more helpful than it is confusing. > > > > Regards, > > > > -Martin > > > > > > > > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Oct. 14, 2016

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

by Sven Van Caekenberghe

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 exist. > On 14 Oct 2016, at 13:28, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > At least Chrome uses this: > > file:///C:/Users/tempfile.txt > > On Fri, Oct 14, 2016 at 1:45 AM, Martin McClure <martin(a)hand2mouse.com> 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 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 might look something like > > file:/c:/foo/bar > > A relative URL that fits the URL syntax would be > > file:c:/foo/bar > > But I'm finding it difficult to tell precisely how RFCs 1738 and 3986 currently interact. > > The discussion in this proposed RFC is somewhat interesting: https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-02, as it directly addresses Windows file naming. In appendix B.2, it says > > "When mapping a DOS- or Windows-like file path to a URI, use the drive > letter (e.g. "c:") as the first path segment. Some implementations leave the leading slash off before the drive letter. " > > and appendix C.1 deals with DOS file paths. > > > I hope this is more helpful than it is confusing. > > Regards, > > -Martin > > >

Oct. 14, 2016

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

by Gabriel Cotelli

At least Chrome uses this: file:///C:/Users/tempfile.txt On Fri, Oct 14, 2016 at 1:45 AM, Martin McClure <martin(a)hand2mouse.com> 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 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 might look something like > > file:/c:/foo/bar > > A relative URL that fits the URL syntax would be > > file:c:/foo/bar > > But I'm finding it difficult to tell precisely how RFCs 1738 and 3986 > currently interact. > > The discussion in this proposed RFC is somewhat interesting: > https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-02, as it > directly addresses Windows file naming. In appendix B.2, it says > > "When mapping a DOS- or Windows-like file path to a URI, use the drive > letter (e.g. "c:") as the first path segment. Some implementations > leave the leading slash off before the drive letter. " > > and appendix C.1 deals with DOS file paths. > > > I hope this is more helpful than it is confusing. > > Regards, > > -Martin > > >

Oct. 14, 2016

Re: [Pharo-dev] About icon: and iconNamed:

by Denis Kudriashov

2016-10-13 20:27 GMT+02:00 stepharo <stepharo(a)free.fr>: > Denis > > You can have a look the changes I did. There is more work to be done but I > started. > > https://pharo.fogbugz.com/f/cases/19201/iconNamed-part-4 > Done. New slice committed

Oct. 14, 2016

Re: [Pharo-dev] [ANN] New release of iceberg

by Nicolas Passerini

Hi HernÃ¡n, thank you for your report. It would be even nicer if you could report it at https://github.com/npasserini/iceberg/issues I think we might not be far from having Iceberg working on Pharo 5.0. Even we have our tests running on Pharo 6.0 and 5.0 in travis ( https://travis-ci.org/npasserini/iceberg) both for linux and mac. Sadly the tests do not cover the UI and that is why I missed the issue reported by HernÃ¡n. I do not know how hard could it be to have tests for that. But the real problem right now is to have everything running on Windows. That might take a while, maybe next month we will arrive there. On Fri, Oct 14, 2016 at 12:48 AM, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > > Ok. IMHO Nicolas if you really want more feedback I think it's worth it to > release it for 5.0, unless 6.0 has dramatically changed :) > Cheers, > > HernÃ¡n > > > 2016-10-13 14:02 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> in principle, Iceberg is meant to work on Pharo6+ >> No idea about backward compatibility (it shouldnât be so hard eitherâ¦) >> >> Esteban >> >> On 13 Oct 2016, at 19:00, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> >> wrote: >> >> Hi Nicolas, >> >> After installing it in Pharo 5.0 (#50761, Win 7) and clicking World Menu >> -> Tools -> Iceberg >> I got the Exception in the screenshot attached. >> >> >> 2016-10-13 9:25 GMT-03:00 Nicolas Passerini <npasserini(a)gmail.com>: >> >>> Hi, we are releasing a new version of Iceberg, with several new features >>> and bugfixes. I would't yet say that is 100% production ready, but it is >>> close, so I want to invite you to test it and provide feedback. >>> >>> You can install it by doing: >>> >>> Metacello new >>> baseline: 'Iceberg'; >>> repository: 'github://npasserini/iceberg'; >>> load. >>> >>> More installation instructions and documentation can be found at >>> https://github.com/npasserini/iceberg. >>> >>> Some of the new features in this version are: >>> - Allow to commit several packages together in the same commit. >>> - Show diffs for incoming and outgoing commits (i.e. before push/pull >>> you can browse the difference between the remote and the local versions). >>> - New History view allows to see any commit in any branch and compare it >>> to the current loaded version. >>> - Better support for interacting code loaded outside Iceberg >>> (smaltalkhub, filetree, gitfiletree, etc). >>> - From the diff view, revert changes or browse them (i.e. open a >>> Nautilus on the changed class/method). >>> - Automatically update presentations on code / repository changes. >>> - Integration with Metacello, i.e. after installing Iceberg you do >>> something like >>> >>> Metacello new >>> baseline: 'TaskIt'; >>> repository: 'github://sbragagnolo/taskit'; >>> load. >>> >>> >>> (By default) it will be loaded using iceberg (there is a setting to >>> avoid it if you prefer traditional behavior. >>> >>> - Improved handling of git errors. >>> - Improved performance for several operations. >>> - Improved documentation. >>> - ... and several bug fixes and other minor improvements (please look at >>> https://github.com/npasserini/iceberg/milestone/7?closed=1 for more >>> details). >>> >>> >>> Please do not hesitate to contact me if you have any doubts. >>> >> >> <IceberError.jpg> >> >> >> >

Oct. 14, 2016

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

by Martin McClure

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 might look something like file:/c:/foo/bar A relative URL that fits the URL syntax would be file:c:/foo/bar But I'm finding it difficult to tell precisely how RFCs 1738 and 3986 currently interact. The discussion in this proposed RFC is somewhat interesting: https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-02, as it directly addresses Windows file naming. In appendix B.2, it says "When mapping a DOS- or Windows-like file path to a URI, use the drive letter (e.g. "c:") as the first path segment. Some implementations leave the leading slash off before the drive letter. " and appendix C.1 deals with DOS file paths. I hope this is more helpful than it is confusing. Regards, -Martin

Oct. 14, 2016

Re: [Pharo-dev] [ANN] New release of iceberg

by HernÃ¡n Morales Durand

Ok. IMHO Nicolas if you really want more feedback I think it's worth it to release it for 5.0, unless 6.0 has dramatically changed :) Cheers, HernÃ¡n 2016-10-13 14:02 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > in principle, Iceberg is meant to work on Pharo6+ > No idea about backward compatibility (it shouldnât be so hard eitherâ¦) > > Esteban > > On 13 Oct 2016, at 19:00, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> > wrote: > > Hi Nicolas, > > After installing it in Pharo 5.0 (#50761, Win 7) and clicking World Menu > -> Tools -> Iceberg > I got the Exception in the screenshot attached. > > > 2016-10-13 9:25 GMT-03:00 Nicolas Passerini <npasserini(a)gmail.com>: > >> Hi, we are releasing a new version of Iceberg, with several new features >> and bugfixes. I would't yet say that is 100% production ready, but it is >> close, so I want to invite you to test it and provide feedback. >> >> You can install it by doing: >> >> Metacello new >> baseline: 'Iceberg'; >> repository: 'github://npasserini/iceberg'; >> load. >> >> More installation instructions and documentation can be found at >> https://github.com/npasserini/iceberg. >> >> Some of the new features in this version are: >> - Allow to commit several packages together in the same commit. >> - Show diffs for incoming and outgoing commits (i.e. before push/pull you >> can browse the difference between the remote and the local versions). >> - New History view allows to see any commit in any branch and compare it >> to the current loaded version. >> - Better support for interacting code loaded outside Iceberg >> (smaltalkhub, filetree, gitfiletree, etc). >> - From the diff view, revert changes or browse them (i.e. open a Nautilus >> on the changed class/method). >> - Automatically update presentations on code / repository changes. >> - Integration with Metacello, i.e. after installing Iceberg you do >> something like >> >> Metacello new >> baseline: 'TaskIt'; >> repository: 'github://sbragagnolo/taskit'; >> load. >> >> >> (By default) it will be loaded using iceberg (there is a setting to avoid >> it if you prefer traditional behavior. >> >> - Improved handling of git errors. >> - Improved performance for several operations. >> - Improved documentation. >> - ... and several bug fixes and other minor improvements (please look at >> https://github.com/npasserini/iceberg/milestone/7?closed=1 for more >> details). >> >> >> Please do not hesitate to contact me if you have any doubts. >> > > <IceberError.jpg> > > >

Oct. 13, 2016