- Pharo-dev - lists.pharo.org

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

by Esteban Lorenzano

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 <mailto:npasserini@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 <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 <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] [ANN] New release of iceberg

by HernÃ¡n Morales Durand

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. >

Oct. 13, 2016

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

by Ben Coman

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 <damien.pollet(a)gmail.com> wrote: > 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 need windows-specific subclasses. Doesn't it feel strange > that we can pass strings with different syntax and assumptions to Path > class >> from: and get instances from the same classes? > > On 8 October 2016 at 19:21, Damien Pollet <damien.pollet(a)gmail.com> wrote: > >> 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 <stepharo(a)free.fr> wrote: >> >>> 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 Path instance. As far as I understand, #fullName should be the >>> symmetric of that, so that we always have (modulo syntactic normalization, >>> maybe) : >>> >>> (Path from: aString) fullName = aString >>> >>> Note that there's an edge case with the empty string that is wrong (at >>> least it should be confusing to unix guys): >>> >>> Path from: ''. "Path root" >>> >>> Usually the absolute path for the root of the filesystem is explicitly >>> noted '/', and an empty path is equivalent to '.' >>> >>> -- >>> Damien Pollet >>> type less, do more [ | ] http://people.untyped.org/damien.pollet >>> >>> >>> >> >> >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet >> > > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet >

Oct. 13, 2016

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

by Damien Pollet

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 need windows-specific subclasses. Doesn't it feel strange that we can pass strings with different syntax and assumptions to Path class >> from: and get instances from the same classes? On 8 October 2016 at 19:21, Damien Pollet <damien.pollet(a)gmail.com> wrote: > 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 <stepharo(a)free.fr> wrote: > >> 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 Path instance. As far as I understand, #fullName should be the >> symmetric of that, so that we always have (modulo syntactic normalization, >> maybe) : >> >> (Path from: aString) fullName = aString >> >> Note that there's an edge case with the empty string that is wrong (at >> least it should be confusing to unix guys): >> >> Path from: ''. "Path root" >> >> Usually the absolute path for the root of the filesystem is explicitly >> noted '/', and an empty path is equivalent to '.' >> >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet >> >> >> > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Oct. 13, 2016

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

by Denis Kudriashov

2016-10-13 17:19 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > Is most of that expense come from passing the same Form over a link > multiple times? I vaguely wonder if content-addressable caching would help > there. You see: current state requires such kind of tricks. But if users always work with icon names it will not the case completely. > But anyway, wouldn't a remote browser work at a higher level that being a > remote UI? and the user want to use their local theme rather than that > from the remote image? I want to do it like this. But now classes define concrete form which should be used in UI. I would call it "no late binding for icons".

Oct. 13, 2016

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

by Ben Coman

On Thu, Oct 13, 2016 at 10:00 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Also look at #systemIcon method which define icon of class in browser. > All implementors dublicate "Smalltalk ui icons iconNamed: #myIconName". > > Should we change it to #systemIconName? > > Also think about remote browser which also wants to show icons over > classes. With icon name it is not problem to transfer it together with > class. With Form it is of course much expensive. > Is most of that expense come from passing the same Form over a link multiple times? I vaguely wonder if content-addressable caching would help there. But anyway, wouldn't a remote browser work at a higher level that being a remote UI? and the user want to use their local theme rather than that from the remote image? cheers -ben > > > 2016-10-13 14:45 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> So I'm trying to think ;) >> >> menuOn: aBuilder >> "Specify the menu used when writing text." >> <contextMenu> >> <RubLineNumberMenu> >> (aBuilder item: #'Find...' translated) >> keyText: 'f'; >> selector: #find; >> icon: (Smalltalk ui icons iconNamed: #smallFindIcon) >> >> ====> >> >> menuOn: aBuilder >> "Specify the menu used when writing text." >> <contextMenu> >> <RubLineNumberMenu> >> (aBuilder item: #'Find...' translated) >> keyText: 'f'; >> selector: #find; >> icon: #smallFindIcon >> >> Now I do not really like to have a symbol or an icon. >> >> icon: aSymbol >> >> aSymbol asIcon but we could have the provider >> >> So for now I will finish the effort. >> >> have >> >> icon: anIcon and >> >> iconNamed: >> >> >> Stef >> >> On Oct 13, 2016, at 1:03 PM, stepharo <stepharo(a)free.fr> wrote: >> >> >> Thanks! >> >> Just a question: How about adding an extension >> >> Symbol>>asIcon >> ^ â¦ look up the icon >> >> Form>>asIcon >> ^ self >> >> >> 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? >> >> 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? >> >> 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 .... >> >>

Oct. 13, 2016

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

by Denis Kudriashov

Also look at #systemIcon method which define icon of class in browser. All implementors dublicate "Smalltalk ui icons iconNamed: #myIconName". Should we change it to #systemIconName? Also think about remote browser which also wants to show icons over classes. With icon name it is not problem to transfer it together with class. With Form it is of course much expensive. 2016-10-13 14:45 GMT+02:00 stepharo <stepharo(a)free.fr>: > So I'm trying to think ;) > > menuOn: aBuilder > "Specify the menu used when writing text." > <contextMenu> > <RubLineNumberMenu> > (aBuilder item: #'Find...' translated) > keyText: 'f'; > selector: #find; > icon: (Smalltalk ui icons iconNamed: #smallFindIcon) > > ====> > > menuOn: aBuilder > "Specify the menu used when writing text." > <contextMenu> > <RubLineNumberMenu> > (aBuilder item: #'Find...' translated) > keyText: 'f'; > selector: #find; > icon: #smallFindIcon > > Now I do not really like to have a symbol or an icon. > > icon: aSymbol > > aSymbol asIcon but we could have the provider > > So for now I will finish the effort. > > have > > icon: anIcon and > > iconNamed: > > > Stef > > On Oct 13, 2016, at 1:03 PM, stepharo <stepharo(a)free.fr> wrote: > > > Thanks! > > Just a question: How about adding an extension > > Symbol>>asIcon > ^ â¦ look up the icon > > Form>>asIcon > ^ self > > > 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? > > 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? > > 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." > > > > > > > > > >

Oct. 13, 2016

itemIcon: and Spotter

by stepharo

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

Oct. 13, 2016

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

by stepharo

So I'm trying to think ;) menuOn: aBuilder "Specify the menu used when writing text." <contextMenu> <RubLineNumberMenu> (aBuilder item: #'Find...' translated) keyText: 'f'; selector: #find; icon: (Smalltalk ui icons iconNamed: #smallFindIcon) ====> menuOn: aBuilder "Specify the menu used when writing text." <contextMenu> <RubLineNumberMenu> (aBuilder item: #'Find...' translated) keyText: 'f'; selector: #find; icon: #smallFindIcon Now I do not really like to have a symbol or an icon. icon: aSymbol aSymbol asIcon but we could have the provider So for now I will finish the effort. have icon: anIcon and iconNamed: Stef >> On Oct 13, 2016, at 1:03 PM, stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> wrote: >> >> >>> Thanks! >>> >>> Just a question: How about adding an extension >>> >>> Symbol>>asIcon >>> ^ â¦ look up the icon >>> >>> Form>>asIcon >>> ^ self >> >> 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? > > 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? > > 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 >>>> <mailto:stepharo@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 <http://www.tudorgirba.com> >>> www.feenk.com >>> >>> "Every thing has its own flow." >>> >>> >>> >>> >>> >>> >>> >> >> > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > www.feenk.com > > "We are all great at making mistakes." > > > > > > > >

Oct. 13, 2016

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

by stepharo

So I'm trying to think menuOn: aBuilder "Specify the menu used when writing text." <contextMenu> <RubLineNumberMenu> (aBuilder item: #'Find...' translated) keyText: 'f'; selector: #find; icon: (Smalltalk ui icons iconNamed: #smallFindIcon) ====> menuOn: aBuilder "Specify the menu used when writing text." <contextMenu> <RubLineNumberMenu> (aBuilder item: #'Find...' translated) keyText: 'f'; selector: #find; icon: #smallFindIcon Now I do not really like to pass a symbol. icon: aSymbol aSymbol asIcon But we cannot plug a provider So for now I would like to continue Stef >> 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? > > 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? > > 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 >>>> <mailto:stepharo@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 <http://www.tudorgirba.com> >>> www.feenk.com >>> >>> "Every thing has its own flow." >>> >>> >>> >>> >>> >>> >>> >> >> > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > www.feenk.com > > "We are all great at making mistakes." > > > > > > > >

Oct. 13, 2016