November 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] A Question about Metacello's #repository:

by Dale Henrichs

On 11/19/2015 02:49 AM, Sven Van Caekenberghe wrote: >> On 18 Nov 2015, at 00:30, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: >> >> >> >> On 11/17/15 1:34 PM, Sven Van Caekenberghe wrote: >>> Hi Dale, >>> >>> Thanks for the elaborate answer. >>> >>> Yes, I think that BaselineOf is what I was looking for, I will experiment with it. >>> >>> I do suspect that a Baseline can only be loaded using the Metacello API, not using the Pharo config handler which seems to fall back to Gofer. >>> >> The Metacello Scripting API should be used for all loads ... I know that does not always happen in Pharo, but that doesn't change the fact that the Metacello API _should_ be used:) > Yes, we should have a look at that. > >> Also make sure that you've loaded the latest Metacello into Pharo[1], because there are definitely bugs that have been fixed In Metacello that haven't made into Pharo ... > I just don't know when the last sync to place, the baseline stuff seemed to work OK. > I'm not sure as well:) The most recent sets of bugfixes[1][2][3] over the last year or so tend to be for fairly isolated problems or platform ports. The mainline functionality has been pretty stable for a couple years now. Dale [1] https://github.com/dalehenrich/metacello-work/issues?q=milestone%3A1.0.0-be… [2] https://github.com/dalehenrich/metacello-work/issues?q=milestone%3A1.0.0-be… [3] https://github.com/dalehenrich/metacello-work/issues?q=milestone%3A1.0.0-be…

Nov. 19, 2015

Versionner packages missing in

by Pavel Krivanek

Hi, I found that the Versionner package version Versionner-Tests-Resources(TheIntegrator.17) do not have its copy in the PharoExtras/Versionner repository. This stable version is placed only in the main Pharo/Pharo50 repository. Can someone, please, copy that? It's not possible to load the stable configuration of Versionner without it. Cheers, -- Pavel.

Nov. 19, 2015

Re: [Pharo-dev] EyeInspector with subclasses of ProtoObject

by Guillermo Polito

> On 19 nov 2015, at 5:46 p.m., ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > > 2015-11-19 10:33 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>>: > I know we can :) and I did some prototypes already as part of my thesis. > > The question is if that is a design we *want* or not. > > There is a misunderstanding. Nope :) I understood you well. And yes, you misunderstood my answer :P. I know that the VM already provides the necessary primitives and I know how to use them ^^. > I am not talking about prototypes. The operations are in the production VM and are stable. That's why I say you can use it. I meant prototypes of mirrors on the image side. I know and used the primitives. The questions are if we want to have a mirror library, if we want core tools (such as the inspector) to use it instead of delegating reflective operations to objects. Also there are many different mirror designs we can come up with. The design I have in mind is pretty much aligned with the idea of mirrors that Camille has in mind where there are low level mirrors to manipulate objects as the VM know them, and then high level mirrors implementing the language concerns AND application specific mirrors. But then this kind of mirror implementation is a beast in itself :) Also, answering Stephan Eggermont below: > 1 Is it an improvement on the current situation? I believe it is. Mirrors allow to extract the reflective behavior in separate objects. With them we would be able to inspect instances of classes that have no methods at all. Moreover, it would clean up objectsâ API because there will be no more meta-level methods in the base classes. This would avoid name clashes like #name in metaclasses that was discussed the other day. > 2 Is it blocking an improvement direction we want to take? I do not completely understand the question. I just can say that I think having mirrors is an interesting direction. > 3 Can it be tested quickly? A basic mirror implementation that only exposes VM internals could be easy to implement and test. Adapting the eye inspector to use a mirror instead of a normal object is also fairly easy, at lest for a first implementation. Of course the question always is doing it for real: I do not know how much time would it take to make all tools work as well. > > There is no need to implement additional VM support to debug this kind of objects as it's already done and stable. > > > >> On 18 nov 2015, at 5:29 p.m., ClÃ©ment Bera <bera.clement(a)gmail.com <mailto:bera.clement@gmail.com>> wrote: >> >> >> >> 2015-11-18 8:43 GMT-03:00 Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>>: >> Iâd like to discuss also the possibility to add those low level operations on mirrors objects, that could be packaged separately from the kernel of the language. Adding them on a first step is easy, then making all tools use them is the hard/timeconsuming part, yes. >> >> All the needed operations already exist. You can put them on your mirror objects without any problem. >> >> >> >>> On 18 nov 2015, at 12:35 p.m., ClÃ©ment Bera <bera.clement(a)gmail.com <mailto:bera.clement@gmail.com>> wrote: >>> >>> Hello, >>> >>> This is known and was discussed on the bug tracker. >>> >>> The problem is that currently Pharo has many tools and classes: EyeInspector in the debugger, GTInspector outside, the debugger itself, the in-image interpreter in the Context class ... that need to be changed to support debugging objects that basically cannot receive any message. >>> >>> We are aware of the solution but fixing it for all the toolkits and classes is quite some work. In addition, if not tested, someone will break it because he won't understand that an inspected object can't receive any message because the expected behavior of an object with no DNU behavior and no methods inherited from Object is to freeze the system. >>> >>> It's a lot of fun doing that though. >>> >>> Clement >>> >>> 2015-11-17 21:39 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>>: >>> Hi Esteban, >>> >>> On Tue, Nov 17, 2015 at 1:37 PM, Esteban A. Maringolo <emaringolo(a)gmail.com <mailto:emaringolo@gmail.com>> wrote: >>> 2015-11-17 14:37 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>>: >>> > Hi Esteban, >>> > >>> > I think EyeInspector needs to handle classes that don't inherit from >>> > Object specially. Instead of asking the instance it should ask the class. >>> > You should be able to use the Context methods for mirror primitives to >>> > extract state without sending messages to the instance. Then the special >>> > version of EyeInspector for ProtoObject subclasses can ask this like >>> >>> Yes, an special inspector for ProtoObject subclasses would be required, but I couldn't find one already suited for this purpose. >>> >>> > (thisContext objectClass: object) isIndexable ifTrue: >>> > [size := thisContext objectSize: object] >>> >>> I don't know if your code was meant to be accurate or just a guideline of how this could be implemented, but Context doesn't implement #objectClass: nor #objectSize: >>> >>> >>> Find attached. I think you'll find they are in the Spur version. You might think of back-porting their use in Context form Spur; that'll make the debugger able to handle proxies. >>> >>> > Basically both the Inspector and the Debugger's execution simulation >>> > machinery need to treat encapsulators such as MessageArchiver with kid >>> > gloves. One *must not* cause inspecting or debugging to send messages >>> > through the encapsulator. Instead, all access to the object should be >>> > through primitives that don't send messages to the objects. >>> >>> I know that dealing with Proxies and similar objects is tricky, I had to deal with my own subclasses of ProtoObject in Dolphin, but there the class implemented all that was needed to interact with the environment tools. >>> >>> Hiwever, to me all this is a kind of black magic, I read the blue book years ago and can understand it, but I do understand it as I understand the mechanics of my car, however when it breaks down I take it to the specialist :) >>> >>> Well, the thing to think of is that inside the VM objects are just a sequence of words, and the VM, while it sends messages, doesn't send messages to objects to update their state; it just accesses the state directly. So in an execution simulation method such as >>> >>> Context methods for instruction decoding >>> pushReceiverVariable: offset >>> self push: (receiver instVarAt: offset + 1) >>> >>> that will send the message instVarAt: to the receiver, and if the receiver is a proxy, that will go through the proixie's doesNotUnderstand: method and send instVarAt: the the object the proxy wraps, which won't do the right thing at all. Instead it needs to be written >>> >>> Context methods for instruction decoding >>> pushReceiverVariable: offset >>> self push: (self object: receiver instVarAt: offset + 1) >>> >>> which reaches into the object without sending any messages to it. I understand that this will appear in Spur, because I made it part of the bootstrap, but if I were you I would integrate these changes into the current version asap. The debugger won't work properly with proxies, encapsulators etc otherwise. >>> >>> _,,,^..^,,,_ >>> best, Eliot >>> >> >> > >

Nov. 19, 2015

Re: [Pharo-dev] EyeInspector with subclasses of ProtoObject

by Tudor Girba

