[Haskell-cafe] C variable access via FFI

2010-04-20 Thread Tom Hawkins
I have a bunch of global variables in C I would like to directly read
and write from Haskell.  Is this possible with FFI, or must I write a
bunch of C wrapper functions for the interface, i.e. a 'get' and a
'set' for each variable?

I'm building a simulator for one of our embedded systems.  The C is
embedded code for an ECU -- the global variables are sensor and
control IO.  I'm using Haskell to integrate the C with vehicle models
and to provide the user interface.  With the help of the SDL hackage
lib, I'm able to feed analog and discrete inputs from a gamepad into
the simulator, which then runs the embedded code and streams VCD data
into GTKWave, providing waveform visualization in realtime.  Pretty
fun stuff.

-Tom
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] memory needed for SAX parsing XML

2010-04-20 Thread Daniil Elovkov

Jason Dagit wrote:



On Mon, Apr 19, 2010 at 3:01 AM, Daniil Elovkov 
daniil.elov...@googlemail.com mailto:daniil.elov...@googlemail.com 
wrote:


Hello haskellers!

I'm trying to process an xml file with as little footprint as
possible. SAX is alright for my case, and I think that's the
lightest way possible. So, I'm looking at HaXml.SAX

I'm surprised to see that it takes about 56-60 MB of ram. This seems
constant relative to xml file size, which is expected. Only slightly
depends on it as I recursively traverse the list of sax events. But
it seems like too much.


For me these sorts of problems always involve investigation into the 
root cause.  I'm just not good enough at predicting what is causing the 
memory consumption.  Thankfully, GHC has great tools for this sort of 
investigative work.  The book real-world haskell documents how to use 
those tools:

http://book.realworldhaskell.org/read/profiling-and-optimization.html

If you haven't already, I highly recommend looking at the profiling 
graphs.  See if you can figure out if your program has any space leaks.


No, I didn't profile it yet. I just made up the simplest example (while 
evaluating a few xml parsers) and saw the result.


Given the triviality of the example I considered it could be a feature 
of HaXml SAX parser, and that somebody would say that it is indeed so.





The size of the file is from 1MB to 20MB.

The code is something like this

main = do
   (fn:_) - getArgs
   h - openFile fn ReadMode
   c - hGetContents h
   let out = proc $ fst $ saxParse fn c
   putStrLn out
   getChar


For such a simple program you won't run into any problem with lazy IO, 
but as your program grows in complexity it will very likely come back to 
bite you.  If you're not familiar with lazy IO, I'm referring to the 
hGetContents.  Some example problems:






Thanks, I'm aware of that. Speaking of this, I've always felt a bit 
uncomfortable about lazy IO. I've just looked at the safe-lazy-io 
package now.


I think iteratees are slowly catching on as an alternative to lazy io.  
Basically, the iteratee approach uses a left fold style to stream the 
data and process it in chunks, including some exception handling.  
Unfortunately, I think it may also require a special sax parser that is 
specifically geared towards iteratee use.  Having an iteratee based sax 
parser would make processing large xml streams very convenient in 
haskell.  Hint, hint, if you want to write a library :)  (Or, maybe it 
exists, I admit that I haven't checked.)



Iteratees  seem like a natural thing if we want to completely avoid 
unsafeInterleaveIO. But the presence of the latter is so good for 
modularity.


We can glue IO code and pure code of the type String - a so seamlessly. 
In case of iteratees, as I understand, pure functions of the type String 
- a would no longer be usable with IO String result. The signature (and 
the code itself) would have to be changed to be left fold.


Another (additional) approach would be to encapsulate unsafeInterleaveIO 
within some routine and not let it go out into the wild.


lazilyDoWithIO :: IO a - (a - b) - IO b

It would use unsafeInterleave internally but catch all IO errors within 
itself.


I wonder if this is a reasonable idea? Maybe it's already done?
So the topic is shifting...

--
Daniil Elovkov
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] newbie question how to pass data

2010-04-20 Thread Stephen Tetley
Hi

If you are working with characteristic functions (Point - Bool or
Point - Colour...) the common way to do this is to manufacture a Num
instance for functions. This gives you syntax overloading of the (+,
-, *) operators. Similarly you might want to overload (or have to
overload) Floating, Fractional...

Examples using this technique are Jerzy Karczmarczuk's Clastic, Conal
Elliott's Vertigo, Tangible Values, Pan etc.

To overload Num you have to define Show and Eq instances for functions
as well. Something along the lines of this is adequate:

type CF = (Double,Double) - Bool

instance Show CF where
  show _ = function

instance Eq CF where
 (==) _ _ = error No Eq on  Characteristic functions

instance Num CF where
  f + g = \pt - f pt + g pt
  -- ...
  negate f = \(x,y) - f (negate x, negate y)

  -- ... rest follows this pattern, Floating, Fractional similar

If you characteristic function is Point - Bool then you also need a
Num instance for Bool.

All that said, I think your formulation of func above is slightly
wrong to fit this style. Its forming a function (- Point) to point
rather than a characteristic function Point - Bool.

Best wishes

Stephen
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] newbie question how to pass data

2010-04-20 Thread Mujtaba Boori
Great job Stephen.
Thank for explaining . I got it to work.


