Re: Trac to Phabricator (Maniphest) migration prototype

This looks good! Manuel > Am 21.12.2016 um 21:12 schrieb Matthew Pickering > : > > Dear devs, > > I have completed writing a migration which moves tickets from trac to > phabricator. The conversion is essentially lossless. The trac > transaction history is

Re: Retro-Haskell: can we get seq somewhat under control?

I don't want to actually put the dictionary there. I want to *pretend* to put the dictionary there. In testing mode, I want to be able to "take one out" by making it out of whole cloth; in production mode I want to just assume there are no bottoms in the constraints and never ever make the

Re: Retro-Haskell: can we get seq somewhat under control?

Actually, if you go back to the original form of Seq it would translate to data Seq a => Foo a = Foo !Int !a which requires resurrecting DatatypeContexts, and not data Foo a = Seq a => Foo !Int !a The former requires Seq to call the constructor, but doesn't pack the dictionary into the

Mailing list CCs (Was: Confused about the sub-modules)

Hi Erik, Am Mittwoch, den 21.12.2016, 20:13 +1100 schrieb Erik de Castro Lopo: > (No need to CC me, I'm subscribed to ghc-devs). I see where you are coming from, I also joined the Haskell community after having been socialized on Debian mailing lists. Slightly unfortunately, unsolicited CCs are

Improving DeriveTraversable

The role system is not currently able to use GND to derive Traversable instances. While we wait for future research to solve that problem, I think it would be nice to address a problem that can arise with DeriveTraversable: when newtypes stack up, fmaps also stack up. I've come up with a trick

Re: Trac to Phabricator (Maniphest) migration prototype

Ahh, nightmare. The address changed on the reboot -- here is the new address. http://ec2-52-211-40-21.eu-west-1.compute.amazonaws.com\ Matt On Wed, Dec 21, 2016 at 10:12 AM, Matthew Pickering wrote: > Dear devs, > > I have completed writing a migration which moves

Re: Trac to Phabricator (Maniphest) migration prototype

I just noticed that the instance was down because the disk quota had been reached. I expanded the size of storage and it should be working again. Matt On Wed, Dec 21, 2016 at 10:12 AM, Matthew Pickering wrote: > Dear devs, > > I have completed writing a migration

Re: Help needed: Restrictions of proc-notation with RebindableSyntax

On Wed, Dec 21, 2016 at 01:49:33PM -0600, amin...@gmail.com wrote: > Additionally, Opaleye uses Arrow syntax pretty heavily iirc. If I were writing the Opaleye tutorial today (and if I rewrite it) I will shy away from arrows and encourage users to use applicative style. There's only one operator

Re: Confused about the sub-modules

I *just* pushed a Cabal submodule update, so Erik probably hadn't gotten it. Excerpts from Ben Gamari's message of 2016-12-21 14:14:37 -0500: > Erik de Castro Lopo writes: > > > Edward Z. Yang wrote: > > > >> Not any more. The commit just has to exist in the remote repo

Re: Confused about the sub-modules

Erik de Castro Lopo writes: > Edward Z. Yang wrote: > >> Not any more. The commit just has to exist in the remote repo (that's >> what the lint checks.) > > So this is where I am running into trouble. Everything for process > and directory is fine, but for Cabal and

Re: Retro-Haskell: can we get seq somewhat under control?

There's a related GHC Proposal: https://github.com/ghc-proposals/ghc-proposals/pull/27 On Wed, Dec 21, 2016 at 10:04 PM, David Feuer wrote: > In the Old Days (some time before Haskell 98), `seq` wasn't fully > polymorphic. It could only be applied to instances of a certain

Retro-Haskell: can we get seq somewhat under control?

In the Old Days (some time before Haskell 98), `seq` wasn't fully polymorphic. It could only be applied to instances of a certain class. I don't know the name that class had, but let's say Seq. Apparently, some people didn't like that, and now it's gone. I'd love to be able to turn on a language

Re: Help needed: Restrictions of proc-notation with RebindableSyntax

> El 21 dic 2016, a las 02:36, Simon Peyton Jones via ghc-devs > escribió: > > > > I even wonder (whisper it) about taking it out altogether, when Edward says > “many of the original applications for arrows have been shown to be perfectly > suited to being handled by

Re: Help needed: Restrictions of proc-notation with RebindableSyntax

On Wed, Dec 21, 2016 at 05:52:34PM +0100, Boespflug, Mathieu wrote: > And Opaleye (a successor to haskellDB, for safe interaction with SQL > databases) also uses arrow notation last I checked. As I recall do-notation > is too powerful, whereas proc-notation provides exactly the right > expressive

Re: Help needed: Restrictions of proc-notation with RebindableSyntax

Exploring alternative formulations is great, but I think it's (mostly?) orthogonal to this thread's original email: Jan found the RebindableSyntax support for Arrow to be disappointing hamstrung. I've had a similar experience in the past; the occurrences of the combinators seem to have overly

Re: Help needed: Restrictions of proc-notation with RebindableSyntax

And Opaleye (a successor to haskellDB, for safe interaction with SQL databases) also uses arrow notation last I checked. As I recall do-notation is too powerful, whereas proc-notation provides exactly the right expressive power (no illegal SQL queries can be expressed). But that's not to say Tom

Re: Help needed: Restrictions of proc-notation with RebindableSyntax

On Wed, Dec 21, 2016 at 12:15 AM, Edward Kmett wrote: > > Given that little new code seems to be being written with Arrows in mind, > while some older code makes heavy use of it (hxt, etc.), refactoring the > arrow hierarchy is kind of a hard sell. It is by no means impossible,

Re: Trac to Phabricator (Maniphest) migration prototype

I was interested to see how many times the raw comment syntax was used as I don't use it myself. Here are the three queries I ran. -- Occurrences of the piece of syntax SELECT COUNT(*) FROM ticket_change WHERE field='comment' AND newvalue LIKE '%comment:%'; > 3783 -- Instances of the syntax

Re: Trac to Phabricator (Maniphest) migration prototype

I regularly use comment references on Trac, and I know others do, too. While I'm not saying they need to be supported in a prototype before we elect to go ahead with this route, I would say that preserving comment references is a necessary part of this migration. Along similar lines, the

Re: Trac to Phabricator (Maniphest) migration prototype

I wondered if someone would ask me about this. In principle I don't see why not but I don't immediately know how to get the correct label. In fact, this is an interesting example as "comment:21" refers to a commit comment (https://ghc.haskell.org/trac/ghc/ticket/10547#comment:21) which I have

Re: Trac to Phabricator (Maniphest) migration prototype

Nice work! Would it be possible to convert comment references too? For instance in http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com/T10547#182793 "comment:21" should be a link to the label #178747 If we do the transfer, we should redirect:

Re: Trac to Phabricator (Maniphest) migration prototype

> Is it possible for those like me who have a different username on trac and > phabricator to get mapped correctly? Yes, definitely. I would need to work out exactly what to do about user accounts, for this I just created accounts with the same names. There are two things to consider about a more

Re: Trac to Phabricator (Maniphest) migration prototype

Hi Matthew, Great work! I must admit I'm one of the few that generally likes Trac but I'm liking this quite a lot. Just two questions, Is it possible for those like me who have a different username on trac and phabricator to get mapped correctly? And how does the ticket creation process look?

Re: Help needed: Restrictions of proc-notation with RebindableSyntax

The S parser I was referring to was based on tracking FIRST sets, and provided a nice linear time parsing bound for (infinite) LL(1) grammars. (You can't really compute FOLLOW sets without knowing the grammar has a finite number of productions, but FIRST sets work perfectly well with infinite

Trac to Phabricator (Maniphest) migration prototype

Dear devs, I have completed writing a migration which moves tickets from trac to phabricator. The conversion is essentially lossless. The trac transaction history is replayed which means all events are transferred with their original authors and timestamps. I welcome comments on the work I have

Re: Confused about the sub-modules

Edward Z. Yang wrote: > Not any more. The commit just has to exist in the remote repo (that's > what the lint checks.) So this is where I am running into trouble. Everything for process and directory is fine, but for Cabal and containers, the git repo on git.haskell.org is missing the commits I

RE: Help needed: Restrictions of proc-notation with RebindableSyntax

The frustrating part for me is that I would like to contribute to this effort. But again, my understanding of each and every component is fleeting at best. Don’t be discouraged – you can learn! And you would not be displacing anyone… as I say, the entire arrows story in GHC lacks leadership

RE: Confused about the sub-modules

Info here. I hope it is up to date https://ghc.haskell.org/trac/ghc/wiki/Repositories If it's out of date, please fix! Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Edward Z. | Yang | Sent: 21 December 2016 06:49 | To: Erik de