headers
Simon Marlow | 1 Apr 2010 10:33
Picon

Re: Terminfo package fails to load .so file on Fedora 13 prerelease

On 29/03/2010 20:49, Robin Green wrote:
> I encountered a problem compiling yi on Fedora Linux 13 (prerelease):
> when the terminfo package was loaded by ghci, it attempted to load the
> native library /usr/lib/libncursesw.so. However, that file has
> recently been changed from a symbolic link to a library, into a plain
> text file, as explained here in the response to my Fedora bug report:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=578509
>
> The response suggests that ghci should instead try to load the
> versioned link libncursesw.so.5 (which happens to be in /lib in
> Fedora, incidentally).
>
> Is this something that could be changed by the terminfo package, or
> would there have to be a change made to ghci?

We applied a workaround for this that will be in 6.14.1:

http://hackage.haskell.org/trac/ghc/ticket/2615

In the meantime you'll need to avoid referring to linker scripts in the 
terminfo package, and instead resolve them to actual shared libraries.

Cheers,
	Simon
Permalink | Reply | 0 comments |
headers
Antoine Latter | 2 Apr 2010 05:23
Picon
Gravatar

Re: Bug in Parsec.Token

On Mon, Mar 15, 2010 at 11:27 PM, Don Stewart <dons <at> galois.com> wrote:
> Parsec98 is kind of a cool name, actually.
>
> -- Don
>

Back to this -

Currently, there's a problem with two versions of parsec being in use
at the same time, and there is a real desire and need for the
low-complexity parsec-2.1.

If we fork and put parsec-2.1 into a parsec98 package, we could then
submit that for inclusion into the platform, and continue offering
parsec-3 for folks that want the complexity/features.

So yes? No? Would anyone prefer that we fork parsec-3 off instead?

-Antoine
Permalink | Reply | 7 comments |
headers
Greg Fitzgerald | 2 Apr 2010 05:39
Picon
Gravatar

Re: Bug in Parsec.Token

It sounds to me like forking Parsec 3 would cause quite a bit of pain
for other packages on Hackage, but forking Parsec 2.1 to Parsec98
would be relatively painless.  I started the process of moving the
parsec 2.1 source to community.haskell.org but the server wouldn't
recognize the public key of Windows box, and haven't had time to look
into it.  If someone else wants to maintain the fork, go for it.
Otherwise, I can maintain a branch on github.

-Greg

On Thu, Apr 1, 2010 at 8:23 PM, Antoine Latter <aslatter <at> gmail.com> wrote:
> On Mon, Mar 15, 2010 at 11:27 PM, Don Stewart <dons <at> galois.com> wrote:
>> Parsec98 is kind of a cool name, actually.
>>
>> -- Don
>>
>
> Back to this -
>
> Currently, there's a problem with two versions of parsec being in use
> at the same time, and there is a real desire and need for the
> low-complexity parsec-2.1.
>
> If we fork and put parsec-2.1 into a parsec98 package, we could then
> submit that for inclusion into the platform, and continue offering
> parsec-3 for folks that want the complexity/features.
>
> So yes? No? Would anyone prefer that we fork parsec-3 off instead?
>
> -Antoine
(Continue reading)

Permalink | Reply | 6 comments |
headers
Isaac Dupree | 2 Apr 2010 06:10

Re: Bug in Parsec.Token

On 04/01/10 23:39, Greg Fitzgerald wrote:
> It sounds to me like forking Parsec 3 would cause quite a bit of pain
> for other packages on Hackage, but forking Parsec 2.1 to Parsec98
> would be relatively painless.

I like the idea of parsec98... But wouldn't then, the .cabal file of 
*every* package that wished to depend on the Platform and its parsec, 
(a.k.a. parsec98), have to be changed?

-Isaac
Permalink | Reply | 5 comments |
headers
Antoine Latter | 2 Apr 2010 06:34
Picon
Gravatar

Re: Bug in Parsec.Token

On Thu, Apr 1, 2010 at 10:10 PM, Isaac Dupree
<ml <at> isaac.cedarswampstudios.org> wrote:
> On 04/01/10 23:39, Greg Fitzgerald wrote:
>>
>> It sounds to me like forking Parsec 3 would cause quite a bit of pain
>> for other packages on Hackage, but forking Parsec 2.1 to Parsec98
>> would be relatively painless.
>
> I like the idea of parsec98... But wouldn't then, the .cabal file of *every*
> package that wished to depend on the Platform and its parsec, (a.k.a.
> parsec98), have to be changed?
>

We've already had situations where distros are in a tight spot because
they only want to ship one version of the parsec package, but they
want to ship packages that list a parsec < 3 dep and packages which
lists a parsec >= 3 dep.

But yes, to be strictly HP compliant a package would need to update
its package description.

I don't think that HP compliance is a goal that any package should aim
for - if a library or executable is popular it will get packaged in
the distros. The exception is libs that want to ship in the platform,
and those are small enough in number they can be handled on a case by
case basis.

Antoine
Permalink | Reply | 4 comments |
headers
Isaac Dupree | 2 Apr 2010 08:00

Re: Bug in Parsec.Token

On 04/02/10 00:34, Antoine Latter wrote:
> On Thu, Apr 1, 2010 at 10:10 PM, Isaac Dupree
> <ml <at> isaac.cedarswampstudios.org>  wrote:
>> On 04/01/10 23:39, Greg Fitzgerald wrote:
>>>
>>> It sounds to me like forking Parsec 3 would cause quite a bit of pain
>>> for other packages on Hackage, but forking Parsec 2.1 to Parsec98
>>> would be relatively painless.
>>
>> I like the idea of parsec98... But wouldn't then, the .cabal file of *every*
>> package that wished to depend on the Platform and its parsec, (a.k.a.
>> parsec98), have to be changed?
>>
>
> We've already had situations where distros are in a tight spot because
> they only want to ship one version of the parsec package, but they
> want to ship packages that list a parsec<  3 dep and packages which
> lists a parsec>= 3 dep.
>
> But yes, to be strictly HP compliant a package would need to update
> its package description.

Do more packages want to use Parsec 2 or Parsec 3?  I believe we were 
operating under the assumption that we would split one of the two into a 
separate package (either parsec3, or parsec98), with the PURPOSE being 
that packages' dependencies would be updated to point to the version of 
Parsec that they wish to use. The naive view would be, then, if more 
packages want Parsec 2 then it's less disruption to split off parsec 3 
and change those that depend on parsec 3, but if more use parsec 3, then 
vice versa. But the plan for a parsec3 package also involved creating
(Continue reading)

Permalink | Reply | 3 comments |
headers
Greg Fitzgerald | 2 Apr 2010 08:30
Picon
Gravatar

Re: Bug in Parsec.Token

> if more packages want
> Parsec 2 then it's less disruption to split off parsec 3

Luckily, there is very little disruption to split off parsec 2.1
because there's no harm in leaving old packages as "parsec < 3".  The
only packages that would need to change are those included in HP
packages to parsec98.  On the other hand, if we forked Parsec 3 and
called 2.1 version 4, then it would break any packages that depend on
"parsec" or "parsec >= 3".  Regardless of the number of packages on
hackage that depend on Parsec 2.1, I think it's more important to
avoid breaking code, and to be considerate of those off hackage that
just pull in the latest Parsec.  Parsec 3 does its best to be backward
compatible with Parsec 2, but Parsec 2 certainly doesn't do the same
for Parsec 3.  Therefore, I'd say forking 2.1 as parsec98 is the clear
win.

-Greg

On Thu, Apr 1, 2010 at 11:00 PM, Isaac Dupree
<ml <at> isaac.cedarswampstudios.org> wrote:
> On 04/02/10 00:34, Antoine Latter wrote:
>>
>> On Thu, Apr 1, 2010 at 10:10 PM, Isaac Dupree
>> <ml <at> isaac.cedarswampstudios.org>  wrote:
>>>
>>> On 04/01/10 23:39, Greg Fitzgerald wrote:
>>>>
>>>> It sounds to me like forking Parsec 3 would cause quite a bit of pain
>>>> for other packages on Hackage, but forking Parsec 2.1 to Parsec98
>>>> would be relatively painless.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Isaac Dupree | 2 Apr 2010 08:41

Re: Bug in Parsec.Token

On 04/02/10 02:30, Greg Fitzgerald wrote:
>> if more packages want
>> Parsec 2 then it's less disruption to split off parsec 3
>
> Luckily, there is very little disruption to split off parsec 2.1
> because there's no harm in leaving old packages as "parsec<  3".

I assert that there is harm.  There will be duplicate packages installed 
(parsec-2.1 and parsec98-2.1) with identical code.  Also, we would be 
committing to upload any bugfix/maintenance updates to both 'branches'.

Do you wish to argue that this is an acceptable level of harm? (I would 
be easily susceptible to such an argument...) Or perhaps that we should 
arrange the transition differently than I guessed above?

((*Oh! another thought: distro packagers would probably still be unhappy 
to see anyone depending on "parsec" version 2 a.k.a. < 3, because they 
don't want to ship the same package-name at two different versions.))

> On the other hand, if we forked Parsec 3 and
> called 2.1 version 4, then it would break any packages that depend on
> "parsec" or "parsec>= 3".

Those are dependencies which do not follow the Package Versioning 
Policy! Admittedly, it's impolite for an "upgrade" (3->4) to really be a 
downgrade, regardless.

-Isaac
Permalink | Reply | 1 comment |
headers
Ganesh Sittampalam | 2 Apr 2010 15:31
Picon
Gravatar

Re: Bug in Parsec.Token

On Mon, 15 Mar 2010, Don Stewart wrote:

> Parsec98 is kind of a cool name, actually.

The parsec98 name sounds cool, but if used, it'll last a long time I think 
it'll just be sowing more confusion for a future in which the origins of 
the name have faded into obscurity. And what if someone wants to keep it 
roughly as is, but bring it up to date with the latest Haskell standard? 
The name would be rather a barrier then.

If versions are going to be forked off, let's aim for a consistent naming 
scheme - parsec2, QuickCheck1, etc. Not sure how to deal with HaXml 1.13 
(the other strong candidate for this kind of treatment).

Ganesh
Permalink | Reply | 1 comment |
headers
sterl | 2 Apr 2010 17:36
Picon

Re: Bug in Parsec.Token

Ganesh Sittampalam wrote:
> The parsec98 name sounds cool, but if used, it'll last a long time I 
> think it'll just be sowing more confusion for a future in which the 
> origins of the name have faded into obscurity. And what if someone 
> wants to keep it roughly as is, but bring it up to date with the 
> latest Haskell standard? The name would be rather a barrier then.
>
> If versions are going to be forked off, let's aim for a consistent 
> naming scheme - parsec2, QuickCheck1, etc. Not sure how to deal with 
> HaXml 1.13 (the other strong candidate for this kind of treatment).

+1 to the idea of doing this as a general practice, and to all the 
particulars raised. Just like a package broken by the new exceptions can 
always switch to importing old-exception for the time being, it should 
be similarly easy for people to remain stable on parsec, quickcheck, 
haxml and such for some time to come -- not even necessarily to 
encourage this, but simply because it makes a uniform treatment of 
legacy code much more manageable.

--Sterl.
Permalink | Reply | 0 comments |

Gmane