September 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Author name in version Iceberg?

by Pavel Krivanek

Iceberg currently uses metadata-less format that does not store method timestamp because of the merging conflicts. You cannot do anything now, sorry. -- Pavel 2017-09-14 9:23 GMT+02:00 stephan <stephan(a)stack.nl>: > What is needed to make sure the author/committer name is shown in a method > version instead of 'GitHub' when using Iceberg? > > Stephan > > >

Sept. 14, 2017

Re: [Pharo-dev] Directory structure on files.pharo.org

by Guillermo Polito

On Thu, Sep 14, 2017 at 9:36 AM, stephan <stephan(a)stack.nl> wrote: > On 11-09-17 11:18, Guillermo Polito wrote: > >> >> On Mon, Sep 11, 2017 at 10:55 AM, stephan <stephan(a)stack.nl <mailto: >> stephan(a)stack.nl>> wrote: >> >> This looks like it is missing directories. >> On the other hand, perhaps exposing the build steps as directories >> might not be the best idea, as that is unlikely to remain stable. >> http://files.pharo.org/image/70/ <http://files.pharo.org/image/70/> >> >> >> Yeh, also so far people will use mostly the latest minimal and full >> images. All intermediate steps are stored just because we can. >> >> But if you have some idea/proposal on how to enhance it, we could do it >> > > Indeed, I also assume most people will be looking for either the minimal > or the full image, in either 32 or 64 bit. Would it be better to add a > subdirectory for the (intermediary) build steps? What and where we upload is in here: https://github.com/pharo-project/pharo/blob/development/bootstrap/scripts/u… > > > Stephan > > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Sept. 14, 2017

Re: [Pharo-dev] Directory structure on files.pharo.org

by stephan

On 11-09-17 11:18, Guillermo Polito wrote: > > On Mon, Sep 11, 2017 at 10:55 AM, stephan > <stephan(a)stack.nl > <mailto:stephan@stack.nl>> wrote: > > This looks like it is missing directories. > On the other hand, perhaps exposing the build steps as directories > might not be the best idea, as that is unlikely to remain stable. > http://files.pharo.org/image/70/ <http://files.pharo.org/image/70/> > > > Yeh, also so far people will use mostly the latest minimal and full > images. All intermediate steps are stored just because we can. > > But if you have some idea/proposal on how to enhance it, we could do it Indeed, I also assume most people will be looking for either the minimal or the full image, in either 32 or 64 bit. Would it be better to add a subdirectory for the (intermediary) build steps? Stephan

Sept. 14, 2017

Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

by H. Hirzel

