Adding new primitives to FilePlugin
Locked
Adding new primitives to FilePlugin
 
|
Good Morning, with UFFI it is easy to call OS functions that return a filedescriptor (e.g. inotify, timerfd, kqueue) but it is then difficult to use it. Classes like AioEventHandler or AttachableFileStream need the fileID (SQFile) but currently there is no way to create a SQFile from a int/FILE*. I would like to propose two new primitives: >>#primitiveFileOpenUseFileDescriptor [1] >>#primitiveFileOpenUseFile [2] and the first implementation[3]. What does it take to get this into the FilePlugin? regards holger [1] https://github.com/zecke/pharo-vm/blob/dd74059acb55fc9e3da4756ff7a751adecce76e2/mc/VMMaker.oscog.package/FilePlugin.class/instance/primitiveFileOpenUseFileDescriptor.st [2] https://github.com/zecke/pharo-vm/blob/dd74059acb55fc9e3da4756ff7a751adecce76e2/mc/VMMaker.oscog.package/FilePlugin.class/instance/primitiveFileOpenUseFile.st [3] https://github.com/zecke/pharo-vm/commit/dd74059acb55fc9e3da4756ff7a751adecce76e2#diff-9bbe8b1dab4518d9de3cc7326295466bR296 |
Re: Adding new primitives to FilePlugin
|
|
I suggest that you try this first by making your own plugin separate from FilePlugin. If the idea proves useful in a general way, then consider adding it to FilePlugin. FilePlugin is one of a small number of essential plugins that needs to be implemented when bringing up a VM an a new platform, so it is generally a good idea to resist the temptation to add features there. >From your previous email regarding sqFileReadIntoAt(), I think that you have already noticed some rather questionable features that have crept into this plugin over the years ;-) Dave On Fri, Sep 23, 2016 at 10:40:15AM +0200, Holger Freyther wrote: > > Good Morning, > > with UFFI it is easy to call OS functions that return a filedescriptor (e.g. inotify, timerfd, kqueue) but it is then difficult to use it. Classes like AioEventHandler or AttachableFileStream need the fileID (SQFile) but currently there is no way to create a SQFile from a int/FILE*. > > I would like to propose two new primitives: > > >>#primitiveFileOpenUseFileDescriptor [1] > >>#primitiveFileOpenUseFile [2] > > and the first implementation[3]. What does it take to get this into the FilePlugin? > > regards > holger > > > > [1] https://github.com/zecke/pharo-vm/blob/dd74059acb55fc9e3da4756ff7a751adecce76e2/mc/VMMaker.oscog.package/FilePlugin.class/instance/primitiveFileOpenUseFileDescriptor.st > > [2] https://github.com/zecke/pharo-vm/blob/dd74059acb55fc9e3da4756ff7a751adecce76e2/mc/VMMaker.oscog.package/FilePlugin.class/instance/primitiveFileOpenUseFile.st > > [3] https://github.com/zecke/pharo-vm/commit/dd74059acb55fc9e3da4756ff7a751adecce76e2#diff-9bbe8b1dab4518d9de3cc7326295466bR296 |
Re: Adding new primitives to FilePlugin
|
|
> On 23 Sep 2016, at 14:40, David T. Lewis <[hidden email]> wrote: > > > I suggest that you try this first by making your own plugin separate from FilePlugin. > If the idea proves useful in a general way, then consider adding it to FilePlugin. > > FilePlugin is one of a small number of essential plugins that needs to be implemented > when bringing up a VM an a new platform, so it is generally a good idea to resist > the temptation to add features there. Fair enough but the other plugin would need to have access to struct SQFile and without plugin dependencies and ABI versioning doing it in another plugin looks rather fragile. fdopen is not in C99 but the other primitive does not add burden on porting as a valid FILE* ptr is passed in and used. No additional API calls are made. Any objection to this primitive? >> From your previous email regarding sqFileReadIntoAt(), I think that you have > already noticed some rather questionable features that have crept into this > plugin over the years ;-) yes, the ungetc for stdio seems rather odd. holger |
Re: Adding new primitives to FilePlugin
|
|
Hi Holger,
On Fri, Sep 23, 2016 at 6:29 AM, Holger Freyther <[hidden email]> wrote:
Not from me. Seems like a very good idea. Feel free to contribute an implementation. I think we should also provide a primitive that answers the file descriptor associated with the fileID. We could also provide primitives that set and get the FILE * structure if the platform has something analogous. This pair of primitives could either fail if the platform fdoesn't use this (Windows) or degenerate to the file descriptor access primitives. What do you think? >> From your previous email regarding sqFileReadIntoAt(), I think that you have _,,,^..^,,,_ best, Eliot |
Re: Adding new primitives to FilePlugin
|
|
While you’re experimenting you can obviously throw any wild and crazy code you like into a plugin. If you want to provide some specialised code that not everyone will want, then a separate plugin is probably better, even if it meant effectively duplicating something like the SQFile struct. The only time it could become a real problem would be if the original FilePlugin definition were to be changed - that hasn’t happened in a while. And you can see in FilePlugin.h that you can get away with different platforms having slightly different structs anyway since the internal are completely hidden from the image. For most cases simply including FilePlugin.h would solve the issue. A potentially better solution would be to provide platform specific plugins where needed and move the portability wrapping up to the image. There is no technical barrier to having separate platform specific classes for the lowest levels of things like file access, with a suitable platform specific plugin (or FFI or Alien) interface. Trying to fit all the platform hiding into a plugin can cause some real ugliness in some cases. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: FLR: Flash Lights Randomly |
Re: Adding new primitives to FilePlugin
|
|
In reply to this post by Eliot Miranda-2
On Fri, Sep 23, 2016 at 2:04 PM, Eliot Miranda <[hidden email]> wrote:
Yes! I was thinking about this one too some hours ago. I workaround it (for my usecase) because I FIRST got the FD (from pipe()) and then got the fileID...so I could simply "remember it" at my side. But sure, getting the fd from a fileID would be very nice to have too.
|
Re: Adding new primitives to FilePlugin
|
|
In reply to this post by timrowledge
+1000 to everything Tim says below. Dave On Fri, Sep 23, 2016 at 11:24:39AM -0700, tim Rowledge wrote: > > While you???re experimenting you can obviously throw any wild and crazy code you like into a plugin. > > If you want to provide some specialised code that not everyone will want, then a separate plugin is probably better, even if it meant effectively duplicating something like the SQFile struct. The only time it could become a real problem would be if the original FilePlugin definition were to be changed - that hasn???t happened in a while. > > And you can see in FilePlugin.h that you can get away with different platforms having slightly different structs anyway since the internal are completely hidden from the image. For most cases simply including FilePlugin.h would solve the issue. > > A potentially better solution would be to provide platform specific plugins where needed and move the portability wrapping up to the image. There is no technical barrier to having separate platform specific classes for the lowest levels of things like file access, with a suitable platform specific plugin (or FFI or Alien) interface. Trying to fit all the platform hiding into a plugin can cause some real ugliness in some cases. > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Strange OpCodes: FLR: Flash Lights Randomly > |
Re: Adding new primitives to FilePlugin
|
|
> On 23-09-2016, at 4:15 PM, David T. Lewis <[hidden email]> wrote: > > > +1000 to everything Tim says below. > [snip] > There is no technical barrier to having separate platform specific classes for the lowest levels of things like file access, with a suitable platform specific plugin (or FFI or Alien) interface. Trying to fit all the platform hiding into a plugin can cause some real ugliness in some cases. As an existence proof, consider the ancient Acorn RISC OS file interface Eliot & I wrote back around 1987, entirely without any primitives other than a single SWI call used to operate the entire file system. The same image had a ‘normal’ file interface for other lesser OS’s such as Unix and DOS of the era. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: CPP: Crush Plotter Pen |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |