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 <mad.one at gmail.com> 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 <hesselink at gmail.com> 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é <chaddai.fouche at gmail.com> wrote:
>>> On Mon, Jul 2, 2012 at 5:29 AM, Kazu Yamamoto <kazu at iij.ad.jp> 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 at haskell.org>>>http://www.haskell.org/mailman/listinfo/haskell-cafe>>>> _______________________________________________
>> Haskell-Cafe mailing list
>>Haskell-Cafe at haskell.org>>http://www.haskell.org/mailman/listinfo/haskell-cafe>>>> --
> Regards,
> Austin
>> _______________________________________________
> Haskell-Cafe mailing list
>Haskell-Cafe at haskell.org>http://www.haskell.org/mailman/listinfo/haskell-cafe