+1 for pinInMemory It explains what it does. On 9/14/17, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Norbert, > >> On Sep 13, 2017, at 3:18 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> >>> Am 14.09.2017 um 00:09 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: >>> >>> Hi Denis, >>> >>> On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >>> wrote: >>>> Hi Eliot. >>>> >>>> I know and I only talk about new messages. I am not trying to rethink >>>> full meta model of Smalltalk. >>>> By the way #class is very common message and it is handy to use short >>>> name. But pinning messages will be used rarely in very specific >>>> applications. So no much sense to preserve them in short version. >>> >>> Agreed. So we have to decide whether to go with pinInMemory or >>> pinObject, pinObject being suggested by Norbert because it matched >>> isReadOnlyObject. Personally I like pinInMemory. Norbert, do you feel >>> strongly about pinObject et al? >>> >> No I don't. It feels only good to me if there is a requirement not to >> implement selectors that are likely to be used in user code. I'm ok with >> pinInMemory although I asked myself where can it be pinned elsewhere if >> not in memory. So the suffix in memory doesn't add anything but also moves >> the selector out of user space. > > Well I think Denis' point is that pinInMemory removes ambiguity with pin for > other uses and I agree. So I for one am happy to change it to pinInMemory > et al. > >> >> Norbert >> >>>> >>>> 2017-09-12 18:05 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>>>> Hi Denis, >>>>> >>>>> >>>>>> On Sep 12, 2017, at 2:39 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >>>>>> wrote: >>>>>> >>>>>> I am really wonder guys. I thought you are not big funs of Object >>>>>> protocol. >>>>>> Current pinning messages are a new set of very generic messages in the >>>>>> Object. >>>>> >>>>> Yes, and that's because this is a fundamental property of all >>>>> non-immediate objects. Do you object to the #class message? Should it >>>>> be #classObject because it might conflict with #class used in an >>>>> educational or socioeconomic model? All objects other than immediates >>>>> can move. Pinning stops that movement. It applies generally. So the >>>>> protocol belongs in Object. >>>>> >>>>> >>>>>> >>>>>> About Norbert idea. >>>>>> - bePinnedObject is not bad convention. But I would prefer the memory >>>>>> suffix because it reflects the low level behaviour. >>>>>> >>>>>> 2017-09-11 14:16 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>>>>> yes, me :) >>>>>>> >>>>>>> I do not see a reason to change them, tbh. >>>>>>> for me they are comprensible as they are now and it does not adds >>>>>>> more information pinInMemory or pinMemory. >>>>>>> >>>>>>> Esteban >>>>>>> >>>>>>> >>>>>>>> On 11 Sep 2017, at 11:56, Denis Kudriashov <dionisiydk(a)gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Anybody else? >>>>>>>> >>>>>>>> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek >>>>>>>> <pavel.krivanek(a)gmail.com>: >>>>>>>>> >>>>>>>>> >>>>>>>>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov >>>>>>>>> <dionisiydk(a)gmail.com>: >>>>>>>>>> Hi. >>>>>>>>>> >>>>>>>>>> We now have very generic message names: >>>>>>>>>> - pin >>>>>>>>>> - unpin >>>>>>>>>> - setPinned: >>>>>>>>>> - isPinned >>>>>>>>>> >>>>>>>>>> Problem that they collide with possible domain related names. >>>>>>>>>> For example I implemented pinning of tabs in Calypso and I found >>>>>>>>>> that I overrides #pin and #isPinned messages. Then I fix it with >>>>>>>>>> different names. >>>>>>>>>> Probably menus also uses pin word but without overrides >>>>>>>>>> >>>>>>>>>> What you think about renaming pinning messages? Something like: >>>>>>>>>> - pinMemory >>>>>>>>> >>>>>>>>> I would use pinInMemory >>>>>>>>> >>>>>>>>> -- Pavel >>>>>>>>> >>>>>>>>>> - unpinMemory >>>>>>>>>> - isMemoryPinned >>>>>>>>>> - setPinnedMemory: >>>>>>>>>> - pinMemoryDuring: (if we will introduce it) >>>>>>>>>> >>>>>>>>>> I think it is easy to do now because not much code uses pinning >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>> >>> >>> >>> -- >>> _,,,^..^,,,_ >>> best, Eliot >> >

Sept. 14, 2017

Re: [Pharo-dev] [Calypso] Toolbar and Statusbar Look - voting time

by Denis Kudriashov

Thank's guys for comments. And thank's Torsten for this initiative. I will merge your changes soon. 2017-09-14 7:09 GMT+02:00 Max Leske <maxleske(a)gmail.com>: > Right > > > On 13 September 2017 at 18:08:26, Torsten Bergmann (astares(a)gmx.de) wrote: > > Hi all, > > as you know Denis Kudriashov does a fantastic job in implementing the new > Calypso system browser. > The plan is that at some point in time will be a replacement for Nautilus > in the standard image. > Even if not yet integrated one can already use it (either by loading from > catalog or github [1]) > > For me the more I use it (and get used to it) the more I like Calypso and > I guess others enjoy it too already. > > But unfortunately there is a single but very prominently visible UI thing > that I dislike on the current look: > > For the "Pharo3Theme" (light theme) the current implementation of Calypso > has a white toolbar in the > middle and a white status bar at the bottom. Technically Dennis sets the > colors of these morphs to > transparent to have this effect (see LEFT example of the attached > screenshot) > > > To me this lookes strange and unusual because > - usually (on Windows, GTK, Java Swing, Linux window managers) such areas > like a status bar follow the window color > and are displayed in gray when that is the default window theme color (see > [2], [3], [4]) > - these white bars would better fit for the "Glamorous Whitespace" theme > (as this theme is already more white areas) > > Also the current white bars do not make a pleasant contrast to the other > panes of Calypso: > - there is not really a visual distinction to the > package/class/protocol-tag/method panes and filters for the middle part > (toolbar) > - there is not really a visual distinction from the code pane for the > bottom part (statusbar) > - the divider line in the code pane just stops in a white area without > borders > > To me this looks rather ugly and I would like Pharo to look more > professional and clean ;) > > So I proposed a simple PR [5] today to change this and technically using > the window color of the theme - the result can be > seen on the right side of the attached screenshot and discussed with Denis > on Discord. > > Denis on the other hand still likes the white approach on the left more > while I prefer the right one. > > He wrote that he wants other people comment on this issue first to which I > agree and therefore I write this mail > to discuss it here on the dev-list and find out about what the majority in > the community prefers. > > So it would be good if others could > - comment about their personal preference > - or just vote with "LEFT" (white/transparent) or "RIGHT" (window color) > in reply to this mail > - or make another proposal (which is only accepted with screenshot and PR > ;) > > Also please do not mix other UI discussions into this thread. Thanks in > advance! > > Bye > T. > > [1] https://github.com/dionisiydk/Calypso > [2] http://cdn.osxdaily.com/wp-content/uploads/2011/08/show- > status-bar-and-disk-space-lion.jpg > [3] http://i.stack.imgur.com/pgt5n.png > [4] http://python.zirael.org/gtk-statusbar1-1.png > [5] https://github.com/dionisiydk/Calypso/pull/91 > >

Sept. 14, 2017

Author name in version Iceberg?

by stephan

What is needed to make sure the author/committer name is shown in a method version instead of 'GitHub' when using Iceberg? Stephan

Sept. 14, 2017

Re: [Pharo-dev] Bintray for Pharo7 images?

by Guillermo Polito

On Thu, Sep 14, 2017 at 8:56 AM, Holger Freyther <holger(a)freyther.de> wrote: > Hey, > > I keep on clicking on the "bintray" badges to get to a recent Pharo7 image > but after looking at the Jenkinsfile I don't see the script being invoked > and given the timestamp of "201706...." it seems no images were uploaded > for a while? Should we remove the bintray badge or upload them again? > True. We are now uploading to the file server in files.pharo.org > > Would there be any objection to link to http://files.pharo.org/get- > files/70/pharo.zip from the README.md to get the latest > image/sources/changes? > No objections. On the contrary :) > > > cheers > holger > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Sept. 14, 2017

Bintray for Pharo7 images?

by Holger Freyther

Hey, I keep on clicking on the "bintray" badges to get to a recent Pharo7 image but after looking at the Jenkinsfile I don't see the script being invoked and given the timestamp of "201706...." it seems no images were uploaded for a while? Should we remove the bintray badge or upload them again? Would there be any objection to link to http://files.pharo.org/get-files/70/pharo.zip from the README.md to get the latest image/sources/changes? cheers holger

Sept. 14, 2017

Re: [Pharo-dev] [Calypso] Toolbar and Statusbar Look - voting time

by Max Leske

Right On 13 September 2017 at 18:08:26, Torsten Bergmann (astares(a)gmx.de) wrote: Hi all, as you know Denis Kudriashov does a fantastic job in implementing the new Calypso system browser. The plan is that at some point in time will be a replacement for Nautilus in the standard image. Even if not yet integrated one can already use it (either by loading from catalog or github [1]) For me the more I use it (and get used to it) the more I like Calypso and I guess others enjoy it too already. But unfortunately there is a single but very prominently visible UI thing that I dislike on the current look: For the "Pharo3Theme" (light theme) the current implementation of Calypso has a white toolbar in the middle and a white status bar at the bottom. Technically Dennis sets the colors of these morphs to transparent to have this effect (see LEFT example of the attached screenshot) To me this lookes strange and unusual because - usually (on Windows, GTK, Java Swing, Linux window managers) such areas like a status bar follow the window color and are displayed in gray when that is the default window theme color (see [2], [3], [4]) - these white bars would better fit for the "Glamorous Whitespace" theme (as this theme is already more white areas) Also the current white bars do not make a pleasant contrast to the other panes of Calypso: - there is not really a visual distinction to the package/class/protocol-tag/method panes and filters for the middle part (toolbar) - there is not really a visual distinction from the code pane for the bottom part (statusbar) - the divider line in the code pane just stops in a white area without borders To me this looks rather ugly and I would like Pharo to look more professional and clean ;) So I proposed a simple PR [5] today to change this and technically using the window color of the theme - the result can be seen on the right side of the attached screenshot and discussed with Denis on Discord. Denis on the other hand still likes the white approach on the left more while I prefer the right one. He wrote that he wants other people comment on this issue first to which I agree and therefore I write this mail to discuss it here on the dev-list and find out about what the majority in the community prefers. So it would be good if others could - comment about their personal preference - or just vote with "LEFT" (white/transparent) or "RIGHT" (window color) in reply to this mail - or make another proposal (which is only accepted with screenshot and PR ;) Also please do not mix other UI discussions into this thread. Thanks in advance! Bye T. [1] https://github.com/dionisiydk/Calypso [2] http://cdn.osxdaily.com/wp-content/uploads/2011/08/show-status-bar-and-disk… [3] http://i.stack.imgur.com/pgt5n.png [4] http://python.zirael.org/gtk-statusbar1-1.png [5] https://github.com/dionisiydk/Calypso/pull/91

