Re: [Haskell-cafe] ordNub

[Anthony Cowley]

On Oct 12, 2013, at 2:47 PM, Niklas Hambüchen  wrote:
> 
> I would like to come back to the original question:
> 
> How can ordNub be added to base?
> 
> I guess we agree that Data.List is the right module for a function of
> type Ord a => [a] -> [a], but this introduces
> 
> * a cyclic dependency between Data.List and Data.Set
> * a base dependency on containers.
> 
> What is the right way to go with that?
> 
> Should ordNub be introduced as part of Data.Set, as Conrad suggested?
> 
> It does not really have anything to do with Set, apart from being
> implemented with it.

I think nub's behavior is rather set-related, so I don't really understand the 
objection to putting it in Data.Set.

Anthony

> 
>> On 14/07/13 14:12, Roman Cheplyaka wrote:
>> Something like that should definitely be included in Data.List.
>> Thanks for working on it.
>> 
>> Roman
> ___
> 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] [ANN] New OpenCV Bindings

[Anthony Cowley]

To be clear, I am not the maintainer of HOpenCV. I have used a fork of that 
library for experimenting with OpenCV interfaces over the past few years, and 
written quite a few kloc using it in several robotics oriented projects with 
computer vision needs. None of my experiments with HOpenCV are on hackage as 
they are experiments, but I have helped others get started with them over time. 

I am totally supportive of Arjun's new efforts: OpenCV has changed a lot, and 
there is reason to be optimistic that he will be able to provide a much better 
foundation for Haskell bindings than we have ever had. As the low level 
bindings come online, we will be able to introduce some of the extra 
type-driven code paths and static checks that have proven successful in the 
existing fragmented Haskell-OpenCV ecosystem.

Anthony

> On Sep 28, 2013, at 2:31 PM, Arjun Comar  wrote:
> 
> I've been talking to Anthony Cowley who I think is the current maintainer of 
> HOpenCV and Ville Tirronen who has been developing the CV bindings. Basically 
> the consensus is that these raw bindings provide a new base to work from, and 
> it's worthwhile to rethink the API we provide with a fresh start.
> 
> 
>> On Sat, Sep 28, 2013 at 2:23 PM, Ivan Perez  
>> wrote:
>> The people working on HOpenCV are very open to incorporating other's 
>> programmer's patches. Maybe you can incorporate your changes to 
>> cv-combinators? (Project's been halted since 2010, I'm sure they'll be very 
>> happy to see that sb is contributing).
>> 
>> 
>>> On 28 September 2013 19:13, Arjun Comar  wrote:
>>> Fair enough, it's been two or three years since I tried to play with them. 
>>> Most of my work is in the raw bindings currently, which provide the C++ API 
>>> in Haskell, so much lower level that cv-combinators. If HOpenCV were to 
>>> incorporate parts of these bindings then cv-combinators would be able to 
>>> benefit from this work. That said, my effort going forward is to provide 
>>> something equivalent to cv-combinators in expressiveness. I'm definitely 
>>> taking inspiration from the library though I'm not basing my work on their 
>>> source code.
>>> 
>>> 
>>>> On Sat, Sep 28, 2013 at 12:51 PM, Ivan Perez 
>>>>  wrote:
>>>> I think they do work. cv-combinators depends on HOpenCV, which depends on 
>>>> OpenCV 2.0.
>>>> 
>>>> 
>>>> 
>>>>> On 28 September 2013 16:03, Arjun Comar  wrote:
>>>>> No, these are unrelated. Cv-combinators hasn't really worked since OpenCV 
>>>>> 2.0 waa released I believe.
>>>>> 
>>>>>> On Sep 28, 2013 8:54 AM, "Ivan Perez"  
>>>>>> wrote:
>>>>>> Cool. Thanks a lot for uploading this.
>>>>>> 
>>>>>> I have a question (and I confess that I haven't checked the link). How 
>>>>>> is this related to or overlaps with cv-combinators?
>>>>>> 
>>>>>> Cheers
>>>>>> Ivan
>>>>>> 
>>>>>> 
>>>>>>> On 28 September 2013 06:18, Arjun Comar  wrote:
>>>>>>> After receiving feedback, I went ahead and split out the raw C wrappers 
>>>>>>> and Haskell bindings. You can find them at 
>>>>>>> www.github.com/arjuncomar/opencv-raw. I'll upload it to hackage as 
>>>>>>> opencv-raw once I have uploader privileges.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Arjun
>>>>>>> 
>>>>>>> 
>>>>>>>> On Fri, Sep 27, 2013 at 4:09 PM, Arjun Comar  wrote:
>>>>>>>> Hi all,
>>>>>>>> I've been hard at work on a new set of OpenCV bindings that will 
>>>>>>>> hopefully solve a lot of the shortcomings with previous attempts. An 
>>>>>>>> automatic header parser has been used to generate a full set of 
>>>>>>>> Haskell bindings for the C++ API, and I'm now working to create a 
>>>>>>>> pleasant Haskell API. The plan is to expose major functionality 
>>>>>>>> through pipes for two reasons: 1) OpenCV is not very referentially 
>>>>>>>> transparent, and so you're stuck in IO for anything non-trivial. Lazy 
>>>>>>>> IO is potentially problematic, and so immediate incorporation of a 
>>>>>>>> proper

Re: [Haskell-cafe] OS X ghci problem

[Anthony Cowley]

On Jul 13, 2013, at 8:04 PM, Jason Dagit  wrote:

> On Sat, Jul 13, 2013 at 4:39 PM, Mark Lentczner
>  wrote:
>> Bizarre - this just happened to me today, too. Anyone? Did you figure out a
>> work around? For the record, I'm trying to bring Euterpea up.
> 
> After some digging, experimenting, asking around, and head scratching
> my best guesses are:
> 
>  * GHCi's custom linker isn't doing the right thing (some versions of
> llvm/clang gave crashes like this and it was a linker bug for them,
> you can find reports on sites like StackOverflow).
>  * We need to feed .m files to clang instead of ghc/gcc
>  * GHCi needs to be built with Cocoa in mind (is it already?)
>  * Some rts component of objective-c is not properly initialized (ARC
> vs. -fobjc-gc vs. -fnext-step, etc)
> 
>> 
>> My system is OS X 10.8.4, and I'm running HP 2013.2, so 7.6.3. And
>> GLFW-0.5.1.0.
> 
> In terms of experimentation, you can hand desugar the objective-c code
> in the GLFW init and when I do that I get segfaults. Also, the address
> mentioned in the objective-c exception has a suspicious value, which
> would further implicate the linker. Add to that, it works for a
> compile program (which uses the system linker, IIRC).
> 
> Basically, I'm pretty sure it's GHCi's linker to blame here but I
> don't have a smoking gun.
> 
> Jason

I thought I'd had some success desugaring the Objective-C code, but I never 
went the whole way, so perhaps I just didn't get to the segfault. What I do for 
GLFW is use a dylib, then you don't rely on GHCi's static-ish linker. The only 
wrinkle is figuring out where you want the dylib. I think homebrew will put one 
in /usr/local/lib, which works out nicely, but they don't have GLFW 3 yet. 
Another option is to build the dylib yourself from the GLFW source bundled with 
the GLFW-b package, then tell cabal where to find it.

It's worth the trouble, as having a GHCi-based workflow for graphics work is 
wonderful. A fancy Setup.hs that works out installation paths could generate 
the dylib, and I thought such code existed in the past. Was some problem found 
with that approach?

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

Re: [Haskell-cafe] What symbol / atom/ interned-string package is currently preferred?

[Anthony Cowley]

On Tue, May 7, 2013 at 2:58 PM, Ryan Newton  wrote:
> Hi cafe,
>
> I use symbols all the time when manipulating code.  I vacillate between
> using stringtable-atom, symbol, and simple-atom.  Unfortunately:
>
> Stringtable-atom is has a broken build right now (GHC 7.6).  (Also I've had
> some crashes with it in the past.)
> simple-atom has dependency upper bounds that restrict it to GHC <= 7.0
> "symbol" has a design flaw, which is that it exposes the constructor for
> Symbol, which reveals the (nondeterministic) unique Int IDs.  I.e. it is not
> "SafeHaskell".
>
> I submitted a pull request to relax simple-atom, but perhaps there are other
> packages people use with which I am not aware?
>
> Thanks,
>   -Ryan

