scala:4: error: value TreeHashMap is not a member of package scala.collection.immutable

Hello buragohain,
It's there alright. Your problem is most likely related to the eclipse
plugin. A lot of problems are.

scala> import scala.collection.immutable.TreeHashMap
import scala.collection.immutable.TreeHashMap

buragohain wrote:
> I was going thru David's Pollack's book and trying the multics.scala program.
> But I encountered the following problem - both in scala nightly build -
> 2.8.0.r19367-b20091102023355 (Java HotSpot(TM) Server VM, Java 1.6.0_16) -
> stand alone instolation and latest eclipse-3.5.1 plugin .
>
> multics.scala:4: error: value TreeHashMap is not a member of package
> scala.collection.immutable
>
> Has anyone any clue?
>
> regards,
>
> rbsomeg
>

I can see the class TreeHashMap in scala-library.jar and javap also can find
it.

rbsomeg

Thanks for the response. But I am facing the problem in both places - my
stand alone scala installation and in eclipse plugin (which by the way was
updated only yesterday).

To check this out - I just wrote the following - and it throws up.

import scala.collection.immutable.TreeHashMap
class CheckImport {
val v= TreeHashMap.empty

}

regards,

buragohain

Tony Morris-4 wrote:
>
> Hello buragohain,
> It's there alright. Your problem is most likely related to the eclipse
> plugin. A lot of problems are.
>
> scala> import scala.collection.immutable.TreeHashMap
> import scala.collection.immutable.TreeHashMap
>
>
> buragohain wrote:
>> I was going thru David's Pollack's book and trying the multics.scala
>> program.
>> But I encountered the following problem - both in scala nightly build -
>> 2.8.0.r19367-b20091102023355 (Java HotSpot(TM) Server VM, Java 1.6.0_16)
>> -
>> stand alone instolation and latest eclipse-3.5.1 plugin .
>>
>> multics.scala:4: error: value TreeHashMap is not a member of package
>> scala.collection.immutable
>>
>> Has anyone any clue?
>>
>> regards,
>>
>> rbsomeg
>>
>

On Sun, Dec 13, 2009 at 07:14:58PM -0800, buragohain wrote:
> To check this out - I just wrote the following - and it throws up.
>
> import scala.collection.immutable.TreeHashMap
> class CheckImport {
> val v= TreeHashMap.empty
>
> }

When using trunk, looking at the source is usually revealing.

package scala.collection
package immutable

// A dummy to fool ant until reintegration.
class TreeHashMap

/* TODO: Reintegrate

... whole rest of file commented out

*/

On Mon, Dec 14, 2009 at 4:28 AM, Paul Phillips <paulp@improving.org> wrote:

On Sun, Dec 13, 2009 at 07:14:58PM -0800, buragohain wrote:
> To check this out - I just wrote the following - and it throws up.
>
> import scala.collection.immutable.TreeHashMap
> class CheckImport {
>  val v= TreeHashMap.empty
>
> }

When using trunk, looking at the source is usually revealing.

Haha, what an awesome catch Tony! :-D

package scala.collection
package immutable

// A dummy to fool ant until reintegration.
class TreeHashMap

/* TODO: Reintegrate

... whole rest of file commented out

*/

--
Paul Phillips      | It's not enough to bash in heads - you've got to
Vivid              | bash in minds.
Empiricist         |     -- Capt Hammer
pal, i pill push   |----------* http://www.improving.org/paulp/ *----------

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Blog: klangism.blogspot.com
Twttr: twitter.com/viktorklang
Code: github.com/viktorklang

On Mon, Dec 14, 2009 at 8:59 AM, Viktor Klang <viktor.klang@gmail.com> wrote:

On Mon, Dec 14, 2009 at 4:28 AM, Paul Phillips <paulp@improving.org> wrote:

On Sun, Dec 13, 2009 at 07:14:58PM -0800, buragohain wrote:
> To check this out - I just wrote the following - and it throws up.
>
> import scala.collection.immutable.TreeHashMap
> class CheckImport {
>  val v= TreeHashMap.empty
>
> }

When using trunk, looking at the source is usually revealing.

Haha, what an awesome catch Tony! :-D

</mysterious_wrong_attribtuion>
 

package scala.collection
package immutable

// A dummy to fool ant until reintegration.
class TreeHashMap

/* TODO: Reintegrate

... whole rest of file commented out

*/

--
Paul Phillips      | It's not enough to bash in heads - you've got to
Vivid              | bash in minds.
Empiricist         |     -- Capt Hammer
pal, i pill push   |----------* http://www.improving.org/paulp/ *----------

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Blog: klangism.blogspot.com
Twttr: twitter.com/viktorklang
Code: github.com/viktorklang

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Blog: klangism.blogspot.com
Twttr: twitter.com/viktorklang
Code: github.com/viktorklang

Viktor Klang wrote:
>
>
> Haha, what an awesome catch Tony! :-D
>
>
>
It was Steve.
http://www.youtube.com/watch?v=zU1ku6B4ONI

I see that collection.immutable.TreeHashMap is still disabled. What
should we do? Reinstantiate it or replace it with something different.

Cheers

The reason I use TreeHashMap in 2.7 is because of #1610. I don't need
TreeHashMap specifically, just an immutable HashMap that works with
concurrent access. This is probably the case for most TreeHashMap
users.

If the new implementation mentioned in Tiark's comment on #1610 is
available for 2.8, I think replacement is fine if no one wants to
reintegrate TreeHashMap (which I assume is why it is still commented
out).

-Mark

> I see that collection.immutable.TreeHashMap is still disabled. What
> should we do? Reinstantiate it or replace it with something different.
>
> Cheers
>

I had planned to replace the default immutable.HashMap with a hash trie implementation for the second 2.8 beta. That should obviate the need for a separate TreeHashMap.
- Tiark

On 15.12.2009, at 15:06, martin odersky wrote:

> I see that collection.immutable.TreeHashMap is still disabled. What
> should we do? Reinstantiate it or replace it with something different.
>
> Cheers
>

+1 for this

On Tue, Dec 15, 2009 at 4:14 PM, Tiark Rompf <tiark.rompf@epfl.ch> wrote:

I had planned to replace the default immutable.HashMap with a hash trie implementation for the second 2.8 beta. That should obviate the need for a separate TreeHashMap.
- Tiark

On 15.12.2009, at 15:06, martin odersky wrote:

> I see that collection.immutable.TreeHashMap is still disabled. What
> should we do? Reinstantiate it or replace it with something different.
>
> Cheers
>
> -- Martin
>
>
> ---------- Forwarded message ----------
> From: buragohain <rbsomeg@yahoo.com>
> Date: Mon, Dec 14, 2009 at 1:42 AM
> Subject: [scala] multics.scala:4: error: value TreeHashMap is not a
> member of package scala.collection.immutable
> To: scala@listes.epfl.ch
>
>
>
> I can see the class TreeHashMap in scala-library.jar and javap also can find
> it.
>
> rbsomeg
> --
> View this message in context:
> http://old.nabble.com/multics.scala%3A4%3A-error%3A-value-TreeHashMap-is-not-a-member-of-package-scala.collection.immutable-tp26771551p26771551.html
> Sent from the Scala mailing list archive at Nabble.com.

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Blog: klangism.blogspot.com
Twttr: twitter.com/viktorklang
Code: github.com/viktorklang

I'm working on a version that wraps the Google Collections immutable classes for an external project called Scala Guava.

http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/co...
http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/co...
http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/co...
http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/co...

These classes don't require any synchronization and should be very fast. Compared to the Scala immutable implementation, separate instances don't share any internal data structures, so they will consume more memory. For our Scala based servers, we're not expecting to share any data anyway, so I'm opting for a faster implementation.

Regards,
Blair

On Dec 15, 2009, at 7:14 AM, Tiark Rompf wrote:

> I had planned to replace the default immutable.HashMap with a hash trie implementation for the second 2.8 beta. That should obviate the need for a separate TreeHashMap.
> - Tiark
>
> On 15.12.2009, at 15:06, martin odersky wrote:
>
>> I see that collection.immutable.TreeHashMap is still disabled. What
>> should we do? Reinstantiate it or replace it with something different.
>>
>> Cheers
>>

That error says "value TreeHashMap" not "class TreeHashMap".  Is there a TreeHashMap object, or just a class?

Bill

On Mon, Dec 14, 2009 at 2:42 AM, buragohain <rbsomeg@yahoo.com> wrote:

I can see the class TreeHashMap in scala-library.jar and javap also can find
it.

rbsomeg
--
View this message in context: http://old.nabble.com/multics.scala%3A4%3A-error%3A-value-TreeHashMap-is-not-a-member-of-package-scala.collection.immutable-tp26771551p26771551.html
Sent from the Scala mailing list archive at Nabble.com.

Sorry -- didn't see the responses in the related thread.
Bill

On Thu, Dec 17, 2009 at 5:31 PM, Bill Burdick <bill.burdick@gmail.com> wrote:

That error says "value TreeHashMap" not "class TreeHashMap".  Is there a TreeHashMap object, or just a class?

Bill

On Mon, Dec 14, 2009 at 2:42 AM, buragohain <rbsomeg@yahoo.com> wrote:

I can see the class TreeHashMap in scala-library.jar and javap also can find
it.

rbsomeg
--
View this message in context: http://old.nabble.com/multics.scala%3A4%3A-error%3A-value-TreeHashMap-is-not-a-member-of-package-scala.collection.immutable-tp26771551p26771551.html
Sent from the Scala mailing list archive at Nabble.com.