<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
Hi Dave --<div><br></div><div>> <span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Do you (or someone else) want to implement 1a)?</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> If yes, can we do 1) near </span><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">term until the implementation</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> is available?</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">We do not have enough control over code-load order to make this work without hacking something we might regret into Monticello. :-) I would love to extent Monticello to give packages more control over code-load order by themselves. Maybe I will get some idea while working on FFI. There is this rather inflexible MethodAddtion >> postLoad ...</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Best,</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Marcel</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 12.08.2021 01:07:41 schrieb David T. Lewis <lewis@mail.msen.com>:</p><div style="font-family:Arial,Helvetica,sans-serif"> <br>On Tue, Aug 10, 2021 at 09:40:05AM -0700, Eliot Miranda wrote:<br>> <br>> Hi Dave, Hi Marcel,<br>> <br>> > On Aug 8, 2021, at 5:40 PM, David T. Lewis <lewis@mail.msen.com> wrote:<br>> > <br>> > ???<br>> > Background: By convention the assignment operator in modern day Squeak<br>> > is ':=' and it Cuis it is '_'. The actual fonts are rendered nicely in<br>> > either case for Cuis and Squeak.<br>> > <br>> > The VMs used for Cuis and Squeak consist of the VM proper along with various<br>> > VM plugins such as OSProcessPlugin and VectorEnginePlugin. The VM plugins<br>> > are written in Smalltalk ("slang") with supporting external code as needed.<br>> > The Smalltalk code for each VM plugin is translated to C code, and the<br>> > resulting C code is expected to be correct regardless of the dialect of<br>> > Squeak/Cuis in which the plugin is written.<br>> > <br>> > The generated C code for a VM plugin is the same regardless of whether the<br>> > Smalltalk source is written in the '_' or ':=' convention. However, mixing<br>> > these two conventions in the same VMMaker image may be confusing, especially<br>> > if the (Squeak) image has disabled its 'Allow underscore selectors' preference.<br>> > <br>> > OK, enough background. The question I want to present is this:<br>> > <br>> > The new VectorEnginePlugin is being developed in Cuis, and therefore uses<br>> > the '_' convention in its Smalltalk source code. When building a new<br>> > opensmalltalk-vm VMMaker image from primary sources, the 'Allow underscore<br>> > selectors' preference' is disabled, presumably in order to catch VM plugin<br>> > code that accidentally uses the '_' convention. However, in the case of<br>> > VectorEnginePlugin, the use of '_' is intentional, and we can expect it<br>> > to be used for current and future versions of the plugin Smalltalk code<br>> > as development proceeds.<br>> > <br>> > So should we:<br>> > <br>> > 1) Relax the restriction and allow VectorEnginePlugin to be loaded without<br>> > modification in a VMMaker image<br>> > <br>> > or:<br>> > <br>> > 2) Convert current and future versions of the VectorEnginePlugin Smalltalk<br>> > to use ':=' for assigments prior to loading in a Squeak VMMaker image<br>> > (method author/timestamps would be preserved).<br>> > <br>> > I personally prefer 1) but consider either option to be reasonable and doable.<br>> > <br>> > Comments? Preferences?<br>> <br>> My preference is 1a :-). 1a is supporting a Compiler patch that allows<br>> one to assert the 'Allow underscore selectors' preference on a per-class<br>> basis and adding some class side state (a method? A method containing<br>> a pragma?) to VectorEnginePlugin that asserts the preference. Maybe this<br>> is too elaborate, and there???s a bootstrap problem (the class side method<br>> must be loaded before methods containing a underscore assignments) but I<br>> like not having the preference globally.<br>><br><br>Hi Eliot,<br><br>Do you (or someone else) want to implement 1a)? If yes, can we do 1) near<br>term until the implementation is available?<br><br>Otherwise, Juan has offered to replace underscores with := in the upstream<br>source.<br><br>Thanks,<br>Dave<br><br></lewis@mail.msen.com></div></blockquote></div>