[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Nikki and the Robots – where is it stuck?

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.


>> 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-]: (error) Memory
>>> leak: argcPtr
>> How do you generate that warning?
> cppcheck 1.55.


>> 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)


> While looking for a changelog to fix no-upstream-changelog, I noticed
> that src/CHANGELOG is out of date.


> 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:
@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.


(I'm not on the debian mailing lists, please CC me!)

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: