Re: [Haskell-cafe] Reading images (PGM)

[Ketil Malde]

Greg Buchholz <[EMAIL PROTECTED]> writes:

>> I need to write a function in Haskell, which
>> 1) reads a greyscale image (for instance, in JPEG, PNG or the like) and

> If you can specify any image format you want, and you're not
> concerned with efficiency, you can't beat the simplicity of the
> portrable greymap (PGM) file format.

There are also variants using black and white (PBM) and color (PPM)
and they also have textual value representations.  Google for Andrew
Cooke's pages, he has some code for reading/writing them as part of
Pancito, IIRC. 

-kzm
-- 
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] Reading images

[Adrian Hey]

On Thursday 20 Jan 2005 7:35 pm, Dmitri Pissarenko wrote:
> Hello!
>
> I need to write a function in Haskell, which
>
> 1) reads a greyscale image (for instance, in JPEG, PNG or the like) and
>
> 2) transforms it into a n X m matrix A, where Aij contains an integer value
> (in the range 0 to 255). That integer value is zero for a completely black
> pixel, 255 for a completely white pixel and lies between zero and 255 for a
> grey pixel.
>
> In my program, I need ONLY to read an image and to transform it into such
> matrix.
>
> Which graphics library can you recommend, if no other image manipulation
> operations are required?

These might help..
 http://homepages.nildram.co.uk/~ahey/HLibs/Multimedia.SDL.Core/
 http://homepages.nildram.co.uk/~ahey/HLibs/Multimedia.SDL.Image/

What you'll get is an SDL surface (C data structure), so
you'll have to write some code to read it if you want a Haskell
array.

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

[Haskell-cafe] weird behavior using HUnit

[Frédéric Gobry]

Hello,

I just experienced a weird problem while using HUnit.  My code (a simple
apache log analyser) used to run in constant space (thanks to the good
suggestions and examples I received from the list :-)), and I wanted to
add some unit tests. To my great surprise, the code started to eat up
lots of memory again. I've isolated the problem down. It seems that if I
declare my test suite with the line:

testParseLog = HUnit.runTestTT (HUnit.TestList [_testUpdate])

then my code does not run in constant space anymore. Note that the
testParseLog is not actually used, but only exported from the module, so
that I can run it with ghc -e testParseLog.

The code is attached. The line in question is at the end of ParseLog.hs,
and I compiled the whole with ghc-6.2.2 (debian testing)

Any hint ?

thanks in advance,

Frédéric

-- 
Frédéric GobryInfoscience
  DIT-KIS / EPFL
  Tel: +41216932288
http://people.epfl.ch/frederic.gobry



parselog--devel--1.0--patch-10.tar.gz
Description: Binary data


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

[Haskell-cafe] Re: [Haskell] Implicit parallel functional programming

[Ben Lippmeier]

Satnam Singh wrote:
Ample looks interesting. What license does it use? I had a quick look
over the source and can't find anything. Is there a port to Windows or
does it not do any OS specific UI/graphics?
By default, we're releasing it under GPL. I guess I should place a copy 
of the license somewhere in the tarball...

For the graphs it produces, it just emits a gnuplot source file 
(textfile, easy) and then automagically calls gnuplot to display that file.

It would probably work straight out of the box under cygwin (or similar) 
with an appropriate build of gnuplot in your current path.

Failing that, you (or I) could easilly comment out the "call gnuplot" 
stage and end up with a vanilla console-IO application.

If it gives you any trouble then send me a mail and i'll fix it.
... There's also a paper that goes with it, which used to be on Clem's 
page but I see that the link is broken now, i'll get fixed.

...
a (very slow) simulator you might want to poke around with. I wrote it 
based around Clem Baker-Finch's "Abstract machine for parallel lazy 
evaluation", which supports fully speculative implicit parallelism.

There's a link to it on my homepage at 
http://cs.anu.edu.au/people/Ben.Lippmeier

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

Re: [Haskell-cafe] Re: Hugsvs GHC (again)was: Re: Somerandomnewbiequestions

[Ben Rudiak-Gould]

Glynn Clements wrote:
>Keean Schupke wrote:
>>Why is disk a special case?
>
>With "slow" streams, where there may be an indefinite delay before the
>data is available, you can use non-blocking I/O, asynchronous I/O,
>select(), poll() etc to determine if the data is available.
>[...]
>With files or block devices, the data is always deemed to be
>"available", even if the data isn't in physical memory.
I don't think this really captures the reason for the difference. It's 
not that select chooses not to do anything on the assumption that file 
access is fast. It's that it /can't/ do anything, because (drum roll) 
disk files are totally different from streams.

The data you read from an input stream is being actively written by 
someone else. As the producer keeps writing, data will end up buffered 
in local memory until you read it. select() tells you when there's 
buffered data to read.

