From rickdzekman at gmail.com  Thu Oct  1 00:46:30 2015
From: rickdzekman at gmail.com (Rick Dzekman)
Date: Thu, 1 Oct 2015 10:46:30 +1000
Subject: [Haskell-cafe] SURVEY: How do you use Hackage?
Message-ID: <CANEHEBX4VkHUViBZxoP2v9u=chUp3pPDj97LEPUbNAYvuLfJ2w@mail.gmail.com>

I recently posted some criticisms of the Haskell User Experience on my
site. Afterwards Greshom B. and I had a brief chat over email about any
recommendations I had.

I suggested that the first step in improving the User Experience of any
product is research. I think Hackage is something that needs looking at and
we agreed that getting some qualitative data was really important. This
survey is an attempt to find out how different people use Hackage.

If you're able to participate in the survey, you can either submit a
response on this webform
<https://docs.google.com/forms/d/1YTqI4BNTQ5PHipsJqxvPMnLsxvz6GA_yHm_fO6RhK8w/viewform?usp=send_form>
 or submit a response on Reddit
<https://www.reddit.com/r/haskell/comments/3n0vaw/survey_how_do_you_use_hackage/>
.

If you have any questions or comments please feel free to email:
haskell-usability-survey at haskell.org


Thanks,

Rick Dzekman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151001/5dcde64c/attachment.html>

From achudnov at gmail.com  Thu Oct  1 00:51:09 2015
From: achudnov at gmail.com (Andrey Chudnov)
Date: Wed, 30 Sep 2015 20:51:09 -0400
Subject: [Haskell-cafe]
 =?utf-8?q?ANNOUNCE=3A_Megaparsec_=E2=80=93_an_impr?=
 =?utf-8?q?oved_and_actively_maintained_fork_of_Parsec?=
In-Reply-To: <CAHYVw0yVwcPmxP7oo81-Ag73ewESsK00-KYRozcaO6dDO3fR1Q@mail.gmail.com>
References: <560ADBAF.3060006@artyom.me> <560AEA9E.9050502@gmail.com>
 <4A1D0740-3F67-41F9-9766-F9E06311D93B@gmail.com>
 <CAHYVw0yVwcPmxP7oo81-Ag73ewESsK00-KYRozcaO6dDO3fR1Q@mail.gmail.com>
Message-ID: <560C837D.8060404@gmail.com>

I think the easiest way might be adding Mark Karpov (the author of 
megaparsec) as the maintainer of parsec and let him run with it. 
(Assuming he would like that too.) As a package trustee, Carter, you 
probably have the best chance of making that happen.

Although, I'd love to hear from the 4 (sic!) parsec maintainers 
regarding the state of the library, their commitment to maintenance and 
their opinion of megaparsec.

Request for comment from Antoine Latter, Derek Elkins, Ian Lynagh and 
Roman Cheplyaka.

On 09/30/2015 03:32 PM, Carter Schonwald wrote:
> Agreed. Great work, and if we can find a path to this being a 
> foundation for or inspiring parsec 4.0, that would probably be a net 
> win for everyone.
>
> On Wednesday, September 30, 2015, Nicola Gigante 
> <nicola.gigante at gmail.com <mailto:nicola.gigante at gmail.com>> wrote:
>
>
>     > Il giorno 29/set/2015, alle ore 21:46, Andrey Chudnov
>     <achudnov at gmail.com <javascript:;>> ha scritto:
>     >
>     > (Artyom, I hope you can forward the following to the original
>     author and, ideally, have them subscribe to the mailing list)
>     >
>     > As a heavy user of parsec, I have to say this is simply awesome.
>     I've read through the announcement and the changelog, and I have
>     to say the changes seem to be spot on and scratch so many old
>     itches I have personally struggled with when using parsec. I'm at
>     the point where I am seriously considering porting all my code to
>     megaparsec; however, lack of compatibility with GHC <7.10 is a bit
>     of a deal-breaker at this point.
>     >
>     > I'd like to discuss the decision to fork parsec. Now, I'm not
>     judging: as long as the license permits it, whether to fork or not
>     is really up to the forker.
>     >
>     > However, it seems the author of megaparsec would like it to
>     become the new standard parsing library (see "How you can help").
>     I'd like that too. However, I don't think that forking is the best
>     way to achieve that. Of the two reasons that were given here, the
>     first (stagnant development and maintenance) is a good reason to
>     become either a co-maintainer, or a new maintainer. There seems to
>     be a pretty smooth process for that now, and it doesn't raise any
>     eyebrows when someone requests to be the new maintainer having
>     good reasons for it (like willingness to contribute time and
>     effort to the package).
>     >
>     > The second reason is backwards compatibility. It's true the
>     changes might break some code, but that's why we have major
>     versions. And the overall architecture and interface is still in
>     line with parsec. So, to me it makes perfect sense to call
>     megaparsec a parsec-4.0.0.0 and get some continuity from the older
>     library. That way megaparsec becomes the default just by inheritance.
>     >
>     > So, if the author of megaparsec is open to becoming a maintainer
>     of parsec, I'm sure the Hackage Trustees would be willing to help.
>     If not, I'm personally willing to champion that.
>     >
>     > /Andrey
>     >
>
>     +1
>
>     Megaparsec seems awesome to me, especially the monad transformers
>     issue
>     is exactly what I missed in using Parsec.
>
>     As someone that often teaches a bit of haskell, I would also like
>     it to become
>     "Parsec 4.0? if that?s possible. That would save a lot of
>     boilerplate in docs and
>     tutorials about why I?m talking about megaparsec while it seems
>     the most used
>     library is parsec and explain the reasons of the fork etc.. every
>     time.
>
>     To megaparsec?s author: great work!
>
>
>     Bye,
>     Nicola
>     _______________________________________________
>     Haskell-Cafe mailing list
>     Haskell-Cafe at haskell.org <javascript:;>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150930/281440c4/attachment.html>

From fa-ml at ariis.it  Thu Oct  1 04:37:48 2015
From: fa-ml at ariis.it (Francesco Ariis)
Date: Thu, 1 Oct 2015 06:37:48 +0200
Subject: [Haskell-cafe]
 =?utf-8?q?ANNOUNCE=3A_Megaparsec_=E2=80=93_an_impr?=
 =?utf-8?q?oved_and_actively_maintained_fork_of_Parsec?=
In-Reply-To: <560C837D.8060404@gmail.com>
References: <560ADBAF.3060006@artyom.me> <560AEA9E.9050502@gmail.com>
 <4A1D0740-3F67-41F9-9766-F9E06311D93B@gmail.com>
 <CAHYVw0yVwcPmxP7oo81-Ag73ewESsK00-KYRozcaO6dDO3fR1Q@mail.gmail.com>
 <560C837D.8060404@gmail.com>
Message-ID: <20151001043748.GB2476@casa.casa>

On Wed, Sep 30, 2015 at 08:51:09PM -0400, Andrey Chudnov wrote:
> I think the easiest way might be adding Mark Karpov (the author of
> megaparsec) as the maintainer of parsec and let him run with it. (Assuming
> he would like that too.) As a package trustee, Carter, you probably have the
> best chance of making that happen.
> 
> Although, I'd love to hear from the 4 (sic!) parsec maintainers regarding
> the state of the library, their commitment to maintenance and their opinion
> of megaparsec.
> 
> Request for comment from Antoine Latter, Derek Elkins, Ian Lynagh and Roman
> Cheplyaka.

Maybe they aren't subscribed to the ML, courtesy ping to Antoine Latter.

From gershomb at gmail.com  Thu Oct  1 05:04:41 2015
From: gershomb at gmail.com (Gershom B)
Date: Thu, 1 Oct 2015 01:04:41 -0400
Subject: [Haskell-cafe] Candidate Haskell Platform 7.10.2-a for use with OS
 X El Capitan
Message-ID: <etPan.560cbf25.5ae7ef75.fe@mbp.local>

The new OS X El Capitan release (out today) broke the method that Haskell Platform uses to install itself, due to new security features. In fact, if you upgrade your OS, you are also likely to (slightly) break your existing install.

There is now a candidate new installer, available at

http://downloads.haskell.org/~platform/7.10.2/Haskell%20Platform%207.10.2-a1%2064bit-unsigned.pkg

Note that it is unsigned and you will have to give it permission to run, the usual way, by right clicking on it, and choosing "open" then explicitly allowing it to run.

The central difference between this and the prior installer is just that it installs symlinks to ghc tools in the /usr/local tree rather than the /usr tree since the latter is now off limits due to new OS X security features.

If you have a prior install and just want to "fix" it after your OS upgrade, no need to reinstall the whole platform. Just download and run the activate-hs shellscript from here: https://github.com/mzero/haskell-platform/blob/master/hptool/os-extras/osx/bin/activate-hs

Again, after a bit more testing we'll get this signed and released as the new official platform installer for OS X, but in the meantime, I wanted to make sure people were in the loop.

Regards,
Gershom


From roma at ro-che.info  Thu Oct  1 07:17:36 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Thu, 1 Oct 2015 10:17:36 +0300
Subject: [Haskell-cafe]
 =?utf-8?q?ANNOUNCE=3A_Megaparsec_=E2=80=93_an_impr?=
 =?utf-8?q?oved_and_actively_maintained_fork_of_Parsec?=
In-Reply-To: <560C837D.8060404@gmail.com>
References: <560ADBAF.3060006@artyom.me> <560AEA9E.9050502@gmail.com>
 <4A1D0740-3F67-41F9-9766-F9E06311D93B@gmail.com>
 <CAHYVw0yVwcPmxP7oo81-Ag73ewESsK00-KYRozcaO6dDO3fR1Q@mail.gmail.com>
 <560C837D.8060404@gmail.com>
Message-ID: <560CDE10.8090201@ro-che.info>

On 10/01/2015 03:51 AM, Andrey Chudnov wrote:
> I think the easiest way might be adding Mark Karpov (the author of
> megaparsec) as the maintainer of parsec and let him run with it.
> (Assuming he would like that too.) As a package trustee, Carter, you
> probably have the best chance of making that happen.
> 
> Although, I'd love to hear from the 4 (sic!) parsec maintainers
> regarding the state of the library, their commitment to maintenance and
> their opinion of megaparsec.
> 
> Request for comment from Antoine Latter, Derek Elkins, Ian Lynagh and
> Roman Cheplyaka.

Indeed four of us happen to have hackage upload rights for parsec, but I
believe the only actual maintainer is Antoine.

For what it's worth, I've been long dissatisfied with the state of
parsec and would love to see it evolve.

But let's hear from Antoine.

Roman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151001/bfcff171/attachment.sig>

From ollie at ocharles.org.uk  Thu Oct  1 09:01:10 2015
From: ollie at ocharles.org.uk (Oliver Charles)
Date: Thu, 01 Oct 2015 09:01:10 +0000
Subject: [Haskell-cafe] Merging the OpenGLRaw and gl packages
In-Reply-To: <CANBN=mt-tWyE=t1gJ9_G2sZZH9KSJ58hRTeJpgW5knDFMLCsJg@mail.gmail.com>
References: <CANBN=msHkd14O2PAsCGoXE=SAWhe8Zzisho3FeiC1P6Y7OFJ-w@mail.gmail.com>
 <CANBN=msTe-=fB6p89-4+iBQ3vj_8GY-o-j1Ee9iH2-DGTc_itg@mail.gmail.com>
 <CAJ5riwL1xJeTaxueoV6bbH+t6fY04B2kPFyzbUG4c3iLApzrAA@mail.gmail.com>
 <CANBN=mt-tWyE=t1gJ9_G2sZZH9KSJ58hRTeJpgW5knDFMLCsJg@mail.gmail.com>
Message-ID: <CAGRp5RmoNM7NR8sGoRBtpWJNdb1c8m0TfixkvyVA-sYPo4x8Lw@mail.gmail.com>

On Wed, Sep 30, 2015 at 6:38 PM Sven Panne <svenpanne at gmail.com> wrote:

> IMHO using pattern synonyms vs. plain old Haskell values is to a large
> part just bikeshedding, at least in the trivial case at hand where we talk
> about simple integral values. It basically boils down to the question: Is
>
>    foo x = case x of
>      GL_BAR -> expr1
>      GL_BAZ -> expr2
>      _ -> expr3
>
> really so much better than
>
>    foo x
>      | x == GL_BAR = expr1
>      | x == GL_BAZ = expr2
>      | otherwise = expr3
>

Yes, because the first approach is an expression that you can use anywhere.
Sure, there's little difference when you do it at the "top" of a function
definition, as you're doing. However, it's a lot more significant if you
want to do something like:

foo x = doSomething (case x of ...)

Without pattern synonyms, you either have

foo x = doSomething x'
  where x' | x == ... = ...

or

{-# LANGUAGE MultiWayIf #-}

foo x = doSomething (if | x == ... -> ...)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151001/d689f647/attachment.html>

From aditya.siram at gmail.com  Thu Oct  1 14:51:28 2015
From: aditya.siram at gmail.com (aditya siram)
Date: Thu, 1 Oct 2015 09:51:28 -0500
Subject: [Haskell-cafe] 7.10.2 : Compilation slowdown.
In-Reply-To: <CAJ8B99z6RVov8xhSjTsRn2YYRvvL6qhz0R47MhOeOCVwu+mfzw@mail.gmail.com>
References: <CAJrReyiQPKhaCLaX+gjFp-d6evQsUzYBUUC_GM2yq8eqS3dcMw@mail.gmail.com>
 <CAHYVw0yD_O2gFQC+cJThvoLuSgKNYfd+KQ7t8XyNaCp3naUOPw@mail.gmail.com>
 <CAJrReyhoC_crGMMdveMS7siV_qjYg3fQnKqX5fdEq1P-KWAdBQ@mail.gmail.com>
 <CAJ8B99z6RVov8xhSjTsRn2YYRvvL6qhz0R47MhOeOCVwu+mfzw@mail.gmail.com>
Message-ID: <CAJrReyiHCF+08oXmCn8v-_AeNUhDk1c5outDDvRW_nwSt2kFdw@mail.gmail.com>

I unfortunately don't have time to pare it down to a small example, but
fortunately I found that the latest HList on Hackage exhibits the same
approximate behavior.

When building the tests for HList-0.4.1.0, on 7.10.2 the module
`Properties.LengthDependentSplice` (
http://hackage.haskell.org/package/HList-0.4.1.0/src/examples/Properties/LengthDependentSplice.hs)
takes 2m30secs to compile. The same file takes ~50secs on 7.8.4.

Thanks!
-deech

On Wed, Sep 30, 2015 at 6:22 PM, David Kraeutmann <kane at kane.cx> wrote:

> Can you post a minimal example that exhibits the compile time increase?
>
> On Thu, Oct 1, 2015 at 12:25 AM, aditya siram <aditya.siram at gmail.com>
> wrote:
> > I'm not using any -O* flags and I'm not using Template Haskell. Not sure
> if
> > this means anything but I do have the context-stack set to 220.
> >
> > Thanks!
> > -deech
> >
> > On Wed, Sep 30, 2015 at 8:47 AM, Carter Schonwald
> > <carter.schonwald at gmail.com> wrote:
> >>
> >> Have you checked how changing the optimization level affects build
> times?
> >> Are you using template Haskell?
> >>
> >>
> >> On Tuesday, September 29, 2015, aditya siram <aditya.siram at gmail.com>
> >> wrote:
> >>>
> >>> Hi all,
> >>> Since upgrading to 7.10.2 from 7.8.4 I'm seeing a significant increase
> in
> >>> compilation time. I understand this is a known issue but since I'm
> seeing
> >>> something like a 3x slowdown but not across the board, I thought I'd
> ask.
> >>>
> >>> Compilation time for the library I'm writing has remained about the
> same.
> >>> I am seeing the slowdown when compiling executables that use the
> library.
> >>> There are no other dependencies except base so I'm guessing it
> something in
> >>> my library causing the issue.
> >>>
> >>> I lean heavily on the FFI, OverlappingInstances and HList style
> >>> programming in my library which leads me to believe that one of these
> is
> >>> causing it. I am seeing no difference in compilation speeds by adding
> the
> >>> per instance OVERLAPPING pragmas.
> >>>
> >>> Can anyone advise or instruct me on how to profile the compiler?
> >>>
> >>> Thanks!
> >>> -deech
> >>>
> >>>
> >
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151001/d4e76c59/attachment.html>

From svenpanne at gmail.com  Thu Oct  1 16:54:42 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Thu, 1 Oct 2015 18:54:42 +0200
Subject: [Haskell-cafe] Merging the OpenGLRaw and gl packages
In-Reply-To: <CAGRp5RmoNM7NR8sGoRBtpWJNdb1c8m0TfixkvyVA-sYPo4x8Lw@mail.gmail.com>
References: <CANBN=msHkd14O2PAsCGoXE=SAWhe8Zzisho3FeiC1P6Y7OFJ-w@mail.gmail.com>
 <CANBN=msTe-=fB6p89-4+iBQ3vj_8GY-o-j1Ee9iH2-DGTc_itg@mail.gmail.com>
 <CAJ5riwL1xJeTaxueoV6bbH+t6fY04B2kPFyzbUG4c3iLApzrAA@mail.gmail.com>
 <CANBN=mt-tWyE=t1gJ9_G2sZZH9KSJ58hRTeJpgW5knDFMLCsJg@mail.gmail.com>
 <CAGRp5RmoNM7NR8sGoRBtpWJNdb1c8m0TfixkvyVA-sYPo4x8Lw@mail.gmail.com>
Message-ID: <CANBN=mtnUgU-Kdec54mC02=UBBsgh_si+3mSMUVfZpGhGy70kA@mail.gmail.com>

2015-10-01 11:01 GMT+02:00 Oliver Charles <ollie at ocharles.org.uk>:

> [...] However, it's a lot more significant if you want to do something
> like:
>
> foo x = doSomething (case x of ...)
>
> Without pattern synonyms, you either have
>
> foo x = doSomething x'
>   where x' | x == ... = ...
>
> or
>
> {-# LANGUAGE MultiWayIf #-}
>
> foo x = doSomething (if | x == ... -> ...)
>

Or simply in plain old Haskell (basically the desugaring of the
multi-way-if):

   foo x = doSomething (case () of
                                     _ | x == gl_BAR -> expr1
                                        | x == gl_BAZ -> expr2
                                        | otherwise -> expr3)

Compared to:

   foo x = doSomething (case x of
                                      GL_BAR -> expr1
                                      GL_BAZ -> expr2
                                      _ .> expr3)

it doesn't really look *that* much different IMHO, given the high price one
has to pay for a tiny improvement in readability. But that's my personal,
more conservative view of things, and I'm here to see what other people
prefer.Alas, up to now, this is not very conclusive... :-/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151001/edb168c9/attachment.html>

From defigueiredo at ucdavis.edu  Thu Oct  1 19:04:53 2015
From: defigueiredo at ucdavis.edu (Dimitri DeFigueiredo)
Date: Thu, 1 Oct 2015 13:04:53 -0600
Subject: [Haskell-cafe] Could we make Haskell Modules "location independent"?
In-Reply-To: <etPan.560cbf25.5ae7ef75.fe@mbp.local>
References: <etPan.560cbf25.5ae7ef75.fe@mbp.local>
Message-ID: <560D83D5.2000105@ucdavis.edu>

Haskell is a fantastic language for refactoring, but I find the module 
system gets in the way when I need to reorganize my files or am trying 
to use git submodules.

My problem is that each module needs to "know where it is" relative to 
the global source paths in the cabal file.

For example, if you have an import statement like
```
module Main where

import SomeDirectory.SomeModule
```

the file SomeModule.hs must "know" that it is in a subdirectory as it is 
called because its name must have the "SomeDirectory" path as a prefix:

module SomeDirectory.SomeModule where ...

this would not work

module SomeModule where ...

To avoid having to add the SomeDirectory prefix, I end up putting *all* 
directories in the .cabal file.

Question: Why does GHC require an exact match between the modulename and 
the complete path? Is there a way to relax this?

Thanks,

Dimitri


From martin.drautzburg at web.de  Fri Oct  2 07:23:25 2015
From: martin.drautzburg at web.de (martin)
Date: Fri, 2 Oct 2015 09:23:25 +0200
Subject: [Haskell-cafe] Concept for "equal but unknown"
Message-ID: <560E30ED.2000503@web.de>

Hello all,

there is a problem which popped up a number of times recently and I wondered if there is a general concept to tackle
this kind of problems. It goes like this:

I book a hotel room. At this time it becomes known that the hotel has one fewer room available, but it is not known
which room it is. Likewise I know, that I have a reservation for "a room", but I don't know which one it is. It is
however known, that the room in my reservation is the same room the hotel has removed from the list of available rooms.

Another example: In air-cargo the cargo company has reserverd space in an aircraft for two containers. One for
high-priority parcels and one for low-priority parcels. In the cargo hub, they plan to pack these two containers. At
this point in time it is only known that there will be two containers one labelled "high-prio" and the other labelled
"low-prio" but their physical identity is not known. Only when you actually do the packing you have a physical container
at hand, which has identity. At this moment it becomes clear to which physical containers the reservations refer to and
which physical containers are used for packing.

I think I can handle this in an imparative style using an extra indirection (think pointers), though even there I would
be happy if someone told me something like "this is an example of covariant unification" or something like this. But in
haskell I cannot see a solution at all?

So:

how can I express that two things are equal to each other without knowing the exact value and

how do I manage to make both assume a value once one of them becomes known.

Do these kind of problems have a name?

From alan.zimm at gmail.com  Fri Oct  2 13:00:51 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Fri, 2 Oct 2015 15:00:51 +0200
Subject: [Haskell-cafe] Haskell Tooling Infrastructure
In-Reply-To: <CANma=H9rtdUJf38z9ygouPnv=OWbpaqhYtXmKM86p_wTKtGx0g@mail.gmail.com>
References: <CANma=H9rtdUJf38z9ygouPnv=OWbpaqhYtXmKM86p_wTKtGx0g@mail.gmail.com>
Message-ID: <CANma=H9tJWtc5yA35ToLnbt-wR+CpdJ6KF5b3_CXjiNmetxsXw@mail.gmail.com>

As a follow-up to this[1], I have written a post[2] detailing how ghc-mod
provides the downwards (BIOS) functions for the next version of HaRe[3].

[1]
https://github.com/RefactoringTools/HaRe/wiki/Requirements-for-IDE-GHC-interfacing
[2]
http://alanz.github.io/haskell%20refactorer/2015/10/02/ghc-mod-for-tooling/
[3] https://github.com/alanz/HaRe/tree/wip

Alan

On Sun, Jun 7, 2015 at 2:02 PM, Alan & Kim Zimmerman <alan.zimm at gmail.com>
wrote:

> Now that I am finally turning back to HaRe, the question of infrastructure
> again comes up.
>
> Basically I woudl like to focus in the tool itself, but it can only be
> useful if it can deal with real world environments.
>
> This means properly managing all the different project and compiler
> environments, and being integrated into IDEs.
>
> The current version uses ghc-mod for the lower level interface, and a
> simple command line interface for the IDE integration.
>
> But I have a definite sense that as a community every tool maker is
> solving the same problems over and over, from ghc-mod to ide-backend to
> ghci-ng, and onwards.
>
> To start a discussion around some kind of architeccture that tool writers
> can develop agains, ide's can integrat against and ghc/cabal can eventually
> internalise, I have put some basic points down at
>
>
> https://github.com/RefactoringTools/HaRe/wiki/Requirements-for-IDE-GHC-interfacing
>
> Regards
>   Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151002/faad6314/attachment.html>

From efasckenoth at gmail.com  Fri Oct  2 14:02:57 2015
From: efasckenoth at gmail.com (Stefan =?iso-8859-1?Q?H=F6ck?=)
Date: Fri, 2 Oct 2015 16:02:57 +0200
Subject: [Haskell-cafe] Concept for "equal but unknown"
In-Reply-To: <560E30ED.2000503@web.de>
References: <560E30ED.2000503@web.de>
Message-ID: <20151002140257.GA1136@hunter.iway.ch>

> how can I express that two things are equal to each other without knowing the exact value and
> 
> how do I manage to make both assume a value once one of them becomes known.

I'm sure there are fancier ways to express such things, but you could
use a placeholder (an Integer for instance, wrapped in a newtype)
for the room reservation, together with a Map from Integer to Room to look
up the room assigned to each reservation. As long as no room is assigned
to a reservation number, a lookup in the map yields Nothing. Once a room
is assigned, a lookup yields the room. All this should probably be
wrapped up in the State Monad (the Map with the reservations being
the state), so you don't have to carry around the Map explicitly.

Hope this is helps.

From mihai.maruseac at gmail.com  Fri Oct  2 14:11:42 2015
From: mihai.maruseac at gmail.com (Mihai Maruseac)
Date: Fri, 2 Oct 2015 10:11:42 -0400
Subject: [Haskell-cafe] Call for Contributions - Haskell Communities and
 Activities Report, November 2015 edition (29th edition)
Message-ID: <CAOMsUM+XU-8fuHZbzDrJXVMWSdyTyt+ktXfkUVree_VLLGMAFQ@mail.gmail.com>

Dear all,

We would like to collect contributions for the 28th edition of the

============================================================
             Haskell Communities & Activities Report

http://www.haskell.org/haskellwiki/Haskell_Communities_and_Activities_Report

                Submission deadline: 30 October 2015

     (please send your contributions to hcar at haskell.org,
                 in plain text or LaTeX format, both are equally accepted)
============================================================

This is the short story:

* If you are working on any project that is in some way related
  to Haskell, please write a short entry and submit it. Even if
  the project is very small or unfinished or you think it is not
  important enough --- please reconsider and submit an entry anyway!

* If you are interested in an existing project related to Haskell that
  has not previously been mentioned in the HCAR, please tell us, so
  that we can contact the project leaders and ask them to submit an
  entry.

* If you are working on a project that is looking for contributors,
  please write a short entry and submit it, mentioning that your are looking
  for contributors. The final report might have an index with such projects,
  provided we get enough such submissions.

* Feel free to pass on this call for contributions to others that
  might be interested.

More detailed information:

The Haskell Communities & Activities Report is a bi-annual overview of
the state of Haskell as well as Haskell-related projects over the
last, and possibly the upcoming six months. If you have only recently
been exposed to Haskell, it might be a good idea to browse the
previous edition --- you will find interesting projects described as
well as several starting points and links that may provide answers to
many questions.

Contributions will be collected until the submission deadline. They
will then be compiled into a coherent report that is published online
as soon as it is ready. As always, this is a great opportunity to
update your webpages, make new releases, announce or even start new
projects, or to talk about developments you want every Haskeller to
know about!

Looking forward to your contributions,

Mihai Maruseac and Alejandro Serrano Mena


FAQ:

Q: What format should I write in?

A: The usual format is a LaTeX source file, adhering to the template
that is available at:

     http://haskell.org/communities/05-2015/template.tex

There is also a LaTeX style file at

     http://haskell.org/communities/05-2015/hcar.sty

that you can use to preview your entry. If you do not know LaTeX, then
use plain text. If you modify an old entry that you have written for an
earlier edition of the report, you should soon receive your old entry as
a template (provided we have your valid email address). Please modify
that template, rather than using your own version of the old entry as a
template.

_However_, if you don't want/have time to format the entry for LaTeX,
you can submit it in any other format possible and we will be happy to
convert it for the final report.

Q: Can I include Haskell code?

A: Yes. Please use lhs2tex syntax (http://www.andres-loeh.de/lhs2tex/).
The report is compiled in mode polycode.fmt.

Q: Can I include images?

A: Yes, you are even encouraged to do so. Please use .jpg or .png
format, then, PNG being preferred for simplicity.

Q: Should I send files in .zip archives or similar?

A: No, plain file attachements are the way.

Q: How much should I write?

A: Authors are asked to limit entries to about one column of text. A
general introduction is helpful. Apart from that, you should focus on
recent or upcoming developments. Pointers to online content can be given
for more comprehensive or "historic" overviews of a project. Images do
not count towards the length limit, so you may want to use this
opportunity to pep up entries. There is no minimum length of an entry!
The report aims for being as complete as possible, so please consider
writing an entry, even if it is only a few lines long.

Q: Which topics are relevant?

A: All topics which are related to Haskell in some way are relevant. We
usually had reports from users of Haskell (private, academic, or
commercial), from authors or contributors to projects related to
Haskell, from people working on the Haskell language, libraries, on
language extensions or variants. We also like reports about
distributions of Haskell software, Haskell infrastructure, books and
tutorials on Haskell. Reports on past and upcoming events related to
Haskell are also relevant. Finally, there might be new topics we do not
even think about. As a rule of thumb: if in doubt, then it probably is
relevant and has a place in the HCAR. You can also simply ask us.

Q: Is unfinished work relevant? Are ideas for projects relevant?

A: Yes! You can use the HCAR to talk about projects you are currently
working on. You can use it to look for other developers that might help
you. You can use HCAR to ask for more contributors to your project,
it is a good way to gain visibility and traction.

Q: If I do not update my entry, but want to keep it in the report, what
should I do?

A: Tell us that there are no changes. The old entry will typically be
reused in this case, but it might be dropped if it is older than a year,
to give more room and more attention to projects that change a lot. Do
not resend complete entries if you have not changed them.

Q: Will I get confirmation if I send an entry? How do I know whether my
email has even reached its destination, and not ended up in a spam folder?

A: Prior to publication of the final report, we will send a draft to all
contributors, for possible corrections. So if you do not hear from us
within two weeks after the deadline, it is safer to send another mail
and check whether your first one was received.

-- 
Mihai Maruseac (MM)
"If you can't solve a problem, then there's an easier problem you can
solve: find it." -- George Polya

From martin.drautzburg at web.de  Fri Oct  2 14:37:16 2015
From: martin.drautzburg at web.de (martin)
Date: Fri, 2 Oct 2015 16:37:16 +0200
Subject: [Haskell-cafe] Concept for "equal but unknown"
In-Reply-To: <20151002140257.GA1136@hunter.iway.ch>
References: <560E30ED.2000503@web.de> <20151002140257.GA1136@hunter.iway.ch>
Message-ID: <560E969C.4020302@web.de>

Am 10/02/2015 um 04:02 PM schrieb Stefan H?ck:
>> how can I express that two things are equal to each other without knowing the exact value and
>>
>> how do I manage to make both assume a value once one of them becomes known.
> 
> I'm sure there are fancier ways to express such things, but you could
> use a placeholder (an Integer for instance, wrapped in a newtype)
> for the room reservation, together with a Map from Integer to Room to look
> up the room assigned to each reservation. As long as no room is assigned
> to a reservation number, a lookup in the map yields Nothing. Once a room
> is assigned, a lookup yields the room. All this should probably be
> wrapped up in the State Monad (the Map with the reservations being
> the state), so you don't have to carry around the Map explicitly.

Yes, this is what I would have done in imperative code and from your suggestion I understand that in haskell I'll have
to carry that map around. So far so good.

Here is another thought:

In math it is terribly easy to express what I am after a simple "x=y" states that x and y are equal, but unknown. As
soon as I add x=25, there is no more choice on the value of y.

I guess I am after values which become more and more defined in the course of computation.


From marcin.jan.mrotek at gmail.com  Fri Oct  2 14:45:58 2015
From: marcin.jan.mrotek at gmail.com (Marcin Mrotek)
Date: Fri, 2 Oct 2015 16:45:58 +0200
Subject: [Haskell-cafe] Concept for "equal but unknown"
In-Reply-To: <560E969C.4020302@web.de>
References: <560E30ED.2000503@web.de> <20151002140257.GA1136@hunter.iway.ch>
 <560E969C.4020302@web.de>
Message-ID: <CAJcfPzm1UALBs0hSuzC8_6uJoD4rBGyRPJRQed0xuFNYaeunig@mail.gmail.com>

Hello,

Do you mean something like variable unification in Prolog or Oz? Maybe
something like this could help you:
https://hackage.haskell.org/package/monad-unify-0.2.2/docs/Control-Monad-Unify.html
or https://hackage.haskell.org/package/unification-fd Disclaimer: I've
never used either of those packages.

Best regards,
Marcin Mrotek

From olf at aatal-apotheke.de  Fri Oct  2 15:36:50 2015
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Fri, 2 Oct 2015 17:36:50 +0200
Subject: [Haskell-cafe] Concept for "equal but unknown"
Message-ID: <F916A3B6-CB40-4186-BA1C-2DA7118B5CA4@aatal-apotheke.de>

To me this sounds like the Reader monad: You have a value that depends on something that is yet to be decided upon. 

data SomeCargo = SomeCargo {
  decide_attribute1 :: ContainerID -> Attr1
  decide_attribute2 :: ContainerID -> Attr2
  ...
}

data ConcreteCargo = ConcreteCargo {
  attribute1 :: Attr1
  attribute2 :: Attr2
}

withID :: SomeCargo -> ContainerID -> ConcreteCargo

If the type ContainerID is searchable [1] then you can have an Eq instance even for the SomeCargo type. That is, two containers are equal if whenever the same ID gets assigned, they have the same properties. The technical term would be "indistinguishable in all contexts". 


-- Olaf

[1] http://math.andrej.com/2008/11/21/a-haskell-monad-for-infinite-search-in-finite-time/

From adam at bergmark.nl  Fri Oct  2 15:55:50 2015
From: adam at bergmark.nl (Adam Bergmark)
Date: Fri, 2 Oct 2015 17:55:50 +0200
Subject: [Haskell-cafe] [PATCH] Interpret missing link relation in Atom
	as "alternate"
In-Reply-To: <1443543161-21716-1-git-send-email-fr33domlover@riseup.net>
References: <CACnqJZbLeqVk1BrKvTxbZUxXockgz8fyNU1f0WH1BFAwnLpJnA@mail.gmail.com>
 <1443543161-21716-1-git-send-email-fr33domlover@riseup.net>
Message-ID: <CACnqJZbFMioXEhqAmxHCKLtpZsQUTW10CQR1sXH8Z5xD4eJzgw@mail.gmail.com>

D?ne! http://hackage.haskell.org/package/feed-0.3.10.2

Thank you,
Adam



On Tue, Sep 29, 2015 at 6:12 PM, <fr33domlover at riseup.net> wrote:

> From: fr33domlover <fr33domlover at riseup.net>
>
> The Atom RFC says that when a link element doesn't
> specify the "rel" attribute, i.e. link relation, it
> should be interpreted as an "alternate" relation.
> This commit makes the feed and item query functions
> treat a missing relation as "alternate".
> ---
>  feed.cabal               |    5 +-
>  src/Text/Feed/Query.hs   |   11 +-
>  tests/Main.hs            |    9 +-
>  tests/Text/Atom/Tests.hs |   39 +
>  tests/files/atom.xml     | 6733
> ++++++++++++++++++++++++++++++++++++++++++++++
>  5 files changed, 6789 insertions(+), 8 deletions(-)
>  create mode 100644 tests/Text/Atom/Tests.hs
>  create mode 100644 tests/files/atom.xml
>
> diff --git a/feed.cabal b/feed.cabal
> index b22dfed..8c04444 100644
> --- a/feed.cabal
> +++ b/feed.cabal
> @@ -17,7 +17,9 @@ homepage:            https://github.com/bergmark/feed
>  bug-reports:         https://github.com/bergmark/feed/issues
>  cabal-version:       >= 1.8
>  build-type:          Simple
> -data-files:          tests/files/rss20.xml
> +data-files:
> +  tests/files/rss20.xml
> +  tests/files/atom.xml
>  extra-source-files:
>    README.md
>    CHANGELOG.md
> @@ -68,6 +70,7 @@ test-suite tests
>    main-is:           Main.hs
>    type:              exitcode-stdio-1.0
>    other-modules:
> +    Text.Atom.Tests
>      Text.RSS.Equals
>      Text.RSS.Export.Tests
>      Text.RSS.Import.Tests
> diff --git a/src/Text/Feed/Query.hs b/src/Text/Feed/Query.hs
> index 970d17b..0a599c7 100644
> --- a/src/Text/Feed/Query.hs
> +++ b/src/Text/Feed/Query.hs
> @@ -129,7 +129,9 @@ getFeedHTML ft =
>          Just e1 -> fmap XML.strContent $ findElement (unqual "link") e1
>          Nothing -> Nothing
>   where
> -  isSelf lr = toStr (Atom.linkRel lr) == "alternate" && isHTMLType
> (linkType lr)
> +  isSelf lr =
> +    let rel = Atom.linkRel lr
> +    in  (isNothing rel || toStr rel == "alternate") && isHTMLType
> (linkType lr)
>
>    isHTMLType (Just str) = "lmth" `isPrefixOf` (reverse str)
>    isHTMLType _ = True -- if none given, assume html.
> @@ -243,13 +245,16 @@ getItemTitle it =
>  getItemLink :: ItemGetter String
>  getItemLink it =
>    case it of
> -       -- look up the 'alternate' HTML link relation on the entry:
> +       -- look up the 'alternate' HTML link relation on the entry, or one
> +       -- without link relation since that is equivalent to 'alternate':
>      Feed.AtomItem i -> fmap Atom.linkHref $ listToMaybe $ filter isSelf $
> Atom.entryLinks i
>      Feed.RSSItem i  -> RSS.rssItemLink i
>      Feed.RSS1Item i -> Just (RSS1.itemLink i)
>      Feed.XMLItem i  -> fmap (\ ei -> XML.strContent ei) $ findElement
> (unqual "link") i
>   where
> -  isSelf lr = toStr (Atom.linkRel lr) == "alternate" && isHTMLType
> (linkType lr)
> +  isSelf lr =
> +    let rel = Atom.linkRel lr
> +    in  (isNothing rel || toStr rel == "alternate") && isHTMLType
> (linkType lr)
>
>    isHTMLType (Just str) = "lmth" `isPrefixOf` (reverse str)
>    isHTMLType _ = True -- if none given, assume html.
> diff --git a/tests/Main.hs b/tests/Main.hs
> index 6aa492a..e55e42f 100644
> --- a/tests/Main.hs
> +++ b/tests/Main.hs
> @@ -2,9 +2,10 @@ module Main (main) where
>
>  import Test.Framework (defaultMain)
>  import Text.RSS.Tests (rssTests)
> -
> +import Text.Atom.Tests (atomTests)
>
>  main :: IO ()
> -main = defaultMain [
> -    rssTests
> -    ]
> +main = defaultMain
> +  [ rssTests
> +  , atomTests
> +  ]
> diff --git a/tests/Text/Atom/Tests.hs b/tests/Text/Atom/Tests.hs
> new file mode 100644
> index 0000000..96a8dae
> --- /dev/null
> +++ b/tests/Text/Atom/Tests.hs
> @@ -0,0 +1,39 @@
> +module Text.Atom.Tests where
> +
> +import Data.Maybe (isJust)
> +import Test.Framework (Test, mutuallyExclusive, testGroup)
> +import Test.HUnit (Assertion, assertBool)
> +import Test.Framework.Providers.HUnit (testCase)
> +import Text.Atom.Feed
> +import Text.Feed.Export
> +import Text.Feed.Import
> +import Text.Feed.Query
> +import Text.Feed.Types
> +import Text.XML.Light
> +
> +import Paths_feed
> +
> +atomTests :: Test
> +atomTests = testGroup "Text.Atom"
> +    [ mutuallyExclusive $ testGroup "Atom"
> +        [ testFullAtomParse
> +        , testAtomAlternate
> +        ]
> +    ]
> +
> +testFullAtomParse :: Test
> +testFullAtomParse = testCase "parse a complete atom file" testAtom
> +  where
> +    testAtom :: Assertion
> +    testAtom = do
> +      putStrLn . ppTopElement . xmlFeed =<< parseFeedFromFile =<<
> getDataFileName "tests/files/atom.xml"
> +      assertBool "OK" True
> +
> +testAtomAlternate :: Test
> +testAtomAlternate = testCase "*unspecified* link relation means
> 'alternate'" testAlt
> +  where
> +    testAlt :: Assertion
> +    testAlt =
> +      let nullent = nullEntry "" (TextString "") ""
> +          item = AtomItem nullent { entryLinks = [nullLink ""] }
> +      in  assertBool "unspecified means alternate" $ isJust $ getItemLink
> item
> diff --git a/tests/files/atom.xml b/tests/files/atom.xml
> new file mode 100644
> index 0000000..c58181b
> --- /dev/null
> +++ b/tests/files/atom.xml
> @@ -0,0 +1,6733 @@
> +<?xml version="1.0" encoding="utf-8"?>
> +
> +<feed xmlns="http://www.w3.org/2005/Atom">
> +<title>RecentChanges</title>
> +<link href="http://www.rel4tion.org/recentchanges/"/>
> +<link href="http://www.rel4tion.org/recentchanges/index.atom" rel="self"
> type="application/atom+xml"/>
> +<author>
> +
> +<name>Rel4tion</name>
> +
> +</author>
> +
> +
> +
> +
> +<id>http://www.rel4tion.org/recentchanges/</id>
> +
> +<subtitle type="html">Rel4tion</subtitle>
> +<generator uri="http://ikiwiki.info/">ikiwiki</generator>
> +<updated>2015-09-27T20:04:22Z</updated>
> +<entry>
> +       <title>change to people/fr33domlover on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_c989bafb33d2bdcd8f01b408f63b7981e62110a9/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-c989bafb33d2bdcd8f01b408f63b7981e62110a9
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-09-27T20:04:22Z</updated>
> +       <published>2015-09-27T20:04:22Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-c989bafb33d2bdcd8f01b408f63b7981e62110a9&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=people/fr33domlover.mdwn;h=70e87c497caca5f004d5434a7d6e52b48c01d4f3;hp=2230d818ac803844191d7842bcb24fa4d5e45e14;hb=c989bafb33d2bdcd8f01b408f63b7981e62110a9;hpb=44148b1572c22c8d979bd90a75f82dbe444530df&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;people/fr33domlover&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;08:04:22 PM 09/27/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=c989bafb33d2bdcd8f01b408f63b7981e62110a9&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +me: update paragraph about the open tickets list&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_44148b1572c22c8d979bd90a75f82dbe444530df/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-44148b1572c22c8d979bd90a75f82dbe444530df
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-09-27T19:58:19Z</updated>
> +       <published>2015-09-27T19:58:19Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-44148b1572c22c8d979bd90a75f82dbe444530df&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot.mdwn;h=ff14943d3018d85e80703df32c9ca2c65c13c83a;hp=d75dd79bb2e9c594f78de4f5897ea7e60d554433;hb=44148b1572c22c8d979bd90a75f82dbe444530df;hpb=1c5f47be50411f5bbcf5b2373d20f6095aeb078f&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;07:58:19 PM 09/27/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=44148b1572c22c8d979bd90a75f82dbe444530df&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: mention the helper packages&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to access/paste on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_1c5f47be50411f5bbcf5b2373d20f6095aeb078f/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-1c5f47be50411f5bbcf5b2373d20f6095aeb078f
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-09-21T17:04:36Z</updated>
> +       <published>2015-09-21T17:04:36Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-1c5f47be50411f5bbcf5b2373d20f6095aeb078f&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=access/paste.mdwn;h=118bdeb612c6b61cf5b59c8bd5b8ea7072a61ae8;hp=978504f51469a8aa3ad45c5d55be22ba0503e4ef;hb=1c5f47be50411f5bbcf5b2373d20f6095aeb078f;hpb=681de3e0ea89f8597ea39766be861e70f947793f&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=access%2Fpaste&quot;
> rel=&quot;nofollow&quot;&gt;access/paste&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;05:04:36 PM 09/21/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=1c5f47be50411f5bbcf5b2373d20f6095aeb078f&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +access: update URL of paste server code&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/guide on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_681de3e0ea89f8597ea39766be861e70f947793f/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-681de3e0ea89f8597ea39766be861e70f947793f
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-09-18T21:39:54Z</updated>
> +       <published>2015-09-18T21:39:54Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-681de3e0ea89f8597ea39766be861e70f947793f&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/guide.mdwn;h=80ec023c5699abad621d01b1818d39db78ccaed0;hp=da0633c981be6cf4f16c67dea4bf1cba63d2f827;hb=681de3e0ea89f8597ea39766be861e70f947793f;hpb=1e55bf1839b514e0524a294fa62ce0eed46ad3e1&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Fguide&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/guide&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;09:39:54 PM 09/18/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=681de3e0ea89f8597ea39766be861e70f947793f&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: mention new dependency, funbot-ext-events&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_1e55bf1839b514e0524a294fa62ce0eed46ad3e1/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-1e55bf1839b514e0524a294fa62ce0eed46ad3e1
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-09-17T19:44:49Z</updated>
> +       <published>2015-09-17T19:44:49Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-1e55bf1839b514e0524a294fa62ce0eed46ad3e1&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot.mdwn;h=d75dd79bb2e9c594f78de4f5897ea7e60d554433;hp=f563f5208d711e1946624f45b58eb19e1c8fd688;hb=1e55bf1839b514e0524a294fa62ce0eed46ad3e1;hpb=9abd0dcfc30145da75cd2b246eac79fdd250a57f&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;07:44:49 PM 09/17/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=1e55bf1839b514e0524a294fa62ce0eed46ad3e1&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: remove dummy text&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_9abd0dcfc30145da75cd2b246eac79fdd250a57f/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-9abd0dcfc30145da75cd2b246eac79fdd250a57f
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-09-17T19:43:38Z</updated>
> +       <published>2015-09-17T19:43:38Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-9abd0dcfc30145da75cd2b246eac79fdd250a57f&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot.mdwn;h=f563f5208d711e1946624f45b58eb19e1c8fd688;hp=4648b803378bdbf71232640adf24429bf1e0bf59;hb=9abd0dcfc30145da75cd2b246eac79fdd250a57f;hpb=8b70f13be1209a55b3d31122cba2a8a8a31539ab&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;07:43:38 PM 09/17/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=9abd0dcfc30145da75cd2b246eac79fdd250a57f&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: minor update and some dummy test text&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to shortcuts on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_8b70f13be1209a55b3d31122cba2a8a8a31539ab/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-8b70f13be1209a55b3d31122cba2a8a8a31539ab
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-09-17T19:22:22Z</updated>
> +       <published>2015-09-17T19:22:22Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-8b70f13be1209a55b3d31122cba2a8a8a31539ab&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=shortcuts.mdwn;h=96adf1fbd8cb6601d15184bd5ec1854e262c003b;hp=848c9edfe10d412737a37883ff955dbee20089cb;hb=8b70f13be1209a55b3d31122cba2a8a8a31539ab;hpb=4811a57e33da708175ddd6d016e78bd410f4d1ea&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=shortcuts&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;shortcuts&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;07:22:22 PM 09/17/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=8b70f13be1209a55b3d31122cba2a8a8a31539ab&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +fix notabug shortcut, it shouldn&amp;#39;t url-encode&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/tickets/5 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_4811a57e33da708175ddd6d016e78bd410f4d1ea/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-4811a57e33da708175ddd6d016e78bd410f4d1ea
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-09-17T13:28:45Z</updated>
> +       <published>2015-09-17T13:28:45Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-4811a57e33da708175ddd6d016e78bd410f4d1ea&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/5.mdwn;h=f3c6b11312ebf91ef89c077beb98b475f5f7760c;hp=993dac4b04ed6e9cfc0796f09a90ee568106b193;hb=4811a57e33da708175ddd6d016e78bd410f4d1ea;hpb=07e5d7d13fc364c06ed1bda3f21fa6a493276859&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F5&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/5&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;01:28:45 PM 09/17/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=4811a57e33da708175ddd6d016e78bd410f4d1ea&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: close memo ticket&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/tickets/2 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_07e5d7d13fc364c06ed1bda3f21fa6a493276859/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-07e5d7d13fc364c06ed1bda3f21fa6a493276859
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-09-17T13:22:05Z</updated>
> +       <published>2015-09-17T13:22:05Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-07e5d7d13fc364c06ed1bda3f21fa6a493276859&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/2.mdwn;h=58c609b1cc1ffb88ad01aa39806bb43d166f67f9;hp=2cc56bb7968465ca690ebcbed6ed5a5213fb8a0c;hb=07e5d7d13fc364c06ed1bda3f21fa6a493276859;hpb=5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F2&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/2&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;01:22:05 PM 09/17/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=07e5d7d13fc364c06ed1bda3f21fa6a493276859&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: close persistence ticket, we have json-state now&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects projects/json-state
> projects/json-state/decisions projects/json-state/forum
> projects/json-state/news projects/json-state/releases
> projects/json-state/tickets on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-09-17T13:01:04Z</updated>
> +       <published>2015-09-17T13:01:04Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects.mdwn;h=345421854fa54c60f59686d3908fe58dd4789069;hp=10ae06877f9882b6bd6f3bb1c5b9dd3c7ab032c1;hb=5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe;hpb=8271123effea28344517c121ee596eb7217e28e2&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/json-state.mdwn;h=41137012211445b4f3f48fc8e1c036ababdab2b9;hp=0000000000000000000000000000000000000000;hb=5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe;hpb=8271123effea28344517c121ee596eb7217e28e2&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fjson-state&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/json-state&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/json-state/decisions.mdwn;h=87e40f15dec6533bbeebf666fa4d2761c0d5adad;hp=0000000000000000000000000000000000000000;hb=5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe;hpb=8271123effea28344517c121ee596eb7217e28e2&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fjson-state%2Fdecisions&quot;
> rel=&quot;nofollow&quot;&gt;projects/json-state/decisions&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/json-state/forum.mdwn;h=cdc6c618a5af5e908dc00cabeed27a4f4d5c9125;hp=0000000000000000000000000000000000000000;hb=5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe;hpb=8271123effea28344517c121ee596eb7217e28e2&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fjson-state%2Fforum&quot;
> rel=&quot;nofollow&quot;&gt;projects/json-state/forum&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/json-state/news.mdwn;h=c463308444ec8f91a1bfae7dfda2e5fe3d183863;hp=0000000000000000000000000000000000000000;hb=5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe;hpb=8271123effea28344517c121ee596eb7217e28e2&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fjson-state%2Fnews&quot;
> rel=&quot;nofollow&quot;&gt;projects/json-state/news&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/json-state/releases.mdwn;h=e4dcf00f9501d98e461c4a6ccd75818cc54b71fc;hp=0000000000000000000000000000000000000000;hb=5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe;hpb=8271123effea28344517c121ee596eb7217e28e2&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fjson-state%2Freleases&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/json-state/releases&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/json-state/tickets.mdwn;h=df2d37627427fe3d89829ad503c725de72c7d762;hp=0000000000000000000000000000000000000000;hb=5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe;hpb=8271123effea28344517c121ee596eb7217e28e2&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fjson-state%2Ftickets&quot;
> rel=&quot;nofollow&quot;&gt;projects/json-state/tickets&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;01:01:04 PM 09/17/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +json-state: new project&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/settings projects/settings/releases on
> Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_8271123effea28344517c121ee596eb7217e28e2/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-8271123effea28344517c121ee596eb7217e28e2
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-09-17T12:59:24Z</updated>
> +       <published>2015-09-17T12:59:24Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-8271123effea28344517c121ee596eb7217e28e2&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings.mdwn;h=be444e1b1ee23712cdb25e2d3fa155319dd04b38;hp=b7f5ffc7ee35f85a7a7d5094fdc02c578122825e;hb=8271123effea28344517c121ee596eb7217e28e2;hpb=9bd1e350a4f81d79b820eb5a1ab3e644a280399a&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fsettings&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/settings&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/releases.mdwn;h=4c6c784b8ea0ca05ff9fd5232a2a195159aa4cae;hp=e4efd9b315242da6e04f9e94546ed3522bdaac68;hb=8271123effea28344517c121ee596eb7217e28e2;hpb=9bd1e350a4f81d79b820eb5a1ab3e644a280399a&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fsettings%2Freleases&quot;
> rel=&quot;nofollow&quot;&gt;projects/settings/releases&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;12:59:24 PM 09/17/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=8271123effea28344517c121ee596eb7217e28e2&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +settings: update repo link&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/tickets/15 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_9bd1e350a4f81d79b820eb5a1ab3e644a280399a/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-9bd1e350a4f81d79b820eb5a1ab3e644a280399a
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-09-17T11:51:13Z</updated>
> +       <published>2015-09-17T11:51:13Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-9bd1e350a4f81d79b820eb5a1ab3e644a280399a&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/15.mdwn;h=a6aef60136eb5939cd49fe3dff12a23214f96914;hp=37a1b5e2695ce312b8f1b8e37078dd4cdbc90898;hb=9bd1e350a4f81d79b820eb5a1ab3e644a280399a;hpb=edabc8116457185ce07d1f61737fa2ce8518bd4b&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F15&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/15&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;11:51:13 AM 09/17/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=9bd1e350a4f81d79b820eb5a1ab3e644a280399a&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: settings system is finally complete&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/manual on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_edabc8116457185ce07d1f61737fa2ce8518bd4b/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-edabc8116457185ce07d1f61737fa2ce8518bd4b
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-09-16T19:04:22Z</updated>
> +       <published>2015-09-16T19:04:22Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-edabc8116457185ce07d1f61737fa2ce8518bd4b&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/manual.mdwn;h=d098b5370a8cbf0e60f80e37f23276dda4f2afd1;hp=56ff43060cd3eecca2eb10237bc7303d1ecc8652;hb=edabc8116457185ce07d1f61737fa2ce8518bd4b;hpb=37ec11668e6a6a9418209c5411508d018592519d&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Fmanual&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/manual&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;07:04:22 PM 09/16/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=edabc8116457185ce07d1f61737fa2ce8518bd4b&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: update manual with recent changes&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to people/fr33domlover/blog/love-of-wisdom on
> Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_37ec11668e6a6a9418209c5411508d018592519d/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-37ec11668e6a6a9418209c5411508d018592519d
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-09-12T13:12:06Z</updated>
> +       <published>2015-09-12T13:12:06Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-37ec11668e6a6a9418209c5411508d018592519d&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=people/fr33domlover/blog/love-of-wisdom.mdwn;h=a9bfd88c473fc20270af0a83570f8a4b70d12691;hp=0000000000000000000000000000000000000000;hb=37ec11668e6a6a9418209c5411508d018592519d;hpb=29d3a9e5554fb2ea6987f31f968578cc2647e8f3&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover%2Fblog%2Flove-of-wisdom&quot;
> rel=&quot;nofollow&quot;&gt;people/fr33domlover/blog/love-of-wisdom&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;01:12:06 PM 09/12/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=37ec11668e6a6a9418209c5411508d018592519d&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +me: another blog post...&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to news/break on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_29d3a9e5554fb2ea6987f31f968578cc2647e8f3/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-29d3a9e5554fb2ea6987f31f968578cc2647e8f3
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-09-10T22:01:02Z</updated>
> +       <published>2015-09-10T22:01:02Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-29d3a9e5554fb2ea6987f31f968578cc2647e8f3&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=news/break.mdwn;h=5eb7a858b10923cf2973d7b6004cb2c1783bea45;hp=0000000000000000000000000000000000000000;hb=29d3a9e5554fb2ea6987f31f968578cc2647e8f3;hpb=34a21b40a95051a6bee7f3c89223b868ebcb64ac&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=news%2Fbreak&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;news/break&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;10:01:02 PM 09/10/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=29d3a9e5554fb2ea6987f31f968578cc2647e8f3&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +news: break&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to index on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_34a21b40a95051a6bee7f3c89223b868ebcb64ac/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-34a21b40a95051a6bee7f3c89223b868ebcb64ac
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-09-10T21:50:12Z</updated>
> +       <published>2015-09-10T21:50:12Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-34a21b40a95051a6bee7f3c89223b868ebcb64ac&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=index.mdwn;h=c68cb36b6224504f98fe4811e08c49a1b07f2df0;hp=126fe28b2815f6a3d4a3095dd5e11485cebb8086;hb=34a21b40a95051a6bee7f3c89223b868ebcb64ac;hpb=ed2a95c268ef060d9dddae5a24b4672911491c72&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=index&quot;
> rel=&quot;nofollow&quot;&gt;index&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;09:50:12 PM 09/10/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=34a21b40a95051a6bee7f3c89223b868ebcb64ac&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +index: remove feedback box&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/manual on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_ed2a95c268ef060d9dddae5a24b4672911491c72/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-ed2a95c268ef060d9dddae5a24b4672911491c72
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-09-10T18:46:34Z</updated>
> +       <published>2015-09-10T18:46:34Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-ed2a95c268ef060d9dddae5a24b4672911491c72&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/manual.mdwn;h=56ff43060cd3eecca2eb10237bc7303d1ecc8652;hp=44c3d463280d7e275a6f93bd9633289f0872b686;hb=ed2a95c268ef060d9dddae5a24b4672911491c72;hpb=d3cdcea02b8dedede9d590ff8a730cac95a10c58&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Fmanual&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/manual&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;06:46:34 PM 09/10/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=ed2a95c268ef060d9dddae5a24b4672911491c72&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: revise manual&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/tickets/5 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_d3cdcea02b8dedede9d590ff8a730cac95a10c58/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-d3cdcea02b8dedede9d590ff8a730cac95a10c58
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-09-10T13:16:52Z</updated>
> +       <published>2015-09-10T13:16:52Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-d3cdcea02b8dedede9d590ff8a730cac95a10c58&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/5.mdwn;h=993dac4b04ed6e9cfc0796f09a90ee568106b193;hp=606f28657913248cbfe3204aa6f0ffebec656b55;hb=d3cdcea02b8dedede9d590ff8a730cac95a10c58;hpb=1a05dfe95cd5a544f09ef39d5187f6ecf75af3b2&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F5&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/5&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;01:16:52 PM 09/10/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=d3cdcea02b8dedede9d590ff8a730cac95a10c58&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: document work on memos&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/tickets/18 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_1a05dfe95cd5a544f09ef39d5187f6ecf75af3b2/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-1a05dfe95cd5a544f09ef39d5187f6ecf75af3b2
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-31T17:35:31Z</updated>
> +       <published>2015-08-31T17:35:31Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-1a05dfe95cd5a544f09ef39d5187f6ecf75af3b2&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/18.mdwn;h=92ddfe617ac1113a7b96d24857c5e783f55432aa;hp=d9fbdf7bd75e3ce0638d56f2bae98e47270b7baa;hb=1a05dfe95cd5a544f09ef39d5187f6ecf75af3b2;hpb=74c8029879813f445632d74c6b0233496729a757&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F18&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/18&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;05:35:31 PM 08/31/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=1a05dfe95cd5a544f09ef39d5187f6ecf75af3b2&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: document progress on friendly command access&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/tickets/18 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_74c8029879813f445632d74c6b0233496729a757/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-74c8029879813f445632d74c6b0233496729a757
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-30T16:31:13Z</updated>
> +       <published>2015-08-30T16:31:13Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-74c8029879813f445632d74c6b0233496729a757&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/18.mdwn;h=d9fbdf7bd75e3ce0638d56f2bae98e47270b7baa;hp=f717e312738110e9fa51874c4efa2b918dca6c43;hb=74c8029879813f445632d74c6b0233496729a757;hpb=2f15a1e3784ca2c076afb2654bb313723de8592e&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F18&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/18&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;04:31:13 PM 08/30/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=74c8029879813f445632d74c6b0233496729a757&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: plan API for friendly command access&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/guide on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_2f15a1e3784ca2c076afb2654bb313723de8592e/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-2f15a1e3784ca2c076afb2654bb313723de8592e
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-28T21:39:21Z</updated>
> +       <published>2015-08-28T21:39:21Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-2f15a1e3784ca2c076afb2654bb313723de8592e&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/guide.mdwn;h=da0633c981be6cf4f16c67dea4bf1cba63d2f827;hp=bb59f3668fc21acdb2072022cb65808df5becebd;hb=2f15a1e3784ca2c076afb2654bb313723de8592e;hpb=60f4a8590a34861a966b85ad8d7e6c9c8daa7ace&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Fguide&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/guide&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;09:39:21 PM 08/28/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=2f15a1e3784ca2c076afb2654bb313723de8592e&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: update guide to explain new state files&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/tickets/15 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_60f4a8590a34861a966b85ad8d7e6c9c8daa7ace/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-60f4a8590a34861a966b85ad8d7e6c9c8daa7ace
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-24T19:45:05Z</updated>
> +       <published>2015-08-24T19:45:05Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-60f4a8590a34861a966b85ad8d7e6c9c8daa7ace&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/15.mdwn;h=37a1b5e2695ce312b8f1b8e37078dd4cdbc90898;hp=a466fadce2c88cde0347c164e7a49c97e32e1b13;hb=60f4a8590a34861a966b85ad8d7e6c9c8daa7ace;hpb=d0ab67c9ff7643ac75e918e3cb295288003e47e4&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F15&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/15&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;07:45:05 PM 08/24/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=60f4a8590a34861a966b85ad8d7e6c9c8daa7ace&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: settings now support exploration&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/tickets/18 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_d0ab67c9ff7643ac75e918e3cb295288003e47e4/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-d0ab67c9ff7643ac75e918e3cb295288003e47e4
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-23T22:01:20Z</updated>
> +       <published>2015-08-23T22:01:20Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-d0ab67c9ff7643ac75e918e3cb295288003e47e4&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/18.mdwn;h=f717e312738110e9fa51874c4efa2b918dca6c43;hp=0000000000000000000000000000000000000000;hb=d0ab67c9ff7643ac75e918e3cb295288003e47e4;hpb=6e90ed1b9fa935727054984b9252bd79a5dbef6b&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F18&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/18&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;10:01:20 PM 08/23/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=d0ab67c9ff7643ac75e918e3cb295288003e47e4&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: new ticket: intuitive UI&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/settings/tickets/1 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_6e90ed1b9fa935727054984b9252bd79a5dbef6b/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-6e90ed1b9fa935727054984b9252bd79a5dbef6b
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-23T21:49:11Z</updated>
> +       <published>2015-08-23T21:49:11Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-6e90ed1b9fa935727054984b9252bd79a5dbef6b&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/tickets/1.mdwn;h=e666ba63a41d9c574d63f73f8e85316a165aa6f9;hp=1212dbea4050efc9f0e06f61ea832babb70099ed;hb=6e90ed1b9fa935727054984b9252bd79a5dbef6b;hpb=9a0291a0846a9ff9cca95b6f7d23938bc2dcdefa&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fsettings%2Ftickets%2F1&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/settings/tickets/1&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;09:49:11 PM 08/23/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=6e90ed1b9fa935727054984b9252bd79a5dbef6b&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +settings: close #1, callbacks and save/load added&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/guide on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_9a0291a0846a9ff9cca95b6f7d23938bc2dcdefa/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-9a0291a0846a9ff9cca95b6f7d23938bc2dcdefa
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-23T19:23:22Z</updated>
> +       <published>2015-08-23T19:23:22Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-9a0291a0846a9ff9cca95b6f7d23938bc2dcdefa&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/guide.mdwn;h=bb59f3668fc21acdb2072022cb65808df5becebd;hp=70eb2c6b749d1499807a21e0bc4a6ef2614f90a4;hb=9a0291a0846a9ff9cca95b6f7d23938bc2dcdefa;hpb=6f734bfda528f1afb249d33bb438a7a5638f3ad1&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Fguide&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/guide&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;07:23:22 PM 08/23/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=9a0291a0846a9ff9cca95b6f7d23938bc2dcdefa&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: explain about settings in the guide&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/settings/tickets/1 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_6f734bfda528f1afb249d33bb438a7a5638f3ad1/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-6f734bfda528f1afb249d33bb438a7a5638f3ad1
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-23T09:49:55Z</updated>
> +       <published>2015-08-23T09:49:55Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-6f734bfda528f1afb249d33bb438a7a5638f3ad1&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/tickets/1.mdwn;h=1212dbea4050efc9f0e06f61ea832babb70099ed;hp=83d3c27561e380877f7214159378ff806b206b2c;hb=6f734bfda528f1afb249d33bb438a7a5638f3ad1;hpb=428482ea05956bcfebaaa68abeb9cdc1105ed129&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fsettings%2Ftickets%2F1&quot;
> rel=&quot;nofollow&quot;&gt;projects/settings/tickets/1&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;09:49:55 AM 08/23/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=6f734bfda528f1afb249d33bb438a7a5638f3ad1&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +settings: plan custom debounce action for saving&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to people/fr33domlover/blog/insanity2 on
> Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_428482ea05956bcfebaaa68abeb9cdc1105ed129/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-428482ea05956bcfebaaa68abeb9cdc1105ed129
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-23T09:49:16Z</updated>
> +       <published>2015-08-23T09:49:16Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-428482ea05956bcfebaaa68abeb9cdc1105ed129&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=people/fr33domlover/blog/insanity2.mdwn;h=9746b62a83126b3a142ff7d067de559441e39a00;hp=0000000000000000000000000000000000000000;hb=428482ea05956bcfebaaa68abeb9cdc1105ed129;hpb=67577535d19a1fcd1c187d71f41aa012a16d65f3&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover%2Fblog%2Finsanity2&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;people/fr33domlover/blog/insanity2&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;09:49:16 AM 08/23/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=428482ea05956bcfebaaa68abeb9cdc1105ed129&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +blog post...&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/settings/tickets/1 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_67577535d19a1fcd1c187d71f41aa012a16d65f3/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-67577535d19a1fcd1c187d71f41aa012a16d65f3
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-22T00:42:25Z</updated>
> +       <published>2015-08-22T00:42:25Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-67577535d19a1fcd1c187d71f41aa012a16d65f3&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/tickets/1.mdwn;h=83d3c27561e380877f7214159378ff806b206b2c;hp=6a63447c56eaeca30431fad77cb1945230f73ac7;hb=67577535d19a1fcd1c187d71f41aa012a16d65f3;hpb=f4aaab3a133c556a0db208924e86bbb312879319&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fsettings%2Ftickets%2F1&quot;
> rel=&quot;nofollow&quot;&gt;projects/settings/tickets/1&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;12:42:25 AM 08/22/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=67577535d19a1fcd1c187d71f41aa012a16d65f3&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +settings: work on callbacks and persistence&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/settings/tickets/1 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_f4aaab3a133c556a0db208924e86bbb312879319/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-f4aaab3a133c556a0db208924e86bbb312879319
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-21T14:20:30Z</updated>
> +       <published>2015-08-21T14:20:30Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-f4aaab3a133c556a0db208924e86bbb312879319&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/tickets/1.mdwn;h=6a63447c56eaeca30431fad77cb1945230f73ac7;hp=0000000000000000000000000000000000000000;hb=f4aaab3a133c556a0db208924e86bbb312879319;hpb=2e457435020f1ab3b5836e8efb3cc1228c6b595c&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fsettings%2Ftickets%2F1&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/settings/tickets/1&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;02:20:30 PM 08/21/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=f4aaab3a133c556a0db208924e86bbb312879319&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +settings: new ticket: scope and features&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects projects/feed-collect
> projects/feed-collect/decisions projects/feed-collect/forum
> projects/feed-collect/news projects/feed-collect/releases
> projects/feed-collect/tickets on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_2e457435020f1ab3b5836e8efb3cc1228c6b595c/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-2e457435020f1ab3b5836e8efb3cc1228c6b595c
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-19T10:02:40Z</updated>
> +       <published>2015-08-19T10:02:40Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-2e457435020f1ab3b5836e8efb3cc1228c6b595c&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects.mdwn;h=10ae06877f9882b6bd6f3bb1c5b9dd3c7ab032c1;hp=898655fcc20c4302682ffe196aa54e3afeb59b36;hb=2e457435020f1ab3b5836e8efb3cc1228c6b595c;hpb=e127857268e2b2c8181245b6693205c98f371648&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/feed-collect.mdwn;h=6c574d38ef834e36a9a9be69bfcff3a6598fe461;hp=0000000000000000000000000000000000000000;hb=2e457435020f1ab3b5836e8efb3cc1228c6b595c;hpb=e127857268e2b2c8181245b6693205c98f371648&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffeed-collect&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/feed-collect&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/feed-collect/decisions.mdwn;h=ae1b64118c25d3e7236d3f239dfb9c423225532a;hp=0000000000000000000000000000000000000000;hb=2e457435020f1ab3b5836e8efb3cc1228c6b595c;hpb=e127857268e2b2c8181245b6693205c98f371648&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffeed-collect%2Fdecisions&quot;
> rel=&quot;nofollow&quot;&gt;projects/feed-collect/decisions&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/feed-collect/forum.mdwn;h=21ae61a8f6c6c15ac9fc7d1776599bddbb66bd39;hp=0000000000000000000000000000000000000000;hb=2e457435020f1ab3b5836e8efb3cc1228c6b595c;hpb=e127857268e2b2c8181245b6693205c98f371648&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffeed-collect%2Fforum&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/feed-collect/forum&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/feed-collect/news.mdwn;h=b7a2df9ac1e94ba97e0bfbcc56d346a153ad78f1;hp=0000000000000000000000000000000000000000;hb=2e457435020f1ab3b5836e8efb3cc1228c6b595c;hpb=e127857268e2b2c8181245b6693205c98f371648&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffeed-collect%2Fnews&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/feed-collect/news&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/feed-collect/releases.mdwn;h=1bf09d72d75f6bce0cf32b591d5fb6245c99d4c9;hp=0000000000000000000000000000000000000000;hb=2e457435020f1ab3b5836e8efb3cc1228c6b595c;hpb=e127857268e2b2c8181245b6693205c98f371648&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffeed-collect%2Freleases&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/feed-collect/releases&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/feed-collect/tickets.mdwn;h=99f8e90067ef5c1404674843969b71e2184721aa;hp=0000000000000000000000000000000000000000;hb=2e457435020f1ab3b5836e8efb3cc1228c6b595c;hpb=e127857268e2b2c8181245b6693205c98f371648&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffeed-collect%2Ftickets&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/feed-collect/tickets&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;10:02:40 AM 08/19/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=2e457435020f1ab3b5836e8efb3cc1228c6b595c&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +feed-collect: new project (actually about to release)&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/tickets/6 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_e127857268e2b2c8181245b6693205c98f371648/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-e127857268e2b2c8181245b6693205c98f371648
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-18T17:06:48Z</updated>
> +       <published>2015-08-18T17:06:48Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-e127857268e2b2c8181245b6693205c98f371648&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/6.mdwn;h=572dde578082b3005aa3534ed3c0a7f92f21f7b3;hp=bffd53261a36337edc4988f732b733d1996f6e5c;hb=e127857268e2b2c8181245b6693205c98f371648;hpb=1f86b06ce5d3930dc77991312d02cba3193084f6&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F6&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/6&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;05:06:48 PM 08/18/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=e127857268e2b2c8181245b6693205c98f371648&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +fix invalid link&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/tickets/6 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_1f86b06ce5d3930dc77991312d02cba3193084f6/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-1f86b06ce5d3930dc77991312d02cba3193084f6
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-18T14:54:20Z</updated>
> +       <published>2015-08-18T14:54:20Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-1f86b06ce5d3930dc77991312d02cba3193084f6&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/6.mdwn;h=bffd53261a36337edc4988f732b733d1996f6e5c;hp=685bde0ac57f25f9a469350985154c13330ccf1e;hb=1f86b06ce5d3930dc77991312d02cba3193084f6;hpb=d2bcaf67089dbb1b92c2128b23134e48597ed455&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F6&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/6&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;02:54:20 PM 08/18/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=1f86b06ce5d3930dc77991312d02cba3193084f6&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: update status of freepost integration&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/tickets/4 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_d2bcaf67089dbb1b92c2128b23134e48597ed455/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-d2bcaf67089dbb1b92c2128b23134e48597ed455
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-18T14:02:57Z</updated>
> +       <published>2015-08-18T14:02:57Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-d2bcaf67089dbb1b92c2128b23134e48597ed455&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/4.mdwn;h=ff2a4540311b77cfbad57c95b57a2090b7eedb9b;hp=071cb7e64ae57c211834ee5cc7e80132209a6bc2;hb=d2bcaf67089dbb1b92c2128b23134e48597ed455;hpb=b61f7736931f2801c6fdd401f29f6fc78b2d900a&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F4&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/4&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;02:02:57 PM 08/18/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=d2bcaf67089dbb1b92c2128b23134e48597ed455&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: notes on coding of logging system&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/tickets/16 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_b61f7736931f2801c6fdd401f29f6fc78b2d900a/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-b61f7736931f2801c6fdd401f29f6fc78b2d900a
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-17T09:12:02Z</updated>
> +       <published>2015-08-17T09:12:02Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-b61f7736931f2801c6fdd401f29f6fc78b2d900a&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/16.mdwn;h=1197b4650734456f81f92dfd314c5a076bb5762c;hp=15bbe0cb556feb7ed9000c36bb42a8396fb12921;hb=b61f7736931f2801c6fdd401f29f6fc78b2d900a;hpb=a9301fc50b752e55af343255a0b54b990646bd43&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F16&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/16&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;09:12:02 AM 08/17/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=b61f7736931f2801c6fdd401f29f6fc78b2d900a&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: close #16, feed reader implemented&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/tickets/17 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_a9301fc50b752e55af343255a0b54b990646bd43/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-a9301fc50b752e55af343255a0b54b990646bd43
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-17T09:09:36Z</updated>
> +       <published>2015-08-17T09:09:36Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-a9301fc50b752e55af343255a0b54b990646bd43&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/17.mdwn;h=7502e27ea78f3f9667ccdad47b77914d283502d2;hp=70f51944ac387924b6f8bf7433631a3baeb038a4;hb=a9301fc50b752e55af343255a0b54b990646bd43;hpb=360a6d980da581e86d5fe7a80c1fa059b668ab93&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F17&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/17&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;09:09:36 AM 08/17/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=a9301fc50b752e55af343255a0b54b990646bd43&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: close #17, the bot should spam less now&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/tickets/10
> projects/irc-fun-bot/tickets/3 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_360a6d980da581e86d5fe7a80c1fa059b668ab93/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-360a6d980da581e86d5fe7a80c1fa059b668ab93
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-17T00:39:34Z</updated>
> +       <published>2015-08-17T00:39:34Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-360a6d980da581e86d5fe7a80c1fa059b668ab93&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/10.mdwn;h=f267e06c2e4ba2d221a5e8b493e7d83954a86b98;hp=2dfa6c5aa076d72de618c647a17774e23cacf78f;hb=360a6d980da581e86d5fe7a80c1fa059b668ab93;hpb=f7b4fd5b731cb17a6489352f10a735368f34d46d&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F10&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/10&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/3.mdwn;h=ca2600e82be6faed8128f2e92e37f7941fc25415;hp=cf324dd4a0534fb640a72e516a58205b01917e28;hb=360a6d980da581e86d5fe7a80c1fa059b668ab93;hpb=f7b4fd5b731cb17a6489352f10a735368f34d46d&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-bot%2Ftickets%2F3&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/irc-fun-bot/tickets/3&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;12:39:34 AM 08/17/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=360a6d980da581e86d5fe7a80c1fa059b668ab93&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: close tickets done with&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/guide projects/funbot/manual on
> Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_f7b4fd5b731cb17a6489352f10a735368f34d46d/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-f7b4fd5b731cb17a6489352f10a735368f34d46d
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-16T22:15:37Z</updated>
> +       <published>2015-08-16T22:15:37Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-f7b4fd5b731cb17a6489352f10a735368f34d46d&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/guide.mdwn;h=70eb2c6b749d1499807a21e0bc4a6ef2614f90a4;hp=85e000a7ff584f162078086dd4c4a2a4fd960028;hb=f7b4fd5b731cb17a6489352f10a735368f34d46d;hpb=599eada420921192ceae6cb687f8a9950022044f&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Fguide&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/guide&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/manual.mdwn;h=44c3d463280d7e275a6f93bd9633289f0872b686;hp=b67467c06eb95e96e22c9645100359f147b32ad1;hb=f7b4fd5b731cb17a6489352f10a735368f34d46d;hpb=599eada420921192ceae6cb687f8a9950022044f&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Fmanual&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/manual&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;10:15:37 PM 08/16/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=f7b4fd5b731cb17a6489352f10a735368f34d46d&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: update docs&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/tickets/15 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_599eada420921192ceae6cb687f8a9950022044f/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-599eada420921192ceae6cb687f8a9950022044f
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-16T18:43:49Z</updated>
> +       <published>2015-08-16T18:43:49Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-599eada420921192ceae6cb687f8a9950022044f&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/15.mdwn;h=a466fadce2c88cde0347c164e7a49c97e32e1b13;hp=9fde6e22407a2eff47b1a666b3d3c274e5e19859;hb=599eada420921192ceae6cb687f8a9950022044f;hpb=2bf9de01bb378e4c9ed11cb7799ee03f12aed21b&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F15&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/15&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;06:43:49 PM 08/16/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=599eada420921192ceae6cb687f8a9950022044f&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: the settings system needs callbacks&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/tickets/17 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_2bf9de01bb378e4c9ed11cb7799ee03f12aed21b/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-2bf9de01bb378e4c9ed11cb7799ee03f12aed21b
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-15T10:34:40Z</updated>
> +       <published>2015-08-15T10:34:40Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-2bf9de01bb378e4c9ed11cb7799ee03f12aed21b&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/17.mdwn;h=70f51944ac387924b6f8bf7433631a3baeb038a4;hp=0000000000000000000000000000000000000000;hb=2bf9de01bb378e4c9ed11cb7799ee03f12aed21b;hpb=0e840edc3dd9ec79ee219ba94cd63866eed668ea&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F17&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/17&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;10:34:40 AM 08/15/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=2bf9de01bb378e4c9ed11cb7799ee03f12aed21b&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: new ticket: avoid spamming with multi-commit pushes&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/tickets/16 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_0e840edc3dd9ec79ee219ba94cd63866eed668ea/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-0e840edc3dd9ec79ee219ba94cd63866eed668ea
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-13T16:57:09Z</updated>
> +       <published>2015-08-13T16:57:09Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-0e840edc3dd9ec79ee219ba94cd63866eed668ea&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/16.mdwn;h=15bbe0cb556feb7ed9000c36bb42a8396fb12921;hp=e62242d40f027b0491185be804ed929dc5a4ac7f;hb=0e840edc3dd9ec79ee219ba94cd63866eed668ea;hpb=f8d63be6c0d9119296673fb426e4a67f514397e0&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F16&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/16&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;04:57:09 PM 08/13/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=0e840edc3dd9ec79ee219ba94cd63866eed668ea&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: list existing feed related packages to review&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/tickets/16 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_f8d63be6c0d9119296673fb426e4a67f514397e0/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-f8d63be6c0d9119296673fb426e4a67f514397e0
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-13T07:23:09Z</updated>
> +       <published>2015-08-13T07:23:09Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-f8d63be6c0d9119296673fb426e4a67f514397e0&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/16.mdwn;h=e62242d40f027b0491185be804ed929dc5a4ac7f;hp=0000000000000000000000000000000000000000;hb=f8d63be6c0d9119296673fb426e4a67f514397e0;hpb=5b11daceee3ab50b30197cfa2ab5385b24a8dc73&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F16&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/16&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;07:23:09 AM 08/13/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=f8d63be6c0d9119296673fb426e4a67f514397e0&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: new ticket: announce RSS feeds&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to people/fr33domlover/veganism on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_5b11daceee3ab50b30197cfa2ab5385b24a8dc73/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-5b11daceee3ab50b30197cfa2ab5385b24a8dc73
> "/>
> +
> +       <author><name>mm</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-13T03:23:02Z</updated>
> +       <published>2015-08-13T03:23:02Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-5b11daceee3ab50b30197cfa2ab5385b24a8dc73&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=people/fr33domlover/veganism.mdwn;h=b129c47a62a42f0e7094ea66ab4120c70bbf2956;hp=531aa72c9aa9be7cec113b57f7cd0792bd873cc4;hb=5b11daceee3ab50b30197cfa2ab5385b24a8dc73;hpb=bb1d1469396d107bdbbe314e87d3666cf530d297&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover%2Fveganism&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;people/fr33domlover/veganism&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Fmm&quot;
> rel=&quot;nofollow&quot;&gt;mm&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;web&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;03:23:02 AM 08/13/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=5b11daceee3ab50b30197cfa2ab5385b24a8dc73&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects projects/vcs-web-hook-parse
> projects/vcs-web-hook-parse/tickets on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_bb1d1469396d107bdbbe314e87d3666cf530d297/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-bb1d1469396d107bdbbe314e87d3666cf530d297
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-10T13:29:45Z</updated>
> +       <published>2015-08-10T13:29:45Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-bb1d1469396d107bdbbe314e87d3666cf530d297&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects.mdwn;h=898655fcc20c4302682ffe196aa54e3afeb59b36;hp=8dc1b5dc39e41e5367ca9ba74882e13effdd2e49;hb=bb1d1469396d107bdbbe314e87d3666cf530d297;hpb=a815429ee204e00c48a0d72cc17456246e6040de&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects&quot;
> rel=&quot;nofollow&quot;&gt;projects&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/vcs-web-hook-parse.mdwn;h=5128a0066c64cf95ed693d43e4b463adad27e2cb;hp=0000000000000000000000000000000000000000;hb=bb1d1469396d107bdbbe314e87d3666cf530d297;hpb=a815429ee204e00c48a0d72cc17456246e6040de&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fvcs-web-hook-parse&quot;
> rel=&quot;nofollow&quot;&gt;projects/vcs-web-hook-parse&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/vcs-web-hook-parse/tickets.mdwn;h=5dea4f6f5c1bd6d7879c5773f8015c408511e55f;hp=0000000000000000000000000000000000000000;hb=bb1d1469396d107bdbbe314e87d3666cf530d297;hpb=a815429ee204e00c48a0d72cc17456246e6040de&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fvcs-web-hook-parse%2Ftickets&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/vcs-web-hook-parse/tickets&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;01:29:45 PM 08/10/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=bb1d1469396d107bdbbe314e87d3666cf530d297&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +vcs-web-hook-parse: new project, added dummy pages&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/guide projects/irc-fun-bot
> projects/irc-fun-client projects/irc-fun-messages on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_a815429ee204e00c48a0d72cc17456246e6040de/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-a815429ee204e00c48a0d72cc17456246e6040de
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-09T14:20:44Z</updated>
> +       <published>2015-08-09T14:20:44Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-a815429ee204e00c48a0d72cc17456246e6040de&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/guide.mdwn;h=85e000a7ff584f162078086dd4c4a2a4fd960028;hp=fe77d4628d012fbba69fb4186054141ac9386e1e;hb=a815429ee204e00c48a0d72cc17456246e6040de;hpb=63c70b3be856df4c006fabdafb301f9f47fa0b42&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Fguide&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/guide&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot.mdwn;h=d16135bd1e6a372261567b700c147259d4e0f6af;hp=bbd523480202c43f2ad9cb96773d69fa16a29819;hb=a815429ee204e00c48a0d72cc17456246e6040de;hpb=63c70b3be856df4c006fabdafb301f9f47fa0b42&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Firc-fun-bot&quot;
> rel=&quot;nofollow&quot;&gt;projects/irc-fun-bot&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-client.mdwn;h=cdac524a07d2eb092f858de8d4d8d8a0cfc0e8d7;hp=052a1471d2b01e04b9a250bd3ce5efda48e973e8;hb=a815429ee204e00c48a0d72cc17456246e6040de;hpb=63c70b3be856df4c006fabdafb301f9f47fa0b42&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-client&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/irc-fun-client&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-messages.mdwn;h=b793f23214f70270ed7da5b3699ad9efdabb5e77;hp=8a037a6b3176f58e7585d9442b98292313fca511;hb=a815429ee204e00c48a0d72cc17456246e6040de;hpb=63c70b3be856df4c006fabdafb301f9f47fa0b42&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-messages&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/irc-fun-messages&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;02:20:44 PM 08/09/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=a815429ee204e00c48a0d72cc17456246e6040de&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: update repo links after move to dev.&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/rel4tion/roadmap/release-00 on
> Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_63c70b3be856df4c006fabdafb301f9f47fa0b42/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-63c70b3be856df4c006fabdafb301f9f47fa0b42
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-09T12:25:39Z</updated>
> +       <published>2015-08-09T12:25:39Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-63c70b3be856df4c006fabdafb301f9f47fa0b42&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/rel4tion/roadmap/release-00.mdwn;h=ce02ef19c8176eb80c1fd5ca77cacfd6ef42a296;hp=b0297d9c7d79acf1fb70bf3029570491f97470c0;hb=63c70b3be856df4c006fabdafb301f9f47fa0b42;hpb=4114d7f291fe124c5169e1588bf3ba8828ea1955&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Frel4tion%2Froadmap%2Frelease-00&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/rel4tion/roadmap/release-00&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;12:25:39 PM 08/09/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=63c70b3be856df4c006fabdafb301f9f47fa0b42&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +rel4tion: update roadmap with recent work&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to templates/rmtask on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_4114d7f291fe124c5169e1588bf3ba8828ea1955/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-4114d7f291fe124c5169e1588bf3ba8828ea1955
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-09T11:34:25Z</updated>
> +       <published>2015-08-09T11:34:25Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-4114d7f291fe124c5169e1588bf3ba8828ea1955&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/rmtask.mdwn;h=e8a5548bd50de46c670e181aa5ab4af0b53336a5;hp=8081803ab94e9f415a0b16ddd06345163bda3541;hb=4114d7f291fe124c5169e1588bf3ba8828ea1955;hpb=a388b2d06814991f93f52276b8dfe18cd1627ef1&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=templates%2Frmtask&quot;
> rel=&quot;nofollow&quot;&gt;templates/rmtask&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;11:34:25 AM 08/09/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=4114d7f291fe124c5169e1588bf3ba8828ea1955&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +templates: tweak rmtask colors&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/guide projects/funbot/manual
> projects/funbot/tickets/7 projects/irc-fun-bot/tickets/3 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_a388b2d06814991f93f52276b8dfe18cd1627ef1/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-a388b2d06814991f93f52276b8dfe18cd1627ef1
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-08T22:47:46Z</updated>
> +       <published>2015-08-08T22:47:46Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-a388b2d06814991f93f52276b8dfe18cd1627ef1&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/guide.mdwn;h=fe77d4628d012fbba69fb4186054141ac9386e1e;hp=6234c5babf562a6e0554c81171beb169c721b6de;hb=a388b2d06814991f93f52276b8dfe18cd1627ef1;hpb=5f028255a061f5e1405aae1f4bcf911086ddc4d9&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Fguide&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/guide&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/manual.mdwn;h=b67467c06eb95e96e22c9645100359f147b32ad1;hp=4fb784a3bbd9efa372438f998917e996c95946d6;hb=a388b2d06814991f93f52276b8dfe18cd1627ef1;hpb=5f028255a061f5e1405aae1f4bcf911086ddc4d9&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Fmanual&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/manual&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/7.mdwn;h=24801b7b18518348ed77f49239ab071f106fe4ab;hp=edc5905349f54c32ce471d98c1434723aca026d5;hb=a388b2d06814991f93f52276b8dfe18cd1627ef1;hpb=5f028255a061f5e1405aae1f4bcf911086ddc4d9&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F7&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/7&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/3.mdwn;h=cf324dd4a0534fb640a72e516a58205b01917e28;hp=7ad03fd86056bf4892a412a1fc7c85838a36d170;hb=a388b2d06814991f93f52276b8dfe18cd1627ef1;hpb=5f028255a061f5e1405aae1f4bcf911086ddc4d9&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Firc-fun-bot%2Ftickets%2F3&quot;
> rel=&quot;nofollow&quot;&gt;projects/irc-fun-bot/tickets/3&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;10:47:46 PM 08/08/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=a388b2d06814991f93f52276b8dfe18cd1627ef1&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: ticket and doc updates&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/tickets/2
> projects/http-listen/tickets/2 projects/irc-fun-bot/tickets/3 on
> Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_5f028255a061f5e1405aae1f4bcf911086ddc4d9/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-5f028255a061f5e1405aae1f4bcf911086ddc4d9
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-06T13:37:56Z</updated>
> +       <published>2015-08-06T13:37:56Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-5f028255a061f5e1405aae1f4bcf911086ddc4d9&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/2.mdwn;h=2cc56bb7968465ca690ebcbed6ed5a5213fb8a0c;hp=2db571641ae6d30d6d74d401e2e96015b833b811;hb=5f028255a061f5e1405aae1f4bcf911086ddc4d9;hpb=c5b0bd2d44344346599c272f5f9f089cff3cd0cf&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F2&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/2&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/http-listen/tickets/2.mdwn;h=083e030badb159f80bb13af5c2ec169c24e4874e;hp=0000000000000000000000000000000000000000;hb=5f028255a061f5e1405aae1f4bcf911086ddc4d9;hpb=c5b0bd2d44344346599c272f5f9f089cff3cd0cf&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fhttp-listen%2Ftickets%2F2&quot;
> rel=&quot;nofollow&quot;&gt;projects/http-listen/tickets/2&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/3.mdwn;h=7ad03fd86056bf4892a412a1fc7c85838a36d170;hp=9a3b0698a4094f4fdc31af182d9233e45bdd5928;hb=5f028255a061f5e1405aae1f4bcf911086ddc4d9;hpb=c5b0bd2d44344346599c272f5f9f089cff3cd0cf&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-bot%2Ftickets%2F3&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/irc-fun-bot/tickets/3&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;01:37:56 PM 08/06/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=5f028255a061f5e1405aae1f4bcf911086ddc4d9&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +some ticket updates&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/http-listen/tickets/1 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_c5b0bd2d44344346599c272f5f9f089cff3cd0cf/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-c5b0bd2d44344346599c272f5f9f089cff3cd0cf
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-05T09:52:09Z</updated>
> +       <published>2015-08-05T09:52:09Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-c5b0bd2d44344346599c272f5f9f089cff3cd0cf&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/http-listen/tickets/1.mdwn;h=0798820f782a817d904c7c077c4a2395ec33c171;hp=0000000000000000000000000000000000000000;hb=c5b0bd2d44344346599c272f5f9f089cff3cd0cf;hpb=abccb345fea04b01b45eed2a0f56c3c88988ebf0&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fhttp-listen%2Ftickets%2F1&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/http-listen/tickets/1&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;09:52:09 AM 08/05/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=c5b0bd2d44344346599c272f5f9f089cff3cd0cf&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +http-listen: ope ticket about timeouts&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects projects/http-listen
> projects/http-listen/decisions projects/http-listen/forum
> projects/http-listen/news projects/http-listen/releases
> projects/http-listen/tickets shortcuts on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_abccb345fea04b01b45eed2a0f56c3c88988ebf0/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-abccb345fea04b01b45eed2a0f56c3c88988ebf0
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-05T09:23:20Z</updated>
> +       <published>2015-08-05T09:23:20Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-abccb345fea04b01b45eed2a0f56c3c88988ebf0&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects.mdwn;h=8dc1b5dc39e41e5367ca9ba74882e13effdd2e49;hp=8a382bc0b1a8668b14aad89aa4bc16711a1ed84a;hb=abccb345fea04b01b45eed2a0f56c3c88988ebf0;hpb=3807c6e1a57de56dd0e0502a1fe7020d089048c5&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects&quot;
> rel=&quot;nofollow&quot;&gt;projects&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/http-listen.mdwn;h=7034ea4798f3d24ebcebd4c02cdd3865c245924d;hp=0000000000000000000000000000000000000000;hb=abccb345fea04b01b45eed2a0f56c3c88988ebf0;hpb=3807c6e1a57de56dd0e0502a1fe7020d089048c5&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fhttp-listen&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/http-listen&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/http-listen/decisions.mdwn;h=1a96e79ec55bb6bb817136a2ee3c333e4bbf4c36;hp=0000000000000000000000000000000000000000;hb=abccb345fea04b01b45eed2a0f56c3c88988ebf0;hpb=3807c6e1a57de56dd0e0502a1fe7020d089048c5&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fhttp-listen%2Fdecisions&quot;
> rel=&quot;nofollow&quot;&gt;projects/http-listen/decisions&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/http-listen/forum.mdwn;h=b4032d88892110263de936a7f9ef6c7f8f7d755b;hp=0000000000000000000000000000000000000000;hb=abccb345fea04b01b45eed2a0f56c3c88988ebf0;hpb=3807c6e1a57de56dd0e0502a1fe7020d089048c5&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fhttp-listen%2Fforum&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/http-listen/forum&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/http-listen/news.mdwn;h=a52d3fd6fc03f44418a4db0ccd745b3f53d6d81d;hp=0000000000000000000000000000000000000000;hb=abccb345fea04b01b45eed2a0f56c3c88988ebf0;hpb=3807c6e1a57de56dd0e0502a1fe7020d089048c5&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fhttp-listen%2Fnews&quot;
> rel=&quot;nofollow&quot;&gt;projects/http-listen/news&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/http-listen/releases.mdwn;h=36687b2803485acb11d99138e4b5d9b1d40a177a;hp=0000000000000000000000000000000000000000;hb=abccb345fea04b01b45eed2a0f56c3c88988ebf0;hpb=3807c6e1a57de56dd0e0502a1fe7020d089048c5&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fhttp-listen%2Freleases&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/http-listen/releases&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/http-listen/tickets.mdwn;h=36e5aefaceccf9996d9dcf98239267d20c895455;hp=0000000000000000000000000000000000000000;hb=abccb345fea04b01b45eed2a0f56c3c88988ebf0;hpb=3807c6e1a57de56dd0e0502a1fe7020d089048c5&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fhttp-listen%2Ftickets&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/http-listen/tickets&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=shortcuts.mdwn;h=848c9edfe10d412737a37883ff955dbee20089cb;hp=955fe6213cd0b74a022cb19d9a82986422a5ac7c;hb=abccb345fea04b01b45eed2a0f56c3c88988ebf0;hpb=3807c6e1a57de56dd0e0502a1fe7020d089048c5&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=shortcuts&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;shortcuts&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;09:23:20 AM 08/05/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=abccb345fea04b01b45eed2a0f56c3c88988ebf0&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +http-listen: new project&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/kiwi/data/idan-files/todo.idan on
> Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_3807c6e1a57de56dd0e0502a1fe7020d089048c5/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-3807c6e1a57de56dd0e0502a1fe7020d089048c5
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-01T21:21:43Z</updated>
> +       <published>2015-08-01T21:21:43Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-3807c6e1a57de56dd0e0502a1fe7020d089048c5&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/kiwi/data/idan-files/todo.idan;h=ccb6b70db2f4b5da7fa5d3a70c1ddc8cd9f1a33e;hp=eace9d20f6dd5d83087bc751aead7446aca7e575;hb=3807c6e1a57de56dd0e0502a1fe7020d089048c5;hpb=dd747340fffdb41ba4ff5066356b22dbffd73c98&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fkiwi%2Fdata%2Fidan-files%2Ftodo.idan&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/kiwi/data/idan-files/todo.idan&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;09:21:43 PM 08/01/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=3807c6e1a57de56dd0e0502a1fe7020d089048c5&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +kiwi: tasks-tui requires new entities&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to news/darcs-hub-new on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_dd747340fffdb41ba4ff5066356b22dbffd73c98/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-dd747340fffdb41ba4ff5066356b22dbffd73c98
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-08-01T11:35:10Z</updated>
> +       <published>2015-08-01T11:35:10Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-dd747340fffdb41ba4ff5066356b22dbffd73c98&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=news/darcs-hub-new.mdwn;h=d1cbc5d5d35452c5272006db744779409c9b8505;hp=0000000000000000000000000000000000000000;hb=dd747340fffdb41ba4ff5066356b22dbffd73c98;hpb=65c40fbb77b5f797a67493716418ed0115a160cf&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=news%2Fdarcs-hub-new&quot;
> rel=&quot;nofollow&quot;&gt;news/darcs-hub-new&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;11:35:10 AM 08/01/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=dd747340fffdb41ba4ff5066356b22dbffd73c98&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +news: new darcs hub&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/vocabularies-hs on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_65c40fbb77b5f797a67493716418ed0115a160cf/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-65c40fbb77b5f797a67493716418ed0115a160cf
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-31T08:44:15Z</updated>
> +       <published>2015-07-31T08:44:15Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-65c40fbb77b5f797a67493716418ed0115a160cf&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/vocabularies-hs.mdwn;h=a21d0e3f8540fe73f4e9591a313c911aed6e6252;hp=c56d2d47ee0fe9de02ef44b045edc516cfe756e6;hb=65c40fbb77b5f797a67493716418ed0115a160cf;hpb=f0986cdfd3174159052ac1d3da6e1180dfb9a644&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fvocabularies-hs&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/vocabularies-hs&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;08:44:15 AM 07/31/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=65c40fbb77b5f797a67493716418ed0115a160cf&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +vocabularies-hs: list the new vocabulary-todo&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/kiwi/data/idan-files/todo.idan on
> Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_f0986cdfd3174159052ac1d3da6e1180dfb9a644/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-f0986cdfd3174159052ac1d3da6e1180dfb9a644
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-29T23:28:20Z</updated>
> +       <published>2015-07-29T23:28:20Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-f0986cdfd3174159052ac1d3da6e1180dfb9a644&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/kiwi/data/idan-files/todo.idan;h=eace9d20f6dd5d83087bc751aead7446aca7e575;hp=9dd53e5a54d1add44987b39afc376c6d16a2e467;hb=f0986cdfd3174159052ac1d3da6e1180dfb9a644;hpb=c2ec1d098f1cc5a41435ed5c28bf87fe8f6057da&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fkiwi%2Fdata%2Fidan-files%2Ftodo.idan&quot;
> rel=&quot;nofollow&quot;&gt;projects/kiwi/data/idan-files/todo.idan&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;11:28:20 PM 07/29/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=f0986cdfd3174159052ac1d3da6e1180dfb9a644&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +kiwi: manually add uids needed for coding&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/task-management on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_c2ec1d098f1cc5a41435ed5c28bf87fe8f6057da/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-c2ec1d098f1cc5a41435ed5c28bf87fe8f6057da
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-29T21:09:24Z</updated>
> +       <published>2015-07-29T21:09:24Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-c2ec1d098f1cc5a41435ed5c28bf87fe8f6057da&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/task-management.mdwn;h=852b193c67147e825e7426c09906641acf1dc5fa;hp=1f188daada9a5897e3bd452afbf20e11b08a9c01;hb=c2ec1d098f1cc5a41435ed5c28bf87fe8f6057da;hpb=696ceb85012bff250079824aa5ccf4b526031427&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ftask-management&quot;
> rel=&quot;nofollow&quot;&gt;projects/task-management&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;09:09:24 PM 07/29/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=c2ec1d098f1cc5a41435ed5c28bf87fe8f6057da&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +task-management: update project status&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/task-management/tickets/1
> projects/task-management/tickets/1/operations
> projects/task-management/tickets/1/possible-features
> projects/task-management/tickets/1/ui
> projects/task-management/tickets/1/views projects/tui on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_696ceb85012bff250079824aa5ccf4b526031427/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-696ceb85012bff250079824aa5ccf4b526031427
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-29T06:51:46Z</updated>
> +       <published>2015-07-29T06:51:46Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-696ceb85012bff250079824aa5ccf4b526031427&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/task-management/tickets/1.mdwn;h=e1a899675f53d52ee329abd44daf3a99c7f10cad;hp=1e660face13843a722026d94ec4c2f51b2160069;hb=696ceb85012bff250079824aa5ccf4b526031427;hpb=acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ftask-management%2Ftickets%2F1&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/task-management/tickets/1&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/task-management/tickets/1/operations.mdwn;h=6aa5582ae854c858059089ce638194a861d92b72;hp=0000000000000000000000000000000000000000;hb=696ceb85012bff250079824aa5ccf4b526031427;hpb=acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ftask-management%2Ftickets%2F1%2Foperations&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/task-management/tickets/1/operations&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/task-management/tickets/1/possible-features.mdwn;h=78a47438fe2c9d00a0ab47f99c0b64c7a801eb0f;hp=0000000000000000000000000000000000000000;hb=696ceb85012bff250079824aa5ccf4b526031427;hpb=acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ftask-management%2Ftickets%2F1%2Fpossible-features&quot;
> rel=&quot;nofollow&quot;&gt;projects/task-management/tickets/1/possible-features&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/task-management/tickets/1/ui.mdwn;h=debe4c625183ab3fce85cb2aa7b371e08fb2d29e;hp=0000000000000000000000000000000000000000;hb=696ceb85012bff250079824aa5ccf4b526031427;hpb=acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ftask-management%2Ftickets%2F1%2Fui&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/task-management/tickets/1/ui&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/task-management/tickets/1/views.mdwn;h=4c3f149808ad74fba579947f393b4f6a21e62bab;hp=0000000000000000000000000000000000000000;hb=696ceb85012bff250079824aa5ccf4b526031427;hpb=acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ftask-management%2Ftickets%2F1%2Fviews&quot;
> rel=&quot;nofollow&quot;&gt;projects/task-management/tickets/1/views&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/tui.mdwn;h=707ea3237ed79a556340a96e60094beb969f0403;hp=ed4986fab9a9c1d0a320e0aebbd548e2046f94a8;hb=696ceb85012bff250079824aa5ccf4b526031427;hpb=acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ftui&quot;
> rel=&quot;nofollow&quot;&gt;projects/tui&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;06:51:46 AM 07/29/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=696ceb85012bff250079824aa5ccf4b526031427&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +task-management: more plans&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/task-management/tickets/1 on
> Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-28T12:58:05Z</updated>
> +       <published>2015-07-28T12:58:05Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/task-management/tickets/1.mdwn;h=1e660face13843a722026d94ec4c2f51b2160069;hp=30461446304a9c48ebbcdf9004b5e046abf60f39;hb=acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e;hpb=16c22f6a025e24ca916e8312b3b5fe9146858523&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ftask-management%2Ftickets%2F1&quot;
> rel=&quot;nofollow&quot;&gt;projects/task-management/tickets/1&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;12:58:05 PM 07/28/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +minor edit&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects projects/tui on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_16c22f6a025e24ca916e8312b3b5fe9146858523/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-16c22f6a025e24ca916e8312b3b5fe9146858523
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-28T12:56:11Z</updated>
> +       <published>2015-07-28T12:56:11Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-16c22f6a025e24ca916e8312b3b5fe9146858523&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects.mdwn;h=8a382bc0b1a8668b14aad89aa4bc16711a1ed84a;hp=ec5984beb457557cddbd8d1ea7df80db9d42a705;hb=16c22f6a025e24ca916e8312b3b5fe9146858523;hpb=c8f6c3fca3796e7b4ee0148cab287d6ba5866f6c&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/tui.mdwn;h=ed4986fab9a9c1d0a320e0aebbd548e2046f94a8;hp=0000000000000000000000000000000000000000;hb=16c22f6a025e24ca916e8312b3b5fe9146858523;hpb=c8f6c3fca3796e7b4ee0148cab287d6ba5866f6c&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ftui&quot;
> rel=&quot;nofollow&quot;&gt;projects/tui&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;12:56:11 PM 07/28/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=16c22f6a025e24ca916e8312b3b5fe9146858523&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +tui: research project&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/tickets/10 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_c8f6c3fca3796e7b4ee0148cab287d6ba5866f6c/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-c8f6c3fca3796e7b4ee0148cab287d6ba5866f6c
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-27T22:30:00Z</updated>
> +       <published>2015-07-27T22:30:00Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-c8f6c3fca3796e7b4ee0148cab287d6ba5866f6c&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/10.mdwn;h=2dfa6c5aa076d72de618c647a17774e23cacf78f;hp=7db97bbee99f558e4dc6164e60ef81504d4afe24;hb=c8f6c3fca3796e7b4ee0148cab287d6ba5866f6c;hpb=3d15ff1b8068e97901410a3d210227036bf528c5&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F10&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/10&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;10:30:00 PM 07/27/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=c8f6c3fca3796e7b4ee0148cab287d6ba5866f6c&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: update status of hello replies&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/tickets/15 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_3d15ff1b8068e97901410a3d210227036bf528c5/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-3d15ff1b8068e97901410a3d210227036bf528c5
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-27T21:43:34Z</updated>
> +       <published>2015-07-27T21:43:34Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-3d15ff1b8068e97901410a3d210227036bf528c5&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/15.mdwn;h=9fde6e22407a2eff47b1a666b3d3c274e5e19859;hp=8409ef6dc3f7697857b7aacdfc1d0d03ebd8e97b;hb=3d15ff1b8068e97901410a3d210227036bf528c5;hpb=2af6df1680072d6e73f4bdb07fae2c88a59c76aa&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F15&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/15&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;09:43:34 PM 07/27/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=3d15ff1b8068e97901410a3d210227036bf528c5&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: update status of settings system&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/guide projects/funbot/manual on
> Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_2af6df1680072d6e73f4bdb07fae2c88a59c76aa/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-2af6df1680072d6e73f4bdb07fae2c88a59c76aa
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-27T21:33:18Z</updated>
> +       <published>2015-07-27T21:33:18Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-2af6df1680072d6e73f4bdb07fae2c88a59c76aa&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/guide.mdwn;h=6234c5babf562a6e0554c81171beb169c721b6de;hp=9d46ed7be13811c424111b5f29dc6ef641e5754a;hb=2af6df1680072d6e73f4bdb07fae2c88a59c76aa;hpb=617249a360c6973ce7f42ad010f1276c552fbaf1&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Fguide&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/guide&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/manual.mdwn;h=4fb784a3bbd9efa372438f998917e996c95946d6;hp=f179ef3cc7731f76ad0bae8b31a4e64a3f8d6871;hb=2af6df1680072d6e73f4bdb07fae2c88a59c76aa;hpb=617249a360c6973ce7f42ad010f1276c552fbaf1&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Fmanual&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/manual&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;09:33:18 PM 07/27/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=2af6df1680072d6e73f4bdb07fae2c88a59c76aa&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: update docs to match the newly added settings system&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects projects/funbot/tickets/15
> projects/settings projects/settings/decisions projects/settings/forum
> projects/settings/news projects/settings/releases projects/settings/tickets
> on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_617249a360c6973ce7f42ad010f1276c552fbaf1/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-617249a360c6973ce7f42ad010f1276c552fbaf1
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-22T09:46:41Z</updated>
> +       <published>2015-07-22T09:46:41Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-617249a360c6973ce7f42ad010f1276c552fbaf1&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects.mdwn;h=ec5984beb457557cddbd8d1ea7df80db9d42a705;hp=9d82d759e2e847c0b174cf1bbe7f57d75c14474f;hb=617249a360c6973ce7f42ad010f1276c552fbaf1;hpb=5f4444298ebe3f674b73a843dfc7bbef7a1703e7&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects&quot;
> rel=&quot;nofollow&quot;&gt;projects&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/15.mdwn;h=8409ef6dc3f7697857b7aacdfc1d0d03ebd8e97b;hp=a19cd36f2568480158c63ddec2185754cab96f30;hb=617249a360c6973ce7f42ad010f1276c552fbaf1;hpb=5f4444298ebe3f674b73a843dfc7bbef7a1703e7&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F15&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/15&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings.mdwn;h=b7f5ffc7ee35f85a7a7d5094fdc02c578122825e;hp=0000000000000000000000000000000000000000;hb=617249a360c6973ce7f42ad010f1276c552fbaf1;hpb=5f4444298ebe3f674b73a843dfc7bbef7a1703e7&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fsettings&quot;
> rel=&quot;nofollow&quot;&gt;projects/settings&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/decisions.mdwn;h=7fa56d100854163543f12f83cc1408ae417f9f7e;hp=0000000000000000000000000000000000000000;hb=617249a360c6973ce7f42ad010f1276c552fbaf1;hpb=5f4444298ebe3f674b73a843dfc7bbef7a1703e7&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fsettings%2Fdecisions&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/settings/decisions&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/forum.mdwn;h=c3b79bd4409643fdbc11a700b29898f904b315b7;hp=0000000000000000000000000000000000000000;hb=617249a360c6973ce7f42ad010f1276c552fbaf1;hpb=5f4444298ebe3f674b73a843dfc7bbef7a1703e7&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fsettings%2Fforum&quot;
> rel=&quot;nofollow&quot;&gt;projects/settings/forum&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/news.mdwn;h=837c8697a653db420eada75ea57630492eb8338e;hp=0000000000000000000000000000000000000000;hb=617249a360c6973ce7f42ad010f1276c552fbaf1;hpb=5f4444298ebe3f674b73a843dfc7bbef7a1703e7&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fsettings%2Fnews&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/settings/news&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/releases.mdwn;h=e4efd9b315242da6e04f9e94546ed3522bdaac68;hp=0000000000000000000000000000000000000000;hb=617249a360c6973ce7f42ad010f1276c552fbaf1;hpb=5f4444298ebe3f674b73a843dfc7bbef7a1703e7&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Fsettings%2Freleases&quot;
> rel=&quot;nofollow&quot;&gt;projects/settings/releases&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/tickets.mdwn;h=e9398e875cda45921bd91361adb0716986869a15;hp=0000000000000000000000000000000000000000;hb=617249a360c6973ce7f42ad010f1276c552fbaf1;hpb=5f4444298ebe3f674b73a843dfc7bbef7a1703e7&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fsettings%2Ftickets&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/settings/tickets&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;09:46:41 AM 07/22/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=617249a360c6973ce7f42ad010f1276c552fbaf1&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +settings: *another* new project...&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/tickets/15 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_5f4444298ebe3f674b73a843dfc7bbef7a1703e7/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-5f4444298ebe3f674b73a843dfc7bbef7a1703e7
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-21T10:47:23Z</updated>
> +       <published>2015-07-21T10:47:23Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-5f4444298ebe3f674b73a843dfc7bbef7a1703e7&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/15.mdwn;h=a19cd36f2568480158c63ddec2185754cab96f30;hp=038b445accf173eee423a1a03eab722fe86ef030;hb=5f4444298ebe3f674b73a843dfc7bbef7a1703e7;hpb=76a709cf4777cf20cf18b62c3e557f380b98a145&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F15&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/15&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;10:47:23 AM 07/21/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=5f4444298ebe3f674b73a843dfc7bbef7a1703e7&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: notes about settings system&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/tickets/15
> projects/funbot/tickets/4 projects/irc-fun-client/tickets/2 on
> Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_76a709cf4777cf20cf18b62c3e557f380b98a145/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-76a709cf4777cf20cf18b62c3e557f380b98a145
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-20T12:22:27Z</updated>
> +       <published>2015-07-20T12:22:27Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-76a709cf4777cf20cf18b62c3e557f380b98a145&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/15.mdwn;h=038b445accf173eee423a1a03eab722fe86ef030;hp=0000000000000000000000000000000000000000;hb=76a709cf4777cf20cf18b62c3e557f380b98a145;hpb=f65b75264b89071970cf00ff16776aa9d5969437&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F15&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/15&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/4.mdwn;h=071cb7e64ae57c211834ee5cc7e80132209a6bc2;hp=7665ef7035b4387f9ceb84ca9cd79130b81d4d48;hb=76a709cf4777cf20cf18b62c3e557f380b98a145;hpb=f65b75264b89071970cf00ff16776aa9d5969437&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F4&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/4&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-client/tickets/2.mdwn;h=ae578674d3cceaaa6cbe726d632bc3c4e87bfd55;hp=0000000000000000000000000000000000000000;hb=76a709cf4777cf20cf18b62c3e557f380b98a145;hpb=f65b75264b89071970cf00ff16776aa9d5969437&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-client%2Ftickets%2F2&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/irc-fun-client/tickets/2&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;12:22:27 PM 07/20/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=76a709cf4777cf20cf18b62c3e557f380b98a145&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: more tickets...&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/irc-fun-messages/tickets/2 on
> Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_f65b75264b89071970cf00ff16776aa9d5969437/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-f65b75264b89071970cf00ff16776aa9d5969437
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-20T09:12:23Z</updated>
> +       <published>2015-07-20T09:12:23Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-f65b75264b89071970cf00ff16776aa9d5969437&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-messages/tickets/2.mdwn;h=e4e35c75ededb220d4ee788abd52f17ab0510352;hp=b97c3b915afa5aee1527549c97939c20979e11ba;hb=f65b75264b89071970cf00ff16776aa9d5969437;hpb=b0d2b4a707f9b0bbe5373a5ad960487b66142b41&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Firc-fun-messages%2Ftickets%2F2&quot;
> rel=&quot;nofollow&quot;&gt;projects/irc-fun-messages/tickets/2&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;09:12:23 AM 07/20/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=f65b75264b89071970cf00ff16776aa9d5969437&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +irc-fun-messages: rearrangemet done&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to templates/my-open-tickets on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_b0d2b4a707f9b0bbe5373a5ad960487b66142b41/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-b0d2b4a707f9b0bbe5373a5ad960487b66142b41
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-20T09:09:43Z</updated>
> +       <published>2015-07-20T09:09:43Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-b0d2b4a707f9b0bbe5373a5ad960487b66142b41&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/my-open-tickets.mdwn;h=d5fc4b5cd9696f21ab75842518f2b7a4f5fd2ebc;hp=6508a11cf60dd90ba71b998848e829d385c495d2;hb=b0d2b4a707f9b0bbe5373a5ad960487b66142b41;hpb=7bc4f88b58f7f0deadb8a79a9823a564cf399b03&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Fmy-open-tickets&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;templates/my-open-tickets&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;09:09:43 AM 07/20/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=b0d2b4a707f9b0bbe5373a5ad960487b66142b41&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +fix template typo&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to people/fr33domlover on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_7bc4f88b58f7f0deadb8a79a9823a564cf399b03/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-7bc4f88b58f7f0deadb8a79a9823a564cf399b03
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-20T09:06:01Z</updated>
> +       <published>2015-07-20T09:06:01Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-7bc4f88b58f7f0deadb8a79a9823a564cf399b03&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=people/fr33domlover.mdwn;h=2230d818ac803844191d7842bcb24fa4d5e45e14;hp=f28b90121dbd2ea1427b476ec65ac299d5a362a7;hb=7bc4f88b58f7f0deadb8a79a9823a564cf399b03;hpb=e970fbaa161547af8a7b378220a602c00c128b20&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;people/fr33domlover&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;09:06:01 AM 07/20/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=7bc4f88b58f7f0deadb8a79a9823a564cf399b03&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +me: use the new template for personal tickets&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to templates/my-open-tickets templates/ticket
> tickets on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_e970fbaa161547af8a7b378220a602c00c128b20/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-e970fbaa161547af8a7b378220a602c00c128b20
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-20T09:02:35Z</updated>
> +       <published>2015-07-20T09:02:35Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-e970fbaa161547af8a7b378220a602c00c128b20&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/my-open-tickets.mdwn;h=6508a11cf60dd90ba71b998848e829d385c495d2;hp=0000000000000000000000000000000000000000;hb=e970fbaa161547af8a7b378220a602c00c128b20;hpb=f650bd6d11c9f12fa342e32a1112e0326f5983a0&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Fmy-open-tickets&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;templates/my-open-tickets&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/ticket.mdwn;h=69a8e86734dca4aec465f6d7fc4f7d6b958e9a51;hp=7adaf50d169a1a3e068b272427c5ccd010b304ea;hb=e970fbaa161547af8a7b378220a602c00c128b20;hpb=f650bd6d11c9f12fa342e32a1112e0326f5983a0&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Fticket&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;templates/ticket&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=tickets.mdwn;h=3b3e0f3959d65e0100c507940f20921dbad4220a;hp=b28306347b2b49e222ec75f0610cfceff8ff7598;hb=e970fbaa161547af8a7b378220a602c00c128b20;hpb=f650bd6d11c9f12fa342e32a1112e0326f5983a0&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=tickets&quot;
> rel=&quot;nofollow&quot;&gt;tickets&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;09:02:35 AM 07/20/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=e970fbaa161547af8a7b378220a602c00c128b20&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +new template my-open-tickets&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to tickets on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_f650bd6d11c9f12fa342e32a1112e0326f5983a0/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-f650bd6d11c9f12fa342e32a1112e0326f5983a0
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-20T07:58:09Z</updated>
> +       <published>2015-07-20T07:58:09Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-f650bd6d11c9f12fa342e32a1112e0326f5983a0&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=tickets.mdwn;h=b28306347b2b49e222ec75f0610cfceff8ff7598;hp=bfc33e243c877bdc29e26067fcccf60865b950f8;hb=f650bd6d11c9f12fa342e32a1112e0326f5983a0;hpb=62e6b115766812a8b7dc1661af21071b300ecf9d&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=tickets&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;tickets&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;07:58:09 AM 07/20/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=f650bd6d11c9f12fa342e32a1112e0326f5983a0&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +tickets: add some notes and hints&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/tickets/2 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_62e6b115766812a8b7dc1661af21071b300ecf9d/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-62e6b115766812a8b7dc1661af21071b300ecf9d
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-20T07:26:24Z</updated>
> +       <published>2015-07-20T07:26:24Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-62e6b115766812a8b7dc1661af21071b300ecf9d&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/2.mdwn;h=2db571641ae6d30d6d74d401e2e96015b833b811;hp=ddf42fa6367bcebe483831befd8a9739a418eb69;hb=62e6b115766812a8b7dc1661af21071b300ecf9d;hpb=d1a178ecde1695f74f21132068fa479443fd364f&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F2&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/2&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;07:26:24 AM 07/20/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=62e6b115766812a8b7dc1661af21071b300ecf9d&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: list options for persistence&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/tickets/2 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_d1a178ecde1695f74f21132068fa479443fd364f/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-d1a178ecde1695f74f21132068fa479443fd364f
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-19T21:12:25Z</updated>
> +       <published>2015-07-19T21:12:25Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-d1a178ecde1695f74f21132068fa479443fd364f&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/2.mdwn;h=ddf42fa6367bcebe483831befd8a9739a418eb69;hp=767aaad5c981d66c8cc3f76b8ffd0b8a172c5840;hb=d1a178ecde1695f74f21132068fa479443fd364f;hpb=9aacf3255d7b2d65ff1a4a3e564e0cc35df5864a&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F2&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/2&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;09:12:25 PM 07/19/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=d1a178ecde1695f74f21132068fa479443fd364f&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: notes on persistent state&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to people/fr33domlover/blog/insanity on
> Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_9aacf3255d7b2d65ff1a4a3e564e0cc35df5864a/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-9aacf3255d7b2d65ff1a4a3e564e0cc35df5864a
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-19T20:28:42Z</updated>
> +       <published>2015-07-19T20:28:42Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-9aacf3255d7b2d65ff1a4a3e564e0cc35df5864a&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=people/fr33domlover/blog/insanity.mdwn;h=ebaa53ca277a0e595b242642aeed217a2d596b54;hp=0000000000000000000000000000000000000000;hb=9aacf3255d7b2d65ff1a4a3e564e0cc35df5864a;hpb=6f2e5495944f200e1e6dd231d85ecbdfbb1aa372&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover%2Fblog%2Finsanity&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;people/fr33domlover/blog/insanity&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;08:28:42 PM 07/19/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=9aacf3255d7b2d65ff1a4a3e564e0cc35df5864a&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +me: some blog post...&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to templates/ticket-depends-on on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_6f2e5495944f200e1e6dd231d85ecbdfbb1aa372/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-6f2e5495944f200e1e6dd231d85ecbdfbb1aa372
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-19T09:26:58Z</updated>
> +       <published>2015-07-19T09:26:58Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-6f2e5495944f200e1e6dd231d85ecbdfbb1aa372&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/ticket-depends-on.mdwn;h=f83eb1c67a3ccac4e181ab4fba9a9dff0a6b6a80;hp=a7f05948f92be66460fa39f2d7ac61c863886994;hb=6f2e5495944f200e1e6dd231d85ecbdfbb1aa372;hpb=b3db4bb425ef79edc4269c0ad57e47685eb888b7&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Fticket-depends-on&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;templates/ticket-depends-on&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;09:26:58 AM 07/19/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=6f2e5495944f200e1e6dd231d85ecbdfbb1aa372&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +if failing, at least fail explicitly&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to templates/ticket-depends-on on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_b3db4bb425ef79edc4269c0ad57e47685eb888b7/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-b3db4bb425ef79edc4269c0ad57e47685eb888b7
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-19T09:15:03Z</updated>
> +       <published>2015-07-19T09:15:03Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-b3db4bb425ef79edc4269c0ad57e47685eb888b7&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/ticket-depends-on.mdwn;h=a7f05948f92be66460fa39f2d7ac61c863886994;hp=0279afa3d1b2bb1796ba9e32955894c6e8436c5e;hb=b3db4bb425ef79edc4269c0ad57e47685eb888b7;hpb=5b2a8e163184284378d48d2419134d6f5e4fabbe&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=templates%2Fticket-depends-on&quot;
> rel=&quot;nofollow&quot;&gt;templates/ticket-depends-on&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;09:15:03 AM 07/19/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=b3db4bb425ef79edc4269c0ad57e47685eb888b7&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +last try, I have no idea about those variables&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to templates/ticket-depends-on on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_5b2a8e163184284378d48d2419134d6f5e4fabbe/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-5b2a8e163184284378d48d2419134d6f5e4fabbe
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-19T09:00:55Z</updated>
> +       <published>2015-07-19T09:00:55Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-5b2a8e163184284378d48d2419134d6f5e4fabbe&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/ticket-depends-on.mdwn;h=0279afa3d1b2bb1796ba9e32955894c6e8436c5e;hp=6e5d9e5744a8b7f07502689526a0bb398df695a6;hb=5b2a8e163184284378d48d2419134d6f5e4fabbe;hpb=476809c178ec0873f4580309443add856c64f339&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Fticket-depends-on&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;templates/ticket-depends-on&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;09:00:55 AM 07/19/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=5b2a8e163184284378d48d2419134d6f5e4fabbe&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +try again&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to templates/ticket-depends-on on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_476809c178ec0873f4580309443add856c64f339/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-476809c178ec0873f4580309443add856c64f339
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-19T08:43:09Z</updated>
> +       <published>2015-07-19T08:43:09Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-476809c178ec0873f4580309443add856c64f339&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/ticket-depends-on.mdwn;h=6e5d9e5744a8b7f07502689526a0bb398df695a6;hp=f83eb1c67a3ccac4e181ab4fba9a9dff0a6b6a80;hb=476809c178ec0873f4580309443add856c64f339;hpb=42242ce1aeb36d653d3312ee46603ca1baeb5f78&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Fticket-depends-on&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;templates/ticket-depends-on&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;08:43:09 AM 07/19/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=476809c178ec0873f4580309443add856c64f339&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +try to fix local ticket dependency template&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/irc-fun-bot/tickets/5 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_42242ce1aeb36d653d3312ee46603ca1baeb5f78/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-42242ce1aeb36d653d3312ee46603ca1baeb5f78
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-19T00:52:24Z</updated>
> +       <published>2015-07-19T00:52:24Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-42242ce1aeb36d653d3312ee46603ca1baeb5f78&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/5.mdwn;h=b9debec3ded1ba8f5151f21acfc3ce6f340f9d06;hp=0e5a1030b7c2ef5dbd1c505352d9172e94bf04d3;hb=42242ce1aeb36d653d3312ee46603ca1baeb5f78;hpb=bd0e46e488bbeb8b216f6ab1aefd98083ec61f16&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-bot%2Ftickets%2F5&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/irc-fun-bot/tickets/5&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;12:52:24 AM 07/19/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=42242ce1aeb36d653d3312ee46603ca1baeb5f78&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +fix typo&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/irc-fun-bot/tickets/5 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_bd0e46e488bbeb8b216f6ab1aefd98083ec61f16/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-bd0e46e488bbeb8b216f6ab1aefd98083ec61f16
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-19T00:48:08Z</updated>
> +       <published>2015-07-19T00:48:08Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-bd0e46e488bbeb8b216f6ab1aefd98083ec61f16&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/5.mdwn;h=0e5a1030b7c2ef5dbd1c505352d9172e94bf04d3;hp=fac452baf181d140dfd541dd3e348b03f4387a1a;hb=bd0e46e488bbeb8b216f6ab1aefd98083ec61f16;hpb=e048d2ba90a4e6f94784c809618051f00a863627&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-bot%2Ftickets%2F5&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/irc-fun-bot/tickets/5&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;12:48:08 AM 07/19/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=bd0e46e488bbeb8b216f6ab1aefd98083ec61f16&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +irc-fun-bot: close ticket 5, user tracking works&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to templates/tktref on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_e048d2ba90a4e6f94784c809618051f00a863627/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-e048d2ba90a4e6f94784c809618051f00a863627
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-18T16:18:02Z</updated>
> +       <published>2015-07-18T16:18:02Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-e048d2ba90a4e6f94784c809618051f00a863627&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/tktref.mdwn;h=a0c97a7571758f0b9ecbdd87da123ddc23e3add3;hp=fc64ea4a97b82588f1cb5c72d9875cbedc196f6b;hb=e048d2ba90a4e6f94784c809618051f00a863627;hpb=64fc69565cd08b8438d34b6453840eec6c328677&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Ftktref&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;templates/tktref&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;04:18:02 PM 07/18/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=e048d2ba90a4e6f94784c809618051f00a863627&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +try to fix tktlink rendering&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/irc-fun-bot/tickets/5
> projects/irc-fun-messages/tickets/1 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_64fc69565cd08b8438d34b6453840eec6c328677/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-64fc69565cd08b8438d34b6453840eec6c328677
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-18T16:13:16Z</updated>
> +       <published>2015-07-18T16:13:16Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-64fc69565cd08b8438d34b6453840eec6c328677&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/5.mdwn;h=fac452baf181d140dfd541dd3e348b03f4387a1a;hp=c3fda7dceeea8bd5b28f491e969db289e813a59a;hb=64fc69565cd08b8438d34b6453840eec6c328677;hpb=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Firc-fun-bot%2Ftickets%2F5&quot;
> rel=&quot;nofollow&quot;&gt;projects/irc-fun-bot/tickets/5&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-messages/tickets/1.mdwn;h=b591bb5228526e4e0c28619d1d51642bd35db0ca;hp=9ef221af24707831f812d2a735fcfa1ed60c2188;hb=64fc69565cd08b8438d34b6453840eec6c328677;hpb=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-messages%2Ftickets%2F1&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/irc-fun-messages/tickets/1&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;04:13:16 PM 07/18/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=64fc69565cd08b8438d34b6453840eec6c328677&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +irc-fun-*: reply analysis added, now track nicknames&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects projects/irc-fun-color
> projects/irc-fun-color/decisions projects/irc-fun-color/forum
> projects/irc-fun-color/news projects/irc-fun-color/releases
> projects/irc-fun-color/tickets on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-18T15:08:45Z</updated>
> +       <published>2015-07-18T15:08:45Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects.mdwn;h=9d82d759e2e847c0b174cf1bbe7f57d75c14474f;hp=2f60c659996eb1080d7af967e9041d62d77d84c9;hb=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8;hpb=3d1ea877911070c0d95bb46c10568bde7b956ae6&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-color.mdwn;h=55a94ef29608a2cf99061cfff38117975ad31fa3;hp=0000000000000000000000000000000000000000;hb=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8;hpb=3d1ea877911070c0d95bb46c10568bde7b956ae6&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Firc-fun-color&quot;
> rel=&quot;nofollow&quot;&gt;projects/irc-fun-color&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-color/decisions.mdwn;h=86674bf28a1eac5aa6a8f6bf02a5f3611fae5afe;hp=0000000000000000000000000000000000000000;hb=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8;hpb=3d1ea877911070c0d95bb46c10568bde7b956ae6&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-color%2Fdecisions&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/irc-fun-color/decisions&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-color/forum.mdwn;h=f297d56c4a7e9099c511dafd8deeec28222e3e17;hp=0000000000000000000000000000000000000000;hb=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8;hpb=3d1ea877911070c0d95bb46c10568bde7b956ae6&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Firc-fun-color%2Fforum&quot;
> rel=&quot;nofollow&quot;&gt;projects/irc-fun-color/forum&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-color/news.mdwn;h=330c55f6fd7f2c4a010044249adcb5456d9658a3;hp=0000000000000000000000000000000000000000;hb=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8;hpb=3d1ea877911070c0d95bb46c10568bde7b956ae6&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-color%2Fnews&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/irc-fun-color/news&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-color/releases.mdwn;h=57e5729d6313d999900ce903adcc35389f4686bb;hp=0000000000000000000000000000000000000000;hb=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8;hpb=3d1ea877911070c0d95bb46c10568bde7b956ae6&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-color%2Freleases&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/irc-fun-color/releases&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-color/tickets.mdwn;h=707729b4f5edb530c7493f701639e14441ece6fb;hp=0000000000000000000000000000000000000000;hb=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8;hpb=3d1ea877911070c0d95bb46c10568bde7b956ae6&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Firc-fun-color%2Ftickets&quot;
> rel=&quot;nofollow&quot;&gt;projects/irc-fun-color/tickets&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;03:08:45 PM 07/18/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +irc-fun-color: new project&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to templates/ticket-depends-on on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_3d1ea877911070c0d95bb46c10568bde7b956ae6/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-3d1ea877911070c0d95bb46c10568bde7b956ae6
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-17T12:13:32Z</updated>
> +       <published>2015-07-17T12:13:32Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-3d1ea877911070c0d95bb46c10568bde7b956ae6&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/ticket-depends-on.mdwn;h=f83eb1c67a3ccac4e181ab4fba9a9dff0a6b6a80;hp=36db3bfac2156cf7980068af0606bf464cd5b6ec;hb=3d1ea877911070c0d95bb46c10568bde7b956ae6;hpb=5361eae41a1dbd74b511f97df16687a0278063d6&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Fticket-depends-on&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;templates/ticket-depends-on&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;12:13:32 PM 07/17/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=3d1ea877911070c0d95bb46c10568bde7b956ae6&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +template: try to make ticket-depends-on render as a single line&lt;br
> /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to templates/tktref on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_5361eae41a1dbd74b511f97df16687a0278063d6/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-5361eae41a1dbd74b511f97df16687a0278063d6
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-17T12:07:39Z</updated>
> +       <published>2015-07-17T12:07:39Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-5361eae41a1dbd74b511f97df16687a0278063d6&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/tktref.mdwn;h=fc64ea4a97b82588f1cb5c72d9875cbedc196f6b;hp=cc3d879c0f434325cf3e0a35768810a4d4c40cb3;hb=5361eae41a1dbd74b511f97df16687a0278063d6;hpb=8acf634f485a70e7f54faa48d5ceaff705849359&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=templates%2Ftktref&quot;
> rel=&quot;nofollow&quot;&gt;templates/tktref&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;12:07:39 PM 07/17/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=5361eae41a1dbd74b511f97df16687a0278063d6&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +templates: fix typo in tktref&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to templates/ticket-dependants templates/ticket on
> Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_8acf634f485a70e7f54faa48d5ceaff705849359/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-8acf634f485a70e7f54faa48d5ceaff705849359
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-17T11:59:11Z</updated>
> +       <published>2015-07-17T11:59:11Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-8acf634f485a70e7f54faa48d5ceaff705849359&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/ticket-dependants.mdwn;h=8996711ad0b53f3acc95eb2fb577260f56f99589;hp=0000000000000000000000000000000000000000;hb=8acf634f485a70e7f54faa48d5ceaff705849359;hpb=4826e57427eb5fdc542b22534276401ef0e0a6bb&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=templates%2Fticket-dependants&quot;
> rel=&quot;nofollow&quot;&gt;templates/ticket-dependants&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/ticket.mdwn;h=7adaf50d169a1a3e068b272427c5ccd010b304ea;hp=cc70c7b4bcf5718cf457b8bc8f9760c3c2dec296;hb=8acf634f485a70e7f54faa48d5ceaff705849359;hpb=4826e57427eb5fdc542b22534276401ef0e0a6bb&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Fticket&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;templates/ticket&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;11:59:11 AM 07/17/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=8acf634f485a70e7f54faa48d5ceaff705849359&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +add ticket reverse dependencies using tags&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/tickets/10
> projects/funbot/tickets/3 projects/funbot/tickets/5 projects/idan/tickets/4
> projects/irc-fun-bot/tickets/5
> projects/sif/tickets/Remove_doxy_references_to_nonfree_browsers
> projects/sif/tickets/Remove_unused_doxy_images templates/ticket-depends-on
> on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_4826e57427eb5fdc542b22534276401ef0e0a6bb/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-4826e57427eb5fdc542b22534276401ef0e0a6bb
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-17T11:27:55Z</updated>
> +       <published>2015-07-17T11:27:55Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-4826e57427eb5fdc542b22534276401ef0e0a6bb&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/10.mdwn;h=7db97bbee99f558e4dc6164e60ef81504d4afe24;hp=f679a8578818b1b59ef502b4e83d972a2696ba2a;hb=4826e57427eb5fdc542b22534276401ef0e0a6bb;hpb=2a4c41ea9590cd73e0aec952e93f745172a32217&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F10&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/10&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/3.mdwn;h=111efa1b015906623afc28c27ee52742a7cddbd8;hp=09da3b9886f12272ba40bde42dcb4ebbd0846de9;hb=4826e57427eb5fdc542b22534276401ef0e0a6bb;hpb=2a4c41ea9590cd73e0aec952e93f745172a32217&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F3&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/3&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/5.mdwn;h=606f28657913248cbfe3204aa6f0ffebec656b55;hp=f605f0ecc0227205dad3b5d4b16c4fdb85df5eb5;hb=4826e57427eb5fdc542b22534276401ef0e0a6bb;hpb=2a4c41ea9590cd73e0aec952e93f745172a32217&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F5&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/5&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/idan/tickets/4.mdwn;h=a4e6bd9fb63289481b2ebea90b374aa0236a604a;hp=e4f1d49482e7e2c66e404a9a0efcdc0bfb29950d;hb=4826e57427eb5fdc542b22534276401ef0e0a6bb;hpb=2a4c41ea9590cd73e0aec952e93f745172a32217&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fidan%2Ftickets%2F4&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/idan/tickets/4&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/5.mdwn;h=c3fda7dceeea8bd5b28f491e969db289e813a59a;hp=215a25f288dfeb80ea06314a6c1b860a1476622e;hb=4826e57427eb5fdc542b22534276401ef0e0a6bb;hpb=2a4c41ea9590cd73e0aec952e93f745172a32217&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Firc-fun-bot%2Ftickets%2F5&quot;
> rel=&quot;nofollow&quot;&gt;projects/irc-fun-bot/tickets/5&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/sif/tickets/Remove_doxy_references_to_nonfree_browsers.mdwn;h=944fb3a116e57ee64af34d891fa43327468b0228;hp=5b6919b3d065d46f997e6abb1f63130978a5e9af;hb=4826e57427eb5fdc542b22534276401ef0e0a6bb;hpb=2a4c41ea9590cd73e0aec952e93f745172a32217&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fsif%2Ftickets%2FRemove_doxy_references_to_nonfree_browsers&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/sif/tickets/Remove doxy references to
> nonfree browsers&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/sif/tickets/Remove_unused_doxy_images.mdwn;h=7f4205dd1dd777bbbf86e08147e73c427c66d984;hp=c54d10be8cc161461d2d1b535b29043cdbdb9fb6;hb=4826e57427eb5fdc542b22534276401ef0e0a6bb;hpb=2a4c41ea9590cd73e0aec952e93f745172a32217&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fsif%2Ftickets%2FRemove_unused_doxy_images&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/sif/tickets/Remove unused doxy
> images&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/ticket-depends-on.mdwn;h=36db3bfac2156cf7980068af0606bf464cd5b6ec;hp=55583bce2cd010f8cf8b3271621428169d3b57a2;hb=4826e57427eb5fdc542b22534276401ef0e0a6bb;hpb=2a4c41ea9590cd73e0aec952e93f745172a32217&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Fticket-depends-on&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;templates/ticket-depends-on&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;11:27:55 AM 07/17/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=4826e57427eb5fdc542b22534276401ef0e0a6bb&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +templates: hopefully improve ticket-depends-on&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/irc-fun-bot/tickets/5
> projects/irc-fun-messages/tickets/1 projects/irc-fun-messages/tickets/2 on
> Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_2a4c41ea9590cd73e0aec952e93f745172a32217/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-2a4c41ea9590cd73e0aec952e93f745172a32217
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-17T10:45:46Z</updated>
> +       <published>2015-07-17T10:45:46Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-2a4c41ea9590cd73e0aec952e93f745172a32217&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/5.mdwn;h=215a25f288dfeb80ea06314a6c1b860a1476622e;hp=9c3b99793d6df15691e519bd472b674b37b871a6;hb=2a4c41ea9590cd73e0aec952e93f745172a32217;hpb=8fb78e1a159821745b973337a7267635a536f3fc&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Firc-fun-bot%2Ftickets%2F5&quot;
> rel=&quot;nofollow&quot;&gt;projects/irc-fun-bot/tickets/5&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-messages/tickets/1.mdwn;h=9ef221af24707831f812d2a735fcfa1ed60c2188;hp=0000000000000000000000000000000000000000;hb=2a4c41ea9590cd73e0aec952e93f745172a32217;hpb=8fb78e1a159821745b973337a7267635a536f3fc&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Firc-fun-messages%2Ftickets%2F1&quot;
> rel=&quot;nofollow&quot;&gt;projects/irc-fun-messages/tickets/1&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-messages/tickets/2.mdwn;h=b97c3b915afa5aee1527549c97939c20979e11ba;hp=0000000000000000000000000000000000000000;hb=2a4c41ea9590cd73e0aec952e93f745172a32217;hpb=8fb78e1a159821745b973337a7267635a536f3fc&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-messages%2Ftickets%2F2&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/irc-fun-messages/tickets/2&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;10:45:46 AM 07/17/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=2a4c41ea9590cd73e0aec952e93f745172a32217&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +irc-fun-messages: open tickets for work being done&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/tickets/14
> projects/irc-fun-bot/tickets/6 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_8fb78e1a159821745b973337a7267635a536f3fc/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-8fb78e1a159821745b973337a7267635a536f3fc
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-16T12:50:22Z</updated>
> +       <published>2015-07-16T12:50:22Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-8fb78e1a159821745b973337a7267635a536f3fc&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/14.mdwn;h=ec589115c87f1e070cf74a0e74bd88fa16320fd5;hp=0000000000000000000000000000000000000000;hb=8fb78e1a159821745b973337a7267635a536f3fc;hpb=18355348f643f521d5172530761ce01abe472ed9&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F14&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/14&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/6.mdwn;h=dc30d1b5dbb1e84f25aebe68f2a00c626870469b;hp=0000000000000000000000000000000000000000;hb=8fb78e1a159821745b973337a7267635a536f3fc;hpb=18355348f643f521d5172530761ce01abe472ed9&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-bot%2Ftickets%2F6&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/irc-fun-bot/tickets/6&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;12:50:22 PM 07/16/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=8fb78e1a159821745b973337a7267635a536f3fc&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: tickets for Tox and OTR support&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/irc-fun-bot/tickets/5 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_18355348f643f521d5172530761ce01abe472ed9/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-18355348f643f521d5172530761ce01abe472ed9
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-15T12:43:41Z</updated>
> +       <published>2015-07-15T12:43:41Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-18355348f643f521d5172530761ce01abe472ed9&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/5.mdwn;h=9c3b99793d6df15691e519bd472b674b37b871a6;hp=17f55a86e0f23d45f9b2edb4f6daec60c2dc0d82;hb=18355348f643f521d5172530761ce01abe472ed9;hpb=143590cacdab92492eb6a14e53c9810f4432cd4b&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Firc-fun-bot%2Ftickets%2F5&quot;
> rel=&quot;nofollow&quot;&gt;projects/irc-fun-bot/tickets/5&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;12:43:41 PM 07/15/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=18355348f643f521d5172530761ce01abe472ed9&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +irc-fun-bot: notes on online user tracking&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/irc-fun-bot/tickets/4 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_143590cacdab92492eb6a14e53c9810f4432cd4b/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-143590cacdab92492eb6a14e53c9810f4432cd4b
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-15T12:28:53Z</updated>
> +       <published>2015-07-15T12:28:53Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-143590cacdab92492eb6a14e53c9810f4432cd4b&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/4.mdwn;h=de50db2d43720e278918b08a15a70fb01065310c;hp=861efebe845edc70875723113005c9292a8181a6;hb=143590cacdab92492eb6a14e53c9810f4432cd4b;hpb=1d7deccdc53477739f5f644a14ddfc08276eb330&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Firc-fun-bot%2Ftickets%2F4&quot;
> rel=&quot;nofollow&quot;&gt;projects/irc-fun-bot/tickets/4&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;12:28:53 PM 07/15/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=143590cacdab92492eb6a14e53c9810f4432cd4b&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +irc-fun-bot: close ticket 4, event handling implemented&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to templates/commit templates/record on
> Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_1d7deccdc53477739f5f644a14ddfc08276eb330/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-1d7deccdc53477739f5f644a14ddfc08276eb330
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-15T12:28:19Z</updated>
> +       <published>2015-07-15T12:28:19Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-1d7deccdc53477739f5f644a14ddfc08276eb330&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/commit.mdwn;h=2216a0ee714109c1860d714832f0a8e1935bdc0a;hp=e715dab0360f63da76233aa8d6018cb5511dd183;hb=1d7deccdc53477739f5f644a14ddfc08276eb330;hpb=74e38e99ab317f66273387b40a96f3817a9a269f&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=templates%2Fcommit&quot;
> rel=&quot;nofollow&quot;&gt;templates/commit&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/record.mdwn;h=b6d048ab252338b6994ea0ee8b04b73db7a4a778;hp=cf2916d42321a35e788ca8121243e4e3e9a1ca3c;hb=1d7deccdc53477739f5f644a14ddfc08276eb330;hpb=74e38e99ab317f66273387b40a96f3817a9a269f&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Frecord&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;templates/record&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;12:28:19 PM 07/15/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=1d7deccdc53477739f5f644a14ddfc08276eb330&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +templates: update record template link text&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to templates/commit templates/record on
> Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_74e38e99ab317f66273387b40a96f3817a9a269f/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-74e38e99ab317f66273387b40a96f3817a9a269f
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-15T11:38:43Z</updated>
> +       <published>2015-07-15T11:38:43Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-74e38e99ab317f66273387b40a96f3817a9a269f&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/commit.mdwn;h=e715dab0360f63da76233aa8d6018cb5511dd183;hp=0000000000000000000000000000000000000000;hb=74e38e99ab317f66273387b40a96f3817a9a269f;hpb=54fd05dc71003ad59211bf218528dd21f1386759&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=templates%2Fcommit&quot;
> rel=&quot;nofollow&quot;&gt;templates/commit&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/record.mdwn;h=cf2916d42321a35e788ca8121243e4e3e9a1ca3c;hp=0000000000000000000000000000000000000000;hb=74e38e99ab317f66273387b40a96f3817a9a269f;hpb=54fd05dc71003ad59211bf218528dd21f1386759&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Frecord&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;templates/record&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;11:38:43 AM 07/15/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=74e38e99ab317f66273387b40a96f3817a9a269f&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +templates: add git/darcs record templates&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/guide on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_54fd05dc71003ad59211bf218528dd21f1386759/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-54fd05dc71003ad59211bf218528dd21f1386759
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-15T11:38:19Z</updated>
> +       <published>2015-07-15T11:38:19Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-54fd05dc71003ad59211bf218528dd21f1386759&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/guide.mdwn;h=9d46ed7be13811c424111b5f29dc6ef641e5754a;hp=ac4c2f5842f1194f7e20148f70c265952cb990f9;hb=54fd05dc71003ad59211bf218528dd21f1386759;hpb=07d23f596ab3b6281acdd9f80768ab64b014bd49&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Fguide&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/guide&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;11:38:19 AM 07/15/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=54fd05dc71003ad59211bf218528dd21f1386759&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: add list of API features to the guide&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/irc-fun-bot/tickets/4 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_07d23f596ab3b6281acdd9f80768ab64b014bd49/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-07d23f596ab3b6281acdd9f80768ab64b014bd49
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-15T00:24:59Z</updated>
> +       <published>2015-07-15T00:24:59Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-07d23f596ab3b6281acdd9f80768ab64b014bd49&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/4.mdwn;h=861efebe845edc70875723113005c9292a8181a6;hp=4cda87eb8f895f7dee560b8df646d1c7d5e4601a;hb=07d23f596ab3b6281acdd9f80768ab64b014bd49;hpb=2f5ca460f67dbbb1503a8bcf0a0f1a815f90ed9a&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Firc-fun-bot%2Ftickets%2F4&quot;
> rel=&quot;nofollow&quot;&gt;projects/irc-fun-bot/tickets/4&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;12:24:59 AM 07/15/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=07d23f596ab3b6281acdd9f80768ab64b014bd49&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +irc-fun-bot: more notes on ticket 4: events types&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/tickets/13 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_2f5ca460f67dbbb1503a8bcf0a0f1a815f90ed9a/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-2f5ca460f67dbbb1503a8bcf0a0f1a815f90ed9a
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-15T00:04:20Z</updated>
> +       <published>2015-07-15T00:04:20Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-2f5ca460f67dbbb1503a8bcf0a0f1a815f90ed9a&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/13.mdwn;h=b6905577f100cfddf71d2589136637129d7016a1;hp=0000000000000000000000000000000000000000;hb=2f5ca460f67dbbb1503a8bcf0a0f1a815f90ed9a;hpb=efaad54e5facfab7d5048a058407a733b987f877&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F13&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/13&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;12:04:20 AM 07/15/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=2f5ca460f67dbbb1503a8bcf0a0f1a815f90ed9a&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: new ticket: collecting quotes&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/irc-fun-bot/tickets/4 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_efaad54e5facfab7d5048a058407a733b987f877/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-efaad54e5facfab7d5048a058407a733b987f877
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-14T23:48:18Z</updated>
> +       <published>2015-07-14T23:48:18Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-efaad54e5facfab7d5048a058407a733b987f877&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/4.mdwn;h=4cda87eb8f895f7dee560b8df646d1c7d5e4601a;hp=d3eb459357a0fe4b6922f45adfaabf25f6753d68;hb=efaad54e5facfab7d5048a058407a733b987f877;hpb=ca1c11f89649f6d8e2ee1e875edf2c4232447c92&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-bot%2Ftickets%2F4&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/irc-fun-bot/tickets/4&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;11:48:18 PM 07/14/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=efaad54e5facfab7d5048a058407a733b987f877&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +irc-fun-bot: thoughts on ticket 4&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to people/fr33domlover on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_ca1c11f89649f6d8e2ee1e875edf2c4232447c92/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-ca1c11f89649f6d8e2ee1e875edf2c4232447c92
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-13T19:56:20Z</updated>
> +       <published>2015-07-13T19:56:20Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-ca1c11f89649f6d8e2ee1e875edf2c4232447c92&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=people/fr33domlover.mdwn;h=f28b90121dbd2ea1427b476ec65ac299d5a362a7;hp=6f209d9fe79aaea43836b9e010f6879ef7428cbc;hb=ca1c11f89649f6d8e2ee1e875edf2c4232447c92;hpb=6d3a6ade9202b71c87723db5d8d99f95625995d0&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;people/fr33domlover&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;07:56:20 PM 07/13/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=ca1c11f89649f6d8e2ee1e875edf2c4232447c92&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +me: not anymore&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/manual projects/funbot/tickets/9
> on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_6d3a6ade9202b71c87723db5d8d99f95625995d0/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-6d3a6ade9202b71c87723db5d8d99f95625995d0
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-13T16:31:31Z</updated>
> +       <published>2015-07-13T16:31:31Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-6d3a6ade9202b71c87723db5d8d99f95625995d0&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/manual.mdwn;h=f179ef3cc7731f76ad0bae8b31a4e64a3f8d6871;hp=c664554baaa6d752bb6412372ae3e03c25f88691;hb=6d3a6ade9202b71c87723db5d8d99f95625995d0;hpb=75eade8953e45278446e742d970840fd5686a759&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Fmanual&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/manual&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/9.mdwn;h=f3728f733ee4e81e0cf9e6aa40df787378449c85;hp=1dcfa08f772cc596392b61eaed26d494b37f4e17;hb=6d3a6ade9202b71c87723db5d8d99f95625995d0;hpb=75eade8953e45278446e742d970840fd5686a759&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F9&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/9&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;04:31:31 PM 07/13/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=6d3a6ade9202b71c87723db5d8d99f95625995d0&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +funbot: finish manual and close ticket 9, Jookia&amp;#39;s patch applied
> - thanks!&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/funbot/tickets/9 on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_75eade8953e45278446e742d970840fd5686a759/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-75eade8953e45278446e742d970840fd5686a759
> "/>
> +
> +       <author><name>jookia</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-13T15:29:57Z</updated>
> +       <published>2015-07-13T15:29:57Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-75eade8953e45278446e742d970840fd5686a759&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/9.mdwn;h=1dcfa08f772cc596392b61eaed26d494b37f4e17;hp=b5300d432f0b164e9ddd5cf70630ec04caca47c6;hb=75eade8953e45278446e742d970840fd5686a759;hpb=660f57dbd862851e014100f04657b9b9f20bd8dd&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F9&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/9&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Fjookia&quot;
> rel=&quot;nofollow&quot;&gt;jookia&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;web&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;03:29:57 PM 07/13/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=75eade8953e45278446e742d970840fd5686a759&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to
> projects/funbot/tickets/9/0001-info-Add-copying-information.patch on
> Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_660f57dbd862851e014100f04657b9b9f20bd8dd/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-660f57dbd862851e014100f04657b9b9f20bd8dd
> "/>
> +
> +       <author><name>jookia</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-13T15:25:55Z</updated>
> +       <published>2015-07-13T15:25:55Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-660f57dbd862851e014100f04657b9b9f20bd8dd&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/9/0001-info-Add-copying-information.patch;h=1c6b87a3543f57c62bc123bc441be563c0a18a75;hp=0000000000000000000000000000000000000000;hb=660f57dbd862851e014100f04657b9b9f20bd8dd;hpb=69a4b71b5f5359915ae8a9c17cd12778e577267b&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=projects%2Ffunbot%2Ftickets%2F9%2F0001-info-Add-copying-information.patch&quot;
> rel=&quot;nofollow&quot;&gt;projects/funbot/tickets/9/0001-info-Add-copying-information.patch&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=people%2Fjookia&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;jookia&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;web&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;03:25:55 PM 07/13/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?rev=660f57dbd862851e014100f04657b9b9f20bd8dd&amp;amp;do=revert&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +attachment upload&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +<entry>
> +       <title>change to projects/libravatar projects/libravatar/tickets/1
> projects/libravatar/tickets/Please_provide_sample_code on Rel4tion</title>
> +
> +       <id>
> http://www.rel4tion.org/recentchanges/change_69a4b71b5f5359915ae8a9c17cd12778e577267b/
> </id>
> +
> +       <link href="
> http://www.rel4tion.org/recentchanges/#change-69a4b71b5f5359915ae8a9c17cd12778e577267b
> "/>
> +
> +       <author><name>fr33domlover</name></author>
> +
> +
> +
> +
> +
> +       <updated>2015-07-13T14:57:10Z</updated>
> +       <published>2015-07-13T14:57:10Z</published>
> +
> +
> +       <content type="html" xml:lang="en">
> +
> +
> +
> +
> +
> +
> +
> +
> +&lt;div id=&quot;change-69a4b71b5f5359915ae8a9c17cd12778e577267b&quot;
> class=&quot;metadata&quot;&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed pages:&lt;/span&gt;
> +&lt;span class=&quot;pagelinks&quot;&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/libravatar.mdwn;h=da1600f753365123dc129bbbb8d306aa48b76e04;hp=a462742b8577f6ceedb5ce392b9b5fd7a56c97af;hb=69a4b71b5f5359915ae8a9c17cd12778e577267b;hpb=af63fb6ef0b0df0490b806b41ca018701e7eb586&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Flibravatar&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/libravatar&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/libravatar/tickets/1.mdwn;h=be178d41ce929dd13f79a42efdce42814cfd781c;hp=0000000000000000000000000000000000000000;hb=69a4b71b5f5359915ae8a9c17cd12778e577267b;hpb=af63fb6ef0b0df0490b806b41ca018701e7eb586&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Flibravatar%2Ftickets%2F1&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/libravatar/tickets/1&lt;/a&gt;
> +
> +
> +&lt;a href=&quot;
> http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/libravatar/tickets/Please_provide_sample_code.mdwn;h=0000000000000000000000000000000000000000;hp=e2ef3abcf2e8dc5bb11d3a0d367fc01a4892123d;hb=69a4b71b5f5359915ae8a9c17cd12778e577267b;hpb=af63fb6ef0b0df0490b806b41ca018701e7eb586&quot;
> title=&quot;diff&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/diff.png&quot;
> alt=&quot;diff&quot; /&gt;&lt;/a&gt;&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Flibravatar%2Ftickets%2FPlease_provide_sample_code&amp;amp;do=goto&quot;
> rel=&quot;nofollow&quot;&gt;projects/libravatar/tickets/Please provide
> sample code&lt;/a&gt;
> +
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Changed by:&lt;/span&gt;
> +&lt;span class=&quot;committer&quot;&gt;
> +
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;amp;page=people%2Ffr33domlover&quot;
> rel=&quot;nofollow&quot;&gt;fr33domlover&lt;/a&gt;
> +
> +&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Commit type:&lt;/span&gt;
> +&lt;span class=&quot;committype&quot;&gt;git&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;Date:&lt;/span&gt;
> +&lt;span class=&quot;changedate&quot;&gt;&lt;span
> class=&quot;date&quot;&gt;02:57:10 PM 07/13/2015&lt;/span&gt;&lt;/span&gt;
> +&lt;span class=&quot;desc&quot;&gt;&lt;br /&gt;&lt;/span&gt;
> +&lt;span class=&quot;revert&quot;&gt;
> +&lt;a href=&quot;
> http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;amp;rev=69a4b71b5f5359915ae8a9c17cd12778e577267b&quot;
> title=&quot;revert&quot; rel=&quot;nofollow&quot;&gt;&lt;img src=&quot;
> http://www.rel4tion.org/recentchanges/../wikiicons/revert.png&quot;
> alt=&quot;revert&quot; /&gt;&lt;/a&gt;
> +&lt;/span&gt;
> +&lt;/div&gt;
> +&lt;div class=&quot;changelog&quot;&gt;
> +
> +
> +libravatar: reply on ticket 1&lt;br /&gt;
> +
> +
> +&lt;/div&gt;
> +
> +
> +
> +       </content>
> +
> +
> +
> +</entry>
> +
> +</feed>
> --
> 1.9.1
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151002/65cb887d/attachment-0001.html>

From martin.drautzburg at web.de  Fri Oct  2 17:08:45 2015
From: martin.drautzburg at web.de (martin)
Date: Fri, 2 Oct 2015 19:08:45 +0200
Subject: [Haskell-cafe] Concept for "equal but unknown"
In-Reply-To: <CAJcfPzm1UALBs0hSuzC8_6uJoD4rBGyRPJRQed0xuFNYaeunig@mail.gmail.com>
References: <560E30ED.2000503@web.de> <20151002140257.GA1136@hunter.iway.ch>
 <560E969C.4020302@web.de>
 <CAJcfPzm1UALBs0hSuzC8_6uJoD4rBGyRPJRQed0xuFNYaeunig@mail.gmail.com>
Message-ID: <560EBA1D.70601@web.de>

Am 10/02/2015 um 04:45 PM schrieb Marcin Mrotek:
> Hello,
> 
> Do you mean something like variable unification in Prolog or Oz? Maybe
> something like this could help you:
> https://hackage.haskell.org/package/monad-unify-0.2.2/docs/Control-Monad-Unify.html
> or https://hackage.haskell.org/package/unification-fd Disclaimer: I've
> never used either of those packages.

Well it was no coincidence that I invented the joke term "covariant unification", because I had a hunch that this has
something to do with unification.

Thanks for the links.


From althainz at gmail.com  Sat Oct  3 22:09:56 2015
From: althainz at gmail.com (Peter Althainz)
Date: Sun, 4 Oct 2015 00:09:56 +0200
Subject: [Haskell-cafe] HGamer3D 0.6.2
Message-ID: <CAKS-SO=88CSjUkbMe5e+W5FA6KA=wTT=oWQ4PdB7wp0irP_67g@mail.gmail.com>

Dear All,

HGamer3D has some new features with version 0.6.2, see www.hgamer3d.org.
Builds on Windows and Linux. with version 0.6 a switch was made towards a
simpler structure and a new 3d library.

regards
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151004/d203ee48/attachment.html>

From clintonmead at gmail.com  Sun Oct  4 07:15:11 2015
From: clintonmead at gmail.com (Clinton Mead)
Date: Sun, 4 Oct 2015 18:15:11 +1100
Subject: [Haskell-cafe] Approach to generalising Functor,
	is it worth pursuing?
Message-ID: <CAFDVgwGywEBLRs3Pq7CGsdCY89+AD9wihFtL1dy4k80KTBrvqg@mail.gmail.com>

I've been thinking about generalising Functor, as I had something which was
"Functor like" but didn't seem to fit into the existing definition. The
example I'll present isn't the problem I was trying to solve, but it
probably illustrates the solution better. The questions I have is:
1. Is this useful?
2. Has this been done?

If the answers are Yes and No, I'll continue on into making this into a
package.

Anyway, here's what I've done:

As we know, the type signature of fmap is the following:

fmap :: Functor f => (a -> b) -> (f a -> f b)

I've put brackets around the last two arguments to show that fmap can be
also seen as a function which takes a function and returns a new function,
in a different "space", for want of a better word.

fmap should also follow this rule:

fmap (f . g) == (fmap f . fmap g)

So we can map an ordinary function into the "Maybe" space, but in a way
that composing functions in the putting them in the space is the same as
putting them in the space then composing them.

I thought it would be nice if we could fmap to Kleisli Arrows, like so:

fmap :: Monad m => (a -> b) -> Kleisli m a b

Of course this is just "arr". But "arr" follows fmap's rules, so I thought
it would be nice to make it a functor.

So I was looking for more generalised versions of "Functor", and I found
the 'categories' package, which had the following definition:


class (Category
<https://hackage.haskell.org/package/base-4.7.0.1/docs/Control-Category.html#t:Category>
 r, Category
<https://hackage.haskell.org/package/base-4.7.0.1/docs/Control-Category.html#t:Category>
t)
=> Functor f r t | f r -> t, f t -> r where
  fmap :: r a b -> t (f a) (f b)

This solves half my problem, as now I can set r = (->) and t = Kleisli m
and I've got the categories right. But it forces the "output" category to
have a data constructor.

So:

fmap :: Monad m => (a -> b) -> Kleisli m a b

Just won't fit. I'd need to make it:

fmap :: Monad m => (a -> b) -> Kleisli m (Id a) (Id b)

and then unwrap the results. I found this ugly though.

So I've gone with another approached. I've linked the code here:
http://ideone.com/TEg4MN and also included it inline at the bottom of this
mail.

Defining functors now becomes a bit wordy, but basically what I've defined
is two functor instances. The first is just a copy of the existing functor
instances to maintain the status quo behaviour. But secondly I've defined
the Kleisli instance as discussed above.

The "main" line, does two calls to fmap. The outermost (on the left) is
just an ordinary fmap call on lists. The innermost, fmaps the function
"triple" into a Kleisli Arrow, allowing it to be composed with the the
Kleisli arrow already defined, 'evenOrNothing'. Type inference works this
all out magically without signatures being required.

Like I said, is approach new and useful? Improvements would be appreciated
also, I'm only over the last few months really started focusing on learning
Haskell properly (after leaving my previous job of 8 years), so I'm sure
I'm still doing plenty of things not quite right.

Thanks,

Clinton

---


{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE FlexibleContexts #-}

module Main (
    main
) where

import qualified Control.Arrow
import Prelude hiding (Functor, fmap, (.))
import Control.Category (Category, (.))
import qualified Data.Functor
import qualified Control.Arrow
import Control.Arrow (Kleisli(Kleisli), runKleisli)

type family F (r :: (* -> * -> *)) (t :: (* -> * -> *)) x
type family InputParam f x
type family ResultParam f x
type family InputCategory f :: (* -> * -> *)
type family ResultCategory f :: (* -> * -> *)

class Functor f where
  fmap ::
    (
      Category r, Category t,
      f ~ F r t c, f ~ F r t d,
      r ~ InputCategory f, t ~ ResultCategory f,
      a ~ InputParam f c, b ~ InputParam f d,
      c ~ ResultParam f a, d ~ ResultParam f b
    ) =>
      r a b -> t c d


data OrdinaryFunctor :: (* -> *) -> *
type instance F (->) (->) (f a) = OrdinaryFunctor f
type instance InputParam (OrdinaryFunctor f) (f a) = a
type instance ResultParam (OrdinaryFunctor f) a = f a
type instance InputCategory (OrdinaryFunctor f) = (->)
type instance ResultCategory (OrdinaryFunctor f) = (->)

instance (Data.Functor.Functor f) => Functor (OrdinaryFunctor f) where
  fmap = Data.Functor.fmap

data KleisliFunctor :: (* -> *) -> *
type instance F (->) (Kleisli m) a = KleisliFunctor m
type instance InputParam (KleisliFunctor f) a = a
type instance ResultParam (KleisliFunctor m) a = a
type instance InputCategory (KleisliFunctor m) = (->)
type instance ResultCategory (KleisliFunctor m) = Kleisli m

instance (Monad m) => Functor (KleisliFunctor m) where
  fmap = Control.Arrow.arr

triple = (*3)
evenOrNothing = Kleisli (\x -> if (even x) then Just x else Nothing)

main = print $ fmap (runKleisli (evenOrNothing . fmap triple)) [3..6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151004/1d52f8b0/attachment.html>

From david.feuer at gmail.com  Sun Oct  4 20:05:27 2015
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 4 Oct 2015 16:05:27 -0400
Subject: [Haskell-cafe] Approach to generalising Functor,
	is it worth pursuing?
In-Reply-To: <CAFDVgwGywEBLRs3Pq7CGsdCY89+AD9wihFtL1dy4k80KTBrvqg@mail.gmail.com>
References: <CAFDVgwGywEBLRs3Pq7CGsdCY89+AD9wihFtL1dy4k80KTBrvqg@mail.gmail.com>
Message-ID: <CAMgWh9sbEW13XG+Oevw0VNp=TdK20=Z+RJodrBFCUuKFt+D37w@mail.gmail.com>

I don't understand what F is supposed to represent. All the other type
families should surely be associated families of Functor rather than
independent families.

On Sun, Oct 4, 2015 at 3:15 AM, Clinton Mead <clintonmead at gmail.com> wrote:
> I've been thinking about generalising Functor, as I had something which was
> "Functor like" but didn't seem to fit into the existing definition. The
> example I'll present isn't the problem I was trying to solve, but it
> probably illustrates the solution better. The questions I have is:
> 1. Is this useful?
> 2. Has this been done?
>
> If the answers are Yes and No, I'll continue on into making this into a
> package.
>
> Anyway, here's what I've done:
>
> As we know, the type signature of fmap is the following:
>
> fmap :: Functor f => (a -> b) -> (f a -> f b)
>
> I've put brackets around the last two arguments to show that fmap can be
> also seen as a function which takes a function and returns a new function,
> in a different "space", for want of a better word.
>
> fmap should also follow this rule:
>
> fmap (f . g) == (fmap f . fmap g)
>
> So we can map an ordinary function into the "Maybe" space, but in a way that
> composing functions in the putting them in the space is the same as putting
> them in the space then composing them.
>
> I thought it would be nice if we could fmap to Kleisli Arrows, like so:
>
> fmap :: Monad m => (a -> b) -> Kleisli m a b
>
> Of course this is just "arr". But "arr" follows fmap's rules, so I thought
> it would be nice to make it a functor.
>
> So I was looking for more generalised versions of "Functor", and I found the
> 'categories' package, which had the following definition:
>
>
> class (Category r, Category t) => Functor f r t | f r -> t, f t -> r where
>   fmap :: r a b -> t (f a) (f b)
>
> This solves half my problem, as now I can set r = (->) and t = Kleisli m and
> I've got the categories right. But it forces the "output" category to have a
> data constructor.
>
> So:
>
> fmap :: Monad m => (a -> b) -> Kleisli m a b
>
> Just won't fit. I'd need to make it:
>
> fmap :: Monad m => (a -> b) -> Kleisli m (Id a) (Id b)
>
> and then unwrap the results. I found this ugly though.
>
> So I've gone with another approached. I've linked the code here:
> http://ideone.com/TEg4MN and also included it inline at the bottom of this
> mail.
>
> Defining functors now becomes a bit wordy, but basically what I've defined
> is two functor instances. The first is just a copy of the existing functor
> instances to maintain the status quo behaviour. But secondly I've defined
> the Kleisli instance as discussed above.
>
> The "main" line, does two calls to fmap. The outermost (on the left) is just
> an ordinary fmap call on lists. The innermost, fmaps the function "triple"
> into a Kleisli Arrow, allowing it to be composed with the the Kleisli arrow
> already defined, 'evenOrNothing'. Type inference works this all out
> magically without signatures being required.
>
> Like I said, is approach new and useful? Improvements would be appreciated
> also, I'm only over the last few months really started focusing on learning
> Haskell properly (after leaving my previous job of 8 years), so I'm sure I'm
> still doing plenty of things not quite right.
>
> Thanks,
>
> Clinton
>
> ---
>
>
> {-# LANGUAGE TypeFamilies #-}
> {-# LANGUAGE FlexibleContexts #-}
>
> module Main (
>     main
> ) where
>
> import qualified Control.Arrow
> import Prelude hiding (Functor, fmap, (.))
> import Control.Category (Category, (.))
> import qualified Data.Functor
> import qualified Control.Arrow
> import Control.Arrow (Kleisli(Kleisli), runKleisli)
>
> type family F (r :: (* -> * -> *)) (t :: (* -> * -> *)) x
> type family InputParam f x
> type family ResultParam f x
> type family InputCategory f :: (* -> * -> *)
> type family ResultCategory f :: (* -> * -> *)
>
> class Functor f where
>   fmap ::
>     (
>       Category r, Category t,
>       f ~ F r t c, f ~ F r t d,
>       r ~ InputCategory f, t ~ ResultCategory f,
>       a ~ InputParam f c, b ~ InputParam f d,
>       c ~ ResultParam f a, d ~ ResultParam f b
>     ) =>
>       r a b -> t c d
>
>
> data OrdinaryFunctor :: (* -> *) -> *
> type instance F (->) (->) (f a) = OrdinaryFunctor f
> type instance InputParam (OrdinaryFunctor f) (f a) = a
> type instance ResultParam (OrdinaryFunctor f) a = f a
> type instance InputCategory (OrdinaryFunctor f) = (->)
> type instance ResultCategory (OrdinaryFunctor f) = (->)
>
> instance (Data.Functor.Functor f) => Functor (OrdinaryFunctor f) where
>   fmap = Data.Functor.fmap
>
> data KleisliFunctor :: (* -> *) -> *
> type instance F (->) (Kleisli m) a = KleisliFunctor m
> type instance InputParam (KleisliFunctor f) a = a
> type instance ResultParam (KleisliFunctor m) a = a
> type instance InputCategory (KleisliFunctor m) = (->)
> type instance ResultCategory (KleisliFunctor m) = Kleisli m
>
> instance (Monad m) => Functor (KleisliFunctor m) where
>   fmap = Control.Arrow.arr
>
> triple = (*3)
> evenOrNothing = Kleisli (\x -> if (even x) then Just x else Nothing)
>
> main = print $ fmap (runKleisli (evenOrNothing . fmap triple)) [3..6]
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>

From alan.zimm at gmail.com  Sun Oct  4 20:18:52 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Sun, 4 Oct 2015 22:18:52 +0200
Subject: [Haskell-cafe] ANN: HaRe 0.8 - The Haskell Refactorer
Message-ID: <CANma=H-j=xYBE-gAp_Ou-fJyv4TH2TEz=VqbZhh8sOC9OYzb+g@mail.gmail.com>

I'm pleased to announce the release of HaRe 0.8, available on hackage [1]

What's new?
===========

Everything, and nothing.

Everything in the sense that it has been completely reworked internally to
make
use of the new API Annotations [2] in GHC 7.10.2, via the ghc-exactprint [3]
library.

Nothing in the sense that the functionality in this version is/should be
identical to that in 0.7.2.8

Limitations
===========

HaRe 0.8 will only work for projects using GHC 7.10.2 for compilation.
Compiling
HaRe with 7.10.2 and then using it against projects using an earlier
compiler
will not work, as HaRe needs to be able to invoke GHC to the type checker
stage
on the project using GHC 7.10.2.

What is it?
===========

HaRe makes changes to working code, so that it still works once the change
is
made.

Refactorings it can do are

* demote

  Take a declaration from the level where it is defined and move it down to
the
  place where it is used. This only works if it is used in one place only.

* dupdef

  Duplicate a definition with a new name.

* iftocase

  Convert an if declaration to a case declaration.

* liftOneLevel

  Move a declaration one level up, adding parameters as needed to pass in
  locally declared variables.

* liftToTopLevel

  Move a declaration to the top level, adding parameters as needed to pass
in
  locally declared variables.

* rename

  Change a name throughout the project. This makes use of the GHC renamed
source
  so will not change other names that just happen to be lexically
identical, but
  are in fact different names.

It currently has an emacs integration only, assistance in supporting other
environnments welcome.

[1] https://hackage.haskell.org/package/HaRe
[2] https://ghc.haskell.org/trac/ghc/wiki/ApiAnnotations
[3] https://hackage.haskell.org/package/ghc-exactprint

Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151004/8e14a2f3/attachment.html>

From wren at community.haskell.org  Sun Oct  4 23:39:49 2015
From: wren at community.haskell.org (wren romano)
Date: Sun, 4 Oct 2015 19:39:49 -0400
Subject: [Haskell-cafe] Concept for "equal but unknown"
In-Reply-To: <560E30ED.2000503@web.de>
References: <560E30ED.2000503@web.de>
Message-ID: <CABUjdS6saifMVpoFtAeDoJc6-YDJMe-hSteSyAXNEk6UZf-8PA@mail.gmail.com>

In the context of logic, the usual way to capture these sorts of
things is to introduce some notion of an event/eventuality which you
can use to index everything by. Then you can say that there exists
some index (e.g., hotel reservation) with such and such properties
(e.g., consumes a free room, provides the same room to the reservation
holder, etc). The connection between this semantic model and how you
write your program is, of course, up to you. Both the
pointer-indirection approach and the unification-variable approach can
be seen as ways of implementing this semantics.

As for a general concept, you may want to look into "constraint
satisfaction"/"constraint programming" (e.g., ECLPS Prolog
<http://eclipseclp.org>). The big idea here is that you can give each
variable a domain of possible values (which need not be the same for
all variables), and then you introduce a set of constraints on what
those values can be. This allows for capturing things like "I have
three reservations X, Y, and Z for three rooms A, B, and C such that
no room is booked twice and no reservation takes more than one room".

-- 
Live well,
~wren

From ky3 at atamo.com  Mon Oct  5 01:16:07 2015
From: ky3 at atamo.com (Kim-Ee Yeoh)
Date: Mon, 5 Oct 2015 08:16:07 +0700
Subject: [Haskell-cafe] Concept for "equal but unknown"
In-Reply-To: <560E969C.4020302@web.de>
References: <560E30ED.2000503@web.de> <20151002140257.GA1136@hunter.iway.ch>
 <560E969C.4020302@web.de>
Message-ID: <CAPY+ZdQ6EYzHE+7sN6R8FrkMz5gVFRns7-8D4nh3PogdwazHsw@mail.gmail.com>

On Fri, Oct 2, 2015 at 9:37 PM, martin <martin.drautzburg at web.de> wrote:

> I guess I am after values which become more and more defined in the course
> of computation.


One way to simulate incremental binding is by extending with multiple
Maybes:

Nothing would mean 'no reservation'
Just Nothing -> 'reservation but unassigned room'
Just (Room 123) -> 'reservation with assigned room'

The type used is Maybe (Maybe Room).

-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151005/82fee95e/attachment.html>

From zocca.marco at gmail.com  Mon Oct  5 05:50:29 2015
From: zocca.marco at gmail.com (Marco Zocca)
Date: Mon, 5 Oct 2015 07:50:29 +0200
Subject: [Haskell-cafe] [ANN] PETSc Haskell bindings
Message-ID: <CAKE6T0Rn=+CSeiv9KHafDpmJ64GT_9A+Le-gaW_Dk8s_u33XxA@mail.gmail.com>

Dear all,

development of the Haskell bindings for the PETSc scientific
computation library is now public; the repository can be found at

https://github.com/ocramz/petsc-hs

The interface is still very much experimental and in a state of flow
but a number of basic functions are working.

I look forward to all feedback;
Kind regards,

Marco Zocca

From andrew.gibiansky at gmail.com  Mon Oct  5 06:07:35 2015
From: andrew.gibiansky at gmail.com (Andrew Gibiansky)
Date: Sun, 4 Oct 2015 23:07:35 -0700
Subject: [Haskell-cafe] ANN: HaRe 0.8 - The Haskell Refactorer
In-Reply-To: <CANma=H-j=xYBE-gAp_Ou-fJyv4TH2TEz=VqbZhh8sOC9OYzb+g@mail.gmail.com>
References: <CANma=H-j=xYBE-gAp_Ou-fJyv4TH2TEz=VqbZhh8sOC9OYzb+g@mail.gmail.com>
Message-ID: <CAF-LYKJTUqeWdKyd12=CMU_H8CXAWYmWbp83VET-kw3Oc1DbKg@mail.gmail.com>

Alan,

This is awesome. I can't express how excited I am to see this develop
further.

I'll gladly start working on Vim support.

Could you describe how it works with emacs?

-- Andrew

On Sun, Oct 4, 2015 at 1:18 PM, Alan & Kim Zimmerman <alan.zimm at gmail.com>
wrote:

> I'm pleased to announce the release of HaRe 0.8, available on hackage [1]
>
> What's new?
> ===========
>
> Everything, and nothing.
>
> Everything in the sense that it has been completely reworked internally to
> make
> use of the new API Annotations [2] in GHC 7.10.2, via the ghc-exactprint
> [3]
> library.
>
> Nothing in the sense that the functionality in this version is/should be
> identical to that in 0.7.2.8
>
> Limitations
> ===========
>
> HaRe 0.8 will only work for projects using GHC 7.10.2 for compilation.
> Compiling
> HaRe with 7.10.2 and then using it against projects using an earlier
> compiler
> will not work, as HaRe needs to be able to invoke GHC to the type checker
> stage
> on the project using GHC 7.10.2.
>
> What is it?
> ===========
>
> HaRe makes changes to working code, so that it still works once the change
> is
> made.
>
> Refactorings it can do are
>
> * demote
>
>   Take a declaration from the level where it is defined and move it down
> to the
>   place where it is used. This only works if it is used in one place only.
>
> * dupdef
>
>   Duplicate a definition with a new name.
>
> * iftocase
>
>   Convert an if declaration to a case declaration.
>
> * liftOneLevel
>
>   Move a declaration one level up, adding parameters as needed to pass in
>   locally declared variables.
>
> * liftToTopLevel
>
>   Move a declaration to the top level, adding parameters as needed to pass
> in
>   locally declared variables.
>
> * rename
>
>   Change a name throughout the project. This makes use of the GHC renamed
> source
>   so will not change other names that just happen to be lexically
> identical, but
>   are in fact different names.
>
> It currently has an emacs integration only, assistance in supporting other
> environnments welcome.
>
> [1] https://hackage.haskell.org/package/HaRe
> [2] https://ghc.haskell.org/trac/ghc/wiki/ApiAnnotations
> [3] https://hackage.haskell.org/package/ghc-exactprint
>
> Alan
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151004/59d834b2/attachment.html>

From alan.zimm at gmail.com  Mon Oct  5 06:19:24 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Mon, 5 Oct 2015 08:19:24 +0200
Subject: [Haskell-cafe] ANN: HaRe 0.8 - The Haskell Refactorer
In-Reply-To: <CAF-LYKJTUqeWdKyd12=CMU_H8CXAWYmWbp83VET-kw3Oc1DbKg@mail.gmail.com>
References: <CANma=H-j=xYBE-gAp_Ou-fJyv4TH2TEz=VqbZhh8sOC9OYzb+g@mail.gmail.com>
 <CAF-LYKJTUqeWdKyd12=CMU_H8CXAWYmWbp83VET-kw3Oc1DbKg@mail.gmail.com>
Message-ID: <CANma=H8t8H7KTZ2E3iBE32xjSTKJNbNSmoO+J+dh8CEXY2m0Tg@mail.gmail.com>

Hi Andrew

Thanks for the offer, that will be awesome.

In emacs the process is to highlight in a buffer the point where a change
should happen, for example place the cursor on something that needs
renaming, and then press the key binding for the relevant refactoring. The
elisp uses the name of the buffer, location of the cursor and/or current
highlighted region to construct the parameters for a call to ghc-hare.

When it is done, ghc-hare returns either (ok [files]) to indicate success
and the names of the files that were changed, or (error "description of
error").

HaRe does not actually change any files, it just places a new version next
to to it with an extension of .refactored.hs. In emacs a (optional) series
of ediff buffers are presented to review the changes. If the user accepts
them the elisp copies the original files to the same name but with a
date-time string as a suffix, and renames the refactored file to be the
original. It should then reload the buffer, but I think that is missing
right now.

Alan

On Mon, Oct 5, 2015 at 8:07 AM, Andrew Gibiansky <andrew.gibiansky at gmail.com
> wrote:

> Alan,
>
> This is awesome. I can't express how excited I am to see this develop
> further.
>
> I'll gladly start working on Vim support.
>
> Could you describe how it works with emacs?
>
> -- Andrew
>
> On Sun, Oct 4, 2015 at 1:18 PM, Alan & Kim Zimmerman <alan.zimm at gmail.com>
> wrote:
>
>> I'm pleased to announce the release of HaRe 0.8, available on hackage [1]
>>
>> What's new?
>> ===========
>>
>> Everything, and nothing.
>>
>> Everything in the sense that it has been completely reworked internally
>> to make
>> use of the new API Annotations [2] in GHC 7.10.2, via the ghc-exactprint
>> [3]
>> library.
>>
>> Nothing in the sense that the functionality in this version is/should be
>> identical to that in 0.7.2.8
>>
>> Limitations
>> ===========
>>
>> HaRe 0.8 will only work for projects using GHC 7.10.2 for compilation.
>> Compiling
>> HaRe with 7.10.2 and then using it against projects using an earlier
>> compiler
>> will not work, as HaRe needs to be able to invoke GHC to the type checker
>> stage
>> on the project using GHC 7.10.2.
>>
>> What is it?
>> ===========
>>
>> HaRe makes changes to working code, so that it still works once the
>> change is
>> made.
>>
>> Refactorings it can do are
>>
>> * demote
>>
>>   Take a declaration from the level where it is defined and move it down
>> to the
>>   place where it is used. This only works if it is used in one place only.
>>
>> * dupdef
>>
>>   Duplicate a definition with a new name.
>>
>> * iftocase
>>
>>   Convert an if declaration to a case declaration.
>>
>> * liftOneLevel
>>
>>   Move a declaration one level up, adding parameters as needed to pass in
>>   locally declared variables.
>>
>> * liftToTopLevel
>>
>>   Move a declaration to the top level, adding parameters as needed to
>> pass in
>>   locally declared variables.
>>
>> * rename
>>
>>   Change a name throughout the project. This makes use of the GHC renamed
>> source
>>   so will not change other names that just happen to be lexically
>> identical, but
>>   are in fact different names.
>>
>> It currently has an emacs integration only, assistance in supporting other
>> environnments welcome.
>>
>> [1] https://hackage.haskell.org/package/HaRe
>> [2] https://ghc.haskell.org/trac/ghc/wiki/ApiAnnotations
>> [3] https://hackage.haskell.org/package/ghc-exactprint
>>
>> Alan
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151005/ac930bb2/attachment.html>

From s.j.thompson at kent.ac.uk  Mon Oct  5 08:47:57 2015
From: s.j.thompson at kent.ac.uk (Simon Thompson)
Date: Mon, 5 Oct 2015 09:47:57 +0100
Subject: [Haskell-cafe] ANN: HaRe 0.8 - The Haskell Refactorer
In-Reply-To: <CANma=H8t8H7KTZ2E3iBE32xjSTKJNbNSmoO+J+dh8CEXY2m0Tg@mail.gmail.com>
References: <CANma=H-j=xYBE-gAp_Ou-fJyv4TH2TEz=VqbZhh8sOC9OYzb+g@mail.gmail.com>
 <CAF-LYKJTUqeWdKyd12=CMU_H8CXAWYmWbp83VET-kw3Oc1DbKg@mail.gmail.com>
 <CANma=H8t8H7KTZ2E3iBE32xjSTKJNbNSmoO+J+dh8CEXY2m0Tg@mail.gmail.com>
Message-ID: <CCE5131B-6853-45D6-8A09-E8FC7CE18D9F@kent.ac.uk>

Alan, Andrew,

The original version of HaRe did integrate with vim. This work was done more than 10 years ago, and it may well be that the mechanisms have changed. Still, the code should be in the HaRe repo. On the other hand, may be easier to start from scratch.

Kind regards, and great to hear that you?re planning to do this!

Simon T.


> On 5 Oct 2015, at 07:19, Alan & Kim Zimmerman <alan.zimm at gmail.com> wrote:
> 
> Hi Andrew
> 
> Thanks for the offer, that will be awesome.
> 
> In emacs the process is to highlight in a buffer the point where a change should happen, for example place the cursor on something that needs renaming, and then press the key binding for the relevant refactoring. The elisp uses the name of the buffer, location of the cursor and/or current highlighted region to construct the parameters for a call to ghc-hare.
> 
> When it is done, ghc-hare returns either (ok [files]) to indicate success and the names of the files that were changed, or (error "description of error").
> 
> HaRe does not actually change any files, it just places a new version next to to it with an extension of .refactored.hs. In emacs a (optional) series of ediff buffers are presented to review the changes. If the user accepts them the elisp copies the original files to the same name but with a date-time string as a suffix, and renames the refactored file to be the original. It should then reload the buffer, but I think that is missing right now.
> 
> Alan
> 
> On Mon, Oct 5, 2015 at 8:07 AM, Andrew Gibiansky <andrew.gibiansky at gmail.com <mailto:andrew.gibiansky at gmail.com>> wrote:
> Alan,
> 
> This is awesome. I can't express how excited I am to see this develop further.
> 
> I'll gladly start working on Vim support.
> 
> Could you describe how it works with emacs?
> 
> -- Andrew
> 
> On Sun, Oct 4, 2015 at 1:18 PM, Alan & Kim Zimmerman <alan.zimm at gmail.com <mailto:alan.zimm at gmail.com>> wrote:
> I'm pleased to announce the release of HaRe 0.8, available on hackage [1]
> 
> What's new?
> ===========
> 
> Everything, and nothing.
> 
> Everything in the sense that it has been completely reworked internally to make
> use of the new API Annotations [2] in GHC 7.10.2, via the ghc-exactprint [3]
> library.
> 
> Nothing in the sense that the functionality in this version is/should be
> identical to that in 0.7.2.8
> 
> Limitations
> ===========
> 
> HaRe 0.8 will only work for projects using GHC 7.10.2 for compilation. Compiling
> HaRe with 7.10.2 and then using it against projects using an earlier compiler
> will not work, as HaRe needs to be able to invoke GHC to the type checker stage
> on the project using GHC 7.10.2.
> 
> What is it?
> ===========
> 
> HaRe makes changes to working code, so that it still works once the change is
> made.
> 
> Refactorings it can do are
> 
> * demote
> 
>   Take a declaration from the level where it is defined and move it down to the
>   place where it is used. This only works if it is used in one place only.
> 
> * dupdef
> 
>   Duplicate a definition with a new name.
> 
> * iftocase
> 
>   Convert an if declaration to a case declaration.
> 
> * liftOneLevel
> 
>   Move a declaration one level up, adding parameters as needed to pass in
>   locally declared variables.
> 
> * liftToTopLevel
> 
>   Move a declaration to the top level, adding parameters as needed to pass in
>   locally declared variables.
> 
> * rename
> 
>   Change a name throughout the project. This makes use of the GHC renamed source
>   so will not change other names that just happen to be lexically identical, but
>   are in fact different names.
> 
> It currently has an emacs integration only, assistance in supporting other
> environnments welcome.
> 
> [1] https://hackage.haskell.org/package/HaRe <https://hackage.haskell.org/package/HaRe>
> [2] https://ghc.haskell.org/trac/ghc/wiki/ApiAnnotations <https://ghc.haskell.org/trac/ghc/wiki/ApiAnnotations>
> [3] https://hackage.haskell.org/package/ghc-exactprint <https://hackage.haskell.org/package/ghc-exactprint>
> 
> Alan
> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org <mailto:Haskell-Cafe at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>
> 
> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Simon Thompson | Professor of Logic and Computation 
School of Computing | University of Kent | Canterbury, CT2 7NF, UK
s.j.thompson at kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151005/3485a131/attachment.html>

From marcin.jan.mrotek at gmail.com  Mon Oct  5 08:53:51 2015
From: marcin.jan.mrotek at gmail.com (Marcin Mrotek)
Date: Mon, 5 Oct 2015 10:53:51 +0200
Subject: [Haskell-cafe] ANN: HaRe 0.8 - The Haskell Refactorer
In-Reply-To: <CCE5131B-6853-45D6-8A09-E8FC7CE18D9F@kent.ac.uk>
References: <CANma=H-j=xYBE-gAp_Ou-fJyv4TH2TEz=VqbZhh8sOC9OYzb+g@mail.gmail.com>
 <CAF-LYKJTUqeWdKyd12=CMU_H8CXAWYmWbp83VET-kw3Oc1DbKg@mail.gmail.com>
 <CANma=H8t8H7KTZ2E3iBE32xjSTKJNbNSmoO+J+dh8CEXY2m0Tg@mail.gmail.com>
 <CCE5131B-6853-45D6-8A09-E8FC7CE18D9F@kent.ac.uk>
Message-ID: <CAJcfPznYS_L3CC38FB6cXCuA_my6e6oMPJB5ia--oKU36J3-Ow@mail.gmail.com>

Hello,

As for vim integration, neovim and
https://github.com/neovimhaskell/nvim-hs might be the way to go.

Best regards,
Marcin Mrotek

From alan.zimm at gmail.com  Mon Oct  5 09:31:29 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Mon, 5 Oct 2015 11:31:29 +0200
Subject: [Haskell-cafe] ANN: HaRe 0.8 - The Haskell Refactorer
In-Reply-To: <CCE5131B-6853-45D6-8A09-E8FC7CE18D9F@kent.ac.uk>
References: <CANma=H-j=xYBE-gAp_Ou-fJyv4TH2TEz=VqbZhh8sOC9OYzb+g@mail.gmail.com>
 <CAF-LYKJTUqeWdKyd12=CMU_H8CXAWYmWbp83VET-kw3Oc1DbKg@mail.gmail.com>
 <CANma=H8t8H7KTZ2E3iBE32xjSTKJNbNSmoO+J+dh8CEXY2m0Tg@mail.gmail.com>
 <CCE5131B-6853-45D6-8A09-E8FC7CE18D9F@kent.ac.uk>
Message-ID: <CANma=H9LSsgMoWe1sgWiB3TabcTttvVp0uLErP0TUY4-8h+pJw@mail.gmail.com>

It is here: https://github.com/alanz/HaRe/tree/master/old/editors/Vim

On Mon, Oct 5, 2015 at 10:47 AM, Simon Thompson <s.j.thompson at kent.ac.uk>
wrote:

> Alan, Andrew,
>
> The original version of HaRe did integrate with vim. This work was done
> more than 10 years ago, and it may well be that the mechanisms have
> changed. Still, the code should be in the HaRe repo. On the other hand, may
> be easier to start from scratch.
>
> Kind regards, and great to hear that you?re planning to do this!
>
> Simon T.
>
>
> On 5 Oct 2015, at 07:19, Alan & Kim Zimmerman <alan.zimm at gmail.com> wrote:
>
> Hi Andrew
>
> Thanks for the offer, that will be awesome.
>
> In emacs the process is to highlight in a buffer the point where a change
> should happen, for example place the cursor on something that needs
> renaming, and then press the key binding for the relevant refactoring. The
> elisp uses the name of the buffer, location of the cursor and/or current
> highlighted region to construct the parameters for a call to ghc-hare.
>
> When it is done, ghc-hare returns either (ok [files]) to indicate success
> and the names of the files that were changed, or (error "description of
> error").
>
> HaRe does not actually change any files, it just places a new version next
> to to it with an extension of .refactored.hs. In emacs a (optional) series
> of ediff buffers are presented to review the changes. If the user accepts
> them the elisp copies the original files to the same name but with a
> date-time string as a suffix, and renames the refactored file to be the
> original. It should then reload the buffer, but I think that is missing
> right now.
>
> Alan
>
> On Mon, Oct 5, 2015 at 8:07 AM, Andrew Gibiansky <
> andrew.gibiansky at gmail.com> wrote:
>
>> Alan,
>>
>> This is awesome. I can't express how excited I am to see this develop
>> further.
>>
>> I'll gladly start working on Vim support.
>>
>> Could you describe how it works with emacs?
>>
>> -- Andrew
>>
>> On Sun, Oct 4, 2015 at 1:18 PM, Alan & Kim Zimmerman <alan.zimm at gmail.com
>> > wrote:
>>
>>> I'm pleased to announce the release of HaRe 0.8, available on hackage [1]
>>>
>>> What's new?
>>> ===========
>>>
>>> Everything, and nothing.
>>>
>>> Everything in the sense that it has been completely reworked internally
>>> to make
>>> use of the new API Annotations [2] in GHC 7.10.2, via the ghc-exactprint
>>> [3]
>>> library.
>>>
>>> Nothing in the sense that the functionality in this version is/should be
>>> identical to that in 0.7.2.8
>>>
>>> Limitations
>>> ===========
>>>
>>> HaRe 0.8 will only work for projects using GHC 7.10.2 for compilation.
>>> Compiling
>>> HaRe with 7.10.2 and then using it against projects using an earlier
>>> compiler
>>> will not work, as HaRe needs to be able to invoke GHC to the type
>>> checker stage
>>> on the project using GHC 7.10.2.
>>>
>>> What is it?
>>> ===========
>>>
>>> HaRe makes changes to working code, so that it still works once the
>>> change is
>>> made.
>>>
>>> Refactorings it can do are
>>>
>>> * demote
>>>
>>>   Take a declaration from the level where it is defined and move it down
>>> to the
>>>   place where it is used. This only works if it is used in one place
>>> only.
>>>
>>> * dupdef
>>>
>>>   Duplicate a definition with a new name.
>>>
>>> * iftocase
>>>
>>>   Convert an if declaration to a case declaration.
>>>
>>> * liftOneLevel
>>>
>>>   Move a declaration one level up, adding parameters as needed to pass in
>>>   locally declared variables.
>>>
>>> * liftToTopLevel
>>>
>>>   Move a declaration to the top level, adding parameters as needed to
>>> pass in
>>>   locally declared variables.
>>>
>>> * rename
>>>
>>>   Change a name throughout the project. This makes use of the GHC
>>> renamed source
>>>   so will not change other names that just happen to be lexically
>>> identical, but
>>>   are in fact different names.
>>>
>>> It currently has an emacs integration only, assistance in supporting
>>> other
>>> environnments welcome.
>>>
>>> [1] https://hackage.haskell.org/package/HaRe
>>> [2] https://ghc.haskell.org/trac/ghc/wiki/ApiAnnotations
>>> [3] https://hackage.haskell.org/package/ghc-exactprint
>>>
>>> Alan
>>>
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>>>
>>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
> Simon Thompson | Professor of Logic and Computation
> School of Computing | University of Kent | Canterbury, CT2 7NF, UK
> s.j.thompson at kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151005/b74e7c5f/attachment.html>

From s.j.thompson at kent.ac.uk  Mon Oct  5 09:59:46 2015
From: s.j.thompson at kent.ac.uk (Simon Thompson)
Date: Mon, 5 Oct 2015 10:59:46 +0100
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
	`return` out of `Monad`
In-Reply-To: <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
Message-ID: <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>

Hello all. I write this to be a little provocative, but ?

It?s really interesting to have this discussion, which pulls in all sorts of well-made points about orthogonality, teaching, the evolution of the language and so on, but it simply goes to show that the process of evolving Haskell is profoundly broken. 

Other languages do evolve, but in a managed and reflective way. Simply throwing in changes that would have a profound impact on systems that are commercially and potentially safety critical in an ? la carte, offhand, way seems like a breakdown of the collective responsibility of the Haskell community to its users and, indirectly, to its future.

If we make claims - I believe rightly - that Haskell is hitting the mainstream, then we need to think about all changes in terms of the costs and benefits of each of them in the widest possible sense. There?s an old fashioned maxim that sums this up in a pithy way: ?if it ain?t broke, don?t fix it?.

Simon Thompson



> On 5 Oct 2015, at 10:47, Micha? J Gajda <mjgajda at gmail.com> wrote:
> 
> Hi,
> 
> As a person who used Haskell in all three capacities (for scientific research, for commercial purpose, and to introduce others to benefits of pure and strongly typed programming), I must voice an supportive voice for this change:
> 1. Orthogonal type classes are easier to explain.
> 2. Gradual improvements helps us to generalize further, and this in turn makes education easier.
> 3. Gradual change that break only a little help to prevent either stagnation (FORTRAN) and big breakage (py3k). That keeps us excited.
> 
> That would also call to split TCs into their orthogonal elements: return, ap, bind having the basic TC on their own.
> 
> So:
> +1, but only if it is possible to have compatibilty mode. I believe that rebindable syntax should allow us to otherwise make our own prelude, if we want such a split. Then we could test it well before it is used by the base library.
> 
> That said, I would appreciate Haskell2010 option just like Haskell98 wad, so that we can compile old programs without changes. Even by using some Compat version of standard library. Would that satisfy need for stability?
> 
> PS And since all experts were beginners some time ago, I beg that we do not call them "peripheral".
> --
>   Best regards
>     Micha?
> 
> On Monday, 5 October 2015, Malcolm Wallace <malcolm.wallace at me.com <mailto:malcolm.wallace at me.com>> wrote:
> On other social media forums, I am seeing educators who use Haskell as a vehicle for their main work, but would not consider themselves Haskell researchers, and certainly do not have the time to follow Haskell mailing lists, who are beginning to say that these kinds of annoying breakages to the language, affecting their research and teaching materials, are beginning to disincline them to continue using Haskell.  They are feeling like they would be 
> (...) 
> 
> 
> -- 
>   Pozdrawiam
>     Micha?
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Simon Thompson | Professor of Logic and Computation 
School of Computing | University of Kent | Canterbury, CT2 7NF, UK
s.j.thompson at kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151005/53d4b4b8/attachment.html>

From mblazevic at stilo.com  Mon Oct  5 13:11:06 2015
From: mblazevic at stilo.com (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=)
Date: Mon, 5 Oct 2015 09:11:06 -0400
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
Message-ID: <561276EA.5030402@stilo.com>

On 15-10-05 05:59 AM, Simon Thompson wrote:
> Hello all. I write this to be a little provocative, but ?
>
> ...
> Other languages do evolve, but in a managed and reflective way.

Citation needed.


From svenpanne at gmail.com  Mon Oct  5 13:27:53 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Mon, 5 Oct 2015 15:27:53 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
Message-ID: <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>

2015-10-05 11:59 GMT+02:00 Simon Thompson <s.j.thompson at kent.ac.uk>:

> [...] It?s really interesting to have this discussion, which pulls in all
> sorts of well-made points about orthogonality, teaching, the evolution of
> the language and so on, but it simply goes to show that the process of
> evolving Haskell is profoundly broken. [...]
>

I wouldn't necessarily call the process "broken", but it's a bit annoying:
Because of the constant flux of minor changes in the language and the
libraries, I've reached the stage where I'm totally unable to tell if my
code will work for the whole GHC 7.x series. The only way I see is doing
heavy testing on Travis CI and littering the code with #ifdefs after
compilation failures. (BTW: Fun exercise: Try using (<>) and/or (<$>) in
conjunction with -Wall. Bonus points for keeping the #ifdefs centralized.
No clue how to do that...) This is less than satisfactory IMHO, and I would
really prefer some other mode for introducing such changes: Perhaps these
should be bundled and released e.g. every 2 years as Haskell2016,
Haskell2018, etc. This way some stuff which belongs together (AMP, FTP,
kicking out return, etc.) comes in slightly larger, but more sensible
chunks.

Don't get me wrong: Most of the proposed changes in itself are OK and
should be done, it's only the way they are introduced should be improved...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151005/632c915c/attachment.html>

From mantkiew at gsd.uwaterloo.ca  Mon Oct  5 13:43:59 2015
From: mantkiew at gsd.uwaterloo.ca (mantkiew at gsd.uwaterloo.ca)
Date: Mon, 05 Oct 2015 09:43:59 -0400
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
	`return` out of `Monad`
In-Reply-To: <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
Message-ID: <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>

An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151005/3ab6512a/attachment.html>

From hvr at gnu.org  Mon Oct  5 14:32:40 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Mon, 05 Oct 2015 16:32:40 +0200
Subject: [Haskell-cafe] Language Change Management (was: Monad of no
	`return` Proposal (MRP): Moving `return` out of `Monad`)
In-Reply-To: <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 (Sven Panne's message of "Mon, 5 Oct 2015 15:27:53 +0200")
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
Message-ID: <87lhbhperb.fsf_-_@gnu.org>

On 2015-10-05 at 15:27:53 +0200, Sven Panne wrote:
> 2015-10-05 11:59 GMT+02:00 Simon Thompson <s.j.thompson at kent.ac.uk>:
>
>> [...] It?s really interesting to have this discussion, which pulls in all
>> sorts of well-made points about orthogonality, teaching, the evolution of
>> the language and so on, but it simply goes to show that the process of
>> evolving Haskell is profoundly broken. [...]
>>
>
> I wouldn't necessarily call the process "broken", but it's a bit
> annoying: Because of the constant flux of minor changes in the
> language and the libraries, I've reached the stage where I'm totally
> unable to tell if my code will work for the whole GHC 7.x series. The
> only way I see is doing heavy testing on Travis CI and littering the
> code with #ifdefs after compilation failures. (BTW: Fun exercise: Try
> using (<>) and/or (<$>) in conjunction with -Wall. Bonus points for
> keeping the #ifdefs centralized.  No clue how to do that...) This is
> less than satisfactory IMHO, and I would really prefer some other mode
> for introducing such changes: Perhaps these should be bundled and
> released e.g. every 2 years as Haskell2016, Haskell2018, etc. This way
> some stuff which belongs together (AMP, FTP, kicking out return, etc.)
> comes in slightly larger, but more sensible chunks.
>
> Don't get me wrong: Most of the proposed changes in itself are OK and
> should be done, it's only the way they are introduced should be
> improved...

I think that part of the reason we have seen these changes occur in a
"constant flux" rather than in bigger coordinated chunks is that faith
in the Haskell Report process was (understandably) abandoned. And
without the Haskell Report as some kind of "clock generator" with which
to align/bundle related changes into logical units, changes occur
whenever they're proposed and agreed upon (which may take several
attempts as we've seen with the AMP and others).

I hope that the current attempt to revive the Haskell Prime process will
give us a chance to clean up the unfinished intermediate `base-4.8`
situation we're left with now after AMP, FTP et al, as the next Haskell
Report revision provides us with a milestone to work towards.

That being said, there's also the desire to have changes field-tested by
a wide audience on a wide range before integrating them into a Haskell
Report. Also I'm not sure if there would be less complaints if
AMP/FTP/MFP/MRP/etc as part of a new Haskell Report would be switched on
all at once in e.g. `base-5.0`, breaking almost *every* single package
out there at once.

For language changes we have a great way to field-test new extensions
before integrating them into the Report via `{-# LANGUAGE #-}` pragmas
in a nicely modular and composable way (i.e. a package enabling a
certain pragma doesn't require other packages to use it as well) which
have proven to be quite popular.

However, for the library side we lack a comparable mechanism at this
point. The closest we have, for instance, to support an isolated
Haskell2010 legacy environment is to use RebindableSyntax which IMO
isn't good enough in its current form[1]. And then there's the question
whether we want a Haskell2010 legacy environment that's isolated or
rather shares the types & typeclasses w/ `base`. If we require sharing
types and classes, then we may need some facility to implicitly
instanciate new superclasses (e.g. implicitly define Functor and
Applicative if only a Monad instance is defined). If we don't want to
share types & classes, we run into the problem that we can't easily mix
packages which depend on different revisions of the standard-library
(e.g. one using `base-4.8` and others which depend on a legacy
`haskell2010` base-API).  One way to solve this could be to mutually
exclude depending on both , `base-4.8` and `haskell2010`, in the same
install-plan (assuming `haskell2010` doesn't depend itself on
`base-4.8`)

In any case, I think we will have to think hard how to address
language/library change management in the future, especially if the
Haskell code-base continues to grow. Even just migrating the code base
between Haskell Report revisions is a problem. An extreme example
is the Python 2->3 transition which the Python ecosystem is still
suffering from today (afaik). Ideas welcome!



 [1]: IMO, we need something to be used at the definition site providing
      desugaring rules, rather than requiring the use-site to enable a
      generalised desugaring mechanism; I've been told that Agda has an
      interesting solution to this in its base libraries via 
      {-# LANGUAGE BUILTIN ... #-} pragmas.


Regards,
  H.V.Riedel

From gershomb at gmail.com  Mon Oct  5 14:32:21 2015
From: gershomb at gmail.com (Gershom B)
Date: Mon, 5 Oct 2015 10:32:21 -0400
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
Message-ID: <etPan.56128a31.41b8da8.7b73@mbp.local>

On October 5, 2015 at 6:00:00 AM, Simon Thompson (s.j.thompson at kent.ac.uk) wrote:
> Hello all. I write this to be a little provocative, but ?
>  
> It?s really interesting to have this discussion, which pulls in all sorts of well-made  
> points about orthogonality, teaching, the evolution of the language and so on, but it  
> simply goes to show that the process of evolving Haskell is profoundly broken.
>  
> Other languages do evolve, but in a managed and reflective way. Simply throwing in changes  
> that would have a profound impact on systems that are commercially and potentially safety  
> critical in an ? la carte, offhand, way seems like a breakdown of the collective responsibility  
> of the Haskell community to its users and, indirectly, to its future.

Hi Simon. I do in fact think this is provocative :-P

I want to object here to your characterization of what has been going on as ?simply throwing in changes?. The proposal seems very well and carefully worked through to provide a good migration strategy, even planning to alter the source of GHC to ensure that adequate hints are given for the indefinite transition period.

I also want to object to the idea that these changes would have ?a profound impact on systems?. As it stands, and I think this is an important criteria in any change, when ?phase 2? goes into affect, code that has compiled before may cease to compile until a minor change is made. However, code that continues to compile will continue to compile with the same behavior.

Now as to process itself, this is a change to core libraries. It has been proposed on the libraries list, which seems appropriate, and a vigorous discussion has ensued. This seems like a pretty decent process to me thus far. Do you have a better one in mind?

?Gershom

P.S. as a general point, I sympathize with concerns about breakage resulting from this, but I also think that the migration strategy proposed is good, and if people are concerned about breakage I think it would be useful if they could explain where they feel the migration strategy is insufficient to allay their concerns.

From bos at serpentine.com  Mon Oct  5 14:59:32 2015
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Mon, 5 Oct 2015 07:59:32 -0700
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
	`return` out of `Monad`
In-Reply-To: <etPan.56128a31.41b8da8.7b73@mbp.local>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
Message-ID: <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>

I would like to suggest that the bar for breaking all existing libraries, books, papers, and lecture notes should be very high; and that the benefit associated with such a breaking change should be correspondingly huge.

This proposal falls far short of both bars, to the extent that I am astonished and disappointed it is being seriously discussed ? and to general approval, no less ? on a date other than April 1. Surely some design flaws have consequences so small that they are not worth fixing.

I'll survive if it goes through, obviously, but it will commit me to a bunch of pointless make-work and compatibility ifdefs. I've previously expressed my sense that cross-version compatibility is a big tax on library maintainers. This proposal does not give me confidence that this cost is being taken seriously.

Thanks,
Bryan.

> On Oct 5, 2015, at 7:32 AM, Gershom B <gershomb at gmail.com> wrote:
> 
>> On October 5, 2015 at 6:00:00 AM, Simon Thompson (s.j.thompson at kent.ac.uk) wrote:
>> Hello all. I write this to be a little provocative, but ?
>> 
>> It?s really interesting to have this discussion, which pulls in all sorts of well-made  
>> points about orthogonality, teaching, the evolution of the language and so on, but it  
>> simply goes to show that the process of evolving Haskell is profoundly broken.
>> 
>> Other languages do evolve, but in a managed and reflective way. Simply throwing in changes  
>> that would have a profound impact on systems that are commercially and potentially safety  
>> critical in an ? la carte, offhand, way seems like a breakdown of the collective responsibility  
>> of the Haskell community to its users and, indirectly, to its future.
> 
> Hi Simon. I do in fact think this is provocative :-P
> 
> I want to object here to your characterization of what has been going on as ?simply throwing in changes?. The proposal seems very well and carefully worked through to provide a good migration strategy, even planning to alter the source of GHC to ensure that adequate hints are given for the indefinite transition period.
> 
> I also want to object to the idea that these changes would have ?a profound impact on systems?. As it stands, and I think this is an important criteria in any change, when ?phase 2? goes into affect, code that has compiled before may cease to compile until a minor change is made. However, code that continues to compile will continue to compile with the same behavior.
> 
> Now as to process itself, this is a change to core libraries. It has been proposed on the libraries list, which seems appropriate, and a vigorous discussion has ensued. This seems like a pretty decent process to me thus far. Do you have a better one in mind?
> 
> ?Gershom
> 
> P.S. as a general point, I sympathize with concerns about breakage resulting from this, but I also think that the migration strategy proposed is good, and if people are concerned about breakage I think it would be useful if they could explain where they feel the migration strategy is insufficient to allay their concerns.
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

From gershomb at gmail.com  Mon Oct  5 15:09:23 2015
From: gershomb at gmail.com (Gershom B)
Date: Mon, 5 Oct 2015 11:09:23 -0400
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
Message-ID: <etPan.561292df.6eacb1b6.7b73@mbp.local>

On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (bos at serpentine.com) wrote:
> I would like to suggest that the bar for breaking all existing libraries, books, papers,  
> and lecture notes should be very high; and that the benefit associated with such a breaking  
> change should be correspondingly huge.
>  

My understanding of the argument here, which seems to make sense to me, is that the AMP already introduced a significant breaking change with regards to monads. Books and lecture notes have already not caught up to this, by and large. Hence, by introducing a further change, which _completes_ the general AMP project, then by the time books and lecture notes are all updated, they will be able to tell a much nicer story than the current one?

As for libraries, it has been pointed out, I believe, that without CPP one can write instances compatible with AMP, and also with AMP + MRP. One can also write code, sans CPP, compatible with pre- and post- AMP.

So the reason for choosing to not do MRP simultaneous with AMP was precisely to allow a gradual migration path where, sans CPP, people could write code compatible with the last three versions of GHC, as the general criteria has been.

So without arguing the necessity or not, I just want to weigh in with a technical opinion that if this goes through, my _estimation_ is that there will be a smooth and relatively painless migration period, the sky will not fall, good teaching material will remain good, those libraries that bitrot will tend to do so for a variety of reasons more significant than this, etc.

It is totally reasonable to have a discussion on whether this change is worth it at all. But let?s not overestimate the cost of it just to further tip the scales :-)

?gershom

From johan.tibell at gmail.com  Mon Oct  5 15:12:38 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Mon, 5 Oct 2015 17:12:38 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <etPan.561292df.6eacb1b6.7b73@mbp.local>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
Message-ID: <CAK-tuPYL7anMKMeD4NNOvvR1iktsMeGdvQP7RMNCi_NQ21V0TQ@mail.gmail.com>

Perhaps we should weigh the +1 and -1s in this thread with the number of
lines of Haskell written by the voter? ;)

On Mon, Oct 5, 2015 at 5:09 PM, Gershom B <gershomb at gmail.com> wrote:

> On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (bos at serpentine.com)
> wrote:
> > I would like to suggest that the bar for breaking all existing
> libraries, books, papers,
> > and lecture notes should be very high; and that the benefit associated
> with such a breaking
> > change should be correspondingly huge.
> >
>
> My understanding of the argument here, which seems to make sense to me, is
> that the AMP already introduced a significant breaking change with regards
> to monads. Books and lecture notes have already not caught up to this, by
> and large. Hence, by introducing a further change, which _completes_ the
> general AMP project, then by the time books and lecture notes are all
> updated, they will be able to tell a much nicer story than the current one?
>
> As for libraries, it has been pointed out, I believe, that without CPP one
> can write instances compatible with AMP, and also with AMP + MRP. One can
> also write code, sans CPP, compatible with pre- and post- AMP.
>
> So the reason for choosing to not do MRP simultaneous with AMP was
> precisely to allow a gradual migration path where, sans CPP, people could
> write code compatible with the last three versions of GHC, as the general
> criteria has been.
>
> So without arguing the necessity or not, I just want to weigh in with a
> technical opinion that if this goes through, my _estimation_ is that there
> will be a smooth and relatively painless migration period, the sky will not
> fall, good teaching material will remain good, those libraries that bitrot
> will tend to do so for a variety of reasons more significant than this, etc.
>
> It is totally reasonable to have a discussion on whether this change is
> worth it at all. But let?s not overestimate the cost of it just to further
> tip the scales :-)
>
> ?gershom
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151005/3beea509/attachment.html>

From lemming at henning-thielemann.de  Mon Oct  5 17:11:23 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Mon, 5 Oct 2015 19:11:23 +0200 (CEST)
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAK-tuPYL7anMKMeD4NNOvvR1iktsMeGdvQP7RMNCi_NQ21V0TQ@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAK-tuPYL7anMKMeD4NNOvvR1iktsMeGdvQP7RMNCi_NQ21V0TQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1510051910060.7643@sputnik>


On Mon, 5 Oct 2015, Johan Tibell wrote:

> Perhaps we should weigh the +1 and -1s in this thread with the number of 
> lines of Haskell written by the voter? ;)

My prefered measure would the number of Haskell packages hosted at 
hub.darcs.net. :-)

From defigueiredo at ucdavis.edu  Mon Oct  5 17:28:00 2015
From: defigueiredo at ucdavis.edu (Dimitri DeFigueiredo)
Date: Mon, 5 Oct 2015 11:28:00 -0600
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAK-tuPYL7anMKMeD4NNOvvR1iktsMeGdvQP7RMNCi_NQ21V0TQ@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAK-tuPYL7anMKMeD4NNOvvR1iktsMeGdvQP7RMNCi_NQ21V0TQ@mail.gmail.com>
Message-ID: <5612B320.3060701@ucdavis.edu>

+1

I think this idea is good and should not be taken lightly. I'm a 
newcomer to the community and currently hold a grand total of *zero* 
open source contributions. Obviously, I would like to change this soon, 
but I think it is very *unfair* and makes absolutely no sense to have 
the standard one person one vote rule for decisions involving the libraries.

Let the code produced vote. Maybe weight them by downloads?

Dimitri



On 10/5/15 9:12 AM, Johan Tibell wrote:
> Perhaps we should weigh the +1 and -1s in this thread with the number 
> of lines of Haskell written by the voter? ;)
>
> On Mon, Oct 5, 2015 at 5:09 PM, Gershom B <gershomb at gmail.com 
> <mailto:gershomb at gmail.com>> wrote:
>
>     On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan
>     (bos at serpentine.com <mailto:bos at serpentine.com>) wrote:
>     > I would like to suggest that the bar for breaking all existing
>     libraries, books, papers,
>     > and lecture notes should be very high; and that the benefit
>     associated with such a breaking
>     > change should be correspondingly huge.
>     >
>
>     My understanding of the argument here, which seems to make sense
>     to me, is that the AMP already introduced a significant breaking
>     change with regards to monads. Books and lecture notes have
>     already not caught up to this, by and large. Hence, by introducing
>     a further change, which _completes_ the general AMP project, then
>     by the time books and lecture notes are all updated, they will be
>     able to tell a much nicer story than the current one?
>
>     As for libraries, it has been pointed out, I believe, that without
>     CPP one can write instances compatible with AMP, and also with AMP
>     + MRP. One can also write code, sans CPP, compatible with pre- and
>     post- AMP.
>
>     So the reason for choosing to not do MRP simultaneous with AMP was
>     precisely to allow a gradual migration path where, sans CPP,
>     people could write code compatible with the last three versions of
>     GHC, as the general criteria has been.
>
>     So without arguing the necessity or not, I just want to weigh in
>     with a technical opinion that if this goes through, my
>     _estimation_ is that there will be a smooth and relatively
>     painless migration period, the sky will not fall, good teaching
>     material will remain good, those libraries that bitrot will tend
>     to do so for a variety of reasons more significant than this, etc.
>
>     It is totally reasonable to have a discussion on whether this
>     change is worth it at all. But let?s not overestimate the cost of
>     it just to further tip the scales :-)
>
>     ?gershom
>     _______________________________________________
>     Libraries mailing list
>     Libraries at haskell.org <mailto:Libraries at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151005/336d44ef/attachment.html>

From jwlato at gmail.com  Mon Oct  5 18:33:42 2015
From: jwlato at gmail.com (John Lato)
Date: Mon, 05 Oct 2015 18:33:42 +0000
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <5612B320.3060701@ucdavis.edu>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAK-tuPYL7anMKMeD4NNOvvR1iktsMeGdvQP7RMNCi_NQ21V0TQ@mail.gmail.com>
 <5612B320.3060701@ucdavis.edu>
Message-ID: <CAJ727GjOyrtnx0NoeMex5QtkiLrC_7aB7edan0j-6bySjAn36Q@mail.gmail.com>

I think code-based weighting should not be considered at all. There's a
non-trivial amount of proprietary code that wouldn't be counted, and likely
can't be accounted for accurately. I have some unknown amount of code at my
previous employer (which does include Monad instances) that now has to be
maintained by others. I may have said +1 (and I'm reconsidering), but the
current maintainers probably don't want the extra make-work this involves.

There's an argument that this proposal involves very little up-front
breakage. This is true but disingenuous, because the breakage will still
happen in the future unless changes are made and committed. The entire
maintenance load should be considered, not just the immediate load.

Bryan, nothing I've seen since I started using Haskell makes me think that
the libraries committee or ghc devs value back compatibility much at all.
My favorite example is RecursiveDo, which was deprecated in favor of DoRec,
only for that to be reversed in the next ghc release. Of course that was
more irritating than breaking, but it's indicative of the general value
placed on maintenance programming.

On 12:28, Mon, Oct 5, 2015 Dimitri DeFigueiredo <defigueiredo at ucdavis.edu>
wrote:

> +1
>
> I think this idea is good and should not be taken lightly. I'm a newcomer
> to the community and currently hold a grand total of *zero* open source
> contributions. Obviously, I would like to change this soon, but I think it
> is very *unfair* and makes absolutely no sense to have the standard one
> person one vote rule for decisions involving the libraries.
>
> Let the code produced vote. Maybe weight them by downloads?
>
> Dimitri
>
>
>
>
> On 10/5/15 9:12 AM, Johan Tibell wrote:
>
> Perhaps we should weigh the +1 and -1s in this thread with the number of
> lines of Haskell written by the voter? ;)
>
> On Mon, Oct 5, 2015 at 5:09 PM, Gershom B <gershomb at gmail.com> wrote:
>
>> On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (bos at serpentine.com)
>> wrote:
>> > I would like to suggest that the bar for breaking all existing
>> libraries, books, papers,
>> > and lecture notes should be very high; and that the benefit associated
>> with such a breaking
>> > change should be correspondingly huge.
>> >
>>
>> My understanding of the argument here, which seems to make sense to me,
>> is that the AMP already introduced a significant breaking change with
>> regards to monads. Books and lecture notes have already not caught up to
>> this, by and large. Hence, by introducing a further change, which
>> _completes_ the general AMP project, then by the time books and lecture
>> notes are all updated, they will be able to tell a much nicer story than
>> the current one?
>>
>> As for libraries, it has been pointed out, I believe, that without CPP
>> one can write instances compatible with AMP, and also with AMP + MRP. One
>> can also write code, sans CPP, compatible with pre- and post- AMP.
>>
>> So the reason for choosing to not do MRP simultaneous with AMP was
>> precisely to allow a gradual migration path where, sans CPP, people could
>> write code compatible with the last three versions of GHC, as the general
>> criteria has been.
>>
>> So without arguing the necessity or not, I just want to weigh in with a
>> technical opinion that if this goes through, my _estimation_ is that there
>> will be a smooth and relatively painless migration period, the sky will not
>> fall, good teaching material will remain good, those libraries that bitrot
>> will tend to do so for a variety of reasons more significant than this, etc.
>>
>> It is totally reasonable to have a discussion on whether this change is
>> worth it at all. But let?s not overestimate the cost of it just to further
>> tip the scales :-)
>>
>> ?gershom
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
>
>
> _______________________________________________
> Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151005/8910ab8c/attachment.html>

From greg at gregorycollins.net  Mon Oct  5 18:34:31 2015
From: greg at gregorycollins.net (Gregory Collins)
Date: Mon, 5 Oct 2015 11:34:31 -0700
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <etPan.561292df.6eacb1b6.7b73@mbp.local>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
Message-ID: <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>

On Mon, Oct 5, 2015 at 8:09 AM, Gershom B <gershomb at gmail.com> wrote:

> My understanding of the argument here, which seems to make sense to me, is
> that the AMP already introduced a significant breaking change with regards
> to monads. Books and lecture notes have already not caught up to this, by
> and large. Hence, by introducing a further change, which _completes_ the
> general AMP project, then by the time books and lecture notes are all
> updated, they will be able to tell a much nicer story than the current one?


This is a multi-year, "boil the ocean"-style project, affecting literally
every Haskell user, and the end result after all of this labor is going to
be... a slightly spiffier bike shed?

Strongly -1 from me also. My experience over the last couple of years is
that every GHC release breaks my libraries in annoying ways that require
CPP to fix:

~/personal/src/snap ?  find . -name '*.hs' | xargs egrep
'#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l
64


As a user this is another bikeshedding change that is not going to benefit
me at all. Maintaining a Haskell library can be an exasperating exercise of
running on a treadmill to keep up with busywork caused by changes to the
core language and libraries. My feeling is starting to become that the
libraries committee is doing as much (if not more) to *cause* problems and
work for me than it is doing to improve the common infrastructure.

G
-- 
Gregory Collins <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151005/0016c4cd/attachment.html>

From nbouscal at gmail.com  Mon Oct  5 18:50:27 2015
From: nbouscal at gmail.com (Nathan Bouscal)
Date: Mon, 5 Oct 2015 19:50:27 +0100
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <5612B320.3060701@ucdavis.edu>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAK-tuPYL7anMKMeD4NNOvvR1iktsMeGdvQP7RMNCi_NQ21V0TQ@mail.gmail.com>
 <5612B320.3060701@ucdavis.edu>
Message-ID: <CABhOzZhTRw0N2M=QBJ8GV0VsmWHwOS_02AyS5R04vAeBefrz9A@mail.gmail.com>

I'm a strong +1 on this (and on Edward's addendum to it), and I object to
the characterization of this change as having only trivial benefits.
Simplicity and correctness are never trivial. In my view, disagreement on
*how* this change is made (migration strategy, etc.) is completely
reasonable, but disagreement on *whether* to make it is not.

There have been a lot of objections based on the idea that learners will
consult books that are out of date, but the number of learners affected by
this is dwarfed by the number of learners who will use updated materials
and be confused by this strange historical artifact. Permanently-enshrined
historical artifacts accrete forever and cause linear confusion, whereas
outdated materials are inevitably replaced such that the amount of
confusion remains constant.

There was also an argument that Haskell has a ?window of opportunity?,
implying that breakages are more likely to cost us future valued community
members than historical artifacts are. I couldn't disagree more. If it
weren't for Haskell's past willingness to make changes when we learned
better ways of doing things, I doubt I would presently be using the
language. I would much rather add a marginal community member with a strong
preference for cleanliness, simplicity, and correctness than one with a
strong preference against making occasional small changes to their code.
?

On Mon, Oct 5, 2015 at 6:28 PM, Dimitri DeFigueiredo <
defigueiredo at ucdavis.edu> wrote:

> +1
>
> I think this idea is good and should not be taken lightly. I'm a newcomer
> to the community and currently hold a grand total of *zero* open source
> contributions. Obviously, I would like to change this soon, but I think it
> is very *unfair* and makes absolutely no sense to have the standard one
> person one vote rule for decisions involving the libraries.
>
> Let the code produced vote. Maybe weight them by downloads?
>
> Dimitri
>
>
>
>
> On 10/5/15 9:12 AM, Johan Tibell wrote:
>
> Perhaps we should weigh the +1 and -1s in this thread with the number of
> lines of Haskell written by the voter? ;)
>
> On Mon, Oct 5, 2015 at 5:09 PM, Gershom B <gershomb at gmail.com> wrote:
>
>> On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (bos at serpentine.com)
>> wrote:
>> > I would like to suggest that the bar for breaking all existing
>> libraries, books, papers,
>> > and lecture notes should be very high; and that the benefit associated
>> with such a breaking
>> > change should be correspondingly huge.
>> >
>>
>> My understanding of the argument here, which seems to make sense to me,
>> is that the AMP already introduced a significant breaking change with
>> regards to monads. Books and lecture notes have already not caught up to
>> this, by and large. Hence, by introducing a further change, which
>> _completes_ the general AMP project, then by the time books and lecture
>> notes are all updated, they will be able to tell a much nicer story than
>> the current one?
>>
>> As for libraries, it has been pointed out, I believe, that without CPP
>> one can write instances compatible with AMP, and also with AMP + MRP. One
>> can also write code, sans CPP, compatible with pre- and post- AMP.
>>
>> So the reason for choosing to not do MRP simultaneous with AMP was
>> precisely to allow a gradual migration path where, sans CPP, people could
>> write code compatible with the last three versions of GHC, as the general
>> criteria has been.
>>
>> So without arguing the necessity or not, I just want to weigh in with a
>> technical opinion that if this goes through, my _estimation_ is that there
>> will be a smooth and relatively painless migration period, the sky will not
>> fall, good teaching material will remain good, those libraries that bitrot
>> will tend to do so for a variety of reasons more significant than this, etc.
>>
>> It is totally reasonable to have a discussion on whether this change is
>> worth it at all. But let?s not overestimate the cost of it just to further
>> tip the scales :-)
>>
>> ?gershom
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
>
>
> _______________________________________________
> Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151005/f5391a70/attachment-0001.html>

From svenpanne at gmail.com  Mon Oct  5 18:58:57 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Mon, 5 Oct 2015 20:58:57 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <etPan.561292df.6eacb1b6.7b73@mbp.local>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
Message-ID: <CANBN=mv6WPLRdvLJppOZ2=1zkd7sWKAHwTF3rHie27RS_YLesA@mail.gmail.com>

2015-10-05 17:09 GMT+02:00 Gershom B <gershomb at gmail.com>:

> On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (bos at serpentine.com)
> wrote:
> [...] As for libraries, it has been pointed out, I believe, that without
> CPP one can write instances compatible with AMP, and also with AMP + MRP.
> One can also write code, sans CPP, compatible with pre- and post- AMP. [...]
>

Nope, at least not if you care about -Wall: If you take e.g. (<$>) which is
now part of the Prelude, you can't simply import some compatibility module,
because GHC might tell you (rightfully) that that import is redundant,
because (<$>) is already visible through the Prelude. So you'll have to use
CPP to avoid that import on base >= 4.8, be it from it Data.Functor,
Control.Applicative or some compat-* module. And you'll have to use CPP in
each and every module using <$> then, unless I miss something obvious.
AFAICT all transitioning guides ignore -Wall and friends...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151005/f3c8d168/attachment.html>

From johan.tibell at gmail.com  Mon Oct  5 19:01:16 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Mon, 5 Oct 2015 21:01:16 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
Message-ID: <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>

On Mon, Oct 5, 2015 at 8:34 PM, Gregory Collins <greg at gregorycollins.net>
wrote:

>
> On Mon, Oct 5, 2015 at 8:09 AM, Gershom B <gershomb at gmail.com> wrote:
>
>> My understanding of the argument here, which seems to make sense to me,
>> is that the AMP already introduced a significant breaking change with
>> regards to monads. Books and lecture notes have already not caught up to
>> this, by and large. Hence, by introducing a further change, which
>> _completes_ the general AMP project, then by the time books and lecture
>> notes are all updated, they will be able to tell a much nicer story than
>> the current one?
>
>
> This is a multi-year, "boil the ocean"-style project, affecting literally
> every Haskell user, and the end result after all of this labor is going to
> be... a slightly spiffier bike shed?
>
> Strongly -1 from me also. My experience over the last couple of years is
> that every GHC release breaks my libraries in annoying ways that require
> CPP to fix:
>
> ~/personal/src/snap ?  find . -name '*.hs' | xargs egrep
> '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l
> 64
>
>
> As a user this is another bikeshedding change that is not going to benefit
> me at all. Maintaining a Haskell library can be an exasperating exercise of
> running on a treadmill to keep up with busywork caused by changes to the
> core language and libraries. My feeling is starting to become that the
> libraries committee is doing as much (if not more) to *cause* problems
> and work for me than it is doing to improve the common infrastructure.
>

On the libraries I maintain and have a copy of on my computer right now: 329
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151005/4542b2ff/attachment.html>

From hesselink at gmail.com  Mon Oct  5 19:02:26 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Mon, 5 Oct 2015 21:02:26 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CANBN=mv6WPLRdvLJppOZ2=1zkd7sWKAHwTF3rHie27RS_YLesA@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CANBN=mv6WPLRdvLJppOZ2=1zkd7sWKAHwTF3rHie27RS_YLesA@mail.gmail.com>
Message-ID: <CAPeieQFUzFD4q0tToxZiNc4_GKkH2TbVvZpe65P_NzawOftCrA@mail.gmail.com>

On 5 October 2015 at 20:58, Sven Panne <svenpanne at gmail.com> wrote:
> 2015-10-05 17:09 GMT+02:00 Gershom B <gershomb at gmail.com>:
>>
>> [...] As for libraries, it has been pointed out, I believe, that without
>> CPP one can write instances compatible with AMP, and also with AMP + MRP.
>> One can also write code, sans CPP, compatible with pre- and post- AMP. [...]
>
> Nope, at least not if you care about -Wall: If you take e.g. (<$>) which is
> now part of the Prelude, you can't simply import some compatibility module,
> because GHC might tell you (rightfully) that that import is redundant,
> because (<$>) is already visible through the Prelude. So you'll have to use
> CPP to avoid that import on base >= 4.8, be it from it Data.Functor,
> Control.Applicative or some compat-* module. And you'll have to use CPP in
> each and every module using <$> then, unless I miss something obvious.
> AFAICT all transitioning guides ignore -Wall and friends...

Does the hack mentioned on the GHC trac [1] work for this? It seems a
bit fragile but that page says it works and it avoids CPP.

Erik

[1] https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10#GHCsaysTheimportof...isredundant

From johan.tibell at gmail.com  Mon Oct  5 19:05:40 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Mon, 5 Oct 2015 21:05:40 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAPeieQFUzFD4q0tToxZiNc4_GKkH2TbVvZpe65P_NzawOftCrA@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CANBN=mv6WPLRdvLJppOZ2=1zkd7sWKAHwTF3rHie27RS_YLesA@mail.gmail.com>
 <CAPeieQFUzFD4q0tToxZiNc4_GKkH2TbVvZpe65P_NzawOftCrA@mail.gmail.com>
Message-ID: <CAK-tuPa7w_=5gXfZ78NDWPAWX1K8_rM+9jUbm7yZUCAwZYdr5Q@mail.gmail.com>

On Mon, Oct 5, 2015 at 9:02 PM, Erik Hesselink <hesselink at gmail.com> wrote:

> On 5 October 2015 at 20:58, Sven Panne <svenpanne at gmail.com> wrote:
> > 2015-10-05 17:09 GMT+02:00 Gershom B <gershomb at gmail.com>:
> >>
> >> [...] As for libraries, it has been pointed out, I believe, that without
> >> CPP one can write instances compatible with AMP, and also with AMP +
> MRP.
> >> One can also write code, sans CPP, compatible with pre- and post- AMP.
> [...]
> >
> > Nope, at least not if you care about -Wall: If you take e.g. (<$>) which
> is
> > now part of the Prelude, you can't simply import some compatibility
> module,
> > because GHC might tell you (rightfully) that that import is redundant,
> > because (<$>) is already visible through the Prelude. So you'll have to
> use
> > CPP to avoid that import on base >= 4.8, be it from it Data.Functor,
> > Control.Applicative or some compat-* module. And you'll have to use CPP
> in
> > each and every module using <$> then, unless I miss something obvious.
> > AFAICT all transitioning guides ignore -Wall and friends...
>
> Does the hack mentioned on the GHC trac [1] work for this? It seems a
> bit fragile but that page says it works and it avoids CPP.
>

No it doesn't, if you also don't want closed import lists (which you
should).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151005/fbc07861/attachment.html>

From cma at bitemyapp.com  Mon Oct  5 19:08:09 2015
From: cma at bitemyapp.com (Christopher Allen)
Date: Mon, 5 Oct 2015 14:08:09 -0500
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
Message-ID: <CADnndOqmZteBtMHveFO=+=vmnPDki2rJ7=+bOEXhWMD9sfnGWw@mail.gmail.com>

I'm writing a book (http://haskellbook.com/) with my coauthor. It is up to
date with GHC 7.10. AMP made things better, not harder, with respect to
teaching Haskell. BBP required some explanation of "ignore this type, we're
asserting a different one", but the positives are still better than the
negatives.

Please don't use existing or forthcoming books as an excuse to do or not-do
things. Do what's right for the users of the language.

On Mon, Oct 5, 2015 at 2:01 PM, Johan Tibell <johan.tibell at gmail.com> wrote:

> On Mon, Oct 5, 2015 at 8:34 PM, Gregory Collins <greg at gregorycollins.net>
> wrote:
>
>>
>> On Mon, Oct 5, 2015 at 8:09 AM, Gershom B <gershomb at gmail.com> wrote:
>>
>>> My understanding of the argument here, which seems to make sense to me,
>>> is that the AMP already introduced a significant breaking change with
>>> regards to monads. Books and lecture notes have already not caught up to
>>> this, by and large. Hence, by introducing a further change, which
>>> _completes_ the general AMP project, then by the time books and lecture
>>> notes are all updated, they will be able to tell a much nicer story than
>>> the current one?
>>
>>
>> This is a multi-year, "boil the ocean"-style project, affecting literally
>> every Haskell user, and the end result after all of this labor is going to
>> be... a slightly spiffier bike shed?
>>
>> Strongly -1 from me also. My experience over the last couple of years is
>> that every GHC release breaks my libraries in annoying ways that require
>> CPP to fix:
>>
>> ~/personal/src/snap ?  find . -name '*.hs' | xargs egrep
>> '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l
>> 64
>>
>>
>> As a user this is another bikeshedding change that is not going to
>> benefit me at all. Maintaining a Haskell library can be an exasperating
>> exercise of running on a treadmill to keep up with busywork caused by
>> changes to the core language and libraries. My feeling is starting to
>> become that the libraries committee is doing as much (if not more) to
>> *cause* problems and work for me than it is doing to improve the common
>> infrastructure.
>>
>
> On the libraries I maintain and have a copy of on my computer right now:
> 329
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>


-- 
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151005/e339ef4e/attachment.html>

From marcin.jan.mrotek at gmail.com  Mon Oct  5 19:21:52 2015
From: marcin.jan.mrotek at gmail.com (Marcin Mrotek)
Date: Mon, 5 Oct 2015 21:21:52 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAJ727GjOyrtnx0NoeMex5QtkiLrC_7aB7edan0j-6bySjAn36Q@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAK-tuPYL7anMKMeD4NNOvvR1iktsMeGdvQP7RMNCi_NQ21V0TQ@mail.gmail.com>
 <5612B320.3060701@ucdavis.edu>
 <CAJ727GjOyrtnx0NoeMex5QtkiLrC_7aB7edan0j-6bySjAn36Q@mail.gmail.com>
Message-ID: <CAJcfPz=9zqjnehDGSV3or_foj+BM+A37iLozJX-tfhUBmATJAg@mail.gmail.com>

> There's an argument that this proposal involves very little up-front
> breakage. This is true but disingenuous, because the breakage will still
> happen in the future unless changes are made and committed. The entire
> maintenance load should be considered, not just the immediate load.

I don't have much to say about breakage (and thus I've refrained from
voting), as a maintainer of just 7 packages of which exactly zero are
compatible with anything else than the latest GHC (well, no one
complained, I'm rather lazy, and if it's any defense I can't even run
GHC 7.10.1 on my Arch Linux box because of inappropriate versions of
dynamically linked libraries), but a honest question: does this
proposal entail anything else than replacing every "return" with
"pure" and conditional compilation of "return = pure" in Monad
instances?

Best regards,
Marcin Mrotek

From quentin.leguennec1 at gmail.com  Mon Oct  5 19:37:49 2015
From: quentin.leguennec1 at gmail.com (Quentin Le Guennec)
Date: Mon, 5 Oct 2015 21:37:49 +0200
Subject: [Haskell-cafe] Teaching haskell at the 42 french school
Message-ID: <CANMnDVNcgoTgLV0q9et8LUxU66_k_Bx948XC42cX3+VXrWC++w@mail.gmail.com>

Hi, as an introduction, it would be a good advice to first look, if you did
not heard of it yet, at what the 42 school is:
http://www.42.fr/42-revolutionary-computer-training-free-and-open-to-all/
(TL;DR:
*"unique pedagogical approach and accessibility to all, completely free of
charge, 42 is the most daring response yet to the challenge of
information-technology skill development", "**Innovative teaching methods
in technology training: Peer-to-Peer learning"*)

?The school aims to teach a general knowledge of computer science, but does
not provide a Haskell course yet. ?The exercices and projects are built by
students, for students. I love haskell and I'd be really happy to teach
that wonderful language, and I'd love to hear your suggestions. I was
thinking of the haskell's hard learning way. (I gotta say, the school's
pedagogy is pretty sadistic).


   - Recode List, (,), Either, Maybe and their
   functor/applicative/monad/etc instances (implying recode those data types
   first)
   - String manipulation (basically recode Data.List). Any ideas for
   prevent students from just copy pasting the hackage code source?
   - Red black trees are fun, aren't they?
   - Some kind of AI to solve, for example, Rubik's cube

One other thing, this may be very sadistic, but I would like to ask what do
you think of allowing ONLY pointfree? It may end-up by having different
answers and promote beautiful and concise code. Please expose your ideas,
everything is feasible, bonus added to traps, hard to solve problems, and
everything that may lead the student to think a lot.

Thanks.


-- 
Quentin Le Guennec
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151005/cc099313/attachment.html>

From yom at artyom.me  Mon Oct  5 19:56:10 2015
From: yom at artyom.me (Artyom)
Date: Mon, 05 Oct 2015 22:56:10 +0300
Subject: [Haskell-cafe] Teaching haskell at the 42 french school
In-Reply-To: <CANMnDVNcgoTgLV0q9et8LUxU66_k_Bx948XC42cX3+VXrWC++w@mail.gmail.com>
References: <CANMnDVNcgoTgLV0q9et8LUxU66_k_Bx948XC42cX3+VXrWC++w@mail.gmail.com>
Message-ID: <5612D5DA.9090702@artyom.me>

 > what do you think of allowing ONLY pointfree? It may end-up by having 
different answers and promote beautiful and concise code

This would be very sadistic, yes ? to people who would have to read code 
written by 42's graduates! I urge you to avoid it.

 > Red black trees are fun, aren't they?

They are also on a rather different level of difficulty from rewriting 
Data.List and friends (which is what beginners often do on their first 
day of learning). So, I don't understand what your intended level 
actually is. If it's ?can understand red-black trees and write them 
without blindly copying code?, you could skip rewriting Data.List and go 
straight to:

* monad transformers
* lenses
* the Cont monad
* free monads

On the other hand, if rewriting Data.List is necessary, then take a look 
at Richard Bird's book Thinking Functionally With Haskell ? it would be 
a perfect fit for you.

From alan.zimm at gmail.com  Mon Oct  5 20:27:30 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Mon, 5 Oct 2015 22:27:30 +0200
Subject: [Haskell-cafe] ANN: HaRe 0.8 - The Haskell Refactorer
In-Reply-To: <CANma=H-j=xYBE-gAp_Ou-fJyv4TH2TEz=VqbZhh8sOC9OYzb+g@mail.gmail.com>
References: <CANma=H-j=xYBE-gAp_Ou-fJyv4TH2TEz=VqbZhh8sOC9OYzb+g@mail.gmail.com>
Message-ID: <CANma=H8sAWNr8VJVk5dKh4Y9a6i-hXjS5d_=FnpF_aBQG7mdEw@mail.gmail.com>

Update: Version 0.8.1 is out, which fixes renaming that crosses module
boundaries and preserves CPP directives

On Sun, Oct 4, 2015 at 10:18 PM, Alan & Kim Zimmerman <alan.zimm at gmail.com>
wrote:

> I'm pleased to announce the release of HaRe 0.8, available on hackage [1]
>
> What's new?
> ===========
>
> Everything, and nothing.
>
> Everything in the sense that it has been completely reworked internally to
> make
> use of the new API Annotations [2] in GHC 7.10.2, via the ghc-exactprint
> [3]
> library.
>
> Nothing in the sense that the functionality in this version is/should be
> identical to that in 0.7.2.8
>
> Limitations
> ===========
>
> HaRe 0.8 will only work for projects using GHC 7.10.2 for compilation.
> Compiling
> HaRe with 7.10.2 and then using it against projects using an earlier
> compiler
> will not work, as HaRe needs to be able to invoke GHC to the type checker
> stage
> on the project using GHC 7.10.2.
>
> What is it?
> ===========
>
> HaRe makes changes to working code, so that it still works once the change
> is
> made.
>
> Refactorings it can do are
>
> * demote
>
>   Take a declaration from the level where it is defined and move it down
> to the
>   place where it is used. This only works if it is used in one place only.
>
> * dupdef
>
>   Duplicate a definition with a new name.
>
> * iftocase
>
>   Convert an if declaration to a case declaration.
>
> * liftOneLevel
>
>   Move a declaration one level up, adding parameters as needed to pass in
>   locally declared variables.
>
> * liftToTopLevel
>
>   Move a declaration to the top level, adding parameters as needed to pass
> in
>   locally declared variables.
>
> * rename
>
>   Change a name throughout the project. This makes use of the GHC renamed
> source
>   so will not change other names that just happen to be lexically
> identical, but
>   are in fact different names.
>
> It currently has an emacs integration only, assistance in supporting other
> environnments welcome.
>
> [1] https://hackage.haskell.org/package/HaRe
> [2] https://ghc.haskell.org/trac/ghc/wiki/ApiAnnotations
> [3] https://hackage.haskell.org/package/ghc-exactprint
>
> Alan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151005/6853ebfc/attachment.html>

From mantkiew at gsd.uwaterloo.ca  Mon Oct  5 21:21:13 2015
From: mantkiew at gsd.uwaterloo.ca (mantkiew at gsd.uwaterloo.ca)
Date: Mon, 05 Oct 2015 17:21:13 -0400
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
	`return` out of `Monad`
In-Reply-To: <CAGW9QSyFwfCE4OxOenD4N5aUXLkp0rVCxWSB5v=euiFAPmN3_Q@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAGW9QSyFwfCE4OxOenD4N5aUXLkp0rVCxWSB5v=euiFAPmN3_Q@mail.gmail.com>
Message-ID: <20151005212113.5476430.73664.12679@gsd.uwaterloo.ca>

I loved the statement made by Ryan Trinkle in his recent talk [1]: "since we cannot predict all the changes needed the future, we must have an architecture that will support any change" (it's roughly like that, not an exact quote, about 4minutes in).

Having to use IFDEFs is a sign that the language itself is not expressive enough to deal with these kinds of changes and therefore it's not having the right "architecture". Is Backpack going to provide the necessary support, (e.g., ability to mix in package fragments with extensions instead of making breaking changes)? What kind of language features are still missing?

Anyway, mistakes were made in the past, because had we known any better we would have done better. Nothing should prevent us from fixing mistakes. 

Regarding IFDEFS, all of them disappeared from my code once I used transformers-compat and mtl-compat. ?Also the trick with import Prelude worked-you just have to list what you hide instead of what you import (which is weird...).?

--
Micha?

[1] http://www.infoq.com/presentations/functional-techniques-complexity

On Mon, Oct 5, 2015 at 2:34 PM, Gregory Collins <greg at gregorycollins.net> wrote:
>
> On Mon, Oct 5, 2015 at 8:09 AM, Gershom B <gershomb at gmail.com> wrote:
>>
>> My understanding of the argument here, which seems to make sense to me, is
>> that the AMP already introduced a significant breaking change with regards
>> to monads. Books and lecture notes have already not caught up to this, by
>> and large. Hence, by introducing a further change, which _completes_ the
>> general AMP project, then by the time books and lecture notes are all
>> updated, they will be able to tell a much nicer story than the current one?
>
>
> This is a multi-year, "boil the ocean"-style project, affecting literally
> every Haskell user, and the end result after all of this labor is going to
> be... a slightly spiffier bike shed?
>
> Strongly -1 from me also. My experience over the last couple of years is
> that every GHC release breaks my libraries in annoying ways that require CPP
> to fix:
>
> ~/personal/src/snap ? find . -name '*.hs' | xargs egrep
> '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l
> 64
>
>
> As a user this is another bikeshedding change that is not going to benefit
> me at all. Maintaining a Haskell library can be an exasperating exercise of
> running on a treadmill to keep up with busywork caused by changes to the
> core language and libraries. My feeling is starting to become that the
> libraries committee is doing as much (if not more) to cause problems and
> work for me than it is doing to improve the common infrastructure.
>
> G
> --
> Gregory Collins <greg at gregorycollins.net>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>

From acfoltzer at gmail.com  Mon Oct  5 21:23:08 2015
From: acfoltzer at gmail.com (Adam Foltzer)
Date: Mon, 5 Oct 2015 14:23:08 -0700
Subject: [Haskell-cafe] Language Change Management (was: Monad of no
 `return` Proposal (MRP): Moving `return` out of `Monad`)
In-Reply-To: <87lhbhperb.fsf_-_@gnu.org>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <87lhbhperb.fsf_-_@gnu.org>
Message-ID: <CAPorAaGN0P8PMh4Nvu=zD_XGc7g+t_gQZBtzKtQTDSgWrjEs8Q@mail.gmail.com>

Thanks for splitting this off, as it really deserves its own conversation.

% find cryptol -name '*.hs' | xargs egrep
'#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l
      49
% find saw-script -name '*.hs' | xargs egrep
'#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l
     242

I introduced most of these in order to accommodate AMP, and now I learn
that there is another proposal that is considered to be part-and-parcel
with AMP where I will have to make yet more changes to the same code and
presumably introduce another layer of #ifdefs. As proposed, I will spend
2*n hours implementing, testing, and releasing these changes. Had both
changes been bundled, it would have been 2*(n+?).

 Also I'm not sure if there would be less complaints if AMP/FTP/MFP/MRP/etc
> as part of a new Haskell Report would be switched on all at once in e.g.
> `base-5.0`, breaking almost *every* single package out there at once.


I doubt the number of complaints-per-change would be fewer, but I'm
strongly in favor of moving away from what feels like a treadmill that
doesn't value the time of developers and that doesn't account for the
more-than-sum-of-parts cost of the "constant flux".

Thanks,
Adam

On Mon, Oct 5, 2015 at 7:32 AM, Herbert Valerio Riedel <hvr at gnu.org> wrote:

> On 2015-10-05 at 15:27:53 +0200, Sven Panne wrote:
> > 2015-10-05 11:59 GMT+02:00 Simon Thompson <s.j.thompson at kent.ac.uk>:
> >
> >> [...] It?s really interesting to have this discussion, which pulls in
> all
> >> sorts of well-made points about orthogonality, teaching, the evolution
> of
> >> the language and so on, but it simply goes to show that the process of
> >> evolving Haskell is profoundly broken. [...]
> >>
> >
> > I wouldn't necessarily call the process "broken", but it's a bit
> > annoying: Because of the constant flux of minor changes in the
> > language and the libraries, I've reached the stage where I'm totally
> > unable to tell if my code will work for the whole GHC 7.x series. The
> > only way I see is doing heavy testing on Travis CI and littering the
> > code with #ifdefs after compilation failures. (BTW: Fun exercise: Try
> > using (<>) and/or (<$>) in conjunction with -Wall. Bonus points for
> > keeping the #ifdefs centralized.  No clue how to do that...) This is
> > less than satisfactory IMHO, and I would really prefer some other mode
> > for introducing such changes: Perhaps these should be bundled and
> > released e.g. every 2 years as Haskell2016, Haskell2018, etc. This way
> > some stuff which belongs together (AMP, FTP, kicking out return, etc.)
> > comes in slightly larger, but more sensible chunks.
> >
> > Don't get me wrong: Most of the proposed changes in itself are OK and
> > should be done, it's only the way they are introduced should be
> > improved...
>
> I think that part of the reason we have seen these changes occur in a
> "constant flux" rather than in bigger coordinated chunks is that faith
> in the Haskell Report process was (understandably) abandoned. And
> without the Haskell Report as some kind of "clock generator" with which
> to align/bundle related changes into logical units, changes occur
> whenever they're proposed and agreed upon (which may take several
> attempts as we've seen with the AMP and others).
>
> I hope that the current attempt to revive the Haskell Prime process will
> give us a chance to clean up the unfinished intermediate `base-4.8`
> situation we're left with now after AMP, FTP et al, as the next Haskell
> Report revision provides us with a milestone to work towards.
>
> That being said, there's also the desire to have changes field-tested by
> a wide audience on a wide range before integrating them into a Haskell
> Report. Also I'm not sure if there would be less complaints if
> AMP/FTP/MFP/MRP/etc as part of a new Haskell Report would be switched on
> all at once in e.g. `base-5.0`, breaking almost *every* single package
> out there at once.
>
> For language changes we have a great way to field-test new extensions
> before integrating them into the Report via `{-# LANGUAGE #-}` pragmas
> in a nicely modular and composable way (i.e. a package enabling a
> certain pragma doesn't require other packages to use it as well) which
> have proven to be quite popular.
>
> However, for the library side we lack a comparable mechanism at this
> point. The closest we have, for instance, to support an isolated
> Haskell2010 legacy environment is to use RebindableSyntax which IMO
> isn't good enough in its current form[1]. And then there's the question
> whether we want a Haskell2010 legacy environment that's isolated or
> rather shares the types & typeclasses w/ `base`. If we require sharing
> types and classes, then we may need some facility to implicitly
> instanciate new superclasses (e.g. implicitly define Functor and
> Applicative if only a Monad instance is defined). If we don't want to
> share types & classes, we run into the problem that we can't easily mix
> packages which depend on different revisions of the standard-library
> (e.g. one using `base-4.8` and others which depend on a legacy
> `haskell2010` base-API).  One way to solve this could be to mutually
> exclude depending on both , `base-4.8` and `haskell2010`, in the same
> install-plan (assuming `haskell2010` doesn't depend itself on
> `base-4.8`)
>
> In any case, I think we will have to think hard how to address
> language/library change management in the future, especially if the
> Haskell code-base continues to grow. Even just migrating the code base
> between Haskell Report revisions is a problem. An extreme example
> is the Python 2->3 transition which the Python ecosystem is still
> suffering from today (afaik). Ideas welcome!
>
>
>
>  [1]: IMO, we need something to be used at the definition site providing
>       desugaring rules, rather than requiring the use-site to enable a
>       generalised desugaring mechanism; I've been told that Agda has an
>       interesting solution to this in its base libraries via
>       {-# LANGUAGE BUILTIN ... #-} pragmas.
>
>
> Regards,
>   H.V.Riedel
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151005/f7f523ac/attachment.html>

From b at chreekat.net  Mon Oct  5 22:18:29 2015
From: b at chreekat.net (Bryan Richter)
Date: Mon, 5 Oct 2015 15:18:29 -0700
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
Message-ID: <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>

On Mon, Oct 5, 2015 at 06:43-0700, mantkiew wrote:
>
> Well, there are the *compat packages:
>
> Base-compat
> Transformers-compat
> Mtl-compat
>
> Etc. They do centralize the ifdefs and give you compatibility with
> GHC 7.*. I recently adopted the last two ones and they work like
> a charm. I am yet to adopt base-compat, so I don't know what the
> experience is with it.

Hang on a moment, are you saying that all the people writing to argue
that these changes would require them to write dozens more #ifdef's
actually don't have to write any at all? I never knew what the *-compat
packages were all about. If that's what they're designed to do, I have a
feeling they have not gotten *nearly* enough exposure.

[Apologies for possible cross-posting; this thread jumped into my inbox
from I-know-not-where and already has half a dozen CCs attached.]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151005/6497aefd/attachment.html>

From alexander at plaimi.net  Mon Oct  5 22:29:34 2015
From: alexander at plaimi.net (Alexander Berntsen)
Date: Tue, 6 Oct 2015 00:29:34 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CABhOzZhTRw0N2M=QBJ8GV0VsmWHwOS_02AyS5R04vAeBefrz9A@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAK-tuPYL7anMKMeD4NNOvvR1iktsMeGdvQP7RMNCi_NQ21V0TQ@mail.gmail.com>
 <5612B320.3060701@ucdavis.edu>
 <CABhOzZhTRw0N2M=QBJ8GV0VsmWHwOS_02AyS5R04vAeBefrz9A@mail.gmail.com>
Message-ID: <5612F9CE.8060106@plaimi.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 05/10/15 20:50, Nathan Bouscal wrote:
> There have been a lot of objections based on the idea that
> learners will consult books that are out of date, but the number of
> learners affected by this is dwarfed by the number of learners who
> will use updated materials and be confused by this strange
> historical artifact. Permanently-enshrined historical artifacts
> accrete forever and cause linear confusion, whereas outdated
> materials are inevitably replaced such that the amount of confusion
> remains constant.
Thank you for making this point

I would be very saddened if the appeal to history (i.e. technical
debt) would halt our momentum. That's what happens to most things both
in and out of computer science. And it's honestly depressing.
- -- 
Alexander
alexander at plaimi.net
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJWEvnNAAoJENQqWdRUGk8BrqEQAKcWj2Gv/4gVzTq++m1lU+r1
9TxdBXG+V+y66yyqpZAv4tOOCVtkDYR6/qUGtpYO5cdmh8mYKh5PUvb/p/l1AUQl
Ug8gVO+u+yvwkVif8Jhhl+e8JqYGPgH6+lUvA8VE47VNkYGKMsNlXFYPik8Sc22w
6EhS7SRhR57quOclQw2NRIxS4F3ZqE7YKkXETId9QBtder9e6OEYdc4pQivcr46H
FHzK3ybRF80U/3lKivPFo/114ICrS0l/Mneqf2ITLso6HFAZXhms5RzuSOaxLSbI
xAV2k9gRv6cPWdMgx7DCjiOOsNc78peAcqwlEdQ5dJWGs5fu70hsKqNAL3LYCmRC
YTcC2F1kJmuKYucHzfDLFYiVgbn03ehZkkx4b9NFQyHwj8rBNn4E4JspjOR/ej9w
p3e3lGCj/Voouq+bIb5AAlp01Bioxew/+ewQeI739js9b9LE0wZQvFbYfngxdmf4
Z7IADHsfou7xtiChXbSkOlOEI3mDYTXXxeTSmF/OY7HVnCReCKtVa0Aj5j9G116V
LrMeUegOFMazlbpyG2GGvp7zD/3xTH3v6zpNcj8ijsCIXtch7ygebA5ecXZ0m30s
y6VoVMPkQtHdAaaO5qi7MY+/cSNAiJdEcKR4hSZxPrFqUsiOJ006FMhh1PcSRjBx
3IMLL+8mPsvTnfWDj+NY
=Mwbu
-----END PGP SIGNATURE-----

From tonymorris at gmail.com  Mon Oct  5 22:31:25 2015
From: tonymorris at gmail.com (Tony Morris)
Date: Tue, 6 Oct 2015 08:31:25 +1000
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <5612F9CE.8060106@plaimi.net>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAK-tuPYL7anMKMeD4NNOvvR1iktsMeGdvQP7RMNCi_NQ21V0TQ@mail.gmail.com>
 <5612B320.3060701@ucdavis.edu>
 <CABhOzZhTRw0N2M=QBJ8GV0VsmWHwOS_02AyS5R04vAeBefrz9A@mail.gmail.com>
 <5612F9CE.8060106@plaimi.net>
Message-ID: <5612FA3D.7050207@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

+1

On 06/10/15 08:29, Alexander Berntsen wrote:
> On 05/10/15 20:50, Nathan Bouscal wrote:
>> There have been a lot of objections based on the idea that 
>> learners will consult books that are out of date, but the number 
>> of learners affected by this is dwarfed by the number of
>> learners who will use updated materials and be confused by this
>> strange historical artifact. Permanently-enshrined historical
>> artifacts accrete forever and cause linear confusion, whereas
>> outdated materials are inevitably replaced such that the amount
>> of confusion remains constant.
> Thank you for making this point
> 
> I would be very saddened if the appeal to history (i.e. technical 
> debt) would halt our momentum. That's what happens to most things 
> both in and out of computer science. And it's honestly depressing.
>  _______________________________________________ Haskell-Cafe 
> mailing list Haskell-Cafe at haskell.org 
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWEvo3AAoJEFkczQCvdvv0BQMH/2oxlo35Y4oFw2ZYMMjmb8es
Asm7IrQCOoYRH10mgFhZiNPsZakRrEBsk6QD6iyIk6DGGoA7YBuQ2DwOE3Hzr2Ih
jelQbB0Lqs6P3bj5EibZ1qad+g0zR9RWkjp+7R+zsbhQ3cu4WITT0EI5nwLIacE3
xKmT9WuWcd166rRJrpFSs7gCzQwtWPHropQgnXttx/85Uw6zxA//EimUqsIaLPI7
Yu8IlxqpbICgq7uWni1f1EVajNEIk4qewezrlahrJuBMcBqZ7jAknMIO06UIGFjv
ZZm5lBRc+c++XmwSAVdo+5StiILzHftrlqsW3dVoJLvFFKdKYRDhd3auA+PB/Oo=
=ND0C
-----END PGP SIGNATURE-----

From doug at cs.dartmouth.edu  Mon Oct  5 22:59:21 2015
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Mon, 05 Oct 2015 18:59:21 -0400
Subject: [Haskell-cafe] Monad of no `return` Proposal
Message-ID: <201510052259.t95MxLKS013731@coolidge.cs.Dartmouth.EDU>

> littering the code with #ifdefs

>  Bonus points for keeping the #ifdefs centralized

Littering is the right word. "Bonus" is merely less negative points.

It is ironic that the beautiful Haskell should progress by
adopting the worst feature of C. #ifdef is a sticking-plaster
for non-portable code. It is inserted at global level, usually
to effect changes at the bottom of the code hierarchy. (Maybe
in Haskell it should be a monad, in competition with IO for
the outermost layer.)

Plan 9 showed the way out of ifdef, by putting (non-ifdef-ed)
inescapably nonportable code, such as endianity, in compilation
units and #include files in a distinct part of the file system
tree selected by the shell. 

Another trick is to use plain if rather than #if or #ifdef,
and let the compiler optimize away the unwanted side of the
branch.

In any event, #ifdef is, as Simon evidently agrees, evidence

From doug at cs.dartmouth.edu  Mon Oct  5 23:07:59 2015
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Mon, 05 Oct 2015 19:07:59 -0400
Subject: [Haskell-cafe] Monad of no `return` Proposal
Message-ID: <201510052307.t95N7xqK013994@coolidge.cs.Dartmouth.EDU>

Sorry for the premature send. The incomplete sentence was:

In any event, #ifdef is, as Simon evidently agrees, telling
evidence of non-portability. It is hard to imagine an uglier
"solution" to keeping up with the drip-drip-drip of Haskell
evolution.

doug

From greg at gregorycollins.net  Tue Oct  6 00:40:43 2015
From: greg at gregorycollins.net (Gregory Collins)
Date: Mon, 5 Oct 2015 17:40:43 -0700
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
Message-ID: <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>

On Mon, Oct 5, 2015 at 3:18 PM, Bryan Richter <b at chreekat.net> wrote:

> Hang on a moment, are you saying that all the people writing to argue
> that these changes would require them to write dozens more #ifdef's
> actually don't have to write any at all?
>

Um, no, it usually isn't anything like that. Here's a sampling of some of
the things I've used CPP for in the past few years:

   - After GHC 7.4, when using a newtype in FFI imports you need to import
   the constructor, i.e. "import Foreign.C.Types(CInt(..))" --- afaik CPP is
   the only way to shut up warnings everywhere
   - defaultTimeLocale moved from System.Locale to Data.Time.Format in
   time-1.5 (no compat package for this, afaik)
   - one of many various changes to Typeable in the GHC 7.* series
   (deriving works better now, mkTyCon vs mkTyCon3, etc)
   - Do I have to hide "catch" from Prelude, or not? It got moved, and
   "hiding" gives an error if the symbol you're trying to hide is missing.
   Time to break out the CPP (and curse myself for not just using the
   qualified import in the first place)
   - Do I get monoid functions from Prelude or from Data.Monoid? Same w/
   Applicative, Foldable, Word. I don't know where anything is supposed to
   live anymore, or which sequence of imports will shut up spurious warnings
   on all four versions of GHC I support, so the lowest-friction fix is: break
   out the #ifdef spackle
   - ==# and friends return Int# instead of Bool after GHC 7.8.1
   - To use functions like "tryReadMVar", "unsafeShiftR", and
   "atomicModifyIORef'" that are in recent base versions but not older ones
   (this is a place where CPP use is actually justified)

-- 
Gregory Collins <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151005/c398f795/attachment-0001.html>

From wren at community.haskell.org  Tue Oct  6 00:49:19 2015
From: wren at community.haskell.org (wren romano)
Date: Mon, 5 Oct 2015 20:49:19 -0400
Subject: [Haskell-cafe] Language Change Management (was: Monad of no
 `return` Proposal (MRP): Moving `return` out of `Monad`)
In-Reply-To: <CAPorAaGN0P8PMh4Nvu=zD_XGc7g+t_gQZBtzKtQTDSgWrjEs8Q@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <87lhbhperb.fsf_-_@gnu.org>
 <CAPorAaGN0P8PMh4Nvu=zD_XGc7g+t_gQZBtzKtQTDSgWrjEs8Q@mail.gmail.com>
Message-ID: <CABUjdS5W5cac8m9kUEXD=LQibJADoj32w1fc9KsfPZPe803gtQ@mail.gmail.com>

On Mon, Oct 5, 2015 at 5:23 PM, Adam Foltzer <acfoltzer at gmail.com> wrote:
>>  Also I'm not sure if there would be less complaints if
>> AMP/FTP/MFP/MRP/etc as part of a new Haskell Report would be switched on all
>> at once in e.g. `base-5.0`, breaking almost *every* single package out there
>> at once.
>
> I doubt the number of complaints-per-change would be fewer, but I'm strongly
> in favor of moving away from what feels like a treadmill that doesn't value
> the time of developers and that doesn't account for the
> more-than-sum-of-parts cost of the "constant flux".

Broadly speaking, I'm a "fix it now rather than later" sort of person
in Haskell because I've seen how long things can linger before finally
getting fixed (even when everyone agrees on what the fix should be and
agrees that it should be done). However, as I mentioned in the
originating thread, I think that ?at this point? when it comes to
AMP/FTP/MFP/MRP/etc we should really aim for the haskell' committee to
work out a comprehensive solution (as soon as possible), and then
enact all the changes at once when switching to
Haskell201X/base-5.0/whatevs. I understand the motivations for wanting
things to be field-tested before making it into the report, but I
don't think having a series of rapid incremental changes is the
correct approach here. Because we're dealing with the Prelude and the
core classes, the amount of breakage (and CPP used to paper over it)
here is much higher than our usual treadmill of changes; so we should
take that into account when planning how to roll the changes out.

-- 
Live well,
~wren

From mantkiew at gsd.uwaterloo.ca  Tue Oct  6 00:49:37 2015
From: mantkiew at gsd.uwaterloo.ca (=?UTF-8?Q?Micha=C5=82_Antkiewicz?=)
Date: Mon, 5 Oct 2015 20:49:37 -0400
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
Message-ID: <CAGW9QSxuMfyVfetFeTEMs==gLMLbRwB-=AzBkfQYWd2MSwq__Q@mail.gmail.com>

All I am saying is that these various *compat packages manage to
encapsulate the ifdefs to some degree.

Here's the record of my struggle [1]. Then came Edward K. and told me
to use transformers-compat [2]. Then Adam B. chimed in suggesting
mtl-compat [3]. That's it. All my IFDEFs related to this topic were
gone.

I looked at base-compat [4] and it's very interesting. The big question is:

**Why cannot normal base be written the same way as base-compat? **
It would then automatically provide compatibility across all GHC versions.

Micha?

[1] https://www.reddit.com/r/haskell/comments/3gqqu8/depending_on_both_mtl2131_for_stackage_lts2_and/
[2] https://www.reddit.com/r/haskell/comments/3gqqu8/depending_on_both_mtl2131_for_stackage_lts2_and/cu0l6nf
[3] https://www.reddit.com/r/haskell/comments/3gqqu8/depending_on_both_mtl2131_for_stackage_lts2_and/cu5g73q
[4] https://hackage.haskell.org/package/base-compat

On Mon, Oct 5, 2015 at 6:18 PM, Bryan Richter <b at chreekat.net> wrote:
> On Mon, Oct 5, 2015 at 06:43-0700, mantkiew wrote:
>>
>> Well, there are the *compat packages:
>>
>> Base-compat
>> Transformers-compat
>> Mtl-compat
>>
>> Etc. They do centralize the ifdefs and give you compatibility with
>> GHC 7.*. I recently adopted the last two ones and they work like
>> a charm. I am yet to adopt base-compat, so I don't know what the
>> experience is with it.
>
> Hang on a moment, are you saying that all the people writing to argue
> that these changes would require them to write dozens more #ifdef's
> actually don't have to write any at all? I never knew what the *-compat
> packages were all about. If that's what they're designed to do, I have a
> feeling they have not gotten *nearly* enough exposure.
>
> [Apologies for possible cross-posting; this thread jumped into my inbox
> from I-know-not-where and already has half a dozen CCs attached.]

From rf at rufflewind.com  Tue Oct  6 01:00:21 2015
From: rf at rufflewind.com (Phil Ruffwind)
Date: Mon, 5 Oct 2015 21:00:21 -0400
Subject: [Haskell-cafe] Language Change Management (was: Monad of no
 `return` Proposal (MRP): Moving `return` out of `Monad`)
In-Reply-To: <CAPorAaGN0P8PMh4Nvu=zD_XGc7g+t_gQZBtzKtQTDSgWrjEs8Q@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <87lhbhperb.fsf_-_@gnu.org>
 <CAPorAaGN0P8PMh4Nvu=zD_XGc7g+t_gQZBtzKtQTDSgWrjEs8Q@mail.gmail.com>
Message-ID: <CADb8sTN6vZ6NgAnRTrgUsDhpgn_hF64bovq1uWxMiCzokyEUVg@mail.gmail.com>

Having so many #ifdefs isn't by itself a major problem.  Yes, it does
introduce a small increase in compilation time and the size of the
codebase.  The real cost is the developer time: every developer has to
come up with these these #ifdef clauses from scratch for every change
that gets made, tailored to their specific code.  As more and more get
added, it becomes more and more of a confusing mess.

It makes me wonder if this can be automated somehow.  It would be nice
to have a mechanism to alleviate this cost so that most developers
downstream (provided that the code was written in a reasonable manner)
only need to make a minimal effort to keep up, while still being able
to write code that works for a reasonably large range of GHC versions.
The burden of breaking changes right now is on the downstream
developers, but perhaps there could be a way to shift most of that
upstream to avoid this large duplication of effort.

Haskell should be allowed to evolve, but there also needs to be a
counterweight mechanism that provides stability in the face of
constant changes.  It would be something similar in spirit to
base-compat, but I don't think a library package alone is powerful
enough to solve the problem: a missing 'return' for example is not
something a library can just patch in.

I don't have any preference for "lots of small changes" vs "one big
change": in the former, there is a lot of overhead needed to keep
track of and fix these small changes; in the latter, there is a risk
of introducing a rift that fragments the community (cf Python 2 vs 3).
Maybe something in-between would be the best.

From amindfv at gmail.com  Tue Oct  6 01:20:40 2015
From: amindfv at gmail.com (amindfv at gmail.com)
Date: Mon, 5 Oct 2015 21:20:40 -0400
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
	`return` out of `Monad`
In-Reply-To: <5612F9CE.8060106@plaimi.net>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAK-tuPYL7anMKMeD4NNOvvR1iktsMeGdvQP7RMNCi_NQ21V0TQ@mail.gmail.com>
 <5612B320.3060701@ucdavis.edu>
 <CABhOzZhTRw0N2M=QBJ8GV0VsmWHwOS_02AyS5R04vAeBefrz9A@mail.gmail.com>
 <5612F9CE.8060106@plaimi.net>
Message-ID: <0DD58DFC-B002-4D09-A91F-66D964BB6845@gmail.com>

IMO, the "tech debt" you're talking about feels very small. We've already made the change that return = pure by default. The historical baggage that this proposal cleans up is just the fact that legacy code is able to define its own "return" without breaking (which must be the same as the definition of pure anyway).
     I am also moving from +0.5 to +0 on this.

Tom


> El 5 oct 2015, a las 18:29, Alexander Berntsen <alexander at plaimi.net> escribi?:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
>> On 05/10/15 20:50, Nathan Bouscal wrote:
>> There have been a lot of objections based on the idea that
>> learners will consult books that are out of date, but the number of
>> learners affected by this is dwarfed by the number of learners who
>> will use updated materials and be confused by this strange
>> historical artifact. Permanently-enshrined historical artifacts
>> accrete forever and cause linear confusion, whereas outdated
>> materials are inevitably replaced such that the amount of confusion
>> remains constant.
> Thank you for making this point
> 
> I would be very saddened if the appeal to history (i.e. technical
> debt) would halt our momentum. That's what happens to most things both
> in and out of computer science. And it's honestly depressing.
> - -- 
> Alexander
> alexander at plaimi.net
> https://secure.plaimi.net/~alexander
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQIcBAEBCgAGBQJWEvnNAAoJENQqWdRUGk8BrqEQAKcWj2Gv/4gVzTq++m1lU+r1
> 9TxdBXG+V+y66yyqpZAv4tOOCVtkDYR6/qUGtpYO5cdmh8mYKh5PUvb/p/l1AUQl
> Ug8gVO+u+yvwkVif8Jhhl+e8JqYGPgH6+lUvA8VE47VNkYGKMsNlXFYPik8Sc22w
> 6EhS7SRhR57quOclQw2NRIxS4F3ZqE7YKkXETId9QBtder9e6OEYdc4pQivcr46H
> FHzK3ybRF80U/3lKivPFo/114ICrS0l/Mneqf2ITLso6HFAZXhms5RzuSOaxLSbI
> xAV2k9gRv6cPWdMgx7DCjiOOsNc78peAcqwlEdQ5dJWGs5fu70hsKqNAL3LYCmRC
> YTcC2F1kJmuKYucHzfDLFYiVgbn03ehZkkx4b9NFQyHwj8rBNn4E4JspjOR/ej9w
> p3e3lGCj/Voouq+bIb5AAlp01Bioxew/+ewQeI739js9b9LE0wZQvFbYfngxdmf4
> Z7IADHsfou7xtiChXbSkOlOEI3mDYTXXxeTSmF/OY7HVnCReCKtVa0Aj5j9G116V
> LrMeUegOFMazlbpyG2GGvp7zD/3xTH3v6zpNcj8ijsCIXtch7ygebA5ecXZ0m30s
> y6VoVMPkQtHdAaaO5qi7MY+/cSNAiJdEcKR4hSZxPrFqUsiOJ006FMhh1PcSRjBx
> 3IMLL+8mPsvTnfWDj+NY
> =Mwbu
> -----END PGP SIGNATURE-----
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

From amindfv at gmail.com  Tue Oct  6 01:24:26 2015
From: amindfv at gmail.com (amindfv at gmail.com)
Date: Mon, 5 Oct 2015 21:24:26 -0400
Subject: [Haskell-cafe] Language Change Management (was: Monad of no
	`return` Proposal (MRP): Moving `return` out of `Monad`)
In-Reply-To: <CADb8sTN6vZ6NgAnRTrgUsDhpgn_hF64bovq1uWxMiCzokyEUVg@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <87lhbhperb.fsf_-_@gnu.org>
 <CAPorAaGN0P8PMh4Nvu=zD_XGc7g+t_gQZBtzKtQTDSgWrjEs8Q@mail.gmail.com>
 <CADb8sTN6vZ6NgAnRTrgUsDhpgn_hF64bovq1uWxMiCzokyEUVg@mail.gmail.com>
Message-ID: <2F902D16-CED6-46D4-A596-5826DC14E5EF@gmail.com>

Another problem with #ifdefs (especially machine-generated ones) is that it makes code much harder to read. One of the things I love about Haskell is the ability to read code and literally see an author describe how they're thinking about the domain. #ifdefs make life less fun :)

Tom


> El 5 oct 2015, a las 21:00, Phil Ruffwind <rf at rufflewind.com> escribi?:
> 
> Having so many #ifdefs isn't by itself a major problem.  Yes, it does
> introduce a small increase in compilation time and the size of the
> codebase.  The real cost is the developer time: every developer has to
> come up with these these #ifdef clauses from scratch for every change
> that gets made, tailored to their specific code.  As more and more get
> added, it becomes more and more of a confusing mess.
> 
> It makes me wonder if this can be automated somehow.  It would be nice
> to have a mechanism to alleviate this cost so that most developers
> downstream (provided that the code was written in a reasonable manner)
> only need to make a minimal effort to keep up, while still being able
> to write code that works for a reasonably large range of GHC versions.
> The burden of breaking changes right now is on the downstream
> developers, but perhaps there could be a way to shift most of that
> upstream to avoid this large duplication of effort.
> 
> Haskell should be allowed to evolve, but there also needs to be a
> counterweight mechanism that provides stability in the face of
> constant changes.  It would be something similar in spirit to
> base-compat, but I don't think a library package alone is powerful
> enough to solve the problem: a missing 'return' for example is not
> something a library can just patch in.
> 
> I don't have any preference for "lots of small changes" vs "one big
> change": in the former, there is a lot of overhead needed to keep
> track of and fix these small changes; in the latter, there is a risk
> of introducing a rift that fragments the community (cf Python 2 vs 3).
> Maybe something in-between would be the best.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From tonymorris at gmail.com  Tue Oct  6 01:52:22 2015
From: tonymorris at gmail.com (Tony Morris)
Date: Tue, 6 Oct 2015 11:52:22 +1000
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <0DD58DFC-B002-4D09-A91F-66D964BB6845@gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAK-tuPYL7anMKMeD4NNOvvR1iktsMeGdvQP7RMNCi_NQ21V0TQ@mail.gmail.com>
 <5612B320.3060701@ucdavis.edu>
 <CABhOzZhTRw0N2M=QBJ8GV0VsmWHwOS_02AyS5R04vAeBefrz9A@mail.gmail.com>
 <5612F9CE.8060106@plaimi.net>
 <0DD58DFC-B002-4D09-A91F-66D964BB6845@gmail.com>
Message-ID: <56132956.5040204@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

- -- I am going to do some logging, yay!
data Logs a =
  Logs a [a]
  deriving (Eq, Show)

- -- one log message
singlelog ::
  a
  -> Logs a
singlelog a =
  Logs a []

- -- two log messages
twologs ::
  a
  -> a
  -> Logs a
twologs a1 a2 =
  Logs a1 [a2]

class Semigroup a where
  (<>) ::
    a
    -> a
    -> a

- -- I can append logs
instance Semigroup (Logs a) where
  Logs h1 t1 <> Logs h2 t2 =
    Logs h1 (t1 ++ h2 : t2)

- -- I can map on Logs
instance Functor Logs where
  fmap f (Logs h t) =
    Logs (f h) (fmap f t)

- -- I will collect logs with a value
data WriteLogs l a =
  WriteLogs (Logs l) a
  deriving (Eq, Show)

- -- I can map the pair of logs and a value
instance Functor (WriteLogs l) where
  fmap f (WriteLogs l a) =
    WriteLogs l (f a)

singlewritelog ::
  l
  -> a
  -> WriteLogs l a
singlewritelog l a =
  WriteLogs (singlelog l) a

- -- Monad without return
class Bind f where
  (-<<) ::
    (a -> f b)
    -> f a
    -> f b

- -- Can I Applicativate WriteLogs? Let's see.
instance Applicative (WriteLogs l) where
  -- Well that was easy.
  WriteLogs l1 f <*> WriteLogs l2 a =
    WriteLogs (l1 <> l2) (f a)
  pure a =
    WriteLogs (error "wait, what goes here?") a
  -- Oh I guess I cannot Applicativate WriteLogs, but I can Apply them!

- -- Well there goes that idea.
- -- instance Monad (WriteLogs l) where

- -- Wait a minute, can I bind WriteLogs?
instance Bind (WriteLogs l) where
  -- Of course I can!
  f -<< WriteLogs l1 a =
    let WriteLogs l2 b = f a
    in WriteLogs (l1 <> l2) b

- -- OK here goes ...
myprogram ::
  WriteLogs String Int
myprogram =
  -- No instance for (Monad (WriteLogs String))
  -- RAR!, why does do-notation require extraneous constraints?!
  -- Oh that's right, Haskell is broken.
  -- Oh well, I guess I need to leave Prelude turned off and rewrite
the base libraries.
  do a <- singlewritelog "message" 18
     b <- WriteLogs (twologs "hi" "bye") 73
     WriteLogs (singlelog "exit") (a * b)

- -- One day, one day soon, I can move on.


On 06/10/15 11:20, amindfv at gmail.com wrote:
> IMO, the "tech debt" you're talking about feels very small. We've
> already made the change that return = pure by default. The
> historical baggage that this proposal cleans up is just the fact
> that legacy code is able to define its own "return" without
> breaking (which must be the same as the definition of pure
> anyway). I am also moving from +0.5 to +0 on this.
> 
> Tom
> 
> 
>> El 5 oct 2015, a las 18:29, Alexander Berntsen
>> <alexander at plaimi.net> escribi?:
>> 
>>>> On 05/10/15 20:50, Nathan Bouscal wrote: There have been a
>>>> lot of objections based on the idea that learners will
>>>> consult books that are out of date, but the number of 
>>>> learners affected by this is dwarfed by the number of
>>>> learners who will use updated materials and be confused by
>>>> this strange historical artifact. Permanently-enshrined
>>>> historical artifacts accrete forever and cause linear
>>>> confusion, whereas outdated materials are inevitably replaced
>>>> such that the amount of confusion remains constant.
> Thank you for making this point
> 
> I would be very saddened if the appeal to history (i.e. technical 
> debt) would halt our momentum. That's what happens to most things
> both in and out of computer science. And it's honestly depressing.
>> _______________________________________________ Haskell-Cafe
>> mailing list Haskell-Cafe at haskell.org 
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> _______________________________________________ Haskell-Cafe
> mailing list Haskell-Cafe at haskell.org 
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWEylQAAoJEFkczQCvdvv08KMIAIGEwj6dQqnk8Z3zjFC1Vpvb
LTXdnzlcXCMXmIdzr9RaSGUKo52b3BPaP6EgFDJm8U/CJYQ/X8FAyy0gmKVJlru4
JQc4Y+CcGqz7+UwfYRlOOJDFNscigvGDj33N3hp3G/HuWfvllWJSx9n7gTqSrnXS
W/jTDN3sntJWiCdC+A5rLoqzH3eZ2LhwB0iL26DSfE1OLPyBK2kignKCjnMtRbEq
xY5vjx7xLQKzApRARIrBdDNVuXVRy+QQyGTGmdOKaLscNNrMzewcUr8LZLRG+6W7
RKA12y3etcVXGRlACHNn67mUKJIlKWX5PZSVsj07SZNWp3eyDctHfKuqYonfgJU=
=G8G2
-----END PGP SIGNATURE-----

From rustompmody at gmail.com  Tue Oct  6 03:43:43 2015
From: rustompmody at gmail.com (Rustom Mody)
Date: Tue, 6 Oct 2015 09:13:43 +0530
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
Message-ID: <CAJ+TeofR-SehxebYyL5jnZJZDa=fd4Jd4wAY3GeSne1Z0LF5NA@mail.gmail.com>

On Tue, Oct 6, 2015 at 4:29 AM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> > littering the code with #ifdefs
>
> >  Bonus points for keeping the #ifdefs centralized
>
> Littering is the right word. "Bonus" is merely less negative points.
>
> It is ironic that the beautiful Haskell should progress by
> adopting the worst feature of C. #ifdef is a sticking-plaster
> for non-portable code. It is inserted at global level, usually
> to effect changes at the bottom of the code hierarchy. (Maybe
> in Haskell it should be a monad, in competition with IO for
> the outermost layer.)
>
> Plan 9 showed the way out of ifdef, by putting (non-ifdef-ed)
> inescapably nonportable code, such as endianity, in compilation
> units and #include files in a distinct part of the file system
> tree selected by the shell.
>
> Another trick is to use plain if rather than #if or #ifdef,
> and let the compiler optimize away the unwanted side of the
> branch.
>
>
> In any event, #ifdef is, as Simon evidently agrees, telling
> evidence of non-portability. It is hard to imagine an uglier
> "solution" to keeping up with the drip-drip-drip of Haskell
> evolution.
>
>
The python 2?3 transition may have caused some pain to some. However it
would have been far more difficult if they had not provided tools like
2to3 and six:
https://docs.python.org/2/library/2to3.html
http://pythonhosted.org/six/

Since the change here is trivial and pervasive why is such a tool not being
considered?
[Or have I missed the discussion?]

In particular we can envisage a tool say 8to10 that has these modes
(command-line flags)
--portable
--readable
--info

with the idea that
- portable is most unreadable (ifdef litter)
- readable is not portable -- generate a copy of the whole source tree that
will have the changes and not be compatible for ghc < 7.8
  This is for those library authors that prefer to maintain a clean code
base and hell with earlier ghc versions
- info summarizes which files would change and how so that a suitable
reorganization of the files/directories can be done prior to the switch
  This is for those library authors that would like to take the trouble to
have a compatibility layer and have code as readable as possible overall

[Whether pure is really preferable to return is another matter --
For me one of the strongest criticisms of the python 2?3 switch is this
that if they were going to break things anyhow why was the cleanup not more
far-reaching?

Lets keep this note in these parentheses :-)

]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151006/f01d7ec2/attachment.html>

From ivan.miljenovic at gmail.com  Tue Oct  6 07:04:02 2015
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Tue, 6 Oct 2015 18:04:02 +1100
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
Message-ID: <CA+u6gbw5g9jqA17O_wFWkyaTmKXJF0oXYSp72pVCxEY4i21uRg@mail.gmail.com>

On 6 October 2015 at 11:40, Gregory Collins <greg at gregorycollins.net> wrote:
>
> defaultTimeLocale moved from System.Locale to Data.Time.Format in time-1.5
> (no compat package for this, afaik)

http://hackage.haskell.org/package/time-locale-compat

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

From hvr at gnu.org  Tue Oct  6 07:10:12 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Tue, 06 Oct 2015 09:10:12 +0200
Subject: [Haskell-cafe] MRP, 3-year-support-window,
	and the non-requirement of CPP (was: Monad of no `return` Proposal
	(MRP): Moving `return` out of `Monad`)
In-Reply-To: <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 (Johan Tibell's message of "Mon, 5 Oct 2015 21:01:16 +0200")
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
Message-ID: <87zizw8obv.fsf_-_@gnu.org>

On 2015-10-05 at 21:01:16 +0200, Johan Tibell wrote:
> On Mon, Oct 5, 2015 at 8:34 PM, Gregory Collins <greg at gregorycollins.net>
[...]

>> Strongly -1 from me also. My experience over the last couple of years is
>> that every GHC release breaks my libraries in annoying ways that require
>> CPP to fix:
>>
>> ~/personal/src/snap ?  find . -name '*.hs' | xargs egrep
>> '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l
>> 64

[...]

> On the libraries I maintain and have a copy of on my computer right now: 329


Although this was already pointed out to you in a response to a Tweet of
yours, I'd like to expand on this here to clarify:


You say that you stick to the 3-major-ghc-release support-window
convention for your libraries. This is good, because then you don't need
any CPP at all! Here's why:

So when GHC 8.2 is released, your support-window requires you to support
GHC 7.10 and GHC 8.0 in addition to GHC 8.2.

At this point you'll be happy that you can start dropping those #ifdefs
you added for GHC 7.10 in your code in order to adapt to FTP & AMP.

And when you do *that*, you can also drop all your `return = pure`
methods overrides. (Because we prepared for MRP already in GHC 7.10 by
introducing the default implementation for `return`!)

This way, you don't need to introduce any CPP whatsoever due to MRP!


Finally, since we're not gonna remove `return` in GHC 8.2 anyway, as GHC
8.2 was just the *earliest theoretical* possible GHC in which this
*could* have happened. Realistically, this would happen at a much later
point, say GHC 8.6 or even later! Therefore, the scheme above would
actually work for 5-year time-windows! And there's even an idea on the
table to have a lawful `return = pure` method override be tolerated by
GHC even when `return` has already moved out of `Monad`!


PS: I'm a bit disappointed you seem to dismiss this proposal right away
    categorically without giving us a chance to address your
    concerns. The proposal is not a rigid all-or-nothing thing that
    can't be tweaked and revised.  That's why we're having these
    proposal-discussions in the first place (rather than doing blind
    +1/-1 polls), so we can hear everyone out and try to maximise the
    agreement (even if we will never reach 100% consensus on any
    proposal).

    So please, keep on discussing!

From mwm at mired.org  Tue Oct  6 07:58:29 2015
From: mwm at mired.org (Mike Meyer)
Date: Tue, 06 Oct 2015 07:58:29 +0000
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <muvtu1$jc0$1@ger.gmane.org>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <muvtu1$jc0$1@ger.gmane.org>
Message-ID: <CAD=7U2BZx5QGOZDZWEueFeYVd0KF56KrpijVnhySFYHKitdSfw@mail.gmail.com>

On Tue, Oct 6, 2015 at 2:40 AM Bardur Arantsson <spam at scientician.net>
wrote:

> >    - To use functions like "tryReadMVar", "unsafeShiftR", and
> >    "atomicModifyIORef'" that are in recent base versions but not older
> ones
> >    (this is a place where CPP use is actually justified)
> Well, yeah, new functions don't magically appear in old versions. I
> don't anybody expects that :).
>

Right - they have to be backported, and imply maintenance of multiple
branches.

Python has been mentioned a couple of times. They did that, backporting
functions that mimiced Python 3 functions to later Python 2 versions, which
made the tools mentioned possible, or at least more capable.

I'll refer those wanting fewer breaking changes to Python. Getting language
changes accepted by the PYthon community is *hard*. You need a use case for
your change, you need to show that the case can't be handled cleanly by the
language as it exists today, that it's common enough to justify the change,
and that it won't tempt people to write uglier code than the current
solution. If you want to break old code, all those bars get raised - a lot.

Or did, anyway, The result of following that was the Python 2/Python 3
split, which I don't think anybody thought was a good thing. Unavoidable,
maybe - Python 3 had to break backwards compatibility, so they cleaned up
everything along the way, and created tools to migrate code, and committed
to maintaining both versions for an extended period of time. And the
community was pretty badly splintered by this.

The one thing I think they got right is documenting the language change
process with the entire PEP process. We seem to have wiki pages, with no
editorial oversight, and pages show up in google searches after they've
been incorporated into the language in a different form. Not quite as good
a thing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151006/dca75ed2/attachment.html>

From hvr at gnu.org  Tue Oct  6 08:31:30 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Tue, 06 Oct 2015 10:31:30 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
	`return` out of `Monad`
In-Reply-To: <CAJ+TeofR-SehxebYyL5jnZJZDa=fd4Jd4wAY3GeSne1Z0LF5NA@mail.gmail.com>
 (Rustom Mody's message of "Tue, 6 Oct 2015 09:13:43 +0530")
References: <CAJ+TeofR-SehxebYyL5jnZJZDa=fd4Jd4wAY3GeSne1Z0LF5NA@mail.gmail.com>
Message-ID: <87mvvw8kkd.fsf@gnu.org>

On 2015-10-06 at 05:43:43 +0200, Rustom Mody wrote:

[...]

> The python 2?3 transition may have caused some pain to some. However it
> would have been far more difficult if they had not provided tools like
> 2to3 and six:
> https://docs.python.org/2/library/2to3.html
> http://pythonhosted.org/six/
>
> Since the change here is trivial and pervasive why is such a tool not being
> considered?
> [Or have I missed the discussion?]

It is being considered! :-)

I'm in the process of collecting rewrite recipes and samples on

  https://github.com/hvr/Hs2010To201x

Alan is looking into how HaRe can be leveraged for this. I've refrained
from bringing this up, as I'm still waiting to reach a proof-of-concept
stage where we can confidently say that this actually works.


> In particular we can envisage a tool say 8to10 that has these modes
> (command-line flags)
> --portable
> --readable
> --info
>
> with the idea that
> - portable is most unreadable (ifdef litter)
> - readable is not portable -- generate a copy of the whole source tree that
> will have the changes and not be compatible for ghc < 7.8
>   This is for those library authors that prefer to maintain a clean code
> base and hell with earlier ghc versions
> - info summarizes which files would change and how so that a suitable
> reorganization of the files/directories can be done prior to the switch
>   This is for those library authors that would like to take the trouble to
> have a compatibility layer and have code as readable as possible overall
>
> [Whether pure is really preferable to return is another matter --
> For me one of the strongest criticisms of the python 2?3 switch is this
> that if they were going to break things anyhow why was the cleanup not more
> far-reaching?
>
> Lets keep this note in these parentheses :-)
>
> ]
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-- 
"Elegance is not optional" -- Richard O'Keefe

From ben at smart-cactus.org  Tue Oct  6 08:44:29 2015
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 06 Oct 2015 10:44:29 +0200
Subject: [Haskell-cafe] Reducing the need for CPP (was: Monad of no `return`
	Proposal (MRP): Moving `return` out of `Monad`)
In-Reply-To: <CANBN=mv6WPLRdvLJppOZ2=1zkd7sWKAHwTF3rHie27RS_YLesA@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CANBN=mv6WPLRdvLJppOZ2=1zkd7sWKAHwTF3rHie27RS_YLesA@mail.gmail.com>
Message-ID: <87k2r0z8r6.fsf@smart-cactus.org>

Sven Panne <svenpanne at gmail.com> writes:

> 2015-10-05 17:09 GMT+02:00 Gershom B <gershomb at gmail.com>:
>
>> On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (bos at serpentine.com)
>> wrote:
>> [...] As for libraries, it has been pointed out, I believe, that without
>> CPP one can write instances compatible with AMP, and also with AMP + MRP.
>> One can also write code, sans CPP, compatible with pre- and post- AMP. [...]
>>
>
> Nope, at least not if you care about -Wall: If you take e.g. (<$>) which is
> now part of the Prelude, you can't simply import some compatibility module,
> because GHC might tell you (rightfully) that that import is redundant,
> because (<$>) is already visible through the Prelude. So you'll have to use
> CPP to avoid that import on base >= 4.8, be it from it Data.Functor,
> Control.Applicative or some compat-* module. And you'll have to use CPP in
> each and every module using <$> then, unless I miss something obvious.
> AFAICT all transitioning guides ignore -Wall and friends...
>
This is a fair point that comes up fairly often. The fact that CPP is
required to silence redundant import warnings is quite unfortunate.
Others languages have better stories in this area. One example is Rust,
which has a quite flexible `#[allow(...)]` pragma which can be used to
acknowledge and silence a wide variety of warnings and lints [1].

I can think of a few ways (some better than others) how we might
introduce a similar idea for import redundancy checks in Haskell,

 1. Attach a `{-# ALLOW redundant_import #-}` pragma to a definition,
        
        -- in Control.Applicative
        {-# ALLOW redundant_import (<$>) #-}
        (<$>) :: (a -> b) -> f a -> f b
        (<$>) = fmap

    asking the compiler to pretend that any import of the symbol did not
    exist when looking for redundant imports. This would allow library
    authors to appropriately mark definitions when they are moved,
    saving downstream users from having to make any change whatsoever.

 2. Or alternatively we could make this a idea a bit more precise,
        
        -- in Control.Applicative
        {-# ALLOW redundant_import Prelude.(<$>) #-}
        (<$>) :: (a -> b) -> f a -> f b
        (<$>) = fmap

    Which would ignore imports of `Control.Applicative.(<$>)` only if
    `Prelude.(<$>)` were also in scope.

 3. Attach a `{-# ALLOW redundancy_import #-}` pragma to an import,

        import {-# ALLOW redundant_import #-} Control.Applicative

        -- or perhaps
        import Control.Applicative
        {-# ALLOW redundant_import Control.Applicative #-}

    allowing the user to explicitly state that they are aware that this
    import may be redundant.

 4. Attach a `{-# ALLOW redundancy_import #-}` pragma to a name in an
    import list,

        import Control.Applicative ((<$>) {-# ALLOW redundant_import #-})

    allowing the user to explicitly state that they are aware that this
    imported function may be redundant.

In general I'd like to reiterate that many of the comments in this
thread describe genuine sharp edges in our language which have presented
a real cost in developer time during the AMP and and FTP transitions. I
think it is worth thinking of ways to soften these edges; we may be
surprised how easy it is to fix some of them.

- Ben


[1] https://doc.rust-lang.org/stable/reference.html#lint-check-attributes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151006/42e097e1/attachment.sig>

From _deepfire at feelingofgreen.ru  Tue Oct  6 09:16:32 2015
From: _deepfire at feelingofgreen.ru (Kosyrev Serge)
Date: Tue, 06 Oct 2015 12:16:32 +0300
Subject: [Haskell-cafe] Monad of no `return` Proposal
In-Reply-To: <201510052259.t95MxLKS013731@coolidge.cs.Dartmouth.EDU>
 (sfid-20151006_032252_496842_92F9A6BF) (Doug McIlroy's message of
 "Mon, 05 Oct 2015 18:59:21 -0400")
References: <201510052259.t95MxLKS013731@coolidge.cs.Dartmouth.EDU>
Message-ID: <87lhbgl5lb.fsf@feelingofgreen.ru>

Doug McIlroy <doug at cs.dartmouth.edu> writes:
>> littering the code with #ifdefs
>
>>  Bonus points for keeping the #ifdefs centralized
>
> Littering is the right word. "Bonus" is merely less negative points.
>
> It is ironic that the beautiful Haskell should progress by
> adopting the worst feature of C. #ifdef is a sticking-plaster
> for non-portable code. It is inserted at global level, usually
> to effect changes at the bottom of the code hierarchy. (Maybe
> in Haskell it should be a monad, in competition with IO for
> the outermost layer.)
>
> Plan 9 showed the way out of ifdef, by putting (non-ifdef-ed)
> inescapably nonportable code, such as endianity, in compilation
> units and #include files in a distinct part of the file system
> tree selected by the shell. 
>
> Another trick is to use plain if rather than #if or #ifdef,
> and let the compiler optimize away the unwanted side of the
> branch.
>
> In any event, #ifdef is, as Simon evidently agrees, telling
> evidence of non-portability. It is hard to imagine an uglier
> "solution" to keeping up with the drip-drip-drip of Haskell
> evolution.

By the nature of the problem -- that is, because we want to isolate the
compiler as much as possible -- the conditionalization must be performed
as a separate pass.

The conclusion is that some sort of pre-processor is inevitable.

The remainder of the available choice space is about how ugly this
pre-processor must be -- and indeed, CPP tends towards the undesirable
end of the spectrum.

As an example of the opposite end, consider Common Lisp, which:

  1. reifies READ as the third processing phase (macroexpansion[1] and actual
     compilation being the other two)
  2. operates at expression granularity
  3. makes the full power of the language available to support the
     decision process of what subexpressions are available in which
     contexts

As a rough example of how this works:

  http://clhs.lisp.se/Body/24_abaa.htm

I don't know how much of Common Lisp preachery the list have suffered
over the years, but I can't help but find this uniformity between the
three parts of the language very appealing:

  - syntax-level of READ
  - macro-level of MACROEXPAND
  - semantics-level of the post-MACROEXPAND part of EVAL

Maybe, just maybe, Haskell could borrow something from that..

-- 
? ???????e? / respectfully,
??????? ??????
--
1.  Macroexpansion is actually defined by the ANSI CL standard to be a
    part of minimal compbilation, but for the purposes of illustration
    it makes sense to distinguish between them.

From _deepfire at feelingofgreen.ru  Tue Oct  6 09:30:12 2015
From: _deepfire at feelingofgreen.ru (Kosyrev Serge)
Date: Tue, 06 Oct 2015 12:30:12 +0300
Subject: [Haskell-cafe] Reducing the need for CPP
In-Reply-To: <87k2r0z8r6.fsf@smart-cactus.org>
 (sfid-20151006_130812_301207_6B09ABEE) (Ben Gamari's message of "Tue,
 06 Oct 2015 10:44:29 +0200")
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CANBN=mv6WPLRdvLJppOZ2=1zkd7sWKAHwTF3rHie27RS_YLesA@mail.gmail.com>
 <87k2r0z8r6.fsf@smart-cactus.org>
Message-ID: <87h9m4l4yj.fsf@feelingofgreen.ru>

Ben Gamari <ben at smart-cactus.org> writes:
> This is a fair point that comes up fairly often. The fact that CPP is
> required to silence redundant import warnings is quite unfortunate.
> Others languages have better stories in this area. One example is Rust,
> which has a quite flexible `#[allow(...)]` pragma which can be used to
> acknowledge and silence a wide variety of warnings and lints [1].
>
> I can think of a few ways (some better than others) how we might
> introduce a similar idea for import redundancy checks in Haskell,
>
>  1. Attach a `{-# ALLOW redundant_import #-}` pragma to a definition,
...
>  2. Or alternatively we could make this a idea a bit more precise,
>         {-# ALLOW redundant_import Prelude.(<$>) #-}
...
>  3. Attach a `{-# ALLOW redundancy_import #-}` pragma to an import,
>         import {-# ALLOW redundant_import #-} Control.Applicative
...
>  4. Attach a `{-# ALLOW redundancy_import #-}` pragma to a name in an
>     import list,
>         import Control.Applicative ((<$>) {-# ALLOW redundant_import #-})

What I don't like about this solution is how specific it is -- the gut
instinct that it can't be the last such extension, if we were to start
replacing CPP piecemeal.

And after a while, we'd accomodate a number of such extensions..
and they would keep coming.. until it converges to a trainwreck.

I think that what instead needs to be done, is this:

  1. a concerted effort to summarize *all* uses of CPP in Haskell code
  2. a bit of forward thinking, to include desirables that would be easy
     to get with a more generic solution

Personally, I think that any such effort, approached with generality
that would be truly satisfying, should inevitably converge to an
AST-level mechanism.

..but then I remember how CPP can be used to paper over incompatible
syntax changes..

Hmm..

-- 
? ???????e? / respectfully,
??????? ??????

From tkoster at gmail.com  Tue Oct  6 10:25:15 2015
From: tkoster at gmail.com (Thomas Koster)
Date: Tue, 6 Oct 2015 21:25:15 +1100
Subject: [Haskell-cafe] A GC'd heap using weak pointers
Message-ID: <CAG1wH7AA9e6tQkashLq6SsgsvqbuXv64PK=o-r8PGVQcktGFbw@mail.gmail.com>

Good afternoon list,

I am implementing a simple, interpreted language that needs a garbage-
collected heap for storage. Like most discussions on memory management,
I use the term "heap" by analogy - the actual data structure is not
necessarily a true heap.

My Heap type is basically a map of "addresses" (Int) to values. Values
may themselves contain addresses, perhaps recursively to each other
(like letrec). The extra field in Heap stores the next unused address,
used to allocate fresh slots, as you can see in "heapAlloc".

> type Address = Int
> data Value = ...things with Addresses...
> data Heap = Heap !Address (Map Address Value)
>
> heapAlloc :: Heap -> (Address, Heap)
> heapAlloc (Heap nextFreeAddr binds) =
>   (nextFreeAddr, Heap (succ nextFreeAddr) binds)

There is also a stack of roots and an expression under evaluation.

> type Stack = [...things with Addresses...]
> data Expr = ...things with Addresses...

The function I need to write is:

> heapGC :: [Address] -> Heap -> Heap
> heapGC roots heap = ...collect unreachable values from heap...

Rather than re-invent this particularly complex wheel, I am wondering
if I could use GHC weak pointers and have the GHC runtime collect values
in my heap for me. Something like this:

> type Address = Int
> data Reference = Reference Address
> data Value = ...things with References...
> data Heap = Heap !Address (Map Address (Weak Value))
>
> heapAlloc :: Heap -> (Reference, Heap)
> heapAlloc (Heap nextFreeAddr binds) =
>   (Reference nextFreeAddr, Heap (succ nextFreeAddr) binds)
>
> heapStore :: Reference -> Value -> Heap -> IO Heap
> heapStore ref@(Reference addr) val (Heap nextFreeAddr binds) = do
>   weakVal <- mkWeak ref val Nothing
>   return $ Heap nextFreeAddr (Map.insert addr weakVal binds)

Note the new type, Reference. This replaces Address everywhere except
in the heap's internal structure, which continues to use Address.
Reference values are opaque, unique and obtained from the heap using
heapAlloc.

The idea is that only two things should cause Values to stay alive:
1. reachable holders of Reference (by GHC's definition of "reachable"),
2. ordinary Haskell closures arising from stepping the interpreter.
"Being in the Heap" should not be enough to keep a Value alive. Then,
my heapGC function should only have to prune dead addresses from the
map.

I am having trouble getting a proof-of-concept working (I am unable to
observe any finalizers running, ever), but before I get into that, is
this idea sound? Has somebody else implemented this in a library
already?

Thanks,
Thomas Koster

From sumit.sahrawat.apm13 at iitbhu.ac.in  Tue Oct  6 10:39:59 2015
From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing,
 IIT (BHU))
Date: Tue, 6 Oct 2015 16:09:59 +0530
Subject: [Haskell-cafe] A GC'd heap using weak pointers
In-Reply-To: <CAG1wH7AA9e6tQkashLq6SsgsvqbuXv64PK=o-r8PGVQcktGFbw@mail.gmail.com>
References: <CAG1wH7AA9e6tQkashLq6SsgsvqbuXv64PK=o-r8PGVQcktGFbw@mail.gmail.com>
Message-ID: <CAJbEW8OiS=xc0chEsHkA9EP=GAD+NFcsLvJedtQf982tHsXwUw@mail.gmail.com>

This would be well recieved on ghc-devs mailing list. Adding to cc.

On 6 October 2015 at 15:55, Thomas Koster <tkoster at gmail.com> wrote:

> Good afternoon list,
>
> I am implementing a simple, interpreted language that needs a garbage-
> collected heap for storage. Like most discussions on memory management,
> I use the term "heap" by analogy - the actual data structure is not
> necessarily a true heap.
>
> My Heap type is basically a map of "addresses" (Int) to values. Values
> may themselves contain addresses, perhaps recursively to each other
> (like letrec). The extra field in Heap stores the next unused address,
> used to allocate fresh slots, as you can see in "heapAlloc".
>
> > type Address = Int
> > data Value = ...things with Addresses...
> > data Heap = Heap !Address (Map Address Value)
> >
> > heapAlloc :: Heap -> (Address, Heap)
> > heapAlloc (Heap nextFreeAddr binds) =
> >   (nextFreeAddr, Heap (succ nextFreeAddr) binds)
>
> There is also a stack of roots and an expression under evaluation.
>
> > type Stack = [...things with Addresses...]
> > data Expr = ...things with Addresses...
>
> The function I need to write is:
>
> > heapGC :: [Address] -> Heap -> Heap
> > heapGC roots heap = ...collect unreachable values from heap...
>
> Rather than re-invent this particularly complex wheel, I am wondering
> if I could use GHC weak pointers and have the GHC runtime collect values
> in my heap for me. Something like this:
>
> > type Address = Int
> > data Reference = Reference Address
> > data Value = ...things with References...
> > data Heap = Heap !Address (Map Address (Weak Value))
> >
> > heapAlloc :: Heap -> (Reference, Heap)
> > heapAlloc (Heap nextFreeAddr binds) =
> >   (Reference nextFreeAddr, Heap (succ nextFreeAddr) binds)
> >
> > heapStore :: Reference -> Value -> Heap -> IO Heap
> > heapStore ref@(Reference addr) val (Heap nextFreeAddr binds) = do
> >   weakVal <- mkWeak ref val Nothing
> >   return $ Heap nextFreeAddr (Map.insert addr weakVal binds)
>
> Note the new type, Reference. This replaces Address everywhere except
> in the heap's internal structure, which continues to use Address.
> Reference values are opaque, unique and obtained from the heap using
> heapAlloc.
>
> The idea is that only two things should cause Values to stay alive:
> 1. reachable holders of Reference (by GHC's definition of "reachable"),
> 2. ordinary Haskell closures arising from stepping the interpreter.
> "Being in the Heap" should not be enough to keep a Value alive. Then,
> my heapGC function should only have to prune dead addresses from the
> map.
>
> I am having trouble getting a proof-of-concept working (I am unable to
> observe any finalizers running, ever), but before I get into that, is
> this idea sound? Has somebody else implemented this in a library
> already?
>
> Thanks,
> Thomas Koster
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>



-- 
Regards

Sumit Sahrawat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151006/4b69b1b6/attachment.html>

From Henrik.Nilsson at nottingham.ac.uk  Tue Oct  6 11:32:31 2015
From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson)
Date: Tue, 06 Oct 2015 12:32:31 +0100
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
Message-ID: <5613B14F.9070107@nottingham.ac.uk>

Dear all,

Executive Summary: Please let us defer further discussion
and ultimate decision on MRP to the resurrected HaskellPrime
committee

While we can discuss the extent of additional breakage
MRP would cause, the fact remains it is a further
breaking change. A survey of breakage to books as
Herbert did is certainly valuable  (thanks!), but
much breakage will (effectively) remain unquantifiable.

It is also clear from the discussions over the last
couple of weeks, on the Haskell libraries list as well
as various other forums and social media, that MRP is
highly contentions.

This begs two questions:

   1. Is the Haskell Libraries list and informal voting process
      really an appropriate, or even acceptable, way to adopt
      such far-reaching changes to what effectively amounts to
      Haskell itself?

   2. Why the hurry to push MRP through?

As to question 1, to Graham Hutton's and my knowledge,
the libraries list and its voting process was originally
set up for 3rd-party libraries in fptools. It seems to
have experienced some form of "mission creep" since.
Maybe that is understandable given that there was no
obvious alternative as HaskellPrime has been defunct
for a fair few years. But, as has been pointed out in a
number of postings, a lot of people with very valuable
perspectives are also very busy, and thus likely to
miss a short discussion period (as has happened in the
past in relation to the Burning the Bridges proposal)
and also have very little time for engaging in long and
complicated e-mail discussions that, from their
perspective, happen at a completely random point in
time and for which they thus have not had a chance to
set aside time even if they wanted to participate.

Just as one data point, AMP etc. mostly passed Graham
and me by simply because a) we were too busy to notice
and b) we simply didn't think there was a mandate for
such massive overhauls outside of a process like
HaskellPrime. And we are demonstrably not alone.

This brings us to question 2. Now that HaskellPrime is
being resurrected, why the hurry to push MRP through?
Surely HaskellPrime is the forum where breaking
changes like MRP should be discussed, allowing as much
time as is necessary and allowing for an as wide range
of perspectives as possible to properly be taken into
account?

The need to "field test" MRP prior to discussing
it in HaskellPrime has been mentioned. Graham and I
are very sceptical. In the past, at least in the
past leading up to Haskell 2010 or so, the community
at large was not roped in as involuntary field testers.

If MRP is pushed through now, with a resurrection of
HaskellPrime being imminent, Graham and I strongly believe
that risks coming across to a very large part of the
Haskell community as preempting proper process by facing
the new HaskellPrime committee with (yet another) fait
accompli.

Therefore, please let us defer further discussion and
ultimate decision on MRP to the resurrected
HaskellPrime committee, which is where it properly
belongs. Otherwise, the Haskell community itself might
be one of the things that MRP breaks.

Best regards,

/Henrik

-- 
Henrik Nilsson
School of Computer Science
The University of Nottingham
nhn at cs.nott.ac.uk




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.


From Lennart.Augustsson at sc.com  Tue Oct  6 11:57:23 2015
From: Lennart.Augustsson at sc.com (Augustsson, Lennart)
Date: Tue, 6 Oct 2015 11:57:23 +0000
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <5613B14F.9070107@nottingham.ac.uk>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <5613B14F.9070107@nottingham.ac.uk>
Message-ID: <22B950C955F8AB4196E72698FBD00002D0290B59@UKWPISXMB01D.zone1.scb.net>

To question 1 my answer is NO!  I think voting to decide these kind of issues a terrible idea; we might as well throw dice.

-----Original Message-----
From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Henrik Nilsson
Sent: 06 October 2015 12:33
To: haskell-prime at haskell.org List; Haskell Libraries; haskell cafe
Subject: Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Dear all,

Executive Summary: Please let us defer further discussion and ultimate decision on MRP to the resurrected HaskellPrime committee

While we can discuss the extent of additional breakage MRP would cause, the fact remains it is a further breaking change. A survey of breakage to books as Herbert did is certainly valuable  (thanks!), but much breakage will (effectively) remain unquantifiable.

It is also clear from the discussions over the last couple of weeks, on the Haskell libraries list as well as various other forums and social media, that MRP is highly contentions.

This begs two questions:

   1. Is the Haskell Libraries list and informal voting process
      really an appropriate, or even acceptable, way to adopt
      such far-reaching changes to what effectively amounts to
      Haskell itself?

   2. Why the hurry to push MRP through?

As to question 1, to Graham Hutton's and my knowledge, the libraries list and its voting process was originally set up for 3rd-party libraries in fptools. It seems to have experienced some form of "mission creep" since.
Maybe that is understandable given that there was no obvious alternative as HaskellPrime has been defunct for a fair few years. But, as has been pointed out in a number of postings, a lot of people with very valuable perspectives are also very busy, and thus likely to miss a short discussion period (as has happened in the past in relation to the Burning the Bridges proposal) and also have very little time for engaging in long and complicated e-mail discussions that, from their perspective, happen at a completely random point in time and for which they thus have not had a chance to set aside time even if they wanted to participate.

Just as one data point, AMP etc. mostly passed Graham and me by simply because a) we were too busy to notice and b) we simply didn't think there was a mandate for such massive overhauls outside of a process like HaskellPrime. And we are demonstrably not alone.

This brings us to question 2. Now that HaskellPrime is being resurrected, why the hurry to push MRP through?
Surely HaskellPrime is the forum where breaking changes like MRP should be discussed, allowing as much time as is necessary and allowing for an as wide range of perspectives as possible to properly be taken into account?

The need to "field test" MRP prior to discussing it in HaskellPrime has been mentioned. Graham and I are very sceptical. In the past, at least in the past leading up to Haskell 2010 or so, the community at large was not roped in as involuntary field testers.

If MRP is pushed through now, with a resurrection of HaskellPrime being imminent, Graham and I strongly believe that risks coming across to a very large part of the Haskell community as preempting proper process by facing the new HaskellPrime committee with (yet another) fait accompli.

Therefore, please let us defer further discussion and ultimate decision on MRP to the resurrected HaskellPrime committee, which is where it properly belongs. Otherwise, the Haskell community itself might be one of the things that MRP breaks.

Best regards,

/Henrik

--
Henrik Nilsson
School of Computer Science
The University of Nottingham
nhn at cs.nott.ac.uk




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html

Insofar as this communication contains any market commentary, the market commentary has been prepared by sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx

Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign on the term sheet to acknowledge in respect of the same.

Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx for important information with respect to derivative products.

From hesselink at gmail.com  Tue Oct  6 12:06:11 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Tue, 6 Oct 2015 14:06:11 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <5613B14F.9070107@nottingham.ac.uk>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <5613B14F.9070107@nottingham.ac.uk>
Message-ID: <CAPeieQFHywiaQ60OEB1xf=RHGVu+46xi30iXTmXTeGSxmAp2fw@mail.gmail.com>

I was always under the impression that +1/-1 was just a quick
indicator of opinion, not a vote, and that it was the core libraries
committee that would make the final call if enough consensus was
reached to enact the change.

Erik

On 6 October 2015 at 13:32, Henrik Nilsson
<Henrik.Nilsson at nottingham.ac.uk> wrote:
> Dear all,
>
> Executive Summary: Please let us defer further discussion
> and ultimate decision on MRP to the resurrected HaskellPrime
> committee
>
> While we can discuss the extent of additional breakage
> MRP would cause, the fact remains it is a further
> breaking change. A survey of breakage to books as
> Herbert did is certainly valuable  (thanks!), but
> much breakage will (effectively) remain unquantifiable.
>
> It is also clear from the discussions over the last
> couple of weeks, on the Haskell libraries list as well
> as various other forums and social media, that MRP is
> highly contentions.
>
> This begs two questions:
>
>   1. Is the Haskell Libraries list and informal voting process
>      really an appropriate, or even acceptable, way to adopt
>      such far-reaching changes to what effectively amounts to
>      Haskell itself?
>
>   2. Why the hurry to push MRP through?
>
> As to question 1, to Graham Hutton's and my knowledge,
> the libraries list and its voting process was originally
> set up for 3rd-party libraries in fptools. It seems to
> have experienced some form of "mission creep" since.
> Maybe that is understandable given that there was no
> obvious alternative as HaskellPrime has been defunct
> for a fair few years. But, as has been pointed out in a
> number of postings, a lot of people with very valuable
> perspectives are also very busy, and thus likely to
> miss a short discussion period (as has happened in the
> past in relation to the Burning the Bridges proposal)
> and also have very little time for engaging in long and
> complicated e-mail discussions that, from their
> perspective, happen at a completely random point in
> time and for which they thus have not had a chance to
> set aside time even if they wanted to participate.
>
> Just as one data point, AMP etc. mostly passed Graham
> and me by simply because a) we were too busy to notice
> and b) we simply didn't think there was a mandate for
> such massive overhauls outside of a process like
> HaskellPrime. And we are demonstrably not alone.
>
> This brings us to question 2. Now that HaskellPrime is
> being resurrected, why the hurry to push MRP through?
> Surely HaskellPrime is the forum where breaking
> changes like MRP should be discussed, allowing as much
> time as is necessary and allowing for an as wide range
> of perspectives as possible to properly be taken into
> account?
>
> The need to "field test" MRP prior to discussing
> it in HaskellPrime has been mentioned. Graham and I
> are very sceptical. In the past, at least in the
> past leading up to Haskell 2010 or so, the community
> at large was not roped in as involuntary field testers.
>
> If MRP is pushed through now, with a resurrection of
> HaskellPrime being imminent, Graham and I strongly believe
> that risks coming across to a very large part of the
> Haskell community as preempting proper process by facing
> the new HaskellPrime committee with (yet another) fait
> accompli.
>
> Therefore, please let us defer further discussion and
> ultimate decision on MRP to the resurrected
> HaskellPrime committee, which is where it properly
> belongs. Otherwise, the Haskell community itself might
> be one of the things that MRP breaks.
>
> Best regards,
>
> /Henrik
>
> --
> Henrik Nilsson
> School of Computer Science
> The University of Nottingham
> nhn at cs.nott.ac.uk
>
>
>
>
> This message and any attachment are intended solely for the addressee
> and may contain confidential information. If you have received this
> message in error, please send it back to me, and immediately delete it.
> Please do not use, copy or disclose the information contained in this
> message or in any attachment.  Any views or opinions expressed by the
> author of this email do not necessarily reflect the views of the
> University of Nottingham.
>
> This message has been checked for viruses but the contents of an
> attachment may still contain software viruses which could damage your
> computer system, you are advised to perform your own checks. Email
> communications with the University of Nottingham may be monitored as
> permitted by UK legislation.
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From jmaessen at alum.mit.edu  Tue Oct  6 12:25:34 2015
From: jmaessen at alum.mit.edu (Jan-Willem Maessen)
Date: Tue, 6 Oct 2015 08:25:34 -0400
Subject: [Haskell-cafe] Reducing the need for CPP (was: Monad of no
 `return` Proposal (MRP): Moving `return` out of `Monad`)
In-Reply-To: <87k2r0z8r6.fsf@smart-cactus.org>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CANBN=mv6WPLRdvLJppOZ2=1zkd7sWKAHwTF3rHie27RS_YLesA@mail.gmail.com>
 <87k2r0z8r6.fsf@smart-cactus.org>
Message-ID: <CANs0n6x+HHHdVdS1g16V0Fwa=jtN2_EFtC2YfHvN7pF4PoYPEg@mail.gmail.com>

On Tue, Oct 6, 2015 at 4:44 AM, Ben Gamari <ben at smart-cactus.org> wrote:

> Sven Panne <svenpanne at gmail.com> writes:
>
> > 2015-10-05 17:09 GMT+02:00 Gershom B <gershomb at gmail.com>:
> >
> >> On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (bos at serpentine.com
> )
> >> wrote:
> >> [...] As for libraries, it has been pointed out, I believe, that without
> >> CPP one can write instances compatible with AMP, and also with AMP +
> MRP.
> >> One can also write code, sans CPP, compatible with pre- and post- AMP.
> [...]
> >>
> >
> > Nope, at least not if you care about -Wall: If you take e.g. (<$>) which
> is
> > now part of the Prelude, you can't simply import some compatibility
> module,
> > because GHC might tell you (rightfully) that that import is redundant,
> > because (<$>) is already visible through the Prelude. So you'll have to
> use
> > CPP to avoid that import on base >= 4.8, be it from it Data.Functor,
> > Control.Applicative or some compat-* module. And you'll have to use CPP
> in
> > each and every module using <$> then, unless I miss something obvious.
> > AFAICT all transitioning guides ignore -Wall and friends...
> >
> This is a fair point that comes up fairly often. The fact that CPP is
> required to silence redundant import warnings is quite unfortunate.
> Others languages have better stories in this area. One example is Rust,
> which has a quite flexible `#[allow(...)]` pragma which can be used to
> acknowledge and silence a wide variety of warnings and lints [1].
>
> I can think of a few ways (some better than others) how we might
> introduce a similar idea for import redundancy checks in Haskell,
>
>  1. Attach a `{-# ALLOW redundant_import #-}` pragma to a definition,
>
>         -- in Control.Applicative
>         {-# ALLOW redundant_import (<$>) #-}
>         (<$>) :: (a -> b) -> f a -> f b
>         (<$>) = fmap
>
>     asking the compiler to pretend that any import of the symbol did not
>     exist when looking for redundant imports. This would allow library
>     authors to appropriately mark definitions when they are moved,
>     saving downstream users from having to make any change whatsoever.
>
>  2. Or alternatively we could make this a idea a bit more precise,
>
>         -- in Control.Applicative
>         {-# ALLOW redundant_import Prelude.(<$>) #-}
>         (<$>) :: (a -> b) -> f a -> f b
>         (<$>) = fmap
>
>     Which would ignore imports of `Control.Applicative.(<$>)` only if
>     `Prelude.(<$>)` were also in scope.
>

One obvious solution I haven't seen mentioned is the ability to add
nonexistent identifier to a hiding clause (these identifiers might
presumably exist in some other version of the import):

import Prelude hiding ((<$>))

I can see the argument for marking such imports with a pragma, though it
gets a bit ugly.

-Jan-Willem Maessen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151006/c4319a11/attachment.html>

From hvr at gnu.org  Tue Oct  6 13:00:41 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Tue, 06 Oct 2015 15:00:41 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
	`return` out of `Monad`
In-Reply-To: <CAPeieQFHywiaQ60OEB1xf=RHGVu+46xi30iXTmXTeGSxmAp2fw@mail.gmail.com>
 (Erik Hesselink's message of "Tue, 6 Oct 2015 14:06:11 +0200")
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <5613B14F.9070107@nottingham.ac.uk>
 <CAPeieQFHywiaQ60OEB1xf=RHGVu+46xi30iXTmXTeGSxmAp2fw@mail.gmail.com>
Message-ID: <87si5o6tja.fsf@gnu.org>

On 2015-10-06 at 14:06:11 +0200, Erik Hesselink wrote:
> I was always under the impression that +1/-1 was just a quick
> indicator of opinion, not a vote, and that it was the core libraries
> committee that would make the final call if enough consensus was
> reached to enact the change.

I'd like to point out, that the core libraries committee ought to
continue to do so (as hinted at in [1]) in its function as a Haskell
Prime sub-Committee (c.f. sub-teams in the Rust community[2]).

While there will be surely overlap of interests, contributions,
cross-reviewing and discussion, the principal task and responsibility of
the new sought members is to concentrate on the language part of the
Haskell Report where quite a bit of work is awaiting them.

Cheers,
  hvr

 [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html
 [2]: https://www.rust-lang.org/team.html

From Graham.Hutton at nottingham.ac.uk  Tue Oct  6 15:07:52 2015
From: Graham.Hutton at nottingham.ac.uk (Graham Hutton)
Date: Tue, 6 Oct 2015 15:07:52 +0000
Subject: [Haskell-cafe] Journal of Functional Programming - Call for PhD
	Abstracts
Message-ID: <B06F644D-A143-4AA8-AF92-6CF7E6E7A9B8@exmail.nottingham.ac.uk>

If you or one of your students recently completed a PhD
in the area of functional programming, please submit the
dissertation abstract for publication in JFP: simple
process, no refereeing, deadline 31st October 2015.

Many thanks,

Graham Hutton


============================================================

CALL FOR PHD ABSTRACTS

Journal of Functional Programming

Deadline: 31st October 2015

http://tinyurl.com/jfp-phd-abstracts

============================================================

PREAMBLE:

Many students complete PhDs in functional programming each
year.  As a service to the community, the Journal of Functional
Programming publishes the abstracts from PhD dissertations
completed during the previous year.

The abstracts are made freely available on the JFP website,
i.e. not behind any paywall.  They do not require any transfer
of copyright, merely a license from the author.  A dissertation
is eligible for inclusion if parts of it have or could have
appeared in JFP, that is, if it is in the general area of
functional programming.  The abstracts are not reviewed.

Please submit dissertation abstracts according to the instructions
below.  We welcome submissions from both the PhD student and PhD
advisor/supervisor although we encourage them to coordinate.

============================================================

SUBMISSION:

Please submit the following information to Graham Hutton
<graham.hutton at nottingham.ac.uk> by 31st October 2015.

o Dissertation title: (including any subtitle)

o Student: (full name)

o Awarding institution: (full name and country)

o Date of PhD award: (month and year; depending on the
 institution, this may be the date of the viva, corrections
 being approved, graduation ceremony, or otherwise)

o Advisor/supervisor: (full names)

o Dissertation URL: (please provide a permanently accessible
 link to the dissertation if you have one, such as to an
 institutional repository or other public archive; links
 to personal web pages should be considered a last resort)

o Dissertation abstract: (plain text, maximum 1000 words;
 you may use \emph{...} for emphasis, but we prefer no
 other markup or formatting in the abstract, but do get
 in touch if this causes significant problems)

Please do not submit a copy of the dissertation itself, as
this is not required.  JFP reserves the right to decline
to publish abstracts that are not deemed appropriate.

============================================================

PHD ABSTRACT EDITOR:

Graham Hutton
School of Computer Science
University of Nottingham
Nottingham NG8 1BB
United Kingdom

============================================================




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.


From spam at scientician.net  Tue Oct  6 16:16:52 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Tue, 6 Oct 2015 18:16:52 +0200
Subject: [Haskell-cafe] Reducing the need for CPP
In-Reply-To: <CAK-tuPYhF3e2nPesPZKtDoo350sL8254WGvf0g5cdFu8QZtnww@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CANBN=mv6WPLRdvLJppOZ2=1zkd7sWKAHwTF3rHie27RS_YLesA@mail.gmail.com>
 <87k2r0z8r6.fsf@smart-cactus.org>
 <CAK-tuPYhF3e2nPesPZKtDoo350sL8254WGvf0g5cdFu8QZtnww@mail.gmail.com>
Message-ID: <mv0s5k$c2a$2@ger.gmane.org>

On 10/06/2015 11:11 AM, Johan Tibell wrote:
> It might be enough to just add a NOWARN <warning type> pragma that acts on
> a single line/expression. I've seen it in both C++ and Python linters and
> it works reasonably well and it's quite general.

+1. Simple is good and can hopefully also be backported to older GHC
releases. (Provided someone's willing to do said releases, obviously.)



From hvr at gnu.org  Tue Oct  6 16:47:08 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Tue, 06 Oct 2015 18:47:08 +0200
Subject: [Haskell-cafe] MRP, 3-year-support-window,
	and the non-requirement of CPP
In-Reply-To: <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 (Johan Tibell's message of "Tue, 6 Oct 2015 10:10:01 +0200")
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
Message-ID: <87612k6j1v.fsf@gnu.org>

On 2015-10-06 at 10:10:01 +0200, Johan Tibell wrote:
[...]
>> You say that you stick to the 3-major-ghc-release support-window
>> convention for your libraries. This is good, because then you don't need
>> any CPP at all! Here's why:
>>
>> [...]
>>
>
> So what do I have to write today to have my Monad instances be:
>
>  * Warning free - Warnings are useful. Turning them off or having spurious
> warnings both contribute to bugs.

Depends on the warnings. Some warnings are more of an advisory kind
(hlint-ish). I wouldn't consider redundant imports a source of
bugs. Leaving off a top-level signature shouldn't be a source of
correctness bugs either. Also, warnings about upcoming changes
(i.e. deprecation warnings) also are not necessarily a bug, but rather a
way to raise awareness of API changes.

At the other end of the spectrum are more serious warnings I'd almost
consider errors, such as failing to define a non-defaulting method or
violating a MINIMAL pragma specification, as that can lead to bottoms
either in the form of runtime errors or even worse, hanging computations
(in case of cyclic definitions).

IMO, GHC should classify its warnings into severities/categories or
introduce some compromise between -Wall and not-Wall.

>  * Use imports that either are qualified or have explicit import lists -
> Unqualified imports makes code more likely to break when dependencies add
> exports.
>  * Don't use CPP.

That being said, as how to write your Monad instances today with GHC
7.10 w/o CPP, while supporting at least GHC 7.4/7.6/7.8/7.10: This
*does* work (admittedly for an easy example, but this can be
generalised):


--8<---------------cut here---------------start------------->8---
module MyMaybe where

import Control.Applicative (Applicative(..))
import Prelude (Functor(..), Monad(..), (.))
-- or alternatively: `import qualified Prelude as P`

data Maybe' a = Nothing' | Just' a

instance Functor Maybe' where
    fmap f (Just' v) = Just' (f v)
    fmap _ Nothing'  = Nothing'

instance Applicative Maybe' where
    pure = Just'
    f1 <*> f2   = f1 >>= \v1 -> f2 >>= (pure . v1)

instance Monad Maybe' where
    Nothing' >>= _  = Nothing'
    Just' x  >>= f  = f x

    return = pure -- "deprecated" since GHC 7.10

--8<---------------cut here---------------end--------------->8---

This example above compiles -Wall-clean and satisfies all your 3 stated
requirements afaics. I do admit this probably not what you had in mind.

But to be consistent, if you want to avoid unqualified imports at all
costs in order to have full control of what gets imported into your
namespace, you shouldn't tolerate an implicit unqualified wildcard
`Prelude` import either. As `Prelude` can, even if seldom, gain new
exports as well (or even loose them -- `interact` *could* be a candidate
for removal at some point).


> Neither AMP or MRP includes a recipe for this in their proposal.

That's because -Wall-hygiene (w/o opting out of harmless) warnings
across multiple GHC versions is not considered a show-stopper.

In the specific case of MRP, I can offer you a Wall-perfect transition
scheme by either using `ghc-options: -fno-mrp-warnings` in your
cabal-file, or if that doesn't satisfy you, we can delay phase1
(i.e. redundant return-def warnings) to GHC 8.2:

Now you can continue to write `return = pure` w/o GHC warning bothering
you until GHC 8.2, at which point the 3-year-window will reach to GHC
7.10.

Then starting with GHC 8.2 you can drop the `return` definition, and
keep your 


More generally though, we need more language-features and/or
modifications to the way GHC triggers warnings to make such
refactorings/changes to the libraries -Wall-perfect as well.

Beyond what Ben already suggested in another post, there was also the
more general suggestion to implicitly suppress warnings when you
explicitly name an import. E.g.

  import Control.Applicative (Applicative(..))
 
would suppress the redundant-import warning for Applicative via Prelude,
because we specifically requested Applicative, so we don't mind that
Prelude re-exports the same symbol.


> AMP got one post-facto on the Wiki. It turns out that the workaround
> there didn't work (we tried it in Cabal and it conflicted with one of
> the above requirements.)

Yes, that unqualified `import Prelude`-last trick mentioned on the Wiki
breaks down for more complex imports with (redundant) explicit import
lists.

However, the Maybe-example above works at the cost of a wordy
Prelude-import, but it's more robust, as you pin down exactly which
symbol you expect to get from each module.



> The problem by discussions is that they are done between two groups with
> quite a difference in experience. On one hand you have people like Bryan,
> who have considerable contributions to the Haskell ecosystem and much
> experience in large scale software development (e.g. from Facebook). On the
> other hand you have people who don't. That's okay. We've all been at the
> latter group at some point of our career.
[...]

At the risk of stating the obvious: I don't think it matters from which
group a given argument comes from as its validity doesn't depend on the
messenger. Neither does it matter whether an argument is repeated
several times or stated only once. Also, every argument deserves to be
considered regardless of its origin or frequency.


-- hvr

From hvr at gnu.org  Tue Oct  6 17:26:06 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Tue, 06 Oct 2015 19:26:06 +0200
Subject: [Haskell-cafe] MRP, 3-year-support-window,
	and the non-requirement of CPP
In-Reply-To: <87612k6j1v.fsf@gnu.org> (Herbert Valerio Riedel's message of
 "Tue, 06 Oct 2015 18:47:08 +0200")
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org>
Message-ID: <87oagb6h8x.fsf@gnu.org>


I hit "send" too early, so here's the incomplete section completed:

On 2015-10-06 at 18:47:08 +0200, Herbert Valerio Riedel wrote:

[...]

> In the specific case of MRP, I can offer you a Wall-perfect transition
> scheme by either using `ghc-options: -fno-mrp-warnings` in your
> cabal-file, or if that doesn't satisfy you, we can delay phase1
> (i.e. redundant return-def warnings) to GHC 8.2:
>
> Now you can continue to write `return = pure` w/o GHC warning bothering
> you until GHC 8.2, at which point the 3-year-window will reach to GHC
> 7.10.
>
> Then starting with GHC 8.2 you can drop the `return` definition, and

...keep supporting a 3-year-window back till GHC 7.10 (which
incorporates AMP and doesn't need `return` explicitly defined anymore)
without CPP.

And since you don't define `return` anymore, you don't get hit by the
MRP warning either, which would start with GHC 8.2.

GHC can keep providing as long as we want it to, and consider `return`
being an extra method of `Monad` simply a GHC-ism.

Future Haskell books and learning materials will hopefully be based on
the next Haskell Report incorporating the AMP and stop referring to the
historical `return` accident (which I consider badly named anyway from a
pedagogically perspective).

Code written unaware of `return` being a method of Monad will work
anyway just fine.

Do you see any problems with this scheme?


From svenpanne at gmail.com  Tue Oct  6 17:41:51 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Tue, 6 Oct 2015 19:41:51 +0200
Subject: [Haskell-cafe] MRP, 3-year-support-window,
 and the non-requirement of CPP
In-Reply-To: <87612k6j1v.fsf@gnu.org>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org>
Message-ID: <CANBN=mu_un8bJR3eCSMmpoXpL3_Mu-wsgdnZ+ZOiUGP-j4RWmw@mail.gmail.com>

2015-10-06 18:47 GMT+02:00 Herbert Valerio Riedel <hvr at gnu.org>:

> [...] That being said, as how to write your Monad instances today with GHC
> 7.10 w/o CPP, while supporting at least GHC 7.4/7.6/7.8/7.10: This
> *does* work (admittedly for an easy example, but this can be
> generalised):
>
>
> --8<---------------cut here---------------start------------->8---
> module MyMaybe where
>
> import Control.Applicative (Applicative(..))
> import Prelude (Functor(..), Monad(..), (.))
> -- or alternatively: `import qualified Prelude as P`
> [...]
> --8<---------------cut here---------------end--------------->8---
>
> This example above compiles -Wall-clean and satisfies all your 3 stated
> requirements afaics. I do admit this probably not what you had in mind.
>

OK, so the trick is that you're effectively hiding Applicative from the
Prelude (which might be a no-op). This "works" somehow, but is not
satisfactory IMHO for several reasons:

   * If you explicitly import all entities from Prelude, your import list
will typically get *very* long and unreadable. Furthermore, if that's the
suggested technique, what's the point of having a Prelude at all?

   * Some people see qualified imports as the holy grail, but having to
prefix tons of things with "P." is IMHO very ugly. Things are even worse
for operators: The whole notion of operators in itself is totally useless
and superfluous *except* for a single reason: Readability. And exactly that
gets destroyed when you have to qualify them, so I would (sadly) prefer
some #ifdef hell, if that gives me readable code elsewhere.

   * With the current trend of moving things to the Prelude, I can envision
a not-so-distant future where the whole Control.Applicative module will be
deprecated. As it is now, it's mostly superfluous and/or contains only
stuff which might better live somewhere else.


> [...] That's because -Wall-hygiene (w/o opting out of harmless) warnings
> across multiple GHC versions is not considered a show-stopper.
>

That's your personal POV, I'm more leaning towards "-Wall -Werror". I've
seen too many projects where neglecting warning over an extended period of
time made fixing them basically impossible at the end. Anyway, I think that
a sane ecosystem should allow *both* POVs, the sloppy one and the strict
one.


> [...] Beyond what Ben already suggested in another post, there was also the
> more general suggestion to implicitly suppress warnings when you
> explicitly name an import. E.g.
>
>   import Control.Applicative (Applicative(..))
>
> would suppress the redundant-import warning for Applicative via Prelude,
> because we specifically requested Applicative, so we don't mind that
> Prelude re-exports the same symbol. [...]
>

Uh, oh... That would be bad, because one normally wants to see redundant
imports. Without the compiler telling me, how should I find out which are
redundant? Manually trying to remove them step by step? :-/

Cheers,
   S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151006/a0242e30/attachment.html>

From david.feuer at gmail.com  Tue Oct  6 18:12:46 2015
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 6 Oct 2015 14:12:46 -0400
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <5613B14F.9070107@nottingham.ac.uk>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <5613B14F.9070107@nottingham.ac.uk>
Message-ID: <CAMgWh9ua5L7Jpng4a7J-WVXZ5xhrxz7GT0kn+S4jJEernDJueQ@mail.gmail.com>

On Oct 6, 2015 7:32 AM, "Henrik Nilsson" <Henrik.Nilsson at nottingham.ac.uk>
wrote:
> Executive Summary: Please let us defer further discussion
> and ultimate decision on MRP to the resurrected HaskellPrime
> committee

Many more people are on this mailing list than will be chosen for the
committee. Those who are not chosen have useful perspectives as well.

>   1. Is the Haskell Libraries list and informal voting process
>      really an appropriate, or even acceptable, way to adopt
>      such far-reaching changes to what effectively amounts to
>      Haskell itself?

As others have said, no one wants that.

> But, as has been pointed out in a
> number of postings, a lot of people with very valuable
> perspectives are also very busy, and thus likely to
> miss a short discussion period (as has happened in the
> past in relation to the Burning the Bridges proposal)

The Foldable/Traversable BBP indeed was not as well discussed as it should
have been. AMP, on the other hand, was discussed extensively and publicly
for months. I understand that some people need months of notice to prepare
to participate in a discussion. Unfortunately, I don't think those people
can always be included. Life moves too quickly for that. I do think it
might be valuable to set up a moderated, extremely low volume mailing list
for discussion of only the most important changes, with its messages
forwarded to the general list.

> The need to "field test" MRP prior to discussing
> it in HaskellPrime has been mentioned. Graham and I
> are very sceptical. In the past, at least in the
> past leading up to Haskell 2010 or so, the community
> at large was not roped in as involuntary field testers.

No, and Haskell 2010 was, by most measures, a failure. It introduced no new
language features (as far as I can recall) and only a few of the most
conservative library changes imaginable. Standard Haskell has stagnated
since 1998, 17 years ago. Haskell 2010 did not reflect the Haskell people
used in their research our practical work then, and I think people are
justified in their concern that the next standard may be similarly
disappointing. One of the major problems is the (understandable, and in
many ways productive) concentration of development effort in a single
compiler. When there is only one modern Haskell implementation that is
commonly used, it's hard to know how changes to the standard will affect
other important implementation techniques, and therefore hard to justify
any substantial changes. That was true in 2010, and it is, if anything,
more true now.

> Therefore, please let us defer further discussion and
> ultimate decision on MRP to the resurrected
> HaskellPrime committee, which is where it properly
> belongs. Otherwise, the Haskell community itself might
> be one of the things that MRP breaks.

I hope not. Haskell has gained an awful lot from the researchers, teachers,
and developers who create it and use it. I hope we can work out an
appropriate balance of inclusion, caution, and speed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151006/c9d09a69/attachment.html>

From malcolm.wallace at me.com  Tue Oct  6 19:02:12 2015
From: malcolm.wallace at me.com (Malcolm Wallace)
Date: Tue, 06 Oct 2015 20:02:12 +0100
Subject: [Haskell-cafe] MRP, 3-year-support-window,
 and the non-requirement of CPP
In-Reply-To: <87612k6j1v.fsf@gnu.org>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org>
Message-ID: <F351956E-517E-4387-A3E5-29968ADB5ACA@me.com>


On 6 Oct 2015, at 17:47, Herbert Valerio Riedel wrote:

> 
>> The problem by discussions is that they are done between two groups with
>> quite a difference in experience. On one hand you have people like Bryan,
>> who have considerable contributions to the Haskell ecosystem and much
>> experience in large scale software development (e.g. from Facebook). On the
>> other hand you have people who don't. That's okay. We've all been at the
>> latter group at some point of our career.
> [...]
> 
> At the risk of stating the obvious: I don't think it matters from which
> group a given argument comes from as its validity doesn't depend on the
> messenger. 

In that case, I think you are misunderstanding the relevance of Johan's argument here.  Let me try to phrase it differently.  Some people who can reasonably claim to have experience with million-line plus codebases are warning that this change is too disruptive, and makes maintenance harder than it ought to be.  On the other hand, of the people who say the change is not really disruptive, none of them have (yet?) made claims to have experience of the maintenance of extremely large-scale codebases.  The authority of the speaker does matter in technical arguments of this nature: people without the relevant experience are simply unqualified to make guesses about the impact. 

Regards,
    Malcolm

From hvr at gnu.org  Tue Oct  6 17:03:44 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Tue, 06 Oct 2015 19:03:44 +0200
Subject: [Haskell-cafe] MRP, 3-year-support-window,
	and the non-requirement of CPP
In-Reply-To: <87612k6j1v.fsf@gnu.org> (Herbert Valerio Riedel's message of
 "Tue, 06 Oct 2015 18:47:08 +0200")
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org>
Message-ID: <871td86ia7.fsf@gnu.org>


I hit "send" too early, so here's the incomplete section completed:

On 2015-10-06 at 18:47:08 +0200, Herbert Valerio Riedel wrote:

[...]

> In the specific case of MRP, I can offer you a Wall-perfect transition
> scheme by either using `ghc-options: -fno-mrp-warnings` in your
> cabal-file, or if that doesn't satisfy you, we can delay phase1
> (i.e. redundant return-def warnings) to GHC 8.2:
>
> Now you can continue to write `return = pure` w/o GHC warning bothering
> you until GHC 8.2, at which point the 3-year-window will reach to GHC
> 7.10.
>
> Then starting with GHC 8.2 you can drop the `return` definition, and

...keep supporting a 3-year-window back till GHC 7.10 (which
incorporates AMP and doesn't need `return` explicitly defined anymore)
without CPP.

And since you don't define `return` anymore, you don't get hit by the
MRP warning either, which would start with GHC 8.2.

GHC can keep providing as long as we want it to, and consider `return`
being an extra method of `Monad` simply a GHC-ism.

Future Haskell books and learning materials will hopefully be based on
the next Haskell Report incorporating the AMP and stop referring to the
historical `return` accident (which I consider badly named anyway from a
pedagogically perspective).

Code written unaware of `return` being a method of Monad will work
anyway just fine.

Do you see any problems with this scheme?


From adam at bergmark.nl  Tue Oct  6 19:16:22 2015
From: adam at bergmark.nl (Adam Bergmark)
Date: Tue, 6 Oct 2015 21:16:22 +0200
Subject: [Haskell-cafe] Reducing the need for CPP
In-Reply-To: <mv0s5k$c2a$2@ger.gmane.org>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CANBN=mv6WPLRdvLJppOZ2=1zkd7sWKAHwTF3rHie27RS_YLesA@mail.gmail.com>
 <87k2r0z8r6.fsf@smart-cactus.org>
 <CAK-tuPYhF3e2nPesPZKtDoo350sL8254WGvf0g5cdFu8QZtnww@mail.gmail.com>
 <mv0s5k$c2a$2@ger.gmane.org>
Message-ID: <CACnqJZY2-WgAeaUU7bLQE+_tnLrtaJWQXx5wm9CrmnZvZSjnAg@mail.gmail.com>

On Tue, Oct 6, 2015 at 6:16 PM, Bardur Arantsson <spam at scientician.net>
wrote:

> On 10/06/2015 11:11 AM, Johan Tibell wrote:
> > It might be enough to just add a NOWARN <warning type> pragma that acts
> on
> > a single line/expression. I've seen it in both C++ and Python linters and
> > it works reasonably well and it's quite general.
>
> +1. Simple is good and can hopefully also be backported to older GHC
> releases. (Provided someone's willing to do said releases, obviously.)
>

I've thought of this in the past and it would be great to have. Another
possible use case is to allow this for extensions as well, e.g. "Only allow
UndecidableInstances for this declaration"


>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151006/4f48f31d/attachment.html>

From the.dead.shall.rise at gmail.com  Tue Oct  6 19:32:19 2015
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Tue, 6 Oct 2015 21:32:19 +0200
Subject: [Haskell-cafe] MRP, 3-year-support-window,
 and the non-requirement of CPP
In-Reply-To: <871td86ia7.fsf@gnu.org>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org> <871td86ia7.fsf@gnu.org>
Message-ID: <CA+tcxkCLqxhXDrjKbVsiezDfhptJY9UtjSMabwtvp+0PK1h+cA@mail.gmail.com>

Hi,

On 6 October 2015 at 19:03, Herbert Valerio Riedel <hvr at gnu.org> wrote:
>> In the specific case of MRP, I can offer you a Wall-perfect transition
>> scheme by either using `ghc-options: -fno-mrp-warnings` in your
>> cabal-file, [...]

Apropos, is there a similar option for AMP warnings? I would rather
use that than CPP.

From cma at bitemyapp.com  Tue Oct  6 20:16:40 2015
From: cma at bitemyapp.com (Christopher Allen)
Date: Tue, 6 Oct 2015 15:16:40 -0500
Subject: [Haskell-cafe] MRP, 3-year-support-window,
 and the non-requirement of CPP
In-Reply-To: <F351956E-517E-4387-A3E5-29968ADB5ACA@me.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org>
 <F351956E-517E-4387-A3E5-29968ADB5ACA@me.com>
Message-ID: <CADnndOpOUaRdYMO4QAmQmAia-3Y5H4eWaJyS-QPJ0frBVUwANg@mail.gmail.com>

Do those participating in this thread think sentiments like this are
constructive or inclusive? Is this how we encourage participation from
newer members of the community?

Framing this debate in terms of a programming pecking order is
unprofessional. Many times, those higher in the ranks will prefer a more
conservative approach, as experienced surgeons once resisted the
introduction of the autoclave.

The problem isn't the change; it's what the change costs you. Provide data
and make your case. Talk about what it _costs_ you, show evidence for that
cost, and describe what would make the change acceptable. Do it without
talking down to a constructed "other" of the people who've neglected to
make the same status display you've injected into this conversation. That
could be valuable input to the discussion, so we would could weigh costs
and benefits as a community.

There _are_ costs associated with going ahead with MRP, especially for
those with large 1mm LOC industrial codebases. This is partly why I'm
lukewarm on the change, but I believe it needs to happen sooner or later
and waiting for more 1mm LOC codebases to be born isn't going to make it
any better. The suggestions that we consider the example of 2to3 I believe
have been more constructive, particularly since we have this lovely
language which lends itself so nicely to static analysis anyway.


On Tue, Oct 6, 2015 at 2:02 PM, Malcolm Wallace <malcolm.wallace at me.com>
wrote:

>
> On 6 Oct 2015, at 17:47, Herbert Valerio Riedel wrote:
>
> >
> >> The problem by discussions is that they are done between two groups with
> >> quite a difference in experience. On one hand you have people like
> Bryan,
> >> who have considerable contributions to the Haskell ecosystem and much
> >> experience in large scale software development (e.g. from Facebook). On
> the
> >> other hand you have people who don't. That's okay. We've all been at the
> >> latter group at some point of our career.
> > [...]
> >
> > At the risk of stating the obvious: I don't think it matters from which
> > group a given argument comes from as its validity doesn't depend on the
> > messenger.
>
> In that case, I think you are misunderstanding the relevance of Johan's
> argument here.  Let me try to phrase it differently.  Some people who can
> reasonably claim to have experience with million-line plus codebases are
> warning that this change is too disruptive, and makes maintenance harder
> than it ought to be.  On the other hand, of the people who say the change
> is not really disruptive, none of them have (yet?) made claims to have
> experience of the maintenance of extremely large-scale codebases.  The
> authority of the speaker does matter in technical arguments of this nature:
> people without the relevant experience are simply unqualified to make
> guesses about the impact.
>
> Regards,
>     Malcolm
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>



-- 
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151006/f345e2ab/attachment.html>

From hvr at gnu.org  Tue Oct  6 20:16:22 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Tue, 06 Oct 2015 22:16:22 +0200
Subject: [Haskell-cafe] MRP, 3-year-support-window,
	and the non-requirement of CPP
In-Reply-To: <CA+tcxkCLqxhXDrjKbVsiezDfhptJY9UtjSMabwtvp+0PK1h+cA@mail.gmail.com>
 (Mikhail Glushenkov's message of "Tue, 6 Oct 2015 21:32:19 +0200")
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org> <871td86ia7.fsf@gnu.org>
 <CA+tcxkCLqxhXDrjKbVsiezDfhptJY9UtjSMabwtvp+0PK1h+cA@mail.gmail.com>
Message-ID: <87d1wrycq1.fsf@gnu.org>

Hi,

On 2015-10-06 at 21:32:19 +0200, Mikhail Glushenkov wrote:
> On 6 October 2015 at 19:03, Herbert Valerio Riedel <hvr at gnu.org> wrote:
>>> In the specific case of MRP, I can offer you a Wall-perfect transition
>>> scheme by either using `ghc-options: -fno-mrp-warnings` in your
>>> cabal-file, [...]
>
> Apropos, is there a similar option for AMP warnings? I would rather
> use that than CPP.

Sure, added in GHC 7.8:

| In GHC 7.10, Applicative will become a superclass of Monad,
| potentially breaking a lot of user code. To ease this transition, GHC
| now generates warnings when definitions conflict with the
| Applicative-Monad Proposal (AMP).
|
| A warning is emitted if a type is an instance of Monad but not of
| Applicative, MonadPlus but not Alternative, and when a local function
| named join, <*> or pure is defined.
|
| The warnings are enabled by default, and can be controlled using the
| new flag -f[no-]warn-amp.


However, if you use that now with GHC 7.10 you get a warning:

| $ ghc-7.10.2 -fno-warn-amp
|  
| on the commandline: Warning:
|     -fno-warn-amp is deprecated: it has no effect, and will be removed in GHC 7.12

so you you'll need to guard that with something like

  if impl(ghc == 7.8.*) ghc-options: -fno-warn-amp


From r.wobben at home.nl  Tue Oct  6 20:24:03 2015
From: r.wobben at home.nl (Roelof Wobben)
Date: Tue, 6 Oct 2015 22:24:03 +0200
Subject: [Haskell-cafe] quickCheck problem
Message-ID: <56142DE3.30604@home.nl>

Hello,

I have written a function to test if three numbers are the same.

Now I want to test my functions by using quickCheck.

So I thought to test first if all three are the same.

but how can I tell quickcheck that all numbers are the same.

and second question :  hwo do the test likeif two numbers are the same.

I ask this because I try to solve a exercise of the programming Haskell 
book,
IM have read chapter 3 now.

Roelof


From creswick at gmail.com  Tue Oct  6 20:31:27 2015
From: creswick at gmail.com (Rogan Creswick)
Date: Tue, 6 Oct 2015 13:31:27 -0700
Subject: [Haskell-cafe] quickCheck problem
In-Reply-To: <56142DE3.30604@home.nl>
References: <56142DE3.30604@home.nl>
Message-ID: <CAHjep=yn7JBfZzZRv9zQN2n0ZagzwtGPdP1gkhPUN2t9VS3MdQ@mail.gmail.com>

On Tue, Oct 6, 2015 at 1:24 PM, Roelof Wobben <r.wobben at home.nl> wrote:
> Hello,
>
> I have written a function to test if three numbers are the same.
>
> Now I want to test my functions by using quickCheck.
>
> So I thought to test first if all three are the same.
>
> but how can I tell quickcheck that all numbers are the same.

Just have quickcheck generate one number, and use it for all three
arguments, eg:

prop_allSame :: Int -> Bool
prop_allSame x = yourFn x x x

then test the other cases:

prop_different :: Int -> Int -> Int -> Property
prop_different x y z = x /= y && y /= z && x /= z ==> not $ yourFn x y z

That's probably OK for ints, but generally the guard in that style
isn't a great solution, since quickcheck will just keep generating
inputs until the predicate is satisfied.  That can take a while, so
you could also manually offset the first input in various ways:

prop_different :: Int -> Int -> Bool
prop_different x y = not $ yourFn x (x + y) (x - (y + 1)) -- I put a
+1 in here to avoid returning true where y = 0,

There are probably other ways to mutate a randomly generated input for
your problem that may work better, but that's the general idea.

--Rogan

>
> and second question :  hwo do the test likeif two numbers are the same.
>
> I ask this because I try to solve a exercise of the programming Haskell
> book,
> IM have read chapter 3 now.
>
> Roelof
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Tue Oct  6 20:36:41 2015
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Tue, 6 Oct 2015 21:36:41 +0100
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
Message-ID: <20151006203641.GS11050@weber>

On Mon, Oct 05, 2015 at 05:40:43PM -0700, Gregory Collins wrote:
>    - defaultTimeLocale moved from System.Locale to Data.Time.Format in
>    time-1.5 (no compat package for this, afaik)

    http://hackage.haskell.org/package/time-compat

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Tue Oct  6 20:39:01 2015
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Tue, 6 Oct 2015 21:39:01 +0100
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
Message-ID: <20151006203900.GT11050@weber>

On Mon, Oct 05, 2015 at 05:40:43PM -0700, Gregory Collins wrote:
> On Mon, Oct 5, 2015 at 3:18 PM, Bryan Richter <b at chreekat.net> wrote:
> > Hang on a moment, are you saying that all the people writing to argue
> > that these changes would require them to write dozens more #ifdef's
> > actually don't have to write any at all?
> 
> Um, no, it usually isn't anything like that. Here's a sampling of some of
> the things I've used CPP for in the past few years:
> 
>    - After GHC 7.4, when using a newtype in FFI imports you need to import
>    the constructor, i.e. "import Foreign.C.Types(CInt(..))" --- afaik CPP is
>    the only way to shut up warnings everywhere
>    - defaultTimeLocale moved from System.Locale to Data.Time.Format in
>    time-1.5 (no compat package for this, afaik)
>    - one of many various changes to Typeable in the GHC 7.* series
>    (deriving works better now, mkTyCon vs mkTyCon3, etc)
>    - Do I have to hide "catch" from Prelude, or not? It got moved, and
>    "hiding" gives an error if the symbol you're trying to hide is missing.
>    Time to break out the CPP (and curse myself for not just using the
>    qualified import in the first place)
>    - Do I get monoid functions from Prelude or from Data.Monoid? Same w/
>    Applicative, Foldable, Word. I don't know where anything is supposed to
>    live anymore, or which sequence of imports will shut up spurious warnings
>    on all four versions of GHC I support, so the lowest-friction fix is: break
>    out the #ifdef spackle
>    - ==# and friends return Int# instead of Bool after GHC 7.8.1
>    - To use functions like "tryReadMVar", "unsafeShiftR", and
>    "atomicModifyIORef'" that are in recent base versions but not older ones
>    (this is a place where CPP use is actually justified)

In fact I think all of these apart from the FFI one could be solved with a
-compat package, could they not?

From r.wobben at home.nl  Tue Oct  6 21:01:44 2015
From: r.wobben at home.nl (Roelof Wobben)
Date: Tue, 6 Oct 2015 23:01:44 +0200
Subject: [Haskell-cafe] quickCheck problem
In-Reply-To: <CAHjep=yn7JBfZzZRv9zQN2n0ZagzwtGPdP1gkhPUN2t9VS3MdQ@mail.gmail.com>
References: <56142DE3.30604@home.nl>
 <CAHjep=yn7JBfZzZRv9zQN2n0ZagzwtGPdP1gkhPUN2t9VS3MdQ@mail.gmail.com>
Message-ID: <561436B8.8090804@home.nl>

Thanks,

but why this part :

x (x + y) (x - (y + 1))


Roelof

Op 6-10-2015 om 22:31 schreef Rogan Creswick:
> On Tue, Oct 6, 2015 at 1:24 PM, Roelof Wobben <r.wobben at home.nl> wrote:
>> Hello,
>>
>> I have written a function to test if three numbers are the same.
>>
>> Now I want to test my functions by using quickCheck.
>>
>> So I thought to test first if all three are the same.
>>
>> but how can I tell quickcheck that all numbers are the same.
> Just have quickcheck generate one number, and use it for all three
> arguments, eg:
>
> prop_allSame :: Int -> Bool
> prop_allSame x = yourFn x x x
>
> then test the other cases:
>
> prop_different :: Int -> Int -> Int -> Property
> prop_different x y z = x /= y && y /= z && x /= z ==> not $ yourFn x y z
>
> That's probably OK for ints, but generally the guard in that style
> isn't a great solution, since quickcheck will just keep generating
> inputs until the predicate is satisfied.  That can take a while, so
> you could also manually offset the first input in various ways:
>
> prop_different :: Int -> Int -> Bool
> prop_different x y = not $ yourFn x (x + y) (x - (y + 1)) -- I put a
> +1 in here to avoid returning true where y = 0,
>
> There are probably other ways to mutate a randomly generated input for
> your problem that may work better, but that's the general idea.
>
> --Rogan
>
>> and second question :  hwo do the test likeif two numbers are the same.
>>
>> I ask this because I try to solve a exercise of the programming Haskell
>> book,
>> IM have read chapter 3 now.
>>
>> Roelof
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
> -----
> Geen virus gevonden in dit bericht.
> Gecontroleerd door AVG - www.avg.com
> Versie: 2015.0.6140 / Virusdatabase: 4435/10768 - datum van uitgifte: 10/06/15
>
>


From mark.lentczner at gmail.com  Tue Oct  6 21:15:10 2015
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Tue, 6 Oct 2015 14:15:10 -0700
Subject: [Haskell-cafe] MRP, 3-year-support-window,
 and the non-requirement of CPP (was: Monad of no `return` Proposal
 (MRP): Moving `return` out of `Monad`)
In-Reply-To: <CAK-tuPYxNM9uoywucSOT6O3RFhw2AGhCvBTKjOruKQK2V5dY3Q@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <CAK-tuPYxNM9uoywucSOT6O3RFhw2AGhCvBTKjOruKQK2V5dY3Q@mail.gmail.com>
Message-ID: <CAAOoiFauRYsFLa_4LfuRq=s7+LhoAqFwEBEEzcuYv2pdesgdCQ@mail.gmail.com>

On Thu, Sep 24, 2015 at 2:43 PM, Herbert Valerio Riedel <hvr at gnu.org> wrote:

> TLDR: To complete the AMP, turn `Monad(return)` method into a
>       top-level binding aliasing `Applicative(pure)`.
>

Sure... if we had a language that no one uses and could keep reforming like
putty until it is perfect. But we don't.

A modest proposal:

We can't keep tinkering with a language and it's libraries like this AND
have a growing ecosystem that serves an ever widening base, including the
range from newcomer to commercial deployment. SO - Why let's do all the
language tinkering in GHC 8 there can be as many prereleases of that as
needed until it is just right. ...and leave GHC 7 (7.10? roll back to
7.8.4?) for all of us doing essential and dependable libraries, commercial
work, projects on Haskell that we don't want to have to go back and #ifdefs
to twice a year just to keep running, educators, people writing books. We
can keep improving GHC 7 as needed, and focus on bugs, security issues,
patches, cross compatibility, etc.

Think of it as Perl 6 or Python 3 for Haskell.

- Mark

On Tue, Oct 6, 2015 at 1:12 AM, Johan Tibell <johan.tibell at gmail.com> wrote:

> (Resending with smaller recipient list to avoid getting stuck in the
> moderator queue.)
>
> On Tue, Oct 6, 2015 at 9:10 AM, Herbert Valerio Riedel <hvr at gnu.org>
>  wrote:
>
>> On 2015-10-05 at 21:01:16 +0200, Johan Tibell wrote:
>> > On the libraries I maintain and have a copy of on my computer right
>> now: 329
>>
>>
>> Although this was already pointed out to you in a response to a Tweet of
>> yours, I'd like to expand on this here to clarify:
>>
>>
>> You say that you stick to the 3-major-ghc-release support-window
>> convention for your libraries. This is good, because then you don't need
>> any CPP at all! Here's why:
>>
>> [...]
>>
>
> So what do I have to write today to have my Monad instances be:
>
>  * Warning free - Warnings are useful. Turning them off or having spurious
> warnings both contribute to bugs.
>  * Use imports that either are qualified or have explicit import lists -
> Unqualified imports makes code more likely to break when dependencies add
> exports.
>  * Don't use CPP.
>
> Neither AMP or MRP includes a recipe for this in their proposal. AMP got
> one post-facto on the Wiki. It turns out that the workaround there didn't
> work (we tried it in Cabal and it conflicted with one of the above
> requirements.)
>
> PS: I'm a bit disappointed you seem to dismiss this proposal right away
>>     categorically without giving us a chance to address your
>>     concerns. The proposal is not a rigid all-or-nothing thing that
>>     can't be tweaked and revised.  That's why we're having these
>>     proposal-discussions in the first place (rather than doing blind
>>     +1/-1 polls), so we can hear everyone out and try to maximise the
>>     agreement (even if we will never reach 100% consensus on any
>>     proposal).
>>
>>     So please, keep on discussing!
>>
>
> The problem by discussions is that they are done between two groups with
> quite a difference in experience. On one hand you have people like Bryan,
> who have considerable contributions to the Haskell ecosystem and much
> experience in large scale software development (e.g. from Facebook). On the
> other hand you have people who don't. That's okay. We've all been at the
> latter group at some point of our career.
>
> What's frustrating is that people don't take a step bad and realize that
> they might be in the latter group and should perhaps listen to those in the
> former. This doesn't happen, instead we get lots of "C++ and Java so bad
> and we don't want to be like them." Haskell is not at risk of becoming C++
> or Java (which are a large improvement compared to the languages came
> before them). We're at risk of missing our window of opportunity. I think
> that would be a shame, as I think Haskell is a step forward compared to
> those languages and I would like to see more software that used be written
> in Haskell.
>
> We've been through this many times before on the libraries list. I'm not
> going to win an argument on this mailing list. Between maintaining
> libraries you all use and managing a largish team at Google, I don't have
> much time for a discussion which approaches a hundred emails and is won by
> virtue of having lots of time to write emails.
>
> -- Johan
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151006/98025ec9/attachment.html>

From greg at gregorycollins.net  Tue Oct  6 21:29:53 2015
From: greg at gregorycollins.net (Gregory Collins)
Date: Tue, 6 Oct 2015 14:29:53 -0700
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <20151006203900.GT11050@weber>
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
Message-ID: <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>

On Tue, Oct 6, 2015 at 1:39 PM, Tom Ellis <
tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote:

> In fact I think all of these apart from the FFI one could be solved with a
> -compat package, could they not?
>

Who cares? In practice, the programs break and I have to fix them. Most of
the time, CPP is the lowest-friction solution -- if I rely on a -compat
package, first I have to know it exists and that I should use it to fix my
compile error, and then I've added an additional non-platform dependency
that I'm going to have to go back and clean up in 18 months. Usually, to be
honest, *actually* the procedure is that the new RC comes out and I get
github pull requests from hvr@ :-) :-)

In response to the other person who asked "why do you want to support so
many GHC versions anyways?" --- because I don't hate my users, and don't
want to force them to run on the upgrade treadmill if they don't have to?
Our policy is to support the last 4 major GHC versions (or 2 years,
whichever is shorter). And if we support a version of GHC, I want our
libraries to compile on it without warnings, I don't think that should
mystify anyone.

-- 
Gregory Collins <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151006/d0ab3c30/attachment.html>

From achudnov at gmail.com  Tue Oct  6 21:52:59 2015
From: achudnov at gmail.com (Andrey Chudnov)
Date: Tue, 6 Oct 2015 17:52:59 -0400
Subject: [Haskell-cafe] MRP, 3-year-support-window,
 and the non-requirement of CPP
In-Reply-To: <87zizw8obv.fsf_-_@gnu.org>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
Message-ID: <561442BB.6010404@gmail.com>

Herbert, unfortunately your logic would break if there is another 
invasive library change somewhere between 7.10 and 8.2 as that would 
require introducing a whole another set of #ifdef's. I've been using GHC 
since 6.2. Since then new versions of GHC have been breaking builds of 
foundational packages every 1-2 releases. I'm actually all for decisive 
and unapologetic language evolution, but there should be a safety net so 
there's less risk of breakage. And, the main sentiment in the discussion 
(which, I admit, I have followed very loosely) seems to be that #ifdef's 
are a poor choice for such a net.

So, forgive me if that has been discussed, but what has happened to the 
`haskell2010` package that is supposed to provide a compatibility layer 
for the standard library? Are people using it? Why hasn't it been 
updated since March 2014? Is it really impossible to provide a legacy 
Haskell2010 base library compatibility layer with AMP in play?

Perhaps it's my ignorance speaking, but I really think if packages like 
`haskell2010` and `haskell98` were actively maintained and used, we 
wouldn't have issues like that. Then you could say: "if you depend on 
the GHC `base` package directly, your portability troubles are well 
deserved".

On 10/06/2015 03:10 AM, Herbert Valerio Riedel wrote:
> So when GHC 8.2 is released, your support-window requires you to support
> GHC 7.10 and GHC 8.0 in addition to GHC 8.2.
>
> At this point you'll be happy that you can start dropping those #ifdefs
> you added for GHC 7.10 in your code in order to adapt to FTP & AMP.

From creswick at gmail.com  Tue Oct  6 22:28:20 2015
From: creswick at gmail.com (Rogan Creswick)
Date: Tue, 6 Oct 2015 15:28:20 -0700
Subject: [Haskell-cafe] quickCheck problem
In-Reply-To: <561436B8.8090804@home.nl>
References: <56142DE3.30604@home.nl>
 <CAHjep=yn7JBfZzZRv9zQN2n0ZagzwtGPdP1gkhPUN2t9VS3MdQ@mail.gmail.com>
 <561436B8.8090804@home.nl>
Message-ID: <CAHjep=xDr1QQCMB1AcirDDW9ZkPVpWX7LyAV8o2-AP5u5PhpOg@mail.gmail.com>

On Tue, Oct 6, 2015 at 2:01 PM, Roelof Wobben <r.wobben at home.nl> wrote:
> but why this part :
>
> x (x + y) (x - (y + 1))

That is buggy.  I was trying to quickly create three arguments that
are guaranteed to be different by some random amount, but what I wrote
doesn't always work (eg: if y = 0, then the first two arguments are
the same, if y is -1, the first and 3rd are the same, if x is MAX_INT,
then it may or may not be the same as other arguments, depending on Y,
etc...)

The predicate guard should work, though it may take longer to run.

--Rogan

>
>
> Roelof
>
> Op 6-10-2015 om 22:31 schreef Rogan Creswick:
>>
>> On Tue, Oct 6, 2015 at 1:24 PM, Roelof Wobben <r.wobben at home.nl> wrote:
>>>
>>> Hello,
>>>
>>> I have written a function to test if three numbers are the same.
>>>
>>> Now I want to test my functions by using quickCheck.
>>>
>>> So I thought to test first if all three are the same.
>>>
>>> but how can I tell quickcheck that all numbers are the same.
>>
>> Just have quickcheck generate one number, and use it for all three
>> arguments, eg:
>>
>> prop_allSame :: Int -> Bool
>> prop_allSame x = yourFn x x x
>>
>> then test the other cases:
>>
>> prop_different :: Int -> Int -> Int -> Property
>> prop_different x y z = x /= y && y /= z && x /= z ==> not $ yourFn x y z
>>
>> That's probably OK for ints, but generally the guard in that style
>> isn't a great solution, since quickcheck will just keep generating
>> inputs until the predicate is satisfied.  That can take a while, so
>> you could also manually offset the first input in various ways:
>>
>> prop_different :: Int -> Int -> Bool
>> prop_different x y = not $ yourFn x (x + y) (x - (y + 1)) -- I put a
>> +1 in here to avoid returning true where y = 0,
>>
>> There are probably other ways to mutate a randomly generated input for
>> your problem that may work better, but that's the general idea.
>>
>> --Rogan
>>
>>> and second question :  hwo do the test likeif two numbers are the same.
>>>
>>> I ask this because I try to solve a exercise of the programming Haskell
>>> book,
>>> IM have read chapter 3 now.
>>>
>>> Roelof
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>> -----
>> Geen virus gevonden in dit bericht.
>> Gecontroleerd door AVG - www.avg.com
>> Versie: 2015.0.6140 / Virusdatabase: 4435/10768 - datum van uitgifte:
>> 10/06/15
>>
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

From jmct at jmct.cc  Tue Oct  6 22:56:47 2015
From: jmct at jmct.cc (=?UTF-8?Q?Jos=C3=A9_Manuel_Calder=C3=B3n_Trilla?=)
Date: Tue, 6 Oct 2015 15:56:47 -0700
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
Message-ID: <CAK+ijdvbxW50-Q3-Vk5PaKyrCrsu7qLVvUzZ3K0iCSFR7h900g@mail.gmail.com>

Hello all,

I agree with Henrik, I'm very keen on giving the new Haskell committee a
shot.

While some may not think that Haskell2010 was a success, I think it would
be difficult to argue that Haskell98 was anything but a resounding success
(even if you don't think the language was what it could have been!).
Haskell98 stabilized the constant changes of the proceeding 7 years. The
stability brought with it books and courses, and the agreed-upon base of
the language allowed _research_ to flourish as well. Having an agreed base
allowed the multiple implementations to experiment with different methods
of implementing what the standard laid out.

Many of us here learned from those texts or those courses. It's easy online
to say that materials being out of date isn't a big deal, but it can turn
people off the language when the code they paste into ghci doesn't work. We
use Haskell for the compilers course at York; Haskell is the means, not the
end, so having to update the materials frequently is a significant cost. It
can be difficult to defend the choice of using Haskell when so much time is
spent on something that 'isn't the point' of the course.

Does that mean that we should never change the language? Of course not, but
this constant flux within Haskell is very frustrating. Maybe Haskell2010
wasn't what everyone wanted it to be, but that does not mean the _idea_ of
a committee is without merit. Having controlled, periodic changes that are
grouped together and thought through as a coherent whole is a very useful
thing. One of the insights of the original committee was that there would
always be one chair at any point in time. The chair of the committee had
final say on any issue. This helped keep the revisions coherent and ensured
that Haskell made sense as a whole.

Lastly, I'd like to quote Prof. Runciman from almost exactly 22 years ago
when the issue of incompatible changes
came up. His thoughts were similar to Johan's:

On 1993-10-19 at 14:12:30 +0100, Colin Runciman wrote:

> As a practical suggestion, if any changes for version 1.3 could make
> some revision of a 1.2 programs necessary, let's have a precise
> stand-alone specification of these revisions and how to make them.
> It had better be short and simple.  Many would prefer it to be empty.
> Perhaps it should be implemented in Haskell compilers?


Overall I don't see the rush for these changes, let's try putting our faith
in a new Haskell committee, whomever it is comprised of.

Best wishes,

Jos? Manuel

P.S. A year ago Prof. Hinze sent me some Miranda code of his from 1995 as I
was studying his thesis. I was able to run the code without issue, allowing
me to be more productive in my research ;-)

On Tue, Oct 6, 2015 at 2:29 PM, Gregory Collins <greg at gregorycollins.net>
wrote:

>
> On Tue, Oct 6, 2015 at 1:39 PM, Tom Ellis <
> tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote:
>
>> In fact I think all of these apart from the FFI one could be solved with a
>> -compat package, could they not?
>>
>
> Who cares? In practice, the programs break and I have to fix them. Most of
> the time, CPP is the lowest-friction solution -- if I rely on a -compat
> package, first I have to know it exists and that I should use it to fix my
> compile error, and then I've added an additional non-platform dependency
> that I'm going to have to go back and clean up in 18 months. Usually, to be
> honest, *actually* the procedure is that the new RC comes out and I get
> github pull requests from hvr@ :-) :-)
>
> In response to the other person who asked "why do you want to support so
> many GHC versions anyways?" --- because I don't hate my users, and don't
> want to force them to run on the upgrade treadmill if they don't have to?
> Our policy is to support the last 4 major GHC versions (or 2 years,
> whichever is shorter). And if we support a version of GHC, I want our
> libraries to compile on it without warnings, I don't think that should
> mystify anyone.
>
> --
> Gregory Collins <greg at gregorycollins.net>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151006/52cc5d32/attachment.html>

From mwm at mired.org  Tue Oct  6 23:24:15 2015
From: mwm at mired.org (Mike Meyer)
Date: Tue, 06 Oct 2015 23:24:15 +0000
Subject: [Haskell-cafe] MRP, 3-year-support-window,
 and the non-requirement of CPP (was: Monad of no `return` Proposal
 (MRP): Moving `return` out of `Monad`)
In-Reply-To: <CAAOoiFauRYsFLa_4LfuRq=s7+LhoAqFwEBEEzcuYv2pdesgdCQ@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <CAK-tuPYxNM9uoywucSOT6O3RFhw2AGhCvBTKjOruKQK2V5dY3Q@mail.gmail.com>
 <CAAOoiFauRYsFLa_4LfuRq=s7+LhoAqFwEBEEzcuYv2pdesgdCQ@mail.gmail.com>
Message-ID: <CAD=7U2C0a9US=mSeko44ThXD2=xXqA5GqQgweF3wq3X98SYsYw@mail.gmail.com>

On Tue, Oct 6, 2015 at 4:15 PM Mark Lentczner <mark.lentczner at gmail.com>
wrote:

>
> On Thu, Sep 24, 2015 at 2:43 PM, Herbert Valerio Riedel <hvr at gnu.org>
>  wrote:
>
>> TLDR: To complete the AMP, turn `Monad(return)` method into a
>>       top-level binding aliasing `Applicative(pure)`.
>>
>
> Sure... if we had a language that no one uses and could keep reforming
> like putty until it is perfect. But we don't.
>
> A modest proposal:
>
> We can't keep tinkering with a language and it's libraries like this AND
> have a growing ecosystem that serves an ever widening base, including the
> range from newcomer to commercial deployment. SO - Why let's do all the
> language tinkering in GHC 8 there can be as many prereleases of that as
> needed until it is just right. ...and leave GHC 7 (7.10? roll back to
> 7.8.4?) for all of us doing essential and dependable libraries, commercial
> work, projects on Haskell that we don't want to have to go back and #ifdefs
> to twice a year just to keep running, educators, people writing books. We
> can keep improving GHC 7 as needed, and focus on bugs, security issues,
> patches, cross compatibility, etc.
>

I'm just curious how much you think this would help, assuming that your
solution would imply not upgrading to 8 until you're ready to. After all,
you can already simply not upgrade now, and create (and distribute) fixes
for bugs, security issues, cross-compatibility for 7 as you see fit.

While that's a popular thing to do in lots of systems (but if we don't it.
for gnus sake let's not adopt the inane parity implies stability numbering
convention), it leaves two major issues unaddressed.

#1, developer time. You need to get the people doing the work now to divide
their efforts into the two branches.I don't know what percentage of that
work is volunteer time, but I expect the answer is "most of it". If they
aren't interested doing that now, what do you expect to change their mind?

#2, everything else in the ecosystem. If you need updates to a library that
require the branch you're not using, where does that leave you?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151006/cf187cc3/attachment.html>

From gershomb at gmail.com  Wed Oct  7 01:18:03 2015
From: gershomb at gmail.com (Gershom B)
Date: Tue, 6 Oct 2015 21:18:03 -0400
Subject: [Haskell-cafe] MRP, 3-year-support-window,
 and the non-requirement of CPP
In-Reply-To: <87612k6j1v.fsf@gnu.org>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org>
Message-ID: <etPan.56147308.2268a666.7b73@mbp.local>

Dear all,

I think this discussion has gotten quite heated for reasons not related to the concrete MRP proposal, which, to be honest, I considered quite modest in terms of both scope and impact.

Instead, I think it is a proxy for lots of remaining frustration and anxiety over the poor handling over the Foldable Traversable Proposal. I would like to remind everyone that due to the broad discussions and concerns over the proposal, a very rare, careful poll of Haskell users was taken, announced broadly in many channels. [1] The poll, overwhelmingly, revealed a mandate for the FTP. The breakdown of that mandate was 87% in favor among hobbyists and 79% in favor among non-hobbyists (who constituted a majority of those polled).?

I. Generalities

That said, even the _best_ poll was not a substitute for a better earlier discussion. The handling of the AMP and FTP, which I think was heroic in terms of minimizing breakage while accomplishing long-desired change also still could have been better. As a whole, the work accomplished the mandate of allowing code to be written backwards-compatible without requiring CPP. However, it did not also seek to prevent warnings. This in itself was an enormous step forward from changes in the past which have _not_ even managed to prevent the need for CPP. At the time, I think it was not recognized how much desire there would be for things that were _both_ CPP free and _also_ warning-free for 3 releases.

I think one of the great elements of progress in the current discussion is that there is now a proposal on the table which recognizes this, and seeks to accomplish this change in accordance with this desire. It is not the world?s most important change, but the recognition that change should seek to be both CPP _and_ warning free is a good recognition, and I?m sure it will be taken into account in future proposals as well.

I don?t think it is useful to continue to have abstract discussions on the conflict between desire for incremental improvement versus the need to minimize pain on maintainers. We might as well continue to argue about the need for purely functional programming versus the need to print ?hello world? to the console. Rather, we should put our collective minds together as collaborators and colleagues to accomplish _both_, and to come up with solutions that should work for everyone. To the extent this discussion has been about that, I think it has been useful and positive. However, to the extent this discussion insists, on either side, on the shallow idea that we must treat ?improvement? versus ?stability? as irreconcilable factions in necessary conflict, then I fear it will be a missed opportunity.

II. Particulars

With that in mind, I think the _concrete_ voices of concern have been the most useful. Gregory Collins? list of issues requiring CPP should be very sobering. Of note, I think they point to areas where the core libraries committee has not paid _enough_ attention (or perhaps has not been sufficiently empowered: recall that not all core libraries fall under its maintenance [2]). Things like the newtype FFI issue, the changes to prim functions, the splitup of old-time and the changes to exception code were _not_ vetted as closely as the AMP and FTP were, or as the MRP is currently being. I don?t know all the reasons for this, but I suspect they just somewhat slipped under the radar. In any case, if all those changes were as carefully engineered as the MRP proposal has been, then imho things would have been much smoother. So, while this discussion may be frustrating, it nonetheless in some ways provides a model of how people have sought to do better and be more proactive with careful discussion of changes. This is much appreciated.

Personally, since the big switch to extensible exceptions back prior in 6.10, and since the split-base nonsense prior to that, very few changes to the core libraries have really caused too much disruption in my code. Since then, the old-time cleanup was the worst, and the big sin there was that time-locale-compat was only written some time after the fact by a helpful third-party contributor and not engineered from the start. (I will note that the time library is one of the core libraries that is _not_ maintained by the core libraries committee).?

Outside of that, the most disruptive changes to my code that I can recall have been from changes to the aeson library over the years ? particularly but not only regarding its handling of doubles. I don?t begrudge these changes ? they iteratively arrived at a _much_ better library than had they not been made. [3] After than, I made a few changes regarding Happstack and Snap API changes if I recall. Additionally, the addition of ?die? to System.Exit caused a few name clashes. My point is simply that there are many packages outside of base that also move, and ?real? users with ?real? code will these days often have quite a chain of dependencies, and will encounter movement and change from across many of them. So if we say ?base never changes? that does not mean ?packages will never break? ? it just means that base will not have the same opportunity to improve that other packages do, which will eventually lead to frustration, just as it did in the past and in the leadup to the BBP.

III. Discussions

Further, since there has been much discussion of a window of opportunity, I would like to offer a counterpoint to the (sound) advice that we take into consideration voices with long experience in Haskell. The window of opportunity is, by definition, regarding takeup of Haskell by new users. And so if newer users favor certain changes, then it is good evidence that those changes will help with uptake among other new users. So, if they are good changes on their own, then the fact that they are appealing to newer users should be seen as a point in their favor, rather than a reason to dismiss those opinions. But if we are in a situation where we see generations of adopters pitted against one another, then we already have deeper problems that need to be sorted out.

Regarding where and how to have these discussions ? the decision was made some time ago (I believe at the start of the initial Haskell Prime process if not sooner, so circa 2009?) that the prime committee would focus on language extensions and not library changes, and that those changes would be delegated to the libraries@ list. The lack of structure to the libraries@ list is what prompted the creation of the libraries committee, whose ultimately responsibility it is to decide on and shepherd through these changes, in consultation with others and ideally driven by broad consensus. Prior to this structure, things broke even more, imho, and simultaneously the things that were widely desired were still not implemented. So I thank the libraries committee for their good work so far.

So, it may be that the process of community discussion on core libraries changes is not best suited for the libraries@ list. But if not there, Where? I worry that the proliferation of lists will not improve things here. Those involved with Haskell have multiplied (this is good). The voices to take into account have multiplied (this is good). Necessarily, this means that there will just be _more_ stuff, and making sure that everyone can filter to just that part they want to is difficult. Here, perhaps, occasional libraries-related summary addenda to the ghc newsletter could be appropriate? Or is there another venue we should look towards???Chair?s reports? to the Haskell Weekly News maybe?

IV. Summing up

We should bear in mind after all that this is just about cleaning up a redundant typeclass method (albeit one in a very prominent place) and hardly the hill anyone would want to die on [4]. Nonetheless,?I think it would be?a good sign of progress and collaboration if we can find a way to implement a modest change like this in a way that everyone finds acceptable vis a vis a sufficiently slow pace, the lack of a need for CPP and the lack of any induced warnings. On the other hand, other opportunities will doubtless present themselves in the future.

Best,
Gershom

[1] https://mail.haskell.org/pipermail/libraries/2015-February/025009.html
[2]?https://wiki.haskell.org/Library_submissions#The_Core_Libraries
[3] and in any case I am sure Bryan would be the last to want us to treat him as some sort of ?guru? on these matters.?
[4] for those in search of better hills to die on, this is a list of some good ones: http://www.theawl.com/2015/07/hills-to-die-on-ranked?

P.S. In case there is any question, this email, as all emails I write that do not state otherwise, is not being written in any particular capacity regarding the various infra-related hats I wear, but is just an expression of my own personal views.



From mwm at mired.org  Wed Oct  7 02:24:58 2015
From: mwm at mired.org (Mike Meyer)
Date: Wed, 07 Oct 2015 02:24:58 +0000
Subject: [Haskell-cafe] Haskell ecosystem improvements meta-propsal
In-Reply-To: <etPan.56147308.2268a666.7b73@mbp.local>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org> <etPan.56147308.2268a666.7b73@mbp.local>
Message-ID: <CAD=7U2BASVF+cmnf+Ue=zXdZL26Od7n63wEL7jtZ7ZPAUgYW1A@mail.gmail.com>

There's been a lot of complaints about the way things have worked in the
past, with things going to fast, or to slow, or the right people not being
heard, or notices not going to the right places, etc.

As far as I can tell, the current process is that someone make a proposal
on some mailing list, that gets debated by those who find out about it,
maybe a wiki page gets set up and announced to those who already know about
the proposal, and then it either happens or not.

There's actually quite a bit of experience with dealing with such. I've
dealt with the IETF RFC process and the Python PEP process, and both of
them worked better than that. So I think we can do better.

I'd like to suggest we adapt something a bit more formal that any process
that changes a developer-visible API should have to go through. Note that
bug fixes, most security fixes, and other things that don't change the API
wouldn't be subject to this requirement. However, any change in an API,
even one that's 100% backward compatible, not possibly breaking any code,
would be. Initial thoughts on scope are anything in the Haskell Platform,
as that seems to be a minimal definition of "Haskell ecosystem". Further,
anything on hackage should be able to avail itself of the process.

My concrete, though very broad proposal, with lots of details to be filled
in yet, is that we need:

1) A wiki page that lists all proposals being considered, along with their
current status and other relevant information.

2) A set of requirements a proposal must meet in order to be listed on that
page.

3) An announcements list that only has announcements of things being added
to the list. Anybody who has time to vote on a proposal should have time to
be on this list.

4) An editorial group responsible for maintaining the list and providing
guidance on meeting the requirements to get on it.

The first three are easy. The fourth one is the killer. Somebody to do the
work is the stumbling block for most proposals. This doesn't require deep
technical knowledge of Haskell or the current ecosystem, but the ability to
implement a process and judge things based on form and not content, Since
it's my proposal, I'll volunteer as the first editor. Hopefully, others
with better reputation will alsob e available.

If adopted, the first two things on the list need to be a description of
the process, followed shortly by a description of the requirements to be
met.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151007/4a22263b/attachment.html>

From rasen.dubi at gmail.com  Wed Oct  7 04:28:26 2015
From: rasen.dubi at gmail.com (Alexey Shmalko)
Date: Wed, 7 Oct 2015 07:28:26 +0300
Subject: [Haskell-cafe] OShack hackathon (offer of help)
Message-ID: <CAFC2PC7+6iVXK1CQL8C60WCpeM50v_YAXCjt5g-MnfR-tk1RvA@mail.gmail.com>

Hi!

We have the OShack hackathon[1] in Kyiv, Ukraine this weekend. It's a
24-hour hackathon dedicated to Open-Source projects.

I with friends want to offer our help of time to any Haskell project
that needs it. Just ping me back so we can discuss the details.

If you're in Kyiv and want to join our team, we'll be glad to see you!
You can also join online.

Regards,
Alexey Shmalko

[1]: http://hackraft.com/hackathon/oshack/

From mark.lentczner at gmail.com  Wed Oct  7 06:36:39 2015
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Tue, 6 Oct 2015 23:36:39 -0700
Subject: [Haskell-cafe] MRP, 3-year-support-window,
 and the non-requirement of CPP (was: Monad of no `return` Proposal
 (MRP): Moving `return` out of `Monad`)
In-Reply-To: <CAD=7U2C0a9US=mSeko44ThXD2=xXqA5GqQgweF3wq3X98SYsYw@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <CAK-tuPYxNM9uoywucSOT6O3RFhw2AGhCvBTKjOruKQK2V5dY3Q@mail.gmail.com>
 <CAAOoiFauRYsFLa_4LfuRq=s7+LhoAqFwEBEEzcuYv2pdesgdCQ@mail.gmail.com>
 <CAD=7U2C0a9US=mSeko44ThXD2=xXqA5GqQgweF3wq3X98SYsYw@mail.gmail.com>
Message-ID: <CAAOoiFYUXaVJ5KX0nzGbzzS4ePDDhHK12X5bhC4zZNA+eUhM+w@mail.gmail.com>

Mike -

You might look up the phrase "A modest proposal".

... for gnus sake let's not adopt the inane parity implies stability
> numbering convention ...
>

6.10 .. 6.12 .. 7.0 .. 7.2 .. 7.4 .. 7.8 .. 7.10

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151006/f671a0f7/attachment.html>

From mark.lentczner at gmail.com  Wed Oct  7 06:45:15 2015
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Tue, 6 Oct 2015 23:45:15 -0700
Subject: [Haskell-cafe] Haskell ecosystem improvements meta-propsal
In-Reply-To: <CAD=7U2BASVF+cmnf+Ue=zXdZL26Od7n63wEL7jtZ7ZPAUgYW1A@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org> <etPan.56147308.2268a666.7b73@mbp.local>
 <CAD=7U2BASVF+cmnf+Ue=zXdZL26Od7n63wEL7jtZ7ZPAUgYW1A@mail.gmail.com>
Message-ID: <CAAOoiFYnmVWhB1Etq=7e67b2hshn396waAFXJn0x0thD7wcB6Q@mail.gmail.com>

On Tue, Oct 6, 2015 at 7:24 PM, Mike Meyer <mwm at mired.org> wrote:

> I've dealt with the IETF RFC process and the Python PEP process, and both
> of them worked better than that.


While both those are good examples of mostly working organizations
shepherding foundational technical standard(s) along... there is one thing
more important than their processes: Their stance. Both organizations have
a very strong engineering discipline of keeping deployed things working
without change. I don't think it is enough to simply model their process.

Until about three years ago, the Haskell community also had such a
discipline. It has been steadily eroding over the last few years.

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151006/92505822/attachment.html>

From r.wobben at home.nl  Wed Oct  7 07:13:00 2015
From: r.wobben at home.nl (Roelof Wobben)
Date: Wed, 7 Oct 2015 09:13:00 +0200
Subject: [Haskell-cafe] quickCheck problem
In-Reply-To: <CAHjep=xDr1QQCMB1AcirDDW9ZkPVpWX7LyAV8o2-AP5u5PhpOg@mail.gmail.com>
References: <56142DE3.30604@home.nl>
 <CAHjep=yn7JBfZzZRv9zQN2n0ZagzwtGPdP1gkhPUN2t9VS3MdQ@mail.gmail.com>
 <561436B8.8090804@home.nl>
 <CAHjep=xDr1QQCMB1AcirDDW9ZkPVpWX7LyAV8o2-AP5u5PhpOg@mail.gmail.com>
Message-ID: <5614C5FC.1020508@home.nl>

Maybe im on the wrong track now.

I know that if three numbers are the same then the outcome will be false.
The same if two numbers are the same.

Can I not do something like this :

prop_different x y z = not( (x /= y && y /= z && x /= z))

to test all cases at once.

Roelof



Op 7-10-2015 om 00:28 schreef Rogan Creswick:
> On Tue, Oct 6, 2015 at 2:01 PM, Roelof Wobben <r.wobben at home.nl> wrote:
>> but why this part :
>>
>> x (x + y) (x - (y + 1))
> That is buggy.  I was trying to quickly create three arguments that
> are guaranteed to be different by some random amount, but what I wrote
> doesn't always work (eg: if y = 0, then the first two arguments are
> the same, if y is -1, the first and 3rd are the same, if x is MAX_INT,
> then it may or may not be the same as other arguments, depending on Y,
> etc...)
>
> The predicate guard should work, though it may take longer to run.
>
> --Rogan
>
>>
>> Roelof
>>
>> Op 6-10-2015 om 22:31 schreef Rogan Creswick:
>>> On Tue, Oct 6, 2015 at 1:24 PM, Roelof Wobben <r.wobben at home.nl> wrote:
>>>> Hello,
>>>>
>>>> I have written a function to test if three numbers are the same.
>>>>
>>>> Now I want to test my functions by using quickCheck.
>>>>
>>>> So I thought to test first if all three are the same.
>>>>
>>>> but how can I tell quickcheck that all numbers are the same.
>>> Just have quickcheck generate one number, and use it for all three
>>> arguments, eg:
>>>
>>> prop_allSame :: Int -> Bool
>>> prop_allSame x = yourFn x x x
>>>
>>> then test the other cases:
>>>
>>> prop_different :: Int -> Int -> Int -> Property
>>> prop_different x y z = x /= y && y /= z && x /= z ==> not $ yourFn x y z
>>>
>>> That's probably OK for ints, but generally the guard in that style
>>> isn't a great solution, since quickcheck will just keep generating
>>> inputs until the predicate is satisfied.  That can take a while, so
>>> you could also manually offset the first input in various ways:
>>>
>>> prop_different :: Int -> Int -> Bool
>>> prop_different x y = not $ yourFn x (x + y) (x - (y + 1)) -- I put a
>>> +1 in here to avoid returning true where y = 0,
>>>
>>> There are probably other ways to mutate a randomly generated input for
>>> your problem that may work better, but that's the general idea.
>>>
>>> --Rogan
>>>
>>>> and second question :  hwo do the test likeif two numbers are the same.
>>>>
>>>> I ask this because I try to solve a exercise of the programming Haskell
>>>> book,
>>>> IM have read chapter 3 now.
>>>>
>>>> Roelof
>>>>
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> Haskell-Cafe at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>>> -----
>>> Geen virus gevonden in dit bericht.
>>> Gecontroleerd door AVG - www.avg.com
>>> Versie: 2015.0.6140 / Virusdatabase: 4435/10768 - datum van uitgifte:
>>> 10/06/15
>>>
>>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
> -----
> Geen virus gevonden in dit bericht.
> Gecontroleerd door AVG - www.avg.com
> Versie: 2015.0.6140 / Virusdatabase: 4435/10768 - datum van uitgifte: 10/06/15
>
>


From mwm at mired.org  Wed Oct  7 07:21:54 2015
From: mwm at mired.org (Mike Meyer)
Date: Wed, 07 Oct 2015 07:21:54 +0000
Subject: [Haskell-cafe] Haskell ecosystem improvements meta-propsal
In-Reply-To: <CAAOoiFYnmVWhB1Etq=7e67b2hshn396waAFXJn0x0thD7wcB6Q@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org> <etPan.56147308.2268a666.7b73@mbp.local>
 <CAD=7U2BASVF+cmnf+Ue=zXdZL26Od7n63wEL7jtZ7ZPAUgYW1A@mail.gmail.com>
 <CAAOoiFYnmVWhB1Etq=7e67b2hshn396waAFXJn0x0thD7wcB6Q@mail.gmail.com>
Message-ID: <CAD=7U2BFbDKzkrNdRXxKKeKyCmM1AGJdJyPm0p8Ymaa2n05N6Q@mail.gmail.com>

On Wed, Oct 7, 2015 at 1:45 AM Mark Lentczner <mark.lentczner at gmail.com>
wrote:

> On Tue, Oct 6, 2015 at 7:24 PM, Mike Meyer <mwm at mired.org> wrote:
>
>> I've dealt with the IETF RFC process and the Python PEP process, and both
>> of them worked better than that.
>
>
> While both those are good examples of mostly working organizations
> shepherding foundational technical standard(s) along... there is one thing
> more important than their processes: Their stance. Both organizations have
> a very strong engineering discipline of keeping deployed things working
> without change. I don't think it is enough to simply model their process.
>

Well, until Python 3, anyway.

My goal wasn't to recreate the engineering discipline that deployed things
keep working without change as you upgrade the ecosystem, it's to provide a
mechanism so the community can more easily engage with the evolution of the
ecosystem. Hopefully this will make it easier for the community to move
things forward in a desirable manner. But it's a process, and leaves the
question of whether the desire is for more stability or a less stagnant
language up to the users of the process.

I don't necessarily want to model the IETF or PEP processes. Those are a
starting point. I tried to abstract the initial points out enough that the
final result could be either one of them, or something totally unrelated
that's a better fit for the Haskell community.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151007/757437bd/attachment.html>

From hvr at gnu.org  Wed Oct  7 07:35:21 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Wed, 07 Oct 2015 09:35:21 +0200
Subject: [Haskell-cafe] MRP, 3-year-support-window,
	and the non-requirement of CPP
In-Reply-To: <CANBN=mu_un8bJR3eCSMmpoXpL3_Mu-wsgdnZ+ZOiUGP-j4RWmw@mail.gmail.com>
 (Sven Panne's message of "Tue, 6 Oct 2015 19:41:51 +0200")
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org>
 <CANBN=mu_un8bJR3eCSMmpoXpL3_Mu-wsgdnZ+ZOiUGP-j4RWmw@mail.gmail.com>
Message-ID: <87lhbfm8qu.fsf@gnu.org>

On 2015-10-06 at 19:41:51 +0200, Sven Panne wrote:
> 2015-10-06 18:47 GMT+02:00 Herbert Valerio Riedel <hvr at gnu.org>:
>
>> [...] That being said, as how to write your Monad instances today with GHC
>> 7.10 w/o CPP, while supporting at least GHC 7.4/7.6/7.8/7.10: This
>> *does* work (admittedly for an easy example, but this can be
>> generalised):
>>
>>
>> --8<---------------cut here---------------start------------->8---
>> module MyMaybe where
>>
>> import Control.Applicative (Applicative(..))
>> import Prelude (Functor(..), Monad(..), (.))
>> -- or alternatively: `import qualified Prelude as P`
>> [...]
>> --8<---------------cut here---------------end--------------->8---
>>
>> This example above compiles -Wall-clean and satisfies all your 3 stated
>> requirements afaics. I do admit this probably not what you had in mind.
>>
>
> OK, so the trick is that you're effectively hiding Applicative from the
> Prelude (which might be a no-op). This "works" somehow, but is not
> satisfactory IMHO for several reasons:

[...]

Btw, I've also seen the trick below, in which you use the aliased `A.`
prefix just once so GHC considers the import non-redundant, and don't
have to suffer from prefixed operators in the style of `A.<*>`.

Is this any better?

--8<---------------cut here---------------start------------->8---
import Control.Applicative as A (Applicative(..))

data Maybe' a = Nothing' | Just' a

instance Functor Maybe' where
    fmap f (Just' v) = Just' (f v)
    fmap _ Nothing'  = Nothing'

instance A.Applicative Maybe' where
    pure = Just'
    f1 <*> f2   = f1 >>= \v1 -> f2 >>= (pure . v1)

instance Monad Maybe' where
    Nothing' >>= _  = Nothing'
    Just' x  >>= f  = f x

    return = pure -- "deprecated" since GHC 7.10
--8<---------------cut here---------------end--------------->8---

-- hvr  

From svenpanne at gmail.com  Wed Oct  7 08:07:38 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Wed, 7 Oct 2015 10:07:38 +0200
Subject: [Haskell-cafe] MRP, 3-year-support-window,
 and the non-requirement of CPP
In-Reply-To: <87lhbfm8qu.fsf@gnu.org>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org>
 <CANBN=mu_un8bJR3eCSMmpoXpL3_Mu-wsgdnZ+ZOiUGP-j4RWmw@mail.gmail.com>
 <87lhbfm8qu.fsf@gnu.org>
Message-ID: <CANBN=msSgkP0eS9bim9A9B10kHyMm2=100Y1TsbmbfGpYy1LXA@mail.gmail.com>

2015-10-07 9:35 GMT+02:00 Herbert Valerio Riedel <hvr at gnu.org>:

> Btw, I've also seen the trick below, in which you use the aliased `A.`
> prefix just once so GHC considers the import non-redundant, and don't
> have to suffer from prefixed operators in the style of `A.<*>`.
>
> Is this any better? [...]
>

While not perfect, it's much better than having to fiddle around with
Prelude imports. Although there's the slight danger that somebody else (or
the author 1 year later) looks at the code and has a WTF-moment... ;-) To
be honest, while it's somehow obvious how it works when you read it, I've
never seen that trick. Perhaps stuff like this belongs into some general
"Porting Guide", along with its alternatives. It's general enough that it
should not be buried in some AMP/FTP/return/... transitioning guide.

Cheers,
   S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151007/e669b6a2/attachment.html>

From simonpj at microsoft.com  Wed Oct  7 15:36:41 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 7 Oct 2015 15:36:41 +0000
Subject: [Haskell-cafe] MRP, 3-year-support-window,
 and the non-requirement of CPP (was: Monad of no `return` Proposal
 (MRP): Moving `return` out of `Monad`)
In-Reply-To: <CAD=7U2C0a9US=mSeko44ThXD2=xXqA5GqQgweF3wq3X98SYsYw@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <CAK-tuPYxNM9uoywucSOT6O3RFhw2AGhCvBTKjOruKQK2V5dY3Q@mail.gmail.com>
 <CAAOoiFauRYsFLa_4LfuRq=s7+LhoAqFwEBEEzcuYv2pdesgdCQ@mail.gmail.com>
 <CAD=7U2C0a9US=mSeko44ThXD2=xXqA5GqQgweF3wq3X98SYsYw@mail.gmail.com>
Message-ID: <3d672fd5db1546b189f16d2a890a953d@DB4PR30MB030.064d.mgd.msft.net>

I think there are several different conversations going on at once in this thread.  I think it?s worth keeping them separate.


?         Haskell Prime.  The intention there is to take a set of language features that are already in wide use in GHC (i.e. have demonstrably proved valuable), work out any dark corners, formalise them, and embody the result in a new Haskell Report.   That puts a useful stake in the ground, empowers alternative implementations of Haskell, gives confidence all round.

I think it?d be unusual for the Haskell Prime committee to specify a new feature of the language, one that had not been field tested.


?         Libraries.  AMP, BBP, and Monad(return) are small but fundamental changes to the core libraries.  I think there was a consensus (not universal in the case of BBP) that the change was good.  Yet AMP and BBP (esp) were controversial.  The issues were mostly around how to make the transition; and, given that the transition is expensive, whether the cost/benefit tradeoff justifies the change.  The question of moving ?return? out of Monad is in this category.


The Core Libraries Committee was formed explicitly to handle this stuff. So my prior assumption was that the CLC would handle the Monad(return) question, not Haskell Prime.



Mark?s suggestion of a ?stable? GHC 7.10 and a new GHC 8.0 is a reasonable one. But I for one would find it hard to promise to back-port every bug fix, especially as the two code bases diverge (which they will).



Here is another idea.  GHC knows very little about Monad.  It would take work, but it probably wouldn?t be impossible to make the same GHC work with two different ?base? libraries, each with a different definitions of the Monad class.  That would not solve the problem: you still could not use one library that used old Monad with another library that used new Monad.   But at least it?d decouple it from which version of GHC you were using.  I stress: it would take some work to make this go, and I?d prefer not to do this.

Returning to ?return?, my instinct is that when these pervasive breaking library changes come up, we should batch them into larger clumps.  The ?treadmill? complaint is real: small change A made me re-release my library; then small change B came along; and so on.  Perhaps if we saved them up this would be less of an issue, for two reasons.  First, the work happens once rather than many times.  Second, the benefits of the change is the sum of the benefits of the little component changes, and so is more attractive to library authors and library clients.

That line of thinking would suggest that the Core Libraries Committee might want to maintain a list of well-worked out agreed changes that are being ?saved up? for execution at some later date.

Simon



From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Mike Meyer
Sent: 07 October 2015 00:24
To: Mark Lentczner; Johan Tibell
Cc: Haskell Libraries; haskell cafe; haskell-prime at haskell.org List
Subject: Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

On Tue, Oct 6, 2015 at 4:15 PM Mark Lentczner <mark.lentczner at gmail.com<mailto:mark.lentczner at gmail.com>> wrote:

On Thu, Sep 24, 2015 at 2:43 PM, Herbert Valerio Riedel <hvr at gnu.org<mailto:hvr at gnu.org>> wrote:
TLDR: To complete the AMP, turn `Monad(return)` method into a
      top-level binding aliasing `Applicative(pure)`.

Sure... if we had a language that no one uses and could keep reforming like putty until it is perfect. But we don't.

A modest proposal:

We can't keep tinkering with a language and it's libraries like this AND have a growing ecosystem that serves an ever widening base, including the range from newcomer to commercial deployment. SO - Why let's do all the language tinkering in GHC 8 there can be as many prereleases of that as needed until it is just right. ...and leave GHC 7 (7.10? roll back to 7.8.4?) for all of us doing essential and dependable libraries, commercial work, projects on Haskell that we don't want to have to go back and #ifdefs to twice a year just to keep running, educators, people writing books. We can keep improving GHC 7 as needed, and focus on bugs, security issues, patches, cross compatibility, etc.

I'm just curious how much you think this would help, assuming that your solution would imply not upgrading to 8 until you're ready to. After all, you can already simply not upgrade now, and create (and distribute) fixes for bugs, security issues, cross-compatibility for 7 as you see fit.

While that's a popular thing to do in lots of systems (but if we don't it. for gnus sake let's not adopt the inane parity implies stability numbering convention), it leaves two major issues unaddressed.

#1, developer time. You need to get the people doing the work now to divide their efforts into the two branches.I don't know what percentage of that work is volunteer time, but I expect the answer is "most of it". If they aren't interested doing that now, what do you expect to change their mind?

#2, everything else in the ecosystem. If you need updates to a library that require the branch you're not using, where does that leave you?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151007/ea94d6a7/attachment.html>

From johan.tibell at gmail.com  Wed Oct  7 16:04:11 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Wed, 7 Oct 2015 18:04:11 +0200
Subject: [Haskell-cafe] Looking for a new maintainer for the network package
Message-ID: <CAK-tuPY1r2QpZ3aU8jjA4hZWuw0X_UW0Srh9m4EBCY9eTFA_tA@mail.gmail.com>

I find myself with too little time to maintain the network package anymore,
so I'm hereby announcing that I'm looking for a new maintainer.

Since lots of people depend on the network package, the maintainer should
probably be someone that values stability. If you want to completely
rethink how networking APIs should work in Haskell, this is probably not
for you.

Please email me if you're interested.

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151007/320dbae7/attachment.html>

From johan.tibell at gmail.com  Wed Oct  7 16:05:03 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Wed, 7 Oct 2015 18:05:03 +0200
Subject: [Haskell-cafe] Looking for a new maintainer for the template package
Message-ID: <CAK-tuPYd6yzK0oeoKxX93nAoJuhA1JO-nAtVepAodVhd9Gu1vg@mail.gmail.com>

I find myself with too little time to maintain the template package
anymore, so I'm hereby announcing that I'm looking for a new maintainer.

The template package is a quaint little package for doing Python-style
string interpolation.

Please email me if you're interested.

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151007/1360f16c/attachment.html>

From greg at gregorycollins.net  Wed Oct  7 16:09:06 2015
From: greg at gregorycollins.net (Gregory Collins)
Date: Wed, 7 Oct 2015 09:09:06 -0700
Subject: [Haskell-cafe] MRP, 3-year-support-window,
 and the non-requirement of CPP
In-Reply-To: <etPan.56147308.2268a666.7b73@mbp.local>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org> <etPan.56147308.2268a666.7b73@mbp.local>
Message-ID: <CAHZrzdpig8R=W5T4SBRYwqCD_3W+wquYajOr-9qqcEd4f8gf1w@mail.gmail.com>

On Tue, Oct 6, 2015 at 6:18 PM, Gershom B <gershomb at gmail.com> wrote:


>
> With that in mind, I think the _concrete_ voices of concern have been the
> most useful. Gregory Collins? list of issues requiring CPP should be very
> sobering. Of note, I think they point to areas where the core libraries
> committee has not paid _enough_ attention (or perhaps has not been
> sufficiently empowered: recall that not all core libraries fall under its
> maintenance [2]). Things like the newtype FFI issue, the changes to prim
> functions, the splitup of old-time and the changes to exception code were
> _not_ vetted as closely as the AMP and FTP were, or as the MRP is currently
> being. I don?t know all the reasons for this, but I suspect they just
> somewhat slipped under the radar.


In fact, more often than I would like, I can recall arguing against a
particular change
<https://www.mail-archive.com/ghc-devs at haskell.org/msg02133.html> on the
grounds that it would break user code, and in Haskell land this is a battle
I usually lose. Usually the argument on the other side boils down to
expediency or hygiene/aesthetics -- it's *difficult* to engineer a change
to some core infra in a way that minimizes impact on people downstream, and
it takes a long time. Often "this change is going to cause a small amount
of work for all of my users" is something that seems to not be taken into
consideration at all.

For this particular proposal, every user will have some small amount of
work *w* to do (to read the change notes, understand why 'return' is going
away, train yourself to use "pure" now instead of "return" like you've been
using for 15 years, etc). It might feel like *w* is small and so the change
isn't burdensome, but *n* is literally everyone who uses the language, so
the total work *w***n* is going to amount to quite a few person-hours. I
just want to make sure that everyone is keeping that in mind and weighing
that effort against the benefits.

Outside of that, the most disruptive changes to my code that I can recall
> have been from changes to the aeson library over the years ? particularly
> but not only regarding its handling of doubles. I don?t begrudge these
> changes ? they iteratively arrived at a _much_ better library than had they
> not been made. [3] After than, I made a few changes regarding Happstack and
> Snap API changes if I recall. Additionally, the addition of ?die? to
> System.Exit caused a few name clashes. My point is simply that there are
> many packages outside of base that also move, and ?real? users with ?real?
> code will these days often have quite a chain of dependencies, and will
> encounter movement and change from across many of them. So if we say ?base
> never changes? that does not mean ?packages will never break? ? it just
> means that base will not have the same opportunity to improve that other
> packages do, which will eventually lead to frustration, just as it did in
> the past and in the leadup to the BBP.
>

Culturally, we have a problem with library authors of all stripes being too
cavalier about breaking user programs: we definitely lean towards "move
fast and break things" vs "stay stable and don't make work for users". As
you write more and more Haskell code, you depend on more and more of these
libraries, and this means that once you go beyond a certain threshold you
will be spending a significant amount of your time just running to keep up
with the treadmill. Personally I just don't have enough time for writing
Haskell code as I used to (or I would like), so I would say for me that the
treadmill tax is now probably exceeding 50% of my total hours invested.

Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151007/9f1c0f7c/attachment.html>

From b at chreekat.net  Wed Oct  7 16:15:58 2015
From: b at chreekat.net (Bryan Richter)
Date: Wed, 7 Oct 2015 09:15:58 -0700
Subject: [Haskell-cafe] quickCheck problem
In-Reply-To: <56142DE3.30604@home.nl>
References: <56142DE3.30604@home.nl>
Message-ID: <20151007161558.GA15337@fuzzbomb>

On Tue, Oct 06, 2015 at 10:24:03PM +0200, Roelof Wobben wrote:
> Hello,
> 
> I have written a function to test if three numbers are the same.
> 
> Now I want to test my functions by using quickCheck.
> 
> So I thought to test first if all three are the same.
> 
> but how can I tell quickcheck that all numbers are the same.

Easy, just generate a single number. :) Make it correct by
construction.

    prop_allSame x =
        yourFunc x x x == True

> and second question :  hwo do the test likeif two numbers are the same.

Now the hard part is not generating two numbers that are the same, but
generating two *different* numbers. To do that you may need to create
a custom generator.

unequalPair = do
    x <- arbitrary
    y <- arbitrary `suchThat` y /= x
    return (x,y)

Now you can use that generator:

prop_twoSame = forAll unequalPair $ \(x,y) ->
    yourFunc x x y == False
    -- But you might want to test all permutations!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151007/0ba32941/attachment.sig>

From creswick at gmail.com  Wed Oct  7 16:32:02 2015
From: creswick at gmail.com (Rogan Creswick)
Date: Wed, 7 Oct 2015 09:32:02 -0700
Subject: [Haskell-cafe] quickCheck problem
In-Reply-To: <5614C5FC.1020508@home.nl>
References: <56142DE3.30604@home.nl>
 <CAHjep=yn7JBfZzZRv9zQN2n0ZagzwtGPdP1gkhPUN2t9VS3MdQ@mail.gmail.com>
 <561436B8.8090804@home.nl>
 <CAHjep=xDr1QQCMB1AcirDDW9ZkPVpWX7LyAV8o2-AP5u5PhpOg@mail.gmail.com>
 <5614C5FC.1020508@home.nl>
Message-ID: <CAHjep=xLp279pF9S6rbyt3hVfiWU4zx50smCOCNdsh_m0NeJ1Q@mail.gmail.com>

On Wed, Oct 7, 2015 at 12:13 AM, Roelof Wobben <r.wobben at home.nl> wrote:
> I know that if three numbers are the same then the outcome will be false.
> The same if two numbers are the same.
>
> Can I not do something like this :
>
> prop_different x y z = not( (x /= y && y /= z && x /= z))
>
> to test all cases at once.

That looks like it will work (I'm assuming you're actually calling
your function in the property and comparing with that boolean
expression); is that the same way your function is implemented?

--Rogan

>
> Roelof
>
>
>
> Op 7-10-2015 om 00:28 schreef Rogan Creswick:
>
>> On Tue, Oct 6, 2015 at 2:01 PM, Roelof Wobben <r.wobben at home.nl> wrote:
>>>
>>> but why this part :
>>>
>>> x (x + y) (x - (y + 1))
>>
>> That is buggy.  I was trying to quickly create three arguments that
>> are guaranteed to be different by some random amount, but what I wrote
>> doesn't always work (eg: if y = 0, then the first two arguments are
>> the same, if y is -1, the first and 3rd are the same, if x is MAX_INT,
>> then it may or may not be the same as other arguments, depending on Y,
>> etc...)
>>
>> The predicate guard should work, though it may take longer to run.
>>
>> --Rogan
>>
>>>
>>> Roelof
>>>
>>> Op 6-10-2015 om 22:31 schreef Rogan Creswick:
>>>>
>>>> On Tue, Oct 6, 2015 at 1:24 PM, Roelof Wobben <r.wobben at home.nl> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> I have written a function to test if three numbers are the same.
>>>>>
>>>>> Now I want to test my functions by using quickCheck.
>>>>>
>>>>> So I thought to test first if all three are the same.
>>>>>
>>>>> but how can I tell quickcheck that all numbers are the same.
>>>>
>>>> Just have quickcheck generate one number, and use it for all three
>>>> arguments, eg:
>>>>
>>>> prop_allSame :: Int -> Bool
>>>> prop_allSame x = yourFn x x x
>>>>
>>>> then test the other cases:
>>>>
>>>> prop_different :: Int -> Int -> Int -> Property
>>>> prop_different x y z = x /= y && y /= z && x /= z ==> not $ yourFn x y z
>>>>
>>>> That's probably OK for ints, but generally the guard in that style
>>>> isn't a great solution, since quickcheck will just keep generating
>>>> inputs until the predicate is satisfied.  That can take a while, so
>>>> you could also manually offset the first input in various ways:
>>>>
>>>> prop_different :: Int -> Int -> Bool
>>>> prop_different x y = not $ yourFn x (x + y) (x - (y + 1)) -- I put a
>>>> +1 in here to avoid returning true where y = 0,
>>>>
>>>> There are probably other ways to mutate a randomly generated input for
>>>> your problem that may work better, but that's the general idea.
>>>>
>>>> --Rogan
>>>>
>>>>> and second question :  hwo do the test likeif two numbers are the same.
>>>>>
>>>>> I ask this because I try to solve a exercise of the programming Haskell
>>>>> book,
>>>>> IM have read chapter 3 now.
>>>>>
>>>>> Roelof
>>>>>
>>>>> _______________________________________________
>>>>> Haskell-Cafe mailing list
>>>>> Haskell-Cafe at haskell.org
>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>>
>>>>
>>>> -----
>>>> Geen virus gevonden in dit bericht.
>>>> Gecontroleerd door AVG - www.avg.com
>>>> Versie: 2015.0.6140 / Virusdatabase: 4435/10768 - datum van uitgifte:
>>>> 10/06/15
>>>>
>>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>> -----
>> Geen virus gevonden in dit bericht.
>> Gecontroleerd door AVG - www.avg.com
>> Versie: 2015.0.6140 / Virusdatabase: 4435/10768 - datum van uitgifte:
>> 10/06/15
>>
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

From hesselink at gmail.com  Wed Oct  7 16:38:01 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Wed, 7 Oct 2015 18:38:01 +0200
Subject: [Haskell-cafe] MRP, 3-year-support-window,
 and the non-requirement of CPP
In-Reply-To: <CAHZrzdpig8R=W5T4SBRYwqCD_3W+wquYajOr-9qqcEd4f8gf1w@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org> <etPan.56147308.2268a666.7b73@mbp.local>
 <CAHZrzdpig8R=W5T4SBRYwqCD_3W+wquYajOr-9qqcEd4f8gf1w@mail.gmail.com>
Message-ID: <CAPeieQG0-6AmNGEZLBg_Lqh5VJKwTtPFC3=iGV42ciJ=zO5xpg@mail.gmail.com>

On 7 October 2015 at 18:09, Gregory Collins <greg at gregorycollins.net> wrote:
> For this particular proposal, every user will have some small amount of work
> w to do (to read the change notes, understand why 'return' is going away,
> train yourself to use "pure" now instead of "return" like you've been using
> for 15 years, etc).

While I don't think it detracts from your argument, it seems you
misread the original proposal. At no point will it remove `return`
completely. It would be moved out of the `Monad` class and be made
into a top-level definition instead, so you would still be able to use
it.

Erik

From r.wobben at home.nl  Wed Oct  7 17:01:15 2015
From: r.wobben at home.nl (Roelof Wobben)
Date: Wed, 7 Oct 2015 19:01:15 +0200
Subject: [Haskell-cafe] quickCheck problem
In-Reply-To: <CAHjep=xLp279pF9S6rbyt3hVfiWU4zx50smCOCNdsh_m0NeJ1Q@mail.gmail.com>
References: <56142DE3.30604@home.nl>
 <CAHjep=yn7JBfZzZRv9zQN2n0ZagzwtGPdP1gkhPUN2t9VS3MdQ@mail.gmail.com>
 <561436B8.8090804@home.nl>
 <CAHjep=xDr1QQCMB1AcirDDW9ZkPVpWX7LyAV8o2-AP5u5PhpOg@mail.gmail.com>
 <5614C5FC.1020508@home.nl>
 <CAHjep=xLp279pF9S6rbyt3hVfiWU4zx50smCOCNdsh_m0NeJ1Q@mail.gmail.com>
Message-ID: <56154FDB.3040503@home.nl>

Op 7-10-2015 om 18:32 schreef Rogan Creswick:
> On Wed, Oct 7, 2015 at 12:13 AM, Roelof Wobben <r.wobben at home.nl> wrote:
>> I know that if three numbers are the same then the outcome will be false.
>> The same if two numbers are the same.
>>
>> Can I not do something like this :
>>
>> prop_different x y z = not( (x /= y && y /= z && x /= z))
>>
>> to test all cases at once.
> That looks like it will work (I'm assuming you're actually calling
> your function in the property and comparing with that boolean
> expression); is that the same way your function is implemented?
>
> --Rogan
>

Unfortanally yes but I do not know another way to test it.
Im only a beginner which has read 2 chapters of the Crafts book.

Roelof


From rasen.dubi at gmail.com  Wed Oct  7 17:13:55 2015
From: rasen.dubi at gmail.com (Alexey Shmalko)
Date: Wed, 7 Oct 2015 20:13:55 +0300
Subject: [Haskell-cafe] Looking for a new maintainer for the template
	package
In-Reply-To: <CAK-tuPYd6yzK0oeoKxX93nAoJuhA1JO-nAtVepAodVhd9Gu1vg@mail.gmail.com>
References: <CAK-tuPYd6yzK0oeoKxX93nAoJuhA1JO-nAtVepAodVhd9Gu1vg@mail.gmail.com>
Message-ID: <CAFC2PC5AcJWjonm5rYr5UyiwiZ6if=at8iqVU5y5Ww3+8Ew8+g@mail.gmail.com>

Hi, Johan!

I would like to maintain the template package. It seems small enough,
so I can easily handle it.

Regards,
Alexey

On Wed, Oct 7, 2015 at 7:05 PM, Johan Tibell <johan.tibell at gmail.com> wrote:
> I find myself with too little time to maintain the template package anymore,
> so I'm hereby announcing that I'm looking for a new maintainer.
>
> The template package is a quaint little package for doing Python-style
> string interpolation.
>
> Please email me if you're interested.
>
> -- Johan
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>

From michael at orlitzky.com  Wed Oct  7 17:34:21 2015
From: michael at orlitzky.com (Michael Orlitzky)
Date: Wed, 7 Oct 2015 13:34:21 -0400
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
Message-ID: <5615579D.5040900@orlitzky.com>

(replying to no one in particular)

This problem isn't specific to Haskell. In every other language, you
have projects that support major versions of toolkits, compilers,
libraries and whatnot. And there's already a tool for it: git.

Instead of using #ifdef to handle four different compilers, keep a
branch for each. Git is designed to make this easy, and it's usually
trivial to merge changes from the master branch back into e.g. the
ghc-7.8 branch. That way the code in your master branch stays clean.
When you want to stop supporting an old GHC, delete that branch.


From fa-ml at ariis.it  Wed Oct  7 17:48:13 2015
From: fa-ml at ariis.it (Francesco Ariis)
Date: Wed, 7 Oct 2015 19:48:13 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <5615579D.5040900@orlitzky.com>
References: <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com>
Message-ID: <20151007174812.GA14335@casa.casa>

On Wed, Oct 07, 2015 at 01:34:21PM -0400, Michael Orlitzky wrote:
> Instead of using #ifdef to handle four different compilers, keep a
> branch for each. Git is designed to make this easy, and it's usually
> trivial to merge changes from the master branch back into e.g. the
> ghc-7.8 branch. That way the code in your master branch stays clean.
> When you want to stop supporting an old GHC, delete that branch.

I suspect `cabal install your-library` without CPP would explode in
the face of (some of) your users though.

From taruti at taruti.net  Wed Oct  7 18:02:39 2015
From: taruti at taruti.net (Taru Karttunen)
Date: Wed, 7 Oct 2015 21:02:39 +0300
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <5615579D.5040900@orlitzky.com>
References: <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com>
Message-ID: <9CEC20CB3BDE0224EDFFAD9B171DC0@mail.local>

On 07.10 13:34, Michael Orlitzky wrote:
> (replying to no one in particular)
> 
> This problem isn't specific to Haskell. In every other language, you
> have projects that support major versions of toolkits, compilers,
> libraries and whatnot. And there's already a tool for it: git.
> 
> Instead of using #ifdef to handle four different compilers, keep a
> branch for each. Git is designed to make this easy, and it's usually
> trivial to merge changes from the master branch back into e.g. the
> ghc-7.8 branch. That way the code in your master branch stays clean.
> When you want to stop supporting an old GHC, delete that branch.

Isn't this hard to do correctly for libraries with Hackage 
and Cabal and narrowly versioned dependencies and deep
import graphs?

E.g. when adding a new feature to the library and merging
it back to the ghc-7.8 branch the versions needed for
features vs compiler support could end up causing
complex dependency clauses for users of such libraries.

- Taru Karttunen

From michael at orlitzky.com  Wed Oct  7 18:06:28 2015
From: michael at orlitzky.com (Michael Orlitzky)
Date: Wed, 7 Oct 2015 14:06:28 -0400
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <20151007174812.GA14335@casa.casa>
References: <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <20151007174812.GA14335@casa.casa>
Message-ID: <56155F24.9030207@orlitzky.com>

On 10/07/2015 01:48 PM, Francesco Ariis wrote:
> On Wed, Oct 07, 2015 at 01:34:21PM -0400, Michael Orlitzky wrote:
>> Instead of using #ifdef to handle four different compilers, keep a
>> branch for each. Git is designed to make this easy, and it's usually
>> trivial to merge changes from the master branch back into e.g. the
>> ghc-7.8 branch. That way the code in your master branch stays clean.
>> When you want to stop supporting an old GHC, delete that branch.
> 
> I suspect `cabal install your-library` without CPP would explode in
> the face of (some of) your users though.

The different branches would have different cabal files saying with
which version of GHC they work. If the user has ghc-7.8 installed, then
cabal-install (or at least, any decent package manager) should pick the
latest version supporting ghc-7.8 to install.


From michael at orlitzky.com  Wed Oct  7 18:12:49 2015
From: michael at orlitzky.com (Michael Orlitzky)
Date: Wed, 7 Oct 2015 14:12:49 -0400
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <9CEC20CB3BDE0224EDFFAD9B171DC0@mail.local>
References: <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <9CEC20CB3BDE0224EDFFAD9B171DC0@mail.local>
Message-ID: <561560A1.1020100@orlitzky.com>

On 10/07/2015 02:02 PM, Taru Karttunen wrote:
>>
>> Instead of using #ifdef to handle four different compilers, keep a
>> branch for each. Git is designed to make this easy, and it's usually
>> trivial to merge changes from the master branch back into e.g. the
>> ghc-7.8 branch. That way the code in your master branch stays clean.
>> When you want to stop supporting an old GHC, delete that branch.
> 
> Isn't this hard to do correctly for libraries with Hackage 
> and Cabal and narrowly versioned dependencies and deep
> import graphs?

It can be...

> E.g. when adding a new feature to the library and merging
> it back to the ghc-7.8 branch the versions needed for
> features vs compiler support could end up causing
> complex dependency clauses for users of such libraries.
> 

but can you think of an example where you don't have the same problem
with #ifdef?

If I need to use a new version of libfoo and the new libfoo only
supports ghc-7.10, then I'm screwed either way right?


From creswick at gmail.com  Wed Oct  7 18:25:16 2015
From: creswick at gmail.com (Rogan Creswick)
Date: Wed, 7 Oct 2015 11:25:16 -0700
Subject: [Haskell-cafe] quickCheck problem
In-Reply-To: <56154FDB.3040503@home.nl>
References: <56142DE3.30604@home.nl>
 <CAHjep=yn7JBfZzZRv9zQN2n0ZagzwtGPdP1gkhPUN2t9VS3MdQ@mail.gmail.com>
 <561436B8.8090804@home.nl>
 <CAHjep=xDr1QQCMB1AcirDDW9ZkPVpWX7LyAV8o2-AP5u5PhpOg@mail.gmail.com>
 <5614C5FC.1020508@home.nl>
 <CAHjep=xLp279pF9S6rbyt3hVfiWU4zx50smCOCNdsh_m0NeJ1Q@mail.gmail.com>
 <56154FDB.3040503@home.nl>
Message-ID: <CAHjep=w5dZfK8YRy_2=GHCWUotJwiy84Lubmy9jYsmZFqC3e-w@mail.gmail.com>

On Wed, Oct 7, 2015 at 10:01 AM, Roelof Wobben <r.wobben at home.nl> wrote:
> Op 7-10-2015 om 18:32 schreef Rogan Creswick:
>>
>> On Wed, Oct 7, 2015 at 12:13 AM, Roelof Wobben <r.wobben at home.nl> wrote:
>>>
>>> I know that if three numbers are the same then the outcome will be false.
>>> The same if two numbers are the same.
>>>
>>> Can I not do something like this :
>>>
>>> prop_different x y z = not( (x /= y && y /= z && x /= z))
>>>
>>> to test all cases at once.
>>
>> That looks like it will work (I'm assuming you're actually calling
>> your function in the property and comparing with that boolean
>> expression); is that the same way your function is implemented?
>>
>> --Rogan
>>
>
> Unfortanally yes but I do not know another way to test it.
> Im only a beginner which has read 2 chapters of the Crafts book.

Then I'd suggest using the quickcheck property guards ( `==>`) to only
generate inputs that are known to be equal, or not equal and test
separately in a few different properties.

--Rogan

>
>
> Roelof
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

From ozgurakgun at gmail.com  Wed Oct  7 18:33:32 2015
From: ozgurakgun at gmail.com (Ozgur Akgun)
Date: Wed, 7 Oct 2015 19:33:32 +0100
Subject: [Haskell-cafe] quickCheck problem
In-Reply-To: <CAHjep=w5dZfK8YRy_2=GHCWUotJwiy84Lubmy9jYsmZFqC3e-w@mail.gmail.com>
References: <56142DE3.30604@home.nl>
 <CAHjep=yn7JBfZzZRv9zQN2n0ZagzwtGPdP1gkhPUN2t9VS3MdQ@mail.gmail.com>
 <561436B8.8090804@home.nl>
 <CAHjep=xDr1QQCMB1AcirDDW9ZkPVpWX7LyAV8o2-AP5u5PhpOg@mail.gmail.com>
 <5614C5FC.1020508@home.nl>
 <CAHjep=xLp279pF9S6rbyt3hVfiWU4zx50smCOCNdsh_m0NeJ1Q@mail.gmail.com>
 <56154FDB.3040503@home.nl>
 <CAHjep=w5dZfK8YRy_2=GHCWUotJwiy84Lubmy9jYsmZFqC3e-w@mail.gmail.com>
Message-ID: <CALzazPBPKp=i8OSUK9kdBUzNq+Wcfpury9DvEm2qzd49_MyS0A@mail.gmail.com>

On 7 October 2015 at 19:25, Rogan Creswick <creswick at gmail.com> wrote:

> Then I'd suggest using the quickcheck property guards ( `==>`) to only
> generate inputs that are known to be equal, or not equal and test
> separately in a few different properties.
>

This is not true, ==> still does generate and test.

Prelude> import Test.QuickCheck
Prelude Test.QuickCheck> let f x = x == 13 ==> mod x 2 == 1
Prelude Test.QuickCheck> quickCheck f
*** Gave up! Passed only 6 tests.

Also try verboseCheck to see what values are generated.

Ozgur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151007/e1cd9407/attachment-0001.html>

From creswick at gmail.com  Wed Oct  7 18:39:32 2015
From: creswick at gmail.com (Rogan Creswick)
Date: Wed, 7 Oct 2015 11:39:32 -0700
Subject: [Haskell-cafe] quickCheck problem
In-Reply-To: <CALzazPBPKp=i8OSUK9kdBUzNq+Wcfpury9DvEm2qzd49_MyS0A@mail.gmail.com>
References: <56142DE3.30604@home.nl>
 <CAHjep=yn7JBfZzZRv9zQN2n0ZagzwtGPdP1gkhPUN2t9VS3MdQ@mail.gmail.com>
 <561436B8.8090804@home.nl>
 <CAHjep=xDr1QQCMB1AcirDDW9ZkPVpWX7LyAV8o2-AP5u5PhpOg@mail.gmail.com>
 <5614C5FC.1020508@home.nl>
 <CAHjep=xLp279pF9S6rbyt3hVfiWU4zx50smCOCNdsh_m0NeJ1Q@mail.gmail.com>
 <56154FDB.3040503@home.nl>
 <CAHjep=w5dZfK8YRy_2=GHCWUotJwiy84Lubmy9jYsmZFqC3e-w@mail.gmail.com>
 <CALzazPBPKp=i8OSUK9kdBUzNq+Wcfpury9DvEm2qzd49_MyS0A@mail.gmail.com>
Message-ID: <CAHjep=yg+3qeskaFhm1UtwoKYw5ZwVyH-7=FqqHWVTYNJa67ew@mail.gmail.com>

On Wed, Oct 7, 2015 at 11:33 AM, Ozgur Akgun <ozgurakgun at gmail.com> wrote:
> This is not true, ==> still does generate and test.

I could have phrased that better.  Sure, it generates values, but it
will never provide them to your test, so your logic is simpler.

> Prelude> import Test.QuickCheck
> Prelude Test.QuickCheck> let f x = x == 13 ==> mod x 2 == 1
> Prelude Test.QuickCheck> quickCheck f
> *** Gave up! Passed only 6 tests.

That's unlikely to be a problem given the test inputs in the original
question, but yes, it is certainly an issue to know about.

Roelof -

The issue Ozgur is demonstrating is that the ==> operator will just
discard test inputs that were generated but which did not satisfy the
predicate (here that x == 13).  QuickCheck will eventually stop trying
to generate inputs (you can tune this), and produce something like the
above result.

--Rogan

>
> Also try verboseCheck to see what values are generated.
>
> Ozgur
>

From davidleothomas at gmail.com  Wed Oct  7 19:50:43 2015
From: davidleothomas at gmail.com (David Thomas)
Date: Wed, 7 Oct 2015 12:50:43 -0700
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <5615579D.5040900@orlitzky.com>
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com>
Message-ID: <CAJUDvchXXL4uMf0Ub33s_5RExWL0aSWJZq73jRCscRcm+y3iBQ@mail.gmail.com>

This sounds like the right approach.  To whatever degree existing
tooling makes this difficult, maybe we can fix existing tooling?

On Wed, Oct 7, 2015 at 10:34 AM, Michael Orlitzky <michael at orlitzky.com> wrote:
> (replying to no one in particular)
>
> This problem isn't specific to Haskell. In every other language, you
> have projects that support major versions of toolkits, compilers,
> libraries and whatnot. And there's already a tool for it: git.
>
> Instead of using #ifdef to handle four different compilers, keep a
> branch for each. Git is designed to make this easy, and it's usually
> trivial to merge changes from the master branch back into e.g. the
> ghc-7.8 branch. That way the code in your master branch stays clean.
> When you want to stop supporting an old GHC, delete that branch.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

From mark.lentczner at gmail.com  Wed Oct  7 21:13:02 2015
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Wed, 7 Oct 2015 22:13:02 +0100
Subject: [Haskell-cafe] MRP, 3-year-support-window,
 and the non-requirement of CPP
In-Reply-To: <CAPeieQG0-6AmNGEZLBg_Lqh5VJKwTtPFC3=iGV42ciJ=zO5xpg@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org> <etPan.56147308.2268a666.7b73@mbp.local>
 <CAHZrzdpig8R=W5T4SBRYwqCD_3W+wquYajOr-9qqcEd4f8gf1w@mail.gmail.com>
 <CAPeieQG0-6AmNGEZLBg_Lqh5VJKwTtPFC3=iGV42ciJ=zO5xpg@mail.gmail.com>
Message-ID: <CAAOoiFb3rqAzG4eH4jrwdors8OqDcTaQaZq7TJhBA5-VAsW8JQ@mail.gmail.com>

On Wed, Oct 7, 2015 at 9:38 AM, Erik Hesselink <hesselink at gmail.com> wrote:

> While I don't think it detracts from your argument, it seems you
> misread the original proposal. At no point will it remove `return`
> completely. It would be moved out of the `Monad` class and be made
> into a top-level definition instead, so you would still be able to use
> it.
>

Then why bother?
If you don't intend to regard code that uses "return" as old, out-dated, in
need of updating, etc....
If you don't intend to correct people on #haskell to use pure instead of
return...
If you don't tsk tsk all mentions of it in books....
If you don't intend to actually deprecate it.
Why bother?

But seriously, why do you think that "you would still be able to use it"?
That is true for only the simplest of code - and untrue for anyone who has
a library that defines a Monad - or anyone who has a library that they want
to keep "up to date". Do you really want to have a library where all your
"how to use this" code has return in the examples? Shouldn't now be pure?
Do I now need -XCPP just for Haddock? and my wiki page? And what gets shown
in Hackage? This is just a nightmare for a huge number of libraries, and
especially many commonly used ones.

Why bother!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151007/82a9d937/attachment.html>

From spam at scientician.net  Wed Oct  7 21:34:50 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Wed, 7 Oct 2015 23:34:50 +0200
Subject: [Haskell-cafe] MRP, 3-year-support-window,
	and the non-requirement of CPP
In-Reply-To: <CAAOoiFYUXaVJ5KX0nzGbzzS4ePDDhHK12X5bhC4zZNA+eUhM+w@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <CAK-tuPYxNM9uoywucSOT6O3RFhw2AGhCvBTKjOruKQK2V5dY3Q@mail.gmail.com>
 <CAAOoiFauRYsFLa_4LfuRq=s7+LhoAqFwEBEEzcuYv2pdesgdCQ@mail.gmail.com>
 <CAD=7U2C0a9US=mSeko44ThXD2=xXqA5GqQgweF3wq3X98SYsYw@mail.gmail.com>
 <CAAOoiFYUXaVJ5KX0nzGbzzS4ePDDhHK12X5bhC4zZNA+eUhM+w@mail.gmail.com>
Message-ID: <mv435r$ump$1@ger.gmane.org>

On 10/07/2015 08:36 AM, Mark Lentczner wrote:
> Mike -
> 
> You might look up the phrase "A modest proposal".
> 

While I personally appreciated it, I don't think irony/sarcasm/satire is
particularly appropriate given the state of discussion at this point ;).

Regards,


From achudnov at gmail.com  Wed Oct  7 22:08:43 2015
From: achudnov at gmail.com (Andrey Chudnov)
Date: Wed, 7 Oct 2015 18:08:43 -0400
Subject: [Haskell-cafe] status and future of haskell98 and haskell2010
	packages
Message-ID: <561597EB.8020906@gmail.com>

Hello,
My e-mail was rejected from libraries at haskell.org (the official 
maintenance contact of the two packages in question), so I'm trying my 
luck here instead. Hoping I can get some answers on the following questions:

1. What is the status of `haskell2010` and `haskell98` packages? Are 
they supported? Deprecated? In need of new maintainers?

2. Assuming the answer to the previous question is "alive and well", are 
there any plans to release new versions of those for GHC 7.10 and beyond?

Thanks in advance,
Andrey

From targen at gmail.com  Wed Oct  7 22:42:09 2015
From: targen at gmail.com (=?UTF-8?Q?Manuel_G=C3=B3mez?=)
Date: Wed, 7 Oct 2015 18:12:09 -0430
Subject: [Haskell-cafe] MRP, 3-year-support-window,
 and the non-requirement of CPP
In-Reply-To: <CAAOoiFb3rqAzG4eH4jrwdors8OqDcTaQaZq7TJhBA5-VAsW8JQ@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org> <etPan.56147308.2268a666.7b73@mbp.local>
 <CAHZrzdpig8R=W5T4SBRYwqCD_3W+wquYajOr-9qqcEd4f8gf1w@mail.gmail.com>
 <CAPeieQG0-6AmNGEZLBg_Lqh5VJKwTtPFC3=iGV42ciJ=zO5xpg@mail.gmail.com>
 <CAAOoiFb3rqAzG4eH4jrwdors8OqDcTaQaZq7TJhBA5-VAsW8JQ@mail.gmail.com>
Message-ID: <CAJWnFaPvHOV4f_aUasg187ffBC=rZBdXMkBoXb5LewAckQuAzA@mail.gmail.com>

On Wed, Oct 7, 2015 at 4:43 PM, Mark Lentczner <mark.lentczner at gmail.com> wrote:
> If you don't intend to actually deprecate it.
> Why bother?
>
> But seriously, why do you think that "you would still be able to use it"?
> That is true for only the simplest of code - and untrue for anyone who has a
> library that defines a Monad - or anyone who has a library that they want to
> keep "up to date". Do you really want to have a library where all your "how
> to use this" code has return in the examples? Shouldn't now be pure? Do I
> now need -XCPP just for Haddock? and my wiki page? And what gets shown in
> Hackage? This is just a nightmare for a huge number of libraries, and
> especially many commonly used ones.
>
> Why bother!

This is explained in the original proposal.  In particular, it
eliminates opportunities for errors and simplifies ApplicativeDo.  I
don?t believe anyone has proposed removing return from base.  The only
proposed change is turning return into a stand-alone function instead
of a method in Monad.  There is no proposal for removing return.

From allbery.b at gmail.com  Wed Oct  7 23:05:44 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Wed, 7 Oct 2015 19:05:44 -0400
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <mv40qe$qaa$1@ger.gmane.org>
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <CAK+ijdvbxW50-Q3-Vk5PaKyrCrsu7qLVvUzZ3K0iCSFR7h900g@mail.gmail.com>
 <mv40qe$qaa$1@ger.gmane.org>
Message-ID: <CAKFCL4UXSjPz+1prDG6hvrHFo_o-auV=M=f6=xVi0n_2p46fdw@mail.gmail.com>

On Wed, Oct 7, 2015 at 4:54 PM, Bardur Arantsson <spam at scientician.net>
wrote:

> Please consider that the the way practical development really happens[2]


...among web developers, who of course are the only real developers?

Have you considered that there are developers who are not web developers?
The past day has convinced me that the web devs have relegated everyone
else to fake-non-programmer status and actively want them out of the
community because fake programmers don't benefit you real programmers.

I had heard that the financial users generally refused to have anything to
do with the Haskell community.
Now I know why.

I wonder how many of them, if any indeed are left after past breaking
changes, are in the process of switching to OCaml. I'm sure you consider
that a good thing, because they're obviously just holding back "real
programmers".

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151007/ab960da1/attachment.html>

From ok at cs.otago.ac.nz  Wed Oct  7 23:16:29 2015
From: ok at cs.otago.ac.nz (Richard A. O'Keefe)
Date: Thu, 8 Oct 2015 12:16:29 +1300
Subject: [Haskell-cafe] quickCheck problem
In-Reply-To: <CAHjep=xDr1QQCMB1AcirDDW9ZkPVpWX7LyAV8o2-AP5u5PhpOg@mail.gmail.com>
References: <56142DE3.30604@home.nl>
 <CAHjep=yn7JBfZzZRv9zQN2n0ZagzwtGPdP1gkhPUN2t9VS3MdQ@mail.gmail.com>
 <561436B8.8090804@home.nl>
 <CAHjep=xDr1QQCMB1AcirDDW9ZkPVpWX7LyAV8o2-AP5u5PhpOg@mail.gmail.com>
Message-ID: <E8DED8B5-8C76-4E84-A93D-F4FF5A5E89A1@cs.otago.ac.nz>

You can generate two unequal integers by doing

prop_twoDifferent :: Int -> Int -> Bool
prop_twoDifferent x y = yourFn2 x y'
  where y' = if y >= x then y+1 else y

Letting the number of distinct Int values be N,
there are N*N pairs of Ints but only N*(N-1) pairs of
*different* Ints, so this technique will generate some
x y' pairs more often than others.  In fact you will
get (x,minBound::Int) with probability 2/N and
(x,y>minBound) with probability 1/N.
The advantage of using a guard is that the probabilities
come out right (it's the "rejection method", in
statistical parlance).

You can use that method to generate
  x x y
  x y x
  y x x

You can iterate the same idea to generate triples.


From spam at scientician.net  Wed Oct  7 23:38:51 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Thu, 8 Oct 2015 01:38:51 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAKFCL4UXSjPz+1prDG6hvrHFo_o-auV=M=f6=xVi0n_2p46fdw@mail.gmail.com>
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <CAK+ijdvbxW50-Q3-Vk5PaKyrCrsu7qLVvUzZ3K0iCSFR7h900g@mail.gmail.com>
 <mv40qe$qaa$1@ger.gmane.org>
 <CAKFCL4UXSjPz+1prDG6hvrHFo_o-auV=M=f6=xVi0n_2p46fdw@mail.gmail.com>
Message-ID: <mv4aeb$svf$1@ger.gmane.org>

On 10/08/2015 01:05 AM, Brandon Allbery wrote:
> On Wed, Oct 7, 2015 at 4:54 PM, Bardur Arantsson <spam at scientician.net>
> wrote:
> 
>> Please consider that the the way practical development really happens[2]
> 
> 
> ....among web developers, who of course are the only real developers?
> 

Nononono, I only provided that as an example. I'm well aware that there
are whole other ecosystems. (I, for example, am currently doing full-stack.)

> Have you considered that there are developers who are not web developers?
> The past day has convinced me that the web devs have relegated everyone
> else to fake-non-programmer status and actively want them out of the
> community because fake programmers don't benefit you real programmers.
> 

Re-read your own words. You're doing exactly the same, just in reverse.

> I had heard that the financial users generally refused to have anything to
> do with the Haskell community.
> Now I know why.

I think Standard Charatered might disagree, but... whatevs.

> 
> I wonder how many of them, if any indeed are left after past breaking
> changes, are in the process of switching to OCaml. I'm sure you consider
> that a good thing, because they're obviously just holding back "real
> programmers".
> 

O'calm down! :)

The world isn't going to end over this.

(And... if you still think it is: Provide quantifiable data: Tell us how
many of *your* MLoC will be affected. Tell us... whatever you can
without violating NDAs, etc. "We" *will* apprectiate and take this into
account.)

Regards,


From mwm at mired.org  Wed Oct  7 23:39:19 2015
From: mwm at mired.org (Mike Meyer)
Date: Wed, 07 Oct 2015 23:39:19 +0000
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAKFCL4UXSjPz+1prDG6hvrHFo_o-auV=M=f6=xVi0n_2p46fdw@mail.gmail.com>
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <CAK+ijdvbxW50-Q3-Vk5PaKyrCrsu7qLVvUzZ3K0iCSFR7h900g@mail.gmail.com>
 <mv40qe$qaa$1@ger.gmane.org>
 <CAKFCL4UXSjPz+1prDG6hvrHFo_o-auV=M=f6=xVi0n_2p46fdw@mail.gmail.com>
Message-ID: <CAD=7U2CnbZHGmErQs7c34mEky4gP7E81YVyASE2Zk1HeNv8OQw@mail.gmail.com>

On Wed, Oct 7, 2015 at 6:05 PM Brandon Allbery <allbery.b at gmail.com> wrote:

> On Wed, Oct 7, 2015 at 4:54 PM, Bardur Arantsson <spam at scientician.net>
> wrote:
>
>> Please consider that the the way practical development really happens[2]
>
> ...among web developers, who of course are the only real developers?
> [...]
> I had heard that the financial users generally refused to have anything to
> do with the Haskell community.
> Now I know why.
>

I'm curious - do "practical" developers really feel like they have to rush
out and update their tool chain whenever a new version of part of it comes
out? Most of the projects I've worked on considered the language version as
a fixed part of the technology stack, and almost never updated it. Even
when using Python, which valued not breaking working code more than it's
own zen. But changing anything that potentially affected all the code in a
working project was pretty much never done, and always involved a lot of
effort.

So the worst headache I got from language evolution was from trying to
remember which set of features I had available for each project. No, that's
second - the biggest one was from arguments about when we should adopt a
new version. But breaking working code pretty much didn't happen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151007/7e48b8c3/attachment.html>

From ok at cs.otago.ac.nz  Thu Oct  8 03:58:45 2015
From: ok at cs.otago.ac.nz (Richard A. O'Keefe)
Date: Thu, 8 Oct 2015 16:58:45 +1300
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
	`return` out of `Monad`
In-Reply-To: <5613B14F.9070107@nottingham.ac.uk>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <5613B14F.9070107@nottingham.ac.uk>
Message-ID: <6E5715BB-FB3D-436D-A1A3-38EC72BA77D7@cs.otago.ac.nz>

The change to make Monad a special case of Applicative has been
a long time coming, and it has been a long time coming precisely
because it's going to break things.

I feel ambivalent about this.  As soon as the question was
raised, it was clear that it *would have been* nicer had
Haskell been this way originally.  I'm not looking forward to
the consequences of the change.


On 7/10/2015, at 12:32 am, Henrik Nilsson <Henrik.Nilsson at nottingham.ac.uk> wrote:
> While we can discuss the extent of additional breakage
> MRP would cause, the fact remains it is a further
> breaking change. A survey of breakage to books as
> Herbert did is certainly valuable  (thanks!), but
> much breakage will (effectively) remain unquantifiable.

This suggests one way in which one of the costs of the change
could be reduced.  Not just to survey the breakage, but to
actually put revised material up on the Haskell.org web site,
with a prominent link from the home page.



From r.wobben at home.nl  Thu Oct  8 05:03:48 2015
From: r.wobben at home.nl (Roelof Wobben)
Date: Thu, 8 Oct 2015 07:03:48 +0200
Subject: [Haskell-cafe] quickCheck problem
In-Reply-To: <E8DED8B5-8C76-4E84-A93D-F4FF5A5E89A1@cs.otago.ac.nz>
References: <56142DE3.30604@home.nl>
 <CAHjep=yn7JBfZzZRv9zQN2n0ZagzwtGPdP1gkhPUN2t9VS3MdQ@mail.gmail.com>
 <561436B8.8090804@home.nl>
 <CAHjep=xDr1QQCMB1AcirDDW9ZkPVpWX7LyAV8o2-AP5u5PhpOg@mail.gmail.com>
 <E8DED8B5-8C76-4E84-A93D-F4FF5A5E89A1@cs.otago.ac.nz>
Message-ID: <5615F934.1030705@home.nl>

Op 8-10-2015 om 01:16 schreef Richard A. O'Keefe:
> You can generate two unequal integers by doing
>
> prop_twoDifferent :: Int -> Int -> Bool
> prop_twoDifferent x y = yourFn2 x y'
>    where y' = if y >= x then y+1 else y
>
> Letting the number of distinct Int values be N,
> there are N*N pairs of Ints but only N*(N-1) pairs of
> *different* Ints, so this technique will generate some
> x y' pairs more often than others.  In fact you will
> get (x,minBound::Int) with probability 2/N and
> (x,y>minBound) with probability 1/N.
> The advantage of using a guard is that the probabilities
> come out right (it's the "rejection method", in
> statistical parlance).
>
> You can use that method to generate
>    x x y
>    x y x
>    y x x
>
> You can iterate the same idea to generate triples.
>
>
>
> -----
> Geen virus gevonden in dit bericht.
> Gecontroleerd door AVG - www.avg.com
> Versie: 2015.0.6140 / Virusdatabase: 4435/10775 - datum van uitgifte: 10/07/15
>
>

Thanks all.

Enough to study and try.

Roelof


From ok at cs.otago.ac.nz  Thu Oct  8 05:04:21 2015
From: ok at cs.otago.ac.nz (Richard A. O'Keefe)
Date: Thu, 8 Oct 2015 18:04:21 +1300
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
	`return` out of `Monad`
In-Reply-To: <CAD=7U2CnbZHGmErQs7c34mEky4gP7E81YVyASE2Zk1HeNv8OQw@mail.gmail.com>
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <CAK+ijdvbxW50-Q3-Vk5PaKyrCrsu7qLVvUzZ3K0iCSFR7h900g@mail.gmail.com>
 <mv40qe$qaa$1@ger.gmane.org>
 <CAKFCL4UXSjPz+1prDG6hvrHFo_o-auV=M=f6=xVi0n_2p46fdw@mail.gmail.com>
 <CAD=7U2CnbZHGmErQs7c34mEky4gP7E81YVyASE2Zk1HeNv8OQw@mail.gmail.com>
Message-ID: <6405267D-7487-4793-8B0B-609E63740526@cs.otago.ac.nz>


On 8/10/2015, at 12:39 pm, Mike Meyer <mwm at mired.org> wrote:
> 
> I'm curious - do "practical" developers really feel like they have to rush out and update their tool chain whenever a new version of part of it comes out? Most of the projects I've worked on considered the language version as a fixed part of the technology stack, and almost never updated it. Even when using Python, which valued not breaking working code more than it's own zen. But changing anything that potentially affected all the code in a working project was pretty much never done, and always involved a lot of effort.

My computer spends more of its time installing new versions of Java 1.8
than it does running Java.  An application I found very useful stopped
working when Java 1.6 went away, but Java 1.6 had to go away because of
(in)security concerns.  How anyone managed to write a program in Java
1.6 that would not run in 1.8 I hope never to know.

(No, rebuilding from sources didn't work either.  Tried that.)



From tonymorris at gmail.com  Thu Oct  8 05:25:56 2015
From: tonymorris at gmail.com (Tony Morris)
Date: Thu, 8 Oct 2015 15:25:56 +1000
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <6405267D-7487-4793-8B0B-609E63740526@cs.otago.ac.nz>
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <CAK+ijdvbxW50-Q3-Vk5PaKyrCrsu7qLVvUzZ3K0iCSFR7h900g@mail.gmail.com>
 <mv40qe$qaa$1@ger.gmane.org>
 <CAKFCL4UXSjPz+1prDG6hvrHFo_o-auV=M=f6=xVi0n_2p46fdw@mail.gmail.com>
 <CAD=7U2CnbZHGmErQs7c34mEky4gP7E81YVyASE2Zk1HeNv8OQw@mail.gmail.com>
 <6405267D-7487-4793-8B0B-609E63740526@cs.otago.ac.nz>
Message-ID: <5615FE64.8060903@gmail.com>

Java is not backward compatible, even between minor release.


On 08/10/15 15:04, Richard A. O'Keefe wrote:
> 
> On 8/10/2015, at 12:39 pm, Mike Meyer <mwm at mired.org> wrote:
>>
>> I'm curious - do "practical" developers really feel like they have to rush out and update their tool chain whenever a new version of part of it comes out? Most of the projects I've worked on considered the language version as a fixed part of the technology stack, and almost never updated it. Even when using Python, which valued not breaking working code more than it's own zen. But changing anything that potentially affected all the code in a working project was pretty much never done, and always involved a lot of effort.
> 
> My computer spends more of its time installing new versions of Java 1.8
> than it does running Java.  An application I found very useful stopped
> working when Java 1.6 went away, but Java 1.6 had to go away because of
> (in)security concerns.  How anyone managed to write a program in Java
> 1.6 that would not run in 1.8 I hope never to know.
> 
> (No, rebuilding from sources didn't work either.  Tried that.)
> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> 

From rustompmody at gmail.com  Thu Oct  8 07:01:16 2015
From: rustompmody at gmail.com (Rustom Mody)
Date: Thu, 8 Oct 2015 12:31:16 +0530
Subject: [Haskell-cafe] MRP, 3-year-support-window,
 and the non-requirement of CPP (was: Monad of no `return` Proposal
 (MRP): Moving `return` out of `Monad`)
In-Reply-To: <3d672fd5db1546b189f16d2a890a953d@DB4PR30MB030.064d.mgd.msft.net>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <CAK-tuPYxNM9uoywucSOT6O3RFhw2AGhCvBTKjOruKQK2V5dY3Q@mail.gmail.com>
 <CAAOoiFauRYsFLa_4LfuRq=s7+LhoAqFwEBEEzcuYv2pdesgdCQ@mail.gmail.com>
 <CAD=7U2C0a9US=mSeko44ThXD2=xXqA5GqQgweF3wq3X98SYsYw@mail.gmail.com>
 <3d672fd5db1546b189f16d2a890a953d@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAJ+Teod4nxme73CgbmYnN55HgcVyPCm36z64kQy+awqF6X-KcQ@mail.gmail.com>

*From:* Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] *On Behalf
Of *Mike Meyer
*Sent:* 07 October 2015 00:24
*To:* Mark Lentczner; Johan Tibell
*Cc:* Haskell Libraries; haskell cafe; haskell-prime at haskell.org List
*Subject:* Re: [Haskell-cafe] MRP, 3-year-support-window, and the
non-requirement of CPP (was: Monad of no `return` Proposal (MRP): Moving
`return` out of `Monad`)



On Tue, Oct 6, 2015 at 4:15 PM Mark Lentczner <mark.lentczner at gmail.com>
wrote:


On Thu, Sep 24, 2015 at 2:43 PM, Herbert Valerio Riedel <hvr at gnu.org> wrote:

TLDR: To complete the AMP, turn `Monad(return)` method into a
      top-level binding aliasing `Applicative(pure)`.



Sure... if we had a language that no one uses and could keep reforming like
putty until it is perfect. But we don't.



A modest proposal:



We can't keep tinkering with a language and it's libraries like this AND
have a growing ecosystem that serves an ever widening base, including the
range from newcomer to commercial deployment. SO - Why let's do all the
language tinkering in GHC 8 there can be as many prereleases of that as
needed until it is just right. ...and leave GHC 7 (7.10? roll back to
7.8.4?) for all of us doing essential and dependable libraries, commercial
work, projects on Haskell that we don't want to have to go back and #ifdefs
to twice a year just to keep running, educators, people writing books. We
can keep improving GHC 7 as needed, and focus on bugs, security issues,
patches, cross compatibility, etc.



On Wed, Oct 7, 2015 at 9:06 PM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> I think there are several different conversations going on at once in this
> thread.  I think it?s worth keeping them separate.
>
> <snip>
>
> Returning to ?return?, my instinct is that when these pervasive breaking
> library changes come up, we should batch them into larger clumps.  The
> ?treadmill? complaint is real: small change A made me re-release my
> library; then small change B came along; and so on.  Perhaps if we saved
> them up this would be less of an issue, for two reasons.  First, the work
> happens once rather than many times.  Second, the benefits of the change is
> the sum of the benefits of the little component changes, and so is more
> attractive to library authors and library clients.
>
>
>
> That line of thinking would suggest that the Core Libraries Committee
> might want to maintain a list of well-worked out agreed changes that are
> being ?saved up? for execution at some later date.
>
>
>
> Simon
>
>
>
This whole discussion is tilted towards the software engineering side.
Of course from this side if someone keeps changing the underbelly in small
but significant ways that has multiplicative effects on higher levels,
people who have to manage the higher affected levels will protest.

However I'd like to respectfully submit that the software engineering angle
is not the only one; there's also the teaching angle.

When the Haskell report first came out in 1990 this dual purpose was very
clear in the first paras.
Over years as Haskell has progressed from being an academic language to a
'Real World' one this balance has been lost.
Whether Monads is really rocket science or its just ill-designed misnamed
stuff that looks like a mess because no heavy duty vacuum cleaner has been
applied, no one knows for sure because there's little pedagogic experience
with any alternative 'cleaned out Haskell'.

However this is just to point out that that possibility may be there.

And from the pedagogic angle Haskell may be neat but functional programming
is probably more significant and programming in general even more so.

In this respect here are two posts:
Functional Programming TimeLine:
http://blog.languager.org/2015/04/cs-history-1.html
and its sequel:
http://blog.languager.org/2015/06/functional-programming-moving-target.html
which is a more indepth analysis of FP in ACM curriculum 2013 and how
pedagogic realities that were generally understood some decades ago have
been increasingly forgotten today.

For the specific case at hand -- return vs pure -- Ive no specific opinion
However on a wider front, the confusion and frustration of the thousands of
beginners who have to see the forbidding meaningless 'Functor' and 'Monad'
instead of something more accessible like Mappable/Computational is IMHO a
factor for Haskell not getting as much success as it should.

Hopefully the community will take spj's call for significant batched-up
changes seriously
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151008/3c582163/attachment.html>

From mlang at delysid.org  Thu Oct  8 08:21:25 2015
From: mlang at delysid.org (Mario Lang)
Date: Thu, 08 Oct 2015 10:21:25 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
	`return` out of `Monad`
In-Reply-To: <CAK+ijdvbxW50-Q3-Vk5PaKyrCrsu7qLVvUzZ3K0iCSFR7h900g@mail.gmail.com>
 (=?utf-8?Q?=22Jos=C3=A9?= Manuel =?utf-8?Q?Calder=C3=B3n?= Trilla"'s
 message of "Tue, 6 Oct 2015 15:56:47 -0700")
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <CAK+ijdvbxW50-Q3-Vk5PaKyrCrsu7qLVvUzZ3K0iCSFR7h900g@mail.gmail.com>
Message-ID: <87lhbdzs6y.fsf@fx.delysid.org>

Jos? Manuel Calder?n Trilla <jmct at jmct.cc> writes:

> Many of us here learned from those texts or those courses. It's easy online
> to say that materials being out of date isn't a big deal, but it can turn
> people off the language when the code they paste into ghci doesn't
> work.

FWIW, I am a newbie, and currently learning a lot from the web.
I've had a different feeling.  Whenever I read something like "This is
historical, and should have been fixed, but isn't yet", it were these
sentences that almost turned me off the language, because I had a
feeling that there is some stagnation going on.

>From the POV of a newbie, I am all for fixing historical hickups.
However, I realize that I have different priorities compared to
long-time users and people needing to maintain a lot of existing code.

Just my 0.01?

-- 
CYa,
  ?????

From tonymorris at gmail.com  Thu Oct  8 08:52:19 2015
From: tonymorris at gmail.com (Tony Morris)
Date: Thu, 8 Oct 2015 18:52:19 +1000
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <87lhbdzs6y.fsf@fx.delysid.org>
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <CAK+ijdvbxW50-Q3-Vk5PaKyrCrsu7qLVvUzZ3K0iCSFR7h900g@mail.gmail.com>
 <87lhbdzs6y.fsf@fx.delysid.org>
Message-ID: <56162EC3.1020205@gmail.com>

Many of my students are distracted by this too. This is why it is turned
off and a practical type-class hierarchy is used to demonstrate concepts.

As for use in production, it's been used for coming up to 10 years. I
will wait.

On 08/10/15 18:21, Mario Lang wrote:
> Jos? Manuel Calder?n Trilla <jmct at jmct.cc> writes:
> 
>> Many of us here learned from those texts or those courses. It's easy online
>> to say that materials being out of date isn't a big deal, but it can turn
>> people off the language when the code they paste into ghci doesn't
>> work.
> 
> FWIW, I am a newbie, and currently learning a lot from the web.
> I've had a different feeling.  Whenever I read something like "This is
> historical, and should have been fixed, but isn't yet", it were these
> sentences that almost turned me off the language, because I had a
> feeling that there is some stagnation going on.
> 
> From the POV of a newbie, I am all for fixing historical hickups.
> However, I realize that I have different priorities compared to
> long-time users and people needing to maintain a lot of existing code.
> 
> Just my 0.01?
> 

From _deepfire at feelingofgreen.ru  Thu Oct  8 09:39:40 2015
From: _deepfire at feelingofgreen.ru (Kosyrev Serge)
Date: Thu, 08 Oct 2015 12:39:40 +0300
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
	`return` out of `Monad`
In-Reply-To: <5615FE64.8060903@gmail.com>
 (sfid-20151008_094939_405258_6941E820) (Tony Morris's message of "Thu,
 8 Oct 2015 15:25:56 +1000")
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <CAK+ijdvbxW50-Q3-Vk5PaKyrCrsu7qLVvUzZ3K0iCSFR7h900g@mail.gmail.com>
 <mv40qe$qaa$1@ger.gmane.org>
 <CAKFCL4UXSjPz+1prDG6hvrHFo_o-auV=M=f6=xVi0n_2p46fdw@mail.gmail.com>
 <CAD=7U2CnbZHGmErQs7c34mEky4gP7E81YVyASE2Zk1HeNv8OQw@mail.gmail.com>
 <6405267D-7487-4793-8B0B-609E63740526@cs.otago.ac.nz>
 <5615FE64.8060903@gmail.com>
Message-ID: <87wpuxog0z.fsf@feelingofgreen.ru>

Tony Morris <tonymorris at gmail.com> writes:
> Java is not backward compatible, even between minor release.

Is there an understanding of how they manage to qualify as an
industrially-acceptable language in spite of this?

-- 
? ???????e? / respectfully,
??????? ??????

From tonymorris at gmail.com  Thu Oct  8 09:41:47 2015
From: tonymorris at gmail.com (Tony Morris)
Date: Thu, 8 Oct 2015 19:41:47 +1000
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <87wpuxog0z.fsf@feelingofgreen.ru>
References: <560E57D1.9060302@nottingham.ac.uk>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <CAK+ijdvbxW50-Q3-Vk5PaKyrCrsu7qLVvUzZ3K0iCSFR7h900g@mail.gmail.com>
 <mv40qe$qaa$1@ger.gmane.org>
 <CAKFCL4UXSjPz+1prDG6hvrHFo_o-auV=M=f6=xVi0n_2p46fdw@mail.gmail.com>
 <CAD=7U2CnbZHGmErQs7c34mEky4gP7E81YVyASE2Zk1HeNv8OQw@mail.gmail.com>
 <6405267D-7487-4793-8B0B-609E63740526@cs.otago.ac.nz>
 <5615FE64.8060903@gmail.com> <87wpuxog0z.fsf@feelingofgreen.ru>
Message-ID: <56163A5B.7080901@gmail.com>

Successful marketing.

On 08/10/15 19:39, Kosyrev Serge wrote:
> Tony Morris <tonymorris at gmail.com> writes:
>> Java is not backward compatible, even between minor release.
> 
> Is there an understanding of how they manage to qualify as an
> industrially-acceptable language in spite of this?
> 

From hvr at gnu.org  Thu Oct  8 12:24:16 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Thu, 08 Oct 2015 14:24:16 +0200
Subject: [Haskell-cafe] status and future of haskell98 and haskell2010
	packages
In-Reply-To: <561597EB.8020906@gmail.com> (Andrey Chudnov's message of "Wed, 7
 Oct 2015 18:08:43 -0400")
References: <561597EB.8020906@gmail.com>
Message-ID: <87egh57dlb.fsf@gnu.org>

On 2015-10-08 at 00:08:43 +0200, Andrey Chudnov wrote:
> My e-mail was rejected from libraries at haskell.org (the official
> maintenance contact of the two packages in question), so I'm trying my
> luck here instead. Hoping I can get some answers on the following
> questions:
>
> 1. What is the status of `haskell2010` and `haskell98` packages? Are
> they supported? Deprecated? In need of new maintainers?

Short answer: with GHC 7.10 it is not possible anymore to implement a
proper[1] `haskell98` or `haskell2010` package anymore.

More details can be found at https://ghc.haskell.org/ticket/9590

> 2. Assuming the answer to the previous question is "alive and well",
> are there any plans to release new versions of those for GHC 7.10 and
> beyond?

In order to be able to recover support for a `haskell2010` package in
newer GHCs, GHC will need to be extended in some way. I can think of two
different paths to pursue to accomplish this, depending on whether
type(classes) need to be shared with `base` or not. Moreover, it wasn't
clear how much actual demand there really is to have the recent GHCs
support a legacy `haskell2010` mode.

So if there's somebody interested in resuscitating a
`haskell98`/`haskell2010` package, please tell us what your use-case is
(to help understand whether type(class) sharing w/ `base` is essential
or not -- it's *much* more easier to get this working w/o the typeclass
sharing requirement, whereas the typeclass-sharing variant might not
even be possible at all)


Cheers,
   hvr

 [1]: I.e. with the requirement that all code written conforming to the
      respective Haskell Report will be compileable via e.g.

      ghc -XHaskell2010 -hide-all-packages -package haskell2010 -c *.hs

      (to some degree, this was already broken before GHC 7.10
      due to the superclass-removal on `Num`, but with AMP this was
      broken beyond tolerance)

From mike at proclivis.com  Thu Oct  8 13:26:09 2015
From: mike at proclivis.com (Michael Jones)
Date: Thu, 8 Oct 2015 07:26:09 -0600
Subject: [Haskell-cafe] Failing to catch exception
Message-ID: <305E198E-C7A6-4D29-8E5C-A54334C631D6@proclivis.com>


I?m having trouble with an exception that won?t catch and looking for suggestions. Basically, a ?fail? inside a ?catch? inside a unsafeIOToSTM, inside a wx callback, trying to catch SomeException or IOException.

Details:

I?m using Text.Regex.PCRE

and the exception comes from a ?fail" in unwrap:

unwrap :: (Show e) => Either e v -> IO v
unwrap x = case x of Left err -> fail ("Text.Regex.PCRE.String died: "++ show err)
                    Right v -> return v

The catch is in this function, catching SomeException:

 filterTableRow _ record fils = do
   s <- showRecord record
   vs <- Control.Exception.catch (
             return $ map (\(fil,col) -> let fil' = if fil == "" then "^" else fil in
                                                    ((splitOn "," s)!!(fromIntegral (col+1))) =~ fil') (elems fils)
             )
             ((\e -> do return $ replicate (length $ elems fils) False) :: SomeException -> IO [Bool])
   return $ foldl (.&.) True vs

filterTableRow is called from an unsafeIOToSTM:

unsafeIOToSTM $ filterTableRow gridData row? fil

which is called from a wx callback from a button press

Before I added the catch, the application was working for over a year, so there is no general problem, All I added was the catch.

Adding -xc to the ghc runtime shows the error:

*** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace: 
 Text.Regex.PCRE.String.matchTest,
 called from Text.Regex.PCRE.String.unwrap,
?
user error (Text.Regex.PCRE.String died: (4,"unmatched parentheses"))


Which indicates the text in unwrap, as if the exception is not caught. I have tried to catch it as IOException, and SomeException.

Any ideas why it is not caught or some way to debug it?

From hjgtuyl at chello.nl  Thu Oct  8 13:35:16 2015
From: hjgtuyl at chello.nl (Henk-Jan van Tuyl)
Date: Thu, 08 Oct 2015 15:35:16 +0200
Subject: [Haskell-cafe] ANN: wxInstall Abriline and wxHaskell 0.92.1.0
Message-ID: <op.x56v02repz0j5l@alquantor>


L.S.,

I am happy to announce the installation packages for wxHaskell on Windows,
and a new version of wxHaskell: 0.92.1.0

So far, the installation of wxHaskell on Windows has been difficult, but
now it is just a matter of downloading an installation package[0][1],
unzipping it to the directory where you want to have it installed, and
clicking on Install.bat. A detailed description can be found at the
wxHaskell-for-Windows homepage[2]. The current configuration of the
installation packages (one package for 32 bit and one for 64 bit systems),
is called Abriline and contains compiled wxWidgets 3.0.2 and all further
necessary DLLs. The installation procedure automatically installs the
latest version of wxHaskell and can be used for several of the most recent
versions of GHC.

In case you are wondering where the name Abriline comes from, it is
generated by a girls name generator I wrote (in Haskell of course); I
selected this name because a search on Internet seems to indicate that the
name is brand new.

The new version of wxHaskell is released because it solves a bug that
could crash an application.


What is wxHaskell?
------------------
wxHaskell[3] is a portable and native GUI library for Haskell. The goal of
the project is to provide an industrial strength GUI library for Haskell,
but without the burden of developing (and maintaining) one ourselves.

wxHaskell is therefore built on top of wxWidgets ? a comprehensive C++
library that is portable across all major GUI platforms; including GTK,
Windows, X11, and MacOS X. Furthermore, it is a mature library (in
development since 1992) that supports a wide range of widgets with the
native look-and-feel.


Links
-----
See the homepage of wxHaskell for more information:
         https://wiki.haskell.org/WxHaskell

The packages are:
        - wxc       https://hackage.haskell.org/package/wxc
        - wxdirect  https://hackage.haskell.org/package/wxdirect
        - wxcore    https://hackage.haskell.org/package/wxcore
        - wx        https://hackage.haskell.org/package/wx

Regards,
Henk-Jan van Tuyl


[0]
http://sourceforge.net/projects/wxhaskell/files/wxInstall/wxInstall-Abriline-32-0.1.zip/download
[1]
http://sourceforge.net/projects/wxhaskell/files/wxInstall/wxInstall-Abriline-64-0.1.zip/download
[2] https://wiki.haskell.org/WxHaskell/Windows#Installing_the_easy_way
[3] https://wiki.haskell.org/WxHaskell



-- 
Folding at home
What if you could share your unused computer power to help find a cure? In
just 5 minutes you can join the world's biggest networked computer and get
us closer sooner. Watch the video.
http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

From hesselink at gmail.com  Thu Oct  8 13:41:43 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Thu, 8 Oct 2015 15:41:43 +0200
Subject: [Haskell-cafe] Failing to catch exception
In-Reply-To: <305E198E-C7A6-4D29-8E5C-A54334C631D6@proclivis.com>
References: <305E198E-C7A6-4D29-8E5C-A54334C631D6@proclivis.com>
Message-ID: <CAPeieQE1LKUg1a_rmReK017Xgka0qSxsNregTznmN5LfG5RWAw@mail.gmail.com>

Perhaps the value you're calculating is lazily computed, so the
exception occurs only when using it, and by then you're already
outside the catch? Try forcing things with `seq` or `deepseq` and see
if that helps in catching the exception.

Erik

On 8 October 2015 at 15:26, Michael Jones <mike at proclivis.com> wrote:
>
> I?m having trouble with an exception that won?t catch and looking for suggestions. Basically, a ?fail? inside a ?catch? inside a unsafeIOToSTM, inside a wx callback, trying to catch SomeException or IOException.
>
> Details:
>
> I?m using Text.Regex.PCRE
>
> and the exception comes from a ?fail" in unwrap:
>
> unwrap :: (Show e) => Either e v -> IO v
> unwrap x = case x of Left err -> fail ("Text.Regex.PCRE.String died: "++ show err)
>                     Right v -> return v
>
> The catch is in this function, catching SomeException:
>
>  filterTableRow _ record fils = do
>    s <- showRecord record
>    vs <- Control.Exception.catch (
>              return $ map (\(fil,col) -> let fil' = if fil == "" then "^" else fil in
>                                                     ((splitOn "," s)!!(fromIntegral (col+1))) =~ fil') (elems fils)
>              )
>              ((\e -> do return $ replicate (length $ elems fils) False) :: SomeException -> IO [Bool])
>    return $ foldl (.&.) True vs
>
> filterTableRow is called from an unsafeIOToSTM:
>
> unsafeIOToSTM $ filterTableRow gridData row? fil
>
> which is called from a wx callback from a button press
>
> Before I added the catch, the application was working for over a year, so there is no general problem, All I added was the catch.
>
> Adding -xc to the ghc runtime shows the error:
>
> *** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace:
>  Text.Regex.PCRE.String.matchTest,
>  called from Text.Regex.PCRE.String.unwrap,
> ?
> user error (Text.Regex.PCRE.String died: (4,"unmatched parentheses"))
>
>
> Which indicates the text in unwrap, as if the exception is not caught. I have tried to catch it as IOException, and SomeException.
>
> Any ideas why it is not caught or some way to debug it?
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

From alex323 at gmail.com  Thu Oct  8 13:48:52 2015
From: alex323 at gmail.com (Alex)
Date: Thu, 8 Oct 2015 09:48:52 -0400
Subject: [Haskell-cafe] Well-typed design issue
Message-ID: <20151008094852.55a67308@gmail.com>

Hello:

I am implementing a high-level protocol which requires the use of
various cryptographic primitives. I have the following goals in mind:

1. Allow others to extend the library to use different underlying
crypto implementations, ciphers, curves, etc, and
2. Have the library be well-typed so that cryptographic operations are
unambiguous, leading to code which can be easily audited.

According to the spec, the user is allowed to instantiate the protocol
with any combination of supported ciphers and curves, but the
high-level operations always remain the same regardless of what
primitives are used. 

Pursuant to the above goals, I've defined two typeclasses, "Cipher" and
"Curve". I'm using TypeFamilies to facilitate the creation of data
types that are independent of the underlying crypto library.

The Cipher typeclass is as follows:

class Cipher c
where                                                                           
  data Ciphertext   c :: *                                                                     
  data SymmetricKey c :: *                                                                     
  data Nonce        c :: *                                                                     
  data Digest       c :: *                                                                     
                              
  cipherName       :: c -> ByteString
  cipherEncrypt    :: SymmetricKey c -> Nonce c -> AssocData -> Plaintext -> Ciphertext c
  cipherDecrypt    :: SymmetricKey c -> Nonce c -> AssocData -> Ciphertext c -> Maybe Plaintext
  cipherZeroNonce  :: Nonce c        
  cipherIncNonce   :: Nonce c -> Nonce c                         
  cipherGetKey     :: SymmetricKey c -> Nonce c -> SymmetricKey c
  cipherHashToKey  :: Digest c -> SymmetricKey c
  cipherHashToAD   :: Digest c -> AssocData
  cipherHash       :: ScrubbedBytes -> Digest c
  cipherConcatHash :: Digest c -> ScrubbedBytes -> Digest c
  cipherHMAC       :: SymmetricKey c -> ScrubbedBytes -> Digest c
               
newtype Plaintext = Plaintext ScrubbedBytes
newtype AssocData = AssocData ScrubbedBytes

Unfortunately, the spec as written assumes that all variables are blobs
of bytes. The issue I'm running in to is that, in my goal to have
everything well-typed, my typeclasses are filling up with conversion
functions like "cipherHashToKey" and "cipherHashToAD". These type
conversions are necessary because I'm required to compute values like
"HMAC-HASH(GETKEY(k, n), data)" (which returns "Digest c") and assign
it to a variable whose type is "SymmetricKey c" (hence the need for
cipherHashToKey).

Is all my effort to write a well-typed library being done in vain?
Should I just give up and have all the functions use ByteStrings?

-- 
Alex

From ben at smart-cactus.org  Thu Oct  8 13:55:13 2015
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 08 Oct 2015 15:55:13 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
	`return` out of `Monad`
In-Reply-To: <5615579D.5040900@orlitzky.com>
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com>
Message-ID: <874mi15uta.fsf@smart-cactus.org>

Michael Orlitzky <michael at orlitzky.com> writes:

> (replying to no one in particular)
>
> This problem isn't specific to Haskell. In every other language, you
> have projects that support major versions of toolkits, compilers,
> libraries and whatnot. And there's already a tool for it: git.
>
> Instead of using #ifdef to handle four different compilers, keep a
> branch for each. Git is designed to make this easy, and it's usually
> trivial to merge changes from the master branch back into e.g. the
> ghc-7.8 branch. That way the code in your master branch stays clean.
> When you want to stop supporting an old GHC, delete that branch.
>
I don't find this option terribly appealing. As a maintainer I would far
prefer maintaining a bit of CPP than a proliferation of branches, with
all of the cherry-picking and potential code divergence that they
bring.

Really though, the point I've been trying to make throughout is that I
think that much of the CPP that we are currently forced to endure isn't
even strictly necessary. With a few changes to our treatment of warnings
and some new pragmas (aimed at library authors), we can greatly reduce
the impact that library interface changes have on users.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151008/f6e87f8b/attachment.sig>

From eir at cis.upenn.edu  Thu Oct  8 16:51:00 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Thu, 8 Oct 2015 12:51:00 -0400
Subject: [Haskell-cafe] Well-typed design issue
In-Reply-To: <20151008094852.55a67308@gmail.com>
References: <20151008094852.55a67308@gmail.com>
Message-ID: <B5307922-2F38-4C73-A230-FE7A710BF4C5@cis.upenn.edu>

What's going wrong? It looks like you're off to a solid start here.

I don't know about these cryptographic primitives you speak of, but it sounds like the type conversion functions you're railing against are indeed necessary -- that is, they perform a runtime action. So where's the problem? Richly typed interfaces are sometimes more verbose (especially when you're just setting things up), but you're getting safety guarantees for that payment.

Richard

On Oct 8, 2015, at 9:48 AM, Alex <alex323 at gmail.com> wrote:

> Hello:
> 
> I am implementing a high-level protocol which requires the use of
> various cryptographic primitives. I have the following goals in mind:
> 
> 1. Allow others to extend the library to use different underlying
> crypto implementations, ciphers, curves, etc, and
> 2. Have the library be well-typed so that cryptographic operations are
> unambiguous, leading to code which can be easily audited.
> 
> According to the spec, the user is allowed to instantiate the protocol
> with any combination of supported ciphers and curves, but the
> high-level operations always remain the same regardless of what
> primitives are used. 
> 
> Pursuant to the above goals, I've defined two typeclasses, "Cipher" and
> "Curve". I'm using TypeFamilies to facilitate the creation of data
> types that are independent of the underlying crypto library.
> 
> The Cipher typeclass is as follows:
> 
> class Cipher c
> where                                                                           
>  data Ciphertext   c :: *                                                                     
>  data SymmetricKey c :: *                                                                     
>  data Nonce        c :: *                                                                     
>  data Digest       c :: *                                                                     
> 
>  cipherName       :: c -> ByteString
>  cipherEncrypt    :: SymmetricKey c -> Nonce c -> AssocData -> Plaintext -> Ciphertext c
>  cipherDecrypt    :: SymmetricKey c -> Nonce c -> AssocData -> Ciphertext c -> Maybe Plaintext
>  cipherZeroNonce  :: Nonce c        
>  cipherIncNonce   :: Nonce c -> Nonce c                         
>  cipherGetKey     :: SymmetricKey c -> Nonce c -> SymmetricKey c
>  cipherHashToKey  :: Digest c -> SymmetricKey c
>  cipherHashToAD   :: Digest c -> AssocData
>  cipherHash       :: ScrubbedBytes -> Digest c
>  cipherConcatHash :: Digest c -> ScrubbedBytes -> Digest c
>  cipherHMAC       :: SymmetricKey c -> ScrubbedBytes -> Digest c
> 
> newtype Plaintext = Plaintext ScrubbedBytes
> newtype AssocData = AssocData ScrubbedBytes
> 
> Unfortunately, the spec as written assumes that all variables are blobs
> of bytes. The issue I'm running in to is that, in my goal to have
> everything well-typed, my typeclasses are filling up with conversion
> functions like "cipherHashToKey" and "cipherHashToAD". These type
> conversions are necessary because I'm required to compute values like
> "HMAC-HASH(GETKEY(k, n), data)" (which returns "Digest c") and assign
> it to a variable whose type is "SymmetricKey c" (hence the need for
> cipherHashToKey).
> 
> Is all my effort to write a well-typed library being done in vain?
> Should I just give up and have all the functions use ByteStrings?
> 
> -- 
> Alex
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe


From alex323 at gmail.com  Thu Oct  8 16:57:17 2015
From: alex323 at gmail.com (Alex)
Date: Thu, 8 Oct 2015 12:57:17 -0400
Subject: [Haskell-cafe] Well-typed design issue
In-Reply-To: <B5307922-2F38-4C73-A230-FE7A710BF4C5@cis.upenn.edu>
References: <20151008094852.55a67308@gmail.com>
 <B5307922-2F38-4C73-A230-FE7A710BF4C5@cis.upenn.edu>
Message-ID: <20151008125717.1c8c7d92@gmail.com>

On Thu, 8 Oct 2015 12:51:00 -0400
Richard Eisenberg <eir at cis.upenn.edu> wrote:

> What's going wrong? It looks like you're off to a solid start here.
> 
> I don't know about these cryptographic primitives you speak of, but
> it sounds like the type conversion functions you're railing against
> are indeed necessary -- that is, they perform a runtime action. So
> where's the problem? Richly typed interfaces are sometimes more
> verbose (especially when you're just setting things up), but you're
> getting safety guarantees for that payment.
> 
> Richard
> 

After a discussion with Cale in #haskell, I've been convinced of the
point that you're making. The reason I was feeling uneasy was because I
incorrectly equated verbosity to inelegance.

-- 
Alex

From eir at cis.upenn.edu  Thu Oct  8 17:05:24 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Thu, 8 Oct 2015 13:05:24 -0400
Subject: [Haskell-cafe] Support for library improvement
In-Reply-To: <874mi15uta.fsf@smart-cactus.org>
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
Message-ID: <069629CD-C350-4B75-A6AB-CC98404A8039@cis.upenn.edu>


On Oct 8, 2015, at 9:55 AM, Ben Gamari <ben at smart-cactus.org> wrote:

>  With a few changes to our treatment of warnings
> and some new pragmas (aimed at library authors), we can greatly reduce
> the impact that library interface changes have on users.

My loose following of the interweaved threads has led me to this same conclusion. Have you paid close enough attention to list exactly what these changes should be? I have not. But I'd love to find a general solution to the migration problem so that we can continue to tinker with our beloved language without fear of flames burning down the house.

Richard



From mike at proclivis.com  Thu Oct  8 17:14:18 2015
From: mike at proclivis.com (Michael Jones)
Date: Thu, 8 Oct 2015 11:14:18 -0600
Subject: [Haskell-cafe] Failing to catch exception
In-Reply-To: <CAPeieQE1LKUg1a_rmReK017Xgka0qSxsNregTznmN5LfG5RWAw@mail.gmail.com>
References: <305E198E-C7A6-4D29-8E5C-A54334C631D6@proclivis.com>
 <CAPeieQE1LKUg1a_rmReK017Xgka0qSxsNregTznmN5LfG5RWAw@mail.gmail.com>
Message-ID: <690B3420-3146-4D1D-9800-F72443356D58@proclivis.com>

Erik,

deepseq was the trick. It was not front of mind that a catch would not enforce evaluation, as it ?naturally" is supposed to catch. Retuned my intuition :-)

Mike


> On Oct 8, 2015, at 7:41 AM, Erik Hesselink <hesselink at gmail.com> wrote:
> 
> Perhaps the value you're calculating is lazily computed, so the
> exception occurs only when using it, and by then you're already
> outside the catch? Try forcing things with `seq` or `deepseq` and see
> if that helps in catching the exception.
> 
> Erik
> 
> On 8 October 2015 at 15:26, Michael Jones <mike at proclivis.com> wrote:
>> 
>> I?m having trouble with an exception that won?t catch and looking for suggestions. Basically, a ?fail? inside a ?catch? inside a unsafeIOToSTM, inside a wx callback, trying to catch SomeException or IOException.
>> 
>> Details:
>> 
>> I?m using Text.Regex.PCRE
>> 
>> and the exception comes from a ?fail" in unwrap:
>> 
>> unwrap :: (Show e) => Either e v -> IO v
>> unwrap x = case x of Left err -> fail ("Text.Regex.PCRE.String died: "++ show err)
>>                    Right v -> return v
>> 
>> The catch is in this function, catching SomeException:
>> 
>> filterTableRow _ record fils = do
>>   s <- showRecord record
>>   vs <- Control.Exception.catch (
>>             return $ map (\(fil,col) -> let fil' = if fil == "" then "^" else fil in
>>                                                    ((splitOn "," s)!!(fromIntegral (col+1))) =~ fil') (elems fils)
>>             )
>>             ((\e -> do return $ replicate (length $ elems fils) False) :: SomeException -> IO [Bool])
>>   return $ foldl (.&.) True vs
>> 
>> filterTableRow is called from an unsafeIOToSTM:
>> 
>> unsafeIOToSTM $ filterTableRow gridData row? fil
>> 
>> which is called from a wx callback from a button press
>> 
>> Before I added the catch, the application was working for over a year, so there is no general problem, All I added was the catch.
>> 
>> Adding -xc to the ghc runtime shows the error:
>> 
>> *** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace:
>> Text.Regex.PCRE.String.matchTest,
>> called from Text.Regex.PCRE.String.unwrap,
>> ?
>> user error (Text.Regex.PCRE.String died: (4,"unmatched parentheses"))
>> 
>> 
>> Which indicates the text in unwrap, as if the exception is not caught. I have tried to catch it as IOException, and SomeException.
>> 
>> Any ideas why it is not caught or some way to debug it?
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe



From mike at proclivis.com  Thu Oct  8 17:22:18 2015
From: mike at proclivis.com (Michael Jones)
Date: Thu, 8 Oct 2015 11:22:18 -0600
Subject: [Haskell-cafe] Failing to catch exception
In-Reply-To: <CAPeieQE1LKUg1a_rmReK017Xgka0qSxsNregTznmN5LfG5RWAw@mail.gmail.com>
References: <305E198E-C7A6-4D29-8E5C-A54334C631D6@proclivis.com>
 <CAPeieQE1LKUg1a_rmReK017Xgka0qSxsNregTznmN5LfG5RWAw@mail.gmail.com>
Message-ID: <48338709-4FF7-47E5-98A3-6FF6786ADF31@proclivis.com>

Erik,

Ok, I need some conceptual help on this one. If the action ?in" the catch is not evaluated, I would think the catch itself cannot be fully evaluated. Once IO demands the value from the work ?in? the catch, how can it escape the catch?

To me it seemed like the exception triggered the death of the wx callback without an evaluation of the catch, like the runtime let it escape.

Mike

> On Oct 8, 2015, at 7:41 AM, Erik Hesselink <hesselink at gmail.com> wrote:
> 
> Perhaps the value you're calculating is lazily computed, so the
> exception occurs only when using it, and by then you're already
> outside the catch? Try forcing things with `seq` or `deepseq` and see
> if that helps in catching the exception.
> 
> Erik
> 
> On 8 October 2015 at 15:26, Michael Jones <mike at proclivis.com> wrote:
>> 
>> I?m having trouble with an exception that won?t catch and looking for suggestions. Basically, a ?fail? inside a ?catch? inside a unsafeIOToSTM, inside a wx callback, trying to catch SomeException or IOException.
>> 
>> Details:
>> 
>> I?m using Text.Regex.PCRE
>> 
>> and the exception comes from a ?fail" in unwrap:
>> 
>> unwrap :: (Show e) => Either e v -> IO v
>> unwrap x = case x of Left err -> fail ("Text.Regex.PCRE.String died: "++ show err)
>>                    Right v -> return v
>> 
>> The catch is in this function, catching SomeException:
>> 
>> filterTableRow _ record fils = do
>>   s <- showRecord record
>>   vs <- Control.Exception.catch (
>>             return $ map (\(fil,col) -> let fil' = if fil == "" then "^" else fil in
>>                                                    ((splitOn "," s)!!(fromIntegral (col+1))) =~ fil') (elems fils)
>>             )
>>             ((\e -> do return $ replicate (length $ elems fils) False) :: SomeException -> IO [Bool])
>>   return $ foldl (.&.) True vs
>> 
>> filterTableRow is called from an unsafeIOToSTM:
>> 
>> unsafeIOToSTM $ filterTableRow gridData row? fil
>> 
>> which is called from a wx callback from a button press
>> 
>> Before I added the catch, the application was working for over a year, so there is no general problem, All I added was the catch.
>> 
>> Adding -xc to the ghc runtime shows the error:
>> 
>> *** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace:
>> Text.Regex.PCRE.String.matchTest,
>> called from Text.Regex.PCRE.String.unwrap,
>> ?
>> user error (Text.Regex.PCRE.String died: (4,"unmatched parentheses"))
>> 
>> 
>> Which indicates the text in unwrap, as if the exception is not caught. I have tried to catch it as IOException, and SomeException.
>> 
>> Any ideas why it is not caught or some way to debug it?
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe



From mike at proclivis.com  Thu Oct  8 17:55:15 2015
From: mike at proclivis.com (Michael Jones)
Date: Thu, 8 Oct 2015 11:55:15 -0600
Subject: [Haskell-cafe] Failing to catch exception
In-Reply-To: <48338709-4FF7-47E5-98A3-6FF6786ADF31@proclivis.com>
References: <305E198E-C7A6-4D29-8E5C-A54334C631D6@proclivis.com>
 <CAPeieQE1LKUg1a_rmReK017Xgka0qSxsNregTznmN5LfG5RWAw@mail.gmail.com>
 <48338709-4FF7-47E5-98A3-6FF6786ADF31@proclivis.com>
Message-ID: <C46CE4C2-A9A6-4A8E-852B-7B4BC615C2E2@proclivis.com>

This was in a draft that got sent by accident. No help needed. I understand why deepseq fixes the problem.


> On Oct 8, 2015, at 11:22 AM, Michael Jones <mike at proclivis.com> wrote:
> 
> Erik,
> 
> Ok, I need some conceptual help on this one. If the action ?in" the catch is not evaluated, I would think the catch itself cannot be fully evaluated. Once IO demands the value from the work ?in? the catch, how can it escape the catch?
> 
> To me it seemed like the exception triggered the death of the wx callback without an evaluation of the catch, like the runtime let it escape.
> 
> Mike
> 



From mail at joachim-breitner.de  Thu Oct  8 18:05:43 2015
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 08 Oct 2015 20:05:43 +0200
Subject: [Haskell-cafe] Support for library improvement
In-Reply-To: <069629CD-C350-4B75-A6AB-CC98404A8039@cis.upenn.edu>
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <069629CD-C350-4B75-A6AB-CC98404A8039@cis.upenn.edu>
Message-ID: <1444327543.21428.6.camel@joachim-breitner.de>

Hi,

Am Donnerstag, den 08.10.2015, 13:05 -0400 schrieb Richard Eisenberg:
> On Oct 8, 2015, at 9:55 AM, Ben Gamari <ben at smart-cactus.org> wrote:
> >  With a few changes to our treatment of warnings
> > and some new pragmas (aimed at library authors), we can greatly
> > reduce
> > the impact that library interface changes have on users.
> 
> My loose following of the interweaved threads has led me to this same 
> conclusion. Have you paid close enough attention to list exactly what 
> these changes should be? I have not. But I'd love to find a general 
> solution to the migration problem so that we can continue to tinker 
> with our beloved language without fear of flames burning down the 
> house.

how willing are we to make the compiler smarter and more complicate to
make sure old code does what it originally meant to do, as long as it
is among the (large number close to 100)% common case?

For example, in this case (as was suggested in some trac ticket, I
believe), ignore a method definition for a method that
 * is no longer in the class and
 * where a normal function is in scope and
 * these are obvious equivalent
where obvious may mean various things, depending on our needs.

One could think this further: If the compiler sees a set of Applicative
and Monad instances for the same type in the same module, and it has
"return = something useful" and "pure = return", can?t it just do what
we expect everyone to do manually and change that to "pure = something
useful" and remove return?

In other words, can we replace pain and hassle for a lot of people by
implementation work (and future maintenance cost) for one or a few
people?

Or will that lead to another hell where code does no longer mean what
it says?

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151008/c06527b5/attachment.sig>

From nicola.gigante at gmail.com  Thu Oct  8 18:24:28 2015
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Thu, 8 Oct 2015 20:24:28 +0200
Subject: [Haskell-cafe] Interfacing with the GHC runtime from a library
Message-ID: <2D70B8F4-55AD-46ED-84BF-EA942A2DAD03@gmail.com>

Hi everybody,

suppose to have an Haskell library which is in part implemented in C
for whatever reason. Can the C part talk with the runtime, in particular
the scheduler? In other words, does the runtime expose the functionality
needed to implement, for example, the STM library from outside the GHC
runtime itself?

Thank you,
Nicola

From defigueiredo at ucdavis.edu  Thu Oct  8 18:32:13 2015
From: defigueiredo at ucdavis.edu (Dimitri DeFigueiredo)
Date: Thu, 8 Oct 2015 12:32:13 -0600
Subject: [Haskell-cafe] Well-typed design issue
In-Reply-To: <20151008094852.55a67308@gmail.com>
References: <20151008094852.55a67308@gmail.com>
Message-ID: <5616B6AD.5060504@ucdavis.edu>

The cryptographic building blocks we use every day (e.g. blockciphers, 
symmetric encryption schemes, message authentication schemes, etc) have 
been formalized. I suggest the library follows the mathematical notions. 
A good place to see the definitions of the cryptographic building blocks 
are Phil Rogaway's lecture notes [1].

For example, there are 2 types of ciphers: blockciphers and 
streamciphers. A blockcipher is family of permutations, but a cipher is 
a distinct thing from a symmetric encryption scheme. I would say they 
have different types. You can build a symmetric encryption scheme using:
1. a blockcipher;
2. a mode of operation (such as Cipher-Block-Chaining, a.k.a CBC); and,
3. a random number (a nonce).

Blockciphers are also distinct from message authentication schemes. The 
most famous message authentication scheme is HMAC. It can use a variety 
of underlying hash functions (such as SHA1, SHA256, etc).

With this in mind, I find it that the classes you propose should 
separate the concepts as they have been formalized. Here's a first rough 
pass at a reorg:

class SymEncryptionScheme c where
     data Ciphertext   c :: *
     data SymmetricKey c :: *
     data Nonce        c :: *
     data Plaintext   c :: *
     KeyGenerationAlgo :: Int -> IO (SymmetricKey c) -- this is 
necessarily probabilistic
     EncryptionAlgo :: Nonce c -> SymmetricKey c -> Plaintext c -> 
Ciphertext c
     DecryptionAlgo :: SymmetricKey c -> Ciphertext c -> Plaintext c

class Blockcipher c where
     data PlaintextBlock      c :: *
     data CiphertextBlock   c :: *
     data SymmetricKey      c :: *
     blockSize :: c -> Int
     encipher :: SymmetricKey c -> PlaintextBlock c -> CiphertextBlock c
     decipher :: SymmetricKey c -> CiphertextBlock c -> PlaintextBlock c

class MAC c where
     data Plaintext  c :: *
     data MessageDigest c :: *
     data SymmetricKey c :: *
     HashFunction :: Plaintext c -> MessageDigest c
     mac :: SymmetricKey c -> Plaintext c -> MessageDigest c

class HashFunction f where
     data inputBlock f :: *
     data ouputBlock f :: *
     compressionFunction :: inputBlock f -> inputBlock f -> ouputBlock f
     padding :: ...
     hash :: ...

I think it is a great idea to use the types to makes sure those building 
blocks are assembled together in ways that make sense. I have a feeling 
constraints will come in handy.

Hope this helps,


Dimitri


[1] http://cseweb.ucsd.edu/~mihir/cse207/classnotes.html



On 10/8/15 7:48 AM, Alex wrote:
> Hello:
>
> I am implementing a high-level protocol which requires the use of
> various cryptographic primitives. I have the following goals in mind:
>
> 1. Allow others to extend the library to use different underlying
> crypto implementations, ciphers, curves, etc, and
> 2. Have the library be well-typed so that cryptographic operations are
> unambiguous, leading to code which can be easily audited.
>
> According to the spec, the user is allowed to instantiate the protocol
> with any combination of supported ciphers and curves, but the
> high-level operations always remain the same regardless of what
> primitives are used.
>
> Pursuant to the above goals, I've defined two typeclasses, "Cipher" and
> "Curve". I'm using TypeFamilies to facilitate the creation of data
> types that are independent of the underlying crypto library.
>
> The Cipher typeclass is as follows:
>
> class Cipher c
> where
>    data Ciphertext   c :: *
>    data SymmetricKey c :: *
>    data Nonce        c :: *
>    data Digest       c :: *
>
>    cipherName       :: c -> ByteString
>    cipherEncrypt    :: SymmetricKey c -> Nonce c -> AssocData -> Plaintext -> Ciphertext c
>    cipherDecrypt    :: SymmetricKey c -> Nonce c -> AssocData -> Ciphertext c -> Maybe Plaintext
>    cipherZeroNonce  :: Nonce c
>    cipherIncNonce   :: Nonce c -> Nonce c
>    cipherGetKey     :: SymmetricKey c -> Nonce c -> SymmetricKey c
>    cipherHashToKey  :: Digest c -> SymmetricKey c
>    cipherHashToAD   :: Digest c -> AssocData
>    cipherHash       :: ScrubbedBytes -> Digest c
>    cipherConcatHash :: Digest c -> ScrubbedBytes -> Digest c
>    cipherHMAC       :: SymmetricKey c -> ScrubbedBytes -> Digest c
>
> newtype Plaintext = Plaintext ScrubbedBytes
> newtype AssocData = AssocData ScrubbedBytes
>
> Unfortunately, the spec as written assumes that all variables are blobs
> of bytes. The issue I'm running in to is that, in my goal to have
> everything well-typed, my typeclasses are filling up with conversion
> functions like "cipherHashToKey" and "cipherHashToAD". These type
> conversions are necessary because I'm required to compute values like
> "HMAC-HASH(GETKEY(k, n), data)" (which returns "Digest c") and assign
> it to a variable whose type is "SymmetricKey c" (hence the need for
> cipherHashToKey).
>
> Is all my effort to write a well-typed library being done in vain?
> Should I just give up and have all the functions use ByteStrings?
>


From michael at orlitzky.com  Thu Oct  8 18:52:58 2015
From: michael at orlitzky.com (Michael Orlitzky)
Date: Thu, 8 Oct 2015 14:52:58 -0400
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <874mi15uta.fsf@smart-cactus.org>
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
Message-ID: <5616BB8A.1080807@orlitzky.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/08/2015 09:55 AM, Ben Gamari wrote:
> Michael Orlitzky <michael at orlitzky.com> writes:
> 
>> (replying to no one in particular)
>> 
>> This problem isn't specific to Haskell. In every other language,
>> you have projects that support major versions of toolkits,
>> compilers, libraries and whatnot. And there's already a tool for
>> it: git.
>> 
>> Instead of using #ifdef to handle four different compilers, keep
>> a branch for each. Git is designed to make this easy, and it's
>> usually trivial to merge changes from the master branch back into
>> e.g. the ghc-7.8 branch. That way the code in your master branch
>> stays clean. When you want to stop supporting an old GHC, delete
>> that branch.
>> 
> I don't find this option terribly appealing. As a maintainer I
> would far prefer maintaining a bit of CPP than a proliferation of
> branches, with all of the cherry-picking and potential code
> divergence that they bring.

It's really not that bad. You only need a separate branch when things
are actually incompatible, so while you may support four versions of
GHC, you might only need two branches.

And the difference between the branches should be exactly what you
have wrapped in an #ifdef right now:

  a) If you're modifying something in an #ifdef, then the change only
     goes in one branch, and you don't have to cherry-pick anything.

  b) If the change wouldn't fall within an #ifdef, then it affects code
     common to all your branches, and the merge will be trivial.

It's annoying to have to do that for every change, so don't. Keep a
pile of common changes in your master branch, and then rebase/merge
the other branches right before you make a release.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJWFruJXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxNEU5RDcyRDdCMUFGREVGQzBCNDFDMUY2
RjQ4RDNEQTA1QzJEQURCAAoJEG9I09oFwtrbPB0P/37UFFBHqgN/Pspr26bdK4Hp
j5TdF5RqP8BeiBg/shJyc1xrq4uB2wQZfrExCwfXssJYz+/Cuiw77MSYkay/ks3s
LemyT6wIAypmjDOKHwzXw9mWU7oS9iL3CSPvZB07HLB4JNHpzBC0hAx3ZuMucyg7
xWFWgmlR5i1k069OCs+dgkfXotyt0zGtt17pw8YbX3X29/SOy9Y4K3+L6kfV8pOW
dN/3/DIDakBDfLLLJG/pc57xq5GnTd77sCLNHrheWkybB3leW9t00Zq4erjBDyWt
O7eO1jjTHoTo/S1iDWYGiy6zPI1dI+jDowUDLrZfIeAURw81ymqbfQlujwqoLB4j
kWnaBDpT5JDhKZ3ZMWOcPtCGlUGbXIYh986s22jXfRhvO0dFNwwhbQOQdQMEUN74
XCggw4APIAHnA7lfg2s33bVOJr/d8XumnOCHD+7IEWYc+25lDWr42Ens7LOVJzv1
COh3JKAPbbWFpwmU2yKdowomiZglNZj9QW27e7x33ZU0rLITS2CdV/zmY5TLqf4S
v40jJcQMt2ZSCW0X8HBpHdGG6tQxUWcYZR8kpbxoaoQgwwqYa+vN0aXyMd5tG3Bp
cHyTDfya+Kt6lVa23kvs2YPXjUAXvSnoSBL646gpYvRvrx6L+T7Dd9UUNFGNg+8k
+Dw1hH2mSYJ852ZreY9e
=qH2g
-----END PGP SIGNATURE-----

From josh3light at gmail.com  Thu Oct  8 19:10:57 2015
From: josh3light at gmail.com (Joshua Jordan)
Date: Thu, 8 Oct 2015 15:10:57 -0400
Subject: [Haskell-cafe] minimizing overhead between c/c++ and Haskell
Message-ID: <CAAszXdLZqo9e7z8oO6dEzRA9JsdU5Dw5Ox45NOY+vLyyomN2nw@mail.gmail.com>

I've been learning Haskell recently and I'm interested in exploring whether
something I have in mind is feasible. I have several projects similar to
the one below, this is just one example:

I have written a plug-in for an existing software (which manages it's own
threading, memory, etc).  The plug-in interface is in c++ and is wrapped in
an extern c call for the final connection to the software.

The actual plugin is rather functional in nature, and at its core simply
accepts float, int, and string values, does a certain amount of internal
processing based on input criteria, and returns float values as a result.
I'd like to re-factor it one day, so instead of doing it in c++, it would
be interesting to rewrite my plug-in with the logic and structure (with
memoization, etc) of the internal processing in Haskell, which is called
from the other executable.  The processing will be called by the c/c++
threads many millions of times in one run, so perhaps the overhead of
separate processes and interprocess communication would be too great, and
I'd hope for minimal time overhead between the c/c++ and Haskell calls.

I imagine the process might go something like this, after looking over the
documentation (Using the FFI with GHC):

------------------------------
--------

-the c/c++ plug-in initializes the GHC runtime in a set-up step

-- begin call: repeated many millions of times
-the c/c++ threads call the haskell function
-the haskell function returns a value to the c/c++ threads
-- end calls

-after everything is finished, the c/c++ plug-in uninitializes the GHC
runtime

--------------------------------------

So before attempting this, my questions would be:
1)  What do you guys think the overhead in this situation would be?
2)  Would you suggest exploring anything besides what I've mentioned, and
am I missing anything?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151008/4a082137/attachment.html>

From davidleothomas at gmail.com  Thu Oct  8 21:12:41 2015
From: davidleothomas at gmail.com (David Thomas)
Date: Thu, 8 Oct 2015 14:12:41 -0700
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <5616BB8A.1080807@orlitzky.com>
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <5616BB8A.1080807@orlitzky.com>
Message-ID: <CAJUDvciWQuABPg+OzNEwnKkq95V0X683k5x=bH66GHEYkYx32Q@mail.gmail.com>

Right.  With a nest of #ifdefs, you still have the same number of
branches (at least - there may be some combinations of options that
you don't support and it won't be obvious), they're just implicit and
harder to work with.

On Thu, Oct 8, 2015 at 11:52 AM, Michael Orlitzky <michael at orlitzky.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 10/08/2015 09:55 AM, Ben Gamari wrote:
>> Michael Orlitzky <michael at orlitzky.com> writes:
>>
>>> (replying to no one in particular)
>>>
>>> This problem isn't specific to Haskell. In every other language,
>>> you have projects that support major versions of toolkits,
>>> compilers, libraries and whatnot. And there's already a tool for
>>> it: git.
>>>
>>> Instead of using #ifdef to handle four different compilers, keep
>>> a branch for each. Git is designed to make this easy, and it's
>>> usually trivial to merge changes from the master branch back into
>>> e.g. the ghc-7.8 branch. That way the code in your master branch
>>> stays clean. When you want to stop supporting an old GHC, delete
>>> that branch.
>>>
>> I don't find this option terribly appealing. As a maintainer I
>> would far prefer maintaining a bit of CPP than a proliferation of
>> branches, with all of the cherry-picking and potential code
>> divergence that they bring.
>
> It's really not that bad. You only need a separate branch when things
> are actually incompatible, so while you may support four versions of
> GHC, you might only need two branches.
>
> And the difference between the branches should be exactly what you
> have wrapped in an #ifdef right now:
>
>   a) If you're modifying something in an #ifdef, then the change only
>      goes in one branch, and you don't have to cherry-pick anything.
>
>   b) If the change wouldn't fall within an #ifdef, then it affects code
>      common to all your branches, and the merge will be trivial.
>
> It's annoying to have to do that for every change, so don't. Keep a
> pile of common changes in your master branch, and then rebase/merge
> the other branches right before you make a release.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0
>
> iQJ8BAEBCgBmBQJWFruJXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxNEU5RDcyRDdCMUFGREVGQzBCNDFDMUY2
> RjQ4RDNEQTA1QzJEQURCAAoJEG9I09oFwtrbPB0P/37UFFBHqgN/Pspr26bdK4Hp
> j5TdF5RqP8BeiBg/shJyc1xrq4uB2wQZfrExCwfXssJYz+/Cuiw77MSYkay/ks3s
> LemyT6wIAypmjDOKHwzXw9mWU7oS9iL3CSPvZB07HLB4JNHpzBC0hAx3ZuMucyg7
> xWFWgmlR5i1k069OCs+dgkfXotyt0zGtt17pw8YbX3X29/SOy9Y4K3+L6kfV8pOW
> dN/3/DIDakBDfLLLJG/pc57xq5GnTd77sCLNHrheWkybB3leW9t00Zq4erjBDyWt
> O7eO1jjTHoTo/S1iDWYGiy6zPI1dI+jDowUDLrZfIeAURw81ymqbfQlujwqoLB4j
> kWnaBDpT5JDhKZ3ZMWOcPtCGlUGbXIYh986s22jXfRhvO0dFNwwhbQOQdQMEUN74
> XCggw4APIAHnA7lfg2s33bVOJr/d8XumnOCHD+7IEWYc+25lDWr42Ens7LOVJzv1
> COh3JKAPbbWFpwmU2yKdowomiZglNZj9QW27e7x33ZU0rLITS2CdV/zmY5TLqf4S
> v40jJcQMt2ZSCW0X8HBpHdGG6tQxUWcYZR8kpbxoaoQgwwqYa+vN0aXyMd5tG3Bp
> cHyTDfya+Kt6lVa23kvs2YPXjUAXvSnoSBL646gpYvRvrx6L+T7Dd9UUNFGNg+8k
> +Dw1hH2mSYJ852ZreY9e
> =qH2g
> -----END PGP SIGNATURE-----
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

From taruti at taruti.net  Thu Oct  8 22:05:34 2015
From: taruti at taruti.net (Taru Karttunen)
Date: Fri, 9 Oct 2015 01:05:34 +0300
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAJUDvciWQuABPg+OzNEwnKkq95V0X683k5x=bH66GHEYkYx32Q@mail.gmail.com>
References: <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <5616BB8A.1080807@orlitzky.com>
 <CAJUDvciWQuABPg+OzNEwnKkq95V0X683k5x=bH66GHEYkYx32Q@mail.gmail.com>
Message-ID: <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local>

On 08.10 14:12, David Thomas wrote:
> Right.  With a nest of #ifdefs, you still have the same number of
> branches (at least - there may be some combinations of options that
> you don't support and it won't be obvious), they're just implicit and
> harder to work with.

Have you got an example of a library that works with branches
for GHC-versions while maintaining feature-parity across
branches with a versioning scheme that works in practice with
Hackage?

- Taru Karttunen

From hyarion at iinet.net.au  Thu Oct  8 22:32:32 2015
From: hyarion at iinet.net.au (Ben)
Date: Fri, 09 Oct 2015 09:32:32 +1100
Subject: [Haskell-cafe] Support for library improvement
In-Reply-To: <1444327543.21428.6.camel@joachim-breitner.de>
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <069629CD-C350-4B75-A6AB-CC98404A8039@cis.upenn.edu>
 <1444327543.21428.6.camel@joachim-breitner.de>
Message-ID: <2602C21F-2BF5-4D93-A136-002561F8BC1B@iinet.net.au>

I like the idea of a separate translator that understands how to make the obvious changes required by such minor improvements (remove/add definitions of return, remove/add imports of Applicative, etc), and having that applied by cabal when the code is built.

Then library authors could write normal code conforming to *one* release, instead of figuring out the clever import gymnastics or CPP required to code simultaneously against several almost-compatible interfaces (or forking).

Some meta data in a cabal file could hopefully be all you need to allow your code to be adjustible forward or backward a few dialects.

On 9 October 2015 5:05:43 am AEDT, Joachim Breitner <mail at joachim-breitner.de> wrote:
>Hi,
>
>Am Donnerstag, den 08.10.2015, 13:05 -0400 schrieb Richard Eisenberg:
>> On Oct 8, 2015, at 9:55 AM, Ben Gamari <ben at smart-cactus.org> wrote:
>> >  With a few changes to our treatment of warnings
>> > and some new pragmas (aimed at library authors), we can greatly
>> > reduce
>> > the impact that library interface changes have on users.
>> 
>> My loose following of the interweaved threads has led me to this same
>
>> conclusion. Have you paid close enough attention to list exactly what
>
>> these changes should be? I have not. But I'd love to find a general 
>> solution to the migration problem so that we can continue to tinker 
>> with our beloved language without fear of flames burning down the 
>> house.
>
>how willing are we to make the compiler smarter and more complicate to
>make sure old code does what it originally meant to do, as long as it
>is among the (large number close to 100)% common case?
>
>For example, in this case (as was suggested in some trac ticket, I
>believe), ignore a method definition for a method that
> * is no longer in the class and
> * where a normal function is in scope and
> * these are obvious equivalent
>where obvious may mean various things, depending on our needs.
>
>One could think this further: If the compiler sees a set of Applicative
>and Monad instances for the same type in the same module, and it has
>"return = something useful" and "pure = return", can?t it just do what
>we expect everyone to do manually and change that to "pure = something
>useful" and remove return?
>
>In other words, can we replace pain and hassle for a lot of people by
>implementation work (and future maintenance cost) for one or a few
>people?
>
>Or will that lead to another hell where code does no longer mean what
>it says?
>
>Greetings,
>Joachim
>
>-- 
>Joachim ?nomeata? Breitner
>  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
>  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
>  Debian Developer: nomeata at debian.org
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Haskell-Cafe mailing list
>Haskell-Cafe at haskell.org
>http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151009/a307b1c8/attachment.html>

From davidleothomas at gmail.com  Fri Oct  9 00:34:03 2015
From: davidleothomas at gmail.com (David Thomas)
Date: Thu, 8 Oct 2015 17:34:03 -0700
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local>
References: <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <5616BB8A.1080807@orlitzky.com>
 <CAJUDvciWQuABPg+OzNEwnKkq95V0X683k5x=bH66GHEYkYx32Q@mail.gmail.com>
 <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local>
Message-ID: <CAJUDvcjr4n3ftUOdzaLPS1puRPYODpPq0f5DMMGuOisMtpRh+A@mail.gmail.com>

No, and I'm not sure just how well existing Hackage tooling/process
matches the workflow (due mostly to ignorance of existing Hackage
tooling/process).  To the degree that there's a mismatch, it may have
reason sufficient to abandon the approach - or it may suggest
improvements to tooling/process.

On Thu, Oct 8, 2015 at 3:05 PM, Taru Karttunen <taruti at taruti.net> wrote:
> On 08.10 14:12, David Thomas wrote:
>> Right.  With a nest of #ifdefs, you still have the same number of
>> branches (at least - there may be some combinations of options that
>> you don't support and it won't be obvious), they're just implicit and
>> harder to work with.
>
> Have you got an example of a library that works with branches
> for GHC-versions while maintaining feature-parity across
> branches with a versioning scheme that works in practice with
> Hackage?
>
> - Taru Karttunen

From ok at cs.otago.ac.nz  Fri Oct  9 00:36:27 2015
From: ok at cs.otago.ac.nz (Richard A. O'Keefe)
Date: Fri, 9 Oct 2015 13:36:27 +1300
Subject: [Haskell-cafe] Support for library improvement
In-Reply-To: <1444327543.21428.6.camel@joachim-breitner.de>
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <069629CD-C350-4B75-A6AB-CC98404A8039@cis.upenn.edu>
 <1444327543.21428.6.camel@joachim-breitner.de>
Message-ID: <02340601-50A8-4017-94C8-84D9DFC854CC@cs.otago.ac.nz>


On 9/10/2015, at 7:05 am, Joachim Breitner <mail at joachim-breitner.de> wrote:

> For example, in this case (as was suggested in some trac ticket, I
> believe), ignore a method definition for a method that
> * is no longer in the class and
> * where a normal function is in scope and
> * these are obvious equivalent
> where obvious may mean various things, depending on our needs.
> ...
> Or will that lead to another hell where code does no longer mean what
> it says?

One help for avoiding that hell is for the compiler never to
deviate from the apparent semantics of the code without SHOUTING
about what it's doing.

There is also a big difference between the compiler adapting code
written for an old interface and tampering with code written for
a new interface, even if both involve the same actions on the
compiler's part.  The former may be helpful, the latter not.

I have long felt that version and dependency information should
be in a source file.  Arguably, the various language pragmas
sort of do that for *language* aspects.  When the compiler *knows*
what language version a module was written for and which library
versions, there are many possibilities:
 - refuse to compile code that's too old
 - quietly compile the code under the old rules
 - noisily compile the code under the old rules
 - quietly adapt the code to the new rules
 - noisily adapt the code to the new rules

Speaking only for myself, dealing with the change in my own code
is not going to be a big deal, because it affects the monads I
*define*, not the monads I *use*.  The main thing I need is very
clear warning messages from the compiler.


From eir at cis.upenn.edu  Fri Oct  9 01:31:38 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Thu, 8 Oct 2015 21:31:38 -0400
Subject: [Haskell-cafe] Support for library improvement
In-Reply-To: <069629CD-C350-4B75-A6AB-CC98404A8039@cis.upenn.edu>
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <069629CD-C350-4B75-A6AB-CC98404A8039@cis.upenn.edu>
Message-ID: <D0AD3181-EB1B-4168-87B0-173257272BCA@cis.upenn.edu>



On Oct 8, 2015, at 1:05 PM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> 
> My loose following of the interweaved threads has led me to this same conclusion. Have you paid close enough attention to list exactly what these changes should be? I have not. But I'd love to find a general solution to the migration problem so that we can continue to tinker with our beloved language without fear of flames burning down the house.

I should have been more explicit. I was more thinking of a multi-tiered warning system, where we decide, as a community, not to be embarrassed by warnings of severity less than X. When putting a DEPRECATED pragma on a definition, we could then give an indication of how soon we expect the definition to be gone.

I was not thinking of the sort of "smart" behavior that Joachim wrote about. I want my programs to do exactly what I say -- compilers should only be so clever.

Richard

From ok at cs.otago.ac.nz  Fri Oct  9 03:10:24 2015
From: ok at cs.otago.ac.nz (Richard A. O'Keefe)
Date: Fri, 9 Oct 2015 16:10:24 +1300
Subject: [Haskell-cafe] Monad of no `return` Proposal
In-Reply-To: <201510052259.t95MxLKS013731@coolidge.cs.Dartmouth.EDU>
References: <201510052259.t95MxLKS013731@coolidge.cs.Dartmouth.EDU>
Message-ID: <DE247FE2-13B3-43CE-ADF8-F2758612FCE6@cs.otago.ac.nz>


On 6/10/2015, at 11:59 am, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> 
> Another trick is to use plain if rather than #if or #ifdef,
> and let the compiler optimize away the unwanted side of the
> branch.

The University of Edinburgh had their own systems implementation
language, IMP.  Fortran -> Algol 60 -> Atlas Autocode -> IMP.
It was no surprise to find that
    %if <constant condition> %then <true part> %else <false part>
eliminated whichever branch would not be executed.
But it was astonishing to discover that
    %if <constant condition> %then %start
        <declarations T>
    %finish %else %start
        <declarations F>
    %finish
would only process the declarations in the chosen part.
If you want to eliminate the preprocessor, you have got
to handle conditional declarations.

Even IMP did not handle

    %record %format table (
        ...
        %if keeping statistics %then %start
            %integer accesses, hits, misses,
        %endif
        ...)

which is something that a preprocessor can handle.



From ok at cs.otago.ac.nz  Fri Oct  9 03:18:19 2015
From: ok at cs.otago.ac.nz (Richard A. O'Keefe)
Date: Fri, 9 Oct 2015 16:18:19 +1300
Subject: [Haskell-cafe] Monad of no `return` Proposal
In-Reply-To: <87lhbgl5lb.fsf@feelingofgreen.ru>
References: <201510052259.t95MxLKS013731@coolidge.cs.Dartmouth.EDU>
 <87lhbgl5lb.fsf@feelingofgreen.ru>
Message-ID: <2053594A-C0F7-4A45-B794-7654C12E7342@cs.otago.ac.nz>


On 6/10/2015, at 10:16 pm, Kosyrev Serge <_deepfire at feelingofgreen.ru> wrote:
> As an example of the opposite end, consider Common Lisp, which:
> 
>  1. reifies READ as the third processing phase (macroexpansion[1] and actual
>     compilation being the other two)
>  2. operates at expression granularity
>  3. makes the full power of the language available to support the
>     decision process of what subexpressions are available in which
>     contexts

Except that the syntax for conditional reading in Common Lisp,
    #+ <feature> <datum>
    #- <feature> <datum>
(a) is utterly different from conditional evaluation,
    like (if <expr> <expr> <expr>).
(b) does NOT make the full power of the language available.
    The feature test is a Boolean combination, using and, or, not
    of atoms, where the value of an atom is true iff it is a
    member of *features* (the asterisks are part of the name).



From trupill at gmail.com  Fri Oct  9 06:57:57 2015
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Fri, 9 Oct 2015 08:57:57 +0200
Subject: [Haskell-cafe] Support for library improvement
In-Reply-To: <D0AD3181-EB1B-4168-87B0-173257272BCA@cis.upenn.edu>
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <069629CD-C350-4B75-A6AB-CC98404A8039@cis.upenn.edu>
 <D0AD3181-EB1B-4168-87B0-173257272BCA@cis.upenn.edu>
Message-ID: <CAHnFXOurt5iSNXtQOfSEsdJVPPdY4N13HcM5CqPu33ib7K6TNA@mail.gmail.com>

I would like to throw something to the discussion. In UHC's build system a
tool called Shuffle is used:
http://foswiki.cs.uu.nl/foswiki/Ehc/ShuffleDocumentation

It has three nice properties which I think could fit well with the problem:
- You can define variants of code with given numbers and names, and then
ask the tool to produce the output file. Something a bit better than CPP
itself.
- It understands some Haskell semantics. In particular, you can state
functions imported or exported by each chunk (see
http://foswiki.cs.uu.nl/foswiki/Ehc/ShuffleDocumentation#A_1.2_Output_specific_configuration)
and the tool takes care of building up the module declaration on top of the
file.
- It ships with a hook to integrate with Cabal (
https://hackage.haskell.org/package/shuffle-0.1.3.3/docs/Distribution-Simple-Shuffle.html
).

Just my two cents.

2015-10-09 3:31 GMT+02:00 Richard Eisenberg <eir at cis.upenn.edu>:

>
>
> On Oct 8, 2015, at 1:05 PM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> >
> > My loose following of the interweaved threads has led me to this same
> conclusion. Have you paid close enough attention to list exactly what these
> changes should be? I have not. But I'd love to find a general solution to
> the migration problem so that we can continue to tinker with our beloved
> language without fear of flames burning down the house.
>
> I should have been more explicit. I was more thinking of a multi-tiered
> warning system, where we decide, as a community, not to be embarrassed by
> warnings of severity less than X. When putting a DEPRECATED pragma on a
> definition, we could then give an indication of how soon we expect the
> definition to be gone.
>
> I was not thinking of the sort of "smart" behavior that Joachim wrote
> about. I want my programs to do exactly what I say -- compilers should only
> be so clever.
>
> Richard
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151009/e23851a5/attachment.html>

From svenpanne at gmail.com  Fri Oct  9 07:29:12 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Fri, 9 Oct 2015 09:29:12 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAJUDvcjr4n3ftUOdzaLPS1puRPYODpPq0f5DMMGuOisMtpRh+A@mail.gmail.com>
References: <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <5616BB8A.1080807@orlitzky.com>
 <CAJUDvciWQuABPg+OzNEwnKkq95V0X683k5x=bH66GHEYkYx32Q@mail.gmail.com>
 <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local>
 <CAJUDvcjr4n3ftUOdzaLPS1puRPYODpPq0f5DMMGuOisMtpRh+A@mail.gmail.com>
Message-ID: <CANBN=mvy6iMOTFzYX989CtDuvoJ4r5VKRVEjDr5B+yu6AhQ4jA@mail.gmail.com>

2015-10-09 2:34 GMT+02:00 David Thomas <davidleothomas at gmail.com>:

> No, and I'm not sure just how well existing Hackage tooling/process
> matches the workflow (due mostly to ignorance of existing Hackage
> tooling/process).  To the degree that there's a mismatch, it may have
> reason sufficient to abandon the approach - or it may suggest
> improvements to tooling/process.
>

To be honest,  I can't really see how git can help with the versioning
issue at all. Let's think backwards: In the end, you must give your
compiler a single version of your code which works with. The common
solution for this is to run something before the actual compilation stage
(preprocessing), which picks the right parts from a single source. Let
assume that we don't want this preprocessing step, then you still have to
give your compiler a single correct version of your sources. How do you
want to accomplish that? Shipping separate source packages (be it via
Hackage or through some other means) for each version? This would be
maintenance hell and much work, especially when there is no 1:1
correspondence between branches and compilers/libraries (as was proposed
above). Furthermore, having to remember which stuff has been merged where,
solving merge conflicts, introducing new branches when compilers/libraries
change, etc. etc. requires extensive bookkeeping beyond git, to such an
extent that larger companies normally have several people working full-time
on such non-technical stuff. This is definitely not the way to go when you
want to encourage people to work on their free time in Haskell.

In a nutshell: IMHO having #ifdefs in the code is the lesser evil. If
somebody has a better, actually working idea, he can probably become a
millionaire quickly by selling this to the industry...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151009/afe96962/attachment.html>

From _deepfire at feelingofgreen.ru  Fri Oct  9 09:00:09 2015
From: _deepfire at feelingofgreen.ru (Kosyrev Serge)
Date: Fri, 09 Oct 2015 12:00:09 +0300
Subject: [Haskell-cafe] Monad of no `return` Proposal
In-Reply-To: <2053594A-C0F7-4A45-B794-7654C12E7342@cs.otago.ac.nz>
 (sfid-20151009_074130_948575_0200F98E) (Richard A. O'Keefe's message
 of "Fri, 9 Oct 2015 16:18:19 +1300")
References: <201510052259.t95MxLKS013731@coolidge.cs.Dartmouth.EDU>
 <87lhbgl5lb.fsf@feelingofgreen.ru>
 <2053594A-C0F7-4A45-B794-7654C12E7342@cs.otago.ac.nz>
Message-ID: <87pp0ofmcm.fsf@feelingofgreen.ru>

"Richard A. O'Keefe" <ok at cs.otago.ac.nz> writes:
> On 6/10/2015, at 10:16 pm, Kosyrev Serge <_deepfire at feelingofgreen.ru> wrote:
>> As an example of the opposite end, consider Common Lisp, which:
>> 
>>  1. reifies READ as the third processing phase (macroexpansion[1] and actual
>>     compilation being the other two)
>>  2. operates at expression granularity
>>  3. makes the full power of the language available to support the
>>     decision process of what subexpressions are available in which
>>     contexts
>
> Except that the syntax for conditional reading in Common Lisp,
>     #+ <feature> <datum>
>     #- <feature> <datum>
>
> (a) is utterly different from conditional evaluation,
>     like (if <expr> <expr> <expr>).
> (b) does NOT make the full power of the language available.
>     The feature test is a Boolean combination, using and, or, not
>     of atoms, where the value of an atom is true iff it is a
>     member of *features* (the asterisks are part of the name).

There are several issues mixed up here:

 1. Desirability of expression-level granularity of pre-processing.

 2. The desired palette of options for this pre-processing (if desired),
    that varies in expressive power.

 3. The difference between #+/#- and #. (aka *READ-EVAL*,
    http://clhs.lisp.se/Body/v_rd_eva.htm) in Common Lisp.

My original message was about point #1, but point #2 deserves a similar
kind of attention.

The point #3 is purely didactic -- the READ-time processing is layered
in Common Lisp into:

  1. the basic layer, covering 95% of cases, which uses the following primitives,
     to decide if an expression suffix needs to be included:

     - *FEATURES*, a variable containing a list of features
     - ability to test for presence of a certain symbol within *FEATURES*
     - ability to combine atomic tests using AND, OR, NOT 

     It is, indeed, what is covered in the example that I have provided.

  2. the full language layer, available through #. -- whatever is returned
     by the expression following #. is inserted as program text.

This layered approach has some merit:

  - It provides a kind of frugal brevity, that is sufficient in 95% of cases

  - Whenever the soft option fails, it unleashes the whole language to
    express basically anything during that pre-processing phase.

Except, in the latter case it /probably/ doesn't count as pre-processing anymore,
since the inserted text is no longer external to the pre-processor directives.

-- 
? ???????e? / respectfully,
??????? ??????
--
?And those who were seen dancing were thought to be insane
 by those who could not hear the music.?
 ? Friedrich Wilhelm Nietzsche

From robstewart57 at gmail.com  Fri Oct  9 11:30:57 2015
From: robstewart57 at gmail.com (Rob Stewart)
Date: Fri, 9 Oct 2015 12:30:57 +0100
Subject: [Haskell-cafe] Time performance with inlining and space performance
	with newtype?
Message-ID: <CA+ZOasLYfVaKFy9s+98fzoqFC_3RpvLAo9JcbtjWM9rzq4KvRg@mail.gmail.com>

Hi,

I'm in search of clarifications and descriptions about code
optimisations that are recommended in GHC docs, regarding inlining and
newtype vs data.

1. Inlining small and often used functions

See https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/pragmas.html
, Section "7.22.6.1. INLINE pragma". It says:

"GHC tries to inline functions/values that are 'small enough', thus
avoiding the call overhead and possibly exposing other more-wonderful
optimisations."

I understand the reason for function inlining with other languages
like C, as it avoids the construction of new stack frames and
coordinating stack pointers for each function call. In Haskell, rather
than call stack we've got evaluation stacks.

Here are my questions: what exactly is the call overhead of a
non-inlned Haskell function? What additional runtime work needs to
happen when calling to a non-inlined function? Specifically what other
GHC optimisations are possible only if function inlining happens
first? Can anyone provide a simple example where 1) a function is not
inlined, versus 2) when that function is inlined, which demonstrates
two things: 1) a GHC report of the additional optimisations that were
applied because of inlining and 2) shorter program runtime as a result
of inlining.

2. Calculating the memory costs of a data type

As Don Stewart nicely explains on SO
http://stackoverflow.com/a/5889784/1526266 , we should always use
newtype when we have only a single constructor which has a single
field. His example is this:

    data Book = Book Int Int
    newtype Book = Book (Int, Int)

With newtype, the `Book` construct is guaranteed to be erased at
compile time, to have the same representation as `(Int,Int)`. How to I
measure the memory space costs of having `Book Int Int` hanging around
at runtime, as opposed to just `(Int,Int)`? How many bytes does it
cost to store `Book 4 5`? How many bytes does it cost to store `(4,5)`
? Can I ask GHC to tell me how many bytes the storage of each object
would require? Or more generally, would looking at GHC Core for all my
data structures inform me of the memory space costs for each of them?

Thanks

--
Rob

From blamario at ciktel.net  Fri Oct  9 12:57:17 2015
From: blamario at ciktel.net (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=)
Date: Fri, 9 Oct 2015 08:57:17 -0400
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CANBN=mvy6iMOTFzYX989CtDuvoJ4r5VKRVEjDr5B+yu6AhQ4jA@mail.gmail.com>
References: <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <5616BB8A.1080807@orlitzky.com>
 <CAJUDvciWQuABPg+OzNEwnKkq95V0X683k5x=bH66GHEYkYx32Q@mail.gmail.com>
 <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local>
 <CAJUDvcjr4n3ftUOdzaLPS1puRPYODpPq0f5DMMGuOisMtpRh+A@mail.gmail.com>
 <CANBN=mvy6iMOTFzYX989CtDuvoJ4r5VKRVEjDr5B+yu6AhQ4jA@mail.gmail.com>
Message-ID: <5617B9AD.90703@ciktel.net>

On 10/09/2015 03:29 AM, Sven Panne wrote:
> 2015-10-09 2:34 GMT+02:00 David Thomas <davidleothomas at gmail.com 
> <mailto:davidleothomas at gmail.com>>:
>
>     No, and I'm not sure just how well existing Hackage tooling/process
>     matches the workflow (due mostly to ignorance of existing Hackage
>     tooling/process).  To the degree that there's a mismatch, it may have
>     reason sufficient to abandon the approach - or it may suggest
>     improvements to tooling/process.
>
>
> To be honest,  I can't really see how git can help with the versioning 
> issue at all. Let's think backwards: In the end, you must give your 
> compiler a single version of your code which works with. The common 
> solution for this is to run something before the actual compilation 
> stage (preprocessing), which picks the right parts from a single 
> source. Let assume that we don't want this preprocessing step, then 
> you still have to give your compiler a single correct version of your 
> sources. How do you want to accomplish that? Shipping separate source 
> packages (be it via Hackage or through some other means) for each version?

     Via Hackage. Let's say my-package is at version 1.7.2 as far as 
features and bug fixes go; Hackage would then host my-package-1.7.2.708 
and my-package-1.7.2.710. The former is uploaded by running cabal upload 
on branch ghc-7.8 of the source repository, the latter on branch 
ghc-7.10. The main difference between the branches would be in the 
.cabal file:

on ghc-7.8 branch

    version: my-package-1.7.2.708
    build-depends: ghc <= 7.8.*,


on ghc-7.10 branch

    version: my-package-1.7.2.710
    build-depends: ghc == 7.10.*,

     You can do this with no extra tooling, the only extra work is to 
run seven commands instead of one at publishing time:

    git checkout ghc-7.8
    git merge master
    cabal upload
    git checkout ghc-7.10
    git merge master
    cabal upload
    git checkout master

     Obviously it would be better to script this, or even to add support 
directly to cabal-install and stack.

> This would be maintenance hell and much work, especially when there is 
> no 1:1 correspondence between branches and compilers/libraries (as was 
> proposed above). Furthermore, having to remember which stuff has been 
> merged where, solving merge conflicts, introducing new branches when 
> compilers/libraries change, etc. etc. requires extensive bookkeeping 
> beyond git, to such an extent that larger companies normally have 
> several people working full-time on such non-technical stuff. This is 
> definitely not the way to go when you want to encourage people to work 
> on their free time in Haskell.

     I really don't see what could possibly cause all that complexity. 
Conflicts between different GHC branches and master development branch 
should be minimal, with any care.


> In a nutshell: IMHO having #ifdefs in the code is the lesser evil. If 
> somebody has a better, actually working idea, he can probably become a 
> millionaire quickly by selling this to the industry...

     The industry can be remarkably reluctant to take up a new idea; 
nobody has ever been fired for using #ifdef.


From sumit.sahrawat.apm13 at iitbhu.ac.in  Fri Oct  9 13:01:26 2015
From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing,
 IIT (BHU))
Date: Fri, 9 Oct 2015 18:31:26 +0530
Subject: [Haskell-cafe] Time performance with inlining and space
 performance with newtype?
In-Reply-To: <CA+ZOasLYfVaKFy9s+98fzoqFC_3RpvLAo9JcbtjWM9rzq4KvRg@mail.gmail.com>
References: <CA+ZOasLYfVaKFy9s+98fzoqFC_3RpvLAo9JcbtjWM9rzq4KvRg@mail.gmail.com>
Message-ID: <CAJbEW8Ozu9qF6sz0YBaGnrqAFn+KYBSihVyMKDqgnqfjHPR59w@mail.gmail.com>

I can only answer the questions to the best of my understanding, here goes:

On 9 October 2015 at 17:00, Rob Stewart <robstewart57 at gmail.com> wrote:
>
> Here are my questions: what exactly is the call overhead of a
> non-inlned Haskell function? What additional runtime work needs to
> happen when calling to a non-inlined function? Specifically what other
> GHC optimisations are possible only if function inlining happens
> first? Can anyone provide a simple example where 1) a function is not
> inlined, versus 2) when that function is inlined, which demonstrates
> two things: 1) a GHC report of the additional optimisations that were
> applied because of inlining and 2) shorter program runtime as a result
> of inlining.


An example of optimizations becoming available after inlining:

listAdd1 = map (+1)
listAdd2 = map (+2)

listAdd3 = listAdd2 . listAdd1

-- From the RHS of listAdd3
   listAdd2 . listAdd1
== map (+2) . map (+1)
== map ((+2) . (+1))         -- List fusion. Also works for types other
than lists (see the talk [1] for more)
== map (\x -> (+2) ((+1) x)) -- Inline the composition dot-operator (.)
== map (\x -> (+2) (x + 1))
== map (\x -> x + 3)
== map (+3)

-- The order and the final result might not be the same, but it will be
operationally equivalent.
-- This prevents having to iterate over the whole list twice.


On 9 October 2015 at 17:00, Rob Stewart <robstewart57 at gmail.com> wrote:
>
> As Don Stewart nicely explains on SO
> http://stackoverflow.com/a/5889784/1526266 , we should always use
> newtype when we have only a single constructor which has a single
> field. His example is this:
>
>     data Book = Book Int Int
>     newtype Book = Book (Int, Int)
>
> With newtype, the `Book` construct is guaranteed to be erased at
> compile time, to have the same representation as `(Int,Int)`. How to I
> measure the memory space costs of having `Book Int Int` hanging around
> at runtime, as opposed to just `(Int,Int)`? How many bytes does it
> cost to store `Book 4 5`? How many bytes does it cost to store `(4,5)`
> ? Can I ask GHC to tell me how many bytes the storage of each object
> would require? Or more generally, would looking at GHC Core for all my
> data structures inform me of the memory space costs for each of them?
>

I don't think it's possible to look into GHC's memory. Simon Marlow's book
[2] explains laziness very well, but even he (he wrote the GHC runtime)
says that there is no way to see the actual structure of memory usage.

[1]: http://www.techcast.com/events/bigtechday6/odeon-1130/?q=odeon-1130
[2]: http://amzn.com/1449335942

-- 
Regards

Sumit Sahrawat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151009/abc7fdc7/attachment.html>

From svenpanne at gmail.com  Fri Oct  9 13:42:49 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Fri, 9 Oct 2015 15:42:49 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <5617B9AD.90703@ciktel.net>
References: <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <5616BB8A.1080807@orlitzky.com>
 <CAJUDvciWQuABPg+OzNEwnKkq95V0X683k5x=bH66GHEYkYx32Q@mail.gmail.com>
 <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local>
 <CAJUDvcjr4n3ftUOdzaLPS1puRPYODpPq0f5DMMGuOisMtpRh+A@mail.gmail.com>
 <CANBN=mvy6iMOTFzYX989CtDuvoJ4r5VKRVEjDr5B+yu6AhQ4jA@mail.gmail.com>
 <5617B9AD.90703@ciktel.net>
Message-ID: <CANBN=mtjPsuFsNkm6=mxb=ixtDdHqbqCHoSfvhsvo53=U8rC5A@mail.gmail.com>

2015-10-09 14:57 GMT+02:00 Mario Bla?evi? <blamario at ciktel.net>:

> [...] You can do this with no extra tooling, the only extra work is to run
> seven commands instead of one at publishing time:
>
>    git checkout ghc-7.8
>    git merge master
>    cabal upload
>    git checkout ghc-7.10
>    git merge master
>    cabal upload
>    git checkout master
>

Let's pray that no merge conflicts will happen. Furthermore, you've omitted
the "git push"s to github to let Travis CI tell you what you've forgot. You
should better do that before an upload. Ooops, and you forgot to tag the
release, too (I mean 7 tags)...


> [...] I really don't see what could possibly cause all that complexity.
> Conflicts between different GHC branches and master development branch
> should be minimal, with any care.


For toy stuff you might be right, but in any larger project I've seen in
the last decades, keeping branches well maintained *is* non-trivial.
Normally you already have branches for different releases of your SW you
still have to maintain, and with the proposed approach you would
effectively multiply the number of those branches by the number of
supported platforms/compilers. Much fun proposing that to your manager...
This might work if you have only linear development and few platforms, but
otherwise it won't scale.

Furthermore, having #ifdef-free code is a non-goal in itself: The goal we
talk about is ease of maintenance, and as it's proposed, it makes a
maintainer's life harder, not easier (you need much more steps +
bookkeeping). And the merges e.g. only work automatically when the change
in the #ifdef'd code would be trivial, too (adding/removing lines, etc.),
so git doesn't offer any advantage.


> In a nutshell: IMHO having #ifdefs in the code is the lesser evil. If
>> somebody has a better, actually working idea, he can probably become a
>> millionaire quickly by selling this to the industry...
>>
>
>     The industry can be remarkably reluctant to take up a new idea; nobody
> has ever been fired for using #ifdef.


If you can provably speed up development time and/or release cycles,
selling new ideas is easy: Nobody has been fired for reaching a deadline
too early. OTOH making some work easier and at the same time other work
more complicated (as is the case in the proposal) will meet some
resistance...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151009/0693c5cd/attachment.html>

From anselm.scholl at tu-harburg.de  Fri Oct  9 13:48:06 2015
From: anselm.scholl at tu-harburg.de (Jonas Scholl)
Date: Fri, 9 Oct 2015 15:48:06 +0200
Subject: [Haskell-cafe] Time performance with inlining and space
 performance with newtype?
In-Reply-To: <CA+ZOasLYfVaKFy9s+98fzoqFC_3RpvLAo9JcbtjWM9rzq4KvRg@mail.gmail.com>
References: <CA+ZOasLYfVaKFy9s+98fzoqFC_3RpvLAo9JcbtjWM9rzq4KvRg@mail.gmail.com>
Message-ID: <5617C596.4080000@tu-harburg.de>

On 10/09/2015 01:30 PM, Rob Stewart wrote:
> Hi,
> 
> I'm in search of clarifications and descriptions about code
> optimisations that are recommended in GHC docs, regarding inlining and
> newtype vs data.
> 
> 1. Inlining small and often used functions
> 
> See https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/pragmas.html
> , Section "7.22.6.1. INLINE pragma". It says:
> 
> "GHC tries to inline functions/values that are 'small enough', thus
> avoiding the call overhead and possibly exposing other more-wonderful
> optimisations."
> 
> I understand the reason for function inlining with other languages
> like C, as it avoids the construction of new stack frames and
> coordinating stack pointers for each function call. In Haskell, rather
> than call stack we've got evaluation stacks.

I am not an expert, but I can try to share my understanding of the issue.

For one, you have the possibility for other optimisations. Consider:

addThree :: Int -> Int -> Int
addThree a b c = a + b + c

This is compiled to the following core (simplified):

addThree = \ a b c -> (+) $dNum_Int ((+) $dNum_Int a b) c

(+) is a record selector for the Num dictionary. By inlining (+) and
$dNum_Int we get this core:

add_Int = \ a b -> case a of
	I# a# -> case b of
		I# b# -> I# (a# +# b#)

addThree = \ a b c -> add_Int (add_Int a b) c

where Int is defined as
data Int = I# Int#

and (+#) implements primitive (C-like) addition and has type Int# ->
Int# -> Int#.

add_Int is again a small function and we inline it:

addThree = \ a b c -> add_Int (case a of
	I# a# -> case b of
		I# b# -> I# (a# +# b#)) c

So now we can see the code allocates an Int (the I# constructor) only to
pattern match on it immediately again. If we inline the second
occurrence of add_Int, we get this:

addThree = \ a b c -> case (case a of
	I# a# -> case b of
		I# b# -> I# (a# +# b#)) of
	I# a' -> case c of
		I# c# -> I# (a' +# c#)

Now we can not inline further, but the simplifier can apply
transformations it couldn't do previously. For example it can apply the
case-of-case transformation:

addThree = \ a b c -> case a of
	I# a# -> case b of
		I# b# -> case I# (a# +# b#) of
			I# a' -> case c of
				I# c# -> I# (a' +# c#)

Now it sees it can eliminate the I# constructor:

addThree = \ a b c -> case a of
	I# a# -> case b of
		I# b# -> case a# +# b# of
			a' -> case c of
				I# c# -> I# (a' +# c#)

I think GHC now floats the addition to its usage site, so we get:

addThree = \ a b c -> case a of
	I# a# -> case b of
		I# b# -> case c of
			I# c# -> I# ((a# +# b#) +# c#)

So inlining did not only save some function calls, but we also avoided
to allocate a boxed Int value.

> 
> Here are my questions: what exactly is the call overhead of a
> non-inlned Haskell function? What additional runtime work needs to
> happen when calling to a non-inlined function? Specifically what other
> GHC optimisations are possible only if function inlining happens
> first? Can anyone provide a simple example where 1) a function is not
> inlined, versus 2) when that function is inlined, which demonstrates
> two things: 1) a GHC report of the additional optimisations that were
> applied because of inlining and 2) shorter program runtime as a result
> of inlining.

As I tried to show in the above example, its not about the call
overhead, but additional possible simplifications. Inlining a function
can make polymorphic arguments monomorphic and provides the possibility
to inline other small functions. It can further expose combinations of
functions used for list- or stream-fusion (many fusing functions are
implemented as unstream . streamedOp . stream with a rule stream .
unsteam = id). Without inlining, fusion would not work at all.

> 
> 2. Calculating the memory costs of a data type
> 
> As Don Stewart nicely explains on SO
> http://stackoverflow.com/a/5889784/1526266 , we should always use
> newtype when we have only a single constructor which has a single
> field. His example is this:
> 
>     data Book = Book Int Int
>     newtype Book = Book (Int, Int)
> 
> With newtype, the `Book` construct is guaranteed to be erased at
> compile time, to have the same representation as `(Int,Int)`. How to I
> measure the memory space costs of having `Book Int Int` hanging around
> at runtime, as opposed to just `(Int,Int)`? How many bytes does it
> cost to store `Book 4 5`? How many bytes does it cost to store `(4,5)`
> ? Can I ask GHC to tell me how many bytes the storage of each object
> would require? Or more generally, would looking at GHC Core for all my
> data structures inform me of the memory space costs for each of them?

There is no difference in your example. Consider instead

data BookD = BookD Int
newtype BookN = BookN Int

BookD consumes 2 pointers (info pointer and pointer to the boxed Int)
while BookN has only the size of a boxed Int (a pointer and a machine
word for the Int# stored in the boxed Int). So by using a newtype you
save 2 pointers and an additional indirection. It also changes the
semantics of the code: Because a newtype is "free", it has to be strict
in its one and only field. So if you evaluate BookD undefined to WHNF,
you will get no exception while evaluating BookN undefined will throw an
exception.

Back to your example: Here we have either a constructor with two fields,
so we need three pointers to store the object (one for the info
pointer), or we have a tuple, which also contains two pointers, so it is
again three pointers large. The only difference is the newtype can reuse
the already existing info table for the (,) data type while the Book
data type needs its own info table, so we save a few bytes of generated
code (if at all, I do not know if GHC reuses info tables in such a
situation).

> 
> Thanks
> 

You're welcome.

> --
> Rob
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> 



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151009/9cbb4da7/attachment.sig>

From robstewart57 at gmail.com  Fri Oct  9 14:06:32 2015
From: robstewart57 at gmail.com (Rob Stewart)
Date: Fri, 9 Oct 2015 15:06:32 +0100
Subject: [Haskell-cafe] Time performance with inlining and space
	performance with newtype?
In-Reply-To: <CA+ZOasLYfVaKFy9s+98fzoqFC_3RpvLAo9JcbtjWM9rzq4KvRg@mail.gmail.com>
References: <CA+ZOasLYfVaKFy9s+98fzoqFC_3RpvLAo9JcbtjWM9rzq4KvRg@mail.gmail.com>
Message-ID: <CA+ZOasJ5EKDsJqXRNRv66e_+GEk-noh57EX9zv2WE6UrXLhD0A@mail.gmail.com>

To add third case:

1. which optimising GHC passes does SPECIALIZE enable? Taking the
example from the GHC docs
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/pragmas.html#specialize-pragma
:

    hammeredLookup :: Ord key => [(key, value)] -> key -> value
    {-# SPECIALIZE hammeredLookup :: [(Widget, value)] -> Widget -> value #-}

This means that the type class dictionary for Ord will not be passed
as a (hidden) argument in Core to `hammeredLookup` when Widget is the
key. The GHC docs about overloading
https://wiki.haskell.org/Performance/Overloading says "The presence of
overloading can prevent many other optimisations, such as Strictness,
from kicking in". So we lose the strictness GHC optimiser in the
absence of SPECIALIZE rules on overloaded functions. Other than
strictness analysis, what other GHC optimisations are being missed
when overloading is not dealt with using monomorphism? And what are
the specific runtime overheads of passing type class constraints as
dictionaries to overloaded functions at runtime?

--
Rob


On 9 October 2015 at 12:30, Rob Stewart <robstewart57 at gmail.com> wrote:
> Hi,
>
> I'm in search of clarifications and descriptions about code
> optimisations that are recommended in GHC docs, regarding inlining and
> newtype vs data.
>
> 1. Inlining small and often used functions
>
> See https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/pragmas.html
> , Section "7.22.6.1. INLINE pragma". It says:
>
> "GHC tries to inline functions/values that are 'small enough', thus
> avoiding the call overhead and possibly exposing other more-wonderful
> optimisations."
>
> I understand the reason for function inlining with other languages
> like C, as it avoids the construction of new stack frames and
> coordinating stack pointers for each function call. In Haskell, rather
> than call stack we've got evaluation stacks.
>
> Here are my questions: what exactly is the call overhead of a
> non-inlned Haskell function? What additional runtime work needs to
> happen when calling to a non-inlined function? Specifically what other
> GHC optimisations are possible only if function inlining happens
> first? Can anyone provide a simple example where 1) a function is not
> inlined, versus 2) when that function is inlined, which demonstrates
> two things: 1) a GHC report of the additional optimisations that were
> applied because of inlining and 2) shorter program runtime as a result
> of inlining.
>
> 2. Calculating the memory costs of a data type
>
> As Don Stewart nicely explains on SO
> http://stackoverflow.com/a/5889784/1526266 , we should always use
> newtype when we have only a single constructor which has a single
> field. His example is this:
>
>     data Book = Book Int Int
>     newtype Book = Book (Int, Int)
>
> With newtype, the `Book` construct is guaranteed to be erased at
> compile time, to have the same representation as `(Int,Int)`. How to I
> measure the memory space costs of having `Book Int Int` hanging around
> at runtime, as opposed to just `(Int,Int)`? How many bytes does it
> cost to store `Book 4 5`? How many bytes does it cost to store `(4,5)`
> ? Can I ask GHC to tell me how many bytes the storage of each object
> would require? Or more generally, would looking at GHC Core for all my
> data structures inform me of the memory space costs for each of them?
>
> Thanks
>
> --
> Rob

From michael at orlitzky.com  Fri Oct  9 14:09:59 2015
From: michael at orlitzky.com (Michael Orlitzky)
Date: Fri, 9 Oct 2015 10:09:59 -0400
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CANBN=mtjPsuFsNkm6=mxb=ixtDdHqbqCHoSfvhsvo53=U8rC5A@mail.gmail.com>
References: <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <5616BB8A.1080807@orlitzky.com>
 <CAJUDvciWQuABPg+OzNEwnKkq95V0X683k5x=bH66GHEYkYx32Q@mail.gmail.com>
 <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local>
 <CAJUDvcjr4n3ftUOdzaLPS1puRPYODpPq0f5DMMGuOisMtpRh+A@mail.gmail.com>
 <CANBN=mvy6iMOTFzYX989CtDuvoJ4r5VKRVEjDr5B+yu6AhQ4jA@mail.gmail.com>
 <5617B9AD.90703@ciktel.net>
 <CANBN=mtjPsuFsNkm6=mxb=ixtDdHqbqCHoSfvhsvo53=U8rC5A@mail.gmail.com>
Message-ID: <5617CAB7.4070507@orlitzky.com>

On 10/09/2015 09:42 AM, Sven Panne wrote:
> 
> For toy stuff you might be right, but in any larger project I've seen in
> the last decades, keeping branches well maintained *is* non-trivial.
> Normally you already have branches for different releases of your SW you
> still have to maintain, and with the proposed approach you would
> effectively multiply the number of those branches by the number of
> supported platforms/compilers. Much fun proposing that to your
> manager... This might work if you have only linear development and few
> platforms, but otherwise it won't scale.
> 
> Furthermore, having #ifdef-free code is a non-goal in itself: The goal
> we talk about is ease of maintenance, and as it's proposed, it makes a
> maintainer's life harder, not easier (you need much more steps +
> bookkeeping). And the merges e.g. only work automatically when the
> change in the #ifdef'd code would be trivial, too (adding/removing
> lines, etc.), so git doesn't offer any advantage.
>  

It works, everyone else already does it, the complexity is there whether
you branch or not, you'll never have merge conflicts, etc. I'm not sure
how much effort you want me to expend convincing you to improve your
life. I don't have this problem.

Go try it instead of arguing that it can't possibly work.


From robstewart57 at gmail.com  Fri Oct  9 14:16:04 2015
From: robstewart57 at gmail.com (Rob Stewart)
Date: Fri, 9 Oct 2015 15:16:04 +0100
Subject: [Haskell-cafe] Time performance with inlining and space
 performance with newtype?
In-Reply-To: <5617C596.4080000@tu-harburg.de>
References: <CA+ZOasLYfVaKFy9s+98fzoqFC_3RpvLAo9JcbtjWM9rzq4KvRg@mail.gmail.com>
 <5617C596.4080000@tu-harburg.de>
Message-ID: <CA+ZOasLKgUQtwmq2g9WOP0Q1j4kUJjPoGOkVEx0YEtr0UvAJUQ@mail.gmail.com>

Thank you Jonas, both answers were very nicely explained!


On 9 October 2015 at 14:48, Jonas Scholl <anselm.scholl at tu-harburg.de> wrote:
> On 10/09/2015 01:30 PM, Rob Stewart wrote:
>> Hi,
>>
>> I'm in search of clarifications and descriptions about code
>> optimisations that are recommended in GHC docs, regarding inlining and
>> newtype vs data.
>>
>> 1. Inlining small and often used functions
>>
>> See https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/pragmas.html
>> , Section "7.22.6.1. INLINE pragma". It says:
>>
>> "GHC tries to inline functions/values that are 'small enough', thus
>> avoiding the call overhead and possibly exposing other more-wonderful
>> optimisations."
>>
>> I understand the reason for function inlining with other languages
>> like C, as it avoids the construction of new stack frames and
>> coordinating stack pointers for each function call. In Haskell, rather
>> than call stack we've got evaluation stacks.
>
> I am not an expert, but I can try to share my understanding of the issue.
>
> For one, you have the possibility for other optimisations. Consider:
>
> addThree :: Int -> Int -> Int
> addThree a b c = a + b + c
>
> This is compiled to the following core (simplified):
>
> addThree = \ a b c -> (+) $dNum_Int ((+) $dNum_Int a b) c
>
> (+) is a record selector for the Num dictionary. By inlining (+) and
> $dNum_Int we get this core:
>
> add_Int = \ a b -> case a of
>         I# a# -> case b of
>                 I# b# -> I# (a# +# b#)
>
> addThree = \ a b c -> add_Int (add_Int a b) c
>
> where Int is defined as
> data Int = I# Int#
>
> and (+#) implements primitive (C-like) addition and has type Int# ->
> Int# -> Int#.
>
> add_Int is again a small function and we inline it:
>
> addThree = \ a b c -> add_Int (case a of
>         I# a# -> case b of
>                 I# b# -> I# (a# +# b#)) c
>
> So now we can see the code allocates an Int (the I# constructor) only to
> pattern match on it immediately again. If we inline the second
> occurrence of add_Int, we get this:
>
> addThree = \ a b c -> case (case a of
>         I# a# -> case b of
>                 I# b# -> I# (a# +# b#)) of
>         I# a' -> case c of
>                 I# c# -> I# (a' +# c#)
>
> Now we can not inline further, but the simplifier can apply
> transformations it couldn't do previously. For example it can apply the
> case-of-case transformation:
>
> addThree = \ a b c -> case a of
>         I# a# -> case b of
>                 I# b# -> case I# (a# +# b#) of
>                         I# a' -> case c of
>                                 I# c# -> I# (a' +# c#)
>
> Now it sees it can eliminate the I# constructor:
>
> addThree = \ a b c -> case a of
>         I# a# -> case b of
>                 I# b# -> case a# +# b# of
>                         a' -> case c of
>                                 I# c# -> I# (a' +# c#)
>
> I think GHC now floats the addition to its usage site, so we get:
>
> addThree = \ a b c -> case a of
>         I# a# -> case b of
>                 I# b# -> case c of
>                         I# c# -> I# ((a# +# b#) +# c#)
>
> So inlining did not only save some function calls, but we also avoided
> to allocate a boxed Int value.
>
>>
>> Here are my questions: what exactly is the call overhead of a
>> non-inlned Haskell function? What additional runtime work needs to
>> happen when calling to a non-inlined function? Specifically what other
>> GHC optimisations are possible only if function inlining happens
>> first? Can anyone provide a simple example where 1) a function is not
>> inlined, versus 2) when that function is inlined, which demonstrates
>> two things: 1) a GHC report of the additional optimisations that were
>> applied because of inlining and 2) shorter program runtime as a result
>> of inlining.
>
> As I tried to show in the above example, its not about the call
> overhead, but additional possible simplifications. Inlining a function
> can make polymorphic arguments monomorphic and provides the possibility
> to inline other small functions. It can further expose combinations of
> functions used for list- or stream-fusion (many fusing functions are
> implemented as unstream . streamedOp . stream with a rule stream .
> unsteam = id). Without inlining, fusion would not work at all.
>
>>
>> 2. Calculating the memory costs of a data type
>>
>> As Don Stewart nicely explains on SO
>> http://stackoverflow.com/a/5889784/1526266 , we should always use
>> newtype when we have only a single constructor which has a single
>> field. His example is this:
>>
>>     data Book = Book Int Int
>>     newtype Book = Book (Int, Int)
>>
>> With newtype, the `Book` construct is guaranteed to be erased at
>> compile time, to have the same representation as `(Int,Int)`. How to I
>> measure the memory space costs of having `Book Int Int` hanging around
>> at runtime, as opposed to just `(Int,Int)`? How many bytes does it
>> cost to store `Book 4 5`? How many bytes does it cost to store `(4,5)`
>> ? Can I ask GHC to tell me how many bytes the storage of each object
>> would require? Or more generally, would looking at GHC Core for all my
>> data structures inform me of the memory space costs for each of them?
>
> There is no difference in your example. Consider instead
>
> data BookD = BookD Int
> newtype BookN = BookN Int
>
> BookD consumes 2 pointers (info pointer and pointer to the boxed Int)
> while BookN has only the size of a boxed Int (a pointer and a machine
> word for the Int# stored in the boxed Int). So by using a newtype you
> save 2 pointers and an additional indirection. It also changes the
> semantics of the code: Because a newtype is "free", it has to be strict
> in its one and only field. So if you evaluate BookD undefined to WHNF,
> you will get no exception while evaluating BookN undefined will throw an
> exception.
>
> Back to your example: Here we have either a constructor with two fields,
> so we need three pointers to store the object (one for the info
> pointer), or we have a tuple, which also contains two pointers, so it is
> again three pointers large. The only difference is the newtype can reuse
> the already existing info table for the (,) data type while the Book
> data type needs its own info table, so we save a few bytes of generated
> code (if at all, I do not know if GHC reuses info tables in such a
> situation).
>
>>
>> Thanks
>>
>
> You're welcome.
>
>> --
>> Rob
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>

From taruti at taruti.net  Fri Oct  9 14:32:24 2015
From: taruti at taruti.net (Taru Karttunen)
Date: Fri, 9 Oct 2015 17:32:24 +0300
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <5617B9AD.90703@ciktel.net>
References: <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <5616BB8A.1080807@orlitzky.com>
 <CAJUDvciWQuABPg+OzNEwnKkq95V0X683k5x=bH66GHEYkYx32Q@mail.gmail.com>
 <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local>
 <CAJUDvcjr4n3ftUOdzaLPS1puRPYODpPq0f5DMMGuOisMtpRh+A@mail.gmail.com>
 <CANBN=mvy6iMOTFzYX989CtDuvoJ4r5VKRVEjDr5B+yu6AhQ4jA@mail.gmail.com>
 <5617B9AD.90703@ciktel.net>
Message-ID: <BCB21A7B440D4ACB4639A75AAC892A@mail.local>

On 09.10 08:57, Mario Bla?evi? wrote:
>     Via Hackage. Let's say my-package is at version 1.7.2 as far as features
> and bug fixes go; Hackage would then host my-package-1.7.2.708 and
> my-package-1.7.2.710. The former is uploaded by running cabal upload on
> branch ghc-7.8 of the source repository, the latter on branch ghc-7.10. The
> main difference between the branches would be in the .cabal file:
> 
> on ghc-7.8 branch
> 
>    version: my-package-1.7.2.708
>    build-depends: ghc <= 7.8.*,
> 
> 
> on ghc-7.10 branch
> 
>    version: my-package-1.7.2.710
>    build-depends: ghc == 7.10.*,
> 
>     You can do this with no extra tooling, the only extra work is to run
> seven commands instead of one at publishing time:
> 
>    git checkout ghc-7.8
>    git merge master
>    cabal upload
>    git checkout ghc-7.10
>    git merge master
>    cabal upload
>    git checkout master

And then GHC 8.0 is released and your library is broken until you
update the cabal file or add a new branch. Which means that all
libraries depending on your library refuse to build...

This would mean that all libraries would need a new release
on each GHC major version? Oh and testing your library on
HEAD before release? Not supported? Using any library depending
on your library before the release?

- Taru Karttunen

From michael at orlitzky.com  Fri Oct  9 14:37:33 2015
From: michael at orlitzky.com (Michael Orlitzky)
Date: Fri, 9 Oct 2015 10:37:33 -0400
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <BCB21A7B440D4ACB4639A75AAC892A@mail.local>
References: <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <5616BB8A.1080807@orlitzky.com>
 <CAJUDvciWQuABPg+OzNEwnKkq95V0X683k5x=bH66GHEYkYx32Q@mail.gmail.com>
 <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local>
 <CAJUDvcjr4n3ftUOdzaLPS1puRPYODpPq0f5DMMGuOisMtpRh+A@mail.gmail.com>
 <CANBN=mvy6iMOTFzYX989CtDuvoJ4r5VKRVEjDr5B+yu6AhQ4jA@mail.gmail.com>
 <5617B9AD.90703@ciktel.net> <BCB21A7B440D4ACB4639A75AAC892A@mail.local>
Message-ID: <5617D12D.6080207@orlitzky.com>

On 10/09/2015 10:32 AM, Taru Karttunen wrote:
>>
>>     You can do this with no extra tooling, the only extra work is to run
>> seven commands instead of one at publishing time:
>>
>>    git checkout ghc-7.8
>>    git merge master
>>    cabal upload
>>    git checkout ghc-7.10
>>    git merge master
>>    cabal upload
>>    git checkout master
> 
> And then GHC 8.0 is released and your library is broken until you
> update the cabal file or add a new branch. Which means that all
> libraries depending on your library refuse to build...
> 
> This would mean that all libraries would need a new release
> on each GHC major version? Oh and testing your library on
> HEAD before release? Not supported? Using any library depending
> on your library before the release?
> 

This has nothing to do with git. You have that problem anyway. Don't
want a version bound on your latest branch? Don't put one there.

From mblazevic at stilo.com  Fri Oct  9 15:47:04 2015
From: mblazevic at stilo.com (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=)
Date: Fri, 9 Oct 2015 11:47:04 -0400
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <BCB21A7B440D4ACB4639A75AAC892A@mail.local>
References: <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <5616BB8A.1080807@orlitzky.com>
 <CAJUDvciWQuABPg+OzNEwnKkq95V0X683k5x=bH66GHEYkYx32Q@mail.gmail.com>
 <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local>
 <CAJUDvcjr4n3ftUOdzaLPS1puRPYODpPq0f5DMMGuOisMtpRh+A@mail.gmail.com>
 <CANBN=mvy6iMOTFzYX989CtDuvoJ4r5VKRVEjDr5B+yu6AhQ4jA@mail.gmail.com>
 <5617B9AD.90703@ciktel.net> <BCB21A7B440D4ACB4639A75AAC892A@mail.local>
Message-ID: <5617E178.9000506@stilo.com>

On 15-10-09 10:32 AM, Taru Karttunen wrote:
> On 09.10 08:57, Mario Bla?evi? wrote:
>> ...
>> on ghc-7.10 branch
>>
>>     version: my-package-1.7.2.710
>>     build-depends: ghc == 7.10.*,
>>
>> ...
>
> And then GHC 8.0 is released and your library is broken until you
> update the cabal file or add a new branch. Which means that all
> libraries depending on your library refuse to build...
>
> This would mean that all libraries would need a new release
> on each GHC major version? Oh and testing your library on
> HEAD before release? Not supported? Using any library depending
> on your library before the release?

	Relax. Take a deep breath.

	The above branching scheme extends the PVP guidance to GHC as well; 
which is to say, it assumes every major GHC release to have a potential 
to break your package. But if you trust that GHC 8.0 will be backward 
compatible with 7.10 as far as your code goes, you can change the same 
.cabal file to

 >> on ghc-7.10 branch
 >>
 >>     version: my-package-1.7.2.710
 >>     build-depends: ghc >= 7.10 && < 8.1,


and if you're confident that GHC will *never* break your code again, you 
can even have

 >> on ghc-forever branch
 >>
 >> version: my-package-1.7.2.0
 >> build-depends: ghc >= 7.10


From dhelta.diaz at gmail.com  Fri Oct  9 16:33:53 2015
From: dhelta.diaz at gmail.com (=?UTF-8?Q?Daniel_D=C3=ADaz_Casanueva?=)
Date: Fri, 9 Oct 2015 12:33:53 -0400
Subject: [Haskell-cafe] [Announce] haskintex-0.6.0.0
Message-ID: <CAJFXAQhMonbVNi3tJRejrfLJoFa1yL1hoh2o5duFNT0hbetEKQ@mail.gmail.com>

Dear Haskell users,

I just released a new version of haskintex, the program that runs Haskell
code inside LaTeX documents.

http://hackage.haskell.org/package/haskintex

# More about haskintex

For those who don't know the program yet, _haskintex_ is a tool that
executes Haskell code inside LaTeX documents, creating a new LaTeX document
where each Haskell expression has been replaced by its result. Furthermore,
since haskintex has a special command for using the HaTeX library, you will
be able to write Haskell code that generates LaTeX code. Find more details
in the haskintex documentation page:

http://daniel-diaz.github.io/projects/haskintex

# What's new?

One of the main issues when evaluating Haskell code with haskintex was that
haskintex was not aware of sandbox environments, so it had to rely on user
or global package databases. From version 0.6.0.0, haskintex can now detect
and use sandbox package databases, with no additional effort required from
you. The -nosandbox flag has been added in case you still want the old
behavior.

Another addition is the -autotexy flag. Without the flag, every expression
contained in a \hatex command is required to have type LaTeX. When the flag
is enabled, this restriction is relaxed to any type that is an instance of
the Texy typeclass. This typeclass contains instances for types that can be
rendered to LaTeX syntax. Could be some text, numbers, or even matrices.
You can create your own instances too.

Suggestions, bugs, questions? Head to the haskintex issue tracker:

https://github.com/Daniel-Diaz/haskintex/issues

Happy texing,
Daniel D?az.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151009/b68e0fe6/attachment.html>

From achudnov at gmail.com  Fri Oct  9 19:32:07 2015
From: achudnov at gmail.com (Andrey Chudnov)
Date: Fri, 9 Oct 2015 15:32:07 -0400
Subject: [Haskell-cafe] [Announce] haskintex-0.6.0.0
In-Reply-To: <CAJFXAQhMonbVNi3tJRejrfLJoFa1yL1hoh2o5duFNT0hbetEKQ@mail.gmail.com>
References: <CAJFXAQhMonbVNi3tJRejrfLJoFa1yL1hoh2o5duFNT0hbetEKQ@mail.gmail.com>
Message-ID: <56181637.30607@gmail.com>

Daniel,
Can this be used in conjunction with the `diagrams` package to generate 
diagrams in LaTeX instead of suffering through Tikz?
Is it possible to include a Haskell source file instead of inlining it 
in the tex file?

On 10/09/2015 12:33 PM, Daniel D?az Casanueva wrote:
> Dear Haskell users,
>
> I just released a new version of haskintex, the program that runs 
> Haskell code inside LaTeX documents.
>
> http://hackage.haskell.org/package/haskintex
>
> # More about haskintex
>
> For those who don't know the program yet, _haskintex_ is a tool that 
> executes Haskell code inside LaTeX documents, creating a new LaTeX 
> document where each Haskell expression has been replaced by its 
> result. Furthermore, since haskintex has a special command for using 
> the HaTeX library, you will be able to write Haskell code that 
> generates LaTeX code. Find more details in the haskintex documentation 
> page:
>
> http://daniel-diaz.github.io/projects/haskintex
>
> # What's new?
>
> One of the main issues when evaluating Haskell code with haskintex was 
> that haskintex was not aware of sandbox environments, so it had to 
> rely on user or global package databases. From version 0.6.0.0, 
> haskintex can now detect and use sandbox package databases, with no 
> additional effort required from you. The -nosandbox flag has been 
> added in case you still want the old behavior.
>
> Another addition is the -autotexy flag. Without the flag, every 
> expression contained in a \hatex command is required to have type 
> LaTeX. When the flag is enabled, this restriction is relaxed to any 
> type that is an instance of the Texy typeclass. This typeclass 
> contains instances for types that can be rendered to LaTeX syntax. 
> Could be some text, numbers, or even matrices. You can create your own 
> instances too.
>
> Suggestions, bugs, questions? Head to the haskintex issue tracker:
>
> https://github.com/Daniel-Diaz/haskintex/issues
>
> Happy texing,
> Daniel D?az.
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151009/bda053ae/attachment.html>

From dhelta.diaz at gmail.com  Fri Oct  9 19:46:10 2015
From: dhelta.diaz at gmail.com (=?UTF-8?Q?Daniel_D=C3=ADaz_Casanueva?=)
Date: Fri, 9 Oct 2015 15:46:10 -0400
Subject: [Haskell-cafe] [Announce] haskintex-0.6.0.0
In-Reply-To: <56181637.30607@gmail.com>
References: <CAJFXAQhMonbVNi3tJRejrfLJoFa1yL1hoh2o5duFNT0hbetEKQ@mail.gmail.com>
 <56181637.30607@gmail.com>
Message-ID: <CAJFXAQgZAWTTcmP1Ghhsa_5KJn87=SGwfXMNHO2fDfhuazzZPA@mail.gmail.com>

> Can this be used in conjunction with the `diagrams` package to generate
diagrams in LaTeX instead of suffering through Tikz?

There is no way of using haskintex combined with diagrams at the moment.
But using the HaTeX library you don't have to write the tikz code! Let the
library generate the tikz code for you:

http://hackage.haskell.org/package/HaTeX-3.16.1.1/docs/Text-LaTeX-Packages-TikZ-Simple.html

Unfortunately, it doesn't have most of the features diagrams offer.

> Is it possible to include a Haskell source file instead of inlining it in
the tex file?

You can write the source file and then use the Haskell import. You can also
open a ticket requesting a feature to include source files with a special
command. In any case, I take note of the suggestion. ;)

Best regards,
Daniel D?az.

On Fri, Oct 9, 2015 at 3:32 PM, Andrey Chudnov <achudnov at gmail.com> wrote:

> Daniel,
> Can this be used in conjunction with the `diagrams` package to generate
> diagrams in LaTeX instead of suffering through Tikz?
> Is it possible to include a Haskell source file instead of inlining it in
> the tex file?
>
>
> On 10/09/2015 12:33 PM, Daniel D?az Casanueva wrote:
>
> Dear Haskell users,
>
> I just released a new version of haskintex, the program that runs Haskell
> code inside LaTeX documents.
>
> http://hackage.haskell.org/package/haskintex
>
> # More about haskintex
>
> For those who don't know the program yet, _haskintex_ is a tool that
> executes Haskell code inside LaTeX documents, creating a new LaTeX document
> where each Haskell expression has been replaced by its result. Furthermore,
> since haskintex has a special command for using the HaTeX library, you will
> be able to write Haskell code that generates LaTeX code. Find more details
> in the haskintex documentation page:
>
> http://daniel-diaz.github.io/projects/haskintex
>
> # What's new?
>
> One of the main issues when evaluating Haskell code with haskintex was
> that haskintex was not aware of sandbox environments, so it had to rely on
> user or global package databases. From version 0.6.0.0, haskintex can now
> detect and use sandbox package databases, with no additional effort
> required from you. The -nosandbox flag has been added in case you still
> want the old behavior.
>
> Another addition is the -autotexy flag. Without the flag, every expression
> contained in a \hatex command is required to have type LaTeX. When the flag
> is enabled, this restriction is relaxed to any type that is an instance of
> the Texy typeclass. This typeclass contains instances for types that can be
> rendered to LaTeX syntax. Could be some text, numbers, or even matrices.
> You can create your own instances too.
>
> Suggestions, bugs, questions? Head to the haskintex issue tracker:
>
> https://github.com/Daniel-Diaz/haskintex/issues
>
> Happy texing,
> Daniel D?az.
>
>
> _______________________________________________
> Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151009/f032e716/attachment.html>

From trebla at vex.net  Fri Oct  9 20:16:11 2015
From: trebla at vex.net (Albert Y. C. Lai)
Date: Fri, 9 Oct 2015 16:16:11 -0400
Subject: [Haskell-cafe] Time performance with inlining and space
 performance with newtype?
In-Reply-To: <CA+ZOasLYfVaKFy9s+98fzoqFC_3RpvLAo9JcbtjWM9rzq4KvRg@mail.gmail.com>
References: <CA+ZOasLYfVaKFy9s+98fzoqFC_3RpvLAo9JcbtjWM9rzq4KvRg@mail.gmail.com>
Message-ID: <5618208B.8000107@vex.net>

On 2015-10-09 07:30 AM, Rob Stewart wrote:
> Can I ask GHC to tell me how many bytes the storage of each object
> would require? Or more generally, would looking at GHC Core for all my
> data structures inform me of the memory space costs for each of them?

Cmm (-ddump-opt-cmm) is where you see the actual numbers directly.

But if you already know the stuff in

https://github.com/takenobu-hs/haskell-ghc-illustrated

then you can just look at the Haskell level and predict.


From rickdzekman at gmail.com  Fri Oct  9 21:44:41 2015
From: rickdzekman at gmail.com (Rick Dzekman)
Date: Sat, 10 Oct 2015 08:44:41 +1100
Subject: [Haskell-cafe] Vote/comment on usability survey feedback
Message-ID: <CANEHEBUTnVez9r4aevVGmystdZtQZHXDz+pULb2SAPaWnQf1_A@mail.gmail.com>

*Responses*

Over 100 people responded to the Hackage usability survey. For a
qualitative survey this was far more than expected so thank you all for
contributing. I'm still going through the responses and will post a csv of
the combined web, email and reddit responses soon.

*Vote and comment*

In the meantime I went through and collated all of the gripes and
suggestions people made into two Trello boards:

Suggestions board:
https://trello.com/b/WJRNDtkD/hackage-usability-suggestions

Issues & bugs board: https://trello.com/b/8YSJ5XYV/hackage-usability-issues

If you have a Trello account (it's free to register) you can comment and
vote on issues. *Please vote on the issues/suggestions you think are the
best or most important*. Feel free to make any relevant comments on the
cards as well.

To vote simply open the card, look in the "Actions" section and select
vote. That's it.

If reading through the suggestions/issues makes you think of something new
simply comment on the very top card and I can add your new suggestion to
the list.

*What happens next?*

There are two things that I want to achieve:

1. Come up with a list of simple, easy to implement changes that can be
done on Hackage/Haddocks
2. Come up with wireframes for a potential future state of Hackage that the
community can comment on / contribute to, which encompasses everything
learned from the survey

Not every suggestion is going to be feasible regardless of how popular it
is. Additionally, any suggestions which are feasible have to be implemented
by someone. The more enthusiasm there is behind an idea (or issue) the more
likely we are to see progress.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151010/0f72d6a8/attachment.html>

From matthewtpickering at gmail.com  Fri Oct  9 22:07:12 2015
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Fri, 9 Oct 2015 23:07:12 +0100
Subject: [Haskell-cafe]  Vote/comment on usability survey feedback
In-Reply-To: <CANEHEBUTnVez9r4aevVGmystdZtQZHXDz+pULb2SAPaWnQf1_A@mail.gmail.com>
References: <CANEHEBUTnVez9r4aevVGmystdZtQZHXDz+pULb2SAPaWnQf1_A@mail.gmail.com>
Message-ID: <CALuQ0m_xB8nFW3_xCp-aDH4C9Wbcef7JTixrRZ27mgLcMJ=HPw@mail.gmail.com>

Thank you Rick. This looks like a great start to a list of well-defined
manageable tasks which we can act upon to improve our ecosystem.

I will make sure to mention this list at the hackathon in London tomorrow.

Matt

On Friday, October 9, 2015, Rick Dzekman <rickdzekman at gmail.com> wrote:
> Responses
> Over 100 people responded to the Hackage usability survey. For a
qualitative survey this was far more than expected so thank you all for
contributing. I'm still going through the responses and will post a csv of
the combined web, email and reddit responses soon.
> Vote and comment
> In the meantime I went through and collated all of the gripes and
suggestions people made into two Trello boards:
> Suggestions board:
https://trello.com/b/WJRNDtkD/hackage-usability-suggestions
> Issues & bugs board:
https://trello.com/b/8YSJ5XYV/hackage-usability-issues
> If you have a Trello account (it's free to register) you can comment and
vote on issues. Please vote on the issues/suggestions you think are the
best or most important. Feel free to make any relevant comments on the
cards as well.
> To vote simply open the card, look in the "Actions" section and select
vote. That's it.
> If reading through the suggestions/issues makes you think of something
new simply comment on the very top card and I can add your new suggestion
to the list.
> What happens next?
> There are two things that I want to achieve:
> 1. Come up with a list of simple, easy to implement changes that can be
done on Hackage/Haddocks
> 2. Come up with wireframes for a potential future state of Hackage that
the community can comment on / contribute to, which encompasses everything
learned from the survey
> Not every suggestion is going to be feasible regardless of how popular it
is. Additionally, any suggestions which are feasible have to be implemented
by someone. The more enthusiasm there is behind an idea (or issue) the more
likely we are to see progress.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151009/92ddd5a0/attachment-0001.html>

From fryguybob at gmail.com  Fri Oct  9 23:48:38 2015
From: fryguybob at gmail.com (Ryan Yates)
Date: Fri, 9 Oct 2015 19:48:38 -0400
Subject: [Haskell-cafe] [Announce] haskintex-0.6.0.0
In-Reply-To: <56181637.30607@gmail.com>
References: <CAJFXAQhMonbVNi3tJRejrfLJoFa1yL1hoh2o5duFNT0hbetEKQ@mail.gmail.com>
 <56181637.30607@gmail.com>
Message-ID: <CAO27hRoDoyBH9HNNp-poTAiedy69QCiE4gyj-Z+D=+sZ1a1qpg@mail.gmail.com>

You can incorporate diagrams from the `diagrams` package inline in LaTeX
using diagrams-builder.  We have a tutorial written up here:

http://projects.haskell.org/diagrams/doc/latex.html

I imagine haskintex has a more sophisticated technique and it would be
interesting to integrate diagrams with that approach too.

Ryan

On Fri, Oct 9, 2015 at 3:32 PM, Andrey Chudnov <achudnov at gmail.com> wrote:

> Daniel,
> Can this be used in conjunction with the `diagrams` package to generate
> diagrams in LaTeX instead of suffering through Tikz?
> Is it possible to include a Haskell source file instead of inlining it in
> the tex file?
>
>
> On 10/09/2015 12:33 PM, Daniel D?az Casanueva wrote:
>
> Dear Haskell users,
>
> I just released a new version of haskintex, the program that runs Haskell
> code inside LaTeX documents.
>
> http://hackage.haskell.org/package/haskintex
>
> # More about haskintex
>
> For those who don't know the program yet, _haskintex_ is a tool that
> executes Haskell code inside LaTeX documents, creating a new LaTeX document
> where each Haskell expression has been replaced by its result. Furthermore,
> since haskintex has a special command for using the HaTeX library, you will
> be able to write Haskell code that generates LaTeX code. Find more details
> in the haskintex documentation page:
>
> http://daniel-diaz.github.io/projects/haskintex
>
> # What's new?
>
> One of the main issues when evaluating Haskell code with haskintex was
> that haskintex was not aware of sandbox environments, so it had to rely on
> user or global package databases. From version 0.6.0.0, haskintex can now
> detect and use sandbox package databases, with no additional effort
> required from you. The -nosandbox flag has been added in case you still
> want the old behavior.
>
> Another addition is the -autotexy flag. Without the flag, every expression
> contained in a \hatex command is required to have type LaTeX. When the flag
> is enabled, this restriction is relaxed to any type that is an instance of
> the Texy typeclass. This typeclass contains instances for types that can be
> rendered to LaTeX syntax. Could be some text, numbers, or even matrices.
> You can create your own instances too.
>
> Suggestions, bugs, questions? Head to the haskintex issue tracker:
>
> https://github.com/Daniel-Diaz/haskintex/issues
>
> Happy texing,
> Daniel D?az.
>
>
> _______________________________________________
> Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151009/de1afe79/attachment.html>

From fryguybob at gmail.com  Sat Oct 10 00:19:18 2015
From: fryguybob at gmail.com (Ryan Yates)
Date: Fri, 9 Oct 2015 20:19:18 -0400
Subject: [Haskell-cafe] Interfacing with the GHC runtime from a library
In-Reply-To: <2D70B8F4-55AD-46ED-84BF-EA942A2DAD03@gmail.com>
References: <2D70B8F4-55AD-46ED-84BF-EA942A2DAD03@gmail.com>
Message-ID: <CAO27hRo3-a+AqaTr2o3nXwzPHvxFFgoZ1LKHBLSDQUjrJVoiPg@mail.gmail.com>

Hi Nicola,

You can sort of do this, but as far as I know there are still some missing
pieces to getting everything you would want.  I'm in the process of doing
this for some STM implementations with some colleagues and what I have so
far has a few changes to GHC (teaching the GC about some new heap objects)
some cmm code in the library imported as foreign prim's and some C code in
the library.  I build this with a cabal file and use the
"--extra-include-dirs" flag to pass the path to the "rts/" directory for
ghc.  This last bit is the unfortunate part that I imagine once we work out
what all we need exposed, we could include in what is installed with GHC.
It might already be there, I'm not sure.

Ryan

On Thu, Oct 8, 2015 at 2:24 PM, Nicola Gigante <nicola.gigante at gmail.com>
wrote:

> Hi everybody,
>
> suppose to have an Haskell library which is in part implemented in C
> for whatever reason. Can the C part talk with the runtime, in particular
> the scheduler? In other words, does the runtime expose the functionality
> needed to implement, for example, the STM library from outside the GHC
> runtime itself?
>
> Thank you,
> Nicola
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151009/564eb62b/attachment.html>

From achudnov at gmail.com  Sat Oct 10 00:25:29 2015
From: achudnov at gmail.com (Andrey Chudnov)
Date: Fri, 9 Oct 2015 20:25:29 -0400
Subject: [Haskell-cafe] [Announce] haskintex-0.6.0.0
In-Reply-To: <CAO27hRoDoyBH9HNNp-poTAiedy69QCiE4gyj-Z+D=+sZ1a1qpg@mail.gmail.com>
References: <CAJFXAQhMonbVNi3tJRejrfLJoFa1yL1hoh2o5duFNT0hbetEKQ@mail.gmail.com>
 <56181637.30607@gmail.com>
 <CAO27hRoDoyBH9HNNp-poTAiedy69QCiE4gyj-Z+D=+sZ1a1qpg@mail.gmail.com>
Message-ID: <56185AF9.6080708@gmail.com>

Thanks, Ryan. The tutorial is really good and to-the-point.

By the way, it looks like haskintex has a more general approach to 
integrating Haskell in LaTeX. It seems that in principle it could just 
use that to enable including diagrams in latex, without `diagrams-latex`.

And the same question about including a Haskell source instead of 
inlining applies. To me, having a standalone Haskell file is superior 
since I can get syntax highlighting, typechecking and even quick REPL 
debugging of diagrams that way. While with the inlined one needs to 
re-pdflatex the whole thing to get type errors (do they even show up in 
the latex output?) and reflect the changes. I guess, that could be done 
with the PGF backend for diagrams and a suitable Makefile, though.

On 10/09/2015 07:48 PM, Ryan Yates wrote:
> You can incorporate diagrams from the `diagrams` package inline in 
> LaTeX using diagrams-builder.  We have a tutorial written up here:
>
> http://projects.haskell.org/diagrams/doc/latex.html
>
> I imagine haskintex has a more sophisticated technique and it would be 
> interesting to integrate diagrams with that approach too.
>
> Ryan
>
> On Fri, Oct 9, 2015 at 3:32 PM, Andrey Chudnov <achudnov at gmail.com 
> <mailto:achudnov at gmail.com>> wrote:
>
>     Daniel,
>     Can this be used in conjunction with the `diagrams` package to
>     generate diagrams in LaTeX instead of suffering through Tikz?
>     Is it possible to include a Haskell source file instead of
>     inlining it in the tex file?
>
>
>     On 10/09/2015 12:33 PM, Daniel D?az Casanueva wrote:
>>     Dear Haskell users,
>>
>>     I just released a new version of haskintex, the program that runs
>>     Haskell code inside LaTeX documents.
>>
>>     http://hackage.haskell.org/package/haskintex
>>
>>     # More about haskintex
>>
>>     For those who don't know the program yet, _haskintex_ is a tool
>>     that executes Haskell code inside LaTeX documents, creating a new
>>     LaTeX document where each Haskell expression has been replaced by
>>     its result. Furthermore, since haskintex has a special command
>>     for using the HaTeX library, you will be able to write Haskell
>>     code that generates LaTeX code. Find more details in the
>>     haskintex documentation page:
>>
>>     http://daniel-diaz.github.io/projects/haskintex
>>
>>     # What's new?
>>
>>     One of the main issues when evaluating Haskell code with
>>     haskintex was that haskintex was not aware of sandbox
>>     environments, so it had to rely on user or global package
>>     databases. From version 0.6.0.0, haskintex can now detect and use
>>     sandbox package databases, with no additional effort required
>>     from you. The -nosandbox flag has been added in case you still
>>     want the old behavior.
>>
>>     Another addition is the -autotexy flag. Without the flag, every
>>     expression contained in a \hatex command is required to have type
>>     LaTeX. When the flag is enabled, this restriction is relaxed to
>>     any type that is an instance of the Texy typeclass. This
>>     typeclass contains instances for types that can be rendered to
>>     LaTeX syntax. Could be some text, numbers, or even matrices. You
>>     can create your own instances too.
>>
>>     Suggestions, bugs, questions? Head to the haskintex issue tracker:
>>
>>     https://github.com/Daniel-Diaz/haskintex/issues
>>
>>     Happy texing,
>>     Daniel D?az.
>>
>>
>>     _______________________________________________
>>     Haskell-Cafe mailing list
>>     Haskell-Cafe at haskell.org <mailto:Haskell-Cafe at haskell.org>
>>     http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
>     _______________________________________________
>     Haskell-Cafe mailing list
>     Haskell-Cafe at haskell.org <mailto:Haskell-Cafe at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151009/580a958a/attachment.html>

From ivan.miljenovic at gmail.com  Sat Oct 10 00:58:46 2015
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Sat, 10 Oct 2015 11:58:46 +1100
Subject: [Haskell-cafe] ANNOUNCE: unordered-graphs
Message-ID: <CA+u6gbyp2A0sXBPADqzWtJDsiiEoekrX8HHdhY+cyjVkgViQ4g@mail.gmail.com>

I have a relatively hacked-together graph library that uses
unordered-containers as a backend available if anyone finds it
interesting/useful:
http://hackage.haskell.org/package/unordered-graphs

It's primarily developed just for my own needs and thus I'm not sure
how much future work I'll be doing on it, but I'm willing to accept
pull requests.

This library was semi-experimental in that I also tried a few things
out with it:

* Polymorphic node type

* Fixed auto-generated edge type: this is because (node,node, label)
triples (ala fgl) do not provide sufficient information to be able to
distinguish between multiple edges, etc.

* Type parameter to determine whether the graph is directed or undirected.

* Typeclass to allow you to determine the type/output of a a match (I
didn't end up actually using this, as the one time I needed to do a
match I found the extra polymorphism caused problems; it also isn't
comprehensive as I didn't write all that many instances.)

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

From ekmett at gmail.com  Sat Oct 10 19:13:26 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Sat, 10 Oct 2015 15:13:26 -0400
Subject: [Haskell-cafe] MRP, 3-year-support-window,
 and the non-requirement of CPP
In-Reply-To: <F351956E-517E-4387-A3E5-29968ADB5ACA@me.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org>
 <F351956E-517E-4387-A3E5-29968ADB5ACA@me.com>
Message-ID: <CAJumaK_ayJ=Xpj_pzKv5sk_G3MncAB9FQEjL4=-9ieMC6LfwDA@mail.gmail.com>

On Tue, Oct 6, 2015 at 3:02 PM, Malcolm Wallace <malcolm.wallace at me.com>
wrote:

>
> On 6 Oct 2015, at 17:47, Herbert Valerio Riedel wrote:
> > At the risk of stating the obvious: I don't think it matters from which
> > group a given argument comes from as its validity doesn't depend on the
> > messenger.
>
> In that case, I think you are misunderstanding the relevance of Johan's
> argument here.  Let me try to phrase it differently.  Some people who can
> reasonably claim to have experience with million-line plus codebases are
> warning that this change is too disruptive, and makes maintenance harder
> than it ought to be.  On the other hand, of the people who say the change
> is not really disruptive, none of them have (yet?) made claims to have
> experience of the maintenance of extremely large-scale codebases.


Very well. Let me offer a view from the "other side of the fence."

I personally maintain about 1.3 million lines of Haskell, and over 120
packages on hackage. It took me less than a half a day to get everything
running with 7.10, and about two days to build -Wall clean. In that first
day I actually had to spend vastly more time fixing things related to
changes in Typeable, template-haskell and a tweaked corner case in the
typechecker than anything AMP/FTP related. In the end I had to add two type
signatures.

Most of the patches to go -Wall clean looked like

+#if __GLASGOW_HASKELL__ < 710
import Control.Applicative
import Data.Monoid
+#endif

Maybe 10% were more complicated.

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151010/1ac84541/attachment.html>

From ekmett at gmail.com  Sat Oct 10 19:16:10 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Sat, 10 Oct 2015 15:16:10 -0400
Subject: [Haskell-cafe] MRP, 3-year-support-window,
 and the non-requirement of CPP
In-Reply-To: <87lhbfm8qu.fsf@gnu.org>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org>
 <CANBN=mu_un8bJR3eCSMmpoXpL3_Mu-wsgdnZ+ZOiUGP-j4RWmw@mail.gmail.com>
 <87lhbfm8qu.fsf@gnu.org>
Message-ID: <CAJumaK-d-uJP6BEmpZTiNmnAtzB=Vaz7nUX6S_5qNT-B02DYLQ@mail.gmail.com>

On Wed, Oct 7, 2015 at 3:35 AM, Herbert Valerio Riedel <hvr at gnu.org> wrote:

> --8<---------------cut here---------------start------------->8---
> import Control.Applicative as A (Applicative(..))
>
> data Maybe' a = Nothing' | Just' a
>
> instance Functor Maybe' where
>     fmap f (Just' v) = Just' (f v)
>     fmap _ Nothing'  = Nothing'
>
> instance A.Applicative Maybe' where
>     pure = Just'
>     f1 <*> f2   = f1 >>= \v1 -> f2 >>= (pure . v1)
>
> instance Monad Maybe' where
>     Nothing' >>= _  = Nothing'
>     Just' x  >>= f  = f x
>
>     return = pure -- "deprecated" since GHC 7.10
> --8<---------------cut here---------------end--------------->8---
>
>
Alternately,

import Control.Applicative
import Prelude

data Maybe' a = Nothing' | Just' a

instance Functor Maybe' where
    fmap f (Just' v) = Just' (f v)
    fmap _ Nothing'  = Nothing'

instance Applicative Maybe' where



> -- hvr
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151010/14bf5791/attachment.html>

From ekmett at gmail.com  Sat Oct 10 19:25:37 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Sat, 10 Oct 2015 15:25:37 -0400
Subject: [Haskell-cafe] MRP, 3-year-support-window,
 and the non-requirement of CPP
In-Reply-To: <CAAOoiFb3rqAzG4eH4jrwdors8OqDcTaQaZq7TJhBA5-VAsW8JQ@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org> <etPan.56147308.2268a666.7b73@mbp.local>
 <CAHZrzdpig8R=W5T4SBRYwqCD_3W+wquYajOr-9qqcEd4f8gf1w@mail.gmail.com>
 <CAPeieQG0-6AmNGEZLBg_Lqh5VJKwTtPFC3=iGV42ciJ=zO5xpg@mail.gmail.com>
 <CAAOoiFb3rqAzG4eH4jrwdors8OqDcTaQaZq7TJhBA5-VAsW8JQ@mail.gmail.com>
Message-ID: <CAJumaK8WDbNfkFOKZPv9dDZqEiyB6ms2wJC9KK0sVv-CWPjqmQ@mail.gmail.com>

The part of the MRP proposal that I actively care about because it fixes a
situation that *actually causes harm* is moving (>>) to the top level.

Why?

Right now (*>) and (>>) have different default definitions. This means that
code runs often with different asymptotics depending on which one you pick.
Folks often define one but not the other.

This means that the performance of mapM_ and traverse_ needlessly differ.
It means that we can't simply weaken the type constraint on mapM_ and
sequence_ to Applicative, it as a knock-on consequence it means we can't
migrate mapM and sequence out of Traversable to top level definitions and
thereby simply provide folks with more efficient parallelizable mapping
when they reach for the 'obvious tool'.

return itself lurking in the class doesn't matter to me all that much as it
doesn't break anybody's asymptotics and it already has a sensible
definition in terms of pure as a default, so effectively you can write code
as if MRP was already in effect today. It is a wart, but one that could be
burned off on however long a time table we want if we choose to proceed.

-Edward

On Wed, Oct 7, 2015 at 5:13 PM, Mark Lentczner <mark.lentczner at gmail.com>
wrote:

>
> On Wed, Oct 7, 2015 at 9:38 AM, Erik Hesselink <hesselink at gmail.com>
> wrote:
>
>> While I don't think it detracts from your argument, it seems you
>> misread the original proposal. At no point will it remove `return`
>> completely. It would be moved out of the `Monad` class and be made
>> into a top-level definition instead, so you would still be able to use
>> it.
>>
>
> Then why bother?
> If you don't intend to regard code that uses "return" as old, out-dated,
> in need of updating, etc....
> If you don't intend to correct people on #haskell to use pure instead of
> return...
> If you don't tsk tsk all mentions of it in books....
> If you don't intend to actually deprecate it.
> Why bother?
>
> But seriously, why do you think that "you would still be able to use it"?
> That is true for only the simplest of code - and untrue for anyone who has
> a library that defines a Monad - or anyone who has a library that they want
> to keep "up to date". Do you really want to have a library where all your
> "how to use this" code has return in the examples? Shouldn't now be pure?
> Do I now need -XCPP just for Haddock? and my wiki page? And what gets shown
> in Hackage? This is just a nightmare for a huge number of libraries, and
> especially many commonly used ones.
>
> Why bother!
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151010/298019f3/attachment.html>

From ekmett at gmail.com  Sat Oct 10 19:33:37 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Sat, 10 Oct 2015 15:33:37 -0400
Subject: [Haskell-cafe] MRP, 3-year-support-window,
 and the non-requirement of CPP
In-Reply-To: <CANBN=mu_un8bJR3eCSMmpoXpL3_Mu-wsgdnZ+ZOiUGP-j4RWmw@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org>
 <CANBN=mu_un8bJR3eCSMmpoXpL3_Mu-wsgdnZ+ZOiUGP-j4RWmw@mail.gmail.com>
Message-ID: <CAJumaK8E7-76L6Pd59uv=JnjsjrJOP=yTAYojtdZV3X3jgO55g@mail.gmail.com>

On Tue, Oct 6, 2015 at 1:41 PM, Sven Panne <svenpanne at gmail.com> wrote:

> 2015-10-06 18:47 GMT+02:00 Herbert Valerio Riedel <hvr at gnu.org>:
>
>> [...] That's because -Wall-hygiene (w/o opting out of harmless) warnings
>>
> across multiple GHC versions is not considered a show-stopper.
>>
>
> That's your personal POV, I'm more leaning towards "-Wall -Werror". I've
> seen too many projects where neglecting warning over an extended period of
> time made fixing them basically impossible at the end. Anyway, I think that
> a sane ecosystem should allow *both* POVs, the sloppy one and the strict
> one.
>

Note: You haven't been able to upload a package that has -Werror turned on
in the cabal file for a couple of years now -- even if it is only turned on
on the test suite, so any -Werror discipline you choose to enforce is
purely local.

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151010/33007ac3/attachment.html>

From shumovichy at gmail.com  Sat Oct 10 20:12:11 2015
From: shumovichy at gmail.com (Yuras Shumovich)
Date: Sat, 10 Oct 2015 23:12:11 +0300
Subject: [Haskell-cafe] MRP, 3-year-support-window,
 and the non-requirement of CPP
In-Reply-To: <CAJumaK8WDbNfkFOKZPv9dDZqEiyB6ms2wJC9KK0sVv-CWPjqmQ@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org> <etPan.56147308.2268a666.7b73@mbp.local>
 <CAHZrzdpig8R=W5T4SBRYwqCD_3W+wquYajOr-9qqcEd4f8gf1w@mail.gmail.com>
 <CAPeieQG0-6AmNGEZLBg_Lqh5VJKwTtPFC3=iGV42ciJ=zO5xpg@mail.gmail.com>
 <CAAOoiFb3rqAzG4eH4jrwdors8OqDcTaQaZq7TJhBA5-VAsW8JQ@mail.gmail.com>
 <CAJumaK8WDbNfkFOKZPv9dDZqEiyB6ms2wJC9KK0sVv-CWPjqmQ@mail.gmail.com>
Message-ID: <1444507931.2047.14.camel@gmail.com>

On Sat, 2015-10-10 at 15:25 -0400, Edward Kmett wrote:
> The part of the MRP proposal that I actively care about because it
> fixes a
> situation that *actually causes harm* is moving (>>) to the top
> level.

Sorry if I'm missing something, but moving (>>) is not part of the
proposal. At least it is not mentioned on the wiki page:

https://ghc.haskell.org/trac/ghc/wiki/Proposal/MonadOfNoReturn

Is the wiki outdated?

> return itself lurking in the class doesn't matter to me all that much
> as it
> doesn't break anybody's asymptotics and it already has a sensible
> definition in terms of pure as a default, so effectively you can
> write code
> as if MRP was already in effect today. It is a wart, but one that
> could be
> burned off on however long a time table we want if we choose to
> proceed.

So the cost of not moving `return` to the top level is zero?

For me the cost of moving it is pretty small, just an hour or two.
Probably recompiling all the dependencies when switching to newer
version of GHC will take longer. (Actually I'm still using 7.8 at
work.) But the cost is definitely nonzero.

The proposal (as written on the wiki page) provides two arguments for
the change:

There is no reason to include `return` into the next standard. That is
true. But we can leave `return` is `GHC` as a compiler specific
extension for backward compatibility, can't we?

The second argument is `ApplicativeDo`, but I don't see the point.
Breaking existing code "in order to benefit existing code" looks a bit
strange.

Could someone please clarify what is the cost of not moving `return`
out of `Monad`?

Sorry if it is already answered somewhere else, it is hard to find
anything in such the huge email thread.

Thanks,
Yuras.


From ekmett at gmail.com  Sat Oct 10 20:39:10 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Sat, 10 Oct 2015 16:39:10 -0400
Subject: [Haskell-cafe] MRP, 3-year-support-window,
 and the non-requirement of CPP
In-Reply-To: <1444507931.2047.14.camel@gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org> <etPan.56147308.2268a666.7b73@mbp.local>
 <CAHZrzdpig8R=W5T4SBRYwqCD_3W+wquYajOr-9qqcEd4f8gf1w@mail.gmail.com>
 <CAPeieQG0-6AmNGEZLBg_Lqh5VJKwTtPFC3=iGV42ciJ=zO5xpg@mail.gmail.com>
 <CAAOoiFb3rqAzG4eH4jrwdors8OqDcTaQaZq7TJhBA5-VAsW8JQ@mail.gmail.com>
 <CAJumaK8WDbNfkFOKZPv9dDZqEiyB6ms2wJC9KK0sVv-CWPjqmQ@mail.gmail.com>
 <1444507931.2047.14.camel@gmail.com>
Message-ID: <CAJumaK_8k0jzTKprOSAoj8xQPvGRMNSSCsabKgowOo5+cFu97A@mail.gmail.com>

On Sat, Oct 10, 2015 at 4:12 PM, Yuras Shumovich <shumovichy at gmail.com>
wrote:

> On Sat, 2015-10-10 at 15:25 -0400, Edward Kmett wrote:
> > The part of the MRP proposal that I actively care about because it
> > fixes a
> > situation that *actually causes harm* is moving (>>) to the top
> > level.
>
> Sorry if I'm missing something, but moving (>>) is not part of the
> proposal. At least it is not mentioned on the wiki page:
>
> https://ghc.haskell.org/trac/ghc/wiki/Proposal/MonadOfNoReturn
>
> Is the wiki outdated?
>

It arose during the original thread discussing the MRP but wasn't included
in the 'proposal as written' that was sent out.

https://mail.haskell.org/pipermail/libraries/2015-September/026129.html

In many ways that proposal would do better 'on its own' than as part of the
MRP.

> return itself lurking in the class doesn't matter to me all that much
> > as it
> > doesn't break anybody's asymptotics and it already has a sensible
> > definition in terms of pure as a default, so effectively you can
> > write code
> > as if MRP was already in effect today. It is a wart, but one that
> > could be
> > burned off on however long a time table we want if we choose to
> > proceed.
>
> So the cost of not moving `return` to the top level is zero?
>
> For me the cost of moving it is pretty small, just an hour or two.
> Probably recompiling all the dependencies when switching to newer
> version of GHC will take longer. (Actually I'm still using 7.8 at
> work.) But the cost is definitely nonzero.
>
> The proposal (as written on the wiki page) provides two arguments for
> the change:
>
> There is no reason to include `return` into the next standard. That is
> true.


Nobody is saying that we should remove return from the language. The
proposal was to move it out of the class -- eventually. Potentially on a
very very long time line.

But we can leave `return` is `GHC` as a compiler specific extension for
> backward compatibility, can't we?
>

This is effectively the status quo. There is a default definition of return
in terms of pure today. The longer we wait the more tenable this proposal
gets in many ways as fewer and fewer people start trying to support
compilers versions below 7.10. Today isn't that day.

There are some niggling corner cases around viewing its continued existence
as a compiler "extension" though, even just around the behavior when you
import the class with Monad(..) you get more or less than you'd expect.

Could someone please clarify what is the cost of not moving `return` out of
> `Monad`?
>

The cost of doing nothing is maintaining a completely redundant member
inside the class for all time and an ever-so-slightly more expensive
dictionaries for Monad, so retaining return in the class does no real harm
operationally.

While I'm personally somewhat in favor of its eventual migration on
correctness grounds and believe it'd be nice to be able to justify the
state of the world as more than a series of historical accidents when I put
on my libraries committee hat I have concerns.

I'm inclined to say at the least that IF we do decide to proceed on this,
at least the return component should be on a long time horizon, with a
clock tied to the release of a standard, say a Haskell2020. I stress IF,
because I haven't had a chance to go through and do any sort of detailed
tally or poll to get a sense of if there is a sufficient mandate. There is
enough of a ruckus being raised that it is worth proceeding cautiously if
we proceed at all.

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151010/90bc7458/attachment.html>

From anton.kholomiov at gmail.com  Sat Oct 10 21:53:02 2015
From: anton.kholomiov at gmail.com (Anton Kholomiov)
Date: Sun, 11 Oct 2015 00:53:02 +0300
Subject: [Haskell-cafe] Monads for Drummers! Yet another monad tutorial with
	pictures!
Message-ID: <CADDxdqPhyGOL-t26F9GA9d5qkQ6qSwwastp8WbxAU+Gy-Fit5w@mail.gmail.com>

Yes!

It's another monad tutorial. I've tried hard not to do it but finally it
came out.

I wrote a book on Haskell in Russian. It's a translation of the chapter
that is dedicated to monads. I was convinced by friends to publish it.

The monads are explained with pictures and Kleisli categories.
Hope this can help to someone to grasp the monad concept.

-------------------------------------

ps: pictures were made with diagrams

Thank you for being kind with my awkward English!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151011/aa3b2d48/attachment.html>

From anton.kholomiov at gmail.com  Sat Oct 10 21:53:20 2015
From: anton.kholomiov at gmail.com (Anton Kholomiov)
Date: Sun, 11 Oct 2015 00:53:20 +0300
Subject: [Haskell-cafe] Monads for Drummers! Yet another monad tutorial
	with pictures!
In-Reply-To: <CADDxdqPhyGOL-t26F9GA9d5qkQ6qSwwastp8WbxAU+Gy-Fit5w@mail.gmail.com>
References: <CADDxdqPhyGOL-t26F9GA9d5qkQ6qSwwastp8WbxAU+Gy-Fit5w@mail.gmail.com>
Message-ID: <CADDxdqMPcENOvnLOe+K4KftGkvGhRB1aiU2QAsw1sNtiO4=uNw@mail.gmail.com>

https://github.com/anton-k/monads-for-drummers

2015-10-11 0:53 GMT+03:00 Anton Kholomiov <anton.kholomiov at gmail.com>:

> Yes!
>
> It's another monad tutorial. I've tried hard not to do it but finally it
> came out.
>
> I wrote a book on Haskell in Russian. It's a translation of the chapter
> that is dedicated to monads. I was convinced by friends to publish it.
>
> The monads are explained with pictures and Kleisli categories.
> Hope this can help to someone to grasp the monad concept.
>
> -------------------------------------
>
> ps: pictures were made with diagrams
>
> Thank you for being kind with my awkward English!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151011/47abccb3/attachment.html>

From defigueiredo at ucdavis.edu  Sun Oct 11 02:09:57 2015
From: defigueiredo at ucdavis.edu (Dimitri DeFigueiredo)
Date: Sat, 10 Oct 2015 20:09:57 -0600
Subject: [Haskell-cafe] A suggestion: On why code merges should influence
	Haskell design
In-Reply-To: <5617E178.9000506@stilo.com>
References: <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <5616BB8A.1080807@orlitzky.com>
 <CAJUDvciWQuABPg+OzNEwnKkq95V0X683k5x=bH66GHEYkYx32Q@mail.gmail.com>
 <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local>
 <CAJUDvcjr4n3ftUOdzaLPS1puRPYODpPq0f5DMMGuOisMtpRh+A@mail.gmail.com>
 <CANBN=mvy6iMOTFzYX989CtDuvoJ4r5VKRVEjDr5B+yu6AhQ4jA@mail.gmail.com>
 <5617B9AD.90703@ciktel.net> <BCB21A7B440D4ACB4639A75AAC892A@mail.local>
 <5617E178.9000506@stilo.com>
Message-ID: <5619C4F5.3060800@ucdavis.edu>

We write software in teams. Most software development (or at least a 
large fraction of it) requires that more than one person work on the 
same codebase simultaneously. This means that in most software 
development there will *necessarily* be code merges.

Every time we merge our work, on branch A, with that of others, on 
branch B, using git or most other tools we are doing a simple line-based 
merge on text files. This kind of merge can produce an output that 
introduces bugs that were not present on either branch A or B even if 
there are no conflicts. This is terrible! This "merge tool" can create 
bugs by itself out of thin air! Can we have a better merge tool?

Ideally, I would like a merge tool to work like a compiler: If there are 
no conflicts, the merge tool guarantees the merge introduces no new bugs 
(other than those already found in A or B). In other words, the output 
of the merge tool is "merge bug free", if there are no conflicts. 
Unfortunately, this is rather tall order. Previous research found that 
for many languages it is impossible to write such a tool [1]. However, 
this may be asking the wrong question.

Let's take a different point of view. Let's assume there will be 
software merges (and therefore that merge tools will be used in software 
development), here are better questions to ask:
1. How does the desire for a "compiler-like" merge tool constrain 
language design? Can we design a language for which such a merge tool is 
possible?
2. If it is not possible to get the guarantee that no bugs will be 
introduced during the merge process, what guarantees can we get? Can we 
at least get that at the module level? Does that constrain the available 
design space?

Specializing those to Haskell:
1. Can we write a "compiler-like" merge tool for Haskell?
2. If not, can we tweak Haskell so that the existence of such a tool 
becomes possible? Can we at least get that at the module level?


Cheers,


Dimitri


[1] D. Binkley, S. Horwitz, and T. Reps. 1995. Program integration for 
languages with procedure calls. /ACM Trans. Softw. Eng. Methodol./ 4, 1 
(January 1995), 3-35.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151010/5c4051cb/attachment.html>

From sean.leather at gmail.com  Sun Oct 11 06:17:35 2015
From: sean.leather at gmail.com (Sean Leather)
Date: Sun, 11 Oct 2015 08:17:35 +0200
Subject: [Haskell-cafe] A suggestion: On why code merges should
 influence Haskell design
In-Reply-To: <5619C4F5.3060800@ucdavis.edu>
References: <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <5616BB8A.1080807@orlitzky.com>
 <CAJUDvciWQuABPg+OzNEwnKkq95V0X683k5x=bH66GHEYkYx32Q@mail.gmail.com>
 <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local>
 <CAJUDvcjr4n3ftUOdzaLPS1puRPYODpPq0f5DMMGuOisMtpRh+A@mail.gmail.com>
 <CANBN=mvy6iMOTFzYX989CtDuvoJ4r5VKRVEjDr5B+yu6AhQ4jA@mail.gmail.com>
 <5617B9AD.90703@ciktel.net> <BCB21A7B440D4ACB4639A75AAC892A@mail.local>
 <5617E178.9000506@stilo.com> <5619C4F5.3060800@ucdavis.edu>
Message-ID: <CACz_ru2dLq5MCQXrXnyoHL+eUNsr9jXg_5iD6NjgP7Y8U8EMLQ@mail.gmail.com>

On Sun, Oct 11, 2015 at 4:09 AM, Dimitri DeFigueiredo wrote:

> Can we write a "compiler-like" merge tool for Haskell?


Merge could be considered to be a combination of diff and patch. And so you
might want to merge ASTs, which are typically families of datatypes.
Related: Type-Safe Diff for Families of Dataypes:
http://www.andres-loeh.de/gdiff-wgp.pdf

Regards,
Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151011/51482621/attachment.html>

From shumovichy at gmail.com  Sun Oct 11 09:49:39 2015
From: shumovichy at gmail.com (Yuras Shumovich)
Date: Sun, 11 Oct 2015 12:49:39 +0300
Subject: [Haskell-cafe] MRP, 3-year-support-window,
 and the non-requirement of CPP
In-Reply-To: <CAJumaK_8k0jzTKprOSAoj8xQPvGRMNSSCsabKgowOo5+cFu97A@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org> <etPan.56147308.2268a666.7b73@mbp.local>
 <CAHZrzdpig8R=W5T4SBRYwqCD_3W+wquYajOr-9qqcEd4f8gf1w@mail.gmail.com>
 <CAPeieQG0-6AmNGEZLBg_Lqh5VJKwTtPFC3=iGV42ciJ=zO5xpg@mail.gmail.com>
 <CAAOoiFb3rqAzG4eH4jrwdors8OqDcTaQaZq7TJhBA5-VAsW8JQ@mail.gmail.com>
 <CAJumaK8WDbNfkFOKZPv9dDZqEiyB6ms2wJC9KK0sVv-CWPjqmQ@mail.gmail.com>
 <1444507931.2047.14.camel@gmail.com>
 <CAJumaK_8k0jzTKprOSAoj8xQPvGRMNSSCsabKgowOo5+cFu97A@mail.gmail.com>
Message-ID: <1444556979.2047.27.camel@gmail.com>

On Sat, 2015-10-10 at 16:39 -0400, Edward Kmett wrote:
> On Sat, Oct 10, 2015 at 4:12 PM, Yuras Shumovich <
> shumovichy at gmail.com>
> wrote:
> 
> > There is no reason to include `return` into the next standard. That
> > is
> > true.
> 
> 
> Nobody is saying that we should remove return from the language. The
> proposal was to move it out of the class -- eventually. Potentially
> on a
> very very long time line.

Yes, I meant there were no reason to include `return` into `Monad`
class in the next standard.


> There are some niggling corner cases around viewing its continued
> existence
> as a compiler "extension" though, even just around the behavior when
> you
> import the class with Monad(..) you get more or less than you'd
> expect.

Indeed that is a good argument.


> The cost of doing nothing is maintaining a completely redundant
> member
> inside the class for all time 

Well, it is just a single line of code. Of course, as any other
technical dept, it can beat you later, e.g. it can make some other
modification harder. But in the worst case it will cost one more
deprecation circle.


> and an ever-so-slightly more expensive
> dictionaries for Monad

Do you mean that moving `return` to the top level will give us
noticeable performance improvement?


> so retaining return in the class does no real harm
> operationally.

IMO that is the reason for the "ruckus".


Thank you for the detailed answer.

Yuras


> 
> While I'm personally somewhat in favor of its eventual migration on
> correctness grounds and believe it'd be nice to be able to justify
> the
> state of the world as more than a series of historical accidents when
> I put
> on my libraries committee hat I have concerns.
> 
> I'm inclined to say at the least that IF we do decide to proceed on
> this,
> at least the return component should be on a long time horizon, with
> a
> clock tied to the release of a standard, say a Haskell2020. I stress
> IF,
> because I haven't had a chance to go through and do any sort of
> detailed
> tally or poll to get a sense of if there is a sufficient mandate.
> There is
> enough of a ruckus being raised that it is worth proceeding
> cautiously if
> we proceed at all.
> 
> -Edward

From hvr at gnu.org  Sun Oct 11 21:27:13 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Sun, 11 Oct 2015 23:27:13 +0200
Subject: [Haskell-cafe] Final Call for Haskell Prime language committee
	Nominations!
In-Reply-To: <87wpvh8ksg.fsf@gmail.com> (Herbert Valerio Riedel's message of
 "Wed, 23 Sep 2015 12:58:07 +0200")
References: <87wpvh8ksg.fsf@gmail.com>
Message-ID: <87twpxjdu6.fsf@gmail.com>


The submission deadline (Wed, Oct 14 23:59:59 UTC 2015) for Haskell
Prime self-nominations (see also original CfN at [1]) is near!


If you have already submitted a self-nomination, please make sure (if it
was sent to the haskell-prime list) that it shows up in the mailing list
archives at

 - https://mail.haskell.org/pipermail/haskell-prime/2015-September/ or
 - https://mail.haskell.org/pipermail/haskell-prime/2015-October/

or (if you have only sent it to me directly) that I acknowledged
receiving your submission by an email reply.


Regards,
  Herbert Valerio Riedel

 [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html

From roconnor at theorem.ca  Sun Oct 11 23:11:15 2015
From: roconnor at theorem.ca (roconnor at theorem.ca)
Date: Sun, 11 Oct 2015 16:11:15 -0700 (PDT)
Subject: [Haskell-cafe] ANNOUNCE: mezzolens 0.0.0 & a puzzle
Message-ID: <alpine.LRH.2.11.1510111536350.29271@turing.theorem.ca>

This is a pre-release of mezzolens, a library of first-order functional 
references based purely on profunctors.  I wrote it because 
https://www.reddit.com/user/Faucelme asked for one.  You can find it at 
https://hackage.haskell.org/package/mezzolens

The main purpose of this pre-release is to provide background for framing 
the following question:

In a pure profunctor lens libray, how do you write choosing and beside in 
such a way that it supports all the following types?

choosing :: Lens ta tb a b -> Lens sa sb a b -> Lens (Either ta sa) (Either sa sb) a b
choosing :: Traversal ta tb a b -> Travesal sa sb a b -> Traversal (Either ta sa) (Either sa sb) a b
choosing :: SEC ta tb a b -> SEC sa sb a b -> SEC (Either ta sa) (Either sa sb) a b

beside :: Traversal ta tb a b -> Travesal sa sb a b -> Traversal (Either ta sa) (Either sa sb) a b
beside :: SEC ta tb a b -> SEC sa sb a b -> SEC (Either ta sa) (Either sa sb) a b


One sufficent solution for choosing would be to write a single function 
that combines

lensVL :: (forall f. Functor f => (a -> f b) -> ta -> f tb) -> Lens ta tb a b
traversal :: (forall f. Applicative f => (a -> f b) -> ta -> f tb) -> Traversal ta tb a b

into one.

The obvious approach is to write an suitable adaptor that transforms any 
(strong) profunctor into a functor, and if the profunctor is wandering, it 
produces an applicative functor.  But I haven't been able to devise such a 
suitable adaptor.

-- 
Russell O'Connor                                      <http://r6.ca/>
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''

From jeffbrown.the at gmail.com  Mon Oct 12 00:10:29 2015
From: jeffbrown.the at gmail.com (Jeffrey Brown)
Date: Sun, 11 Oct 2015 17:10:29 -0700
Subject: [Haskell-cafe] A suggestion: On why code merges should
 influence Haskell design
In-Reply-To: <CACz_ru2dLq5MCQXrXnyoHL+eUNsr9jXg_5iD6NjgP7Y8U8EMLQ@mail.gmail.com>
References: <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <5616BB8A.1080807@orlitzky.com>
 <CAJUDvciWQuABPg+OzNEwnKkq95V0X683k5x=bH66GHEYkYx32Q@mail.gmail.com>
 <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local>
 <CAJUDvcjr4n3ftUOdzaLPS1puRPYODpPq0f5DMMGuOisMtpRh+A@mail.gmail.com>
 <CANBN=mvy6iMOTFzYX989CtDuvoJ4r5VKRVEjDr5B+yu6AhQ4jA@mail.gmail.com>
 <5617B9AD.90703@ciktel.net> <BCB21A7B440D4ACB4639A75AAC892A@mail.local>
 <5617E178.9000506@stilo.com> <5619C4F5.3060800@ucdavis.edu>
 <CACz_ru2dLq5MCQXrXnyoHL+eUNsr9jXg_5iD6NjgP7Y8U8EMLQ@mail.gmail.com>
Message-ID: <CAEc4Ma3ctVR8cdATxr-cg+e_-noGM4yX+vwJs_FnaZv54EAMuQ@mail.gmail.com>

+1 for AST merge. Writing code from text is reasonable, but storing code as
text is lunacy.

On Sat, Oct 10, 2015 at 11:17 PM, Sean Leather <sean.leather at gmail.com>
wrote:

> On Sun, Oct 11, 2015 at 4:09 AM, Dimitri DeFigueiredo wrote:
>
>> Can we write a "compiler-like" merge tool for Haskell?
>
>
> Merge could be considered to be a combination of diff and patch. And so
> you might want to merge ASTs, which are typically families of datatypes.
> Related: Type-Safe Diff for Families of Dataypes:
> http://www.andres-loeh.de/gdiff-wgp.pdf
>
> Regards,
> Sean
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>


-- 
Jeffrey Benjamin Brown
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151011/acbbd1cc/attachment.html>

From tkoster at gmail.com  Mon Oct 12 00:45:20 2015
From: tkoster at gmail.com (Thomas Koster)
Date: Mon, 12 Oct 2015 11:45:20 +1100
Subject: [Haskell-cafe] A GC'd heap using weak pointers
In-Reply-To: <CAJbEW8OiS=xc0chEsHkA9EP=GAD+NFcsLvJedtQf982tHsXwUw@mail.gmail.com>
References: <CAG1wH7AA9e6tQkashLq6SsgsvqbuXv64PK=o-r8PGVQcktGFbw@mail.gmail.com>
 <CAJbEW8OiS=xc0chEsHkA9EP=GAD+NFcsLvJedtQf982tHsXwUw@mail.gmail.com>
Message-ID: <CAG1wH7AOeyYWmLOGQRzmiH+sVH2LWnbVn-5T=L9uq63GrWbF0A@mail.gmail.com>

On 6 October 2015 at 21:25, Thomas Koster <tkoster at gmail.com> wrote:
> I am implementing a simple, interpreted language that needs a garbage-
> collected heap for storage. Like most discussions on memory management,
> I use the term "heap" by analogy - the actual data structure is not
> necessarily a true heap.
>
> My Heap type is basically a map of "addresses" (Int) to values. Values
> may themselves contain addresses, perhaps recursively to each other
> (like letrec). The extra field in Heap stores the next unused address,
> used to allocate fresh slots, as you can see in "heapAlloc".
>
>> type Address = Int
>> data Value = ...things with Addresses...
>> data Heap = Heap !Address (Map Address Value)
>>
>> heapAlloc :: Heap -> (Address, Heap)
>> heapAlloc (Heap nextFreeAddr binds) =
>>   (nextFreeAddr, Heap (succ nextFreeAddr) binds)
>
> There is also a stack of roots and an expression under evaluation.
>
>> type Stack = [...things with Addresses...]
>> data Expr = ...things with Addresses...
>
> The function I need to write is:
>
>> heapGC :: [Address] -> Heap -> Heap
>> heapGC roots heap = ...collect unreachable values from heap...
>
> Rather than re-invent this particularly complex wheel, I am wondering
> if I could use GHC weak pointers and have the GHC runtime collect values
> in my heap for me. Something like this:
>
>> type Address = Int
>> data Reference = Reference Address
>> data Value = ...things with References...
>> data Heap = Heap !Address (Map Address (Weak Value))
>>
>> heapAlloc :: Heap -> (Reference, Heap)
>> heapAlloc (Heap nextFreeAddr binds) =
>>   (Reference nextFreeAddr, Heap (succ nextFreeAddr) binds)
>>
>> heapStore :: Reference -> Value -> Heap -> IO Heap
>> heapStore ref@(Reference addr) val (Heap nextFreeAddr binds) = do
>>   weakVal <- mkWeak ref val Nothing
>>   return $ Heap nextFreeAddr (Map.insert addr weakVal binds)
>
> Note the new type, Reference. This replaces Address everywhere except
> in the heap's internal structure, which continues to use Address.
> Reference values are opaque, unique and obtained from the heap using
> heapAlloc.
>
> The idea is that only two things should cause Values to stay alive:
> 1. reachable holders of Reference (by GHC's definition of "reachable"),
> 2. ordinary Haskell closures arising from stepping the interpreter.
> "Being in the Heap" should not be enough to keep a Value alive. Then,
> my heapGC function should only have to prune dead addresses from the
> map.
>
> I am having trouble getting a proof-of-concept working (I am unable to
> observe any finalizers running, ever), but before I get into that, is
> this idea sound? Has somebody else implemented this in a library
> already?

On 6 October 2015 at 21:39, Sumit Sahrawat, Maths & Computing, IIT
(BHU) <sumit.sahrawat.apm13 at iitbhu.ac.in> wrote:
> This would be well recieved on ghc-devs mailing list. Adding to cc.

Maybe. My question has nothing to do with the development of GHC itself.
Perhaps I should have been more clear - I am implementing this
interpreter as a straightforward Haskell program. I apologize to
ghc-devs if this is inbox noise to them.

To be clear, I will re-state my question another way. I am writing an
interpreter for a simple programming language in Haskell. The
interpreter needs to implement a garbage-collected storage area (heap).
At this stage, my "Heap" is actually just a "Map Address Value", plus
some administrative fields. Some of the constructors of Value contain
Addresses. Address is just a newtype for Int. I am faced with the
problem of removing unreachable Values from this map to fix unbounded
space usage. My question is: Rather than traverse the graph of values
and re-invent a true garbage collector, can I change this to "Map
Address (Weak Value)" (Weak from System.Mem.Weak) and have the Haskell
runtime reclaim unreachable Values for me?

My original post (quoted above) has more detail on what I attempted (but
it doesn't work - as far as I can tell nothing is ever reclaimed).

Thanks,
--
Thomas Koster

From ratzes at gmail.com  Mon Oct 12 00:58:53 2015
From: ratzes at gmail.com (Charles Durham)
Date: Sun, 11 Oct 2015 20:58:53 -0400
Subject: [Haskell-cafe] A suggestion: On why code merges should
 influence Haskell design
In-Reply-To: <CAEc4Ma3ctVR8cdATxr-cg+e_-noGM4yX+vwJs_FnaZv54EAMuQ@mail.gmail.com>
References: <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <5616BB8A.1080807@orlitzky.com>
 <CAJUDvciWQuABPg+OzNEwnKkq95V0X683k5x=bH66GHEYkYx32Q@mail.gmail.com>
 <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local>
 <CAJUDvcjr4n3ftUOdzaLPS1puRPYODpPq0f5DMMGuOisMtpRh+A@mail.gmail.com>
 <CANBN=mvy6iMOTFzYX989CtDuvoJ4r5VKRVEjDr5B+yu6AhQ4jA@mail.gmail.com>
 <5617B9AD.90703@ciktel.net> <BCB21A7B440D4ACB4639A75AAC892A@mail.local>
 <5617E178.9000506@stilo.com> <5619C4F5.3060800@ucdavis.edu>
 <CACz_ru2dLq5MCQXrXnyoHL+eUNsr9jXg_5iD6NjgP7Y8U8EMLQ@mail.gmail.com>
 <CAEc4Ma3ctVR8cdATxr-cg+e_-noGM4yX+vwJs_FnaZv54EAMuQ@mail.gmail.com>
Message-ID: <CAEXAPH7ygrf-35o1W8_9nDEjgkkS8RqzzHexeDpMZGBGSa4t6g@mail.gmail.com>

1. If you have a merge take place in two lines right next to each other,
say one variable is declared in one and a function processes that variable
in another, if those two are responsible together for exiting a loop, then
you're going to be solving the Halting Problem to show there are no bugs.

2. If you have one function "f(x) = a + bx + cx^2 +..." and another
function that iterates through integers until a solution is found in
integers, then if the internals of either is changed (either the constants
in f, or the search strategy), then you're going to have to be solving
"Hilberts 10th Problem" to understand that there are no bugs introduced,
thought this was interesting as the changes are "further" apart.

At least for the general case, this should be a problem for all Turing
Complete languages. It might be interesting to think about finding sections
of code that are "Total", and perhaps put certain guarantees on that, but
there still might be weird ways that two lines of code can play with each
other beyond that.

I hope this isn't overly pedantic, or that I'm not completely off base.

On Sun, Oct 11, 2015 at 8:10 PM, Jeffrey Brown <jeffbrown.the at gmail.com>
wrote:

> +1 for AST merge. Writing code from text is reasonable, but storing code
> as text is lunacy.
>
> On Sat, Oct 10, 2015 at 11:17 PM, Sean Leather <sean.leather at gmail.com>
> wrote:
>
>> On Sun, Oct 11, 2015 at 4:09 AM, Dimitri DeFigueiredo wrote:
>>
>>> Can we write a "compiler-like" merge tool for Haskell?
>>
>>
>> Merge could be considered to be a combination of diff and patch. And so
>> you might want to merge ASTs, which are typically families of datatypes.
>> Related: Type-Safe Diff for Families of Dataypes:
>> http://www.andres-loeh.de/gdiff-wgp.pdf
>>
>> Regards,
>> Sean
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>
>
> --
> Jeffrey Benjamin Brown
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151011/9667177c/attachment.html>

From alexey.raga at gmail.com  Mon Oct 12 12:34:54 2015
From: alexey.raga at gmail.com (Alexey Raga)
Date: Mon, 12 Oct 2015 12:34:54 +0000
Subject: [Haskell-cafe] GHC 7.10.2 Stage 1 compiler
Message-ID: <CACf4mn_+ev8FDJZaSKjF2McRF4Vf39i_z-pyuqQe4Fx6a2YRPg@mail.gmail.com>

Hello,

On the "Download" page (https://www.haskell.org/ghc/download_ghc_7_10_2) I
see the archive with the binaries for ARM. Unfortunately this archive
doesn't seem to include stage 1 compiler (which would be a cross-compiler
from x86 or x64 to ARM as far as I understand).

I am trying to build one myself, but unfortunately no luck so far.

Is it possible to know the detailed instructions on how the existing ARM
package has been built? A script or a dockerfile would be ideal.

I could tune that build and make a docker container that could
cross-compile x64 -> ARM...

Regards,
Alexey.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151012/b036f46b/attachment.html>

From s.j.thompson at kent.ac.uk  Mon Oct 12 13:55:32 2015
From: s.j.thompson at kent.ac.uk (Simon Thompson)
Date: Mon, 12 Oct 2015 14:55:32 +0100
Subject: [Haskell-cafe] CFP: Workshop on Real World Domain Specific
	Languages, March 2016
Message-ID: <57F1B9D7-FD15-4D3C-ACB8-FB0EA1AD1BA8@kent.ac.uk>




CALL FOR PAPERS

=================================
Workshop on Real World Domain Specific Languages

https://sites.google.com/site/realworlddsl

In conjunction with 

The International Symposium on Code Generation and Optimisation 2016.
http://cgo.org/cgo2016

Barcelona, 12-13 March, 2016
=================================

As the use of computers proliferates, the complexity and variety of
systems continues to grow. As a result, it is becoming increasingly
inflexible to "hard wire? behaviours into software. Software
developers can enable more control over their software configurations
by exploiting Domain Specific Languages (DSLs). Such DSLs provide a
systematic way to structure the underlying computational components:
to coin a phrase, a DSL is a library with syntax.

There is an enormous variety of DSLs for a very wide range of
domains. Most DSLs are highly idiosyncratic, reflecting both the
specific natures of their application domains and their designers? own
preferences. This workshop will bring together constructors of DSLs
for ?real world? domains; that is, DSLs intended primarily to aid in
building software to solve real world problems rather than to explore
the more theoretical aspects of language design and implementation. We
are looking for submissions that present the motivation, design,
implementation, use and evaluation of such DSLs.


=================================

Key Dates:
----------------
Paper submission deadline: 10 January 2016.
Author notification:       2 February 2016.
Final manuscript due:     21 February 2016.
Workshop:                 12-13 March 2016.
----------------

Submission Instructions:

The EasyChair submission page for this workshop is
https://easychair.org/conferences/?conf=rwdsl16

Accepted submissions will be published in the ACM Digital Library
within its International Conference Proceedings Series. Submissions
should be 8-10 in ACM double-column format. Authors should follow the
information for formatting ACM SIGPLAN conference papers, which can be
found at http://www.sigplan.org/Resources/Author. We will provide more
details of the submissions format and process at the beginning of
November.

=================================

Program Chairs
Rob Stewart, Heriot-Watt University
Greg Michaelson, Heriot-Watt University

PC Members
Jost Berthold, Commonwealth Bank of Australia
Andy Gill, University of Kansas
Kevin Hammond, University of St Andrews
Rita Loogen, Philipps Universitat Marburg
Patrick Maier, University of Glasgow
Josef Svenningsson, Chalmers University
Simon Thompson, University of Kent
Phil Trinder, University of Glasgow

Contact
Please email inquiries concerning the workshop to: R.Stewart at hw.ac.uk




Simon Thompson | Professor of Logic and Computation 
School of Computing | University of Kent | Canterbury, CT2 7NF, UK
s.j.thompson at kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt


From defigueiredo at ucdavis.edu  Mon Oct 12 19:20:29 2015
From: defigueiredo at ucdavis.edu (Dimitri DeFigueiredo)
Date: Mon, 12 Oct 2015 13:20:29 -0600
Subject: [Haskell-cafe] A suggestion: On why code merges should
 influence Haskell design
In-Reply-To: <CAEXAPH7ygrf-35o1W8_9nDEjgkkS8RqzzHexeDpMZGBGSa4t6g@mail.gmail.com>
References: <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <5616BB8A.1080807@orlitzky.com>
 <CAJUDvciWQuABPg+OzNEwnKkq95V0X683k5x=bH66GHEYkYx32Q@mail.gmail.com>
 <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local>
 <CAJUDvcjr4n3ftUOdzaLPS1puRPYODpPq0f5DMMGuOisMtpRh+A@mail.gmail.com>
 <CANBN=mvy6iMOTFzYX989CtDuvoJ4r5VKRVEjDr5B+yu6AhQ4jA@mail.gmail.com>
 <5617B9AD.90703@ciktel.net> <BCB21A7B440D4ACB4639A75AAC892A@mail.local>
 <5617E178.9000506@stilo.com> <5619C4F5.3060800@ucdavis.edu>
 <CACz_ru2dLq5MCQXrXnyoHL+eUNsr9jXg_5iD6NjgP7Y8U8EMLQ@mail.gmail.com>
 <CAEc4Ma3ctVR8cdATxr-cg+e_-noGM4yX+vwJs_FnaZv54EAMuQ@mail.gmail.com>
 <CAEXAPH7ygrf-35o1W8_9nDEjgkkS8RqzzHexeDpMZGBGSa4t6g@mail.gmail.com>
Message-ID: <561C07FD.5070304@ucdavis.edu>

I think both these examples strengthen my argument! :-)

There is no problem at all in the second and the first one precisely 
show us a situation when we would like to know there is a conflict.

The guarantee I want is that when merging 2 branches A and B:
*If there are no conflicts*, the merge tool guarantees the merge output 
introduces no new bugs *other than those already found in A or B*.

Note:
1. we get to define what a conflict is and
2. we don't care if the bugs were already present in either branch.

On the first example, I assume both branches A and B will compile and 
run before the merge so that we are really only changing the value of 
the variable on branch A and the definition of the function on branch B 
(otherwise the branches would not compile before the merge).

Because the definition of the function depends on a *specific* value the 
variable, there is no way to avoid declaring a conflict. But notice that 
in the more general case where the function puts that value as a 
parameter there is no conflict, because if there were a bug it would 
already be present in branch B. So, the merge process is not introducing 
any bugs by itself.

This is exactly what happens in the second example. I assume branch A 
provides the new definition of f(x) and that in branch B we change the 
search strategy in the search function g. However, I assume that g would 
take f as a parameter g:: (Integer -> Integer) -> Integer. In this case, 
if there were a bug in g in the merged output, then it would already be 
present in branch B before the merge. Therefore, there is no conflict at 
all here.

In summary, there is no conflict on the second example and I would like 
to know about the conflict due to the global dependency on the first one.


Dimitri


On 10/11/15 6:58 PM, Charles Durham wrote:
> 1. If you have a merge take place in two lines right next to each 
> other, say one variable is declared in one and a function processes 
> that variable in another, if those two are responsible together for 
> exiting a loop, then you're going to be solving the Halting Problem to 
> show there are no bugs.
>
> 2. If you have one function "f(x) = a + bx + cx^2 +..." and another 
> function that iterates through integers until a solution is found in 
> integers, then if the internals of either is changed (either the 
> constants in f, or the search strategy), then you're going to have to 
> be solving "Hilberts 10th Problem" to understand that there are no 
> bugs introduced, thought this was interesting as the changes are 
> "further" apart.
>
> At least for the general case, this should be a problem for all Turing 
> Complete languages. It might be interesting to think about finding 
> sections of code that are "Total", and perhaps put certain guarantees 
> on that, but there still might be weird ways that two lines of code 
> can play with each other beyond that.
>
> I hope this isn't overly pedantic, or that I'm not completely off base.
>
> On Sun, Oct 11, 2015 at 8:10 PM, Jeffrey Brown 
> <jeffbrown.the at gmail.com <mailto:jeffbrown.the at gmail.com>> wrote:
>
>     +1 for AST merge. Writing code from text is reasonable, but
>     storing code as text is lunacy.
>
>     On Sat, Oct 10, 2015 at 11:17 PM, Sean Leather
>     <sean.leather at gmail.com <mailto:sean.leather at gmail.com>> wrote:
>
>         On Sun, Oct 11, 2015 at 4:09 AM, Dimitri DeFigueiredo wrote:
>
>             Can we write a "compiler-like" merge tool for Haskell?
>
>
>         Merge could be considered to be a combination of diff and
>         patch. And so you might want to merge ASTs, which are
>         typically families of datatypes. Related: Type-Safe Diff for
>         Families of Dataypes: http://www.andres-loeh.de/gdiff-wgp.pdf
>
>         Regards,
>         Sean
>
>         _______________________________________________
>         Haskell-Cafe mailing list
>         Haskell-Cafe at haskell.org <mailto:Haskell-Cafe at haskell.org>
>         http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
>
>
>     -- 
>     Jeffrey Benjamin Brown
>
>     _______________________________________________
>     Haskell-Cafe mailing list
>     Haskell-Cafe at haskell.org <mailto:Haskell-Cafe at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151012/a6443aae/attachment.html>

From dct25-561bs at mythic-beasts.com  Mon Oct 12 20:16:13 2015
From: dct25-561bs at mythic-beasts.com (David Turner)
Date: Mon, 12 Oct 2015 21:16:13 +0100
Subject: [Haskell-cafe] A suggestion: On why code merges should
 influence Haskell design
In-Reply-To: <5619C4F5.3060800@ucdavis.edu>
References: <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <5616BB8A.1080807@orlitzky.com>
 <CAJUDvciWQuABPg+OzNEwnKkq95V0X683k5x=bH66GHEYkYx32Q@mail.gmail.com>
 <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local>
 <CAJUDvcjr4n3ftUOdzaLPS1puRPYODpPq0f5DMMGuOisMtpRh+A@mail.gmail.com>
 <CANBN=mvy6iMOTFzYX989CtDuvoJ4r5VKRVEjDr5B+yu6AhQ4jA@mail.gmail.com>
 <5617B9AD.90703@ciktel.net>
 <BCB21A7B440D4ACB4639A75AAC892A@mail.local>
 <5617E178.9000506@stilo.com> <5619C4F5.3060800@ucdavis.edu>
Message-ID: <CAErCyQ-VkB6-tkDWEYwVKcyga9czxAjqiKvjCY+_p4zaVKcZeA@mail.gmail.com>

Hi,

I work on a team of ~15 developers and we follow a merge-free process using
rebasing. Although in theory it sounds like you'll get the same problems
with rebasing as with merging, over 6 years and 100,000+ commits I'm
struggling to think of a single bug silently introduced due to a rebase
that succeeded without conflicts. It's a cunning bit of social engineering:
when merging the work of two developers, it's easy for both of them to
disclaim responsibility for any bugs introduced by the merge, but when
rebasing the work of developer A on top of that of developer B it's clear
that any bugs are dev A's responsibility as their commits come later in the
published history than dev B's, and this gives dev A the incentive to check
for semantic conflicts properly.

That said, it's theoretically possible to introduce bugs with a 'clean'
rebase, just as with merging, and I'm interested in your suggestion because
of that. The difficulty I see is defining what you mean by "no new bugs".
The two branches satisfy two different specifications, and my reading of
"no new bugs" is that the merge result satisfies a merged specification. It
sounds difficult to automatically merge two specs together in general,
although in practice specs are often quite informal and where a rebase
looks questionable a merged spec can be invented and verified with human
intervention, remembering that the rebasing developer has a personal
incentive to get this right.

There's two kind of formal spec that I know of in common usage in the
industry: types and tests. Using a type system gives you a bunch of
theorems about what your program can and cannot do, and this is checked at
compile time, and an automated test suite is basically a bunch of
properties that your program satisfies which can be verified by running the
test suite. Neither of these can capture the real spec exactly, but in
practice they turn out to be good enough for many purposes. For those cases
where that's not enough you can bring out the heavy artillery of a theorem
prover, and this does let you write down the real spec exactly and verify
it either side of a merge or rebase. I wouldn't say that approach was in
common usage but it does get used where the investment is worth it.

Verifying that changes to the type system leave the real spec satisfied
sounds quite hard in general. Merging additions to the test suite sounds
easy but other changes to the part of the spec embodied in the test suite
also sounds hard in general. Of the three, merging changes to an
automatically-proved theorem actually feels easiest - my experience is that
keeping a (well-written) automatic proof in sync with changes to code is
often not that hard, and when it is hard it's normally been because the
changes to the code meant the theorem was no longer true.

Perhaps enriching the type system to a point where you can write truly
useful specs in it is the answer? Thus dependent types.

Cheers,

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151012/47b46056/attachment.html>

From vigalchin at gmail.com  Tue Oct 13 08:41:05 2015
From: vigalchin at gmail.com (Vasili I. Galchin)
Date: Tue, 13 Oct 2015 01:41:05 -0700
Subject: [Haskell-cafe] https://hackage.haskell.org/package/hoq build
	problems
Message-ID: <CA+0XtC8vYmksVF+iUkq2G1JL9jYPDwPJrjWesqvhzuV=ej7dnQ@mail.gmail.com>

Hello,

     I stumbled across hoq and it sounds very interesting to me.
However, it has build problems now enumerated in the official build
reports. I was thinking to investigate and possibly fix these build
problems.

     However, when I run "cabal configure", I already ran into a problem:

"unrecognized option `--extra-prog-path=/home/vasili/.cabal/bin'"

I have been trying to track this down. Not sure how to fix this. Any help??

Regards,

Vasily

From andreas.abel at ifi.lmu.de  Tue Oct 13 17:22:30 2015
From: andreas.abel at ifi.lmu.de (Andreas Abel)
Date: Tue, 13 Oct 2015 19:22:30 +0200
Subject: [Haskell-cafe] https://hackage.haskell.org/package/hoq build
 problems
In-Reply-To: <CA+0XtC8vYmksVF+iUkq2G1JL9jYPDwPJrjWesqvhzuV=ej7dnQ@mail.gmail.com>
References: <CA+0XtC8vYmksVF+iUkq2G1JL9jYPDwPJrjWesqvhzuV=ej7dnQ@mail.gmail.com>
Message-ID: <561D3DD6.1060101@ifi.lmu.de>

This worked for me:

   git clone git at github.com:valis/hoq.git
   cd hoq
   cabal install

$ cabal --version
cabal-install version 1.22.4.0
using version 1.22.2.0 of the Cabal library
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.8.4

Cheers,
Andreas

On 13.10.2015 10:41, Vasili I. Galchin wrote:
> Hello,
>
>       I stumbled across hoq and it sounds very interesting to me.
> However, it has build problems now enumerated in the official build
> reports. I was thinking to investigate and possibly fix these build
> problems.
>
>       However, when I run "cabal configure", I already ran into a problem:
>
> "unrecognized option `--extra-prog-path=/home/vasili/.cabal/bin'"
>
> I have been trying to track this down. Not sure how to fix this. Any help??
>
> Regards,
>
> Vasily
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>


-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

andreas.abel at gu.se
http://www2.tcs.ifi.lmu.de/~abel/

From byorgey at gmail.com  Tue Oct 13 17:59:24 2015
From: byorgey at gmail.com (Brent Yorgey)
Date: Tue, 13 Oct 2015 17:59:24 +0000
Subject: [Haskell-cafe] [Announce] haskintex-0.6.0.0
In-Reply-To: <56185AF9.6080708@gmail.com>
References: <CAJFXAQhMonbVNi3tJRejrfLJoFa1yL1hoh2o5duFNT0hbetEKQ@mail.gmail.com>
 <56181637.30607@gmail.com>
 <CAO27hRoDoyBH9HNNp-poTAiedy69QCiE4gyj-Z+D=+sZ1a1qpg@mail.gmail.com>
 <56185AF9.6080708@gmail.com>
Message-ID: <CAH0njds8=VsA1VRe09AA1TaS3yXEMHF1M7HM9HBq19kSeqPv6w@mail.gmail.com>

You can easily have a standalone Haskell file when using `diagrams-latex`.
All you have to do is

\begin{diagram}[width=100]
  import StandaloneHaskellFile
  dia = someDiagramDefinedThere
\end{diagram}

-Brent

On Fri, Oct 9, 2015 at 7:25 PM Andrey Chudnov <achudnov at gmail.com> wrote:

> Thanks, Ryan. The tutorial is really good and to-the-point.
>
> By the way, it looks like haskintex has a more general approach to
> integrating Haskell in LaTeX. It seems that in principle it could just use
> that to enable including diagrams in latex, without `diagrams-latex`.
>
> And the same question about including a Haskell source instead of inlining
> applies. To me, having a standalone Haskell file is superior since I can
> get syntax highlighting, typechecking and even quick REPL debugging of
> diagrams that way. While with the inlined one needs to re-pdflatex the
> whole thing to get type errors (do they even show up in the latex output?)
> and reflect the changes. I guess, that could be done with the PGF backend
> for diagrams and a suitable Makefile, though.
>
>
> On 10/09/2015 07:48 PM, Ryan Yates wrote:
>
> You can incorporate diagrams from the `diagrams` package inline in LaTeX
> using diagrams-builder.  We have a tutorial written up here:
>
> http://projects.haskell.org/diagrams/doc/latex.html
>
> I imagine haskintex has a more sophisticated technique and it would be
> interesting to integrate diagrams with that approach too.
>
> Ryan
>
> On Fri, Oct 9, 2015 at 3:32 PM, Andrey Chudnov <achudnov at gmail.com> wrote:
>
>> Daniel,
>> Can this be used in conjunction with the `diagrams` package to generate
>> diagrams in LaTeX instead of suffering through Tikz?
>> Is it possible to include a Haskell source file instead of inlining it in
>> the tex file?
>>
>>
>> On 10/09/2015 12:33 PM, Daniel D?az Casanueva wrote:
>>
>> Dear Haskell users,
>>
>> I just released a new version of haskintex, the program that runs Haskell
>> code inside LaTeX documents.
>>
>> http://hackage.haskell.org/package/haskintex
>>
>> # More about haskintex
>>
>> For those who don't know the program yet, _haskintex_ is a tool that
>> executes Haskell code inside LaTeX documents, creating a new LaTeX document
>> where each Haskell expression has been replaced by its result. Furthermore,
>> since haskintex has a special command for using the HaTeX library, you will
>> be able to write Haskell code that generates LaTeX code. Find more details
>> in the haskintex documentation page:
>>
>> http://daniel-diaz.github.io/projects/haskintex
>>
>> # What's new?
>>
>> One of the main issues when evaluating Haskell code with haskintex was
>> that haskintex was not aware of sandbox environments, so it had to rely on
>> user or global package databases. From version 0.6.0.0, haskintex can now
>> detect and use sandbox package databases, with no additional effort
>> required from you. The -nosandbox flag has been added in case you still
>> want the old behavior.
>>
>> Another addition is the -autotexy flag. Without the flag, every
>> expression contained in a \hatex command is required to have type LaTeX.
>> When the flag is enabled, this restriction is relaxed to any type that is
>> an instance of the Texy typeclass. This typeclass contains instances for
>> types that can be rendered to LaTeX syntax. Could be some text, numbers, or
>> even matrices. You can create your own instances too.
>>
>> Suggestions, bugs, questions? Head to the haskintex issue tracker:
>>
>> https://github.com/Daniel-Diaz/haskintex/issues
>>
>> Happy texing,
>> Daniel D?az.
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151013/53c17cee/attachment.html>

From mikhail.glushenkov at gmail.com  Tue Oct 13 19:43:31 2015
From: mikhail.glushenkov at gmail.com (Mikhail Glushenkov)
Date: Tue, 13 Oct 2015 21:43:31 +0200
Subject: [Haskell-cafe] https://hackage.haskell.org/package/hoq build
	problems
In-Reply-To: <CA+0XtC8vYmksVF+iUkq2G1JL9jYPDwPJrjWesqvhzuV=ej7dnQ@mail.gmail.com>
References: <CA+0XtC8vYmksVF+iUkq2G1JL9jYPDwPJrjWesqvhzuV=ej7dnQ@mail.gmail.com>
Message-ID: <CA+tcxkBCMZoyVVhTKJ3Z7N0YfWRZAVZu-03y_w1ARZj6MQC10w@mail.gmail.com>

Hi,

On 13 October 2015 at 10:41, Vasili I. Galchin <vigalchin at gmail.com> wrote:
> [...]
> "unrecognized option `--extra-prog-path=/home/vasili/.cabal/bin'"
> [...]

Upgrading to a newer GHC and/or cabal-install should fix this, I think.

Which versions of GHC/cabal-install are you using? What is the output
of 'cabal configure -v3'?

From defigueiredo at ucdavis.edu  Tue Oct 13 20:08:14 2015
From: defigueiredo at ucdavis.edu (Dimitri DeFigueiredo)
Date: Tue, 13 Oct 2015 14:08:14 -0600
Subject: [Haskell-cafe] A suggestion: On why code merges should
 influence Haskell design
In-Reply-To: <CAErCyQ-VkB6-tkDWEYwVKcyga9czxAjqiKvjCY+_p4zaVKcZeA@mail.gmail.com>
References: <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <5616BB8A.1080807@orlitzky.com>
 <CAJUDvciWQuABPg+OzNEwnKkq95V0X683k5x=bH66GHEYkYx32Q@mail.gmail.com>
 <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local>
 <CAJUDvcjr4n3ftUOdzaLPS1puRPYODpPq0f5DMMGuOisMtpRh+A@mail.gmail.com>
 <CANBN=mvy6iMOTFzYX989CtDuvoJ4r5VKRVEjDr5B+yu6AhQ4jA@mail.gmail.com>
 <5617B9AD.90703@ciktel.net> <BCB21A7B440D4ACB4639A75AAC892A@mail.local>
 <5617E178.9000506@stilo.com> <5619C4F5.3060800@ucdavis.edu>
 <CAErCyQ-VkB6-tkDWEYwVKcyga9czxAjqiKvjCY+_p4zaVKcZeA@mail.gmail.com>
Message-ID: <561D64AE.8030308@ucdavis.edu>

The 6 years and 100K+ commits data point is pretty impressive! It makes 
me question how much effort should be devoted to avoiding these 
"merge-introduced" bugs in the first place. I assume this data point 
does not capture bugs introduced by merges that were found by unit tests 
though.

I hadn't looked at how to actually go about writing the "bug-free" merge 
tool (if it becomes possible to write one). However, I think my 
immediate approach would be different from your suggestion. I was 
thinking that we could just look at the dependency graph between the 
definitions.

Consider 2 possible (previously suggested) merge scenarios where we 
define both a variable and a function. In both scenarios:
- Branch A changes the "variable" (but does not change the function)
- Branch B changes the function

The scenarios are different because of the dependency between the 
function and the variable:
1. Function definition is independent of variable definition
https://gist.github.com/dimitri-xyz/f0819c947ecd386b84d6

2. Function definition dependents on variable definition
https://gist.github.com/dimitri-xyz/81a56b0ce0929e8513e9

Intuitively, I would like to have a merge conflict in scenario 2, but 
none in scenario 1. That suggests the following rule:

We have a conflict iif a definition *that was changed* in branch B 
depends (transitively) on a definition *that was change* in branch A or 
vice-versa.

In scenario 1, the definition of the function does not depend on the 
definition of the variable, so there is no conflict. Notice that 'main' 
depends on both, but it hasn't changed. In scenario 2, the definition of 
the functions has changed and it depends on the definition of the 
variable, so we would have a conflict.

I understand this may not be sufficient to ensure no bugs are 
introduced, but this is my first approximation. The rule just captures 
the notion that programmer's shouldn't have their assumptions pulled 
from under their feet as they make changes. I wonder if/how I could 
claim that 'main' (that depends on both the function and the variable) 
is "merge-bug free" in the merged version.

Cheers,

Dimitri



On 10/12/15 2:16 PM, David Turner wrote:
> Hi,
>
> I work on a team of ~15 developers and we follow a merge-free process 
> using rebasing. Although in theory it sounds like you'll get the same 
> problems with rebasing as with merging, over 6 years and 100,000+ 
> commits I'm struggling to think of a single bug silently introduced 
> due to a rebase that succeeded without conflicts. It's a cunning bit 
> of social engineering: when merging the work of two developers, it's 
> easy for both of them to disclaim responsibility for any bugs 
> introduced by the merge, but when rebasing the work of developer A on 
> top of that of developer B it's clear that any bugs are dev A's 
> responsibility as their commits come later in the published history 
> than dev B's, and this gives dev A the incentive to check for semantic 
> conflicts properly.
>
> That said, it's theoretically possible to introduce bugs with a 
> 'clean' rebase, just as with merging, and I'm interested in your 
> suggestion because of that. The difficulty I see is defining what you 
> mean by "no new bugs". The two branches satisfy two different 
> specifications, and my reading of "no new bugs" is that the merge 
> result satisfies a merged specification. It sounds difficult to 
> automatically merge two specs together in general, although in 
> practice specs are often quite informal and where a rebase looks 
> questionable a merged spec can be invented and verified with human 
> intervention, remembering that the rebasing developer has a personal 
> incentive to get this right.
>
> There's two kind of formal spec that I know of in common usage in the 
> industry: types and tests. Using a type system gives you a bunch of 
> theorems about what your program can and cannot do, and this is 
> checked at compile time, and an automated test suite is basically a 
> bunch of properties that your program satisfies which can be verified 
> by running the test suite. Neither of these can capture the real spec 
> exactly, but in practice they turn out to be good enough for many 
> purposes. For those cases where that's not enough you can bring out 
> the heavy artillery of a theorem prover, and this does let you write 
> down the real spec exactly and verify it either side of a merge or 
> rebase. I wouldn't say that approach was in common usage but it does 
> get used where the investment is worth it.
>
> Verifying that changes to the type system leave the real spec 
> satisfied sounds quite hard in general. Merging additions to the test 
> suite sounds easy but other changes to the part of the spec embodied 
> in the test suite also sounds hard in general. Of the three, merging 
> changes to an automatically-proved theorem actually feels easiest - my 
> experience is that keeping a (well-written) automatic proof in sync 
> with changes to code is often not that hard, and when it is hard it's 
> normally been because the changes to the code meant the theorem was no 
> longer true.
>
> Perhaps enriching the type system to a point where you can write truly 
> useful specs in it is the answer? Thus dependent types.
>
> Cheers,
>
> David


From alan.zimm at gmail.com  Tue Oct 13 20:55:43 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Tue, 13 Oct 2015 22:55:43 +0200
Subject: [Haskell-cafe] ghc-mod and IDE / plugin integration
Message-ID: <CANma=H_xneTtikkKZAfUu9-rgP238_=YxQyV+9oN5wdH2pCehg@mail.gmail.com>

Historically ghc-mod provided (and still does) support for emacs and vim as
part of its distribution.

It is also used by a number of other IDE backends to provide a way of
getting information about a project without worrying too much about the
details of how the project is organised on the file system.

There is currently a discussion between various interested parties about
adjusting the way ghc-mod communicates with the IDE, to make it simpler to
provide this support for other environments.

This should end up with a definition of a protocol that ghc-mod can expose,
which should also allow tools (such as HaRe) to be plugged into it, so that
IDE integration can be handled by the various IDE integrators in a clean,
common way.

This is all just hand waving at the moment, so if anyone would like to get
involved I am proposing that we revive the "Haskell IDE implementation"[1]
google group/mailing list to host the discussion.

The new design is/will be captured here [2]

Regards
  Alan

[1] https://groups.google.com/forum/#!forum/haskell-ide
[2] https://github.com/kazu-yamamoto/ghc-mod/wiki/Library-API-Redesign
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151013/c38a9aff/attachment.html>

From vigalchin at gmail.com  Wed Oct 14 01:18:55 2015
From: vigalchin at gmail.com (Vasili I. Galchin)
Date: Tue, 13 Oct 2015 18:18:55 -0700
Subject: [Haskell-cafe] https://hackage.haskell.org/package/hoq build
	problems
In-Reply-To: <CA+tcxkBCMZoyVVhTKJ3Z7N0YfWRZAVZu-03y_w1ARZj6MQC10w@mail.gmail.com>
References: <CA+0XtC8vYmksVF+iUkq2G1JL9jYPDwPJrjWesqvhzuV=ej7dnQ@mail.gmail.com>
 <CA+tcxkBCMZoyVVhTKJ3Z7N0YfWRZAVZu-03y_w1ARZj6MQC10w@mail.gmail.com>
Message-ID: <CA+0XtC-QKxcjCp4BOXq9ArFUWYhz6XVBofpXcL=ELHcas4R+qQ@mail.gmail.com>

vasili at vasili-VirtualBox:  cabal --version
cabal-install version 1.20.0.3
using version 1.20.0.2 of the Cabal library

vasili at vasili-VirtualBox: ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.6.3


OK ... I am running Ubuntu #31-Ubuntu. I am using apt-* install
manager. I am relying on the install manager team to furnish versions
of software. I will have  to directly haskell.org to upgrade, yes??

Vasily

On Tue, Oct 13, 2015 at 12:43 PM, Mikhail Glushenkov
<mikhail.glushenkov at gmail.com> wrote:
> Hi,
>
> On 13 October 2015 at 10:41, Vasili I. Galchin <vigalchin at gmail.com> wrote:
>> [...]
>> "unrecognized option `--extra-prog-path=/home/vasili/.cabal/bin'"
>> [...]
>
> Upgrading to a newer GHC and/or cabal-install should fix this, I think.
>
> Which versions of GHC/cabal-install are you using? What is the output
> of 'cabal configure -v3'?

From sumit.sahrawat.apm13 at iitbhu.ac.in  Wed Oct 14 02:20:14 2015
From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing,
 IIT (BHU))
Date: Wed, 14 Oct 2015 07:50:14 +0530
Subject: [Haskell-cafe] https://hackage.haskell.org/package/hoq build
	problems
In-Reply-To: <CA+0XtC-QKxcjCp4BOXq9ArFUWYhz6XVBofpXcL=ELHcas4R+qQ@mail.gmail.com>
References: <CA+0XtC8vYmksVF+iUkq2G1JL9jYPDwPJrjWesqvhzuV=ej7dnQ@mail.gmail.com>
 <CA+tcxkBCMZoyVVhTKJ3Z7N0YfWRZAVZu-03y_w1ARZj6MQC10w@mail.gmail.com>
 <CA+0XtC-QKxcjCp4BOXq9ArFUWYhz6XVBofpXcL=ELHcas4R+qQ@mail.gmail.com>
Message-ID: <CAJbEW8Pe0-ytvxB7CCWMhxRHr+Ccri0fos8fDu9chwNs5cFgpQ@mail.gmail.com>

The learnhaskell guide has instructions to get up to date versions of ghc
and cabal.

For Ubuntu:
https://github.com/bitemyapp/learnhaskell/blob/master/install.md#ubuntu

On 14 October 2015 at 06:48, Vasili I. Galchin <vigalchin at gmail.com> wrote:

> vasili at vasili-VirtualBox:  cabal --version
> cabal-install version 1.20.0.3
> using version 1.20.0.2 of the Cabal library
>
> vasili at vasili-VirtualBox: ghc --version
> The Glorious Glasgow Haskell Compilation System, version 7.6.3
>
>
> OK ... I am running Ubuntu #31-Ubuntu. I am using apt-* install
> manager. I am relying on the install manager team to furnish versions
> of software. I will have  to directly haskell.org to upgrade, yes??
>
> Vasily
>
> On Tue, Oct 13, 2015 at 12:43 PM, Mikhail Glushenkov
> <mikhail.glushenkov at gmail.com> wrote:
> > Hi,
> >
> > On 13 October 2015 at 10:41, Vasili I. Galchin <vigalchin at gmail.com>
> wrote:
> >> [...]
> >> "unrecognized option `--extra-prog-path=/home/vasili/.cabal/bin'"
> >> [...]
> >
> > Upgrading to a newer GHC and/or cabal-install should fix this, I think.
> >
> > Which versions of GHC/cabal-install are you using? What is the output
> > of 'cabal configure -v3'?
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>



-- 
Regards

Sumit Sahrawat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151014/b93d28e1/attachment.html>

From vigalchin at gmail.com  Wed Oct 14 04:20:58 2015
From: vigalchin at gmail.com (Vasili I. Galchin)
Date: Tue, 13 Oct 2015 21:20:58 -0700
Subject: [Haskell-cafe] https://hackage.haskell.org/package/hoq build
	problems
In-Reply-To: <CAJbEW8Pe0-ytvxB7CCWMhxRHr+Ccri0fos8fDu9chwNs5cFgpQ@mail.gmail.com>
References: <CA+0XtC8vYmksVF+iUkq2G1JL9jYPDwPJrjWesqvhzuV=ej7dnQ@mail.gmail.com>
 <CA+tcxkBCMZoyVVhTKJ3Z7N0YfWRZAVZu-03y_w1ARZj6MQC10w@mail.gmail.com>
 <CA+0XtC-QKxcjCp4BOXq9ArFUWYhz6XVBofpXcL=ELHcas4R+qQ@mail.gmail.com>
 <CAJbEW8Pe0-ytvxB7CCWMhxRHr+Ccri0fos8fDu9chwNs5cFgpQ@mail.gmail.com>
Message-ID: <CA+0XtC_OwMhW8XnnO3k2cipaxcioMz4Qrvjwse1TpWdnpbFfVQ@mail.gmail.com>

Thx everybody.
Vasily

On Tuesday, October 13, 2015, Sumit Sahrawat, Maths & Computing, IIT (BHU) <
sumit.sahrawat.apm13 at iitbhu.ac.in> wrote:

> The learnhaskell guide has instructions to get up to date versions of ghc
> and cabal.
>
> For Ubuntu:
> https://github.com/bitemyapp/learnhaskell/blob/master/install.md#ubuntu
>
> On 14 October 2015 at 06:48, Vasili I. Galchin <vigalchin at gmail.com
> <javascript:_e(%7B%7D,'cvml','vigalchin at gmail.com');>> wrote:
>
>> vasili at vasili-VirtualBox:  cabal --version
>> cabal-install version 1.20.0.3
>> using version 1.20.0.2 of the Cabal library
>>
>> vasili at vasili-VirtualBox: ghc --version
>> The Glorious Glasgow Haskell Compilation System, version 7.6.3
>>
>>
>> OK ... I am running Ubuntu #31-Ubuntu. I am using apt-* install
>> manager. I am relying on the install manager team to furnish versions
>> of software. I will have  to directly haskell.org to upgrade, yes??
>>
>> Vasily
>>
>> On Tue, Oct 13, 2015 at 12:43 PM, Mikhail Glushenkov
>> <mikhail.glushenkov at gmail.com
>> <javascript:_e(%7B%7D,'cvml','mikhail.glushenkov at gmail.com');>> wrote:
>> > Hi,
>> >
>> > On 13 October 2015 at 10:41, Vasili I. Galchin <vigalchin at gmail.com
>> <javascript:_e(%7B%7D,'cvml','vigalchin at gmail.com');>> wrote:
>> >> [...]
>> >> "unrecognized option `--extra-prog-path=/home/vasili/.cabal/bin'"
>> >> [...]
>> >
>> > Upgrading to a newer GHC and/or cabal-install should fix this, I think.
>> >
>> > Which versions of GHC/cabal-install are you using? What is the output
>> > of 'cabal configure -v3'?
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> <javascript:_e(%7B%7D,'cvml','Haskell-Cafe at haskell.org');>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>
>
>
> --
> Regards
>
> Sumit Sahrawat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151013/f7bc0b5a/attachment.html>

From alan.zimm at gmail.com  Wed Oct 14 06:42:42 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Wed, 14 Oct 2015 08:42:42 +0200
Subject: [Haskell-cafe] Haskell ecosystem improvements meta-propsal
In-Reply-To: <CAD=7U2BFbDKzkrNdRXxKKeKyCmM1AGJdJyPm0p8Ymaa2n05N6Q@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org> <etPan.56147308.2268a666.7b73@mbp.local>
 <CAD=7U2BASVF+cmnf+Ue=zXdZL26Od7n63wEL7jtZ7ZPAUgYW1A@mail.gmail.com>
 <CAAOoiFYnmVWhB1Etq=7e67b2hshn396waAFXJn0x0thD7wcB6Q@mail.gmail.com>
 <CAD=7U2BFbDKzkrNdRXxKKeKyCmM1AGJdJyPm0p8Ymaa2n05N6Q@mail.gmail.com>
Message-ID: <CANma=H9fx2yeG2YDq45ihrmhCztCS11e7huUUhB=5+m+KwuCgg@mail.gmail.com>

Here is another example of a language change RFC process

https://github.com/rust-lang/rfcs

Alan

On Wed, Oct 7, 2015 at 9:21 AM, Mike Meyer <mwm at mired.org> wrote:

> On Wed, Oct 7, 2015 at 1:45 AM Mark Lentczner <mark.lentczner at gmail.com>
> wrote:
>
>> On Tue, Oct 6, 2015 at 7:24 PM, Mike Meyer <mwm at mired.org> wrote:
>>
>>> I've dealt with the IETF RFC process and the Python PEP process, and
>>> both of them worked better than that.
>>
>>
>> While both those are good examples of mostly working organizations
>> shepherding foundational technical standard(s) along... there is one thing
>> more important than their processes: Their stance. Both organizations have
>> a very strong engineering discipline of keeping deployed things working
>> without change. I don't think it is enough to simply model their process.
>>
>
> Well, until Python 3, anyway.
>
> My goal wasn't to recreate the engineering discipline that deployed things
> keep working without change as you upgrade the ecosystem, it's to provide a
> mechanism so the community can more easily engage with the evolution of the
> ecosystem. Hopefully this will make it easier for the community to move
> things forward in a desirable manner. But it's a process, and leaves the
> question of whether the desire is for more stability or a less stagnant
> language up to the users of the process.
>
> I don't necessarily want to model the IETF or PEP processes. Those are a
> starting point. I tried to abstract the initial points out enough that the
> final result could be either one of them, or something totally unrelated
> that's a better fit for the Haskell community.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151014/50d04a11/attachment.html>

From svenpanne at gmail.com  Wed Oct 14 07:23:39 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Wed, 14 Oct 2015 09:23:39 +0200
Subject: [Haskell-cafe] A suggestion: On why code merges should
 influence Haskell design
In-Reply-To: <561D64AE.8030308@ucdavis.edu>
References: <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <5616BB8A.1080807@orlitzky.com>
 <CAJUDvciWQuABPg+OzNEwnKkq95V0X683k5x=bH66GHEYkYx32Q@mail.gmail.com>
 <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local>
 <CAJUDvcjr4n3ftUOdzaLPS1puRPYODpPq0f5DMMGuOisMtpRh+A@mail.gmail.com>
 <CANBN=mvy6iMOTFzYX989CtDuvoJ4r5VKRVEjDr5B+yu6AhQ4jA@mail.gmail.com>
 <5617B9AD.90703@ciktel.net>
 <BCB21A7B440D4ACB4639A75AAC892A@mail.local>
 <5617E178.9000506@stilo.com> <5619C4F5.3060800@ucdavis.edu>
 <CAErCyQ-VkB6-tkDWEYwVKcyga9czxAjqiKvjCY+_p4zaVKcZeA@mail.gmail.com>
 <561D64AE.8030308@ucdavis.edu>
Message-ID: <CANBN=mt5w=vzRiP5kcJ4VWKro9yNV=_BJEjjMZrHBW7+LMWtFw@mail.gmail.com>

2015-10-13 22:08 GMT+02:00 Dimitri DeFigueiredo <defigueiredo at ucdavis.edu>:

> [...] I hadn't looked at how to actually go about writing the "bug-free"
> merge tool (if it becomes possible to write one).


Isn't the whole approach limited by Rices's theorem? (
https://en.wikipedia.org/wiki/Rice%27s_theorem) In general we have to deal
with partial functions, and the property you're talking about is definitely
not trivial in the theorem's sense. So this implies 2 choices:

   * You don't detect all problems caused by merging (no point in putting
some effort into that approach, it's basically what we have today with
plain 'git merge').

   * You have false positives, i.e. the merge tool complains although the
merge is OK.

So the best you can do AFAICT is to keep the amount of false positives low,
hoping that people will see a benefit for the added annoyances.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151014/58a1b95b/attachment.html>

From dct25-561bs at mythic-beasts.com  Wed Oct 14 08:14:21 2015
From: dct25-561bs at mythic-beasts.com (David Turner)
Date: Wed, 14 Oct 2015 09:14:21 +0100
Subject: [Haskell-cafe] A suggestion: On why code merges should
 influence Haskell design
In-Reply-To: <561D64AE.8030308@ucdavis.edu>
References: <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <5616BB8A.1080807@orlitzky.com>
 <CAJUDvciWQuABPg+OzNEwnKkq95V0X683k5x=bH66GHEYkYx32Q@mail.gmail.com>
 <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local>
 <CAJUDvcjr4n3ftUOdzaLPS1puRPYODpPq0f5DMMGuOisMtpRh+A@mail.gmail.com>
 <CANBN=mvy6iMOTFzYX989CtDuvoJ4r5VKRVEjDr5B+yu6AhQ4jA@mail.gmail.com>
 <5617B9AD.90703@ciktel.net>
 <BCB21A7B440D4ACB4639A75AAC892A@mail.local>
 <5617E178.9000506@stilo.com> <5619C4F5.3060800@ucdavis.edu>
 <CAErCyQ-VkB6-tkDWEYwVKcyga9czxAjqiKvjCY+_p4zaVKcZeA@mail.gmail.com>
 <561D64AE.8030308@ucdavis.edu>
Message-ID: <CAErCyQ9E=2MrUy+ps1JSdp1pWCWu=f6QZH5C4hu8QQu5jA0U5Q@mail.gmail.com>

Yes, you're quite right, it's not uncommon for the result of a rebase
either not to compile or else to fail some set of tests. But then that's
also true of all code changes even by a single developer in isolation.

A dependency analysis is an interesting idea (indeed, it's one of the tools
we use to work out what the rough consequences of a change will be) but
risks both false positives and false negatives. On the false positive side,
as you observe, there'll often be something like 'main' which transitively
depends on two parallel changes. On the false negative side, you can get
conflicting changes that occur in separate programs - for instance the two
sides of a network protocol - and a naive dependency analysis will miss
this kind of problem. Heck, the changes could be in different languages
(think browser-side JS talking via AJAX to server-side Haskell). Or even in
separate repositories, possibly even developed by separate organisations,
so you can't even tell you've done a merge let alone tell that it contains
conflicts!

Because of this sort of reasoning, I'm sceptical that the problem of
'bugs-introduced-by-merges' is really any easier than the general problem
of 'bugs'. It's a continuum, not a clearly-defined subclass of bugs.

I realised that there's another way to justify the unreasonable
effectiveness of rebasing over merging. Assuming (conscientious) developers
A & B making parallel changes:

A1 -> A2 -> .... -> An
B1 -> B2 -> .... -> Bm

Each individual change can be seen to be correct, because that's how
conscientious developers work. But then when it comes to merging, from
their individual points of view it looks like:

A1 -> A2 -> .... -> An -> [all of B's changes in one go]
B1 -> B2 -> .... -> Bm -> [all of A's changes in one go]

It's very hard for either A or B to reason about the correctness of that
last step because it's such a big change. On the other hand, rebasing B's
changes on top of A's looks like this:

A1 -> A2 -> .... -> An -> B1' -> B2' -> .... -> Bm'

Then B can go through their rebased changes and use pretty much the same
reasoning as they were using before to check that they're still correct.

Cheers,





On 13 October 2015 at 21:08, Dimitri DeFigueiredo <defigueiredo at ucdavis.edu>
wrote:

> The 6 years and 100K+ commits data point is pretty impressive! It makes me
> question how much effort should be devoted to avoiding these
> "merge-introduced" bugs in the first place. I assume this data point does
> not capture bugs introduced by merges that were found by unit tests though.
>
> I hadn't looked at how to actually go about writing the "bug-free" merge
> tool (if it becomes possible to write one). However, I think my immediate
> approach would be different from your suggestion. I was thinking that we
> could just look at the dependency graph between the definitions.
>
> Consider 2 possible (previously suggested) merge scenarios where we define
> both a variable and a function. In both scenarios:
> - Branch A changes the "variable" (but does not change the function)
> - Branch B changes the function
>
> The scenarios are different because of the dependency between the function
> and the variable:
> 1. Function definition is independent of variable definition
> https://gist.github.com/dimitri-xyz/f0819c947ecd386b84d6
>
> 2. Function definition dependents on variable definition
> https://gist.github.com/dimitri-xyz/81a56b0ce0929e8513e9
>
> Intuitively, I would like to have a merge conflict in scenario 2, but none
> in scenario 1. That suggests the following rule:
>
> We have a conflict iif a definition *that was changed* in branch B depends
> (transitively) on a definition *that was change* in branch A or vice-versa.
>
> In scenario 1, the definition of the function does not depend on the
> definition of the variable, so there is no conflict. Notice that 'main'
> depends on both, but it hasn't changed. In scenario 2, the definition of
> the functions has changed and it depends on the definition of the variable,
> so we would have a conflict.
>
> I understand this may not be sufficient to ensure no bugs are introduced,
> but this is my first approximation. The rule just captures the notion that
> programmer's shouldn't have their assumptions pulled from under their feet
> as they make changes. I wonder if/how I could claim that 'main' (that
> depends on both the function and the variable) is "merge-bug free" in the
> merged version.
>
> Cheers,
>
> Dimitri
>
>
>
>
> On 10/12/15 2:16 PM, David Turner wrote:
>
>> Hi,
>>
>> I work on a team of ~15 developers and we follow a merge-free process
>> using rebasing. Although in theory it sounds like you'll get the same
>> problems with rebasing as with merging, over 6 years and 100,000+ commits
>> I'm struggling to think of a single bug silently introduced due to a rebase
>> that succeeded without conflicts. It's a cunning bit of social engineering:
>> when merging the work of two developers, it's easy for both of them to
>> disclaim responsibility for any bugs introduced by the merge, but when
>> rebasing the work of developer A on top of that of developer B it's clear
>> that any bugs are dev A's responsibility as their commits come later in the
>> published history than dev B's, and this gives dev A the incentive to check
>> for semantic conflicts properly.
>>
>> That said, it's theoretically possible to introduce bugs with a 'clean'
>> rebase, just as with merging, and I'm interested in your suggestion because
>> of that. The difficulty I see is defining what you mean by "no new bugs".
>> The two branches satisfy two different specifications, and my reading of
>> "no new bugs" is that the merge result satisfies a merged specification. It
>> sounds difficult to automatically merge two specs together in general,
>> although in practice specs are often quite informal and where a rebase
>> looks questionable a merged spec can be invented and verified with human
>> intervention, remembering that the rebasing developer has a personal
>> incentive to get this right.
>>
>> There's two kind of formal spec that I know of in common usage in the
>> industry: types and tests. Using a type system gives you a bunch of
>> theorems about what your program can and cannot do, and this is checked at
>> compile time, and an automated test suite is basically a bunch of
>> properties that your program satisfies which can be verified by running the
>> test suite. Neither of these can capture the real spec exactly, but in
>> practice they turn out to be good enough for many purposes. For those cases
>> where that's not enough you can bring out the heavy artillery of a theorem
>> prover, and this does let you write down the real spec exactly and verify
>> it either side of a merge or rebase. I wouldn't say that approach was in
>> common usage but it does get used where the investment is worth it.
>>
>> Verifying that changes to the type system leave the real spec satisfied
>> sounds quite hard in general. Merging additions to the test suite sounds
>> easy but other changes to the part of the spec embodied in the test suite
>> also sounds hard in general. Of the three, merging changes to an
>> automatically-proved theorem actually feels easiest - my experience is that
>> keeping a (well-written) automatic proof in sync with changes to code is
>> often not that hard, and when it is hard it's normally been because the
>> changes to the code meant the theorem was no longer true.
>>
>> Perhaps enriching the type system to a point where you can write truly
>> useful specs in it is the answer? Thus dependent types.
>>
>> Cheers,
>>
>> David
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151014/2bb699f0/attachment.html>

From jpmoresmau at gmail.com  Wed Oct 14 08:19:42 2015
From: jpmoresmau at gmail.com (JP Moresmau)
Date: Wed, 14 Oct 2015 09:19:42 +0100
Subject: [Haskell-cafe] ghc-mod and IDE / plugin integration
In-Reply-To: <CANma=H_xneTtikkKZAfUu9-rgP238_=YxQyV+9oN5wdH2pCehg@mail.gmail.com>
References: <CANma=H_xneTtikkKZAfUu9-rgP238_=YxQyV+9oN5wdH2pCehg@mail.gmail.com>
Message-ID: <CAAambFTUSy6nOxBdeb5-ntgHuCJiDGpK_eJ=vF1i8VuZf1j1fA@mail.gmail.com>

ide-backend (https://github.com/fpco/ide-backend) provides a JSON layer (
https://github.com/commercialhaskell/stack-ide). I haven't tried it, since
it requires stack and it's asking me to install the latest GHC 7.10.2
(sorry, I just wanted to have a look at the API, not reinstall a complete
Haskell stack again), but maybe there are some good ideas there.
But before talking about API, shouldn't we talk about why we have ghc-mod
and ide-backend? Can we merge them, or be clear what are their differences
and when/why we should use one and not the other? We don't have
fragmentation at the compiler level itself (with the dominance of GHC) but
we seem to have some at the "nicer API on top of GHC" level.
Or maybe, should we have something in GHC itself, something like a GHC
service that we could talk to via JSON or something, without having to use
the complex, changing with each release GHC API, and have that part of GHC
instead of having another tool to install?

My 2 cents,

JP

On Tue, Oct 13, 2015 at 9:55 PM, Alan & Kim Zimmerman <alan.zimm at gmail.com>
wrote:

> Historically ghc-mod provided (and still does) support for emacs and vim
> as part of its distribution.
>
> It is also used by a number of other IDE backends to provide a way of
> getting information about a project without worrying too much about the
> details of how the project is organised on the file system.
>
> There is currently a discussion between various interested parties about
> adjusting the way ghc-mod communicates with the IDE, to make it simpler to
> provide this support for other environments.
>
> This should end up with a definition of a protocol that ghc-mod can
> expose, which should also allow tools (such as HaRe) to be plugged into it,
> so that IDE integration can be handled by the various IDE integrators in a
> clean, common way.
>
> This is all just hand waving at the moment, so if anyone would like to get
> involved I am proposing that we revive the "Haskell IDE implementation"[1]
> google group/mailing list to host the discussion.
>
> The new design is/will be captured here [2]
>
> Regards
>   Alan
>
> [1] https://groups.google.com/forum/#!forum/haskell-ide
> [2] https://github.com/kazu-yamamoto/ghc-mod/wiki/Library-API-Redesign
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>


-- 
JP Moresmau
http://jpmoresmau.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151014/7edd033f/attachment.html>

From michael at snoyman.com  Wed Oct 14 09:20:24 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Wed, 14 Oct 2015 12:20:24 +0300
Subject: [Haskell-cafe] ghc-mod and IDE / plugin integration
In-Reply-To: <CAAambFTUSy6nOxBdeb5-ntgHuCJiDGpK_eJ=vF1i8VuZf1j1fA@mail.gmail.com>
References: <CANma=H_xneTtikkKZAfUu9-rgP238_=YxQyV+9oN5wdH2pCehg@mail.gmail.com>
 <CAAambFTUSy6nOxBdeb5-ntgHuCJiDGpK_eJ=vF1i8VuZf1j1fA@mail.gmail.com>
Message-ID: <CAKA2JgL_hVOD2zJ78ZMCMui79f3zCCX1pqtQfwnhyd1T+3GDJg@mail.gmail.com>

Thanks for kicking off this thread Alan. I'm 100% behind the idea of
working on unified tooling, and am happy to participate in making that
happen.

JP: You're right to bring up ide-backend. Let's start a real discussion (as
part of what Alan's kicked off here) about what the best future for these
projects would be. I don't want to predetermine the outcome of that
conversation now, but I can say that anything up to merging ide-backend
into ghc-mod and deprecating ide-backend as a separate project would be
acceptable to me. Whatever makes the most sense for improved community
tooling is what we should do.

As for stack-ide, we already have slowed down development on it as a result
of the changes to ghc-mod recently. None of us on the project had a chance
yet to really analyze the situation and sync up with the ghc-mod team yet
(mostly due to some travel), but at least IMO the ideal will be a single
tool that supports multiple project structures (cabal, cabal sandbox,
stack, etc) and various editor frontends.

I don't have much structured thought right now on what the end game of all
of this should look like, but I'll be happy to be part of the conversation
and help get us to that better tooling future.

On Wed, Oct 14, 2015 at 11:19 AM, JP Moresmau <jpmoresmau at gmail.com> wrote:

> ide-backend (https://github.com/fpco/ide-backend) provides a JSON layer (
> https://github.com/commercialhaskell/stack-ide). I haven't tried it,
> since it requires stack and it's asking me to install the latest GHC 7.10.2
> (sorry, I just wanted to have a look at the API, not reinstall a complete
> Haskell stack again), but maybe there are some good ideas there.
> But before talking about API, shouldn't we talk about why we have ghc-mod
> and ide-backend? Can we merge them, or be clear what are their differences
> and when/why we should use one and not the other? We don't have
> fragmentation at the compiler level itself (with the dominance of GHC) but
> we seem to have some at the "nicer API on top of GHC" level.
> Or maybe, should we have something in GHC itself, something like a GHC
> service that we could talk to via JSON or something, without having to use
> the complex, changing with each release GHC API, and have that part of GHC
> instead of having another tool to install?
>
> My 2 cents,
>
> JP
>
> On Tue, Oct 13, 2015 at 9:55 PM, Alan & Kim Zimmerman <alan.zimm at gmail.com
> > wrote:
>
>> Historically ghc-mod provided (and still does) support for emacs and vim
>> as part of its distribution.
>>
>> It is also used by a number of other IDE backends to provide a way of
>> getting information about a project without worrying too much about the
>> details of how the project is organised on the file system.
>>
>> There is currently a discussion between various interested parties about
>> adjusting the way ghc-mod communicates with the IDE, to make it simpler to
>> provide this support for other environments.
>>
>> This should end up with a definition of a protocol that ghc-mod can
>> expose, which should also allow tools (such as HaRe) to be plugged into it,
>> so that IDE integration can be handled by the various IDE integrators in a
>> clean, common way.
>>
>> This is all just hand waving at the moment, so if anyone would like to
>> get involved I am proposing that we revive the "Haskell IDE
>> implementation"[1] google group/mailing list to host the discussion.
>>
>> The new design is/will be captured here [2]
>>
>> Regards
>>   Alan
>>
>> [1] https://groups.google.com/forum/#!forum/haskell-ide
>> [2] https://github.com/kazu-yamamoto/ghc-mod/wiki/Library-API-Redesign
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>
>
> --
> JP Moresmau
> http://jpmoresmau.blogspot.com/
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151014/3e62cc2b/attachment-0001.html>

From svenpanne at gmail.com  Wed Oct 14 09:51:50 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Wed, 14 Oct 2015 11:51:50 +0200
Subject: [Haskell-cafe] A suggestion: On why code merges should
 influence Haskell design
In-Reply-To: <CAErCyQ9E=2MrUy+ps1JSdp1pWCWu=f6QZH5C4hu8QQu5jA0U5Q@mail.gmail.com>
References: <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <5616BB8A.1080807@orlitzky.com>
 <CAJUDvciWQuABPg+OzNEwnKkq95V0X683k5x=bH66GHEYkYx32Q@mail.gmail.com>
 <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local>
 <CAJUDvcjr4n3ftUOdzaLPS1puRPYODpPq0f5DMMGuOisMtpRh+A@mail.gmail.com>
 <CANBN=mvy6iMOTFzYX989CtDuvoJ4r5VKRVEjDr5B+yu6AhQ4jA@mail.gmail.com>
 <5617B9AD.90703@ciktel.net>
 <BCB21A7B440D4ACB4639A75AAC892A@mail.local>
 <5617E178.9000506@stilo.com> <5619C4F5.3060800@ucdavis.edu>
 <CAErCyQ-VkB6-tkDWEYwVKcyga9czxAjqiKvjCY+_p4zaVKcZeA@mail.gmail.com>
 <561D64AE.8030308@ucdavis.edu>
 <CAErCyQ9E=2MrUy+ps1JSdp1pWCWu=f6QZH5C4hu8QQu5jA0U5Q@mail.gmail.com>
Message-ID: <CANBN=mu6NPnghgRKSa8brdJy2QGamd1aDKj_XP8coii6RhMAjw@mail.gmail.com>

2015-10-14 10:14 GMT+02:00 David Turner <dct25-561bs at mythic-beasts.com>:

> [...] It's very hard for either A or B to reason about the correctness of
> that last step because it's such a big change. On the other hand, rebasing
> B's changes on top of A's looks like this:
>
> A1 -> A2 -> .... -> An -> B1' -> B2' -> .... -> Bm'
>
> Then B can go through their rebased changes and use pretty much the same
> reasoning as they were using before to check that they're still correct.
>

And what's even better: If you have a sane set of tests, you can easily
find the exact commit where things went wrong in an automated way via 'git
bisect'. This is the reason why some companies with large code bases
totally ban merge commits and rely on rebasing exclusively. You can even go
a step further by e.g. trying to revert the guilty commit and see if things
work again without it, again in a totally automated way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151014/3b8de1ac/attachment.html>

From hesselink at gmail.com  Wed Oct 14 11:44:38 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Wed, 14 Oct 2015 13:44:38 +0200
Subject: [Haskell-cafe] A suggestion: On why code merges should
 influence Haskell design
In-Reply-To: <CANBN=mu6NPnghgRKSa8brdJy2QGamd1aDKj_XP8coii6RhMAjw@mail.gmail.com>
References: <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <5616BB8A.1080807@orlitzky.com>
 <CAJUDvciWQuABPg+OzNEwnKkq95V0X683k5x=bH66GHEYkYx32Q@mail.gmail.com>
 <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local>
 <CAJUDvcjr4n3ftUOdzaLPS1puRPYODpPq0f5DMMGuOisMtpRh+A@mail.gmail.com>
 <CANBN=mvy6iMOTFzYX989CtDuvoJ4r5VKRVEjDr5B+yu6AhQ4jA@mail.gmail.com>
 <5617B9AD.90703@ciktel.net> <BCB21A7B440D4ACB4639A75AAC892A@mail.local>
 <5617E178.9000506@stilo.com> <5619C4F5.3060800@ucdavis.edu>
 <CAErCyQ-VkB6-tkDWEYwVKcyga9czxAjqiKvjCY+_p4zaVKcZeA@mail.gmail.com>
 <561D64AE.8030308@ucdavis.edu>
 <CAErCyQ9E=2MrUy+ps1JSdp1pWCWu=f6QZH5C4hu8QQu5jA0U5Q@mail.gmail.com>
 <CANBN=mu6NPnghgRKSa8brdJy2QGamd1aDKj_XP8coii6RhMAjw@mail.gmail.com>
Message-ID: <CAPeieQH_giqhfAe2cTxC12ob+bQTWVngv5dLNKjz=g5KJVE7uQ@mail.gmail.com>

On 14 October 2015 at 11:51, Sven Panne <svenpanne at gmail.com> wrote:
>
> 2015-10-14 10:14 GMT+02:00 David Turner <dct25-561bs at mythic-beasts.com>:
>>
>> [...] It's very hard for either A or B to reason about the correctness of
>> that last step because it's such a big change. On the other hand, rebasing
>> B's changes on top of A's looks like this:
>>
>> A1 -> A2 -> .... -> An -> B1' -> B2' -> .... -> Bm'
>>
>> Then B can go through their rebased changes and use pretty much the same
>> reasoning as they were using before to check that they're still correct.
>
>
> And what's even better: If you have a sane set of tests, you can easily find
> the exact commit where things went wrong in an automated way via 'git
> bisect'. This is the reason why some companies with large code bases totally
> ban merge commits and rely on rebasing exclusively. You can even go a step
> further by e.g. trying to revert the guilty commit and see if things work
> again without it, again in a totally automated way.

I'm not sure why you're saying this is impossible with merges; I've
done it several times. Git will find the right branch where things
went wrong, and then finds the commit on that branch without problems.

Erik

From svenpanne at gmail.com  Wed Oct 14 13:03:09 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Wed, 14 Oct 2015 15:03:09 +0200
Subject: [Haskell-cafe] A suggestion: On why code merges should
 influence Haskell design
In-Reply-To: <CAPeieQH_giqhfAe2cTxC12ob+bQTWVngv5dLNKjz=g5KJVE7uQ@mail.gmail.com>
References: <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <5616BB8A.1080807@orlitzky.com>
 <CAJUDvciWQuABPg+OzNEwnKkq95V0X683k5x=bH66GHEYkYx32Q@mail.gmail.com>
 <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local>
 <CAJUDvcjr4n3ftUOdzaLPS1puRPYODpPq0f5DMMGuOisMtpRh+A@mail.gmail.com>
 <CANBN=mvy6iMOTFzYX989CtDuvoJ4r5VKRVEjDr5B+yu6AhQ4jA@mail.gmail.com>
 <5617B9AD.90703@ciktel.net>
 <BCB21A7B440D4ACB4639A75AAC892A@mail.local>
 <5617E178.9000506@stilo.com> <5619C4F5.3060800@ucdavis.edu>
 <CAErCyQ-VkB6-tkDWEYwVKcyga9czxAjqiKvjCY+_p4zaVKcZeA@mail.gmail.com>
 <561D64AE.8030308@ucdavis.edu>
 <CAErCyQ9E=2MrUy+ps1JSdp1pWCWu=f6QZH5C4hu8QQu5jA0U5Q@mail.gmail.com>
 <CANBN=mu6NPnghgRKSa8brdJy2QGamd1aDKj_XP8coii6RhMAjw@mail.gmail.com>
 <CAPeieQH_giqhfAe2cTxC12ob+bQTWVngv5dLNKjz=g5KJVE7uQ@mail.gmail.com>
Message-ID: <CANBN=msX0Asn=mTCojP2DzVjPr-MVwHf2EGXVpgbiDNWMhtDyw@mail.gmail.com>

2015-10-14 13:44 GMT+02:00 Erik Hesselink <hesselink at gmail.com>:

> I'm not sure why you're saying this is impossible with merges; I've
> done it several times. Git will find the right branch where things
> went wrong, and then finds the commit on that branch without problems.


Well, it might be the case that 'git bisect' alone works, but if you've got
lots of tooling sitting on top of your version control (e.g. bots measuring
and visualing performance, detecting regressions, etc.), you have a much
easier time with a linear history than a DAG-shaped one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151014/453158f3/attachment.html>

From hesselink at gmail.com  Wed Oct 14 13:15:17 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Wed, 14 Oct 2015 15:15:17 +0200
Subject: [Haskell-cafe] A suggestion: On why code merges should
 influence Haskell design
In-Reply-To: <CANBN=msX0Asn=mTCojP2DzVjPr-MVwHf2EGXVpgbiDNWMhtDyw@mail.gmail.com>
References: <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <5616BB8A.1080807@orlitzky.com>
 <CAJUDvciWQuABPg+OzNEwnKkq95V0X683k5x=bH66GHEYkYx32Q@mail.gmail.com>
 <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local>
 <CAJUDvcjr4n3ftUOdzaLPS1puRPYODpPq0f5DMMGuOisMtpRh+A@mail.gmail.com>
 <CANBN=mvy6iMOTFzYX989CtDuvoJ4r5VKRVEjDr5B+yu6AhQ4jA@mail.gmail.com>
 <5617B9AD.90703@ciktel.net> <BCB21A7B440D4ACB4639A75AAC892A@mail.local>
 <5617E178.9000506@stilo.com> <5619C4F5.3060800@ucdavis.edu>
 <CAErCyQ-VkB6-tkDWEYwVKcyga9czxAjqiKvjCY+_p4zaVKcZeA@mail.gmail.com>
 <561D64AE.8030308@ucdavis.edu>
 <CAErCyQ9E=2MrUy+ps1JSdp1pWCWu=f6QZH5C4hu8QQu5jA0U5Q@mail.gmail.com>
 <CANBN=mu6NPnghgRKSa8brdJy2QGamd1aDKj_XP8coii6RhMAjw@mail.gmail.com>
 <CAPeieQH_giqhfAe2cTxC12ob+bQTWVngv5dLNKjz=g5KJVE7uQ@mail.gmail.com>
 <CANBN=msX0Asn=mTCojP2DzVjPr-MVwHf2EGXVpgbiDNWMhtDyw@mail.gmail.com>
Message-ID: <CAPeieQGz6f+g=vQ81vmJ4KU4XvDKPHvXugriRuX=-PSLtPZTCA@mail.gmail.com>

On 14 October 2015 at 15:03, Sven Panne <svenpanne at gmail.com> wrote:
> 2015-10-14 13:44 GMT+02:00 Erik Hesselink <hesselink at gmail.com>:
>>
>> I'm not sure why you're saying this is impossible with merges; I've
>> done it several times. Git will find the right branch where things
>> went wrong, and then finds the commit on that branch without problems.
>
> Well, it might be the case that 'git bisect' alone works, but if you've got
> lots of tooling sitting on top of your version control (e.g. bots measuring
> and visualing performance, detecting regressions, etc.), you have a much
> easier time with a linear history than a DAG-shaped one.

This is getting a bit off topic, but anyway: I'm not even sure about
that. What if your tools finds a regression, and you want to revert
it. If it's part of a big rebased branch, this is tricky because the
whole feature might depend on it. If it's a merge, though, you can
just revert the merge.

Erik

From ianmbloom at gmail.com  Wed Oct 14 13:31:51 2015
From: ianmbloom at gmail.com (Ian Bloom)
Date: Wed, 14 Oct 2015 09:31:51 -0400
Subject: [Haskell-cafe] Trying to write an Embedded DSL that threads a monad?
Message-ID: <CAG67gco8L62n_q5-WAec7mbr-yYPgRaQ4PdBK+iEPV0_bnSH2A@mail.gmail.com>

I've been wrestling with this for a while and I decided eventually to look
for help. I've been hoping to design a domain specific embedded language in
Haskell that would let me pipe a commutative monad throughout an expression
written in the language. Special terms within the language will eventually
have access to this monad. I've created a simplified version here to
represent the main issues.

Here is what I'd like from the language:

 * To use haskell syntax for substitution and pattern matching rather than
implementing this myself.
 * To be able to express lambdas in my language.
 * To be able to embed any haskell terms including functions into the
language.
 * I'd like the Haskell type checker to tell me about bad terms.
 * I'd like to thread a monad through the entire expression.

So here is the first implementation that I tried of this (full source here:
http://lpaste.net/142959)

    data Exp m x where
       Val :: m x -> Exp m x
       Lam1 :: m (a -> Exp m b)        -> Exp m (a -> b)
       Lam2 :: m (a -> Exp m (b -> c)) -> Exp m (a -> b -> c)

a function liftE allows me to lift a haskell term into an expression:

    liftE x = Val $ return x

Application is a function <@> so:

    (<@>) :: forall m a b. Monad m => Exp m (a -> b) -> Exp m a -> Exp m b
    (<@>) (Val  f) (Val x) = Val  $ f `ap` x
    (<@>) (Lam2 f) (Val x) = Lam1 $ f >>= \f' -> x >>= \x' -> unLam1 $ f' x'
    (<@>) (Lam1 f) (Val x) = Val $ f >>= \f' -> x >>= \x' -> unVal $ f' x'

Seems like it might work! In fact it does typecheck.

So the first test expressions I'd like to try are these:

    mapE :: Monad m => Exp m ((a -> b) -> [a] -> [b])
    mapE = Lam2 $ return $ \ f -> Lam1 $ return $ \ xxs ->
      case xxs of
        [] -> liftE []
        (x:xs) -> liftE (:) <@> liftE (f x) <@> (mapE <@> liftE f <@> liftE
xs)

    testExpression :: Monad m => Exp m [Int]
    testExpression = mapE <@> liftE (+10) <@> liftE [1,2,3,4]

and just to justify doing any of this I'll create a Monad called
BindCounter that counts the number of times bind is called:

    newtype BindCounter a = BC (Int -> (Int, a))

    runBC (BC f) = f 0

    instance Functor (BindCounter) where
      fmap f (BC x) = BC $ \t -> let (t', x') = x t in (t', f x')

    instance Applicative (BindCounter) where
      pure x = BC (\t -> (t,x))
      f <*> x = f >>= \f' -> x >>= \x' -> return $ f' x'

    instance Monad (BindCounter) where
      return = pure
      BC f >>= g = BC $ \old ->
                        let (new, val) = f (old + 1)
                            BC f' = g val
                        in f' new

now I can try a test

    test =
      let (count, result) = runBC (unVal testExpression) in
        putStrLn $ "Count: " ++ show count ++ " Result: " ++ show result

The result in ghci is:
   Count: 36 Result: [11,12,13,14]

Ok so that's a lot. I was surprised I got this working. You can see from
the code that my main gripe with this is I haven't found a way to remove
the need to specify the number of embedded lambdas using Lam1 and Lam2 (we
could easily add more) and I haven't found a way to apply a Lam to another
Lam. I'm also curious if I am reinventing the wheel, I hadn't found a
library yet that let's me do something similar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151014/5fb7e079/attachment.html>

From svenpanne at gmail.com  Wed Oct 14 13:40:39 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Wed, 14 Oct 2015 15:40:39 +0200
Subject: [Haskell-cafe] A suggestion: On why code merges should
 influence Haskell design
In-Reply-To: <CAPeieQGz6f+g=vQ81vmJ4KU4XvDKPHvXugriRuX=-PSLtPZTCA@mail.gmail.com>
References: <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <5616BB8A.1080807@orlitzky.com>
 <CAJUDvciWQuABPg+OzNEwnKkq95V0X683k5x=bH66GHEYkYx32Q@mail.gmail.com>
 <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local>
 <CAJUDvcjr4n3ftUOdzaLPS1puRPYODpPq0f5DMMGuOisMtpRh+A@mail.gmail.com>
 <CANBN=mvy6iMOTFzYX989CtDuvoJ4r5VKRVEjDr5B+yu6AhQ4jA@mail.gmail.com>
 <5617B9AD.90703@ciktel.net>
 <BCB21A7B440D4ACB4639A75AAC892A@mail.local>
 <5617E178.9000506@stilo.com> <5619C4F5.3060800@ucdavis.edu>
 <CAErCyQ-VkB6-tkDWEYwVKcyga9czxAjqiKvjCY+_p4zaVKcZeA@mail.gmail.com>
 <561D64AE.8030308@ucdavis.edu>
 <CAErCyQ9E=2MrUy+ps1JSdp1pWCWu=f6QZH5C4hu8QQu5jA0U5Q@mail.gmail.com>
 <CANBN=mu6NPnghgRKSa8brdJy2QGamd1aDKj_XP8coii6RhMAjw@mail.gmail.com>
 <CAPeieQH_giqhfAe2cTxC12ob+bQTWVngv5dLNKjz=g5KJVE7uQ@mail.gmail.com>
 <CANBN=msX0Asn=mTCojP2DzVjPr-MVwHf2EGXVpgbiDNWMhtDyw@mail.gmail.com>
 <CAPeieQGz6f+g=vQ81vmJ4KU4XvDKPHvXugriRuX=-PSLtPZTCA@mail.gmail.com>
Message-ID: <CANBN=muoxh58bmJ0gTGLyuQCENnzw-3Lwor93eq6REziY9vpng@mail.gmail.com>

2015-10-14 15:15 GMT+02:00 Erik Hesselink <hesselink at gmail.com>:

> This is getting a bit off topic, but anyway: I'm not even sure about
> that. What if your tools finds a regression, and you want to revert
> it. If it's part of a big rebased branch, this is tricky because the
> whole feature might depend on it. If it's a merge, though, you can
> just revert the merge.
>

OK, now we're really off-topic, but anyway: But when you revert the merge
(which brought in lots of commits at once), you still have no idea which
individual commit caused the regression. Perhaps there isn't even a
regression on your branch at all, only after the merge. Been there, done
that... :-P When you have a multi-million line project with hundreds of
people working on it, your bots can't keep up with the constant stream of
commits (so they typically batch things, doing more detailed runs later
when there is time, if any), and you really have to rely on some kind of
continuos integration, things get really complicated. So I understand the
policy of taking one problem out of the way, namely non-linear history.
That's at least what I've experienced, but your mileage may vary, of course.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151014/b4ed97fd/attachment.html>

From ratzes at gmail.com  Wed Oct 14 13:44:40 2015
From: ratzes at gmail.com (Charles Durham)
Date: Wed, 14 Oct 2015 09:44:40 -0400
Subject: [Haskell-cafe] A suggestion: On why code merges should
 influence Haskell design
In-Reply-To: <561C07FD.5070304@ucdavis.edu>
References: <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org>
 <5616BB8A.1080807@orlitzky.com>
 <CAJUDvciWQuABPg+OzNEwnKkq95V0X683k5x=bH66GHEYkYx32Q@mail.gmail.com>
 <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local>
 <CAJUDvcjr4n3ftUOdzaLPS1puRPYODpPq0f5DMMGuOisMtpRh+A@mail.gmail.com>
 <CANBN=mvy6iMOTFzYX989CtDuvoJ4r5VKRVEjDr5B+yu6AhQ4jA@mail.gmail.com>
 <5617B9AD.90703@ciktel.net> <BCB21A7B440D4ACB4639A75AAC892A@mail.local>
 <5617E178.9000506@stilo.com> <5619C4F5.3060800@ucdavis.edu>
 <CACz_ru2dLq5MCQXrXnyoHL+eUNsr9jXg_5iD6NjgP7Y8U8EMLQ@mail.gmail.com>
 <CAEc4Ma3ctVR8cdATxr-cg+e_-noGM4yX+vwJs_FnaZv54EAMuQ@mail.gmail.com>
 <CAEXAPH7ygrf-35o1W8_9nDEjgkkS8RqzzHexeDpMZGBGSa4t6g@mail.gmail.com>
 <561C07FD.5070304@ucdavis.edu>
Message-ID: <CAEXAPH4u7Mc0z-gnQDfXZfpVE7K0KxZkw3MGk_pENhAd4-dyjw@mail.gmail.com>

Hmm, I think for Case 2, that there is a case where there is no bug in A or
B, but a bug in the merge. If the search strategy changes from s to s', and
the function definition changes from f to f', then I can come up with a
scenario where s and s' works for f and s works for both f and f', but s'
doesn't work for f'. I believe that Case 1 is pretty much the same.

On Mon, Oct 12, 2015 at 3:20 PM, Dimitri DeFigueiredo <
defigueiredo at ucdavis.edu> wrote:

> I think both these examples strengthen my argument! :-)
>
> There is no problem at all in the second and the first one precisely show
> us a situation when we would like to know there is a conflict.
>
> The guarantee I want is that when merging 2 branches A and B:
> *If there are no conflicts*, the merge tool guarantees the merge output
> introduces no new bugs *other than those already found in A or B*.
>
> Note:
> 1. we get to define what a conflict is and
> 2. we don't care if the bugs were already present in either branch.
>
> On the first example, I assume both branches A and B will compile and run
> before the merge so that we are really only changing the value of the
> variable on branch A and the definition of the function on branch B
> (otherwise the branches would not compile before the merge).
>
> Because the definition of the function depends on a *specific* value the
> variable, there is no way to avoid declaring a conflict. But notice that in
> the more general case where the function puts that value as a parameter
> there is no conflict, because if there were a bug it would already be
> present in branch B. So, the merge process is not introducing any bugs by
> itself.
>
> This is exactly what happens in the second example. I assume branch A
> provides the new definition of f(x) and that in branch B we change the
> search strategy in the search function g. However, I assume that g would
> take f as a parameter g:: (Integer -> Integer) -> Integer. In this case, if
> there were a bug in g in the merged output, then it would already be
> present in branch B before the merge. Therefore, there is no conflict at
> all here.
>
> In summary, there is no conflict on the second example and I would like to
> know about the conflict due to the global dependency on the first one.
>
>
> Dimitri
>
>
>
> On 10/11/15 6:58 PM, Charles Durham wrote:
>
> 1. If you have a merge take place in two lines right next to each other,
> say one variable is declared in one and a function processes that variable
> in another, if those two are responsible together for exiting a loop, then
> you're going to be solving the Halting Problem to show there are no bugs.
>
> 2. If you have one function "f(x) = a + bx + cx^2 +..." and another
> function that iterates through integers until a solution is found in
> integers, then if the internals of either is changed (either the constants
> in f, or the search strategy), then you're going to have to be solving
> "Hilberts 10th Problem" to understand that there are no bugs introduced,
> thought this was interesting as the changes are "further" apart.
>
> At least for the general case, this should be a problem for all Turing
> Complete languages. It might be interesting to think about finding sections
> of code that are "Total", and perhaps put certain guarantees on that, but
> there still might be weird ways that two lines of code can play with each
> other beyond that.
>
> I hope this isn't overly pedantic, or that I'm not completely off base.
>
> On Sun, Oct 11, 2015 at 8:10 PM, Jeffrey Brown <jeffbrown.the at gmail.com>
> wrote:
>
>> +1 for AST merge. Writing code from text is reasonable, but storing code
>> as text is lunacy.
>>
>> On Sat, Oct 10, 2015 at 11:17 PM, Sean Leather < <sean.leather at gmail.com>
>> sean.leather at gmail.com> wrote:
>>
>>> On Sun, Oct 11, 2015 at 4:09 AM, Dimitri DeFigueiredo wrote:
>>>
>>>> Can we write a "compiler-like" merge tool for Haskell?
>>>
>>>
>>> Merge could be considered to be a combination of diff and patch. And so
>>> you might want to merge ASTs, which are typically families of datatypes.
>>> Related: Type-Safe Diff for Families of Dataypes:
>>> <http://www.andres-loeh.de/gdiff-wgp.pdf>
>>> http://www.andres-loeh.de/gdiff-wgp.pdf
>>>
>>> Regards,
>>> Sean
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>>>
>>
>>
>> --
>> Jeffrey Benjamin Brown
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>
>
> _______________________________________________
> Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151014/fd9b2548/attachment.html>

From vagif.verdi at gmail.com  Wed Oct 14 19:57:53 2015
From: vagif.verdi at gmail.com (Vagif Verdi)
Date: Wed, 14 Oct 2015 12:57:53 -0700 (PDT)
Subject: [Haskell-cafe] Haskell developer job offer
Message-ID: <e7d6dead-df2d-424a-ba09-398fe603c2f5@googlegroups.com>

https://home2.eease.adp.com/recruit2/?id=19008792&t=1

Email me if interested.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151014/c702d516/attachment.html>

From winterkoninkje at gmail.com  Thu Oct 15 11:43:46 2015
From: winterkoninkje at gmail.com (wren romano)
Date: Thu, 15 Oct 2015 07:43:46 -0400
Subject: [Haskell-cafe] Trying to write an Embedded DSL that threads a
	monad?
In-Reply-To: <CAG67gco8L62n_q5-WAec7mbr-yYPgRaQ4PdBK+iEPV0_bnSH2A@mail.gmail.com>
References: <CAG67gco8L62n_q5-WAec7mbr-yYPgRaQ4PdBK+iEPV0_bnSH2A@mail.gmail.com>
Message-ID: <CABUjdS7LCCitmz=E5=PBZk7PBpg=PUuf1z6CykuD4FkBHCB0zQ@mail.gmail.com>

On Wed, Oct 14, 2015 at 9:31 AM, Ian Bloom <ianmbloom at gmail.com> wrote:
> Here is what I'd like from the language:
>
>  * To use haskell syntax for substitution and pattern matching rather than
> implementing this myself.
>  * To be able to express lambdas in my language.
>  * To be able to embed any haskell terms including functions into the
> language.
>  * I'd like the Haskell type checker to tell me about bad terms.
>  * I'd like to thread a monad through the entire expression.

It's still not clear exactly what you want/need with that last bullet
point. So I can try to offer help, but have no idea if this is on the
right track...


> So here is the first implementation that I tried of this (full source here:
> http://lpaste.net/142959)
>
>     data Exp m x where
>        Val :: m x -> Exp m x
>        Lam1 :: m (a -> Exp m b)        -> Exp m (a -> b)
>        Lam2 :: m (a -> Exp m (b -> c)) -> Exp m (a -> b -> c)
>
> a function liftE allows me to lift a haskell term into an expression:
>
>     liftE x = Val $ return x
>
> Application is a function <@> so:
>
>     (<@>) :: forall m a b. Monad m => Exp m (a -> b) -> Exp m a -> Exp m b
>     (<@>) (Val  f) (Val x) = Val  $ f `ap` x
>     (<@>) (Lam2 f) (Val x) = Lam1 $ f >>= \f' -> x >>= \x' -> unLam1 $ f' x'
>     (<@>) (Lam1 f) (Val x) = Val $ f >>= \f' -> x >>= \x' -> unVal $ f' x'
>
>[...]
>
> Ok so that's a lot. I was surprised I got this working. You can see from the
> code that my main gripe with this is I haven't found a way to remove the
> need to specify the number of embedded lambdas using Lam1 and Lam2 (we could
> easily add more) and I haven't found a way to apply a Lam to another Lam.
> I'm also curious if I am reinventing the wheel, I hadn't found a library yet
> that let's me do something similar.

So, two things to notice.

First, the type for Lam2 is just a refinement of the type for Lam1.
Thus, Lam2 gives you nothing new in terms of what can be made to
typecheck; the only thing it gives you is the ability to make runtime
decisions based on whether a particular expression was built with Lam1
or Lam2 (or Val).

Second, the apparent need for multiple lambdas stems from the fact
that your (<@>) function needs to "count down by one" each time an
argument is applied. This hides a big problem in the definition,
namely that you're assuming that after the right number of arguments
the resulting Exp will be built with Val; which isn't actually
guaranteed by the types.

After playing around with it for a while, it seems like the crux of
the issue comes from not being able to embed m(Exp m a) into Exp m a.
So, we can fix that by adding a new constructor:

    data Exp m x where
        Val :: m a -> Exp m a
        Exp :: m (Exp m a) -> Exp m a
        Lam :: m (a -> Exp m b) -> Exp m (a -> b)

    Exp f <@> x     = Exp ((<@> x) <$> f)
    f     <@> Exp x = Exp ((f <@>) <$> x)
    Val f <@> Val x = Val (f <*> x)
    Lam f <@> Val x = Exp (($) <$> f <*> x)
    -- TODO: Val/Lam and Lam/Lam cases...

    unVal :: Monad m => Exp m a -> m a
    unVal (Val v) = v
    unVal (Exp e) = e >>= unVal

This at least works for the given test case with mapE, testExpression,
and test? though it doesn't give exactly the same result about the
number of binds. But again I'm not sure what you're really after here.

(Note that, once we add the Exp constructor, we can redo Val to take a
pure argument without losing anything re typeability. Though again,
the exact semantics of dubious things like (>>=)-counting won't
necessarily be preserved. Still, as a general rule, it makes sense for
EDSLs to distinguish between pure values vs impure expressions...)

-- 
Live well,
~wren

From oleg at okmij.org  Thu Oct 15 12:55:42 2015
From: oleg at okmij.org (Oleg)
Date: Thu, 15 Oct 2015 21:55:42 +0900
Subject: [Haskell-cafe] Trying to write an Embedded DSL that threads a monad?
Message-ID: <20151015125542.GA2012@Magus.sf-private>



> Ian Bloom wrote:
> I've been hoping to design a domain specific embedded language in
> Haskell that would let me pipe a commutative monad throughout an expression
> written in the language. Special terms within the language will eventually
> have access to this monad.


Is there a reason tagless-final approach does not work for you? You
can easily thread any monad, even if you don't make any provision for
it initially. For example,

        http://okmij.org/ftp/tagless-final/index.html#call-by-any
        http://okmij.org/ftp/tagless-final/course/CBAny.hs

uses monad to print out traces of the expression and then later to
implement lazy evaluation for EDLS (which needs mutable cells).



From ianmbloom at gmail.com  Thu Oct 15 13:57:06 2015
From: ianmbloom at gmail.com (Ian Bloom)
Date: Thu, 15 Oct 2015 09:57:06 -0400
Subject: [Haskell-cafe] Trying to write an Embedded DSL that threads a
	monad?
In-Reply-To: <CABUjdS7LCCitmz=E5=PBZk7PBpg=PUuf1z6CykuD4FkBHCB0zQ@mail.gmail.com>
References: <CAG67gco8L62n_q5-WAec7mbr-yYPgRaQ4PdBK+iEPV0_bnSH2A@mail.gmail.com>
 <CABUjdS7LCCitmz=E5=PBZk7PBpg=PUuf1z6CykuD4FkBHCB0zQ@mail.gmail.com>
Message-ID: <CAG67gcpFu=-dZQcWmB8r+G=PD28DvxZJJkZ6xOinTtvCC3fNnA@mail.gmail.com>

Hi,
Thanks for your reply. I think the Monad that I chose for my example code
was not the best. I've been hoping to generalize across all possible monads
but the real use case arises because I have an expensive computation that I
know will repeat multiple times within the evaluation of a given large
expression so in my monad I want to implement a cache. If I query the cache
and it has not done the computation it will perform the computation once
and then return the result plus a new cache holding the result, if the
computation has already been performed it is present in the cache and taken
from there. In my definition of Exp there would then be one more value, say
Ext that when applied to a parameter can access and modify the cache. In
this case the order of evaluation doesn't affect the result of the Monad,
I'm not sure if "commutative" is the right way to describe this.

There is a lot to think about here but let me try playing around with your
code.

Thanks,
Ian

On Thu, Oct 15, 2015 at 7:43 AM, wren romano <winterkoninkje at gmail.com>
wrote:

> On Wed, Oct 14, 2015 at 9:31 AM, Ian Bloom <ianmbloom at gmail.com> wrote:
> > Here is what I'd like from the language:
> >
> >  * To use haskell syntax for substitution and pattern matching rather
> than
> > implementing this myself.
> >  * To be able to express lambdas in my language.
> >  * To be able to embed any haskell terms including functions into the
> > language.
> >  * I'd like the Haskell type checker to tell me about bad terms.
> >  * I'd like to thread a monad through the entire expression.
>
> It's still not clear exactly what you want/need with that last bullet
> point. So I can try to offer help, but have no idea if this is on the
> right track...
>
>
> > So here is the first implementation that I tried of this (full source
> here:
> > http://lpaste.net/142959)
> >
> >     data Exp m x where
> >        Val :: m x -> Exp m x
> >        Lam1 :: m (a -> Exp m b)        -> Exp m (a -> b)
> >        Lam2 :: m (a -> Exp m (b -> c)) -> Exp m (a -> b -> c)
> >
> > a function liftE allows me to lift a haskell term into an expression:
> >
> >     liftE x = Val $ return x
> >
> > Application is a function <@> so:
> >
> >     (<@>) :: forall m a b. Monad m => Exp m (a -> b) -> Exp m a -> Exp m
> b
> >     (<@>) (Val  f) (Val x) = Val  $ f `ap` x
> >     (<@>) (Lam2 f) (Val x) = Lam1 $ f >>= \f' -> x >>= \x' -> unLam1 $
> f' x'
> >     (<@>) (Lam1 f) (Val x) = Val $ f >>= \f' -> x >>= \x' -> unVal $ f'
> x'
> >
> >[...]
> >
> > Ok so that's a lot. I was surprised I got this working. You can see from
> the
> > code that my main gripe with this is I haven't found a way to remove the
> > need to specify the number of embedded lambdas using Lam1 and Lam2 (we
> could
> > easily add more) and I haven't found a way to apply a Lam to another Lam.
> > I'm also curious if I am reinventing the wheel, I hadn't found a library
> yet
> > that let's me do something similar.
>
> So, two things to notice.
>
> First, the type for Lam2 is just a refinement of the type for Lam1.
> Thus, Lam2 gives you nothing new in terms of what can be made to
> typecheck; the only thing it gives you is the ability to make runtime
> decisions based on whether a particular expression was built with Lam1
> or Lam2 (or Val).
>
> Second, the apparent need for multiple lambdas stems from the fact
> that your (<@>) function needs to "count down by one" each time an
> argument is applied. This hides a big problem in the definition,
> namely that you're assuming that after the right number of arguments
> the resulting Exp will be built with Val; which isn't actually
> guaranteed by the types.
>
> After playing around with it for a while, it seems like the crux of
> the issue comes from not being able to embed m(Exp m a) into Exp m a.
> So, we can fix that by adding a new constructor:
>
>     data Exp m x where
>         Val :: m a -> Exp m a
>         Exp :: m (Exp m a) -> Exp m a
>         Lam :: m (a -> Exp m b) -> Exp m (a -> b)
>
>     Exp f <@> x     = Exp ((<@> x) <$> f)
>     f     <@> Exp x = Exp ((f <@>) <$> x)
>     Val f <@> Val x = Val (f <*> x)
>     Lam f <@> Val x = Exp (($) <$> f <*> x)
>     -- TODO: Val/Lam and Lam/Lam cases...
>
>     unVal :: Monad m => Exp m a -> m a
>     unVal (Val v) = v
>     unVal (Exp e) = e >>= unVal
>
> This at least works for the given test case with mapE, testExpression,
> and test? though it doesn't give exactly the same result about the
> number of binds. But again I'm not sure what you're really after here.
>
> (Note that, once we add the Exp constructor, we can redo Val to take a
> pure argument without losing anything re typeability. Though again,
> the exact semantics of dubious things like (>>=)-counting won't
> necessarily be preserved. Still, as a general rule, it makes sense for
> EDSLs to distinguish between pure values vs impure expressions...)
>
> --
> Live well,
> ~wren
>



-- 
718.755.5483
http://ianbloom.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151015/9cc5adeb/attachment.html>

From ianmbloom at gmail.com  Thu Oct 15 14:01:24 2015
From: ianmbloom at gmail.com (Ian Bloom)
Date: Thu, 15 Oct 2015 10:01:24 -0400
Subject: [Haskell-cafe] Trying to write an Embedded DSL that threads a
	monad?
In-Reply-To: <20151015125542.GA2012@Magus.sf-private>
References: <20151015125542.GA2012@Magus.sf-private>
Message-ID: <CAG67gcq6zPzVJsvE6CXnbvn3oBtec1OU+nVdGhMA=yg1yx86Sw@mail.gmail.com>

Thanks for pointing that out, this is my first time encountering
tagless-final. The use of the :-> data constructor seems to solve a lot of
problems. I'm wondering how to introduce a haskell function as an embedded
value in such an EDSL but I think I will try it out.

Thanks,
Ian

On Thu, Oct 15, 2015 at 8:55 AM, Oleg <oleg at okmij.org> wrote:

>
>
> > Ian Bloom wrote:
> > I've been hoping to design a domain specific embedded language in
> > Haskell that would let me pipe a commutative monad throughout an
> expression
> > written in the language. Special terms within the language will
> eventually
> > have access to this monad.
>
>
> Is there a reason tagless-final approach does not work for you? You
> can easily thread any monad, even if you don't make any provision for
> it initially. For example,
>
>         http://okmij.org/ftp/tagless-final/index.html#call-by-any
>         http://okmij.org/ftp/tagless-final/course/CBAny.hs
>
> uses monad to print out traces of the expression and then later to
> implement lazy evaluation for EDLS (which needs mutable cells).
>
>
>


-- 
718.755.5483
http://ianbloom.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151015/60e4a20c/attachment.html>

From capn.freako at gmail.com  Thu Oct 15 14:33:45 2015
From: capn.freako at gmail.com (David Banas)
Date: Thu, 15 Oct 2015 07:33:45 -0700
Subject: [Haskell-cafe] Talk at tonight's Haskell Meetup at the Hacker Dojo.
Message-ID: <A989A14B-F7C5-48F9-8BFB-9EECECE3B5B9@gmail.com>

Hi all,

I plan to give a short talk, at tonight?s Haskell Meetup at the Hacker Dojo in Mountain View, CA, on using Conal?s Circat and Lambda-CCC machinery to implement the Fast Fourier Transform (FFT).

Hope to see you there,
-db


From amit at amitlevy.com  Thu Oct 15 17:16:48 2015
From: amit at amitlevy.com (Amit Aryeh Levy)
Date: Thu, 15 Oct 2015 13:16:48 -0400
Subject: [Haskell-cafe] Specializing argument to forM_,
	mapM_ & foldM_ in base-4.8
Message-ID: <561FDF80.8000507@amitlevy.com>

I've been running into a relatively small but frequent annoyance with
base >= 4.8 (GHC 7.10). `Control.Monad.foldM_`, `Control.Monad.mapM_`
and `Control.Monad.forM_` are generalized traverse over any `Foldable a`
rather than just arrays (`[a]`).

 This is great, except I'm finding that, for a lot of my code that works
well in previous versions, I need to specialize the argument to `[a]`
now. If other people are encoutering a similar patter, I wonder what are
your best practices for doing this: ScopedTypeVariables? Deconstruct the
reconstruct the array? ...

 The most common example is when I deserialize a JSON array with aeson
and want to traverse over that array (say, to store the objects to a DB):

 ```
let objArray = eitherDecode myjson
case objArray of
    Left err -> ...
    Right (objs :: [MyObjType]) ->
        forM_ objs $ \obj -> saveToDb obj
 ```

?The above fix requires `ScopedTypeVariables` (which is probably OK).
Another option is to deconstruct and reconstruct the list:

```
Right (o:objs) ->
    forM_ (o:objs) $ \obj -> saveToDb obj
```

Does this get optimized away?

Penny for your thoughts?

Cheers!
Amit

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151015/a4b96bd0/attachment.sig>

From manny at fpcomplete.com  Thu Oct 15 17:40:00 2015
From: manny at fpcomplete.com (Emanuel Borsboom)
Date: Thu, 15 Oct 2015 17:40:00 +0000
Subject: [Haskell-cafe] ANN: stack-0.1.6.0
Message-ID: <CACGj5vJecd23o_7UKrTaaFsO2rw1OK5NLAkPQrbgU4S_0dB-cQ@mail.gmail.com>

New version released of Stack, a build tool.

See README
<https://github.com/commercialhaskell/stack/tree/release#how-to-install>
for installation and upgrade instructions.

Major changes:

   - ?stack setup? now supports building and booting GHCJS from source
   tarball.
   - On Windows, build directories no longer display ?pretty? information
   (like x86_64-windows/Cabal-1.22.4.0), but rather a hash of that
   content. The reason is to avoid the 260 character path limitation on
   Windows. See
   #1027 <https://github.com/commercialhaskell/stack/pull/1027>
   - Rename config files and clarify their purposes #969
   <https://github.com/commercialhaskell/stack/issues/969>
      - ~/.stack/stack.yaml ? ~/.stack/config.yaml
      - ~/.stack/global ? ~/.stack/global-project
      - /etc/stack/config ? /etc/stack/config.yaml
      - Old locations still supported, with deprecation warnings
   - New command ?stack eval CODE?, which evaluates to ?stack exec ghc ? -e
   CODE?.

Other enhancements:

   - No longer install git on Windows
   #1046 <https://github.com/commercialhaskell/stack/issues/1046>. You
   can still get this behavior by running the following yourself:
   stack exec -- pacman -Sy --noconfirm git.
   - Typing enter during ?file-watch triggers a rebuild #1023
   <https://github.com/commercialhaskell/stack/pull/1023>
   - Use Haddock?s --hyperlinked-source (crosslinked source), if available
   #1070 <https://github.com/commercialhaskell/stack/pull/1070>
   - Use Stack-installed GHCs for stack init --solver #1072
   <https://github.com/commercialhaskell/stack/issues/1072>
   - New experimental stack query command #1087
   <https://github.com/commercialhaskell/stack/issues/1087>
   - By default, stack no longer rebuilds a package due to GHC options
   changes. This behavior can be tweaked with the rebuild-ghc-options
   setting. #1089 <https://github.com/commercialhaskell/stack/issues/1089>
   - By default, ghc-options are applied to all local packages, not just
   targets. This behavior can be tweaked with the apply-ghc-options
   setting. #1089 <https://github.com/commercialhaskell/stack/issues/1089>
   - Docker: download or override location of stack executable to re-run in
   container #974 <https://github.com/commercialhaskell/stack/issues/974>
   - Docker: when Docker Engine is remote, don?t run containerized
   processes as host?s UID/GID #194
   <https://github.com/commercialhaskell/stack/issues/194>
   - Docker: set-user option to enable/disable running containerized
   processes as host?s UID/GID #194
   <https://github.com/commercialhaskell/stack/issues/194>
   - Custom Setup.hs files are now precompiled instead of interpreted. This
   should be a major performance win for certain edge cases (biggest
example: building
   Cabal itself <https://github.com/commercialhaskell/stack/issues/1041>)
   while being either neutral or a minor slowdown for more common cases.
   - stack test --coverage now also generates a unified coverage report for
   multiple test-suites / packages. In the unified report, test-suites can
   contribute to the coverage of other packages.

Bug fixes:

   - Ignore stack-built executables named ghc
   #1052 <https://github.com/commercialhaskell/stack/issues/1052>
   - Fix quoting of output failed command line arguments
   - Mark executable-only packages as installed when copied from cache #1043
   <https://github.com/commercialhaskell/stack/pull/1043>
   - Canonicalize temporary directory paths #1047
   <https://github.com/commercialhaskell/stack/pull/1047>
   - Put code page fix inside the build function itself #1066
   <https://github.com/commercialhaskell/stack/issues/1066>
   - Add explicit-setup-deps option #1110
   <https://github.com/commercialhaskell/stack/issues/1110>, and change the
   default to the old behavior of using any package in the global and snapshot
   database #1025 <https://github.com/commercialhaskell/stack/issues/1025>
   - Precompiled cache checks full package IDs on Cabal < 1.22 #1103
   <https://github.com/commercialhaskell/stack/issues/1103>
   - Pass -package-id to ghci #867
   <https://github.com/commercialhaskell/stack/issues/867>
   - Ignore global packages when copying precompiled packages #1146
   <https://github.com/commercialhaskell/stack/issues/1146>

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151015/d0086272/attachment.html>

From adam at bergmark.nl  Thu Oct 15 18:27:55 2015
From: adam at bergmark.nl (Adam Bergmark)
Date: Thu, 15 Oct 2015 20:27:55 +0200
Subject: [Haskell-cafe] Specializing argument to forM_,
	mapM_ & foldM_ in base-4.8
In-Reply-To: <561FDF80.8000507@amitlevy.com>
References: <561FDF80.8000507@amitlevy.com>
Message-ID: <CACnqJZbhD9MJHegLgOYPnot25mt3nzQ8FWBeeog4-fNBgcAqLg@mail.gmail.com>

If you care about performance you may - I haven't benchmarked - want to use
Vector instead of lists here since that's what aeson uses internally. Then
it's pretty handy that you can still use forM_.

It's possible that the list pattern deconstruction and list construction
gets optimized away, my gut says you need -O2 for that to happen. Here's a
good explanation on how to dump and read core so you can check for yourself
what happens in this case:
http://stackoverflow.com/questions/6121146/reading-ghc-core . Either way
it's definitiely not less efficient to annotate the type instead. You don't
need ScopedTypeVariables here, you can write the type inside an expression
instead: `forM (objs :: Type) [...]`

HTH,
Adam


On Thu, Oct 15, 2015 at 7:16 PM, Amit Aryeh Levy <amit at amitlevy.com> wrote:

> I've been running into a relatively small but frequent annoyance with
> base >= 4.8 (GHC 7.10). `Control.Monad.foldM_`, `Control.Monad.mapM_`
> and `Control.Monad.forM_` are generalized traverse over any `Foldable a`
> rather than just arrays (`[a]`).
>
>  This is great, except I'm finding that, for a lot of my code that works
> well in previous versions, I need to specialize the argument to `[a]`
> now. If other people are encoutering a similar patter, I wonder what are
> your best practices for doing this: ScopedTypeVariables? Deconstruct the
> reconstruct the array? ...
>
>  The most common example is when I deserialize a JSON array with aeson
> and want to traverse over that array (say, to store the objects to a DB):
>
>  ```
> let objArray = eitherDecode myjson
> case objArray of
>     Left err -> ...
>     Right (objs :: [MyObjType]) ->
>         forM_ objs $ \obj -> saveToDb obj
>  ```
>
> ?The above fix requires `ScopedTypeVariables` (which is probably OK).
> Another option is to deconstruct and reconstruct the list:
>
> ```
> Right (o:objs) ->
>     forM_ (o:objs) $ \obj -> saveToDb obj
> ```
>
> Does this get optimized away?
>
> Penny for your thoughts?
>
> Cheers!
> Amit
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151015/205b5030/attachment.html>

From capn.freako at gmail.com  Thu Oct 15 18:29:28 2015
From: capn.freako at gmail.com (David Banas)
Date: Thu, 15 Oct 2015 11:29:28 -0700
Subject: [Haskell-cafe] Talk at tonight's Haskell Meetup at the Hacker
	Dojo.
In-Reply-To: <CAF-LYK+D=E-vDsOpwveUchXOw7iYwRZD=DdxfxQXQWSrdvmvAA@mail.gmail.com>
References: <A989A14B-F7C5-48F9-8BFB-9EECECE3B5B9@gmail.com>
 <CAF-LYK+D=E-vDsOpwveUchXOw7iYwRZD=DdxfxQXQWSrdvmvAA@mail.gmail.com>
Message-ID: <CADz=fO3N7c=0PBHAEEE6mLki7Xh9gaTBwgrYVOtHN8zBv_g87g@mail.gmail.com>

Yes, you may attend without being a member of the Hacker Dojo.
-db


On Thu, Oct 15, 2015 at 10:27 AM, Andrew Gibiansky <
andrew.gibiansky at gmail.com> wrote:

> Can I come if I'm not a member of Hacker Dojo? The website is unclear.
>
> -- Andrew
>
> On Thu, Oct 15, 2015 at 7:33 AM, David Banas <capn.freako at gmail.com>
> wrote:
>
>> Hi all,
>>
>> I plan to give a short talk, at tonight?s Haskell Meetup at the Hacker
>> Dojo in Mountain View, CA, on using Conal?s Circat and Lambda-CCC machinery
>> to implement the Fast Fourier Transform (FFT).
>>
>> Hope to see you there,
>> -db
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151015/aac1eead/attachment.html>

From kc1956 at gmail.com  Thu Oct 15 18:35:24 2015
From: kc1956 at gmail.com (KC)
Date: Thu, 15 Oct 2015 11:35:24 -0700
Subject: [Haskell-cafe] Talk at tonight's Haskell Meetup at the Hacker
	Dojo.
In-Reply-To: <A989A14B-F7C5-48F9-8BFB-9EECECE3B5B9@gmail.com>
References: <A989A14B-F7C5-48F9-8BFB-9EECECE3B5B9@gmail.com>
Message-ID: <CAMLKXy=wTM-ddsS0RCwFDuThCdd6ZTEoCg89Zo=WvBw2sGcxPg@mail.gmail.com>

Will slides be posted?

--
--

Sent from an expensive device which will be obsolete in a few months! :D

Casey

On Oct 15, 2015 7:33 AM, "David Banas" <capn.freako at gmail.com> wrote:

> Hi all,
>
> I plan to give a short talk, at tonight?s Haskell Meetup at the Hacker
> Dojo in Mountain View, CA, on using Conal?s Circat and Lambda-CCC machinery
> to implement the Fast Fourier Transform (FFT).
>
> Hope to see you there,
> -db
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151015/e2d44f97/attachment.html>

From capn.freako at gmail.com  Thu Oct 15 19:15:23 2015
From: capn.freako at gmail.com (David Banas)
Date: Thu, 15 Oct 2015 12:15:23 -0700
Subject: [Haskell-cafe] Talk at tonight's Haskell Meetup at the Hacker
	Dojo.
In-Reply-To: <CAMLKXy=wTM-ddsS0RCwFDuThCdd6ZTEoCg89Zo=WvBw2sGcxPg@mail.gmail.com>
References: <A989A14B-F7C5-48F9-8BFB-9EECECE3B5B9@gmail.com>
 <CAMLKXy=wTM-ddsS0RCwFDuThCdd6ZTEoCg89Zo=WvBw2sGcxPg@mail.gmail.com>
Message-ID: <CADz=fO0pR-b2E5CoeWdnYV+Ma07g5O4Ahg8yfYKi3is8TQ_W+Q@mail.gmail.com>

Yes, assuming Meetup has infrastructure in place for doing so.
I'll check w/ Tim on that.
-db


On Thu, Oct 15, 2015 at 11:35 AM, KC <kc1956 at gmail.com> wrote:

> Will slides be posted?
>
> --
> --
>
> Sent from an expensive device which will be obsolete in a few months! :D
>
> Casey
>
> On Oct 15, 2015 7:33 AM, "David Banas" <capn.freako at gmail.com> wrote:
>
>> Hi all,
>>
>> I plan to give a short talk, at tonight?s Haskell Meetup at the Hacker
>> Dojo in Mountain View, CA, on using Conal?s Circat and Lambda-CCC machinery
>> to implement the Fast Fourier Transform (FFT).
>>
>> Hope to see you there,
>> -db
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151015/24e15305/attachment.html>

From kc1956 at gmail.com  Thu Oct 15 19:18:06 2015
From: kc1956 at gmail.com (KC)
Date: Thu, 15 Oct 2015 12:18:06 -0700
Subject: [Haskell-cafe] Talk at tonight's Haskell Meetup at the Hacker
	Dojo.
In-Reply-To: <CADz=fO0pR-b2E5CoeWdnYV+Ma07g5O4Ahg8yfYKi3is8TQ_W+Q@mail.gmail.com>
References: <A989A14B-F7C5-48F9-8BFB-9EECECE3B5B9@gmail.com>
 <CAMLKXy=wTM-ddsS0RCwFDuThCdd6ZTEoCg89Zo=WvBw2sGcxPg@mail.gmail.com>
 <CADz=fO0pR-b2E5CoeWdnYV+Ma07g5O4Ahg8yfYKi3is8TQ_W+Q@mail.gmail.com>
Message-ID: <CAMLKXym-JTWhPiPgA1so3SPAiuquYvv=JXxbZqPh-Cybv7YC4g@mail.gmail.com>

We in Canada like to learn a thing or three ... :D

--
--

Sent from an expensive device which will be obsolete in a few months! :D

Casey

On Oct 15, 2015 12:15 PM, "David Banas" <capn.freako at gmail.com> wrote:

> Yes, assuming Meetup has infrastructure in place for doing so.
> I'll check w/ Tim on that.
> -db
>
>
> On Thu, Oct 15, 2015 at 11:35 AM, KC <kc1956 at gmail.com> wrote:
>
>> Will slides be posted?
>>
>> --
>> --
>>
>> Sent from an expensive device which will be obsolete in a few months! :D
>>
>> Casey
>>
>> On Oct 15, 2015 7:33 AM, "David Banas" <capn.freako at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I plan to give a short talk, at tonight?s Haskell Meetup at the Hacker
>>> Dojo in Mountain View, CA, on using Conal?s Circat and Lambda-CCC machinery
>>> to implement the Fast Fourier Transform (FFT).
>>>
>>> Hope to see you there,
>>> -db
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151015/644f03b5/attachment.html>

From wren at community.haskell.org  Thu Oct 15 19:48:26 2015
From: wren at community.haskell.org (wren romano)
Date: Thu, 15 Oct 2015 15:48:26 -0400
Subject: [Haskell-cafe] Trying to write an Embedded DSL that threads a
	monad?
In-Reply-To: <CAG67gcpFu=-dZQcWmB8r+G=PD28DvxZJJkZ6xOinTtvCC3fNnA@mail.gmail.com>
References: <CAG67gco8L62n_q5-WAec7mbr-yYPgRaQ4PdBK+iEPV0_bnSH2A@mail.gmail.com>
 <CABUjdS7LCCitmz=E5=PBZk7PBpg=PUuf1z6CykuD4FkBHCB0zQ@mail.gmail.com>
 <CAG67gcpFu=-dZQcWmB8r+G=PD28DvxZJJkZ6xOinTtvCC3fNnA@mail.gmail.com>
Message-ID: <CABUjdS5QQWvg-NG0G+EWOwEqPH5PU8wCxsOs5j7PzyJD2v56PQ@mail.gmail.com>

On Thu, Oct 15, 2015 at 9:57 AM, Ian Bloom <ianmbloom at gmail.com> wrote:
> Hi,
> Thanks for your reply. I think the Monad that I chose for my example code
> was not the best. I've been hoping to generalize across all possible monads
> but the real use case arises because I have an expensive computation that I
> know will repeat multiple times within the evaluation of a given large
> expression so in my monad I want to implement a cache. If I query the cache
> and it has not done the computation it will perform the computation once and
> then return the result plus a new cache holding the result, if the
> computation has already been performed it is present in the cache and taken
> from there. In my definition of Exp there would then be one more value, say
> Ext that when applied to a parameter can access and modify the cache. In
> this case the order of evaluation doesn't affect the result of the Monad,
> I'm not sure if "commutative" is the right way to describe this.

Yeah, if the order of computations doesn't matter, then the monad is
commutative.

If you want to distinguish "finished computations", then you should
make that distinction in the types; for example:

    data WHNF m a where
        Val :: a -> WHNF m a
        Lam :: (a -> Exp m b) -> WHNF m (a -> b)
        -- ...other value constructors of your DSL go here...

    data Exp m a where
        -- | Do some side effects and then return a value.
        Exp :: m (WHNF m a) -> Exp m a

N.B., this version collapses chains of (the old)Exp data constructor,
forcing them to all be bundled up together. That has its ups and
downs. On the upside, you know you'll get a WHNF out after running
stuff. On the downside, maybe sometimes you'll want to run the first
part of the monad stuff just once, and then pause things so you can
run more effects repeatedly (i.e., the ability to package up the type
m(m(WHNF m a)) so you can run the outer m once, and then the inner m
repeatedly). If you need that latter ability, then you should use this
instead:

    data Exp m a where
        Now :: m (WHNF m a) -> Exp m a
        Later :: m (Exp m a) -> Exp m a

-- 
Live well,
~wren

From amit at amitlevy.com  Thu Oct 15 20:17:24 2015
From: amit at amitlevy.com (Amit Aryeh Levy)
Date: Thu, 15 Oct 2015 16:17:24 -0400
Subject: [Haskell-cafe] Specializing argument to forM_,
 mapM_ & foldM_ in base-4.8
In-Reply-To: <CACnqJZbhD9MJHegLgOYPnot25mt3nzQ8FWBeeog4-fNBgcAqLg@mail.gmail.com>
References: <561FDF80.8000507@amitlevy.com>
 <CACnqJZbhD9MJHegLgOYPnot25mt3nzQ8FWBeeog4-fNBgcAqLg@mail.gmail.com>
Message-ID: <562009D4.4020807@amitlevy.com>

Thanks Adam!

Vector does make more sense (i'll continue to use lists in this thread
just for simplicity, since I don't think it matters for the higher level
problem).

`forM_ (objs :: Type) ....` seems like exactly the right solution in the
simple case. However, it doesn't seem to work if I try to write a more
general function. For example:

```
class ToRow r

saveToDb :: FromJSON r, ToRow r => ByteString -> (tr -> IO ()) -> IO ()
saveToDb json processRow =
    case eitherDecode json of
        Left err => r