On 20 November 2013 04:57, Andres Valloud <avalloud@smalltalk.comcastbiz.net> wrote:
On 11/19/13 19:13 , Eliot Miranda wrote:
I would argue that in fact the best way to deal with differing UNIX
implementations is this approach.  For example, ioctl defines, socket
constant defines, struct layouts, etc, etc all differ markedly between
UNIX implementations, and hence one easy way to extract exact
information is to generate, compile and either run or load a program
that reveals the implementation details.

It's not clear to me how an arbitrary interpretation mechanism 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

#if defined(FOO)
...
#endif

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.

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.


But you forgot to mention, that while writing plugin, or trying to dynamically link with some external library,
 an author must deal with tons of those #ifdefs as well..

IMO, macros is the worst thing invented for C.
Having 10+ years of Pascal experience, i cannot really understand why it left behind by industry: 10/100 times faster compilation times, no crazy modularity problems,
same (or even better code performance), but what's most important is that you get what you see in code.

--
Best regards,
Igor Stasenko.