April 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Spec] whenSelectedItemsChanged: on TreeModel

by phil＠highoctane.be

I made a plugin to spy on the NaytimusAnnouncer and in fact there is a storm of announcements flying around all the time. And they do not carry the expected payload ( nil instead of the method for example) The plugin is in Smalltallhub in philippeback , HOExtras I'll do a screencast to show you. Phil Le 2 avr. 2014 13:30, "Martin Dias" <tinchodias(a)gmail.com> a Ã©crit : > Hi, > > I still can reproduce this issue in Pharo 30807 (last image). I'm trying > to workaround it with some problems. > > I ignore if this is already reported in fogbugs. Steps to reproduce: > > a) do it: > > TreeModel new > roots: (1 to: 2); > whenSelectedItemsChanged: [ :items | self logCr: items ]; > openWithSpec. > > > => in Transcript I see: > > b) during initial do it: > > #() > > c) after a click on 2: > > #() > an OrderedCollection(2) > > d) after a click on 1: > > an OrderedCollection(2) > an OrderedCollection(2) > an OrderedCollection(1) > > > Cheers, > MArtÃn > > > > On Wed, Dec 11, 2013 at 6:10 PM, Benjamin < > Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > >> As I said to Martin, I will investigate why, but it's a bit tricky >> Must be some issue in MorphTreeMorph I introduced recently >> >> Ben >> >> On 11 Dec 2013, at 16:46, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: >> >> Hi, >> >> I am experiencing problems with #whenSelectedItemsChanged: on a TreeModel. >> >> In particular, the block (i.e., argument of #whenSelectedItemsChanged: >> gets randomly executed a couple of times (3/4) the second time that the >> selection happens. The first time is fine. It looks like the registration >> of the "event" or "announcement" is done multiple times. >> >> Any hint? >> >> Cheers, >> R >> >> >> >

April 2, 2014

Re: [Pharo-dev] [Inspiration] Toward a better programming

by phil＠highoctane.be

Yes, RB would immensely benefit from some doc. See other thread on that. I will start something pnce I get it wotking for my case. Phil Le 2 avr. 2014 13:30, "Goubier Thierry" <thierry.goubier(a)cea.fr> a Ã©crit : > > > Le 02/04/2014 08:12, Tudor Girba a Ã©crit : > >> The language itself is less interesting for me, but what makes it stand >> out is that it has a coherent and robust philosophy behind and >> phenomenal goals to reach. In Pharo, we have the luxury of building on >> top of coherent and robust philosophy (even if different from the >> Wolfram one) and we should try as much as possible to keep our eyes on >> phenomenal goals that seem unreachable. >> > > I see two barriers in the current Pharo to be able to reach that: > > - Lack of clear documentation of the underlying code management structure > and facilities. It takes ages to get into the gritty details of things like > RPackage and the refactory framework, documentation is very often limited > to "this is the way Nautilus does it", and "no worry about changing it, > Nautilus developpers are the same guy" which ends up being very painful for > someone outside that core group. > > - GUI conservatism. The choice made in Pharo in the overall look is to be > conservative and business-like, and so blame the too-advanced, too-fancy > Morphic (and at the same time have Roassal pushing the enveloppe, but > outside the normal toolkit :) which means someone would find it probably > hard to do Roassal-based development tools). Glamour, Spec and GTToolkit > are interesting to look at along that "conservatism" in GUI. > > Another thing I like in Wolfram's work is attention to details: >> http://blog.wolfram.com/2008/01/10/ten-thousand-hours-of-design-reviews/ >> >> Details are crucial, and all the effort in Pharo around naming and >> redesigning what already exists is incredibly important. But, it is >> precisely at the moment when we are knee-deep in details that is crucial >> to keep our eyes on the phenomenal long term goals. >> > > I'm less convinced by that. Refining, trying, fiddling, spending hundreds > of iterations on making drag and drop or scrolling perfect, yes. > Redesigning whole chunks of the low-level facilities without really seeing > where we will end up, at at the same time presenting a very conservative > view on top of it, not much. > > For example, I know of a GTInspector use case which is entirely justified > by deficiencies in the standard system browser ;) > > There is so much to build. Let's be bold. >> > > +100 > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > >

April 2, 2014

Re: [Pharo-dev] [Inspiration] Toward a better programming

by Goubier Thierry

Le 02/04/2014 08:12, Tudor Girba a Ã©crit : > The language itself is less interesting for me, but what makes it stand > out is that it has a coherent and robust philosophy behind and > phenomenal goals to reach. In Pharo, we have the luxury of building on > top of coherent and robust philosophy (even if different from the > Wolfram one) and we should try as much as possible to keep our eyes on > phenomenal goals that seem unreachable. I see two barriers in the current Pharo to be able to reach that: - Lack of clear documentation of the underlying code management structure and facilities. It takes ages to get into the gritty details of things like RPackage and the refactory framework, documentation is very often limited to "this is the way Nautilus does it", and "no worry about changing it, Nautilus developpers are the same guy" which ends up being very painful for someone outside that core group. - GUI conservatism. The choice made in Pharo in the overall look is to be conservative and business-like, and so blame the too-advanced, too-fancy Morphic (and at the same time have Roassal pushing the enveloppe, but outside the normal toolkit :) which means someone would find it probably hard to do Roassal-based development tools). Glamour, Spec and GTToolkit are interesting to look at along that "conservatism" in GUI. > Another thing I like in Wolfram's work is attention to details: > http://blog.wolfram.com/2008/01/10/ten-thousand-hours-of-design-reviews/ > > Details are crucial, and all the effort in Pharo around naming and > redesigning what already exists is incredibly important. But, it is > precisely at the moment when we are knee-deep in details that is crucial > to keep our eyes on the phenomenal long term goals. I'm less convinced by that. Refining, trying, fiddling, spending hundreds of iterations on making drag and drop or scrolling perfect, yes. Redesigning whole chunks of the low-level facilities without really seeing where we will end up, at at the same time presenting a very conservative view on top of it, not much. For example, I know of a GTInspector use case which is entirely justified by deficiencies in the standard system browser ;) > There is so much to build. Let's be bold. +100 Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

April 2, 2014

Re: [Pharo-dev] [Spec] whenSelectedItemsChanged: on TreeModel

by Martin Dias

Hi, I still can reproduce this issue in Pharo 30807 (last image). I'm trying to workaround it with some problems. I ignore if this is already reported in fogbugs. Steps to reproduce: a) do it: TreeModel new roots: (1 to: 2); whenSelectedItemsChanged: [ :items | self logCr: items ]; openWithSpec. => in Transcript I see: b) during initial do it: #() c) after a click on 2: #() an OrderedCollection(2) d) after a click on 1: an OrderedCollection(2) an OrderedCollection(2) an OrderedCollection(1) Cheers, MArtÃn On Wed, Dec 11, 2013 at 6:10 PM, Benjamin < Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > As I said to Martin, I will investigate why, but it's a bit tricky > Must be some issue in MorphTreeMorph I introduced recently > > Ben > > On 11 Dec 2013, at 16:46, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > > Hi, > > I am experiencing problems with #whenSelectedItemsChanged: on a TreeModel. > > In particular, the block (i.e., argument of #whenSelectedItemsChanged: > gets randomly executed a couple of times (3/4) the second time that the > selection happens. The first time is fine. It looks like the registration > of the "event" or "announcement" is done multiple times. > > Any hint? > > Cheers, > R > > >

April 2, 2014

Bug in ZnUTF8Encoder

by Igor Stasenko

nextPut: character toStream: stream ... code < 65535 ifTrue: [ ... should be code < 65536 ifTrue: [ because 3-byte encoding can fit 16 bits, which is range 0...65535 but not 0...65534 -- Best regards, Igor Stasenko.

April 2, 2014

Re: [Pharo-dev] [Inspiration] Toward a better programming

by Sven Van Caekenberghe

Yes, having grand, ambitious goals is important. It is all to easy to get lost and demotivated in the day to day details, but on the other hand, that work must be done. I just read the piece about their design process and reviews. It is indeed amazing that they can have such a complex system with just one global namespace (at least for the command language and top level interface). Of course, getting there is a lot of work. On 02 Apr 2014, at 08:12, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Indeed, I read this article several times over the last couple of days. This work is impressive particularly when combined with the cloud part. > > The language itself is less interesting for me, but what makes it stand out is that it has a coherent and robust philosophy behind and phenomenal goals to reach. In Pharo, we have the luxury of building on top of coherent and robust philosophy (even if different from the Wolfram one) and we should try as much as possible to keep our eyes on phenomenal goals that seem unreachable. > > Another thing I like in Wolfram's work is attention to details: > http://blog.wolfram.com/2008/01/10/ten-thousand-hours-of-design-reviews/ > > Details are crucial, and all the effort in Pharo around naming and redesigning what already exists is incredibly important. But, it is precisely at the moment when we are knee-deep in details that is crucial to keep our eyes on the phenomenal long term goals. > > There is so much to build. Let's be bold. > > Doru > > > > On Tue, Apr 1, 2014 at 7:22 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 31 Mar 2014, at 06:21, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: > > > How about impact of this: > > > > http://blog.stephenwolfram.com/2014/03/injecting-computation-everywhere-a-s… > > > > I would agree it is quite complex for any beginner, but utility of a programming language on these lines seems cut out for the future.. > > Wow, this is really powerful stuff, a long read, but well worth it. By recombining and reusing all their technology they seem to be able to move into more and more territory. > > It is closed source and (very) expensive, and I don't like the syntax, but we sure can get good ideas from them. > > Thanks for sharing the link. > > Sven > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

April 2, 2014

Re: [Pharo-dev] [Inspiration] Toward a better programming

by phil＠highoctane.be

Environmentally aware is nice indeed. We can have this. Phil Le 2 avr. 2014 11:11, "Tudor Girba" <tudor(a)tudorgirba.com> a Ã©crit : > Both. But, does it really matter? :) > > Doru > > > On Wed, Apr 2, 2014 at 9:49 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> Definitely the latter... >> >> Norbert >> >> Am 02.04.2014 um 09:11 schrieb Andres Valloud < >> avalloud(a)smalltalk.comcastbiz.net>: >> >> > Hey Doru, I was going to ask "so is that a language or a library?"... >> > >> > On 4/1/14 23:12 , Tudor Girba wrote: >> >> Indeed, I read this article several times over the last couple of days. >> >> This work is impressive particularly when combined with the cloud part. >> >> >> >> The language itself is less interesting for me, but what makes it stand >> >> out is that it has a coherent and robust philosophy behind and >> >> phenomenal goals to reach. In Pharo, we have the luxury of building on >> >> top of coherent and robust philosophy (even if different from the >> >> Wolfram one) and we should try as much as possible to keep our eyes on >> >> phenomenal goals that seem unreachable. >> >> >> >> Another thing I like in Wolfram's work is attention to details: >> >> >> http://blog.wolfram.com/2008/01/10/ten-thousand-hours-of-design-reviews/ >> >> >> >> Details are crucial, and all the effort in Pharo around naming and >> >> redesigning what already exists is incredibly important. But, it is >> >> precisely at the moment when we are knee-deep in details that is >> crucial >> >> to keep our eyes on the phenomenal long term goals. >> >> >> >> There is so much to build. Let's be bold. >> >> >> >> Doru >> >> >> >> >> >> >> >> On Tue, Apr 1, 2014 at 7:22 PM, Sven Van Caekenberghe <sven(a)stfx.eu >> >> <mailto:sven@stfx.eu>> wrote: >> >> >> >> >> >> On 31 Mar 2014, at 06:21, S Krish < >> krishnamachari.sudhakar(a)gmail.com >> >> <mailto:krishnamachari.sudhakar@gmail.com>> wrote: >> >> >> >> > How about impact of this: >> >> > >> >> > >> >> >> http://blog.stephenwolfram.com/2014/03/injecting-computation-everywhere-a-s… >> >> > >> >> > I would agree it is quite complex for any beginner, but utility >> >> of a programming language on these lines seems cut out for the >> future.. >> >> >> >> Wow, this is really powerful stuff, a long read, but well worth it. >> >> By recombining and reusing all their technology they seem to be able >> >> to move into more and more territory. >> >> >> >> It is closed source and (very) expensive, and I don't like the >> >> syntax, but we sure can get good ideas from them. >> >> >> >> Thanks for sharing the link. >> >> >> >> Sven >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> www.tudorgirba.com <http://www.tudorgirba.com> >> >> >> >> "Every thing has its own flow" >> > >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

April 2, 2014

Re: [Pharo-dev] [Inspiration] Toward a better programming

by Tudor Girba

Both. But, does it really matter? :) Doru On Wed, Apr 2, 2014 at 9:49 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > Definitely the latter... > > Norbert > > Am 02.04.2014 um 09:11 schrieb Andres Valloud < > avalloud(a)smalltalk.comcastbiz.net>: > > > Hey Doru, I was going to ask "so is that a language or a library?"... > > > > On 4/1/14 23:12 , Tudor Girba wrote: > >> Indeed, I read this article several times over the last couple of days. > >> This work is impressive particularly when combined with the cloud part. > >> > >> The language itself is less interesting for me, but what makes it stand > >> out is that it has a coherent and robust philosophy behind and > >> phenomenal goals to reach. In Pharo, we have the luxury of building on > >> top of coherent and robust philosophy (even if different from the > >> Wolfram one) and we should try as much as possible to keep our eyes on > >> phenomenal goals that seem unreachable. > >> > >> Another thing I like in Wolfram's work is attention to details: > >> > http://blog.wolfram.com/2008/01/10/ten-thousand-hours-of-design-reviews/ > >> > >> Details are crucial, and all the effort in Pharo around naming and > >> redesigning what already exists is incredibly important. But, it is > >> precisely at the moment when we are knee-deep in details that is crucial > >> to keep our eyes on the phenomenal long term goals. > >> > >> There is so much to build. Let's be bold. > >> > >> Doru > >> > >> > >> > >> On Tue, Apr 1, 2014 at 7:22 PM, Sven Van Caekenberghe <sven(a)stfx.eu > >> <mailto:sven@stfx.eu>> wrote: > >> > >> > >> On 31 Mar 2014, at 06:21, S Krish <krishnamachari.sudhakar(a)gmail.com > >> <mailto:krishnamachari.sudhakar@gmail.com>> wrote: > >> > >> > How about impact of this: > >> > > >> > > >> > http://blog.stephenwolfram.com/2014/03/injecting-computation-everywhere-a-s… > >> > > >> > I would agree it is quite complex for any beginner, but utility > >> of a programming language on these lines seems cut out for the > future.. > >> > >> Wow, this is really powerful stuff, a long read, but well worth it. > >> By recombining and reusing all their technology they seem to be able > >> to move into more and more territory. > >> > >> It is closed source and (very) expensive, and I don't like the > >> syntax, but we sure can get good ideas from them. > >> > >> Thanks for sharing the link. > >> > >> Sven > >> > >> > >> > >> > >> > >> -- > >> www.tudorgirba.com <http://www.tudorgirba.com> > >> > >> "Every thing has its own flow" > > > > > -- www.tudorgirba.com "Every thing has its own flow"

April 2, 2014

Was TickingWindow integrated?

by Pharo4Stef

Hi guys Iâm in a train (no internet) and I see that the inspector does not refresh but in fact we introduced with clement a nice tickingWindow in spec and the goal is that the window refresh its contents. I have the impression it was not integrated. Note that this change is important because it removes a lot of processes hanging in the background. Stef

April 2, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30807 Home: https://github.com/pharo-project/pharo-core

April 2, 2014