Re: [Haskell-cafe] Re: A typeclass for Data.Map etc?

[wren ng thornton]

Achim Schneider wrote:

wren ng thornton  wrote:
> (b) allows 
> instances to have a fixed type for keys (like Data.Trie and
> Data.IntMap have), 


Can't we do some type magic to automagically select Data.Trie if the
key is a (strict) bytestring?


Uh, sure. I was thinking more that some ancient proposals for a map 
interface required that the instance be polymorphic in the keys. Not all 
maps are polymorphic in the keys, ergo...


--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hoogle and Network.Socket

[Magnus Therning]

Neil Mitchell wrote:
> Hi
> 
>> 1) Show all the functions (when the number is low), but place platform
>> specific functions under separate headers: "Windows",
>> "Linux/BSD/POSIX", "OS X", etc.
> 
> If a function isn't available on all OS's then all Hoogle would be
> encouraging you to do is break compatibility and stop me from using
> your software. If a function is only available on one OS you will
> certainly have to deliberately choose to search for that, and it will
> never show up by default.

I see your point, but why make Hoogle less usable for people interested
in writing platform-specific software in Haskell?  Will you really ever
be interested in running a tool that "debianises" a cabalised Haskell
library?

I've on several occasions been irritated that hoogle doesn't cover
platform-specific APIs.  I've written platform-specific software for
both Windows (e.g. pretty-printing SDDL) and Linux/Unix (e.g.
ptrace-based debugging) and in both cases I'm bitten by this lack in
hoogle.  Since then I've found Hayoo! and have partly switched to using
it instead.

> For what shows up by default I more meant other packages. Should
> Gtk2hs show up by default? What about tagsoup? What about base? Things
> like Win32 will never show up by default.

IMHO hoogle should show all standard libraries (x-platform and platform
specific) as well as _everything_ on hackage.  This would of course mean
that the UI must show whether a function is x-platform or not.

/M

-- 
Magnus Therning(OpenPGP: 0xAB4DFBA4)
magnus＠therning．org  Jabber: magnus＠therning．org
http://therning.org/magnus identi.ca|twitter: magthe

Haskell is an even 'redder' pill than Lisp or Scheme.
 -- PaulPotts



signature.asc
Description: OpenPGP digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hoogle and Network.Socket

[Martijn van Steenbergen]

Hi Neil,

Neil Mitchell wrote:

If a function isn't available on all OS's then all Hoogle would be
encouraging you to do is break compatibility and stop me from using
your software. If a function is only available on one OS you will
certainly have to deliberately choose to search for that, and it will
never show up by default.

For what shows up by default I more meant other packages. Should
Gtk2hs show up by default? What about tagsoup? What about base? Things
like Win32 will never show up by default.


How about allowing an extra search flag +windows that reveals 
windows-specific APIs? Likewise for other OS's.


Being able to enable API for a specific package requires me knowing in 
what package I want to look, while an OS flag doesn't, all the while 
still making very explicit I want to look for OS-specific API.


Thanks,

Martijn.

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

Re: [Haskell-cafe] Hoogle and Network.Socket

[Svein Ove Aas]

On Sat, Feb 21, 2009 at 11:55 AM, Martijn van Steenbergen
 wrote:
>
> How about allowing an extra search flag +windows that reveals
> windows-specific APIs? Likewise for other OS's.
>
> Being able to enable API for a specific package requires me knowing in what
> package I want to look, while an OS flag doesn't, all the while still making
> very explicit I want to look for OS-specific API.
>
There aren't enough platforms supported that we need this kind of freeform flag.

My preference would be for a bunch of (initially hidden, drop-down)
checkboxes, that remember their state via a cookie; if I wanted to see
windows-specific functions last search, chances are I still do this
time.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: speed: ghc vs gcc

[Manlio Perillo]

Bulat Ziganshin ha scritto:

[...]
but problem - not mine, but for haskellers, is that some people said
that ghc can generate code that is as fast as gcc one. it will be
stupid if someone will start to write say mpeg4 codec and after year
of work will find that it need 100 Ghz cpu to work.


IMHO, a more viable solution is to write the *parser* in GHC, but use 
the raw code written in C.


As an example, I get some problems from mplayer, not caused by the 
codec, but by the demuxer and stream parsing.





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

Re: [Haskell-cafe] Help using catch in 6.10

[Ian Lynagh]

On Sat, Feb 21, 2009 at 01:18:35AM +0100, Martijn van Steenbergen wrote:
> 
> You now need to specify the exact type of the exception you wish to 
> catch. For example, to catch any exception:
> 
> action `catch` (\(e :: SomeException) -> handler)
> 
> For more information, see:
> 
> http://www.haskell.org/~simonmar/papers/ext-exceptions.pdf

See also

"Catching all exceptions"
http://www.haskell.org/ghc/dist/stable/docs/libraries/base/Control-Exception.html#4


Thanks
Ian

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

Re: [Haskell-cafe] Re: speed: ghc vs gcc

[Peter Verswyvelen]

Most people in the games industry that I knew don't even know haskell. they
are trained imperative hackers.
However tim sweeney studies haskell, so it cetainly has influenced at least
one well known game developer.

But I wasn't saying that Haskell *is* used, I said one could use it for
programming the logic of a game.

And I'm not saying a AAA nexgen title :-)



On Sat, Feb 21, 2009 at 1:10 AM, Achim Schneider  wrote:

> Peter Verswyvelen  wrote:
>
> > nothing should stop you from writing video games in Haskell
> >
> Show me a studio that uses Haskell and I'd even accept dollars or pounds
> as payment.
>
> --
> (c) this sig last receiving data processing entity. Inspect headers
> for copyright history. All rights reserved. Copying, hiring, renting,
> performance and/or quoting of this signature prohibited.
>
>
> ___
> 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] Hoogle and Network.Socket

[John A. De Goes]

I think the (valid) concern is that too many people are choosing  
platform-specific packages when there are alternatives available  
(albeit not as convenient in some cases), and this really hurts the  
Windows community because Windows is so radically different from all  
the other operating systems.


Not showing platform-specific packages by default *might* make package  
writers more likely to develop cross-platform packages. We've heard  
many times someone say, "I don't know if it works on Windows, never  
really thought of that."


Regards,

John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration

http://www.n-brain.net|877-376-2724 x 101

On Feb 21, 2009, at 3:55 AM, Martijn van Steenbergen wrote:


Hi Neil,

Neil Mitchell wrote:

If a function isn't available on all OS's then all Hoogle would be
encouraging you to do is break compatibility and stop me from using
your software. If a function is only available on one OS you will
certainly have to deliberately choose to search for that, and it will
never show up by default.
For what shows up by default I more meant other packages. Should
Gtk2hs show up by default? What about tagsoup? What about base?  
Things

like Win32 will never show up by default.


How about allowing an extra search flag +windows that reveals  
windows-specific APIs? Likewise for other OS's.


Being able to enable API for a specific package requires me knowing  
in what package I want to look, while an OS flag doesn't, all the  
while still making very explicit I want to look for OS-specific API.


Thanks,

Martijn.

___
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: Re[6]: [Haskell-cafe] Re: speed: ghc vs gcc

[Peter Verswyvelen]

>
> > nothing should stop you from writing video games in Haskell since
>
> video codec isn't video game :)))
>

ouch, mea culpa, I misread  your message.

>
> > but I've worked with people that wrote physics engines in C/C++,
> > and they also had to hand optimize specifically for a certain compiler to
> get things fast.
>
> that's important signal. if you need to hand-optimize your code even
> if you use icl to compile it, using haskell will be like hunting with
> a hand instead of gun


well in the past I wrote a couple of video codecs (one was a multi core
motion JPEG decoder), and I had to write parts of it in assembler to get
fast enough frame rates. but that is already more than 10 years ago, today I
don't think I could beat a C/C++ compiler like ICL anymore, at least not in
a reasonable time frame
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Showing >100% CPU usage of parallel code

[Jim Burton]

Hi, I copied the program below from a reddit post of dons'. I have a dual
core laptop with ubuntu hardy and ghc 6.10.1. I can see the difference when
I run the program with +RTS -N2 but CPU always says 100%. I'd like an
example that shows >100 -- is it not showing >100 because of my timeformat
or because of the program? If it's the latter can you point me to an example
that will use more cpu? 

Here's the output:

$ cat /proc/cpuinfo | grep processor | wc -l
2
$ export TIMEFORMAT="%E real,%U user,%S sys, %P cpu"
$ ghc -O2 --make Par.hs -threaded
$ time ./Par
1405006117752879898543142606244511569936384005711076
2.330 real,2.328 user,0.000 sys, 99.92 cpu
$ time ./Par +RTS -N2
1405006117752879898543142606244511569936384005711076
1.504 real,2.316 user,0.016 sys, 100.00 cpu

Here's the program:


import Control.Parallel

main = a `par` b `par` c `pseq` print (a + b + c)
where
a = ack 3 10
b = fac 42
c = fib 34

fac 0 = 1
fac n = n * fac (n-1)

ack 0 n = n+1
ack m 0 = ack (m-1) 1
ack m n = ack (m-1) (ack m (n-1))

fib 0 = 0
fib 1 = 1
fib n = fib (n-1) + fib (n-2)


Thanks,

Jim


-- 
View this message in context: 
http://www.nabble.com/Showing-%3E100--CPU-usage-of-parallel-code-tp22137081p22137081.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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

[Haskell-cafe] Re: [darcs-users] darcs and Google Summer of Code

[Eric Kow]

Hi Wolgang,

On Wed, Feb 18, 2009 at 12:53:23 +0100, Wolfgang Jeltsch wrote:
> What do you mean with “something which will make it much easier for third 
> parties to write a GUI in the future”?

Kari's example of GUI-friendly optimisations might be one thought.

More generally, I was thinking of some kind of darcs library design
work: now that we have exposed all our modules in a sort of darcs
library, how we can grow this into a proper library that people can
"safely" use (safe in the sense that the library makes it very clear
what kinds of operations are read-only, or to what extent operations are
"atomic", preferably with atomic repository-manipulating functions only
being exposed and not their underlying substeps).  The library could
also tackle issues like darcs sending messages back to the user (right
now, we just putStrLn, but what if we want them to go a special Window?)

Sorry if these are vague thoughts.  In general, it would be nice to see
a some summer of code projects that emphasised foundational work.

> > I'll note that last year, we had a few interested students for this year and
> > a potential mentor (Shelarcy from wxHaskell).  Hopefully we can call on
> > them again this year?  There is also some work by Wolgang Jeltsch
> 
> Wol*f*gang, please. :-) 

Argh, after looking Jeltsch up to make sure I got that right, I had to
go make a typo on the easy part.  :-D

> How can I get write access for this page?

Very sorry for the delayed response:
  http://wiki.darcs.net/index.html/UserPreferences

> I’ve put myself as a potential mentor on the old Haskell SoC ticket 
> ().

Thanks!

> However, one or two years ago I was told that mentoring is a very
> time-consuming thing (and to my knowledge, you don’t get any payments
> for that, at least for Haskell projects).

While the darcs project would be grateful if you wanted to donate us
your mentor payment, we certainly do not want to make you feel obliged
to do so.

-- 
Eric Kow 
PGP Key ID: 08AC04F9


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

Re: [Haskell-cafe] Showing >100% CPU usage of parallel code

[Bulat Ziganshin]

Hello Jim,

Saturday, February 21, 2009, 6:17:54 PM, you wrote:

> main = a `par` b `par` c `pseq` print (a + b + c)

two things:
1) that are grouping order? may be,
a `par` (b `par` (c `pseq` print (a + b + c))) ?

2) i recommend you to use 2 *same* computations.
otherwise, it's easily possible that one of them needs much more time
that the rest


> where
> a = ack 3 10
> b = fac 42
> c = fib 34

> fac 0 = 1
> fac n = n * fac (n-1)

> ack 0 n = n+1
> ack m 0 = ack (m-1) 1
> ack m n = ack (m-1) (ack m (n-1))

> fib 0 = 0
> fib 1 = 1
> fib n = fib (n-1) + fib (n-2)
> 

> Thanks,

> Jim





-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

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

Re: [Haskell-cafe] Showing >100% CPU usage of parallel code

[Jeff Heard]

Jim, I'm actually not sure that time will report greater than 100% cpu
on ubuntu hardy. (really not sure, and don't have it available right
this moment to check).  I would however try making a computation that
will take a little longer and use the system monitor or /proc to look
at your CPU usage rather than time.  I've had good luck with GHC 6.8
using > 100% cpu, so I assume 6.10 will work much better.

On Sat, Feb 21, 2009 at 10:32 AM, Bulat Ziganshin
 wrote:
> Hello Jim,
>
> Saturday, February 21, 2009, 6:17:54 PM, you wrote:
>
>> main = a `par` b `par` c `pseq` print (a + b + c)
>
> two things:
> 1) that are grouping order? may be,
> a `par` (b `par` (c `pseq` print (a + b + c))) ?
>
> 2) i recommend you to use 2 *same* computations.
> otherwise, it's easily possible that one of them needs much more time
> that the rest
>
>
>> where
>> a = ack 3 10
>> b = fac 42
>> c = fib 34
>
>> fac 0 = 1
>> fac n = n * fac (n-1)
>
>> ack 0 n = n+1
>> ack m 0 = ack (m-1) 1
>> ack m n = ack (m-1) (ack m (n-1))
>
>> fib 0 = 0
>> fib 1 = 1
>> fib n = fib (n-1) + fib (n-2)
>> 
>
>> Thanks,
>
>> Jim
>
>
>
>
>
> --
> Best regards,
>  Bulatmailto:bulat.zigans...@gmail.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] Showing >100% CPU usage of parallel code

[Felipe Lessa]

On Sat, Feb 21, 2009 at 12:17 PM, Jim Burton  wrote:
> $ time ./Par +RTS -N2
> 1405006117752879898543142606244511569936384005711076
> 1.504 real,2.316 user,0.016 sys, 100.00 cpu

I don't know why it is only 100%, but you can see that the user time
is greater than real time, so everything is working on GHC's side. You
may also use -sstderr to see some more info.

HTH,

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

Re: [Haskell-cafe] Showing >100% CPU usage of parallel code

[Jim Burton]

Jeff Heard wrote:
> 
> Jim, I'm actually not sure that time will report greater than 100% cpu
> on ubuntu hardy. (really not sure, and don't have it available right
> this moment to check).  I would however try making a computation that
> will take a little longer and use the system monitor or /proc to look
> at your CPU usage rather than time.  I've had good luck with GHC 6.8
> using > 100% cpu, so I assume 6.10 will work much better.
> 
> 
Hi, thanks for that. The system monitor shows that I get ~160% usage, but
like you I don't know if it's possible to get time to display that (on
hardy, it clearly does elsewhere). The system monitor GUI is good enough, if
less neat than showing it via time. 

Jim


> 
> 
> On Sat, Feb 21, 2009 at 10:32 AM, Bulat Ziganshin
>  wrote:
>> Hello Jim,
>>
>> Saturday, February 21, 2009, 6:17:54 PM, you wrote:
>>
>>> main = a `par` b `par` c `pseq` print (a + b + c)
>>
>> two things:
>> 1) that are grouping order? may be,
>> a `par` (b `par` (c `pseq` print (a + b + c))) ?
>>
>> 2) i recommend you to use 2 *same* computations.
>> otherwise, it's easily possible that one of them needs much more time
>> that the rest
>>
>>
>>> where
>>> a = ack 3 10
>>> b = fac 42
>>> c = fib 34
>>
>>> fac 0 = 1
>>> fac n = n * fac (n-1)
>>
>>> ack 0 n = n+1
>>> ack m 0 = ack (m-1) 1
>>> ack m n = ack (m-1) (ack m (n-1))
>>
>>> fib 0 = 0
>>> fib 1 = 1
>>> fib n = fib (n-1) + fib (n-2)
>>> 
>>
>>> Thanks,
>>
>>> Jim
>>
>>
>>
>>
>>
>> --
>> Best regards,
>>  Bulatmailto:bulat.zigans...@gmail.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
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Showing-%3E100--CPU-usage-of-parallel-code-tp22137081p22137684.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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

[Haskell-cafe] Haskell Weekly News: Issue 106 - February 21, 2009

[Brent Yorgey]

---
Haskell Weekly News
http://sequence.complete.org/hwn/20090221
Issue 106 - February 21, 2009
---

   Welcome to issue 106 of HWN, a newsletter covering developments in the
   [1]Haskell community.

Announcements

   HWEB. Eric Macaulay, following a little [2]prodding by Neil Mitchell,
   has released version 0 of [3]HWEB, a small tool for producing literate
   Haskell programs.

   Cabal-1.6.0.2 and cabal-install-0.6.2. Duncan Coutts [4]announced
   point-releases of the Cabal library and the cabal-install command line
   tool. These releases include a number of fixes and minor improvements,
   and are expected to be included with ghc-6.10.2.

   Barrie 0.3.1. Fraser Wilson [5]announced a hackage release of
   [6]Barrie, an implementation of an idea for supporting state based,
   user-driven GUIs.

   Yogurt-0.3. Martijn van Steenbergen [7]announced the release of
   [8]Yogurt-0.3, a MUD client library for Haskell. This version improves
   over 0.2 in several ways, including support for GHC 6.10, no more
   unsafeCoerce needed, new support for forking threads, and various
   refactorings.

   wxFruit-0.1.2. Henk-Jan van Tuyl [9]announced an [10]update of
   [11]wxFruit, a graphical user interface that combines some of the power
   and versatility of wxHaskell with the elegance and simplicity of Fruit.
   The new version works with GHC 6.10, and also includes a demo game,
   PaddleBall. Interested parties, take note: the position of
   developer/maintainer for this library is currently open.

   Paper draft: "Denotational design with type class morphisms". Conal
   Elliott [12]announced a [13]draft of a new paper, "Denotational design
   with type class morphisms". Feedback is appreciated, especially if in
   time for the March 2 ICFP deadline.

   Crypto 4.2.0 & Related News. Creighton Hogg [14]announced the release
   of version 4.2.0 of the [15]Crypto library. Creighton will also
   betaking over maintenance of the library from Dominic Steinitz.

   The Typeclassopedia, and request for feedback. Brent Yorgey
   [16]announced a [17]first draft of an article entitled 'The
   Typeclassopedia', a "starting point for the student of Haskell wishing
   to gain a firm grasp of its standard type classes." Comments and
   feedback are encouraged!

   hslibsvm-2.88.0.1 - A FFI binding to LibSVM. S. Guenther [18]announced
   the [19]hlibsvm package, a set of Haskell bindings to the C++
   [20]libsvm library.

   spacepart-0.1.0.0 (was called data-spacepart). Corey O'Connor
   [21]announced a new release of the [22]spacepart package, supporting
   space-partitioning data structures. The new release includes many bug
   fixes and some code cleanup.

   pqueue-mtl, stateful-mtl. Louis Wasserman [23]announced two new
   packages, [24]stateful-mtl and [25]pqueue-mtl. stateful-mtl provides an
   ST monad transformer, several useful operations on generic monad
   transformers, and a monad transformer intended to cleanly externally
   wrap operations on a mutable array (including resizing operations).
   pqueue-mtl provides implementations of several structures supporting a
   generic 'single-in, single-out' paradigm (encapsulated in a typeclass
   named Queuelike), including stacks, queues, and several implementations
   of priority queues.

   haha-0.1 - Animated ascii lambda. Sebastiaan Visser [26]announced
   [27]haha, a very minimal vector based ascii art library written just
   for fun. If you've always wanted to have a full-color rotating vector
   based ascii art lambda on your terminal, now is your chance!

Discussion

   Darcs and Google Summer of Code. Eric Kow [28]floated the idea of
   having darcs apply to the Google Summer of Code as a separate mentoring
   organization, and discussed several ideas for student projects.

Jobs

   Postdoctoral Research Position at Yale University. Paul Hudak
   [29]announced the availability of a postdoctoral research position at
   Yale University. The successful candidate will apply modern, high-level
   programming language ideas (such as embodied in Haskell) to help design
   and implement a language for the control of BGP-based network routers,
   with the goal of realizing high-level networking protocols for traffic
   engineering, security, and related networking concerns.

Blog noise

   [30]Haskell news from the [31]blogosphere.
 * GHC / OpenSPARC Project: [32]Triage.
 * Manuel M T Chakravarty: [33]Mark your Haskell tweets with #haskell.
 * Gregg Reynolds: [34]Performance Economics.
 * Alex Mason: [35]AVar released (three times).
 * Sean Leather: [36]The strict danger of switching from pure to
   monadic Template Haskell.
 * Mads Lindstrom: [37]Using Mutable Arrays for Faster Sorting.
 * Conal Elliott: [38]Denotational desig

[Haskell-cafe] controlling timeout for Network.Socket.connect - how?

[Belka]

Hello, communion people!

I have a problem and ask for an advice. 
I'm dealing with sockets on *Linux* platform (Network.Socket). The problem
is that I can't fully control timeout for (connect :: Socket -> SockAddr ->
IO ()) operation. 
On my system the timeout is - 3 seconds - I want to be able to change that
in run-time. Well I managed to find out how to make it LESS THAN 3 seconds -
using System.Timeout. But how to make timeout bigger (for example 9 seconds)
is a mystery.
(Notice: in order to achieve 9 seconds timeout - just repeating *connect* 3
times won't be effective for long-slow-way-connections. So it's not a
solution.)

The source code of Network.Socket.connect, taken from darcs:
-
-- Connecting a socket
--
-- Make a connection to an already opened socket on a given machine
-- and port.  assumes that we have already called createSocket,
-- otherwise it will fail.
--
-- This is the dual to $bindSocket$.  The {\em server} process will
-- usually bind to a port number, the {\em client} will then connect
-- to the same port number.  Port numbers of user applications are
-- normally agreed in advance, otherwise we must rely on some meta
-- protocol for telling the other side what port number we have been
-- allocated.

connect :: Socket   -- Unconnected Socket
-> SockAddr -- Socket address stuff
-> IO ()

connect sock@(MkSocket s _family _stype _protocol socketStatus) addr = do
 modifyMVar_ socketStatus $ \currentStatus -> do
 if currentStatus /= NotConnected 
  then
   ioError (userError ("connect: can't peform connect on socket in status "
++
 show currentStatus))
  else do
   withSockAddr addr $ \p_addr sz -> do

   let  connectLoop = do
   r <- c_connect s p_addr (fromIntegral sz)
   if r == -1
   then do 
   rc <- c_getLastError
   case rc of
 10093 -> do -- WSANOTINITIALISED
   withSocketsDo (return ())
   r <- c_connect s p_addr (fromIntegral sz)
   if r == -1
then (c_getLastError >>= throwSocketError "connect")
else return r
 _ -> throwSocketError "connect" rc
   else return r

connectBlocked = do 
#if !defined(__HUGS__)
   threadWaitWrite (fromIntegral s)
#endif
   err <- getSocketOption sock SoError
   if (err == 0)
then return 0
else do ioError (errnoToIOError "connect" 
(Errno (fromIntegral err))
Nothing Nothing)

   connectLoop
   return Connected

-
I know that controlling timeout is somehow connected to select(2) (I'm
currently investigating this matter...), but it's not in the Network or
Network.Socket libs (but in the libs that they FFI with). 
Hope I won't have to rewrite these low-level functions >__<
Could anybody, please share some experience on how to adjust timeout for
*connect*? 

Thanks in advance,
Best regards,
Belka
-- 
View this message in context: 
http://www.nabble.com/controlling-timeout-for-Network.Socket.connect---how--tp22139581p22139581.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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

[Haskell-cafe] Stacking StateTs

[Luis O'Shea]

I've been experimenting with the state monad and with StateT, and  
have some questions about how to combine one state with another.


This email is literate Haskell tested on GHCi, version 6.10.1.  Also,  
sigfpe's post on monad transformers (http://blog.sigfpe.com/2006/05/ 
grok-haskell-monad-transformers.html) was very helpful.


> import Control.Monad.State

My question is basically whether the function modifyT (below) makes  
sense, whether some form of it already exists in a standard library,  
and (most importantly) whether it actually indicates that I'm  
thinking about StateT all wrong.


> modifyT :: Monad m =>
>(s -> StateT t m s)
> -> StateT t (StateT s m) ()
> modifyT f = do
> x <- get
> y <- lift get
> (y',x') <- lift $ lift $ runStateT (f y) x
> lift $ put y'
> put x'

Some context may be useful, so here is how I ended up thinking I  
needed modifyT.


The state monad makes it easy to write stateful computations.  For  
example here is a computation that has an Integer as its state and  
returns a String:


> test1 :: State Integer String
> test1 = do
>   modify (+ 1)
>   a <- get
>   return $ "foobar" ++ (show a)

If the computation wants to do some IO then it makes sense to start  
with the IO monad and then apply the StateT transformer to it:


> test2 :: StateT Integer IO String
> test2 = do
>   modify (+ 1)
>   a <- get
>   lift $ print a
>   return $ "foobar" ++ (show a)

So from now on I won't actually do any IO and will replace IO with an  
arbitrary monad m.  Also instead of the fixed string "foobar" I'll  
have it take a String as a parameter:


> test3 :: Monad m => String -> StateT Integer m String
> test3 s = do
>   modify (+ 1)
>   a <- get
>   return $ s ++ (show a)

A nice feature of all this is that it is easy to combine these  
computations:


> test4 :: Monad m => StateT Integer m (String,String)
> test4 = do
>   s1 <- test3 "foo"
>   s2 <- test3 "bar"
>   return $ (s1,s2)

Now seeing as test3 takes a String and returns another String you can  
imagine using it to transform a String state.  (I'm also going to  
assume that test3 is in another library so we don't want to alter how  
it's written.)  So here is how you could use test3 in a computation  
that has (String,Integer) as its state:


> test5 :: (Monad m) => m Integer
> test5 = do
>   (s1,x1) <- runStateT (test3 "") 0
>   (s2,x2) <- runStateT (test3 s1) (2*x1 + 1)
>   (s3,x3) <- runStateT (test3 s2) (x2*x2)
>   return x3

Then running test5 >>= print gives 17.  The problem with test5, of  
course, is that we have manually threaded the state, with all the  
problems that implies.  For example nothing prevents you from  
erroneously misthreading the state:


> test5bad :: (Monad m) => m Integer
> test5bad = do
> (s1,x1) <- runStateT (test3 "") 0
> (s2,x2) <- runStateT (test3 s1) (2*x1 + 1)
> (s3,x3) <- runStateT (test3 s1) (x2*x1)
> return x3

Running test5bad >>= print gives 5.  Obviously we want operate in a  
State monad with more state.  One way to do this is to stack two  
StateTs on top of m.  This is, finally, where I need the modifyT that  
we defined above -- it lets us "lift" test3 to a function that  
modifies the state of the top *two* StateTs.  Now let's use it to  
rewrite test5:


> test6 :: (Monad m) => StateT Integer (StateT String m) Integer
> test6 = do
>   modifyT test3
>   modify $ \x -> 2*x + 1
>   modifyT test3
>   modify $ \x -> x*x
>   modifyT test3
>   x <- get
>   return x
>
> test7 :: (Monad m) => m Integer
> test7  = evalStateT (evalStateT test6 0) ""

As expected, running test7 >>= print gives 17.

So, given that modifyT seems to be useful, does it, or something like  
it, already exists in the standard libraries?  More likely, am I  
making a mountain of a molehill and is there a better way to  
structure all this?


Thanks,

Luis

> main = do
>   test5 >>= print
>   test5bad >>= print
>   test7 >>= print

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

[Haskell-cafe] Haskellers on Twitter!

[Daniel Peebles]

Hi all,

I liked Brian O'Sullivan's blog post on twitter
(http://www.serpentine.com/blog/2008/12/05/functional-programmers-on-twitter/),
so I moved the Haskell subset of his list (along with a couple of
additions) onto the haskell wiki, to make it easier for people to
update. You can find the page at
http://haskell.org/haskellwiki/Twitter. Please update with yourself or
any other Haskellers we may have missed.

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

Fwd: Re: [Haskell-cafe] speed: ghc vs gcc

[Khudyakov Alexey]

Oh I've again sent mail to wrong address
--  Forwarded Message  --

On Saturday 21 February 2009 02:42:11 you wrote:
> On Sat, Feb 21, 2009 at 12:22 AM, Bulat Ziganshin
> 
> > wrote:
> >
> > Hello Khudyakov,
> >
> > Saturday, February 21, 2009, 2:07:39 AM, you wrote:
> > > I have another question. Why shouldn't compiler realize that `sum
> >
> > [1..10^9]'
> >
> > > is constant and thus evaluate it at compile time?
> >
> > since we expect that compilation will be done in reasonable amount of
> > time. you cannot guarantee this for list-involving computation
>
> it would be nice to have a compiler that can run forever, incrementally
> generating faster and faster versions of the same program, until you press
> a key or a timeout is reached.
>
> then you just let it run before you get to bed ;-)
>
> you could even pass it in a test data set to which it must be optimized;
> after the program is compiled, the compiler runs and profiles it, measures
> the results, and does another pass to make it faster.
>
I've just remembered another but related approach to optimization. It uses 
genetic algorithm to determine close to the best set of optimization options. 
Alternatively it could be used to find badly interacting options, 
pessimizations. 

Implementation for gcc is here: 
http://www.coyotegulch.com/products/acovea/

In fact I didn't tried it but I liked the idea. 

--
  Khudaykov Alexey

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

Re: Fwd: Re: [Haskell-cafe] speed: ghc vs gcc

[Bulat Ziganshin]

Hello Khudyakov,

Sunday, February 22, 2009, 12:58:59 AM, you wrote:

>> you could even pass it in a test data set to which it must be optimized;
>> after the program is compiled, the compiler runs and profiles it, measures
>> the results, and does another pass to make it faster.

it supported in gcc4 and icl at least

> I've just remembered another but related approach to optimization. It uses
> genetic algorithm to determine close to the best set of optimization options.

afaik it used widely for tuning parameters of compression algorithms


-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

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

Re[3]: [Haskell-cafe] Re: speed: ghc vs gcc

[Bulat Ziganshin]

Hello Louis,

Saturday, February 21, 2009, 4:16:10 AM, you wrote:

> In the meantime, a brief summary:

a minor correction: the best gcc result shown in the thread was 50x
faster than Don's one, so you need to miltiple all ratios by a factor
of 50

> Straightforward and simple Haskell code, written by an individual
> aware of issues with tail recursion and stream fusion, is frequently
> within 3x the speed of GCC code when compiled with appropriate
> optimizations in GHC.

yes, within 150x margin

> When performance is an absolute necessity,
> Haskell code can sometimes be manually modified (e.g. with manual
> loop unrolls) to equal GCC in performance.

yes, to make it only 50x slower while being only 7 times larger (i
mean source lines)

> Can we move on?

yes, we can! :)


-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

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

Re: Re[3]: [Haskell-cafe] Re: speed: ghc vs gcc

[Louis Wasserman]

Observation:

The best gcc result shown in the thread, if I recall, precomputed the result
of the full computation at compiletime and simply outputted it, when we
looked at the assembly.

While I will accept that this could be seen as an optimization GHC should
have made, I do not accept that this will be the case with most everyday
code a programmer writes, as most code is not used to simply compute
arithmetic constants.

For code that actively requires computation at runtime, I have seen no
examples of an instance where well-optimized GHC is actually dozens or
hundreds of times slower than GCC output.

Louis Wasserman
wasserman.lo...@gmail.com


On Sat, Feb 21, 2009 at 5:21 PM, Bulat Ziganshin
wrote:

> Hello Louis,
>
> Saturday, February 21, 2009, 4:16:10 AM, you wrote:
>
> > In the meantime, a brief summary:
>
> a minor correction: the best gcc result shown in the thread was 50x
> faster than Don's one, so you need to miltiple all ratios by a factor
> of 50
>
> > Straightforward and simple Haskell code, written by an individual
> > aware of issues with tail recursion and stream fusion, is frequently
> > within 3x the speed of GCC code when compiled with appropriate
> > optimizations in GHC.
>
> yes, within 150x margin
>
> > When performance is an absolute necessity,
> > Haskell code can sometimes be manually modified (e.g. with manual
> > loop unrolls) to equal GCC in performance.
>
> yes, to make it only 50x slower while being only 7 times larger (i
> mean source lines)
>
> > Can we move on?
>
> yes, we can! :)
>
>
> --
> Best regards,
>  Bulatmailto:bulat.zigans...@gmail.com
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: speed: ghc vs gcc

[Daniel Fischer]

Am Sonntag, 22. Februar 2009 00:21 schrieb Bulat Ziganshin:
> Hello Louis,
>
> Saturday, February 21, 2009, 4:16:10 AM, you wrote:
> > In the meantime, a brief summary:
>
> a minor correction: the best gcc result shown in the thread was 50x
> faster than Don's one, so you need to miltiple all ratios by a factor
> of 50

You're referring to the freak result of Dan Doel?
Come on, be serious, please. I have a Haskell result that runs in 7ms, too. 
Just use a rewrite rule and hey presto :)

>
> > Straightforward and simple Haskell code, written by an individual
> > aware of issues with tail recursion and stream fusion, is frequently
> > within 3x the speed of GCC code when compiled with appropriate
> > optimizations in GHC.
>
> yes, within 150x margin

Bulat, your obsession has become obnoxious and ridiculous.

>
> > When performance is an absolute necessity,
> > Haskell code can sometimes be manually modified (e.g. with manual
> > loop unrolls) to equal GCC in performance.
>
> yes, to make it only 50x slower while being only 7 times larger (i
> mean source lines)
>
> > Can we move on?
>
> yes, we can! :)

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

Re[5]: [Haskell-cafe] Re: speed: ghc vs gcc

[Bulat Ziganshin]

Hello Louis,

Sunday, February 22, 2009, 2:30:23 AM, you wrote:

yes, you are right. Don also compared results of 64x-reduced
computation with full one. are you think that these results are more
fair?

> Observation:

> The best gcc result shown in the thread, if I recall, precomputed
> the result of the full computation at compiletime and simply
> outputted it, when we looked at the assembly.

> While I will accept that this could be seen as an optimization GHC
> should have made, I do not accept that this will be the case with
> most everyday code a programmer writes, as most code is not used to
> simply compute arithmetic constants.
>  
> For code that actively requires computation at runtime, I have seen
> no examples of an instance where well-optimized GHC is actually
> dozens or hundreds of times slower than GCC output.

> Louis Wasserman
>  wasserman.lo...@gmail.com
>  

> On Sat, Feb 21, 2009 at 5:21 PM, Bulat Ziganshin
>  wrote:
>  Hello Louis,
>  

>  Saturday, February 21, 2009, 4:16:10 AM, you wrote:
>  
 >> In the meantime, a brief summary:
>  
>  
> a minor correction: the best gcc result shown in the thread was 50x
>  faster than Don's one, so you need to miltiple all ratios by a factor
>  of 50
>  

 >> Straightforward and simple Haskell code, written by an individual
 >> aware of issues with tail recursion and stream fusion, is frequently
 >> within 3x the speed of GCC code when compiled with appropriate
 >> optimizations in GHC.
>  
>  
> yes, within 150x margin
>  

 >> When performance is an absolute necessity,
 >> Haskell code can sometimes be manually modified (e.g. with manual
 >> loop unrolls) to equal GCC in performance.
>  
>  
> yes, to make it only 50x slower while being only 7 times larger (i
>  mean source lines)
>  
 >> Can we move on?
>  
>  yes, we can! :)
>  
>  
>  --
>  Best regards,
>   Bulat                            mailto:bulat.zigans...@gmail.com
>  
>  

>   


-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

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

Re: [Haskell-cafe] Stacking StateTs

[David Menendez]

On Sat, Feb 21, 2009 at 3:33 PM, Luis O'Shea  wrote:
> I've been experimenting with the state monad and with StateT, and have some
> questions about how to combine one state with another.



>> test3 :: Monad m => String -> StateT Integer m String
>> test3 s = do
>>   modify (+ 1)
>>   a <- get
>>   return $ s ++ (show a)

A style point: It's often better to specify what operations test3
uses, rather than requiring a specific family of monads.

test3 :: MonadState Integer m => String -> m String

> Now seeing as test3 takes a String and returns another String you can
> imagine using it to transform a String state.  (I'm also going to assume
> that test3 is in another library so we don't want to alter how it's
> written.)  So here is how you could use test3 in a computation that has
> (String,Integer) as its state:
>
>> test5 :: (Monad m) => m Integer
>> test5 = do
>>   (s1,x1) <- runStateT (test3 "") 0
>>   (s2,x2) <- runStateT (test3 s1) (2*x1 + 1)
>>   (s3,x3) <- runStateT (test3 s2) (x2*x2)
>>   return x3

You don't really need to jump all the way out of the state
transformer. Something like this would work just as well:

test5a = flip execStateT 0 $ do
s1 <- test3 ""
modify $ \x -> 2 * x + 1
s2 <- test3 s1
modify $ \x -> x * x
test3 s2

Contrast this with your test6.

Now, if you want to avoid passing the strings around explicitly, you
could add another state transformer. For example, we could layer a
String transformer on top of the underlying monad with this fairly
general combinator:

modifyM :: (Monad m) => (s -> m s) -> StateT s m ()
modifyM f = StateT $ \s -> f s >>= \s' -> return ((),s')

test5b = flip execStateT 0 . flip evalStateT "" $ do
modifyM test3
lift $ modify $ \x -> 2 * x + 1
modifyM test3
lift $ modify $ \x -> x * x
modifyM test3

Note that modifyM works on the top-level state, whereas lift . modify
works on the inner state.

Or, you can put the state transformer on the bottom by taking
advantage of the fact that test3 is polymorphic in any underlying
monad.

test3' = lift get >>= test3 >>= lift . put   -- this is essentially
modifyT test3

test5c = flip evalState "" . flip execStateT 0 $ do
test3'
modify $ \x -> 2*x+1
test3'
modify $ \x -> x * x
test3'

But this only really makes sense if you expect the String state to
last at least as long as the Integer state.

Of my three alternatives, test5a actually seems the most idiomatic to
me, followed by test5b and then test5c. It's possible to write test5a
in a way that avoids explicitly passing the strings around, but the
result doesn't end up looking much better.


PS. Here are two functions that I ended up not using in my examples,
but which may come in handy when dealing with nested applications of
StateT:

curryStateT :: (Monad m) => StateT (s,t) m a -> StateT s (StateT t m) a
curryStateT m = StateT $ \s -> StateT $ \t ->
runStateT m (s,t) >>= \ ~(a,(s,t)) -> return ((a,s),t)

uncurryStateT :: (Monad m) => StateT s (StateT t m) a -> StateT (s,t) m a
uncurryStateT m = StateT $ \ ~(s,t) ->
runStateT (runStateT m s) t >>= \ ~((a,s),t) -> return (a,(s,t))

-- 
Dave Menendez 

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

Re[2]: [Haskell-cafe] Re: speed: ghc vs gcc

[Bulat Ziganshin]

Hello Daniel,

Sunday, February 22, 2009, 2:36:57 AM, you wrote:

> You're referring to the freak result of Dan Doel?
> Come on, be serious, please. I have a Haskell result that runs in 7ms, too.
> Just use a rewrite rule and hey presto :)

Dan, why you have not said the same about test where ghc becomes 4x
faster than gcc?

> Bulat, your obsession has become obnoxious and ridiculous.

i really, really wonder why cheating on gcc side is "obsession that
become obnoxious and ridiculous" while cheating on ghc side is ok for
you. can you explain?


-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

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

Re: Re[5]: [Haskell-cafe] Re: speed: ghc vs gcc

[Louis Wasserman]

I said nothing about fairness, and *never at any point said I thought Don's
results were more useful or fair.*  What makes you think that's what I meant
to imply?

You have not responded to my separate concern that
> For code that actively requires computation at runtime, I have seen
> no examples of an instance where well-optimized GHC is actually
> dozens or hundreds of times slower than GCC output.

Rather than accusing me of taking sides, if you'd take an actual
apples-to-apples comparison, citing the best Haskell results and best GCC
results -- without using examples from either language which performed
computation at compile-time that would not be possible in everyday programs
-- my original claims were true: that GHC code is frequently within 3x the
speed of GCC code, and hacked-up GHC code can reach and match GCC
performance -- though I agree those hacks require an impractical blowup in
code size.  (Depending on your individual interpretation of what an average
Haskell program looks like, I concede that 3x might be off by a factor of 2
or so -- but not the factor of 50 you claimed.)

Don's "-D64" results, while *not* a useful gcc-vs-ghc comparison, are
relevant if really determined Haskellers are interested in learning how to
obtain the absolute optimal perfection from their code.  Don's results *are*
useful, but not in the way you say we're claiming.

Louis Wasserman
wasserman.lo...@gmail.com


On Sat, Feb 21, 2009 at 5:35 PM, Bulat Ziganshin
wrote:

> Hello Louis,
>
> Sunday, February 22, 2009, 2:30:23 AM, you wrote:
>
> yes, you are right. Don also compared results of 64x-reduced
> computation with full one. are you think that these results are more
> fair?
>
> > Observation:
>
> > The best gcc result shown in the thread, if I recall, precomputed
> > the result of the full computation at compiletime and simply
> > outputted it, when we looked at the assembly.
>
> > While I will accept that this could be seen as an optimization GHC
> > should have made, I do not accept that this will be the case with
> > most everyday code a programmer writes, as most code is not used to
> > simply compute arithmetic constants.
> >
> > For code that actively requires computation at runtime, I have seen
> > no examples of an instance where well-optimized GHC is actually
> > dozens or hundreds of times slower than GCC output.
>
> > Louis Wasserman
> >  wasserman.lo...@gmail.com
> >
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Re[5]: [Haskell-cafe] Re: speed: ghc vs gcc

[Sebastian Sylvan]

On Sat, Feb 21, 2009 at 11:35 PM, Bulat Ziganshin  wrote:

> Hello Louis,
>
> Sunday, February 22, 2009, 2:30:23 AM, you wrote:
>
> yes, you are right. Don also compared results of 64x-reduced
> computation with full one. are you think that these results are more
> fair?


Yes. Clearly so.
It still computes the result from scratch - it just uses a trick which
generates better code. This is clearly a useful and worthwhile exercise as
it shows A) A neat trick with TH, B) A reasonably practical way to produce
fast code for the critical parts of a Haskell app, C) a motivating example
for implementing a compiler optimization to do it automatically.

Just outputting the precomputed result means nothing.



-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Help using catch in 6.10

[John Meacham]

On Sat, Feb 21, 2009 at 01:54:52PM +, Ian Lynagh wrote:
> On Sat, Feb 21, 2009 at 01:18:35AM +0100, Martijn van Steenbergen wrote:
> > 
> > You now need to specify the exact type of the exception you wish to 
> > catch. For example, to catch any exception:
> > 
> > action `catch` (\(e :: SomeException) -> handler)
> > 
> > For more information, see:
> > 
> > http://www.haskell.org/~simonmar/papers/ext-exceptions.pdf
> 
> See also
> 
> "Catching all exceptions"
> http://www.haskell.org/ghc/dist/stable/docs/libraries/base/Control-Exception.html#4

It is too bad we didn't name SomeException to just be Exception, then it
would be quite straightforward to write code that cleanly compiles on
6.8 and 6.10. As it is,

#if __GLASGOW_HASKELL__ < 610
type SomeException = Exception
#endif

does the trick, but no one likes CPP...

John


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

Re: Re[5]: [Haskell-cafe] Re: speed: ghc vs gcc

[Louis Wasserman]

Sebastian, that's not Bulat's point.  He's saying that if we make that
optimization in Haskell, we should at least make the same optimization in
GCC for fair comparison.  (Though I'm not entirely sure that that
optimization would be of any use to GCC, but that's a linguistic concern, no
more.)

His point is valid.  But Don's results *not* obtained by optimizing in this
fashion are valid comparisons, and the results obtained with this
optimization are useful for other reasons.

Louis Wasserman
wasserman.lo...@gmail.com


On Sat, Feb 21, 2009 at 5:55 PM, Sebastian Sylvan <
syl...@student.chalmers.se> wrote:

>
>
> On Sat, Feb 21, 2009 at 11:35 PM, Bulat Ziganshin <
> bulat.zigans...@gmail.com> wrote:
>
>> Hello Louis,
>>
>> Sunday, February 22, 2009, 2:30:23 AM, you wrote:
>>
>> yes, you are right. Don also compared results of 64x-reduced
>> computation with full one. are you think that these results are more
>> fair?
>>
>
> Yes. Clearly so.
> It still computes the result from scratch - it just uses a trick which
> generates better code. This is clearly a useful and worthwhile exercise as
> it shows A) A neat trick with TH, B) A reasonably practical way to produce
> fast code for the critical parts of a Haskell app, C) a motivating example
> for implementing a compiler optimization to do it automatically.
>
> Just outputting the precomputed result means nothing.
>
>
>
> --
> Sebastian Sylvan
> +44(0)7857-300802
> UIN: 44640862
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] The community is more important than the product

[Don Stewart]

http://haskell.org/haskellwiki/Protect_the_community

Random notes on how to maintain tone, focus and productivity in an
online community I took a few years ago.

Might be some material there if anyone's seeking to help ensure
we remain a constructive, effective community.

-- Don

P.S. release some code on hackage.haskell.org.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Re[5]: [Haskell-cafe] Re: speed: ghc vs gcc

[Sebastian Sylvan]

No, he asked if comparing the D64 version with the straight gcc one was
"more fair" then comparing a version that precomputes the result with one
that doesn't. That's what I responded to.

On Sat, Feb 21, 2009 at 11:59 PM, Louis Wasserman  wrote:

> Sebastian, that's not Bulat's point.  He's saying that if we make that
> optimization in Haskell, we should at least make the same optimization in
> GCC for fair comparison.  (Though I'm not entirely sure that that
> optimization would be of any use to GCC, but that's a linguistic concern, no
> more.)
>
> His point is valid.  But Don's results *not* obtained by optimizing in this
> fashion are valid comparisons, and the results obtained with this
> optimization are useful for other reasons.
>
> Louis Wasserman
> wasserman.lo...@gmail.com
>
>
> On Sat, Feb 21, 2009 at 5:55 PM, Sebastian Sylvan <
> syl...@student.chalmers.se> wrote:
>
>>
>>
>> On Sat, Feb 21, 2009 at 11:35 PM, Bulat Ziganshin <
>> bulat.zigans...@gmail.com> wrote:
>>
>>> Hello Louis,
>>>
>>> Sunday, February 22, 2009, 2:30:23 AM, you wrote:
>>>
>>> yes, you are right. Don also compared results of 64x-reduced
>>> computation with full one. are you think that these results are more
>>> fair?
>>>
>>
>> Yes. Clearly so.
>> It still computes the result from scratch - it just uses a trick which
>> generates better code. This is clearly a useful and worthwhile exercise as
>> it shows A) A neat trick with TH, B) A reasonably practical way to produce
>> fast code for the critical parts of a Haskell app, C) a motivating example
>> for implementing a compiler optimization to do it automatically.
>>
>> Just outputting the precomputed result means nothing.
>>
>>
>>
>> --
>> Sebastian Sylvan
>> +44(0)7857-300802
>> UIN: 44640862
>>
>
>


