On 11 March 2013 23:13, Bert Freudenberg <bert at freudenbergs.de> wrote:
>
> On 2013-03-12, at 00:11, Frank Shearar <frank.shearar at gmail.com> 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 -
>
>
>