Build Error with gtk-0.13.0.0

Question

Build Error with gtk-0.13.0.0

amas-git opened this issue 10 years ago · comments

Hi Mikolaj
I'm haskell newbee, I build threadscope by cabal and it failed.

Linux 3.15.8-1-ARCH #1 SMP PREEMPT Fri Aug 1 08:53:42 CEST 2014 i686 GNU/Linux
The Glorious Glasgow Haskell Compilation System, version 7.8.3
gtk-0.13.0.0

''''
GUI/ProgressView.hs:92:15:
Could not deduce (System.Glib.UTFString.GlibString string0)
arising from a use of ‘labelNew’
from the context (WindowClass win)
bound by the type signature for
new :: WindowClass win => win -> IO () -> IO ProgressView
at GUI/ProgressView.hs:79:8-57
The type variable ‘string0’ is ambiguous
Note: there are several potential instances:
instance System.Glib.UTFString.GlibString
text-1.1.1.3:Data.Text.Internal.Text
-- Defined in ‘System.Glib.UTFString’
instance System.Glib.UTFString.GlibString [Char]
-- Defined in ‘System.Glib.UTFString’
In a stmt of a 'do' block: progText <- labelNew Nothing
In the expression:
do { win <- windowNew;
set win [containerBorderWidth := 10, windowTitle := "", ....];
progText <- labelNew Nothing;
set progText [miscXalign := 0, labelUseMarkup := True];
.... }
In an equation for ‘new’:
new parent cancelAction
= do { win <- windowNew;
set win [containerBorderWidth := 10, ....];
progText <- labelNew Nothing;
.... }

''''

Mikolaj Konarski · Answer 1 · Tue Aug 12 2014 13:29:12 GMT+0800 (China Standard Time)

Thank you for the report. Somebody needs to fix TS, to make it compatible with gtk-0.13.0.0. For now, as a workaround, please set "gtk >= 0.12.1 && < 0.13" in threadscope.cabal.

amas · Answer 2 · Wed Aug 13 2014 01:21:15 GMT+0800 (China Standard Time)

thanks it works

GeorgeCo · Answer 3 · Thu Aug 14 2014 23:36:56 GMT+0800 (China Standard Time)

Thanks but where is the threadscope.cabal file I need to update? I am on a Mac running 10.9 with ghc 7.8.3 (latest Haskell platform).
Thanks

Elliot Cameron · Answer 4 · Sat Aug 23 2014 03:23:52 GMT+0800 (China Standard Time)

You need to clone (or download) the source for threadscope and modify threadscope.cabal in the root of the project. As of now, the change needs to be made on line 44.

Then run the following in the ThreadScope folder:

cabal sandbox init
cabal build
cabal install --user

MasterMastic · Answer 5 · Wed Sep 17 2014 02:27:30 GMT+0800 (China Standard Time)

When TS is updated, it would be wise to restrict the versions for everything that isn't restricted already according to PVP (just restrict the API-breaking part).

P.S. Is this likely to be fixed soon? is there anyone assigned yet?
I'm personally having troubles with the given workaround.

GeorgeCo · Answer 6 · Wed Sep 17 2014 02:29:58 GMT+0800 (China Standard Time)

Yes, it would be nice to see this fixed

On Tue, Sep 16, 2014 at 3:27 PM, MasterMastic notifications@github.com
wrote:

When TS is updated, it would be wise to restrict the versions for
everything that isn't restricted already according to PVP
http://www.haskell.org/haskellwiki/Package_versioning_policy (just
restrict the API-breaking part).

P.S. Is this likely to be fixed soon? is there anyone assigned yet?
I'm personally having troubles with the given workaround.

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

Mikolaj Konarski · Answer 7 · Wed Sep 17 2014 05:36:50 GMT+0800 (China Standard Time)

I've updated TS to gtk-0.13.0.0. Please test. If no problems emerge and if the maintainers don't veto, I will make a new release. Please, feel free to submit pull requests re package versioning and any others that you'd like to include in the release.

The second part of the fix is hacky, because the code needs to work with gtk < 0.13, too. The bug gtk2hs/gtk2hs#46 doesn't help either. If this gtk2hs bug bites you, manually install new versions of the required packages (e.g., text), or stick to gtk < 0.13.

I've defaulted to String, where possible. This is usually less efficient, but for now, compatibility with the other parts of the TS codebase was the more important concern.

MasterMastic · Answer 8 · Wed Sep 17 2014 19:20:22 GMT+0800 (China Standard Time)

It's building & working perfectly for me 👍.
Thank you very much, Mikolaj :) and kudos - I didn't expect for it to be fixed so fast.

Mikolaj Konarski · Answer 9 · Thu Sep 18 2014 01:46:59 GMT+0800 (China Standard Time)

@MasterMastic: thank you for the report. Could you specify which version of GHC you have and which version of gtk is used for the compilation (if you run cabal configure -v2, it should mention the version)?

MasterMastic · Answer 10 · Thu Sep 18 2014 13:20:04 GMT+0800 (China Standard Time)

Sure:
GHC 7.8.3 (x64).
GTK version 0.13.0.0.

And other information that may be relevant:
OS is Windows 7 x64 SP1.
Native GTK bundle version 2.22.1 (x64).
MinGW's GCC version 4.8.1 (not the one from the Haskell Platform).

Mikolaj Konarski · Answer 11 · Thu Sep 18 2014 14:01:17 GMT+0800 (China Standard Time)

Thank you! Anybody with GHC < 7.8?

Mikolaj Konarski · Answer 12 · Thu Oct 23 2014 06:26:37 GMT+0800 (China Standard Time)

It compiles for me successfully with GHC 7.6.3 and gtk-0.13 (no Haskell Platform). But I get segfaults with GHC 7.4.2 (gkt-0.12 was picked by cabal, that wasn't a clean package DB slate and I had some extra GHC patches, so I'm not sure what's going on). Could somebody perhaps verify? Dependencies of the gtk package were fixed upstream some time after we tested with gtk-0.13 above, so in theory TS with gtk-0.13 should work just fine now, regardless of the package DB state.

Edit: Testing with gtk-0.12 and any other GHC may do (7.4 is very old, after all).

Edit2: Clarified my very unclear earlier description.

GeorgeCo · Answer 13 · Sat Nov 01 2014 23:20:13 GMT+0800 (China Standard Time)

so maintainers vetoed a new release? The problem still exists with latest
version of gtk. Any chance of a new release soon?

Thanks
George

On Tue, Sep 16, 2014 at 6:36 PM, Mikolaj Konarski notifications@github.com
wrote:

I've updated TS to gtk-0.13.0.0. Please test. If no problems emerge and if
the maintainers don't veto, I will make a new release. Please, feel free to
submit pull requests re package versioning and any others that you'd like
to include in the release.

The second part of the fix is hacky, because the code needs to work with
gtk < 0.13, too. The bug gtk2hs/gtk2hs#46
gtk2hs/gtk2hs#46 doesn't help either. If this
gtk2hs bug bites you, manually install new versions of the required
packages (e.g., text), or stick to gtk < 0.13.

I've defaulted to String, where possible. This is usually less efficient,
but for now, compatibility with the other parts of the TS codebase was the
more important concern.

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

Mikolaj Konarski · Answer 14 · Sun Nov 02 2014 05:25:05 GMT+0800 (China Standard Time)

I'm sorry about my originally confusing report of testing with older GHCs. The gist is I'd be more comfortable if somebody tested the current master branch of TS with ghc-0.12.x before we release. Then I'm fine with a release, but note that I'm not a maintainer, Simon Marlow is.

@simonmar: please veto the release, if you think we should wait for fixes to some other issues or test some more.

Mikolaj Konarski · Answer 15 · Fri Nov 07 2014 23:26:10 GMT+0800 (China Standard Time)

OK, I've tested on my own, with GHC 7.6.3, no previous package DB and gtk-0.12.5.7 and it runs fine.

Package candidate released:

http://hackage.haskell.org/package/threadscope-0.2.5/candidate

Please test.

Mikolaj Konarski · Answer 16 · Thu Nov 13 2014 00:13:13 GMT+0800 (China Standard Time)

Version 0.2.5 published. Closing. Thank you for all your help.