Yep. Got it. See my other mail about integrating the reflection methods in Context. This would be enough to get the GTInspector working properly (we already did it but we cannot commit because of missing Context methods). Cheers, Doru > On Nov 19, 2015, at 5:53 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > > 2015-11-19 15:31 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > Please tell me more specifically what needs to be done. Could you give me a concrete example of an object that cannot be inspected? > > Try this code: > > GTInspector inspect: ProtoObject new > > Then you can try with instance of subclasses of ProtoObjects with different properties. For example: > > ProtoObject variableSubclass: #ProtoArray > instanceVariableNames: '' > classVariableNames: '' > category: 'Kernel-Objects' > > GTInspector inspect: (ProtoArray new: 3) > > Lastly you can try the hard cases. For example run: > > ProtoArray superclass: nil. > GTInspector inspect: (ProtoArray new: 3) > > The generic problem is that these objects cannot be expected to answer any message, as it can crash the VM, so inspection should happen without the object inspected receiving any message. > > > Cheers, > Tudor > > > > On Nov 18, 2015, at 6:08 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > > > 2015-11-18 13:29 GMT-03:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > >> > >> > >> 2015-11-18 8:43 GMT-03:00 Guillermo Polito <guillermopolito(a)gmail.com>: > >>> > >>> Iâd like to discuss also the possibility to add those low level operations > >>> on mirrors objects, that could be packaged separately from the kernel of the > >>> language. Adding them on a first step is easy, then making all tools use > >>> them is the hard/timeconsuming part, yes. > >> > >> > >> All the needed operations already exist. You can put them on your mirror > >> objects without any problem. > > > > > > Who takes the decision to put it either in EyeInspector or GtInspector? > > > > Regards! > > > > -- > www.tudorgirba.com > > "Be rather willing to give than demanding to get." > > > > > -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding."

Nov. 19, 2015

Re: [Pharo-dev] EyeInspector with subclasses of ProtoObject

by Tudor Girba

Hi, I looked at the problem with Esteban. Essentially, we would benefit a lot from the Context mirror methods that Eliot sent. We can still imagine a mirror object on top of that, but already they would provide a good enough support. Do we agree to add these methods to Pharo? Cheers, Doru > On Nov 19, 2015, at 3:31 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > Please tell me more specifically what needs to be done. Could you give me a concrete example of an object that cannot be inspected? > > Cheers, > Tudor > > >> On Nov 18, 2015, at 6:08 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >> >> 2015-11-18 13:29 GMT-03:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >>> >>> >>> 2015-11-18 8:43 GMT-03:00 Guillermo Polito <guillermopolito(a)gmail.com>: >>>> >>>> Iâd like to discuss also the possibility to add those low level operations >>>> on mirrors objects, that could be packaged separately from the kernel of the >>>> language. Adding them on a first step is easy, then making all tools use >>>> them is the hard/timeconsuming part, yes. >>> >>> >>> All the needed operations already exist. You can put them on your mirror >>> objects without any problem. >> >> >> Who takes the decision to put it either in EyeInspector or GtInspector? >> >> Regards! >> > > -- > www.tudorgirba.com > > "Be rather willing to give than demanding to get." > > > -- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

Nov. 19, 2015

Re: [Pharo-dev] EyeInspector with subclasses of ProtoObject

by ClÃ©ment Bera

2015-11-19 15:31 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > Please tell me more specifically what needs to be done. Could you give me > a concrete example of an object that cannot be inspected? > Try this code: GTInspector inspect: ProtoObject new Then you can try with instance of subclasses of ProtoObjects with different properties. For example: ProtoObject variableSubclass: #ProtoArray instanceVariableNames: '' classVariableNames: '' category: 'Kernel-Objects' GTInspector inspect: (ProtoArray new: 3) Lastly you can try the hard cases. For example run: ProtoArray superclass: nil. GTInspector inspect: (ProtoArray new: 3) The generic problem is that these objects cannot be expected to answer any message, as it can crash the VM, so inspection should happen without the object inspected receiving any message. > Cheers, > Tudor > > > > On Nov 18, 2015, at 6:08 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > > > > 2015-11-18 13:29 GMT-03:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > >> > >> > >> 2015-11-18 8:43 GMT-03:00 Guillermo Polito <guillermopolito(a)gmail.com>: > >>> > >>> Iâd like to discuss also the possibility to add those low level > operations > >>> on mirrors objects, that could be packaged separately from the kernel > of the > >>> language. Adding them on a first step is easy, then making all tools > use > >>> them is the hard/timeconsuming part, yes. > >> > >> > >> All the needed operations already exist. You can put them on your mirror > >> objects without any problem. > > > > > > Who takes the decision to put it either in EyeInspector or GtInspector? > > > > Regards! > > > > -- > www.tudorgirba.com > > "Be rather willing to give than demanding to get." > > > > >

