Re: GetOpt formatting improvements

On 2008 Jun 30, at 15:17, Henning Thielemann wrote:

>
> On Mon, 30 Jun 2008, Tony Finch wrote:
>
>> On Mon, 30 Jun 2008, Jon Fairbairn wrote:
>>>
>>> Making it read the terminal width is clearly the best option.
>>
>> It should be the maximum of the terminal width and 80 columns.
>
> Did you mean the _minimum_ ?

Maximum, I suspect.  As in "don't go nuts trying to fit it into  
someone's 16x22 pssh".

--

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery <at> kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery <at> ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH

Re: GetOpt formatting improvements

On Mon, 30 Jun 2008, Henning Thielemann wrote:
> On Mon, 30 Jun 2008, Tony Finch wrote:
> > On Mon, 30 Jun 2008, Jon Fairbairn wrote:
> > >
> > > Making it read the terminal width is clearly the best option.
> >
> > It should be the maximum of the terminal width and 80 columns.
>
> Did you mean the _minimum_ ?

Er yes. Oops! It might make sense to apply a minimum too.

Tony.
--

-- 
f.anthony.n.finch  <dot <at> dotat.at>  http://dotat.at/
FORTIES CROMARTY FORTH TYNE DOGGER: SOUTHEAST 5 OR 6, OCCASIONALLY 7 FOR A
TIME, DECREASING 3 OR 4 LATER IN FORTH, TYNE AND DOGGER. MODERATE,
OCCASIONALLY ROUGH FOR A TIME. RAIN FOR A TIME. MODERATE OR GOOD, OCCASIONALLY
POOR LATER.

Re: Takusen build error

On Mon, Jun 30, 2008 at 02:25:22PM +0200, Benjamin Franksen wrote:
> I get a strange error building Takusen (more precisely: the module
> Foreign/C/UTF8.hs) with ghc-6.8.3. It says
> 
> /tmp/ghc18936_0/ghc18936_0.s: Assembler messages:
> 
> /tmp/ghc18936_0/ghc18936_0.s:1257:0:
>      Error: symbol `base_GHCziBase_Z0T_closure' is already defined

Thanks for the report; I've filed a bug here:
http://hackage.haskell.org/trac/ghc/ticket/2409

As a workaround, removing the (redundant) uses of
    () `seq`
in Foreign/C/UTF8.hs makes the build go through.

Thanks
Ian

Re: agreeing a policy for maintainers and hackageDB

On 2008.06.24 18:29:03 +0400, Bulat Ziganshin <bulat.ziganshin <at> gmail.com> scribbled 1.3K characters:
> Hello Isaac,
>
> Tuesday, June 24, 2008, 5:42:48 PM, you wrote:
>
> >> Do we want to permit unsupported forks? I am not convinced they are a good idea.
>
> imho, we are going too deep into this topic. there are even
> proposals to force developers to answer emails :)
>
> We have AUTHORS field which should list everyone contributed to the
> package just for copyrighting purposes. and we have MAINTAINER field
> for the person(s) which are ready to accept patches, feature requests
> and ask dumb user questions. that's all
>
> if one uploading package know person which maintains package in
> above-mentioned meaning, he declare that person in .cabal file. if
> noone is expected to support the package, it may be mentioned too
>
> non-maintainers shouldn't upload new versions of maintained packages
> without written ;) maintainer permission. well, as far as maintainer
> answers their letters

And how would we handle the case where the package is fully maintained, but the maintainer hates Cabal &
Hackage and would never give permission? Does the maintainer have eternal veto power over uploads?

> it should be ok to fork existing maintained library Foo as SuperFoo
> and leave it unmaintained - sometimes we write just for fun (things
> useful for other haskellers)
>

Re: agreeing a policy for maintainers and hackageDB

On 2008.06.24 10:30:39 +0300, Antti-Juhani Kaijanaho <antti-juhani <at> kaijanaho.fi> scribbled 1.4K characters:
> On Mon, Jun 23, 2008 at 10:51:43PM +0100, Duncan Coutts wrote:
> > If a few more people could read this nice short policy and say "yes that
> > looks fine, I agree" then that would be very helpful.
>
> Yes, that looks fine, I agree :)
>
> I would prefer that a missing Maintainer field were a bug in the
> metadata instead of being semantically significant.  Otherwise there
> would be no way of distinguishing between "I forgot to add my Maintainer
> line" and "I am not supporting this".
>
> --
> Antti-Juhani Kaijanaho, Jyväskylä, Finland

The alternative is worse: why is it better to have three values ('Specifically unmaintained',
'Maintained by foo', 'not specified either way/omitted field')? At least with the omitted field being
significant, users can proceed knowing that if there is a maintainer of a package with omitted maintainer
field, they haven't been too diligent about packaging the program.

And we already have a situation where omissions are significant. Consider the license: field. If a license
isn't specified, it must, legally, be AllRightsReserved. That's the law.

--
gwern
MI6 SISDE 36800 Waihopai ple SP4 illuminati FSF cracking rico

_______________________________________________
Libraries mailing list

Re: agreeing a policy for maintainers and hackageDB

On Tue, 1 Jul 2008, Gwern Branwen wrote:

> > non-maintainers shouldn't upload new versions of maintained packages
> > without written ;) maintainer permission. well, as far as maintainer
> > answers their letters
> 
> And how would we handle the case where the package is fully maintained, 
> but the maintainer hates Cabal & Hackage and would never give 
> permission? Does the maintainer have eternal veto power over uploads?
> 

To the extent it's legal to do so? Upload a package clearly marked as 
unofficial, with the maintainer field blank.

--

-- 
flippa <at> flippac.org

Sometimes you gotta fight fire with fire. Most
of the time you just get burnt worse though.

Re: agreeing a policy for maintainers and hackageDB

On 2008.06.23 20:18:41 -0700, Bryan O'Sullivan <bos <at> serpentine.com> scribbled 0.3K characters:
> On Mon, Jun 23, 2008 at 2:05 AM, Ross Paterson <ross <at> soi.city.ac.uk> wrote:
>
> > When something is agreed, I propose to put it on the hackageDB upload
> > page and expect people to follow it.
>
> Thanks for putting this together. I like it, and I think that any
> colour will do for the bike shed maintainer field.

I realize this looks like a trivial discussion, but small things can make big differences - this is one of the
primary convictions I've carried away from my Wikipedia experience.

The difference in edits between a wiki that forces you to make an account to edit and one that allows
anonymous edits can be considerable, even though an account takes like 10 seconds to make (if you've done
it before).

Similarly, if we force people to explicitly say whether or not something is maintained instead of having a
reasonable default when omitted - we are ratcheting up how much of a commitment a Hackage upload
represents. People only have so much commitment in them. Supply and demand...

--
gwern
MI6 SISDE 36800 Waihopai ple SP4 illuminati FSF cracking rico

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

Error accessing data files from package code in Cabal: Unkown symbol

Hi!

I'm working on a library package called ForSyDe.

Following Cabal's documentation, I'm using the autogenerated
Paths_ForSyDe module in order to access the data files of my library
during execution.

After installation,  the Paths_ForSyDe import seems to be causing an
unknown-symbol error whenever I try to compile any code which makes
use of the ForSyDe library:

" unknown symbol `___stginit_ForSyDezm0zi1_PathszuForSyDe_' "

I'm not sure, but it seems that cabal doesn't properly link or install
the Paths_ForSyDe module (I tried to include it in the cabal
description file to no avail)

Any suggestions about how to fix this problem?

Thanks in advance,

Fons

P.S: I'm using Cabal-1.2.3.0

Re: Error accessing data files from package code in Cabal: Unkown symbol

alfonso.acosta:
> Hi!
> 
> I'm working on a library package called ForSyDe.
> 
> Following Cabal's documentation, I'm using the autogenerated
> Paths_ForSyDe module in order to access the data files of my library
> during execution.
> 
> After installation,  the Paths_ForSyDe import seems to be causing an
> unknown-symbol error whenever I try to compile any code which makes
> use of the ForSyDe library:
> 
> " unknown symbol `___stginit_ForSyDezm0zi1_PathszuForSyDe_' "
> 
> I'm not sure, but it seems that cabal doesn't properly link or install
> the Paths_ForSyDe module (I tried to include it in the cabal
> description file to no avail)
> 
> Any suggestions about how to fix this problem?
> 
> Thanks in advance,

Probably you've not listed the Paths_ForSyDe module in your module
exports in the .cabal file?

Re: agreeing a policy for maintainers and hackageDB

Philippa Cowderoy wrote:
> On Tue, 1 Jul 2008, Gwern Branwen wrote:
> 
>>> non-maintainers shouldn't upload new versions of maintained packages
>>> without written ;) maintainer permission. well, as far as maintainer
>>> answers their letters
>> And how would we handle the case where the package is fully maintained, 
>> but the maintainer hates Cabal & Hackage and would never give 
>> permission? Does the maintainer have eternal veto power over uploads?
>>
> 
> To the extent it's legal to do so? Upload a package clearly marked as 
> unofficial, with the maintainer field blank.

If someone wants to put a version on hackage and act as maintainer for 
it (presumably mostly pulling updates from the "upstream"), should we 
let them?  Although, this situation sounds too hypothetical for me to 
have any idea how to answer my own question.