- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] OCASTTranslator forValue/forEffect

by Nicolai Hess

2016-12-05 10:55 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Can we collect this as a nice class comment? > Yes, I 'll try to add this as class comment. > > On Mon, Dec 5, 2016 at 10:42 AM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >> >> >> 2016-12-05 10:08 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >> >>> Both are used for each compilation. They're instance variables of each >>> other. >>> >>> | *Who decides which to use* >>> >>> In each AST node translation, you know for each value which one to use. >>> >>> For example, when translating a return, the value to return needs to be >>> pushed on stack, so the valueTranslator is used: >>> visitReturnNode: aReturnNode >>> valueTranslator visitNode: aReturnNode value. >>> methodBuilder returnTop. >>> >>> Yet, in #visitMethodNode:, you can see that the effectTranslator is >>> used, because no value is pushed on stack at the end of the method body: >>> ...effectTranslator visitNode: aMethodNode body... >>> >>> Then some behavior can be conditional, for example, in OCASTTranslator >>> >> #visitArrayNode: >>> ...^ self visitLargeArrayNode: anArrayNode ]... >>> The self here represents either the value or effect translator and >>> dispatches to the correct method using polymorphism. >>> >>> *| when do I know that I need to use ?* >>> >>> If you need the value on stack, use the valueTranslator. >>> If you need the effect but not the value, use the effectTranslator. >>> >>> If you're implementing something in the valueTranslator, it needs to >>> push something on stack at the end. >>> If you're implementing something in the effectTranslator, it doesn't >>> push anything on stack at the end. >>> >>> | * the effect translator only or the value translator?* >>> >>> I think you always need both.Let's take this method: >>> >>> MyClass>>return1 >>> ^ 42.0 >>> >>> The method uses the effect translator to translate is body (^ 42.0). >>> The body is a sequence node, with one statement only. A sequence node >>> translates all its statements for effect, except the last one which depends >>> on how it's called (in this case, it's called with the effectTranslator, so >>> it's also for effect). Sequence translated for value are used in inlined >>> control structures. >>> So the first statement is translated for effect. >>> The return node asks first the value translator to push the float (42.0) >>> on stack, generating pushLiteral: 42.0 >>> Then the return node generates the returnTop instruction. >>> >>> ** >>> >>> I don't know how to explain better. I like to think of this problem as >>> the difference between procedures and functions in old programming >>> languages. >>> >> >> Thank you clement, this helped a lot. >> >> Some background why I am asking: >> >> http://forum.world.st/Stack-underflow-with-meta-links-on-mes >> sage-nodes-tp4925154.html >> >> Adding a "before" metalink to a message node like "1+1" and trying use a >> the receiver value within the metalink >> will raise a stack underflow error. >> This is caused by the RFEReceiverReification, it will pop the arguments >> of the stack, to access the receiver. It will >> create temporaries for the popped arguments and expects this temporaries >> to be pushed on to the stack again, after storing the >> receiver value. >> But this does not work (the arguments aren't pushed back). >> It works if we assign this metalink to a return node *value*, the "1+1" in >> ^ 1 + 1 >> >> Now there is no stack underflow, because the return node value uses the >> valueTranslator that does do the pushTemp, as expected by the >> RFEReceiverReification. >> (Best seen by comparing both IRs. >> First, link is attached to a message that is not a return statement: >> >> label: 1 >> pushLiteral: '1' >> pushLiteral: '1' >> popIntoTemp: #RFArg1RFReification >> storeTemp: #RFReceiverReificationVar >> pushLiteralVariable: RFMetaLink >> pushTemp: #RFReceiverReificationVar >> pushLiteral: RBMessageNode('1' , '1') >> send: #value:value: >> popTop >> send: #, >> popTop >> returnReceiver >> >> Next, if the link is attached to the expression of a return statement: >> >> label: 1 >> pushLiteral: '1' >> pushLiteral: '1' >> popIntoTemp: #RFArg1RFReification >> storeTemp: #RFReceiverReificationVar >> pushTemp: #RFArg1RFReification "<<<- this is >> missing in the other IR" >> pushLiteralVariable: RFMetaLink >> pushTemp: #RFReceiverReificationVar >> pushLiteral: RBMessageNode('1' , '1') >> send: #value:value: >> popTop >> send: #, >> returnTop >> >> >> Solution ? >> >> @Marcus, >> can we *always* use the valueTranslator when visiting a link preamble ? >> (I tried this, the above method now works, and all tests are green, but I >> am not sure if this is the right solution). >> >> nicolai >> >> >> >>> >>> On Mon, Dec 5, 2016 at 9:36 AM, Nicolai Hess <nicolaihess(a)gmail.com> >>> wrote: >>> >>>> >>>> >>>> 2016-12-05 8:51 GMT+01:00 Nicolas Cellier < >>>> nicolas.cellier.aka.nice(a)gmail.com>: >>>> >>>>> Translate AST to byte codes? >>>>> >>>> >>>> (For opal, this first creates the intermediate representation (IR), but >>>> yes translating from AST to (finally) byte codes) >>>> >>>> >>>>> One for the case when we don't care of the result (we will pop it off >>>>> the stack), we just want the effect. >>>>> >>>> >>>> Ok. >>>> >>>> >>>>> The other case when we want to keep the resulting value on the stack. >>>>> >>>> >>>> Who decides which to use, when do I know that I need to use, the effect >>>> translator only or the value translator? >>>> >>>> >>>>> >>>>> 2016-12-05 8:47 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>> >>>>>> Hi, >>>>>> >>>>>> I need a short description for what the OCASTTranslator subclasses >>>>>> OCASTTranslatorForEffect >>>>>> OCASTTranslatorForValue >>>>>> are. >>>>>> >>>>>> I don't fully understand the usage. >>>>>> >>>>>> thanks in advance >>>>>> Nicolai >>>>>> >>>>>> >>>>> >>>> >>> >> >

Dec. 5, 2016

Re: [Pharo-dev] OCASTTranslator forValue/forEffect

by Stephane Ducasse

Can we collect this as a nice class comment? On Mon, Dec 5, 2016 at 10:42 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > 2016-12-05 10:08 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > >> Both are used for each compilation. They're instance variables of each >> other. >> >> | *Who decides which to use* >> >> In each AST node translation, you know for each value which one to use. >> >> For example, when translating a return, the value to return needs to be >> pushed on stack, so the valueTranslator is used: >> visitReturnNode: aReturnNode >> valueTranslator visitNode: aReturnNode value. >> methodBuilder returnTop. >> >> Yet, in #visitMethodNode:, you can see that the effectTranslator is used, >> because no value is pushed on stack at the end of the method body: >> ...effectTranslator visitNode: aMethodNode body... >> >> Then some behavior can be conditional, for example, in OCASTTranslator >> >> #visitArrayNode: >> ...^ self visitLargeArrayNode: anArrayNode ]... >> The self here represents either the value or effect translator and >> dispatches to the correct method using polymorphism. >> >> *| when do I know that I need to use ?* >> >> If you need the value on stack, use the valueTranslator. >> If you need the effect but not the value, use the effectTranslator. >> >> If you're implementing something in the valueTranslator, it needs to push >> something on stack at the end. >> If you're implementing something in the effectTranslator, it doesn't push >> anything on stack at the end. >> >> | * the effect translator only or the value translator?* >> >> I think you always need both.Let's take this method: >> >> MyClass>>return1 >> ^ 42.0 >> >> The method uses the effect translator to translate is body (^ 42.0). >> The body is a sequence node, with one statement only. A sequence node >> translates all its statements for effect, except the last one which depends >> on how it's called (in this case, it's called with the effectTranslator, so >> it's also for effect). Sequence translated for value are used in inlined >> control structures. >> So the first statement is translated for effect. >> The return node asks first the value translator to push the float (42.0) >> on stack, generating pushLiteral: 42.0 >> Then the return node generates the returnTop instruction. >> >> ** >> >> I don't know how to explain better. I like to think of this problem as >> the difference between procedures and functions in old programming >> languages. >> > > Thank you clement, this helped a lot. > > Some background why I am asking: > > http://forum.world.st/Stack-underflow-with-meta-links-on- > message-nodes-tp4925154.html > > Adding a "before" metalink to a message node like "1+1" and trying use a > the receiver value within the metalink > will raise a stack underflow error. > This is caused by the RFEReceiverReification, it will pop the arguments of > the stack, to access the receiver. It will > create temporaries for the popped arguments and expects this temporaries > to be pushed on to the stack again, after storing the > receiver value. > But this does not work (the arguments aren't pushed back). > It works if we assign this metalink to a return node *value*, the "1+1" in > ^ 1 + 1 > > Now there is no stack underflow, because the return node value uses the > valueTranslator that does do the pushTemp, as expected by the > RFEReceiverReification. > (Best seen by comparing both IRs. > First, link is attached to a message that is not a return statement: > > label: 1 > pushLiteral: '1' > pushLiteral: '1' > popIntoTemp: #RFArg1RFReification > storeTemp: #RFReceiverReificationVar > pushLiteralVariable: RFMetaLink > pushTemp: #RFReceiverReificationVar > pushLiteral: RBMessageNode('1' , '1') > send: #value:value: > popTop > send: #, > popTop > returnReceiver > > Next, if the link is attached to the expression of a return statement: > > label: 1 > pushLiteral: '1' > pushLiteral: '1' > popIntoTemp: #RFArg1RFReification > storeTemp: #RFReceiverReificationVar > pushTemp: #RFArg1RFReification "<<<- this is > missing in the other IR" > pushLiteralVariable: RFMetaLink > pushTemp: #RFReceiverReificationVar > pushLiteral: RBMessageNode('1' , '1') > send: #value:value: > popTop > send: #, > returnTop > > > Solution ? > > @Marcus, > can we *always* use the valueTranslator when visiting a link preamble ? > (I tried this, the above method now works, and all tests are green, but I > am not sure if this is the right solution). > > nicolai > > > >> >> On Mon, Dec 5, 2016 at 9:36 AM, Nicolai Hess <nicolaihess(a)gmail.com> >> wrote: >> >>> >>> >>> 2016-12-05 8:51 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai >>> l.com>: >>> >>>> Translate AST to byte codes? >>>> >>> >>> (For opal, this first creates the intermediate representation (IR), but >>> yes translating from AST to (finally) byte codes) >>> >>> >>>> One for the case when we don't care of the result (we will pop it off >>>> the stack), we just want the effect. >>>> >>> >>> Ok. >>> >>> >>>> The other case when we want to keep the resulting value on the stack. >>>> >>> >>> Who decides which to use, when do I know that I need to use, the effect >>> translator only or the value translator? >>> >>> >>>> >>>> 2016-12-05 8:47 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>> >>>>> Hi, >>>>> >>>>> I need a short description for what the OCASTTranslator subclasses >>>>> OCASTTranslatorForEffect >>>>> OCASTTranslatorForValue >>>>> are. >>>>> >>>>> I don't fully understand the usage. >>>>> >>>>> thanks in advance >>>>> Nicolai >>>>> >>>>> >>>> >>> >> >

Dec. 5, 2016

Re: [Pharo-dev] OCASTTranslator forValue/forEffect

by Nicolai Hess

2016-12-05 10:08 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > Both are used for each compilation. They're instance variables of each > other. > > | *Who decides which to use* > > In each AST node translation, you know for each value which one to use. > > For example, when translating a return, the value to return needs to be > pushed on stack, so the valueTranslator is used: > visitReturnNode: aReturnNode > valueTranslator visitNode: aReturnNode value. > methodBuilder returnTop. > > Yet, in #visitMethodNode:, you can see that the effectTranslator is used, > because no value is pushed on stack at the end of the method body: > ...effectTranslator visitNode: aMethodNode body... > > Then some behavior can be conditional, for example, in OCASTTranslator >> > #visitArrayNode: > ...^ self visitLargeArrayNode: anArrayNode ]... > The self here represents either the value or effect translator and > dispatches to the correct method using polymorphism. > > *| when do I know that I need to use ?* > > If you need the value on stack, use the valueTranslator. > If you need the effect but not the value, use the effectTranslator. > > If you're implementing something in the valueTranslator, it needs to push > something on stack at the end. > If you're implementing something in the effectTranslator, it doesn't push > anything on stack at the end. > > | * the effect translator only or the value translator?* > > I think you always need both.Let's take this method: > > MyClass>>return1 > ^ 42.0 > > The method uses the effect translator to translate is body (^ 42.0). > The body is a sequence node, with one statement only. A sequence node > translates all its statements for effect, except the last one which depends > on how it's called (in this case, it's called with the effectTranslator, so > it's also for effect). Sequence translated for value are used in inlined > control structures. > So the first statement is translated for effect. > The return node asks first the value translator to push the float (42.0) > on stack, generating pushLiteral: 42.0 > Then the return node generates the returnTop instruction. > > ** > > I don't know how to explain better. I like to think of this problem as the > difference between procedures and functions in old programming languages. > Thank you clement, this helped a lot. Some background why I am asking: http://forum.world.st/Stack-underflow-with-meta-links-on-message-nodes-tp49… Adding a "before" metalink to a message node like "1+1" and trying use a the receiver value within the metalink will raise a stack underflow error. This is caused by the RFEReceiverReification, it will pop the arguments of the stack, to access the receiver. It will create temporaries for the popped arguments and expects this temporaries to be pushed on to the stack again, after storing the receiver value. But this does not work (the arguments aren't pushed back). It works if we assign this metalink to a return node *value*, the "1+1" in ^ 1 + 1 Now there is no stack underflow, because the return node value uses the valueTranslator that does do the pushTemp, as expected by the RFEReceiverReification. (Best seen by comparing both IRs. First, link is attached to a message that is not a return statement: label: 1 pushLiteral: '1' pushLiteral: '1' popIntoTemp: #RFArg1RFReification storeTemp: #RFReceiverReificationVar pushLiteralVariable: RFMetaLink pushTemp: #RFReceiverReificationVar pushLiteral: RBMessageNode('1' , '1') send: #value:value: popTop send: #, popTop returnReceiver Next, if the link is attached to the expression of a return statement: label: 1 pushLiteral: '1' pushLiteral: '1' popIntoTemp: #RFArg1RFReification storeTemp: #RFReceiverReificationVar pushTemp: #RFArg1RFReification "<<<- this is missing in the other IR" pushLiteralVariable: RFMetaLink pushTemp: #RFReceiverReificationVar pushLiteral: RBMessageNode('1' , '1') send: #value:value: popTop send: #, returnTop Solution ? @Marcus, can we *always* use the valueTranslator when visiting a link preamble ? (I tried this, the above method now works, and all tests are green, but I am not sure if this is the right solution). nicolai > > On Mon, Dec 5, 2016 at 9:36 AM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >> >> >> 2016-12-05 8:51 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai >> l.com>: >> >>> Translate AST to byte codes? >>> >> >> (For opal, this first creates the intermediate representation (IR), but >> yes translating from AST to (finally) byte codes) >> >> >>> One for the case when we don't care of the result (we will pop it off >>> the stack), we just want the effect. >>> >> >> Ok. >> >> >>> The other case when we want to keep the resulting value on the stack. >>> >> >> Who decides which to use, when do I know that I need to use, the effect >> translator only or the value translator? >> >> >>> >>> 2016-12-05 8:47 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>> >>>> Hi, >>>> >>>> I need a short description for what the OCASTTranslator subclasses >>>> OCASTTranslatorForEffect >>>> OCASTTranslatorForValue >>>> are. >>>> >>>> I don't fully understand the usage. >>>> >>>> thanks in advance >>>> Nicolai >>>> >>>> >>> >> >

Dec. 5, 2016

Re: [Pharo-dev] OCASTTranslator forValue/forEffect

by ClÃ©ment Bera

Both are used for each compilation. They're instance variables of each other. | *Who decides which to use* In each AST node translation, you know for each value which one to use. For example, when translating a return, the value to return needs to be pushed on stack, so the valueTranslator is used: visitReturnNode: aReturnNode valueTranslator visitNode: aReturnNode value. methodBuilder returnTop. Yet, in #visitMethodNode:, you can see that the effectTranslator is used, because no value is pushed on stack at the end of the method body: ...effectTranslator visitNode: aMethodNode body... Then some behavior can be conditional, for example, in OCASTTranslator >> #visitArrayNode: ...^ self visitLargeArrayNode: anArrayNode ]... The self here represents either the value or effect translator and dispatches to the correct method using polymorphism. *| when do I know that I need to use ?* If you need the value on stack, use the valueTranslator. If you need the effect but not the value, use the effectTranslator. If you're implementing something in the valueTranslator, it needs to push something on stack at the end. If you're implementing something in the effectTranslator, it doesn't push anything on stack at the end. | * the effect translator only or the value translator?* I think you always need both.Let's take this method: MyClass>>return1 ^ 42.0 The method uses the effect translator to translate is body (^ 42.0). The body is a sequence node, with one statement only. A sequence node translates all its statements for effect, except the last one which depends on how it's called (in this case, it's called with the effectTranslator, so it's also for effect). Sequence translated for value are used in inlined control structures. So the first statement is translated for effect. The return node asks first the value translator to push the float (42.0) on stack, generating pushLiteral: 42.0 Then the return node generates the returnTop instruction. ** I don't know how to explain better. I like to think of this problem as the difference between procedures and functions in old programming languages. On Mon, Dec 5, 2016 at 9:36 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > 2016-12-05 8:51 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com>: > >> Translate AST to byte codes? >> > > (For opal, this first creates the intermediate representation (IR), but > yes translating from AST to (finally) byte codes) > > >> One for the case when we don't care of the result (we will pop it off the >> stack), we just want the effect. >> > > Ok. > > >> The other case when we want to keep the resulting value on the stack. >> > > Who decides which to use, when do I know that I need to use, the effect > translator only or the value translator? > > >> >> 2016-12-05 8:47 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> >>> Hi, >>> >>> I need a short description for what the OCASTTranslator subclasses >>> OCASTTranslatorForEffect >>> OCASTTranslatorForValue >>> are. >>> >>> I don't fully understand the usage. >>> >>> thanks in advance >>> Nicolai >>> >>> >> >

Dec. 5, 2016

[pharo-project/pharo-core]

by GitHub

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

Dec. 5, 2016

[pharo-project/pharo-core] b609c1: 60316

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: b609c15965d52acf119f3912127d7d6c9925fbfd https://github.com/pharo-project/pharo-core/commit/b609c15965d52acf119f3912… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-12-05 (Mon, 05 Dec 2016) Changed paths: A GT-InspectorExtensions-Core.package/extension/Collection/instance/gtCollectionSizeThreshold.st M GT-InspectorExtensions-Core.package/extension/Collection/instance/gtDisplayOn_.st M GT-InspectorExtensions-Core.package/extension/SequenceableCollection/instance/gtInspectorItemsIn_.st M GT-SpotterExtensions-Core.package/extension/Collection/instance/spotterItemsFor_.st M Rubric.package/RubSmalltalkCodeMode.class/class/menu/menuOn_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60315.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60316.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60315.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60316.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Core.package/TextModel.class/instance/api/accept_notifying_.st Log Message: ----------- 60316 19418 Spec TextModel editor has broken cancel operation after first accept https://pharo.fogbugz.com/f/cases/19418 19413 GTInspector/Debugger do not work for large/ toolarge intervals https://pharo.fogbugz.com/f/cases/19413 19420 redu menu item is wrong and not working for rubric https://pharo.fogbugz.com/f/cases/19420 http://files.pharo.org/image/60/60316.zip

Dec. 5, 2016

Re: [Pharo-dev] OCASTTranslator forValue/forEffect

by Nicolai Hess

2016-12-05 8:51 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > Translate AST to byte codes? > (For opal, this first creates the intermediate representation (IR), but yes translating from AST to (finally) byte codes) > One for the case when we don't care of the result (we will pop it off the > stack), we just want the effect. > Ok. > The other case when we want to keep the resulting value on the stack. > Who decides which to use, when do I know that I need to use, the effect translator only or the value translator? > > 2016-12-05 8:47 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > >> Hi, >> >> I need a short description for what the OCASTTranslator subclasses >> OCASTTranslatorForEffect >> OCASTTranslatorForValue >> are. >> >> I don't fully understand the usage. >> >> thanks in advance >> Nicolai >> >> >

Dec. 5, 2016

Re: [Pharo-dev] OCASTTranslator forValue/forEffect

by ClÃ©ment Bera

On Mon, Dec 5, 2016 at 8:51 AM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > Translate AST to byte codes? > One for the case when we don't care of the result (we will pop it off the > stack), we just want the effect. > The other case when we want to keep the resulting value on the stack. > It translates AST to Opal's IR. And yes one uses one or the other if one wants only the effect and don't care about the result or if one cares about the result and the effect. > > 2016-12-05 8:47 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > >> Hi, >> >> I need a short description for what the OCASTTranslator subclasses >> OCASTTranslatorForEffect >> OCASTTranslatorForValue >> are. >> >> I don't fully understand the usage. >> >> thanks in advance >> Nicolai >> >> >

Dec. 5, 2016

Re: [Pharo-dev] OCASTTranslator forValue/forEffect

by Nicolas Cellier

Translate AST to byte codes? One for the case when we don't care of the result (we will pop it off the stack), we just want the effect. The other case when we want to keep the resulting value on the stack. 2016-12-05 8:47 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > Hi, > > I need a short description for what the OCASTTranslator subclasses > OCASTTranslatorForEffect > OCASTTranslatorForValue > are. > > I don't fully understand the usage. > > thanks in advance > Nicolai > >

Dec. 5, 2016

OCASTTranslator forValue/forEffect

by Nicolai Hess

Hi, I need a short description for what the OCASTTranslator subclasses OCASTTranslatorForEffect OCASTTranslatorForValue are. I don't fully understand the usage. thanks in advance Nicolai

Dec. 5, 2016