[Vm-dev] Fwd: Merging FilesAttributesPlugin

[Eliot Miranda]

Hi Clément, Hi Alistair,

    FileAttrbutesPlugin is not yet ready for use.  The main problem is that it neither fails properly nor communicates error codes back properly.  Basically FileAttrbutesPlugin confuses failing because it gets invalid arguments with reporting error codes due to operating system level errors.  For the FileAttrbutesPlugin's primitives to work in Spur they must fail in the traditional way when given invalid arguments.  This is because the Spur VM will check when a primitive fails if there are any forwarders in the primitive's parameters, and if so, follow (fix up) the forwarders and retry the primitive.  

Next, communication no os errors back through the primitives results is acceptable, but a better way would be to use the new #'operating system error' primitive failure code mechanism.  Here, provided a suitable two slot prototype is installed in the primitiveErrorTable (see Squeak trunk) then a plugin can do
        interpreterProxy primitiveFailForOSError(signedSixtyFourBitErrorCode)
and the VM will clone the error object whose first slot should be #'operating system error' and whose second slot will be the code.

This gives us a clean way of communicating errors back to a primitive's method body in the traditional way.

I do apologize if I hadn't made this clear earlier.  But AFAIA there is significant work to do before the plugin is ready for integration. 

_,,,^..^,,,_ (phone)

> On Dec 22, 2017, at 2:48 AM, Alistair Grant <akgrant0710 at gmail.com> wrote:
> 
> 
> Hi Clément,
> 
>> On 22 December 2017 at 11:29, Clément Bera <bera.clement at gmail.com> wrote:
>> 
>> Hi,
>> 
>> What is the status of the FilesAttributesPlugin ?
> 
> I'm hoping that it will be integrated soon.
> 
> 
>> I would like to make it available by default on pharo VMs.
> 
> Yes, please. :-)
> 
> 
>> Questions:
>> 
>> 1) Is it already merged with another plugin ?
> 
> I'm not sure that I understand the question.  FileAttributesPlugin
> works along side FilePlugin (which is obviously already part of the
> pharo VM).
> 
> 
>> 2) If not, for integration, should I move the FilesAttributesPlugin from its external smalltalkhub repository to VMMaker-Plugins package ?
> 
> That's my guess, but someone knowledgable needs to answer this.
> 
> 
>> 3) What is the right way to generate a plugin ? I use this:
>> 
>> (VMMaker
>> makerFor: StackInterpreter
>> and: nil
>> with: #()
>> to: (FileDirectory default pathFromURI: '../src')
>> platformDir: (FileDirectory default pathFromURI: '../platforms')
>> including: #(FileAttributesPlugin)
>> ) generateExternalPlugin: FileAttributesPlugin
>> 
>> Is that correct ?
>> It seems it generates only the C file but no header file.
> 
> There isn't a FileAttributesPlugin.h.  It does need the platform support file:
> 
> platforms/win32/plugins/FileAttributesPlugin/Makefile.plugin
> 
> which is already part of opensmalltalk-vm.
> 
> I've always used VMMakerTool to make the plugin, but if it's
> generating the .c file it's probably correct.
> 
> 
> My plan was that once the plugin was added to VMMaker-Plugins that I
> would test it again on linux and windows, and then ask for the
> appropriate plugins.int to be updated.
> 
> 
> Thanks!
> Alistair
> 
> 
>> Thanks,
>> 
>> --
>> Clément Béra
>> https://clementbera.wordpress.com/
>> Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq