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: ironruby-core-boun...@rubyforge.org [mailto:ironruby-core-boun...@rubyforge.org] On Behalf Of Jimmy Schementi Sent: Thursday, October 15, 2009 11:10 AM To: ironruby-core@rubyforge.org 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: ironruby-core-boun...@rubyforge.org [mailto:ironruby-core-boun...@rubyforge.org] On Behalf Of Nathan Stults Sent: Thursday, October 15, 2009 6:58 AM To: ironruby-core@rubyforge.org 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: ironruby-core-boun...@rubyforge.org [mailto:ironruby-core-boun...@rubyforge.org] On Behalf Of Tomas Matousek Sent: Thursday, October 15, 2009 12:07 AM To: ironruby-core@rubyforge.org 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: ironruby-core-boun...@rubyforge.org [mailto:ironruby-core-boun...@rubyforge.org] On Behalf Of Nathan Stults Sent: Wednesday, October 14, 2009 11:05 PM To: ironruby-core@rubyforge.org 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: 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
