On Mon, Jul 2, 2012 at 7:54 AM, Kazu Yamamoto wrote:

Hello,

...

vacuum allow that and much more though I don't know if it still works correctly on GHC 7.4. Anyway your isThunk is

...

isThunk a = fmap GHC.Vacuum.ClosureType.isThunk GHC.Vacuum.closureType

Great. I confirmed that this works with GHC 7.4.

Good news !

# I removed the "a" parameter.

Yes, I wrote an horrible hybrid of two idea and the result don't work... I suppose you got something like that :

isThunk :: a -> IO Bool isThunk = fmap VC.isThunk . closureType

-- Jedaï

Hi, Just a word of note: a while back, I decided to take up maintainership of Vacuum and some associated stuff. In the process of doing this, I realized that the ClosureType code in vacuum may not accurately model reality depending on the GHC version. In particular, the definition of ClosureType in vacuum as currently released on Hackage is woefully out of date with respect to Modern GHC. Matt Morrow it seems originally just copied the definition wholesale when he developed it, but as GHC has evolved, so too has the ClosureType definition. Vacuum has not kept up. I have a github repository[1] containing several cleanups of Vacuum which I'm calling Vacuum 2.0, one of these cleanups being that the ClosureType definition is automatically generated from the GHC definition, and compiled-in accordingly. I have also dropped support for older GHCs (although it could be re-added.) In this case, based on the changes I made I believe it is fairly unlikely that isThunk would turn up being wrong here. The THUNK* definitions seem to have been relatively untouched over GHC's evolution. But for more advanced functionality, it could possibly result in Vacuum as it stands constructing an invalid heap representation based on object misinterpretations. I have been busy with a new job but I am not totally absent, and I think I will take this opportunity to release v2.0 in short order, which is mostly intended as a polish and maintenance release for modern GHCs. In the future I would like to see vacuum deprecated and move all its functionality into GHC - much of the code is deeply intertwined with GHC's runtime representations and in some cases I have seen code in the package that was literally copied verbatim from the GHC sources itself, obviously dating several years. It's hard to assess the validity of much of this code. All of this feels brittle and makes me uneasy, and given the complexity of the package as it stands, will make it extremely difficult to maintain as GHC moves forward. Sorry for the ramble, but I figured it might be relevant if people are going to rely on this functionality. [1] https://github.com/thoughtpolice/vacuum On Mon, Jul 2, 2012 at 2:54 AM, Erik Hesselink wrote:

There is also the 'isevaluated' package (which depends on vacuum, but seems to do something more involved than your code).

Erik

On Mon, Jul 2, 2012 at 7:40 AM, Chaddaï Fouché wrote:

...

On Mon, Jul 2, 2012 at 5:29 AM, Kazu Yamamoto wrote:

...

Hello,

Are there any ways to see if a value is a thunk or memorized? I would like to have a function like:   isThunk :: a -> IO Bool

vacuum allow that and much more though I don't know if it still works correctly on GHC 7.4. Anyway your isThunk is

...

isThunk a = fmap GHC.Vacuum.ClosureType.isThunk GHC.Vacuum.closureType

(Feel free to arrange your imports to make that a bit more readable ;)

http://hackage.haskell.org/package/vacuum -- Jedaï

_______________________________________________ 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

-- Regards, Austin

Hi Rico, This is certainly a possibility I have not considered. However, I still think the Right Way Forward is to ultimately deprecate the current package as quickly as possible and move its outstanding functionality into GHC. Vacuum is still undeniably useful for older GHCs, so I would be willing to maintain the current package past that point. But GHC is quick moving, and considering how Vacuum is so closely linked to its internals, I think overall this is the right thing to do to reduce maintenance burden in the long haul (and it would certainly reduce a lot of code, since a good portion of it exists in GHC already as I mentioned.) I'm not completely opposed to other options here, and it's not entirely my decision either - in particular, it does add more code to GHC, which GHC HQ has to maintain possibly past my lifetime as a contributor. So I'm open to being convinced otherwise. On Mon, Jul 2, 2012 at 6:15 AM, Rico Moorman wrote:

Dear Austin,

Wouldn't it be a good idea to link the Vacuum version-number to the related ghc version number directly as it's functionality is directly tied to the ghc version anyway.

vacuum 7.4 for ghc 7.4; vacuum 7.2 for ghc 7.2 aso.

Best regards,

Rico Moorman

On Mon, Jul 2, 2012 at 12:04 PM, Austin Seipp wrote:

...

Hi,

Just a word of note: a while back, I decided to take up maintainership of Vacuum and some associated stuff. In the process of doing this, I realized that the ClosureType code in vacuum may not accurately model reality depending on the GHC version. In particular, the definition of ClosureType in vacuum as currently released on Hackage is woefully out of date with respect to Modern GHC. Matt Morrow it seems originally just copied the definition wholesale when he developed it, but as GHC has evolved, so too has the ClosureType definition. Vacuum has not kept up.

I have a github repository[1] containing several cleanups of Vacuum which I'm calling Vacuum 2.0, one of these cleanups being that the ClosureType definition is automatically generated from the GHC definition, and compiled-in accordingly. I have also dropped support for older GHCs (although it could be re-added.)

In this case, based on the changes I made I believe it is fairly unlikely that isThunk would turn up being wrong here. The THUNK* definitions seem to have been relatively untouched over GHC's evolution. But for more advanced functionality, it could possibly result in Vacuum as it stands constructing an invalid heap representation based on object misinterpretations.

I have been busy with a new job but I am not totally absent, and I think I will take this opportunity to release v2.0 in short order, which is mostly intended as a polish and maintenance release for modern GHCs. In the future I would like to see vacuum deprecated and move all its functionality into GHC - much of the code is deeply intertwined with GHC's runtime representations and in some cases I have seen code in the package that was literally copied verbatim from the GHC sources itself, obviously dating several years. It's hard to assess the validity of much of this code. All of this feels brittle and makes me uneasy, and given the complexity of the package as it stands, will make it extremely difficult to maintain as GHC moves forward.

Sorry for the ramble, but I figured it might be relevant if people are going to rely on this functionality.

[1] https://github.com/thoughtpolice/vacuum

On Mon, Jul 2, 2012 at 2:54 AM, Erik Hesselink wrote:

...

There is also the 'isevaluated' package (which depends on vacuum, but seems to do something more involved than your code).

Erik

On Mon, Jul 2, 2012 at 7:40 AM, Chaddaï Fouché wrote:

...

On Mon, Jul 2, 2012 at 5:29 AM, Kazu Yamamoto wrote:

...

Hello,

Are there any ways to see if a value is a thunk or memorized? I would like to have a function like: isThunk :: a -> IO Bool

vacuum allow that and much more though I don't know if it still works correctly on GHC 7.4. Anyway your isThunk is

...

isThunk a = fmap GHC.Vacuum.ClosureType.isThunk GHC.Vacuum.closureType

(Feel free to arrange your imports to make that a bit more readable ;)

http://hackage.haskell.org/package/vacuum -- Jedaï

_______________________________________________ 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

-- Regards, Austin

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Regards, Austin

On Mon, Jul 2, 2012 at 6:56 AM, Ivan Lazar Miljenovic wrote:

If you've taken over maintainership, should we remove it from haskell-pkg-janitors?

I haven't removed it from haskell-pkg-janitors because I haven't made a release and the current package points there as the homepage and source repository. My intentions were to remove the original repository (as I'm a member of the github group) once a release was made.

(I would also appreciate having my copyright being listed in https://github.com/thoughtpolice/vacuum/blob/master/pkgs/graphviz/src/GHC/Va... as that looks suspiciously like my code [1,2]).

I've pushed a commit to fix this. I'm very sorry - I imagine I was copy-pasting module-header boilerplate across the source tree to get some decent haddock results, and forgot about that (I also put the code for vacuum-graphviz up as LGPLv3 to match Vacuum's license even though I prefer BSD. Perhaps this should be changed as well, if you're not opposed.) I'll probably make a release later today after doing a glance over the source tree and adding attributions I otherwise forgot (including Conrad's work.) -- Regards, Austin

On Mon, Jul 2, 2012 at 7:33 AM, Ivan Lazar Miljenovic wrote:

I'm OK with BSD for this.  And I understand that copy-pasting boilerplate could mess things up ;-)

I think I'll change it then, thanks :)

There is a 2999.13.* series of graphviz out, I haven't actually tested this but I think for the limited part of the API that gets used it remains the same.

I can test this later today before pushing out something on Hackage.

When you get around to updating vacuum-cairo, it should then also dep on vacuum-graphviz and use customise vacuumParams if need be and then a custom call to graphToDotParams (that was the point of why I wrote the graphviz usage like that; Don copied a lot of the old Dot usage out just to be able to customise the attributes).

I actually have not updated the Cairo code to work with the updated packages; it is likely broken as hell, I merely put it in the source tree to keep track of it.

Well, you should probably mention Matt Morrow in Authors.txt ... ;-) (and the only thing I did was remove the old manual Dot manipulation, so it could be argued that my name isn't as important in there).

Matt is in the AUTHORS.txt at the very top :) Although he should rightfully be accredited with Copyright in all the modules, which I will get to later today as well. (Sorry for hijacking this thread, by the way.)

...

-- Regards, Austin

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

-- Regards, Austin