Re: changing directories

On Wednesday February 3 2010, Naftoli Gugenheim wrote:
> Why do you want to?

Change is good?

RRS

Says who?

-------------------------------------
Randall R Schulz wrote:

On Wednesday February 3 2010, Naftoli Gugenheim wrote:
> Why do you want to?

Change is good?

RRS

On Wed, Feb 3, 2010 at 4:29 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Why do you want to?

It's not something I need badly, but it would be nice. I'm doing some testing using "sbt test-run." One of my tests writes to an output file. I want the file to appear in the same directory with the test source code -- not in the project home directory. Yes, I can just use "src/test/scala/MyOutputFile", but it seems that I should be able to change directories and just give the file name without the path.

Russ P.

 

-------------------------------------
Russ Paielli<russ.paielli@gmail.com> wrote:

Sorry if this should be easy to find. I couldn't find it. In Python, you
change directories with "chdir." How do you change directories in Scala?
Thanks.

Russ P.

--
http://RussP.us

--
http://RussP.us

See if the system property approach works, but I don't really see the benefit over new File(parentDir, filename)... :)

-------------------------------------
Russ Paielli wrote:

On Wed, Feb 3, 2010 at 4:29 PM, Naftoli Gugenheim wrote:

> Why do you want to?
>

It's not something I need badly, but it would be nice. I'm doing some
testing using "sbt test-run." One of my tests writes to an output file. I
want the file to appear in the same directory with the test source code --
not in the project home directory. Yes, I can just use
"src/test/scala/MyOutputFile", but it seems that I should be able to change
directories and just give the file name without the path.

Russ P.

>
> -------------------------------------
> Russ Paielli wrote:
>
> Sorry if this should be easy to find. I couldn't find it. In Python, you
> change directories with "chdir." How do you change directories in Scala?
> Thanks.
>
> Russ P.
>
> --
> http://RussP.us
>

Also there was a discussion once about a better file api for scala. Don't remember any specifics, sorry, but there may be something with a nicer syntax.

-------------------------------------
Russ Paielli wrote:

On Wed, Feb 3, 2010 at 4:29 PM, Naftoli Gugenheim wrote:

> Why do you want to?
>

It's not something I need badly, but it would be nice. I'm doing some
testing using "sbt test-run." One of my tests writes to an output file. I
want the file to appear in the same directory with the test source code --
not in the project home directory. Yes, I can just use
"src/test/scala/MyOutputFile", but it seems that I should be able to change
directories and just give the file name without the path.

Russ P.

>
> -------------------------------------
> Russ Paielli wrote:
>
> Sorry if this should be easy to find. I couldn't find it. In Python, you
> change directories with "chdir." How do you change directories in Scala?
> Thanks.
>
> Russ P.
>
> --
> http://RussP.us
>

Changing directories is so basic that it should be very convenient to do, particularly if Scala is intended to be usable as a scripting language. That's what I think, anyway.

Russ P.


On Wed, Feb 3, 2010 at 5:30 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

See if the system property approach works, but I don't really see the benefit over new File(parentDir, filename)... :)

-------------------------------------
Russ Paielli<russ.paielli@gmail.com> wrote:

On Wed, Feb 3, 2010 at 4:29 PM, Naftoli Gugenheim <naftoligug@gmail.com>wrote:

> Why do you want to?
>

It's not something I need badly, but it would be nice. I'm doing some
testing using "sbt test-run." One of my tests writes to an output file. I
want the file to appear in the same directory with the test source code --
not in the project home directory. Yes, I can just use
"src/test/scala/MyOutputFile", but it seems that I should be able to change
directories and just give the file name without the path.

Russ P.



>
> -------------------------------------
> Russ Paielli<russ.paielli@gmail.com> wrote:
>
> Sorry if this should be easy to find. I couldn't find it. In Python, you
> change directories with "chdir." How do you change directories in Scala?
> Thanks.
>
> Russ P.
>
> --
> http://RussP.us
>



--
http://RussP.us

--
http://RussP.us

It's basic for what sort of tool? For what set of tasks?When one says Scala is intended to be a scripting language, the intent is not scripting as in shell scripting. The intent is a language the has a very lightweight syntax and can be used without going through the step of compiling. Like Javascript. Look at the big picture: Scala is not an environment. It's a language. It's doesn't provide basics because it sits on top of an existing platform, namely Java or .NET. Plus, it includes a standard library that builds on the platform standard library and includes super-useful power tools for a wide range of tasks, most of very general use. So your critique should be targeted at Java, except that Java was not intended to be used as a scripting language.In any case if you search a little I believe you will find third party scala libraries providing a lightweight syntax for IO processing.


On Wed, Feb 3, 2010 at 11:09 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

Changing directories is so basic that it should be very convenient to do, particularly if Scala is intended to be usable as a scripting language. That's what I think, anyway.

Russ P.


On Wed, Feb 3, 2010 at 5:30 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

See if the system property approach works, but I don't really see the benefit over new File(parentDir, filename)... :)

-------------------------------------
Russ Paielli<russ.paielli@gmail.com> wrote:

On Wed, Feb 3, 2010 at 4:29 PM, Naftoli Gugenheim <naftoligug@gmail.com>wrote:

> Why do you want to?
>

It's not something I need badly, but it would be nice. I'm doing some
testing using "sbt test-run." One of my tests writes to an output file. I
want the file to appear in the same directory with the test source code --
not in the project home directory. Yes, I can just use
"src/test/scala/MyOutputFile", but it seems that I should be able to change
directories and just give the file name without the path.

Russ P.



>
> -------------------------------------
> Russ Paielli<russ.paielli@gmail.com> wrote:
>
> Sorry if this should be easy to find. I couldn't find it. In Python, you
> change directories with "chdir." How do you change directories in Scala?
> Thanks.
>
> Russ P.
>
> --
> http://RussP.us
>



--
http://RussP.us

--
http://RussP.us

Lachlan Deck wrote:
> On 04/02/2010, at 3:09 PM, Russ Paielli wrote:
>
>
>> Changing directories is so basic that it should be very convenient to do,
>> particularly if Scala is intended to be usable as a scripting language.
>> That's what I think, anyway.
>>
>
> Well, even in scripting it's bad practice to chdir unless you can guarantee that you'll return to the original dir upon exit/error. It's much better practice to utilise variables rather than changing the pwd. Hence, the system property should be treated as a read-only property seeing as it's useful info about where the script came into life.
>
> with regards,
> --
>
> Lachlan Deck
>
>
>
There is this.

def inDir[A](dir: String, a: => A): A = {
val z = System.getProperty("user.dir")
System.setProperty("user.dir", dir)
val i = a
System.setProperty("user.dir", z)
i
}

On Wednesday February 3 2010, Tony Morris wrote:
> ...
>
> There is this.
>
> def inDir[A](dir: String, a: => A): A = {
> val z = System.getProperty("user.dir")
> System.setProperty("user.dir", dir)
> val i = a
> System.setProperty("user.dir", z)
> i
> }

Suitably adorned with try/finally in case the expression passed by name
throws an exception.

Randall Schulz

On 04/02/2010, at 3:09 PM, Russ Paielli wrote:

> Changing directories is so basic that it should be very convenient to do,
> particularly if Scala is intended to be usable as a scripting language.
> That's what I think, anyway.

Well, even in scripting it's bad practice to chdir unless you can guarantee that you'll return to the original dir upon exit/error. It's much better practice to utilise variables rather than changing the pwd. Hence, the system property should be treated as a read-only property seeing as it's useful info about where the script came into life.

with regards,
--

Lachlan Deck

Nice, but needs to be in a try-finally, and even then it smells of the
nastiest possible side-effects.

Having a per-process current directory is an OS misfeature, and doesn't
become less so just because it's a time-honored misfeature.

Tony Morris-4 wrote:
>
> Lachlan Deck wrote:
>> On 04/02/2010, at 3:09 PM, Russ Paielli wrote:
>>
>>
>>> Changing directories is so basic that it should be very convenient to
>>> do,
>>> particularly if Scala is intended to be usable as a scripting language.
>>> That's what I think, anyway.
>>>
>>
>> Well, even in scripting it's bad practice to chdir unless you can
>> guarantee that you'll return to the original dir upon exit/error. It's
>> much better practice to utilise variables rather than changing the pwd.
>> Hence, the system property should be treated as a read-only property
>> seeing as it's useful info about where the script came into life.
>>
>> with regards,
>> --
>>
>> Lachlan Deck
>>
>>
>>
> There is this.
>
> def inDir[A](dir: String, a: => A): A = {
> val z = System.getProperty("user.dir")
> System.setProperty("user.dir", dir)
> val i = a
> System.setProperty("user.dir", z)
> i
> }
>

I usually write "scripts" (whatever that really means) using Haskell. I
translated from Haskell where if 'a' were an action, then the client
(not the function itself) handles any evaluation of running that action.
Ah, the benefits of first-class side-effects.

def inDir[A](dir: String, a: => A): A = {
val z = System.getProperty("user.dir")
System.setProperty("user.dir", dir)
try {
a
} finally {
System.setProperty("user.dir", z)
}
}
Dave Griffith wrote:
> Nice, but needs to be in a try-finally, and even then it smells of the
> nastiest possible side-effects.
>
> Having a per-process current directory is an OS misfeature, and doesn't
> become less so just because it's a time-honored misfeature.
>
>
> Tony Morris-4 wrote:
>
>> Lachlan Deck wrote:
>>
>>> On 04/02/2010, at 3:09 PM, Russ Paielli wrote:
>>>
>>>
>>>
>>>> Changing directories is so basic that it should be very convenient to
>>>> do,
>>>> particularly if Scala is intended to be usable as a scripting language.
>>>> That's what I think, anyway.
>>>>
>>>>
>>> Well, even in scripting it's bad practice to chdir unless you can
>>> guarantee that you'll return to the original dir upon exit/error. It's
>>> much better practice to utilise variables rather than changing the pwd.
>>> Hence, the system property should be treated as a read-only property
>>> seeing as it's useful info about where the script came into life.
>>>
>>> with regards,
>>> --
>>>
>>> Lachlan Deck
>>>
>>>
>>>
>>>
>> There is this.
>>
>> def inDir[A](dir: String, a: => A): A = {
>> val z = System.getProperty("user.dir")
>> System.setProperty("user.dir", dir)
>> val i = a
>> System.setProperty("user.dir", z)
>> i
>> }
>>

Neat!

On Wed, Feb 3, 2010 at 11:22 PM, Tony Morris <tonymorris@gmail.com> wrote:

Lachlan Deck wrote:
> On 04/02/2010, at 3:09 PM, Russ Paielli wrote:
>
>
>> Changing directories is so basic that it should be very convenient to do,
>> particularly if Scala is intended to be usable as a scripting language.
>> That's what I think, anyway.
>>
>
> Well, even in scripting it's bad practice to chdir unless you can guarantee that you'll return to the original dir upon exit/error. It's much better practice to utilise variables rather than changing the pwd. Hence, the system property should be treated as a read-only property seeing as it's useful info about where the script came into life.
>
> with regards,
> --
>
> Lachlan Deck
>
>
>
There is this.

def inDir[A](dir: String, a: => A): A = {
   val z = System.getProperty("user.dir")
   System.setProperty("user.dir", dir)
   val i = a
   System.setProperty("user.dir", z)
   i
}

--
Tony Morris
http://tmorris.net/

What problem is there with a per-process directory that a withDir type approach doesn't solve? It's not even per thread - it's ARM style, no?

On Wed, Feb 3, 2010 at 11:39 PM, Dave Griffith <dave.l.griffith@gmail.com> wrote:

Nice, but needs to be in a try-finally, and even then it smells of the
nastiest possible side-effects.

Having a per-process current directory is an OS misfeature, and doesn't
become less so just because it's a time-honored misfeature.


Tony Morris-4 wrote:
>
> Lachlan Deck wrote:
>> On 04/02/2010, at 3:09 PM, Russ Paielli wrote:
>>
>>
>>> Changing directories is so basic that it should be very convenient to
>>> do,
>>> particularly if Scala is intended to be usable as a scripting language.
>>> That's what I think, anyway.
>>>
>>
>> Well, even in scripting it's bad practice to chdir unless you can
>> guarantee that you'll return to the original dir upon exit/error. It's
>> much better practice to utilise variables rather than changing the pwd.
>> Hence, the system property should be treated as a read-only property
>> seeing as it's useful info about where the script came into life.
>>
>> with regards,
>> --
>>
>> Lachlan Deck
>>
>>
>>
> There is this.
>
> def inDir[A](dir: String, a: => A): A = {
>     val z = System.getProperty("user.dir")
>     System.setProperty("user.dir", dir)
>     val i = a
>     System.setProperty("user.dir", z)
>     i
> }
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>
>

--
View this message in context: http://old.nabble.com/Re%3A-changing-directories-tp27445915p27447671.html
Sent from the Scala - User mailing list archive at Nabble.com.

On Wed, Feb 3, 2010 at 8:39 PM, Dave Griffith <dave.l.griffith@gmail.com> wrote:

Having a per-process current directory is an OS misfeature, and doesn't
become less so just because it's a time-honored misfeature.

Well, I must be missing something here. If you don't have a current directory, then don't all your file names need absolute paths? And don't absolute paths kill portability?

Russ P.

If having a current directory solves portability, what's the portable way of setting it?java.io.File does support relative paths. But not being able to change the working directory does not mean you have to user absolute paths.

On Wed, Feb 3, 2010 at 11:54 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

On Wed, Feb 3, 2010 at 8:39 PM, Dave Griffith <dave.l.griffith@gmail.com> wrote:

Having a per-process current directory is an OS misfeature, and doesn't
become less so just because it's a time-honored misfeature.

Well, I must be missing something here. If you don't have a current directory, then don't all your file names need absolute paths? And don't absolute paths kill portability?

Russ P.

Both the current user home directory and the absolute path of the executable
can reasonably used as milestones for relative access. They are much safer
than the current
working directory, being immutable and not subject to accidental or
malicious munging.

Russ Paielli-5 wrote:
>
> Well, I must be missing something here. If you don't have a current
> directory, then don't all your file names need absolute paths? And don't
> absolute paths kill portability?
>

It's a matter of convenience. Suppose I am writing a program that deals with a dozens of files in each of 100 different data directories. Yes, I can use the extended pathname (relative or absolute) for every access, but that is cumbersome. Changing the current directory is cleaner and more convenient -- and possibly even less prone to error. You can always keep a record of the original working directory as a reference to go back to if something goes wrong or if you just want to simplify keeping track of where you are.

I have actually done this sort of thing in Python.

Russ P.


On Wed, Feb 3, 2010 at 9:29 PM, Dave Griffith <dave.l.griffith@gmail.com> wrote:

Both the current user home directory and the absolute path of the executable
can reasonably used as milestones for relative access.  They are much safer
than the current
working directory, being immutable and not subject to accidental or
malicious munging.


Russ Paielli-5 wrote:
>
> Well, I must be missing something here. If you don't have a current
> directory, then don't all your file names need absolute paths? And don't
> absolute paths kill portability?
>

Can you define "cleaner and more convenient"? :)

On Thu, Feb 4, 2010 at 12:56 AM, Russ Paielli <russ.paielli@gmail.com> wrote:

It's a matter of convenience. Suppose I am writing a program that deals with a dozens of files in each of 100 different data directories. Yes, I can use the extended pathname (relative or absolute) for every access, but that is cumbersome. Changing the current directory is cleaner and more convenient -- and possibly even less prone to error. You can always keep a record of the original working directory as a reference to go back to if something goes wrong or if you just want to simplify keeping track of where you are.

I have actually done this sort of thing in Python.

Russ P.


On Wed, Feb 3, 2010 at 9:29 PM, Dave Griffith <dave.l.griffith@gmail.com> wrote:

Both the current user home directory and the absolute path of the executable
can reasonably used as milestones for relative access.  They are much safer
than the current
working directory, being immutable and not subject to accidental or
malicious munging.


Russ Paielli-5 wrote:
>
> Well, I must be missing something here. If you don't have a current
> directory, then don't all your file names need absolute paths? And don't
> absolute paths kill portability?
>

On 04/02/2010, at 4:56 PM, Russ Paielli wrote:

> It's a matter of convenience. Suppose I am writing a program that deals with
> a dozens of files in each of 100 different data directories. Yes, I can use
> the extended pathname (relative or absolute) for every access, but that is
> cumbersome. Changing the current directory is cleaner and more convenient --
> and possibly even less prone to error.

Not so. You simply need the path to the dir new File(someDir, ...) and not the absolute path for every one of those 100 files.

You just need to rethink your approach. You already needed to know what 'someDir' was to chdir anyway.

> You can always keep a record of the
> original working directory as a reference to go back to if something goes
> wrong or if you just want to simplify keeping track of where you are.

So if the user aborts the script part-way through they'll be in which dir?

You can alternatively keep a var for which dir you want to reference.

> I have actually done this sort of thing in Python.

Sure, or perl or whatever. Doesn't make it a best-practice.

with regards,
--

Lachlan Deck

Actually, it's messier and significantly more prone to error.

scala> List("a", "b", "c") map ("/tmp/" + _)
res0: List[java.lang.String] = List(/tmp/a, /tmp/b, /tmp/c)

Welcome.

Russ Paielli wrote:
> It's a matter of convenience. Suppose I am writing a program that deals with
> a dozens of files in each of 100 different data directories. Yes, I can use
> the extended pathname (relative or absolute) for every access, but that is
> cumbersome. Changing the current directory is cleaner and more convenient --
> and possibly even less prone to error. You can always keep a record of the
> original working directory as a reference to go back to if something goes
> wrong or if you just want to simplify keeping track of where you are.
>
> I have actually done this sort of thing in Python.
>
> Russ P.
>
>
> On Wed, Feb 3, 2010 at 9:29 PM, Dave Griffith wrote:
>
>
>> Both the current user home directory and the absolute path of the
>> executable
>> can reasonably used as milestones for relative access. They are much safer
>> than the current
>> working directory, being immutable and not subject to accidental or
>> malicious munging.
>>
>>
>> Russ Paielli-5 wrote:
>>
>>> Well, I must be missing something here. If you don't have a current
>>> directory, then don't all your file names need absolute paths? And don't
>>> absolute paths kill portability?
>>>
>>>
>>
>
>

Surely, if you are working with a 100 directories you probably have some sort of uniform naming convention and so you wouldn't be hard-coding their names all over you code. If you are, then it sounds ugly to me.

Instead, what I'd be doing is refactoring so that the code relies on a variable that I can use. So then, it is not that big a deal to use an absolute path over a relative path. Even so, you shouldn't have to set the current working directory simply to use relative paths.

As others have mentioned you can set the user.dir property and rely on that, but in my opinion something like this:

System.setProperty("user.dir", "/foo/bar")
new File("myFile1")
new File("myFile2")

is more clunky than:

topLevelDir="/foo/bar"
new File(topLevelDir, "myFile")
new File(topLevelDir, "myFile2")

The point being that in either case you have to do an extra step - either reset the working dir, or set a variable.

Finally, if you really find it tedious to have to specify topLevelDir multiple times like that then you should be easily able to construct a DSL that uses implicits to hide it away.

Regards,
Ishaaq

On 4 February 2010 16:56, Russ Paielli <russ.paielli@gmail.com> wrote:

It's a matter of convenience. Suppose I am writing a program that deals with a dozens of files in each of 100 different data directories. Yes, I can use the extended pathname (relative or absolute) for every access, but that is cumbersome. Changing the current directory is cleaner and more convenient -- and possibly even less prone to error. You can always keep a record of the original working directory as a reference to go back to if something goes wrong or if you just want to simplify keeping track of where you are.

