- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 029fd5: 60357

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 029fd5cd43d54b77ff02a7ec6f974389b4e83c63 https://github.com/pharo-project/pharo-core/commit/029fd5cd43d54b77ff02a7ec… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-01-26 (Thu, 26 Jan 2017) Changed paths: M BaselineOfIDE.package/BaselineOfIDE.class/instance/actions/postload_package_.st M ConfigurationOfEpicea.package/ConfigurationOfEpicea.class/instance/tags/stable_.st A ConfigurationOfEpicea.package/ConfigurationOfEpicea.class/instance/versions/version808_.st M EpiceaBrowsers.package/EpMonitorLogNode.class/class/instance creation/for_.st M EpiceaBrowsers.package/EpMonitorLogNode.class/definition.st A EpiceaBrowsers.package/EpMonitorLogNode.class/instance/accessing/headReference.st A EpiceaBrowsers.package/EpMonitorLogNode.class/instance/accessing/headReference_.st R EpiceaBrowsers.package/EpMonitorLogNode.class/instance/accessing/referencedGlobalNameIfEmptyLog.st R EpiceaBrowsers.package/EpMonitorLogNode.class/instance/accessing/referencedGlobalNameIfEmptyLog_.st M EpiceaBrowsers.package/EpMonitorLogNode.class/instance/accessing/referencedGlobalNamesIfEmptyLog.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60356.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60357.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60356.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60357.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60357 19601 [Epicea] Epicea monitor is off by default https://pharo.fogbugz.com/f/cases/19601 19600 [Epicea] OmNullReference shuld provide #globalName https://pharo.fogbugz.com/f/cases/19600 http://files.pharo.org/image/60/60357.zip

Jan. 26, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60357 Home: https://github.com/pharo-project/pharo-core

Jan. 26, 2017

Re: [Pharo-dev] Immutability support

by Denis Kudriashov

2017-01-26 10:59 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > Let's rewrite the method this way: > > attemptToAssign: value withIndex: index > | process | > "INSERT CODE HERE" > process := Processor activeProcess. > [ process suspendedContext: process suspendedContext sender ] fork. > Processor yield. > self error: 'should not be reached'. > I guess I found simplest solution to problem. Instead of process logic we can just use "thisContext sender jump". attemptToAssign: value withIndex: index | process | thisContext sender jump. self error: 'should not be reached'. In my tests it works correctly. I use this method: ValueHolder>>contents2: anObject | result | result := (contents := anObject). self halt. ^result printString. So debugger is opened at halt. And #result var contains anObject.

Jan. 26, 2017

Re: [Pharo-dev] Immutability support

by Denis Kudriashov

2017-01-26 10:59 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > Let's rewrite the method this way: > > attemptToAssign: value withIndex: index > | process | > "INSERT CODE HERE" > process := Processor activeProcess. > [ process suspendedContext: process suspendedContext sender ] fork. > Processor yield. > self error: 'should not be reached'. > > This way it's clear that execution flow never reaches the end of the > method as the error message is never sent. For some reason in the previous > code by increasing the priority of the process the end of the method could > be reached, as Denis showed, which leaded to incorrect behavior. This is > still hackish and we still need to provide a better way of performing such > returns. > > Any code can be written at the "INSERT CODE HERE" position, including > exception signals, etc. > > Normal methods ends with a return, for example, "^ self". When performed, > "^ self" pushes "self" on the sender's stack and resumes execution in the > sender. In this call-back, when reaching the end of the method, the > sender's execution needs to be resumed, but no value needs to be pushed on > its stack. That's why instead of a normal return I use: > process := Processor activeProcess. > [ process suspendedContext: process suspendedContext sender ] fork. > Processor yield. > I don't know how to explain it better. I understand that because it was > bugged it was very hard to understand. I will put a slice on the bug > tracker. > Thank's Clement. Now I understand it.

Jan. 26, 2017

Re: [Pharo-dev] Immutability support

by Stefan Marr

Hi Clement: > On 26 Jan 2017, at 10:59, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Let's rewrite the method this way: > > attemptToAssign: value withIndex: index > | process | > "INSERT CODE HERE" > process := Processor activeProcess. > [ process suspendedContext: process suspendedContext sender ] fork. > Processor yield. > self error: âshould not be reached'. The PRocessorScheduler>>#yield does not guarantee that this process becomes never runnable again. It just puts the processes at the end of the runnable list. The fallback code of yield even explicitly forks another processes thatâs signaling the old process again to make it runnable. Best regards Stefan -- Stefan Marr Johannes Kepler UniversitÃ¤t Linz http://stefan-marr.de/research/

Jan. 26, 2017

Re: [Pharo-dev] Immutability support

by ClÃ©ment Bera

Let's rewrite the method this way: attemptToAssign: value withIndex: index | process | "INSERT CODE HERE" process := Processor activeProcess. [ process suspendedContext: process suspendedContext sender ] fork. Processor yield. self error: 'should not be reached'. This way it's clear that execution flow never reaches the end of the method as the error message is never sent. For some reason in the previous code by increasing the priority of the process the end of the method could be reached, as Denis showed, which leaded to incorrect behavior. This is still hackish and we still need to provide a better way of performing such returns. Any code can be written at the "INSERT CODE HERE" position, including exception signals, etc. Normal methods ends with a return, for example, "^ self". When performed, "^ self" pushes "self" on the sender's stack and resumes execution in the sender. In this call-back, when reaching the end of the method, the sender's execution needs to be resumed, but no value needs to be pushed on its stack. That's why instead of a normal return I use: process := Processor activeProcess. [ process suspendedContext: process suspendedContext sender ] fork. Processor yield. I don't know how to explain it better. I understand that because it was bugged it was very hard to understand. I will put a slice on the bug tracker. On Thu, Jan 26, 2017 at 10:35 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > *Sorry Clement, maybe I am stupid but it is not clear for me.* > > *If I put halt after "CAN'T REACH" I got debugger which means that it "can > reach".* > *Maybe by "CAN'T REACH" you mean that any return value will not be used? > But it is not true: if I return something it will be result of original > assignment expression. But as you said it could crash VM.* > > Ok I tried and I can see that. This is why I have bugs. Well "CAN'T REACH" > was supposed to mean it cannot be reached, I don't understand how it could > be reached. > > > On Thu, Jan 26, 2017 at 10:18 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> >> 2017-01-26 8:11 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >> >>> The "CAN'T REACH" comment is there because execution never reach that >>> part of the code. If you write code there, it will never be executed. The >>> process code performs a return without pushing any value on stack. >>> >> >> Sorry Clement, maybe I am stupid but it is not clear for me. >> If I put halt after "CAN'T REACH" I got debugger which means that it "can >> reach". >> Maybe by "CAN'T REACH" you mean that any return value will not be used? >> But it is not true: if I return something it will be result of original >> assignment expression. But as you said it could crash VM. >> >> >>> >>> Signalling an error is safe if the error is never resumed. But you'll >>> need the returnNoValue for performance intensive modification tracking. >>> >> >> Do you have reproducible test case to crash VM when #attemptToAssign is >> badly implemented? It will help for framework implementation and would be >> nice description for method. In comment we can point to it. Because this >> magic with forking process is very confusing. >> Also I not get your "returnNoValue" sentence. >> > >

Jan. 26, 2017

Re: [Pharo-dev] Immutability support

by Norbert Hartl

> Am 26.01.2017 um 10:32 schrieb ClÃ©ment Bera <bera.clement(a)gmail.com>: > > > > On Thu, Jan 26, 2017 at 9:54 AM, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: > >> Am 26.01.2017 um 08:11 schrieb ClÃ©ment Bera <bera.clement(a)gmail.com <mailto:bera.clement@gmail.com>>: >> >> The "CAN'T REACH" comment is there because execution never reach that part of the code. If you write code there, it will never be executed. The process code performs a return without pushing any value on stack. >> > Because you return from the sender, right? > > Yes because the process code returns to the sender. > > In Smalltalk a send returns necessarily a value to be pushed on the stack of the context performing the send. In the write barrier call-back, the context is not performing a send, but an instance variable store. Unlike sends, instance variable stores are not expected to push a value on stack. If the call-back returns a value, it's pushed on stack while nothing is expected, and if further code use values on stack it will use the returned value instead of the correct one, furthermore, stack depth computation is messed up, overflowing the context stack somewhere in the runtime memory leading to data corruption. I see. I'm not sure I understand it correctly. But isn't it the case that you return the value of attemptToAssign:index: as return value of the sender? In the current implementation it will return self. This would break any method with instVar access that do not return self. >> Signalling an error is safe if the error is never resumed. But you'll need the returnNoValue for performance intensive modification tracking. >> >> > Ok, while you are popping of the stack there is no way to return, right? I cannot see what it has to be that way but I can see that my approach cannot work this way. In my case the error is resumed because not resuming would defeat the purpose of having transparent modification tracking. > > I'll use announcements for it because it is a better fit for that anyway. > > You can signal an error, but then keep the process code. For example: > > Object>>#attemptToAssign: value withIndex: index > | process | > NoModification signal. > process := Processor activeProcess. > [ process suspendedContext: process suspendedContext sender ] forkAt: Processor activePriority + 1. > Processor yield. > > this method just works fine. > > However, > > Object>>#attemptToAssign: value withIndex: index > NoModification signal. > > this method does not work because it returns a value. > Ok, thanks. Norbert > > Norbert > >> >> On Wed, Jan 25, 2017 at 10:26 PM, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >> >> 2017-01-25 22:24 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: >> For the Process hack, it's because the call-back was designed to return no value. >> >> Now I am confused. >> Why anybody needs to return value from this method? >> And why there is "CAN'T REACH" comment at the end of method? >> Do you mean that method should never return? >> >> It may look like it works when returning a value but you will have uncommon crashes. >> >> And is it safe to just signal error? >> > >

Jan. 26, 2017

Re: [Pharo-dev] Immutability support

by ClÃ©ment Bera

*Sorry Clement, maybe I am stupid but it is not clear for me.* *If I put halt after "CAN'T REACH" I got debugger which means that it "can reach".* *Maybe by "CAN'T REACH" you mean that any return value will not be used? But it is not true: if I return something it will be result of original assignment expression. But as you said it could crash VM.* Ok I tried and I can see that. This is why I have bugs. Well "CAN'T REACH" was supposed to mean it cannot be reached, I don't understand how it could be reached. On Thu, Jan 26, 2017 at 10:18 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-01-26 8:11 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > >> The "CAN'T REACH" comment is there because execution never reach that >> part of the code. If you write code there, it will never be executed. The >> process code performs a return without pushing any value on stack. >> > > Sorry Clement, maybe I am stupid but it is not clear for me. > If I put halt after "CAN'T REACH" I got debugger which means that it "can > reach". > Maybe by "CAN'T REACH" you mean that any return value will not be used? > But it is not true: if I return something it will be result of original > assignment expression. But as you said it could crash VM. > > >> >> Signalling an error is safe if the error is never resumed. But you'll >> need the returnNoValue for performance intensive modification tracking. >> > > Do you have reproducible test case to crash VM when #attemptToAssign is > badly implemented? It will help for framework implementation and would be > nice description for method. In comment we can point to it. Because this > magic with forking process is very confusing. > Also I not get your "returnNoValue" sentence. >

Jan. 26, 2017

Re: [Pharo-dev] Immutability support

by ClÃ©ment Bera

On Thu, Jan 26, 2017 at 9:54 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 26.01.2017 um 08:11 schrieb ClÃ©ment Bera <bera.clement(a)gmail.com>: > > The "CAN'T REACH" comment is there because execution never reach that part > of the code. If you write code there, it will never be executed. The > process code performs a return without pushing any value on stack. > > Because you return from the sender, right? > Yes because the process code returns to the sender. In Smalltalk a send returns necessarily a value to be pushed on the stack of the context performing the send. In the write barrier call-back, the context is not performing a send, but an instance variable store. Unlike sends, instance variable stores are not expected to push a value on stack. If the call-back returns a value, it's pushed on stack while nothing is expected, and if further code use values on stack it will use the returned value instead of the correct one, furthermore, stack depth computation is messed up, overflowing the context stack somewhere in the runtime memory leading to data corruption. > Signalling an error is safe if the error is never resumed. But you'll need > the returnNoValue for performance intensive modification tracking. > > > Ok, while you are popping of the stack there is no way to return, right? I > cannot see what it has to be that way but I can see that my approach cannot > work this way. In my case the error is resumed because not resuming would > defeat the purpose of having transparent modification tracking. > > I'll use announcements for it because it is a better fit for that anyway. > You can signal an error, but then keep the process code. For example: Object>>#attemptToAssign: value withIndex: index | process | NoModification signal. process := Processor activeProcess. [ process suspendedContext: process suspendedContext sender ] forkAt: Processor activePriority + 1. Processor yield. this method just works fine. However, Object>>#attemptToAssign: value withIndex: index NoModification signal. this method does not work because it returns a value. > Norbert > > > On Wed, Jan 25, 2017 at 10:26 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> >> 2017-01-25 22:24 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >>> For the Process hack, it's because the call-back was designed to return >>>> no value. >>> >>> >>> Now I am confused. >>> Why anybody needs to return value from this method? >>> And why there is "CAN'T REACH" comment at the end of method? >>> Do you mean that method should never return? >>> >>> >>>> It may look like it works when returning a value but you will have >>>> uncommon crashes. >>> >>> >> And is it safe to just signal error? >> > > >

Jan. 26, 2017

Re: [Pharo-dev] Immutability support

by Denis Kudriashov

2017-01-26 8:11 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > The "CAN'T REACH" comment is there because execution never reach that part > of the code. If you write code there, it will never be executed. The > process code performs a return without pushing any value on stack. > Sorry Clement, maybe I am stupid but it is not clear for me. If I put halt after "CAN'T REACH" I got debugger which means that it "can reach". Maybe by "CAN'T REACH" you mean that any return value will not be used? But it is not true: if I return something it will be result of original assignment expression. But as you said it could crash VM. > > Signalling an error is safe if the error is never resumed. But you'll need > the returnNoValue for performance intensive modification tracking. > Do you have reproducible test case to crash VM when #attemptToAssign is badly implemented? It will help for framework implementation and would be nice description for method. In comment we can point to it. Because this magic with forking process is very confusing. Also I not get your "returnNoValue" sentence.

Jan. 26, 2017