<div dir="ltr">Hi Monty,<div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 23, 2018 at 10:12 PM, monty <span dir="ltr"><<a href="mailto:monty2@programmer.net" target="_blank">monty2@programmer.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
Echoing Alistair, no SharedPool in my generated VMMaker image seems to do what you describe.</blockquote><div><br></div><div>That's right.  I did a prototype for VisualWorks when I worked at Cincom.  I don't think they would object to me giving you the code but if you can do with out it would be better, and since the code isn't that difficult it might be better to start afresh.  But if you read the thread you'll see that Mariano Martines Peck did something in Pharo based on our conversations and that might be a better starting point.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> If you want, I can do the implementation. (In the FFI-Pools package.)<br></blockquote><div><br></div><div>That would be great.  Remember the major requirements:</div><div><br></div><div>Deployment:</div><div>The output of the C program should be a concise parseable, human-editable document (in STON?) whose name identifies the platform.  Let's call it PlatformConstants-XXX.ext (where ext reflects the syntax chosen).</div><div>Various PlatformConstants-XXX.ext files can live either in a folder in the virtual machine or a folder parallel to the image</div><div>Various PlatformConstants-XXX.ext files and the pool definition that generated them should live somewhere on <a href="http://squeak.org">squeak.org</a> so people can download them without needing a C development environment to get access to new constants, etc.<br></div><div>The PlatformConstants-XXX.ext file is only parsed on start-up if the image comes up on a different platform.  Parsing happens before any FFI/socket call</div><div>An alternative would be "conditional bindings", where the various platform-specific values for a particular constant could be in additional inst vars of a suitable binding type, which could allow for a default value for concision, for example</div><div><div><span class="gmail-Apple-tab-span" style="white-space:pre">   </span>Global variableSubclass: #PlatformConstant</div><div><span class="gmail-Apple-tab-span" style="white-space:pre">             </span>instanceVariableNames: 'default'</div><div><span class="gmail-Apple-tab-span" style="white-space:pre">               </span>classVariableNames: ''</div><div><span class="gmail-Apple-tab-span" style="white-space:pre">         </span>poolDictionaries: ''</div><div><span class="gmail-Apple-tab-span" style="white-space:pre">           </span>category: 'FFI-Core'</div></div><div>and then the alternatives different from the default would be held in indexed inst vars as pairs of platform moniker, value</div><div><br></div><div>Development:</div><div>Generating a new PlatformConstants-XXX.ext file should be entirely automatic, but would assume the platform's standard compiler would be available</div></div><br><br><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>