I have actually done this sort of thing in Python.

Russ P.


On Wed, Feb 3, 2010 at 9:29 PM, Dave Griffith <dave.l.griffith@gmail.com> wrote:

Both the current user home directory and the absolute path of the executable
can reasonably used as milestones for relative access.  They are much safer
than the current
working directory, being immutable and not subject to accidental or
malicious munging.


Russ Paielli-5 wrote:
>
> Well, I must be missing something here. If you don't have a current
> directory, then don't all your file names need absolute paths? And don't
> absolute paths kill portability?
>

On Wed, Feb 3, 2010 at 10:10 PM, Tony Morris <tonymorris@gmail.com> wrote:

Actually, it's messier and significantly more prone to error.

scala> List("a", "b", "c") map ("/tmp/" + _)
res0: List[java.lang.String] = List(/tmp/a, /tmp/b, /tmp/c)

Welcome.

Now I have to remember the index number of each of dozens of files. That will lead to an unreadable mess. Each of those files (a, b, c in your example) is a different sort of file that needs to be dealt with in a particular way. They each have names that mean something, and I sure don't want to refer to them as myList(i) or any such thing.

Just to give you an idea of what I am talking about, I have archived tracking data for about 100 actual "operational errors" (losses of minimum required separation due to an error by an air traffic controller). Here is a partial sample of the files I have for EACH CASE (these are just the .dat files, but there are many others).

-rw-r--r--+  1 paielli ctas  7979 Jan 20  2009 alt-04-FP-DR.dat
-rw-r--r--+  1 paielli ctas  7811 Jan 20  2009 alt-05-DR-DR.dat
-rw-r--r--+  1 paielli ctas  7979 Jan 20  2009 alt-06-DR-FP.dat
-rw-r--r--+  1 paielli ctas  7811 Jan 20  2009 alt-07-DR-DR.dat
-rw-r--r--+  1 paielli ctas  8016 Jan 20  2009 alt-08-FP-DR.dat
-rw-r--r--+  1 paielli ctas  7848 Jan 20  2009 alt-09-DR-DR.dat
-rw-r--r--+  1 paielli ctas  8016 Jan 20  2009 alt-10-DR-FP.dat
-rw-r--r--+  1 paielli ctas  7848 Jan 20  2009 alt-11-DR-DR.dat
-rw-r--r--+  1 paielli ctas  7158 Jan 19 15:08 alt-aug.dat
-rw-r--r--+  1 paielli ctas  7127 Jan 19 15:08 alt.dat
-rw-r--r--+  1 paielli ctas   351 Jan 19 15:08 clralt.dat
-rw-r--r--+  1 paielli ctas  6308 Jan 19 15:08 fltplans-1.dat
-rw-r--r--+  1 paielli ctas  6490 Jan 19 15:08 fltplans-2.dat
-rw-r--r--+  1 paielli ctas  1315 Jan 19 15:08 fltplans.dat
-rw-r--r--+  1 paielli ctas  4336 Jan 19 15:08 gspeed.dat
-rw-r--r--+  1 paielli ctas 12089 Jan 20 18:01 man-alt.dat
-rw-r--r--+  1 paielli ctas 14032 Jan 20 18:01 man-tracks.dat
-rw-r--r--+  1 paielli ctas  1311 Jan 25 16:19 minsep-pred.dat
-rw-r--r--+  1 paielli ctas 23010 Jan 25 16:19 pred-alt-DR-1.dat
-rw-r--r--+  1 paielli ctas 23018 Jan 25 16:19 pred-alt-DR-2.dat
-rw-r--r--+  1 paielli ctas 51775 Jan 25 16:19 pred-alt-FP-1.dat
-rw-r--r--+  1 paielli ctas 25953 Jan 25 16:19 pred-alt-FP-2.dat
-rw-r--r--+  1 paielli ctas 24962 Jan 25 16:19 pred-tracks-DR-1.dat
-rw-r--r--+  1 paielli ctas 27886 Jan 25 16:19 pred-tracks-DR-2.dat
-rw-r--r--+  1 paielli ctas 24962 Jan 25 16:19 pred-tracks-FP-1.dat
-rw-r--r--+  1 paielli ctas 26346 Jan 25 16:19 pred-tracks-FP-2.dat
-rw-r--r--+  1 paielli ctas   509 Jan 20  2009 probe2.dat
-rw-r--r--+  1 paielli ctas   923 Jan 25 16:19 probe.dat
-rw-r--r--+  1 paielli ctas  1308 Jan 25 16:19 relspeed2.dat
-rw-r--r--+  1 paielli ctas  1952 Jan 19 15:08 relspeed.dat
-rw-r--r--+  1 paielli ctas  3120 Jan 19 15:08 sectors.dat
-rw-r--r--+  1 paielli ctas  2901 Jan 19 15:08 separation0.dat
-rw-r--r--+ 70 paielli ctas  2901 Jan 25 16:19 separation.dat
-rw-r--r--+  1 paielli ctas  5882 Jan 19 15:08 sepHist.dat
-rw-r--r--+  1 paielli ctas  1691 Jan 19 15:08 time-1.dat
-rw-r--r--+  1 paielli ctas  1691 Jan 19 15:08 time-2.dat
-rw-r--r--+  1 paielli ctas  6967 Jan 19 15:08 timedif.dat
-rw-r--r--+  1 paielli ctas  2572 Jan 19 15:08 timetoLOShist.dat
-rw-r--r--+  1 paielli ctas   960 Jan 20  2009 timetoLOShistory.dat
-rw-r--r--+  1 paielli ctas  8027 Jan 20  2009 tracks-04-FP-DR.dat
-rw-r--r--+  1 paielli ctas  7946 Jan 20  2009 tracks-05-DR-DR.dat
-rw-r--r--+  1 paielli ctas  8027 Jan 20  2009 tracks-06-DR-FP.dat
-rw-r--r--+  1 paielli ctas  7946 Jan 20  2009 tracks-07-DR-DR.dat
-rw-r--r--+  1 paielli ctas  8030 Jan 20  2009 tracks-08-FP-DR.dat
-rw-r--r--+  1 paielli ctas  7947 Jan 20  2009 tracks-09-DR-DR.dat
-rw-r--r--+  1 paielli ctas  8030 Jan 20  2009 tracks-10-DR-FP.dat
-rw-r--r--+  1 paielli ctas  7947 Jan 20  2009 tracks-11-DR-DR.dat
-rw-r--r--+  1 paielli ctas  9259 Jan 19 15:08 tracks.dat

Now let me clarify something here. I am using Scala for a program that is ultimately intended to aid air traffic controllers. I am not using it for the analysis of the testing data. I will continue using Python for the data analysis. That means that I don't really need to do deal with all these directories and data files with Scala. But what if I wanted to use Scala for the data analysis? That would certainly be a reasonable thing to do if I had not already done it in Python.

Russ P.

 

Russ Paielli wrote:
> It's a matter of convenience. Suppose I am writing a program that deals with
> a dozens of files in each of 100 different data directories. Yes, I can use
> the extended pathname (relative or absolute) for every access, but that is
> cumbersome. Changing the current directory is cleaner and more convenient --
> and possibly even less prone to error. You can always keep a record of the
> original working directory as a reference to go back to if something goes
> wrong or if you just want to simplify keeping track of where you are.
>
> I have actually done this sort of thing in Python.
>
> Russ P.
>
>
> On Wed, Feb 3, 2010 at 9:29 PM, Dave Griffith <dave.l.griffith@gmail.com>wrote:

On Wed, Feb 3, 2010 at 10:17 PM, Ishaaq Chandy <ishaaq@gmail.com> wrote:

As others have mentioned you can set the user.dir property and rely on that, but in my opinion something like this:

System.setProperty("user.dir", "/foo/bar")
new File("myFile1")
new File("myFile2")

is more clunky than:

topLevelDir="/foo/bar"
new File(topLevelDir, "myFile")
new File(topLevelDir, "myFile2")

The point being that in either case you have to do an extra step - either reset the working dir, or set a variable.

But if you have 50 such files, then certainly you would agree that is cleaner and more convenient to simply change the directory once than to repeat the directory over and over.

 

Finally, if you really find it tedious to have to specify topLevelDir multiple times like that then you should be easily able to construct a DSL that uses implicits to hide it away.

Why do I need a DSL when "chdir" will do the job (if it were available)?
 
--
http://RussP.us

Lists are polymorphic. You can store pairs.

I assure you there is a neat way to solve your problem (whatever that
may actually be) and it doesn't require piss-farting about in an
incredibly error-prone manner with changing directories and whatever else.

