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/dd74059acb55fc9e3da4756ff7a751adecce7...
[2] https://github.com/zecke/pharo-vm/blob/dd74059acb55fc9e3da4756ff7a751adecce7...
[3] https://github.com/zecke/pharo-vm/commit/dd74059acb55fc9e3da4756ff7a751adecc...
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/dd74059acb55fc9e3da4756ff7a751adecce7...
[2] https://github.com/zecke/pharo-vm/blob/dd74059acb55fc9e3da4756ff7a751adecce7...
[3] https://github.com/zecke/pharo-vm/commit/dd74059acb55fc9e3da4756ff7a751adecc...
On 23 Sep 2016, at 14:40, David T. Lewis lewis@mail.msen.com 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
Hi Holger,
On Fri, Sep 23, 2016 at 6:29 AM, Holger Freyther holger@freyther.de wrote:
On 23 Sep 2016, at 14:40, David T. Lewis lewis@mail.msen.com 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?
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
already noticed some rather questionable features that have crept into
this
plugin over the years ;-)
yes, the ungetc for stdio seems rather odd.
holger
_,,,^..^,,,_ best, Eliot
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; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: FLR: Flash Lights Randomly
+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; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: FLR: Flash Lights Randomly
On 23-09-2016, at 4:15 PM, David T. Lewis lewis@mail.msen.com 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; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: CPP: Crush Plotter Pen
On Fri, Sep 23, 2016 at 2:04 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Holger,
On Fri, Sep 23, 2016 at 6:29 AM, Holger Freyther holger@freyther.de wrote:
On 23 Sep 2016, at 14:40, David T. Lewis lewis@mail.msen.com 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?
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.
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.
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
already noticed some rather questionable features that have crept into
this
plugin over the years ;-)
yes, the ungetc for stdio seems rather odd.
holger
_,,,^..^,,,_ best, Eliot
vm-dev@lists.squeakfoundation.org