On Sat, Mar 20, 2010 at 5:38 PM, Don Stewart wrote:
> http://hackage.haskell.org/platform/new/
> Enjoy. Web design courtesy tupil.com (Eelco and Chris)
Nice!
Muggezifterij: (that's dutch)
* The Haskell logo moves out of view when I decrease my window size.
* The Pure functional programming is
Hi Simon,
Nice package!
For completeness sake, shouldn't the package also offer these functions:
* asyncOS
* asyncOn
* asyncWithUnmask
* asyncOnWithUnmask
analogous to the same functions in Control.Concurrent.
I don't know if they will be used a lot but I also added them to the
threads package
On 14 June 2012 15:57, Bas van Dijk wrote:
> Hi Simon,
>
> Nice package!
>
> For completeness sake, shouldn't the package also offer these functions:
>
> * asyncOS
> * asyncOn
> * asyncWithUnmask
> * asyncOnWithUnmask
>
> analogous to the same functions i
On 15 June 2012 23:45, Johan Tibell wrote:
> Hi,
>
> I am, with Roman's support, making a formal proposal to have the
> vector package included in the Haskell Platform:
>
> http://trac.haskell.org/haskell-platform/wiki/Proposals/vector
>
> See the wiki page for details, and a list of open issue
On Jun 19, 2012 12:16 AM, "Henning Thielemann" <
lemm...@henning-thielemann.de> wrote:
>
>
> On Mon, 18 Jun 2012, Roman Leshchinskiy wrote:
>
>> There are type families, rank-n types, unboxed types and other goodies
deep in the guts of vector so the Storable part is very much GHC-specific.
To be ho
On 10 July 2012 22:58, Johan Tibell wrote:
> Hi Simon,
>
> Sorry for the late reply, I was on vacation.
>
> Let me preface my response below by saying that I think SafeHaskell
> (SH) is an interesting and worthwhile research project and this isn't
> meant as a diss of SH as whole. Also, my argumen
On 11 July 2012 20:49, Henning Thielemann wrote:
> I think the idea was to have Unsafe modules and move the unsafe functions
> there. :-)
Indeed. I don't see the point about having .Safe modules. Modules
should be safe by default as you mentioned before. I guess the reason
we have .Safe modules i
On 11 July 2012 23:45, Johan Tibell wrote:
> On Wed, Jul 11, 2012 at 2:11 PM, Bas van Dijk wrote:
>> On 11 July 2012 20:49, Henning Thielemann
>> wrote:
>>> I think the idea was to have Unsafe modules and move the unsafe functions
>>> there. :-)
>>
>&g
On 11 July 2012 23:46, Henning Thielemann wrote:
>
> On Wed, 11 Jul 2012, Bas van Dijk wrote:
>
>> The ideal, but currently, impossible way of dealing with this is to
>> mark the _export_ of unsafe functions in a module as DEPRECATED and in
>> a later version remove th
On 12 July 2012 05:52, Johan Tibell wrote:
> It's unsafe in the sense that any module containing it cannot be
> marked as Safe (only Trustworthy) and thus won't fit the scheme with
> modules containing only Safe functions that Simon described.
I think what Simon described was the current situatio
On 11 January 2013 21:00, Gregory Collins wrote:
> First: Bas, would you support making case-insensitive a Haskell platform
> package?
Yes, I would support that.
> Assuming you say yes, I'd like to propose it for inclusion in the Haskell
> platform. The wiki page for this proposal is here:
>
>
On 14 January 2013 18:20, Henning Thielemann
wrote:
>
> On Mon, 14 Jan 2013, Ben Millwood wrote:
>
>> In response to this, I ask you: is compatibility with the platform really
>> a goal for your live-sequencer? Would the live-sequencer benefit
>> particularly from use of the case-insensitive packa
On Jan 15, 2013 12:29 AM, "Gregory Collins" wrote:
>
> On Mon, Jan 14, 2013 at 2:24 PM, Bas van Dijk
wrote:
>>
>> Something else: according to the HP procedure proposals should be
>> discussed on the libraries list. Gregory: could you start a new
>> discu
On 21 January 2013 00:29, Mark Lentczner wrote:
> In 0.4.0.2 and earlier, it was mapping Data.Char's toLower for all types
> except Text (where it was using Text's toCaseFold)
> From 0.4.0.3 and on, it is using Text's toCaseFold for all types, except
> ByteString, where it uses it's own toLower fu
On Jan 23, 2013 11:30 AM, "Gregory Collins" wrote:
> I'm proposing the popular and widely-used attoparsec to become part of
the Haskell Platform.
+1
In the future it would be nice if the Data.Attoparsec.Combinator module was
moved to a separate package so that both parsec and attoparsec can prov
On 21 January 2013 21:03, Ganesh Sittampalam wrote:
> I couldn't spot any tests. Some ideas:
>
> - It uses a few different implementations of toLower (Data.Char, Text,
> toLower8) depending on how it is being used. Those implementations could
> be tested against each other.
>
> - Some concrete tes
I added a simple benchmark:
https://github.com/basvandijk/case-insensitive/blob/hp/bench/bench.hs
Unfortunately it shows some negative results:
$ cabal configure --enable-benchmarks
$ echo -n "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
$ cabal build && \
dist/build/b
On 26 January 2013 19:31, Bas van Dijk wrote:
> Any ideas how to improve this?
It also doesn't help using a rewrite rule to not go via the type class:
{-# RULES
"mk/ByteString" forall (bs :: B.ByteString). mk bs = CI bs (B.map toLower8 bs)
#-}
and modifying the benchmar
Adding the following rewrite rule makes the "case-insensitve"
benchmark as fast as the "no-class" benchmark:
{-# RULES
"mk/ByteString" forall (bs :: B.ByteString). mk bs = CI bs (foldCaseBS bs)
#-}
foldCaseBS :: B.ByteString -> B.ByteString
foldCaseBS bs = B.map toLower8' bs
where
t
I released case-insensitive-1.0:
http://hackage.haskell.org/package/case-insensitive-1.0
Bas
___
Haskell-platform mailing list
Haskell-platform@projects.haskell.org
http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
On 11 January 2013 21:00, Gregory Collins wrote:
> Hi all,
>
> First: Bas, would you support making case-insensitive a Haskell platform
> package?
>
> Assuming you say yes, I'd like to propose it for inclusion in the Haskell
> platform. The wiki page for this proposal is here:
>
> http://trac.
On 21 March 2013 06:54, wren ng thornton wrote:
> One concern with the above approach: is "siphash" a sufficiently generic
> name, or is it just one hashing method that happens to deflect this DoS
> issue? I haven't read the paper, so...
One could of course generalize the above method using somet
On 14 May 2013 21:48, Peter Simons wrote:
> I wonder how
> you feel about updating both packages in the upcoming HP to their
> respective latest version? Do you think there's any risk associated with
> those updates?
Hi Peter,
There's no risk to upgrading case-insensitive to 1.0.0.2. The only
ch
The case-insensitive bump is good.
___
Haskell-platform mailing list
Haskell-platform@projects.haskell.org
http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
On 10 November 2013 23:14, Mark Lentczner wrote:
> I spoke too soon:
>
> aeson induces blaze-builder
Note that I removed the blaze-builder requirement from aeson-HEAD (it
now uses the Builder from bytestring with a fallback to blaze-builder
when configured with -fblaze-builder).
I think we're pr
On 10 November 2013 22:40, Mark Lentczner wrote:
> Including aeson, which I think we'd all very much like to do, requires
> dlist-0.5.
> Now, dlist has been around for a very long time, and is very stable.
> I do not believe that dlist's API is exposed indirectly via aeson at all.
>
> I hereby pro
On 12 November 2013 11:47, Sean Leather wrote:
> Assuming Don is willing and others agree, I don't mind taking over
> maintenance of dlist. I just imported it into GitHub:
> https://github.com/spl/dlist
Thanks for maintaining it!
> Bas: please submit a pull request with the suggested changes. Th
On 13 Nov 2013 18:53, "Joachim Breitner" wrote:
>
> Hi,
>
> Am Dienstag, den 12.11.2013, 09:26 +0100 schrieb Bas van Dijk:
> > On 10 November 2013 22:40, Mark Lentczner
wrote:
> > > Including aeson, which I think we'd all very much like to do, requires
g changes but that it would
significantly stabilize after this. I would prefer this over first
including and old release and then later including a breaking release since
I would like the HP to be as stable as possible.
> On Mon, Nov 11, 2013 at 2:07 AM, Bas van Dijk
wrote:
>>
>> N
On 28 November 2013 13:42, Sven Panne wrote:
> Just two add my 2c: Given all these new packages which would need to
> be pulled into the HP just for aeson, let's not include aeson for
> 2013.4.0.0 and release 2013.4.0.0 soon without the need for lengthy
> discussions.
As the proposer for inclusio
30 matches
Mail list logo
