<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
Hi Christoph,<div><br></div><div>> [...] <span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px"> </span><span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px">subclasses of ByteString can be indeed non-trivial. This applies to MCVersionName, for example</span></div><div><span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px"><br></span></div><div><span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px">You are mixing up object structure with structured information. The latter needs interpretation by some other means. Squeak's inspector cannot provide such means of interpretation such as for URLs in strings.</span></div><div><span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px"><br></span></div><div><span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px">> </span><span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px">even a string can be non-trivial, for instance, "</span><span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px">String value: 1234", where I only will see a question mark unless I inspect the result.</span></div><div><span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px"><br></span></div><div><span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px">That's why I would only skip ByteString, not WideString.</span></div><div><span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px"><br></span></div><div><span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px">> </span><span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px">Also, in all situations where you do some experiments concerning identity, an inspector would be very helpful to track individual instances.</span></div><div><span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px"><br></span></div><div><span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px">For most of the literals (or primitive kinds) I listed, object identity does not matter. Small integers and characters are immediate. Symbols are internalized. There is only one "nil", "true", "false." From the top of my head, I cannot think of an example, where you would be interested in two ByteStrings having the same identity. :-)</span></div><div><span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px"><br></span></div><div><span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px">Best,</span></div><div><span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px">Marcel</span></div><div><span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px"><br></span></div><div class="mb_sig"></div>
<blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
<p style="color: #AAAAAA; margin-top: 10px;">Am 19.04.2021 19:29:16 schrieb Thiede, Christoph <christoph.thiede@student.hpi.uni-potsdam.de>:</p><div style="font-family:Arial,Helvetica,sans-serif">
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size: 12pt;color: #000000;font-family: Calibri,Helvetica,sans-serif">
<p>Hi Marcel, hi all,</p>
<p><br>
</p>
<p>I keeping considering this type check as something bad and unexpected. :-)</p>
<p><br>
</p>
<p>First, as I have mentioned earlier, subclasses of ByteString can be indeed non-trivial. This applies to MCVersionName, for example. Second, even a string can be non-trivial, for instance, "<span>String value: 1234", where I only will see a question mark
unless I inspect the result. <span style="font-family: Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size: 16px">
Yes, in the second example, I could also trouble the Compiler again for a new inspect-it, but I just don't see why we should </span><span style="font-family: Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size: 16px">restrict</span><span style="font-family: Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size: 16px"> these
useful links for certain types of </span><span style="font-family: Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size: 16px">results. </span>Also, in all situations
where you do some experiments concerning identity, an inspector would be very helpful to track individual instances. Re-evaluating the expression would not be a solution here.</span></p>
<p><span><br>
</span></p>
<p><span>To summarize, I just would not say that any object in Squeak can have a boring structure. It's just the other way around, these clickable results are a great way to make the inspector more visible in the system.</span></p>
<p><span><br>
</span></p>
<p><span>PS: We should also consider making the new links available for print-its in the search bar.</span></p>
<p><span><br>
</span></p>
<p><span>Best,</span></p>
<p><span>Christoph</span></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><span style="font-size: 10pt;color: #808080"></span></div>
</div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><span style="font-family: Calibri, sans-serif;color: #000000"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von K K Subbu <kksubbu.ml@gmail.com><br>
<b>Gesendet:</b> Montag, 19. April 2021 18:23:22<br>
<b>An:</b> squeak-dev@lists.squeakfoundation.org<br>
<b>Betreff:</b> Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz</span>
<div> </div>
</div>
</div>
<span style="font-size: 10pt"><span style="font-size: 10pt">
<div class="PlainText">All,<br>
<br>
How about:<br>
<br>
Object>>isInspectable ^true<br>
ByteString>>isInspectable ^false<br>
Number>>isInspectable ^false<br>
...<br>
<br>
so inspectors can skip unitary objects?<br>
<br>
Just a thought .. Subbu<br>
<br>
On 19/04/21 8:36 pm, Marcel Taeumel wrote:<br>
> Hi Christoph, hi all.<br>
> <br>
> I think that we should not highlight the following kinds of Objects to <br>
> reserve this feature for really interesting structures that are worth <br>
> inspecting without an extra evaluate. The kinds to ignore are:<br>
> <br>
> ByteString<br>
> ByteSymbol<br>
> Number<br>
> Boolean<br>
> UndefinedObject<br>
> <br>
> So, we can use both (1) visuals and (2) interactivity to let the more <br>
> complex objects say: "Hey, I have interesting structure! Did you mix up <br>
> print-it with inspect-it? No worries, just click on me."<br>
> <br>
> This effect will not be if any stoopid literal gets this treatment. :-)<br>
> <br>
> Best,<br>
> Marcel<br>
>><br>
>> Am 19.04.2021 13:21:53 schrieb Thiede, Christoph <br>
>> <christoph.thiede@student.hpi.uni-potsdam.de>:<br>
>><br>
>> Hi Marcel,<br>
>><br>
>><br>
>> I still stumble upon this edge case for some print-it results that do <br>
>> not support click-to-inspect. Why do we need this exception? :-)<br>
>><br>
>><br>
>> > > Also consider this snippet where the print-link does not exist for <br>
>> an MCVersionName<br>
>> ><br>
>> > Looks fine.<br>
>><br>
>> I don't think it looks fine, why do you think so? :-)<br>
>><br>
>> Best,<br>
>> Christoph<br>
>> ------------------------------------------------------------------------<br>
>> *Von:* Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im <br>
>> Auftrag von Taeumel, Marcel<br>
>> *Gesendet:* Freitag, 16. April 2021 19:52:16<br>
>> *An:* squeak-dev<br>
>> *Betreff:* Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz<br>
>> Hi Christoph,<br>
>><br>
>> I think that this clickable link is a compromise between printString <br>
>> and storeString. For mouse navigation, you can always choose "inspect <br>
>> it" from the context menu on that text selection. ;-) I also found the <br>
>> link color annyoing for simple literals.<br>
>><br>
>> > Also consider this snippet where the print-link does not exist for <br>
>> an MCVersionName<br>
>><br>
>> Looks fine. ^__^ I am certain that we will collect more feedback on <br>
>> this feature during the next weeks and months. Let's refine it then.<br>
>><br>
>> Best,<br>
>> Marcel<br>
>>><br>
>>> Am 16.04.2021 18:39:10 schrieb Thiede, Christoph <br>
>>> <christoph.thiede@student.hpi.uni-potsdam.de>:<br>
>>><br>
>>> Hi Marcel, it's great that you have found a solution to this idea! :-)<br>
>>><br>
>>><br>
>>> > + ^ (self class interactivePrintIt and: [(anObject isString <br>
>>> or: [anObject isNumber]) not])<br>
>>><br>
>>><br>
>>> Is this necessary? I know that an inspector for a literal object like <br>
>>> these does not make great sense, but this just feels like an <br>
>>> unnecessary heuristic and limitation for me and adds complexity. I <br>
>>> would like to be able to open an inspector always. Also consider this <br>
>>> snippet where the print-link does not exist for an MCVersionName: :-)<br>
>>><br>
>>> MCRepository inbox allFileNames first<br>
>>><br>
>>><br>
>>> > CI scripts will default to "true".<br>
>>><br>
>>><br>
>>> Unfortunately, no, mine just timed out while preparing the image. <br>
>>> Also, my server images for @SqueakSmalltalkBot were interrupted. I'd <br>
>>> opt for keeping preamble/postscript content in the update stream <br>
>>> strictly non-interactive. :-)<br>
>>><br>
>>><br>
>>> Best,<br>
>>><br>
>>> Christoph<br>
>>><br>
>>><br>
>>> ------------------------------------------------------------------------<br>
>>> *Von:* Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im <br>
>>> Auftrag von Taeumel, Marcel<br>
>>> *Gesendet:* Freitag, 16. April 2021 17:27:54<br>
>>> *An:* squeak-dev<br>
>>> *Betreff:* Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz<br>
>>> Hi all!<br>
>>><br>
>>> It is now in Trunk. You can opt-out via the preference browser. <br>
>>> Still, you will be asked the first time when you update your image. <br>
>>> CI scripts will default to "true".<br>
>>><br>
>>> Best,<br>
>>> Marcel<br>
>>>><br>
>>>> Am 17.11.2019 17:36:11 schrieb Jakob Reschke <forums.jakob@resfarm.de>:<br>
>>>><br>
>>>> Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de <br>
>>>> <<a href="mailto:Christoph.Thiede@student.hpi.uni-potsdam.de">mailto:Christoph.Thiede@student.hpi.uni-potsdam.de</a>>> schrieb am
<br>
>>>> Fr., 15. Nov. 2019, 09:38:<br>
>>>><br>
>>>><br>
>>>> Just another idea (I seem to have too many of them :D): Some<br>
>>>> kind of UnderlyingObjectAttribute (with a better name, of<br>
>>>> course) an editor can check the selection before compiling it<br>
>>>> when inspectIt/exploreIt is pressed?<br>
>>>><br>
>>>><br>
>>>> Example 1: ('2 + 3' asText) -> User presses inspectIt -> Editor<br>
>>>> checks for UnderylingObjectAttribute -> none found, so the<br>
>>>> string is compilaed as usual.<br>
>>>><br>
>>>> Example 2: (Text string: '2 + 3' attributes:<br>
>>>> (UnderylingObjectAttribute for: 5)) -> User presses inspectIt -><br>
>>>> Editor finds an UnderylingObjectAttribute -> instead of<br>
>>>> compiling the selection, the cached result is reused for<br>
>>>> the inspector.<br>
>>>><br>
>>>> We would not even need to display this Attribute visually if it<br>
>>>> works reliably.<br>
>>>><br>
>>>><br>
>>>> Make sure it is transient in some way because it would be quite <br>
>>>> annoying if the hidden object were out of date with regards to the text.<br>
> <br>
> <br>
<br>
<br>
</div>
</span></span>
</div></blockquote></div>