Peter Simons | 1 Nov 01:25 2006
Picon

darcs patch: forkChild, waitForChild, parIO, timeout


New patches:

[strip trailing whitespace
Peter Simons <simons <at> cryp.to>**20061031225552] {
hunk ./Control/Concurrent.hs 6
--- 
+--
hunk ./Control/Concurrent.hs 36
-	-- $conc_scheduling	
+	-- $conc_scheduling
hunk ./Control/Concurrent.hs 40
-	
+
hunk ./Control/Concurrent.hs 79
-	
+
hunk ./Control/Concurrent.hs 164
   simple graphical user interfaces.  
+    simple graphical user interfaces.
hunk ./Control/Concurrent.hs 186
--- merged into a single output list.  
+-- merged into a single output list.
hunk ./Control/Concurrent.hs 205
-type Buffer a 
+type Buffer a
hunk ./Control/Concurrent.hs 217
-	      else 	
+	      else
hunk ./Control/Concurrent.hs 277
(Continue reading)

Samuel Bronson | 1 Nov 04:03 2006
Picon

Re: Re[2]: darcs patch: Adding isLeft, isRight, fromLeft, fromRight, splitEithers

On 10/31/06, Bulat Ziganshin <bulat.ziganshin <at> gmail.com> wrote:

> it's just part of business. if you will give to consumer bug-free
> program, you can't charge for program support :)))

Um, we don't!

(What is a "consumer", by the way?)
Samuel Bronson | 1 Nov 04:22 2006
Picon

Re: Names for small functions: just say no... Re: Data.List.join

On 10/30/06, Jon Fairbairn <jon.fairbairn <at> cl.cam.ac.uk> wrote:

> Just so. But there are lots of languages where the stuff is
> based on accidental choices of idioms by unknown bodies, and
> I "[h]ates the lot of [th]em", so I don't want Haskell to go
> that way.  I'm really uneasy at the idea that we should be
> in favour of rapid changes to libraries; I'd much rather
> they were developed after a good deal of argument about the
> mathematical properties.

So, just because nobody has figured out what the "<weeble>" category
is, you don't want it? That seems like a silly reason... next you will
be asking what mathematical construct "Show" relates to!
Bulat Ziganshin | 1 Nov 09:13 2006
Picon

Re[4]: darcs patch: Adding isLeft, isRight, fromLeft, fromRight, splitEithers

Hello Samuel,

Wednesday, November 1, 2006, 6:03:46 AM, you wrote:
>> it's just part of business. if you will give to consumer bug-free
>> program, you can't charge for program support :)))

> Um, we don't!
> (What is a "consumer", by the way?)

definitely, you are not goes through MBA school

consumers are the peoples that eat your product, stare at your product
and sleep with your product

--

-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin <at> gmail.com
Henning Thielemann | 1 Nov 09:18 2006
Picon

Re: darcs patch: Adding isLeft, isRight, fromLeft, fromRight, splitEithers


On Tue, 31 Oct 2006, Ross Paterson wrote:

> On Tue, Oct 31, 2006 at 02:20:04PM +0300, Bulat Ziganshin wrote:
> > nevertheless, we want to use them all :)   "don't teach me a life,
> > just give some money :)"
> 
> Sure.  Meanwhile over at http://hackage.haskell.org/trac/ghc/ticket/960
> we have yet another discussion of how to track down the runtime errors
> that result from this style.

Today I'm also struggling with early uses of fromJust.
   fromMaybe (error "function X was not called corectly")
  is much better. I vote for not adding isLeft and fromLeft, 'either' is a
good and safe thing.
Conor McBride | 1 Nov 09:33 2006
Picon

Re: darcs patch: Adding isLeft, isRight, fromLeft, fromRight, splitEithers

Bulat Ziganshin wrote:
> Hello Samuel,
>
> Wednesday, November 1, 2006, 6:03:46 AM, you wrote:
>   
>>> it's just part of business. if you will give to consumer bug-free
>>> program, you can't charge for program support :)))
>>>       
>
>   
>> Um, we don't!
>> (What is a "consumer", by the way?)
>>     
>
> definitely, you are not goes through MBA school
>
> consumers are the peoples that eat your product, stare at your product
> and sleep with your product
>   

Well, if this is your approach, I should be confident about your 
products but fearful of your sums.

Conor
Einar Karttunen | 1 Nov 10:26 2006
Picon
Picon

Re: darcs patch: forkChild, waitForChild, parIO, timeout

On 01.11 01:25, Peter Simons wrote:
> +	-- ** Child Threads
> +	ChildId,		-- opaque: ChildId a = Child ThreadId (MVar a)
> +	childId,		-- :: Child a -> ThreadId
> +	forkChild,		-- :: Monoid a => IO a -> IO (Child a)
> +	activeChild,		-- :: Child a -> IO Bool
> +	waitForChild,		-- :: Child a -> IO a

This makes it hard to have a manager thread that sits over a pool of
children and watches them. I think we could look at Erlang for the API
- it is one of the few languages which make it easy to handle pools
of child threads and restart handlers watching over them.

The proposed API makes it hard to manage a dynamically sized pool
of threads in an efficient fashion.

> +	-- ** Parallel Execution
> +	parIO,			-- :: Monoid a => IO a -> IO a -> IO a

Nice :-)

> +	-- ** Timeouts
> +	Timeout,		-- Timeout = Int

Better have a type like MicroSecond or Second that conveys
the meaning.

> +	timeout,		-- :: Timeout -> IO a -> IO (Maybe a)

The implementation is actually non-optimal and spawns
(Continue reading)

Bulat Ziganshin | 1 Nov 11:36 2006
Picon

Re[2]: darcs patch: forkChild, waitForChild, parIO, timeout

Hello Einar,

Wednesday, November 1, 2006, 12:26:12 PM, you wrote:

> This makes it hard to have a manager thread that sits over a pool of
> children and watches them. I think we could look at Erlang for the API
> - it is one of the few languages which make it easy to handle pools
> of child threads and restart handlers watching over them.

i'm not sure that it is the same, but there is bsphlib library:

This is a forwarded message
From: Frederico Franzosi <ffranzosi <at> gmail.com>
To: haskell-cafe <at> haskell.org
Date: Tuesday, September 5, 2006, 6:52:30 AM
Subject: [Haskell-cafe] BSPHlib-0.1 Release

===8<==============Original message text===============
Is with happiness that I announce my first project release.

I announced it as an idea to the summer of code and as Paolo Martini
said to me that it was a "good idea" I decided to publish it.

The link to the summer of code proposal follows:
http://hackage.haskell.org/trac/summer-of-code/ticket/80
That link briefly explains what BSPHlib is.

To download the source:
http://www.inf.ufes.br/~ffranzosi/BSPHlib-0.1.tar.gz

(Continue reading)

roconnor | 1 Nov 13:34 2006
Picon

Re: [GHC] #974: Add unzipEithers, lefts, rights to Data.Either

I've removed the controvertial isLeft, fromLeft, isRight, fromRight from 
the trac, and added lefts and rights. The controvertial additions can be 
put in a new trac. Let us focus on the the noncontrovertial additions 
first.

I've also renamed splitEithers into unzipEithers, which I think is better.

A new patch is available on the trac: 
<http://hackage.haskell.org/trac/ghc/ticket/974>

--

-- 
Russell O'Connor                                      <http://r6.ca/>
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''
Jón Fairbairn | 1 Nov 14:59 2006
X-Face
Picon
Picon

Re: Names for small functions: just say no... Re: Data.List.join

"Samuel Bronson" <naesten <at> gmail.com> writes:

> On 10/30/06, Jon Fairbairn <jon.fairbairn <at> cl.cam.ac.uk> wrote:
> 
> > Just so. But there are lots of languages where the stuff is
> > based on accidental choices of idioms by unknown bodies, and
> > I "[h]ates the lot of [th]em", so I don't want Haskell to go
> > that way.  I'm really uneasy at the idea that we should be
> > in favour of rapid changes to libraries; I'd much rather
> > they were developed after a good deal of argument about the
> > mathematical properties.
> 
> So, just because nobody has figured out what the
> "<weeble>" category is, you don't want it?

You need to read more carefully. I said "what would convince
me ..." I didn't say that the absence of a proof convinces
me otherwise. Everything /else/ I've been arguing convinces
me otherwise.

> That seems like a silly reason... next you will be asking
> what mathematical construct "Show" relates to!

Of course not. But I do care that Show has showsPrec and
that elements of the type ShowS has useful compositional
properties.  These things were thought about carefully.

--

-- 
Jón Fairbairn                                 Jon.Fairbairn <at> cl.cam.ac.uk
(Continue reading)


Gmane