Hi Christoph, Marcel,

On Jan 19, 2022, at 4:18 PM, Christoph.Thiede at student.hpi.uni-potsdam.de wrote:
> 
> 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.

You mean point 4 right? Whether DebuggerMethodMap should be in Tools or Compiler-Support.  DebuggerMethodMap clearly supports the tools (and the programmer), not the compiler.  DMM’s major jobs are determining what temporaries are in scope at any suspension point in a method, computing a linear sequence of the temps, and mapping indices into this sequence into locations for temporaries given that the closure design a) copies read-only temporaries into closures and b) puts non-locally assigned to temps in indirection vectors.  Hence, to present a logical view of the temporaries in the debugger DMM needs to do a lot of mangling, essentially undoing the mangling the bytecode compiler does to efficiently implement closures.

Now it seems natural to me to put DMM in Tools, but I can understand that some would disagree.  What are the main driving and restraining forces in keeping it where it is (Tools) or moving it to Compiler-Support (where I think it is a misfit)?

> 
> 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>
> > 
> > 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220120/eb4b9dc8/attachment.html>