<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 21, 2016 at 6:24 AM, Denis Kudriashov <span dir="ltr">&lt;<a href="mailto:dionisiydk@gmail.com" target="_blank">dionisiydk@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <br><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2016-01-21 15:18 GMT+01:00 Denis Kudriashov <span dir="ltr">&lt;<a href="mailto:dionisiydk@gmail.com" target="_blank">dionisiydk@gmail.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_extra">Hi</div><div class="gmail_extra"><br><div class="gmail_quote">2016-01-21 13:43 GMT+01:00 Mariano Martinez Peck <span dir="ltr">&lt;<a href="mailto:marianopeck@gmail.com" target="_blank">marianopeck@gmail.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><br></div><div>I was thinking the following. Having to distribute the FFI wrapper (take as an example the myself wrapper) with the .ston files is a bit of a pain with MC.  So I was thinking...what if FFISharedPool has all the machinery to allow FFI lib wrapper developer (the developer of the MySQL wrapper), to autogenerate the ston file as we said, BUT, the ston file is stored as methods in the MYSQLInterface subclass? Probably under a &quot;autogenerated&quot; protocol. That way, it&#39;s very easy to distribute and in addition, at system startup it&#39;s easier to &quot;search&quot; for the &quot;ston files&quot;.</div><div><br></div><div>The only drawback is the for very large ston files MC will suffer a bit.. but..</div><div><br></div><div>Thoughts?</div></blockquote></div><br>After reading this thread I have no understanding why &quot;platform constants&quot; information should be distributed as ston files? Why not generate smalltalk classes or methods for each platform? They will initialize pool variables directly when platform change happens. And no problems with there distribution</div></blockquote></div><br>In your example it can be methods on MYSQLInterface class side like:</div><div class="gmail_extra">MYSQLInterface&gt;&gt;initWindows64Declarations<br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra">ConstantA := 1</div><div class="gmail_extra">ConstantB := 5<br></div></blockquote><div class="gmail_extra">MYSQLInterface&gt;&gt;initWindows32Declarations<br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra">ConstantA := 2.<br></div><div class="gmail_extra">ConstantB := 6<br></div></blockquote><div class="gmail_extra">MYSQLInterface&gt;&gt;initUnix32Declarations<br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra">ConstantA := 3.<br></div><div class="gmail_extra">ConstantB := 7<br></div></blockquote><div class="gmail_extra"><br></div><div class="gmail_extra">And this methods can be published in separate packages if needed</div></div></blockquote><div><br></div><div>Let&#39;s measure this.  Let&#39;s say we have 8 platforms (that&#39;s an underestimate, because different Linux distributions may have different values for certain constants), but 8, which is 4 basic platforms times 32- &amp; 64-bits.  We have Mac x86 32-bit, Mac x64 64-bit, Windows x86 32-bit, Windows x64 64-bit, Linux x86 32-bit, Linux ARM 32-bit, Linux x64 64-bit, and soon enough there will be more.  Further, there may be different versions over time.</div><div><br></div><div>So each of those initialization methods has</div><div>- 1 slot for the global variable to be assigned</div><div>- 1 slot for the literal value to assign to it</div><div>- 3 bytes of bytecode per initialization for small methods, 4 for large methods.  Let&#39;s say 4.</div><div><br></div><div>So the overhead in 32-bits is 12 bytes per constant, and in 64-bits is 20 bytes.  So the overhead per constant for all platforms is 96 bytes per constant in 32-bits and 160 bytes per constant for 64-bits.  A full system with sockets, files, a database connexion etc could easily exceed 100 constants.  I think it would be nearer 1000.  So the overheads are in the 10- to 100-k byte range (100k ~= 0.5% of the image) on 32-bits.  That&#39;s low but it&#39;s also pure overhead.  Every GC has to visit them.  Every senders and implementors has to visit them, but they offer nothing of value.  Whereas the small parser for whatever notation is used to store the constants externally (if they are needed in a given deployment) has a small constant overhead; its simple code.</div><div><br></div><div>Further, you still need the machinery to export the constants to be able to generate these initialization methods.  If you&#39;ve got the machinery and you don&#39;t need the methods why bother to generate the methods?</div></div><div class="gmail_extra"><br></div>As the Scots say, many a mickle makes a muckle.<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>