<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Hi Tobias, thanks for the pointers!</p>
<p><br>
</p>
<p>> <span style="font-size:12pt">(CTTéstClass compiledMethodAt: #foo) preamble</span></p>
<div><br>
</div>
<div>Like you said:</div>
<div><img size="28942" id="x_img618772" tabindex="0" style="max-width:99.9%" src="cid:83a80b39-6292-4b27-a568-4108acb2ecc6"><br>
</div>
<div><br>
</div>
<div>I made the following change:</div>
<div><img size="37267" id="x_img499641" tabindex="0" style="max-width:99.9%" src="cid:ca6036be-fde9-4c4d-9941-5f14ff95ddea"><br>
</div>
<div>This seems to fix the conversion issues.</div>
<div><br>
</div>
<div>Outputs are:</div>
<div><img size="63724" id="x_img469882" tabindex="0" style="max-width:99.9%" src="cid:ee893e7e-8605-4413-9cdd-3761fc73b0d5"><br>
</div>
<div><br>
</div>
<div>The next problem is the trailing ! for the CTTéstClass preamble.</div>
<div>Here, the integer returned by expandedSourceFileArray >> #<span>filePositionFromSourcePointer: is too large by one.</span></div>
<div><span>If have no idea where these constants come from, but as this is a constant method, I don't see how this calculation could be wrong.</span></div>
<div><span><br>
</span></div>
<div><span>I also tried the following:</span></div>
<div><span><img size="233098" id="x_img268456" tabindex="0" style="max-width:99.9%" src="cid:388ac190-510f-4612-8961-689c359f9799"></span></div>
<div><span style="font-size:12pt">yielding correctly:</span><br>
</div>
<div><span><img size="22208" id="x_img50200" tabindex="0" style="max-width:99.9%" src="cid:79731c28-bf8f-4335-889f-ce5652e9091a"><br>
</span></div>
<div><span>But that seems hacky again.</span></div>
<p></p>
<p><br>
</p>
<p>Looking forward to your reply!</p>
<p><br>
</p>
<p>Best,</p>
<p>Christoph</p>
<div id="x_Signature">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="x_divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">
<div class="x__rp_U4 x_ms-font-weight-regular x_ms-font-color-neutralDark x_rpHighlightAllClass x_rpHighlightBodyClass" id="x_Item.MessageUniqueBody" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif,serif,EmojiFont">
<div dir="ltr">
<div id="x_divtagdefaultwrapper"><font face="Calibri,Helvetica,sans-serif,EmojiFont,Apple Color Emoji,Segoe UI Emoji,NotoColorEmoji,Segoe UI Symbol,Android Emoji,EmojiSymbols">
<div id="x_Signature">
<div style="margin:0px"><font style="font-family:Calibri,Arial,Helvetica,sans-serif,serif,EmojiFont"></font></div>
</div>
</font></div>
</div>
</div>
</div>
</div>
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Tobias Pape <Das.Linux@gmx.de><br>
<b>Gesendet:</b> Samstag, 21. Dezember 2019 19:22:38<br>
<b>An:</b> The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] [BUG] Timestamps don't work for classes with special character names</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText"><br>
> On 21.12.2019, at 19:11, Tobias Pape <Das.Linux@gmx.de> wrote:<br>
> <br>
>> <br>
>> On 21.12.2019, at 17:36, Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:<br>
>> <br>
>> Hi Tobias,<br>
>> <br>
>> what do you mean in detail?<br>
>> <br>
>> If I create the class via System Browser and add the method, my change file ends with:<br>
>> <br>
>> Object subclass: #CTTéstClass<br>
>> instanceVariableNames: ''<br>
>> classVariableNames: ''<br>
>> poolDictionaries: ''<br>
>> category: 'CT-Experiments'!<br>
>> !CTTéstClass methodsFor: 'no messages' stamp: 'ct 12/21/2019 17:18'!<br>
>> foo! !<br>
> <br>
> <br>
> Good. that was what I thought was important.<br>
> <br>
> <br>
>> <br>
>> However, CompiledMethod >> #timeStamp returns ''.<br>
> <br>
> What is the result of the following?<br>
> <br>
> (CTTéstClass compiledMethodAt: #foo) preamble<br>
> <br>
> <br>
>> <br>
>> Here is a snapshot of the #timeStamp stackframe:<br>
>> <br>
>> <br>
>> <br>
>> Please note that "tokens at: tokenCount" returns the correct timestamp, but however, stamp is nil. What is this???<br>
> <br>
> <br>
> I see what the problem is. The .changes file is apparently written UTF-8 coded, but read Latin-1 coded.<br>
> This is BAD.<br>
<br>
Oh, and we were warned:<br>
<br>
CompiledMethod<br>
getPreambleFrom: aFileStream at: endPosition<br>
"This method is an ugly hack. This method assumes that source files have ASCII-compatible encoding and that preambles contain no non-ASCII characters."<br>
<br>
| chunkSize chunk |<br>
chunkSize := 160 min: endPosition.<br>
[<br>
| index |<br>
chunk := aFileStream<br>
position: (endPosition - chunkSize + 1 max: 0);<br>
basicNext: chunkSize.<br>
(index := chunk lastIndexOf: $! startingAt: chunk size) ~= 0 ifTrue: [<br>
^chunk copyFrom: index + 1 to: chunk size ].<br>
chunkSize := chunkSize * 2.<br>
chunkSize <= endPosition ] whileTrue.<br>
^chunk<br>
<br>
<br>
I have the feeling that the problematic send is #basicNext: in line 10 or so. This seems to circumvent the conversion done by MultiByteFileStream.<br>
<br>
Best regards <br>
-Tobias<br>
<br>
> <br>
> You end up with 7 tokens, because you have three for the class name instead of one. This is because the Latin-1 copyright symbol is classified as binary selector, and thus separates the first part of the Class name from the second part. This happens only
because utf8 vs latin.<br>
> <br>
> But the code path for 7-element tokens is different, and it looks for the #stamp: at a different position.<br>
> <br>
> Hence stamp is nil.<br>
> <br>
> A wrong but easy fix would be to call #utf8ToSqueak on the preamble.<br>
> <br>
> Best regards<br>
> -Tobias<br>
> <br>
> <br>
>> <br>
>> I'm not sure if I understand you correctly, but if you told me to search the hex of my change file for a "zero word", the only occurrence I could find is:<br>
>> <br>
>> Which lead me to this:<br>
>> <br>
>> Does not seem related, but still looks somehow wrong ^^<br>
>> <br>
>> Best,<br>
>> Christoph<br>
>> <br>
>> Von: Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Tobias Pape <Das.Linux@gmx.de><br>
>> Gesendet: Samstag, 21. Dezember 2019 15:44 Uhr<br>
>> An: The general-purpose Squeak developers list<br>
>> Betreff: Re: [squeak-dev] [BUG] Timestamps don't work for classes with special character names<br>
>> <br>
>> <br>
>>> On 21.12.2019, at 15:16, Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:<br>
>>> <br>
>>> Hi all, found just another bug. If you get tired of them, just tell me :-)<br>
>>> <br>
>>> Steps to reproduce:<br>
>>> Print it:<br>
>>> class := Object subclass: #CTTèstClass "sic (with accent in name)!"<br>
>>> instanceVariableNames: ''<br>
>>> classVariableNames: ''<br>
>>> poolDictionaries: ''<br>
>>> category: 'CT-Experiments'.<br>
>>> class compile: 'foo ^ #foo'.<br>
>>> (class >> #foo) timeStamp<br>
>>> <br>
>>> Expected output:<br>
>>> Something like 'ct 12/21/2019 15:13'.<br>
>>> <br>
>>> Actual output:<br>
>>> ''.<br>
>>> <br>
>>> Please note that everything would have worked fine if we named class #CTTestClass (without accent) instead.<br>
>>> <br>
>>> Do we want to support special class names in general? If yes, this is a bug in my opinion. If no, we should raise an error in the first statement.<br>
>>> <br>
>>> Cause of infection not yet investigated.<br>
>> <br>
>> Please look at your .changes file whether at some point \00 bytes appear.<br>
>> <br>
>> Best regards<br>
>> -Tobias<br>
<br>
<br>
<br>
</div>
</span></font>
</body>
</html>