Re: [Haskell-cafe] Fwd: Can I use String without in ghci?
On 3/09/2013, at 10:44 PM, Rustom Mody wrote: Whoops! my bad -- I was *thinking* 'pipes' but ended up *writing* 'IPC' :-) So let me restate more explicitly what I intended -- pipes, FIFOs, sockets, etc. IOW read/write/send/recv calls and the mathematical model represented by the (non-firstclass) pair of C data structures in those functions: buf, len (or count). Yes, but none of these have anything to do with strings. string has a precise meaning in C: 7.1.1#1 A string is a contiguous sequence of characters terminated by and including the first null character. The term multibyte string is sometimes used instead of emphasize special processing given to multibyte characters contained in the string or to avoid confusion with a wide string. A pointer to a string is a pointer to its initial (lowest addressed) character. The length of a string is the number of characters preceding the null character and the value of a string is the sequence of the values of the contained characters, in order. 7.1.1#6 (same as #1 but string-wide string and character-wide character) If you are going to claim Humpty-Dumpty's privilege, we cannot have a meaningful discussion. Let me propose a more general definition of string which is consistent with the three kinds of string natively supported by the C string.h library and the four or five alternatives I've personally used in C, with AWK, Python, JavaScript, Java, Erlang, Ada, Smalltalk, Objective C, and PL/I. (Haskell gets a little fuzzy here.) A *string* is a *completed* sequence of characters which may be traversed in the natural order *and others*. In this definition, there are four key aspects: - CHARACTERS. The elements of a string belong to some finite set whose elements we have agreed to regard as representing characters. - SEQUENCE. The implementation might be a multiway tree, a piece table, an AVL DAG, or something more exotic, but there is a privileged view of it as a sequence. - COMPLETED. For any particular state of the string, there is some present fact of the matter about what the length is and each element is known. - TRAVERSAL. You can go from the beginning of the string to the end. And you can go back again. Palindrome tests are easy. Now here's another definition: A (byte, character) *stream* is a *non-completed* sequence of (bytes, characters) which may be traversed once in the natural order; repeated traversal, and other traversal orders, need not be possible. Now let us look at pipes, FIFOs, sockets, c. These things aren't even close to being strings. They are BYTE STREAMS. - The contents are *not* characters, they are *bytes*. It was and remains common practice to read and write *non-textual* data using these interfaces. There are portability issues in transputting binary data in native format, but there are serious performance advantages to doing so. Interfaces like XDR make it straightforward to read and write arrays and records and trees with never a character in sight. The fact that the external data are *byte* sequences rather than *character* sequences is the reason that we now have a problem with having to specify the encoding of an external stream when we *want* characters. In another mailing list I'm on a problem came up when a data set from the US government was proclaimed to be ASCII but was in fact Windows CP1250 (or some such number) and the receiver's system didn't _have_ any locale that could decode that code-page. To put that another way, given an external byte sequence accessed using pipes, FIFOs, sockets, c, if it is to be interpreted as bytes, there is no question about what its contents are, but if it is to be interpreted as characters, the information needed to discern what the characters _are_ is as a rule not in that byte sequence. - The buffers transferred in a read() or write() call are not strings either. They are *chunks* of a byte sequence. (Oh, and if you have wide character data inside your program, it is very likely to be a bad idea to transput them directly this way.) write(fd, record, sizeof record) is not uncommon. - The size of an external byte sequence accessed using pipes, FIFOs, sockets, c is not knowable through that interface. The information can be conveyed by some other means, but it cannot be trusted. (I could _say_ that there are 400 bytes but _send_ 500, or 300.) The interface is a *stream* interface, not a *string* interface. - Only forward traversal is possible. As an aside: modern usage types the buf as void * . The version 7 unix manuals on which I grew up (and first edition of KR), there was no void; buf would be just 'char *buf; ' Version 7 did have void but did not have void *. Since void * and char * are required to have identical
Re: [Haskell-cafe] Haskell / Functional Programmers Group in Madrid (Spain)?
Alejandro Serrano Mena trupill at gmail.com writes: Hi,Is there any Haskell or functional programmers user group in the region of Madrid? If not, I think it could be a great idea to get to know each other, and share experiences. Furthermore, we could try to organize some meetings with presentations, hackatons and so on (my personal ambition is to be able to organize another ekmett Workshop as the Japanese one - http://comonad.com/reader/2013/japanese-workshop-1/). I know there is some locations along Madrid dedicated to open source promotion, like http://madridonrails.com/, and which we could use for these meetings. I'm really looking forward to hearing from you! PS: Maybe a bare Haskell group is not big enough (at least according to Haskellers.com), but a functional programmers one may well be. ___ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Let's do it! I think that two it's enough to begin! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell / Functional Programmers Group in Madrid (Spain)?
There is one Functional Programming meetup in Madrid. The first meeting was in August. The next meeting is the 11th September (this month) . I couldn't assist in September. I hope to see you in October!. http://www.meetup.com/FP-Madrid/ 2013/9/4 Eduardo Basterrechea eba...@molinodeideas.es Alejandro Serrano Mena trupill at gmail.com writes: Hi,Is there any Haskell or functional programmers user group in the region of Madrid? If not, I think it could be a great idea to get to know each other, and share experiences. Furthermore, we could try to organize some meetings with presentations, hackatons and so on (my personal ambition is to be able to organize another ekmett Workshop as the Japanese one - http://comonad.com/reader/2013/japanese-workshop-1/). I know there is some locations along Madrid dedicated to open source promotion, like http://madridonrails.com/, and which we could use for these meetings. I'm really looking forward to hearing from you! PS: Maybe a bare Haskell group is not big enough (at least according to Haskellers.com), but a functional programmers one may well be. ___ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Let's do it! I think that two it's enough to begin! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Alberto. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Tutorial on JS with Haskell: Fay or GHCJS?
Hi, I'm currently writing a tutorial on web applications using Haskell. I know the pros and cons of each server-side library (Yesod, Snap, Scotty, Warp, Happstack), but I'm looking for the right choice for client-side programming that converts Haskell to JavaScript. I've finally come to Fay vs. GHCJS, and would like your opinion on what's the best to tackle. My current list of pros and cons is: Fay === Pros: - Does not need GHC 7.8 - Easy FFI with JS - Has libraries for integration with Yesod and Snap Cons: - Only supports a subset of GHC (in particular, no type classes) GHCJS == Pros: - Supports full GHC - Easy FFI with JS - Highly opinionated point: will stay longer than Fay (but it's very important for not having a tutorial that is old in few months) Cons: - Needs GHC 7.8 (but provides a Vagrant image) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on JS with Haskell: Fay or GHCJS?
Hi, I'm also interested in that. Have you already evaluated haste? It does not seem to have any of your cons, but maybe others. What I particularly miss from all solutions is the ability to simply call parts written in Haskell from Javascript, e.g. to write `fib` and then integrate it into an existing Javascript application (they are all more interested in doing the other direction). On Wed 04 Sep 2013 17:14:55 JST, Alejandro Serrano Mena wrote: Hi, I'm currently writing a tutorial on web applications using Haskell. I know the pros and cons of each server-side library (Yesod, Snap, Scotty, Warp, Happstack), but I'm looking for the right choice for client-side programming that converts Haskell to JavaScript. I've finally come to Fay vs. GHCJS, and would like your opinion on what's the best to tackle. My current list of pros and cons is: Fay === Pros: - Does not need GHC 7.8 - Easy FFI with JS - Has libraries for integration with Yesod and Snap Cons: - Only supports a subset of GHC (in particular, no type classes) GHCJS == Pros: - Supports full GHC - Easy FFI with JS - Highly opinionated point: will stay longer than Fay (but it's very important for not having a tutorial that is old in few months) Cons: - Needs GHC 7.8 (but provides a Vagrant image) ___ 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] Tutorial on JS with Haskell: Fay or GHCJS?
I haven't looked at Haste too much, I'll give it a try. My main problem is that I would like to find a solution that will continue working in years (somehow, that will became the solution for generating JS from Haskell code). That's why I see GHCJS (which just includes some patches to mainstream GHC) as the preferred solution, because it seems the most probable to continue working when new versions of GHC appear. 2013/9/4 Niklas Hambüchen m...@nh2.me Hi, I'm also interested in that. Have you already evaluated haste? It does not seem to have any of your cons, but maybe others. What I particularly miss from all solutions is the ability to simply call parts written in Haskell from Javascript, e.g. to write `fib` and then integrate it into an existing Javascript application (they are all more interested in doing the other direction). On Wed 04 Sep 2013 17:14:55 JST, Alejandro Serrano Mena wrote: Hi, I'm currently writing a tutorial on web applications using Haskell. I know the pros and cons of each server-side library (Yesod, Snap, Scotty, Warp, Happstack), but I'm looking for the right choice for client-side programming that converts Haskell to JavaScript. I've finally come to Fay vs. GHCJS, and would like your opinion on what's the best to tackle. My current list of pros and cons is: Fay === Pros: - Does not need GHC 7.8 - Easy FFI with JS - Has libraries for integration with Yesod and Snap Cons: - Only supports a subset of GHC (in particular, no type classes) GHCJS == Pros: - Supports full GHC - Easy FFI with JS - Highly opinionated point: will stay longer than Fay (but it's very important for not having a tutorial that is old in few months) Cons: - Needs GHC 7.8 (but provides a Vagrant image) ___ 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] Tutorial on JS with Haskell: Fay or GHCJS?
In my opinion haste is somewhere between Fay and ghcjs. It supports more than Fay, but in difference to ghcjs some PrimOps are not supported (weak pointers for example). It is a little bit more direct than ghcjs, in the sense that it does not need such a big rts written in js. I like haste :). What I wonder is how the outputs of these 3 compilers compare speed wise. On 09/04/2013 11:11 AM, Alejandro Serrano Mena wrote: I haven't looked at Haste too much, I'll give it a try. My main problem is that I would like to find a solution that will continue working in years (somehow, that will became the solution for generating JS from Haskell code). That's why I see GHCJS (which just includes some patches to mainstream GHC) as the preferred solution, because it seems the most probable to continue working when new versions of GHC appear. 2013/9/4 Niklas Hambüchen m...@nh2.me mailto:m...@nh2.me Hi, I'm also interested in that. Have you already evaluated haste? It does not seem to have any of your cons, but maybe others. What I particularly miss from all solutions is the ability to simply call parts written in Haskell from Javascript, e.g. to write `fib` and then integrate it into an existing Javascript application (they are all more interested in doing the other direction). On Wed 04 Sep 2013 17:14:55 JST, Alejandro Serrano Mena wrote: Hi, I'm currently writing a tutorial on web applications using Haskell. I know the pros and cons of each server-side library (Yesod, Snap, Scotty, Warp, Happstack), but I'm looking for the right choice for client-side programming that converts Haskell to JavaScript. I've finally come to Fay vs. GHCJS, and would like your opinion on what's the best to tackle. My current list of pros and cons is: Fay === Pros: - Does not need GHC 7.8 - Easy FFI with JS - Has libraries for integration with Yesod and Snap Cons: - Only supports a subset of GHC (in particular, no type classes) GHCJS == Pros: - Supports full GHC - Easy FFI with JS - Highly opinionated point: will stay longer than Fay (but it's very important for not having a tutorial that is old in few months) Cons: - Needs GHC 7.8 (but provides a Vagrant image) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto: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
[Haskell-cafe] Efficient matrix multiply using accelerate
I've been trying to get some speed out of the accelerate library today. What I want to implement is something as simple as a matrix multiply. I'd like it to be fast and memory efficient. Given the equation C = AB where A is nxr B is rxm C is nxm it seem reasonable to allocate three arrays on the GPU wiht n*r, r*m and n*m elements respectively. Anyone know how to achieve this with accelerate? My first thought was to use the generate function to create the new C array, but I didn't manage to wrap my head around all the fancy type features that pop up when you want to return an array C that has dimensions dependent on the dimensions of it's inputs, A and B. I've search around a bit and found this [1] example implementation but it is just as slow as a simple sequential algorithm in C. I would be very thankful for any advice for working with accelerate! Here's a snippet of what I have tried to make. There are several errors in there. Maybe I'm approaching the problem from the wrong angle. matMul' arr brr = let dotProd shp = let (Z :. rowsA :. _) = unlift (shape arr):: (Z :. Exp Int :. Exp Int) (Z :. _ :. colsB) = unlift (shape brr):: (Z :. Exp Int :. Exp Int) (Z :. i :. j) = unlift shp :: (Z :. Exp Int :. Exp Int) rs = lift (Z :. All :.) (unlift i) cs = (lift (Z :.) (unlift j)) (:. All) in the $ A.fold1All (+) $ A.zipWith (+) (flatten (slice arr rs)) (flatten (slice brr cs)) in A.generate (lift (Z :. rowsA :. colsB)) dotProd [1] http://www.mail-archive.com/haskell-cafe@haskell.org/msg102782.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on JS with Haskell: Fay or GHCJS?
You might be interested in these two comment threads (and maybe the rest of the comments as well): http://www.reddit.com/r/haskell/comments/1ldqav/thoughts_on_uhc_vs_haste_vs_fay/cbyrhwz http://www.reddit.com/r/haskell/comments/1htqi2/announce_haste_the_haskell_to_js_compiler_is_now/cay79g9?context=1 On Wed, Sep 4, 2013 at 12:36 PM, Nathan Hüsken nathan.hues...@posteo.dewrote: In my opinion haste is somewhere between Fay and ghcjs. It supports more than Fay, but in difference to ghcjs some PrimOps are not supported (weak pointers for example). It is a little bit more direct than ghcjs, in the sense that it does not need such a big rts written in js. I like haste :). What I wonder is how the outputs of these 3 compilers compare speed wise. On 09/04/2013 11:11 AM, Alejandro Serrano Mena wrote: I haven't looked at Haste too much, I'll give it a try. My main problem is that I would like to find a solution that will continue working in years (somehow, that will became the solution for generating JS from Haskell code). That's why I see GHCJS (which just includes some patches to mainstream GHC) as the preferred solution, because it seems the most probable to continue working when new versions of GHC appear. 2013/9/4 Niklas Hambüchen m...@nh2.me Hi, I'm also interested in that. Have you already evaluated haste? It does not seem to have any of your cons, but maybe others. What I particularly miss from all solutions is the ability to simply call parts written in Haskell from Javascript, e.g. to write `fib` and then integrate it into an existing Javascript application (they are all more interested in doing the other direction). On Wed 04 Sep 2013 17:14:55 JST, Alejandro Serrano Mena wrote: Hi, I'm currently writing a tutorial on web applications using Haskell. I know the pros and cons of each server-side library (Yesod, Snap, Scotty, Warp, Happstack), but I'm looking for the right choice for client-side programming that converts Haskell to JavaScript. I've finally come to Fay vs. GHCJS, and would like your opinion on what's the best to tackle. My current list of pros and cons is: Fay === Pros: - Does not need GHC 7.8 - Easy FFI with JS - Has libraries for integration with Yesod and Snap Cons: - Only supports a subset of GHC (in particular, no type classes) GHCJS == Pros: - Supports full GHC - Easy FFI with JS - Highly opinionated point: will stay longer than Fay (but it's very important for not having a tutorial that is old in few months) Cons: - Needs GHC 7.8 (but provides a Vagrant image) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing listHaskell-Cafe@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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unexpected behaviour with send and send-buffer setting
On Tue, Sep 3, 2013 at 3:56 PM, Simon Yarde simonya...@me.com wrote: I'm new to Haskell and have reached an impasse in understanding the behaviour of sockets. Your question is actually not related to Haskell at all, but is a general I don't understand socket programming question. You're being misled by the non-blocking sockets observation - this makes no difference to the behaviour of your program. I recommend picking up copies of Unix Network Programming and TCP/IP Illustrated, and reading them. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on JS with Haskell: Fay or GHCJS?
Hi, Am Mittwoch, den 04.09.2013, 14:46 +0200 schrieb Adam Bergmark: You might be interested in these two comment threads (and maybe the rest of the comments as well): http://www.reddit.com/r/haskell/comments/1ldqav/thoughts_on_uhc_vs_haste_vs_fay/cbyrhwz http://www.reddit.com/r/haskell/comments/1htqi2/announce_haste_the_haskell_to_js_compiler_is_now/cay79g9?context=1 and another data point: http://www.joachim-breitner.de/blog/archives/602-Running-Circle-Packing-in-the-Browser-using-Haste.html Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reasoning about performance
Awesome/ thanks for sharing. It's worth noting that criterion is also pretty great for microbenchmarks too. On my machine I get pretty good timing accuracy on anything that takes more than 20 nanoseconds. On Wednesday, September 4, 2013, Scott Pakin wrote: On 09/03/2013 06:02 PM, Carter Schonwald wrote: It's also worth adding that ghci does a lot less optimization than ghc. Yes, I discovered that before I posted. Note from my initial message that I used ghc to compile, then loaded the compiled module into ghci: Prelude :!ghc -c -O2 allpairs.hs Prelude :load allpairs Ok, modules loaded: AllPairs. Prelude AllPairs :m +Control.DeepSeq Prelude Control.DeepSeq AllPairs :show modules AllPairs ( allpairs.hs, allpairs.o ) Likewise, the best tool for doing performance benchmarking is the excellent Criterion library. Ah, I didn't know about Criterion; that does look useful. For the record, here's what Criterion reports for my three all-pairs implementations: Prelude Criterion.Main AllPairs defaultMain [bench allPairs1 $ nf allPairs1 [1..1]] ... mean: 5.184160 s, lb 5.156169 s, ub 5.212516 s, ci 0.950 std dev: 144.4938 ms, lb 127.3414 ms, ub 164.8774 ms, ci 0.950 Prelude Criterion.Main AllPairs defaultMain [bench allPairs2 $ nf allPairs2 [1..1]] ... mean: 2.310527 s, lb 2.290451 s, ub 2.329349 s, ci 0.950 Prelude Criterion.Main AllPairs defaultMain [bench allPairs3 $ nf allPairs3 [1..1]] ... mean: 10.05609 s, lb 10.02453 s, ub 10.08866 s, ci 0.950 As before, allPairs2 is the fastest, followed by allPairs1, with allPairs3 in last place. -- Scott ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How to read a file and return a String?
I want to read a text file, and store it in a *String*. But readFile will get *IO String*. I search with google and they tell me it is not necessarily to do so. Can you explain to me why is this? Furthermore, How to read a file and store it in a String? In fact, I want to read a file and split it into *[String]* with *lines*function. Here is what I have tried. linkhttps://github.com/eccstartup/findDict/blob/master/src/Data/Dict/Utils.hsI think I could directly operate on *[String]*. But it is not true for me. [1] http://www.haskell.org/hoogle/?hoogle=IO+String+-%3E+String Yi Lu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on JS with Haskell: Fay or GHCJS?
Hi!
On Sep 4, 2013, at 13:02, Niklas Hambüchen m...@nh2.me wrote:
Hi, I'm also interested in that.
Have you already evaluated haste?
It does not seem to have any of your cons, but maybe others.
What I particularly miss from all solutions is the ability to simply
call parts written in Haskell from Javascript, e.g. to write `fib` and
then integrate it into an existing Javascript application (they are all
more interested in doing the other direction).
So, I don't how Fay handles things but I can say the following about GHCJS:
I have to admit that it's not that easy to call Haskell from
JavaScript as I want it.
However, there are several functions you can use for doing that. GHCJS
supports running actions in main asynchronous threads (application
is considered to be terminated when the thread is finished), regular
asynchronous threads and synchronous threads. Since you want to call
pure Haskell code you probably want to use runSync.
One way to do that would be to use an intermediate object to store the
result of calling Fib:
fib :: Int - Int
fib n = fibs !! n
where fibs = 0:1:zipWith (+) fibs (tail fibs)
fibAction :: JSRef () - Int - IO ()
fibAction ref n = do
res - toJSRef (fib n)
setProp (result::Text) res ref
function go() {
var i = parseInt($(#num).val(), 10);
var o = { result : null };
var oref = mkJSRefNew(o);
var act = h$c3( h$ap2_e
, h$mainZCMainzifibAction
, oref
, i );
h$runSync(act);
$(#result).text(o.result);
};
You can find the complete sourcecode and a runnable executable here:
http://co-dan.github.io/ghcjs/examples/Fib.hs
http://co-dan.github.io/ghcjs/examples/Fib/index.html
I think it's nice that you've raised that question, I will think about
implementing a finer API for calling Haskell from JS.
NB: It also sounds like you might benefit from the non-concurrent
GHCJS runtime and codegen that Luite is now porting to the new API.
Since you plan to implement your interface/interactions in JS you
probably don't need support for concurrency and you can enjoy smaller
code rts sizes.
On Wed 04 Sep 2013 17:14:55 JST, Alejandro Serrano Mena wrote:
Hi,
I'm currently writing a tutorial on web applications using Haskell. I
know the pros and cons of each server-side library (Yesod, Snap,
Scotty, Warp, Happstack), but I'm looking for the right choice for
client-side programming that converts Haskell to JavaScript. I've
finally come to Fay vs. GHCJS, and would like your opinion on what's
the best to tackle. My current list of pros and cons is:
Fay
===
Pros:
- Does not need GHC 7.8
- Easy FFI with JS
- Has libraries for integration with Yesod and Snap
Cons:
- Only supports a subset of GHC (in particular, no type classes)
GHCJS
==
Pros:
- Supports full GHC
- Easy FFI with JS
- Highly opinionated point: will stay longer than Fay (but it's very
important for not having a tutorial that is old in few months)
Cons:
- Needs GHC 7.8 (but provides a Vagrant image)
___
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] Tutorial on JS with Haskell: Fay or GHCJS?
Here are some points I'd like to emphasize in addition to the threads above, with the disclaimer that I'm the maintainer of Fay. Fay tries to be very simple, the code base is small (~4800 LoC). This really lowers the entry barrier for contributions which I think is very important for open source projects. GHCJS is much more complicated since it tries to do so much. For GHCJS I'd be afraid that the developers might eventually abandon the project and then it'd be pretty hard to take over development. Much easier for someone to take over Fay development. I think you can safely expect to find bugs in all compilers, and if you do and you are in a hurry you might have to fix it yourself. Fay has very simple output that is close to both Haskell and JavaScript so it's pretty easy to just add a breakpoint and start debugging. Even if GHCJS can successfully compile most of hackage, would we want to have these as dependencies in web projects? An output size of 1MiB is nothing when compiling a binary, but for a public website 1MiB can still be quite a lot, add some transitive dependencies and output will explode. Most people don't optimize their packages to have few dependencies, which makes sense since the abstraction usually heavily outweighs code size. So either way you would probably want to write some specific light-weight versions of libraries you want to use, that's one reason both GHCJS and Fay have their own base packages. One place I think GHCJS can shine is for non standard web applications such as WEBGL games. Nothing stopping you from using Fay for this, but I expect you can really start to leverage GHCJS's threaded runtime here. I'm not sure if GHCJS or Haste have any out of the box solutions for doing client-server communication. In Fay you can just serialize any data type automatically on the front and backend to a json format and then deserialize it automatically again on the other end. You can also leverage phantom types ( https://github.com/fpco/yesod-fay/blob/master/Language/Fay/Yesod.hs#L41) to typecheck this communication. It's hard to know how well GHCJS performs in a real web application. FP Complete uses Fay for their IDE and School of Haskell so it has been battle tested, so if you want something that definitely works today I think Fay is the more reliable option. It is possible that GHCJS will eventually supercede Fay. But if you want something that's easy to use today you can always write Fay, and then convert it to GHCJS later since Fay is a subset of Haskell. I think GHCJS needs more time to prove itself. I know the developers are hard at work and I hope they will focus on a lot of learning materials. Once you can `cabal install ghcjs` and just get started I think they will see a lot more interest coming their way. Let me know if you have more questions. If you decide to use Fay in your tutorial I'd be happy to help out, just send me an e-mail! - Adam On Wed, Sep 4, 2013 at 2:46 PM, Adam Bergmark a...@edea.se wrote: You might be interested in these two comment threads (and maybe the rest of the comments as well): http://www.reddit.com/r/haskell/comments/1ldqav/thoughts_on_uhc_vs_haste_vs_fay/cbyrhwz http://www.reddit.com/r/haskell/comments/1htqi2/announce_haste_the_haskell_to_js_compiler_is_now/cay79g9?context=1 On Wed, Sep 4, 2013 at 12:36 PM, Nathan Hüsken nathan.hues...@posteo.dewrote: In my opinion haste is somewhere between Fay and ghcjs. It supports more than Fay, but in difference to ghcjs some PrimOps are not supported (weak pointers for example). It is a little bit more direct than ghcjs, in the sense that it does not need such a big rts written in js. I like haste :). What I wonder is how the outputs of these 3 compilers compare speed wise. On 09/04/2013 11:11 AM, Alejandro Serrano Mena wrote: I haven't looked at Haste too much, I'll give it a try. My main problem is that I would like to find a solution that will continue working in years (somehow, that will became the solution for generating JS from Haskell code). That's why I see GHCJS (which just includes some patches to mainstream GHC) as the preferred solution, because it seems the most probable to continue working when new versions of GHC appear. 2013/9/4 Niklas Hambüchen m...@nh2.me Hi, I'm also interested in that. Have you already evaluated haste? It does not seem to have any of your cons, but maybe others. What I particularly miss from all solutions is the ability to simply call parts written in Haskell from Javascript, e.g. to write `fib` and then integrate it into an existing Javascript application (they are all more interested in doing the other direction). On Wed 04 Sep 2013 17:14:55 JST, Alejandro Serrano Mena wrote: Hi, I'm currently writing a tutorial on web applications using Haskell. I know the pros and cons of each server-side library (Yesod, Snap, Scotty, Warp, Happstack), but I'm looking for the right choice for client-side
Re: [Haskell-cafe] How to read a file and return a String?
On Wed, Sep 4, 2013 at 10:21 AM, yi lu zhiwudazhanjiang...@gmail.comwrote: I want to read a text file, and store it in a *String*. But readFile will get *IO String*. I search with google and they tell me it is not necessarily to do so. Can you explain to me why is this? Furthermore, How to read a file and store it in a String? You do not do so directly. An IO action is a promise to produce a value, not an actual value. (readFile contains a String in the same way the ls or dir command contains a list of files.) I suggest you take a look at http://learnyouahaskell.com/input-and-output#files-and-streams to see how IO works in Haskell. tl;dr: use do notation (which lets you pretend to a limited extent that you can see the String in an IO String) or = or fmap to attach a callback to the IO promise. readFile = (something that operates on a String and produces an IO whatever) do s - readFile (something that operates on a String and produces an IO whatever) Note that in the end it's still in IO. You can't escape it. (There are actually ways to escape but they will get you into trouble fairly quickly because they don't work the way you want them to.) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Strange IO sequence behaviour (Was: sequence causing stack overflow on pretty small lists)
As an addendum to the recent discussion, can anyone explain why main crashes quickly with a stack overflow, whereas main' is happy to print Hi for ages (eventually crashing due to an out of memory condition)? bignum = 100 * 1000 * 1000 main = replicateM bignum (return ()) main' = replicateM bignum (putStrLn Hi) Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to read a file and return a String?
On Wed, Sep 04, 2013 at 10:21:37PM +0800, yi lu wrote: I want to read a text file, and store it in a *String*. But readFile will get *IO String*. I search with google and they tell me it is not necessarily to do so. Can you explain to me why is this? Furthermore, How to read a file and store it in a String? You need to lift 'lines' into the IO functor, rather than trying to remove the String from IO (which doesn't make sense). Try fmap lines (readFile filename) Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reasoning about performance
On 09/03/2013 06:02 PM, Carter Schonwald wrote: It's also worth adding that ghci does a lot less optimization than ghc. Yes, I discovered that before I posted. Note from my initial message that I used ghc to compile, then loaded the compiled module into ghci: Prelude :!ghc -c -O2 allpairs.hs Prelude :load allpairs Ok, modules loaded: AllPairs. Prelude AllPairs :m +Control.DeepSeq Prelude Control.DeepSeq AllPairs :show modules AllPairs ( allpairs.hs, allpairs.o ) Likewise, the best tool for doing performance benchmarking is the excellent Criterion library. Ah, I didn't know about Criterion; that does look useful. For the record, here's what Criterion reports for my three all-pairs implementations: Prelude Criterion.Main AllPairs defaultMain [bench allPairs1 $ nf allPairs1 [1..1]] ... mean: 5.184160 s, lb 5.156169 s, ub 5.212516 s, ci 0.950 std dev: 144.4938 ms, lb 127.3414 ms, ub 164.8774 ms, ci 0.950 Prelude Criterion.Main AllPairs defaultMain [bench allPairs2 $ nf allPairs2 [1..1]] ... mean: 2.310527 s, lb 2.290451 s, ub 2.329349 s, ci 0.950 Prelude Criterion.Main AllPairs defaultMain [bench allPairs3 $ nf allPairs3 [1..1]] ... mean: 10.05609 s, lb 10.02453 s, ub 10.08866 s, ci 0.950 As before, allPairs2 is the fastest, followed by allPairs1, with allPairs3 in last place. -- Scott ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on JS with Haskell: Fay or GHCJS?
On Wed, Sep 4, 2013 at 6:32 PM, Daniil Frumin difru...@gmail.com wrote: I think it's nice that you've raised that question, I will think about implementing a finer API for calling Haskell from JS. It sounds like something like h$runSyncWithResult (name open for bikeshedding) that takes an IO (JSRef a) and returns the result to the caller, or null (exception?) when the synchronous thread terminated for some reason, would fit the bill. I think this can be implemented in a few lines of JS. the current API is a bit bare-bones, based around calling main or a few other top-level IO actions and doing the rest from Haskell code. The Haskell code can make callbacks (JS functions that run Haskell when called, see [1] ), but that can be a bit cumbersome to use when wrapping a library with lots of external JavaScript. If anyone has ideas of how they'd like a call-Haskell-functions-from-JS API to look, I'd be happy to hear and see if we can make something nice. One thing to keep in mind though is that type information has been erased from the compiled code, making a generic applyHaskellFun(fun,x,y) that would run 'fun x y' and return its result would be rather risky. That's why the syncCallback/asyncCallback actions use JSRef, letting the Haskell side do the conversion. Going through 'foreign export' could work though, or perhaps there are other options that make this safer. luite ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: Haskell Refactorer (HaRe) version 0.7.0.0
I am please to announce an alpha release of the Haskell Refactorer making use of the GHC API. It is a work in progress, but currently supports the following refactorings iftocase Convert an if expression to a case expression dupdef Duplicate a definition liftToTopLevel Lift a declaration to the top level liftOneLevel Lift a declaration one level demote Move a declaration down one level rename Rename an identifier It offers emacs integration only at this point, based on the Wrangler elisp. The underlying environment in terms of cabal file, sandbox, etc are managed by ghc-mod via the internals exposed in version 2.1.2 There are some known issues (and bound to be plenty of unknown ones too). The most damaging of these is that layout is not adjusted after renaming an identifier if the new name is a different length. This affects layout-sensitive code. Installation instructions can be found at https://github.com/alanz/HaRe/blob/master/README.markdown Regards Alan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on JS with Haskell: Fay or GHCJS?
I second the recommendation to look at Haste. It's what I would pick for a project like this today. In the big picture, Haste and GHCJS are fairly similar. But when it comes to the ugly details of the runtime system, GHCJS adopts the perspective that it's basically an emulator, where compatibility is the number one goal. Haste goes for a more native approach; while the evaluation semantics and such are completely faithful to Haskell, it doesn't go out of the way to emulate the gritty details of GHC's runtime system. On Sep 4, 2013 3:38 AM, Nathan Hüsken nathan.hues...@posteo.de wrote: In my opinion haste is somewhere between Fay and ghcjs. It supports more than Fay, but in difference to ghcjs some PrimOps are not supported (weak pointers for example). It is a little bit more direct than ghcjs, in the sense that it does not need such a big rts written in js. I like haste :). What I wonder is how the outputs of these 3 compilers compare speed wise. On 09/04/2013 11:11 AM, Alejandro Serrano Mena wrote: I haven't looked at Haste too much, I'll give it a try. My main problem is that I would like to find a solution that will continue working in years (somehow, that will became the solution for generating JS from Haskell code). That's why I see GHCJS (which just includes some patches to mainstream GHC) as the preferred solution, because it seems the most probable to continue working when new versions of GHC appear. 2013/9/4 Niklas Hambüchen m...@nh2.me Hi, I'm also interested in that. Have you already evaluated haste? It does not seem to have any of your cons, but maybe others. What I particularly miss from all solutions is the ability to simply call parts written in Haskell from Javascript, e.g. to write `fib` and then integrate it into an existing Javascript application (they are all more interested in doing the other direction). On Wed 04 Sep 2013 17:14:55 JST, Alejandro Serrano Mena wrote: Hi, I'm currently writing a tutorial on web applications using Haskell. I know the pros and cons of each server-side library (Yesod, Snap, Scotty, Warp, Happstack), but I'm looking for the right choice for client-side programming that converts Haskell to JavaScript. I've finally come to Fay vs. GHCJS, and would like your opinion on what's the best to tackle. My current list of pros and cons is: Fay === Pros: - Does not need GHC 7.8 - Easy FFI with JS - Has libraries for integration with Yesod and Snap Cons: - Only supports a subset of GHC (in particular, no type classes) GHCJS == Pros: - Supports full GHC - Easy FFI with JS - Highly opinionated point: will stay longer than Fay (but it's very important for not having a tutorial that is old in few months) Cons: - Needs GHC 7.8 (but provides a Vagrant image) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing listHaskell-Cafe@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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on JS with Haskell: Fay or GHCJS?
Niklas: I missed your note about calling Haskell from JS, see this for Fay: https://github.com/faylang/fay/wiki/Fay-Status-Update-September-2013%3A-ZuriHac%2C-typeclasses%2C-haskell-suite%2C-and-strictness-wrappers#javascript-fay-communication On Wed, Sep 4, 2013 at 8:18 PM, Luite Stegeman stege...@gmail.com wrote: On Wed, Sep 4, 2013 at 6:32 PM, Daniil Frumin difru...@gmail.com wrote: I think it's nice that you've raised that question, I will think about implementing a finer API for calling Haskell from JS. It sounds like something like h$runSyncWithResult (name open for bikeshedding) that takes an IO (JSRef a) and returns the result to the caller, or null (exception?) when the synchronous thread terminated for some reason, would fit the bill. I think this can be implemented in a few lines of JS. the current API is a bit bare-bones, based around calling main or a few other top-level IO actions and doing the rest from Haskell code. The Haskell code can make callbacks (JS functions that run Haskell when called, see [1] ), but that can be a bit cumbersome to use when wrapping a library with lots of external JavaScript. If anyone has ideas of how they'd like a call-Haskell-functions-from-JS API to look, I'd be happy to hear and see if we can make something nice. One thing to keep in mind though is that type information has been erased from the compiled code, making a generic applyHaskellFun(fun,x,y) that would run 'fun x y' and return its result would be rather risky. That's why the syncCallback/asyncCallback actions use JSRef, letting the Haskell side do the conversion. Going through 'foreign export' could work though, or perhaps there are other options that make this safer. luite ___ 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] Strange IO sequence behaviour (Was: sequence causing stack overflow on pretty small lists)
To give a very casual explanation, both mains are of the form do this a bunch of times and return the results. Your first is do nothing and return the ()s, but importantly, it has to execute all those nothings. Your second is print hello a bunch and return the ()s. The list it wants to eventually return gets bigger and bigger as more prints happen, until poof! You should look at how replicateM works again, and hopefully it will make more sense with that in mind. On Sep 4, 2013 11:35 AM, Tom Ellis tom-lists-haskell-cafe-2...@jaguarpaw.co.uk wrote: As an addendum to the recent discussion, can anyone explain why main crashes quickly with a stack overflow, whereas main' is happy to print Hi for ages (eventually crashing due to an out of memory condition)? bignum = 100 * 1000 * 1000 main = replicateM bignum (return ()) main' = replicateM bignum (putStrLn Hi) Tom ___ 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] Strange IO sequence behaviour (Was: sequence causing stack overflow on pretty small lists)
Er, I seem to have misread and thought you were doing infinite replicateM, so that explanation doesn't completely address your question. That's what I get for reading on a phone! On Sep 4, 2013 4:11 PM, Joe Q headprogrammingc...@gmail.com wrote: To give a very casual explanation, both mains are of the form do this a bunch of times and return the results. Your first is do nothing and return the ()s, but importantly, it has to execute all those nothings. Your second is print hello a bunch and return the ()s. The list it wants to eventually return gets bigger and bigger as more prints happen, until poof! You should look at how replicateM works again, and hopefully it will make more sense with that in mind. On Sep 4, 2013 11:35 AM, Tom Ellis tom-lists-haskell-cafe-2...@jaguarpaw.co.uk wrote: As an addendum to the recent discussion, can anyone explain why main crashes quickly with a stack overflow, whereas main' is happy to print Hi for ages (eventually crashing due to an out of memory condition)? bignum = 100 * 1000 * 1000 main = replicateM bignum (return ()) main' = replicateM bignum (putStrLn Hi) Tom ___ 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] ANN: Cabal v1.18.0 released
Hi all, On behalf of the cabal maintainers and contributors I'm proud to announce the Cabal (and cabal-install) 1.18.0 release. To install run cabal update cabal install Cabal-1.18.0 cabal-install-1.18.0 With 854 commits since the last release there are two many improvements and bug fixes to list them here, but two highlights are: * Hermetic builds using sandboxes. This should reduce the number of dependency hell and broken package DB problems. * GHCi support. It's now much easier to use ghci when developing your packages, especially if those packages require preprocessors (e.g. hsc2hs). Here's how working on a package might look like using the new features: # Only once: cabal sandbox init cabal install --only-dependencies --enable-tests # Configure, build, and run tests: cabal test # now implies configure and build # Play around with the code in GHCi: cabal repl Mikhail wrote a bit more about the user visible changes on his blog: http://coldwa.st/e/blog/2013-08-21-Cabal-1-18.html For a complete list of changes run git log cabal-install-v1.16.0.2..cabal-install-v1.18.0 in the cabal repo or look at the GitHub compare page: https://github.com/haskell/cabal/compare/cabal-install-v1.16.0.2...cabal-install-v1.18.0 (only shows the last 250 commits). 57 people contributed to this release! 503 Mikhail Glushenkov 99 Johan Tibell 41 Duncan Coutts 39 Ian Lynagh 19 Brent Yorgey 19 Thomas Tuegel 18 Ben Millwood 16 Eyal Lotem 10 Thomas Dziedzic 7 Andres Loeh 6 John Wiegley 6 Benno Fünfstück 5 Gregory Collins 4 Herbert Valerio Riedel 4 Simon Hengel 3 Joachim Breitner 3 Luke Iannini 3 Bryan Richter 3 Richard Eisenberg 3 Tuncer Ayaz 3 Jens Petersen 2 Arun Tejasvi Chaganty 2 Bryan O'Sullivan 2 Eric Kow 2 Jookia 2 Paolo G. Giarrusso 2 Paolo Capriotti 1 Sönke Hahn 1 Yitzchak Gale 1 Albert Krewinkel 1 stepcut 1 Alexander Kjeldaas 1 Austin Seipp 1 Bardur Arantsson 1 Ben Doyle 1 Ben Gamari 1 Bram 1 Carter Tazio Schonwald 1 Clint Adams 1 Daniel Wagner 1 David Lazar 1 Erik Hesselink 1 Eugene Sukhodolin 1 Gabor Greif 1 Jack Henahan 1 Jason Dagit 1 Ken Bateman 1 Mark Lentczner 1 Masahiro Yamauchi 1 Merijn Verstraaten 1 Michael Thompson 1 Niklas Hambüchen 1 Oleksandr Manzyuk 1 Patrick Premont 1 Roman Cheplyaka 1 Sergei Trofimovich 1 Stephen Blackheath -- Johan, on behalf of the cabal maintainers and contributors. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Cabal v1.18.0 released
Thank you all for the hard work. The new features are already of great help to me! Cheers, Darren On 2013-09-04 2:13 PM, Johan Tibell johan.tib...@gmail.com wrote: Hi all, On behalf of the cabal maintainers and contributors I'm proud to announce the Cabal (and cabal-install) 1.18.0 release. To install run cabal update cabal install Cabal-1.18.0 cabal-install-1.18.0 With 854 commits since the last release there are two many improvements and bug fixes to list them here, but two highlights are: * Hermetic builds using sandboxes. This should reduce the number of dependency hell and broken package DB problems. * GHCi support. It's now much easier to use ghci when developing your packages, especially if those packages require preprocessors (e.g. hsc2hs). Here's how working on a package might look like using the new features: # Only once: cabal sandbox init cabal install --only-dependencies --enable-tests # Configure, build, and run tests: cabal test # now implies configure and build # Play around with the code in GHCi: cabal repl Mikhail wrote a bit more about the user visible changes on his blog: http://coldwa.st/e/blog/2013-08-21-Cabal-1-18.html For a complete list of changes run git log cabal-install-v1.16.0.2..cabal-install-v1.18.0 in the cabal repo or look at the GitHub compare page: https://github.com/haskell/cabal/compare/cabal-install-v1.16.0.2...cabal-install-v1.18.0 (only shows the last 250 commits). 57 people contributed to this release! 503 Mikhail Glushenkov 99 Johan Tibell 41 Duncan Coutts 39 Ian Lynagh 19 Brent Yorgey 19 Thomas Tuegel 18 Ben Millwood 16 Eyal Lotem 10 Thomas Dziedzic 7 Andres Loeh 6 John Wiegley 6 Benno Fünfstück 5 Gregory Collins 4 Herbert Valerio Riedel 4 Simon Hengel 3 Joachim Breitner 3 Luke Iannini 3 Bryan Richter 3 Richard Eisenberg 3 Tuncer Ayaz 3 Jens Petersen 2 Arun Tejasvi Chaganty 2 Bryan O'Sullivan 2 Eric Kow 2 Jookia 2 Paolo G. Giarrusso 2 Paolo Capriotti 1 Sönke Hahn 1 Yitzchak Gale 1 Albert Krewinkel 1 stepcut 1 Alexander Kjeldaas 1 Austin Seipp 1 Bardur Arantsson 1 Ben Doyle 1 Ben Gamari 1 Bram 1 Carter Tazio Schonwald 1 Clint Adams 1 Daniel Wagner 1 David Lazar 1 Erik Hesselink 1 Eugene Sukhodolin 1 Gabor Greif 1 Jack Henahan 1 Jason Dagit 1 Ken Bateman 1 Mark Lentczner 1 Masahiro Yamauchi 1 Merijn Verstraaten 1 Michael Thompson 1 Niklas Hambüchen 1 Oleksandr Manzyuk 1 Patrick Premont 1 Roman Cheplyaka 1 Sergei Trofimovich 1 Stephen Blackheath -- Johan, on behalf of the cabal maintainers and contributors. ___ 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: Cabal v1.18.0 released
Thanks for all the hard work! If you see this in OSX (#1009) while installing cabal 1.18: *Warning: could not create a symlink in /Users/lemao/Library/Haskell/bin for * *cabal because the file exists there already but is not managed by cabal. You* *can create a symlink for this executable manually if you wish. The executable* *file has been installed at* */Users/user/Library/Haskell/ghc-7.6.3/lib/cabal-install-1.18.0/bin/cabal* You will need to manually remove the pre-existing 1.16 links in ~/Library/Haskell/bin before installing again. On Wed, Sep 4, 2013 at 5:11 PM, Johan Tibell johan.tib...@gmail.com wrote: Hi all, On behalf of the cabal maintainers and contributors I'm proud to announce the Cabal (and cabal-install) 1.18.0 release. To install run cabal update cabal install Cabal-1.18.0 cabal-install-1.18.0 With 854 commits since the last release there are two many improvements and bug fixes to list them here, but two highlights are: * Hermetic builds using sandboxes. This should reduce the number of dependency hell and broken package DB problems. * GHCi support. It's now much easier to use ghci when developing your packages, especially if those packages require preprocessors (e.g. hsc2hs). Here's how working on a package might look like using the new features: # Only once: cabal sandbox init cabal install --only-dependencies --enable-tests # Configure, build, and run tests: cabal test # now implies configure and build # Play around with the code in GHCi: cabal repl Mikhail wrote a bit more about the user visible changes on his blog: http://coldwa.st/e/blog/2013-08-21-Cabal-1-18.html For a complete list of changes run git log cabal-install-v1.16.0.2..cabal-install-v1.18.0 in the cabal repo or look at the GitHub compare page: https://github.com/haskell/cabal/compare/cabal-install-v1.16.0.2...cabal-install-v1.18.0 (only shows the last 250 commits). 57 people contributed to this release! 503 Mikhail Glushenkov 99 Johan Tibell 41 Duncan Coutts 39 Ian Lynagh 19 Brent Yorgey 19 Thomas Tuegel 18 Ben Millwood 16 Eyal Lotem 10 Thomas Dziedzic 7 Andres Loeh 6 John Wiegley 6 Benno Fünfstück 5 Gregory Collins 4 Herbert Valerio Riedel 4 Simon Hengel 3 Joachim Breitner 3 Luke Iannini 3 Bryan Richter 3 Richard Eisenberg 3 Tuncer Ayaz 3 Jens Petersen 2 Arun Tejasvi Chaganty 2 Bryan O'Sullivan 2 Eric Kow 2 Jookia 2 Paolo G. Giarrusso 2 Paolo Capriotti 1 Sönke Hahn 1 Yitzchak Gale 1 Albert Krewinkel 1 stepcut 1 Alexander Kjeldaas 1 Austin Seipp 1 Bardur Arantsson 1 Ben Doyle 1 Ben Gamari 1 Bram 1 Carter Tazio Schonwald 1 Clint Adams 1 Daniel Wagner 1 David Lazar 1 Erik Hesselink 1 Eugene Sukhodolin 1 Gabor Greif 1 Jack Henahan 1 Jason Dagit 1 Ken Bateman 1 Mark Lentczner 1 Masahiro Yamauchi 1 Merijn Verstraaten 1 Michael Thompson 1 Niklas Hambüchen 1 Oleksandr Manzyuk 1 Patrick Premont 1 Roman Cheplyaka 1 Sergei Trofimovich 1 Stephen Blackheath -- Johan, on behalf of the cabal maintainers and contributors. ___ cabal-devel mailing list cabal-de...@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] type constructor section for (- Bool), _not_ ((-) Bool)
Brent Yorgey byorgey at seas.upenn.edu writes: On Tue, Sep 03, 2013 at 11:33:46AM +, AntC wrote: I want an instance and type improvement constraint of the form instance (f ~ (- Bool)) = C Foo (f b) where ... There is no operator section syntax for types. Moreover, this is not just an issue of syntax: it is impossible to partially apply a type constructor to anything other than its first argument, because there is no type-level lambda. Thank you Brent, so I'm not being entirely dumb ;-). data FlipFun b -- abstract instance (f ~ FlipFun) = C Foo (f b) where ... And a type function inside the class to generate the type. But then I'd have to apply the type function for all instances, and in most places it'd be id. That's the only way to do it that I know of. OK, I've got that working. My class is a helper doing type discrimination. So the constraints have 'infected' the caller and the caller's caller, etc ... Elegant it ain't. AntC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reasoning about performance
On 09/03/2013 05:43 PM, Bob Ippolito wrote: Haskell's non-strict evaluation can often lead to unexpected results when doing tail recursion if you're used to strict functional programming languages. In order to get the desired behavior you will need to force the accumulator (with something like Data.List's foldl', $!, seq, BangPatterns, etc.). I had previously tried BangPatterns and recall it not making any difference. However, this result now makes sense given what you described in terms of tail recursion thwarting some of the benefits of non-strict evaluation. I think what's happening with allPairs2 is that GHC is throwing away the the list during the traversal since the result of the computation isn't used at all. I get very different timings (still fast, but no longer orders of magnitude difference) for allPairs2 if the result is still around. You could probably figure this out with the heap profiler. h deepseq (allPairs2 [1..1]) True True (2.47 secs, 4403724176 bytes) h let x = allPairs2 [1..1] (0.00 secs, 510488 bytes) h deepseq x True True (10.47 secs, 4401625192 bytes) h deepseq x True True (2.21 secs, 1031864 bytes) Ah, I hadn't thought about that. Even though deepseq is forcing the complete evaluation, it can discard evaluated results (and maybe even deforest) in the lazy allPairs1 and allPairs2 implementations but not in the tail-recursive-but-not-lazy allPairs3. Using your let trick to prevent the result from being discarded cases caused my memory subsystem to scream in pain in all three cases. I had to reduce the problem size quite a bit and still ended up spending hours of real time in GC. With this approach, allPairs1 and allPairs2 take an equal amount of time and roughly equal amounts of memory. allPairs3 takes twice as long and uses a bit more than half the memory: Prelude Control.DeepSeq System.Mem AllPairs let x = allPairs1 [1..4000] (0.00 secs, 512968 bytes) Prelude Control.DeepSeq System.Mem AllPairs performGC (1.31 secs, 1113528 bytes) Prelude Control.DeepSeq System.Mem AllPairs deepseq x True True (0.74 secs, 641687568 bytes) Prelude Control.DeepSeq System.Mem AllPairs let x = allPairs2 [1..4000] (0.00 secs, 510144 bytes) Prelude Control.DeepSeq System.Mem AllPairs performGC (3.53 secs, 848312 bytes) Prelude Control.DeepSeq System.Mem AllPairs deepseq x True True (0.74 secs, 705185688 bytes) Prelude Control.DeepSeq System.Mem AllPairs let x = allPairs3 [1..4000] (0.01 secs, 510072 bytes) Prelude Control.DeepSeq System.Mem AllPairs performGC (27.00 secs, 956096 bytes) Prelude Control.DeepSeq System.Mem AllPairs deepseq x True True (1.54 secs, 385915160 bytes) Thanks for the explanation, -- Scott ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Efficient matrix multiply using accelerate
Hi Morten, On 04/09/2013, at 9:53 PM, Morten Olsen Lysgaard mor...@lysgaard.no wrote: I've been trying to get some speed out of the accelerate library today. What I want to implement is something as simple as a matrix multiply. I'd like it to be fast and memory efficient. Well, the trouble with something like matrix multiply is that it is only simple conceptually. Making it fast and memory [bandwidth] efficient is another matter entirely, GPU or otherwise. Anyone know how to achieve this with accelerate? My first thought was to use the generate function to create the new C array, but I didn't manage to wrap my head around all the fancy type features that pop up when you want to return an array C that has dimensions dependent on the dimensions of it's inputs, A and B. If in doubt, add a type signature; sometimes you need to help GHC's type checker along a bit. Typically this comes up when constructing/deconstructing things using lift/unlift respectively, which you'll need to do to unpack shapes indices. I've search around a bit and found this [1] example implementation but it is just as slow as a simple sequential algorithm in C. What kind of GPU are you running on? Also I haven't benchmarked that matrix multiply code, but I am not overly surprised --- it wasn't designed to be efficient. Here's a snippet of what I have tried to make. There are several errors in there. Maybe I'm approaching the problem from the wrong angle. matMul' arr brr = let dotProd shp = let (Z :. rowsA :. _) = unlift (shape arr):: (Z :. Exp Int :. Exp Int) (Z :. _ :. colsB) = unlift (shape brr):: (Z :. Exp Int :. Exp Int) (Z :. i :. j) = unlift shp :: (Z :. Exp Int :. Exp Int) rs = lift (Z :. All :.) (unlift i) cs = (lift (Z :.) (unlift j)) (:. All) in the $ A.fold1All (+) $ A.zipWith (+) (flatten (slice arr rs)) (flatten (slice brr cs)) in A.generate (lift (Z :. rowsA :. colsB)) dotProd Yeah, this introduces nested parallelism, because each thread (scalar computation) in the generate function is trying to initiate new parallel computation via dotProd. Anyway, even if it did work, you'd still perform the same number of memory transfers as the replicate-based version you linked to earlier [1]. There is a bit more of an explanation of how reduction works in Accelerate at [2], slide 44. I am thinking about how to implement some shared memory optimisations, but that isn't likely to be ready soon. If you want truly fast matrix multiply, Accelerate has an escape hatch --- there is a foreign function interface, so you can just call into the matrix multiply routine provided by, for example, the CUBLAS library. Cheers, -Trev [1] http://www.mail-archive.com/haskell-cafe@haskell.org/msg102746.html [2] http://www.cse.unsw.edu.au/~tmcdonell/presentations/2013-lambdajam-workshop.pdf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to read a file and return a String?
The original poster wants to - read a file - get the contents as a String - break the string into lines - do something with the lines - and presumably print the result Easy. Put the following lines in a file called 'rf.hs': file_name = rf.hs main = readFile file_name = \string - putStr (process (lines string)) process lines = maximum lines ++ \n Then m% ghc rf.hs m% ./rf = process lines = maximum lines ++ \n Explanation: readFile file_name is an IO action which when performed will read the named file and deliver a string cmd1 = \x - cmd2 is an IO action which when performed will first perform cmd1, then bind its result to x, and then perform cmd2. = is the fundamental operation for chaining actions together. lines is a plain old String - [String] function process is a plain old [String] - String function, whatever you want putStr x is an IO action which when performed will write x The run time environment causes main to be performed. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
