lambda mining

[Austin Seipp]

I just pushed support for external repositories in ./sync-all, but
didn't add async. It makes it easy to do so, however (and the patch is
small and lightweight.)

José, if async is all you're missing, I can add it to the 'extra'
repositories, and then it should be reasonably straightforward to add
it to nofib as an extra benchmark, I think.

On Fri, Aug 16, 2013 at 1:26 PM, Austin Seipp <aseipp at pobox.com> wrote:
> IMO, it's reasonable to allow this, but there's one minor sticky bit.
>
> async's only dependency is stm, and it's also part of the platform, so I
> expect it will be relatively stable. In this case, perhaps we should just
> add 'async' to the set of 'extra' libraries for ./sync-all, which can be
> built with the compiler. Then, it should be easy to add tests for nofib (and
> even testsuite, if people find bugs.) stm is already one of the 'extra'
> libraries, and there are a few smp benchmarks that use it too, so this
> doesn't really change anything in that regard.
>
> The main thing is that async isn't under our normal package structure, so
> we'll either need to A) mirror it, or B) we need to add support for
> ./sync-all to sync with an arbitrary HTTP url or something, and point it to
> Simon's repository as an extra package.
>
> I'm in favor of 2 since then we don't have to maintain an unnecessary
> mirror, and also, because it might be useful later for similar things.
>
> Thoughts?
>
> On Fri, Aug 16, 2013 at 6:58 AM, Simon Peyton-Jones <simonpj at microsoft.com>
> wrote:
>>
>> (devs: this thread is about adding useful new benchmarks to nofib.)
>>
>>
>>
>> Oh bother. I’d forgotten about dependencies. I don’t want to make building
>> nofib depend on libraries other those in GHC anyway (bytestring, unix ok,
>> asynch perhaps not).  If that makes it tricky, maybe we should give up on
>> the idea.
>>
>>
>>
>> S
>>
>>
>>
>> From: José Pedro Magalhães [mailto:jose.pedro.magalhaes at cs.ox.ac.uk]
>> Sent: 05 August 2013 08:41
>> To: Simon Peyton-Jones
>> Subject: Re: lambda mining
>>
>>
>>
>> I'm not entirely sure how to do that, though. Do I just add it to the
>> "real" subset?
>> How about dependencies (e.g. bytestring >= 0.9, unix >= 2.5.0, async >=
>> 2.0.0.0, ...)
>>
>>
>> Cheers,
>> Pedro
>>
>> On Fri, Aug 2, 2013 at 9:02 AM, Simon Peyton-Jones <simonpj at microsoft.com>
>> wrote:
>>
>> great!  Just add it :-)
>>
>>
>> simon
>>
>>
>>
>> From: José Pedro Magalhães [mailto:jpm at cs.ox.ac.uk]
>> Sent: 30 July 2013 07:48
>> To: Simon Peyton-Jones
>> Cc: Nicolas Wu; Wouter Swierstra; Jeroen Bransen
>> Subject: Re: lambda mining
>>
>>
>>
>> Hi Simon,
>>
>> (CC-ing co-authors)
>>
>> Yes, I think it might work fine. Its running time can also be adjusted
>> easily, depending on the maps
>> given as input and some internal parameters. How would we go about adding
>> it to nofib?
>>
>>
>> Thanks,
>> Pedro
>>
>> On Tue, Jul 30, 2013 at 7:04 AM, Simon Peyton-Jones
>> <simonpj at microsoft.com> wrote:
>>
>> Pedro
>>
>>
>>
>> Wandering past your home page I took a look at your “lambda mining” paper.
>> Would it be suitable as a nofib benchmark? Moderate size, authentic code...
>> Would you be interested?
>>
>>
>>
>> Simon
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
>
> --
> Regards,
> Austin - PGP: 4096R/0x91384671



-- 
Regards,
Austin - PGP: 4096R/0x91384671