Environment-caused SyntaxError running build scripts (was Re: [squeak-dev] error when updating Squeak4.4-12327 to trunk)
Locked
Environment-caused SyntaxError running build scripts (was Re: [squeak-dev] error when updating Squeak4.4-12327 to trunk)
 
|
It is Environments, and it's _after_ the image is updated: first the
CI job runs update-image.st, copies this updated artifact, and in the copy runs prepare-test-image.st. That then fails because of a SyntaxError being thrown, saying this: DoIt Smalltalk at: #Log put: [:t1 | | t2 | t2 := #Invalid literal character ->#DateAndTime value now printString , ': ' , t1. FileStream stdout nextPutAll: t2; nextPut: Character lf; flush. ##Transcript value cr; show: t2]. Compare that to the original source, from prepare-test-image.st in the CI job: Smalltalk at: #Log put: [:msg | | str | str := DateAndTime now printString, ': ', msg. FileStream stdout nextPutAll: str; nextPut: Character lf; flush. Transcript cr; show: str]. Note the ## marks prepended to (some of) the class names. Colin? Thoughts? frank On 11 March 2013 22:55, Nicolas Cellier <[hidden email]> wrote: > Most likely Environments. > The Parser problem did crash well earlier. > > Nicolas > > 2013/3/11 Frank Shearar <[hidden email]>: >> They are hanging, and I haven't had a chance to run them by hand to >> see what's going wrong. It doesn't help that we have potentially three >> breaking things on the go right now: >> * the Parser issue >> * Environments upgrade >> * my snafu with deleting/readding classes (unlikely?) >> >> frank >> >> On 11 March 2013 22:10, Nicolas Cellier >> <[hidden email]> wrote: >>> Unfortunately, I can't check, all recent SqueakTrunk CI jobs seem to >>> hang (timeout after 15minutes). >>> There are quite many tests failing with last Environmental changes >>> (AttemptToWriteReadOnlyGlobal), and this might be related. >>> Should we increase the timeout, or is it something else that blocks the image? >>> >>> Nicolas >>> >>> 2013/3/10 Nicolas Cellier <[hidden email]>: >>>> I'm not sure exactly how to read the CI results, but I confirm that >>>> the update may fail, I experienced two trunk update failure starting >>>> at Squeak4.4-12327 on MacOS-X with latest COG VM. >>>> >>>> So I renewed my fix in Kernel-nice.747, changed updates 222 to 227 >>>> again, and will wait for the reports... >>>> >>>> Nicolas >>>> >>>> 2013/3/10 Frank Shearar <[hidden email]>: >>>>> http://build.squeak.org/job/SqueakTrunk-OSX/88/ shows things working, >>>>> and the trend shows that the Mac Cog seems to have always been OK. >>>>> >>>>> http://build.squeak.org/job/SqueakTrunk/212/ shows bad things still >>>>> happening with the Parser. If you look at the test history (show test >>>>> failures only on http://build.squeak.org/job/SqueakTrunk/) you'll see >>>>> this bug's biting hard - all the only-2-failing-test builds exhibit >>>>> the behaviour. >>>>> >>>>> (Why do the tests run at all when it's a failing update? I _think_ >>>>> that's because the build script is insufficiently suicidal, and ends >>>>> up running a TrunkImage from a previous build.) >>>>> >>>>> frank >>>>> >>>>> On 10 March 2013 19:10, Nicolas Cellier >>>>> <[hidden email]> wrote: >>>>>> OK, see the VM thread, I now think that problems does not come from >>>>>> COG, but from ClassBuilder which in some cases fail to clean a cache >>>>>> (primitive 116). >>>>>> The problem does not show up in interpreter VM thanks to primitive 119 >>>>>> (this primitives does not unlink send in cogit). >>>>>> I have attempted a ClassBuilder fix and posted new updates from >>>>>> nice-222 to cwp-227. >>>>>> >>>>>> Can I please ask our testers contribution once again? >>>>>> >>>>>> Nicolas >>>>>> >>>>>> 2013/3/8 Nicolas Cellier <[hidden email]>: >>>>>>> 2013/3/8 Bert Freudenberg <[hidden email]>: >>>>>>>> >>>>>>>> On 2013-03-08, at 10:55, Frank Shearar <[hidden email]> wrote: >>>>>>>> >>>>>>>>> On 7 March 2013 23:25, Frank Shearar <[hidden email]> wrote: >>>>>>>>>> On 7 March 2013 23:11, Bert Freudenberg <[hidden email]> wrote: >>>>>>>>>>> On 2013-03-07, at 23:42, Frank Shearar <[hidden email]> wrote: >>>>>>>>>>> >>>>>>>>>>>>>> On 6 March 2013 15:59, Ken G. Brown <[hidden email]> wrote: >>>>>>>>>>>>>>> Running on COG 2397, and after updating fresh Squeak4.4-12327 Release to >>>>>>>>>>>>>>> 12332, updating to Trunk fails at first attempt in the same place, then by >>>>>>>>>>>>>>> abandoning and trying the update again, it apparently completes to 12511. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Ken G. Brown >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> With COG 2678, pretty well the same. First attempt it timed out during >>>>>>>>>>>>>>>> the same update-nice-223, then trying again from what had already been >>>>>>>>>>>>>>>> loaded, got the following during the same update, during compiling >>>>>>>>>>>>>>>> SMLoader-fbs-78 as before: >>>>>>>>>>>> >>>>>>>>>>>> What I find strange about all this is that we take a 4.4-12327 image >>>>>>>>>>>> and whatever the latest Cog is and update it all the way without any >>>>>>>>>>>> probems quite a few times a day on the CI server. >>>>>>>>>>>> >>>>>>>>>>>> frank >>>>>>>>>>> >>>>>>>>>>> Looks like it's an intermittent problem, unfortunately: >>>>>>>>>>> >>>>>>>>>>> I just updated the new all-in-one-cog to latest trunk, no problem. This is a 4.4-12327 image with Cog VM 2697. >>>>>>>>>>> >>>>>>>>>>> I then tried what Ken described: update the fresh image first from the squeak44 stream, then switch to trunk, then update again. >>>>>>>>>>> >>>>>>>>>>> BOOM. Cog crash. Didn't save the log unfortunately. >>>>>>>>>>> >>>>>>>>>>> Tried again. Update, switch to trunk, update again. No crash. What?! >>>>>>>>>>> >>>>>>>>>>> Once more. Update, switch to trunk, update. Crash! See below. >>>>>>>>>>> >>>>>>>>>>> Tried yet again, with switching to trunk immediately in a fresh image. Crashes, too, same place. >>>>>>>>>>> >>>>>>>>>>> So it does crash, just not always. But it's been more than 50% in my case. >>>>>>>>>> >>>>>>>>>> Ah, interesting. The CI jobs, naturally, don't update from squeak44; >>>>>>>>>> they switch to trunk and update just like that. Which I would have >>>>>>>>>> thought would make no difference... >>>>>>>>> >>>>>>>>> Actually, I lie. Here's an example of the CI jobs hitting the same >>>>>>>>> issue: http://build.squeak.org/job/SqueakTrunk/204/console And further >>>>>>>>> if you look at http://build.squeak.org/job/SqueakTrunk/ and choose to >>>>>>>>> see the failing tests you'll see times (say around build #184) where >>>>>>>>> the test failure count is unusually low. And >>>>>>>>> http://build.squeak.org/job/SqueakTrunk/buildTimeTrend shows grey >>>>>>>>> streaks where builds die. >>>>>>>> >>>>>>>> Curious that it still runs the tests at all if the update failed ... >>>>>>>> >>>>>>>> So Cog crashes, but has someone tried to replicate this on an interpreter? >>>>>>>> >>>>>>>> - Bert - >>>>>>>> >>>>>>> >>>>>>> I think that the problem comes form COG which tries to use an obsolete >>>>>>> method sent AFTER the recompilation of Parser which is not the >>>>>>> expected behavior. >>>>>>> I have triggered such kind of strange behavior that does not happen on >>>>>>> an Interpreter VM, see the thread opened by Jeff Gonis '[Vm-dev] Cog >>>>>>> VM Crash on Windows' >>>>>>> For me, it must be related to a cache that is not cleaned-up, I don't know why. >>>>>>> >>>>>>> Nicolas >>>>>> >>>>> >>> >> > |
Re: Environment-caused SyntaxError running build scripts (was Re: [squeak-dev] error when updating Squeak4.4-12327 to trunk)
|
|
On 2013-03-12, at 00:11, Frank Shearar <[hidden email]> wrote: > It is Environments, and it's _after_ the image is updated: first the > CI job runs update-image.st, copies this updated artifact, and in the > copy runs prepare-test-image.st. That then fails because of a > SyntaxError being thrown, saying this: > > DoIt > Smalltalk > at: #Log > put: [:t1 | > | t2 | > t2 := #Invalid literal character ->#DateAndTime value now > printString , ': ' , t1. > FileStream stdout nextPutAll: t2; > nextPut: Character lf; > flush. > ##Transcript value cr; show: t2]. > > Compare that to the original source, from prepare-test-image.st in the CI job: > > Smalltalk at: #Log put: [:msg | | str | > str := DateAndTime now printString, ': ', msg. > FileStream stdout nextPutAll: str; nextPut: Character lf; flush. > Transcript cr; show: str]. > > Note the ## marks prepended to (some of) the class names. Colin? Thoughts? I've seen that too. It happens I think when code gets decompiled. - Bert - |
Re: Environment-caused SyntaxError running build scripts (was Re: [squeak-dev] error when updating Squeak4.4-12327 to trunk)
|
|
On 11 March 2013 23:13, Bert Freudenberg <[hidden email]> wrote:
> > On 2013-03-12, at 00:11, Frank Shearar <[hidden email]> wrote: > >> It is Environments, and it's _after_ the image is updated: first the >> CI job runs update-image.st, copies this updated artifact, and in the >> copy runs prepare-test-image.st. That then fails because of a >> SyntaxError being thrown, saying this: >> >> DoIt >> Smalltalk >> at: #Log >> put: [:t1 | >> | t2 | >> t2 := #Invalid literal character ->#DateAndTime value now >> printString , ': ' , t1. >> FileStream stdout nextPutAll: t2; >> nextPut: Character lf; >> flush. >> ##Transcript value cr; show: t2]. >> >> Compare that to the original source, from prepare-test-image.st in the CI job: >> >> Smalltalk at: #Log put: [:msg | | str | >> str := DateAndTime now printString, ': ', msg. >> FileStream stdout nextPutAll: str; nextPut: Character lf; flush. >> Transcript cr; show: str]. >> >> Note the ## marks prepended to (some of) the class names. Colin? Thoughts? > > I've seen that too. It happens I think when code gets decompiled. Odd, but I think I can imagine how it happens: Foo gets turned into a Symbol which is printed out as #Foo which then gets... printed out as a Symbol by something that thinks it has a String, resulting in ##Foo? And then something ELSE takes this broken source and tries to compile it. I guess? OK, stepping through, I can see it gets as far as Compiler >> #evaluate:cue:ifFailed:logged. There we turn the source into an AST (succeeds), and then compile that (succeeds)... but that CompiledMethod screws up decompilation, putting in the extra #s. I can't seem to step into MethodNode >> #generate:using: though to see what's going on. frank > - Bert - > > > |
Re: Environment-caused SyntaxError running build scripts (was Re: [squeak-dev] error when updating Squeak4.4-12327 to trunk)
|
|
Also note that DecompilerTests are now failing (in updated trunk after
update-cwp.227) Nicolas 2013/3/12 Frank Shearar <[hidden email]>: > On 11 March 2013 23:13, Bert Freudenberg <[hidden email]> wrote: >> >> On 2013-03-12, at 00:11, Frank Shearar <[hidden email]> wrote: >> >>> It is Environments, and it's _after_ the image is updated: first the >>> CI job runs update-image.st, copies this updated artifact, and in the >>> copy runs prepare-test-image.st. That then fails because of a >>> SyntaxError being thrown, saying this: >>> >>> DoIt >>> Smalltalk >>> at: #Log >>> put: [:t1 | >>> | t2 | >>> t2 := #Invalid literal character ->#DateAndTime value now >>> printString , ': ' , t1. >>> FileStream stdout nextPutAll: t2; >>> nextPut: Character lf; >>> flush. >>> ##Transcript value cr; show: t2]. >>> >>> Compare that to the original source, from prepare-test-image.st in the CI job: >>> >>> Smalltalk at: #Log put: [:msg | | str | >>> str := DateAndTime now printString, ': ', msg. >>> FileStream stdout nextPutAll: str; nextPut: Character lf; flush. >>> Transcript cr; show: str]. >>> >>> Note the ## marks prepended to (some of) the class names. Colin? Thoughts? >> >> I've seen that too. It happens I think when code gets decompiled. > > Odd, but I think I can imagine how it happens: Foo gets turned into a > Symbol which is printed out as #Foo which then gets... printed out as > a Symbol by something that thinks it has a String, resulting in ##Foo? > And then something ELSE takes this broken source and tries to compile > it. I guess? > > OK, stepping through, I can see it gets as far as Compiler >> > #evaluate:cue:ifFailed:logged. There we turn the source into an AST > (succeeds), and then compile that (succeeds)... but that > CompiledMethod screws up decompilation, putting in the extra #s. > > I can't seem to step into MethodNode >> #generate:using: though to see > what's going on. > > frank > >> - Bert - >> >> >> > |
Re: Environment-caused SyntaxError running build scripts (was Re: [squeak-dev] error when updating Squeak4.4-12327 to trunk)
|
|
This smells fishy:
LiteralNode >> printOn: aStream indent: level Transcript showln: 'ping'. key isVariableBinding ifTrue: [key key isNil ifTrue: [aStream nextPutAll: '###'; nextPutAll: key value soleInstance name] ifFalse: [aStream nextPutAll: '##'; nextPutAll: key key]] ifFalse: [key storeOn: aStream] Note the '##'. I don't mean _this_ guy's fishy; I think that key has changed somehow to be a `key isVariableBinding and: [key notNil]` kind of thing where it used to be a `key isVariableBinding not` thing. And _that_ would be because the latest version of Environments does funky stuff with class resolution. Yes? frank On 11 March 2013 23:31, Nicolas Cellier <[hidden email]> wrote: > Also note that DecompilerTests are now failing (in updated trunk after > update-cwp.227) > > Nicolas > > 2013/3/12 Frank Shearar <[hidden email]>: >> On 11 March 2013 23:13, Bert Freudenberg <[hidden email]> wrote: >>> >>> On 2013-03-12, at 00:11, Frank Shearar <[hidden email]> wrote: >>> >>>> It is Environments, and it's _after_ the image is updated: first the >>>> CI job runs update-image.st, copies this updated artifact, and in the >>>> copy runs prepare-test-image.st. That then fails because of a >>>> SyntaxError being thrown, saying this: >>>> >>>> DoIt >>>> Smalltalk >>>> at: #Log >>>> put: [:t1 | >>>> | t2 | >>>> t2 := #Invalid literal character ->#DateAndTime value now >>>> printString , ': ' , t1. >>>> FileStream stdout nextPutAll: t2; >>>> nextPut: Character lf; >>>> flush. >>>> ##Transcript value cr; show: t2]. >>>> >>>> Compare that to the original source, from prepare-test-image.st in the CI job: >>>> >>>> Smalltalk at: #Log put: [:msg | | str | >>>> str := DateAndTime now printString, ': ', msg. >>>> FileStream stdout nextPutAll: str; nextPut: Character lf; flush. >>>> Transcript cr; show: str]. >>>> >>>> Note the ## marks prepended to (some of) the class names. Colin? Thoughts? >>> >>> I've seen that too. It happens I think when code gets decompiled. >> >> Odd, but I think I can imagine how it happens: Foo gets turned into a >> Symbol which is printed out as #Foo which then gets... printed out as >> a Symbol by something that thinks it has a String, resulting in ##Foo? >> And then something ELSE takes this broken source and tries to compile >> it. I guess? >> >> OK, stepping through, I can see it gets as far as Compiler >> >> #evaluate:cue:ifFailed:logged. There we turn the source into an AST >> (succeeds), and then compile that (succeeds)... but that >> CompiledMethod screws up decompilation, putting in the extra #s. >> >> I can't seem to step into MethodNode >> #generate:using: though to see >> what's going on. >> >> frank >> >>> - Bert - >>> >>> >>> >> > |
Re: Environment-caused SyntaxError running build scripts (was Re: [squeak-dev] error when updating Squeak4.4-12327 to trunk)
|
|
On Mon, Mar 11, 2013 at 4:39 PM, Frank Shearar <[hidden email]> wrote: This smells fishy: Yeah, sounds right. I'm trying to reproduce now. Colin |
Re: Environment-caused SyntaxError running build scripts (was Re: [squeak-dev] error when updating Squeak4.4-12327 to trunk)
|
|
In reply to this post by Frank Shearar-3
On Mon, Mar 11, 2013 at 4:39 PM, Frank Shearar <[hidden email]> wrote: And _that_ would be because the latest version of Environments does Yes. There are actually two bugs here: The first is that Environment>>at:put: doesn't pull existing bindings out of Undeclared. Here's what happens: the Doit in prepare-test-image.st looks basically like this:
When this code is compiled, the reference to Log on line 2 is undeclared. Then execution starts, and line 1 does an assignment to Log though sneaky reflection, rather than assignment. SystemDictionary overrides #at:put: to make sure this works, but Environments doesn't, so the binding on line 2 isn't affected. Then we execute line 2, and send #value: to nil, which raises a MNU.
We get a debugger, click on the DoIt frame to see what happened, and boom, a syntax error. The DoIt doesn't have a source pointer, because the code is in a .st file, so we need to decompile it. The new binding classes in Environments don't support decompilation well, so it produces invalid source. I'm not sure why we're reparsing decompiled code, but clearly it's not working.
I should be able to just commit fixes to the trunk, since this doesn't break updating, just building the test image. Colin |
Re: Environment-caused SyntaxError running build scripts (was Re: [squeak-dev] error when updating Squeak4.4-12327 to trunk)
|
|
In reply to this post by Frank Shearar-3
On Mon, Mar 11, 2013 at 4:22 PM, Frank Shearar <[hidden email]> wrote:
No. Its arguably a bug but a binding will print itself as the Symbol key. So what's happening is that the binding for DateAndTime is printing itself as #DateAndTime. So the problem is that the Decompiler is not mapping the sequence pushLiteral: aBinding, send #value back into an appropriate LiteralVariableNode instance. The Decompiler needs to special-case this.
best, Eliot
|
Re: Environment-caused SyntaxError running build scripts (was Re: [squeak-dev] error when updating Squeak4.4-12327 to trunk)
|
|
On Mon, Mar 11, 2013 at 5:59 PM, Eliot Miranda <[hidden email]> wrote: No. Its arguably a bug but a binding will print itself as the Symbol key. So what's happening is that the binding for DateAndTime is printing itself as #DateAndTime. So the problem is that the Decompiler is not mapping the sequence pushLiteral: aBinding, send #value back into an appropriate LiteralVariableNode instance. The Decompiler needs to special-case this. Yeah, that should probably be fixed. The new Alias bindings will generate #value sends, which I don't think we've used before. (We've used #value: for assignment to globals, but not #value for reads.)
But since DateAndTime is a class, this shouldn't be an Alias at all, and thus shouldn't be sending #value. Colin |
Re: Environment-caused SyntaxError running build scripts (was Re: [squeak-dev] error when updating Squeak4.4-12327 to trunk)
|
|
On 2013-03-12, at 02:26, Colin Putney <[hidden email]> wrote:
> On Mon, Mar 11, 2013 at 5:59 PM, Eliot Miranda <[hidden email]> wrote: > >> No. Its arguably a bug but a binding will print itself as the Symbol key. So what's happening is that the binding for DateAndTime is printing itself as #DateAndTime. So the problem is that the Decompiler is not mapping the sequence pushLiteral: aBinding, send #value back into an appropriate LiteralVariableNode instance. The Decompiler needs to special-case this. >> > Yeah, that should probably be fixed. The new Alias bindings will generate #value sends, which I don't think we've used before. (We've used #value: for assignment to globals, but not #value for reads.) Isn't #value too general to serve as a specially treated token in the decompiler? It might easily appear in code. I'd think it would be better if the compiler emitted a unique message selector that the decompiler could reliably recognize. Maybe #pvtValue, which cannot be used in regular code anyway? - Bert - |
Re: Environment-caused SyntaxError running build scripts (was Re: [squeak-dev] error when updating Squeak4.4-12327 to trunk)
|
|
2013/3/12 Bert Freudenberg <[hidden email]>:
> On 2013-03-12, at 02:26, Colin Putney <[hidden email]> wrote: > >> On Mon, Mar 11, 2013 at 5:59 PM, Eliot Miranda <[hidden email]> wrote: >> >>> No. Its arguably a bug but a binding will print itself as the Symbol key. So what's happening is that the binding for DateAndTime is printing itself as #DateAndTime. So the problem is that the Decompiler is not mapping the sequence pushLiteral: aBinding, send #value back into an appropriate LiteralVariableNode instance. The Decompiler needs to special-case this. >>> >> Yeah, that should probably be fixed. The new Alias bindings will generate #value sends, which I don't think we've used before. (We've used #value: for assignment to globals, but not #value for reads.) > Well, I used value sends for my experiments of auto and lazy initialization of class variables http://smallissimo.blogspot.fr/2011/08/lazy-initialization-of-shared-variable.html so I can say it kind of works. > Isn't #value too general to serve as a specially treated token in the decompiler? It might easily appear in code. > > I'd think it would be better if the compiler emitted a unique message selector that the decompiler could reliably recognize. Maybe #pvtValue, which cannot be used in regular code anyway? > > - Bert - > That's a good question. If we want to be able to define different behaviors with delegation in mind, pvtValue seems a bit restrictive. Corolaries: how will the VM optimize the send (PIC, etc...) Nicolas |
Re: Environment-caused SyntaxError running build scripts (was Re: [squeak-dev] error when updating Squeak4.4-12327 to trunk)
|
|
On 2013-03-12, at 12:33, Nicolas Cellier <[hidden email]> wrote: > 2013/3/12 Bert Freudenberg <[hidden email]>: > >> Isn't #value too general to serve as a specially treated token in the decompiler? It might easily appear in code. >> >> I'd think it would be better if the compiler emitted a unique message selector that the decompiler could reliably recognize. Maybe #pvtValue, which cannot be used in regular code anyway? >> >> - Bert - >> > > That's a good question. > If we want to be able to define different behaviors with delegation in > mind, pvtValue seems a bit restrictive. Why? #value can easily implemented as "^self pvtValue". It's really only so that that we can distinguish the compiler-generated selector from a user-typed selector. > Corolaries: how will the VM optimize the send (PIC, etc...) > > Nicolas Well, a PIC wouldn't care about the actual selector. It would only make a difference if #value was treated specially by the VM, and I though it wasn't, and probably shouldn't. - Bert - |
Re: Environment-caused SyntaxError running build scripts (was Re: [squeak-dev] error when updating Squeak4.4-12327 to trunk)
|
|
2013/3/12 Bert Freudenberg <[hidden email]>:
> > On 2013-03-12, at 12:33, Nicolas Cellier <[hidden email]> wrote: > >> 2013/3/12 Bert Freudenberg <[hidden email]>: >> >>> Isn't #value too general to serve as a specially treated token in the decompiler? It might easily appear in code. >>> >>> I'd think it would be better if the compiler emitted a unique message selector that the decompiler could reliably recognize. Maybe #pvtValue, which cannot be used in regular code anyway? >>> >>> - Bert - >>> >> >> That's a good question. >> If we want to be able to define different behaviors with delegation in >> mind, pvtValue seems a bit restrictive. > > Why? #value can easily implemented as "^self pvtValue". It's really only so that that we can distinguish the compiler-generated selector from a user-typed selector. > As I understand it, yes, this way is possible, but isn't the other way forbidden ? pvtValue ^delegate pvtValue Unless of course we change selector at first indirection. Nicolas >> Corolaries: how will the VM optimize the send (PIC, etc...) >> >> Nicolas > > > Well, a PIC wouldn't care about the actual selector. It would only make a difference if #value was treated specially by the VM, and I though it wasn't, and probably shouldn't. > > - Bert - > > > |
Re: Environment-caused SyntaxError running build scripts (was Re: [squeak-dev] error when updating Squeak4.4-12327 to trunk)
|
|
On 2013-03-12, at 12:59, Nicolas Cellier <[hidden email]> wrote:
> 2013/3/12 Bert Freudenberg <[hidden email]>: >> >> On 2013-03-12, at 12:33, Nicolas Cellier <[hidden email]> wrote: >> >>> 2013/3/12 Bert Freudenberg <[hidden email]>: >>> >>>> Isn't #value too general to serve as a specially treated token in the decompiler? It might easily appear in code. >>>> >>>> I'd think it would be better if the compiler emitted a unique message selector that the decompiler could reliably recognize. Maybe #pvtValue, which cannot be used in regular code anyway? >>>> >>>> - Bert - >>>> >>> >>> That's a good question. >>> If we want to be able to define different behaviors with delegation in >>> mind, pvtValue seems a bit restrictive. >> >> Why? #value can easily implemented as "^self pvtValue". It's really only so that that we can distinguish the compiler-generated selector from a user-typed selector. >> > > As I understand it, yes, this way is possible, but isn't the other way > forbidden ? > > pvtValue > ^delegate pvtValue > > Unless of course we change selector at first indirection. Or use "delegate perform: #pvtValue". That said, what selector would you propose? - Bert - |
Re: Environment-caused SyntaxError running build scripts (was Re: [squeak-dev] error when updating Squeak4.4-12327 to trunk)
|
|
In reply to this post by Bert Freudenberg
On Tue, Mar 12, 2013 at 3:17 AM, Bert Freudenberg <[hidden email]> wrote: Isn't #value too general to serve as a specially treated token in the decompiler? It might easily appear in code. AFAICT, the decompiler should special case a send of #value *to a binding*, not just any send of #value. There's no way to refer directly to a binding with regular Smalltalk code, right?
Colin |
Re: Environment-caused SyntaxError running build scripts (was Re: [squeak-dev] error when updating Squeak4.4-12327 to trunk)
|
|
On 2013-03-12, at 15:59, Colin Putney <[hidden email]> wrote:
> On Tue, Mar 12, 2013 at 3:17 AM, Bert Freudenberg <[hidden email]> wrote: > > Isn't #value too general to serve as a specially treated token in the decompiler? It might easily appear in code. > > AFAICT, the decompiler should special case a send of #value *to a binding*, not just any send of #value. There's no way to refer directly to a binding with regular Smalltalk code, right? Ah. Well, I guess it would be the first time the decompiler behavior depends on the *kind* of literal stored, but then, maybe that's not so bad. Being able to just use #value would be nice indeed. - Bert - |
Re: Environment-caused SyntaxError running build scripts (was Re: [squeak-dev] error when updating Squeak4.4-12327 to trunk)
|
|
In reply to this post by Bert Freudenberg
On Tue, Mar 12, 2013 at 3:17 AM, Bert Freudenberg <[hidden email]> wrote: --
No. The way the decompiler works when value is sent there is a ParseNode on the stack. The only context in which the ParseNode can be a kind of variable binding is in the case where #value and/or #value: is being sent to a global variable. In all other cases it'll be some other kind of node.
No need. best, Eliot
|
Re: Environment-caused SyntaxError running build scripts (was Re: [squeak-dev] error when updating Squeak4.4-12327 to trunk)
|
|
In reply to this post by Bert Freudenberg
On Tue, Mar 12, 2013 at 11:52 AM, Bert Freudenberg <[hidden email]> wrote: --
The point is that one can't mention variable bindings in code directly. There's no literal denotation of a binding; bindings (Associations and/or VariableBindings et al) are not literals; the only way to introduce a binding into the bytecode is via a global variable reference. So if the Decompiler finds a binding on the decompilation stack it knows that that is a variable reference, and hence that "aBinding value" must be a variable dereference.
And of course, any other reference to a binding in code will be a send, e.g. self classPool associationAt: #Foo will appear to the debugger as a send of #associationAt:, not as a VariableNode for #Foo.
best, Eliot
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |