[Vm-dev] AioPlugin:
VMConstruction-Plugins-AioPlugin-EstebanLorenzano.19.mcz
Esteban Lorenzano
estebanlm at gmail.com
Sat May 28 09:45:34 UTC 2016
yes, I was trying to “fix” a problem that emerged with a commit from Eliot that was forbidding strings in cCode:… but that is already properly fixed, so this package should be removed.
Esteban
> On 28 May 2016, at 04:17, David T. Lewis <lewis at mail.msen.com> wrote:
>
>
> On Sat, May 28, 2016 at 05:29:03AM +0800, Ben Coman wrote:
>>
>> On Sat, May 28, 2016 at 1:52 AM, David T. Lewis <lewis at mail.msen.com> wrote:
>>>
>>> Hi Esteban,
>>>
>>> I missed the discussion here, but this does not look like a good change. The
>>> values of AIO_R, AIO_W, and AIO_X are declared in a header file in the platforms
>>> sources. They should also not be hard-coded in the image, which is what happens
>>> when you define them as class variables in AioPlugin.
>>
>> What is the preferred way to synchronise header values between the
>> platform sources and the Image?
>>
>
> Do not do that. Do not attempt to synchonize them. Use the actual values
> in the header files. Do not assume that they will never change, and do not
> assume that they they will be the same on all platforms.
>
> For example, you can write this, because it invokes the actual C language
> definition of 'AIO_X' as defined in an external header file, and it uses 4
> as a default for VM simulation:
>
> flags := flags bitOr: (self cCode: 'AIO_W' inSmalltalk: [4])
>
> But you should not write the following, where AIO_X is a class var set to 4.
> It looks prettier, but it is wrong because the value of AIO_W is hard coded
> in a class initialization in the image:
>
> flags := flags bitOr: AIO_W
>
> Pretty code is nice, but it is more important that it be correct.
>
> Dave
>
More information about the Vm-dev
mailing list