This package is current and maintained:

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

Anthony

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

Re: [Haskell-cafe] GPGPU

[Anthony Cowley]

On Sat, May 4, 2013 at 3:17 PM, Jason Dagit  wrote:
> On Sat, May 4, 2013 at 11:54 AM, Anthony Cowley  
> wrote:
>> I wrote this some time ago.
>>
>> http://www.arcadianvisions.com/blog/?p=346
>>
>> I know that soon after I wrote that, it worked with both OpenCL and gloss
>> from hackage, but there may be some bitrot at this point.
>
> Some of the links in the blog seem to be broken as well. For instance,
> the link to the animation screen shot.
>
> Jason

Thanks to the nudge from Jason, the bitrot has now been scraped off.
The post is prettier, the code all works again, and the screenshot has
been restored.

Anthony

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

Re: [Haskell-cafe] GPGPU

[Anthony Cowley]

I wrote this some time ago. 

http://www.arcadianvisions.com/blog/?p=346

I know that soon after I wrote that, it worked with both OpenCL and gloss from 
hackage, but there may be some bitrot at this point.

Anthony

On May 4, 2013, at 6:00 AM, Christopher Howard 
 wrote:

> Has anybody on the list been playing around with OpenCL at all? I'm just
> starting to look into it - need to get a newer Radeon card, I think -
> but I'm strongly interested in GPGPU programming.
> 
> -- 
> frigidcode.com
> 
> ___
> 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] data types with overlapping component names (in one module)?

[Anthony Cowley]

On Tue, Apr 16, 2013 at 4:05 PM, Sturdy, Ian  wrote:
> 'vinyl' uses type-level literal strings and is very slick (although all 
> fields with the same name have the same type)

This is not entirely true, depending on what you mean by "name". The
following is just fine. You only have naming issues if you want to
give @Field::"baz":::Int@ a name, that name is, unsurprisingly, tied
to the field type of Int.

{-# LANGUAGE DataKinds, TypeOperators #-}
import Data.Vinyl

type Foo = '["baz" ::: Int]
type Bar = '["baz" ::: String]

x :: PlainRec Foo
x = Field =: 2

y :: PlainRec Bar
y = Field =: "Two"


Anthony

>
> -IRS
> 
> From: haskell-cafe-boun...@haskell.org [haskell-cafe-boun...@haskell.org] on 
> behalf of Johannes Waldmann [waldm...@imn.htwk-leipzig.de]
> Sent: Tuesday, April 16, 2013 8:17 AM
> To: haskell-cafe@haskell.org
> Subject: [Haskell-cafe] data types with overlapping component names (in one   
>   module)?
>
> What is the current situation: can we have two types
> with overlapping component names in one module?
>
> module M where
> data T1 = C1 { foo :: Int }
> data T2 = C2 { foo :: String }
>
> It seems not (ghc says: Multiple declarations of 'foo'). This comes close:
> http://www.haskell.org/ghc/docs/7.6.2/html/users_guide/syntax-extns.html#disambiguate-fields
> but still requires the definitions to reside in different modules?
>
> This is a major pain (it forces me to spread the source over several files),
> and also a show-stopper when selling Haskell to OO folks, who "naturally"
> assume that a class also denotes a scope. (And that you could nest them.)
>
> Are/were there plans/proposals to address this?
>
> - J.W.
>
>
>
> ___
> 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

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

Re: [Haskell-cafe] Overloading

[Anthony Cowley]

On Mar 9, 2013, at 3:33 PM, Peter Caspers  wrote:

> Hi,
> 
> I just started playing around a bit with Haskell, so sorry in advance for 
> very basic (and maybe stupid) questions. Coming from the C++ world one thing 
> I would like to do is overloading operators. For example I want to write 
> (Date 6 6 1973) + (Period 2 Months) for some self defined types Date and 
> Period. Another example would be (Period 1 Years) + (Period 3 Months).
> 
> So maybe make the types instances of typeclasses? This would be Num for (+) I 
> guess. For the first example above it will not work however, alone for it is 
> not of type a -> a -> a. Also the second example does not fit, because I 
> would have to make Period an instance of Num, which does not make sense, 
> because I can not multiply Periods (for example).
> 
> Am I missing something or is that what I am trying here just impossible by 
> the language design (and then probably for a good reason) ?

Take a look at affine spaces and additive groups in the vector-space package. 
There may be other treatments of torsors on hackage, but vector-space has a 
fairly straightforward approach.

> A second question concerns the constructors in own datatypes like Date above. 
> Is it possible to restrict the construction of objects to sensible inputs, 
> i.e. reject something like Date 50 23 2013 ? My workaround would be to 
> provide a function say
> 
> date :: Int->Int->Int->Date
> 
> checking the input and returning a Date object or throw an error if the input 
> does not correspond to a real date. I could then hide the Date constructor 
> itself (by not exporting it). However this seems not really elegant. Also 
> again, taking this way I can not provide several constructors taking inputs 
> of different types, can I ?

This approach -- hiding data constructors and exporting functions that perform 
validation -- is called "smart constructors," and is accepted practice. It 
isn't entirely satisfying due to interfering with pattern matching in client 
code, so you either need to work with projection functions for your data type, 
or use ViewPatterns to provide a more transparent record type at use sites.

Anthony


> 
> Thanks a lot
> Peter
> 
> 
> ___
> 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] Roshask

[Anthony Cowley]

I know that it probably needs updating for Groovy. I don't think it
has many users, which makes it more challenging to keep things running
smoothly, but I'm willing to help any interested parties get it up and
running.

Anthony

On Fri, Jan 11, 2013 at 4:37 PM, Tijn van der Zant  wrote:
> Hi,
>
> I want to use Haskell to program my robot using ros. I've found roshask
> https://github.com/acowley/roshask
> and I was wondering if someone on this list has experience with it and can
> tell me how good it is.
> Thanx!
>
> --Tijn
>
>
> ___
> 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] Can't prevent memoizing in simple code

[Anthony Cowley]

On May 16, 2012, at 12:08 PM, Yves Parès wrote:

> The buffer http://hpaste.org/68595 presents a simple code I tried to profile.
> I spotted what I strongly think to be an abusive memoization. The problem is 
> that I don't see how to (simply) get rid of it.
> Compiled with -O2, it consumes 130MB of memory, however lines A and B 
> executed separately consume each only 1MB.
> 
> The infinite list (l 1), whatever I do, keeps being shared between lines A 
> and B.
> I tried to wrap it in a function, as you can see, I also tried to make it 
> explicitely polymorphic (bypassing monomorphic restriction), nothing solves 
> it, GHC is just to good at memoizing.

Adding a {-# NOINLINE l #-} annotation helps here. Syntactically, it must be 
located somewhere a type signature for l would also be valid.

Anthony

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

Re: [Haskell-cafe] Haskell integration with C/C++ (GSOC)

[Anthony Cowley]

On Thursday, April 5, 2012 at 1:53 AM, Sutherland, Julian wrote:
> Hey Guys,
> 
> I'm Julian, I am reaching the end of my second year as a JMC (Joint 
> Mathematics and Computer science) Student at Imperial College London
> and I'd like to apply to GSOC for a project involving Haskell and I just 
> wanted to run my idea past the community.