Russ Paielli wrote:
> On Wed, Feb 3, 2010 at 10:10 PM, Tony Morris wrote:
>
>
>> Actually, it's messier and significantly more prone to error.
>>
>> scala> List("a", "b", "c") map ("/tmp/" + _)
>> res0: List[java.lang.String] = List(/tmp/a, /tmp/b, /tmp/c)
>>
>> Welcome.
>>
>>
>
>
> Now I have to remember the index number of each of dozens of files. That
> will lead to an unreadable mess. Each of those files (a, b, c in your
> example) is a different sort of file that needs to be dealt with in a
> particular way. They each have names that mean something, and I sure don't
> want to refer to them as myList(i) or any such thing.
>
> Just to give you an idea of what I am talking about, I have archived
> tracking data for about 100 actual "operational errors" (losses of minimum
> required separation due to an error by an air traffic controller). Here is a
> partial sample of the files I have for EACH CASE (these are just the .dat
> files, but there are many others).
>
> -rw-r--r--+ 1 paielli ctas 7979 Jan 20 2009 alt-04-FP-DR.dat
> -rw-r--r--+ 1 paielli ctas 7811 Jan 20 2009 alt-05-DR-DR.dat
> -rw-r--r--+ 1 paielli ctas 7979 Jan 20 2009 alt-06-DR-FP.dat
> -rw-r--r--+ 1 paielli ctas 7811 Jan 20 2009 alt-07-DR-DR.dat
> -rw-r--r--+ 1 paielli ctas 8016 Jan 20 2009 alt-08-FP-DR.dat
> -rw-r--r--+ 1 paielli ctas 7848 Jan 20 2009 alt-09-DR-DR.dat
> -rw-r--r--+ 1 paielli ctas 8016 Jan 20 2009 alt-10-DR-FP.dat
> -rw-r--r--+ 1 paielli ctas 7848 Jan 20 2009 alt-11-DR-DR.dat
> -rw-r--r--+ 1 paielli ctas 7158 Jan 19 15:08 alt-aug.dat
> -rw-r--r--+ 1 paielli ctas 7127 Jan 19 15:08 alt.dat
> -rw-r--r--+ 1 paielli ctas 351 Jan 19 15:08 clralt.dat
> -rw-r--r--+ 1 paielli ctas 6308 Jan 19 15:08 fltplans-1.dat
> -rw-r--r--+ 1 paielli ctas 6490 Jan 19 15:08 fltplans-2.dat
> -rw-r--r--+ 1 paielli ctas 1315 Jan 19 15:08 fltplans.dat
> -rw-r--r--+ 1 paielli ctas 4336 Jan 19 15:08 gspeed.dat
> -rw-r--r--+ 1 paielli ctas 12089 Jan 20 18:01 man-alt.dat
> -rw-r--r--+ 1 paielli ctas 14032 Jan 20 18:01 man-tracks.dat
> -rw-r--r--+ 1 paielli ctas 1311 Jan 25 16:19 minsep-pred.dat
> -rw-r--r--+ 1 paielli ctas 23010 Jan 25 16:19 pred-alt-DR-1.dat
> -rw-r--r--+ 1 paielli ctas 23018 Jan 25 16:19 pred-alt-DR-2.dat
> -rw-r--r--+ 1 paielli ctas 51775 Jan 25 16:19 pred-alt-FP-1.dat
> -rw-r--r--+ 1 paielli ctas 25953 Jan 25 16:19 pred-alt-FP-2.dat
> -rw-r--r--+ 1 paielli ctas 24962 Jan 25 16:19 pred-tracks-DR-1.dat
> -rw-r--r--+ 1 paielli ctas 27886 Jan 25 16:19 pred-tracks-DR-2.dat
> -rw-r--r--+ 1 paielli ctas 24962 Jan 25 16:19 pred-tracks-FP-1.dat
> -rw-r--r--+ 1 paielli ctas 26346 Jan 25 16:19 pred-tracks-FP-2.dat
> -rw-r--r--+ 1 paielli ctas 509 Jan 20 2009 probe2.dat
> -rw-r--r--+ 1 paielli ctas 923 Jan 25 16:19 probe.dat
> -rw-r--r--+ 1 paielli ctas 1308 Jan 25 16:19 relspeed2.dat
> -rw-r--r--+ 1 paielli ctas 1952 Jan 19 15:08 relspeed.dat
> -rw-r--r--+ 1 paielli ctas 3120 Jan 19 15:08 sectors.dat
> -rw-r--r--+ 1 paielli ctas 2901 Jan 19 15:08 separation0.dat
> -rw-r--r--+ 70 paielli ctas 2901 Jan 25 16:19 separation.dat
> -rw-r--r--+ 1 paielli ctas 5882 Jan 19 15:08 sepHist.dat
> -rw-r--r--+ 1 paielli ctas 1691 Jan 19 15:08 time-1.dat
> -rw-r--r--+ 1 paielli ctas 1691 Jan 19 15:08 time-2.dat
> -rw-r--r--+ 1 paielli ctas 6967 Jan 19 15:08 timedif.dat
> -rw-r--r--+ 1 paielli ctas 2572 Jan 19 15:08 timetoLOShist.dat
> -rw-r--r--+ 1 paielli ctas 960 Jan 20 2009 timetoLOShistory.dat
> -rw-r--r--+ 1 paielli ctas 8027 Jan 20 2009 tracks-04-FP-DR.dat
> -rw-r--r--+ 1 paielli ctas 7946 Jan 20 2009 tracks-05-DR-DR.dat
> -rw-r--r--+ 1 paielli ctas 8027 Jan 20 2009 tracks-06-DR-FP.dat
> -rw-r--r--+ 1 paielli ctas 7946 Jan 20 2009 tracks-07-DR-DR.dat
> -rw-r--r--+ 1 paielli ctas 8030 Jan 20 2009 tracks-08-FP-DR.dat
> -rw-r--r--+ 1 paielli ctas 7947 Jan 20 2009 tracks-09-DR-DR.dat
> -rw-r--r--+ 1 paielli ctas 8030 Jan 20 2009 tracks-10-DR-FP.dat
> -rw-r--r--+ 1 paielli ctas 7947 Jan 20 2009 tracks-11-DR-DR.dat
> -rw-r--r--+ 1 paielli ctas 9259 Jan 19 15:08 tracks.dat
>
> Now let me clarify something here. I am using Scala for a program that is
> ultimately intended to aid air traffic controllers. I am not using it for
> the analysis of the testing data. I will continue using Python for the data
> analysis. That means that I don't really need to do deal with all these
> directories and data files with Scala. But what if I wanted to use Scala for
> the data analysis? That would certainly be a reasonable thing to do if I had
> not already done it in Python.
>
> Russ P.
>
>
>
>
>> Russ Paielli wrote:
>>
>>> It's a matter of convenience. Suppose I am writing a program that deals
>>>
>> with
>>
>>> a dozens of files in each of 100 different data directories. Yes, I can
>>>
>> use
>>
>>> the extended pathname (relative or absolute) for every access, but that
>>>
>> is
>>
>>> cumbersome. Changing the current directory is cleaner and more convenient
>>>
>> --
>>
>>> and possibly even less prone to error. You can always keep a record of
>>>
>> the
>>
>>> original working directory as a reference to go back to if something goes
>>> wrong or if you just want to simplify keeping track of where you are.
>>>
>>> I have actually done this sort of thing in Python.
>>>
>>> Russ P.
>>>
>>>
>>> On Wed, Feb 3, 2010 at 9:29 PM, Dave Griffith >> wrote:
>>>
>
>

On 04/02/2010, at 6:07 PM, Russ Paielli wrote:

> On Wed, Feb 3, 2010 at 10:17 PM, Ishaaq Chandy wrote:
>
>> As others have mentioned you can set the user.dir property and rely on
>> that, but in my opinion something like this:
>>
>> System.setProperty("user.dir", "/foo/bar")
>> new File("myFile1")
>> new File("myFile2")
>>
>> is more clunky than:
>>
>> topLevelDir="/foo/bar"
>> new File(topLevelDir, "myFile")
>> new File(topLevelDir, "myFile2")
>>
>> The point being that in either case you have to do an extra step - either
>> reset the working dir, or set a variable.
>>
> But if you have 50 such files, then certainly you would agree that is
> cleaner and more convenient to simply change the directory once than to
> repeat the directory over and over.

No. I would not. What makes you think you need to repeat the directory over and over. You clearly have a list of files in groups. Use a map where the key is the directory and value is a list of files.

>> Finally, if you really find it tedious to have to specify topLevelDir
>> multiple times like that then you should be easily able to construct a DSL
>> that uses implicits to hide it away.
>>
>
> Why do I need a DSL when "chdir" will do the job (if it were available)?

Because you can pass this off to multiple worker threads rather than using global variables.

with regards,
--

Lachlan Deck

No worries mate. I'll take the opportunity to make one more point too,
before I head home.

For if something is to be "yours (or my) way of thinking" then this does
not necessarily preclude it from being false, unless perhaps this very
statement is also false under that same "way of thinking". Pragmatism in
a nutshell ;)

Russ Paielli wrote:
> On Wed, Feb 3, 2010 at 11:04 PM, Tony Morris wrote:
>
>
>> Lists are polymorphic. You can store pairs.
>>
>> I assure you there is a neat way to solve your problem (whatever that
>> may actually be) and it doesn't require piss-farting about in an
>> incredibly error-prone manner with changing directories and whatever else.
>>
>>
>>
> There may well be. I'll just make one more point, then drop it. As I'm sure
> you know, there is a difference between writing code for data analysis and
> writing "production" code. You may well be right that, for production code,
> changing directories should be avoided. I'm not arguing with you on that. In
> my example, I have ~100 data directories, one for each operational error
> case. I just want to go into each directory one by one and do something with
> a few dozen files. So I construct a big loop that loops over the
> directories. Inside that loop, I can refer to each file by prepending the
> directory for every file, or I can simply change directories, and refer to
> the files by their simple name. To my way of thinking, the latter is
> simpler, cleaner, and less prone to error. But that's just my opinion.
>
> Russ P.
>
>

Or without implicits -- e.g., ThreadLocal to hold the dir and a file method:
def file(name: String) = new File(getCurDir, name)
The ThreadLocal should be private to an object with a withDir similar to Tony's but setting the ThreadLocal not the system property.

-------------------------------------
Ishaaq Chandy wrote:

Surely, if you are working with a 100 directories you probably have some
sort of uniform naming convention and so you wouldn't be hard-coding their
names all over you code. If you are, then it sounds ugly to me.

Instead, what I'd be doing is refactoring so that the code relies on a
variable that I can use. So then, it is not that big a deal to use an
absolute path over a relative path. Even so, you shouldn't have to set the
current working directory simply to use relative paths.

As others have mentioned you can set the user.dir property and rely on that,
but in my opinion something like this:

System.setProperty("user.dir", "/foo/bar")
new File("myFile1")
new File("myFile2")

is more clunky than:

topLevelDir="/foo/bar"
new File(topLevelDir, "myFile")
new File(topLevelDir, "myFile2")

The point being that in either case you have to do an extra step - either
reset the working dir, or set a variable.

Finally, if you really find it tedious to have to specify topLevelDir
multiple times like that then you should be easily able to construct a DSL
that uses implicits to hide it away.

Regards,
Ishaaq

On 4 February 2010 16:56, Russ Paielli wrote:

> It's a matter of convenience. Suppose I am writing a program that deals
> with a dozens of files in each of 100 different data directories. Yes, I can
> use the extended pathname (relative or absolute) for every access, but that
> is cumbersome. Changing the current directory is cleaner and more convenient

On Wed, Feb 3, 2010 at 11:04 PM, Tony Morris <tonymorris@gmail.com> wrote:

Lists are polymorphic. You can store pairs.

I assure you there is a neat way to solve your problem (whatever that
may actually be) and it doesn't require piss-farting about in an
incredibly error-prone manner with changing directories and whatever else.

There may well be. I'll just make one more point, then drop it. As I'm sure you know, there is a difference between writing code for data analysis and writing "production" code. You may well be right that, for production code, changing directories should be avoided. I'm not arguing with you on that. In my example, I have ~100 data directories, one for each operational error case. I just want to go into each directory one by one and do something with a few dozen files. So I construct a big loop that loops over the directories. Inside that loop, I can refer to each file by prepending the directory for every file, or I can simply change directories, and refer to the files by their simple name. To my way of thinking, the latter is simpler, cleaner, and less prone to error. But that's just my opinion.

Russ P.

Why do you have to know the index number?

-------------------------------------
Russ Paielli wrote:

On Wed, Feb 3, 2010 at 10:10 PM, Tony Morris wrote:

> Actually, it's messier and significantly more prone to error.
>
> scala> List("a", "b", "c") map ("/tmp/" + _)
> res0: List[java.lang.String] = List(/tmp/a, /tmp/b, /tmp/c)
>
> Welcome.
>

Now I have to remember the index number of each of dozens of files. That
will lead to an unreadable mess. Each of those files (a, b, c in your
example) is a different sort of file that needs to be dealt with in a
particular way. They each have names that mean something, and I sure don't
want to refer to them as myList(i) or any such thing.

Just to give you an idea of what I am talking about, I have archived
tracking data for about 100 actual "operational errors" (losses of minimum
required separation due to an error by an air traffic controller). Here is a
partial sample of the files I have for EACH CASE (these are just the .dat
files, but there are many others).

-rw-r--r--+ 1 paielli ctas 7979 Jan 20 2009 alt-04-FP-DR.dat
-rw-r--r--+ 1 paielli ctas 7811 Jan 20 2009 alt-05-DR-DR.dat
-rw-r--r--+ 1 paielli ctas 7979 Jan 20 2009 alt-06-DR-FP.dat
-rw-r--r--+ 1 paielli ctas 7811 Jan 20 2009 alt-07-DR-DR.dat
-rw-r--r--+ 1 paielli ctas 8016 Jan 20 2009 alt-08-FP-DR.dat
-rw-r--r--+ 1 paielli ctas 7848 Jan 20 2009 alt-09-DR-DR.dat
-rw-r--r--+ 1 paielli ctas 8016 Jan 20 2009 alt-10-DR-FP.dat
-rw-r--r--+ 1 paielli ctas 7848 Jan 20 2009 alt-11-DR-DR.dat
-rw-r--r--+ 1 paielli ctas 7158 Jan 19 15:08 alt-aug.dat
-rw-r--r--+ 1 paielli ctas 7127 Jan 19 15:08 alt.dat
-rw-r--r--+ 1 paielli ctas 351 Jan 19 15:08 clralt.dat
-rw-r--r--+ 1 paielli ctas 6308 Jan 19 15:08 fltplans-1.dat
-rw-r--r--+ 1 paielli ctas 6490 Jan 19 15:08 fltplans-2.dat
-rw-r--r--+ 1 paielli ctas 1315 Jan 19 15:08 fltplans.dat
-rw-r--r--+ 1 paielli ctas 4336 Jan 19 15:08 gspeed.dat
-rw-r--r--+ 1 paielli ctas 12089 Jan 20 18:01 man-alt.dat
-rw-r--r--+ 1 paielli ctas 14032 Jan 20 18:01 man-tracks.dat
-rw-r--r--+ 1 paielli ctas 1311 Jan 25 16:19 minsep-pred.dat
-rw-r--r--+ 1 paielli ctas 23010 Jan 25 16:19 pred-alt-DR-1.dat
-rw-r--r--+ 1 paielli ctas 23018 Jan 25 16:19 pred-alt-DR-2.dat
-rw-r--r--+ 1 paielli ctas 51775 Jan 25 16:19 pred-alt-FP-1.dat
-rw-r--r--+ 1 paielli ctas 25953 Jan 25 16:19 pred-alt-FP-2.dat
-rw-r--r--+ 1 paielli ctas 24962 Jan 25 16:19 pred-tracks-DR-1.dat
-rw-r--r--+ 1 paielli ctas 27886 Jan 25 16:19 pred-tracks-DR-2.dat
-rw-r--r--+ 1 paielli ctas 24962 Jan 25 16:19 pred-tracks-FP-1.dat
-rw-r--r--+ 1 paielli ctas 26346 Jan 25 16:19 pred-tracks-FP-2.dat
-rw-r--r--+ 1 paielli ctas 509 Jan 20 2009 probe2.dat
-rw-r--r--+ 1 paielli ctas 923 Jan 25 16:19 probe.dat
-rw-r--r--+ 1 paielli ctas 1308 Jan 25 16:19 relspeed2.dat
-rw-r--r--+ 1 paielli ctas 1952 Jan 19 15:08 relspeed.dat
-rw-r--r--+ 1 paielli ctas 3120 Jan 19 15:08 sectors.dat
-rw-r--r--+ 1 paielli ctas 2901 Jan 19 15:08 separation0.dat
-rw-r--r--+ 70 paielli ctas 2901 Jan 25 16:19 separation.dat
-rw-r--r--+ 1 paielli ctas 5882 Jan 19 15:08 sepHist.dat
-rw-r--r--+ 1 paielli ctas 1691 Jan 19 15:08 time-1.dat
-rw-r--r--+ 1 paielli ctas 1691 Jan 19 15:08 time-2.dat
-rw-r--r--+ 1 paielli ctas 6967 Jan 19 15:08 timedif.dat
-rw-r--r--+ 1 paielli ctas 2572 Jan 19 15:08 timetoLOShist.dat
-rw-r--r--+ 1 paielli ctas 960 Jan 20 2009 timetoLOShistory.dat
-rw-r--r--+ 1 paielli ctas 8027 Jan 20 2009 tracks-04-FP-DR.dat
-rw-r--r--+ 1 paielli ctas 7946 Jan 20 2009 tracks-05-DR-DR.dat
-rw-r--r--+ 1 paielli ctas 8027 Jan 20 2009 tracks-06-DR-FP.dat
-rw-r--r--+ 1 paielli ctas 7946 Jan 20 2009 tracks-07-DR-DR.dat
-rw-r--r--+ 1 paielli ctas 8030 Jan 20 2009 tracks-08-FP-DR.dat
-rw-r--r--+ 1 paielli ctas 7947 Jan 20 2009 tracks-09-DR-DR.dat
-rw-r--r--+ 1 paielli ctas 8030 Jan 20 2009 tracks-10-DR-FP.dat
-rw-r--r--+ 1 paielli ctas 7947 Jan 20 2009 tracks-11-DR-DR.dat
-rw-r--r--+ 1 paielli ctas 9259 Jan 19 15:08 tracks.dat

Now let me clarify something here. I am using Scala for a program that is
ultimately intended to aid air traffic controllers. I am not using it for
the analysis of the testing data. I will continue using Python for the data
analysis. That means that I don't really need to do deal with all these
directories and data files with Scala. But what if I wanted to use Scala for
the data analysis? That would certainly be a reasonable thing to do if I had
not already done it in Python.

Russ P.

>
> Russ Paielli wrote:
> > It's a matter of convenience. Suppose I am writing a program that deals
> with
> > a dozens of files in each of 100 different data directories. Yes, I can
> use
> > the extended pathname (relative or absolute) for every access, but that
> is
> > cumbersome. Changing the current directory is cleaner and more convenient
> --
> > and possibly even less prone to error. You can always keep a record of
> the
> > original working directory as a reference to go back to if something goes
> > wrong or if you just want to simplify keeping track of where you are.
> >
> > I have actually done this sort of thing in Python.
> >
> > Russ P.
> >
> >
> > On Wed, Feb 3, 2010 at 9:29 PM, Dave Griffith >wrote:
>

-------------------------------------
Tony Morris wrote:

Lists are polymorphic. You can store pairs.

I assure you there is a neat way to solve your problem (whatever that
may actually be) and it doesn't require piss-farting about in an
incredibly error-prone manner with changing directories and whatever else.

Russ Paielli wrote:
> On Wed, Feb 3, 2010 at 10:10 PM, Tony Morris wrote:
>
>
>> Actually, it's messier and significantly more prone to error.
>>
>> scala> List("a", "b", "c") map ("/tmp/" + _)
>> res0: List[java.lang.String] = List(/tmp/a, /tmp/b, /tmp/c)
>>
>> Welcome.
>>
>>
>
>
> Now I have to remember the index number of each of dozens of files. That
> will lead to an unreadable mess. Each of those files (a, b, c in your
> example) is a different sort of file that needs to be dealt with in a
> particular way. They each have names that mean something, and I sure don't
> want to refer to them as myList(i) or any such thing.
>
> Just to give you an idea of what I am talking about, I have archived
> tracking data for about 100 actual "operational errors" (losses of minimum
> required separation due to an error by an air traffic controller). Here is a
> partial sample of the files I have for EACH CASE (these are just the .dat
> files, but there are many others).
>
> -rw-r--r--+ 1 paielli ctas 7979 Jan 20 2009 alt-04-FP-DR.dat
> -rw-r--r--+ 1 paielli ctas 7811 Jan 20 2009 alt-05-DR-DR.dat
> -rw-r--r--+ 1 paielli ctas 7979 Jan 20 2009 alt-06-DR-FP.dat
> -rw-r--r--+ 1 paielli ctas 7811 Jan 20 2009 alt-07-DR-DR.dat
> -rw-r--r--+ 1 paielli ctas 8016 Jan 20 2009 alt-08-FP-DR.dat
> -rw-r--r--+ 1 paielli ctas 7848 Jan 20 2009 alt-09-DR-DR.dat
> -rw-r--r--+ 1 paielli ctas 8016 Jan 20 2009 alt-10-DR-FP.dat
> -rw-r--r--+ 1 paielli ctas 7848 Jan 20 2009 alt-11-DR-DR.dat
> -rw-r--r--+ 1 paielli ctas 7158 Jan 19 15:08 alt-aug.dat
> -rw-r--r--+ 1 paielli ctas 7127 Jan 19 15:08 alt.dat
> -rw-r--r--+ 1 paielli ctas 351 Jan 19 15:08 clralt.dat
> -rw-r--r--+ 1 paielli ctas 6308 Jan 19 15:08 fltplans-1.dat
> -rw-r--r--+ 1 paielli ctas 6490 Jan 19 15:08 fltplans-2.dat
> -rw-r--r--+ 1 paielli ctas 1315 Jan 19 15:08 fltplans.dat
> -rw-r--r--+ 1 paielli ctas 4336 Jan 19 15:08 gspeed.dat
> -rw-r--r--+ 1 paielli ctas 12089 Jan 20 18:01 man-alt.dat
> -rw-r--r--+ 1 paielli ctas 14032 Jan 20 18:01 man-tracks.dat
> -rw-r--r--+ 1 paielli ctas 1311 Jan 25 16:19 minsep-pred.dat
> -rw-r--r--+ 1 paielli ctas 23010 Jan 25 16:19 pred-alt-DR-1.dat
> -rw-r--r--+ 1 paielli ctas 23018 Jan 25 16:19 pred-alt-DR-2.dat
> -rw-r--r--+ 1 paielli ctas 51775 Jan 25 16:19 pred-alt-FP-1.dat
> -rw-r--r--+ 1 paielli ctas 25953 Jan 25 16:19 pred-alt-FP-2.dat
> -rw-r--r--+ 1 paielli ctas 24962 Jan 25 16:19 pred-tracks-DR-1.dat
> -rw-r--r--+ 1 paielli ctas 27886 Jan 25 16:19 pred-tracks-DR-2.dat
> -rw-r--r--+ 1 paielli ctas 24962 Jan 25 16:19 pred-tracks-FP-1.dat
> -rw-r--r--+ 1 paielli ctas 26346 Jan 25 16:19 pred-tracks-FP-2.dat
> -rw-r--r--+ 1 paielli ctas 509 Jan 20 2009 probe2.dat
> -rw-r--r--+ 1 paielli ctas 923 Jan 25 16:19 probe.dat
> -rw-r--r--+ 1 paielli ctas 1308 Jan 25 16:19 relspeed2.dat
> -rw-r--r--+ 1 paielli ctas 1952 Jan 19 15:08 relspeed.dat
> -rw-r--r--+ 1 paielli ctas 3120 Jan 19 15:08 sectors.dat
> -rw-r--r--+ 1 paielli ctas 2901 Jan 19 15:08 separation0.dat
> -rw-r--r--+ 70 paielli ctas 2901 Jan 25 16:19 separation.dat
> -rw-r--r--+ 1 paielli ctas 5882 Jan 19 15:08 sepHist.dat
> -rw-r--r--+ 1 paielli ctas 1691 Jan 19 15:08 time-1.dat
> -rw-r--r--+ 1 paielli ctas 1691 Jan 19 15:08 time-2.dat
> -rw-r--r--+ 1 paielli ctas 6967 Jan 19 15:08 timedif.dat
> -rw-r--r--+ 1 paielli ctas 2572 Jan 19 15:08 timetoLOShist.dat
> -rw-r--r--+ 1 paielli ctas 960 Jan 20 2009 timetoLOShistory.dat
> -rw-r--r--+ 1 paielli ctas 8027 Jan 20 2009 tracks-04-FP-DR.dat
> -rw-r--r--+ 1 paielli ctas 7946 Jan 20 2009 tracks-05-DR-DR.dat
> -rw-r--r--+ 1 paielli ctas 8027 Jan 20 2009 tracks-06-DR-FP.dat
> -rw-r--r--+ 1 paielli ctas 7946 Jan 20 2009 tracks-07-DR-DR.dat
> -rw-r--r--+ 1 paielli ctas 8030 Jan 20 2009 tracks-08-FP-DR.dat
> -rw-r--r--+ 1 paielli ctas 7947 Jan 20 2009 tracks-09-DR-DR.dat
> -rw-r--r--+ 1 paielli ctas 8030 Jan 20 2009 tracks-10-DR-FP.dat
> -rw-r--r--+ 1 paielli ctas 7947 Jan 20 2009 tracks-11-DR-DR.dat
> -rw-r--r--+ 1 paielli ctas 9259 Jan 19 15:08 tracks.dat
>
> Now let me clarify something here. I am using Scala for a program that is
> ultimately intended to aid air traffic controllers. I am not using it for
> the analysis of the testing data. I will continue using Python for the data
> analysis. That means that I don't really need to do deal with all these
> directories and data files with Scala. But what if I wanted to use Scala for
> the data analysis? That would certainly be a reasonable thing to do if I had
> not already done it in Python.
>
> Russ P.
>
>
>
>
>> Russ Paielli wrote:
>>
>>> It's a matter of convenience. Suppose I am writing a program that deals
>>>
>> with
>>
>>> a dozens of files in each of 100 different data directories. Yes, I can
>>>
>> use
>>
>>> the extended pathname (relative or absolute) for every access, but that
>>>
>> is
>>
>>> cumbersome. Changing the current directory is cleaner and more convenient
>>>
>> --
>>
>>> and possibly even less prone to error. You can always keep a record of
>>>
>> the
>>
>>> original working directory as a reference to go back to if something goes
>>> wrong or if you just want to simplify keeping track of where you are.
>>>
>>> I have actually done this sort of thing in Python.
>>>
>>> Russ P.
>>>
>>>
>>> On Wed, Feb 3, 2010 at 9:29 PM, Dave Griffith >> wrote:
>>>
>
>

You are specifying 50 filenames explicitly? Why not use parentDir.listFiles?

-------------------------------------
Russ Paielli wrote:

On Wed, Feb 3, 2010 at 10:17 PM, Ishaaq Chandy wrote:

>
> As others have mentioned you can set the user.dir property and rely on
> that, but in my opinion something like this:
>
> System.setProperty("user.dir", "/foo/bar")
> new File("myFile1")
> new File("myFile2")
>
> is more clunky than:
>
> topLevelDir="/foo/bar"
> new File(topLevelDir, "myFile")
> new File(topLevelDir, "myFile2")
>
> The point being that in either case you have to do an extra step - either
> reset the working dir, or set a variable.
>
>
But if you have 50 such files, then certainly you would agree that is
cleaner and more convenient to simply change the directory once than to
repeat the directory over and over.

> Finally, if you really find it tedious to have to specify topLevelDir
> multiple times like that then you should be easily able to construct a DSL
> that uses implicits to hide it away.
>

Why do I need a DSL when "chdir" will do the job (if it were available)?

Define false.
;)

-------------------------------------
Tony Morris wrote:

No worries mate. I'll take the opportunity to make one more point too,
before I head home.

For if something is to be "yours (or my) way of thinking" then this does
not necessarily preclude it from being false, unless perhaps this very
statement is also false under that same "way of thinking". Pragmatism in
a nutshell ;)

Russ Paielli wrote:
> On Wed, Feb 3, 2010 at 11:04 PM, Tony Morris wrote:
>
>
>> Lists are polymorphic. You can store pairs.
>>
>> I assure you there is a neat way to solve your problem (whatever that
>> may actually be) and it doesn't require piss-farting about in an
>> incredibly error-prone manner with changing directories and whatever else.
>>
>>
>>
> There may well be. I'll just make one more point, then drop it. As I'm sure
> you know, there is a difference between writing code for data analysis and
> writing "production" code. You may well be right that, for production code,
> changing directories should be avoided. I'm not arguing with you on that. In
> my example, I have ~100 data directories, one for each operational error
> case. I just want to go into each directory one by one and do something with
> a few dozen files. So I construct a big loop that loops over the
> directories. Inside that loop, I can refer to each file by prepending the
> directory for every file, or I can simply change directories, and refer to
> the files by their simple name. To my way of thinking, the latter is
> simpler, cleaner, and less prone to error. But that's just my opinion.
>
> Russ P.
>
>

If that is all you're trying to do then you're just making life difficult for yourself.

for(file <- new File("/foo/bar/topLevelDir").listFiles {
   doSomething(file)
}

additinally, if you don't want to process each and every file you can also either use a java.io.FileFilter or a java.io.FilenameFilter to filter the results.

Changing the current working directory is almost always a bad idea in a program that runs on the JVM that can potentially spawn multiple threads of work each of which may be trying to do quite different things.

Ishaaq

On 4 February 2010 18:20, Russ Paielli <russ.paielli@gmail.com> wrote:

On Wed, Feb 3, 2010 at 11:04 PM, Tony Morris <tonymorris@gmail.com> wrote:

Lists are polymorphic. You can store pairs.

I assure you there is a neat way to solve your problem (whatever that
may actually be) and it doesn't require piss-farting about in an
incredibly error-prone manner with changing directories and whatever else.

There may well be. I'll just make one more point, then drop it. As I'm sure you know, there is a difference between writing code for data analysis and writing "production" code. You may well be right that, for production code, changing directories should be avoided. I'm not arguing with you on that. In my example, I have ~100 data directories, one for each operational error case. I just want to go into each directory one by one and do something with a few dozen files. So I construct a big loop that loops over the directories. Inside that loop, I can refer to each file by prepending the directory for every file, or I can simply change directories, and refer to the files by their simple name. To my way of thinking, the latter is simpler, cleaner, and less prone to error. But that's just my opinion.

Russ P.

This is especially true if you are using a complex build system like sbt which might be doing all sorts of stuff underneath your program

2010/2/4 Ishaaq Chandy <ishaaq@gmail.com>

If that is all you're trying to do then you're just making life difficult for yourself.

for(file <- new File("/foo/bar/topLevelDir").listFiles {
   doSomething(file)
}

additinally, if you don't want to process each and every file you can also either use a java.io.FileFilter or a java.io.FilenameFilter to filter the results.

Changing the current working directory is almost always a bad idea in a program that runs on the JVM that can potentially spawn multiple threads of work each of which may be trying to do quite different things.

Ishaaq

On 4 February 2010 18:20, Russ Paielli <russ.paielli@gmail.com> wrote:

On Wed, Feb 3, 2010 at 11:04 PM, Tony Morris <tonymorris@gmail.com> wrote:

Lists are polymorphic. You can store pairs.

I assure you there is a neat way to solve your problem (whatever that
may actually be) and it doesn't require piss-farting about in an
incredibly error-prone manner with changing directories and whatever else.

There may well be. I'll just make one more point, then drop it. As I'm sure you know, there is a difference between writing code for data analysis and writing "production" code. You may well be right that, for production code, changing directories should be avoided. I'm not arguing with you on that. In my example, I have ~100 data directories, one for each operational error case. I just want to go into each directory one by one and do something with a few dozen files. So I construct a big loop that loops over the directories. Inside that loop, I can refer to each file by prepending the directory for every file, or I can simply change directories, and refer to the files by their simple name. To my way of thinking, the latter is simpler, cleaner, and less prone to error. But that's just my opinion.

Russ P.

Apologies, turned out I was misinformed, setting the user.dir property has no effect on the java.io classes and is actually discouraged anyway as that property is supposed to be global and immutable.

More discussion here:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4045688

Note the age of the bug, the fact that it is closed and all the various alternatives available for most use cases.

Regards,
Ishaaq

On 4 February 2010 21:25, Stefan Langer <mailtolanger@googlemail.com> wrote:

This is especially true if you are using a complex build system like sbt which might be doing all sorts of stuff underneath your program

2010/2/4 Ishaaq Chandy <ishaaq@gmail.com>

If that is all you're trying to do then you're just making life difficult for yourself.

for(file <- new File("/foo/bar/topLevelDir").listFiles {
   doSomething(file)
}

additinally, if you don't want to process each and every file you can also either use a java.io.FileFilter or a java.io.FilenameFilter to filter the results.

Changing the current working directory is almost always a bad idea in a program that runs on the JVM that can potentially spawn multiple threads of work each of which may be trying to do quite different things.

Ishaaq

On 4 February 2010 18:20, Russ Paielli <russ.paielli@gmail.com> wrote:

On Wed, Feb 3, 2010 at 11:04 PM, Tony Morris <tonymorris@gmail.com> wrote:

Lists are polymorphic. You can store pairs.

I assure you there is a neat way to solve your problem (whatever that
may actually be) and it doesn't require piss-farting about in an
incredibly error-prone manner with changing directories and whatever else.

There may well be. I'll just make one more point, then drop it. As I'm sure you know, there is a difference between writing code for data analysis and writing "production" code. You may well be right that, for production code, changing directories should be avoided. I'm not arguing with you on that. In my example, I have ~100 data directories, one for each operational error case. I just want to go into each directory one by one and do something with a few dozen files. So I construct a big loop that loops over the directories. Inside that loop, I can refer to each file by prepending the directory for every file, or I can simply change directories, and refer to the files by their simple name. To my way of thinking, the latter is simpler, cleaner, and less prone to error. But that's just my opinion.

Russ P.

It seems to affect File.

-------------------------------------
Ishaaq Chandy wrote:

Apologies, turned out I was misinformed, setting the user.dir property has
no effect on the java.io classes and is actually discouraged anyway as that
property is supposed to be global and immutable.

More discussion here:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4045688

Note the age of the bug, the fact that it is closed and all the various
alternatives available for most use cases.

Regards,
Ishaaq

On 4 February 2010 21:25, Stefan Langer wrote:

> This is especially true if you are using a complex build system like sbt
> which might be doing all sorts of stuff underneath your program
>
> 2010/2/4 Ishaaq Chandy
>
> If that is all you're trying to do then you're just making life difficult
>> for yourself.
>>
>> for(file <- new File("/foo/bar/topLevelDir").listFiles {
>> doSomething(file)
>> }
>>
>> additinally, if you don't want to process each and every file you can also
>> either use a java.io.FileFilter or a java.io.FilenameFilter to filter the
>> results.
>>
>> Changing the current working directory is almost always a bad idea in a
>> program that runs on the JVM that can potentially spawn multiple threads of
>> work each of which may be trying to do quite different things.
>>
>> Ishaaq
>>
>>
>> On 4 February 2010 18:20, Russ Paielli wrote:
>>
>>> On Wed, Feb 3, 2010 at 11:04 PM, Tony Morris wrote:
>>>
>>>> Lists are polymorphic. You can store pairs.
>>>>
>>>> I assure you there is a neat way to solve your problem (whatever that
>>>> may actually be) and it doesn't require piss-farting about in an
>>>> incredibly error-prone manner with changing directories and whatever
>>>> else.
>>>>
>>>>
>>> There may well be. I'll just make one more point, then drop it. As I'm
>>> sure you know, there is a difference between writing code for data analysis
>>> and writing "production" code. You may well be right that, for production
>>> code, changing directories should be avoided. I'm not arguing with you on
>>> that. In my example, I have ~100 data directories, one for each operational
>>> error case. I just want to go into each directory one by one and do
>>> something with a few dozen files. So I construct a big loop that loops over
>>> the directories. Inside that loop, I can refer to each file by prepending
>>> the directory for every file, or I can simply change directories, and refer
>>> to the files by their simple name. To my way of thinking, the latter is
>>> simpler, cleaner, and less prone to error. But that's just my opinion.
>>>
>>> Russ P.
>>>
>>>
>>
>

On Thu, Feb 4, 2010 at 2:13 AM, Ishaaq Chandy <ishaaq@gmail.com> wrote:

Changing the current working directory is almost always a bad idea in a program that runs on the JVM that can potentially spawn multiple threads of work each of which may be trying to do quite different things.

Look, guys, I'm talking about short data-analysis "scripts" of a few hundred lines or less that nobody except me will ever see or use. They typically run in a few seconds. Using multiple threads for something like that would be silly. And yes, I agree that there are many ways to avoid changing directories. I have many such scripts. In some of them I change the working directory, and in some of them I don't. It just depends on the particulars and how I feel that day.

Maybe it's because I'm so familiar with Python, but I'm just surprised that a major language with massive libraries wouldn't have a simple method to change directories. Sure, it could be misused, but so can most language features. I thought that one of goals of Scala was to be useful as a "scripting" language, but in my view, not being able to change directories easily is a significant drawback for scripting convenience. Note that I did not say it is a "major" drawback. I said it is "significant." (Come to think of it, just what the hell does "significant" mean anyway? I'll have to look it up one of these days!)

Russ P.

>>>>> "Russ" == Russ Paielli writes:

Russ> Maybe it's because I'm so familiar with Python, but I'm just
Russ> surprised that a major language with massive libraries wouldn't
Russ> have a simple method to change directories.

This is a JVM issue, not a Scala issue.

Did you see my comment about the definition of scripting, and the ThreadLocal DSL?
Slightly off topic but an extractor for a file would be nice, so instead of a FileFilter you could do e.g.
for(f <- parent.listFiles) f match {
case File(_, filename, "jpeg") =>
...
}

-------------------------------------
Russ Paielli wrote:

On Thu, Feb 4, 2010 at 2:13 AM, Ishaaq Chandy wrote:

>
> Changing the current working directory is almost always a bad idea in a
> program that runs on the JVM that can potentially spawn multiple threads of
> work each of which may be trying to do quite different things.
>
>
Look, guys, I'm talking about short data-analysis "scripts" of a few hundred
lines or less that nobody except me will ever see or use. They typically run
in a few seconds. Using multiple threads for something like that would be
silly. And yes, I agree that there are many ways to avoid changing
directories. I have many such scripts. In some of them I change the working
directory, and in some of them I don't. It just depends on the particulars
and how I feel that day.

Maybe it's because I'm so familiar with Python, but I'm just surprised that
a major language with massive libraries wouldn't have a simple method to
change directories. Sure, it could be misused, but so can most language
features. I thought that one of goals of Scala was to be useful as a
"scripting" language, but in my view, not being able to change directories
easily is a significant drawback for scripting convenience. Note that I did
not say it is a "major" drawback. I said it is "significant." (Come to think
of it, just what the hell does "significant" mean anyway? I'll have to look
it up one of these days!)

Russ P.

Here's another thought/angle: Java is not cross-platform. It's platform independent.
Meaning, changing directories is one of many very OS-ish low-level things that Java doesn't make easy.
That said, one thing no one mentioned: I believe JDK 7 adds a new file API which is really meant to address this kind of gap: OS-implemented file copying, for example, rather than reading and writing to manually copy yourself. Does anyone know if that includes changing directories?

-------------------------------------
Russ Paielli wrote:

On Thu, Feb 4, 2010 at 2:13 AM, Ishaaq Chandy wrote:

>
> Changing the current working directory is almost always a bad idea in a
> program that runs on the JVM that can potentially spawn multiple threads of
> work each of which may be trying to do quite different things.
>
>
Look, guys, I'm talking about short data-analysis "scripts" of a few hundred
lines or less that nobody except me will ever see or use. They typically run
in a few seconds. Using multiple threads for something like that would be
silly. And yes, I agree that there are many ways to avoid changing
directories. I have many such scripts. In some of them I change the working
directory, and in some of them I don't. It just depends on the particulars
and how I feel that day.

Maybe it's because I'm so familiar with Python, but I'm just surprised that
a major language with massive libraries wouldn't have a simple method to
change directories. Sure, it could be misused, but so can most language
features. I thought that one of goals of Scala was to be useful as a
"scripting" language, but in my view, not being able to change directories
easily is a significant drawback for scripting convenience. Note that I did
not say it is a "major" drawback. I said it is "significant." (Come to think
of it, just what the hell does "significant" mean anyway? I'll have to look
it up one of these days!)

Russ P.

One of the nice things about Scala is that it's relatively easy to add your own mini-DSL that replicates functionality you were fond of from other places.

object WorkingDir {
  import java.io._
  private var currentDirectory = new File( System.getProperty("user.dir") );
  def cd = currentDirectory
  def cd_=(s: String) {
    val f = new File(cd,s).getCanonicalFile;
    if (!f.exists || !f.isDirectory) {
      val g = new File(s).getCanonicalFile;
      if (!g.exists || !g.isDirectory) {
        throw new IOException("Cannot cd to "+s);
      }
      currentDirectory = g
    }
    else currentDirectory = f
  }
  def cd_=(f: File) {
    val g = f.getCanonicalFile
    if (!g.exists || !g.isDirectory) throw new IOException("Cannot cd to "+f);
    currentDirectory = g
  }
  def F(s: String) = new File(currentDirectory,s);
}

And then we use it:

scala> import WorkingDir._
import WorkingDir._

scala> F("temp.txt")
res1: java.io.File = /tmp/example/pkg/scala-2.8.0.Beta1-prerelease/temp.txt

scala> cd = ".."
cd: java.io.File = /tmp/example/pkg

scala> F("temp.txt")
res2: java.io.File = /tmp/example/pkg/temp.txt

Personally, I think this sort of stateful scripting thing scales poorly and hence should _not_ be part of the main library (unless, perhaps, it picks up a dedicated "scala.scripting" package that everyone knows could be used for scripts but otherwise should be handled with care).  But the package isn't that hard to create, so why not just create it and use it?

  --Rex

P.S. You could make WorkingDir a class, in which case you could have multiple current directories floating around at once, and then specify files using wd.F("temp.txt")

Russ,
3 points
1. Convenience methods like what you are wanting don't really have any
place in a modern language. Modern in the sense that the language
doesn't make too many assumptions about it's operating environment.
2. Once you've opened the door to such methods where do you stop? What
then "belongs" as part of the language? Do you end up with PHP? I think
this is why people react so strongly to these types of "convenience"
method suggestions.
3. You can easily create a "RichFile" object has an chdir method and a
file method. I'm fairly sure that you could import its methods into your
scope so the bulk of your code can be exactly what you want. No need to
change the language to handle your particular need. I think this is what
some people were referring to as creating a DSL. From what you've
written so far in your case the DSL would have two methods that
correspond to the companion object's two methods: chdir and file. Or
skip the imports and have the apply method create java.io.File instances
and you'll have just RFile.chdir("/path") and val f = RFile('simple file
name"); 5-6 lines tops.

HTH
Brett Knights

On 02/04/2010 11:29 AM, Naftoli Gugenheim wrote:
> Here's another thought/angle: Java is not cross-platform. It's
> platform independent. Meaning, changing directories is one of many
> very OS-ish low-level things that Java doesn't make easy. That said,
> one thing no one mentioned: I believe JDK 7 adds a new file API which
> is really meant to address this kind of gap: OS-implemented file
> copying, for example, rather than reading and writing to manually
> copy yourself. Does anyone know if that includes changing
> directories?

Just my $0.02, but I do system administration and I've written hundreds,
if not thousands, of shell scripts in bash, perl, python and Tcl.
Typically I would either use absolute paths to avoid confusion, or,
along the lines I think you're talking about, I would do something like:

pushd $SOME_DIR
for input in *.txt
do
# something here
done
popd

Honestly, I think that

implicit def strToFilenameFilter(pattern String) = new FilenameFilter {
def accept (dir File, name String) = name.matches(pattern)
}

(new File(SOME_DIR)).listFiles(".*\.txt").foreach {
// Something here
}

or even

val currentDir = new File(...)
val output = new FileWriter(new File(currentDir, "logfile"))

Is just as clean (and more flexible).

Derek

We've given you multiple alternatives to what you're trying to do - some of them are no less verbose than what you would have achieved using Python. Yet you insist on complaining that Scala won't do it exactly like Python.

As others have explicitly pointed out and I implicitly did so by sending you the Sun bug link, this is a JVM issue, not a Scala issue. If you stop thinking only of your scripts for a moment and think about the larger picture it becomes clear - how absurd does it sound for an entire virtual machine to change working directory mid flight? If you had read the bug link I sent you'd understand that what you are asking for from the JVM is not as simple as you seem to think.

If you absolutely *must* have syntax that matches Python's approach, I think you have three options:

1. Write a DSL to match Python syntax.
2. Hope someone else will do so for you and put it into some standard library (frankly, the amount of code involved is so embarrassingly small and simple that I don't understand why you'd wait for this and not go with option 1).
3. Stick to Python (or Jython if you want to use the JVM - which sounds unlikely to me).

Ishaaq

On 5 February 2010 04:58, Russ Paielli <russ.paielli@gmail.com> wrote:

On Thu, Feb 4, 2010 at 2:13 AM, Ishaaq Chandy <ishaaq@gmail.com> wrote:

Changing the current working directory is almost always a bad idea in a program that runs on the JVM that can potentially spawn multiple threads of work each of which may be trying to do quite different things.

Look, guys, I'm talking about short data-analysis "scripts" of a few hundred lines or less that nobody except me will ever see or use. They typically run in a few seconds. Using multiple threads for something like that would be silly. And yes, I agree that there are many ways to avoid changing directories. I have many such scripts. In some of them I change the working directory, and in some of them I don't. It just depends on the particulars and how I feel that day.

Maybe it's because I'm so familiar with Python, but I'm just surprised that a major language with massive libraries wouldn't have a simple method to change directories. Sure, it could be misused, but so can most language features. I thought that one of goals of Scala was to be useful as a "scripting" language, but in my view, not being able to change directories easily is a significant drawback for scripting convenience. Note that I did not say it is a "major" drawback. I said it is "significant." (Come to think of it, just what the hell does "significant" mean anyway? I'll have to look it up one of these days!)

Russ P.

Not that I can tell from the Javadocs.

However I am pretty excited about it (when it finally arrives) - being able to abstract the filesystem and create mock ones for testing will be very handy, plus we can finally get hold of things like file attributes, permissions, poll asynchronously for filesystem events, etc - IMO these deficiencies in the current JVMs are much much more troubling than not being able to change the current working directory.

Ishaaq

On 5 February 2010 05:29, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Here's another thought/angle: Java is not cross-platform. It's platform independent.
Meaning, changing directories is one of many very OS-ish low-level things that Java doesn't make easy.
That said, one thing no one mentioned: I believe JDK 7 adds a new file API which is really meant to address this kind of gap: OS-implemented file copying, for example, rather than reading and writing to manually copy yourself. Does anyone know if that includes changing directories?


-------------------------------------
Russ Paielli<russ.paielli@gmail.com> wrote:

On Thu, Feb 4, 2010 at 2:13 AM, Ishaaq Chandy <ishaaq@gmail.com> wrote:

>
> Changing the current working directory is almost always a bad idea in a
> program that runs on the JVM that can potentially spawn multiple threads of
> work each of which may be trying to do quite different things.
>
>
Look, guys, I'm talking about short data-analysis "scripts" of a few hundred
lines or less that nobody except me will ever see or use. They typically run
in a few seconds. Using multiple threads for something like that would be
silly. And yes, I agree that there are many ways to avoid changing
directories. I have many such scripts. In some of them I change the working
directory, and in some of them I don't. It just depends on the particulars
and how I feel that day.

Maybe it's because I'm so familiar with Python, but I'm just surprised that
a major language with massive libraries wouldn't have a simple method to
change directories. Sure, it could be misused, but so can most language
features. I thought that one of goals of Scala was to be useful as a
"scripting" language, but in my view, not being able to change directories
easily is a significant drawback for scripting convenience. Note that I did
not say it is a "major" drawback. I said it is "significant." (Come to think
of it, just what the hell does "significant" mean anyway? I'll have to look
it up one of these days!)

Russ P.

On Thu, Feb 4, 2010 at 3:56 PM, Ishaaq Chandy wrote:
> 3. Stick to Python (or Jython if you want to use the JVM - which sounds
> unlikely to me).

FWIW, Jython doesn't have os.chdir

Which makes sense doesn't it? Even as I wrote that, the thought did cross my mind briefly, but I couldn't be bothered checking.

On 5 February 2010 11:16, David Hall <dlwh@cs.berkeley.edu> wrote:

On Thu, Feb 4, 2010 at 3:56 PM, Ishaaq Chandy <ishaaq@gmail.com> wrote:
> 3. Stick to Python (or Jython if you want to use the JVM - which sounds
> unlikely to me).

FWIW, Jython doesn't have os.chdir

Yes. It was more for Russ, as more evidence for
it-really-can't-be-fixed-on-the-jvm .

Even if the JVM could, a reasonable solution to this problem (which is
still unclear) would still not use such a device.

David Hall wrote:
> Yes. It was more for Russ, as more evidence for
> it-really-can't-be-fixed-on-the-jvm .
>