Nov. 19, 2015

Re: [Pharo-dev] EyeInspector with subclasses of ProtoObject

by ClÃ©ment Bera

2015-11-19 10:33 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: > I know we can :) and I did some prototypes already as part of my thesis. > > The question is if that is a design we *want* or not. > There is a misunderstanding. I am not talking about prototypes. The operations are in the production VM and are stable. That's why I say you can use it. There is no need to implement additional VM support to debug this kind of objects as it's already done and stable. > > > On 18 nov 2015, at 5:29 p.m., ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > > 2015-11-18 8:43 GMT-03:00 Guillermo Polito <guillermopolito(a)gmail.com>: > >> Iâd like to discuss also the possibility to add those low level >> operations on mirrors objects, that could be packaged separately from the >> kernel of the language. Adding them on a first step is easy, then making >> all tools use them is the hard/timeconsuming part, yes. >> > > All the needed operations already exist. You can put them on your mirror > objects without any problem. > > > >> On 18 nov 2015, at 12:35 p.m., ClÃ©ment Bera <bera.clement(a)gmail.com> >> wrote: >> >> Hello, >> >> This is known and was discussed on the bug tracker. >> >> The problem is that currently Pharo has many tools and classes: >> EyeInspector in the debugger, GTInspector outside, the debugger itself, the >> in-image interpreter in the Context class ... that need to be changed to >> support debugging objects that basically cannot receive any message. >> >> We are aware of the solution but fixing it for all the toolkits and >> classes is quite some work. In addition, if not tested, someone will break >> it because he won't understand that an inspected object can't receive any >> message because the expected behavior of an object with no DNU behavior and >> no methods inherited from Object is to freeze the system. >> >> It's a lot of fun doing that though. >> >> Clement >> >> 2015-11-17 21:39 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >>> Hi Esteban, >>> >>> On Tue, Nov 17, 2015 at 1:37 PM, Esteban A. Maringolo < >>> emaringolo(a)gmail.com> wrote: >>> >>>> 2015-11-17 14:37 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>>> > Hi Esteban, >>>> > >>>> > I think EyeInspector needs to handle classes that don't inherit from >>>> > Object specially. Instead of asking the instance it should ask the >>>> class. >>>> > You should be able to use the Context methods for mirror primitives to >>>> > extract state without sending messages to the instance. Then the >>>> special >>>> > version of EyeInspector for ProtoObject subclasses can ask this like >>>> >>>> Yes, an special inspector for ProtoObject subclasses would be required, >>>> but I couldn't find one already suited for this purpose. >>>> >>>> > (thisContext objectClass: object) isIndexable ifTrue: >>>> > [size := thisContext objectSize: object] >>>> >>>> I don't know if your code was meant to be accurate or just a guideline >>>> of how this could be implemented, but Context doesn't implement >>>> #objectClass: nor #objectSize: >>>> >>> >>> Find attached. I think you'll find they are in the Spur version. You >>> might think of back-porting their use in Context form Spur; that'll make >>> the debugger able to handle proxies. >>> >>> > Basically both the Inspector and the Debugger's execution simulation >>>> > machinery need to treat encapsulators such as MessageArchiver with kid >>>> > gloves. One *must not* cause inspecting or debugging to send messages >>>> > through the encapsulator. Instead, all access to the object should be >>>> > through primitives that don't send messages to the objects. >>>> >>>> I know that dealing with Proxies and similar objects is tricky, I had >>>> to deal with my own subclasses of ProtoObject in Dolphin, but there the >>>> class implemented all that was needed to interact with the environment >>>> tools. >>>> >>>> Hiwever, to me all this is a kind of black magic, I read the blue book >>>> years ago and can understand it, but I do understand it as I understand the >>>> mechanics of my car, however when it breaks down I take it to the >>>> specialist :) >>>> >>> Well, the thing to think of is that inside the VM objects are just a >>> sequence of words, and the VM, while it sends messages, doesn't send >>> messages to objects to update their state; it just accesses the state >>> directly. So in an execution simulation method such as >>> >>> Context methods for instruction decoding >>> pushReceiverVariable: offset >>> self push: (receiver instVarAt: offset + 1) >>> >>> that will send the message instVarAt: to the receiver, and if the >>> receiver is a proxy, that will go through the proixie's doesNotUnderstand: >>> method and send instVarAt: the the object the proxy wraps, which won't do >>> the right thing at all. Instead it needs to be written >>> >>> Context methods for instruction decoding >>> pushReceiverVariable: offset >>> self push: (self object: receiver instVarAt: offset + 1) >>> >>> which reaches into the object without sending any messages to it. I >>> understand that this will appear in Spur, because I made it part of the >>> bootstrap, but if I were you I would integrate these changes into the >>> current version asap. The debugger won't work properly with proxies, >>> encapsulators etc otherwise. >>> >>> _,,,^..^,,,_ >>> best, Eliot >>> >> >> >> > >

Nov. 19, 2015

[pharo-project/pharo-core]

by GitHub

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

Nov. 19, 2015

[pharo-project/pharo-core] a5e4ed: 50454

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: a5e4eddae752faa22b0453fe3689b7deadb29569 https://github.com/pharo-project/pharo-core/commit/a5e4eddae752faa22b0453fe… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-19 (Thu, 19 Nov 2015) Changed paths: R Nautilus-GroupManager.package/GroupsAlreadyExist.class/README.md R Nautilus-GroupManager.package/GroupsAlreadyExist.class/class/instance creation/groupName_.st R Nautilus-GroupManager.package/GroupsAlreadyExist.class/definition.st R Nautilus-GroupManager.package/GroupsAlreadyExist.class/instance/accessing/groupName.st R Nautilus-GroupManager.package/GroupsAlreadyExist.class/instance/accessing/groupName_.st R Nautilus-GroupManager.package/extension/OrderedCollection/instance/removeDuplicates.st M Nautilus.package/AbstractNautilusUI.class/instance/displaying/open.st M OpalCompiler-Core.package/IRBytecodeGenerator.class/instance/instructions/label_.st M OpalCompiler-Core.package/IRBytecodeGenerator.class/instance/instructions/pushClosureCopyNumCopiedValues_numArgs_to_.st M OpalCompiler-Core.package/IRBytecodeGenerator.class/instance/instructions/pushNClosureTemps_.st A OpalCompiler-Core.package/IRClosureStackCount.class/README.md A OpalCompiler-Core.package/IRClosureStackCount.class/class/instance creation/newOn_.st A OpalCompiler-Core.package/IRClosureStackCount.class/definition.st A OpalCompiler-Core.package/IRClosureStackCount.class/instance/accessing/length.st A OpalCompiler-Core.package/IRClosureStackCount.class/instance/accessing/numMethodTempVars.st A OpalCompiler-Core.package/IRClosureStackCount.class/instance/accessing/numMethodTempVars_.st A OpalCompiler-Core.package/IRClosureStackCount.class/instance/initialization/initialize.st A OpalCompiler-Core.package/IRStackCount.class/class/instance creation/newOn_.st M OpalCompiler-Core.package/IRStackCount.class/instance/results/linkTo_.st R Reflectivity.package/Breakpoint.class/instance/api/break_withArguments_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50453.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50454.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50453.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50454.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M SmartSuggestions.package/SugsBreakAlwaysSuggestion.class/instance/accessing/label.st M SmartSuggestions.package/SugsBreakAlwaysSuggestion.class/instance/execution/execute.st M SmartSuggestions.package/SugsBreakConditionSuggestion.class/instance/breakpoints/breakpointForCondition.st M SmartSuggestions.package/SugsBreakOnceSuggestion.class/instance/accessing/label.st M SmartSuggestions.package/SugsBreakOnceSuggestion.class/instance/execution/execute.st Log Message: ----------- 50454 13854 frameSize calculated wrongly for #lineSegmentsDo: https://pharo.fogbugz.com/f/cases/13854 17055 simplify Breakpoint API and menu entries a little https://pharo.fogbugz.com/f/cases/17055 17052 Small cleanup GroupManager model https://pharo.fogbugz.com/f/cases/17052 17051 browsing a method directly via spotter does not show visualization of breakpoints if it has any breakpoint https://pharo.fogbugz.com/f/cases/17051 http://files.pharo.org/image/50/50454.zip

Nov. 19, 2015

Re: [Pharo-dev] Preparing for the (already here) future world of multi-core PCs

by Craig Latta

> Maybe a 'pack' of Seasides is the wrong collective. > A 'shoreline' of Seasides? A 'coast'? An archipelago. -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Nov. 19, 2015