yeah, but now I saw lots of translations are missing too… so this needs some iterations :(
On 26 May 2016, at 13:56, squeak-dev-noreply@lists.squeakfoundation.org wrote:
Esteban Lorenzano uploaded a new version of VMConstruction-Plugins-AioPlugin to project AioPlugin: http://www.squeaksource.com/AioPlugin/VMConstruction-Plugins-AioPlugin-Esteb...
==================== Summary ====================
Name: VMConstruction-Plugins-AioPlugin-EstebanLorenzano.19 Author: EstebanLorenzano Time: 26 May 2016, 1:56:31.823249 pm UUID: 6608ce78-afce-4d1b-9061-f24c6492c36c Ancestors: VMConstruction-Plugins-AioPlugin-eem.18
replace cCode: '' with cCode:[]
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.
Also, the change cannot be loaded without enabling the "Allow underscores selectors" preference.
Dave
On Thu, May 26, 2016 at 02:45:24PM +0200, Esteban Lorenzano wrote:
yeah, but now I saw lots of translations are missing too??? so this needs some iterations :(
On 26 May 2016, at 13:56, squeak-dev-noreply@lists.squeakfoundation.org wrote:
Esteban Lorenzano uploaded a new version of VMConstruction-Plugins-AioPlugin to project AioPlugin: http://www.squeaksource.com/AioPlugin/VMConstruction-Plugins-AioPlugin-Esteb...
==================== Summary ====================
Name: VMConstruction-Plugins-AioPlugin-EstebanLorenzano.19 Author: EstebanLorenzano Time: 26 May 2016, 1:56:31.823249 pm UUID: 6608ce78-afce-4d1b-9061-f24c6492c36c Ancestors: VMConstruction-Plugins-AioPlugin-eem.18
replace cCode: '' with cCode:[]
On Sat, May 28, 2016 at 1:52 AM, David T. Lewis lewis@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?
cheers -ben
Also, the change cannot be loaded without enabling the "Allow underscores selectors" preference.
Dave
On Thu, May 26, 2016 at 02:45:24PM +0200, Esteban Lorenzano wrote:
yeah, but now I saw lots of translations are missing too??? so this needs some iterations :(
On 26 May 2016, at 13:56, squeak-dev-noreply@lists.squeakfoundation.org wrote:
Esteban Lorenzano uploaded a new version of VMConstruction-Plugins-AioPlugin to project AioPlugin: http://www.squeaksource.com/AioPlugin/VMConstruction-Plugins-AioPlugin-Esteb...
==================== Summary ====================
Name: VMConstruction-Plugins-AioPlugin-EstebanLorenzano.19 Author: EstebanLorenzano Time: 26 May 2016, 1:56:31.823249 pm UUID: 6608ce78-afce-4d1b-9061-f24c6492c36c Ancestors: VMConstruction-Plugins-AioPlugin-eem.18
replace cCode: '' with cCode:[]
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@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
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@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@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
forget to say: but I’m not admin so I cannot remove it myself… could you please do it?
thanks!
On 28 May 2016, at 11:45, Esteban Lorenzano estebanlm@gmail.com wrote:
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@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@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
Will do, thank you Esteban :-)
Dave
On Sat, May 28, 2016 at 11:47:16AM +0200, Esteban Lorenzano wrote:
forget to say: but I???m not admin so I cannot remove it myself??? could you please do it?
thanks!
On 28 May 2016, at 11:45, Esteban Lorenzano estebanlm@gmail.com wrote:
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@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@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
On Sat, May 28, 2016 at 10:17 AM, David T. Lewis lewis@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@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])
Thanks Dave. That is useful to know. cheers -ben
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_WPretty code is nice, but it is more important that it be correct.
vm-dev@lists.squeakfoundation.org
-
Ben Coman -
David T. Lewis -
Esteban Lorenzano