Re: Haskell Platform Proposal: add the 'text' library

On Tue, Sep 21, 2010 at 10:53 AM, Ian Lynagh <igloo <at> earth.li> wrote:

Still segfaults for me in 0.9, and I can't see the test for it.

Turns out there were two bugs, not just one. It's definitely fixed in 0.9.0.1  

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

RE: Proposal: Better power for Rational

Henning

| I'll try to create a patch, however I may need some assistance compiling base libraries.

Thank you.  Creating a patch, attaching to a ticket with some rationale, and submitting it to the libraries
list, is the best way to push your work over the hill and into the actual code base.   I'm sure others will help. 
If you get stuck, yell!

Daniel Fischer is working in this patch too.

Simon


|  -----Original Message-----
|  From: libraries-bounces <at> haskell.org [mailto:libraries-bounces <at> haskell.org] On Behalf
|  Of Henning Thielemann
|  Sent: 28 September 2010 19:23
|  To: libraries <at> haskell.org
|  Subject: Re: Proposal: Better power for Rational
|  
|  Simon Peyton-Jones schrieb:
|  > |  >  #4101: constant folding for (**)
|  > |  >  #3676: realToFrac conversions
|  > |  >  #3744: comparisons against minBound and maxBound are not optimised away
|  > |  >  #3065: quot is sub-optimal
|  > |  >  #2269: Word type to Double or Float conversions
|  > |  >  #2271: floor, ceiling, round :: Double -> Int are awesomely slow
|  > |  >  #1434: slow conversion Double to Int
|  > |
|  > |  For the rounding issue I have already written some code for numeric-prelude:
|  > |    http://code.haskell.org/numeric-prelude/src/Algebra/RealRing.hs

|  >
|  > Great. I'm not sure which ticket you are referring to, but if you could propose a
|  patch, by email to the libraries list, that would be great
|  
|  I'm referring to tickets #2271 and #1434.
|  I implemented round, truncate, floor, ceiling with Int result in terms
|  of double2Int and friends and added RULES for decomposing, e.g.
|    round :: Double -> Int16
|   into
|    (fromIntegral :: Int -> Int16) . (round :: Double -> Int)
|   However my code is adapted to NumericPrelude's type classes and must be
|  adapted to those of Haskell98's Prelude. This should not be too hard.
|  I'll try to create a patch, however I may need some assistance compiling
|  base libraries.
|  
|  
|  Henning
|  _______________________________________________
|  Libraries mailing list
|  Libraries <at> haskell.org
|  http://www.haskell.org/mailman/listinfo/libraries

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

Re: Proposal: Better power for Rational

On Monday 04 October 2010 11:57:06, Simon Peyton-Jones wrote:
> Henning
>
> | I'll try to create a patch, however I may need some assistance
> | compiling base libraries.
>
> Thank you.  Creating a patch, attaching to a ticket with some rationale,
> and submitting it to the libraries list, is the best way to push your
> work over the hill and into the actual code base.   I'm sure others will
> help.  If you get stuck, yell!
>
> Daniel Fischer is working in this patch too.
>
> Simon

Since I'm working on GHC.Float anyway, I'll include Henning's rounding etc. 
code too.

Speaking of GHC.Float, there are a few points where I would like some 
guidance on where to put things.

I could of course put everything in GHC.Float, but it's big already and I'd 
prefer not to clutter it up further.

For toRational, to avoid wasting time in gcd, I need an array for the 
number of trailing 0-bits in a byte. Also, since bit-fiddling of Integers 
is considerably slower than for fixed width types, I'd need to import 
GHC.IntWord64 since a Double mantissa won't fit in an Int on 32-bit 
systems. This could go into GHC.Float or into a GHC.Float.Utils module.

For fromRational, I need a fast integerLog2. For that, I need access to the 
internal representation of Integers when using integer-gmp and an 
alternative implementation for integer-simple (which would be much slower, 
but if you use integer-simple, performance probably isn't your foremost 
concern). I might need a few more odds and ends if special-casing for the 
results of toRational (whose denominator is a power of 2) proves to be a 
gain.

Putting all the auxiliary stuff in GHC.Float wrapped in #ifdefs is IMO an 
appalling idea.

integerLog2 and more generally integerLogBase are useful enough to be added 
to GHC.Integer (Int/Word is not yet available, so it'd be the '#' versions, 
where would the wrappers returning an Int or Word go?).
If I need the stuff for special casing, my preferred solution would be to 
put it in GHC.Integer.Variant.Internals or add a small dedicated module for 
them to the package.

So what's the best place to put stuff?

RE: Proposal: Better power for Rational

In general, it's an implementation matter where to put these functions, rather than a major design choice. 
If one module is getting big and clumsy, then maybe splitting it into two would help.

However, as you say we need to think about integer-simple too, so we should perhaps think about adding the
same new functions to the 'integer-gmp' and 'integer-simple' packages.  Then you would not need #ifdefs
in GHC.Float, would you?  

s

| -----Original Message-----
| From: daniel.is.fischer <at> web.de [mailto:daniel.is.fischer <at> web.de]
| Sent: 04 October 2010 15:01
| To: Simon Peyton-Jones; libraries <at> haskell.org
| Subject: Re: Proposal: Better power for Rational
| 
| On Monday 04 October 2010 11:57:06, Simon Peyton-Jones wrote:
| > Henning
| >
| > | I'll try to create a patch, however I may need some assistance
| > | compiling base libraries.
| >
| > Thank you.  Creating a patch, attaching to a ticket with some rationale,
| > and submitting it to the libraries list, is the best way to push your
| > work over the hill and into the actual code base.   I'm sure others will
| > help.  If you get stuck, yell!
| >
| > Daniel Fischer is working in this patch too.
| >
| > Simon
| 
| Since I'm working on GHC.Float anyway, I'll include Henning's rounding etc.
| code too.
| 
| Speaking of GHC.Float, there are a few points where I would like some
| guidance on where to put things.
| 
| I could of course put everything in GHC.Float, but it's big already and I'd
| prefer not to clutter it up further.
| 
| For toRational, to avoid wasting time in gcd, I need an array for the
| number of trailing 0-bits in a byte. Also, since bit-fiddling of Integers
| is considerably slower than for fixed width types, I'd need to import
| GHC.IntWord64 since a Double mantissa won't fit in an Int on 32-bit
| systems. This could go into GHC.Float or into a GHC.Float.Utils module.
| 
| For fromRational, I need a fast integerLog2. For that, I need access to the
| internal representation of Integers when using integer-gmp and an
| alternative implementation for integer-simple (which would be much slower,
| but if you use integer-simple, performance probably isn't your foremost
| concern). I might need a few more odds and ends if special-casing for the
| results of toRational (whose denominator is a power of 2) proves to be a
| gain.
| 
| Putting all the auxiliary stuff in GHC.Float wrapped in #ifdefs is IMO an
| appalling idea.
| 
| integerLog2 and more generally integerLogBase are useful enough to be added
| to GHC.Integer (Int/Word is not yet available, so it'd be the '#' versions,
| where would the wrappers returning an Int or Word go?).
| If I need the stuff for special casing, my preferred solution would be to
| put it in GHC.Integer.Variant.Internals or add a small dedicated module for
| them to the package.
| 
| So what's the best place to put stuff?

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

Re: Proposal: Better power for Rational

On Monday 04 October 2010 16:47:27, Simon Peyton-Jones wrote:
> In general, it's an implementation matter where to put these functions,
> rather than a major design choice.  If one module is getting big and
> clumsy, then maybe splitting it into two would help.

Yes, I just was a bit uncertain because my favoured way involves several 
packages, so I thought I'd rather ask for a general okay before producing a 
number of patches and then get told "Duh, that's not cricket."

>
> However, as you say we need to think about integer-simple too, so we
> should perhaps think about adding the same new functions to the
> 'integer-gmp' and 'integer-simple' packages.  Then you would not need
> #ifdefs in GHC.Float, would you?  
>
> s

Right, putting the log-related stuff in the integer-* packages would make 
it work without #ifdefs.
I would only need one for toRational if using Int64 instead of Int incurs a 
performance penalty on 64-bit systems.
Does anybody have knowledge about that?

Cheers,
Daniel

Making it easier to contribute non-functional changes

Hi all,

During the work on the containers library, I felt that it's too
difficult to contribute non-functional changes to the libraries
managed by the libraries list. If you look at repos of libraries
managed by individuals, rather than the libraries list, you see a
smattering of small changes that improve: the internal structure, the
docs, the tests, and (if you're lucky) the benchmarks of the library.

I'd like to see (and make) more non-functional changes to the core
libraries, but currently I feel that the overhead of creating a
ticket, writing an email, etc., is too large; what should be a
5-minute change stretches to over two weeks. I argue that's the reason
we don't see many small, but important, changes to the core libraries.

Proposal:

Non-functional changes should be allowed without review by the
libraries list. Such changes can be commited directly, if the commiter
has access to the repo, or attached to a "please merge" ticket on the
bug tracker.

Only changes that don't affect the API or performance (in non-trivial
ways) should be allowed in without a review. Examples of patches that
shouldn't require review: addition of tests/benchmarks, smaller
documentation improvements, internal reorganization, updates due to
compiler changes, etc.

It's possible that once a commit that should have been reviewed gets
commited. I suggest we adopt an "ask for forgiveness, not for
permission" policy in these cases. We can always roll back changes.

N.B. If someone (e.g. Ian) commits patches of this nature on someone
else's behalf, that person should not be held responsible if the
patches are rolled back later.

Comments welcome!

Cheers,
Johan

Re: Haskell Platform Proposal: add the 'text' library

On Sun, Oct 03, 2010 at 11:05:49PM -0400, Bryan O'Sullivan wrote:
> On Tue, Sep 21, 2010 at 10:53 AM, Ian Lynagh <igloo <at> earth.li> wrote:
> 
> > Still segfaults for me in 0.9, and I can't see the test for it.
> >
> 
> Turns out there were two bugs, not just one. It's definitely fixed in
> 0.9.0.1 

Yup, that fixes that case, but this one still segfaults (on a 32bit
platform):

    import qualified Data.Text as T

    main :: IO ()
    main = do let s = T.replicate (5^11) (T.pack (replicate 89 'a'))
              print $ T.last s
              print $ T.head s

Thanks
Ian

Re: Make lines stricter to fix a space leak

Daniel Fischer schrieb:
> On Monday 27 September 2010 22:18:40, Daniel Fischer wrote:
>> Although the Core looks as though it might leak,
> 
> And with 6.8.3 it does leak indeed, but no more with 6.10.* and 6.12.*.
> All produced identical Core, so it's probably a change in the garbage 
> collector.

How can we be sure it runs in constant memory in future GHC versions? Or
in other Haskell compilers? Those fixes to memory leaks look very
fragile to me.

Re: Making it easier to contribute non-functional changes

Hey,

Aren't you suppose to be on vacation!  : )

BTW, I went through you slides while waiting for my connection.  You did a 
nice job covering a lot of stuff.

Hope you enjoy the rest of your time on Canada.

Cheers!  -Tyson

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

Re: Making it easier to contribute non-functional changes

On Mon, Oct 04, 2010 at 12:03:22PM -0400, Johan Tibell wrote:
> Only changes that don't affect the API or performance (in non-trivial
> ways) should be allowed in without a review. Examples of patches that
> shouldn't require review: addition of tests/benchmarks, smaller
> documentation improvements, internal reorganization, updates due to
> compiler changes, etc.

It's already the case that such changes are applied by people with
commit access.  I agree that the libraries submission process is too
heavyweight in such cases.  But contributors without commit access need
to persuade someone who does to commit for them, e.g. by posting on
the libraries list.

> It's possible that once a commit that should have been reviewed gets
> commited. I suggest we adopt an "ask for forgiveness, not for
> permission" policy in these cases. We can always roll back changes.
> 
> N.B. If someone (e.g. Ian) commits patches of this nature on someone
> else's behalf, that person should not be held responsible if the
> patches are rolled back later.

There I disagree -- committers need to make a best effort to be sure
of what they are doing, that it doesn't break validate, and that it's
not an API change.  Breaking the GHC build is a big deal.  That means
someone asking someone else to commit for them has to demonstrate that
it's safe and minor.