PlatformAdaptationLayer - scope

What is the correct way to view the PlatformAdaptationLayer? My initial
assumption was that it was IronRuby’s abstraction of the file system
(and environment variables), but in digging deeper I see that the Dir
builtin is calling into the file system in many places using the
System.IO classes directly. My next thought was that the PAL must then
be purely a hosting construct that exists to allow hosts to provide
alternative dependency resolution, but this doesn’t seem to quite fit
either, since the Glob implementation, which is also a part of Dir.cs,
does go through the PAL, so it isn’t just used for dependency
resolution. Is the long term plan to make all file system manipulation
go through the PAL, and if not, could someone shed some light on how the
PAL is intended to be used / understood? I’m attempting to do something
similar to the ZipArchive stuff in Chiron, that would allow zip files to
be put into the application path of non-silverlight apps, or used for
the Gem_Path, etc (for easy deployment of IronRuby, gems and other
static library code) but I’m concerned that if a gem or some other ruby
code tries to scan the file system for convention based dependencies
(does this even happen?) the PAL may get bypassed entirely under certain
circumstances. I’m not familiar enough with the ruby libraries to know
if this should even be a concern in practice, but the
zip-as-virtual-file-system metaphor looks like it will have some holes
at least in theory.

Thanks,

Nathan

Your initial intuition is right. The intention is to provide some
abstraction of the file system/OS. The goal is not to provide a complete
abstraction but one that is complete enough to support common
operations. If the abstraction is leaking somewhere it’s either a bug or
there is a good reason why the code doesn’t use PAL (for example, the
operation is platform/Ruby specific and has no simple abstraction). So
if you have a good use-case that doesn’t work right now feel free to
file a bug here: http://ironruby.codeplex.com/WorkItem/AdvancedList.aspx
and we’ll fix it.

Tomas

From: [email protected]
[mailto:[email protected]] On Behalf Of Nathan Stults
Sent: Tuesday, October 13, 2009 11:19 PM
To: [email protected]
Subject: [Ironruby-core] PlatformAdaptationLayer - scope

What is the correct way to view the PlatformAdaptationLayer? My initial
assumption was that it was IronRuby’s abstraction of the file system
(and environment variables), but in digging deeper I see that the Dir
builtin is calling into the file system in many places using the
System.IO classes directly. My next thought was that the PAL must then
be purely a hosting construct that exists to allow hosts to provide
alternative dependency resolution, but this doesn’t seem to quite fit
either, since the Glob implementation, which is also a part of Dir.cs,
does go through the PAL, so it isn’t just used for dependency
resolution. Is the long term plan to make all file system manipulation
go through the PAL, and if not, could someone shed some light on how the
PAL is intended to be used / understood? I’m attempting to do something
similar to the ZipArchive stuff in Chiron, that would allow zip files to
be put into the application path of non-silverlight apps, or used for
the Gem_Path, etc (for easy deployment of IronRuby, gems and other
static library code) but I’m concerned that if a gem or some other ruby
code tries to scan the file system for convention based dependencies
(does this even happen?) the PAL may get bypassed entirely under certain
circumstances. I’m not familiar enough with the ruby libraries to know
if this should even be a concern in practice, but the
zip-as-virtual-file-system metaphor looks like it will have some holes
at least in theory.

Thanks,

Nathan

I have run into a problem, which I think I can work around, but before I
contaminate your bug list, I thought I’d see if there is any point, or
if I’ve simply exceeded the expected use of the PAL. The problem I’m
having is that I want to treat a zip file as a virtual file system, as
if it were a mounted drive from the DLR’s perspective. My issue at the
moment is that, while the PAL defines an IsAbsolutePath method,
RubyFileOps via RubyUtils uses its own concept of IsAbsolutePath. My
desire, at least my initial desire, is to treat “myzip.zip” as a path
root, so that “myzip.zip/mydir/myfile.rb” can be considered an absolute
path by my version of PAL. This works for all standard dependencies, but
ruby gems likes to call File.expand_path on stuff, and this bypasses my
PAL’s IsAbsolutePath entirely, so “myzip.zip”, which had heretofore been
treated as if “myzip.zip” were a drive letter because of my
implementation of IsAbsolutePath, is now blown out into
“c:\myapp\bin\debug\myzip.zip\mydir\myfile.rb”. Anyway, that was a long
way of asking, am I trying to stretch the PAL too far, or is this in
fact a valid issue? I do get that Ruby may do certain things differently
than the DLR proper, and that the implementation of IronRuby libraries
needs to reflect that, but I wonder if variances from the standard DLR
PlatformAdaptationLayer might possibly be modeled by providing a
non-sealed, IronRuby specific PAL that implements the Rubyisms but also
allows those of us who wish to modify global behavior to inherit from
the ruby version and apply our tweaks.

From: [email protected]
[mailto:[email protected]] On Behalf Of Tomas M.
Sent: Tuesday, October 13, 2009 11:36 PM
To: [email protected]
Subject: Re: [Ironruby-core] PlatformAdaptationLayer - scope

Your initial intuition is right. The intention is to provide some
abstraction of the file system/OS. The goal is not to provide a complete
abstraction but one that is complete enough to support common
operations. If the abstraction is leaking somewhere it’s either a bug or
there is a good reason why the code doesn’t use PAL (for example, the
operation is platform/Ruby specific and has no simple abstraction). So
if you have a good use-case that doesn’t work right now feel free to
file a bug here: http://ironruby.codeplex.com/WorkItem/AdvancedList.aspx
and we’ll fix it.

Tomas

From: [email protected]
[mailto:[email protected]] On Behalf Of Nathan Stults
Sent: Tuesday, October 13, 2009 11:19 PM
To: [email protected]
Subject: [Ironruby-core] PlatformAdaptationLayer - scope

What is the correct way to view the PlatformAdaptationLayer? My initial
assumption was that it was IronRuby’s abstraction of the file system
(and environment variables), but in digging deeper I see that the Dir
builtin is calling into the file system in many places using the
System.IO classes directly. My next thought was that the PAL must then
be purely a hosting construct that exists to allow hosts to provide
alternative dependency resolution, but this doesn’t seem to quite fit
either, since the Glob implementation, which is also a part of Dir.cs,
does go through the PAL, so it isn’t just used for dependency
resolution. Is the long term plan to make all file system manipulation
go through the PAL, and if not, could someone shed some light on how the
PAL is intended to be used / understood? I’m attempting to do something
similar to the ZipArchive stuff in Chiron, that would allow zip files to
be put into the application path of non-silverlight apps, or used for
the Gem_Path, etc (for easy deployment of IronRuby, gems and other
static library code) but I’m concerned that if a gem or some other ruby
code tries to scan the file system for convention based dependencies
(does this even happen?) the PAL may get bypassed entirely under certain
circumstances. I’m not familiar enough with the ruby libraries to know
if this should even be a concern in practice, but the
zip-as-virtual-file-system metaphor looks like it will have some holes
at least in theory.

Thanks,

Nathan

How should the entire virtual file system look like? Is “myzip.zip” the
only root? Or do you need multiple roots (like drive letters on
Windows)?

Tomas

From: [email protected]
[mailto:[email protected]] On Behalf Of Nathan Stults
Sent: Wednesday, October 14, 2009 11:05 PM
To: [email protected]
Subject: Re: [Ironruby-core] PlatformAdaptationLayer - scope

I have run into a problem, which I think I can work around, but before I
contaminate your bug list, I thought I’d see if there is any point, or
if I’ve simply exceeded the expected use of the PAL. The problem I’m
having is that I want to treat a zip file as a virtual file system, as
if it were a mounted drive from the DLR’s perspective. My issue at the
moment is that, while the PAL defines an IsAbsolutePath method,
RubyFileOps via RubyUtils uses its own concept of IsAbsolutePath. My
desire, at least my initial desire, is to treat “myzip.zip” as a path
root, so that “myzip.zip/mydir/myfile.rb” can be considered an absolute
path by my version of PAL. This works for all standard dependencies, but
ruby gems likes to call File.expand_path on stuff, and this bypasses my
PAL’s IsAbsolutePath entirely, so “myzip.zip”, which had heretofore been
treated as if “myzip.zip” were a drive letter because of my
implementation of IsAbsolutePath, is now blown out into
“c:\myapp\bin\debug\myzip.zip\mydir\myfile.rb”. Anyway, that was a long
way of asking, am I trying to stretch the PAL too far, or is this in
fact a valid issue? I do get that Ruby may do certain things differently
than the DLR proper, and that the implementation of IronRuby libraries
needs to reflect that, but I wonder if variances from the standard DLR
PlatformAdaptationLayer might possibly be modeled by providing a
non-sealed, IronRuby specific PAL that implements the Rubyisms but also
allows those of us who wish to modify global behavior to inherit from
the ruby version and apply our tweaks.

From: [email protected]
[mailto:[email protected]] On Behalf Of Tomas M.
Sent: Tuesday, October 13, 2009 11:36 PM
To: [email protected]
Subject: Re: [Ironruby-core] PlatformAdaptationLayer - scope

Your initial intuition is right. The intention is to provide some
abstraction of the file system/OS. The goal is not to provide a complete
abstraction but one that is complete enough to support common
operations. If the abstraction is leaking somewhere it’s either a bug or
there is a good reason why the code doesn’t use PAL (for example, the
operation is platform/Ruby specific and has no simple abstraction). So
if you have a good use-case that doesn’t work right now feel free to
file a bug here: http://ironruby.codeplex.com/WorkItem/AdvancedList.aspx
and we’ll fix it.

Tomas

From: [email protected]
[mailto:[email protected]] On Behalf Of Nathan Stults
Sent: Tuesday, October 13, 2009 11:19 PM
To: [email protected]
Subject: [Ironruby-core] PlatformAdaptationLayer - scope

What is the correct way to view the PlatformAdaptationLayer? My initial
assumption was that it was IronRuby’s abstraction of the file system
(and environment variables), but in digging deeper I see that the Dir
builtin is calling into the file system in many places using the
System.IO classes directly. My next thought was that the PAL must then
be purely a hosting construct that exists to allow hosts to provide
alternative dependency resolution, but this doesn’t seem to quite fit
either, since the Glob implementation, which is also a part of Dir.cs,
does go through the PAL, so it isn’t just used for dependency
resolution. Is the long term plan to make all file system manipulation
go through the PAL, and if not, could someone shed some light on how the
PAL is intended to be used / understood? I’m attempting to do something
similar to the ZipArchive stuff in Chiron, that would allow zip files to
be put into the application path of non-silverlight apps, or used for
the Gem_Path, etc (for easy deployment of IronRuby, gems and other
static library code) but I’m concerned that if a gem or some other ruby
code tries to scan the file system for convention based dependencies
(does this even happen?) the PAL may get bypassed entirely under certain
circumstances. I’m not familiar enough with the ruby libraries to know
if this should even be a concern in practice, but the
zip-as-virtual-file-system metaphor looks like it will have some holes
at least in theory.

Thanks,

Nathan

Sounds like you just need a PAL implementation which looks into zip
files. Why do you have to promote zip files to be roots? That seems very
strange. Why not just add the zip file path to the SearchPath, so your
script files can be required via normal path resolution? I’d like to
understand more about more motivation to do this, so we can accurately
determine whether this is a scenario the PAL should cover.

I’m doing the same thing with using zip files as a file-system in
Silverlight; the path to the ZIP file is a real location like
http://foo.com/mylibs.zip, and then that is added to the SearchPath so
script files can be required out of the zip. For file-system operations
like File.open, you can either use the full path name like
http://foo.com/mylibs.zip/foo.rb or the path will be relative to the
current HTML file, so “mylibs.zip/foo.rb” will do just fine.

~js

From: [email protected]
[mailto:[email protected]] On Behalf Of Nathan Stults
Sent: Thursday, October 15, 2009 6:58 AM
To: [email protected]
Subject: Re: [Ironruby-core] PlatformAdaptationLayer - scope

There may be multiple roots, of course existing roots are still roots
(c:…, f:…) but I am adding roots. In my current
implementation, any time my PAL is asked to resolve a path that starts
with xxxx.zip (or some other magic extension) then it creates a new
root, and future requests to resolve paths rooted in xxxx.zip will look
in the zip file in question, not the file system.

From: [email protected]
[mailto:[email protected]] On Behalf Of Tomas M.
Sent: Thursday, October 15, 2009 12:07 AM
To: [email protected]
Subject: Re: [Ironruby-core] PlatformAdaptationLayer - scope

How should the entire virtual file system look like? Is “myzip.zip” the
only root? Or do you need multiple roots (like drive letters on
Windows)?

Tomas

From: [email protected]
[mailto:[email protected]] On Behalf Of Nathan Stults
Sent: Wednesday, October 14, 2009 11:05 PM
To: [email protected]
Subject: Re: [Ironruby-core] PlatformAdaptationLayer - scope

I have run into a problem, which I think I can work around, but before I
contaminate your bug list, I thought I’d see if there is any point, or
if I’ve simply exceeded the expected use of the PAL. The problem I’m
having is that I want to treat a zip file as a virtual file system, as
if it were a mounted drive from the DLR’s perspective. My issue at the
moment is that, while the PAL defines an IsAbsolutePath method,
RubyFileOps via RubyUtils uses its own concept of IsAbsolutePath. My
desire, at least my initial desire, is to treat “myzip.zip” as a path
root, so that “myzip.zip/mydir/myfile.rb” can be considered an absolute
path by my version of PAL. This works for all standard dependencies, but
ruby gems likes to call File.expand_path on stuff, and this bypasses my
PAL’s IsAbsolutePath entirely, so “myzip.zip”, which had heretofore been
treated as if “myzip.zip” were a drive letter because of my
implementation of IsAbsolutePath, is now blown out into
“c:\myapp\bin\debug\myzip.zip\mydir\myfile.rb”. Anyway, that was a long
way of asking, am I trying to stretch the PAL too far, or is this in
fact a valid issue? I do get that Ruby may do certain things differently
than the DLR proper, and that the implementation of IronRuby libraries
needs to reflect that, but I wonder if variances from the standard DLR
PlatformAdaptationLayer might possibly be modeled by providing a
non-sealed, IronRuby specific PAL that implements the Rubyisms but also
allows those of us who wish to modify global behavior to inherit from
the ruby version and apply our tweaks.

From: [email protected]
[mailto:[email protected]] On Behalf Of Tomas M.
Sent: Tuesday, October 13, 2009 11:36 PM
To: [email protected]
Subject: Re: [Ironruby-core] PlatformAdaptationLayer - scope

Your initial intuition is right. The intention is to provide some
abstraction of the file system/OS. The goal is not to provide a complete
abstraction but one that is complete enough to support common
operations. If the abstraction is leaking somewhere it’s either a bug or
there is a good reason why the code doesn’t use PAL (for example, the
operation is platform/Ruby specific and has no simple abstraction). So
if you have a good use-case that doesn’t work right now feel free to
file a bug here: http://ironruby.codeplex.com/WorkItem/AdvancedList.aspx
and we’ll fix it.

Tomas

