Re: [Haskell-cafe] Status of Haskell under OsX

[Arne Dehli Halvorsen]

Manuel M T Chakravarty wrote:

I'm planning to purchase a MacBookPro so I'm wondering how well
Haskell is supported under this platform.


At least two of the regular contributors to GHC work on Macs.  That 
should ensure that Mac OS X is well supported.  Installation is 
trivial with the Mac OS X installer package:


  http://haskell.org/ghc/download_ghc_6_10_1.html#macosxintel

Hi, following on from this point:

How does one get gtk2hs running on a mac?

I have a MacBook Pro, and I've had ghc installed for some time now.

(first in 6.8.2 (packaged),
then 6.10.1 (packaged),
then 6.8.2 via macports 1.6
then 6.10.1 via macports 1.7)

I tried to install gtk2hs via macports, but it didn't work.
(0.9.12? on 6.8.2, then on 6.10.1)
Is there a recipe one could follow?
Can I get the preconditions via macports, and then use cabal to install
gtk2hs 0.10?

Grateful for assistance,
Arne D H


Manuel

___
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] Performance question

[Ketil Malde]

Lennart Augustsson  writes:

> C's rand() function is very bad and should never be used really.

On Linux (really GNU libc, I suppose) it is the same as random().  But
for portability, one is encouraged to spend the two extra letters.  I
don't understand the details, but I think the Mersenne twister is much
better in any case.  

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ByteString questions

[Galchin, Vasili]

;^)

On Thu, Feb 26, 2009 at 11:15 PM, Brandon S. Allbery KF8NH <
allb...@ece.cmu.edu> wrote:

> On 2009 Feb 26, at 23:58, Galchin, Vasili wrote:
>
> i.e. protocol events seem to "leak" into an application => yuck
>
> On Thu, Feb 26, 2009 at 10:57 PM, Galchin, Vasili wrote:
>
>> I already looked at MSDN examples and am not seriously enccouraged ;^(
>>
>
> So, next stop:  look for a serial library in C (or C++ with appropriate
> wrappers) for Win32 and make an FFI binding for it.
>
> --
> brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
> system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
> electrical and computer engineering, carnegie mellon universityKF8NH
>
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ByteString questions

[Brandon S. Allbery KF8NH]

On 2009 Feb 26, at 23:58, Galchin, Vasili wrote:

i.e. protocol events seem to "leak" into an application => yuck

On Thu, Feb 26, 2009 at 10:57 PM, Galchin, Vasili  
 wrote:

I already looked at MSDN examples and am not seriously enccouraged ;^(



So, next stop:  look for a serial library in C (or C++ with  
appropriate wrappers) for Win32 and make an FFI binding for it.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




PGP.sig
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] ByteString questions

[Galchin, Vasili]

i.e. protocol events seem to "leak" into an application => yuck

On Thu, Feb 26, 2009 at 10:57 PM, Galchin, Vasili wrote:

> I already looked at MSDN examples and am not seriously enccouraged ;^(
>
> Vasili
>
>
> On Thu, Feb 26, 2009 at 10:51 PM, Brandon S. Allbery KF8NH <
> allb...@ece.cmu.edu> wrote:
>
>> On 2009 Feb 26, at 23:45, Galchin, Vasili wrote:
>>
>>  I have forgotten about RS232 protocol. Can I just reads and writes
>> from the RS232 device from an application to handle data? Or do I need to
>> handle RS232 protocol events in the application?
>>
>>
>> Usually the OS handles protocol events, although you have to tell it what
>> kind of events matter (carrier? does it use hardware flow control, ^S/^Q, or
>> ETX/ACK?)  I suggest heading to MSDN and digging up documentation on how
>> serial devices work on Windows.
>>
>>  --
>> brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
>> system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
>> electrical and computer engineering, carnegie mellon universityKF8NH
>>
>>
>>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ByteString questions

[Galchin, Vasili]

I already looked at MSDN examples and am not seriously enccouraged ;^(

Vasili

On Thu, Feb 26, 2009 at 10:51 PM, Brandon S. Allbery KF8NH <
allb...@ece.cmu.edu> wrote:

> On 2009 Feb 26, at 23:45, Galchin, Vasili wrote:
>
>  I have forgotten about RS232 protocol. Can I just reads and writes
> from the RS232 device from an application to handle data? Or do I need to
> handle RS232 protocol events in the application?
>
>
> Usually the OS handles protocol events, although you have to tell it what
> kind of events matter (carrier? does it use hardware flow control, ^S/^Q, or
> ETX/ACK?)  I suggest heading to MSDN and digging up documentation on how
> serial devices work on Windows.
>
> --
> brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
> system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
> electrical and computer engineering, carnegie mellon universityKF8NH
>
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ByteString questions

[Brandon S. Allbery KF8NH]

On 2009 Feb 26, at 23:45, Galchin, Vasili wrote:
 I have forgotten about RS232 protocol. Can I just reads and  
writes from the RS232 device from an application to handle data? Or  
do I need to handle RS232 protocol events in the application?



Usually the OS handles protocol events, although you have to tell it  
what kind of events matter (carrier? does it use hardware flow  
control, ^S/^Q, or ETX/ACK?)  I suggest heading to MSDN and digging up  
documentation on how serial devices work on Windows.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




PGP.sig
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: statep haskell-lang [was: Re: Hoogle and Network.Socket]

[Achim Schneider]

Jonathan Cast  wrote:

> I've been busy convincing myself I'm really trying to
> replace TeX, instead.  After all, TeX is clearly a much less adequate
> programming language...
>
That's brilliant. 

OTOH, remember Oedipus, who, by attempting to avoid hubris, got caught
right in it.

(The old Greeks are true buggers when it comes to morales)

-- 
(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] Re: Coming up with a better API for Network.Socket.recv

[Brandon S. Allbery KF8NH]

On 2009 Feb 26, at 23:41, Achim Schneider wrote:

"Brandon S. Allbery KF8NH"  wrote:

On 2009 Feb 26, at 16:45, Johan Tibell wrote:

definition of `recv` would look like. My current thinking is that it
would mimic what C/Python/Java does and return a zero length
ByteString when EOF is reached.


Ew.  Isn't this what Maybe is for?

Anyway, the reason recv doesn't return 0 is that if you have a
datagram socket, a zero-length recv is valid and doesn't mean EOF.


My man page says a retval of 0 means that "the peer has performed an
orderly shutdown", which, in the UDP case, means that it has send a
complete datagram... no mention of EOF. A true EOF in the sense of "no
more data will be received" would mean unbinding the socket.


Right.  Just have to realize that a zero-length datagram packet is  
possible and even meaningful, so 0 isn't available as an EOF flag.


Anyway, the POSIX spec indicates the EOF condition as return -1 with  
errno == ECONNRESET; this should not be taken as anything but the  
limited expressiveness of a C-based API.  We should map this return to  
Nothing.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




PGP.sig
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] ByteString questions

[Galchin, Vasili]

Hi Brandon,

 I have forgotten about RS232 protocol. Can I just reads and writes from
the RS232 device from an application to handle data? Or do I need to handle
RS232 protocol events in the application?

Thanks, Vasili

On Thu, Feb 26, 2009 at 10:30 PM, Brandon S. Allbery KF8NH <
allb...@ece.cmu.edu> wrote:

> On 2009 Feb 26, at 23:16, Galchin, Vasili wrote:
>
> h  but at work I am surreptitiously writing in Haskell to test
> firmware and the platform in Windows XP, Brandon. So if I want something
> other than the default port configuration I am out of luck? (the default is
> 9600, ??,??,??)?
>
>
> I didn't mention how to do it on Windows because I have no idea how to do
> it.  You can look in the Win32 hierarchy in the hierarchical libraries:
> http://www.haskell.org/ghc/docs/latest/html/libraries/index.html
>
> --
> brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
> system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
> electrical and computer engineering, carnegie mellon universityKF8NH
>
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Coming up with a better API for Network.Socket.recv

[Achim Schneider]

"Brandon S. Allbery KF8NH"  wrote:

> On 2009 Feb 26, at 16:45, Johan Tibell wrote:
> > definition of `recv` would look like. My current thinking is that it
> > would mimic what C/Python/Java does and return a zero length
> > ByteString when EOF is reached.
> 
> Ew.  Isn't this what Maybe is for?
> 
> Anyway, the reason recv doesn't return 0 is that if you have a  
> datagram socket, a zero-length recv is valid and doesn't mean EOF.   
>
My man page says a retval of 0 means that "the peer has performed an
orderly shutdown", which, in the UDP case, means that it has send a
complete datagram... no mention of EOF. A true EOF in the sense of "no
more data will be received" would mean unbinding the socket.


-- 
(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] ByteString questions

[Brandon S. Allbery KF8NH]

On 2009 Feb 26, at 23:16, Galchin, Vasili wrote:
h  but at work I am surreptitiously writing in Haskell to  
test firmware and the platform in Windows XP, Brandon. So if I want  
something other than the default port configuration I am out of  
luck? (the default is 9600, ??,??,??)?



I didn't mention how to do it on Windows because I have no idea how to  
do it.  You can look in the Win32 hierarchy in the hierarchical  
libraries:  http://www.haskell.org/ghc/docs/latest/html/libraries/index.html


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




PGP.sig
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] Translating an imperative algorithm - negascout

[Anton van Straaten]

Colin Paul Adams wrote:

I want to implement the negascout algorithm for the game I'm writing.

Wikipedia gives the algorithm in imperative terms:

http://en.wikipedia.org/wiki/Negascout

I've tried to translate this into Haskell. I'm not sure if I'm going
about it the right way, and if I am, if I've done it correctly.


Variable names like alpha'' can be seen as an indication that a function 
is too big and/or monolithic.  It's worth keeping in mind the lesson of 
the lambda calculus: that a local variable is just a function in disguise.


To exploit that, you can replace definitions and uses of variables like 
alpha' and alpha'' with calls to functions.  Wherever you have something 
like:


  let alpha' = 
  in 

...try changing it to something like:

  foo 
  ...
  where foo alpha = 

Instead of a monolithic deeply-nested conditional expression, this will 
naturally lead to a set of small functions which call other small 
functions.  As Toby Hutton said, you should also factor out any 
repetition into functions.


One advantage of defining small functions like this is that you can also 
take advantage of guard syntax, which used appropriately in Haskell can 
be cleaner and more readable than either 'case' or 'if'.


For example, to deal with the following pseudocode:

  a := -negascout (child, depth-1, -b, -alpha)
  if a > alpha
 alpha := a

You could write a function such as:

  newAlpha a | a > alpha = a
 | otherwise = alpha

Note this function depends on 'alpha'.  To avoid having to pass extra 
parameters around all over the place, simply define this function using 
a 'where' clause, at the appropriate scope level so that the 'alpha' it 
needs is in scope.  In your example, it would probably be defined in 
your negascout' function, something like this:


  negascout' node depth beta' alpha beta rest =
...
where
  newAlpha a | a > alpha = a
 | otherwise = alpha

Note that newAlpha needs to be called with the result of a call to 
negascout.  While we're about it, notice that both of the recursive 
calls to negascout use the same first two arguments, so just for 
readability, we can define this:


  search a b = -negascout child (depth-1) (-b) (-a)

The pseudocode above can now be (mostly) replaced with a call 
'newAlpha', as follows:


  newAlpha (search alpha b)

However, this doesn't deal with what happens to the result of the call 
to newAlpha.  In the imperative pseudocode, alpha is mutated.  For a 
functional version, you can just repeat the above strategy: define a 
function which takes an argument alpha, and call that function with the 
new value for alpha, i.e. the result of the call to newAlpha, so 
something like:


  foo (newAlpha $ search alpha b)

The foo function will implement the remainder of the body of the foreach 
loop from the pseudocode.  (Coming up with a better name than 'foo' is 
left as an exercise...)


I tried this and the result was 13-16 lines, depending how you count, of 
code that is of similarly high level to the original pseudocode.


Anton

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

Re: [Haskell-cafe] ByteString questions

[Galchin, Vasili]

h  but at work I am surreptitiously writing in Haskell to test
firmware and the platform in Windows XP, Brandon. So if I want something
other than the default port configuration I am out of luck? (the default is
9600, ??,??,??)?

Vasili

On Thu, Feb 26, 2009 at 9:51 PM, Brandon S. Allbery KF8NH <
allb...@ece.cmu.edu> wrote:

> On 2009 Feb 26, at 18:50, Galchin, Vasili wrote:
>
> 1) I noticed there is no "open" function in Data.ByteString. So when I
> call writeFile or readFile is there an implicit open?
>
>
> Correct; they're modeled after the writeFile and readFile functions in
> System.IO.
>
> 2) For both readFile and writeFile, the first parameter is of type
> FilePath (which is of course alliased to just String). In any case, for
> Windows and POSIX OS's like Linux can read and write to a serial device like
> RS232 by specfiying the device path, e.g. /dev/tty01?
>
>
> Only if the default port configuration is sufficient.  You may need to use
> System.IO.Posix functions to set things up, then wrap in a Handle and pass
> to getContents.
>
> --
> brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
> system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
> electrical and computer engineering, carnegie mellon universityKF8NH
>
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ByteString questions

[Brandon S. Allbery KF8NH]

On 2009 Feb 26, at 18:50, Galchin, Vasili wrote:
1) I noticed there is no "open" function in Data.ByteString. So  
when I call writeFile or readFile is there an implicit open?


Correct; they're modeled after the writeFile and readFile functions in  
System.IO.


2) For both readFile and writeFile, the first parameter is of  
type FilePath (which is of course alliased to just String). In any  
case, for Windows and POSIX OS's like Linux can read and write to a  
serial device like RS232 by specfiying the device path, e.g. /dev/ 
tty01?


Only if the default port configuration is sufficient.  You may need to  
use System.IO.Posix functions to set things up, then wrap in a Handle  
and pass to getContents.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




PGP.sig
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] Re: statep haskell-lang [was: Re: Hoogle and Network.Socket]

[Jonathan Cast]

On Thu, 2009-02-26 at 22:34 -0500, Brandon S. Allbery KF8NH wrote:
> There's something I'm missing in all of this.
> 
> Perl is in the process of rebooting itself (perl6 is syntactically  
> very different from perl5; the closest it's ever previously gotten to  
> this kind of radical change was the change from ' to :: as the package  
> separator).  Perl5 will continue to exist, and probably even be  
> maintained.  So why is it not possible to declare Haskell98 and  
> Haskell10 (or whatever Haskell' becomes) as stable, maintained  
> languages for production use, then reboot the Haskell development  
> process?

Right, that's what I want.  (Although perl6 has been a long time in
coming).  Haskell is, far and away, the best name I can think of for the
next mainstream research language.  I just don't think it's going to
happen.

> In fact, I thought that was the reason Haskell98 support is  
> retained in Haskell compilers?

jcc


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

Re: [Haskell-cafe] Coming up with a better API for Network.Socket.recv

[Brandon S. Allbery KF8NH]

On 2009 Feb 26, at 16:45, Johan Tibell wrote:

definition of `recv` would look like. My current thinking is that it
would mimic what C/Python/Java does and return a zero length
ByteString when EOF is reached.


Ew.  Isn't this what Maybe is for?

Anyway, the reason recv doesn't return 0 is that if you have a  
datagram socket, a zero-length recv is valid and doesn't mean EOF.   
(Not that many UDP-using programs know what to do with a 0-length  
packet.)  So you need to indicate "EOF" (sender closed its end) in  
some different way.  It *should* have been Maybe


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




PGP.sig
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] Re: statep haskell-lang [was: Re: Hoogle and Network.Socket]

[Brandon S. Allbery KF8NH]

There's something I'm missing in all of this.

Perl is in the process of rebooting itself (perl6 is syntactically  
very different from perl5; the closest it's ever previously gotten to  
this kind of radical change was the change from ' to :: as the package  
separator).  Perl5 will continue to exist, and probably even be  
maintained.  So why is it not possible to declare Haskell98 and  
Haskell10 (or whatever Haskell' becomes) as stable, maintained  
languages for production use, then reboot the Haskell development  
process?  In fact, I thought that was the reason Haskell98 support is  
retained in Haskell compilers?


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




PGP.sig
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Boston Area Haskell User's Group, first meeting on Saturday February 28th

[Shae Matijs Erisson]

This weekend the Boston Area Haskell User's Group will have its first meeting.
You are invited to the mailing list, and to the first meeting this weekend!
If you think you'll show up to the meeting, please send your RSVP to the
mailing list, thanks!

Mailing list: http://groups.google.com/group/bostonhaskell

Agenda:
Edward Kmett will talk about either comonads or Kan extensions.
Shae Erisson will talk about QuickCheck and relatives.
Some attendees will volunteer to talk at the next meeting (I hope).

Time: Starts at noon, organized stuff stops at 2pm.

Place: BlueSpec in Waltham, MA

Wikipage with directions to the venue: 
http://www.haskell.org/haskellwiki/Boston_Area_Haskell_Users%27_Group

If you're in or near Boston and you're interested in Haskell, show up!
-- 
Programming is the Magic Executable Fridge Poetry, | www.ScannedInAvian.com
It is machines made of thought, fueled by ideas.   | -- Shae Matijs Erisson


pgpbNL5lNqPeA.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

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

[Belka]

Thanks, Manlio!

>What system?
A r c h Linux (2.6.27)

>Is the timeout the same with a plain C program?
Didn't try yet... ^__^

>> I know that controlling timeout is somehow connected to select(2)
>Yes.
>The only working method is to set the socket to non blocking mode, and
>use select (or poll/epoll/kqueue).

Thanks, now I'm confident, that am on the right way! ^__^
I wonder, if *select* really blocks the whole process... or blocks just the
"green" thread, that called it?..
It doesn't depend from being safe/unsafe FFI-ed, does it?

Belka
-- 
View this message in context: 
http://www.nabble.com/controlling-timeout-for-Network.Socket.connect---how--tp22139581p22236279.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

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

[Belka]

Thanks, Manlio!

>What system?
ArchLinux (2.6.27)

>Is the timeout the same with a plain C program?
Didn't try yet... ^__^

>> I know that controlling timeout is somehow connected to select(2) 
>Yes.
>The only working method is to set the socket to non blocking mode, and 
>use select (or poll/epoll/kqueue).

Thanks, now I'm confident, that am on the right way! ^__^
I wonder, if *select* really blocks the whole process... or blocks just the
"green" thread, that called it?.. 
It doesn't depend from being safe/unsafe FFI-ed, does it?

Belka
-- 
View this message in context: 
http://www.nabble.com/controlling-timeout-for-Network.Socket.connect---how--tp22139581p22235312.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] ByteString questions

[Galchin, Vasili]

Hello,

1) I noticed there is no "open" function in Data.ByteString. So when I
call writeFile or readFile is there an implicit open?

2) For both readFile and writeFile, the first parameter is of type
FilePath (which is of course alliased to just String). In any case, for
Windows and POSIX OS's like Linux can read and write to a serial device like
RS232 by specfiying the device path, e.g. /dev/tty01?


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

Re: [Haskell-cafe] Re: statep haskell-lang [was: Re: Hoogle and Network.Socket]

[Jonathan Cast]

On Fri, 2009-02-27 at 00:04 +0100, Achim Schneider wrote:
> Jonathan Cast  wrote:
> > (I am actually writing my own language;
> > when I get something usable for real work, I may very well just plain
> > un-subscribe from haskell-cafe, even though I will continue using
> > Haskell for bootstrapping for some time after that.)

I've actually got a complete syntax (except the module system (which,
for me, means mostly type classes :)), a type checker (which has lambda
terms --- including higher-order ones --- but no local declarations
yet), and an implementation that seems like it would mostly do what I
want if the standard library were rich enough to write interesting
things in.

Actual documentation is more lacking: I'm partway through a syntax man
page (including I think the most interesting parts of the language);
unfortunately, it's written in Global Script, and uses both features of
the language I haven't implemented yet and a library I haven't even
started.

> /me is curious.

I'm not sure what the best interface for publishing this is.  Blogs seem
to be somewhat standard; I should probably revive mine.

> And I'm wondering whether you're aware of the stuff Luke is working on
> (http://lukepalmer.wordpress.com/).

I've read all those posts through Planet Haskell; I don't think they've
made it into my list of interesting things to consider w.r.t. language
design yet.

> Personally, I've got some thoughts
> about a syntax, a preliminary parser and a lot of half-understood ideas.

Hmm.  Today's the first day I've really given serious consideration to
the viability of replacing Haskell with Global Script, even in
principle.  After all, trying to replace one of the most successful
research languages in existence would be hubristic.  (And as SPJ has
said, it won't happen by someone setting out to do it explicitly).  To
avoid hubris (which my study of Greek tragedy tells me is the greatest
danger to heroes), I've been busy convincing myself I'm really trying to
replace TeX, instead.  After all, TeX is clearly a much less adequate
programming language...

jcc


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

Re: [Haskell-cafe] Translating an imperative algorithm - negascout

[Toby Hutton]

On Fri, Feb 27, 2009 at 7:54 AM, Colin Paul Adams
 wrote:
> Hello Haskellers,
>
> I want to implement the negascout algorithm for the game I'm writing.
>
> Wikipedia gives the algorithm in imperative terms:
>
> http://en.wikipedia.org/wiki/Negascout
>
> I've tried to translate this into Haskell. I'm not sure if I'm going
> about it the right way, and if I am, if I've done it correctly.

In my opinion keeping the code looking vaguely like the pseudo-code is
a good idea for when you revisit it weeks later and try to remember
what the hell you were originally doing.

But I don't want to try and refactor the code you've provided without
some tests to ensure everything is correct.  Rule number one for
refactoring. :)  But for starters I imagine it's far more readable to
covert all the 'case boolExpr of' expressions to 'if then else'.

Secondly there's a lot of repeated functionality in there that should
be abstracted to smaller functions, which I think could still be done
without sacrificing the correlation to the algorithm pseudocode.
There's 3 parts which check if alpha is greater than beta which could
be abstracted and there's the check if rest is empty else recurse
which could be abstracted.  negascout' would be far more readable if
you did this as long as you gave the helper functions good names. :)

Sorry to be so vague though.  If you have some data and tests then I
can help you out some more if you like.




> Any comments on my effort here, are welcome:
>
> module Move (negascout
>            ) where
>
> {-# contract negascout Ok -> {depth | depth >= 0} ->
>  Ok -> Ok -> Ok #-}
> negascout :: Node -> Int -> Int -> Int -> Int
> negascout node depth alpha beta =
>    case depth == 0 || is_terminal node of
>      True -> evaluate node
>      False -> let child:rest = children node
>                   b = beta  -- initial window is (-beta, -alpha)
>               in negascout' child (depth-1) (- b) (- alpha) beta rest
>
>
> -- Implementation
>
> {-# contract negascout' Ok -> {depth | depth >= 0} ->
>  Ok -> Ok -> Ok -> Ok -> Ok #-}
> negascout' :: Node -> Int -> Int -> Int -> Int -> [Node] -> Int
> negascout' node depth beta' alpha beta rest =
>    let a = negate $ negascout child depth beta' alpha
>    in case a > (- alpha) of
>         True -> let alpha' = a
>                 in case alpha' >= beta of
>                      True -> alpha' -- beta cut-off
>                      False -> case alpha' >= (- beta') of -- null window 
> failed high?
>                                 True -> let alpha'' = negate $ negascout 
> child depth (- beta) (- alpha') -- full re-search
>                                         in case alpha'' >= beta of
>                                                         True -> alpha'' -- 
> beta cut-off
>                                                         False -> case rest of
>                                                                    [] -> 
> alpha''
>                                                                    
> child':rest' -> let b' = alpha'' + 1
>                                                                               
>      in negascout' child' depth (- b') alpha'' beta rest'
>                                            False -> case rest of
>                                                       [] -> alpha'
>                                                             child':rest' ->  
> let b' = alpha' + 1
>                                                                              
> in negascout' child' depth (- b') alpha' beta rest'
>                    False -> case rest of
>                               [] -> alpha
>                                     child':rest' ->  let b' = alpha + 1
>                                                      in negascout' child' 
> depth (- b') alpha beta rest'
>
>
> --
> Colin Adams
> Preston Lancashire
> ___
> 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] Re: Coming up with a better API for Network.Socket.recv

[Achim Schneider]

"Bryan O'Sullivan"  wrote:

> There's another problem with the network APIs: they mirror the BSD
> socket API too faithfully, and provide insufficient type safety. You
> can try to send on an unconnected socket, and to bind a socket that's
> already connected, both of which should be statically forbidden. The
> APIs for datagram-oriented networking ought to be distinct from the
> stream-oriented variety, I think, even if the underlying C-level
> calls end up being substantially the same.
>
Iteratees to the rescue? Ideally, we'd have a composable IO system
that's uniform across different types of IO.

-- 
(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] Re: statep haskell-lang [was: Re: Hoogle and Network.Socket]

[Achim Schneider]

Jonathan Cast  wrote:

> (I am actually writing my own language;
> when I get something usable for real work, I may very well just plain
> un-subscribe from haskell-cafe, even though I will continue using
> Haskell for bootstrapping for some time after that.)
>
/me is curious. 
And I'm wondering whether you're aware of the stuff Luke is working on
(http://lukepalmer.wordpress.com/). Personally, I've got some thoughts
about a syntax, a preliminary parser and a lot of half-understood ideas.

-- 
(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] Coming up with a better API for Network.Socket.recv

[Bryan O'Sullivan]

On Thu, Feb 26, 2009 at 1:45 PM, Johan Tibell wrote:

> I find it quite inconvenient to use the `recv` function in
> Network.Socket as it throws an exception when reaching EOF and there's
> no way to check whether EOF has been reached before calling `recv`.


I agree, the current behaviour is quite unfortunate. In fact, I'm pretty
sure I added an entry point named recv_ to network-bytestring to work around
precisely this problem.


> I'm also interested in understanding the reasons behind the design of
> the `recv` function in the network library.


I think that it was modeled after the Handle API, which provides an isEOF
function that you can call to see whether a Handle is done before you try
reading it. This works well enough on a Handle because it's buffered, but
sockets aren't buffered, and the symmetric isEOF function isn't available. I
don't like the way the Handle API works, but I grudgingly accept it as not
amenable to change.

There's another problem with the network APIs: they mirror the BSD socket
API too faithfully, and provide insufficient type safety. You can try to
send on an unconnected socket, and to bind a socket that's already
connected, both of which should be statically forbidden. The APIs for
datagram-oriented networking ought to be distinct from the stream-oriented
variety, I think, even if the underlying C-level calls end up being
substantially the same.

Really, the big thing that's missing here is enough application of elbow
grease from someone who's got a good eye for design and doesn't mind all the
slog involved. I think that if someone published a network-alt package (much
like the one that was published a few years ago) and tooted their horn
vigorously enough, we could put the existing network package out to pasture
in fairly short order.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: statep haskell-lang [was: Re: Hoogle and Network.Socket]

[Jonathan Cast]

On Thu, 2009-02-26 at 15:23 -0700, John A. De Goes wrote:
> On Feb 26, 2009, at 1:36 PM, Jonathan Cast wrote:
> > On Thu, 2009-02-26 at 13:25 -0700, John A. De Goes wrote:
> >> No, I hate C and will never use it again in my entire life unless
> >> forced to at the point of a gun.
> >
> > Why?  Its libraries are far better, its editors are far better [1],  
> > its
> > compilers are far better, its tool support is far better, it's
> > incomparably superior in every possible way to Haskell.
> 
> There are better languages than C with more libraries and better tools  
> (e.g. Java). I would chose one of those over Haskell for a commercial  
> product needing short time-to-market and a long shelf life.

OK, great.  But still: if you want Java, you know where to find it.

> Even  
> though Haskell is a superior language, there are other, often more  
> important considerations for anything but hobby coding.
> 
> > Except the relatively narrow criterion of the *language itself*.   
> > Maybe
> > making languages better is a worthwile pursuit, then?  Or do you still
> > think languages should be frozen in time[2] so the tools, compilers,
> > editors, libraries, etc. can undergo vast improvements?
> 
> I think to reap the benefits of a language, it must necessarily stop  
> evolving in ways that impose high costs on its user base.
> 
> > [2] For the record: I'd be content to see a frozen production  
> > language,
> > like Haskell, frozen in time; as long there's a credible other
> > evolveable language --- preferably one with zero backward- 
> > compatibility
> > requirements w.r.t. Haskell 98 or current or past GHC.
> 
> Let me ask you this question: If I wanted a language like Haskell, but  
> which is "Enterprise ready", where should I turn?

My *optimal* solution (not one I actually expect): Haskell forks.  One
frok retains backwards-compatibility, but gives up type families and any
new language developments.  If that language evolves, I can *guarantee*
you I will dislike any changes it makes (see Java generics for an
example; see the entirety of C++ for another).

The other fork continues to impose `high costs' on its user base, in the
name of being the best language it can possibly be.  This will
eventually involve just discarding features of Haskell 98 that get in
the way.

> My answer: Haskell. It's maturing and its slowed rate of evolution is  
> already having beneficial effects on other dimensions.

Beneficial as per you.  Not everyone agrees/cares --- not everyone is
doing Enterprise programming!

> >  Re-designing a
> > purely function research language from the ground up would be neat ---
> > but then it wouldn't be Haskell at all, and I wouldn't use Haskell,  
> > I'd
> > use the new language.  If I thought I could realistically leave the
> > Haskell community, I wouldn't be nearly so opposed to Haskell's
> > continued slide into practicality.
> 
> Why do you think you'll have no where else to go if Haskell continues  
> moving away from being a research language?

I have nowhere to go as yet.  (I am actually writing my own language;
when I get something usable for real work, I may very well just plain
un-subscribe from haskell-cafe, even though I will continue using
Haskell for bootstrapping for some time after that.)

> There are plenty of people  
> who would join you. I think you'd have far more company than you seem  
> to believe.

Yeah, I'd have the company of everyone who argues against you in this
(quite on-going) debate.  At least in spirit (how long it will take for
a new common research language to emerge from the mist is another
matter).

> And a fresh start, with absolutely zero requirements for  
> any backward compatibility, would open up many new directions.

I agree with that.  Although you're trying to argue those directions are
less valuable than I think they are!

In any case, I'm going to *try* not to continue this discussion any
further.  Best case nothing beneficial comes of it; worst case
participating in it slows down Global Script development.

jcc


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

[Haskell-cafe] Hardware for FRP programming - what should it support?

[Noam Lewis]

Greetings,

I've heard about the Reduceron (graph reduction machine in FPGA), and
also FRP (functional reactive programming).

What sort of features/capabilities/architecture would you expect from
a processor that will be designed a-priori for FRP programming?
I guess it will need graph-reduction capabilities for the Functional
in FRP, but what other tools do we need or can we take advantage of
for the Reactive Programming?

I haven't thought about this much yet, just a question that came to
mind.

Any thoughts?

- Noam

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

Re: [Haskell-cafe] Re: statep haskell-lang [was: Re: Hoogle and Network.Socket]

[John A. De Goes]

On Feb 26, 2009, at 1:36 PM, Jonathan Cast wrote:

On Thu, 2009-02-26 at 13:25 -0700, John A. De Goes wrote:

No, I hate C and will never use it again in my entire life unless
forced to at the point of a gun.


Why?  Its libraries are far better, its editors are far better [1],  
its

compilers are far better, its tool support is far better, it's
incomparably superior in every possible way to Haskell.


There are better languages than C with more libraries and better tools  
(e.g. Java). I would chose one of those over Haskell for a commercial  
product needing short time-to-market and a long shelf life. Even  
though Haskell is a superior language, there are other, often more  
important considerations for anything but hobby coding.


Except the relatively narrow criterion of the *language itself*.   
Maybe

making languages better is a worthwile pursuit, then?  Or do you still
think languages should be frozen in time[2] so the tools, compilers,
editors, libraries, etc. can undergo vast improvements?


I think to reap the benefits of a language, it must necessarily stop  
evolving in ways that impose high costs on its user base.


[2] For the record: I'd be content to see a frozen production  
language,

like Haskell, frozen in time; as long there's a credible other
evolveable language --- preferably one with zero backward- 
compatibility

requirements w.r.t. Haskell 98 or current or past GHC.


Let me ask you this question: If I wanted a language like Haskell, but  
which is "Enterprise ready", where should I turn?


My answer: Haskell. It's maturing and its slowed rate of evolution is  
already having beneficial effects on other dimensions.



 Re-designing a
purely function research language from the ground up would be neat ---
but then it wouldn't be Haskell at all, and I wouldn't use Haskell,  
I'd

use the new language.  If I thought I could realistically leave the
Haskell community, I wouldn't be nearly so opposed to Haskell's
continued slide into practicality.


Why do you think you'll have no where else to go if Haskell continues  
moving away from being a research language? There are plenty of people  
who would join you. I think you'd have far more company than you seem  
to believe. And a fresh start, with absolutely zero requirements for  
any backward compatibility, would open up many new directions.


Regards,

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

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


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

Re: [Haskell-cafe] Coming up with a better API for Network.Socket.recv

[Jonathan Cast]

On Thu, 2009-02-26 at 22:45 +0100, Johan Tibell wrote:
> Hi all,
> 
> I find it quite inconvenient to use the `recv` function in
> Network.Socket as it throws an exception when reaching EOF and there's
> no way to check whether EOF has been reached before calling `recv`.
> This means that all calls to `recv` needs to be wrapped in an
> exception handler.

NB:

  tryJust (guard . isEOFError) $ recv ...

with base-4 or

  tryJust (ioErrors >=> guard . isEOFError) $ recv ...

with base-3, right?

> I've been thinking about changing the version of
> `recv` that's included in the network-bytestring library [1] so it
> behaves differently from the one in the network library. Before I do
> so I thought I should see if we can reach a consensus on what a nicer
> definition of `recv` would look like. My current thinking is that it
> would mimic what C/Python/Java does and return a zero length
> ByteString when EOF is reached.

+1

In the interest of totality.

Also, Prelude.getChar/System.IO.hGetChar should have return type

  IO (Maybe Char)

in the interest of totality.

> I'm also interested in understanding the reasons behind the design of
> the `recv` function in the network library. More generally, I'm
> interested in discussing the pros and cons of the current Haskell I/O
> library design where the different read functions throw EOF exceptions
> and you have to call e.g. hIsEOF before reading from a Handle.
> 
> 1. http://github.com/tibbe/network-bytestring

jcc


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

[Haskell-cafe] Re: Coming up with a better API for Network.Socket.recv

[Achim Schneider]

Achim Schneider  wrote:

> Johan Tibell  wrote:
> 
> > I'm also interested in understanding the reasons behind the design
> > of the `recv` function in the network library.
> >
> POSIX semantics. And, frankly, I'm opposed to messing with them: If
> you want to have different behaviour, please do a (different|wrapper)
> library.
> 
Ouch. I revoke.

-- 
(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] Re: Coming up with a better API for Network.Socket.recv

[Achim Schneider]

Johan Tibell  wrote:

> I'm also interested in understanding the reasons behind the design of
> the `recv` function in the network library.
>
POSIX semantics. And, frankly, I'm opposed to messing with them: If you
want to have different behaviour, please do a (different|wrapper)
library.


-- 
(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] Bug in HLint or haskell-src-exts?

[Martin Huschenbett]

Hello again,

I found another problem I dont understand:


evalOp :: Op -> (Integer -> Integer -> Integer)
evalOp op = case op of
  Plus  -> (+)
  Minus -> \x y -> max 0 (x-y)
  Times -> (*)


brings a parse error, too:


Interpreter.hs:92:3: Parse failure, Parse error in expression: DVar 
[Ident "x",Ident "...




The mentioned position is the "T" of "Times" in the last line.

Regards,

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

[Haskell-cafe] Coming up with a better API for Network.Socket.recv

[Johan Tibell]

Hi all,

I find it quite inconvenient to use the `recv` function in
Network.Socket as it throws an exception when reaching EOF and there's
no way to check whether EOF has been reached before calling `recv`.
This means that all calls to `recv` needs to be wrapped in an
exception handler. I've been thinking about changing the version of
`recv` that's included in the network-bytestring library [1] so it
behaves differently from the one in the network library. Before I do
so I thought I should see if we can reach a consensus on what a nicer
definition of `recv` would look like. My current thinking is that it
would mimic what C/Python/Java does and return a zero length
ByteString when EOF is reached.

I'm also interested in understanding the reasons behind the design of
the `recv` function in the network library. More generally, I'm
interested in discussing the pros and cons of the current Haskell I/O
library design where the different read functions throw EOF exceptions
and you have to call e.g. hIsEOF before reading from a Handle.

1. http://github.com/tibbe/network-bytestring

Cheers,

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

[Haskell-cafe] Bug in HLint or haskell-src-exts?

[Martin Huschenbett]

Hello Haskellers,

I've got the following piece of code


type Memory addr value = Map.Map addr value

type Stack item = [item]

data MachineState addr value item = MachineState
  { memory :: Memory addr value
  , stack  :: Stack item
  }
  deriving (Show)

newtype Machine addr value item m a =
Machine { unMachine :: StateT (MachineState addr value item) m a }
  deriving (Monad, MonadState (MachineState addr value item), 
MonadTrans, MonadIO)



and HLint complains:


Machine.hs:20:31: Parse failure, Parse error


This is exactly the position of the opening bracket after MonadState. 
Why can GHC parse this and HLint cannot?


Regards,

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

Re: [Haskell-cafe] memory-efficient data type for Netflix data - UArray Int Int vs UArray Int Word8

[Manlio Perillo]

Kenneth Hoste ha scritto:

[...]
However, as I posted yesterday, I've been able to circumvent the issue 
by rethinking my data type, i.e. using
the ~18K movie IDs as key instead of the 480K user IDs, which radically 
limits the overhead...


Well, but what if you really need the original data structure, for 
better data processing?


That way, I'm able to fit the data set in <700M of memory, without 
having to reorganize the raw data.


The uvector package implements a vector of unboxed types, and has an 
snocU operation, to append an element to the array.


I don't know how efficient it is, however.



By the way, about uvector: it has a Stream data type, and you can 
build a vector from a stream.


Thanks for letting me know, I'll keep this in mind.



Let me know if there are performance improvements.

Arrays are one of the few things I dislike in Haskell, and all the 
available array/vector packages cause me some confusion.





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

Re: [Haskell-cafe] Re: statep haskell-lang [was: Re: Hoogle and Network.Socket]

[Miguel Mitrofanov]

Believe it or not, but I still edit Haskell sources with vi sometimes.  
My favorite Emacs doesn't work on iPhone.


On 26 Feb 2009, at 23:18, John A. De Goes wrote:



Are you saying has been no progress since K&R C in the number of  
libraries available to C programmers? And that C programmers still  
have to edit files with vi and compile and link by specifying all  
files on the command-line?


You may disagree, but the evidence points in the opposite direction.  
There are tens of thousands of robust C libraries available to suit  
any particular programming need. Many of Haskell's own libraries are  
based on C versions. Tool support for the C language (not for some  
successor you might think would exist if the language continued  
evolving) can detect memory leaks, detect memory overwrites, apply  
dozens of automatic refactorings to C large-scale C programs, etc.


Library and tool support for the C language is light years beyond  
Haskell. It wouldn't be there if we had been through 20 iterations  
of C each completely breaking backward compatibility.


Regards,

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

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

On Feb 26, 2009, at 1:08 PM, Achim Schneider wrote:


"John A. De Goes"  wrote:


What do you mean by "progress"? I noted before that there are
tradeoffs. Constraining the evolution of the language in backward
compatible ways leads to substantial improvements in tools,
libraries, and the speed of compiled code. That's progress in  
several

dimensions -- just not along the dimension of "language".


I disagree. Backwards compatibility can be the very reason no
progress _can_ be made in the areas you mention. The C toolchain was
and is a mess for anything but small, uniform, single-platform
programs, things like valgrind of course outperform plain lint in a
variety of ways, but are still hacks around the language's major  
flaws

(And I'm speaking as a C-fan, here). Further breakthroughs in C
compiler technology will require stalin-like brute force and library
support... well, did you ever use yacc or libxml and compared them to
Haskell solutions?

Java generics are broken by design, for the questionable benefit of
backwards compatibility. Leave those Bad Decisions to language
communities who don't care about Doing It Right. "Right" being a
technological measure here, not how well politics sell to  
accountants.


--
(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


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

[Haskell-cafe] Translating an imperative algorithm - negascout

[Colin Paul Adams]

Hello Haskellers,

I want to implement the negascout algorithm for the game I'm writing.

Wikipedia gives the algorithm in imperative terms:

http://en.wikipedia.org/wiki/Negascout

I've tried to translate this into Haskell. I'm not sure if I'm going
about it the right way, and if I am, if I've done it correctly.


Any comments on my effort here, are welcome:

module Move (negascout
) where

{-# contract negascout Ok -> {depth | depth >= 0} ->
  Ok -> Ok -> Ok #-}
negascout :: Node -> Int -> Int -> Int -> Int
negascout node depth alpha beta =
case depth == 0 || is_terminal node of
  True -> evaluate node
  False -> let child:rest = children node
   b = beta  -- initial window is (-beta, -alpha)
   in negascout' child (depth-1) (- b) (- alpha) beta rest


-- Implementation

{-# contract negascout' Ok -> {depth | depth >= 0} ->
  Ok -> Ok -> Ok -> Ok -> Ok #-}
negascout' :: Node -> Int -> Int -> Int -> Int -> [Node] -> Int
negascout' node depth beta' alpha beta rest =
let a = negate $ negascout child depth beta' alpha
in case a > (- alpha) of
 True -> let alpha' = a
 in case alpha' >= beta of
  True -> alpha' -- beta cut-off
  False -> case alpha' >= (- beta') of -- null window 
failed high?
 True -> let alpha'' = negate $ negascout child 
depth (- beta) (- alpha') -- full re-search
 in case alpha'' >= beta of
 True -> alpha'' -- 
beta cut-off
 False -> case rest of
[] -> 
alpha'' 

child':rest' -> let b' = alpha'' + 1

in negascout' child' depth (- b') alpha'' beta rest'
False -> case rest of
   [] -> alpha'
 child':rest' ->  
let b' = alpha' + 1
  
in negascout' child' depth (- b') alpha' beta rest'
False -> case rest of
   [] -> alpha
 child':rest' ->  let b' = alpha + 1
  in negascout' child' 
depth (- b') alpha beta rest'


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

[Haskell-cafe] Re: statep haskell-lang [was: Re: Hoogle and Network.Socket]

[Achim Schneider]

Jonathan Cast  wrote:

> IDEs are for losers
>
Hell is freezing over: I'm actually agreeing with an editor heretic.

-- 
(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] Re: statep haskell-lang [was: Re: Hoogle and Network.Socket]

[Achim Schneider]

"John A. De Goes"  wrote:

> Are you saying has been no progress since K&R C in the number of  
> libraries available to C programmers?
>
I never did, I asked you to compare usability. If you want it in plain
English, library semantics still suck, hell, there isn't even name
spacing.

> And that C programmers still have to edit files with vi and compile
> and link by specifying all files on the command-line?
>
No, we still use some kind of make, and, believe it or not, I've
written myself an omakefile that allows you to compile C with the same
ease as ghc --make compiles Haskell. It makes many assumptions about
the usage of imports, though: Such power will always be hackish in
C-land.

I am offended by the demeaning way you portray vi.

> You may disagree, but the evidence points in the opposite direction.  
> There are tens of thousands of robust C libraries available to suit  
> any particular programming need. Many of Haskell's own libraries are  
> based on C versions. 
>
Semantic suckage tends to collect around those libraries that aren't
pure Haskell, XHB has proven itself able to crash a _very_ mature piece
of C software, the X server. You won't have to search long for security
advisories exposing flaws in virtually every of those libraries,
usually caused by fundamental flaws of the language. Your point?

> Tool support for the C language (not for some successor you might
> think would exist if the language continued evolving) can detect
> memory leaks, detect memory overwrites, apply dozens of automatic
> refactorings to C large-scale C programs, etc.
> 
Hacks, as I said. None of them are able to address the fundamental
problems.

> Library and tool support for the C language is light years beyond  
> Haskell. It wouldn't be there if we had been through 20 iterations
> of C each completely breaking backward compatibility.
> 
It wouldn't be there if C was younger than Haskell, either, but still
suck the same.


-- 
(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] Re: statep haskell-lang [was: Re: Hoogle and Network.Socket]

[Jonathan Cast]

On Thu, 2009-02-26 at 13:25 -0700, John A. De Goes wrote:
> No, I hate C and will never use it again in my entire life unless  
> forced to at the point of a gun.

Why?  Its libraries are far better, its editors are far better [1], its
compilers are far better, its tool support is far better, it's
incomparably superior in every possible way to Haskell.

Except the relatively narrow criterion of the *language itself*.  Maybe
making languages better is a worthwile pursuit, then?  Or do you still
think languages should be frozen in time[2] so the tools, compilers,
editors, libraries, etc. can undergo vast improvements?

jcc

[1] They're not; IDEs are for losers
[2] For the record: I'd be content to see a frozen production language,
like Haskell, frozen in time; as long there's a credible other
evolveable language --- preferably one with zero backward-compatibility
requirements w.r.t. Haskell 98 or current or past GHC.  Re-designing a
purely function research language from the ground up would be neat ---
but then it wouldn't be Haskell at all, and I wouldn't use Haskell, I'd
use the new language.  If I thought I could realistically leave the
Haskell community, I wouldn't be nearly so opposed to Haskell's
continued slide into practicality.


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

[Haskell-cafe] Re: base-4 + gtk2hs-0.10.0 licensing

[Peter Hercek]

Wolfgang Jeltsch wrote:

Am Mittwoch, 25. Februar 2009 23:38 schrieb Peter Hercek:
  

So my opinion (IAMNAL):
1) source code under very limiting commercial license (just to allow
recompile with a newer LGPL lib and nothing else) is OK
2) it is probable that only the *.o, *.hi files and a linking script are
OK too



I think, it’s technically not possible to let your Haskell application use 
another library version when you just have the .o and .hi files of the new 
library version. The .hi files typically contain code which is inlined by the 
application, so you have to be able to recompile the application. Or am I 
misunderstanding you?
  


You may be right. I do not know. Compiler authors would know. But if the 
*only* problem is the inlined functions then it may not be that bad. 
Depends whether the depth of inlining has some limit and whether a 
change of code which is not inlined any more results in failure to link 
correctly too.
The point is that inlining itself is not a problem simply the code which 
is inlined represents the interface and you need to provide an option to 
upgrade to a newer library with the same interface only. The same 
problem is with shared objects in C. The header files may contains 
macros (which are inlined) and you are not forced to provide source code 
of your app despite the fact that compilation inlines some code from the 
LGPL library used. Simply that code is part of the interface and 
changing it changes the interface. The acceptable size of inlined 
fuctions for a C code is about 10 lines. I did not read any info how it 
would be for Haskell.


Peter.

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

Re: [Haskell-cafe] Re: statep haskell-lang [was: Re: Hoogle and Network.Socket]

[John A. De Goes]

No, I hate C and will never use it again in my entire life unless  
forced to at the point of a gun.


You're point? :-P

Regards,

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

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

On Feb 26, 2009, at 1:17 PM, Jonathan Cast wrote:


On Thu, 2009-02-26 at 13:18 -0700, John A. De Goes wrote:

Are you saying has been no progress since K&R C in the number of
libraries available to C programmers? And that C programmers still
have to edit files with vi and compile and link by specifying all
files on the command-line?

You may disagree, but the evidence points in the opposite direction.
There are tens of thousands of robust C libraries available to suit
any particular programming need. Many of Haskell's own libraries are
based on C versions. Tool support for the C language (not for some
successor you might think would exist if the language continued
evolving) can detect memory leaks, detect memory overwrites, apply
dozens of automatic refactorings to C large-scale C programs, etc.

Library and tool support for the C language is light years beyond
Haskell. It wouldn't be there if we had been through 20 iterations of
C each completely breaking backward compatibility.


Maybe you should use C then?

jcc




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

Re: [Haskell-cafe] Re: statep haskell-lang [was: Re: Hoogle and Network.Socket]

[Jonathan Cast]

On Thu, 2009-02-26 at 13:18 -0700, John A. De Goes wrote:
> Are you saying has been no progress since K&R C in the number of  
> libraries available to C programmers? And that C programmers still  
> have to edit files with vi and compile and link by specifying all  
> files on the command-line?
> 
> You may disagree, but the evidence points in the opposite direction.  
> There are tens of thousands of robust C libraries available to suit  
> any particular programming need. Many of Haskell's own libraries are  
> based on C versions. Tool support for the C language (not for some  
> successor you might think would exist if the language continued  
> evolving) can detect memory leaks, detect memory overwrites, apply  
> dozens of automatic refactorings to C large-scale C programs, etc.
> 
> Library and tool support for the C language is light years beyond  
> Haskell. It wouldn't be there if we had been through 20 iterations of  
> C each completely breaking backward compatibility.

Maybe you should use C then?

jcc


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

Re: [Haskell-cafe] Re: statep haskell-lang [was: Re: Hoogle and Network.Socket]

[John A. De Goes]

Are you saying has been no progress since K&R C in the number of  
libraries available to C programmers? And that C programmers still  
have to edit files with vi and compile and link by specifying all  
files on the command-line?


You may disagree, but the evidence points in the opposite direction.  
There are tens of thousands of robust C libraries available to suit  
any particular programming need. Many of Haskell's own libraries are  
based on C versions. Tool support for the C language (not for some  
successor you might think would exist if the language continued  
evolving) can detect memory leaks, detect memory overwrites, apply  
dozens of automatic refactorings to C large-scale C programs, etc.


Library and tool support for the C language is light years beyond  
Haskell. It wouldn't be there if we had been through 20 iterations of  
C each completely breaking backward compatibility.


Regards,

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

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

On Feb 26, 2009, at 1:08 PM, Achim Schneider wrote:


"John A. De Goes"  wrote:


What do you mean by "progress"? I noted before that there are
tradeoffs. Constraining the evolution of the language in backward
compatible ways leads to substantial improvements in tools,
libraries, and the speed of compiled code. That's progress in several
dimensions -- just not along the dimension of "language".


I disagree. Backwards compatibility can be the very reason no
progress _can_ be made in the areas you mention. The C toolchain was
and is a mess for anything but small, uniform, single-platform
programs, things like valgrind of course outperform plain lint in a
variety of ways, but are still hacks around the language's major flaws
(And I'm speaking as a C-fan, here). Further breakthroughs in C
compiler technology will require stalin-like brute force and library
support... well, did you ever use yacc or libxml and compared them to
Haskell solutions?

Java generics are broken by design, for the questionable benefit of
backwards compatibility. Leave those Bad Decisions to language
communities who don't care about Doing It Right. "Right" being a
technological measure here, not how well politics sell to accountants.

--
(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

[Haskell-cafe] Re: statep haskell-lang [was: Re: Hoogle and Network.Socket]

[Achim Schneider]

"John A. De Goes"  wrote:

> What do you mean by "progress"? I noted before that there are  
> tradeoffs. Constraining the evolution of the language in backward  
> compatible ways leads to substantial improvements in tools,
> libraries, and the speed of compiled code. That's progress in several
> dimensions -- just not along the dimension of "language".
>
I disagree. Backwards compatibility can be the very reason no
progress _can_ be made in the areas you mention. The C toolchain was
and is a mess for anything but small, uniform, single-platform
programs, things like valgrind of course outperform plain lint in a
variety of ways, but are still hacks around the language's major flaws
(And I'm speaking as a C-fan, here). Further breakthroughs in C
compiler technology will require stalin-like brute force and library
support... well, did you ever use yacc or libxml and compared them to
Haskell solutions?

Java generics are broken by design, for the questionable benefit of
backwards compatibility. Leave those Bad Decisions to language
communities who don't care about Doing It Right. "Right" being a
technological measure here, not how well politics sell to accountants.

-- 
(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] Performance question

[Roel van Dijk]

On Thu, Feb 26, 2009 at 6:23 PM, Don Stewart  wrote:
> But note the lazy list of Double pairs, so the inner loop still looks like 
> this though:
>
>    $wlgo :: Int# -> [(Double, Double)] -> Int
>
>    $wlgo =
>      \ (ww_s1pv :: Int#)
>        (w_s1px :: [(Double, Double)]) ->
>        case w_s1px of wild_aTl {
>          [] -> I# ww_s1pv;
>          : x_aTp xs_aTq ->
>            case x_aTp of wild1_B1 { (x1_ak3, y_ak5) ->
>            case x1_ak3 of wild2_aX8 { D# x2_aXa ->
>            case y_ak5 of wild3_XYs { D# x3_XYx ->
>            case <=##
>                   (sqrtDouble#
>                      (+##
>                         (*## x2_aXa x2_aXa) (*## x3_XYx x3_XYx)))
>                   1.0
>            of wild4_X1D {
>              False -> $wlgo ww_s1pv xs_aTq;
>              True -> $wlgo (+# ww_s1pv 1) xs_aTq
>            }
>
> while we want to keep everything in registers with something like:
>
>    Int# -> Double# -> Double# -> Int#
>
> So we'll be paying a penalty to force the next elem of the list (instead of
> just calling the Double generator).  This definitely has an impact on 
> performance.
>
>    $ ghc-core B.hs -O2 -fvia-C -optc-O3 -fexcess-precision -optc-march=core2 
> -funbox-strict-fields
>
>    $ time ./B 1000
>    3.1407688
>    ./B 1000  2.41s user 0.01s system 99% cpu 2.415 total
>
>
> Now, what if we just rewrote that inner loop directly to avoid intermediate 
> stuff? That'd give
> us a decent lower bound.
>
>    {-# LANGUAGE BangPatterns #-}
>
>    import System.Environment
>    import System.Random.Mersenne
>
>    isInCircle :: Double -> Double -> Bool
>    isInCircle x y = sqrt (x*x + y*y) <= 1.0
>
>    countHits :: Int -> IO Int
>    countHits lim = do
>        g <- newMTGen Nothing
>        let go :: Int -> Int -> IO Int
>            go !throws !hits
>                | throws >= lim  = return hits
>                | otherwise = do
>                    x <- random g   -- use mersenne-random-pure64 to stay pure!
>                    y <- random g
>                    if isInCircle x y
>                        then go (throws+1) (hits+1)
>                        else go (throws+1) hits
>        go 0 0
>
>    monteCarloPi :: Int -> IO Double
>    monteCarloPi n = do
>        hits <- countHits n
>        return $ 4.0 * fromIntegral hits / fromIntegral n
>
>    main = do
>        [n] <- getArgs
>        res <- monteCarloPi (read n)
>        print res
>
> And now the inner loop looks like:
>
>      $wa_s1yW :: Int#
>                  -> Int#
>                  -> State# RealWorld
>                  -> (# State# RealWorld, Int #)
>
> Pretty good. Can't avoid the Int boxed return (and resulting heap check) due 
> to use of IO monad.
> But at least does away with heap allocs in the inner loop!
>
> How does it go:
>
>    $ ghc-core A.hs -O2 -fvia-C -optc-O3 -fexcess-precision -optc-march=core2 
> -funbox-strict-fields
>
>    $ time ./A 1000
>    3.1412564
>    ./A 1000  0.81s user 0.00s system 99% cpu 0.818 total
>
> Ok. So 3 times faster. Now the goal is to recover the high level version.
> We have many tools to employ: switching to mersenne-random-pure64 might help
> here. And seeing if you can fuse filling a uvector with randoms, and folding
> over it... t
>
> -- Don
>

Very nice! I also wrote a naive version which used uvector but it was
about twice as slow as the original Haskell version. I wanted to write
"lengthU . filterU isInCircle" because that clearly expresses the
algorithm. Sadly I was at work and didn't have time for profile the
program to see what was wrong. Still, I couldn't resist having a go at
the problem :-)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Re[2]: [Haskell-cafe] Re: Incremental array updates

[Eugene Kirpichov]

Hello,
Thanks, I'll have a look at these. Treating unboxed stuff
polymorphically is anyways very interesting and would be good to use
in collections API that has been recently discussed (and which I
occasionally try to continue inventing with scarce success :-/ ).

2009/2/26 Bulat Ziganshin :
> Hello Eugene,
>
> Thursday, February 26, 2009, 5:32:14 PM, you wrote:
>
> look at http://haskell.org/haskellwiki/Library/ArrayRef
> it contains reimplementation of arrays library according to Oleg&Simon idea:
>
> - Unboxed arrays now can be used in polymorphic functions, they are defined
> for every element type that belongs to the classes Unboxed and HasDefaultValue
> (again, look at 
> http://www.haskell.org/pipermail/haskell-cafe/2004-July/006400.html).
> You can add new instances to these classes
>
>
>
>> STUArray is really a bit tricky to get used with: especially, if you
>> do something wrong, the type errors will be rather dreadful.
>> However, if you do everything right, it's OK and you sometimes even
>> don't need to write the types at all.
>> There are a couple of examples here
>> http://www.google.com/codesearch?q=runSTUArray
>> I also use them a bit in
>> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/jarfind
>> And here's one more small source where I used it:
>> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=1791#a1791 That's
>> problem 87 from projecteuler.net.
>
>> 2009/2/26 Daniel Kraft :
>>> Daniel Fischer wrote:

 Am Donnerstag, 26. Februar 2009 14:53 schrieb Daniel Kraft:
>
> Hi,
>
> I seem to be a little stuck with incremental array updates...  I've got
> an array of "few" (some thousand) integers, but have to do a calculation
> where I incrementally build up the array.  For sake of simplicity, for
> now I don't use a State-Monad but simply pass the array as state down
> the recursive calls.
>
> Unfortunatelly, I seem to experience problems with lazyness; when I run
> my program, memory usage goes up to horrific values!  The simple program
> below reproduces this; when run on my machine, it uses up about 300 MB
> of real and 300 MB of virtual memory, and the system starts swapping
> like mad!  I compiled with ghc --make -O3, ghc version 6.8.3 if that
> matters.

 As Eugene already said, use STUArray (STArray if you need some laziness).
 It's much much faster.
>>>
>>> I'm just reading about it, but didn't find anything except the Haddock
>>> documentation...  This may need some time to work out :)
>>>
> BTW, I tried to make the array update strict using the `seq` as below,
> but with no effect...  What am I doing wrong here?
>
> Many thanks,
> Daniel
>
>
>
>
> import Data.Array;
>
>
> arraySize = 1000
> limit = 10
>
> type MyArray = Array Int Int
>
> emptyArray :: MyArray
> emptyArray = array (0, arraySize - 1) [ (i, 0) | i <- [0 .. arraySize -
> 1]
> ]
>
>
> procOne :: Int -> MyArray -> MyArray
> procOne a cnt
>
>   | a > limit = cnt
>   | otherwise =
>
>     let ind = a `mod` arraySize
>         oldcnt = cnt ! ind
>         newarr = cnt // [(ind, oldcnt + 1)]
>     in
>       procOne (a + 1) (newarr `seq` newarr)

 Note that
 x `seq` x
 is exactly equivalent to just writing x, it will be evaluated if and only
 if x is required to be evaluated by something else.

 Try
        let ind = a `mod` arraySize
            oldcnt = cnt ! ind
            newarr = cnt // [(ind,oldcnt+1)]
            newcnt = newarr ! ind
        in newcnt `seq` procOne (a+1) newarr

 to force newarr to be evaluated, so the old array is eligible for garbage
 collection.
>>>
>>> This was my first attempt at using `seq` for forcing strict evaluation, and
>>> I seemingly did it wrong ;)
>>>
>>> Thanks for all the quick answers!
>>>
>>> Yours,
>>> Daniel
>>>
>>> ___
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe@haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>
>
>
>
>
>
> --
> Best regards,
>  Bulat                            mailto:bulat.zigans...@gmail.com
>
>



-- 
Eugene Kirpichov
Web IR developer, market.yandex.ru
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] statep haskell-lang [was: Re: Hoogle and Network.Socket]

[John A. De Goes]

On Feb 26, 2009, at 12:12 PM, Achim Schneider wrote:

I think that arguing that Haskell is _obsolete_ because it isn't yet
fully dependently typed is vastly mistaken.


I never said it was obsolete. Far from it. But I did say that choices  
already made and codified into H98 have implications on the future  
evolution of Haskell, because Haskell is unlikely to deviate in ways  
that significantly break backward compatibility.



One thing is for sure: All progress will be stopped dead if the
community starts to listen to people who demand "enterprise- 
readiness".


What do you mean by "progress"? I noted before that there are  
tradeoffs. Constraining the evolution of the language in backward  
compatible ways leads to substantial improvements in tools, libraries,  
and the speed of compiled code. That's progress in several dimensions  
-- just not along the dimension of "language".



I seriously doubt that backwards compatibility will ever be broken to
the point of non-inoperation, but I certainly expect -- and do, in  
some

sense, hope -- it to be broken, to the point where you can't mix H98
and H' source because they are mutually incompatible, either in  
syntax,
semantics, or both, as long as you can still comparably painlessly  
link

them.


We'll see. First we have to know what H' is going to look like, which  
is a long ways off.



If your business is fine with that, you shouldn't have any problems. I
can imagine a lot of companies currently using Haskell wouldn't be
happy with freezing Haskell, at all: They don't mind updating their
code to the state of the art.


The problem with completely fluid languages is that they impose  
arbitrarily high costs on those who choose them. That's why companies  
prefer well-defined standards and strong backwards compatibility. And  
that's why such languages eventually die, from lack of innovation --  
even if 40 years later there are still developers forced to maintain  
software written in them.


An intermediate solution is providing a source-to-source translator  
that flawlessly converts older source code into newer source code. Add  
binary compatibility, and then the only real disadvantage in language  
evolution becomes retraining and tools. Which are both significant  
costs, to be sure, but not as significant as the former.


Regards,

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

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


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

[Haskell-cafe] Re: statep haskell-lang [was: Re: Hoogle and Network.Socket]

[Achim Schneider]

Achim Schneider  wrote:

> -calculus
>
PiSigma calculus, that is. I really shouldn't attempt to send unicode
via US-ascii.

-- 
(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] Re: base-4 + gtk2hs-0.10.0 licensing

[Achim Schneider]

Wolfgang Jeltsch  wrote:

> Am Donnerstag, 26. Februar 2009 09:17 schrieb Ketil Malde:
> > Peter Hercek  writes:
> > >> Relinking against newer Gtk2Hs versions might not work.
> >
> > You have the option of recompiling the new Gtk2Hs with the old GHC
> > and relinking, don't you?
> 
> Relinking is technically not possible because of inlining.
> 
I don't think the situation is any different from providing C headers
that contain macros or inline functions. In fact, bundling GHC with
your app in the spirit of xmonad and yi should enable far less painful
relinking than your average C toolchain will ever support.

-- 
(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] statep haskell-lang [was: Re: Hoogle and Network.Socket]

[Achim Schneider]

"John A. De Goes"  wrote:

> Partial functions and dependent typing do not seem to play well together,
> for instance.
>
Well, sure, they do, as long as you don't expect the typechecker to
terminate if some type it checks is formulated in unterminating code.
GHC already has this problem if you enable UndecidableInstances, which
is exactly the reason why you shouldn't enable it if you don't
understand the need to enable it in great detail and clarity.

I think that arguing that Haskell is _obsolete_ because it isn't yet
fully dependently typed is vastly mistaken. Right now there are only a
handful of dependently typed languages, Agda being the only one that
seems to be at least partly usable by people without a Ph.D in logic.

It is _especially_ still unknown how to properly tackle totality. Not
jumping on the bleeding-edge bandwagon does not imply that Haskell's
evolution grinded to a halt, but that it protects itself from possibly
fatal mistakes.

Maybe the first -calculus based languages will change the state of
the art and you will see the GHC devs fighting over who is going to
implement it, maybe they won't and they will be free to concentrate on
other, equally important, though vastly different, topics. Like
optimisations, toolchain support or finally outlawing tabs in source
code.


One thing is for sure: All progress will be stopped dead if the
community starts to listen to people who demand "enterprise-readiness".
I seriously doubt that backwards compatibility will ever be broken to
the point of non-inoperation, but I certainly expect -- and do, in some
sense, hope -- it to be broken, to the point where you can't mix H98
and H' source because they are mutually incompatible, either in syntax,
semantics, or both, as long as you can still comparably painlessly link
them.

If your business is fine with that, you shouldn't have any problems. I
can imagine a lot of companies currently using Haskell wouldn't be
happy with freezing Haskell, at all: They don't mind updating their
code to the state of the art.

-- 
(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[2]: [Haskell-cafe] Re: Incremental array updates

[Bulat Ziganshin]

Hello Eugene,

Thursday, February 26, 2009, 5:32:14 PM, you wrote:

look at http://haskell.org/haskellwiki/Library/ArrayRef
it contains reimplementation of arrays library according to Oleg&Simon idea:

- Unboxed arrays now can be used in polymorphic functions, they are defined
for every element type that belongs to the classes Unboxed and HasDefaultValue
(again, look at 
http://www.haskell.org/pipermail/haskell-cafe/2004-July/006400.html).
You can add new instances to these classes



> STUArray is really a bit tricky to get used with: especially, if you
> do something wrong, the type errors will be rather dreadful.
> However, if you do everything right, it's OK and you sometimes even
> don't need to write the types at all.
> There are a couple of examples here
> http://www.google.com/codesearch?q=runSTUArray
> I also use them a bit in
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/jarfind
> And here's one more small source where I used it:
> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=1791#a1791 That's
> problem 87 from projecteuler.net.

> 2009/2/26 Daniel Kraft :
>> Daniel Fischer wrote:
>>>
>>> Am Donnerstag, 26. Februar 2009 14:53 schrieb Daniel Kraft:

 Hi,

 I seem to be a little stuck with incremental array updates...  I've got
 an array of "few" (some thousand) integers, but have to do a calculation
 where I incrementally build up the array.  For sake of simplicity, for
 now I don't use a State-Monad but simply pass the array as state down
 the recursive calls.

 Unfortunatelly, I seem to experience problems with lazyness; when I run
 my program, memory usage goes up to horrific values!  The simple program
 below reproduces this; when run on my machine, it uses up about 300 MB
 of real and 300 MB of virtual memory, and the system starts swapping
 like mad!  I compiled with ghc --make -O3, ghc version 6.8.3 if that
 matters.
>>>
>>> As Eugene already said, use STUArray (STArray if you need some laziness).
>>> It's much much faster.
>>
>> I'm just reading about it, but didn't find anything except the Haddock
>> documentation...  This may need some time to work out :)
>>
 BTW, I tried to make the array update strict using the `seq` as below,
 but with no effect...  What am I doing wrong here?

 Many thanks,
 Daniel




 import Data.Array;


 arraySize = 1000
 limit = 10

 type MyArray = Array Int Int

 emptyArray :: MyArray
 emptyArray = array (0, arraySize - 1) [ (i, 0) | i <- [0 .. arraySize -
 1]
 ]


 procOne :: Int -> MyArray -> MyArray
 procOne a cnt

   | a > limit = cnt
   | otherwise =

     let ind = a `mod` arraySize
         oldcnt = cnt ! ind
         newarr = cnt // [(ind, oldcnt + 1)]
     in
       procOne (a + 1) (newarr `seq` newarr)
>>>
>>> Note that
>>> x `seq` x
>>> is exactly equivalent to just writing x, it will be evaluated if and only
>>> if x is required to be evaluated by something else.
>>>
>>> Try
>>>        let ind = a `mod` arraySize
>>>            oldcnt = cnt ! ind
>>>            newarr = cnt // [(ind,oldcnt+1)]
>>>            newcnt = newarr ! ind
>>>        in newcnt `seq` procOne (a+1) newarr
>>>
>>> to force newarr to be evaluated, so the old array is eligible for garbage
>>> collection.
>>
>> This was my first attempt at using `seq` for forcing strict evaluation, and
>> I seemingly did it wrong ;)
>>
>> Thanks for all the quick answers!
>>
>> Yours,
>> Daniel
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>






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

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

Re[2]: [Haskell-cafe] Re: Incremental array updates

[Bulat Ziganshin]

Hello Ross,

Thursday, February 26, 2009, 9:54:23 PM, you wrote:

>> the same loop using STArray, but accumArray provide you pure API for
>> such computations

> And accumArray can also be used with UArray if laziness is a problem.

to be exact, for Array, STArray used internally
 for UArray - STUArray


-- 
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: Incremental array updates

[Ross Paterson]

On Thu, Feb 26, 2009 at 09:36:17PM +0300, Bulat Ziganshin wrote:
> Thursday, February 26, 2009, 9:27:10 PM, you wrote:
> > It was about this:  I needed to generate "all possibilities" for some
> > combinations and each of those had a numeric property, say from 1 to 
> > 1; I then had to count how many of the possibilities were of a given
> > "category".  So I created this array, generated all combinations, and 
> > incremented the matching slot each time.
> 
> it's histogram essentially? accumArray is doing so. internally, it's
> the same loop using STArray, but accumArray provide you pure API for
> such computations

And accumArray can also be used with UArray if laziness is a problem.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Incremental array updates

[Ross Paterson]

On Thu, Feb 26, 2009 at 06:45:27PM +, Ross Paterson wrote:
> Yes, bucketing problems like this are a common case that the standard
> functions cannot handle.  Perhaps the libraries need a canned solution.

Stratch that -- as Bulat points out, accumArray is such a canned solution.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Incremental array updates

[Ross Paterson]

On Thu, Feb 26, 2009 at 07:27:10PM +0100, Daniel Kraft wrote:
> It was about this:  I needed to generate "all possibilities" for some  
> combinations and each of those had a numeric property, say from 1 to  
> 1; I then had to count how many of the possibilities were of a given  
> "category".  So I created this array, generated all combinations, and  
> incremented the matching slot each time.
>
> I do not see how I could have done this another way, but I think it  
> should be a fairly common pattern, so if there are ideas, I'd welcome 
> them!

Yes, bucketing problems like this are a common case that the standard
functions cannot handle.  Perhaps the libraries need a canned solution.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Performance Issue

[Daniel Fischer]

Am Donnerstag, 26. Februar 2009 18:48 schrieb Luke Palmer:
> 2009/2/26 James Swaine 
>
> > --gets r[k], which is the value at the kth
> > --position in the overall sequence of
> > --pseudorandom numbers
> > getRandAt :: Int64 -> Int64 -> Float
> > getRandAt 0 seed = multiplier * (fromIntegral seed)
> > getRandAt k seed = multiplier * (fromIntegral x_next)
> > where
> > x_prev = (a^k * seed) `mod` divisor
> > x_next = (a * x_prev) `mod` divisor
>
> One thing that comes to mind is that this exponentiation, with a very big
> exponent, could potentially take a very long time. I believe that GHC
> implements (^) using a repeated squaring technique, so it runs in log(k)
> time, which ought to be no problem.  I'm not sure about other compilers
> though.

Another thing: if you don't need to pick random indices, but use them in 
order, it may be faster to have a list of the random numbers :

randInts = iterate ((`mod` divisor) . (*a)) seed

or carry x[k] around as state.

>
> Also note:
>
> (a^k * seed) `mod` divisor = ((a^k `mod` divisor) * seed) `mod` divisor =
> (a^(k `mod` phi(divisor)) * seed) `mod` divisor.
>
> Where phi is the Euler totient function: phi(2^46) = 2^23.

phi(2^n) = 2^(n-1).

Apart from that, correct.

>
> Modulo errors... it's been a while since I've done this stuff.
>
> Luke

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

Re: [Haskell-cafe] Re: Incremental array updates

[Bulat Ziganshin]

Hello Daniel,

Thursday, February 26, 2009, 9:27:10 PM, you wrote:

> It was about this:  I needed to generate "all possibilities" for some
> combinations and each of those had a numeric property, say from 1 to 
> 1; I then had to count how many of the possibilities were of a given
> "category".  So I created this array, generated all combinations, and 
> incremented the matching slot each time.

it's histogram essentially? accumArray is doing so. internally, it's
the same loop using STArray, but accumArray provide you pure API for
such computations


-- 
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] Re: Performance question

[Achim Schneider]

Ketil Malde  wrote:

> So it seems we're just tremendously lousy at generating random
> Doubles.
>
We had this a while ago, and Don was kind enough to post some bindings
to dSFMT:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mersenne-random-pure64-0.2.0.2

which could have a purer interface, but then the upstream code could be
less blatantly impure. 

Anyway, that's about as fast as you can get.

-- 
(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] Re: Incremental array updates

[Daniel Kraft]

Ross Paterson wrote:

On Thu, Feb 26, 2009 at 05:31:34PM +0100, Daniel Kraft wrote:

Well, my main problem was the lazy evaluation...


No, your main problem was that you were creating 100,000 arrays,
each only a little different from the one before.


Here I have to disagree (in my particular situation).  Even with 
Data.Array but the strict evaluation the program took about 5m, where it 
before wouldn't even get far because of all that memory swapping... 
With STUArray it took 1m--much better, but the worst of all was the 
horrific memory usage.


For this example program... yes of course :)  I'm trying to do so when  
possible, but for my real problem I couldn't figure out a nice way to do  
it like that, unfortunately.  Which does not mean it is impossible of  
course, but maybe just I need more experience in functional  
programming... :D


Writing imperative programs in Haskell may not be the best way to gain
that experience.  What is the pattern of updates in your actual program?


It was about this:  I needed to generate "all possibilities" for some 
combinations and each of those had a numeric property, say from 1 to 
1; I then had to count how many of the possibilities were of a given 
"category".  So I created this array, generated all combinations, and 
incremented the matching slot each time.


I do not see how I could have done this another way, but I think it 
should be a fairly common pattern, so if there are ideas, I'd welcome them!


Daniel

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

Re: [Haskell-cafe] Memoization local to a function

[Dušan Kolář]

Thanks for all the hints and code provided, nevertheless, it implied 
another questions:


1) Am I right that MemoCombinators can be hardly ever used with hugs? If 
not, which guidelines to be used for installation...
2) Is there any paper/tutorial/wiki that describes, which local 
definitions/expressions are "discarded"/"not shared" after/"to the next" 
computation, that means separated closure is built for them?


Dusan

Henning Thielemann wrote:


On Wed, 25 Feb 2009, Luke Palmer wrote:

On Wed, Feb 25, 2009 at 10:38 AM, Dusan Kolar  
wrote:
   I have a function a computation of which is quite expensive, 
it is recursively
  dependent on itself with respect to some other function values 
- we can roughly
  model its behaviour with fib function (returns n-th number of 
Fibonacci's
  sequence). Unfortunately, it is not fib, it is far more 
complicated.
  Nevertheless, for demonstration of my question/problem I will 
use fib, it's quite

  good.


I suggest using data-memocombinators for this rather than rolling 
your own.  It accomplishes
the same thing, but makes the choice of memo structure independent of 
the code that uses it

(and Memo.integral has asymptotically better performance than a list).


Nice to know that there is a package for this purpose. See also
  http://haskell.org/haskellwiki/Memoization


--

 Dusan Kolartel: +420 54 114 1238
 UIFS FIT VUT Brno  fax: +420 54 114 1270
 Bozetechova 2   e-mail: ko...@fit.vutbr.cz
 Brno 612 66
 Czech Republic

--

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

Re: [Haskell-cafe] Memoization local to a function

[Dusan Kolar]

Thanks for all the hints and code provided, nevertheless, it implied 
another questions:


1) Am I right that MemoCombinators can be hardly ever used with hugs? If 
not, which guidelines to be used for installation...
2) Is there any paper/tutorial/wiki that describes, which local 
definitions/expressions are "discarded"/"not shared" after/"to the next" 
computation, that means separated closure is built for them?


Dusan

Henning Thielemann wrote:


On Wed, 25 Feb 2009, Luke Palmer wrote:

On Wed, Feb 25, 2009 at 10:38 AM, Dusan Kolar  
wrote:
   I have a function a computation of which is quite expensive, 
it is recursively
  dependent on itself with respect to some other function values 
- we can roughly
  model its behaviour with fib function (returns n-th number of 
Fibonacci's
  sequence). Unfortunately, it is not fib, it is far more 
complicated.
  Nevertheless, for demonstration of my question/problem I will 
use fib, it's quite

  good.


I suggest using data-memocombinators for this rather than rolling 
your own.  It accomplishes
the same thing, but makes the choice of memo structure independent of 
the code that uses it

(and Memo.integral has asymptotically better performance than a list).


Nice to know that there is a package for this purpose. See also
  http://haskell.org/haskellwiki/Memoization



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

Re: [Haskell-cafe] Performance question

[David Leimbach]

How about an FFI call to rand() and then measure the performance

On Thu, Feb 26, 2009 at 3:37 AM, Felipe Lessa wrote:

> On Thu, Feb 26, 2009 at 7:56 AM, Eugene Kirpichov 
> wrote:
> > Here is a variant that uses mersenne-random-pure64 and works less than
> > 2x slower than C++:
>
> And I would like to notice that rand() is incredibly dumber than the
> Mersenne twister, so probably if we took rand()'s code from glibc and
> rewrote it in Haskell, there would be another performance increase.
>
> --
> Felipe.
> ___
> 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] Performance Issue

[Luke Palmer]

2009/2/26 James Swaine 

> --gets r[k], which is the value at the kth
> --position in the overall sequence of
> --pseudorandom numbers
> getRandAt :: Int64 -> Int64 -> Float
> getRandAt 0 seed = multiplier * (fromIntegral seed)
> getRandAt k seed = multiplier * (fromIntegral x_next)
> where
> x_prev = (a^k * seed) `mod` divisor
> x_next = (a * x_prev) `mod` divisor


One thing that comes to mind is that this exponentiation, with a very big
exponent, could potentially take a very long time. I believe that GHC
implements (^) using a repeated squaring technique, so it runs in log(k)
time, which ought to be no problem.  I'm not sure about other compilers
though.

Also note:

(a^k * seed) `mod` divisor = ((a^k `mod` divisor) * seed) `mod` divisor =
(a^(k `mod` phi(divisor)) * seed) `mod` divisor.

Where phi is the Euler totient function: phi(2^46) = 2^23.

Modulo errors... it's been a while since I've done this stuff.

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

Re: [Haskell-cafe] Performance Issue

[Don Stewart]

james.swaine:
> i'm implementing a benchmark which includes a detailed specification for a
> random number generator.  for any of the kernels outlined in the benchmark, i
> might have to generate a set of random numbers R, which has a length n, using
> the following formulas:
> 
> R[k] = ((2^-46)(X[k])) mod 2^46, where
> 
> X[k] = (a^k)s
> 
> where the values of a and s are constant and defined below. 
> many of the kernels in the benchmark require a large number of randoms to be
> generated (in the tens of millions).  when i invoke the following getRandAt
> function that many times to build up a list, evaluation of the list takes
> forever (somewhere between 5 and 10 minutes).  i've tried optimizing this
> several different ways, with no luck.  i though i might post my code here and
> see if anyone notices anything i'm doing wrong that might be causing such a
> large bottleneck:
> 
> --constants
> a :: Int64
> a = 5^13   
> 
> divisor :: Int64
> divisor = 2^46
> 
> multiplier :: Float
> multiplier = 2**(-46)
> 
> 
> --gets r[k], which is the value at the kth
> --position in the overall sequence of
> --pseudorandom numbers
> getRandAt :: Int64 -> Int64 -> Float
> getRandAt 0 seed = multiplier * (fromIntegral seed)
> getRandAt k seed = multiplier * (fromIntegral x_next)
> where
> x_prev = (a^k * seed) `mod` divisor
> x_next = (a * x_prev) `mod` divisor
> 
> thanks all in advance for your help!


Using ghc -O2 --make

There's nothing wrong with this code, really:

Z.$wgetRandAt :: Int# -> Int# -> Float#

and an inner loop of:

Z.$w$j :: Int# -> Float#
Z.$w$j =
  \ (w_sHx :: Int#) ->
case Z.^1 Z.lit1 Z.lvl of w1_XFs { I64# ww_XFv ->
case ww_XFv of wild_aFB {
  __DEFAULT ->
case minBound3 of wild1_aFC { I64# b1_aFE ->
case ==# w_sHx b1_aFE of wild2_aFG {
  False ->
case modInt# w_sHx wild_aFB of wild3_aFJ { __DEFAULT ->
timesFloat#
  (powerFloat# __float 2.0 __float -46.0)
  (int2Float# wild3_aFJ)
};
  True ->
case wild_aFB of wild3_aFM {
  __DEFAULT ->
case modInt# w_sHx wild3_aFM of wild4_aFN { __DEFAULT ->
timesFloat#
  (powerFloat# __float 2.0 __float -46.0)
  (int2Float# wild4_aFN)
};
  (-1) ->
overflowError
`cast` (CoUnsafe (forall a_aFS. a_aFS) Float#
:: forall a_aFS. a_aFS ~ Float#)
}
}
};
  0 ->
divZeroError
`cast` (CoUnsafe (forall a_aFT. a_aFT) Float#
:: forall a_aFT. a_aFT ~ Float#)
}

Which is just fine.

Inlining those constants explicitly might be a good idea, then we get an outer 
loop of:

Z.$wgetRandAt :: Int# -> Int# -> Float#
Z.$wgetRandAt =
  \ (ww_sHG :: Int#) (ww1_sHK :: Int#) ->
case ww_sHG of wild_B1 {
  __DEFAULT ->
case Z.lvl3 of wild1_aEd { I64# x#_aEf ->
case Z.^ Z.a (I64# wild_B1)
of wild2_XFe { I64# x#1_XFh ->
case Z.lvl1 of w_aE7 { I64# ww2_aE9 ->
case ww2_aE9 of wild3_aFB {
  __DEFAULT ->
case minBound3 of wild11_aFC { I64# b1_aFE ->
let {
  ww3_aFz [ALWAYS Just L] :: Int#

  ww3_aFz = *# x#1_XFh ww1_sHK } in
case ==# ww3_aFz b1_aFE of wild21_aFG {
  False ->
case modInt# ww3_aFz wild3_aFB
of wild31_aFJ { __DEFAULT ->
Z.$w$j (*# x#_aEf wild31_aFJ)
};
  True ->
case wild3_aFB of wild31_aFM {
  __DEFAULT ->
case modInt# ww3_aFz wild31_aFM
of wild4_aFN { __DEFAULT ->
Z.$w$j (*# x#_aEf wild4_aFN)
};
  (-1) ->
overflowError
`cast` (CoUnsafe (forall a_aFS. a_aFS) Float#
:: forall a_aFS. a_aFS ~ Float#)
}
  0 ->
divZeroError
`cast` (CoUnsafe (forall a_aFT. a_aFT) Float#
:: forall a_aFT. a_aFT ~ Float#)
}
}
}
};
  0 ->
timesFloat#
  (powerFloat# __float 2.0 __float -46.0)
  (int2Float# ww1_sHK)
}

which is the fast path, then error / bounds checking.

this looks perfectly acceptable.

What does sound troublesome is using lazy lists .. that's more likely to be the 
bottleneck.

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

Re: [Haskell-cafe] Strict version of Data.Map.map

[Felipe Lessa]

On Thu, Feb 26, 2009 at 2:13 PM, Edsko de Vries  wrote:
> On Thu, Feb 26, 2009 at 12:45:09PM -0300, Felipe Lessa wrote:
>> I'd advise you to see Control.Parallel.Strategies, specially the
>> NFData class and the rnf function.
>
> What is the time complexity of running rnf on a Data.Map? If it is O(n),
> then surely running rnf on my map after every 'map' operation is hardly
> going to speed things up?

I guess so. Maybe using mapAccum helps:

  import qualified Data.Map as M

  strictMap :: (a -> b) -> M.Map k a -> M.Map k b
  strictMap f m = case M.mapAccum f' () m of
((), m') -> m'
  where f' () x = x' `seq` ((), x') where x' = f x

  testStrictness mapper = m `seq` "Not strict."
  where m = mapper (const e) (M.singleton () ())
e = error "Strict!" :: ()


Testing:

*Main> testStrictness M.map
"Not strict."
*Main> testStrictness strictMap
"*** Exception: Strict!

Don't know about efficiency, though :).

HTH,

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

Re: [Haskell-cafe] Performance question

[Don Stewart]

vandijk.roel:
> I replaced the standard random number generated with the one from
> mersenne-random. On my system this makes the resulting program about
> 14 times faster than the original. I also made a change to
> accumulateHit because it doesn't need to count to total. That is
> already known.
> 
> {-# LANGUAGE BangPatterns #-}
> 
> import System( getArgs )
> import Data.List( foldl' )
> 
> import System.Random.Mersenne
> 
> pairs :: [a] -> [(a,a)]
> pairs [] = []
> pairs (x:[]) = []
> pairs (x:y:rest) = (x, y) : pairs rest
> 
> isInCircle :: (Double, Double) -> Bool
> isInCircle (x,y) = sqrt (x*x + y*y) <= 1.0
> 
> accumulateHit :: Int -> (Double, Double) -> Int
> accumulateHit (!hits) pair | isInCircle pair = hits + 1
>| otherwise   = hits
> 
> countHits :: [(Double, Double)] -> Int
> countHits ps = foldl' accumulateHit 0 ps
> 
> monteCarloPi :: Int -> [(Double, Double)] -> Double
> monteCarloPi n xs = 4.0 * fromIntegral hits / fromIntegral n
>   where hits = countHits $ take n xs
> 
> main = do
>   args <- getArgs
>   let samples = read $ head args
> 
>   randomNumberGenerator <- getStdGen
>   randomNumbers <- randoms randomNumberGenerator
> 
>   let res = monteCarloPi samples $ pairs randomNumbers
>   putStrLn $ show $ res


But note the lazy list of Double pairs, so the inner loop still looks like this 
though:

$wlgo :: Int# -> [(Double, Double)] -> Int

$wlgo =
  \ (ww_s1pv :: Int#)
(w_s1px :: [(Double, Double)]) ->
case w_s1px of wild_aTl {
  [] -> I# ww_s1pv;
  : x_aTp xs_aTq ->
case x_aTp of wild1_B1 { (x1_ak3, y_ak5) ->
case x1_ak3 of wild2_aX8 { D# x2_aXa ->
case y_ak5 of wild3_XYs { D# x3_XYx ->
case <=##
   (sqrtDouble#
  (+##
 (*## x2_aXa x2_aXa) (*## x3_XYx x3_XYx)))
   1.0
of wild4_X1D {
  False -> $wlgo ww_s1pv xs_aTq;
  True -> $wlgo (+# ww_s1pv 1) xs_aTq
}

while we want to keep everything in registers with something like:

Int# -> Double# -> Double# -> Int#

So we'll be paying a penalty to force the next elem of the list (instead of
just calling the Double generator).  This definitely has an impact on 
performance.

$ ghc-core B.hs -O2 -fvia-C -optc-O3 -fexcess-precision -optc-march=core2 
-funbox-strict-fields

$ time ./B 1000 
   
3.1407688
./B 1000  2.41s user 0.01s system 99% cpu 2.415 total


Now, what if we just rewrote that inner loop directly to avoid intermediate 
stuff? That'd give
us a decent lower bound.

{-# LANGUAGE BangPatterns #-}

import System.Environment
import System.Random.Mersenne

isInCircle :: Double -> Double -> Bool
isInCircle x y = sqrt (x*x + y*y) <= 1.0

countHits :: Int -> IO Int
countHits lim = do
g <- newMTGen Nothing
let go :: Int -> Int -> IO Int
go !throws !hits
| throws >= lim  = return hits
| otherwise = do
x <- random g   -- use mersenne-random-pure64 to stay pure!
y <- random g
if isInCircle x y
then go (throws+1) (hits+1)
else go (throws+1) hits
go 0 0

monteCarloPi :: Int -> IO Double
monteCarloPi n = do
hits <- countHits n
return $ 4.0 * fromIntegral hits / fromIntegral n

main = do
[n] <- getArgs
res <- monteCarloPi (read n)
print res

And now the inner loop looks like:

  $wa_s1yW :: Int#
  -> Int#
  -> State# RealWorld
  -> (# State# RealWorld, Int #)

Pretty good. Can't avoid the Int boxed return (and resulting heap check) due to 
use of IO monad. 
But at least does away with heap allocs in the inner loop!

How does it go:

$ ghc-core A.hs -O2 -fvia-C -optc-O3 -fexcess-precision -optc-march=core2 
-funbox-strict-fields

$ time ./A 1000
3.1412564
./A 1000  0.81s user 0.00s system 99% cpu 0.818 total

Ok. So 3 times faster. Now the goal is to recover the high level version.
We have many tools to employ: switching to mersenne-random-pure64 might help
here. And seeing if you can fuse filling a uvector with randoms, and folding
over it... t

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

Re: [Haskell-cafe] Strict version of Data.Map.map

[Edsko de Vries]

On Thu, Feb 26, 2009 at 12:45:09PM -0300, Felipe Lessa wrote:
> I'd advise you to see Control.Parallel.Strategies, specially the
> NFData class and the rnf function.

What is the time complexity of running rnf on a Data.Map? If it is O(n),
then surely running rnf on my map after every 'map' operation is hardly
going to speed things up? 

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

[Haskell-cafe] Performance Issue

[James Swaine]

i'm implementing a benchmark which includes a detailed specification for a
random number generator.  for any of the kernels outlined in the benchmark,
i might have to generate a set of random numbers R, which has a length n,
using the following formulas:

R[k] = ((2^-46)(X[k])) mod 2^46, where

X[k] = (a^k)s

where the values of a and s are constant and defined below.
many of the kernels in the benchmark require a large number of randoms to be
generated (in the tens of millions).  when i invoke the following getRandAt
function that many times to build up a list, evaluation of the list takes
forever (somewhere between 5 and 10 minutes).  i've tried optimizing this
several different ways, with no luck.  i though i might post my code here
and see if anyone notices anything i'm doing wrong that might be causing
such a large bottleneck:

--constants
a :: Int64
a = 5^13

divisor :: Int64
divisor = 2^46

multiplier :: Float
multiplier = 2**(-46)


--gets r[k], which is the value at the kth
--position in the overall sequence of
--pseudorandom numbers
getRandAt :: Int64 -> Int64 -> Float
getRandAt 0 seed = multiplier * (fromIntegral seed)
getRandAt k seed = multiplier * (fromIntegral x_next)
where
x_prev = (a^k * seed) `mod` divisor
x_next = (a * x_prev) `mod` divisor

thanks all in advance for your help!
-james
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: seg-fault in mersenne-random with SSE2 (was Performance question)

[Peter Verswyvelen]

Might also mean bad alignment of data structures, maybe when marshalling
data between the GHC runtime and the C implementation? If I recall correctly
SSE2 requires 16-byte alignment.
On Thu, Feb 26, 2009 at 5:24 PM, Don Stewart  wrote:

> Alistair.Bayley:
> > > From: haskell-cafe-boun...@haskell.org
> > > [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Roel van Dijk
> > >
> > > I replaced the standard random number generated with the one from
> > > mersenne-random. On my system this makes the resulting program about
> > > 14 times faster than the original. I also made a change to
> > > accumulateHit because it doesn't need to count to total. That is
> > > already known.
> >
> >
> > I tried this too, but got a seg fault (!), so I stripped it back to a
> > small test program. This is with mersenne-random, setup configured with
> > -fuse_sse2:
>
> This in the past has always meant: wrong architecture (or GCC can't handle
> sse2 on your system)
>
> -- Don
> ___
> 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] Re: Incremental array updates

[Ross Paterson]

On Thu, Feb 26, 2009 at 05:31:34PM +0100, Daniel Kraft wrote:
> Well, my main problem was the lazy evaluation...

No, your main problem was that you were creating 100,000 arrays,
each only a little different from the one before.

> For this example program... yes of course :)  I'm trying to do so when  
> possible, but for my real problem I couldn't figure out a nice way to do  
> it like that, unfortunately.  Which does not mean it is impossible of  
> course, but maybe just I need more experience in functional  
> programming... :D

Writing imperative programs in Haskell may not be the best way to gain
that experience.  What is the pattern of updates in your actual program?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Performance question

[Eugene Kirpichov]

I looked at the core and the tuples were already unboxed IIRC.

2009/2/26 Don Stewart :
> Ben.Lippmeier:
>>
>> On 26/02/2009, at 9:27 PM, hask...@kudling.de wrote:
>>>
>>> Currently i can only imagine to define a data type in order to use
>>> unboxed Ints instead of the accumulator tuple.
>>
>> That would probably help a lot. It would also help to use two separate
>> Double# parameters instead of the tuple.
>
>    data T = T !Double !Double
>
> should be enough.
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Eugene Kirpichov
Web IR developer, market.yandex.ru
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Incremental array updates

[Daniel Kraft]

Ross Paterson wrote:

On Thu, Feb 26, 2009 at 02:53:42PM +0100, Daniel Kraft wrote:
I seem to be a little stuck with incremental array updates...  I've got  
an array of "few" (some thousand) integers, but have to do a calculation  
where I incrementally build up the array.  For sake of simplicity, for  
now I don't use a State-Monad but simply pass the array as state down  
the recursive calls.


Unfortunatelly, I seem to experience problems with lazyness; when I run  
my program, memory usage goes up to horrific values!  The simple program  
below reproduces this; when run on my machine, it uses up about 300 MB  
of real and 300 MB of virtual memory, and the system starts swapping  
like mad!  I compiled with ghc --make -O3, ghc version 6.8.3 if that  
matters.


As noted above, updating an array one element at a time is the problem.
But before writing an imperative program with STUArray, you might try
building a whole new Array, specifying a new value for each element,
using array or accumArray.  These are often enough.  In your simple
example:


Well, my main problem was the lazy evaluation...  And using STUArray did 
also speed it up notably, of course :)  I finally managed to get it 
working with it ;)



procOne :: Int -> MyArray -> MyArray
procOne a cnt
   | a >= limit = cnt
   | otherwise =
   procOne (a + arraySize) $!
  array (0, arraySize - 1)
[ (i, cnt!i + 1) | i <- [0 .. arraySize - 1] ]

If elements of the new array depend on previously computed elements of
the same array, you can define the array recursively.


For this example program... yes of course :)  I'm trying to do so when 
possible, but for my real problem I couldn't figure out a nice way to do 
it like that, unfortunatelly.  Which does not mean it is impossible of 
course, but maybe just I need more experience in functional 
programming... :D


Daniel

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

[Haskell-cafe] Re: seg-fault in mersenne-random with SSE2 (was Performance question)

[Don Stewart]

Alistair.Bayley:
> > From: haskell-cafe-boun...@haskell.org 
> > [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Roel van Dijk
> > 
> > I replaced the standard random number generated with the one from
> > mersenne-random. On my system this makes the resulting program about
> > 14 times faster than the original. I also made a change to
> > accumulateHit because it doesn't need to count to total. That is
> > already known.
> 
> 
> I tried this too, but got a seg fault (!), so I stripped it back to a
> small test program. This is with mersenne-random, setup configured with
> -fuse_sse2:

This in the past has always meant: wrong architecture (or GCC can't handle sse2 
on your system)

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

Re: [Haskell-cafe] Performance question

[Don Stewart]

Ben.Lippmeier:
>
> On 26/02/2009, at 9:27 PM, hask...@kudling.de wrote:
>>
>> Currently i can only imagine to define a data type in order to use  
>> unboxed Ints instead of the accumulator tuple.
>
> That would probably help a lot. It would also help to use two separate  
> Double# parameters instead of the tuple.

data T = T !Double !Double

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

Re: [Haskell-cafe] Incremental array updates

[Ross Paterson]

On Thu, Feb 26, 2009 at 02:53:42PM +0100, Daniel Kraft wrote:
> I seem to be a little stuck with incremental array updates...  I've got  
> an array of "few" (some thousand) integers, but have to do a calculation  
> where I incrementally build up the array.  For sake of simplicity, for  
> now I don't use a State-Monad but simply pass the array as state down  
> the recursive calls.
>
> Unfortunatelly, I seem to experience problems with lazyness; when I run  
> my program, memory usage goes up to horrific values!  The simple program  
> below reproduces this; when run on my machine, it uses up about 300 MB  
> of real and 300 MB of virtual memory, and the system starts swapping  
> like mad!  I compiled with ghc --make -O3, ghc version 6.8.3 if that  
> matters.

As noted above, updating an array one element at a time is the problem.
But before writing an imperative program with STUArray, you might try
building a whole new Array, specifying a new value for each element,
using array or accumArray.  These are often enough.  In your simple
example:

procOne :: Int -> MyArray -> MyArray
procOne a cnt
   | a >= limit = cnt
   | otherwise =
   procOne (a + arraySize) $!
  array (0, arraySize - 1)
[ (i, cnt!i + 1) | i <- [0 .. arraySize - 1] ]

If elements of the new array depend on previously computed elements of
the same array, you can define the array recursively.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Performance question

[Tracy Wadleigh]

Awesome, Felipe. Thanks.

--Tracy

On Thu, Feb 26, 2009 at 11:07 AM, Felipe Lessa wrote:

> 2009/2/26 Tracy Wadleigh :
> > On Thu, Feb 26, 2009 at 7:17 AM, Lennart Augustsson <
> lenn...@augustsson.net>
> > wrote:
> >>
> >> You can implement a reasonable split if you can fast-forward the
> >> generator.
> >> There's no known method to fast-forward the MT, but other generators
> >> like MRG32k3a can handle it.
> >
> > Are you aware of any existing (C/C++/Haskell) library implementing this
> > algorithm? A cursory google search didn't turn anything up for me, aside
> > from something implemented in Java, and another in Lisp.
>
> Maybe 
> http://www.iro.umontreal.ca/~lecuyer/myftp/streams00/?
>
> --
> Felipe.
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Performance question

[Felipe Lessa]

2009/2/26 Tracy Wadleigh :
> On Thu, Feb 26, 2009 at 7:17 AM, Lennart Augustsson 
> wrote:
>>
>> You can implement a reasonable split if you can fast-forward the
>> generator.
>> There's no known method to fast-forward the MT, but other generators
>> like MRG32k3a can handle it.
>
> Are you aware of any existing (C/C++/Haskell) library implementing this
> algorithm? A cursory google search didn't turn anything up for me, aside
> from something implemented in Java, and another in Lisp.

Maybe http://www.iro.umontreal.ca/~lecuyer/myftp/streams00/ ?

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

Re: [Haskell-cafe] Performance question

[Tracy Wadleigh]

On Thu, Feb 26, 2009 at 7:17 AM, Lennart Augustsson
wrote:

> You can implement a reasonable split if you can fast-forward the generator.
> There's no known method to fast-forward the MT, but other generators
> like MRG32k3a can handle it.
>

Are you aware of any existing (C/C++/Haskell) library implementing this
algorithm? A cursory google search didn't turn anything up for me, aside
from something implemented in Java, and another in Lisp.

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

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

[John Lato]

On Thu, Feb 26, 2009 at 1:21 PM, Thomas DuBuisson
 wrote:
> Daniel provided the wisdom:
>> "Do not knowingly make your code unportable unless you have a good reason to"
>>
>> Are there any objections to that maxim?
>
> Thanks for bringing some sanity back.  I notice very few people have
> bothered to comment on the wiki page Neil has setup.  Incase anyone
> has fogotten - this was originally about what packages hoogle should
> search and which options should be available (and which should be
> default) for returning platform specific results.

Yes, thanks for dragging this back on topic.  I am sorry for my
contribution to moving so far away from it.

>
> Platform specifity:
> The suggestion of platform specific flags, which I now support, seems
> to be dominante. The only alternate I recall is showing all results
> catagorized by platform (with 'portable' being on top) - perhaps that
> could be displayed if there are zero results that are portable.
>
> Default packages searched:
> I've yet to hear anyone say we should search anything less than the
> Haskell Platform by default.  I also don't think anyone has spoke ill
> of a "+hackage" flag.
>

I would agree with Haskell Platform as default search, and also with a
+hackage flag.  I would also support platform-specific flags if they
were simple to implement.

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

Re: [Haskell-cafe] Strict version of Data.Map.map

[Felipe Lessa]

I'd advise you to see Control.Parallel.Strategies, specially the
NFData class and the rnf function.

HTH,

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

Re: [Haskell-cafe] ANN: gitit 0.5.1

[Hugo Pacheco]

Yes I am.
I just copy/pasted the text from the server where it is plain text, so
that shall not be the problem.

On Thu, Feb 26, 2009 at 3:23 PM, Ross Mellgren  wrote:
> Are you by chance using OSX? The file you attached was not a plain text file
> -- it was an RTF file.
>
> If you made this file on OSX and forgot to invoke the Format > Make Plain
> Text command, it'll be an RTF file which I'm sure gitit will have no clue
> about.
>
> -Ross
>
> On Feb 26, 2009, at 10:21 AM, Hugo Pacheco wrote:
>
>> Still nothing. No matter which config file I try (deleting almost
>> every fields, newlines, etc), I always get the no parse error.
>>
>> On Thu, Feb 26, 2009 at 5:47 AM, Robin Green  wrote:
>>>
>>> On Thu, 26 Feb 2009 14:30:17 +
>>> Hugo Pacheco  wrote:
>>>
 Hi all,

 Under gitit 0.5.3 I always get "Prelude.read: no parse" when trying to
 load a configuration file.
 My previous file goes attached, but the sample config file from
 http://github.com/jgm/gitit/tree/master does not work also.
>>>
>>> I don't think you can actually do multiplication in the config file, as
>>> the sample config file tries to. Replace 2 * 1024 * 1024 with 200,
>>> and the sample config should work.
>>> --
>>> Robin
>>> ___
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe@haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>
>>
>>
>> --
>> www.di.uminho.pt/~hpacheco
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>



-- 
www.di.uminho.pt/~hpacheco
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Strict version of Data.Map.map

[Edsko de Vries]

Hi,

Is it possible to write a strict version of Data.Map.map (so that the
Map becomes strict in the elements as well as the keys)?

Thanks,

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

Re: [Haskell-cafe] ANN: gitit 0.5.1

[Ross Mellgren]

Are you by chance using OSX? The file you attached was not a plain  
text file -- it was an RTF file.


If you made this file on OSX and forgot to invoke the Format > Make  
Plain Text command, it'll be an RTF file which I'm sure gitit will  
have no clue about.


-Ross

On Feb 26, 2009, at 10:21 AM, Hugo Pacheco wrote:


Still nothing. No matter which config file I try (deleting almost
every fields, newlines, etc), I always get the no parse error.

On Thu, Feb 26, 2009 at 5:47 AM, Robin Green   
wrote:

On Thu, 26 Feb 2009 14:30:17 +
Hugo Pacheco  wrote:


Hi all,

Under gitit 0.5.3 I always get "Prelude.read: no parse" when  
trying to

load a configuration file.
My previous file goes attached, but the sample config file from
http://github.com/jgm/gitit/tree/master does not work also.


I don't think you can actually do multiplication in the config  
file, as
the sample config file tries to. Replace 2 * 1024 * 1024 with  
200,

and the sample config should work.
--
Robin
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe





--
www.di.uminho.pt/~hpacheco
___
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: gitit 0.5.1

[Hugo Pacheco]

Still nothing. No matter which config file I try (deleting almost
every fields, newlines, etc), I always get the no parse error.

On Thu, Feb 26, 2009 at 5:47 AM, Robin Green  wrote:
> On Thu, 26 Feb 2009 14:30:17 +
> Hugo Pacheco  wrote:
>
>> Hi all,
>>
>> Under gitit 0.5.3 I always get "Prelude.read: no parse" when trying to
>> load a configuration file.
>> My previous file goes attached, but the sample config file from
>> http://github.com/jgm/gitit/tree/master does not work also.
>
> I don't think you can actually do multiplication in the config file, as
> the sample config file tries to. Replace 2 * 1024 * 1024 with 200,
> and the sample config should work.
> --
> Robin
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
www.di.uminho.pt/~hpacheco
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: gitit 0.5.1

[Robin Green]

On Thu, 26 Feb 2009 14:30:17 +
Hugo Pacheco  wrote:

> Hi all,
> 
> Under gitit 0.5.3 I always get "Prelude.read: no parse" when trying to
> load a configuration file.
> My previous file goes attached, but the sample config file from
> http://github.com/jgm/gitit/tree/master does not work also.

I don't think you can actually do multiplication in the config file, as
the sample config file tries to. Replace 2 * 1024 * 1024 with 200,
and the sample config should work.
-- 
Robin
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] A foray into type-level programming, and getting stuck

[George Pollard]

Okay, so I've written a small library to generalize 'fst' and 'snd' to
arbitrary tuples, but I'd like to extend it a bit. I'm using the
type-level library to do the thinking :)

Imports and defines first:

> {-# LANGUAGE UnicodeSyntax, MultiParamTypeClasses,
> FunctionalDependencies, FlexibleInstances, FlexibleContexts,
> UndecidableInstances, DeriveDataTypeable, OverlappingInstances,
> ScopedTypeVariables #-}
> import Prelude hiding ((-),Eq)
> import qualified Prelude as P
> import Data.TypeLevel.Num.Sets
> import Data.TypeLevel.Num.Reps
> import Data.TypeLevel.Num.Aliases
> import Data.TypeLevel.Bool
> import Data.TypeLevel.Num.Ops
> import Data.Typeable

I start by requiring that if you can access element 'n', you should be
able to access element 'n-1'.

> class (ImplementsPrev t n a) ⇒ Nthable t n a | t n → a where
>   nth ∷ n → t → a
>
> class (Pos n) ⇒ ImplementsPrev t n a
> instance (Pred n n', Nthable t n' a') ⇒ ImplementsPrev t n a
> instance ImplementsPrev t D1 a

So, this is a simple induction. Testing it with the nthable instances
confirms that it works; removing either of the first two lines stops the
code from compiling, hurrah!

> instance Nthable (a,b,c) D1 a where nth _ (a,_,_) = a
> instance Nthable (a,b,c) D2 b where nth _ (_,b,_) = b
> instance Nthable (a,b,c) D3 c where nth _ (_,_,c) = c

Now, I have heard talk/suggestions of revamping tuples in Haskell to a
more flexible system. Perhaps we would like to do it like this (modulo
strictness annotations):

> data (Nat n) ⇒ Tuple n a b = Tuple a b
>   deriving (Show,Read,Typeable,P.Eq,Ord)
> infixr 0 `comma`
> -- comma :: a -> (b ~> c) -> (a ~> (b ~> c)) -- to investigate
> comma ∷ (Succ n n') ⇒ a → Tuple n b c → Tuple n' a (Tuple n b c)
> x `comma` y = Tuple x y
> empty ∷ Tuple D0 () undefined
> empty = Tuple () undefined

Thus, we can create, e.g. (1 `comma` 2 `comma` empty). Now, I'd like to be
able to write Nthable instances, so I start with the base case:

> instance (n :>=: D1) ⇒ Nthable (Tuple n a b) D1 a where
>   nth _ (Tuple a _) = a

This works well. However, I am really stuck on the instance for the inductive 
case.
My first idea was this:

> instance (Pred x x', Nthable b x' r) ⇒ Nthable (Tuple n a b) x r where
>   nth _ (Tuple _ b) = nth (undefined ∷ x') b

But this doesn't work, muttering about IncoherentInstances and hidden datatypes 
from
the type-level library.

So, I turn to Haskell café for help :)




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] Re: Incremental array updates

[Eugene Kirpichov]

STUArray is really a bit tricky to get used with: especially, if you
do something wrong, the type errors will be rather dreadful.
However, if you do everything right, it's OK and you sometimes even
don't need to write the types at all.
There are a couple of examples here
http://www.google.com/codesearch?q=runSTUArray
I also use them a bit in
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/jarfind
And here's one more small source where I used it:
http://hpaste.org/fastcgi/hpaste.fcgi/view?id=1791#a1791 That's
problem 87 from projecteuler.net.

2009/2/26 Daniel Kraft :
> Daniel Fischer wrote:
>>
>> Am Donnerstag, 26. Februar 2009 14:53 schrieb Daniel Kraft:
>>>
>>> Hi,
>>>
>>> I seem to be a little stuck with incremental array updates...  I've got
>>> an array of "few" (some thousand) integers, but have to do a calculation
>>> where I incrementally build up the array.  For sake of simplicity, for
>>> now I don't use a State-Monad but simply pass the array as state down
>>> the recursive calls.
>>>
>>> Unfortunatelly, I seem to experience problems with lazyness; when I run
>>> my program, memory usage goes up to horrific values!  The simple program
>>> below reproduces this; when run on my machine, it uses up about 300 MB
>>> of real and 300 MB of virtual memory, and the system starts swapping
>>> like mad!  I compiled with ghc --make -O3, ghc version 6.8.3 if that
>>> matters.
>>
>> As Eugene already said, use STUArray (STArray if you need some laziness).
>> It's much much faster.
>
> I'm just reading about it, but didn't find anything except the Haddock
> documentation...  This may need some time to work out :)
>
>>> BTW, I tried to make the array update strict using the `seq` as below,
>>> but with no effect...  What am I doing wrong here?
>>>
>>> Many thanks,
>>> Daniel
>>>
>>>
>>>
>>>
>>> import Data.Array;
>>>
>>>
>>> arraySize = 1000
>>> limit = 10
>>>
>>> type MyArray = Array Int Int
>>>
>>> emptyArray :: MyArray
>>> emptyArray = array (0, arraySize - 1) [ (i, 0) | i <- [0 .. arraySize -
>>> 1]
>>> ]
>>>
>>>
>>> procOne :: Int -> MyArray -> MyArray
>>> procOne a cnt
>>>
>>>   | a > limit = cnt
>>>   | otherwise =
>>>
>>>     let ind = a `mod` arraySize
>>>         oldcnt = cnt ! ind
>>>         newarr = cnt // [(ind, oldcnt + 1)]
>>>     in
>>>       procOne (a + 1) (newarr `seq` newarr)
>>
>> Note that
>> x `seq` x
>> is exactly equivalent to just writing x, it will be evaluated if and only
>> if x is required to be evaluated by something else.
>>
>> Try
>>        let ind = a `mod` arraySize
>>            oldcnt = cnt ! ind
>>            newarr = cnt // [(ind,oldcnt+1)]
>>            newcnt = newarr ! ind
>>        in newcnt `seq` procOne (a+1) newarr
>>
>> to force newarr to be evaluated, so the old array is eligible for garbage
>> collection.
>
> This was my first attempt at using `seq` for forcing strict evaluation, and
> I seemingly did it wrong ;)
>
> Thanks for all the quick answers!
>
> Yours,
> Daniel
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Eugene Kirpichov
Web IR developer, market.yandex.ru
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

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

[Jonathan Cast]

On Thu, 2009-02-26 at 06:30 -0700, John A. De Goes wrote:
> On Feb 25, 2009, at 7:49 PM, Achim Schneider wrote:
> > "John A. De Goes"  wrote:
> >
> >> The problem is that PL research is probably not going to stop
> >> evolving in our lifetimes. Yes, that research needs a venue, but why
> >> should it be Haskell? Haskell is a good language and it's time to
> >> start benefiting from the research that's already gone into it. That
> >> means some tradeoffs.
> >>
> > Why shouldn't it be Haskell?
> 
> More, why *can't* it be Haskell. Haskell is already constrained by  
> backwards compatibility, which limits future directions. Partial  
> functions and dependent typing do not seem to play well together, for  
> instance.
> 
> Moreover, look at the packages being uploaded to Hackage: they're  
> almost all trying to do useful stuff. The direction of Haskell has  
> already changed, and I don't see it reverting to its old course.
> 
> > Not really, look at e.g. type families, which give you much of the
> > power dependently typed languages give you while saying "nah, not yet"
> > to the question of how to deal with non-terminating typechecking.
> 
> *Some*, not *much*, and there are dependently typed languages that  
> have guaranteed terminating type checking.
> 
> > About the H' progress... It's hard to tell how many drops are needed  
> > to
> > make a bucket overflow, especially if you've got no idea what the
> > bucket looks like. What certainly isn't happening is people taking a
> > house, trying to overflow a badly leaking bucket.
> 
> As far as I know, H' was supposed to be completed many years ago.  
> Likely, it won't be completed for many more years. H2 is probably more  
> than a decade away, if it happens at all.

Here's to hoping it doesn't.  Practical languages, when they change,
*never* improve.  And that's going from study (although not experience!)
of 40 years of history.

jcc


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

Re: [Haskell-cafe] ANN: gitit 0.5.1

[Hugo Pacheco]

Hi all,

Under gitit 0.5.3 I always get "Prelude.read: no parse" when trying to
load a configuration file.
My previous file goes attached, but the sample config file from
http://github.com/jgm/gitit/tree/master does not work also.

Has anything changed that is not documented?

Thanks,
hugo

On Sun, Feb 1, 2009 at 5:07 PM, John MacFarlane  wrote:
> I've just uploaded gitit 0.5.1 to HackageDb. Gitit is a wiki program
> that uses git or darcs as a filestore and HAppS as a server.
>
> Changes:
>
> * Major code reorganization, making gitit more modular.
> * Gitit can now optionally be built using Happstack instead of HAppS
>  (just use -fhappstack when cabal installing).
> * Fixed bug with directories that had the same names as pages.
> * Added code from HAppS-Extra to fix cookie parsing problems.
> * New command-line options for --port, --debug.
> * New debug feature prints the date, the raw request, and
>  the processed request data to standard output on each request.
> * Files with ".page" extension can no longer be uploaded.
> * Apostrophes and quotation marks now allowed in page names.
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
www.di.uminho.pt/~hpacheco
{\rtf1\ansi\ansicpg1252\cocoartf949\cocoasubrtf430
{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
{\colortbl;\red255\green255\blue255;}
\paperw11900\paperh16840\margl1440\margr1440\vieww9000\viewh8400\viewkind0
\pard\tx566\tx1133\tx1700\tx2267\tx2834\tx3401\tx3968\tx4535\tx5102\tx5669\tx6236\tx6803\ql\qnatural\pardirnatural

\f0\fs24 \cf0 Config \{\
repositoryPath  = "/var/www/wiki/wikidata",\
userFile= "/var/www/wiki/gitit-users",\
templateFile= "/var/www/wiki/template.html",\
staticDir   = "/var/www/wiki/static",\
tableOfContents = False,\
maxUploadSize   = 10,\
portNumber  = 8080,\
passwordSalt= "l91snthoae8eou2340987",\
debugMode   = True,\
frontPage   = "Front Page",\
noEdit  = ["Help"],\
noDelete= ["Help", "Front Page"],\
accessQuestion  = Nothing\
\}\
}___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

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

[Jonathan Cast]

On Thu, 2009-02-26 at 13:52 +0100, Daniel Fischer wrote:
> Am Donnerstag, 26. Februar 2009 13:41 schrieb John Lato:
> > I didn't phrase this well.  In the context of my argument, "design for
> > cross-platform" meant "avoid platform-limiting choices in the absence
> > of any compelling reasons otherwise", which really isn't the same.
> 
> 
> Could we sum that up as:
> 
> "Do not knowingly make your code unportable unless you have a good reason to"?
> 
> Are there any objections to that maxim?

Actually, yes.  But it's quite off-topic, not just as per thread but as
per mailing list.

jcc


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

[Haskell-cafe] Re: Incremental array updates

[Daniel Kraft]

Daniel Fischer wrote:

Am Donnerstag, 26. Februar 2009 14:53 schrieb Daniel Kraft:

Hi,

I seem to be a little stuck with incremental array updates...  I've got
an array of "few" (some thousand) integers, but have to do a calculation
where I incrementally build up the array.  For sake of simplicity, for
now I don't use a State-Monad but simply pass the array as state down
the recursive calls.

Unfortunatelly, I seem to experience problems with lazyness; when I run
my program, memory usage goes up to horrific values!  The simple program
below reproduces this; when run on my machine, it uses up about 300 MB
of real and 300 MB of virtual memory, and the system starts swapping
like mad!  I compiled with ghc --make -O3, ghc version 6.8.3 if that
matters.


As Eugene already said, use STUArray (STArray if you need some laziness).
It's much much faster.


I'm just reading about it, but didn't find anything except the Haddock 
documentation...  This may need some time to work out :)



BTW, I tried to make the array update strict using the `seq` as below,
but with no effect...  What am I doing wrong here?

Many thanks,
Daniel




import Data.Array;


arraySize = 1000
limit = 10

type MyArray = Array Int Int

emptyArray :: MyArray
emptyArray = array (0, arraySize - 1) [ (i, 0) | i <- [0 .. arraySize - 1]
]


procOne :: Int -> MyArray -> MyArray
procOne a cnt

   | a > limit = cnt
   | otherwise =

 let ind = a `mod` arraySize
 oldcnt = cnt ! ind
 newarr = cnt // [(ind, oldcnt + 1)]
 in
   procOne (a + 1) (newarr `seq` newarr)


Note that 

x `seq` x 

is exactly equivalent to just writing x, it will be evaluated if and only if x 
is required to be evaluated by something else.


Try
let ind = a `mod` arraySize
oldcnt = cnt ! ind
newarr = cnt // [(ind,oldcnt+1)]
newcnt = newarr ! ind
in newcnt `seq` procOne (a+1) newarr

to force newarr to be evaluated, so the old array is eligible for garbage 
collection.


This was my first attempt at using `seq` for forcing strict evaluation, 
and I seemingly did it wrong ;)


Thanks for all the quick answers!

Yours,
Daniel

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

Re: [Haskell-cafe] Incremental array updates

[Sjur Gjøstein Karevoll]

On Thursday 26 February 2009 15.07.34 Luke Palmer wrote:
> On Thu, Feb 26, 2009 at 6:53 AM, Daniel Kraft  wrote:
> >  procOne (a + 1) (newarr `seq` newarr)
>
> The semantics of seq are:  a `seq` b = _|_ if a = _|_, b otherwise.  This
> implies that x `seq` x = x, and this seq is superfluous.
>
> Maybe you meant  newarr `seq` procOne (a+1) newarr ?
>
> Luke

I just tested that, and both that and the original used about 500mb of memory.

I changed it to "(newarr ! ind) `seq` procOne (a+1) newarr" and it only used 
about 15mb.

-- 
Sjur Gjøstein Karevoll
sjurberen...@gmail.com


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] Incremental array updates

[Daniel Fischer]

Am Donnerstag, 26. Februar 2009 14:53 schrieb Daniel Kraft:
> Hi,
>
> I seem to be a little stuck with incremental array updates...  I've got
> an array of "few" (some thousand) integers, but have to do a calculation
> where I incrementally build up the array.  For sake of simplicity, for
> now I don't use a State-Monad but simply pass the array as state down
> the recursive calls.
>
> Unfortunatelly, I seem to experience problems with lazyness; when I run
> my program, memory usage goes up to horrific values!  The simple program
> below reproduces this; when run on my machine, it uses up about 300 MB
> of real and 300 MB of virtual memory, and the system starts swapping
> like mad!  I compiled with ghc --make -O3, ghc version 6.8.3 if that
> matters.

As Eugene already said, use STUArray (STArray if you need some laziness).
It's much much faster.

>
> BTW, I tried to make the array update strict using the `seq` as below,
> but with no effect...  What am I doing wrong here?
>
> Many thanks,
> Daniel
>
>
>
>
> import Data.Array;
>
>
> arraySize = 1000
> limit = 10
>
> type MyArray = Array Int Int
>
> emptyArray :: MyArray
> emptyArray = array (0, arraySize - 1) [ (i, 0) | i <- [0 .. arraySize - 1]
> ]
>
>
> procOne :: Int -> MyArray -> MyArray
> procOne a cnt
>
>| a > limit = cnt
>| otherwise =
>
>  let ind = a `mod` arraySize
>  oldcnt = cnt ! ind
>  newarr = cnt // [(ind, oldcnt + 1)]
>  in
>procOne (a + 1) (newarr `seq` newarr)

Note that 

x `seq` x 

is exactly equivalent to just writing x, it will be evaluated if and only if x 
is required to be evaluated by something else.

Try
let ind = a `mod` arraySize
oldcnt = cnt ! ind
newarr = cnt // [(ind,oldcnt+1)]
newcnt = newarr ! ind
in newcnt `seq` procOne (a+1) newarr

to force newarr to be evaluated, so the old array is eligible for garbage 
collection.

>
>
> main :: IO ()
> main =
>do
>  arr <- return $ procOne 0 emptyArray
>  print $ arr ! 42
>

Cheers,
Daniel

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

Re: [Haskell-cafe] memory-efficient data type for Netflix data - UArray Int Int vs UArray Int Word8

[Kenneth Hoste]

On Feb 26, 2009, at 13:00 , Manlio Perillo wrote:


Kenneth Hoste ha scritto:

Hello,
I'm having a go at the Netflix Prize using Haskell. Yes, I'm brave.
[...]
To see if I could efficiently represent the data set in this way, I  
wrote a small

Haskell program (attached) which uses the following data type:


From what I see, to append a new integer to the Array, you convert  
the array to a list, append the new element to the list, and then  
convert to array again.


Isn't this a bit inefficient?


Yes, performance-wise this is terribly inefficient, I agree. But, it  
was just an artefact of how the raw data is organized.


My main concern was the memory usage of the huge IntMap with UArray  
elements.
Once I solved that, I would be able to get around the performance  
issue by reorganizing the raw data.


However, as I posted yesterday, I've been able to circumvent the issue  
by rethinking my data type, i.e. using
the ~18K movie IDs as key instead of the 480K user IDs, which  
radically limits the overhead...
That way, I'm able to fit the data set in <700M of memory, without  
having to reorganize the raw data.


The uvector package implements a vector of unboxed types, and has an  
snocU operation, to append an element to the array.


I don't know how efficient it is, however.



By the way, about uvector: it has a Stream data type, and you can  
build a vector from a stream.


Thanks for letting me know, I'll keep this in mind.

greetings,

Kenneth

--

Kenneth Hoste
Paris research group - ELIS - Ghent University, Belgium
email: kenneth.ho...@elis.ugent.be
website: http://www.elis.ugent.be/~kehoste
blog: http://boegel.kejo.be

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

[Haskell-cafe] Re: Incremental array updates

[Daniel Kraft]

Eugene Kirpichov wrote:

You need to use STUArray. The Data.Array
completely-immutable-and-boxed arrays are ok only for tasks where you
build an array once and don't modify it, and where you need array
elements to be lazy.
The // operation creates a copy of the whole array with one element
modified. It should probably be called
"turtleSlowCopyWholeArrayAndModifySingleElement".


Thanks for the hint!

However, I still don't see why this increments memory usage so much... 
Shouldn't even in this case the garbage collector remove the old, no 
longer needed versions of the array?  My main point of concern is not 
that the program may run slowly, but that it uses that much memory.


But of course for the real program this hint is surely very useful! 
I'll give it a try...


Thanks,
Daniel


2009/2/26 Daniel Kraft :

Hi,

I seem to be a little stuck with incremental array updates...  I've got an
array of "few" (some thousand) integers, but have to do a calculation where
I incrementally build up the array.  For sake of simplicity, for now I don't
use a State-Monad but simply pass the array as state down the recursive
calls.

Unfortunatelly, I seem to experience problems with lazyness; when I run my
program, memory usage goes up to horrific values!  The simple program below
reproduces this; when run on my machine, it uses up about 300 MB of real and
300 MB of virtual memory, and the system starts swapping like mad!  I
compiled with ghc --make -O3, ghc version 6.8.3 if that matters.

BTW, I tried to make the array update strict using the `seq` as below, but
with no effect...  What am I doing wrong here?

Many thanks,
Daniel




import Data.Array;


arraySize = 1000
limit = 10

type MyArray = Array Int Int

emptyArray :: MyArray
emptyArray = array (0, arraySize - 1) [ (i, 0) | i <- [0 .. arraySize - 1] ]


procOne :: Int -> MyArray -> MyArray
procOne a cnt
 | a > limit = cnt
 | otherwise =
   let ind = a `mod` arraySize
   oldcnt = cnt ! ind
   newarr = cnt // [(ind, oldcnt + 1)]
   in
 procOne (a + 1) (newarr `seq` newarr)


main :: IO ()
main =
 do
   arr <- return $ procOne 0 emptyArray
   print $ arr ! 42

___
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] Incremental array updates

[Luke Palmer]

On Thu, Feb 26, 2009 at 6:53 AM, Daniel Kraft  wrote:

>  procOne (a + 1) (newarr `seq` newarr)


The semantics of seq are:  a `seq` b = _|_ if a = _|_, b otherwise.  This
implies that x `seq` x = x, and this seq is superfluous.

Maybe you meant  newarr `seq` procOne (a+1) newarr ?

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

Re: [Haskell-cafe] Incremental array updates

[Eugene Kirpichov]

You need to use STUArray. The Data.Array
completely-immutable-and-boxed arrays are ok only for tasks where you
build an array once and don't modify it, and where you need array
elements to be lazy.
The // operation creates a copy of the whole array with one element
modified. It should probably be called
"turtleSlowCopyWholeArrayAndModifySingleElement".

2009/2/26 Daniel Kraft :
> Hi,
>
> I seem to be a little stuck with incremental array updates...  I've got an
> array of "few" (some thousand) integers, but have to do a calculation where
> I incrementally build up the array.  For sake of simplicity, for now I don't
> use a State-Monad but simply pass the array as state down the recursive
> calls.
>
> Unfortunatelly, I seem to experience problems with lazyness; when I run my
> program, memory usage goes up to horrific values!  The simple program below
> reproduces this; when run on my machine, it uses up about 300 MB of real and
> 300 MB of virtual memory, and the system starts swapping like mad!  I
> compiled with ghc --make -O3, ghc version 6.8.3 if that matters.
>
> BTW, I tried to make the array update strict using the `seq` as below, but
> with no effect...  What am I doing wrong here?
>
> Many thanks,
> Daniel
>
>
>
>
> import Data.Array;
>
>
> arraySize = 1000
> limit = 10
>
> type MyArray = Array Int Int
>
> emptyArray :: MyArray
> emptyArray = array (0, arraySize - 1) [ (i, 0) | i <- [0 .. arraySize - 1] ]
>
>
> procOne :: Int -> MyArray -> MyArray
> procOne a cnt
>  | a > limit = cnt
>  | otherwise =
>    let ind = a `mod` arraySize
>        oldcnt = cnt ! ind
>        newarr = cnt // [(ind, oldcnt + 1)]
>    in
>      procOne (a + 1) (newarr `seq` newarr)
>
>
> main :: IO ()
> main =
>  do
>    arr <- return $ procOne 0 emptyArray
>    print $ arr ! 42
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Eugene Kirpichov
Web IR developer, market.yandex.ru
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe