ISO-2022-JP is a Japanese string encoding. I find it rather funny that
the method goes by writing the string to a file, unencoded, and
reading it from the file again, presumably decoding along the way.
Maybe MultiByteBinaryOrTextStream did not exist in 2002...

https://en.wikipedia.org/wiki/ISO/IEC_2022#ISO-2022-JP

Anyway, its purpose is string decoding. But whether it works or not
probably depends on other parts of the image, such as which coding is
by default used in the file streams you get when you use FileStream
constructors. Maybe nowadays the method no longer does what its
selector says, since by default you will get a MultiByteFileStream
which uses a UTF-8 converter, doesn't it?

Am Do., 20. Jan. 2022 um 01:18 Uhr schrieb
<christoph.thiede at student.hpi.uni-potsdam.de>:
>
> Hi Marcel, thank you for the feedback!
>
> Points 2 and 5 are resolved, I have fixed three package dependency tests in total. For point 5, let's wait for Eliot's opinion.
>
> Ad 3 (#fromISO2022JPString:): There is no further mention of this selector on the entire list and it is not indexed in Google, Sourcegraph, etc. Did you look into it? :-) Otherwise, we can only leave it in the Trunk forever if no soul reading this has any memories about it.
>
> Best,
> Christoph
>
> ---
> Sent from Squeak Inbox Talk
>
> On 2022-01-11T11:24:08+01:00, marcel.taeumel at hpi.de wrote:
>
> > > Just a few quick questions [...]
> >
> > You are aware that those kind of questions are the challenging ones in the programming profession? ;-P Here we go:
> >
> > 1) Not yet. ProgressNotification is still in "Collections" package. And there are more than 20 senders of  #do:displayingProgress: whose dependecy to then "Tools" should be checked, too.
> >
> > 2) Yes, please.
> >
> > 3) If you have no theory at all, leave it be. Gather more insight to make an informed decision. Avoid pure guessing.
> >
> > 4) Maybe later. It seems that Decompiler and DebuggerMethodMap are close friends. Let Eliot decide this but it looks okay to me to move the DebuggerMethodMap hierarchy from "Tools" to "Compiler-Support". HOWEVER, watch out for dependencies to "Chronology", which "Compiler" has not at the moment. Or maybe Decompiler should move into a new "CompilerTools"? :-D This one is tricky. Maybe leave it be for the moment and allow it.
> >
> > 5) Yes. "TextStyle defaultFont" is a common expression that can be used in "Tools" and "System" and "Morphic" etc.
> >
> > Best,
> > Marcel
> > Am 10.01.2022 21:48:46 schrieb christoph.thiede at student.hpi.uni-potsdam.de <christoph.thiede at student.hpi.uni-potsdam.de>:
> > Hi all! Just a few quick questions while trying to fix the PackageDependencyTest again ...
> >
> > 1.) Is it okay to move Collection>>#do:displayingProgress:every: into an extension category of the package *toolbuilder-kernel, just like we're doing for String>>#displayProgressFrom:to:during: already?
> > 2.) Can I move String >> #asTime[Stamp] into an extension category for the package *Chronology-Core?
> > 3.) I cannot make any sense of WideString class>>#fromISO2022JPString:. What is this for and do we really need it - it has zero senders?
> > 4.) Compiler now depends on Tools because the Decompiler uses DebuggerMethodMap. I suggest moving DebuggerMethodMap into Compiler-Kernel, wdyt?
> > 5.) ToolBuilder-Kernel now depends on Graphics for accessing TextStyle defaultFont in PluggableSpacerSpec>>#extent - shall I allow this dependency in the package dependency test?
> >
> > Thanks in advance!
> >
> > Best,
> > Christoph
> >
> >
> > ---
> > Sent from Squeak Inbox Talk [https://github.com/hpi-swa-lab/squeak-inbox-talk]
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220111/7ddb8ea5/attachment.html>
> >
> >