Hi Eliot,<br>
<br>
DMM is used by the Decompiler, so if I understand correctly, it is also a tool for the (de)compiler, not only for the Tools. If we leave it in the Tools package, we will have to accept that the compiler will not be completely functional if we unload the Tools package - which I would consider a pity in terms of modularity. In Squeak 5.3, this dependency did not yet exist. What do you think? Or can rewrite Decompiler>>#mapFromBlockKeysIn:toTempVarsFrom:constructor: so that it does not require DMM any longerk, just like in 2018?<br>
<br>
Best,<br>
Christoph<br>
<br>
<font color="#808080">---<br>
</font><font color="#808080"><i>Sent from </i></font><font color="#808080"><i><a href="https://github.com/hpi-swa-lab/squeak-inbox-talk"><u><font color="#808080">Squeak Inbox Talk</font></u></a></i></font><br>
<br>
On 2022-01-20T12:01:51-08:00, eliot.miranda@gmail.com wrote:<br>
<br>
> Hi Christoph, Marcel,<br>
> <br>
> On Jan 19, 2022, at 4:18 PM, Christoph.Thiede at student.hpi.uni-potsdam.de wrote:<br>
> > <br>
> > Hi Marcel, thank you for the feedback!<br>
> > <br>
> > 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.<br>
> <br>
> 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.<br>
> <br>
> 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)?<br>
> <br>
> > <br>
> > 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.<br>
> > <br>
> > Best,<br>
> > Christoph<br>
> > <br>
> > ---<br>
> > Sent from Squeak Inbox Talk<br>
> > <br>
> > On 2022-01-11T11:24:08+01:00, marcel.taeumel at hpi.de wrote:<br>
> > <br>
> > > > Just a few quick questions [...]<br>
> > > <br>
> > > You are aware that those kind of questions are the challenging ones in the programming profession? ;-P Here we go:<br>
> > > <br>
> > > 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.<br>
> > > <br>
> > > 2) Yes, please.<br>
> > > <br>
> > > 3) If you have no theory at all, leave it be. Gather more insight to make an informed decision. Avoid pure guessing.<br>
> > > <br>
> > > 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.<br>
> > > <br>
> > > 5) Yes. "TextStyle defaultFont" is a common expression that can be used in "Tools" and "System" and "Morphic" etc.<br>
> > > <br>
> > > Best,<br>
> > > Marcel<br>
> > > Am 10.01.2022 21:48:46 schrieb christoph.thiede at student.hpi.uni-potsdam.de <christoph.thiede at student.hpi.uni-potsdam.de>:<br>
> > > Hi all! Just a few quick questions while trying to fix the PackageDependencyTest again ...<br>
> > > <br>
> > > 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?<br>
> > > 2.) Can I move String >> #asTime[Stamp] into an extension category for the package *Chronology-Core?<br>
> > > 3.) I cannot make any sense of WideString class>>#fromISO2022JPString:. What is this for and do we really need it - it has zero senders?<br>
> > > 4.) Compiler now depends on Tools because the Decompiler uses DebuggerMethodMap. I suggest moving DebuggerMethodMap into Compiler-Kernel, wdyt?<br>
> > > 5.) ToolBuilder-Kernel now depends on Graphics for accessing TextStyle defaultFont in PluggableSpacerSpec>>#extent - shall I allow this dependency in the package dependency test?<br>
> > > <br>
> > > Thanks in advance!<br>
> > > <br>
> > > Best,<br>
> > > Christoph<br>
> > > <br>
> > > <br>
> > > ---<br>
> > > Sent from Squeak Inbox Talk [https://github.com/hpi-swa-lab/squeak-inbox-talk]<br>
> > > -------------- next part --------------<br>
> > > An HTML attachment was scrubbed...<br>
> > > URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220111/7ddb8ea5/attachment.html><br>
> > > <br>
> > > <br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220120/eb4b9dc8/attachment.html><br>
> <br>
>