Hi,
I'm not sure I fully understand what you're trying to do, but when I read
Ideally, I'd like to restrict my
search to Located instances that wrap an instance of Outputable,
I think this means SYB is not the right tool. Due to the way Typeable works
(it's monomorphic), SYB doesn't really
You can't define (=) if your state type changes:
(=) :: m a - (a - m b) - m c
Whereas, your bind is effectively three different parametric types:
_bind :: m1 a - (a - m2 b) - m3 b
You can use parametric monads to represent state changing within a
monad. Oleg Kiselyov has tutorials on their use
On 08/16/2011 09:23 AM, Stephen Tetley wrote:
{-
I don't think parametric monads will solve your problem though, as you
want a product of the states as the result of bind. Are you really
sure you want this behavior?, I'd imagine it breaks the monad laws
anyway.
-}
It seems that the product
Hi all,
I'm trying to profile a mixed language program, in which Haskell is NOT
the top layer and does not contain the `main' function. (C is/does.)
Is this effort doomed to fail?
I'm getting a segmentation fault, as soon as the first Haskell function
is called, despite having included `-K100M'
On 16 August 2011 15:56, David Banas dba...@banasfamily.net wrote:
Any thoughts?
Just a hunch, did you specify the correct calling convention for amiInit?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
It seems that the notmuch-haskell bindings (version 0.2.2 built against
notmuch from git master; passes notmuch-test) aren't dealing with memory
management properly. In particular, the attached test code[1] causes
talloc to abort. Unfortunately, while the issue is consistently
reproducible, it
If you want to call a Haskell function from C you should do a foreign
export of the function, that will create a stub function with C
calling convention that you can call.
Regards,
Niklas
2011/8/16 David Banas dba...@banasfamily.net:
Hi all,
I'm trying to profile a mixed language program, in
Reading a bit closer I assume you have already done that. Sorry for that.
Regards,
Niklas
2011/8/16 Niklas Larsson metanik...@gmail.com:
If you want to call a Haskell function from C you should do a foreign
export of the function, that will create a stub function with C
calling convention
On Tue, Aug 16, 2011 at 12:42 PM, Niklas Larsson metanik...@gmail.com wrote:
If you want to call a Haskell function from C you should do a foreign
export of the function, that will create a stub function with C
calling convention that you can call.
I put an example of how to do this on
I've noticed there's a convention to put modules having to deal with
randomness into System.Random. I thought System was for OS
interaction? Granted getting a random seed usually means going to the
OS, but isn't the rest of it, like generating random sequences,
distributions, selecting based on
I think of it as natural for exactly the reason you stated (the data
comes from the OS). It seems even more natural to me in the entropy
package module 'System.Entropy' as I am accustom to the phrase system
entropy. Equally, I would fine a 'Network.Entropy' module acceptable
under the assumption
On Aug 16, 2011, at 4:04 PM, Evan Laforge wrote:
I've noticed there's a convention to put modules having to deal with
randomness into System.Random. I thought System was for OS
interaction? Granted getting a random seed usually means going to the
OS, but isn't the rest of it, like
On Tue, Aug 16, 2011 at 17:07, James Cook mo...@deepbondi.net wrote:
On Aug 16, 2011, at 4:04 PM, Evan Laforge wrote:
I've noticed there's a convention to put modules having to deal with
randomness into System.Random. I thought System was for OS
interaction? Granted getting a random seed
Yeah, fair enough about getting the seed. I think I like the idea of
breaking them into System.Entropy and then Random or Data.Random. It
feels odd to stick pure algorithm packages, which simply accept a
random seed or stream from elsewhere, under System.Random.
There are a fair number of
I don't like the idea of Data.Random because random numbers use
ordinary number types, and the generator itself is not the object of
interest, the numbers are. I'd much prefer Math.Random. As the Math
prefix isn't used in the core libraries maybe Control.Random is the
least unpalatable
Hi, forks
I'm glad to announce the alpha release of TKYProf.
http://hackage.haskell.org/package/tkyprof
https://github.com/maoe/tkyprof
TKYprof is a web-based interacitve visualizer for GHC time and allocation
profiling reports. It helps you to find the bottlenecks in your code quickly!
I'm glad to announce the alpha release of TKYProf.
This looks useful, thanks! I'll try it out and let you know if I have
problems.
Installing with GHC 7.2, I needed to relax some upper bounds in cabal files
of dependencies (maintainers CC'ed).
- email-validate and ranges specify base 4.4
The blaze-textual issue is intentional: There's a bug in GHC that
prevents C++ code from working correctly with Template Haskell, and
newer versions of blaze-textual use a C++ library for parsing doubles.
I'm hoping that the defaults change on blaze-textual to use the native
code instead so that I
18 matches
Mail list logo
