aeson 0.10

[bergmark]

aeson-0.10.0.0 depended on by:

• aeson-schema-0.4.0.0 (>=0.8.0.0 && < 0.10). Mateusz Kowalczyk fuuzetsu@fuuzetsu.co.uk @Fuuzetsu. @Fuuzetsu
• aeson-utils-0.3.0.2 (>=0.6 && < 0.10). Silk code@silk.co. @bergmark @hesselink
• arbtt-0.9.0.5 (>=0.6 && < 0.10). Joachim Breitner mail@joachim-breitner.de.
• binary-orphans-0.1.1.0 (>=0.8 && < 0.10). Oleg Grenrus oleg.grenrus@iki.fi @phadej. @phadej
• binary-tagged-0.1.1.0 (>=0.8 && < 0.10). Oleg Grenrus oleg.grenrus@iki.fi @phadej. @phadej
• bloodhound-0.8.0.0 (>=0.7 && < 0.10). Chris Allen cma@bitemyapp.com. @bitemyapp
• country-codes-0.1.2 (>=0.5 && < 0.10). Felipe Lessa felipe.lessa@gmail.com @meteficha. @meteficha
• datadog-0.1.0.1 (>=0.8 && < 0.10). Ian Duncan ian@iankduncan.com @iand675. @iand675
• digestive-functors-aeson-1.1.16 (>=0.7 && < 0.10). Oliver Charles ollie@ocharles.org.uk. @ocharles
• engine-io-1.2.10 (>=0.7 && < 0.10). Oliver Charles ollie@ocharles.org.uk. @ocharles
• fay-0.23.1.8 (>0.6 && < 0.10). Adam Bergmark adam@bergmark.nl. @bergmark
• fb-1.0.11 (>=0.5 && < 0.10). Felipe Lessa felipe.lessa@gmail.com @meteficha. @meteficha
• flowdock-0.3.0.1 (>=0.8 && < 0.10). Ian Duncan ian@iankduncan.com @iand675. @brewtown
• generic-aeson-0.2.0.7 (>=0.6 && < 0.10). Silk code@silk.co. @bergmark @hesselink
• gipeda-0.1.2.1 (>=0.7 && < 0.10). Joachim Breitner mail@joachim-breitner.de. @nomeata
• hasql-postgres-0.10.5 (>=0.7 && < 0.10). Nikita Volkov nikita.y.volkov@mail.ru. @nikita-volkov
• heist-0.14.1.1 (>=0.6 && < 0.10). No maintainer. @mightybyte
• hoauth2-0.4.8 (>=0.7 && < 0.10). No maintainer. @freizl
• ide-backend-0.10.0 (>=0.6.2 && < 0.10). FP Complete michael@fpcomplete.com @snoyberg.
• ide-backend-common-0.10.0 (>=0.6.2 && < 0.10). No maintainer.
• ihaskell-0.8.0.0 (>=0.7 && < 0.10). Andrew Gibiansky andrew.gibiansky@gmail.com @gibiansky. @gibiansky
• ipython-kernel-0.8.1.0 (>=0.6 && < 0.10). Andrew Gibiansky andrew.gibiansky@gmail.com @gibiansky. @gibiansky
• json-autotype-1.0.7 (>=0.7 && < 0.10). Michal J. Gajda maintainer@migamake.com. @mgajda
• json-schema-0.7.4.0 (>=0.7 && < 0.10). Silk code@silk.co. @bergmark @hesselink
• mandrill-0.4.0.0 (>=0.7.0.3 && < 0.10.0.0). Alfredo Di Napoli alfredo.dinapoli@gmail.com. @adinapoli
• mangopay-1.11.4 (>=0.7 && < 0.10). Felipe Lessa felipe.lessa@gmail.com @meteficha. @meteficha
• pandoc-1.15.0.6 (>=0.7.0.5 && < 0.10). No maintainer. @jgm
• pandoc-citeproc-0.7.3.1 (>=0.7 && < 0.10). No maintainer. @jgm
• pandoc-types-1.12.4.5 (>=0.6.2 && < 0.10). No maintainer. @jgm
• persistent-template-2.1.3.4 (>=0.7 && < 0.10). Michael Snoyman michael@snoyman.com @snoyberg. @snoyberg
• pipes-aeson-0.4.1.4 (>=0.6.1 && < 0.10). Renzo Carbonara renzocarbonara@gmail.com @k0001. @k0001
• purescript-0.7.4.1 (>=0.8 && < 0.10). Oleg Grenrus oleg.grenrus@iki.fi @phadej. @purescript
• rest-core-0.36.0.6 (>=0.7 && < 0.10). Silk code@silk.co. @bergmark @hesselink
• rest-gen-0.17.1.3 (>=0.7 && < 0.10). Silk code@silk.co. @bergmark @hesselink
• rest-stringmap-0.2.0.6 (>=0.7 && < 0.10). Silk code@silk.co.
• rest-types-1.14.0.1 (>=0.7 && < 0.10). Silk code@silk.co. @bergmark @hesselink
• rethinkdb-2.1.0.2 (>=0.7 && < 0.10). Brandon Martin brandon@codedmart.com @codedmart. @AtnNn
• servant-server-0.4.4.2 (>=0.7 && < 0.10). Haskell Servant jkarni@gmail.com @jkarni. @haskell-servant
• smoothie-0.4.1 (>=0.8 && < 0.10). Dimitri Sabadie <dimitri.sabadie@gmail.com. @phaazon
• snap-0.14.0.6 (==0.6.* || >=0.7.0.4 && < 0.10). No maintainer. @mightybyte
• snaplet-fay-0.3.3.12 (>=0.6 && < 0.10). Adam Bergmark adam@bergmark.nl. @bergmark
• socket-io-1.3.3 (>=0.7 && < 0.10). Oliver Charles ollie@ocharles.org.uk. @ocharles
• stylish-haskell-0.5.14.1 (>=0.6 && < 0.10). Jasper Van der Jeugt. @jaspervdj
• tttool-1.4.0.4 (>=0.7 && < 0.10). Joachim Breitner mail@joachim-breitner.de. @entropia
• twitter-feed-0.2.0.3 (>=0.8 && < 0.10). Juan Pedro Villa Isaza jvilla@stackbuilders.com @jpvillaisaza. @stackbuilders
• wai-routes-0.8.1 (>=0.8 && < 0.10). Anupam Jain ajnsit@gmail.com. @ajnsit
• webdriver-0.6.2.1 (>=0.6.2.0 && < 0.10). FP Complete michael@fpcomplete.com @snoyberg. @kallisti-dev
• yesod-auth-oauth2-0.1.3 (>=0.6 && < 0.10). Paul Harper benekastah@gmail.com. @thoughtbot
• yesod-mangopay-1.11.4 (>=0.6 && < 0.10). Felipe Lessa felipe.lessa@gmail.com @meteficha. @meteficha

