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

[Pharo 7.0] Build #120: 21867-cannot-loadsave-to-ftp-repository

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

There is a new Pharo build available! The status of the build #120 was: FAILURE. The Pull Request #2208 was integrated: "21867-cannot-loadsave-to-ftp-repository" Pull request url: https://github.com/pharo-project/pharo/pull/2208 Issue Url: https://pharo.fogbugz.com/f/cases/21867 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 11, 2019

[Pharo 7.0] Build #119: 22892 update to iceberg v154 support for win64

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

There is a new Pharo build available! The status of the build #119 was: SUCCESS. The Pull Request #2221 was integrated: "22892 update to iceberg v154 support for win64" Pull request url: https://github.com/pharo-project/pharo/pull/2221 Issue Url: https://pharo.fogbugz.com/f/cases/22892 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 11, 2019

Re: [Pharo-dev] DebugSession>>activePC:

by Thomas Dupriez

Hi, Yes, my question was just of the form: "Hey there's this method in DebugSession. What is it doing? What's the intention behind it? Does someone know?". There was no hidden agenda behind it. @Eliot After taking another look at this method, there's something I don't understand: activePC: aContext ^ (self isLatestContext: aContext) Â Â Â Â Â Â ifTrue: [ interruptedContext pc ] Â Â Â Â Â Â ifFalse: [ self previousPC: aContext ] isLatestContext: checks whether its argument is the suspended context (the context at the top of the stack of the interrupted process). And if that's true, activePC: returns the pc of **interruptedContext**, not of the suspended context. These two contexts are different when the debugger opens on an exception, so this method is potentially returning a pc for another context than its argument... Another question I have to improve the comment for this method is: what's the high-level meaning of this concept of "activePC". You gave the formal definition, but what's the point of defining this so to speak? What makes this concept interesting enough to warrant defining it and giving it a name? Cheers, Thomas On 11/01/2019 13:53, Tudor Girba wrote: > Hi, > > @Eliot: Thanks for the clarifying answer. > > I believe you might have jumped to conclusion about the intention of the question. Thomas asked a legitimate question. Without users of a method it is hard to understand its use. It does not necessarily imply that the intention is to remove it, but it does show that someone wants to understand. > > As far as I know, Thomas actually wants to write a test to cover that usage. I am sure that you appreciate and encourage that :). > > @Thomas: Thanks for this effort! > > Cheers, > Doru > > >> On Jan 10, 2019, at 3:11 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi Thomas, >> >>> On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: >>> >>> <mime-attachment> >> in a stack of contexts the active pc is different for the top context. For other than the top context, a contextâs pc will be pointing after the send that created the context above it, so to find the pc of the send one finds the previous pc. For the top context its pc is the active pc. >> >> Typically the debugger is invoked in two different modes, interruption or exception. When interrupted, a process is stopped at the next suspension point (method entry or backward branch) and the top context in the process is the context to be displayed in the debugger. When an exception occurs the exception search machinery will find the signaling context, the context that raised the exception, which will be below the search machinery and the debugger invocation above that. The active pc of the signaling context will be the of for the send of digbsl et al. >> >> So the distinction is important and the utility method is probably useful. >> >> Do you want to remove the method simply because there are no senders in the image? >> >> If so, this is indicative of a serious problem with the Pharo development process. In the summer I ported VMMaker.oscog to Pharo 6. Now as feenk try and build a VMMaker.oscog image on Pharo 7, the system is broken, in part because of depreciations and in part because useful methods (isOptimisedBlock (isOptimizedBlock?) in the Opal compiler) have been removed. >> >> Just because a method is not in the image does not imply it is not in use. It simply means that it is not in use in the base image. As the system gets modularised this issue will only increase. There are lots of collection methods that exist as a library that are not used in the base image and removing them would clearly damage the library for users. This is the case for lots of so-called system code. There are users out there, like those of us in the vm team, who rely on such system code, and it is extremely unsettling and frustrating to have that system code change all the time. If Pharo is to be a useful platform to the vm team it has to be more stable. > -- > www.feenk.com > > âThe smaller and more pervasive the hardware becomes, the more physical the software gets." > >

Jan. 11, 2019

[Pharo 7.0] Build #118: Correct a typo in ZnDefaultServerDelegate class

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

There is a new Pharo build available! The status of the build #118 was: SUCCESS. The Pull Request #2216 was integrated: "Correct a typo in ZnDefaultServerDelegate class" Pull request url: https://github.com/pharo-project/pharo/pull/2216 Issue Url: https://pharo.fogbugz.com/f/cases/patch Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 11, 2019

Re: [Pharo-dev] external#senders (was Re: DebugSession>>activePC:)

by Norbert Hartl

> Am 11.01.2019 um 11:33 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > > >> On 11 Jan 2019, at 08:45, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> You know? since we are sharing frustrations, I have to say: we already had that process (which was the old pharo-vm project). In that project, for each version of vmmaker we were loading it, generating a vm and running pharo tests there (since there are no vm-specific tests, this was working at least to test things were not broken). >> Andâ¦ we were told this was not good and that we needed to submit to the canonical way of building the vm, which we did to not split more the community. >> >> In the process we lost all our validation process. >> >> Now we are told that we remove things without caring. >> But we care, and we spent a lot of time and effort putting in place mechanisms to allow things to continue moving. >> And then we needed to throw it away. >> >> Maybe now we have a new attempt and possibility of improving, but honestly I already spent one year of the work this community pays me to do to improve things and then it was wasted work. >> I do not thing I want to spend another âsabaticalâ year like that. >> >> Esteban >> >> Ps: Iâm sorry for the frustration rant, but when I see this things emerge I become very-very sad. > > One can only image, dream, of a world where VM development decided years ago to step into the future with a better process, better code management, modern tools, actual CI, tests, open process for real, welcoming more contributors, catering for its largest user base. > We live in an ever changing world, resisting change is not the solution. > > Open source is about embracing and nurturing community, and yes that is sometimes messy, but totally worth it. > Amen ð >

Jan. 11, 2019

Re: [Pharo-dev] DebugSession>>activePC:

by Tudor Girba

Hi, @Eliot: Thanks for the clarifying answer. I believe you might have jumped to conclusion about the intention of the question. Thomas asked a legitimate question. Without users of a method it is hard to understand its use. It does not necessarily imply that the intention is to remove it, but it does show that someone wants to understand. As far as I know, Thomas actually wants to write a test to cover that usage. I am sure that you appreciate and encourage that :). @Thomas: Thanks for this effort! Cheers, Doru > On Jan 10, 2019, at 3:11 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Thomas, > >> On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: >> >> <mime-attachment> > > in a stack of contexts the active pc is different for the top context. For other than the top context, a contextâs pc will be pointing after the send that created the context above it, so to find the pc of the send one finds the previous pc. For the top context its pc is the active pc. > > Typically the debugger is invoked in two different modes, interruption or exception. When interrupted, a process is stopped at the next suspension point (method entry or backward branch) and the top context in the process is the context to be displayed in the debugger. When an exception occurs the exception search machinery will find the signaling context, the context that raised the exception, which will be below the search machinery and the debugger invocation above that. The active pc of the signaling context will be the of for the send of digbsl et al. > > So the distinction is important and the utility method is probably useful. > > Do you want to remove the method simply because there are no senders in the image? > > If so, this is indicative of a serious problem with the Pharo development process. In the summer I ported VMMaker.oscog to Pharo 6. Now as feenk try and build a VMMaker.oscog image on Pharo 7, the system is broken, in part because of depreciations and in part because useful methods (isOptimisedBlock (isOptimizedBlock?) in the Opal compiler) have been removed. > > Just because a method is not in the image does not imply it is not in use. It simply means that it is not in use in the base image. As the system gets modularised this issue will only increase. There are lots of collection methods that exist as a library that are not used in the base image and removing them would clearly damage the library for users. This is the case for lots of so-called system code. There are users out there, like those of us in the vm team, who rely on such system code, and it is extremely unsettling and frustrating to have that system code change all the time. If Pharo is to be a useful platform to the vm team it has to be more stable. -- www.feenk.com âThe smaller and more pervasive the hardware becomes, the more physical the software gets."

Jan. 11, 2019

Is metacello aware of MC branches???

by Nicolas Cellier

Hi all, I'm trying to resolve a dialect compatibility problem like this: I want to load the Squeak and Pharo3 to 5 version depending on FFI Smallapack-StdLib-nice.1 For Pharo6, I made a different branch depending on UFFI Smallapack-StdLib.UFFI-nice.1 In the base line, i tell spec for: #'common' do: [ spec blessing: #'baseline'. spec repository: 'http://www.squeaksource.com/Smallapack'. spec package: 'Smallapack-StdLib'] and in the version I tell spec for: #squeak do: [ spec package: 'Smallapack-StdLib' with: 'Smallapack-StdLib-nice.1']. spec for: #'pharo5.0.x' do: [ spec package: 'Smallapack-StdLib' with: 'Smallapack-StdLib-nice.1']. spec for: #'pharo6.0.x' do: [ spec package: 'Smallapack-StdLib' with: 'Smallapack-StdLib.UFFI-nice.1']. but the configuration loads Smallapack-StdLib-nice.1 instead of Smallapack-StdLib.UFFI-nice.1 I would like to avoid using two different package names because it complexifies the baseline for nothing. It the same package, just a different branch. Isn't it possible? Why? Can we fix it?

Jan. 11, 2019

FFILibrary uniqueInstance

by Nicolas Cellier

Hi all, I wanted to know if the moduleName was cached somewhere or recomputed at each function call... It seems to be recomputed. We could have a different scheme: moduleName is cached in a class inst var of FFILibrary. FFILibrary is then added to startup list and moduleName is reset when resuming on a different platform. instance side moduleName calls class side moduleName. Or moduleName becomes an inst var, set during uniqueInstance construction, and uniqueInstance is nilled out when resuming. What do you think?

Jan. 11, 2019

Re: [Pharo-dev] external#senders (was Re: DebugSession>>activePC:)

by Sven Van Caekenberghe

> On 11 Jan 2019, at 08:45, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > You know? since we are sharing frustrations, I have to say: we already had that process (which was the old pharo-vm project). In that project, for each version of vmmaker we were loading it, generating a vm and running pharo tests there (since there are no vm-specific tests, this was working at least to test things were not broken). > Andâ¦ we were told this was not good and that we needed to submit to the canonical way of building the vm, which we did to not split more the community. > > In the process we lost all our validation process. > > Now we are told that we remove things without caring. > But we care, and we spent a lot of time and effort putting in place mechanisms to allow things to continue moving. > And then we needed to throw it away. > > Maybe now we have a new attempt and possibility of improving, but honestly I already spent one year of the work this community pays me to do to improve things and then it was wasted work. > I do not thing I want to spend another âsabaticalâ year like that. > > Esteban > > Ps: Iâm sorry for the frustration rant, but when I see this things emerge I become very-very sad. One can only image, dream, of a world where VM development decided years ago to step into the future with a better process, better code management, modern tools, actual CI, tests, open process for real, welcoming more contributors, catering for its largest user base. We live in an ever changing world, resisting change is not the solution. Open source is about embracing and nurturing community, and yes that is sometimes messy, but totally worth it.

Jan. 11, 2019

Re: [Pharo-dev] DebugSession>>activePC:

by ducasse

Then perfect! > On 11 Jan 2019, at 09:58, Craig Latta <craig(a)blackpagedigital.com> wrote: > > > Hi all-- > > Eliot writes: > >> Do you want to remove the method simply because there are no senders >> in the image? >> >> If so, this is indicative of a serious problem with the Pharo >> development process. In the summer I ported VMMaker.oscog to Pharo 6. >> Now as feenk try and build a VMMaker.oscog image on Pharo 7, the >> system is broken, in part because of depreciations and in part because >> useful methods (isOptimisedBlock (isOptimizedBlock?) in the Opal >> compiler) have been removed. >> >> Just because a method is not in the image does not imply it is not in >> use. It simply means that it is not in use in the base image. As the >> system gets modularised this issue will only increase. There are lots >> of collection methods that exist as a library that are not used in the >> base image and removing them would clearly damage the library for >> users. This is the case for lots of so-called system code. There are >> users out there, like those of us in the vm team, who rely on such >> system code, and it is extremely unsettling and frustrating to have >> that system code change all the time. If Pharo is to be a useful >> platform to the vm team it has to be more stable. > > Esteban responds: > >> ...we are told that we remove things without caring. > > I don't see where Eliot said anyone didn't care. > > Stef responds: > >> About the method removed, could you please react less negatively? It >> would be nice. >> >> ... >> >> How much time opening a bug entry can take? Under 1 min I guess. So >> why if marcus removed it inadvertly would you want to make him feel >> bad? > > Eliot said the system has to be more stable. It doesn't seem like a > negative reaction, or an attempt to make anyone feel bad. As Ben pointed > out, the major cost of reporting regressions isn't the time spent > interacting with the bug-tracking system, it's being switched away from > what you were doing. Using the automated regression-testing system seems > like a good way of catching this particular issue (even though it's a > step away from having full live traceability all the time, before > committing changes). > >> For calypso we try and sometimes fail and retry. But we do not rant... >> The solution is also to have ***********positive********* >> communication... There is no point to piss on our process... So before >> bashing us I would expect a bit of respect that it is due to our track >> record... it would be nice if you could refrain to be systematically >> negative about what we are doing. > > I don't think Eliot is being systematically negative, or that he > was ranting, pissing, or bashing. I think introducing those accusatory > words into the conversation detracts from positive communication. > >> I think that we are doing a great job make Smalltalk cool. > > I do, too! (And thanks for using that word. ;) > > > thanks, > > -C > > -- > Craig Latta > Black Page Digital > Amsterdam :: San Francisco > craig(a)blackpagedigital.com <mailto:craig@blackpagedigital.com> > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS)

Jan. 11, 2019