From: [email protected]
[mailto:[email protected]] On Behalf Of Nathan Stults
Sent: Tuesday, October 13, 2009 11:19 PM
To: [email protected]
Subject: [Ironruby-core] PlatformAdaptationLayer - scope

What is the correct way to view the PlatformAdaptationLayer? My initial
assumption was that it was IronRuby’s abstraction of the file system
(and environment variables), but in digging deeper I see that the Dir
builtin is calling into the file system in many places using the
System.IO classes directly. My next thought was that the PAL must then
be purely a hosting construct that exists to allow hosts to provide
alternative dependency resolution, but this doesn’t seem to quite fit
either, since the Glob implementation, which is also a part of Dir.cs,
does go through the PAL, so it isn’t just used for dependency
resolution. Is the long term plan to make all file system manipulation
go through the PAL, and if not, could someone shed some light on how the
PAL is intended to be used / understood? I’m attempting to do something
similar to the ZipArchive stuff in Chiron, that would allow zip files to
be put into the application path of non-silverlight apps, or used for
the Gem_Path, etc (for easy deployment of IronRuby, gems and other
static library code) but I’m concerned that if a gem or some other ruby
code tries to scan the file system for convention based dependencies
(does this even happen?) the PAL may get bypassed entirely under certain
circumstances. I’m not familiar enough with the ruby libraries to know
if this should even be a concern in practice, but the
zip-as-virtual-file-system metaphor looks like it will have some holes
at least in theory.

Thanks,

Nathan

There may be multiple roots, of course existing roots are still roots
(c:…, f:…) but I am adding roots. In my current
implementation, any time my PAL is asked to resolve a path that starts
with xxxx.zip (or some other magic extension) then it creates a new
root, and future requests to resolve paths rooted in xxxx.zip will look
in the zip file in question, not the file system.

From: [email protected]
[mailto:[email protected]] On Behalf Of Tomas M.
Sent: Thursday, October 15, 2009 12:07 AM
To: [email protected]
Subject: Re: [Ironruby-core] PlatformAdaptationLayer - scope

How should the entire virtual file system look like? Is “myzip.zip” the
only root? Or do you need multiple roots (like drive letters on
Windows)?

Tomas

From: [email protected]
[mailto:[email protected]] On Behalf Of Nathan Stults
Sent: Wednesday, October 14, 2009 11:05 PM
To: [email protected]
Subject: Re: [Ironruby-core] PlatformAdaptationLayer - scope

I have run into a problem, which I think I can work around, but before I
contaminate your bug list, I thought I’d see if there is any point, or
if I’ve simply exceeded the expected use of the PAL. The problem I’m
having is that I want to treat a zip file as a virtual file system, as
if it were a mounted drive from the DLR’s perspective. My issue at the
moment is that, while the PAL defines an IsAbsolutePath method,
RubyFileOps via RubyUtils uses its own concept of IsAbsolutePath. My
desire, at least my initial desire, is to treat “myzip.zip” as a path
root, so that “myzip.zip/mydir/myfile.rb” can be considered an absolute
path by my version of PAL. This works for all standard dependencies, but
ruby gems likes to call File.expand_path on stuff, and this bypasses my
PAL’s IsAbsolutePath entirely, so “myzip.zip”, which had heretofore been
treated as if “myzip.zip” were a drive letter because of my
implementation of IsAbsolutePath, is now blown out into
“c:\myapp\bin\debug\myzip.zip\mydir\myfile.rb”. Anyway, that was a long
way of asking, am I trying to stretch the PAL too far, or is this in
fact a valid issue? I do get that Ruby may do certain things differently
than the DLR proper, and that the implementation of IronRuby libraries
needs to reflect that, but I wonder if variances from the standard DLR
PlatformAdaptationLayer might possibly be modeled by providing a
non-sealed, IronRuby specific PAL that implements the Rubyisms but also
allows those of us who wish to modify global behavior to inherit from
the ruby version and apply our tweaks.

From: [email protected]
[mailto:[email protected]] On Behalf Of Tomas M.
Sent: Tuesday, October 13, 2009 11:36 PM
To: [email protected]
Subject: Re: [Ironruby-core] PlatformAdaptationLayer - scope

Your initial intuition is right. The intention is to provide some
abstraction of the file system/OS. The goal is not to provide a complete
abstraction but one that is complete enough to support common
operations. If the abstraction is leaking somewhere it’s either a bug or
there is a good reason why the code doesn’t use PAL (for example, the
operation is platform/Ruby specific and has no simple abstraction). So
if you have a good use-case that doesn’t work right now feel free to
file a bug here: http://ironruby.codeplex.com/WorkItem/AdvancedList.aspx
and we’ll fix it.

Tomas

From: [email protected]
[mailto:[email protected]] On Behalf Of Nathan Stults
Sent: Tuesday, October 13, 2009 11:19 PM
To: [email protected]
Subject: [Ironruby-core] PlatformAdaptationLayer - scope

What is the correct way to view the PlatformAdaptationLayer? My initial
assumption was that it was IronRuby’s abstraction of the file system
(and environment variables), but in digging deeper I see that the Dir
builtin is calling into the file system in many places using the
System.IO classes directly. My next thought was that the PAL must then
be purely a hosting construct that exists to allow hosts to provide
alternative dependency resolution, but this doesn’t seem to quite fit
either, since the Glob implementation, which is also a part of Dir.cs,
does go through the PAL, so it isn’t just used for dependency
resolution. Is the long term plan to make all file system manipulation
go through the PAL, and if not, could someone shed some light on how the
PAL is intended to be used / understood? I’m attempting to do something
similar to the ZipArchive stuff in Chiron, that would allow zip files to
be put into the application path of non-silverlight apps, or used for
the Gem_Path, etc (for easy deployment of IronRuby, gems and other
static library code) but I’m concerned that if a gem or some other ruby
code tries to scan the file system for convention based dependencies
(does this even happen?) the PAL may get bypassed entirely under certain
circumstances. I’m not familiar enough with the ruby libraries to know
if this should even be a concern in practice, but the
zip-as-virtual-file-system metaphor looks like it will have some holes
at least in theory.

Thanks,

Nathan

I agree with Jimmy, defining “myzip.zip” as a root is strange. How do
you distinguish between a relative path that starts with “myzip.zip”
(let’s say I create a “myzip.zip” subdirectory in the current directory)
from a rooted path?

Tomas

From: [email protected]
[mailto:[email protected]] On Behalf Of Jimmy
Schementi
Sent: Thursday, October 15, 2009 11:10 AM
To: [email protected]
Subject: Re: [Ironruby-core] PlatformAdaptationLayer - scope

Sounds like you just need a PAL implementation which looks into zip
files. Why do you have to promote zip files to be roots? That seems very
strange. Why not just add the zip file path to the SearchPath, so your
script files can be required via normal path resolution? I’d like to
understand more about more motivation to do this, so we can accurately
determine whether this is a scenario the PAL should cover.

I’m doing the same thing with using zip files as a file-system in
Silverlight; the path to the ZIP file is a real location like
http://foo.com/mylibs.zip, and then that is added to the SearchPath so
script files can be required out of the zip. For file-system operations
like File.open, you can either use the full path name like
http://foo.com/mylibs.zip/foo.rb or the path will be relative to the
current HTML file, so “mylibs.zip/foo.rb” will do just fine.

~js

From: [email protected]
[mailto:[email protected]] On Behalf Of Nathan Stults
Sent: Thursday, October 15, 2009 6:58 AM
To: [email protected]
Subject: Re: [Ironruby-core] PlatformAdaptationLayer - scope

There may be multiple roots, of course existing roots are still roots
(c:…, f:…) but I am adding roots. In my current
implementation, any time my PAL is asked to resolve a path that starts
with xxxx.zip (or some other magic extension) then it creates a new
root, and future requests to resolve paths rooted in xxxx.zip will look
in the zip file in question, not the file system.

From: [email protected]
[mailto:[email protected]] On Behalf Of Tomas M.
Sent: Thursday, October 15, 2009 12:07 AM
To: [email protected]
Subject: Re: [Ironruby-core] PlatformAdaptationLayer - scope

How should the entire virtual file system look like? Is “myzip.zip” the
only root? Or do you need multiple roots (like drive letters on
Windows)?

Tomas

From: [email protected]
[mailto:[email protected]] On Behalf Of Nathan Stults
Sent: Wednesday, October 14, 2009 11:05 PM
To: [email protected]
Subject: Re: [Ironruby-core] PlatformAdaptationLayer - scope

I have run into a problem, which I think I can work around, but before I
contaminate your bug list, I thought I’d see if there is any point, or
if I’ve simply exceeded the expected use of the PAL. The problem I’m
having is that I want to treat a zip file as a virtual file system, as
if it were a mounted drive from the DLR’s perspective. My issue at the
moment is that, while the PAL defines an IsAbsolutePath method,
RubyFileOps via RubyUtils uses its own concept of IsAbsolutePath. My
desire, at least my initial desire, is to treat “myzip.zip” as a path
root, so that “myzip.zip/mydir/myfile.rb” can be considered an absolute
path by my version of PAL. This works for all standard dependencies, but
ruby gems likes to call File.expand_path on stuff, and this bypasses my
PAL’s IsAbsolutePath entirely, so “myzip.zip”, which had heretofore been
treated as if “myzip.zip” were a drive letter because of my
implementation of IsAbsolutePath, is now blown out into
“c:\myapp\bin\debug\myzip.zip\mydir\myfile.rb”. Anyway, that was a long
way of asking, am I trying to stretch the PAL too far, or is this in
fact a valid issue? I do get that Ruby may do certain things differently
than the DLR proper, and that the implementation of IronRuby libraries
needs to reflect that, but I wonder if variances from the standard DLR
PlatformAdaptationLayer might possibly be modeled by providing a
non-sealed, IronRuby specific PAL that implements the Rubyisms but also
allows those of us who wish to modify global behavior to inherit from
the ruby version and apply our tweaks.

From: [email protected]
[mailto:[email protected]] On Behalf Of Tomas M.
Sent: Tuesday, October 13, 2009 11:36 PM
To: [email protected]
Subject: Re: [Ironruby-core] PlatformAdaptationLayer - scope

Your initial intuition is right. The intention is to provide some
abstraction of the file system/OS. The goal is not to provide a complete
abstraction but one that is complete enough to support common
operations. If the abstraction is leaking somewhere it’s either a bug or
there is a good reason why the code doesn’t use PAL (for example, the
operation is platform/Ruby specific and has no simple abstraction). So
if you have a good use-case that doesn’t work right now feel free to
file a bug here: http://ironruby.codeplex.com/WorkItem/AdvancedList.aspx
and we’ll fix it.

Tomas

From: [email protected]
[mailto:[email protected]] On Behalf Of Nathan Stults
Sent: Tuesday, October 13, 2009 11:19 PM
To: [email protected]
Subject: [Ironruby-core] PlatformAdaptationLayer - scope

What is the correct way to view the PlatformAdaptationLayer? My initial
assumption was that it was IronRuby’s abstraction of the file system
(and environment variables), but in digging deeper I see that the Dir
builtin is calling into the file system in many places using the
System.IO classes directly. My next thought was that the PAL must then
be purely a hosting construct that exists to allow hosts to provide
alternative dependency resolution, but this doesn’t seem to quite fit
either, since the Glob implementation, which is also a part of Dir.cs,
does go through the PAL, so it isn’t just used for dependency
resolution. Is the long term plan to make all file system manipulation
go through the PAL, and if not, could someone shed some light on how the
PAL is intended to be used / understood? I’m attempting to do something
similar to the ZipArchive stuff in Chiron, that would allow zip files to
be put into the application path of non-silverlight apps, or used for
the Gem_Path, etc (for easy deployment of IronRuby, gems and other
static library code) but I’m concerned that if a gem or some other ruby
code tries to scan the file system for convention based dependencies
(does this even happen?) the PAL may get bypassed entirely under certain
circumstances. I’m not familiar enough with the ruby libraries to know
if this should even be a concern in practice, but the
zip-as-virtual-file-system metaphor looks like it will have some holes
at least in theory.

Thanks,

Nathan

Thanks - that approach worked much better, everything is working
perfectly, except that it is sloooooow. I’ll have to try zero
compression and see if that helps, and if not maybe some form of
pre-fetching and caching will be required. One concern is that because
the DLR appears to require its streams to be seekable, I have to copy
each de-compressed file into a memory stream, causing each stream to be
read twice. I have no idea how much that contributes to the performance
issues though.

From: [email protected]
[mailto:[email protected]] On Behalf Of Jimmy
Schementi
Sent: Thursday, October 15, 2009 11:10 AM
To: [email protected]
Subject: Re: [Ironruby-core] PlatformAdaptationLayer - scope

Sounds like you just need a PAL implementation which looks into zip
files. Why do you have to promote zip files to be roots? That seems very
strange. Why not just add the zip file path to the SearchPath, so your
script files can be required via normal path resolution? I’d like to
understand more about more motivation to do this, so we can accurately
determine whether this is a scenario the PAL should cover.

I’m doing the same thing with using zip files as a file-system in
Silverlight; the path to the ZIP file is a real location like
http://foo.com/mylibs.zip, and then that is added to the SearchPath so
script files can be required out of the zip. For file-system operations
like File.open, you can either use the full path name like
http://foo.com/mylibs.zip/foo.rb or the path will be relative to the
current HTML file, so “mylibs.zip/foo.rb” will do just fine.

~js

From: [email protected]
[mailto:[email protected]] On Behalf Of Nathan Stults
Sent: Thursday, October 15, 2009 6:58 AM
To: [email protected]
Subject: Re: [Ironruby-core] PlatformAdaptationLayer - scope

There may be multiple roots, of course existing roots are still roots
(c:…, f:…) but I am adding roots. In my current
implementation, any time my PAL is asked to resolve a path that starts
with xxxx.zip (or some other magic extension) then it creates a new
root, and future requests to resolve paths rooted in xxxx.zip will look
in the zip file in question, not the file system.

From: [email protected]
[mailto:[email protected]] On Behalf Of Tomas M.
Sent: Thursday, October 15, 2009 12:07 AM
To: [email protected]
Subject: Re: [Ironruby-core] PlatformAdaptationLayer - scope

How should the entire virtual file system look like? Is “myzip.zip” the
only root? Or do you need multiple roots (like drive letters on
Windows)?

Tomas

From: [email protected]
[mailto:[email protected]] On Behalf Of Nathan Stults
Sent: Wednesday, October 14, 2009 11:05 PM
To: [email protected]
Subject: Re: [Ironruby-core] PlatformAdaptationLayer - scope

I have run into a problem, which I think I can work around, but before I
contaminate your bug list, I thought I’d see if there is any point, or
if I’ve simply exceeded the expected use of the PAL. The problem I’m
having is that I want to treat a zip file as a virtual file system, as
if it were a mounted drive from the DLR’s perspective. My issue at the
moment is that, while the PAL defines an IsAbsolutePath method,
RubyFileOps via RubyUtils uses its own concept of IsAbsolutePath. My
desire, at least my initial desire, is to treat “myzip.zip” as a path
root, so that “myzip.zip/mydir/myfile.rb” can be considered an absolute
path by my version of PAL. This works for all standard dependencies, but
ruby gems likes to call File.expand_path on stuff, and this bypasses my
PAL’s IsAbsolutePath entirely, so “myzip.zip”, which had heretofore been
treated as if “myzip.zip” were a drive letter because of my
implementation of IsAbsolutePath, is now blown out into
“c:\myapp\bin\debug\myzip.zip\mydir\myfile.rb”. Anyway, that was a long
way of asking, am I trying to stretch the PAL too far, or is this in
fact a valid issue? I do get that Ruby may do certain things differently
than the DLR proper, and that the implementation of IronRuby libraries
needs to reflect that, but I wonder if variances from the standard DLR
PlatformAdaptationLayer might possibly be modeled by providing a
non-sealed, IronRuby specific PAL that implements the Rubyisms but also
allows those of us who wish to modify global behavior to inherit from
the ruby version and apply our tweaks.

From: [email protected]
[mailto:[email protected]] On Behalf Of Tomas M.
Sent: Tuesday, October 13, 2009 11:36 PM
To: [email protected]
Subject: Re: [Ironruby-core] PlatformAdaptationLayer - scope

Your initial intuition is right. The intention is to provide some
abstraction of the file system/OS. The goal is not to provide a complete
abstraction but one that is complete enough to support common
operations. If the abstraction is leaking somewhere it’s either a bug or
there is a good reason why the code doesn’t use PAL (for example, the
operation is platform/Ruby specific and has no simple abstraction). So
if you have a good use-case that doesn’t work right now feel free to
file a bug here: http://ironruby.codeplex.com/WorkItem/AdvancedList.aspx
and we’ll fix it.

Tomas

From: [email protected]
[mailto:[email protected]] On Behalf Of Nathan Stults
Sent: Tuesday, October 13, 2009 11:19 PM
To: [email protected]
Subject: [Ironruby-core] PlatformAdaptationLayer - scope

What is the correct way to view the PlatformAdaptationLayer? My initial
assumption was that it was IronRuby’s abstraction of the file system
(and environment variables), but in digging deeper I see that the Dir
builtin is calling into the file system in many places using the
System.IO classes directly. My next thought was that the PAL must then
be purely a hosting construct that exists to allow hosts to provide
alternative dependency resolution, but this doesn’t seem to quite fit
either, since the Glob implementation, which is also a part of Dir.cs,
does go through the PAL, so it isn’t just used for dependency
resolution. Is the long term plan to make all file system manipulation
go through the PAL, and if not, could someone shed some light on how the
PAL is intended to be used / understood? I’m attempting to do something
similar to the ZipArchive stuff in Chiron, that would allow zip files to
be put into the application path of non-silverlight apps, or used for
the Gem_Path, etc (for easy deployment of IronRuby, gems and other
static library code) but I’m concerned that if a gem or some other ruby
code tries to scan the file system for convention based dependencies
(does this even happen?) the PAL may get bypassed entirely under certain
circumstances. I’m not familiar enough with the ruby libraries to know
if this should even be a concern in practice, but the
zip-as-virtual-file-system metaphor looks like it will have some holes
at least in theory.

Thanks,

Nathan

You’re probably right about the promoting to root thing, it doesn’t add
much value and makes things more complex. Very strange even J . I’m
working on refactoring that now. I think I ended up with that design
because I was trying to build a sort of pluggable virtual file system
mechanism, where, based on the root, a different VFS provider could deal
with xxx.zip/xxx/xxx.rb, http://xxx/xxx.rb, ftp://xxx/xxx.rb or
whatever. As I have no immediate plans to implement any other providers
besides zip nor any use cases that would require loading files from the
web, and since it makes the design of the zip solution more difficult
and less flexible, I’ll reject my urge to over-engineer.

Of course, I still think it’s a bit confusing to have an IsAbsolutePath
method on the PAL interface but have it totally bypassed by a language
implementation, and would appear to block implementation of my
gold-plated original design, but maybe that is a good thing.

In your implementation, how are you treating the ambiguous case, if
DirectoryExists is called for the path “root/bin/mylibs.zip” - is that
true or false? And what about FileExists? Maybe they should both be
true.

From: [email protected]
[mailto:[email protected]] On Behalf Of Jimmy
Schementi
Sent: Thursday, October 15, 2009 11:10 AM
To: [email protected]
Subject: Re: [Ironruby-core] PlatformAdaptationLayer - scope

Sounds like you just need a PAL implementation which looks into zip
files. Why do you have to promote zip files to be roots? That seems very
strange. Why not just add the zip file path to the SearchPath, so your
script files can be required via normal path resolution? I’d like to
understand more about more motivation to do this, so we can accurately
determine whether this is a scenario the PAL should cover.

I’m doing the same thing with using zip files as a file-system in
Silverlight; the path to the ZIP file is a real location like
http://foo.com/mylibs.zip, and then that is added to the SearchPath so
script files can be required out of the zip. For file-system operations
like File.open, you can either use the full path name like
http://foo.com/mylibs.zip/foo.rb or the path will be relative to the
current HTML file, so “mylibs.zip/foo.rb” will do just fine.

~js

From: [email protected]
[mailto:[email protected]] On Behalf Of Nathan Stults
Sent: Thursday, October 15, 2009 6:58 AM
To: [email protected]
Subject: Re: [Ironruby-core] PlatformAdaptationLayer - scope

There may be multiple roots, of course existing roots are still roots
(c:…, f:…) but I am adding roots. In my current
implementation, any time my PAL is asked to resolve a path that starts
with xxxx.zip (or some other magic extension) then it creates a new
root, and future requests to resolve paths rooted in xxxx.zip will look
in the zip file in question, not the file system.

From: [email protected]
[mailto:[email protected]] On Behalf Of Tomas M.
Sent: Thursday, October 15, 2009 12:07 AM
To: [email protected]
Subject: Re: [Ironruby-core] PlatformAdaptationLayer - scope

How should the entire virtual file system look like? Is “myzip.zip” the
only root? Or do you need multiple roots (like drive letters on
Windows)?

Tomas

From: [email protected]
[mailto:[email protected]] On Behalf Of Nathan Stults
Sent: Wednesday, October 14, 2009 11:05 PM
To: [email protected]
Subject: Re: [Ironruby-core] PlatformAdaptationLayer - scope

I have run into a problem, which I think I can work around, but before I
contaminate your bug list, I thought I’d see if there is any point, or
if I’ve simply exceeded the expected use of the PAL. The problem I’m
having is that I want to treat a zip file as a virtual file system, as
if it were a mounted drive from the DLR’s perspective. My issue at the
moment is that, while the PAL defines an IsAbsolutePath method,
RubyFileOps via RubyUtils uses its own concept of IsAbsolutePath. My
desire, at least my initial desire, is to treat “myzip.zip” as a path
root, so that “myzip.zip/mydir/myfile.rb” can be considered an absolute
path by my version of PAL. This works for all standard dependencies, but
ruby gems likes to call File.expand_path on stuff, and this bypasses my
PAL’s IsAbsolutePath entirely, so “myzip.zip”, which had heretofore been
treated as if “myzip.zip” were a drive letter because of my
implementation of IsAbsolutePath, is now blown out into
“c:\myapp\bin\debug\myzip.zip\mydir\myfile.rb”. Anyway, that was a long
way of asking, am I trying to stretch the PAL too far, or is this in
fact a valid issue? I do get that Ruby may do certain things differently
than the DLR proper, and that the implementation of IronRuby libraries
needs to reflect that, but I wonder if variances from the standard DLR
PlatformAdaptationLayer might possibly be modeled by providing a
non-sealed, IronRuby specific PAL that implements the Rubyisms but also
allows those of us who wish to modify global behavior to inherit from
the ruby version and apply our tweaks.

From: [email protected]
[mailto:[email protected]ain.invalid] On Behalf Of Tomas M.
Sent: Tuesday, October 13, 2009 11:36 PM
To: [email protected]
Subject: Re: [Ironruby-core] PlatformAdaptationLayer - scope

Your initial intuition is right. The intention is to provide some
abstraction of the file system/OS. The goal is not to provide a complete
abstraction but one that is complete enough to support common
operations. If the abstraction is leaking somewhere it’s either a bug or
there is a good reason why the code doesn’t use PAL (for example, the
operation is platform/Ruby specific and has no simple abstraction). So
if you have a good use-case that doesn’t work right now feel free to
file a bug here: http://ironruby.codeplex.com/WorkItem/AdvancedList.aspx
and we’ll fix it.

Tomas

From: [email protected]
[mailto:[email protected]] On Behalf Of Nathan Stults
Sent: Tuesday, October 13, 2009 11:19 PM
To: [email protected]
Subject: [Ironruby-core] PlatformAdaptationLayer - scope

What is the correct way to view the PlatformAdaptationLayer? My initial
assumption was that it was IronRuby’s abstraction of the file system
(and environment variables), but in digging deeper I see that the Dir
builtin is calling into the file system in many places using the
System.IO classes directly. My next thought was that the PAL must then
be purely a hosting construct that exists to allow hosts to provide
alternative dependency resolution, but this doesn’t seem to quite fit
either, since the Glob implementation, which is also a part of Dir.cs,
does go through the PAL, so it isn’t just used for dependency
resolution. Is the long term plan to make all file system manipulation
go through the PAL, and if not, could someone shed some light on how the
PAL is intended to be used / understood? I’m attempting to do something
similar to the ZipArchive stuff in Chiron, that would allow zip files to
be put into the application path of non-silverlight apps, or used for
the Gem_Path, etc (for easy deployment of IronRuby, gems and other
static library code) but I’m concerned that if a gem or some other ruby
code tries to scan the file system for convention based dependencies
(does this even happen?) the PAL may get bypassed entirely under certain
circumstances. I’m not familiar enough with the ruby libraries to know
if this should even be a concern in practice, but the
zip-as-virtual-file-system metaphor looks like it will have some holes
at least in theory.

Thanks,

Nathan

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs