[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