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: ironruby-core-boun...@rubyforge.org [mailto:ironruby-core-boun...@rubyforge.org] On Behalf Of Tomas Matousek Sent: Tuesday, October 13, 2009 11:36 PM To: ironruby-core@rubyforge.org 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: ironruby-core-boun...@rubyforge.org [mailto:ironruby-core-boun...@rubyforge.org] On Behalf Of Nathan Stults Sent: Tuesday, October 13, 2009 11:19 PM To: ironruby-core@rubyforge.org 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
_______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