If you're reading from a random-access file, there's no way it can tell 
you when the file data is buffered, because it doesn't know which part 
of the file you plan to read. The OS may try to guess for readahead 
purposes, but select()'s behavior can't depend on that guess.

If streams were distinguished from random-access files at the OS level, 
the situation would be different. The fact that you create an input 
stream on top of a disk file indicates to the OS that you plan to read 
the file sequentially from that point. It's natural to use the same 
buffering model that's used for sockets, and select() can tell you when 
that buffer is non-empty. This is just like readahead, except 
predictable and under app control to some extent.

Since you can create an arbitrary number of streams on a file, this 
mechanism provides all the functionality of NT's overlapped I/O model 
and quite a bit more.

This is another example of why the world would be better off with the 
file/stream model. Have I convinced anyone?

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

[Haskell-cafe] Can't do basic time operations with System.Time

[John Goerzen]

Hi,

I have a simple desire.  I have a string that I need to parse as a
date/time string in the local timezone, then convert it to standard
seconds-since-epoch format.  This is trivial in C, Perl, Python, etc.
but seems impossible to do reliably in Haskell.  I'm hoping someone can
tell me where I've gone wrong.

My initial idea was to parse the string, generate a CalendarTime object,
use toClockTime to convert it to seconds-since-epoch, and then grab the
value out of that.  There were some problems, though: what to put in
ctTZ and ctIsDST?  I initially loaded them with 0 and False, though that
turned out to be clearly wrong.

My next idea was to take the ctTZ result from toCalendarTime, then use
that for all the CalendarTime objects I'd generate.  That was wrong,
too, during daylight savings time.  I don't think I should have to
re-implement the algorithms for determining whether a given date is
under DST worldwide.

What I really need is just a wrapper around mktime() that just calls
mktime and doesn't do anything else.  All the post-processing that
System.Time is doing is what's causing me trouble.  I'd just like it to
ignore ctTZ, ctTZName, and ctIsDST.  That would yield behavior identical
to the C library.

-- John


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

[Haskell-cafe] lex

[Daniel Fischer]

Hi,

does anybody know, why 'lex' isn't faithful to the Haskell-syntax?

Since it isn't difficult to make it ignore comments, handle qualified names 
and recognize octal/hexadecimal literals (the system, be it hugs or ghc, does 
it, and I filled in the required code this evening, so for a good programmer 
it would be a matter of half an hour at most), I suppose there must be a 
reason, only I can't think of one.

If you have any good ideas or even know the reason, please tell me.

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

Re: [Haskell-cafe]Re: Hugsvs GHC (again)was: Re: Somerandomnewbiequestions

[Glynn Clements]

Keean Schupke wrote:

> > > read. I don't see the problem... (Okay, I can see that if select lies, 
> > > and the
> > > read takes a long time you might miss the next scheduling timeslot - but
> > > as far as I am aware select doesn't lie, and read will return immediately
> > > if select says there is data ready)...
> > > 
> > > 
> >
> >select() _does_ lie for "ordinary files", e.g., disk files.  It
> >assumes the data is immediately readable, even if it hasn't pulled it
> >off disk yet.  If the "ordinary" file actually resides on an NFS
> >volume, or CD, or something else slow, then you have a problem.
> 
> But the kernel does read-ahead so this data should just be a buffer copy.

You can't rely upon the kernel always having read the data already. 
E.g. a program which performs trivial operations on large files may
well be able to consume the data faster than the kernel can obtain it.

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Hugsvs GHC (again)was: Re: Somerandomnewbiequestions

[Glynn Clements]

Keean Schupke wrote:

> Why is disk a special case?

With "slow" streams, where there may be an indefinite delay before the
data is available, you can use non-blocking I/O, asynchronous I/O,
select(), poll() etc to determine if the data is available.

If it is, reading the data is essentially just copying from kernel
memory to userspace.

If it isn't, the program can do something else while it's waiting for
the data to arrive.

With files or block devices, the data is always deemed to be
"available", even if the data isn't in physical memory. Calling read()
in such a situation will block until the data has been read into
memory.

> I have never heard that all processes
> under linux wait for a disk read... The kernel most certainly does
> not busy wait for disks to respond, so the only alternative is that
> the process that needs to wait (and only that process) is put to
> sleep. In which case a second thread would be unaffected.

Correct. The point is that maximising CPU utilisation requires the use
of multiple kernel threads; select/poll or non-blocking/asynchronous
I/O won't suffice.

> Linux does not busy wait in the Kernel! (don't forget the kernel
> does read-ahead, so it could be that read really does return
> 'immediately' and without any delay apart from at the end of file -
> In which case asynchronous IO just slows you down with extra context
> switches).

It doesn't busy wait; it suspends the process/thread, then schedules
some other runnable process/thread. The original thread remains
suspended until the data has been transferred into physical memory.

Reading data from a descriptor essentially falls into three cases:

1. The data is in physical RAM. read() copies the data to the supplied
user-space buffer then returns control to the caller.

2. The data isn't in physical RAM, but is available with only a finite
delay (i.e. time taken to read from block device or network
filesystem).

3. The data isn't in physical RAM, and may take an indefinite amount
of time to arrive (e.g. from a socket, pipe, terminal etc).

The central issue is that the Unix API doesn't distinguish between
cases 1 and 2 when it comes to non-blocking I/O, asynchronous I/O,
select/poll etc. [OTOH, NT overlapped I/O and certain Unix extensions
do distinguish these cases, i.e. data is only "available" when it's in
physical RAM.]

If you read from a non-blocking descriptor, and case 2 applies, read()
will block while the data is read from disk then return the data; it
won't return -1 with errno set to EAGAIN, as would happen with case 3. 

If you want to be able to utilise the CPU while waiting for disk I/O
to occur, you have to use multiple kernel threads, with one thread for
each pending I/O operation, plus another one for computations (or
another one for each CPU if you want to obtain the full benefit of
an SMP system).

Even then, you still have to allow for the fact that user-space
"memory" is subject to swapping and demand-paging.

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] File path programme

[Mark Carroll]

I tried writing a little command-line utility to find the relative path of
one thing from another thing (with Unix-like systems in mind). For example,

$ ./pathfromof /etc/init.d/ /etc/X11/XF86Config-4
../X11/XF86Config-4
$ ./pathfromof /tmp/baz/ /tmp/foo/
.
$ ls -l /tmp/baz
lrwxr-xr-x  1 markc markc 8 2005-01-20 12:01 /tmp/baz -> /tmp/foo

It turned out surprisingly complex, though, and doesn't feel very neat or
tidy at all, nor is it very portable given that I couldn't find generic
library functions for manipulating bits of filepaths. Anyhow, it's at
http://www.chiark.greenend.org.uk/~markc/PathFromOf.hs and may yet have
egregious bugs.

It seems to me like it could certainly be improved in various ways. If
anyone has any thoughts, as to how I could improve my style, make more use
of standard libraries, etc., I'd certainly appreciate them.

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

Re: [Haskell-cafe] Reading images (PGM)

[Greg Buchholz]

Dmitri Pissarenko wrote:
> I need to write a function in Haskell, which
> 
> 1) reads a greyscale image (for instance, in JPEG, PNG or the like) and

If you can specify any image format you want, and you're not
concerned with efficiency, you can't beat the simplicity of the
portrable greymap (PGM) file format.  You read in a simple header with
the dimensions of the image, and one 8 bit character per pixel.

http://www-info2.informatik.uni-wuerzburg.de/mitarbeiter/wolfram/lehre/bildformate.html

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

[Haskell-cafe] Reading images

[Dmitri Pissarenko]

Hello!

I need to write a function in Haskell, which

1) reads a greyscale image (for instance, in JPEG, PNG or the like) and

2) transforms it into a n X m matrix A, where Aij contains an integer value
(in the range 0 to 255). That integer value is zero for a completely black
pixel, 255 for a completely white pixel and lies between zero and 255 for a
grey pixel.

In my program, I need ONLY to read an image and to transform it into such
matrix.

Which graphics library can you recommend, if no other image manipulation
operations are required?

TIA

Dmitri Pissarenko
--
Dmitri Pissarenko
Software Engineer
http://dapissarenko.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] RE: Answers to Exercises in Craft of FP

[Gour]

Ketil Malde ([EMAIL PROTECTED]) wrote:

> Another option is posting the excercise to this list (or perhaps in
> comp.lang.functional), along with your current effort at solving it.

I consider it would be useful to have the the whole collection somewhere, maybe
on wiki since Thompson's book (beside Hudak's HSOE) very popular one for
learning Haskell and it can bring even more popularity for Haskell language.

Is it only me, but it looks that more & more posts are appearing on this list?

> (As this could look like a homework request, don't expect the direct
> solution, but I think you will get some hints to nudge you in the
> right direction.)

Of course, but, otoh, solving ALL the exercises from the book is 
time-consuming, so to be able to sneak into some would be a nice learning 
experience :-)

Sincerely,
Gour

-- 
Registered Linux User   | #278493
GPG Public Key  | 8C44EDCD
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Answers to Exercises in Craft of FP

[Gour]

David Owen ([EMAIL PROTECTED]) wrote:

> Unfortuantely I don't know of anywhere that the exercise answers can be 
> found, even after some google searching.  I would definitely find them 
> useful though as there are a couple I haven't been able to work out.

Me too. And I hope we're not the only one using the textbook :-)

> I can't say I've gone through all the exercises yet but I'll get there one 
> day!  I've got as far as the abstract data types chapter.

Same here. It takes a lot of time to go thorugh all the exercises, especially
since there are some which are just a slight variation on the theme.

I have to finish some from the 6th chapter :-(

Sincerely,
Gour

-- 
Registered Linux User   | #278493
GPG Public Key  | 8C44EDCD
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Problems with compiling wxFruit

[Dmitri Pissarenko]

Thanks all for the help! Now it works.
--
Dmitri Pissarenko
Software Engineer
http://dapissarenko.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Problems with compiling wxFruit

[Georg Martius]

Hi,
It looks like you should use --make option.
The error message  "Failed to load interface for X" indicates, that no compiled version 
(".hi") of X could be found. "--make" will chaise the dependencies.
Good luck!
Georg
On Thu, 20 Jan 2005 15:50:29 +0100, Dmitri Pissarenko <[EMAIL PROTECTED]> wrote:
Hello!
I'm trying to compile wxFruit sample program paddleball
(http://zoo.cs.yale.edu/classes/cs490/03-04b/bartholomew.robinson/).
When I try to compile file paddle.hs (see below where it is availeble) using
the call

ghc -fglasgow-exts -farrows -package wx -iC:\dapWork\haskell-learning\afrp-0.4
\src:C:\dapWork\haskell-learning paddle.hs

I'm getting the error message

paddle.hs:10:
Failed to load interface for `WXFruit':
Could not find interface file for `WXFruit'
(use -v to see a list of the files searched for)
paddle.hs:11:
Failed to load interface for `AFRP':
Could not find interface file for `AFRP'
(use -v to see a list of the files searched for)
paddle.hs:12:
Failed to load interface for `AFRPUtilities':
Could not find interface file for `AFRPUtilities'
(use -v to see a list of the files searched for)

The file WXFruit.hs is located in the same directory as paddle.hs. AFRP.hs and
AFRPUtilities.hs are located in the directory C:\dapWork\haskell-learning\afrp-
0.4\src.
Apparently, those packages are not installed properly.
What should I do in order to compile paddle.hs?
Thanks in advance
PS: All files related to this example (paddle.hs and wxFruit.hs) are available
at
http://dapissarenko.com/resources/2005_01_20_haskell_learning/wxFruitSample.zip
in a 7 MB zip archive.
--
Dmitri Pissarenko
Software Engineer
http://dapissarenko.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

--
 Georg Martius,  Tel: (+49 34297) 89434 
--- http://www.flexman.homeip.net -
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Problems with compiling wxFruit

[shelarcy]

You hace to add option --make, if you complie haskell program file with
(Bsome files.
(BAnd, you have to change WX.size to Wx.sz .
(BBecause wxHaskell-0.8 changed some functions.
(B
(BOn Thu, 20 Jan 2005 15:50:29 +0100, Dmitri Pissarenko
(B<[EMAIL PROTECTED]> wrote:
(B> I'm trying to compile wxFruit sample program paddleball
(B> (http://zoo.cs.yale.edu/classes/cs490/03-04b/bartholomew.robinson/).
(B>
(B>
(B> When I try to compile file paddle.hs (see below where it is availeble)  
(B> using the call
(B>
(B> 
(B> ghc -fglasgow-exts -farrows -package wx  
(B> -iC:\dapWork\haskell-learning\afrp-0.4
(B> \src:C:\dapWork\haskell-learning paddle.hs
(B> 
(B>
(B> I'm getting the error message
(B>
(B> 
(B> paddle.hs:10:
(B> Failed to load interface for `WXFruit':
(B> Could not find interface file for `WXFruit'
(B> (use -v to see a list of the files searched for)
(B>
(B> paddle.hs:11:
(B> Failed to load interface for `AFRP':
(B> Could not find interface file for `AFRP'
(B> (use -v to see a list of the files searched for)
(B>
(B> paddle.hs:12:
(B> Failed to load interface for `AFRPUtilities':
(B> Could not find interface file for `AFRPUtilities'
(B> (use -v to see a list of the files searched for)
(B> 
(B
(B-- 
(Bshelarcy 
(Bhttp://page.freett.com/shelarcy/
(B___
(BHaskell-Cafe mailing list
(BHaskell-Cafe@haskell.org
(Bhttp://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe]Re: Hugsvs GHC (again)was: Re: Somerandomnewbiequestions

[Keean Schupke]

Keith Wansbrough wrote:
read. I don't see the problem... (Okay, I can see that if select lies, 
and the
read takes a long time you might miss the next scheduling timeslot - but
as far as I am aware select doesn't lie, and read will return immediately
if select says there is data ready)...
   

select() _does_ lie for "ordinary files", e.g., disk files.  It
assumes the data is immediately readable, even if it hasn't pulled it
off disk yet.  If the "ordinary" file actually resides on an NFS
volume, or CD, or something else slow, then you have a problem.
--KW 8-)
 

But the kernel does read-ahead so this data should just be a buffer copy.
   Keean.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: I/O interface

[Keean Schupke]

Andre Pang wrote:
The syntactic sugar is the killer.  (Using monads is really no fun if 
you don't have do notation, for example.  Doable: yes.  Pretty: 
definitely not!)  Even if you use Template Haskell to try to implement 
the syntactic sugar, you're very limited by the splice $(...) notation 
at the call site.  I've always argued that Haskell really should have 
a full-blown macro system: it would really help with Haskell and 
EDSLs, and of course for integrating these kinds of libraries.  TH is 
90% of the way there, and with a bit more thought, those pesky splices 
could just magically disappear ... ;)

Its not that bad... the trick I am using is lifting existing haskell 
syntax, so an interface definition looks like:

   $(interface [d| data MyInterface = MyInterface {
 method1 :: ...,
 method2 :: ...,
 method3 :: ...} |])
So we define a normal haskell98 record, and the TH lifts it to an 
interface definition
using extensible records. An implementation looks would possibly look like:

   $(implementation [MyInterface] [d|
   method1 = ...
   method2 = ...
   method3 = ... |])
Yes, also agreed.  I did some similar Haskell<->OO integration work, 
and the type errors which appeared when something went wrong are quite 
awesome.  User-defined compile-time errors would be fantastic, but 
that would require quite a lot of effort.
We can do something better than what we have at the moment, for a start 
TH can generate user defined
compile time errors - but we don't want to have to implement our own 
typechecking, so we can supplement
this with a class with no instance and empty types:

   class Fail a
   data Some_user_defined_error
   instance Fail Some_user_defined_error => Test ...
So the compiler will report an undefined instance in Fail for your error 
type, but you can at least get some
readable text, which is better than nothing.

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

[Haskell-cafe] Problems with compiling wxFruit

[Dmitri Pissarenko]

Hello!

I'm trying to compile wxFruit sample program paddleball
(http://zoo.cs.yale.edu/classes/cs490/03-04b/bartholomew.robinson/).


When I try to compile file paddle.hs (see below where it is availeble) using
the call


ghc -fglasgow-exts -farrows -package wx -iC:\dapWork\haskell-learning\afrp-0.4
\src:C:\dapWork\haskell-learning paddle.hs


I'm getting the error message


paddle.hs:10:
Failed to load interface for `WXFruit':
Could not find interface file for `WXFruit'
(use -v to see a list of the files searched for)

paddle.hs:11:
Failed to load interface for `AFRP':
Could not find interface file for `AFRP'
(use -v to see a list of the files searched for)

paddle.hs:12:
Failed to load interface for `AFRPUtilities':
Could not find interface file for `AFRPUtilities'
(use -v to see a list of the files searched for)


The file WXFruit.hs is located in the same directory as paddle.hs. AFRP.hs and
AFRPUtilities.hs are located in the directory C:\dapWork\haskell-learning\afrp-
0.4\src.

Apparently, those packages are not installed properly.

What should I do in order to compile paddle.hs?

Thanks in advance

PS: All files related to this example (paddle.hs and wxFruit.hs) are available
at

http://dapissarenko.com/resources/2005_01_20_haskell_learning/wxFruitSample.zip

in a 7 MB zip archive.
--
Dmitri Pissarenko
Software Engineer
http://dapissarenko.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe]Re: Hugsvs GHC (again)was: Re: Somerandomnewbiequestions

[Keith Wansbrough]

> read. I don't see the problem... (Okay, I can see that if select lies, 
> and the
> read takes a long time you might miss the next scheduling timeslot - but
> as far as I am aware select doesn't lie, and read will return immediately
> if select says there is data ready)...

select() _does_ lie for "ordinary files", e.g., disk files.  It
assumes the data is immediately readable, even if it hasn't pulled it
off disk yet.  If the "ordinary" file actually resides on an NFS
volume, or CD, or something else slow, then you have a problem.

--KW 8-)

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

[Haskell-cafe] Re: I/O interface

[Andre Pang]

On 20/01/2005, at 11:06 PM, Keean Schupke wrote:
I find it no harder than writing with monads for example... certainly 
there are some
tricky things going on in both... but that doesn't stop people using 
monads for IO,
state etc.

Syntactic sugar over the top for instance and implementation 
definitions is something
we are working on (using template-haskell) - so that end of things can 
certainly be
made neater for the user.
The syntactic sugar is the killer.  (Using monads is really no fun if 
you don't have do notation, for example.  Doable: yes.  Pretty: 
definitely not!)  Even if you use Template Haskell to try to implement 
the syntactic sugar, you're very limited by the splice $(...) notation 
at the call site.  I've always argued that Haskell really should have a 
full-blown macro system: it would really help with Haskell and EDSLs, 
and of course for integrating these kinds of libraries.  TH is 90% of 
the way there, and with a bit more thought, those pesky splices could 
just magically disappear ... ;)

The big problem I guess is error messages - and that would require 
some user
defined way of throwing compile time errors.
Yes, also agreed.  I did some similar Haskell<->OO integration work, 
and the type errors which appeared when something went wrong are quite 
awesome.  User-defined compile-time errors would be fantastic, but that 
would require quite a lot of effort.

--
% Andre Pang : trust.in.love.to.save  
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe]Re: Hugsvs GHC (again)was: Re: Somerandomnewbiequestions

[Simon Marlow]

On 20 January 2005 11:30, Keean Schupke wrote:

> Simon Marlow wrote:
> 
>> Yes, except that you forgot that not all foreign calls can run
>> 
>> concurrently with Haskell code.  Only the "safe" ones can.
>> 
>> 
> Okay, now I understand what is going on. Why is there extra overhead
> for a 'safe' call?

A safe call must 

  - save its state on the Haskell stack
  - save its thread state object on a queue, so GC can find it
  - tidy up the stack so GC can take place
  - release the RTS lock
  - possibly start a new OS thread if the pool is empty

of these, releasing the RTS lock is probably the most expensive.  Also,
if another OS thread gets scheduled before the call returns, we have an
expensive context switch on return.

In contrast, an unsafe call is just an inline C call.

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

[Haskell-cafe] Re: I/O interface

[Keean Schupke]

Andre Pang wrote:
Just because you can encode the OO idioms in Haskell doesn't mean it's 
particularly straightforward to use them.  As your example shows, 
getting the syntax right for these OOish constructs isn't easy (not to 
mention verbose), and even so, the type errors you face when you get 
things wrong are, well, long :).
This is true enough... but it really isn't as dificault as it looks. 
Once you get used to
the style it is really quite easy - and notice how you don't need class 
definitions, or
types for the objects - it is all derived by GHC. This is an advance 
over current OO
languages.

I guess my point is that in theory, Haskell can support OO right now.  
In practice, it's something that isn't very tasty.
I find it no harder than writing with monads for example... certainly 
there are some
tricky things going on in both... but that doesn't stop people using 
monads for IO,
state etc.

Syntactic sugar over the top for instance and implementation definitions 
is something
we are working on (using template-haskell) - so that end of things can 
certainly be
made neater for the user.

The big problem I guess is error messages - and that would require some user
defined way of throwing compile time errors.
   Keean.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe]Re: Hugsvs GHC (again)was: Re: Somerandomnewbiequestions

[Keean Schupke]

But does it matter... If the select says the read will block you schedule
another haskell thread, if select says the read will not block, you do the
read. I don't see the problem... (Okay, I can see that if select lies, 
and the
read takes a long time you might miss the next scheduling timeslot - but
as far as I am aware select doesn't lie, and read will return immediately
if select says there is data ready)...

So I guess technically other Haskell threads cannot be scheduled during
the read, but as read returns immediately they don't need to...
It seems to me this is why calling read sequentially and with 'unsafe' is
faster than calling it with 'safe' and allowing haskell-thread-scheduling to
occur during the read syscall.
   Is that about right?
   Keean.
Simon Marlow wrote:
A safe call must 

 - save its state on the Haskell stack
 - save its thread state object on a queue, so GC can find it
 - tidy up the stack so GC can take place
 - release the RTS lock
 - possibly start a new OS thread if the pool is empty
of these, releasing the RTS lock is probably the most expensive.  Also,
if another OS thread gets scheduled before the call returns, we have an
expensive context switch on return.
In contrast, an unsafe call is just an inline C call.
Cheers,
	Simon
 

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

[Haskell-cafe] Re: I/O interface

[Andre Pang]

On 20/01/2005, at 3:42 AM, Keean Schupke wrote:
Have you read the OOHaskell paper?
   http://homepages.cwi.nl/~ralf/OOHaskell/
This shows how to encode many OO idioms in Haskell, without any 
extensions
(beyond those that GHC already supports)... Here's some sample code
(from the Shapes.hs example) to give you a flavor of it:
[..]
Just because you can encode the OO idioms in Haskell doesn't mean it's 
particularly straightforward to use them.  As your example shows, 
getting the syntax right for these OOish constructs isn't easy (not to 
mention verbose), and even so, the type errors you face when you get 
things wrong are, well, long :).

I guess my point is that in theory, Haskell can support OO right now.  
In practice, it's something that isn't very tasty.

--
% Andre Pang : trust.in.love.to.save  
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe]Re: Hugsvs GHC (again)was: Re: Somerandomnewbiequestions

[Keean Schupke]

Simon Marlow wrote:
Yes, except that you forgot that not all foreign calls can run
concurrently with Haskell code.  Only the "safe" ones can.
 

Okay, now I understand what is going on. Why is there extra overhead
for a 'safe' call?
   Keean.
//
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe]Re: Hugsvs GHC (again)was: Re: Somerandomnewbiequestions

[Simon Marlow]

On 20 January 2005 10:01, Keean Schupke wrote:

> Simon Marlow wrote:
> 
>> We're getting a bit confused here.  Keean: the original question was
>> about whether a disk read will stop all other *Haskell* threads. 
>> Not OS threads.  The two are quite different beasts in GHC.
>> 
>> Cheers,
>>  Simon
>> 
>> 
> But if GHC is running with the -threaded flag, then other
> Haskell-threads can keep running using the second OS-thread, even
> though one Haskell-thread (and its associated OS thread) is blocking
> - right? 

If the call to read() was "safe" (i.e. the FFI "safe" attribute), then
yes.  But GHC currently does and "unsafe" call to read(), even with
-threaded, which doesn't give other threads a chance to run.

Perhaps it should be a safe call.  That's going to hurt performance
unless you really need to parallelise disk I/O, though.  Maybe it
wouldn't hurt too much, someone should measure it.

> In other words even with disk IO (as I said the kernel would not
> busy-wait - so there are
> only two options, this OS-thread is put to sleep, or the data is
> already in a buffer and is
> returned immediately), all the other Haskell-threads should not block
> (provided it is
> running with -threaded)
> 
> Have I got that right?

Yes, except that you forgot that not all foreign calls can run
concurrently with Haskell code.  Only the "safe" ones can.

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

Re: [Haskell-cafe] Re: Hugsvs GHC (again)was: Re: Somerandomnewbiequestions

[Keean Schupke]

Simon Marlow wrote:
On 20 January 2005 09:56, Keean Schupke wrote:
 

Why is disk a special case? I have never heard that all processes
under linux wait for a disk read...
   

You were talking about Haskell threads, not processes!  These are quite
different things.
 

But with -threaded GHC is using multiple processes (OS-threads)
to run the Haskell threads. If one OS thread handles IO, and the other
runs the Haskell-thread-scheduler, then Haskell-threads need never
wait for IO - apart form the actual thread doing the IO.
The reason that disk I/O is different is because select() treats it
differently, and select() is what GHC's runtime currently uses to
multiplex I/O.
 

Are you sure? Its not mentioned in the manual...
   Keean.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Re: Hugsvs GHC (again)was: Re: Somerandomnewbiequestions

[Simon Marlow]

On 20 January 2005 09:56, Keean Schupke wrote:

> Why is disk a special case? I have never heard that all processes
> under linux wait for a disk read...

You were talking about Haskell threads, not processes!  These are quite
different things.

> The kernel most certainly does not busy wait for disks
> to respond, so the only alternative is that the process that needs to
> wait (and only that process) is put to sleep. In which case a second
> thread would be unaffected.
> 
> Linux does not busy wait in the Kernel! (don't forget the kernel does
> read-ahead,
> so it could be that read really does return 'immediately' and without
> any delay
> apart from at the end of file - In which case asynchronous IO just
> slows you down with extra context switches).

The question is whether Haskell threads block when one of them is
reading from the disk, and this has nothing to do with what happens in
the kernel.   I never said that Linux busy waits in the kernel.

The reason that disk I/O is different is because select() treats it
differently, and select() is what GHC's runtime currently uses to
multiplex I/O.

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

Re: [Haskell-cafe]Re: Hugsvs GHC (again)was: Re: Somerandomnewbiequestions

[Keean Schupke]

Simon Marlow wrote:
We're getting a bit confused here.  Keean: the original question was
about whether a disk read will stop all other *Haskell* threads.  Not OS
threads.  The two are quite different beasts in GHC.
Cheers,
	Simon
 

But if GHC is running with the -threaded flag, then other Haskell-threads
can keep running using the second OS-thread, even though one Haskell-thread
(and its associated OS thread) is blocking - right?
In other words even with disk IO (as I said the kernel would not 
busy-wait - so there are
only two options, this OS-thread is put to sleep, or the data is already 
in a buffer and is
returned immediately), all the other Haskell-threads should not block 
(provided it is
running with -threaded)

Have I got that right?
   Keean.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Re: Hugsvs GHC (again)was: Re: Somerandomnewbiequestions

[Simon Marlow]

On 19 January 2005 16:58, Keean Schupke wrote:

> Simon Marlow wrote:
>> This is what GHC does, if I understand you correctly.  The thread
>> running select() does so in its own OS thread, while another OS
>> thread runs the Haskell code.  As long as you use -threaded, that
>> is.  Oh, and before GHC 6.4 it was done a different way - the
>> scheduler used to do the select() between running Haskell threads.
>> 
>> Cheers,
>>  Simon
>> 
>> 
> So this means even though the IO calls block, the other Haskell
> threads (when run with -threaded) keep running?

Yes, unless the IO is to/from disk on a Unix system.

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

Re: [Haskell-cafe] Re: Hugsvs GHC (again)was: Re: Somerandomnewbiequestions

[Keean Schupke]

Why is disk a special case? I have never heard that all processes under 
linux
wait for a disk read... The kernel most certainly does not busy wait for 
disks
to respond, so the only alternative is that the process that needs to wait
(and only that process) is put to sleep. In which case a second thread would
be unaffected.

Linux does not busy wait in the Kernel! (don't forget the kernel does 
read-ahead,
so it could be that read really does return 'immediately' and without 
any delay
apart from at the end of file - In which case asynchronous IO just slows 
you down
with extra context switches).

   Keean.
Simon Marlow wrote:
On 19 January 2005 16:58, Keean Schupke wrote:
 

Simon Marlow wrote:
   

This is what GHC does, if I understand you correctly.  The thread
running select() does so in its own OS thread, while another OS
thread runs the Haskell code.  As long as you use -threaded, that
is.  Oh, and before GHC 6.4 it was done a different way - the
scheduler used to do the select() between running Haskell threads.
Cheers,
Simon
 

So this means even though the IO calls block, the other Haskell
threads (when run with -threaded) keep running?
   

Yes, unless the IO is to/from disk on a Unix system.
Cheers,
	Simon
 

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

RE: [Haskell-cafe]Re: Hugsvs GHC (again)was: Re: Somerandomnewbiequestions

[Simon Marlow]

On 19 January 2005 20:33, Glynn Clements wrote:

> Simon Marlow wrote:
> 
>> We do use a thread pool.  But you still need as many OS threads as
>> there are blocked read() calls, unless you have a single thread
>> doing select() as I described.
> 
> How does the select() help? AFAIK, select() on a regular file or block
> device will always indicate that it is readable, even if a subsequent
> read() would have to read the data from disk.

Again we've lost track of the discussion a bit.  Yes you're right, but I
was answering a different question.

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

RE: [Haskell-cafe]Re: Hugsvs GHC (again)was: Re: Somerandomnewbiequestions

[Simon Marlow]

On 19 January 2005 20:31, Glynn Clements wrote:

> Keean Schupke wrote:
> 
 Okay, my ignorance of Posix is showing again. Is it currently the
 case, then, that every GHC thread will stop running while a disk
 read is in progress in any thread? Is this true on all platforms?
>>> 
>>> It's true on Unix-like systems, I believe.  Even with -threaded.  It
>>> might not be true on Win32.
>> 
>> I think this is not true on linux, where a thread is just a process
>> created with special flags to keep the same fds and memory.
>> 
>> As threads on linux are scheduled like processes, one thread
>> blocking should not affect the others?
> 
> That should be true of all POSIX-like thread implementations
> (including Linux, whose threads aren't quite POSIX-compliant, e.g. in
> regard to signal handling, but aren't that far off).
> 
> Essentially, blocking system calls only block the calling kernel
> thread.
> 
> OTOH, if you are implementing multiple user-space threads within a
> single kernel thread, if that kernel thread blocks, all of the
> user-space threads within it will be blocked.

We're getting a bit confused here.  Keean: the original question was
about whether a disk read will stop all other *Haskell* threads.  Not OS
threads.  The two are quite different beasts in GHC.

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

Re: [Haskell-cafe] Re: Top Level etc.

[Keean Schupke]

Ben Rudiak-Gould wrote:
   > len :: [a] -> Int
   >
   > len xs = let ?accum = 0 in len' xs
   >
   > len' :: forall a. (?accum :: Int) => [a] -> Int
   >
   > len' [] = ?accum
   > len' (x:xs) = let ?accum = ?accum + (1::Int) in len' xs
   *Main> :t len'
   len' :: forall a. (?accum :: Int) => [a] -> Int
   *Main> len "hello"
   5
I don't get this. The second answer (the one quoted above) must be wrong...
len' gets a value only in the empty '[]' case. The recursion is such 
that the value
of '?accum' is incremented on the return of the recursively called 
function, therefore
the value of '?accum' in the case '[]' is always zero! How on earth does 
this get
the answer five?

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

Re: [Haskell-cafe] Re: Top Level etc.

[Ben Rudiak-Gould]

Jim Apple wrote:
> Does anyone have examples of these? This one scares the foo out of me:
>
>>> * It's not even safe in general to add a signature giving the same type
>>> that the compiler would infer anyway
Here's an example:
   > len :: [a] -> Int
   >
   > len xs = let ?accum = 0 in len' xs
   >
   > len' [] = ?accum
   > len' (x:xs) = let ?accum = ?accum + (1::Int) in len' xs
   *Main> :t len'
   len' :: forall a. (?accum :: Int) => [a] -> Int
   *Main> len "hello"
   0
   > len :: [a] -> Int
   >
   > len xs = let ?accum = 0 in len' xs
   >
   > len' :: forall a. (?accum :: Int) => [a] -> Int
   >
   > len' [] = ?accum
   > len' (x:xs) = let ?accum = ?accum + (1::Int) in len' xs
   *Main> :t len'
   len' :: forall a. (?accum :: Int) => [a] -> Int
   *Main> len "hello"
   5
This happens as a side effect of the way that type inference currently 
works on recursive binding groups. It happens with typeclass 
dictionaries too, but it isn't observable because they can't be rebound 
in a local scope.

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