[phadej]

new revisions of binary-orphans and binary-tagged published

[phadej]

Also, be aware of really breaking change haskell/aeson#287

[jpvillaisaza]

twitter-feed is updated in Hackage now.

[adinapoli]

Mandrill 0.4.1.0 is updated & on Hackage now, fixed by: adinapoli/mandrill#22

[mgajda]

json-autotype is fixed too.

On Sunday, September 20, 2015, Alfredo Di Napoli notifications@github.com
wrote:

Mandrill 0.4.1.0 is updated & on Hackage now, fixed by:
adinapoli/mandrill#22 adinapoli/mandrill#22

—
Reply to this email directly or view it on GitHub
#845 (comment).

Pozdrawiam
Michał

[nomeata]

Is there actually any point in everyone reporting here that a fix is uploaded? I would presume that the stackage admins would see what’s fixed and what not based on their tool, and use that to check it. At least until there are only two or three packages left which everyone is waiting on, in which case a “I’m finally done message” might be useful.

[hadronized]

smoothie fixed.

[nikita-volkov]

"hasql-postgres" is fixed, but I would love to see the maintainers' input on @nomeata's comment.

[snoyberg]

Is there actually any point in everyone reporting here that a fix is uploaded? I would presume that the stackage admins would see what’s fixed and what not based on their tool, and use that to check it. At least until there are only two or three packages left which everyone is waiting on, in which case a “I’m finally done message” might be useful.

When it's just a few packages: telling us to try again is very helpful. With lots of packages: everyone needs to do the mental checklist of "did everyone else already fix this?" In which case: it's less useful. The curator team will regularly check on open issues and see if they're still relevant, so that seems like the right way to address these big issues.

How's this for a policy: if there are five or more package maintainers pinged in an issue, don't bother writing back.

@bergmark @DanBurton @juhp Any thoughts on that?

[mgajda]

Whatever helps You best Michael!
Thanks for making awesome contribution to the commuńity, and making sure
that our packages are all together compatibleand up to date.

On Monday, September 21, 2015, Michael Snoyman notifications@github.com
wrote:

Is there actually any point in everyone reporting here that a fix is
uploaded? I would presume that the stackage admins would see what’s fixed
and what not based on their tool, and use that to check it. At least until
there are only two or three packages left which everyone is waiting on, in
which case a “I’m finally done message” might be useful.

When it's just a few packages: telling us to try again is very helpful.
With lots of packages: everyone needs to do the mental checklist of "did
everyone else already fix this?" In which case: it's less useful. The
curator team will regularly check on open issues and see if they're still
relevant, so that seems like the right way to address these big issues.

How's this for a policy: if there are five or more package maintainers
pinged in an issue, don't bother writing back.

@bergmark https://github.com/bergmark @DanBurton
https://github.com/DanBurton @juhp https://github.com/juhp Any
thoughts on that?

—
Reply to this email directly or view it on GitHub
#845 (comment).

Pozdrawiam
Michał

[bergmark]

👍

[gregwebs]

Due to the breaking change that got released mentioned by @phadej, I would recommend that nobody use aeson 0.10 for now. There is already a pull request to attempt to fix this situation: haskell/aeson#288

[bitemyapp]

@gregwebs yeah I've been holding out to see how that clears up.

[erratic-pattern]

For webdriver, my solution was to simply add a new operator to Test.WebDriver.JSON and use it in place of .:?

(.:??) :: FromJSON a => Object -> Text -> Parser (Maybe a)
o .:?? k = fmap join (o .:? k)

I believe this should have the same result regardless of which aeson version you use.

[mgajda]

I used Adam's solution in json-autotype too, and it passed all unit tests
without issues.

On Monday, 28 September 2015, Adam Curtis notifications@github.com wrote:

For webdriver, my solution was to simply add a new operator to
Test.WebDriver.JSON and use it in place of .:?

(.:??) :: FromJSON a => Object -> Text -> Parser (Maybe a)
o .:?? k = fmap join (o .:? k)

Pozdrawiam
Michał

[phadej]

I was a bit impatient so I made Data.Aeson.Compat

[bitemyapp]

Fixed in http://hackage.haskell.org/package/bloodhound-0.9.0.0 but I had to bring the lower-bound up to 0.10.

Current LTS Aeson is 0.8.0.2, let me know if this'll be a problem.

[bergmark]

Update:

aeson-0.10.0.0 depended on by:

• aeson-schema-0.4.0.0 (>=0.8.0.0 && < 0.10). Mateusz Kowalczyk fuuzetsu@fuuzetsu.co.uk @Fuuzetsu. @Fuuzetsu
• datadog-0.1.0.1 (>=0.8 && < 0.10). Ian Duncan ian@iankduncan.com @iand675. @iand675
• eventstore-0.9.1.1 (>=0.8 && < 0.10). Yorick Laupa yo.eight@gmail.com @YoEight. @YoEight
• flowdock-0.3.0.1 (>=0.8 && < 0.10). Ian Duncan ian@iankduncan.com @iand675. @brewtown
• hoauth2-0.4.8 (>=0.7 && < 0.10). No maintainer. @freizl
• ide-backend-0.10.0 (>=0.6.2 && < 0.10). FP Complete michael@fpcomplete.com @snoyberg.
• ide-backend-common-0.10.1.1 (>=0.6.2 && < 0.10). No maintainer.
• pipes-aeson-0.4.1.4 (>=0.6.1 && < 0.10). Renzo Carbonara renzocarbonara@gmail.com @k0001. @k0001
• rethinkdb-2.2.0.0 (>=0.7 && < 0.10). Brandon Martin brandon@codedmart.com @codedmart. @AtnNn
• riak-0.9.0.0 (>=0.8 && < 0.10). Tim McGilchrist timmcgil@gmail.com @tmcgilchrist. @markhibberd
• snaplet-fay-0.3.3.12 (>=0.6 && < 0.10). Adam Bergmark adam@bergmark.nl. @bergmark
• stack-0.1.10.1 (>=0.8.0.2 && < 0.10). Emanuel Borsboom manny@fpcomplete.com @borsboom. @commercialhaskell
• swagger2-0.4.1 (< 0.10). Nickolay Kudasov nickolay.kudasov@gmail.com @fizruk. @GetShopTV
• yesod-auth-oauth2-0.1.5 (>=0.6 && < 0.10). Paul Harper benekastah@gmail.com. @thoughtbot

postgresql-binary-0.7.4.1 depended on by:

• hasql-postgres-0.10.6 (==0.5.*). Nikita Volkov nikita.y.volkov@mail.ru. @nikita-volkov

[YoEight]

Fixed eventstore https://hackage.haskell.org/package/eventstore-0.9.1.2

[fizruk]

@tmcgilchrist I am not sure what you're asking. You can check the Travis build for v1.0.
The only problem I had with aeson-0.10.0.0 was a couple of bugs fixed in HEAD but not released (e.g. haskell/aeson#293 and the misplaced MINIMAL pragma). To fix compatibility with aeson-0.10.0.0 I just replaced TH with Generic-based code.

[bergmark]

@tmcgilchrist Do you mean if there are other dependencies you might need to bump? If you can build against the latest nightly and cabal sandbox init && cabal install --dry-run | grep latest doesn't give any results you should be good. Possibly also pass --enable-tests --enable-benchmarks if you have those

[tolysz]

Whenever your code handle Maybe via Value type it will be broken in aeson saying that there is a patch for that. So Basically if you use .:? or anything Value -> Maybe a there will be issues as current version is not working correctly there. So if you have Maybe in your type there is no way to write correct fromJson.

[tmcgilchrist]

@bergmark Yes that's what I meant. Thanks.

New version of riak up on package 0.9.1.1. @juhp

[juhp]

@tmcgilchrist okay thanks - looks good now

[freizl]

houath is bump to 0.5.0 in order to work with aeson-0.10

[jgm]

In my opinion, it was premature to add aeson 0.10 to stackage. The problem noted in haskell/aeson#296 essentially makes it impossible to compile pandoc-types on a machine with 2 GB RAM or less. Once pandoc enters lts-4.0, many people are going to find that stack install pandoc simply dies with an unexplained "ExitFailure 127."

As long as aeson 0.10 is in stackage, I'm faced with the choice between putting an upper bound on aeson in pandoc-types, thus excluding the pandoc ecosystem from stackage, or having many users complain that they are unable to install pandoc. (Yes, I know there are workarounds; you can specify a constraint on aeson; but most people aren't going to know that, and there's no way to figure out that that's what is needed.)

See my comment on haskell reddit.

[DanBurton]

@jgm the problem is with the generics-based default implementation, right? As an implementation workaround, how about using Data.Aeson.TH instead?

[jgm]

@DanBurton I've studiously avoided using any TH in pandoc, due to problems I had in the past with TH + Windows (I can't recall the details now). Does Data.Aeson.TH generate the same JSON mapping as the generics implementation?

[phadej]

@jgm it does, IIRC there are actual tests for that in aeson

[jgm]

Even if there is a workaround, I think my point stands. The aim of stackage is to provide a consistent set of packages that make building Haskell projects unproblematic. If one of the packages makes projects (not just mine, but anything that derives generic instances for complex product or sum types) unbuildable on machines without lots of RAM, that strikes me as a reason not to include it until the relevant bugs are fixed.

[phadej]

@jgm but that sounds as a bug in GHC, not the package itself.

[brendanhay]

The aeson-0.10 release was a bit of a cluster fart (looking at haskell/aeson#293) and there hasn't been visible movement getting the fixes that are in HEAD released.

Being dependent upon aeson I would of (pre-stackage) just added an upper bound < 0.10, but since the broken package is in stackage nightly I'm forced to somehow play along, or my package versions get put in the naughty section of stackage's build_constraints.yaml. Seems there should be provision for omitting or rolling back the offender from stackage (nightly at least), rather than forcing downstream dependencies through acts of choreographed contortion.

[gregwebs]

Can anyone get in touch with @bos? I think the community can benefit from having additional official maintainers of aeson that are focused on shouldering the burden of stability, releases, and responsiveness.

[jgm]

@phadej Well, it seems to be an interaction between changes specific to aeson 0.10 and ghc 7.10.3. Earlier version of aeson do not have the same problem, even with ghc 7.10.3. So the hope is that something can be fixed in aeson, even independent of fixes to ghc. Someone just commented on the aeson issue that removing the INLINE pragmas might do it.

[DanBurton]

We stackage curators have been considering our options. We didn't properly take the regressions of aeson-0.10 into consideration when we selected it for LTS-4; we intend to take action over the next few days to remedy the situation.

[phadej]

I'd like to help with aeson situation, if only there is something I can help with.

[gregwebs]

heads up: aeson just merged a PR to revert some of the 0.10 nullability change:
haskell/aeson#288

[RyanGlScott]

Also, we're exploring a workaround to aeson-0.10's generic-deriving issues here.

[DanBurton]

@brendanhay (and @ all) as of tonight's nightly, aeson 0.9 is back, and you're no longer in the naughty section for failing to support aeson 0.10.0.0. lts-5 will be released (planned for 2016-01-24) with aeson 0.9.

See #1155 for details.

[brendanhay]

Thank you!

[RyanGlScott]

I've opened a pull request to aeson to address the compilation slowdowns related to GHC generics.

[DanBurton]

To whomever is still listening to this thread, aeson-0.11 is being prepared for release. If you can clone the repo and test it out with your package, it would be much appreciated.

[hadronized]

I will!

[phadej]

At least aeson's master suffers from QuickCheck instances https://travis-ci.org/phadej/aeson/jobs/104043153

[phadej]

also aeson-compat (with small adoptions) and aeson-extra tests pass with nightly-2016-01-22 amended with aeson's master