<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 19, 2013 at 7:57 PM, Andres Valloud <span dir="ltr"><<a href="mailto:avalloud@smalltalk.comcastbiz.net" target="_blank">avalloud@smalltalk.comcastbiz.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 11/19/13 19:13 , Eliot Miranda wrote:<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I would argue that in fact the best way to deal with differing UNIX<br>
implementations is this approach. For example, ioctl defines, socket<br>
constant defines, struct layouts, etc, etc all differ markedly between<br>
UNIX implementations, and hence one easy way to extract exact<br>
information is to generate, compile and either run or load a program<br>
that reveals the implementation details.<br>
</blockquote>
<br></div>
It's not clear to me how an arbitrary interpretation mechanism </blockquote><div><br></div><div>I didn't untroduce an interpretation mechanism, I introduced a compialtion mechanism.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
would reveal what function to call to invoke e.g. malloc(), assuming that's all there is to it. The mechanism would have to deal with arbitrary macro code expansion, arbitrary code without source code provided by the compiler itself, and on some platforms such as OS X the behavior of malloc() could depend on the value of environment variables at the time the binary is loaded (as opposed to the time when the interpretation mechanism looks at said variables). Similarly, it's unclear what that interpretation mechanism would do in the general presence of things like<br>
<br>
#if defined(FOO)<br>
...<br>
#endif<br>
<br>
To me, avoiding writing a few lines of C does not justify the effort of correctly rewriting and maintaining (parts of) a C compiler in Smalltalk.<br></blockquote><div><br></div><div>No matter what, the following defines a function that takes an integer and returns the result of malloc:</div>
<div><br></div><div>#include <stdlib.h></div><div>void *malloc_wrapper(int n) { return malloc(n); }</div><div><br></div><div>This wrapper can be auto-generated and compiled into a shared object or dll and used to wrap whatever crap the underlying platform chooses to use in implementing malloc.</div>
<div><br></div><div>This can also be used to wrap macros and print the values of simple defines.</div><div><br></div><div>A similar approach can be used to derive the layouts of things like a struct stat.</div><div><br></div>
<div>#define printfield(s,f) printf("&" #s "." #f "=%ld\n", offsetof(s.f))</div><div><br></div><div>So one can use the C compiler to extract layout information easily that abstracts away from implementation detail and means the Smalltalk system *does not* have to implement a C compiler, merely invoke one.</div>
<div><br></div><div>Note that this approach is a fall-back for perverse platforms. Most platforms are not remotely this difficult to use. Most allow us to directly call functions, know the layouts of structures and so on.</div>
<div><br></div><div>The above can be autogenerated.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Generally, I agree that one could carefully and consciously write comparatively small primitives and/or plugins. Then, one could compile those with a C compiler in a compilation environment compatible with that of the VM. And then, one could call those primitives and/or plugins from the image with the expectation (within reason) that they should work.<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>