Hi Paul!
On 08/14/2012 05:43 AM, Paul Wise wrote:
>> We are not planning to create a tarball with "cabal sdist", we use
>> "darcs dist". Cabal expects the .cabal-file to be in the top level
>> directory, but we can't put it there, because we use multiple cabal
>> files (one for our binary deployment (in src/), one for the debian
>> deployment (in src/rootInstall/), one for the testsuite (in
>> src/testsuite), etc.). So this is a wontfix from our perspective.
>
> Hmm, is cabal not flexible enough to be able to do everything from one file?
Hmm, I think theoretically this could be possible. But I don't think
it's trivial and there is probably little else to be gained from that.
(Other than getting rid of these warnings.)
>
>> I tried using TChan instead and it makes the code less readable.
>> 'isEmptyChan' is deprecated because it isn't threadsafe, but we only use
>> it from one thread, so this also won't be fixed. (If you have no
>> objections, that is.)
>
> Seems reasonable, at some point isEmptyChan might get removed though
> so you may need to switch eventually.
Yes.
>> We could easily switch to
>> 'Foreign.ForeignPtr.Unsafe.unsafeForeignPtrToPtr', but that would break
>> compatibility with older ghc-versions (as young as 7.2, IIRC).
>
> I see, does Haskell not have a way to use one function if available
> and another otherwise?
Haskell (or ghc) supports the C-pre-processor, so this could be done
through conditional compilation. I dislike conditional compilation,
because it means you cannot statically check all of the code in one
compilation in one environment.
I don't see another way in Haskell to do that.
>
>> The force_align_arg_pointer attribute is a workaround for a Qt bug on
>> windows (the microsoft OS). So ignoring this on Linux isn't a problem.
>> We could get rid of this warning by conditional compilation. Is that wanted?
>
> Seems reasonable to only apply the attribute where it is definitely needed.
I put this on my todo-list.
>
>>> [/tmp/buildd/nikki-0.5.1.2/src/cpp/qtwrapper.cpp:48]: (error) Memory
>>> leak: argcPtr
>>
>> How do you generate that warning?
>
> cppcheck 1.55.
Fixed!
>
>> dpkg-shlipdeps seems to need a debian/control file. So I cannot
>> reproduce this.
>>
>> We do have an interest in fixing this warning (and the one above). Some
>> help in reproducing them on our end would be appreciated.
>
> I expect the dpkg-shlipdeps one is the fault of ghc or maybe one of
> your other dependencies, I wouldn't worry about it too much.
I've discovered two unneeded deps on our side and removed them. (I
doubt, they were the ones that introduced these link requirements, though.)
>
>> I don't need to understand these, right?
>
> The a few are relevant for you...
>
> I: nikki: spelling-error-in-binary usr/games/nikki unkown unknown
>
> Here is why:
>
> pabs@chianamo ~/devel/games/nikki $ grep -r unkown .
> ./src/LevelServer/Configuration.hs: x -> error ("unkown version: " ++ x)
>
Fixed!
> While looking for a changelog to fix no-upstream-changelog, I noticed
> that src/CHANGELOG is out of date.
Fixed!
>
> binary-without-manpage means that the game has no manual page, this
> isn't a big issue but is something you might want to add upstream.
I put that on my todo-list, with a low priority.
>
> I note that the bug where you can't move without re-setting the keys
> is still present.
Oh, I forgot about that. There is a bug report now here:
https://bugs.launchpad.net/nikki/+bug/1043771
@Paul: I failed to find the first report of this. If you can easily find
it, would you send me a link (or resend the mail), please?
>
>> I will be on a hiking trip, so I won't be able to answer in the coming
>> ten days.
>
> Have fun!
Thanks, I did.
Cheers,
Sönke
(I'm not on the debian mailing lists, please CC me!)
Attachment:
signature.asc
Description: OpenPGP digital signature