Am 09.12.2013 16:19, schrieb Johan Tibell:

On Mon, Dec 9, 2013 at 3:49 PM, Christian Maeder mailto:Christian.Maeder@dfki.de> wrote:

Couldn't match type `text-0.11.3.1:Data.Text.__Internal.Text' with `T.Text' Expected type: [T.Text] Actual type: [text-0.11.3.1:Data.Text.__Internal.Text]

You typically get these errors when you try to use two versions of a package at the same time. Are you building with cabal? If so it should have warned you about that.

no, I just call "ghc --make ..." When I add "-hide-package text-1.0.0.0" to the command line, then compilation goes through, but linking fails. Obviously, having two versions is bad. Maybe I should install the old text version explicitly first and reinstall all other packages. Or I wait until warp can work with text-1.0.0.0, too. C. /home/linux-bkb/ghc/ghc-7.6.3/lib/i386-linux-ghc-7.6.3/text-1.0.0.0/libHStext-1.0.0.0.a(cbits.o): In function `_hs_text_memcpy': cbits.c:(.text+0x0): multiple definition of `_hs_text_memcpy' /home/linux-bkb/ghc/ghc-7.6.3/lib/i386-linux-ghc-7.6.3/text-0.11.3.1/libHStext-0.11.3.1.a(cbits.o):cbits.c:(.text+0x0): first defined here /home/linux-bkb/ghc/ghc-7.6.3/lib/i386-linux-ghc-7.6.3/text-1.0.0.0/libHStext-1.0.0.0.a(cbits.o): In function `_hs_text_memcmp': cbits.c:(.text+0x30): multiple definition of `_hs_text_memcmp' /home/linux-bkb/ghc/ghc-7.6.3/lib/i386-linux-ghc-7.6.3/text-0.11.3.1/libHStext-0.11.3.1.a(cbits.o):cbits.c:(.text+0x30): first defined here /home/linux-bkb/ghc/ghc-7.6.3/lib/i386-linux-ghc-7.6.3/text-1.0.0.0/libHStext-1.0.0.0.a(cbits.o): In function `_hs_text_decode_latin1': cbits.c:(.text+0x60): multiple definition of `_hs_text_decode_latin1' /home/linux-bkb/ghc/ghc-7.6.3/lib/i386-linux-ghc-7.6.3/text-0.11.3.1/libHStext-0.11.3.1.a(cbits.o):cbits.c:(.text+0x60): first defined here /home/linux-bkb/ghc/ghc-7.6.3/lib/i386-linux-ghc-7.6.3/text-1.0.0.0/libHStext-1.0.0.0.a(cbits.o): In function `_hs_text_decode_utf8': cbits.c:(.text+0x2b0): multiple definition of `_hs_text_decode_utf8' /home/linux-bkb/ghc/ghc-7.6.3/lib/i386-linux-ghc-7.6.3/text-0.11.3.1/libHStext-0.11.3.1.a(cbits.o):cbits.c:(.text+0x110): first defined here collect2: error: ld returned 1 exit status

On Mon, Dec 9, 2013 at 9:28 PM, Bryan O'Sullivan wrote:

There will be a 1.1 release of text in a matter of weeks, which leaves the public API unchanged, but exposes all the hitherto hidden internal modules.

Why make this a major bump? If it only exposes new things, it should only have to be a minor bump, right? Also, I've already said this elsewhere before, but all package breakages I've had in the past year have been due to missing upper bounds, also on stable things like 'text' or 'base'. Removing an upper bound saves one developer work at the expense of many users. Friends don't let friends remove upper bounds. Erik

Erik Hesselink wrote

Why make this a major bump? If it only exposes new things, it should only have to be a minor bump, right?

I just had a build break because a module I was importing exposed a new function that clashed with an existing function from a different module. Should potential build-breakers be a minor bump? -- View this message in context: http://haskell.1045720.n5.nabble.com/text-warp-and-blaze-builder-tp5740884p5... Sent from the Haskell - Libraries mailing list archive at Nabble.com.

Sven Panne-2 wrote

I think the rational is: If you carefully and explictly import only the things you need, the new version won't break your build. Importing whole modules can of course break your build when new entities have been added to the imported module, but this could be avoided by being less lazy and more explicit. ;-) Changing e.g. a signature or removing stuff OTOH will break some builds in ways which can't be anticipated.

Fixing that took considerably less time than what I would have spent on making all my imports explicit. Laziness wins again :) -- View this message in context: http://haskell.1045720.n5.nabble.com/text-warp-and-blaze-builder-tp5740884p5... Sent from the Haskell - Libraries mailing list archive at Nabble.com.

On Tue, 10 Dec 2013, Erik Hesselink wrote:

On Tue, Dec 10, 2013 at 3:36 PM, harry wrote:

...

Sven Panne-2 wrote

...

I think the rational is: If you carefully and explictly import only the things you need, the new version won't break your build. Importing whole modules can of course break your build when new entities have been added to the imported module, but this could be avoided by being less lazy and more explicit. ;-) Changing e.g. a signature or removing stuff OTOH will break some builds in ways which can't be anticipated.

Fixing that took considerably less time than what I would have spent on making all my imports explicit. Laziness wins again :)

True :) Although I have noticed that when you use explicit or qualified imports, the code is much more easily readable for others, since it's always clear where an identifier comes from. That might be a reason to use this style for some code. I've often developed without explicit imports, and added them when 'done'. Then later, when altering the code, I can remove the explicitness again while developing, adding it back at the end. That flow could use some tool support, though.

The decision whether to use qualification or not, cannot be done when importing, it must be done when exporting. If you define writeChan, then it is certainly not intended to use it as Chan.writeChan. Vice versa, if module Chan exports "write" then it calls for name clashes if you import that implicitly and unqualified. For that reason I use qualified style whereever possible (i.e. except for infix operators) and define names such that they make sense together with the qualification. This way I need neither interim solutions nor tool support.

Just to keep the discussion on point, in this case bos is exposing additional modules, rather than exporting additional functions from existing modules, right? The danger is that a user of text is currently also using another package's, say, Data.Text.Util module. Users can also defend themselves against this kind of change, by using package-qualified imports, though I don't think I've ever seen anyone do so preemptively (only in cases where there is a real existing conflict, like between mtl and monads-tf). Regards, Reid On Tue, Dec 10, 2013 at 11:16 AM, Edward Kmett wrote:

The idea is that exposing a new function can be defended against by the user by using qualified imports. If you don't use qualified imports then minor version changes CAN break your code, even bough they rarely will.

If a something new is exposed in a module users were already importing like that it should be a minor bump so that users can defend themselves if they are sufficiently paranoid.

-Edward

...

On Dec 10, 2013, at 3:20 AM, harry wrote:

Erik Hesselink wrote

...

Why make this a major bump? If it only exposes new things, it should only have to be a minor bump, right?

I just had a build break because a module I was importing exposed a new function that clashed with an existing function from a different module. Should potential build-breakers be a minor bump?

-- View this message in context: http://haskell.1045720.n5.nabble.com/text-warp-and-blaze-builder-tp5740884p5... Sent from the Haskell - Libraries mailing list archive at Nabble.com. _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

---

Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

I have a big yard, but I don't think it'd be enough to house and feed a pony. I may have to content myself with a photo. :) A middle ground that has worked for me is that between my own packages I just use the first digit of the major version. If the bulk of the API is unlikely to break in the 1.x regime, putting a bound of text < 2 would permit large breaking changes to be signaled in the future, while still removing most of the headaches of day to day version bumps forced on you by the pvp. -Edward

On Dec 9, 2013, at 3:28 PM, "Bryan O'Sullivan" wrote:

...

On Mon, Dec 9, 2013 at 11:29 AM, Edward A Kmett wrote: At last check blaze-builder hadn't updated its text dependency though stuff built on top of it has. I opened an issue with the repo about it as this is currently blocking the updated release of trifecta.

There will be a 1.1 release of text in a matter of weeks, which leaves the public API unchanged, but exposes all the hitherto hidden internal modules.

Everyone who removes their upper bounds on the version of text gets a pony. Everyone who widens their upper bounds to allow 1.1 gets a photo of a pony. Everyone who widens, but only to 1.0, gets some postprocessed pony food.