Sept. 14, 2017

Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

by Eliot Miranda

Hi Norbert, > On Sep 13, 2017, at 3:18 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > > >> Am 14.09.2017 um 00:09 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: >> >> Hi Denis, >> >> On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>> Hi Eliot. >>> >>> I know and I only talk about new messages. I am not trying to rethink full meta model of Smalltalk. >>> By the way #class is very common message and it is handy to use short name. But pinning messages will be used rarely in very specific applications. So no much sense to preserve them in short version. >> >> Agreed. So we have to decide whether to go with pinInMemory or pinObject, pinObject being suggested by Norbert because it matched isReadOnlyObject. Personally I like pinInMemory. Norbert, do you feel strongly about pinObject et al? >> > No I don't. It feels only good to me if there is a requirement not to implement selectors that are likely to be used in user code. I'm ok with pinInMemory although I asked myself where can it be pinned elsewhere if not in memory. So the suffix in memory doesn't add anything but also moves the selector out of user space. Well I think Denis' point is that pinInMemory removes ambiguity with pin for other uses and I agree. So I for one am happy to change it to pinInMemory et al. > > Norbert > >>> >>> 2017-09-12 18:05 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>>> Hi Denis, >>>> >>>> >>>>> On Sep 12, 2017, at 2:39 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>>>> >>>>> I am really wonder guys. I thought you are not big funs of Object protocol. >>>>> Current pinning messages are a new set of very generic messages in the Object. >>>> >>>> Yes, and that's because this is a fundamental property of all non-immediate objects. Do you object to the #class message? Should it be #classObject because it might conflict with #class used in an educational or socioeconomic model? All objects other than immediates can move. Pinning stops that movement. It applies generally. So the protocol belongs in Object. >>>> >>>> >>>>> >>>>> About Norbert idea. >>>>> - bePinnedObject is not bad convention. But I would prefer the memory suffix because it reflects the low level behaviour. >>>>> >>>>> 2017-09-11 14:16 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>>>> yes, me :) >>>>>> >>>>>> I do not see a reason to change them, tbh. >>>>>> for me they are comprensible as they are now and it does not adds more information pinInMemory or pinMemory. >>>>>> >>>>>> Esteban >>>>>> >>>>>> >>>>>>> On 11 Sep 2017, at 11:56, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>>>>>> >>>>>>> Anybody else? >>>>>>> >>>>>>> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>>>>>>> >>>>>>>> >>>>>>>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>>>>>>>> Hi. >>>>>>>>> >>>>>>>>> We now have very generic message names: >>>>>>>>> - pin >>>>>>>>> - unpin >>>>>>>>> - setPinned: >>>>>>>>> - isPinned >>>>>>>>> >>>>>>>>> Problem that they collide with possible domain related names. >>>>>>>>> For example I implemented pinning of tabs in Calypso and I found that I overrides #pin and #isPinned messages. Then I fix it with different names. >>>>>>>>> Probably menus also uses pin word but without overrides >>>>>>>>> >>>>>>>>> What you think about renaming pinning messages? Something like: >>>>>>>>> - pinMemory >>>>>>>> >>>>>>>> I would use pinInMemory >>>>>>>> >>>>>>>> -- Pavel >>>>>>>> >>>>>>>>> - unpinMemory >>>>>>>>> - isMemoryPinned >>>>>>>>> - setPinnedMemory: >>>>>>>>> - pinMemoryDuring: (if we will introduce it) >>>>>>>>> >>>>>>>>> I think it is easy to do now because not much code uses pinning >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot >

Sept. 13, 2017