[snip] 
> I found an example of such a bug, which I will test further before reporting 
> it.
> It seems to be the opposite of the following bug:
> http://hackage.haskell.org/trac/ghc/ticket/5594
> 
> i.e. the stdout buffer isn't always correctly flushed when calling C/C++ in a 
> program whose main is written in Haskell.
> 
> For example, when running the code:
> 
> main.hs:
> module Main where
> 
> import Foreign.C.Types
> import System.IO
> 
> foreign import ccall "inc" c_inc :: CInt -> CInt
> 
> main :: IO ()
> main = do
> putStr "Enter n: " 
> -- hFlush stdout
> s <-getLine
> putStrLn . show . c_inc . read $ s
> 
> inc.c:
> 
> int inc(int i) __attribute__ ((const));
> 
> int inc(int i)
> {
> return i + 1;
> }
> 
> Built with
> Makefile:
> all: 
> gcc -c -o inc.o inc.c
> ghc --make -main-is Main main.hs inc.o -o test
> rm *.hi *.o
> 
> The output comes out as:
> [julek@cryptid inc]$ ./test 
> 2
> Enter n: 3
> 
> But when the " hFlush stdout" line is commented back in, the output is:
> [julek@cryptid inc]$ ./test 
> Enter n: 2
> 3
> 
> which is correct, but the extra line shouldn't be necessary.
> 
> I am currently using ghc 7.4.1 which is the newest version, so this is a 
> current bug.

I think this is a consequence of line buffering rather than a bug. If you write 
your own increment function in Haskell, you get the same behavior. If you 
`hSetBuffering stdout NoBuffering` before your `putStr` call, you should get 
the behavior you wanted. I've seen similar issues with programs written in many 
languages; it's just one of those gotchas to be aware of when dealing with 
console UI.

As to the rest of your proposal, when you started out talking about calling 
Haskell from C or C++, I hoped you would focus on the pain of linking the final 
executable. This seems to me a more fundamental -- and addressable -- stumbling 
block than the richness of interaction with C++. As things stand, it is quite a 
hassle to use a Haskell library of any complexity called from C. Improved 
interaction with C++ could indeed be valuable, but, unless something has 
changed recently, work is still needed to improve the more basic C -> Haskell 
FFI story.

Anthony

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

Re: [Haskell-cafe] Trying to use more than one array in runSTUArray

[Anthony Cowley]

On Thursday, March 15, 2012 at 2:27 PM, Juan Miguel Vilar wrote:
> Hello, café:
>  
> I am trying to use more than one array with runSTUArray but I don't seem
> to be able to understand how it works. My first try is this:
>  
> test1 n = runSTUArray $ do
> a <- newArray (1, n) (2::Int)
> b <- newArray (1, n) (3::Int)
> forM_ [1..n] $ \i -> do
> v <- readArray a i
> writeArray b i (v+1)
> return b
>  
> but it does not work. However, when I write

The problem is that GHC doesn't know what type of array a is. If you provide an 
annotation, you can resolve the ambiguity:

a <- newArray (1,n) (2::Int) :: ST s (STUArray s Int Int)

However, this is somewhat ugly, so we should look at your next example:
  
>  
> test2 n = runSTUArray $ do
> let createArray v n = newArray (1, n) (v::Int)
> a <- createArray 2 n
> b <- createArray 0 n
> forM_ [1..n] $ \i -> do
> v <- readArray a i
> writeArray b i (v+1)
> return b
>  
>  


Note that the type of the b array was never in doubt thanks to runSTUArray. 
What you've done here is said that the same function that creates b also 
creates a, and since we know b's type, we now know a's type because GHC doesn't 
make createArray's type as polymorphic as it might.

Another approach to resolving the types is to essentially do what you've done 
in your second example, but give createArray a type that is as polymorphic as 
you need:

{-# LANGUAGE FlexibleContexts #-}

newSTUArray :: (MArray (STUArray s) e (ST s), Ix i) =>  
   (i,i) -> e -> ST s (STUArray s i e)
newSTUArray = newArray

test3 n = runSTUArray $ do
a <- newSTUArray (1, n) False
b <- newSTUArray (1, n) (3::Int)
forM_ [1..n] $ \i -> do
  v <- readArray a i
  writeArray b i (fromEnum v+1)
return b


I hope that helps clear things up. The issue to be aware of, particularly with 
the Array types, is just how polymorphic the interfaces you rely upon are. The 
best approach to figuring these problems out is to add type annotations to see 
where your intuition diverged from the type checker's reality.

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

Re: [Haskell-cafe] Understanding GC time

[Anthony Cowley]

>From that profiling data, I think you're just seeing a decrease in sharing. 
>With one thread, you create the list structure in memory: the first fold could 
>consume it in-place, but the second fold is still waiting for its turn.  The 
>list is built on the heap so the two folds can both refer to the same list. 

With two threads, GHC is being clever and inlining the definition you give for 
list, which is then optimized into two parallel loops. No list on the heap 
means there's not much for the GC to do.

Sharing of index lists like this is a common source of problems. In particular, 
nested loops can make it even trickier to prevent sharing as there may not be 
an opportunity for parallel evaluation.

Anthony

On Mar 10, 2012, at 10:21 AM, Thiago Negri  wrote:

> Hi all.
> 
> I wrote a very simple program to try out parallel Haskel and check how
> it would look like to make use of more than one core in this language.
> 
> When I tried the program with RTS option -N1, total time shows it took
> 2.48 seconds to complete and around 65% of that time was taken by GC.
> 
> Then I tried the same program with RTS options -N2 and total time
> decreased to 1.15 seconds as I expected a gain here. But what I didn't
> expect is the GC time to drop to 0%.
> 
> I guess I'm having trouble to understand the output of the RTS option -s.
> Can you enlighten me?
> 
> 
> The source for the testing program:
> 
>> module Main where
>> 
>> import Data.List (foldl1')
>> import Control.Parallel (par, pseq)
>> import Control.Arrow ((&&&))
>> 
>> f `parApp` (a, b) = a `par` (b `pseq` (f a b))
>> seqApp = uncurry
>> 
>> main = print result
>>  where result = (+) `parApp` minMax list
>>minMax = minlist &&& maxlist
>>minlist = foldl1' min
>>maxlist = foldl1' max
>>list = [1..1999]
> 
> 
> The results on a Windows 7 64bits with an Intel Core 2 Duo, compiled
> with GHC from Haskell Platform:
> 
> c:\tmp\hs>par +RTS -s -N1
> par +RTS -s -N1
> 2000
> 803,186,152 bytes allocated in the heap
> 859,916,960 bytes copied during GC
> 233,465,740 bytes maximum residency (10 sample(s))
>  30,065,860 bytes maximum slop
> 483 MB total memory in use (0 MB lost due to fragmentation)
> 
>  Generation 0:  1523 collections, 0 parallel,  0.80s,  0.75s elapsed
>  Generation 1:10 collections, 0 parallel,  0.83s,  0.99s elapsed
> 
>  Parallel GC work balance: nan (0 / 0, ideal 1)
> 
>MUT time (elapsed)   GC time  (elapsed)
>  Task  0 (worker) :0.00s(  0.90s)   0.00s(  0.06s)
>  Task  1 (worker) :0.00s(  0.90s)   0.00s(  0.00s)
>  Task  2 (bound)  :0.86s(  0.90s)   1.62s(  1.69s)
> 
>  SPARKS: 1 (0 converted, 0 pruned)
> 
>  INIT  time0.00s  (  0.00s elapsed)
>  MUT   time0.86s  (  0.90s elapsed)
>  GCtime1.62s  (  1.74s elapsed)
>  EXIT  time0.00s  (  0.00s elapsed)
>  Total time2.48s  (  2.65s elapsed)
> 
>  %GC time  65.4%  (65.9% elapsed)
> 
>  Alloc rate936,110,032 bytes per MUT second
> 
>  Productivity  34.6% of total user, 32.4% of total elapsed
> 
> gc_alloc_block_sync: 0
> whitehole_spin: 0
> gen[0].sync_large_objects: 0
> gen[1].sync_large_objects: 0
> 
> 
> c:\tmp\hs>par +RTS -s -N2
> par +RTS -s -N2
> 2000
>   1,606,279,644 bytes allocated in the heap
>  74,924 bytes copied during GC
>  28,340 bytes maximum residency (1 sample(s))
>  29,004 bytes maximum slop
>   2 MB total memory in use (0 MB lost due to fragmentation)
> 
>  Generation 0:  1566 collections,  1565 parallel,  0.00s,  0.01s elapsed
>  Generation 1: 1 collections, 1 parallel,  0.00s,  0.00s elapsed
> 
>  Parallel GC work balance: 1.78 (15495 / 8703, ideal 2)
> 
>MUT time (elapsed)   GC time  (elapsed)
>  Task  0 (worker) :0.00s(  0.59s)   0.00s(  0.00s)
>  Task  1 (worker) :0.58s(  0.59s)   0.00s(  0.01s)
>  Task  2 (bound)  :0.58s(  0.59s)   0.00s(  0.00s)
>  Task  3 (worker) :0.00s(  0.59s)   0.00s(  0.00s)
> 
>  SPARKS: 1 (1 converted, 0 pruned)
> 
>  INIT  time0.00s  (  0.00s elapsed)
>  MUT   time1.15s  (  0.59s elapsed)
>  GCtime0.00s  (  0.01s elapsed)
>  EXIT  time0.00s  (  0.00s elapsed)
>  Total time1.15s  (  0.61s elapsed)
> 
>  %GC time   0.0%  (2.4% elapsed)
> 
>  Alloc rate1,391,432,695 bytes per MUT second
> 
>  Productivity 100.0% of total user, 190.3% of total elapsed
> 
> gc_alloc_block_sync: 90
> whitehole_spin: 0
> gen[0].sync_large_objects: 0
> gen[1].sync_large_objects: 0
> 
> ___
> 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] The (!) operation

[Anthony Cowley]

On Thu, Mar 8, 2012 at 11:19 AM, Christopher Done
 wrote:
> ‘Ello.
>
> Is there a generalization of this operator? It's all over the place,
> it's basically
>
>    (!) :: (Monad m, Indexed collection index value) => index ->
> container -> m value
>
> We have `(!!)` on lists, `(!)` on maps, vectors, json objects, …
> (doesn't seem there's one for bytestring)
>
> (Though I seem to recall the monadic return value being frowned upon
> but I don't recall why.)
>
> Thoughts?

Perhaps Data.Key meets your needs?

http://hackage.haskell.org/packages/archive/keys/2.1.2/doc/html/Data-Key.html

Anthony

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

Re: [Haskell-cafe] Vector (or List) to CArray?

[Anthony Cowley]

On Thu, Jan 19, 2012 at 1:15 PM, Dominic Espinosa  wrote:
> Hello,
>
> I'm trying to use the fftw binding, and its functions operate on CArrays of
> Complex. My data is coming from hsndfile, so it starts out as a Vector of
> Double. How do I convert this data to CArray? The API functions in the
> CArray module don't seem to indicate how.
>
> Thanks.

I've not tried this, but I would expect to be able to use
, and then
use the ForeignPtr that lives inside the Vector the to build a CArray.

Anthony

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

Re: [Haskell-cafe] haxr standalone server?

[Anthony Cowley]

On Thu, Jan 5, 2012 at 10:40 AM, Johannes Waldmann
 wrote:
> How could I use haxr (http://www.haskell.org/haskellwiki/HaXR)
> to build a stateful server?
>
> It should listen on some port,
> and fork threads (inside Haskell land) to handle incoming calls.
> Any of the Haskell web frameworks can do this?

I use HaXR in conjunction with Snap. It basically boils down to using
Network.XmlRpc.Server (handleCall, methods) in conjunction with Snap's
getRequestBody and writeLBS.

The good news is you don't need to worry about forking your own
threads, the web server handles that. To make calls stateful, you just
stash away a reference in the handler you give Snap (or whatever web
server you use).

Anthony

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

Re: [Haskell-cafe] Alternative versus Monoid

[Anthony Cowley]

On Dec 15, 2011, at 10:19 AM, Brent Yorgey wrote:

> On Thu, Dec 15, 2011 at 06:49:13PM +1000, Gregory Crosswhite wrote:
>> 
>> So at the end of the day... what is the point of even making Maybe and [] 
>> instances of Alternative?
> 
> The Alternative and Monoid instances for [] are equivalent.  However,
> the Alternative and Monoid instances for Maybe are not. To wit:
> 
>> (Just (Sum  4)) <|> (Just (Sum 3))
>  Just (Sum {getSum = 4})
> 
>> (Just (Sum 4)) `mappend` (Just (Sum 3))
>  Just (Sum {getSum = 7})

We already have,

> First (Just (Sum 4)) `mappend` First (Just (Sum 3))
First {getFirst = Just (Sum {getSum = 4})}

So the overlap of apparent Alternative and Monoid functionality remains. This 
just represents an opportunity for the caller to select the monoid they want.

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

Re: [Haskell-cafe] I for one welcome our new Robotic Overlords

[Anthony Cowley]

On Sep 27, 2011, at 2:01 PM, Jeremy Shaw  wrote:

> When the robots take over, do you want them to be developed using a sane 
> language like Haskell or Agda? Or some dangerous untyped OO language? I think 
> the answer is obvious.
> 
> The question is, "How?". The robots will not be developed by us, but by the 
> children of today. So, we must reach their pure minds before they have been 
> unsafely coerced by the evil unbelievers who do not worship the gods λ, Π, 
> and ω.

Timing: you have it. 

I presented the work behind https://github.com/acowley/roshask at IROS 2011 
just this morning. ROS is possibly the most widely used robotics middleware 
today, and you can now use Haskell to work with existing ROS components. 

While FP isn't hugely popular among the robotics community (I've been pitching 
functional approaches here for several years), this time around I am optimistic 
that we've turned the corner, or at least started that process. There was a lot 
of support, and developers behind other large projects expressed eagerness to 
rely more heavily on the compositionally of good old functions.

I am not aware of as good a story for Arduino-level development. Atom may be an 
appropriate foundation for such an effort, but I also hope that we can get GHC 
ARM support sorted out, and then use platforms like the forthcoming Raspberry 
Pi as the computational core of an inexpensive robotics platform.

In short, you can just about achieve your vision today with a TurtleBot from 
Willow Garage and roshask.

Anthony


> 
> My long term vision is:
> 
> A company which produces an extensible robotics platform for children and 
> adults ages 8 and up. The platform would be very open, extensible, and 
> hackable.
> 
> The robotic programming languages would be based around concepts like 
> functional reactive programming, dependent types, etc.
> 
> Children would begin with a simple FRP language to control the robot. They 
> would solve simple problems like "go forward until an object is encountered." 
> As the young masters grow, they can tackle more difficult problems such as 
> maze solving. Even later they can delve into more advanced subjects like 
> computer vision, speech recognition and synthesis, or mind control rays.
> 
> The short term vision can be summarized in one word "leverage".
> 
> We need to find an existing robotic platform which can be easily targeted 
> somehow using Haskell or Agda. Perhaps something that can be targeted using 
> atom or lava? Maybe something Arduino based?
> 
> I have created a wiki page here to record your suggestions and ideas:
> 
> http://haskell.org/haskellwiki/RoboticOverlords
> 
> The requirements now are something that is:
> 
> - hackable/open
> - easily obtained
> - reasonable in price
> - can easily be targeted via Haskell
> 
> The only candidate I know of so far is lego mindstorms via the NXT package on 
> hackage, Though some could argue that lego mindstorms are not reasonably 
> priced.
> 
> http://hackage.haskell.org/package/NXT
> 
> Let's here your ideas!
> - 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] Segfault in the libc malloc using FFI (occurs only in x86_64)

[Anthony Cowley]

I reported a segfault in FFI calls a while back that should be fixed
in 7.2. It turned out to be a stack alignment issue, which may or may
not be related to what you are seeing.

Here is the bug report:


Anthony

On Sat, Aug 20, 2011 at 12:51 PM, Vincent Gerard  wrote:
> Hi cafe,
>
> I have been struggling with this issue for the past days. I have
> investigated at the Haskell, C and even at assembly level...
> Perhaps I'm missing something big ??
>
> I hope someone familiar with FFI could help me on this Segfault.
>
> My env is: Linux Debian 3.0.0-1, SMP, GHC 7.0.4, x86_64, eglibc 2.13-10
> (This issues occurs as well on others people with /= env, but only with
> x86_64 arch)
>
> The bug is in the hsmagick library (FFI bindings to
> GraphicsMagick), for which I am the maintainer.
>
> --
> So here is a reproducer (Works fine in 32 bit, segfault in 64).
>
> You should have hsmagick + GraphicsMagick dev libs installed.
>
>  import Graphics.Transform.Magick.Images
>
>  main =  do
>    initializeMagick
>    c <- readImage "image.jpg"
>    putStrLn "End"
> --
> Executing this program, compiled with standard options, a Segfault
> occurs at runtime.
>
> If I compile this small program with -threaded option an assertion error
> is thrown at runtime:
>
>  main: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr)
>  (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct
>  malloc_chunk, fd && old_size == 0) || ((unsigned long) (old_size)
>  >= (unsigned long)__builtin_offsetof (struct malloc_chunk,
>  >fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t)))
>  >- 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end &
>  >pagemask) == 0)' failed.
>
> This assertion error is cryptic for me... but it maybe could help
> someone here.
>
> However, having a C experience, investigating a Segfault is in
> my habits, so let's install debugs symbols on everything and dig with
> gdb.
>
> Here is the backtrace:
>
>  Program received signal SIGSEGV, Segmentation fault.
>  0x7510292c in malloc_consolidate (av=0x7540fe60) at
>  malloc.c:5161 (this is inside the eglibc source)
>  5161              unlink(p, bck, fwd);
> (gdb) bt
>  #0  0x7510292c in malloc_consolidate (av=0x7540fe60) at
>  malloc.c:5161
>  #1  0x75104d64 in _int_malloc (av=0x7540fe60,bytes=8520)
>  at malloc.c:4373
>  #2  0x75107420 in __libc_malloc (bytes=8520) at malloc.c:3660
>  #3  0x767bf311 in CloneImageInfo (image_info=0x0) at
>  magick/image.c:1012
>  #4  0x00439dfa in
>  hsmagickzm0zi5_GraphicsziTransformziMagickziFFIHelpers_mkNewImageInfo1_info
>  ()
>
> Yay, the Segfault is deep in the libc after a regular malloc (8520bytes)
> (I dug into the GraphicsMagick source starting from magick/image.c:1012)
>
> And this libc call is called by a call to CloneImageInfo(NULL) from
> Haskell, which is correct as it is graphicsMagick way to
> allocate an empty ImageInfo data structure.
> (http://www.graphicsmagick.org/api/image.html#cloneimageinfo)
>
> I tried in a C program to execute (after initializing ImageMagick)
> image_info=CloneImageInfo((ImageInfo *) NULL);
> And of course  no Segfault...
>
> Let's look at the FFI call...
>
> This FFI call is the done by the mkNewImageInfo as shown in the trace.
>
> The Haskell FFI layer here has done the right job, calling
> the C function with the right args (NULL)
>
> Here is all the code related to mkNewImageInfo (the last Haskell part we
> see in the backtrace)
>
> ---
>  mkNewImageInfo :: IO (ForeignPtr HImageInfo)
>  mkNewImageInfo = mkFinalizedImageInfo =<< mkNewImageInfo_
>
>  mkFinalizedImageInfo :: Ptr HImageInfo -> IO (ForeignPtr HImageInfo)
>  mkFinalizedImageInfo = newForeignPtr imageInfoFinalizer
>
>  mkNewImageInfo_ :: IO (Ptr HImageInfo)
>  mkNewImageInfo_ = clone_image_info nullPtr -- CALL before the Segfault
>
>  destroyImageInfo :: Ptr HImageInfo -> IO ()
>  destroyImageInfo = destroy_image_info
>
>  foreign import ccall "static magick/api.h &DestroyImageInfo"
>    imageInfoFinalizer :: FunPtr (Ptr HImageInfo -> IO ())
>
>  foreign import ccall "static magick/api.h CloneImageInfo"
>    clone_image_info :: Ptr HImageInfo -> IO (Ptr HImageInfo)
> --
>
> To me, this code is right (and works perfectly in 32 bit).
> Furthermore, as the call is made with a nullPtr arg, no data structure
> is used ...
> I tried this code without using ForeignPtr Finalizers (hsmagick <= 0.4)
> and the Segfault occurs as well ...
>
> I even had a look at the generated assembly, which also looks right...
>
> It seems there is a real segmentation error, or an illegal access to a
> memory page... But I could not find the root cause of this error.
>
> And an additionnal piece to the puzzle, when running the program inside
> valgrind, there is no Segfault and the program works as expected.
>
>
> So if anyone have an idea on how only on 64bits arch an Haskell FFI
> call cou

Re: [Haskell-cafe] How to determine minimal dependency of package

[Anthony Cowley]

On Fri, Jul 15, 2011 at 10:48 AM, yi huang  wrote:
> I'm writing my first haskell package, how do i determine the minimal
> dependency of it, for example, it use Data.Data, how do i know which version
> of base package  first introduce Data.Data module, i can't find the answer
> with google.

You should specify the minimum version you have tested with.

Anthony

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

Re: [Haskell-cafe] Lazy Evaluation in Monads

[Anthony Cowley]

On Tue, May 31, 2011 at 3:49 PM, Scott Lawrence  wrote:
> I was under the impression that operations performed in monads (in this
> case, the IO monad) were lazy. (Certainly, every time I make the
> opposite assumption, my code fails :P .) Which doesn't explain why the
> following code fails to terminate:
>
>  iRecurse :: (Num a) => IO a
>  iRecurse = do
>    recurse <- iRecurse
>    return 1
>
>  main = (putStrLn . show) =<< iRecurse
>
> Any pointers to a good explanation of when the IO monad is lazy?

import System.IO.Unsafe

iRecurse :: (Num a) => IO a
iRecurse = do
  recurse <- unsafeInterleaveIO iRecurse
  return 1

More interesting variations of this leave you with questions of
whether or not the missles were launched, or, worse yet, was data
actually read from the file handle?

Anthony

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

Re: [Haskell-cafe] GHC 7, Platform 2011.2 vs OS X 10.5, Ubuntu 11.04

[Anthony Cowley]

On Mon, May 23, 2011 at 8:16 AM, Jacek Generowicz
 wrote:
>
> On 2011 May 23, at 13:45, Anthony Cowley wrote:
>> As for the platform, if it is giving you trouble, don't shy away from
>> just using GHC and cabal as normal! After you've cabal installed a few
>> big packages, you will find that you've acquired many of the most
>> popular packages.
>
> If by "cabal install" you mean use the command "cabal" ... yeah, that would
> be great, if only I could install cabal-install, which fails. Or do you mean
> "manual install" of Cabal packages? Either way, I'm not making much
> progress.

What I do is get GHC installed, then download the cabal-install
package from hackage and use the bootstrap.sh installer it comes with.
Then you can use the cabal executable to install packages as you go.

Anthony

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

Re: [Haskell-cafe] GHC 7, Platform 2011.2 vs OS X 10.5, Ubuntu 11.04

[Anthony Cowley]

On Mon, May 23, 2011 at 5:17 AM, Jacek Generowicz
 wrote:
> So, after this tale of agony, here are two concrete questions:
>
> a) Am I right in concluding that GHC 7.0.3 will not run on OS X 10.5
> (without unreasonable effort)?

This is a frustrating situation. Note that there is a binary for 7.0.1
that supports 10.5
. From
this, you should be able to build 7.0.3 yourself. One minor note: if
you're interested in LLVM, stick to the 32-bit build.! If you
encounter problems, #haskell will help.

As for the platform, if it is giving you trouble, don't shy away from
just using GHC and cabal as normal! After you've cabal installed a few
big packages, you will find that you've acquired many of the most
popular packages.

> b) On Ubuntu Natty I installed the generic linux GHC 7.0.3 binary.
> Downloaded Haskell Platform 2011.2.0.1 source distribution. ./configure
> worked happily. make fails as follows.
>
> Building transformers-0.2.2.0
> "/usr/local/haskell-platform-2011.2.0.1/bin/ghc" "--make" "Setup" "-o"
> "Setup" "-package" "Cabal-1.10.1.0"
> : cannot satisfy -package Cabal-1.10.1.0:
>    Cabal-1.10.1.0-1fb2094e19492373b1a39284193e7984 is unusable due to
> missing or recursive dependencies:
>      process-1.0.1.5-55dfaccf3a91c4cb8f6284a0bafef198


The Ubuntu HP story is a bit of a gotcha for the innocent user, too.
But, again, you can happily install GHC 7.0.3, and then cabal install
your way to happiness. The problem you encountered seems due to a
conflict among packages that came with GHC.

I think your strategy of nuking everything Haskell through your
package manager (if available), then manually (not forgetting ~/.ghc
and ~/.cabal) was prudent to get out of the hole you found yourself
in. But don't let HP installation troubles keep you away from Haskell
altogether!

Anthony

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

Re: [Haskell-cafe] Foreign function performance: monadic vs pure

[Anthony Cowley]

On Mon, Apr 11, 2011 at 8:09 AM, Serguei Son  wrote:
> Consider two versions of sin wrapped:
> foreign import ccall "math.h sin"
>    c_sin_m :: CDouble -> IO CDouble

Marking this call as unsafe (i.e. foreign import ccall unsafe "math.h
sin") can improve performance dramatically. If the FFI call is quick,
then I believe this is the recommended approach. If you really need
the imported function to be thread safe, then perhaps you should move
more of the calculation into C to decrease the granularity of FFI
calls.

It is remarkably easy to get the meanings of safe and unsafe confused,
and I can't even see the word "unsafe" in the current FFI user's
guide! 

Anthony

> and
> foreign import ccall "math.h sin"
>    c_sin :: CDouble -> CDouble
>
> One can invoke them so:
>
> mapM c_sin_m [1..n]
> mapM (return . c_sin) [1..n]
>
> On my computer with n = 10^7 the first
> version never finishes, whereas the second
> one calculates the result within seconds.
>
> To give you my context, I need to call
> a random variable generator multiple times,
> so that it must return IO a.
>
> Any explanation for this behavior?
>
>
> ___
> 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] coding style vs. foreign interfaces

[Anthony Cowley]

On Sun, Feb 6, 2011 at 10:10 PM, Donn Cave  wrote:
> Of the people who are apt to be interested, a sizeable percentage
> already will be familiar with ALARM_STUFF_WENT_WRONG, and as the
> "nice" Haskell spelling offers no practical advantage at all, it's
> purely a waste of their time to translate from one to the other.
> Is screenflicker_frequency() going to be screenFlickerFrequency,
> or screenflickerFrequency?  gah!

I don't think it's this simple. It is disheartening to innocently
download a library from Hackage to find that it only supports a very
non-Haskelly API. Why am I being punished by the history of a library?
To support both kinds of users, we have designs like that used in the
OpenGL library: a Foo-Raw library, with a friendlier API layered on
top, perhaps in a separate package. If the "friendly" API turns out to
be no friend of yours, you are free to turn to the raw wrappers.

Perhaps we should aim for a more systematic application of this design
pattern? I know that I appreciate a more idiomatic Haskell API when it
is available, and certainly do not want library authors discouraged
from providing such a service solely due to the provenance of the
functionality. On the other hand, when I am porting, say, C coded
against a particular API to Haskell, being able to use a more
symmetric API is beneficial.

One can keep both APIs in the same package until a legitimate desire
to split them arises (e.g. to provide alternate high-level APIs).

Anthony

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

Re: [Haskell-cafe] Extending GHCi

[Anthony Cowley]

On Sun, Feb 6, 2011 at 11:59 PM, C K Kashyap  wrote:
>>
>> $ ghci
>> GHCi, version 6.12.3: http://www.haskell.org/ghc/  :? for help
>> Loading package ghc-prim ... linking ... done.
>> Loading package integer-gmp ... linking ... done.
>> Loading package base ... linking ... done.
>> Loading package ffi-1.0 ... linking ... done.
>> Prelude> :m +Data.IORef Control.Concurrent Control.Monad
>> Prelude Data.IORef Control.Concurrent Control.Monad> msg <- newIORef
>> "Hello"
>> Prelude Data.IORef Control.Concurrent Control.Monad> let echo =
>> forever $ readIORef msg >>= putStrLn >> threadDelay 300
>> Prelude Data.IORef Control.Concurrent Control.Monad> t <- forkIO echo
>> Hello
>> Prelude Data.IORef Control.Concurrent Control.Monad> Hello
>> Hello
>> writeIORefHello msg "World"
>> Prelude Data.IORef Control.Concurrent Control.Monad> World
>> World
>
> Thanks ... this is the possibility I was looking for. Btw, I am thinking I'd
> need to use STM to synchronize right?
> Regards,
> Kashyap

You need STM when you need groups of references to change
simultaneously as perceived by concurrent processes.

Anthony

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

Re: [Haskell-cafe] Extending GHCi

[Anthony Cowley]

On Fri, Feb 4, 2011 at 9:41 AM, C K Kashyap  wrote:
> Thanks Steffen,
>
>>
>> Prelude> :l MyModule.hs
>> *MyModule> conn <- waitForAndAcceptConnection
>> *MyModule> someData <- getSomeData conn
>> *MyModule> sendSomeAnswer conn $ processSomeData someData
>> ...
>>
>
> So this cycle of getting data from the connection and writing answer on the
> connection should happen concurrently with the ghci interaction ... so lets
> say that when the "thread" is forked that listens on socket behaves like an
> echo server ... as in, it reads data from the client till "\n" and echoes it
> back ... All this would happen without the intervention of the user using
> GHCI ... However, using GHCI, the user should be able to modify the code
> such that the server returns "hello" prepended to the input. ..
>> startMyServer -- at this point the the echo server gets spawned
>>                       -- echo server continues to run
>> someFunction "hello" --- now onwards  hello gets prepended
>>                       --- echo server continues to run returning "hello"
>> prepended
>> someFunction "world" --- now onwards "helloworld" get
> I hope this is possible without having to modify ghci itself.

Something like this, perhaps. Sorry that it is a bit hard to read.

Anthony


$ ghci
GHCi, version 6.12.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Prelude> :m +Data.IORef Control.Concurrent Control.Monad
Prelude Data.IORef Control.Concurrent Control.Monad> msg <- newIORef "Hello"
Prelude Data.IORef Control.Concurrent Control.Monad> let echo =
forever $ readIORef msg >>= putStrLn >> threadDelay 300
Prelude Data.IORef Control.Concurrent Control.Monad> t <- forkIO echo
Hello
Prelude Data.IORef Control.Concurrent Control.Monad> Hello
Hello
writeIORefHello msg "World"
Prelude Data.IORef Control.Concurrent Control.Monad> World
World

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

Re: [Haskell-cafe] Type System vs Test Driven Development

[Anthony Cowley]

On Wed, Jan 5, 2011 at 3:02 PM, Jonathan Geddes
 wrote:
>> The Haskell type system is simply not rich enough to guarantee everything 
>> you might need.
> Despite all this, I suspect that since Haskell is at a higher level of
> abstraction than other languages, the tests in Haskell must be at a
> correspondingly higher level than the tests in other languages. I can
> see that such tests would give great benefits to the development
> process. I am convinced that I should try to write such tests. But I
> still think that Haskell makes a huge class of tests unnecessary.

The way I think about this is that you want to write tests for things
that can not be usefully represented in the type system. If you have a
parametrically typed function, then the type system is doing a lot of
useful "testing" for you. If you want to make sure that you properly
parse documents in a given format, then having a bunch of examples
that feed into unit tests is a smart move.

Anthony

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

Re: [Haskell-cafe] Confused about missing data constructor

[Anthony Cowley]

On Tue, Nov 23, 2010 at 7:58 PM, Adam Miezianko  wrote:
> I'm working through Learn You a Haskell for Great Good [1] and getting
> a compiler error while playing around with some of the code.  I have
> this:
> Now, I'm not exactly sure how to read the documentation for
> Control.Monad.State [2] but it seems that newtype State s a = State
> {...} defines a constructor, or am I wrong on that point too?  So,
> what am I missing here?  In case it matters, I am using mtl-2.0.1.0
> and ghci 6.12.3.
>
> [1] http://learnyouahaskell.com/for-a-few-monads-more
> [2] http://cvs.haskell.org/Hugs/pages/libraries/mtl/Control-Monad-State.html

Wrong documentation page, the one you want is


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

Re: [Haskell-cafe] date parsing and formatting

[Anthony Cowley]

On Sat, Nov 13, 2010 at 4:35 PM, Alex Baranosky
 wrote:
> I've been working with Haskell's Date.Time modules to parse a date
> like 12-4-1999 or 1-31-1999. I tried:
>
> parseDay :: String -> Day
>
> parseDay s = readTime defaultTimeLocale "%m%d%Y" s
>
> And I think it wants my months and days to have exactly two digits instead
> of 1 or 2...
>
> What's the proper way to do this?
>
> Also, I'd like to print out my Day in this format: 12/4/1999 what's the
> Haskell way to?

Something like this, perhaps,

parseDate :: String -> LocalTime
parseDate = readTime defaultTimeLocale "%m/%e/%Y"

printDate :: LocalTime -> String
printDate = formatTime defaultTimeLocale "%m/%-e/%Y"

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

Re: [Haskell-cafe] Haskellers.com skills list moderation?

[Anthony Cowley]

On Wed, Oct 20, 2010 at 9:02 AM, Ben Millwood  wrote:
>> Robotics and Automation
>
> Would be tempted to drop "Automation" from here.

That name was deliberately chosen, and is appropriate for people in the area,
http://www.ieee-ras.org/

I have my own opinions on a lot of these tags, but haskell-cafe
doesn't seem like the right forum for this polling. A difficulty is
that while we may all be qualified to debate the merits of
"Mathematics" as a discriminative label for programmers, some of these
tags (such as the one above) are domain specific. We don't want people
outside of an area of interest governing name choices that lessen the
value of the tags.

As a strawman for people to beat up on, what if each tag linked to a
wiki description? Such a description could include a couple sentences
of exposition, and perhaps links to relevant resources.

Another alternate is that if a tag becomes *too* popular (i.e. more
than x% of haskellers check it off), then perhaps there should be a
poll to have it removed and its spirit embedded in the general site
text. Tags like "Algorithmic Problem Solving" might fall into this
category.

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

Re: [Haskell-cafe] Eta-expansion destroys memoization?

[Anthony Cowley]

On Thu, Oct 7, 2010 at 9:33 AM, Jan-Willem Maessen
 wrote:
> There's no evaluation magic here---all that's happening is GHC is
> executing the program exactly as written.  It can't float the list out
> of the function, as that can lead to unexpected space leaks (if you
> didn't intend to keep the list of fibs around forever).

To echo Jan-Willem a bit, the impact of let floating can be seen by
compiling the eta expanded version (i.e. fib x = map fib' [0..] !! x)
with different options.

$ ghc --make -O -fforce-recomp FibMemo.hs
[1 of 1] Compiling Main ( FibMemo.hs, FibMemo.o )
Linking FibMemo ...
$ ./FibMemo
5
3
2
4
5

$ ghc --make -O -fforce-recomp FibMemo.hs -fno-full-laziness
[1 of 1] Compiling Main ( FibMemo.hs, FibMemo.o )
Linking FibMemo ...
$ ./FibMemo
5
3
2
4
2
3
2
5

My understanding is that this is just a case where GHCi is able to
float a binding in the partial application formulation because the
dependency analysis is trivial due to there being no name for the
binding.

Looking at the core for the optimized version of the eta expanded
code, there is a a top-level function for building a list of fibonacci
numbers, a top-level value of type [Type.Integer] set to an
application of the builder function to zero, and finally the fib
function that indexes into that list.

The version with -fno-full-laziness leaves the let binding under the
lambda as expected.

So the optimizer is clever and can see through the lambda, but we make
the interpreter's job easier by not putting a lambda over its eyes to
begin with.

Anthony

On Thu, Oct 7, 2010 at 9:33 AM, Jan-Willem Maessen
 wrote:
> What people seem to be missing here is that the location of the
> where-binding with respect to the lambda changes in each case.  As a
> result, I think the forgoing explanations were rather confusing;
> there's no magic going on here.
>
> On Thu, Oct 7, 2010 at 8:17 AM, Brent Yorgey  wrote:
>
>> - Forwarded message from Yue Wang  -
>>
>> From: Yue Wang 
>> Then there is a clever way to do that on haskell wiki:
>>
>> fib = ((map fib' [0 ..]) !!)
>>    where
>>      fib' 0 = 0
>>      fib' 1 = 1
>>      fib' n =trace(show(n)) fib (n - 1) + fib (n - 2)
>
> This is indeed equivalent to:
> fib =
>  let fib' 0 = 0
>       fib' 1 = 1
>       fib' n = fib (n-1) + fib (n-2)
>  in (map fib' [0..] !!)
>
> But adding the argument embeds the let inside the function call:
> fib x =
>  let fib' 0 = 0
>       fib' 1 = 1
>       fib' n = fib (n-1) + fib (n-2)
>  in (map fib' [0..] !!)
>
> Now we create a new fib' for each invocation of fib.  Not efficient at
> all!  (Much *less* efficient the the recursive fib).
>
> There's no evaluation magic here---all that's happening is GHC is
> executing the program exactly as written.  It can't float the list out
> of the function, as that can lead to unexpected space leaks (if you
> didn't intend to keep the list of fibs around forever).
>
> -Jan-Willem Maessen
> ___
> 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] interesting type families problem

[Anthony Cowley]

2010/9/8 Gábor Lehel :
> Oh. Hmm. That makes sense. So I gather there's absolutely no way to
> specify which instance you mean, and hence to use `value` as any
> concrete type?

Here's one way to indicate which value you are referring to.

Anthony

{-# LANGUAGE EmptyDataDecls, TypeFamilies #-}
data True
data False

class TypeValue a where
type ValueTypeOf a
value :: a -> ValueTypeOf a

instance TypeValue True where
type ValueTypeOf True = Bool
value _ = True

instance TypeValue False where
type ValueTypeOf False = Bool
value _ = False

main = print (value (undefined::True))
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] bitmap examples

[Anthony Cowley]

On Tue, Aug 24, 2010 at 11:02 AM, Raluca-Elena Podiuc
 wrote:
>
> Hi,
> I am trying to build a mini framework for image processing but I can find
> any examples about that (bitmap processing ). Does anybody know were can I
> find some tutorials or samples about that ?

Noam Lewis's HOpenCV package on hackage
 is a great way to get
started using OpenCV for image processing.

My own fork of this project  adds
static checking of color and pixel depth, more OpenCV functionality,
and interoperation with Data.Vector.Storable. However, it should
definitely be classified as experimental as I'm still exploring how I
want things to work. I am using it for real-time video processing in
an active research project, though, so it is getting regularly
exercised. An example program included in the repository is,

> import AI.CV.OpenCV.HighCV

> main = toFile "closed.png" . erode 8 . dilate 8 =<< fromFileGray "input.png"

I've made some effort to provide reasonable haddock documentation, so
I recommend building that (cabal haddock) and consulting it to find
your way around.

As I mentioned, it is all still very rough, but feel free to give it a
try if it seems to do what you need. If you're looking to start your
own effort from scratch, I think Data.Vector.Storable is nice way to
mix Haskell and C.

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

Re: [Haskell-cafe] Re: Sifflet dependencies

[Anthony Cowley]

On Tue, Aug 17, 2010 at 2:54 PM, Andrew Coppin
 wrote:
> While we're on the subject... Suppose I have a package, which I know works
> with foo-8.7.2. What should the Cabal dependents field say? We have a choice
> of
>
>  foo == 8.7.2
>  foo >= 8.7.2
>  foo >= 8.7
>  foo >= 8.7 && < 8.8
>  foo == 8.7.*

I'd like to add another option since it's the one I use,

foo >= 8.7.2 && < 8.8

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

Re: [Haskell-cafe] Arrays and image processing

[Anthony Cowley]

On Wed, Aug 4, 2010 at 12:49 AM, kirstin penelope rhys
 wrote:
> But now I need a fast multidimensional array which can handle a tuple of
> primitive types.
>
> My options, as far an I can see, are:
>
> 1) Add an instance for UArray (Int,Int) (Word16, Word16, Word16)
> and/or UArray (Int,Int) (Word8, Word8, Word8)
>
> 2) Add a multidimensional wrapper for Data.Vector

What about something like,

import qualified Data.Vector.Unboxed as V
import Data.Word

type Pixel = (Word8, Word8, Word8)
type Image = (Int, Int, V.Vector Pixel)


Since you may want interoperability with C, you could also consider
using Data.Vector.Storable with flat data. Just put the
multi-dimensional logic in your indexing operations. I do quite a bit
of image processing with a mix of Haskell and C, and have found
Unboxed and Storable Vectors effective.

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

Re: [Haskell-cafe] possible bug in default module lookup scheme / or invalid haskell?

[Anthony Cowley]

On Sun, Jul 18, 2010 at 1:55 PM, Carter Schonwald
 wrote:
> I'm not sure I follow, because the toy example I'm asking about does in fact
> use hierarchical module names...
> are you proposing that a reasonable workaround in my use case is to do
> :cd ..
> :r
> this seems like a reasonableish approach, or was there a different example
> you had in mind?


Yes, that is what I had in mind. The typical scenario for me is to be
editing a file in emacs, C-c-C-l it, and have GHCi complain. I then
issue a ":cd .." in GHCi, and my subsequent loads are properly rooted
at top of the project directory.

What I was trying to describe as unwanted is for someone to take your
toy example and, in the file A/B.hs have a line "import B.C" that is
gets correctly resolved by GHC. I'm not sure that you were actually
suggesting this, but this kind of leniency on the part of GHC (or
GHCi) would make the file B.hs fragile with respect to moving it
around on disk.

Anthony

> On Sun, Jul 18, 2010 at 1:34 PM, Anthony Cowley 
> wrote:
>>
>> On Sun, Jul 18, 2010 at 3:59 AM, Carter Schonwald
>>  wrote:
>> > I don't think that semantics creates the sort of ambiguity that Kevin is
>> > concerned about, and while yes there simple alternative approaches, they
>> > require whatever is starting up ghci to know what the correct directory
>> > to
>> > pass to the -i flag, and that seems a bit of a heavy weight expectation
>>
>> I usually use ghci's :cd command in this situation, and wouldn't want
>> to think about changing source files depending on where they were on
>> disk.
>>
>> While having to use fully hierarchical names might seem verbose, I
>> have found it to be a very predictable mechanism that makes managing
>> large-ish projects easier.
>>
>> Anthony
>> ___
>> 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] possible bug in default module lookup scheme / or invalid haskell?

[Anthony Cowley]

On Sun, Jul 18, 2010 at 3:59 AM, Carter Schonwald
 wrote:
> I don't think that semantics creates the sort of ambiguity that Kevin is
> concerned about, and while yes there simple alternative approaches, they
> require whatever is starting up ghci to know what the correct directory to
> pass to the -i flag, and that seems a bit of a heavy weight expectation

I usually use ghci's :cd command in this situation, and wouldn't want
to think about changing source files depending on where they were on
disk.

While having to use fully hierarchical names might seem verbose, I
have found it to be a very predictable mechanism that makes managing
large-ish projects easier.

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

Re: [Haskell-cafe] design question/font metrics

[Anthony Cowley]

On Tue, Jun 1, 2010 at 10:30 AM, Gery Debongnie
 wrote:
> 3. Perform a reading of the font metrics file in the main program, put
> the results into some FontMetrics object, and give that to stringWidth
> :: FontMetrics -> Font -> String -> Double.  Pros : allow me to avoid
> problems of solution 1 and 2, cons : it doesn't sound right for the
> main program to have to do this, it should be confined into a Font
> module.

Ultimately all your IO is driven from main, so don't be afraid to add
more IO dependencies to it. You can let IO "infect" a module for
dealing with font files (e.g. a FontMetrics module with a function
getMetrics :: [String] -> Map String Double), then drive that module
from main and feed its results into your pure code.

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

Re: [Haskell-cafe] dependent types

[Anthony Cowley]

On Sun, Apr 11, 2010 at 5:54 PM, Jason Dagit  wrote:
> On Sun, Apr 11, 2010 at 1:59 AM, Andrew U. Frank
>  wrote:
>>
>> in modeling real application we have often the case that the type of
>> some object depends on a value. e.g. small_boat is a vessel with size
>> less than a constant. big_boat is a vessel with a larger size. for
>> example, many legal classifications are expressed in this form (e.g. car
>> vs. truck)
>> depending on the type, operations are applicable or not (e.g. road with
>> restriction 'no trucks').
>>
> In the witness type version you may find that defining Vehicle as a GADT is
> even better:
> data Vehicle classification where
>   mkCar :: ... -> Vehicle Car
>   mkTruck :: ... -> Vehicle Truck
> This is nice because it's direct and when you pattern match on the
> constructor you recover the type of classification.  For example, I believe
> this would type check:
> foo :: Vehicle c -> c
> foo (mkCar ...) = Car
> foo (mkTruck ...) = Truck

You can combine GADTs with a mirror type for views of that data.

{-# LANGUAGE GADTs, EmptyDataDecls #-}
module GADTSmart (VehicleView(..), Vehicle, Car, Truck,
  mkCar, mkTruck, view) where
data Car
data Truck

data Vehicle t where
VCar   :: Int -> Vehicle Car
VTruck :: Int -> Vehicle Truck

data VehicleView t where
VVCar   :: Int -> VehicleView Car
VVTruck :: Int -> VehicleView Truck

view :: Vehicle t -> VehicleView t
view (VCar wt)   = VVCar wt
view (VTruck wt) = VVTruck wt

mkCar :: Int -> Maybe (Vehicle Car)
mkCar wt | wt < 2000 = Just (VCar wt)
 | otherwise = Nothing

mkTruck :: Int -> Maybe (Vehicle Truck)
mkTruck wt | wt >= 2000 = Just (VTruck wt)
   | otherwise  = Nothing


-- Client code that doesn't have access to the VCar or VTruck
-- constructors.

moveAcrossBridge :: Vehicle Car -> IO ()
moveAcrossBridge c = case view c of
   VVCar wt -> putStrLn $ "Car ("++show wt++") on bridge"


Now you can type your functions with the Vehicle GADT, but only
introduce values of that type using smart constructors. You could use
the VVCar or VVTruck data constructors to create invalid values, but
they won't work your functions.

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

Re: [Haskell-cafe] Re: Haskellers hate GUIs!!

[Anthony Cowley]

On Fri, Apr 2, 2010 at 12:53 PM, Dominic Espinosa  wrote:
> Is there a general strategy for deploying Haskell apps, graphical or no,
> to MacOS X and/or Windows? I'm especially interested in cases where the
> application uses some heavyweight libraries like OpenGL.

I have a GUI app that I deploy on Mac and Linux that uses OpenGL and
wxHaskell. It has been a pretty good experience, but getting wx set up
on every development machine is hairier than cabal install. The good
news is that it was easy to set up a pure GLUT front end as well as a
wx one that both use the same OpenGL code for rendering graphically
intensive bits. I just have two build targets to switch between the
two.

For general cross-platform GUI apps that I need in a pinch, I turn to
PLT Scheme. They have a really excellent system in this regard.

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

Re: [Haskell-cafe] GHC RTS question

[Anthony Cowley]

On Sun, Feb 21, 2010 at 1:58 PM, Artyom Kazak  wrote:
> So, if I type "./prog +RTS --RTS +RTS", the output will be "+RTS". But
> I want the output to be equal to the input IN ALL CASES, without any
> quotes, additional options, etc. I want all the command line to go to
> my program. How can I do it? (The only way I know now - hacking the
> GHC. If there are no other ways, I'll do it.)

How about a wrapper script? Something like,

#! /usr/bin/env bash
./prog --RTS $*

Just use that as the front-end to your Haskell program.

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