On 20 November 2013 15:07, Igor Stasenko <siguctua at gmail.com> wrote:

>
>
> On 20 November 2013 04:57, Andres Valloud <
> avalloud at 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..
>
>
Heck, even worse (and most offensive scenario):
 - you compiled plugin & ship it with own set of defines
 - a stupid (or maybe too clever) user uses a slightly different
environment setup built with own set of defines
 - crash boom as result

... so the following (quote):

<<< . VM plugins are reliable,
portable, and debuggable. They work across a range of processors. They
work on 64-bit platforms. >>>

.. is just a fairy tale. Nothing is reliable, portable, and debuggable when
it comes about C.


> 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.
>



-- 
Best regards,
Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131120/695ba936/attachment.htm