DebugSession>>activePC:
Locked
12
12
DebugSession>>activePC:
 
|
Hello,
I saw that DebugSession>>activePC: has no senders in pharo. Does someone know the intention behind it? activePC: aContext ^ (self isLatestContext: aContext) ifTrue: [ interruptedContext pc ] ifFalse: [ self previousPC: aContext ] Thomas Dupriez |
|
|
Hi Thomas,
> On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev <[hidden email]> 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. |
Re: DebugSession>>activePC:
|
|
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. So why if marcus removed it inadvertly would you want to make him feel bad? I don’t want people to feel bad. We can do mistake. I prefer a living system where people can make mistake over a system that is frozen. In that case I prefer to go and code in Java or javascript for many obvious reasons. May be it was removed because it was in an extension method. So if you do not collaborate then how can we know it? Stef Usually at home I move the dirt outside so that people can take them away. Now if my kids tells me not to throw away then I don’t. > On 10 Jan 2019, at 15:11, Eliot Miranda <[hidden email]> wrote: > > Hi Thomas, > >> On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev <[hidden email]> 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. |
Re: DebugSession>>activePC:
|
|
In reply to this post by Eliot Miranda-2
Eliot I would like also two points to this.
- First we asked thomas to write tests about the debugger model and you see if they would be tests about methods we could understand that they are used and control what they do. So we should all thank thomas for his energy in this not so easy task. - Second it would be nice if you could refrain to be systematically negative about what we are doing. I think that our development process is much better than many others :) It is not perfect because this does not exist. I think that we are doing a great job make Smalltalk cool. And yes it may happen that one untested, undocumented method get lost. I think that we are doing pretty good given the resources we have. Stef > On 10 Jan 2019, at 15:11, Eliot Miranda <[hidden email]> wrote: > > Hi Thomas, > >> On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev <[hidden email]> 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. |
external#senders (was Re: DebugSession>>activePC:)
|
|
In reply to this post by Pharo Smalltalk Developers mailing list
On Thu, 10 Jan 2019 at 23:51, ducasse via Pharo-dev <[hidden email]> wrote: Thomas can you integrate such comments in the debugger class comment 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. 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 |
|
|
In reply to this post by Pharo Smalltalk Developers mailing list
Ben
Since you asked I reply. For calypso we try and sometimes fail and retry. But we do not rant. Now the solution is also to have tests and this is what we are doing. We want more tests and we are working on having more tests. The solution is also to have ***********positive********* communication. There is no point to piss on our process because - we were the first to push package usage back in squeal 3.9 - increase enormously the number of tests - have CI to run the tests and use PR. and it is working! So before bashing us I would expect a bit of respect that it is due to our track record. Finally it takes 1 min to enter a bug entry and now you cannot even complain that you have to log because it is on github. (BTW nobdoy is asking the amount of time it takes US to migrate and go over the bug entry - again I ask for respect for the people doing this tedious, boring but important job). When VMMaker will be available in Pharo we will be able to automate things not before. Please remember also that Igor paid by us spent a lot of time making sure that everybody and in particular our jenkins server could automatically build vm. So we believe in agility, communication and automation. Stef
|
|
|
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.
|
|
|
In reply to this post by ducasse
On Fri, 11 Jan 2019 at 15:24, ducasse <[hidden email]> wrote:
Agreed.
A massive amount of work on the process has been done behind the scenes, and we are reaping the benefit of it daily. Thanks everyone involved in that. By offering some ideas to take things to the next level I didn't mean to imply something was wrong, more acknowledging the constraint under which those decisions are made.
Cool. As priority and constraints dictate, it will be a good day when it gets here.
I like that. Thanks for your response. cheers -ben |
|
|
In reply to this post by Pharo Smalltalk Developers mailing list
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 [hidden email] +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) |
|
|
Then perfect!
|
Re: external#senders (was Re: DebugSession>>activePC:)
|
|
In reply to this post by EstebanLM
> On 11 Jan 2019, at 08:45, Esteban Lorenzano <[hidden email]> 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. |
|
|
In reply to this post by Eliot Miranda-2
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 <[hidden email]> wrote: > > Hi Thomas, > >> On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev <[hidden email]> 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." |
Re: external#senders (was Re: DebugSession>>activePC:)
|
|
In reply to this post by Sven Van Caekenberghe-2
> Am 11.01.2019 um 11:33 schrieb Sven Van Caekenberghe <[hidden email]>: > > > >> On 11 Jan 2019, at 08:45, Esteban Lorenzano <[hidden email]> 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. > > |
|
|
In reply to this post by Tudor Girba-2
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 <[hidden email]> wrote: >> >> Hi Thomas, >> >>> On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev <[hidden email]> 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." > > |
Re: external#senders (was Re: DebugSession>>activePC:)
|
|
In reply to this post by ducasse
Stef,
|
Re: external#senders (was Re: DebugSession>>activePC:)
|
|
In reply to this post by ducasse
I would never dream of responding to technical criticism of the CM with a response that says “please refrain from criticizing us”. I try and respond honestly with an objective assessment of the technical, logistical and human issues. In fact I welcome criticism; how on earth will the VM improve in directions other than the narrow ones those working on it set without criticism from other stake holders?
|
Re: external#senders (was Re: DebugSession>>activePC:)
|
|
In reply to this post by Eliot Miranda-2
Eliot,
I can assure you that multiple core Pharo people had the same reaction, don't turn this (again) in a play on one person's emotions (apart from the fact that those are present in all living creatures). Sven > On 11 Jan 2019, at 18:57, Eliot Miranda <[hidden email]> wrote: > > Stef, > > On Jan 10, 2019, at 11:24 PM, ducasse <[hidden email]> wrote: > >> Ben >> >> Since you asked I reply. >> For calypso we try and sometimes fail and retry. But we do not rant. >> >> Now the solution is also to have tests and this is what we are doing. >> We want more tests and we are working on having more tests. >> >> The solution is also to have ***********positive********* communication. >> >> There is no point to piss on our process because >> - we were the first to push package usage back in squeal 3.9 >> - increase enormously the number of tests >> - have CI to run the tests and use PR. >> and it is working! >> >> So before bashing us I would expect a bit of respect that it is due to our track record. > > Again you fail to respond to an attempt to discuss real issues and instead take it as a personal map attack and respond emotionally. Ben is /not/ bashing your process in an attempt to damage Pharo. As an academic researcher you should be able to respond objectively to criticism. This frequent emotionality doesn’t help you or the community. > >> >> Finally it takes 1 min to enter a bug entry and now you cannot even complain that you have to log >> because it is on github. (BTW nobdoy is asking the amount of time it takes US to migrate and go over the bug entry - >> again I ask for respect for the people doing this tedious, boring but important job). >> >> When VMMaker will be available in Pharo we will be able to automate things not before. >> Please remember also that Igor paid by us spent a lot of time making sure that >> everybody and in particular our jenkins server could automatically build vm. >> >> So we believe in agility, communication and automation. >> >> Stef >> >> >> >> >>> On 11 Jan 2019, at 05:54, Ben Coman <[hidden email]> wrote: >>> >>> On Thu, 10 Jan 2019 at 23:51, ducasse via Pharo-dev <[hidden email]> 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 |
|
|
In reply to this post by Craig Latta
Craig,
thank you. +1000 > On Jan 11, 2019, at 12:58 AM, Craig Latta <[hidden email]> 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 > [hidden email] > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > |
|
|
In reply to this post by Tudor Girba-2
Hi Doru,
> On Jan 11, 2019, at 4:53 AM, Tudor Girba <[hidden email]> 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. Indeed. I am responding because of the recent experience we had, that you are intimately aware of, of moving the somewhat functional Pharo 6 VMMaker port forward to Pharo 7, which is frustrating because enough things changes that it was broken. And that is far from an isolated experience. I want very, very much for Pharo to succeed. It is the most important user of the opensmalltalk-vm by far. If Pharo fails, opensmalltalk-vm will very likely become entirely irrelevant and uninteresting. So my career and financial security are wedded to Pharo’s success. At the same time I do not feel positive about Pharo, as I have said, in its stability and in the community’s difficulty in discussing problems (primarily the stability and development model issues). I am therefore very much interested in solving these problems. So if I jump to conclusions it is because I am concerned and want to change how I feel about Pharo as a viable platform for my work, and that means being able to talk about difficult issues and not be shushed. I want there to be constructive discussion, not defensiveness or blithe positivity. Progress depends on truth and ingenuity, not positive thinking. > > 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 :). Indeed I do! > > @Thomas: Thanks for this effort! > > Cheers, > Doru > > >> On Jan 10, 2019, at 3:11 PM, Eliot Miranda <[hidden email]> wrote: >> >> Hi Thomas, >> >>> On Jan 10, 2019, at 2:24 AM, Thomas Dupriez via Pharo-dev <[hidden email]> 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." > > |
Re: external#senders (was Re: DebugSession>>activePC:)
|
|
In reply to this post by EstebanLM
Esteban,
|
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |