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

Shortcut for programmatically executing a class side method ?
by Sven Van Caekenberghe Jan. 13, 2019

Jan. 13, 2019

Hi, Does there exist a shortcut for programmatically executing a class side method ? For example, String class>>#loremIpsum in: [ :method | method methodClass instanceSide perform: method selector ]. I was looking for a shortcut, like #eval, #execute, #value or something like that. (String class>>#loremIpsum) eval. Sven

3 2

[Pharo 7.0] Build #121: 22885-Rename-Calypso-Queries-to-have-Query-suffix
by ci-pharo-ci-jenkins2＠inria.fr Jan. 13, 2019

Jan. 13, 2019

There is a new Pharo build available! The status of the build #121 was: SUCCESS. The Pull Request #2223 was integrated: "22885-Rename-Calypso-Queries-to-have-Query-suffix" Pull request url: https://github.com/pharo-project/pharo/pull/2223 Issue Url: https://pharo.fogbugz.com/f/cases/22885 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Re: [Pharo-dev] DebugSession>>activePC:
by Denis Kudriashov Jan. 12, 2019

Jan. 12, 2019

Hi guys. Funny thing that DebugSession does not exists in Squeak. It was introduced in Pharo to represent the model for debugger. Ð¿Ñ, 11 ÑÐ½Ð². 2019 Ð³. Ð² 22:34, Thomas Dupriez via Pharo-dev < pharo-dev(a)lists.pharo.org>: > Yeah, it's a bit unfortunate you assumed I wanted to remove the method. > It brought up a not so pleasant discussion. > Everyone makes mistakes. :-) > > So if I understand, this method gives the pc that maps to the ast node > the debugger should highlight when a context is selected in the stack > widget? If I'm right, how comes that this method has no senders in the > debugger code? That would mean this feature is also implemented > somewhere else. > > Thomas > > Le 11/01/2019 Ã 20:28, Eliot Miranda a Ã©crit : > > Hi Thomas, > > > > forgive me, my first response was too terse. Having thought about it > in the shower it becomes clear :-) > > > >> On Jan 11, 2019, at 6:49 AM, Thomas Dupriez < > tdupriez(a)ens-paris-saclay.fr> wrote: > >> > >> 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? > > There are two âmodesâ where a pc us mapped to a source range. One is > when stepping a context in the debugger (the context is on top and is > actively executing bytecodes). Here the debugger stops immediately before > a send or assignment or return, so that for sends we can do into or over, > or for assignments or returns check stack top to see what will be assigned > or returned. In this mode we want the pc of the send, assign or return to > map to the source range for the send, or the expression being assigned or > returned. Since this is the âcommon caseâ, and since this is the only > choice that makes sense for assignments ta and returns, the bytecode > compiler constructs itâs pc to source range map in terms of the pc of the > first byte if the send, assign or return bytecode. > > > > The second âmodeâ is when selecting a context below the top context. > The pc for any context below the top context will be the return pc for a > send, because the send has already happened. The compiler could choose to > map this pc to the send, but it would not match what works for the common > case. Another choice would appear be to have two map entries, one for the > send and one for the return pc, both mapping to the source range. But this > wouldnât work because the result of a send might be assigned or returned > and so there is a potential conflict. I stead the reasonable solution is > to select the previous pc for contexts below the top of context, which will > be the pc for the start of the send bytecode. > > > > HTH > > > >> 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." > >>> > >>> > >

1 0

Is metacello aware of MC branches???
by Nicolas Cellier Jan. 12, 2019

Jan. 12, 2019

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?

3 3

Visual Studio code Configuration for the VM
by Guillermo Polito Jan. 11, 2019

Jan. 11, 2019

Hi guys, We have been using this week with Pablo a combination of Visual Studio Code, cygwin, and gdb to build and debug the VM to chase some issues during ffi calls in win64. It was overall simple to setup, and though I thought it was going to be just a text editor with vitamines, it ended up being a really light but versatile IDE with code navigation, compilation and debugging integration. But, since there were some little things over here and there like gdb source code mapping that was not so straight forward to find in the documentation, we thought it would be good to share it. If somebody is interested in using a similar setup to work with the VM, I've left my configuration files in the following gist, including: - cygwin bash terminal integration (also with zsh, but that's pure cygwin) - task actions to build cog and stack vms on debug mode - launch configs to run both in debug mode with gdb attached https://gist.github.com/guillep/452a9be3d231db6f89dd40bfb8cf4405 Cheers, Guille & Pablo

1 0

external#senders (was Re: [Pharo-dev] DebugSession>>activePC:)
by Ben Coman Jan. 11, 2019

Jan. 11, 2019

On Thu, 10 Jan 2019 at 23:51, ducasse via Pharo-dev < pharo-dev(a)lists.pharo.org> wrote: > Thomas can you integrate such comments in the debugger class comment > > @Eliot thanks for the explanation. > About the method removed, could you please react less negatively? It would > be nice. > I cannot believe that you the guy that know the VM would get stopped to > open a bug entry telling us that isOptimizedBlock > has been removed and it should not. How much time opening a bug entry can > take? Under 1 min I guess. > I'd guess it takes more than 1 minute overall - a few minutes to shift context to open an old Pharo image and a few more open the original method to copy it to Pharo and repeat that for the next ten missing methods, and then having fixed it for yourself, rather than just log a job for someone else, having fixed your own you now repair your pharo repo with Iceberg and submit a commit, and your now off-task by half an hour. Not a great deal of time if that was what you schedule to work on, you but frustrating when dragged off task. The thing is, when is someone is frustrated, without sharing there is no chance to resolve anything, so the frustration doubles and builds up, and unconsciously creeps in relationships and/or leads to a breakdown. Putting it out in the world relieves that pressure and provides the possibility that someone might find a middle path. As always, it is not what is said but how it is said, and personally that seemed okay to me. >> 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. On the flip side, if the rule was "don't touch unused methods", that would block a lot of action around cleaning, minimisation and modulation that are important. Even though those things aren't directly the shiney new tools that make Pharo great, its their philosophy that underpins a lot of the visible Pharo improvements which has facilitated Pharo's growth. That "vision" is why I'm here. The pivot point here the concept of "unused" and perhaps where we can do better. Currently developers have no information available to base their decision on. Requiring developers to query the mail list about every cleaning, minimisation and modulation action would have a freezing effect. For stuff that is image its much easier for developers since: * its "visible" right in front of them * they can make decisions and take action around it * tests can be run So the question is how we can get those things for important modules outside the image? For me, VM is not like any third party app but is very much a *part* of Pharo since its something which helps Pharo itself advance. So lets treat it as such, similar to how we treat other modules like Calypso or Iceberg which happen distributed in-Image. Can we consider the last step of the CI (after packing the CI product) could load a static version of VMMaker? Not that any issues would fail the commit, but just report to bring "visibility" to the table ? Or, once VMMaker is in git, perhaps a separate opensmalltalk-vm CI job could run against each latest Pharo image to report problems? Or to broaden the perspective of "unused" further, we could put broader #senders-info in front of developers so then can make informed decisions at design time rather cleaning up after-the-fact? Projects could register on a central site their list of #senders (generated from some tool) so the Pharo IDE could reference that when asked for #senders - so the information is available to make informed decisions. Clicking on an external#sender could pop up the actual code hosted on github, so developers have even better knowledge for decisions and communication. Of course, creating such a system requires effort in our world of limited resources. But the external#senders register could be a premium service available just to Pharo Association/Consortium members which sets up a bit of a win/win scenario. It helps developers and is an incentive to join up. This is not to guarantee changes won't affect your project's #senders, but just to improve communication around them. So why if marcus removed it inadvertently would you want to make him feel > bad? I donât want people to feel bad. > We can do mistake. That is an important philosophy, but here is a key thing to be clear on... [ "If you are not open to hearing about mistakes, then you are not open to making mistakes." ] repeat. There is no reason for an individual to feel bad about removing an "unused" method if that is the process. But can the process be improved? cheers -ben

6 12

Re: [Pharo-dev] DebugSession>>activePC:
by Craig Latta Jan. 11, 2019

Jan. 11, 2019

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 +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

3 2

[Pharo 7.0] Build #120: 21867-cannot-loadsave-to-ftp-repository
by ci-pharo-ci-jenkins2＠inria.fr Jan. 11, 2019

Jan. 11, 2019

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…

1 0

[Pharo 7.0] Build #119: 22892 update to iceberg v154 support for win64
by ci-pharo-ci-jenkins2＠inria.fr Jan. 11, 2019

Jan. 11, 2019

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…

1 0

[Pharo 7.0] Build #118: Correct a typo in ZnDefaultServerDelegate class
by ci-pharo-ci-jenkins2＠inria.fr Jan. 11, 2019

Jan. 11, 2019

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…

1 0