October 2016 - Pharo-dev - lists.pharo.org

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

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

by Tudor Girba

Hi, > On Oct 13, 2016, at 2:16 PM, stepharo <stepharo(a)free.fr> wrote: > > >>> what if you want to have side by side two different themes to compare the best icons >>> choices? >> >> This is a valid concern, but I do not understand how this would work if the only thing you pass in iconName: is just one symbol: >> >> act: aBlock iconName: aSymbol entitled: aString >> >> So there needs to be a lookup. This lookup will depend on the current icon theme. So, you could open on window with one theme, switch the theme and then open another window. Or did I misunderstand something? > > The idea is that all the tools: should have an iconProvider and not a global lookup (even if the lookup can access a global) >> My idea was that we leave the public API of Glamour to be: >> >> act: aBlock icon: aSymbolOrForm entitled: aString >> >> and then if you want to play with things, you can also explicitly pass one icon or another (beside relying on the default lookup behavior). >> >> What do you think? > I would like to avoid clients to use Symbol >> asIcon it can be an internal implementation. I think I am missing something. If it is the concrete tool that should dispatch on the concrete icon set, then Glamour cannot get a symbol because Glamour does not know the tool. I am a bit under time pressure, and I likely need some days to look at this, but I will look at the code and get a better picture. Cheers, Doru >> >> Doru >> >>> >>>> >>>> In this way we do not have to change the external interface, and only the internal implementation has to send an âasIconâ before using it? >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> >>>>> On Oct 12, 2016, at 10:33 PM, stepharo <stepharo(a)free.fr> wrote: >>>>> >>>>> I'm adding >>>>> >>>>> act: aBlock iconName: aSymbol entitled: aString >>>>> self act: aBlock icon: (self iconNamed: aSymbol) entitled: aString >>>>> >>>>> and >>>>> >>>>> act: aBlock iconName: aSymbol on: aCharacter entitled: aString >>>>> self act: aBlock icon: (self iconNamed: aSymbol) on: aCharacter entitled: aString >>>>> >>>>> and others .... >>>>> >>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "Every thing has its own flow." >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "We are all great at making mistakes." >> >> >> >> >> >> >> >> > -- www.tudorgirba.com www.feenk.com "Every thing has its own flow."

Oct. 13, 2016

Re: [Pharo-dev] Shout style table editor (Request for Feedback)

by Nicolai Hess

Thanks for the feedback. I'll start first with adding some small enhancements to the styler (so it really uses all the existing style options) see : 19179 <https://pharo.fogbugz.com/f/cases/19179/Styler-does-not-support-all-style-t…> Styler does not support all style table tokens 2016-10-11 21:37 GMT+02:00 stepharo <stepharo(a)free.fr>: > > > Le 10/10/16 Ã 19:30, Sven Van Caekenberghe a Ã©crit : > >> Wow, that looks very nice ! >> > > + 10 > I want that :) > > > >> On 10 Oct 2016, at 18:42, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>> >>> I am working on a syntax style table editor, see issue for some >>> background about this. >>> 18322 Settings for Syntax Highlighting a bit confusing >>> 15409 A more complete set of syntactic colors is needed >>> >>> >>> Load package >>> >>> ST-StylingPreview >>> ST-StylingPreviewShoutExtension >>> >>> from >>> >>> MCHttpRepository >>> location: 'http://smalltalkhub.com/mc/Ni >>> colaiHess/StylerTableEditor/main' >>> user: '' >>> password: '' >>> >>> And open the preview/editor with: >>> >>> STStylerPreview open. >>> >>> This is a prototype, you can view builtin style tables, create and edit >>> new custom style tables. >>> This has some fake code styler methods to make the styling work for the >>> code preview pane, and it supports more styling attributes than the >>> default styler. >>> >>> This is what I would like to have as a syntax style setting dialog >>> instead of the current >>> confusing behavior. It may be helpful to actually see what syntax >>> styling attributs are >>> actually available. >>> >>> >>> <PharoScreenshot.3.png> >>> >> >> >> > >

Oct. 13, 2016

Re: [Pharo-dev] itemIcon: and Spotter

by Tudor Girba

Hi, Ok. I did not look at the changes yet. Could you give me a quick update: are base changes with iconNamed: integrated already? Doru > On Oct 13, 2016, at 2:51 PM, stepharo <stepharo(a)free.fr> wrote: > > Doru > > It would be nice to take some action here too. > > I would like to remove the Smalltalk ui icons iconNamed: > > spotterMonticelloWorkingCopyFor: aStep > <spotterOrder: 1> > aStep listProcessor > title: 'Monticello Working Copy'; > allCandidates: [ Array with: self workingCopy ]; > itemIcon: [ Smalltalk ui icons iconNamed: #versionControlIcon ]; > filter: GTFilterSubstring > > -- www.tudorgirba.com www.feenk.com "We are all great at making mistakes."

Oct. 13, 2016