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

[pharo-project/pharo-core]

by GitHub

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

May 15, 2016

[pharo-project/pharo-core] 728a7d: 60003

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 728a7d49160272b052b923aa71a6dc1bb9682998 https://github.com/pharo-project/pharo-core/commit/728a7d49160272b052b923aa… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-05-15 (Sun, 15 May 2016) Changed paths: M Polymorph-Widgets.package/ThemeIcons.class/instance/accessing/iconNamed_ifNone_.st M Polymorph-Widgets.package/ThemeIcons.class/instance/loading/loadIconsFromUrl.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60002.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60003.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60002.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60003.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60003 18129 ThemeIcons should store icons in an IdentityDictionarry https://pharo.fogbugz.com/f/cases/18129 http://files.pharo.org/image/60/60003.zip

May 15, 2016

[pharo-project/pharo-core] 0f6544: 60002

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 0f65440719bf4a01991d19b392957773e4d55b5d https://github.com/pharo-project/pharo-core/commit/0f65440719bf4a01991d19b3… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-05-15 (Sun, 15 May 2016) Changed paths: M NECompletion.package/NECContext.class/instance/private-type-guessing/guessGlobal_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60001.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60002.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60001.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60002.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60002 18148 NEC should guess global variables https://pharo.fogbugz.com/f/cases/18148 http://files.pharo.org/image/60/60002.zip

May 15, 2016

[pharo-project/pharo-core]

by GitHub

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

May 15, 2016

Re: [Pharo-dev] About Pragma keyword vs Pragma selector

by Tudor Girba

Hi, We can indeed deprecate keyword, but if we change selector to mean the pragma selector instead of method selector, we cannot deprecate that one. But, indeed, I do not think we have many users out there :). Cheers, Doru > On May 15, 2016, at 10:34 AM, stepharo <stepharo(a)free.fr> wrote: > > we can use deprecation and I do not think that there are that many usages out there. > > > Le 14/5/16 Ã 15:53, Tudor Girba a Ã©crit : >> Hi, >> >> I would agree with that. The only thing to take into account is that this can introduce incompatibilities with external libraries, but I do not think this would be much. >> >> Cheers, >> Doru >> >> >>> On May 14, 2016, at 3:03 PM, stepharo <stepharo(a)free.fr> wrote: >>> >>> I would rename >>> >>> Pragma>>keyword into Pragma>>selector >>> >>> Pragma>>selector into Pragma>>methodSelector >>> so like that it is coherent with >>> >>> Message and method api and with Pragma>>methodClass >>> Le 13/5/16 Ã 14:33, stepharo a Ã©crit : >>>> Color >> gtInspectorColorIn: composite >>>> <gtInspectorPresentationOrder: 30> >>>> >>>> composite morph >>>> title: 'Color'; >>>> display: [ BorderedMorph new color: self ] >>>> >>>> pragma := (Color >> #gtInspectorColorIn:) pragmas first >>>> pragma arguments >>>>> 30 >>>> pragma keyword >>>>> #gtInspectorPresentationOrder: >>>> >>>> I wonder why pragma returns their selector using keyword and not selector? >>>> >>>> Especially since message API uses selector. >>>> >>>> >>>> Pragma >> message >>>> "Answer the message of the receiving pragma." >>>> >>>> ^ Message selector: self keyword arguments: self arguments. >>>> >>>> Stef >>>> >>>> >>>> >>> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "What we can governs what we wish." >> >> >> >> >> >> > > -- www.tudorgirba.com www.feenk.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

May 15, 2016

Re: [Pharo-dev] problem with slots on proxies

by stepharo

what is the status of Ghost? Because we should get a good (and this implies documented) proxy model Stef Le 27/3/16 Ã 18:47, Denis Kudriashov a Ã©crit : > Hi > > 2016-03-26 21:54 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>>: > > Hi, > > I am trying to play with some proxies that inherit from > ProtoObject have slots. For example, I try to do this, but I get > an error: > > ProtoObject subclass: #BBB > instanceVariableNames: 'variable' > classVariableNames: '' > package: 'BBB'. > BBB class allSlots first read: BBB new > > The problem is that the slot sends messages to its parent object, > such as: > IndexedSlot>>read: anObject > ^ anObject instVarAt: index > > This is a problem because a similar scenario happens also when you > open a debugger on a proxy that tries to communicate with a remote > image. > > I think that instead of sending messages to the receiver, we > should make the slot work with the mirror primitives. > > For example, we would rewrite the read: method like: > IndexedSlot>>read: anObject > ^ thisContext object: anObject instVarAt: index > > Do you agree? Can I open an issue for this? I think this is important. > > > Yes, please. > But does not thisContext degrades performance? > Guille extracted mirror primitives to separate class MirrorPrimitives > (project Mirror in Pharo repo). I think we should start to use it and > move away from context.

May 15, 2016

Re: [Pharo-dev] Spec: Rereading Dolphin book and MVP

by Denis Kudriashov

Hi. I am sure I saw model inside presenter in Spec. It was one of reason why presenter is better name. We had Model model. Now it is Presenter model. But if your wrote this there is no reference from presenter to model now? 15 Ð¼Ð°Ñ 2016 Ð³. 10:29 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "stepharo" <stepharo(a)free.fr> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: > In MVP the presenter has direct access to the Model and (of course it means that the Model API is fixed) I did not mean that Model :) I meant the relationship with View. Stef Why would that be true? You can plug the necessary behavior of how the model can be accessed, so no need to fix the Model's API. After all the actual model will vary from user the user, so the API can't be fixed. On Sat, May 14, 2016 at 8:39 PM, stepharo <stepharo(a)free.fr> wrote: > Hi > > > In MVP the presenter has direct access to the Model and (of course it > means that the Model API is fixed) but I wonder if this would not > > help us simplify Spec. > > > Model <---- presenter <----> View > > > What do you think? > > > Stef > > >

May 15, 2016

Re: [Pharo-dev] About Pragma keyword vs Pragma selector

by stepharo

we can use deprecation and I do not think that there are that many usages out there. Le 14/5/16 Ã 15:53, Tudor Girba a Ã©crit : > Hi, > > I would agree with that. The only thing to take into account is that this can introduce incompatibilities with external libraries, but I do not think this would be much. > > Cheers, > Doru > > >> On May 14, 2016, at 3:03 PM, stepharo <stepharo(a)free.fr> wrote: >> >> I would rename >> >> Pragma>>keyword into Pragma>>selector >> >> Pragma>>selector into Pragma>>methodSelector >> so like that it is coherent with >> >> Message and method api and with Pragma>>methodClass >> Le 13/5/16 Ã 14:33, stepharo a Ã©crit : >>> Color >> gtInspectorColorIn: composite >>> <gtInspectorPresentationOrder: 30> >>> >>> composite morph >>> title: 'Color'; >>> display: [ BorderedMorph new color: self ] >>> >>> pragma := (Color >> #gtInspectorColorIn:) pragmas first >>> pragma arguments >>>> 30 >>> pragma keyword >>>> #gtInspectorPresentationOrder: >>> >>> I wonder why pragma returns their selector using keyword and not selector? >>> >>> Especially since message API uses selector. >>> >>> >>> Pragma >> message >>> "Answer the message of the receiving pragma." >>> >>> ^ Message selector: self keyword arguments: self arguments. >>> >>> Stef >>> >>> >>> >> > -- > www.tudorgirba.com > www.feenk.com > > "What we can governs what we wish." > > > > > >

May 15, 2016

Re: [Pharo-dev] Spec: Rereading Dolphin book and MVP

by stepharo

> > In MVP the presenter has direct access to the Model and (of course > it means that the Model API is fixed) I did not mean that Model :) I meant the relationship with View. Stef > > Why would that be true? You can plug the necessary behavior of how the > model can be accessed, so no need to fix the Model's API. > After all the actual model will vary from user the user, so the API > can't be fixed. > > On Sat, May 14, 2016 at 8:39 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Hi > > > In MVP the presenter has direct access to the Model and (of course > it means that the Model API is fixed) but I wonder if this would not > > help us simplify Spec. > > > Model <---- presenter <----> View > > > What do you think? > > > Stef > > >

May 15, 2016

Re: [Pharo-dev] Spec: Rereading Dolphin book and MVP

by Peter UhnÃ¡k

> In MVP the presenter has direct access to the Model and (of course it means that the Model API is fixed) Why would that be true? You can plug the necessary behavior of how the model can be accessed, so no need to fix the Model's API. After all the actual model will vary from user the user, so the API can't be fixed. On Sat, May 14, 2016 at 8:39 PM, stepharo <stepharo(a)free.fr> wrote: > Hi > > > In MVP the presenter has direct access to the Model and (of course it > means that the Model API is fixed) but I wonder if this would not > > help us simplify Spec. > > > Model <---- presenter <----> View > > > What do you think? > > > Stef > > >

May 14, 2016