This page is no longer maintained — Please continue to the home page at www.scala-lang.org

scala.io.Source.fromURL bug? Or misunderstanding..

2 replies
Toby Corkindale 2
Joined: 2010-04-19,
User offline. Last seen 42 years 45 weeks ago.

Hi,
I'm trying to use scala.io.Source.fromURL().

According to http://www.scala-lang.org/docu/files/api/scala/io/Source$object.html#fromURL%28String%29
I should be able to call it with a string, ie.
Source.fromURL("http://example.com")

However that fails because it requires a java.net.URL type, not a
string.. even though the string type is listed in the docs.

Also, the docs mention another, non-deprecated method, of fromURL(s, enc).
However it only tells me that enc should be a string - it doesn't say
what the string is meant to contain!
Should it be a MIME type? Or a character encoding? Or something else altogether?

cheers,
Toby
PS. I am testing on 2.8.0.RC1

Toby Corkindale 2
Joined: 2010-04-19,
User offline. Last seen 42 years 45 weeks ago.
Re: scala.io.Source.fromURL bug? Or misunderstanding..

On 6 May 2010 00:17, Toby Corkindale wrote:
> Hi,
> I'm trying to use scala.io.Source.fromURL().
>
> According to http://www.scala-lang.org/docu/files/api/scala/io/Source$object.html#fromURL%28String%29
> I should be able to call it with a string, ie.
> Source.fromURL("http://example.com")
>
> However that fails because it requires a java.net.URL type, not a
> string.. even though the string type is listed in the docs.

Oh, hmm, I see that in the /trunk/ the method that accepts a string
has been removed.
Why? I see now that it was only doing an immediate fromURL(new
URL(s)), but still, it was handy to have.

> Also, the docs mention another, non-deprecated method, of fromURL(s, enc).
> However it only tells me that enc should be a string - it doesn't say
> what the string is meant to contain!
> Should it be a MIME type? Or a character encoding? Or something else altogether?

I think this has changed in 2.8.0.RC1 to be a "Codec" type, although
I'm still somewhat in the dark as to the correct thing to pass
through.

Jason Zaugg
Joined: 2009-05-18,
User offline. Last seen 38 weeks 5 days ago.
Re: Re: scala.io.Source.fromURL bug? Or misunderstanding..

Here's the signature of Codec.fromBytes, similar to fromURL:

def fromBytes(bytes: Array[Byte])(implicit codec: Codec =
Codec.default): Source =
fromString(new String(bytes, codec.name))

This call relies on the default for the parameter value, which is
platform dependent:

scala> import io.{Codec, Source}
import io.{Codec, Source}

scala> Source.fromBytes(Array(65: Byte))
res5: scala.io.Source = non-empty iterator

You can also pass a Codec explicitly:

scala> Source.fromBytes(Array(65: Byte))(Codec.UTF8)
res6: scala.io.Source = non-empty iterator

If you pass a String, it will be implicitly converted to a Codec by
Codec.str2codec:

scala> Source.fromBytes(Array(65: Byte))("UTF-8")
res7: scala.io.Source = non-empty iterator

If you have an implicit value of type Codec in scope and omit the
second parameter list, this will be used:

scala> implicit val ourCodec = Codec.UTF8
ourCodec: java.nio.charset.Charset = UTF-8

scala> Source.fromBytes(Array(65: Byte))
res8: scala.io.Source = non-empty iterator

-jason

On Wed, May 5, 2010 at 4:40 PM, Toby Corkindale wrote:
> On 6 May 2010 00:17, Toby Corkindale wrote:
>> Hi,
>> I'm trying to use scala.io.Source.fromURL().
>>
>> According to http://www.scala-lang.org/docu/files/api/scala/io/Source$object.html#fromURL%28String%29
>> I should be able to call it with a string, ie.
>> Source.fromURL("http://example.com")
>>
>> However that fails because it requires a java.net.URL type, not a
>> string.. even though the string type is listed in the docs.
>
> Oh, hmm, I see that in the /trunk/ the method that accepts a string
> has been removed.
> Why? I see now that it was only doing an immediate fromURL(new
> URL(s)), but still, it was handy to have.
>
>
>> Also, the docs mention another, non-deprecated method, of fromURL(s, enc).
>> However it only tells me that enc should be a string - it doesn't say
>> what the string is meant to contain!
>> Should it be a MIME type? Or a character encoding? Or something else altogether?
>
> I think this has changed in 2.8.0.RC1 to be a "Codec" type, although
> I'm still somewhat in the dark as to the correct thing to pass
> through.
>

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland