Hi,
2012/2/19 Bas van Dijk
>
> I do think it's better to integrate this into the deepseq package (and
> thus removing the default implementation of rnf). Otherwise we end up
> with two ways of evaluating values to normal form.
>
I agree with this, and I guess many people are already using the d
On Sun, Feb 19, 2012 at 23:27, Richard O'Keefe wrote:
> Now *that's* annoying. It turns out that the xattr command is *there*,
> but 'man xattr' is completely silent. There is nothing for it in
> /usr/share/man/man1 . I had been using my own command to do the
> equivalent of xattr -d.
Bzuh?
On 20/02/2012, at 3:04 PM, Jack Henahan wrote:
>
> What's your setup like that you can't even use gdb in your own directory?
> That sounds unusual. And you can turn off the warning, either globally or
> selectively.[3][4]
My setup is Mac OS X 10.6.8, pretty much out of the box, plus a bunch of
On 20 February 2012 15:06, Thomas DuBuisson wrote:
> Using GHC, is there any way to disable warnings (entirely or
> selectively) during a section of source code? I ask because of some
> Template Haskell that periodically generates unused code and I'd
> rather not see the warnings or rework the ma
Using GHC, is there any way to disable warnings (entirely or
selectively) during a section of source code? I ask because of some
Template Haskell that periodically generates unused code and I'd
rather not see the warnings or rework the macros (beyond emitting some
sort of "disable" and "re-enable"
In fact, since Gatekeeper, by design, can only quarantine applications acquired
through the App Store or a download (or any other method which applies the
quarantine flag), it may be entirely irrelevant for you depending on how you
distribute. Applications on physical media are exempt, source bu
> I'm proposing my record fields so that selectors are just functions. Then
it's
> independent of dot notation. (It's the semantics I'm far more concerned
> with.)
Folks, I've put my 'Record in Haskell' proposal on the wiki
http://hackage.haskell.org/trac/ghc/wiki/Records as suggestion 5 Declar
As has been mentioned, it's already possible to override Gatekeeper on a
per-app basis, and what I've seen so far is that it operates just as the
download warning: once you get past the first check, it never bothers you
again. Is it unreasonable for your users to open it that way once? As for
s
On Sun, Feb 19, 2012 at 8:39 PM, Tom Murphy wrote:
> On the other hand,
> it's impossible for a software company to maintain a sense of
> professionalism, when a user has to know a weird "secret handshake" to
> disable what they may perceive as equivalent to antivirus software.
I'll also just add
On Sun, Feb 19, 2012 at 8:19 PM, Tom Murphy wrote:
> Actually, what I was more concerned about was the ability to
> distribute a "full" Mac application, with a GUI, made with a method
> other than calling Haskell from Objective-C.
> It seems that *none* of these applications will be usable
> *Short* term, the most that will happen is that people will have to
> say "yeah yeah I know just let me have it OK?".
>
> Already in 10.6 there was this nagging feature where you click on a
> downloaded document and it says "this was downloaded, do you really
> want to open it" and it takes a pai
On 2/19/12, Austin Seipp wrote:
> On Sun, Feb 19, 2012 at 6:01 PM, Tom Murphy wrote:
>> 0) Distributing non-Cocoa-built apps, even if you're approved by Apple
>
> Do you just mean binaries that you expect users run under
> /usr/local/bin or something, not app bundles? If that's the case, I
> cann
Hello Felipe,
> If we have separate directories, then you can "build-depends:
> own-package". This means that on the test suite's build-depends you
> need to list only the dependencies that the test-suite needs, not
> every dependency. Also, you don't need to constrain the version of
> any dupli
Well, the command-line tools are now available as a standalone package[1]
separate from Xcode[2], so Apple's taken notice of and responded positively to
large efforts like Homebrew and MacRuby. With that in mind, I don't think it's
unreasonable to think this support also applies to other users o
On 20/02/2012, at 1:01 PM, Tom Murphy wrote:
> Does anyone know what this will mean for the future of Haskell
> development in OS X?:
>
> http://www.apple.com/macosx/mountain-lion/security.html
Quoting that document:
Or you can install all apps from anywhere,
just as you can tod
On Sun, Feb 19, 2012 at 6:01 PM, Tom Murphy wrote:
> 0) Distributing non-Cocoa-built apps, even if you're approved by Apple
Do you just mean binaries that you expect users run under
/usr/local/bin or something, not app bundles? If that's the case, I
cannot say if the same restrictions will apply.
Does anyone know what this will mean for the future of Haskell
development in OS X?:
http://www.apple.com/macosx/mountain-lion/security.html
I'm particularly interested in what it'll mean for
0) Distributing non-Cocoa-built apps, even if you're approved by Apple
1) Writing software for widespr
On Sun, 2012-02-19 at 21:06 +0100, Bas van Dijk wrote:
> On 19 February 2012 18:11, Maxime Henrion wrote:
> > If you're not dealing with an abstract datatype, you _shouldn't_ have an
> > explicit instance, because it would be possible to write an incorrect one,
> > while that is impossible if you
On 19 February 2012 18:11, Maxime Henrion wrote:
> If you're not dealing with an abstract datatype, you _shouldn't_ have an
> explicit instance, because it would be possible to write an incorrect one,
> while that is impossible if you just derive a generic implementation
> (as long as the generic
On Sun, 2012-02-19 at 16:17 +0100, Bas van Dijk wrote:
> On 19 February 2012 13:12, Maxime Henrion wrote:
> > Any suggestions are welcome.
>
> Nice work but it would be nice to have this functionality directly in
> the deepseq package as in:
>
> #ifdef GENERICS
> {-# LANGUAGE DefaultSignatures,
On 19 February 2012 13:12, Maxime Henrion wrote:
> Any suggestions are welcome.
Nice work but it would be nice to have this functionality directly in
the deepseq package as in:
#ifdef GENERICS
{-# LANGUAGE DefaultSignatures, TypeOperators, FlexibleContexts #-}
#endif
class NFData a where
rn
Erik Hesselink writes:
> On Sun, Feb 19, 2012 at 12:50, Jon Fairbairn
> wrote:
>> This is probably a failure of my search fu or some other mental
>> lacuna, but is there already a definition of this function
>> somewhere:
>> \a b -> runKleisli $ (Kleisli a) <+> Kleisli b
>> ?
> Not a single na
Hello all,
Yesterday I uploaded a new package on Hackage called generic-deepseq. It
implements the 'deepseq' function generically using the new GHC.Generics
framework as found in GHC >= 7.2. It can be used as a replacement for
the deepseq package.
Given that hackage is currently down, here is an
Isn't that just something like liftA2 mplus?
Отправлено с iPhone
Feb 19, 2012, в 15:50, Jon Fairbairn написал(а):
>
> This is probably a failure of my search fu or some other mental
> lacuna, but is there already a definition of this function
> somewhere:
>
> \a b -> runKleisli $ (Kleisli a)
Not a single name, but I believe
liftA2 mplus
is the same function, and much shorter (and more general). It uses the
Applicative instance for (a ->). Of course, it also works with liftM2.
Erik
On Sun, Feb 19, 2012 at 12:50, Jon Fairbairn wrote:
>
> This is probably a failure of my search fu
This is probably a failure of my search fu or some other mental
lacuna, but is there already a definition of this function
somewhere:
\a b -> runKleisli $ (Kleisli a) <+> Kleisli b
?
Hoogling for its type
MonadPlus m => (a -> m b) -> (a -> m b) -> a -> m b
doesn’t net me anything useful.
-
edgar klerks wrote:
As beginner I really liked reactive-banana. I used it in a inhouse
project for the graphical user interface (wx) and I found it easier to
use than the "imperative" approach. Unfortunately the
reactive-banana-wx package seems to be broken on 7.2.
Actually, it's a weird bug in
27 matches
Mail list logo
