August 2020 - Pharo-dev - lists.pharo.org

[Pharo 9.0] Build #617: ReservedVariable-lookupDictionary

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #617 was: SUCCESS. The Pull Request #7177 was integrated: "ReservedVariable-lookupDictionary" Pull request url: https://github.com/pharo-project/pharo/pull/7177 Issue Url: https://github.com/pharo-project/pharo/issues/ReservedVariable Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 26, 2020

Re: [Pharo-dev] Pharo-dev Digest, Vol 88, Issue 7

by Pavel Krivanek

Ãºt 25. 8. 2020 v 21:52 odesÃlatel Esteban Maringolo <emaringolo(a)gmail.com> napsal: > Hi Richard, > > Thanks for the reply, I add my comments between your lines. > > On Tue, Aug 25, 2020 at 4:29 PM Richard Uttner <richard.uttner(a)gmail.com> > wrote: > > > sorry for my contribution to this topic being so late. I fully agree to > > Martin's suggestion of checking if an inspected object conforms to the > > rich inspector api before applying it. > > > > For dealing with Glorp, I found an easy solution which Pavel will > > integrate soon in the Glorp port he published some time ago. > > Where is this port? I haven't seen it and it would be great if we > could merge it with the canonical repository at pharo-rdbms/glorp > which has been active lately (I even have a few bugfixes to submit) > It is here: https://github.com/pavel-krivanek/glorp/tree/8.3.1-23-baseline In a lot of ways, it is different to the master version so transition for users may cause some troubles and there are still some failing tests. It is not safe to promote it as master for everyone but we are using it without any trouble. > > My approach > > to find the trigger(s) resolving the proxy was simply hooking > > #doesNotUnderstand: with a Transcript trace of the current message. So I > > found out that it were only 3, which I list below along with my > > implementation in Proxy that stopped any resolving: > > Simple and clever. > > > gtDisplayString > > self isInstantiated > > ifTrue: [ ^self class name , ' on ', value gtDisplayString]. > > ^self class name, ' uninstantiated on ', self query resultClass name > > I had this. > > > gtInspectorVariableNodesIn: aCollection > > readSlot: aSlot > > I hadn't these. I'll add them as an extension to the Proxy class. > > > With this approach, I was not able to trigger proxy resolution by just > > navigating in the inspector, I had to explicitely send #getValue to the > > slot. Hope this helps until we have a more general solution! > > This is exactly what I needed. > > Thank you very much! > >

Aug. 26, 2020

Re: [Pharo-dev] Pharo-dev Digest, Vol 88, Issue 7

by Esteban Maringolo

Hi Richard, Thanks for the reply, I add my comments between your lines. On Tue, Aug 25, 2020 at 4:29 PM Richard Uttner <richard.uttner(a)gmail.com> wrote: > sorry for my contribution to this topic being so late. I fully agree to > Martin's suggestion of checking if an inspected object conforms to the > rich inspector api before applying it. > > For dealing with Glorp, I found an easy solution which Pavel will > integrate soon in the Glorp port he published some time ago. Where is this port? I haven't seen it and it would be great if we could merge it with the canonical repository at pharo-rdbms/glorp which has been active lately (I even have a few bugfixes to submit) > My approach > to find the trigger(s) resolving the proxy was simply hooking > #doesNotUnderstand: with a Transcript trace of the current message. So I > found out that it were only 3, which I list below along with my > implementation in Proxy that stopped any resolving: Simple and clever. > gtDisplayString > self isInstantiated > ifTrue: [ ^self class name , ' on ', value gtDisplayString]. > ^self class name, ' uninstantiated on ', self query resultClass name I had this. > gtInspectorVariableNodesIn: aCollection > readSlot: aSlot I hadn't these. I'll add them as an extension to the Proxy class. > With this approach, I was not able to trigger proxy resolution by just > navigating in the inspector, I had to explicitely send #getValue to the > slot. Hope this helps until we have a more general solution! This is exactly what I needed. Thank you very much!

Aug. 25, 2020

Re: [Pharo-dev] Pharo-dev Digest, Vol 88, Issue 7

by Richard Uttner

Hi Esteban and Martin, sorry for my contribution to this topic being so late. I fully agree to Martin's suggestion of checking if an inspected object conforms to the rich inspector api before applying it. For dealing with Glorp, I found an easy solution which Pavel will integrate soon in the Glorp port he published some time ago. My approach to find the trigger(s) resolving the proxy was simply hooking #doesNotUnderstand: with a Transcript trace of the current message. So I found out that it were only 3, which I list below along with my implementation in Proxy that stopped any resolving: gtDisplayString Â Â Â self isInstantiated Â Â Â Â Â Â ifTrue: [ ^self class name , ' on ', value gtDisplayString]. Â Â Â ^self class name, ' uninstantiated on ', self query resultClass name gtInspectorVariableNodesIn: aCollection Â Â "Taken from Object, avoiding loop over indexed variables calling #basicSize" Â Â aCollection Â Â Â Â Â Â addAll: ((self class allSlots collect: [ :slot | Â Â Â Â Â Â Â Â Â GTInspectorSlotNode hostObject: self slot: slot ])) readSlot: aSlot Â Â Â "Taken from Object, sent by GTInspectorSlotNode" Â Â Â ^aSlot read: self With this approach, I was not able to trigger proxy resolution by just navigating in the inspector, I had to explicitely send #getValue to the slot. Hope this helps until we have a more general solution! Best regards, Richard Am 08.08.2020 um 18:00 schrieb pharo-dev-request(a)lists.pharo.org: > Message: 1 > Date: Fri, 7 Aug 2020 20:33:50 -0300 > From: Esteban Maringolo<emaringolo(a)gmail.com> > To: Pharo Developers<pharo-dev(a)lists.pharo.org> > Subject: [Pharo-dev] Tools with Proxy support > Message-ID: > <CAJMgPC+5v4eG+qK3m7LjWmYs3H1J=mWopg_acUU9VcCsY5YJ5g(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hi, > > I'm having a hard time trying to debug some Glorp code in Pharo 8 > because the inspectors and the glamour things are triggering the > instantiation of my Proxy objects. > > I don't know how the inspectors, variable lists, and other tool work, > but I assume there should be a way to reimplement something in Proxy > to avoid causing a MessageNotUnderstood that triggers the > instantiation. > > If there is no way for it (I guess there is, looking at some gt* > selectors in ProtoObject), please consider having a debugPrintString > (and debugPrintOn:) in the upcoming Spec2 based tools.:-) > > Best regards, > > Esteban A. Maringolo > > > > ------------------------------ > > Message: 2 > Date: Fri, 7 Aug 2020 16:59:10 -0700 > From: Martin McClure<martin(a)hand2mouse.com> > To: Pharo Development List<pharo-dev(a)lists.pharo.org>, Esteban > Maringolo<emaringolo(a)gmail.com> > Subject: Re: [Pharo-dev] Tools with Proxy support > Message-ID:<49dde322-a79d-1b16-798e-9679ce08b1bf(a)hand2mouse.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > Hi Esteban, > > I also have trouble with this sort of thing in Pharo -- inspectors > sending messages to objects under inspection that are not understood, or > that do not respond in the way the inspector expects. > > It is possible to build a basic inspector that sends no messages at all > to the inspected object (using the mirror methods), and it would be nice > to have that option in Pharo. > > It's also possible to have a "careful" inspector that uses a mirror > method to determine the class of the inspected object, then uses either > the purely-mirroring inspector or the richer inspector, depending on > whether the object's class inherits from Object. Since the GemStone > clients make use of proxy objects, GemStone's inspectors take this > general approach. They're not perfect either, but problems are > considerably fewer. > > Regards, > -Martin

Aug. 25, 2020

Re: [Pharo-dev] 'VOMongoConnectionError' when dowloading mcz from smalltalkhub.com

by Dale Henrichs

On 8/25/20 9:07 AM, Esteban Maringolo wrote: > Hi Dale, > > Can't you use this? > http://static.smalltalkhub.com/dkh/metacello/mc/Metacello-Base-dkh.109.mcz I can hack things to make my single test case work, but there is code and configuration files at GemStone/GLASS/GsDevKit sites around the world that I cannot edit ... If I was told "sorry we are not going to make sure that the smalltalkhub servers are going to work any more", then I wouldn't have a choice, but to drop everything and do the conversion RIGHT NOW. Eventually there is going to be a (hopefully) more stable static site and IF/WHEN that happens I won't have to change anything, but this interim flakiness of the smalltalkhub servers is getting to be annoying ... > > Available at: > http://static.smalltalkhub.com/dkh/metacello/mc/ > > Maybe the requests to the "dynamic" SmalltalkHub could be rewritten to > point to the static version of it. If the dynamic servers are going to be unreliable, then this is probably a better solution, I'm sure that the folks who are still actively using the dynamic site aren't pleased with the flakiness either:) Dale > > Regards! > > Esteban A. Maringolo > > > On Tue, Aug 25, 2020 at 1:03 PM Dale Henrichs > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@gemtalksystems.com>> wrote: > > SmalltalkHub mcz downloads are broken ... looks like a mongo > server has gone down? .... I ran into this problem running > production tests yesterday and today I find that while the > smalltalkhub site is up, I cannot download an mcz file, using this > url: > http://smalltalkhub.com/mc/dkh/metacello/main/Metacello-Base-dkh.109.mcz. > > If you are not going to keep the current smalltalkhub site > functional, why don't you switch to the static site and give those > of us who DEPEND upon static access to mcz files a reliable site > to connect to ... I have plans to move completely away from mcz > files, but I didn't plan on doing that this week ... and frankly I > don't have the cycles to do that ... right now ... > > Here's a screenshot of a manual login and navigation to the mcz > file that is failing to download: > > And when I press the `Download .mcz` button, I get the following > "response" after a delay: >

Aug. 25, 2020

Re: [Pharo-dev] 'VOMongoConnectionError' when dowloading mcz from smalltalkhub.com

by Esteban Maringolo

Hi Dale, Can't you use this? http://static.smalltalkhub.com/dkh/metacello/mc/Metacello-Base-dkh.109.mcz Available at: http://static.smalltalkhub.com/dkh/metacello/mc/ Maybe the requests to the "dynamic" SmalltalkHub could be rewritten to point to the static version of it. Regards! Esteban A. Maringolo On Tue, Aug 25, 2020 at 1:03 PM Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > SmalltalkHub mcz downloads are broken ... looks like a mongo server has > gone down? .... I ran into this problem running production tests yesterday > and today I find that while the smalltalkhub site is up, I cannot download > an mcz file, using this url: > http://smalltalkhub.com/mc/dkh/metacello/main/Metacello-Base-dkh.109.mcz. > > If you are not going to keep the current smalltalkhub site functional, why > don't you switch to the static site and give those of us who DEPEND upon > static access to mcz files a reliable site to connect to ... I have plans > to move completely away from mcz files, but I didn't plan on doing that > this week ... and frankly I don't have the cycles to do that ... right now > ... > > Here's a screenshot of a manual login and navigation to the mcz file that > is failing to download: > > And when I press the `Download .mcz` button, I get the following > "response" after a delay: > >

Aug. 25, 2020

'VOMongoConnectionError' when dowloading mcz from smalltalkhub.com

by Dale Henrichs

SmalltalkHub mcz downloads are broken ... looks like a mongo server has gone down? .... I ran into this problem running production tests yesterday and today I find that while the smalltalkhub site is up, I cannot download an mcz file, using this url: http://smalltalkhub.com/mc/dkh/metacello/main/Metacello-Base-dkh.109.mcz. If you are not going to keep the current smalltalkhub site functional, why don't you switch to the static site and give those of us who DEPEND upon static access to mcz files a reliable site to connect to ... I have plans to move completely away from mcz files, but I didn't plan on doing that this week ... and frankly I don't have the cycles to do that ... right now ... Here's a screenshot of a manual login and navigation to the mcz file that is failing to download: And when I press the `Download .mcz` button, I get the following "response" after a delay:

Aug. 25, 2020

[Pharo 9.0] Build #616: Variable-writeInContext-should-return-Value

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #616 was: FAILURE. The Pull Request #7174 was integrated: "Variable-writeInContext-should-return-Value" Pull request url: https://github.com/pharo-project/pharo/pull/7174 Issue Url: https://github.com/pharo-project/pharo/issues/Variable Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 24, 2020

[Pharo 9.0] Build #615: Guard-ReservedVariable-name-setter

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #615 was: FAILURE. The Pull Request #7173 was integrated: "Guard-ReservedVariable-name-setter" Pull request url: https://github.com/pharo-project/pharo/pull/7173 Issue Url: https://github.com/pharo-project/pharo/issues/Guard Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 24, 2020

[Pharo 9.0] Build #614: refersToLiteral-DoNotLookIntoProperties

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #614 was: FAILURE. The Pull Request #6991 was integrated: "refersToLiteral-DoNotLookIntoProperties" Pull request url: https://github.com/pharo-project/pharo/pull/6991 Issue Url: https://github.com/pharo-project/pharo/issues/refersToLiteral Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 24, 2020