-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: speed: ghc vs gcc

[Daniel Fischer]

Am Sonntag, 22. Februar 2009 00:50 schrieb Bulat Ziganshin:
> Hello Daniel,
>
> Sunday, February 22, 2009, 2:36:57 AM, you wrote:
> > You're referring to the freak result of Dan Doel?
> > Come on, be serious, please. I have a Haskell result that runs in 7ms,
> > too. Just use a rewrite rule and hey presto :)
>
> Dan, why you have not said the same about test where ghc becomes 4x
> faster than gcc?

Because, as has been explained several times to you, it was not a test of 
ghc's code generation vs. gcc's, and it was NOT meant to be. It was 
explicitely an investigation of how effective an improvement loop-unrolling 
could be.

>
> > Bulat, your obsession has become obnoxious and ridiculous.
>
> i really, really wonder why cheating on gcc side is "obsession that
> become obnoxious and ridiculous" while cheating on ghc side is ok for
> you. can you explain?

Seriously

You have one case where gcc calculated the result for an extremely simple 
programme during the compilation and you use that to say that gcc's code is 
routinely 50-150 times faster than ghc's. Very convincing.

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

Re[7]: [Haskell-cafe] Re: speed: ghc vs gcc

[Bulat Ziganshin]

Hello Sebastian,

Sunday, February 22, 2009, 2:55:38 AM, you wrote:
>  yes, you are right. Don also compared results of 64x-reduced
>  computation with full one. are you think that these results are more
>  fair?

> Yes. Clearly so.
> It still computes the result from scratch - it just uses a trick
> which generates better code. This is clearly a useful and worthwhile
> exercise as it shows A) A neat trick with TH, B) A reasonably
> practical way to produce fast code for the critical parts of a
> Haskell app, C) a motivating example for implementing a compiler
> optimization to do it automatically.

yes, but does you know why his last program is 64x faster than simple
code? it's because *gcc* optimize it this way. the first program i
published there does it by mistake, then i fixed it by using 'xor'
instead of (+) and published here that i've considered most fair
comparison

OTOH Don used this gcc optimization to generate faster code for
haskell. he doesn't used this trick for C++ and doesn't omitted
unoptimized gcc results from the chart. as a result people who don't
analyzed details made conclusion that ghc outperformed gcc here

so i have made experiment with cheating the same way, but in more
obvious manner. and i got 3 angry answers in 5 minutes. so what are
the difference? you don't catched details of Don comparison or you
bothered only by gcc-related cheating?

-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

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

[Haskell-cafe] Template Haskell compilation error on Windows (was Re: speed: ghc vs gcc)

[Peter Verswyvelen]

I tried to compile the template Haskell loop unrolling trick from Claus
Reinke on my machine which is running Windows and GHC 6.10.1, and I got
linker errors.
(note that compiling *without* -fvia-C works fine)

Compiling under Cygwin did not solve it. Any ideas how I could get this
working? I have no experience with TH yet so I might be missing something
essential...

Thanks,
Peter

c:\temp>ghc -O2 -fvia-C -optc-O3 -fforce-recomp Apply.hs
Apply.o:ghc6140_0.hc:(.text+0x7d): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziSyntax_VarP_con_info'
Apply.o:ghc6140_0.hc:(.text+0x10d): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziSyntax_VarE_con_info'
Apply.o:ghc6140_0.hc:(.text+0x19d): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziSyntax_VarP_con_info'
Apply.o:ghc6140_0.hc:(.text+0x571): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziSyntax_VarP_con_info'
Apply.o:ghc6140_0.hc:(.text+0x609): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziSyntax_VarE_con_info'
Apply.o:ghc6140_0.hc:(.text+0x6c9): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziSyntax_VarE_con_info'
Apply.o:ghc6140_0.hc:(.text+0x789): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziSyntax_VarE_con_info'
Apply.o:ghc6140_0.hc:(.text+0x82c): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziLib_a23_closure'
Apply.o:ghc6140_0.hc:(.text+0x868): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziLib_a23_closure'
Apply.o:ghc6140_0.hc:(.text+0x891): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziSyntax_VarP_con_info'
Apply.o:ghc6140_0.hc:(.text+0xd81): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziSyntax_VarP_con_info'
Apply.o:ghc6140_0.hc:(.text+0xe19): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziSyntax_VarE_con_info'
Apply.o:ghc6140_0.hc:(.text+0xed9): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziSyntax_VarE_con_info'
Apply.o:ghc6140_0.hc:(.text+0xf99): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziSyntax_VarE_con_info'
Apply.o:ghc6140_0.hc:(.text+0x103c): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziLib_a23_closure'
Apply.o:ghc6140_0.hc:(.text+0x1078): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziLib_a23_closure'
Apply.o:ghc6140_0.hc:(.text+0x10a1): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziSyntax_VarP_con_info'
Apply.o:ghc6140_0.hc:(.text+0x14d0): undefined reference to
`__stginit_templatezmhaskell_LanguageziHaskellziTHziSyntax_'
Apply.o:ghc6140_0.hc:(.text+0x292): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziLib_lamE_info'
Apply.o:ghc6140_0.hc:(.text+0x6ab): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziLib_a23_info'
Apply.o:ghc6140_0.hc:(.text+0x76b): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziLib_a23_info'
Apply.o:ghc6140_0.hc:(.text+0x9bc): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziLib_lamE_info'
Apply.o:ghc6140_0.hc:(.text+0xebb): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziLib_a23_info'
Apply.o:ghc6140_0.hc:(.text+0xf7b): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziLib_a23_info'
Apply.o:ghc6140_0.hc:(.text+0x11cc): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziLib_lamE_info'
C:\app\ghc-6.10.1/libHSrts.a(Main.o):Main.c:(.text+0x7): undefined reference
to `__stginit_ZCMain'
C:\app\ghc-6.10.1/libHSrts.a(Main.o):Main.c:(.text+0x36): undefined
reference to `ZCMain_main_closure'
collect2: ld returned 1 exit status



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

[Haskell-cafe] Re: Template Haskell compilation error on Windows (was Re: speed: ghc vs gcc)

[Don Stewart]

Missing --make

bugfact:
> I tried to compile the template Haskell loop unrolling trick from Claus Reinke
> on my machine which is running Windows and GHC 6.10.1, and I got linker 
> errors.
> 
> c:\temp>ghc -O2 -fvia-C -optc-O3 -fforce-recomp Apply.hs
> Apply.o:ghc6140_0.hc:(.text+0x7d): undefined reference to
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Template Haskell compilation error on Windows (was Re: speed: ghc vs gcc)

[Peter Verswyvelen]

I JUST FOUND OUT...SILLY ME!!! ;-)
On Sun, Feb 22, 2009 at 1:13 AM, Don Stewart  wrote:

> Missing --make
>
> bugfact:
> > I tried to compile the template Haskell loop unrolling trick from Claus
> Reinke
> > on my machine which is running Windows and GHC 6.10.1, and I got linker
> errors.
> >
> > c:\temp>ghc -O2 -fvia-C -optc-O3 -fforce-recomp Apply.hs
> > Apply.o:ghc6140_0.hc:(.text+0x7d): undefined reference to
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Re[7]: [Haskell-cafe] Re: speed: ghc vs gcc

[Sebastian Sylvan]

On Sun, Feb 22, 2009 at 12:10 AM, Bulat Ziganshin  wrote:

> Hello Sebastian,
>
> Sunday, February 22, 2009, 2:55:38 AM, you wrote:
> >  yes, you are right. Don also compared results of 64x-reduced
> >  computation with full one. are you think that these results are more
> >  fair?
>
> > Yes. Clearly so.
> > It still computes the result from scratch - it just uses a trick
> > which generates better code. This is clearly a useful and worthwhile
> > exercise as it shows A) A neat trick with TH, B) A reasonably
> > practical way to produce fast code for the critical parts of a
> > Haskell app, C) a motivating example for implementing a compiler
> > optimization to do it automatically.
>
> yes, but does you know why his last program is 64x faster than simple
> code? it's because *gcc* optimize it this way. the first program i
> published there does it by mistake, then i fixed it by using 'xor'
> instead of (+) and published here that i've considered most fair
> comparison
>
> OTOH Don used this gcc optimization to generate faster code for
> haskell. he doesn't used this trick for C++ and doesn't omitted
> unoptimized gcc results from the chart. as a result people who don't
> analyzed details made conclusion that ghc outperformed gcc here
>
> so i have made experiment with cheating the same way, but in more
> obvious manner. and i got 3 angry answers in 5 minutes. so what are
> the difference? you don't catched details of Don comparison or you
> bothered only by gcc-related cheating?
>

Bulat, please stop insulting everyone whenever you discuss something. Was
that sentence really necessary? You really think it's productive to
insinuate that I'm intellectualy dishonest?
I'm afraid I don't understand what you're talking about, could you try being
a bit clearer?
As I understand it you compared a gcc version which printed the precomputed
result, with a GHC version which computed the result at runtime, and got the
"150x" figure from that. Is this incorrect? If so, say so.

Don't accuse everyone who disagrees with you of being dishonest. NOBODY in
this thread has said anything to even remotely suggest that they think it's
okay to "cheat" in favour of Haskell and consider it fair, yet you jump to
this conclusion every single time. Please, give people the benefit of the
doubt? Just because someone disagrees with you does not make them stupid or
dishonest. Maybe they're actually right, or maybe you didn't make your point
clear enough, or maybe they just misunderstood you. Either way, please try
to be civil.

The only argument anyone made towards "cheating" on the gcc side is that ANY
program which just prints a precomputed result is worthless for comparisoin
(regardless of which side is doing it).

-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re[7]: [Haskell-cafe] Re: speed: ghc vs gcc

[Bulat Ziganshin]

Hello Louis,

Sunday, February 22, 2009, 2:59:05 AM, you wrote:

> Sebastian, that's not Bulat's point.  He's saying that if we make
> that optimization in Haskell, we should at least make the same
> optimization in GCC for fair comparison.  (Though I'm not entirely
> sure that that optimization would be of any use to GCC, but that's a 
> linguistic concern, no more.)

:)))  it was *ghc* who replaced 64 additions with just one:

sum += [n..n+k]  ==>  sum += n*k+const

my first program had this optimization by mistake. i've found way to
avoid it completely, Don found way to use it only in Haskell :)

>  
> His point is valid.  But Don's results *not* obtained by optimizing
> in this fashion are valid comparisons, and the results obtained with
> this optimization are useful for other reasons.

of course these results are useful! my own goal was just to make fair
comparison. i'm bothered when people said that ghc should be used
for something like video codecs based on those "let's optimize only
for haskell" pseudo-benchmarks. if Don was omitted unoptimized gcc
results from is chart and you don't wrote those "conclusions" based on
the chart, i will never make this comment


> Louis Wasserman
>  wasserman.lo...@gmail.com
>  

> On Sat, Feb 21, 2009 at 5:55 PM, Sebastian Sylvan
>  wrote:
>  

> On Sat, Feb 21, 2009 at 11:35 PM, Bulat Ziganshin
>  wrote:
>  
>  Hello Louis,
>  
>  Sunday, February 22, 2009, 2:30:23 AM, you wrote:
>  
>  yes, you are right. Don also compared results of 64x-reduced
>  computation with full one. are you think that these results are more
>  fair?


> Yes. Clearly so.
> It still computes the result from scratch - it just uses a trick
> which generates better code. This is clearly a useful and worthwhile
> exercise as it shows A) A neat trick with TH, B) A reasonably
> practical way to produce fast code for the critical parts of a
> Haskell app, C) a motivating example for implementing a compiler
> optimization to do it automatically.
>   

> Just outputting the precomputed result means nothing.






-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

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

Re: [Haskell-cafe] Re: speed: ghc vs gcc

[Don Stewart]

Bulat, you've some serious lessons to learn on how to interact with
online communities. First,

1. Stop posting replies to every post on this thread

2. Read some of the fine literature on how to be a productive,
contributing member of a mailing list community,

http://haskell.org/haskellwiki/Protect_the_community

3. Then see if you can rephrase your concerns in a form that will be
useful. Claus (as always) has made a fine suggestion:


http://www.haskell.org/pipermail/haskell-cafe/2009-February/056241.html

3. Come back with some analysis, or a ticket, and authentically try
to collaborate with people here to improve or fix the problems you see.

I'm setting your moderation bit now, and in public so we all know what
is going on, so your posts will bounce until you do something
constructive. This will likely expire in a few days - just enough to
calm things down.

-- Don (on jerk police protrol today)


P.S. if anyone strongly objects, let's talk offline how better to manage things.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Re[7]: [Haskell-cafe] Re: speed: ghc vs gcc

[Louis Wasserman]

Bulat,

Thank you for being productive. =)

of course these results are useful! my own goal was just to make fair
comparison. i'm bothered when people said that ghc should be used
for something like video codecs based on those "let's optimize only
for haskell" pseudo-benchmarks. if Don was omitted unoptimized gcc
results from is chart and you don't wrote those "conclusions" based on
the chart, i will never make this comment

Haskellers do need a baseline, y'know.  What I mean by that is, attempting
to write Haskell code that is as fast as gcc-optimized "typical" code is a
useful enterprise.  Of course it's possible to write a faster gcc program
than the one that Don compared to, but it's still a useful benchmark, and of
course it's not fair to optimize the heck out of Haskell code and leave gcc
code untouched and then say a comparison between *those* pieces of code is
fair.

I think we all agree on my original point now, that

   - Straightforward and simple Haskell code, written by an individual aware
   of issues with tail recursion and stream fusion, is frequently within 3x the
   speed of *straightforward and simple* GCC code when compiled with
   appropriate optimizations in GHC.

Sebastian, yes, there's still useful conversation to be had about more
super-heavily-optimized code.  (Bulat, if you'd like to continue posting
examples of more heavily optimized C and its outputted assembly, I think
that'd still provide a useful comparison in a conversation that can be
continued civilly on all sides.)

Louis Wasserman
wasserman.lo...@gmail.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Re[5]: [Haskell-cafe] Re: speed: ghc vs gcc

[John A. De Goes]

It's not practical at all. It's monstrously more complicated than C.  
It would be much simpler to do it in C and use FFI.


Regards,

John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration

http://www.n-brain.net|877-376-2724 x 101

On Feb 21, 2009, at 4:55 PM, Sebastian Sylvan wrote:

B) A reasonably practical way to produce fast code for the critical  
parts of a Haskell app,


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

Re: [Haskell-cafe] Re: speed: ghc vs gcc

[Ian Lynagh]

I think this thread has stopped being useful and started going round in
circles, so I've blocked all messages to it and...

On Sat, Feb 21, 2009 at 04:28:21PM -0800, Donald Bruce Stewart wrote:
> 
> I'm setting your moderation bit now

...reverted this.


Thanks
Ian

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

Re: [Haskell-cafe] ANNOUNCE: wxFruit-0.1.2

[Peter Verswyvelen]

Cool!
Does an overview exists of what can be done with wxFruit versus Yampa?

E.g. Yampa has many switchers (up to the amazing dpSwitch). Does wxFruit
support switching?

For what I can read at
http://www.cs.uu.nl/wiki/pub/Afp0607/DomainSpecificLanguages/fruit.pdf

wxFruit (by Bart Robinson and Paul Hudak)
* Does not support switching
* Does not support multiple windows
* The layout of widgets is intimately tied to the scoping of GUIs, which is
very inflexible.

Is this still valid (if it ever was)?

On Sat, Feb 21, 2009 at 12:13 AM, Henk-Jan van Tuyl wrote:

>
> L.S.,
>
> I have updated wxFruit to work with GHC 6.10; it can be downloaded from
> Hackage:
>  http://hackage.haskell.org/cgi-bin/hackage-scripts/package/wxFruit
>
> wxFruit is a graphical user interface that combines some of the power and
> versatility of wxHaskell with the elegance and simplicity of Fruit. The
> interface of wxFruit has a functional style, using arrows, whereas wxHaskell
> has an object oriented style.
>
> The package includes a demo game, PaddleBall: try to keep the ball in the
> game, using the mouse to move the paddle.
>
> The position of developer/maintainer is currently open.
>
> See also http://www.haskell.org/haskellwiki/WxFruit
>
> --
> Regards,
> Henk-Jan van Tuyl
>
>
> --
> http://functor.bamikanarie.com
> http://Van.Tuyl.eu/
> --
>
> ___
> 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] Array use breaks when I make it unboxed?

[Phil]

Hi,

The code below compiles fine as it is, but if I change the import statement
to:

import Data.Array.Unboxed

I get the following error:

philip-beadlings-imac-g5:MonteCarlo phil$ ghc -O2 --make test.hs
[2 of 5] Compiling InverseNormal( InverseNormal.hs, InverseNormal.o )

InverseNormal.hs:28:38:
No instance for (IArray a1 Double)
  arising from a use of `!' at InverseNormal.hs:28:38-40
Possible fix: add an instance declaration for (IArray a1 Double)
In the first argument of `(*)', namely `c ! 1'
In the first argument of `(+)', namely `c ! 1 * q'
In the first argument of `(*)', namely `(c ! 1 * q + c ! 2)'

and so on


My understanding is that I should just be able to use them like-for-like?
Anyone seen this before?

Thanks,

Phil.


module InverseNormal
where

import Array

a = listArray (1,6) [-3.969683028665376e+01, 2.209460984245205e+02,
 -2.759285104469687e+02, 1.383577518672690e+02,
 -3.066479806614716e+01, 2.506628277459239e+00]

b = listArray (1,5) [-5.447609879822406e+01, 1.615858368580409e+02,
 -1.556989798598866e+02, 6.680131188771972e+01,
 -1.328068155288572e+01]

c = listArray (1,6) [-7.784894002430293e-03, -3.223964580411365e-01,
 -2.400758277161838e+00, -2.549732539343734e+00,
 4.374664141464968e+00,  2.938163982698783e+00]

d = listArray (1,4) [7.784695709041462e-03,  3.224671290700398e-01,
 2.445134137142996e+00,  3.754408661907416e+00]

invnorm :: Double -> Double
invnorm p | p < 0.02425 = let q = sqrt ( -2*log(p) )
 in (c!1*q+c!2)*q+c!3)*q+c!4)*q+c!5)*q+c!6) /
d!1*q+d!2)*q+d!3)*q+d!4)*q+1)
   
  | p > (1-0.02425) = let q = sqrt ( -2*log(1-p) )
 in -(c!1*q+c!2)*q+c!3)*q+c!4)*q+c!5)*q+c!6)
/ d!1*q+d!2)*q+d!3)*q+d!4)*q+1)

  | otherwise = let q = p-0.5
r = q*q
in (a!1*r+a!2)*r+a!3)*r+a!4)*r+a!5)*r+a!6)*q
/ (b!1*r+b!2)*r+b!3)*r+b!4)*r+b!5)*r+1)


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

Re: [Haskell-cafe] Array use breaks when I make it unboxed?

[Felipe Lessa]

2009/2/21 Phil :

> InverseNormal.hs:28:38:
> No instance for (IArray a1 Double)
>   arising from a use of `!' at InverseNormal.hs:28:38-40
> Possible fix: add an instance declaration for (IArray a1 Double)
> In the first argument of `(*)', namely `c ! 1'
> In the first argument of `(+)', namely `c ! 1 * q'
> In the first argument of `(*)', namely `(c ! 1 * q + c ! 2)'

'a1' here is the type of the key. Try something like


> a = listArray (1 :: Int,6) [-3.969683028665376e+01, 2.209460984245205e+02,
>  -2.759285104469687e+02, 1.383577518672690e+02,
>  -3.066479806614716e+01, 2.506628277459239e+00]

or maybe

> b :: UArray (Int, Int) Double
> b = listArray (1,5) [-5.447609879822406e+01, 1.615858368580409e+02,
>  -1.556989798598866e+02, 6.680131188771972e+01,
>  -1.328068155288572e+01]

I think this is the problem.

HTH,

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

Re: [Haskell-cafe] Array use breaks when I make it unboxed?

[Phil]

Thanks for the tip - I got it to work using:

a :: UArray Int Double

 And so on.


Cheers,

Phil.


On 22/02/2009 01:05, "Felipe Lessa"  wrote:

> 2009/2/21 Phil :
> 
>> InverseNormal.hs:28:38:
>> No instance for (IArray a1 Double)
>>   arising from a use of `!' at InverseNormal.hs:28:38-40
>> Possible fix: add an instance declaration for (IArray a1 Double)
>> In the first argument of `(*)', namely `c ! 1'
>> In the first argument of `(+)', namely `c ! 1 * q'
>> In the first argument of `(*)', namely `(c ! 1 * q + c ! 2)'
> 
> 'a1' here is the type of the key. Try something like
> 
> 
>> a = listArray (1 :: Int,6) [-3.969683028665376e+01, 2.209460984245205e+02,
>>  -2.759285104469687e+02, 1.383577518672690e+02,
>>  -3.066479806614716e+01, 2.506628277459239e+00]
> 
> or maybe
> 
>> b :: UArray (Int, Int) Double
>> b = listArray (1,5) [-5.447609879822406e+01, 1.615858368580409e+02,
>>  -1.556989798598866e+02, 6.680131188771972e+01,
>>  -1.328068155288572e+01]
> 
> I think this is the problem.
> 
> HTH,

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

Re: [Haskell-cafe] Array use breaks when I make it unboxed?

[Felipe Lessa]

On Sat, Feb 21, 2009 at 10:26 PM, Phil  wrote:
> Thanks for the tip - I got it to work using:
>
> a :: UArray Int Double
>
>  And so on.

That's nice. I should have noted as well that you may say just

a, b, c, d :: UArray Int Double

or, even better,

type DataArray = UArray Int Double
a, b, c, d :: DataArray

And yes, that "UArray (Int,Int) Double" was a typo, sorry =).

Cheers,

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

Re: [Haskell-cafe] Hoogle and Network.Socket

[Jonathan Cast]

On Sat, 2009-02-21 at 07:25 -0700, John A. De Goes wrote:
> I think the (valid) concern is that too many people are choosing  
> platform-specific packages when there are alternatives available  
> (albeit not as convenient in some cases), and this really hurts the  
> Windows community because Windows is so radically different from all  
> the other operating systems.
> 
> Not showing platform-specific packages by default *might* make package  
> writers more likely to develop cross-platform packages. We've heard  
> many times someone say, "I don't know if it works on Windows, never  
> really thought of that."

Um, why *should* I think of that?

jcc


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

Re: [Haskell-cafe] Stacking StateTs

[Antoine Latter]

On Sat, Feb 21, 2009 at 5:37 PM, David Menendez  wrote:
>
> PS. Here are two functions that I ended up not using in my examples,
> but which may come in handy when dealing with nested applications of
> StateT:
>
> curryStateT :: (Monad m) => StateT (s,t) m a -> StateT s (StateT t m) a
> curryStateT m = StateT $ \s -> StateT $ \t ->
>runStateT m (s,t) >>= \ ~(a,(s,t)) -> return ((a,s),t)
>
> uncurryStateT :: (Monad m) => StateT s (StateT t m) a -> StateT (s,t) m a
> uncurryStateT m = StateT $ \ ~(s,t) ->
>runStateT (runStateT m s) t >>= \ ~((a,s),t) -> return (a,(s,t))
>

For some reason that reminds me of one of my favorites:

embedReader :: Monad m => ReaderT r m a -> Reader r (m a)
embedReader m = Reader $ \r -> runReaderT m r

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

Re: [Haskell-cafe] Hoogle and Network.Socket

[John A. De Goes]

Maybe because one Haskeller generally tries to help another one.  
That's what what it means to be a community, no?


Regards,

John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration

http://www.n-brain.net|877-376-2724 x 101

On Feb 21, 2009, at 6:47 PM, Jonathan Cast wrote:


On Sat, 2009-02-21 at 07:25 -0700, John A. De Goes wrote:

I think the (valid) concern is that too many people are choosing
platform-specific packages when there are alternatives available
(albeit not as convenient in some cases), and this really hurts the
Windows community because Windows is so radically different from all
the other operating systems.

Not showing platform-specific packages by default *might* make  
package

writers more likely to develop cross-platform packages. We've heard
many times someone say, "I don't know if it works on Windows, never
really thought of that."


Um, why *should* I think of that?

jcc




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

[Haskell-cafe] Re: The community is more important than the product

[Achim Schneider]

Don Stewart  wrote:

> http://haskell.org/haskellwiki/Protect_the_community
> 
> Random notes on how to maintain tone, focus and productivity in an
> online community I took a few years ago.
> 
> Might be some material there if anyone's seeking to help ensure
> we remain a constructive, effective community.
> 
> -- Don
> 
> P.S. release some code on hackage.haskell.org.

http://video.google.com/videoplay?docid=-4216011961522818645

-- 
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting,
performance and/or quoting of this signature prohibited.


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

Re: [Haskell-cafe] Hoogle and Network.Socket

[Thomas DuBuisson]

John A. De Goes:
> I think the (valid) concern is that too many people are choosing
> platform-specific packages when there are alternatives available
> (albeit not as convenient in some cases), and this really hurts the
> Windows community because Windows is so radically different from all
> the other operating systems.

Its apparent that Neil has the legitimate concern of general purpose
libraries becoming or being built on platform specific pieces - a
situation I also want to avoid seeing as I work on three different
platforms.  The point I'm trying to make is that some programs and
libraries perform platform specific taskes and that's ok - there is no
loss of portability because it wouldn't make sense to port them
anyway.  Examples include Debian/Arch packaging, X.org bindings /
Window Managers, Xen system call bindings, etc.

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

[Haskell-cafe] ANNOUNCE: X Haskell Bindings 0.2

[Antoine Latter]

I'd like to announce the 0.2.* series release of the X Haskell
Bindings.  This release, like the prior 0.1.* series focuses on making
the API prettier.  This does mean that there's a good chance this is a
breaking release.  Also, 0.2.* is based on the just-released version
1.4 of the XML descriptions of the X protocol.

The goal of XHB is to provide a Haskell implementation of the X11 wire
protocol, similar in spirit to the X protocol C-language Binding
(XCB).

On Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xhb

New this release:

In the core protocol, a lot of the fields which previously were of
type 'Word8' or 'Word16' now have appropriate higher-level types.

For example, in the type GetWindowAttributesReply, the 'class' field
was previously of type 'Word16', and is now of type 'WindowClass,'
and the 'all_event_masks' field was of type 'Word32' and is now of
type '[EventMask]'.

These improvements haven't made their way out to the extensions yet,
but the code-generation machinery is now in place for this to happen
as the information makes its way into the XML protocol description.

Related projects:

X C Bindings: http://xcb.freedesktop.org/

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

[Haskell-cafe] Re: [Haskell] ANNOUNCE: X Haskell Bindings 0.2

[Don Stewart]

aslatter:
> I'd like to announce the 0.2.* series release of the X Haskell
> Bindings.  This release, like the prior 0.1.* series focuses on making
> the API prettier.  This does mean that there's a good chance this is a
> breaking release.  Also, 0.2.* is based on the just-released version
> 1.4 of the XML descriptions of the X protocol.
> 
> The goal of XHB is to provide a Haskell implementation of the X11 wire
> protocol, similar in spirit to the X protocol C-language Binding
> (XCB).
> 
> On Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xhb

Woo, well done! Here's an Arch Linux package,

http://aur.archlinux.org/packages.php?ID=23765

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

[Haskell-cafe] Re: [Haskell] ANNOUNCE: X Haskell Bindings 0.2

[Felipe Lessa]

On Sun, Feb 22, 2009 at 2:08 AM, Antoine Latter  wrote:
> The goal of XHB is to provide a Haskell implementation of the X11 wire
> protocol, similar in spirit to the X protocol C-language Binding
> (XCB).
[snip]
> Related projects:
>
> X C Bindings: http://xcb.freedesktop.org/

I wonder how XHB is related to Xmonad, specially the need for
compositing. Sorry if this is a dumb question :).

Thanks,

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