On Tue, Apr 20, 2010 at 9:21 AM, Stephen Tetley stephen.tet...@gmail.comwrote:

 Hi

 If you are working with characteristic functions (Point - Bool or
 Point - Colour...) the common way to do this is to manufacture a Num
 instance for functions. This gives you syntax overloading of the (+,
 -, *) operators. Similarly you might want to overload (or have to
 overload) Floating, Fractional...

 Examples using this technique are Jerzy Karczmarczuk's Clastic, Conal
 Elliott's Vertigo, Tangible Values, Pan etc.

 To overload Num you have to define Show and Eq instances for functions
 as well. Something along the lines of this is adequate:

 type CF = (Double,Double) - Bool

 instance Show CF where
  show _ = function

 instance Eq CF where
  (==) _ _ = error No Eq on  Characteristic functions

 instance Num CF where
  f + g = \pt - f pt + g pt
  -- ...
  negate f = \(x,y) - f (negate x, negate y)

  -- ... rest follows this pattern, Floating, Fractional similar

 If you characteristic function is Point - Bool then you also need a
 Num instance for Bool.

 All that said, I think your formulation of func above is slightly
 wrong to fit this style. Its forming a function (- Point) to point
 rather than a characteristic function Point - Bool.

 Best wishes

 Stephen
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe




-- 
Mujtaba Ali Alboori
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Re: hamming distance allocation

2010-04-20 Thread Heinrich Apfelmus
Daniel Fischer wrote:
 Heinrich Apfelmus:

 For instance, your expression can be replaced by

filter (/=0) [hammingX x y | (x:xs) - tails example, y - xs]

 which cuts the total running time in half. It's still quadratic in the
 length of  example . I'm sure there are faster algorithms out there that
 can bring it down to O(n log n) if you want.
 
 I don't think so. You can't calculate the Hamming distance of x and z from 
 the distances between x and y and y and z, so you'd have to consider all 
 pairs of distinct strings, wouldn't you?

And there I was sure about something once, only to see that it's
actually really doubtful... ;)

The thing about the Hamming distance is that it's not a black box, so
you can't get a lower bound by counting the number of minimum calls to
hamming  that have to be made. You are essentially arguing that the
different Hamming distances are independent, which they are not. Not to
mention that there are also black-box restrictions like the triangle
inequality

d(x,z) = d(x,y) + d(y,z)

but that one is probably harmless. In short, the situation is similar to
how the sorting bound O(n*log n) does not apply to radix sort.


Still, you are right to question my O(n*log n) claim; so far, my
attempts at finding such an algorithm myself have failed.

More precisely, the goal is to make a histogram of the possible hamming
distances. We need at least O(n*w) time to do that, where n is the
number of strings and w their maximum length; after all, we have to
touch every character. For simplicity, that the characters are just
one bit each. Furthermore, we can assume that w = log n, otherwise
there are lots of duplicate strings which can be grouped together. In
this notation, the simple algorithm takes O(n^2*w) time.


I did find a straightforward divide-and-conquer algorithm to tally small
Hamming distances, but it's not good enough for the whole histogram.
Here's the specification:

countHemming :: Int - [Bool] - [Bool]
countHemming d xs ys = length [() | x-xs, y-ys, hamming x y == d]

In other words,  countHemming d xs ys  counts the number of pairings
(x,y) whose Hamming distance is exactly  d .

Now, the idea is that this can be made faster for small  d . For
instance, for  d == 0 , we are essentially just calculating the number
of different elements of  xs  and  ys . By requiring that  xs  and  ys
be sorted, this can be done in linear time

countHemming 0 xs ys = ... a variation on  merge xs ys

And for slightly larger  d , we can partition the lists by their first
bits and continue recursively

countHemming _ [] [] = 0
countHemming d xs ys =
  countHemming (d-1) x0 y1 + countHemming (d-1) x1 y0
+ countHemming d x0 y0 + countHemming d x1 y1
where
(x0,x1) = partitionByHead xs
(y0,y1) = partitionByHead ys

partitionByHead xs = (behead True xs, behead False xs)
behead b xs = [bs | (b':bs) - xs, b == b']

To estimate the running time, we set  n = length (xs ++ ys) and let

T(d,n) = running time of  countHamming d xs ys

We started with

T(0,n) = O(n)

and want to discuss the recursive case. The idea is that each list is
divided in half, so we get

T(d,n) = 2*T(d-1,n/2) + 2*T(d,n/2)

From this, we can calculate

T(1,n) = 2*T(0,n/2) + 2*T(1,n/2)
   = O(n) + 2*T(1,n/2) -- remember quicksort!
   = O(n*log n)
T(2,n) = O(n*log n) + 2*T(2,n/2)
   = O(n*(log n)^2)

and so on, yielding

T(d,n) = O(n*(log n)^d)


Alas, this can be used to search a dictionary while accounting for
spelling errors, but it's no good to calculate a full histogram because
it becomes prohibitively expensive when  d ~ w/2 ~ (log n)/2  .



Regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] C variable access via FFI

2010-04-20 Thread Bas van Dijk
On Tue, Apr 20, 2010 at 8:48 AM, Tom Hawkins tomahawk...@gmail.com wrote:
 I have a bunch of global variables in C I would like to directly read
 and write from Haskell.  Is this possible with FFI, or must I write a
 bunch of C wrapper functions for the interface, i.e. a 'get' and a
 'set' for each variable?

I believe Maurício C. Antunes' bindings-DSL has support for automating
reading from and writing to global variables. Look at the Detailed
usage guide from the home page of:

http://hackage.haskell.org/package/bindings-DSL

regards,

Bas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] C variable access via FFI

2010-04-20 Thread Bertram Felgenhauer
Tom Hawkins wrote:
 I have a bunch of global variables in C I would like to directly read
 and write from Haskell.  Is this possible with FFI,

Yes it is, as explained in section 4.1.1. in the FFI specification [1].
An import for a global variable  int bar  would look like this:

foreign import ccall bar bar :: Ptr CInt 

The difference to an import of a function  int foo()  is the extra .

HTH,

Bertram

[1] http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi/ffise4.html#x7-170004.1.1
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: Asynchronous exception wormholes kill modularity

2010-04-20 Thread Simon Marlow

On 09/04/2010 12:14, Bertram Felgenhauer wrote:

Simon Marlow wrote:

On 09/04/2010 09:40, Bertram Felgenhauer wrote:

  timeout t io = mask $ \restore -  do
  result- newEmptyMVar
  tid- forkIO $ restore (io= putMVar result)
  threadDelay t `onException` killThread tid
  killThread tid
  tryTakeMVar result


I'm worried about the case when this function is called with exceptions
already blocked. Then 'restore' will be the identity, and exceptions
will continue to be blocked inside the forked thread.

You could argue that this is the responsibility of the whole chain of
callers (who'd have to supply their own 'restore' functions that will
have to be incorporated into the 'io' action), but that goes against
modularity. In my opinion there's a valid demand for an escape hatch
out of the blocked exception state for newly forked threads.

It could be baked into a variant of the forkIO primitive, say

 forkIOwithUnblock :: ((IO a -  IO a) -  IO b) -  IO ThreadId


I agree with the argument here.  However, forkIOWithUnblock reintroduces 
the wormhole, which is bad.


The existing System.Timeout.timeout does it the other way around: the 
forked thread sleeps and then sends an exception to the main thread. 
This version work if exceptions are masked, regardless of whether we 
have forkIOWithUnblock.


Arguably the fact that System.Timeout.timeout uses an exception is a 
visible part of its implementation: the caller must be prepared for 
this, so it is not unreasonable for the caller to also ensure that 
exceptions are unmasked.  But it does mean that a library cannot use 
System.Timeout.timeout invisibly as part of its implementation.  If we 
had forkIOWithUnblock that would solve this case too, as the library 
code can use a private thread in which exceptions are unmasked.  This is 
quite a nice solution too, since a private ThreadId is not visible to 
anyone else and hence cannot be the target of any unexpected exceptions.


So I think I'm convinced that forkIOWithUnblock is necessary.  It's a 
shame that it can be misused, but I don't see a way to avoid that.


Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] ANNOUNCE: Agata-0.2.0

2010-04-20 Thread Neil Mitchell
Hi,

Have you seen the derive package? It also generates QuickCheck
instances in virtually the same way - plus it can generate source code
and do lots of other types of instances.
http://community.haskell.org/~ndm/derive/

Thanks, Neil


2010/4/20 Bas van Dijk v.dijk@gmail.com:
 2010/4/19 Jonas Almström Duregård jonas.dureg...@gmail.com:
 If this is to be used with QuickCheck maybe it should be named that way.
 Certainly worth considering. There seems to be no convenient way of
 renaming packages on Hackage though, is there?

 AFAIK hackage has support for deprecating packages in favor of others.
 This functionality is not exposed to regular users but you could mail
 one of the maintainers (Ross Paterson) to rename your package.

 Bas
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] ANNOUNCE: Agata-0.2.0

2010-04-20 Thread Sebastiaan Visser
Jonas,

You can also derive (Co)Arbitrary instances automatically using the 
regular-extras package based on the Regular generic programming library.

The advantage of using a library like Regular is that you do not have to write 
any Template Haskell code. The library generates a nice algebraic generic view 
on your datatype that you can use to write your generic functions. The Regular 
library itself of course uses TH internally, but this is done once and all 
datatype generic functions can piggy bag on the same TH derivation. For 
example, look at Generics.Regular.Functions.Arbitrary, this module is really 
concise.

Nice work though!

Gr,
Sebastiaan

On Apr 18, 2010, at 1:43 AM, Jonas Almström Duregård wrote:
 I'm pleased to announce Agata (Agata Generates Algebraic Types Automatically)!
 
 Avoiding excessive details, usage is best described by a small example:
 
 {-#LANGUAGE TemplateHaskell #-}
 import Test.QuickCheck
 import Test.AgataTH
 
 data X a b = X [Either a b] deriving Show
 data Y = Y deriving Show
 data Z = Z deriving Show
 
 $(agatath $ deriveall [''X,''Y,''Z])
 
 main = sample (arbitrary :: Gen (X Y Z))
 
 This code derives instances of Test.QuickCheck.Arbitrary for the data
 types X, Y and Z.
 
 http://hackage.haskell.org/package/Agata
 
 Regards Jonas

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Profiling

2010-04-20 Thread rodrigo.bonifacio
Dear all,
I am trying to compile a project with the "-prof -auto-all" profile options. But the compiler returns:
"Could not find module `Text.ParserCombinators.Parsec.Language':Perhaps you haven't installed the profiling libraries for package `parsec-3.1.0'?Use -v to see a list of the files searched for."
When I build the project without the "-prof -auto-all", the project compiles without any error or warning. I build GHC (6.10.4) from source, without changing any build option.
Thanks in advance for any help,
Rodrigo.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Profiling

2010-04-20 Thread Ivan Lazar Miljenovic
rodrigo.bonifacio rodrigo.bonifa...@uol.com.br writes:
 Could not find module `Text.ParserCombinators.Parsec.Language':
 Perhaps you haven't installed the profiling libraries for package 
 `parsec-3.1.0'?
 Use -v to see a list of the files searched for.

How did you install parsec?  You need to rebuild it with profiling
library support.  If you used cabal-install, you have two options:

1) set library-profiling to True in ~/.cabal/config and then
cabal install parsec --reinstall
2) cabal install parsec --reinstall --enable-library-profiling

 When I build the project without the -prof -auto-all, the project
 compiles without any error or warning. I build GHC (6.10.4) from
 source, without changing any build option.

This has nothing to do with GHC.

-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: GUI (was: Re: [Haskell-cafe] DLL on Windows)

2010-04-20 Thread Neil Mitchell
:-( - it seems that cabal install wx isn't how you install it on
Windows, not by a long shot.

I'm currently a Gtk2hs user. If wx got to the point where cabal
install wx either installed wx, including all it's non-Haskell
dependencies, or printed out a message you're a windows user who
hasn't installed wxWidgets, here's a handy url for you to click and
run then run cabal install wx again I'd be tempted to switch. I
realise that the platform differences makes it annoying, but it would
be generally handy for Windows users.

I do appreciate the work the wx people are doing for Windows users -
it is generally going in the right direction :-)

Thanks, Neil


On Mon, Apr 19, 2010 at 2:54 AM, Jeremy O'Donoghue
jeremy.odonog...@gmail.com wrote:
 On 18/04/2010, Daniel Fischer daniel.is.fisc...@web.de wrote:
 Am Sonntag 18 April 2010 21:41:06 schrieb Daniel Fischer:
 wx-config should have been installed as part of the wxWidgets package.
 Is that not included in the windows-installer of wxWidgets?

 Seems it's not so.
 http://www.haskell.org/haskellwiki/WxHaskell/Building says
 Windows users should also get the Windows port of wx-config.
 ( http://sites.google.com/site/wxconfig/

 Sadly, the Windows port of wxWidgets doesn't contain wx-config (all of
 the Unix variants have it - it's a shell script), which is a major
 problem as this by far the simplest way for the build system to work
 out the options used to build wxWidgets.

 The Windows port of wx-config is an attempt to fix this problem, but
 only currently supports gcc, hence the restriction to using MinGW
 (although I guess Cygwin would probably work).

  If wxHaskell could be installed with one cabal command that would be
  incredibly cool :-)

 Well, it's just one cabal command if you have all non-Haskell requirements
 installed as needed.

 An option I am looking at is creating a basic Windows installer for
 wxHaskell which would contain a compiled copy of wxWidgets and a copy
 of wx-config, and which would run cabal install wxWidgets out of the
 box. (basic here means you probably don't get to choose anything at
 all - not even where the wxWidgets libraries get installed)

 Provided that I don't need to maintain a source distribution, this
 might be a good way forward for some Windows users. The installer
 would be updated for 'significant' wxWidgets updates (you would be
 able to 'cabal install wx' at any time wxHaskell is updated once you
 have all of the libraries)

 Any interest - please let me know.

 Regards Jeremy
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Profiling

2010-04-20 Thread C K Kashyap
Hi Ivan,
I tried doing
 cabal install parsec = 3 --reinstall --enable-library-profiling
This complained about bytestring ... so I did this -
 cabal install bytestring --reinstall --enable-library-profiling
And this complained about base -
Data/ByteString.hs:278:7:
Could not find module `GHC.ST':
  Perhaps you haven't installed the profiling libraries for package
`base'?
  Use -v to see a list of the files searched for.
cabal: Error: some packages failed to install:
bytestring-0.9.1.5 failed during the building phase. The exception was:
exit: ExitFailure 1
[kash...@trinity318 ~]$ cabal install base --reinstall
--enable-library-profiling
Resolving dependencies...
cabal: internal error: impossible


Am I missing something?



On Tue, Apr 20, 2010 at 6:59 PM, Ivan Lazar Miljenovic 
ivan.miljeno...@gmail.com wrote:

 rodrigo.bonifacio rodrigo.bonifa...@uol.com.br writes:
  Could not find module `Text.ParserCombinators.Parsec.Language':
  Perhaps you haven't installed the profiling libraries for package
 `parsec-3.1.0'?
  Use -v to see a list of the files searched for.

 How did you install parsec?  You need to rebuild it with profiling
 library support.  If you used cabal-install, you have two options:

 1) set library-profiling to True in ~/.cabal/config and then
cabal install parsec --reinstall
 2) cabal install parsec --reinstall --enable-library-profiling

  When I build the project without the -prof -auto-all, the project
  compiles without any error or warning. I build GHC (6.10.4) from
  source, without changing any build option.

 This has nothing to do with GHC.

 --
 Ivan Lazar Miljenovic
 ivan.miljeno...@gmail.com
 IvanMiljenovic.wordpress.com
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe




-- 
Regards,
Kashyap
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: Asynchronous exception wormholes kill modularity

2010-04-20 Thread Isaac Dupree

On 04/20/10 06:56, Simon Marlow wrote:

On 09/04/2010 12:14, Bertram Felgenhauer wrote:

Simon Marlow wrote:

On 09/04/2010 09:40, Bertram Felgenhauer wrote:

timeout t io = mask $ \restore - do
result- newEmptyMVar
tid- forkIO $ restore (io= putMVar result)
threadDelay t `onException` killThread tid
killThread tid
tryTakeMVar result


I'm worried about the case when this function is called with exceptions
already blocked. Then 'restore' will be the identity, and exceptions
will continue to be blocked inside the forked thread.

You could argue that this is the responsibility of the whole chain of
callers (who'd have to supply their own 'restore' functions that will
have to be incorporated into the 'io' action), but that goes against
modularity. In my opinion there's a valid demand for an escape hatch
out of the blocked exception state for newly forked threads.

It could be baked into a variant of the forkIO primitive, say

forkIOwithUnblock :: ((IO a - IO a) - IO b) - IO ThreadId


I agree with the argument here. However, forkIOWithUnblock reintroduces
the wormhole, which is bad.

The existing System.Timeout.timeout does it the other way around: the
forked thread sleeps and then sends an exception to the main thread.
This version work if exceptions are masked, regardless of whether we
have forkIOWithUnblock.

Arguably the fact that System.Timeout.timeout uses an exception is a
visible part of its implementation: the caller must be prepared for
this, so it is not unreasonable for the caller to also ensure that
exceptions are unmasked. But it does mean that a library cannot use
System.Timeout.timeout invisibly as part of its implementation. If we
had forkIOWithUnblock that would solve this case too, as the library
code can use a private thread in which exceptions are unmasked. This is
quite a nice solution too, since a private ThreadId is not visible to
anyone else and hence cannot be the target of any unexpected exceptions.

So I think I'm convinced that forkIOWithUnblock is necessary. It's a
shame that it can be misused, but I don't see a way to avoid that.


[forkIOWithUnblock in the implementation of 'timeout'?] I thought that 
System.Timeout.timeout runs the IO in the original thread for a good 
reason.  Was it just so that it could receive asynchronous exceptions 
correctly? Or also so that myThreadID returned the correct value?  If 
just the former is what we're concerned about, we *could* make it behave 
differently when exceptions are unblocked vs. when it's uninterruptible, 
except that they can be restored to an unblocked state somewhere within 
the io.


[Oh wait, Simon was suggesting that the library should run 
forkIOWithUnblock as a wrapper to its use of 'timeout'.]  Yes, that 
sounds relatively safe.  None of the exceptions thrown to the original 
thread will be discharged unexpectedly as a result of this unblocking, 
because of the forkIO.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Profiling

2010-04-20 Thread Daniel Fischer
Am Dienstag 20 April 2010 18:59:23 schrieb C K Kashyap:
 Hi Ivan,
 I tried doing

  cabal install parsec = 3 --reinstall --enable-library-profiling

 This complained about bytestring ... so I did this -

  cabal install bytestring --reinstall --enable-library-profiling

 And this complained about base -
 Data/ByteString.hs:278:7:
 Could not find module `GHC.ST':
   Perhaps you haven't installed the profiling libraries for package
 `base'?
   Use -v to see a list of the files searched for.
 cabal: Error: some packages failed to install:
 bytestring-0.9.1.5 failed during the building phase. The exception was:
 exit: ExitFailure 1
 [kash...@trinity318 ~]$ cabal install base --reinstall
 --enable-library-profiling
 Resolving dependencies...
 cabal: internal error: impossible


 Am I missing something?

You cannot reinstall or upgrade core libs (basically, what comes with the 
compiler).
If your GHC came from a system package (and I think the binaries from the 
GHC page include profiling libs and they're built by default when building 
GHC from source, so you wouldn't have that problem), you probably don't 
have installed the package with the profiling libraries, something like

yum/apt-get install libghc??-prof

should get you the profiling libraries for base, bytestring and a few 
others, then
cabal install parsec = 3 --reinstall --enable-library-profiling
should work.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Bulk Synchronous Parallel

2010-04-20 Thread Jason Dusek
2010/04/19 Gregory Crosswhite gcr...@phys.washington.edu:
 Thanks for the link;  my ultimate interest, though, is in an architecture
 that could scale to multiple machines rather than multiple cores with shared
 memory on a single machine.  Has there been any interest and/or progress in
 making DPH run on multiple machines and other NUMA architectures?

  I wonder what it would take to do this.

  One approach is some compiler magic that provides you with an RTS
  that can communicate with other RTSen over TCP and chunks the computation
  appropriately. Or maybe you give it a chunk size and it gives you some
  number of executables that find one another using Bonjour. Values not on
  this node are found via some hashing scheme (the same scheme used to
  chunk in the first place).

  There is a lot to know about this problem area.

  It would be a great alternative to OpenMPI.

--
Jason Dusek
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Profiling

2010-04-20 Thread C K Kashyap
Thanks Daniel, that worked.


On Tue, Apr 20, 2010 at 11:24 PM, Daniel Fischer
daniel.is.fisc...@web.dewrote:

 Am Dienstag 20 April 2010 18:59:23 schrieb C K Kashyap:
  Hi Ivan,
  I tried doing
 
   cabal install parsec = 3 --reinstall --enable-library-profiling
 
  This complained about bytestring ... so I did this -
 
   cabal install bytestring --reinstall --enable-library-profiling
 
  And this complained about base -
  Data/ByteString.hs:278:7:
  Could not find module `GHC.ST':
Perhaps you haven't installed the profiling libraries for package
  `base'?
Use -v to see a list of the files searched for.
  cabal: Error: some packages failed to install:
  bytestring-0.9.1.5 failed during the building phase. The exception was:
  exit: ExitFailure 1
  [kash...@trinity318 ~]$ cabal install base --reinstall
  --enable-library-profiling
  Resolving dependencies...
  cabal: internal error: impossible
 
 
  Am I missing something?

 You cannot reinstall or upgrade core libs (basically, what comes with the
 compiler).
 If your GHC came from a system package (and I think the binaries from the
 GHC page include profiling libs and they're built by default when building
 GHC from source, so you wouldn't have that problem), you probably don't
 have installed the package with the profiling libraries, something like

 yum/apt-get install libghc??-prof

 should get you the profiling libraries for base, bytestring and a few
 others, then
 cabal install parsec = 3 --reinstall --enable-library-profiling
 should work.
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe




-- 
Regards,
Kashyap
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] ANNOUNCE: hamlet 0.0.0

2010-04-20 Thread Michael Snoyman
Hi all,

I'd like to announce the first release of Hamlet[1], a templating system
which is fully compile-time checked. Templates are parsed via quasi-quoting,
giving you greater confidence in the validity of your templates. The syntax
is inspired by Haml[2]; however, it is most definitely its own language,
avoiding embedding of arbitrary code in favor of a more strict view-logic
separation.

Finally, it has a goal of allowing high performance uses; to facilitate
this, it allows calling monadic code from inside the template, and can use
enumerators for traversing elements. While these features could be abused to
allow templates to perform unintended side-effects, the performance gains
allowed by them are sometimes essential.

I have started a documentation site for all Yesod-related packages[3], and
in particular there is a Hamlet section[4]. I've also put up a small blog
post[5] on this release, which explains how Hamlet fits into the Yesod
ecosystem. (For those not in the know, Yesod is a web framework I'm working
on.)

Michael

[1] http://hackage.haskell.org/package/hamlet-0.0.0
[2] http://haml-lang.com/
[3] http://docs.yesodweb.com/
[4] http://docs.yesodweb.com/hamlet/
[5] http://www.snoyman.com/blog/entry/hamlet-is-born/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] ANNOUNCE: Agata-0.2.0

2010-04-20 Thread Jonas Almström Duregård
Hi Neil and Sebastiaan,

Thanks for the constructive criticism ;).

As far as i can tell, derive only works for regular and linear
recursive types and Regular uses frequencies to regulate size. (Also
Regular doesn't seem to work for QuickCheck-2).

I think I may have used a too simple example in my original post. Here
is a more complicated one:

data TrinaryTree a =
Branch a (TrinaryTree a) (TrinaryTree a) (TrinaryTree a)
  | Empty deriving Show

$(agatath $ derive ''TrinaryTree)

With the derive tool, generated values would typically be infinite.

With Regular, the user would need to specify frequencies, and even
then the generator would be useless because of the low frequency
required for Branch to ensure termination (most generated trees
would be empty, and almost none would contain several branches).

Most of the work i have done on Agata is to make a class that
resembles arbitrary (i.e. can be used to construct generators) but
where the instances can be defined mechanically from the definition of
instantiated types. The reason i didn't use Generics for defining the
instances is that I was unsure if/how it distinguishes mutually
recursive fields.

Another feature of Agata generators is improved scalability compared
to other QuickCheck generators, especially for nested collection data
types (analog to a and such). The details of how this works in
Agata will one day be explained in the documentation, but the
principle is explained in my masters thesis[1].

Regards,
Jonas

[1] http://gupea.ub.gu.se/bitstream/2077/22087/1/gupea_2077_22087_1.pdf


2010/4/20 Sebastiaan Visser sfvis...@cs.uu.nl:
 Jonas,

 You can also derive (Co)Arbitrary instances automatically using the 
 regular-extras package based on the Regular generic programming library.

 The advantage of using a library like Regular is that you do not have to 
 write any Template Haskell code. The library generates a nice algebraic 
 generic view on your datatype that you can use to write your generic 
 functions. The Regular library itself of course uses TH internally, but this 
 is done once and all datatype generic functions can piggy bag on the same TH 
 derivation. For example, look at Generics.Regular.Functions.Arbitrary, this 
 module is really concise.

 Nice work though!

 Gr,
 Sebastiaan

 On Apr 18, 2010, at 1:43 AM, Jonas Almström Duregård wrote:
 I'm pleased to announce Agata (Agata Generates Algebraic Types 
 Automatically)!

 Avoiding excessive details, usage is best described by a small example:

 {-#LANGUAGE TemplateHaskell #-}
 import Test.QuickCheck
 import Test.AgataTH

 data X a b = X [Either a b] deriving Show
 data Y = Y deriving Show
 data Z = Z deriving Show

 $(agatath $ deriveall [''X,''Y,''Z])

 main = sample (arbitrary :: Gen (X Y Z))

 This code derives instances of Test.QuickCheck.Arbitrary for the data
 types X, Y and Z.

 http://hackage.haskell.org/package/Agata

 Regards Jonas


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Why does the transformers/mtl 'Error' class exist?

2010-04-20 Thread Ryan Ingram
On Sat, Apr 17, 2010 at 2:52 PM, Henning Thielemann
schlepp...@henning-thielemann.de wrote:
 Ryan Ingram schrieb:

 It's used in the implementation of fail for those monads.

 class Monad m where
   ...
   fail :: String - m a
   fail = error  -- default implementation

 which is then used to desugar do-notation when pattern matching fails:

    do
        Left x - something
        return x
 =
     something = \v - case v of { Left x - return x ; _ - fail
 Pattern match failure ... }

 You can argue about whether fail belongs in Monad (and many people
 have), but that's why it is how it is.


 I also prefered to not support the fail method in this way and wrote:
  http://hackage.haskell.org/packages/archive/explicit-exception/0.1.4/doc/html/Control-Monad-Exception-Synchronous.html

I find that having pattern match desugar to fail, and supporting
fail, can lead to extremely concise, clear code.

For example, an excerpt from some type checking/inference code I wrote:

data Equal a b = (a ~ b) = Refl

data Typ a where
   TInt :: Typ Int
   TBool :: Typ Bool
   TList :: Typ a - Typ [a]
   TArrow :: Typ a - Typ b - Typ (a - b)

eqT :: Typ a - Typ b - Maybe (Equal a b)
eqT TInt TInt = return Refl
eqT TBool TBool = return Refl
eqT (TList a) (TList b) = do
Refl - eqT a b
return Refl
eqT (TArrow a1 a2) (TArrow b1 b2) = do
Refl - eqT a1 b1
Refl - eqT a2 b2
return Refl
eqT _ _ = fail not equal

This relies heavily on the pattern match desugaring to case, which
brings the type equality (a ~ b) into scope, and fail returning
Nothing.  For example, the list case:

desugaring eqT (TList TInt) (TList TInt), with all operations on the
Maybe monad inlined and simplified

we have
   ta = TList TInt :: Typ a, tb :: TList TInt :: Typ b, for some a, b

eqT = case ta of
   ...
   (TList ta1) -
-- now we have a ~ [a1] for some a1
   case tb of
   ...
   (TList tb1) -
-- now we have b ~ [b1] for some b1
  case eqT ta1 tb1 of
   Just Refl -
-- now we have a1 ~ b1, which gives us [a1] ~ [b1], which gives us a ~ b
Just Refl
   _ - Nothing

  -- ryan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] what does the '~' mean ?

2010-04-20 Thread Ryan Ingram
On Thu, Apr 15, 2010 at 10:59 PM, zaxis z_a...@163.com wrote:

 instance (BinaryDefer a, BinaryDefer b) = BinaryDefer (a,b) where
    put (a,b) = put2 a b
    get = get2 (,)
    size x = let ~(a,b) = x in size a + size b
    putFixed (a,b) = putFixed2 a b
    getFixed = getFixed2 (,)

 in `size` function, what does the `~` mean ?

This is kind of a funny question, because in this case the ~ doesn't
mean anything at all.  Pattern matches in let are automatically
irrefutable/lazy.

A better way to write this is

size ~(a,b) = size a + size b

which is equivalent to

size x = size a + size b where
   (a,b) = x

which is equivalent to

size x = let (a,b) = x in size a + size b

which is equivalent to

size x = let
a = case x of (v,_) - v
b = case x of (_,v) - v
  in size a + size b

If a or b never get evaluated, the case statements (which will fail on
bottom values) don't happen.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] C variable access via FFI

2010-04-20 Thread John Meacham
On Tue, Apr 20, 2010 at 01:48:16AM -0500, Tom Hawkins wrote:
 I have a bunch of global variables in C I would like to directly read
 and write from Haskell.  Is this possible with FFI, or must I write a
 bunch of C wrapper functions for the interface, i.e. a 'get' and a
 'set' for each variable?

Yup. 

foo.c:
  int my_int;

Foo.hs:

foreign import my_int my_int_ptr :: Ptr Int

foo = do
poke my_int_ptr 4
x - peek my_int_Ptr


John

-- 
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] ANN: forkable-monad 0.1

2010-04-20 Thread David Anderson
Dear Haskellers,

I'm happy, and only slightly intimidated, to announce the initial
release of forkable-monad.

The short version is that forkable-monad exports a replacement forkIO
that lets you do this:

type MyMonad = ReaderT Config (StateT Ctx IO)

startThread :: MyMonad ThreadId
startThread = forkIO threadMain

threadMain :: MyMonad ()
threadMain = forever $ liftIO $ putStrLn Painless monad stack forking!

Note the lack of monad stack deconstruction and reconstruction to
transport it over to the new thread. You'll find the details in the
Haddock documentation for the module.

forkable-monad is available:

* On hackage: http://hackage.haskell.org/package/forkable-monad
* Via cabal: cabal install forkable-monad
* Source and issue tracker: http://code.google.com/p/forkable-monad/

Feedback is of course welcome. As this is my first published Haskell
code and Hackage upload, I expect there will be quite a bit!

- Dave
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Re: Re: instance Eq (a - b)

2010-04-20 Thread Edward Kmett
I don't mind the 0.0 == -0.0 case, its the NaN /= NaN one that gets me. ;)

The former just says that the equivalence relation you are using isn't
structural. The latter breaks the notion that you have an equivalence
relation by breaking reflexivity.

Eq doesn't state anywhere that the instances should be structural, though in
general where possible it is a good idea, since you don't have to worry
about whether or not functions respect your choice of setoid.

Ultimately, I find myself having to play a bit unsafe with lazy bytestrings
more often than I'd like to admit. Use of toChunks should always be careful
to be safe to work regardless of the size of the chunks exposed, and can
also rely on the extra-logical fact enforced by the bytestring internals
that each such chunk is non-empty.

It greatly facilitates 'lifting' algorithms that work over strict
bytestrings to work over their lazy kin, and its omission would deal a
terrible blow to the practical usability and efficiency of the bytestring
library. I frankly would be forced to reimplement them from scratch in
several packages were it gone.

Ultimately, almost any libraries relies on a contract that extends beyond
the level of the type system to ensure they are used them correctly. A
malformed 'Ord' instance can wreak havoc with Set, a non-associative
'Monoid' can leak structural information out of a FingerTree.

Similarly, the pleasant fiction that x == y == f x == f y -- only holds if
the Eq instance is structural, and toChunks can only 'safely' be used in a
manner that is oblivious to the structural partitioning of the lazy
bytestring.

-Edward Kmett

On Mon, Apr 19, 2010 at 6:02 PM, Ashley Yakeley ash...@semantic.org wrote:

  Why is a function that gets a bunch of strict ByteStrings out of a lazy
 one exposed?

 In any case, it sounds like a similar situation to (==) on Float and
 Double. There's a mismatch between the Haskellish desire for a law on
 (==), and the convenient desire for -0.0 == 0.0, or for exposing toChunks.
 Which one you prefer depends on your attitude. My point is not so much to
 advocate for the Haskellish viewpoint than to recognise the tension in the
 design. Float and Double are pretty ugly anyway from a Haskell point of
 view, since they break a bunch of other desirable properties for (+), (-)
 and so on.

 The theoretical reason for using floating point rather than fixed point is
 when one needs relative precision over a range of scales: for other needs
 one should use fixed point or rationals. I added a Fixed type to base, but
 it doesn't implement the functions in the Floating class and I doubt it's as
 fast as Double for common arithmetic functions.

 It would be possible to represent the IEEE types in a Haskellish way,
 properly revealing all their ugliness. This would be gratifying for us
 purists, but would annoy those just trying to get some numeric calculations
 done.

 --
 Ashley Yakeley



 On Mon, 2010-04-19 at 15:32 -0400, Edward Kmett wrote:

 Because it is the most utilitarian way to get a bunch of strict ByteStrings
 out of a lazy one.

 Yes it exposes an implementation detail, but the alternatives involve an
 unnatural amount of copying.

 -Edward Kmett

  On Sat, Apr 17, 2010 at 6:37 PM, Ashley Yakeley ash...@semantic.org
 wrote:

  Ketil Malde wrote:

 Do we also want to modify equality for lazy bytestrings, where equality
 is currently independent of chunk segmentation?  (I.e.

  toChunks s1 == toChunks s2 == s1 == s2
 but not vice versa.)



   Why is toChunks exposed?

 --
 Ashley Yakeley



 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe


 ___
 Haskell-Cafe mailing 
 listhaskell-c...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: Move MonadIO to base

2010-04-20 Thread Anders Kaseorg
On Tue, 20 Apr 2010, wren ng thornton wrote:
 -- | The isomorphic Haskell98 version
 class Monad m = MonadJoinIO m where 
 -- | Embed the IO into the monad m
 joinIO :: IO (m a) - m a
 
 -- | Extract the IO computation to the top level,
 -- rendering the m pure from IO.
 partIO :: m a - IO (m a)
 
 -- | The isomorphisms
 joinIO'  m = morphIO (m =)
 morphIO' f = joinIO (f partIO)

To establish an isomorphism, you also need to define partIO from morphIO. 
For example, I don’t see how I could define
  partIO :: IO a - IO (ReaderT r IO a)
that extracts effects into the outer IO, because the effects depend on 
some unknown state of type r.

By the way:

 This bounced because I have different emails registered for cafe@ and 
 libraries@, so forwarding it along to the cafe.

You can sign up both addresses for the list, then log in to the Mailman 
web interface ( http://www.haskell.org/mailman/listinfo/haskell-cafe → 
Unsubscribe or edit options) and disable mail delivery on one of them.  
Then you get one copy of each message but you can post from either 
address.

Anders
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Bulk Synchronous Parallel

2010-04-20 Thread Alexander Solla


On Apr 20, 2010, at 11:05 AM, Jason Dusek wrote:

Thanks for the link;  my ultimate interest, though, is in an  
architecture
that could scale to multiple machines rather than multiple cores  
with shared
memory on a single machine.  Has there been any interest and/or  
progress in

making DPH run on multiple machines and other NUMA architectures?


 I wonder what it would take to do this.


Erlang.  ;0)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe