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

Re: [Pharo-dev] Contributing to Pharo

by Ben Coman

On Sat, Jan 16, 2016 at 7:25 PM, David Allouche <david(a)allouche.net> wrote: > >> On 16 Jan 2016, at 12:14, stepharo <stepharo(a)free.fr> wrote: >> >> Le 16/1/16 09:59, David Allouche a Ã©crit : >>> >>> But, really, this "list of dirty packages" should really only list dirty packages. What is the use case for selecting a non-dirty package? >> >> because you never know >> Sometimes you save a package then you do a slice and you should be able to decide. > > That does not make sense to me. I guess it will, when I understand Monticello better. > > Its a very corner case. I've had to do it on occasion but I can't exactly remember the circumstance. Now what might be useful is a checkbox for displaying non-dirty packages - so we only display the short list in the usual case. (??) cheers -ben

Jan. 16, 2016

Re: [Pharo-dev] Growl setting name

by Ferlicot D. Cyril

Le 16/01/2016 09:18, Dimitris Chloupis a Ã©crit : > Personally I dont see the point of a rename, we got like 30% of people > coming from macos that will be familiar with the name Growl, 0% that > will be familiar with any other name. So you take a name that is very > popular and change it to something none knows, how is that an improvement ? > I don't want to rename Growl, just to change the name of the setting. The setting should not depend of the implementation of the notification system. We can name the setting "Notifier Popup" and behind use a GrowlMorph, a NotifierBloc, a PopupBrickâ¦ The common developer doesn't care. When we want to use a Growl we just call #inform:, not #growl: or "Growl new inform:". As you said 30% of people can understand what Growl is about. Almost everyone can understand that "Notifier Popup" is about a little popup that give us informations. Should we ignore the 70% of people that don't use mac ? And when Pharo will be use by more industry than search lab there will be less than 30% of mac I think. If the community don't want to rename this setting it's your choice, but that will be 70% of newcomers that will be frustrating when they will try to customize the appearance of there Pharo. > What notification morph, or notification popup even means ? Is it a > window ? is it a right click menu popup ? > > Only the time having to port everything to the new name does not make it > worth it. > > > -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Jan. 16, 2016

Re: [Pharo-dev] Growl setting name

by Ferlicot D. Cyril

Le 16/01/2016 09:12, stepharo a Ã©crit : > Finally > > "Growl is a global notification system and pop-up notification > implementation for the Mac OS X and Windows[1] operating systems. " > > So? > Growl can be downloaded on Windows but almost no Windows user know this name and can understand what it means. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Jan. 16, 2016

Re: [Pharo-dev] Color yzw

by Marcus Denker

> On 16 Jan 2016, at 13:26, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-01-16 10:11 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: > >>> anyone an idea? >>> >> I'm trying to think. >> Looks like it would be good to be able to make a distinction between symbols and selectors (selectors installed >> in method dictionaries) >> > > yes, this would improve code completion a bit, too, as there are more symbols than symbols that are actually names > of methods. > > The data could be created per environment (Smalltalk globals) the first time and then cached till shutdown. > (it would be an array of size 46451, pointing to existing symbols). > > The environment could cache sent selectors, tooâ¦ pablo did an experiment with that. > > Marcus > > > How about a new SymbolTable "SelectorTable" that gets new entries on every method compilation ? maybe better when a method is added to a Method Dictionary? This way even adding things the strange way would work... > > I hacked a simple experimental version. > But I don't yet understand the workflow for initialisation of the Symbol class (with rehash, interned, and compacting). > If we hook into adding methods, then compactSymbolTable and rehash could just reset the SelectorTable and fill it after by going over all methodsâ¦ Marcus

Jan. 16, 2016

Re: [Pharo-dev] Color yzw

by Nicolai Hess

2016-01-16 10:11 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > anyone an idea? > > I'm trying to think. > Looks like it would be good to be able to make a distinction between > symbols and selectors (selectors installed > in method dictionaries) > > > yes, this would improve code completion a bit, too, as there are more > symbols than symbols that are actually names > of methods. > > The data could be created per environment (Smalltalk globals) the first > time and then cached till shutdown. > (it would be an array of size 46451, pointing to existing symbols). > > The environment could cache sent selectors, tooâ¦ pablo did an experiment > with that. > > Marcus > > How about a new SymbolTable "SelectorTable" that gets new entries on every method compilation ? I hacked a simple experimental version. But I don't yet understand the workflow for initialisation of the Symbol class (with rehash, interned, and compacting).

Jan. 16, 2016

Re: [Pharo-dev] Color yzw

by Dimitris Chloupis

and so is auto completion ;) On Sat, Jan 16, 2016 at 1:03 PM stepharo <stepharo(a)free.fr> wrote: > How can we proceed? > Because this coloring functionality is really important. > > Stef > > > anyone an idea? > > I'm trying to think. > Looks like it would be good to be able to make a distinction between > symbols and selectors (selectors installed > in method dictionaries) > > > yes, this would improve code completion a bit, too, as there are more > symbols than symbols that are actually names > of methods. > > The data could be created per environment (Smalltalk globals) the first > time and then cached till shutdown. > (it would be an array of size 46451, pointing to existing symbols). > > The environment could cache sent selectors, tooâ¦ pablo did an experiment > with that. > > Marcus > > >

Jan. 16, 2016

Re: [Pharo-dev] Contributing to Pharo

by David Allouche

> On 16 Jan 2016, at 12:14, stepharo <stepharo(a)free.fr> wrote: > > Le 16/1/16 09:59, David Allouche a Ã©crit : >> >> But, really, this "list of dirty packages" should really only list dirty packages. What is the use case for selecting a non-dirty package? > > because you never know > Sometimes you save a package then you do a slice and you should be able to decide. That does not make sense to me. I guess it will, when I understand Monticello better.

Jan. 16, 2016

Re: [Pharo-dev] Contributing to Pharo

by David Allouche

> On 16 Jan 2016, at 12:12, stepharo <stepharo(a)free.fr> wrote: >>> On 16 Jan 2016, at 02:42, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> So if occasionally if everything seems against you, after trying a >>> fresh Image as you already did, slide back to the last build that >>> worked for you (I don't think the issues you experience are Spur >>> related, but 50496 might be a good fallback as Pre-Spur and >>> Pre-GTDebugger). Then create a fresh Image from the latest build to >>> test your Slice and in that time maybe the other issues have gone. >> Ok. So my earlier question (in Slack, I think) about how "unstable" is unstable in Pharo is now answered. It's really unstable, not "Debian-like unstable". > > No this is not really the case. In general we try hard to get alpha stable after you get some hiccups. > This is not every day that we change FFI, GC, object internal representations and the text editors, syntax highli > And our problems is that sometimes often we just jump over glitches (this is why I'm getting mad because when I do videos > or other I see them in my face). Now I would love to have task forces that check glitches. I get the picture now. I just checked in when the lobby, the roof and the plumbing of the hotel were undergoing renovations: it's not how it is usually. I could question whether it's a good idea to cram so much in a single release cycle. But release management is a difficult topic, and often there is no good solution, just one that has less downsides than the others. Cheers.

Jan. 16, 2016

Re: [Pharo-dev] Contributing to Pharo

by stepharo

Le 16/1/16 09:59, David Allouche a Ã©crit : >> On 16 Jan 2016, at 02:15, Ben Coman <btc(a)openinworld.com >> <mailto:btc@openinworld.com>> wrote: >> On Sat, Jan 16, 2016 at 3:45 AM, David Allouche<david(a)allouche.net >> <mailto:david@allouche.net>>wrote: >> >> 1. it shows a bunch of packages I have not touched >> 2. it does not show the package that contains my fix (Spec-Tools) >> >> >> I am curious on item 2. Was this just because the dirty package was >> sorted to the top of the list (per Nicolai's snapshots)? > > I think that was indeed the source of confusion. > > But, really, this "list of dirty packages" should really only list > dirty packages. What is the use case for selecting a non-dirty package? because you never know Sometimes you save a package then you do a slice and you should be able to decide. > >> I looked in the world menu, and I found this menu item called >> "Komitter". That sounded like a good candidate. >> >> >> I see how the term "Commit" is misleading here without context. >> Probably "Press the <Save> button to commit your slice to the inbox >> repository" would probably be better. > > Yes, that would help, too. > >> https://pharo.fogbugz.com/default.asp?17398 > > Cool! >

Jan. 16, 2016

Re: [Pharo-dev] Contributing to Pharo

by stepharo

Hi david >> On 16 Jan 2016, at 02:42, Ben Coman <btc(a)openinworld.com> wrote: >> >> So if occasionally if everything seems against you, after trying a >> fresh Image as you already did, slide back to the last build that >> worked for you (I don't think the issues you experience are Spur >> related, but 50496 might be a good fallback as Pre-Spur and >> Pre-GTDebugger). Then create a fresh Image from the latest build to >> test your Slice and in that time maybe the other issues have gone. > Ok. So my earlier question (in Slack, I think) about how "unstable" is unstable in Pharo is now answered. It's really unstable, not "Debian-like unstable". No this is not really the case. In general we try hard to get alpha stable after you get some hiccups. This is not every day that we change FFI, GC, object internal representations and the text editors, syntax highli And our problems is that sometimes often we just jump over glitches (this is why I'm getting mad because when I do videos or other I see them in my face). Now I would love to have task forces that check glitches. > > It would also be nice to add some public info about that. I'll create an issue. > > At the moment, I am stuck with GTDebugger, because it seems the old debugger does not have any keyboard shortcut form stepping through code. And that's something I would really really miss. So I'll suffer the pain of all the other glitches, and see how that goes. >

Jan. 16, 2016