From the documentation, I don't think I grasp how stable names work. From the docs: "There is no deRefStableName operation. You can't get back from a stable name to the original Haskell object. The reason for this is that the existence of a stable name for an object does not guarantee the existence of the object itself; it can still be garbage collected."
From this I can conclude that stable names behave a bit like weak pointers.
However, suppose I have a hash table of these stable names. How can I remove the redundant stable names from the table? I mean removing stable names that refer to an object that is garbage collected? I don't see any function for checking that (e.g. isStableNameTargetAlive or something) Thanks, Peter
I also would like a isStableNameTargetAlive function. Though if you had such a function then you probably _could_ make a deRefStableName function, which, since there isn't one, probably means that such a function would be hard to make. - Job On Sun, Aug 30, 2009 at 4:54 PM, Peter Verswyvelen <bugfact@gmail.com>wrote:
From the documentation, I don't think I grasp how stable names work. From the docs: "There is no deRefStableName operation. You can't get back from a stable name to the original Haskell object. The reason for this is that the existence of a stable name for an object does not guarantee the existence of the object itself; it can still be garbage collected."
From this I can conclude that stable names behave a bit like weak pointers.
However, suppose I have a hash table of these stable names. How can I remove the redundant stable names from the table? I mean removing stable names that refer to an object that is garbage collected? I don't see any function for checking that (e.g. isStableNameTargetAlive or something)
Thanks, Peter
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
but without that function, stable names are not that useful I guess? they would cause a space leak? On Mon, Aug 31, 2009 at 10:59 PM, Job Vranish <jvranish@gmail.com> wrote:
I also would like a isStableNameTargetAlive function. Though if you had such a function then you probably _could_ make a deRefStableName function, which, since there isn't one, probably means that such a function would be hard to make.
- Job
On Sun, Aug 30, 2009 at 4:54 PM, Peter Verswyvelen <bugfact@gmail.com>wrote:
From the documentation, I don't think I grasp how stable names work. From the docs: "There is no deRefStableName operation. You can't get back from a stable name to the original Haskell object. The reason for this is that the existence of a stable name for an object does not guarantee the existence of the object itself; it can still be garbage collected."
From this I can conclude that stable names behave a bit like weak pointers.
However, suppose I have a hash table of these stable names. How can I remove the redundant stable names from the table? I mean removing stable names that refer to an object that is garbage collected? I don't see any function for checking that (e.g. isStableNameTargetAlive or something)
Thanks, Peter
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Well usually, when I've used stable names, I've just used them to check if things are the same, and then thrown them away. So no chance for a space leak. It's usually unsafe to keep stable names around for very long as they can lose their ability to tell if two things are the same (if this surprises you, you should carefully reread http://haskell.org/ghc/docs/latest/html/libraries/base/System-Mem-StableName...). Out of curiosity, how are you planning on using them? - Job On Tue, Sep 1, 2009 at 3:40 AM, Peter Verswyvelen <bugfact@gmail.com> wrote:
but without that function, stable names are not that useful I guess? they would cause a space leak?
On Mon, Aug 31, 2009 at 10:59 PM, Job Vranish <jvranish@gmail.com> wrote:
I also would like a isStableNameTargetAlive function. Though if you had such a function then you probably _could_ make a deRefStableName function, which, since there isn't one, probably means that such a function would be hard to make.
- Job
On Sun, Aug 30, 2009 at 4:54 PM, Peter Verswyvelen <bugfact@gmail.com>wrote:
From the documentation, I don't think I grasp how stable names work. From the docs: "There is no deRefStableName operation. You can't get back from a stable name to the original Haskell object. The reason for this is that the existence of a stable name for an object does not guarantee the existence of the object itself; it can still be garbage collected."
From this I can conclude that stable names behave a bit like weak pointers.
However, suppose I have a hash table of these stable names. How can I remove the redundant stable names from the table? I mean removing stable names that refer to an object that is garbage collected? I don't see any function for checking that (e.g. isStableNameTargetAlive or something)
Thanks, Peter
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
I was planning to use them for caching OpenGL display lists and render targets. These are generated from a pure scene graph description, and if the same description is handed over to the render engine, it would just reuse the previously cached OpenGL object. I can of course just embedding and IORef inside the pure structures, that would also work I guess On Tue, Sep 1, 2009 at 6:09 PM, Job Vranish<jvranish@gmail.com> wrote:
Well usually, when I've used stable names, I've just used them to check if things are the same, and then thrown them away. So no chance for a space leak. It's usually unsafe to keep stable names around for very long as they can lose their ability to tell if two things are the same (if this surprises you, you should carefully reread http://haskell.org/ghc/docs/latest/html/libraries/base/System-Mem-StableName... ).
Out of curiosity, how are you planning on using them?
- Job
On Tue, Sep 1, 2009 at 3:40 AM, Peter Verswyvelen <bugfact@gmail.com> wrote:
but without that function, stable names are not that useful I guess? they would cause a space leak? On Mon, Aug 31, 2009 at 10:59 PM, Job Vranish <jvranish@gmail.com> wrote:
I also would like a isStableNameTargetAlive function. Though if you had such a function then you probably _could_ make a deRefStableName function, which, since there isn't one, probably means that such a function would be hard to make.
- Job
On Sun, Aug 30, 2009 at 4:54 PM, Peter Verswyvelen <bugfact@gmail.com> wrote:
From the documentation, I don't think I grasp how stable names work. From the docs: "There is no deRefStableName operation. You can't get back from a stable name to the original Haskell object. The reason for this is that the existence of a stable name for an object does not guarantee the existence of the object itself; it can still be garbage collected." From this I can conclude that stable names behave a bit like weak pointers. However, suppose I have a hash table of these stable names. How can I remove the redundant stable names from the table? I mean removing stable names that refer to an object that is garbage collected? I don't see any function for checking that (e.g. isStableNameTargetAlive or something) Thanks, Peter
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Have you considered computing a hash of the scene graph description (compositionally)? This gives you all the same advantages, including re-using shared subparts of the graph (which would be unlikely to stay around for very long as stable names). Luke On Tue, Sep 1, 2009 at 11:02 AM, Peter Verswyvelen<bugfact@gmail.com> wrote:
I was planning to use them for caching OpenGL display lists and render targets. These are generated from a pure scene graph description, and if the same description is handed over to the render engine, it would just reuse the previously cached OpenGL object. I can of course just embedding and IORef inside the pure structures, that would also work I guess
On Tue, Sep 1, 2009 at 6:09 PM, Job Vranish<jvranish@gmail.com> wrote:
Well usually, when I've used stable names, I've just used them to check if things are the same, and then thrown them away. So no chance for a space leak. It's usually unsafe to keep stable names around for very long as they can lose their ability to tell if two things are the same (if this surprises you, you should carefully reread http://haskell.org/ghc/docs/latest/html/libraries/base/System-Mem-StableName... ).
Out of curiosity, how are you planning on using them?
- Job
On Tue, Sep 1, 2009 at 3:40 AM, Peter Verswyvelen <bugfact@gmail.com> wrote:
but without that function, stable names are not that useful I guess? they would cause a space leak? On Mon, Aug 31, 2009 at 10:59 PM, Job Vranish <jvranish@gmail.com> wrote:
I also would like a isStableNameTargetAlive function. Though if you had such a function then you probably _could_ make a deRefStableName function, which, since there isn't one, probably means that such a function would be hard to make.
- Job
On Sun, Aug 30, 2009 at 4:54 PM, Peter Verswyvelen <bugfact@gmail.com> wrote:
From the documentation, I don't think I grasp how stable names work. From the docs: "There is no deRefStableName operation. You can't get back from a stable name to the original Haskell object. The reason for this is that the existence of a stable name for an object does not guarantee the existence of the object itself; it can still be garbage collected." From this I can conclude that stable names behave a bit like weak pointers. However, suppose I have a hash table of these stable names. How can I remove the redundant stable names from the table? I mean removing stable names that refer to an object that is garbage collected? I don't see any function for checking that (e.g. isStableNameTargetAlive or something) Thanks, Peter
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Yes that is possible too. But it feels "obvious" to first lookup by stable name. I had no idea stable names were so volatile. They should be called unstable names then :-) In .NET it is possible to assign an identifier to an object, and that identifier will always be the same for the same object, no matter where to garbage collectors moves the object in memory. For Haskell, at first sight it would feel natural to have something like that too. On Tue, Sep 1, 2009 at 8:31 PM, Luke Palmer<lrpalmer@gmail.com> wrote:
Have you considered computing a hash of the scene graph description (compositionally)? This gives you all the same advantages, including re-using shared subparts of the graph (which would be unlikely to stay around for very long as stable names).
Luke
On Tue, Sep 1, 2009 at 11:02 AM, Peter Verswyvelen<bugfact@gmail.com> wrote:
I was planning to use them for caching OpenGL display lists and render targets. These are generated from a pure scene graph description, and if the same description is handed over to the render engine, it would just reuse the previously cached OpenGL object. I can of course just embedding and IORef inside the pure structures, that would also work I guess
On Tue, Sep 1, 2009 at 6:09 PM, Job Vranish<jvranish@gmail.com> wrote:
Well usually, when I've used stable names, I've just used them to check if things are the same, and then thrown them away. So no chance for a space leak. It's usually unsafe to keep stable names around for very long as they can lose their ability to tell if two things are the same (if this surprises you, you should carefully reread http://haskell.org/ghc/docs/latest/html/libraries/base/System-Mem-StableName... ).
Out of curiosity, how are you planning on using them?
- Job
On Tue, Sep 1, 2009 at 3:40 AM, Peter Verswyvelen <bugfact@gmail.com> wrote:
but without that function, stable names are not that useful I guess? they would cause a space leak? On Mon, Aug 31, 2009 at 10:59 PM, Job Vranish <jvranish@gmail.com> wrote:
I also would like a isStableNameTargetAlive function. Though if you had such a function then you probably _could_ make a deRefStableName function, which, since there isn't one, probably means that such a function would be hard to make.
- Job
On Sun, Aug 30, 2009 at 4:54 PM, Peter Verswyvelen <bugfact@gmail.com> wrote:
>From the documentation, I don't think I grasp how stable names work. From the docs: "There is no deRefStableName operation. You can't get back from a stable name to the original Haskell object. The reason for this is that the existence of a stable name for an object does not guarantee the existence of the object itself; it can still be garbage collected." From this I can conclude that stable names behave a bit like weak pointers. However, suppose I have a hash table of these stable names. How can I remove the redundant stable names from the table? I mean removing stable names that refer to an object that is garbage collected? I don't see any function for checking that (e.g. isStableNameTargetAlive or something) Thanks, Peter
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On Sep 1, 2009, at 14:57 , Peter Verswyvelen wrote:
In .NET it is possible to assign an identifier to an object, and that identifier will always be the same for the same object, no matter where to garbage collectors moves the object in memory. For Haskell, at first sight it would feel natural to have something like that too.
Hm. I'd think such names would have to live in a monad (which then leads you to either Reader or ST, I think). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
A monad can surely handle this, but then this is purely for caching, and enforcing a monad just for getting caching sounds like overkill. Caching is something you typically add in the end, and using a monad for that seems akward no? Since all "objects" in Haskell are readonly, it looks line an ideal opportunity to associate a cached object with another object without needing to wrap a lot of code in a monad On Wed, Sep 2, 2009 at 1:25 AM, Brandon S. Allbery KF8NH<allbery@ece.cmu.edu> wrote:
On Sep 1, 2009, at 14:57 , Peter Verswyvelen wrote:
In .NET it is possible to assign an identifier to an object, and that identifier will always be the same for the same object, no matter where to garbage collectors moves the object in memory. For Haskell, at first sight it would feel natural to have something like that too.
Hm. I'd think such names would have to live in a monad (which then leads you to either Reader or ST, I think).
-- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
participants (4)
-
Brandon S. Allbery KF8NH -
Job Vranish -
Luke Palmer -
Peter Verswyvelen