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

Re: [Pharo-dev] can or: be redefined?

by ClÃ©ment Bera

2015-05-01 13:59 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Le 01/05/2015 13:43, ClÃ©ment Bera a Ã©crit : > >> >> >> 2015-05-01 11:58 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com >> <mailto:thierry.goubier@gmail.com>>: >> >> Le 01/05/2015 11:50, Marcus Denker a Ã©crit : >> >> >> On 01 May 2015, at 11:48, stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> wrote: >> >> >> >> >> To make the whole thing easier to understand we need to >> distinguish the two bugs. >> >> 1) or: is somehow special. No, it is not. We fixed that, >> but the fix was broken. >> >> >> This is wrong. They are special for non compiler developer. I explain >> why below. >> >> See my other mail. >> I would add two different kind of rules to help people and >> slow the use of redefinition of special selectors. >> >> >> >> I do not understand why. >> >> >> I side with Marcus there. Why? >> >> >> Why ? >> >> Because you can't debug them normally. If they're executed normally, you >> cannot step into sends using these selectors on the contrary to any >> other send because they are inlined, which is light because most of the >> time you don't want to step into these selectors. If they're executed on >> non boolean, the debugger shows the whole #mustBeBoolean, >> #mustBeBooleanIn: and #ExecuteUnoptimizedIn: stack of noise, and that's >> assuming the ExecuteUnoptimizedIn: would work in any case without errors. >> >> They are very special because they can't be debugged as other selectors. >> And I'm not talking about rare cases which make these selectors only >> slightly special, like for example where you run out of literals in a >> method, the method is not shown in the list of senders of the special >> selectors it uses. >> >> Debugging has already become much harder now that we have slots: the >> debugger highlights an instance variable in a frame whereas there are >> frames below, so you now have to understand slots to debug code. It is >> not possible to make the debugger compliant with slots because the >> debugger has access only to the bottom 20 frames of the active stack for >> other good reasons such as a very deep recursive stack, and if the >> instance variable access with a slot is not in these bottom 20 frames, >> the debugger can't detect it. >> >> Now in addition, you're telling me that for some selectors in specific >> cases instead of the regular stack I will have #mustBeBoolean, >> #mustBeBooleanIn: and #ExecuteUnoptimizedIn: inserted into the stack. So >> to debug code, you have to understand this hack too. >> >> What is the next step ? Do you want the debugger to show a stack mainly >> unrelated to what the programmer wrote that only compiler developers can >> understand ? Are we also in Pharo in the philosophy where we don't care >> about how bad is the debugger ? >> > > Well, we need to have that discussion then, since we can't roll back: the > slots are already there, and I guess that with the Meta links, we will have > to do something about it. > > So, what would it take to improve the debugger? > > Do we need to consider that the execution model shown in the debugger > needs to be a bit further away from the vm execution model? That's the way to go. I think some people like Camille are already working on it. Basically, you need abstraction over what is happening which is implemented in the image instead of the VM for simplicity and maintenance, and what the programmer wants to see which is relevant for him. For optimized selectors, one could mark the methods with pragmas as 'Do not show in debugger' and in addition rewire the bytecode to source code mapping from the method compiled on-the-fly executed in ExecuteUnoptimizedIn: to the regular method. But as I stated for Slots, it is more complicated. The debugger cannot detect if the stack is currently in a slot access, as it has access only to the bottom 20 frames. Having the debugger access the full stack is a bad idea as it would slow it considerably, making the debugger unusable on devices such as the raspberry pie, and hard to use to debug recursive code. Maybe a solution could be that if the compiled bytecode for a slot has an interrupt point (branch, back jump, send), then it could change a state in the process, probably encoded in the process instance variables, and as the debugger has access to the process it is showing it would know. > > > Thierry > > > I agree with Stef that there should be a warning telling you that >> shouldn't override such selectors if you don't know what you are doing. >> >> Btw control flow selectors are not the only special selectors. You >> cannot override #== anywhere in Pharo too. >> >> >> You now have a compiler which does not make those selectors special, >> and you want to keep them special? >> >> They're kept special in any case, for compiler developers and non >> compiler developers. We do not have a compiler and a VM that do not make >> those selectors special (Yes, this is not only a compiler problem, it's >> a VM + compiler problem). As far as I know, only the Self VMs and >> compilers do not keep those selectors special. >> > > > > >> Thierry >> >> >> Marcus >> >> >> >> >> >> > >

May 1, 2015

Re: [Pharo-dev] can or: be redefined?

by Andrei Chis

> > >> Well, we need to have that discussion then, since we can't roll back: the > slots are already there, and I guess that with the Meta links, we will have > to do something about it. > > So, what would it take to improve the debugger? > Since you can add meta links to any ast node the best approach would be to change the debugger to work at the AST level and not the bytecode level. Right now stepOver steps over a bytecode instruction and then calls #stepToSendOrReturn. I made an attempt to gave the debugger step over slot writes/reads but it is not nice at all. In a debugger at the ast level we can have actions like stepInto/Over Slot, stepInto/Over metalink, etc > Do we need to consider that the execution model shown in the debugger > needs to be a bit further away from the vm execution model? In moose we have two views for the debugger: one is the default one and the other the bytecode view. In the bytecode view you always step over one bytecode intruction and see the real stack with no hidden contexts. Cheers, Andrei > > Thierry > > > I agree with Stef that there should be a warning telling you that >> shouldn't override such selectors if you don't know what you are doing. >> >> Btw control flow selectors are not the only special selectors. You >> cannot override #== anywhere in Pharo too. >> >> >> You now have a compiler which does not make those selectors special, >> and you want to keep them special? >> >> They're kept special in any case, for compiler developers and non >> compiler developers. We do not have a compiler and a VM that do not make >> those selectors special (Yes, this is not only a compiler problem, it's >> a VM + compiler problem). As far as I know, only the Self VMs and >> compilers do not keep those selectors special. >> > > > > >> Thierry >> >> >> Marcus >> >> >> >> >> >> > >

May 1, 2015

Re: [Pharo-dev] Breakpoint of variable write

by Ben Coman

On Fri, May 1, 2015 at 6:41 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi, is it possible to do a halt whenever some instance variable is written? > > Because this week Iâve spent a lot of time debugging because something was > setting some strange values to variables and it was hard to track that down. > > Uko > Old style... replace all direct ivar references with call to ivar's accessor method, then halt in that -- or if interactive do this... Transcript crShow: thisContext sender printString. but I'm really looking forward to trying it with MetaLinks. cheers -ben

May 1, 2015

Proportional layout philosophy?

by Yuriy Tymchuk

Hi, I want to change the size of my nautilus plugin, as I donât need it always to be as big as it is by default and it takes too much space. But as soon as I use #hight: to change the hight, it gets set back. I guess itâs done by the layout, but Iâm not sure, as putting halt somewhere in layout methods means killing your image. Maybe someone is familiar with this? Uko

May 1, 2015

Re: [Pharo-dev] can or: be redefined?

by Thierry Goubier

Le 01/05/2015 13:43, ClÃ©ment Bera a Ã©crit : > > > 2015-05-01 11:58 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com > <mailto:thierry.goubier@gmail.com>>: > > Le 01/05/2015 11:50, Marcus Denker a Ã©crit : > > > On 01 May 2015, at 11:48, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > > > > To make the whole thing easier to understand we need to > distinguish the two bugs. > > 1) or: is somehow special. No, it is not. We fixed that, > but the fix was broken. > > > This is wrong. They are special for non compiler developer. I explain > why below. > > See my other mail. > I would add two different kind of rules to help people and > slow the use of redefinition of special selectors. > > > > I do not understand why. > > > I side with Marcus there. Why? > > > Why ? > > Because you can't debug them normally. If they're executed normally, you > cannot step into sends using these selectors on the contrary to any > other send because they are inlined, which is light because most of the > time you don't want to step into these selectors. If they're executed on > non boolean, the debugger shows the whole #mustBeBoolean, > #mustBeBooleanIn: and #ExecuteUnoptimizedIn: stack of noise, and that's > assuming the ExecuteUnoptimizedIn: would work in any case without errors. > > They are very special because they can't be debugged as other selectors. > And I'm not talking about rare cases which make these selectors only > slightly special, like for example where you run out of literals in a > method, the method is not shown in the list of senders of the special > selectors it uses. > > Debugging has already become much harder now that we have slots: the > debugger highlights an instance variable in a frame whereas there are > frames below, so you now have to understand slots to debug code. It is > not possible to make the debugger compliant with slots because the > debugger has access only to the bottom 20 frames of the active stack for > other good reasons such as a very deep recursive stack, and if the > instance variable access with a slot is not in these bottom 20 frames, > the debugger can't detect it. > > Now in addition, you're telling me that for some selectors in specific > cases instead of the regular stack I will have #mustBeBoolean, > #mustBeBooleanIn: and #ExecuteUnoptimizedIn: inserted into the stack. So > to debug code, you have to understand this hack too. > > What is the next step ? Do you want the debugger to show a stack mainly > unrelated to what the programmer wrote that only compiler developers can > understand ? Are we also in Pharo in the philosophy where we don't care > about how bad is the debugger ? Well, we need to have that discussion then, since we can't roll back: the slots are already there, and I guess that with the Meta links, we will have to do something about it. So, what would it take to improve the debugger? Do we need to consider that the execution model shown in the debugger needs to be a bit further away from the vm execution model? Thierry > I agree with Stef that there should be a warning telling you that > shouldn't override such selectors if you don't know what you are doing. > > Btw control flow selectors are not the only special selectors. You > cannot override #== anywhere in Pharo too. > > > You now have a compiler which does not make those selectors special, > and you want to keep them special? > > They're kept special in any case, for compiler developers and non > compiler developers. We do not have a compiler and a VM that do not make > those selectors special (Yes, this is not only a compiler problem, it's > a VM + compiler problem). As far as I know, only the Self VMs and > compilers do not keep those selectors special. > > Thierry > > > Marcus > > > > >

May 1, 2015

Re: [Pharo-dev] [QUESTION] For Dark Theme users

by phil＠highoctane.be

Dawn Theme is lighter actually. As long as it is not black ... Phil Le 1 mai 2015 12:34, "Esteban Lorenzano" <estebanlm(a)gmail.com> a Ã©crit : > I suppose "Down Themeâ users (cough, cough, Phil) too. > > I want to change the background color for something even darker: > > > > > > I think it look betterâ¦ what do you think? > > (Alsoâ¦ I need to refactor this theme thingyâ¦ is really ugly :P) > > Esteban >

May 1, 2015

Re: [Pharo-dev] can or: be redefined?

by ClÃ©ment Bera

2015-05-01 11:58 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Le 01/05/2015 11:50, Marcus Denker a Ã©crit : > >> >> On 01 May 2015, at 11:48, stepharo <stepharo(a)free.fr> wrote: >>> >>> >>> >>> >>>> To make the whole thing easier to understand we need to distinguish the >>>> two bugs. >>>> >>>> 1) or: is somehow special. No, it is not. We fixed that, but the fix >>>> was broken. >>>> >>> This is wrong. They are special for non compiler developer. I explain why below. > See my other mail. >>> I would add two different kind of rules to help people and slow the use >>> of redefinition of special selectors. >>> >> >> >> I do not understand why. >> > > I side with Marcus there. Why? > Why ? Because you can't debug them normally. If they're executed normally, you cannot step into sends using these selectors on the contrary to any other send because they are inlined, which is light because most of the time you don't want to step into these selectors. If they're executed on non boolean, the debugger shows the whole #mustBeBoolean, #mustBeBooleanIn: and #ExecuteUnoptimizedIn: stack of noise, and that's assuming the ExecuteUnoptimizedIn: would work in any case without errors. They are very special because they can't be debugged as other selectors. And I'm not talking about rare cases which make these selectors only slightly special, like for example where you run out of literals in a method, the method is not shown in the list of senders of the special selectors it uses. Debugging has already become much harder now that we have slots: the debugger highlights an instance variable in a frame whereas there are frames below, so you now have to understand slots to debug code. It is not possible to make the debugger compliant with slots because the debugger has access only to the bottom 20 frames of the active stack for other good reasons such as a very deep recursive stack, and if the instance variable access with a slot is not in these bottom 20 frames, the debugger can't detect it. Now in addition, you're telling me that for some selectors in specific cases instead of the regular stack I will have #mustBeBoolean, #mustBeBooleanIn: and #ExecuteUnoptimizedIn: inserted into the stack. So to debug code, you have to understand this hack too. What is the next step ? Do you want the debugger to show a stack mainly unrelated to what the programmer wrote that only compiler developers can understand ? Are we also in Pharo in the philosophy where we don't care about how bad is the debugger ? I agree with Stef that there should be a warning telling you that shouldn't override such selectors if you don't know what you are doing. Btw control flow selectors are not the only special selectors. You cannot override #== anywhere in Pharo too. > You now have a compiler which does not make those selectors special, and > you want to keep them special? > > They're kept special in any case, for compiler developers and non compiler developers. We do not have a compiler and a VM that do not make those selectors special (Yes, this is not only a compiler problem, it's a VM + compiler problem). As far as I know, only the Self VMs and compilers do not keep those selectors special. > Thierry > > >> Marcus >> >> >> > >

May 1, 2015

Re: [Pharo-dev] Breakpoint of variable write

by Yuriy Tymchuk

Thanks Marcus! This will be very useful. Uko > On 01 May 2015, at 12:51, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 01 May 2015, at 12:41, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> Hi, is it possible to do a halt whenever some instance variable is written? > > Soonâ¦ I am working on it. > > Make a class TT with ivar âttâ, method > tt > tt := 1. > > > Then we can define a meta-link to call "Halt nowâ: > > > | link | > link := MetaLink new > metaObject: Halt; > selector: #now. > > This we can install on the Slot itself: > > (TT slotNamed: #tt) link: link. > > > If we now call > > TT new tt > > it will tell you that we need to implement #write:to: in LinkWrapperâ¦ ;-) > Which means a lot of the basic machinery is working! > > Next week... > > Marcus

May 1, 2015

Re: [Pharo-dev] Breakpoint of variable write

by Thierry Goubier

Le 01/05/2015 12:51, Marcus Denker a Ã©crit : > >> On 01 May 2015, at 12:41, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> Hi, is it possible to do a halt whenever some instance variable is written? > > Soonâ¦ I am working on it. > > Make a class TT with ivar âttâ, method > tt > tt := 1. > > > Then we can define a meta-link to call "Halt nowâ: > > > | link | > link := MetaLink new > metaObject: Halt; > selector: #now. > > This we can install on the Slot itself: > > (TT slotNamed: #tt) link: link. > > > If we now call > > TT new tt > > it will tell you that we need to implement #write:to: in LinkWrapperâ¦ ;-) > Which means a lot of the basic machinery is working! > > Next week... Can't wait :) Thierry > > Marcus > >

May 1, 2015

Re: [Pharo-dev] Breakpoint of variable write

by Marcus Denker

> On 01 May 2015, at 12:41, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Hi, is it possible to do a halt whenever some instance variable is written? Soonâ¦ I am working on it. Make a class TT with ivar âttâ, method tt tt := 1. Then we can define a meta-link to call "Halt nowâ: | link | link := MetaLink new metaObject: Halt; selector: #now. This we can install on the Slot itself: (TT slotNamed: #tt) link: link. If we now call TT new tt it will tell you that we need to implement #write:to: in LinkWrapperâ¦ ;-) Which means a lot of the basic machinery is working! Next week... Marcus

May 1, 2015