[Swift-devel] remote file/directory stuff (bug 22)

Ben Clifford benc at hawaga.org.uk
Mon Feb 26 15:14:55 CST 2007



On Mon, 26 Feb 2007, Mihael Hategan wrote:

> We may also want to do the same to the input, because some even more
> twisted apps will not even accept that as a parameter.

 So:
> (file k, file m, file n) myapp(file l) {
>   app{
>     l>"input.txt";
>     myapp;
>     k<"output.crd"
>     m<"output.prd"
>     n<"output.rtf"
>   }
> }

somewhat related to that is the way that the air align_warp program wants 
its input files:

  $ ls Raw/ 
  anatomy1.hdr anatomy2.hdr anatomy3.hdr anatomy4.hdr reference.hdr
  anatomy1.img anatomy2.img anatomy3.img anatomy4.img reference.img

All paired up - but the app is told just:

  $ align_warp /path/to/anatomy1.img /otherpath/reference.img

with it being implicit that the corresponding hdr files exists at:

 "/path/to/anatomy1.img" - "img" + "hdr"
 "/otherpath/reference.img" - "img" + "hdr"

In practice, I think this is OK in the short-medium term because as long 
as the corresponding hdr and img files sit next to each other in the 
submit side, they'll map through to execute side files that also sit next 
to each other, because of the way that we map.

But in the longer term future, that is not necessarily going to be the 
case - as source-side mapping becomes richer, to pull data from different 
places that maybe don't have a single source filename (eg replicas, other 
kinds of data store), the above invariant may become untrue. So there's at 
least consideration needed there - either in terms of the invariants that 
we assume are true but are never written down in a spec, or in terms of 
how we make that stuff map properly on the execute side.

-- 



More information about the Swift-devel mailing list