Sorry, I left the profiling option on, which seems to suppress the
dynamic options.
On Mon, Oct 29, 2012 at 1:29 PM, Magicloud Magiclouds
wrote:
> Hi,
> I set "shared: True" in ~/.cabal/config, and using ghc 7.6.1. Then
> clear user space hackages and reinstall them.
> First of all, I think c
Er, oops.
...can be implemented as:
\a rs -> let s = Set.fromList (rs >>= \(a, b) -> [a..b]) in a `member` s
Something like that!
On Mon, Oct 29, 2012 at 2:48 PM, Tony Morris wrote:
> Hi,
> I was wondering if anyone knows of a package implementing a fast lookup
> for an element in ranges.
>
>
Hi,
I was wondering if anyone knows of a package implementing a fast lookup
for an element in ranges.
For example, this operation:
Ord a => a -> [(a, a)] -> Bool
...can be implemented:
\a rs -> let s = Set.fromList rs in a `member` s
This is not particularly efficient. A segment tree seems like
Arch does not keep 2 python packages. There are simply 2 pythons (different
programs). And this is true not only for Arch but for practically any other
distro.
Obvious solution for arch is IgnorePkg in the pacman.conf. That's what i
did (until Yesod officially supports newest ghc).
On Sunday,
Sure. No matter what's done in Cabal, the clients for everything else will
still be mainly browsers.
On Mon, Oct 29, 2012 at 12:59 AM, Niklas Hambüchen wrote:
> No matter what we do with cabal, it would be great if I could soon point
> my browser at https://haskell.org *anyway*.
>
> On 28/10/12
No matter what we do with cabal, it would be great if I could soon point
my browser at https://haskell.org *anyway*.
On 28/10/12 23:55, Patrick Mylund Nielsen wrote:
> Of course, as long as Cabal itself is distributed through this same
> https-enabled site, you have the same PKI-backed security as
Of course, as long as Cabal itself is distributed through this same
https-enabled site, you have the same PKI-backed security as just about any
major website. This model has problems, yes, but it's good enough, and it's
easy to use. If you really want to improve it (without impacting
usability), ha
PGP tends to present many usability issues, and in this case it would make
more sense/provide a clearer win if there were many different,
semi-untrusted hackage mirrors. Just enable HTTPS and have Cabal validate
the server certificate against a CA pool of one. PKI/trusting obscure
certificate autho
On Sun, 28 Oct 2012 17:07:24 -0400 Patrick Hurst wrote:
> How do you get a copy of cabal while making sure that somebody hasn't MITMed
> you and replaced the PGP key?
Ultimately it is a DNS problem. To establish a secure connection with
haskell.org you'd have to get the certificate from the DNS,
Actually Arch has been accommodating in other cases when there was a stable
library and a new/developing. It certainly keeps around two versions of
python, autoconf, GTK, qt, gambas... The solution I'm proposing would be a
little different than those cases, but on the same principle.
Timothy
On Sun, Oct 28, 2012 at 5:54 PM, wrote:
> There seems to be a bit of a clash between ghc being a tool, and ghc
> being a toy. There need not be. Your works-for-me is great but it is
> meaningless to those of us who use ghc as a tool for larger projects.
>
This is not specific to GHC. Arch Lin
I didn't wish to suggest that the latest version shouldn't be available. If
you read my entire message, the suggestion I made, is that arch should
install the latest with the next to latest in parallel and do so by default
rather than as some weird and hacky work-around.
Sending pull request
So why not use HTTPS?
Michael Walker
October 28, 2012
5:43 PM
You don't.
Somewhere, you just have to trust that nothing went awry.The best
thing to do is just to make it as difficult as possible for anattacker
to be successful - make the PGP keys widely known and have al
> How do you get a copy of cabal while making sure that somebody hasn't
> MITMed you and replaced the PGP key?
You don't. Somewhere, you just have to trust that nothing went awry.
The best thing to do is just to make it as difficult as possible for an
attacker to be successful - make the PGP keys
Fyi, the is a specific arch-haskell mailing list which will probably get
you a better answer to your question. I cc'd them for you.
~Rickey
On Sun, Oct 28, 2012 at 5:24 PM, Clark Gaebel wrote:
> Personally, I like the latest version of GHC being in the repository, as
> that's the version I nor
Do it at home.
If you're at an internet cafe, though, it'd be nice if you could trust
cabal packages.
- Clark
On Sun, Oct 28, 2012 at 5:07 PM, Patrick Hurst wrote:
>
> On Oct 28, 2012, at 4:38 PM, Changaco wrote:
>
> > On Sun, 28 Oct 2012 17:46:10 +0100 Petr P wrote:
> >> In this particul
Personally, I like the latest version of GHC being in the repository, as
that's the version I normally use.
What packages aren't working for you on 7.6? I find that they get updated
pretty quickly, and if you run into any that aren't, feel free to send the
authors a pull request. Almost everything
Golfed: http://en.wikipedia.org/wiki/Code_golf
<=< : Also known as Kleisli composition. More info:
http://www.haskell.org/hoogle/?hoogle=%3C%3D%3C
On Sun, Oct 28, 2012 at 4:36 PM, dokondr wrote:
> On Fri, Oct 26, 2012 at 2:34 AM, Jake McArthur wrote:
>
>> I golfed a bit. :)
>>
>> sequence <=
On Oct 28, 2012, at 4:38 PM, Changaco wrote:
> On Sun, 28 Oct 2012 17:46:10 +0100 Petr P wrote:
>> In this particular case, cabal can have the public part of the
>> certificate built-in (as it has the web address built in). So once one
>> has a verified installation of cabal, it can verify the s
Hello,
Who is in charge of the ghc and haskell packages on Arch linux? The current
system isn't working.
Arch linux tends to update packages very quickly.
For ghc, always having the latest ghc isn't a good thing. At least if you
actually want to get some work done. A majority of the time the
On Sun, Oct 28, 2012 at 1:45 PM, Patrick Hurst
wrote:
> On the other hand, with PGP, any user who wants to be secure but doesn't use
> GPG would have to verify the identity of whoever signed the Cabal GPG key,
> and most non-Linux operating systems don't come with a list of trusted GPG
> keys.
On Sun, 28 Oct 2012 17:46:10 +0100 Petr P wrote:
> In this particular case, cabal can have the public part of the
> certificate built-in (as it has the web address built in). So once one
> has a verified installation of cabal, it can verify the server
> packages without being susceptible to MitM at
On Fri, Oct 26, 2012 at 2:34 AM, Jake McArthur wrote:
> I golfed a bit. :)
>
> sequence <=< filterM (const [False ..])
>
>
What is "golfed" and "<=<" ? Please, explain.
Thanks,
Dmitri
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://ww
On Sun, 28 Oct 2012 13:38:46 +0100, Petr P wrote:
Erik,
does cabal need to do any authenticated stuff? For downloading
packages I think HTTP is perfectly fine. So we could have HTTP for
cabal download only and HTTPS for everything else.
Best regards,
Petr Pudlak
Without checking a ce
On Oct 28, 2012, at 12:10 PM, Changaco wrote:
> On Sun, 28 Oct 2012 16:39:10 +0100 Iustin Pop wrote:
>> Sure, but I was talking about a proper certificate signed by a
>> well-known registrar, at which point the https client would default to
>> verify the signature against the system certificate
On Sun, Oct 28, 2012 at 05:10:39PM +0100, Changaco wrote:
> On Sun, 28 Oct 2012 16:39:10 +0100 Iustin Pop wrote:
> > Sure, but I was talking about a proper certificate signed by a
> > well-known registrar, at which point the https client would default to
> > verify the signature against the system
2012/10/28 Changaco :
> It doesn't matter what kind of certificate the server uses since the
> client generally doesn't know about it, especially on first connection.
> Some programs remember the certificate between uses and inform you
> when it changes, but that's not perfect either.
In this part
On Sun, 28 Oct 2012 16:39:10 +0100 Iustin Pop wrote:
> Sure, but I was talking about a proper certificate signed by a
> well-known registrar, at which point the https client would default to
> verify the signature against the system certificate store.
It doesn't matter what kind of certificate the
Hi,
at work, I often need the values the cumulative distribution function of
the Gaussian distribution. The code for this function in haskell, erlang
and perl and the corresponding mathematical paper can be found at
git://github.com/frecker/gaussian-distribution.git .
Regards,
Frank
__
On Sun, Oct 28, 2012 at 04:26:07PM +0100, Changaco wrote:
> On Sun, 28 Oct 2012 14:45:02 +0100 Iustin Pop wrote:
> > Kindly disagree here. Ensuring that packages are downloaded
> > safely/correctly without MITM attacks is also important. Even if as an
> > option.
>
> HTTPS doesn't fully protect ag
On Sun, 28 Oct 2012 14:45:02 +0100 Iustin Pop wrote:
> Kindly disagree here. Ensuring that packages are downloaded
> safely/correctly without MITM attacks is also important. Even if as an
> option.
HTTPS doesn't fully protect against a MITM since there is no shared
secret between client and server
On Sun, Oct 28, 2012 at 03:53:04PM +0100, Petr P wrote:
> 2012/10/28 Iustin Pop :
> > On Sun, Oct 28, 2012 at 01:38:46PM +0100, Petr P wrote:
> >> does cabal need to do any authenticated stuff? For downloading
> >> packages I think HTTP is perfectly fine. So we could have HTTP for
> >> cabal downlo
2012/10/28 Iustin Pop :
> On Sun, Oct 28, 2012 at 01:38:46PM +0100, Petr P wrote:
>> does cabal need to do any authenticated stuff? For downloading
>> packages I think HTTP is perfectly fine. So we could have HTTP for
>> cabal download only and HTTPS for everything else.
>
> Kindly disagree here. E
On Sun, Oct 28, 2012 at 01:38:46PM +0100, Petr P wrote:
> Erik,
>
> does cabal need to do any authenticated stuff? For downloading
> packages I think HTTP is perfectly fine. So we could have HTTP for
> cabal download only and HTTPS for everything else.
Kindly disagree here. Ensuring that packag
I think it is only needed for 'cabal upload'. So if you upload via the
web only, you'd never send your password over plain HTTP.
Erik
On Sun, Oct 28, 2012 at 1:38 PM, Petr P wrote:
> Erik,
>
> does cabal need to do any authenticated stuff? For downloading
> packages I think HTTP is perfectly f
Erik,
does cabal need to do any authenticated stuff? For downloading
packages I think HTTP is perfectly fine. So we could have HTTP for
cabal download only and HTTPS for everything else.
Best regards,
Petr Pudlak
2012/10/28 Erik Hesselink :
> While I would love to have hackage available (o
While I would love to have hackage available (or even forced) over
https, I think the biggest reason it currently isn't, is that cabal
would then also need https support. This means the HTTP library would
need https support, which I've heard will be hard to implement
cross-platform (read: on Window
At Sun, 28 Oct 2012 14:59:00 +0400,
Dmitry Vyal wrote:
> Does hackage at least store the logs of packages uploads? What's the reason or
> such a security model? I guess it was appropriate in the past when hackage was
> an experimental service, but now it's a standard way of distributing Haskell
> c
On 10/28/2012 03:20 AM, Niklas Hambüchen wrote:
- abuse your hackage account and override arbitrary packages
(especially since hackage allows everybody to override everything)
Does hackage at least store the logs of packages uploads? What's the
reason or such a security model? I guess it was
I support this proposal too.
More reasons to use HTTPS can be found at
https://www.eff.org/https-everywhere/deploying-https
On Sun, Oct 28, 2012 at 8:51 AM, Petr P wrote:
> 2012/10/28 Francesco Mazzoli :
> > At Sun, 28 Oct 2012 00:20:16 +0100,
> > Niklas Hambüchen wrote:
> >> (I have mentioned t
2012/10/28 Francesco Mazzoli :
> At Sun, 28 Oct 2012 00:20:16 +0100,
> Niklas Hambüchen wrote:
>> (I have mentioned this several times on #haskell, but nothing has
>> happened so far.)
>>
>> Are you aware that all haskell.org websites (hackage, HaskellWiki, ghc
>> trac) allow unencrypted http conne
At Sun, 28 Oct 2012 00:20:16 +0100,
Niklas Hambüchen wrote:
> (I have mentioned this several times on #haskell, but nothing has
> happened so far.)
>
> Are you aware that all haskell.org websites (hackage, HaskellWiki, ghc
> trac) allow unencrypted http connections only?
>
> This means that every
Cool! Thanks so much!
--Myles
On Sat, Oct 27, 2012 at 8:35 PM, Michael Snoyman wrote:
> The important issue here is that, when using =$, $=, and =$=, leftovers will
> discarded. To see this more clearly, realize that the first line of sink is
> equivalent to:
>
> out1 <- C.injectLeftovers CT.l
43 matches
Mail list logo
