Re: [GHC] #652: Have a single Data.Typeable hash table in GHCi
#652: Have a single Data.Typeable hash table in GHCi ---+ Reporter: simonmar | Owner: Type: task | Status: closed Priority: high | Milestone: 6.6 Component: Runtime System|Version: 6.4.1 Severity: normal| Resolution: fixed Keywords:| Os: Unknown Difficulty: Moderate (1 day) | Architecture: Unknown ---+ Changes (by simonmar): * resolution: = fixed * status: new = closed Comment: Done, thanks to Esa. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/652 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #652: Have a single Data.Typeable hash table in GHCi
#652: Have a single Data.Typeable hash table in GHCi ---+ Reporter: simonmar | Owner: Type: task | Status: new Priority: high | Milestone: 6.6 Component: Runtime System|Version: 6.4.1 Severity: normal| Resolution: Keywords:| Os: Unknown Difficulty: Moderate (1 day) | Architecture: Unknown ---+ Changes (by simonmar): * priority: normal = high -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/652 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #652: Have a single Data.Typeable hash table in GHCi
#652: Have a single Data.Typeable hash table in GHCi
---+
Reporter: simonmar | Owner:
Type: task | Status: new
Priority: normal| Milestone: 6.6
Component: Runtime System|Version: 6.4.1
Severity: normal| Resolution:
Keywords:| Os: Unknown
Difficulty: Moderate (1 day) | Architecture: Unknown
---+
Old description:
The hash table used by Data.Typeable is declared as a top-level IORef.
This means in GHCi, there will be two Data.Typeable hash tables: one in
the dynamically-loaded base package, and one in the statically-linked
GHCi binary. Therefore Dyanmics created in one world are incompatible
with the other world.
We have a hack to make sure the two hash tables don't use the same
uniques, so at least a {{{TypeRep}}} created in one world will ''never''
compare equal to a {{{TypeRep}}} from the other world (before this hack
we could different TypeReps bogusly claiming to be equal). However, we
would like them to compare equal when they are equal.
This implies that the packages in use in both world must be compatible
(preferably identical). This is because when a TypeRep compares equal,
we must be sure that the value has the representation we expect.
Fortunately this is the case in a stage2 GHC.
We should store a ptr (StablePtr?) to the hash table in an RTS global, so
that there is only one per runtime instance.
New description:
The hash table used by {{{Data.Typeable}}} is declared as a top-level
IORef. This means in GHCi, there will be two {{{Data.Typeable}}} hash
tables: one in the dynamically-loaded base package, and one in the
statically-linked GHCi binary. Therefore Dyanmics created in one world
are incompatible with the other world.
We have a hack to make sure the two hash tables don't use the same
uniques, so at least a {{{TypeRep}}} created in one world will ''never''
compare equal to a {{{TypeRep}}} from the other world (before this hack we
could different TypeReps bogusly claiming to be equal). However, we would
like them to compare equal when they are equal.
This implies that the packages in use in both world must be compatible
(preferably identical). This is because when a {{{TypeRep}}} compares
equal, we must be sure that the value has the representation we expect.
Fortunately this is the case in a stage2 GHC.
We should store a ptr ({{{StablePtr}}}?) to the hash table in an RTS
global, so that there is only one per runtime instance.
--
Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/652
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #652: Have a single Data.Typeable hash table in GHCi
#652: Have a single Data.Typeable hash table in GHCi
---+
Reporter: simonmar | Owner:
Type: task | Status: new
Priority: normal| Milestone: 6.6
Component: Runtime System|Version: 6.4.1
Severity: normal| Resolution:
Keywords:| Os: Unknown
Difficulty: Moderate (1 day) | Architecture: Unknown
---+
Old description:
The hash table used by {{{Data.Typeable}}} is declared as a top-level
IORef. This means in GHCi, there will be two {{{Data.Typeable}}} hash
tables: one in the dynamically-loaded base package, and one in the
statically-linked GHCi binary. Therefore Dyanmics created in one world
are incompatible with the other world.
We have a hack to make sure the two hash tables don't use the same
uniques, so at least a {{{TypeRep}}} created in one world will ''never''
compare equal to a {{{TypeRep}}} from the other world (before this hack
we could different TypeReps bogusly claiming to be equal). However, we
would like them to compare equal when they are equal.
This implies that the packages in use in both world must be compatible
(preferably identical). This is because when a {{{TypeRep}}} compares
equal, we must be sure that the value has the representation we expect.
Fortunately this is the case in a stage2 GHC.
We should store a ptr ({{{StablePtr}}}?) to the hash table in an RTS
global, so that there is only one per runtime instance.
New description:
The hash table used by {{{Data.Typeable}}} is declared as a top-level
IORef. This means in GHCi, there will be two {{{Data.Typeable}}} hash
tables: one in the dynamically-loaded base package, and one in the
statically-linked GHCi binary. Therefore Dyanmics created in one world
are incompatible with the other world.
We have a hack to make sure the two hash tables don't use the same
uniques, so at least a {{{TypeRep}}} created in one world will ''never''
compare equal to a {{{TypeRep}}} from the other world (before this hack we
could different {{{TypeRep}}}s bogusly claiming to be equal). However, we
would like them to compare equal when they are equal.
This implies that the packages in use in both world must be compatible
(preferably identical). This is because when a {{{TypeRep}}} compares
equal, we must be sure that the value has the representation we expect.
Fortunately this is the case in a stage2 GHC.
We should store a ptr ({{{StablePtr}}}?) to the hash table in an RTS
global, so that there is only one per runtime instance.
--
Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/652
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
