Nabble - Scalax - The Scala Community Library

UnknownHostException while running tests on fresh clone

2009-09-01T06:40:02Z

Hello,

I apologize if I haven’t lurked/searched enough before sending this email. Running ‘mvn install’ on a newly cloned scalax repository generates

the following error during testing. Any help is appreciated.

Thank you,

Chris

- File URL... EXCEPTION

java.net.UnknownHostException: c

at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:177)

at java.net.Socket.connect(Socket.java:519)

at java.net.Socket.connect(Socket.java:469)

at sun.net.NetworkClient.doConnect(NetworkClient.java:157)

at sun.net.NetworkClient.openServer(NetworkClient.java:118)

at sun.net.ftp.FtpClient.openServer(FtpClient.java:488)

at sun.net.ftp.FtpClient.openServer(FtpClient.java:475)

at sun.net.www.protocol.ftp.FtpURLConnection.connect(FtpURLConnection.java:270)

at sun.net.www.protocol.ftp.FtpURLConnection.getInputStream(FtpURLConnection.java:352)

at scalax.io.InputStreamResource$.is$3(resources.scala:130)

at scalax.io.InputStreamResource$$anonfun$url$1.apply(resources.scala:132)

at scalax.io.InputStreamResource$$anon$13.unsafeOpen(resources.scala:113)

at scalax.io.InputStreamResource$$anon$13.unsafeOpen(resources.scala:112)

at scalax.io.CloseableResource$Wrapper$class.unsafeOpen(resources.scala:50)

at scalax.io.InputStreamResource$$anon$2.unsafeOpen(resources.scala:74)

at scalax.control.ManagedResource.acquireFor(resources.scala:70)

at scalax.control.ManagedResource.map(resources.scala:66)

at scalax.control.ManagedSequence.toList(resources.scala:411)

at scalax.io.ReaderResource.readLines(resources.scala:183)

at scalax.io.InputStreamResource.readLines(resources.scala:98)

at InputStreamResourceTests$$anonfun$5.apply(resources.scala:78)

at InputStreamResourceTests$$anonfun$5.apply(resources.scala:73)

at scalax.testing.TestSuite$TestIs.fullTest$1(testing.scala:53)

at scalax.testing.TestSuite$TestIs$$anonfun$is$1.apply(testing.scala:58)

at scalax.testing.TestSuite$SingleTestCase.run(testing.scala:29)

at scalax.testing.TestSuite$$anonfun$runThese$1.apply(testing.scala:94)

at scalax.testing.TestSuite$$anonfun$runThese$1.apply(testing.scala:93)

at scala.Iterator$class.foreach(Iterator.scala:414)

at scala.collection.mutable.ListBuffer$$anon$1.foreach(ListBuffer.scala:266)

at scala.Iterable$class.foreach(Iterable.scala:256)

at scala.collection.mutable.ListBuffer.foreach(ListBuffer.scala:24)

at scalax.testing.TestSuite.runThese(testing.scala:93)

at scalax.testing.TestSuite.run(testing.scala:87)

at scalax.testing.TestSuite$$anonfun$runThese$1.apply(testing.scala:94)

at scalax.testing.TestSuite$$anonfun$runThese$1.apply(testing.scala:93)

at scala.Iterator$class.foreach(Iterator.scala:414)

at scala.collection.mutable.ListBuffer$$anon$1.foreach(ListBuffer.scala:266)

at scala.Iterable$class.foreach(Iterable.scala:256)

at scala.collection.mutable.ListBuffer.foreach(ListBuffer.scala:24)

at scalax.testing.TestSuite.runThese(testing.scala:93)

at scalax.testing.TestSuite.run(testing.scala:87)

at scalax.testing.TestSuite$$anonfun$runThese$1.apply(testing.scala:94)

at scalax.testing.TestSuite$$anonfun$runThese$1.apply(testing.scala:93)

at scala.Iterator$class.foreach(Iterator.scala:414)

at scala.collection.mutable.ListBuffer$$anon$1.foreach(ListBuffer.scala:266)

at scala.Iterable$class.foreach(Iterable.scala:256)

at scala.collection.mutable.ListBuffer.foreach(ListBuffer.scala:24)

at scalax.testing.TestSuite.runThese(testing.scala:93)

at scalax.testing.TestSuite.run(testing.scala:87)

at TestScalax.testScalax(main.scala:34)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:597)

at org.apache.maven.surefire.testset.PojoTestSet.executeTestMethod(PojoTestSet.java:153)

at org.apache.maven.surefire.testset.PojoTestSet.executeTestMethods(PojoTestSet.java:94)

at org.apache.maven.surefire.testset.PojoTestSet.execute(PojoTestSet.java:75)

at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)

at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)

at org.apache.maven.surefire.Surefire.run(Surefire.java:177)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:597)

at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)

at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)

Christopher Farnham
Senior Software Engineer
Decision Management Division
cfarnham@...
617.491.3474 x562

Charles River Analytics
625 Mount Auburn Street
Cambridge, MA 02138
http://www.cra.com

THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records.

Scalax.IO - Documentation Generation

2009-08-11T20:12:43Z

All,

I fixed the documentation generation for Scalax.IO (Scala-2.8.0 port) project. I'd like to know what you all think of aiming for a "Preview Release" by the end of September. I'm thinking we should have the following by then (a lot of which is already there):

Synchronous I/O API
File/Directory API
Scaladoc Documentation
Examples/Cookbooks

I wired in maven's XDoclet support for generating a usage site (includes scaladocs and statically generated HTML files). I figure this is a temporary solution until we can merge back into Scalax proper (when Scala 2.8.0 is released). To check it out, run "mvn site" and then open target/site/index.html in a web browser.

Anyone have any thoughts on the goals/deadlines? Anything I'm missing here?

- Josh

Re: layers of abstraction or simple, flat implementation

2009-07-17T10:28:57Z

None from me. There's probably no useful abstraction that could be re-used across .NET + JVM, so I figure a concrete implementation with a nice API is a better way to go (the API could be ported). Seems like a good move.

What do you think of the Stream abstractions?

- Josh

On Fri, Jul 17, 2009 at 12:20 PM, Erik Engbrecht <erik.engbrecht@...> wrote:

I think the file api I've been working on may have a significant amount of unnecessary complexity stemming from the separation of abstract interfaces defined in traits from the concrete implementations based java.io.File. Right now I think I'm going to chop it all down to a single set of concrete implementations that wrap file.

Any objections?

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The Scala BEAST" group.
To post to this group, send email to scala-beast@...
To unsubscribe from this group, send email to scala-beast%2Bunsubscribe@...
For more options, visit this group at http://groups.google.com/group/scala-beast?hl=en
-~----------~----~----~----~------~----~------~--~---

layers of abstraction or simple, flat implementation

2009-07-17T09:20:41Z

I think the file api I've been working on may have a significant amount of unnecessary complexity stemming from the separation of abstract interfaces defined in traits from the concrete implementations based java.io.File. Right now I think I'm going to chop it all down to a single set of concrete implementations that wrap file.

Any objections?

ObjectStream abstractions

2009-07-05T09:43:28Z

I just realized that afaik there is no Object*Stream support in
scalax.io or the 2.8 fork. Any thoughts on adding support? My plan
so far is to add a def objects: Traversable[Any] that you could
pattern match results from.

- Josh
Sent from my iPhone

2.8.0 Fork - File API

2009-06-29T18:35:28Z

Erik,

A few thoughts from my gander through the source:

I'm thinking the "Stuff" trait belongs in either a "Files" object, or insidea Filesystem abstraction
We should migrate from java.nio.charset.Charset to paulp's new Codec class
We should probably be using xyzStream.buffered for any of the pass-through File api calls (writeLines/readLines, etc.)

Other than that, I like what you've done. The use of Option/Either instead of null is great! I'm wondering if we should make some extractors to make pattern matching files somewhat easier...

e.g.

myPath match {
     case _ / _ / "*.foo".r =>
    case File("/") / _ / "log" / glob("**/*.log")
     case Directory() =>
}

Anyway, curious if you had any other thoughts/designs.

Also, has anyone else looked through the API to give us an idea of what they think? I plan to find sometime this week to really compare it against the upcoming JSR for Java 7.

Re: 2.8.0 Upgrades

2009-06-28T07:41:12Z

What I have (locally) right now is looking like:

trait Location {

// stuff common to files and directories

}

trait File extends Location {

// stuff specific to files

// kind of like JSR203 FileRef only with the stuff from JSR203 Path that applies to Files

// http://openjdk.java.net/projects/nio/javadoc/java/nio/file/FileRef.html

}

trait Directory extends Location {

// stuff specific to directories

}

trait Path extends Location {

// stuff roughly equivalent to a JSR203 path, objects that can be a File or a Directory

// http://openjdk.java.net/projects/nio/javadoc/java/nio/file/Path.html

}

Then there's the java.io.File wrappers which form a parallel hierarchy, along with mixins so implementation isn't duplicated between File/Directory and Path.

On Sun, Jun 28, 2009 at 9:46 AM, Josh Suereth <joshua.suereth@...> wrote:

I see the path trait becoming java's file class. Pattern matching against files and directries could be handy.

I'm in the fence with this one. However I think a well designed path trait (Composite pattern) + pattern matching could win out here.

Besides performance (against the spoon to be obsolete java file API). Are there anyother reasons?)

Sent from my iPhone

On Jun 27, 2009, at 8:09 PM, Erik Engbrecht <erik.engbrecht@...> wrote:

re: performance
The "wrongness" of such a solution depends on what your objectives are. In many cases the added type-safety would outweigh the performance impact. Assuming there is a performance impact. I don't see why the API couldn't be designed to avoid the isDirectory calls where they aren't wanted. I can think of a couple different ways to do it.

re: isDirectory vs pattern matching
People have their preferences. I don't see why both can't be supported.

re: underlying issue
What's more important: Performance or type safety? Low-level access or "doing the right thing?" I lean toward type safety and doing the right thing because people can always drop down the Java APIs. I don't see a lot of value in creating wrapper classes that just mimic the objects they wrap.

On Sat, Jun 27, 2009 at 6:39 PM, Stepan Koltsov <yozh@...yozh@...> wrote:

On Sun, Jun 28, 2009 at 00:28, Erik Engbrecht<erik.engbrecht@...erik.engbrecht@...> wrote:
> I think the trait File should be split apart so that files and directories
> have separate traits as follows because there are operations you can perform
> on files that you can't perform on directories and vice-versa.
> trait Path {
>   // methods common to both Files and Directories
> }
> trait Directory extends Path {
>   // directory specific methods
> }
> trait File extends Path {
>   // file specific methods
> }
> I'll post some updates later on tonight.

It is wrong, because of two reasons: performance and useability.

Perfornane: When you listing directory, you only get file names. To
get file type you have to call isDirectory for each file in that
directory. It could be slow.

Useability. Some people prefer calling isDirectory than doing pattern matching.

S.

--
http://erikengbrecht.blogspot.com/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The Scala BEAST" group.
To post to this group, send email to scala-beast@...
To unsubscribe from this group, send email to scala-beast%2Bunsubscribe@...
For more options, visit this group at http://groups.google.com/group/scala-beast?hl=en
-~----------~----~----~----~------~----~------~--~---

--
http://erikengbrecht.blogspot.com/

Re: 2.8.0 Upgrades

2009-06-28T06:46:49Z

I see the path trait becoming java's file class. Pattern matching against files and directries could be handy.

I'm in the fence with this one. However I think a well designed path trait (Composite pattern) + pattern matching could win out here.

Besides performance (against the spoon to be obsolete java file API). Are there anyother reasons?)

Sent from my iPhone

On Jun 27, 2009, at 8:09 PM, Erik Engbrecht <erik.engbrecht@...> wrote:

re: performance
The "wrongness" of such a solution depends on what your objectives are. In many cases the added type-safety would outweigh the performance impact. Assuming there is a performance impact. I don't see why the API couldn't be designed to avoid the isDirectory calls where they aren't wanted. I can think of a couple different ways to do it.

re: isDirectory vs pattern matching
People have their preferences. I don't see why both can't be supported.

re: underlying issue
What's more important: Performance or type safety? Low-level access or "doing the right thing?" I lean toward type safety and doing the right thing because people can always drop down the Java APIs. I don't see a lot of value in creating wrapper classes that just mimic the objects they wrap.

On Sat, Jun 27, 2009 at 6:39 PM, Stepan Koltsov <yozh@...> wrote:

On Sun, Jun 28, 2009 at 00:28, Erik Engbrecht<erik.engbrecht@...> wrote:
> I think the trait File should be split apart so that files and directories
> have separate traits as follows because there are operations you can perform
> on files that you can't perform on directories and vice-versa.
> trait Path {
>   // methods common to both Files and Directories
> }
> trait Directory extends Path {
>   // directory specific methods
> }
> trait File extends Path {
>   // file specific methods
> }
> I'll post some updates later on tonight.

It is wrong, because of two reasons: performance and useability.

Perfornane: When you listing directory, you only get file names. To
get file type you have to call isDirectory for each file in that
directory. It could be slow.

Useability. Some people prefer calling isDirectory than doing pattern matching.

S.

--
http://erikengbrecht.blogspot.com/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The Scala BEAST" group.
To post to this group, send email to scala-beast@...
To unsubscribe from this group, send email to scala-beast+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/scala-beast?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: 2.8.0 Upgrades

2009-06-27T17:09:12Z

re: performance

The "wrongness" of such a solution depends on what your objectives are. In many cases the added type-safety would outweigh the performance impact. Assuming there is a performance impact. I don't see why the API couldn't be designed to avoid the isDirectory calls where they aren't wanted. I can think of a couple different ways to do it.

re: isDirectory vs pattern matching

People have their preferences. I don't see why both can't be supported.

re: underlying issue

What's more important: Performance or type safety? Low-level access or "doing the right thing?" I lean toward type safety and doing the right thing because people can always drop down the Java APIs. I don't see a lot of value in creating wrapper classes that just mimic the objects they wrap.

On Sat, Jun 27, 2009 at 6:39 PM, Stepan Koltsov <yozh@...> wrote:

On Sun, Jun 28, 2009 at 00:28, Erik Engbrecht<erik.engbrecht@...> wrote:
> I think the trait File should be split apart so that files and directories
> have separate traits as follows because there are operations you can perform
> on files that you can't perform on directories and vice-versa.
> trait Path {
>   // methods common to both Files and Directories
> }
> trait Directory extends Path {
>   // directory specific methods
> }
> trait File extends Path {
>   // file specific methods
> }
> I'll post some updates later on tonight.

It is wrong, because of two reasons: performance and useability.

Perfornane: When you listing directory, you only get file names. To
get file type you have to call isDirectory for each file in that
directory. It could be slow.

Useability. Some people prefer calling isDirectory than doing pattern matching.

S.

--
http://erikengbrecht.blogspot.com/

IO library for 2.8.0 and JSR-203

2009-06-27T16:57:30Z

Since you guys are thinking about including the new scalax-based IO
library into 2.8.0, I think it might be a good idea to future-proof it
by thinking about how to integrate with JSR-203, slated for Java 7.
From a cursory glance a while ago, I would guess that a prominent
concern might be that the 203 API specifies an abstraction for
FileSystems. But there might be other issues.

--
Rafael de F. Ferreira.
http://www.rafaelferreira.net/

Re: 2.8.0 Upgrades

2009-06-27T16:44:05Z

--
Rafael de F. Ferreira.
http://www.rafaelferreira.net/

On Sat, Jun 27, 2009 at 7:39 PM, Stepan Koltsov<yozh@...> wrote:

> On Sun, Jun 28, 2009 at 00:28, Erik Engbrecht<erik.engbrecht@...> wrote:
>> I think the trait File should be split apart so that files and directories
>> have separate traits as follows because there are operations you can perform
>> on files that you can't perform on directories and vice-versa.
>> trait Path {
>>   // methods common to both Files and Directories
>> }
>> trait Directory extends Path {
>>   // directory specific methods
>> }
>> trait File extends Path {
>>   // file specific methods
>> }
>> I'll post some updates later on tonight.
>
> It is wrong, because of two reasons: performance and useability.
>
> Perfornane: When you listing directory, you only get file names. To
> get file type you have to call isDirectory for each file in that
> directory. It could be slow.
>
> Useability. Some people prefer calling isDirectory than doing pattern matching.
>
> S.
>
>

Re: 2.8.0 Upgrades

2009-06-27T15:39:50Z

On Sun, Jun 28, 2009 at 00:28, Erik Engbrecht<erik.engbrecht@...> wrote:

> I think the trait File should be split apart so that files and directories
> have separate traits as follows because there are operations you can perform
> on files that you can't perform on directories and vice-versa.
> trait Path {
>   // methods common to both Files and Directories
> }
> trait Directory extends Path {
>   // directory specific methods
> }
> trait File extends Path {
>   // file specific methods
> }
> I'll post some updates later on tonight.

It is wrong, because of two reasons: performance and useability.

Perfornane: When you listing directory, you only get file names. To
get file type you have to call isDirectory for each file in that
directory. It could be slow.

Useability. Some people prefer calling isDirectory than doing pattern matching.

S.

Re: 2.8.0 Upgrades

2009-06-27T13:28:43Z

I think the trait File should be split apart so that files and directories have separate traits as follows because there are operations you can perform on files that you can't perform on directories and vice-versa.

trait Path {

// methods common to both Files and Directories

}

trait Directory extends Path {

// directory specific methods

}

trait File extends Path {

// file specific methods

}

I'll post some updates later on tonight.

On Sun, Jun 21, 2009 at 8:21 PM, Josh Suereth <joshua.suereth@...> wrote:

All,

I've started a wiki article to work through upgrading the scalax.io interfaces for 2.8.0 features. Please let me know your thoughts!

http://wiki.github.com/eengbrec/Scalax.IO/upgraded-io-design-for-280-features

- Josh

--
http://erikengbrecht.blogspot.com/

Re: sbt built problem with 2.8 branch

2009-06-27T12:10:36Z

We're having trouble with sbt and 2.8.0

The maven build should work.

Sent from my iPhone

On Jun 27, 2009, at 2:28 PM, Erik Engbrecht <erik.engbrecht@...>
wrote:

> See attached log. Any ideas?
>
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "The Scala BEAST" group.
> To post to this group, send email to scala-beast@...
> To unsubscribe from this group, send email to scala-beast+unsubscribe@...
> For more options, visit this group at http://groups.google.com/group/scala-beast?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
> <update.log>

sbt built problem with 2.8 branch

2009-06-27T11:28:33Z

See attached log. Any ideas?

update.log (101K) Download Attachment

Re: Glob-mapper functions added like FileTree

2009-06-22T01:02:24Z

As I mentioned in an earlier method it is nice to be able to control
order of traversal. For example if you want to delete all files
(perhaps as the implementation of deleteRecurse method) you want to
traverse Postorder instead of Preorder.

Just a consideration. Would there be a way to do this?

A lessor issue is how would files within a directory be sorted (for traversal).

Thanks for the thoughts,

Jesse

On Mon, Jun 22, 2009 at 8:47 AM, Jorge Ortiz<jorge.ortiz@...> wrote:

> I'd encourage the use of strings rather than operators for this. Operators
> look cute, but for something like this would prove a little too brittle, I'm
> afraid.
>
> --j
>
> On Sun, Jun 21, 2009 at 12:14 PM, Josh Suereth <joshua.suereth@...>
> wrote:
>>
>> Not a bad idea. The .g would have to be after the directory in which to
>> search.   Paulp also suggested just using the existing regularExpression.
>>
>> So....
>>
>> for {
>>     file <- pwd / "**/*.log".r
>> ...
>>
>>
>> or
>>
>>
>> for {
>>    file <- pwd / "**/*.log".g
>> ...
>>
>>
>>
>> I'm thinking .g might actually be required so we can specially handle the
>> ** as "in any subdirectory".   If we used pure regular expressions, it would
>> confuse those who expected glob-mapping.   Perhaps a combined approach that
>> would allow either?
>>
>>
>> - Josh
>>
>> On Sun, Jun 21, 2009 at 3:10 PM, Alex Boisvert <boisvert@...>
>> wrote:
>>>
>>> Another idea would be to define a pimp conversion "globExpression".g
>>> analogous to the standard "regularExpression".r
>>>
>>> for {
>>> file <- (pwd + "/**/*.log").g
>>> lines <- file.readLines
>>>    if line startsWith "[ERROR]"
>>> } yield line
>>>
>>> The ** and * globs are easy to masquerade into the syntax but what about
>>> things like .{c, cpp, java} ?
>>>
>>> for {
>>> file <- (pwd + "/**/*.{java,scala}").g
>>> lines <- file.readLines
>>>    if line startsWith "[ERROR]"
>>> } yield line
>>>
>>> alex
>>>
>>> On Sun, Jun 21, 2009 at 11:21 AM, Josh Suereth <joshua.suereth@...>
>>> wrote:
>>>>
>>>> Wanted to get people's thoughts on glob-mapping of files using the
>>>> File-Tree-Walker style interface. (This is an idea I got from SBT)
>>>>
>>>>
>>>> Imagine the following code:
>>>>
>>>> for {
>>>>    file <-   pwd / ** / "*.log" //The spaces are necessary so we don't
>>>> make a comment!
>>>>    lines <- file.readLines
>>>>    if line startsWith "[ERROR]"
>>>> } yield line
>>>>
>>>> for pulling out all lines from all log files under the current working
>>>> directory or any sub-directory.
>>>>
>>>>
>>>> Another example:
>>>>
>>>> for {
>>>>    file <- pwd / * ".log"
>>>>    lines <- file.readLines
>>>>    if line startsWith "[ERROR]"
>>>> } yield line
>>>>
>>>>
>>>> This would do something similar to the above but only for one directory.
>>>>
>>>>
>>>> I'm not exactly happy with the operators used, but I do like the
>>>> idea.    Any thoughts?
>>>>
>>>>
>>>> - Josh
>>>
>>
>
>

Re: Glob-mapper functions added like FileTree

2009-06-21T23:47:19Z

I'd encourage the use of strings rather than operators for this. Operators look cute, but for something like this would prove a little too brittle, I'm afraid.

--j

On Sun, Jun 21, 2009 at 12:14 PM, Josh Suereth <joshua.suereth@...> wrote:

Not a bad idea. The .g would have to be after the directory in which to search.   Paulp also suggested just using the existing regularExpression.

So....

for {
    file <- pwd / "**/*.log".r
...

or

for {
   file <- pwd / "**/*.log".g
...

I'm thinking .g might actually be required so we can specially handle the ** as "in any subdirectory".   If we used pure regular expressions, it would confuse those who expected glob-mapping.   Perhaps a combined approach that would allow either?

- Josh

On Sun, Jun 21, 2009 at 3:10 PM, Alex Boisvert <boisvert@...> wrote:

Another idea would be to define a pimp conversion "globExpression".g analogous to the standard "regularExpression".r

for {
file <- (pwd + "/**/*.log").g

lines <- file.readLines
   if line startsWith "[ERROR]"
} yield line

The ** and * globs are easy to masquerade into the syntax but what about things like .{c, cpp, java} ?

for {
file <- (pwd + "/**/*.{java,scala}").g

lines <- file.readLines
   if line startsWith "[ERROR]"
} yield line

alex

On Sun, Jun 21, 2009 at 11:21 AM, Josh Suereth <joshua.suereth@...> wrote:

Wanted to get people's thoughts on glob-mapping of files using the File-Tree-Walker style interface. (This is an idea I got from SBT)

Imagine the following code:

for {
   file <-   pwd / ** / "*.log" //The spaces are necessary so we don't make a comment!
   lines <- file.readLines
   if line startsWith "[ERROR]"
} yield line

for pulling out all lines from all log files under the current working directory or any sub-directory.

Another example:

for {
   file <- pwd / * ".log"
   lines <- file.readLines
   if line startsWith "[ERROR]"
} yield line

This would do something similar to the above but only for one directory.

I'm not exactly happy with the operators used, but I do like the idea.    Any thoughts?

- Josh

2.8.0 Upgrades

2009-06-21T17:21:16Z

All,

I've started a wiki article to work through upgrading the scalax.io interfaces for 2.8.0 features. Please let me know your thoughts!

http://wiki.github.com/eengbrec/Scalax.IO/upgraded-io-design-for-280-features

- Josh

Re: Minimized Scalax IO branch

2009-06-21T12:26:31Z

All,

I've started trying to document what scalax currently provides and I'd like to make notes of what would need to take place to migrate to scala 2.8.0. Here's the wiki page: http://wiki.github.com/eengbrec/Scalax.IO/fiile-api.

I see the following being somewhat important:

Updating the current scalax.io to work with the new collections API
Updating scalax APIs to make use of named and default parameters.

Anyone interested in helping define how the APIs should start looking? The combination of default-parameters + implicit parameters provides some very interesting API possibilities.

- Josh

On Sun, Jun 21, 2009 at 1:50 PM, Josh Suereth <joshua.suereth@...> wrote:

We're actually trying to retain the ability to merge back into scalax when this project is "completed" or "matured". The main reason I pushed for github is the ghpages feature of github. It allows us to maintain a static website with documentation with no cost other than time. There's also rumors of github->scalatools.org integration in the future.

Anyway, let us know if you'd like to help contribute! We see this as a very important task to the evolution of scala.

- Josh

On Sun, Jun 21, 2009 at 1:13 PM, Stepan Koltsov <yozh@...> wrote:

Why on github, not on bitbucket? scalax is stored in Mercurial.

Actually, IO is only part of scalax I use, so this is great!

And also, shouldn't scalax.io be renamed to something like
org.scalatools.io or something. I don't like package name scala* for
anything unofficial.

S.

On Sun, Jun 21, 2009 at 20:35, Josh Suereth<joshua.suereth@...> wrote:
>
> I've started making the minimized scalax I/O branch on github. This should
> only contain classes need to compile the I/O portions of scalax. This is
> the first step towards making a releasable I/O library. The branch is
> called "minimize".

Re: Removing CommandLineParser from scalax.io fork

2009-06-21T12:18:26Z

Sounds reasonable to me. If paulp needs something soon for trunk then priority should be on getting to that point.

On Sun, Jun 21, 2009 at 3:11 PM, Josh Suereth <joshua.suereth@...> wrote:

All,

I'm debating removing CommandLineParser form the scalax.io fork. The reasoning is thus:

Paul Phillips is interested in something I/O related he can place in scala trunk for 2.8.0

CommandLineParser relies on PolyHashMap which I do not believe exists in scala trunk's collections
I'd like to focus mostly on a simple File API and I/O input/output convenience methods (actually, scalax is pretty rock-solid here, IMHO. Just need to upgrade to 2.8.0 collections)

David MacIver has an interesting reflective approach to Command Line arguments that may trump the current approach of CommandLineParser
Anyway, wanted to get a little feedback here. Anyone have any thoughts?

- Josh

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The Scala BEAST" group.
To post to this group, send email to scala-beast@...
To unsubscribe from this group, send email to scala-beast%2Bunsubscribe@...
For more options, visit this group at http://groups.google.com/group/scala-beast?hl=en
-~----------~----~----~----~------~----~------~--~---

--
http://erikengbrecht.blogspot.com/

Re: Glob-mapper functions added like FileTree

2009-06-21T12:14:11Z

Not a bad idea. The .g would have to be after the directory in which to search.   Paulp also suggested just using the existing regularExpression.

So....

for {
    file <- pwd / "**/*.log".r
...

or

for {
   file <- pwd / "**/*.log".g
...

I'm thinking .g might actually be required so we can specially handle the ** as "in any subdirectory".   If we used pure regular expressions, it would confuse those who expected glob-mapping.   Perhaps a combined approach that would allow either?

- Josh

On Sun, Jun 21, 2009 at 3:10 PM, Alex Boisvert <boisvert@...> wrote:

Another idea would be to define a pimp conversion "globExpression".g analogous to the standard "regularExpression".r

for {
file <- (pwd + "/**/*.log").g

lines <- file.readLines
   if line startsWith "[ERROR]"
} yield line

The ** and * globs are easy to masquerade into the syntax but what about things like .{c, cpp, java} ?

for {
file <- (pwd + "/**/*.{java,scala}").g

lines <- file.readLines
   if line startsWith "[ERROR]"
} yield line

alex

On Sun, Jun 21, 2009 at 11:21 AM, Josh Suereth <joshua.suereth@...> wrote:

Wanted to get people's thoughts on glob-mapping of files using the File-Tree-Walker style interface. (This is an idea I got from SBT)

Imagine the following code:

for {
   file <-   pwd / ** / "*.log" //The spaces are necessary so we don't make a comment!
   lines <- file.readLines
   if line startsWith "[ERROR]"
} yield line

for pulling out all lines from all log files under the current working directory or any sub-directory.

Another example:

for {
   file <- pwd / * ".log"
   lines <- file.readLines
   if line startsWith "[ERROR]"
} yield line

This would do something similar to the above but only for one directory.

I'm not exactly happy with the operators used, but I do like the idea.    Any thoughts?

- Josh

Removing CommandLineParser from scalax.io fork

2009-06-21T12:11:17Z

All,

I'm debating removing CommandLineParser form the scalax.io fork. The reasoning is thus:

Paul Phillips is interested in something I/O related he can place in scala trunk for 2.8.0
CommandLineParser relies on PolyHashMap which I do not believe exists in scala trunk's collections
I'd like to focus mostly on a simple File API and I/O input/output convenience methods (actually, scalax is pretty rock-solid here, IMHO. Just need to upgrade to 2.8.0 collections)
David MacIver has an interesting reflective approach to Command Line arguments that may trump the current approach of CommandLineParser

Anyway, wanted to get a little feedback here. Anyone have any thoughts?

- Josh

Re: Glob-mapper functions added like FileTree

2009-06-21T12:10:01Z

Another idea would be to define a pimp conversion "globExpression".g analogous to the standard "regularExpression".r

for {
file <- (pwd + "/**/*.log").g
lines <- file.readLines
if line startsWith "[ERROR]"
} yield line

The ** and * globs are easy to masquerade into the syntax but what about things like .{c, cpp, java} ?

for {
file <- (pwd + "/**/*.{java,scala}").g
lines <- file.readLines
if line startsWith "[ERROR]"
} yield line

alex

On Sun, Jun 21, 2009 at 11:21 AM, Josh Suereth <joshua.suereth@...> wrote:

Wanted to get people's thoughts on glob-mapping of files using the File-Tree-Walker style interface. (This is an idea I got from SBT)

Imagine the following code:

for {
   file <-   pwd / ** / "*.log" //The spaces are necessary so we don't make a comment!
   lines <- file.readLines
   if line startsWith "[ERROR]"
} yield line

for pulling out all lines from all log files under the current working directory or any sub-directory.

Another example:

for {
   file <- pwd / * ".log"
   lines <- file.readLines
   if line startsWith "[ERROR]"
} yield line

This would do something similar to the above but only for one directory.

I'm not exactly happy with the operators used, but I do like the idea.    Any thoughts?

- Josh

Glob-mapper functions added like FileTree

2009-06-21T11:21:51Z

Wanted to get people's thoughts on glob-mapping of files using the File-Tree-Walker style interface. (This is an idea I got from SBT)

Imagine the following code:

for {
   file <-   pwd / ** / "*.log" //The spaces are necessary so we don't make a comment!
   lines <- file.readLines
   if line startsWith "[ERROR]"
} yield line

for pulling out all lines from all log files under the current working directory or any sub-directory.

Another example:

for {
   file <- pwd / * ".log"
   lines <- file.readLines
   if line startsWith "[ERROR]"
} yield line

This would do something similar to the above but only for one directory.

I'm not exactly happy with the operators used, but I do like the idea.    Any thoughts?

- Josh

Re: Minimized Scalax IO branch

2009-06-21T10:50:53Z

We're actually trying to retain the ability to merge back into scalax when this project is "completed" or "matured". The main reason I pushed for github is the ghpages feature of github. It allows us to maintain a static website with documentation with no cost other than time. There's also rumors of github->scalatools.org integration in the future.

Anyway, let us know if you'd like to help contribute! We see this as a very important task to the evolution of scala.

- Josh

On Sun, Jun 21, 2009 at 1:13 PM, Stepan Koltsov <yozh@...> wrote:

Why on github, not on bitbucket? scalax is stored in Mercurial.

Actually, IO is only part of scalax I use, so this is great!

And also, shouldn't scalax.io be renamed to something like
org.scalatools.io or something. I don't like package name scala* for
anything unofficial.

S.

On Sun, Jun 21, 2009 at 20:35, Josh Suereth<joshua.suereth@...> wrote:
>
> I've started making the minimized scalax I/O branch on github. This should
> only contain classes need to compile the I/O portions of scalax. This is
> the first step towards making a releasable I/O library. The branch is
> called "minimize".

Re: Minimized Scalax IO branch

2009-06-21T10:13:12Z

Why on github, not on bitbucket? scalax is stored in Mercurial.

Actually, IO is only part of scalax I use, so this is great!

And also, shouldn't scalax.io be renamed to something like
org.scalatools.io or something. I don't like package name scala* for
anything unofficial.

S.

On Sun, Jun 21, 2009 at 20:35, Josh Suereth<joshua.suereth@...> wrote:
>
> I've started making the minimized scalax I/O branch on github. This should
> only contain classes need to compile the I/O portions of scalax. This is
> the first step towards making a releasable I/O library. The branch is
> called "minimize".

Minimized Scalax IO branch

2009-06-21T09:35:54Z

All,

I've started making the minimized scalax I/O branch on github. This should only contain classes need to compile the I/O portions of scalax. This is the first step towards making a releasable I/O library. The branch is called "minimize".

Also, I've set up with the latest SBT project definitions so we can cross-build the library against scala versions 2.7.2, 2.7.3, 2.7.4 and 2.7.5 simulataneously. Once I get approval, you'll see snapshots show up on scala-tools.org.

- Josh

Re: scalax I/O and Resource Management Fork

2009-06-20T16:03:07Z

Paul,

Which branch? I'll take a look at it while I'm sorting out what's in scalax and see what I can do.

-Erik

On Sat, Jun 20, 2009 at 6:01 PM, Paul Phillips <paulp@...> wrote:

On Sat, Jun 20, 2009 at 03:01:32PM -0400, Josh Suereth wrote:
> We plan to have a 0.1 (complete with documentation) released in 2-3
> months.

Unfortunately paulp can't wait 2-3 months to do something about
scala.io. It's intolerable to ship what's in there with 2.8. I have a
partial rewrite in pieces to go with my 20 other git branches, but I'm
trying to fish or cut bait on all of them so I can focus on the pattern
matcher with no distractions.

I would encourage you to either target an incremental improvement and
maybe give me something I can work into trunk with a more aggressive
timeline, or failing that to document what you have in mind, and I'll
try not to paint us into too many corners.

--
Paul Phillips | If this is raisin, make toast with it.
Imperfectionist |
Empiricist |
i'll ship a pulp |----------* http://www.improving.org/paulp/ *----------

--
http://erikengbrecht.blogspot.com/

Re: scalax I/O and Resource Management Fork

2009-06-20T15:01:12Z

On Sat, Jun 20, 2009 at 03:01:32PM -0400, Josh Suereth wrote:
> We plan to have a 0.1 (complete with documentation) released in 2-3
> months.

Unfortunately paulp can't wait 2-3 months to do something about
scala.io. It's intolerable to ship what's in there with 2.8. I have a
partial rewrite in pieces to go with my 20 other git branches, but I'm
trying to fish or cut bait on all of them so I can focus on the pattern
matcher with no distractions.

I would encourage you to either target an incremental improvement and
maybe give me something I can work into trunk with a more aggressive
timeline, or failing that to document what you have in mind, and I'll
try not to paint us into too many corners.

--
Paul Phillips | If this is raisin, make toast with it.
Imperfectionist |
Empiricist |
i'll ship a pulp |----------* http://www.improving.org/paulp/ *----------

Re: scalax I/O and Resource Management Fork

2009-06-20T12:52:43Z

quick note - I just destroyed and recreated the repo, so you probably have to refollow. I used the new hg-git plugin the hg to create it this time so we have the full revision history this time.

On Sat, Jun 20, 2009 at 3:46 PM, Jesse Eichar <jeichar.w@...> wrote:

THANK YOU!

Scala's IO is currently one of the biggest weaknesses for me. I have
slowly been evolving a little scalax-like library to handle this sort
of thing as well ( against my wishes since scalax has not seemed very
healthy as of late.)

Please let me know when I can begin testing. I am watching the repo
already and am excited to see what come from it.

A quick word to consider. In my use cases one of the biggest wins
have been handling tree's of files/directories. I requested and
helped introduce the Walker/FileTree to scalax.io and have privately
extended it so that there is more control for how directory trees can
be traversed.

The next big pluses are being able to easily read and write to files
without so much overhead of creating Readers/Writers, Channels etc...

Do you have any design ideas yet? Maybe consider looking at the
design of the nnio that is coming in Java 7 for some inspiration (I
havent but seems like it might be a good idea).

My 2 cents,

Let me know if you want any design/code reviews/testing. (This is
near and dear to my heart)

Jesse

On Sat, Jun 20, 2009 at 9:01 PM, Josh Suereth<joshua.suereth@...> wrote:
> Hi Scalax-ers,
>
> This is Josh Suereth and Erik Engbrecht.   The BEAST has decided to improve
> Scala's I/O libraries as part of our contributions to Scala.   We were
> thinking we could take the Resource Management portions and I/O from scalax
> and try to evolve it independently (and under the same BSD license).   Our
> reasoning behind this is to minimize the scope of the project (mainly to
> good I/O in scala). We believe that we can take the existing (and rather
> nice) scalax libraries and provide documentation/final touches. We would
> also use SBT's new multi-scala-version release mechanism to promote this
> subset of scalax.   This way the library can easily be used across multiple
> versions of Scala. We feel better support across Scala versions is critical
> to future commercial adoption, especially in larger, more conservative
> settings.
>
> We don't want to split the community. We believe a narrower focus will help
> us deliver a finished product in a shorter timeline. We will keep a
> compatabile license with the end goal being merge back into scalax and
> hopefully scala itself. We're calling the project scalax.io, and it's
> located on github. We'd like to keep the community active and involved and
> invite all current members to contribute to the project. We plan to have a
> 0.1 (complete with documentation) released in 2-3 months.
>
>
> - The BEAST
>

--
http://erikengbrecht.blogspot.com/

Re: scalax I/O and Resource Management Fork

2009-06-20T12:46:37Z

THANK YOU!

Scala's IO is currently one of the biggest weaknesses for me. I have
slowly been evolving a little scalax-like library to handle this sort
of thing as well ( against my wishes since scalax has not seemed very
healthy as of late.)

Please let me know when I can begin testing. I am watching the repo
already and am excited to see what come from it.

A quick word to consider. In my use cases one of the biggest wins
have been handling tree's of files/directories. I requested and
helped introduce the Walker/FileTree to scalax.io and have privately
extended it so that there is more control for how directory trees can
be traversed.

The next big pluses are being able to easily read and write to files
without so much overhead of creating Readers/Writers, Channels etc...

Do you have any design ideas yet? Maybe consider looking at the
design of the nnio that is coming in Java 7 for some inspiration (I
havent but seems like it might be a good idea).

My 2 cents,

Let me know if you want any design/code reviews/testing. (This is
near and dear to my heart)

Jesse

On Sat, Jun 20, 2009 at 9:01 PM, Josh Suereth<joshua.suereth@...> wrote:

> Hi Scalax-ers,
>
> This is Josh Suereth and Erik Engbrecht.   The BEAST has decided to improve
> Scala's I/O libraries as part of our contributions to Scala.   We were
> thinking we could take the Resource Management portions and I/O from scalax
> and try to evolve it independently (and under the same BSD license).   Our
> reasoning behind this is to minimize the scope of the project (mainly to
> good I/O in scala). We believe that we can take the existing (and rather
> nice) scalax libraries and provide documentation/final touches. We would
> also use SBT's new multi-scala-version release mechanism to promote this
> subset of scalax.   This way the library can easily be used across multiple
> versions of Scala. We feel better support across Scala versions is critical
> to future commercial adoption, especially in larger, more conservative
> settings.
>
> We don't want to split the community. We believe a narrower focus will help
> us deliver a finished product in a shorter timeline. We will keep a
> compatabile license with the end goal being merge back into scalax and
> hopefully scala itself. We're calling the project scalax.io, and it's
> located on github. We'd like to keep the community active and involved and
> invite all current members to contribute to the project. We plan to have a
> 0.1 (complete with documentation) released in 2-3 months.
>
>
> - The BEAST
>

scalax I/O and Resource Management Fork

2009-06-20T12:01:32Z

Hi Scalax-ers,

This is Josh Suereth and Erik Engbrecht. The BEAST has decided to improve Scala's I/O libraries as part of our contributions to Scala. We were thinking we could take the Resource Management portions and I/O from scalax and try to evolve it independently (and under the same BSD license). Our reasoning behind this is to minimize the scope of the project (mainly to good I/O in scala). We believe that we can take the existing (and rather nice) scalax libraries and provide documentation/final touches. We would also use SBT's new multi-scala-version release mechanism to promote this subset of scalax. This way the library can easily be used across multiple versions of Scala. We feel better support across Scala versions is critical to future commercial adoption, especially in larger, more conservative settings.

We don't want to split the community. We believe a narrower focus will help us deliver a finished product in a shorter timeline. We will keep a compatabile license with the end goal being merge back into scalax and hopefully scala itself. We're calling the project scalax.io, and it's located on github. We'd like to keep the community active and involved and invite all current members to contribute to the project. We plan to have a 0.1 (complete with documentation) released in 2-3 months.

- The BEAST

CommandLineParser use case

2009-06-19T03:59:02Z

Hi guys,

I just want to show some code that will hopefully help to improve CommandLineParser usability. For the moment I don't know how to integrate such behaviour directly to the CommandLineParser class.

Generally you can define the command line option (-x, --exclude) by this:

  val exclude = new StringOption('x', "exclude", "Exclude the given file") with AllowAll

and then evaluate it in this way:

  exclude { f =>
    println("I'll exclude the " + f + " file")
  }

Invocation and output log:

$ scala -cp scalax-0.1.jar optparser.scala --exclude somefile.txt
I'll exclude the somefile.txt file

And here is the whole code:

import scalax.io._

object Options extends CommandLineParser {
  val version = new Flag("version", "Show version info") with AllowNone
  val exclude = new StringOption('x', "exclude", "Exclude the given file") with AllowAll
}

Options.parseOrHelp(argv) { cmd =>
  object dummy {
    def extrude(o: Options.Flag)(block: => Unit) {
      if (cmd(o)) block
    }

    def extrude[T](o: Options.OptionType[T])(block: T => Unit) {
      val f = cmd(o)
      if (!f.isEmpty) block(f.get)
    }
    
    implicit def o2b(o: Options.Flag) = extrude(o)_
    implicit def o2b[T](o: Options.OptionType[T]) = extrude(o)_
  }
  
  import dummy._, Options._  
  
  version {
    println("0.1")
  }

  exclude { f =>
    println("I'll exclude the " + f + " file")
  }
}

Thanks,
Dawid Marcin Grzesiak
http://www.dmg.pl/

Re: Scalax status

2009-05-12T09:53:57Z

2009/5/12 David MacIver <david.maciver@...>:

> 2009/5/12 Stepan Koltsov <yozh@...>:
>> On Tue, May 12, 2009 at 19:47, David MacIver <david.maciver@...> wrote:
>>> 2009/5/12 Jorge Ortiz <jorge.ortiz@...>:
>>>> I consistently find myself coming back to Scalax for the IO stuff. It's
>>>> better than Source, but I don't know if it's ready to go in the standard
>>>> library (don't ask me how that's in any way logical...).
>>>
>>> I like scalax.io, but I think I wouldn't want it in the standard
>>> library. It's too transparently a wrapper around java.io (it's
>>> basically a great big pimp my library), and I'd much rather scala.io
>>> was an independent library in its own right. I think including the
>>> scalax.io stuff in the standard library would doom chances of that
>>> happening.
>>
>> Disagree. IO is a very basic thing that is needed in everyday
>> programming. Having external library is not a problem for a large
>> project, but when you write something small, the need of having
>> several extra libraries is a headache.
>>
>> One of reasons of Python success is its great (but not big) standard library.
>>
>> java.io is very basic and inconvenient library, I don't use it
>> directly even in Java.
>
> Um.
>
> You appear to be disagreeing with something that bears no resemblance
> to anything I actually said?

Ok. I see the confusion. "independent library in its own right" meant
"not a thin wrapper around java.io" (as might have been inferred from
the fact that it immediately followed my explaining how scalax.io
*was* a thin wrapper around java.io), not "not part of the standard
Scala distribution".

Re: Scalax status

2009-05-12T09:52:07Z

2009/5/12 Stepan Koltsov <yozh@...>:

> On Tue, May 12, 2009 at 19:47, David MacIver <david.maciver@...> wrote:
>> 2009/5/12 Jorge Ortiz <jorge.ortiz@...>:
>>> I consistently find myself coming back to Scalax for the IO stuff. It's
>>> better than Source, but I don't know if it's ready to go in the standard
>>> library (don't ask me how that's in any way logical...).
>>
>> I like scalax.io, but I think I wouldn't want it in the standard
>> library. It's too transparently a wrapper around java.io (it's
>> basically a great big pimp my library), and I'd much rather scala.io
>> was an independent library in its own right. I think including the
>> scalax.io stuff in the standard library would doom chances of that
>> happening.
>
> Disagree. IO is a very basic thing that is needed in everyday
> programming. Having external library is not a problem for a large
> project, but when you write something small, the need of having
> several extra libraries is a headache.
>
> One of reasons of Python success is its great (but not big) standard library.
>
> java.io is very basic and inconvenient library, I don't use it
> directly even in Java.

Um.

You appear to be disagreeing with something that bears no resemblance
to anything I actually said?