From v.dijk.bas at gmail.com  Thu Apr  2 03:14:04 2009
From: v.dijk.bas at gmail.com (Bas van Dijk)
Date: Thu Apr  2 03:01:12 2009
Subject: some comments about bytestring-show package
In-Reply-To: <49CAA81D.70002@gmail.com>
References: <49CAA81D.70002@gmail.com>
Message-ID: <f73f66150904020014p3e2b876akf20454ccabf6448e@mail.gmail.com>

On Wed, Mar 25, 2009 at 11:54 PM, Manlio Perillo
<manlio.perillo@gmail.com> wrote:
> Hi.
>
> I have started to use the bytestring-show package, since I need to serialize
> a big data structure in a lazy bytestring.
>
> However I have noted some possible problems with the API:
>
> - sometime it is used the put<xxx> prefix, other times the show<xxx>
> ?prefix
> - the module Text.Show.ByteString, IMHO, should re-export the Put class
> ?from the Data.Binary.Put.
>
>
> Thanks to the author of the package.
>
> Manlio Perillo

Maybe you have better luck contacting the maintainer of the package
which can be found on the package's hackage page:

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bytestring-show

regards,

Bas
From manlio.perillo at gmail.com  Thu Apr  2 03:45:23 2009
From: manlio.perillo at gmail.com (Manlio Perillo)
Date: Thu Apr  2 03:32:44 2009
Subject: some comments about bytestring-show package
In-Reply-To: <f73f66150904020014p3e2b876akf20454ccabf6448e@mail.gmail.com>
References: <49CAA81D.70002@gmail.com>
	<f73f66150904020014p3e2b876akf20454ccabf6448e@mail.gmail.com>
Message-ID: <49D46D13.6090409@gmail.com>

Bas van Dijk ha scritto:
> On Wed, Mar 25, 2009 at 11:54 PM, Manlio Perillo
> <manlio.perillo@gmail.com> wrote:
>> Hi.
>>
>> I have started to use the bytestring-show package, since I need to serialize
>> a big data structure in a lazy bytestring.
>>
> 
> Maybe you have better luck contacting the maintainer of the package
> which can be found on the package's hackage page:
> 
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bytestring-show
> 

Thanks, Dan already contacted me privately.


Manlio
From sebf at informatik.uni-kiel.de  Fri Apr  3 05:46:23 2009
From: sebf at informatik.uni-kiel.de (Sebastian Fischer)
Date: Fri Apr  3 05:33:32 2009
Subject: cabal: confusing dependencies conflict between ghc-6.10.1 and
	process
Message-ID: <00D7B66A-BDE4-4870-860F-6B706567CDA1@informatik.uni-kiel.de>

Hello,

I get a confusing message when trying to install 'vacuum' from Hackage:

$ cabal install vacuum
Resolving dependencies...
cabal: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.1  
however
process-1.0.1.1 was excluded because ghc-6.10.1 requires process  
==1.0.1.0

There is something wrong: according to this message, the package  
ghc-6.10.1 requires both process==1.0.1.1 and process==1.0.1.0.

According to ghc-pkg, the package ghc-6.10.1 requires process==1.0.1.0:

$ ghc-pkg describe ghc
name: ghc
version: 6.10.1
[...]
depends: Cabal-1.6.0.1 array-0.2.0.0 base-4.0.0.0
          bytestring-0.9.1.4 containers-0.2.0.0 directory-1.0.0.2
          editline-0.2.1.0 filepath-1.1.0.1 haskell98-1.0.1.0  
hpc-0.5.0.2
          old-time-1.0.0.1 process-1.0.1.0 template-haskell-2.3.0.0
          unix-2.3.1.0
[...]

Why does cabal think that ghc-6.10.1 requires process==1.0.1.1?

I use

$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.1

$ cabal --version
cabal-install version 0.6.2
using version 1.6.0.2 of the Cabal library

Is it a problem that cabal uses version 1.6.0.2 of the Cabala library  
but the package ghc-6.10.1 requires version 1.6.0.1?

Cheers,
Sebastian
From martijn at van.steenbergen.nl  Fri Apr  3 05:56:42 2009
From: martijn at van.steenbergen.nl (Martijn van Steenbergen)
Date: Fri Apr  3 05:43:47 2009
Subject: cabal: confusing dependencies conflict between ghc-6.10.1 and
 process
In-Reply-To: <00D7B66A-BDE4-4870-860F-6B706567CDA1@informatik.uni-kiel.de>
References: <00D7B66A-BDE4-4870-860F-6B706567CDA1@informatik.uni-kiel.de>
Message-ID: <49D5DD5A.40602@van.steenbergen.nl>

Hi Sebastian,

Sebastian Fischer wrote:
> There is something wrong: according to this message, the package 
> ghc-6.10.1 requires both process==1.0.1.1 and process==1.0.1.0.

Please see Duncan's email [1].

Hope this helps!

Martijn.


[1] http://www.mail-archive.com/haskell-cafe@haskell.org/msg52659.html
From sebf at informatik.uni-kiel.de  Fri Apr  3 06:20:36 2009
From: sebf at informatik.uni-kiel.de (Sebastian Fischer)
Date: Fri Apr  3 06:07:45 2009
Subject: cabal: confusing dependencies conflict between ghc-6.10.1 and
	process
In-Reply-To: <49D5DD5A.40602@van.steenbergen.nl>
References: <00D7B66A-BDE4-4870-860F-6B706567CDA1@informatik.uni-kiel.de>
	<49D5DD5A.40602@van.steenbergen.nl>
Message-ID: <1CF32E54-33EB-4126-A017-486BC6303B1D@informatik.uni-kiel.de>

Hi Martijn,

>> There is something wrong: according to this message, the package  
>> ghc-6.10.1 requires both process==1.0.1.1 and process==1.0.1.0.
>
> Please see Duncan's email [1].

Thanks for the hint! Unregistering QuickCheck-1.2.0.0 and  
haskell98-1.0.1.0 from the user package db (those packages are present  
in the global package db with the same version) solved this problem  
for me.

Sebastian
From marlowsd at gmail.com  Fri Apr  3 06:30:42 2009
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri Apr  3 06:17:53 2009
Subject: System.Posix.User: make get{Group,User}EntryFor* more portable
In-Reply-To: <20090329150842.GA25577@petunia.outback.escape.de>
References: <20090329150842.GA25577@petunia.outback.escape.de>
Message-ID: <49D5E552.2050303@gmail.com>

Matthias Kilian wrote:
> Hi,
> 
> some oddities let the user001 test of the unix package fail on
> getGroupEntryFor*. One reason is that sysconf(_SC_GETGR_R_SIZE_MAX)
> returns 1024 on OpenBSD, while getgr*_r(3) actually need a buffer
> of 1024 + 200 * sizeof(char*) bytes.
> 
> Note that the grBufSize = 2048 workaround in User.hsc did not work
> on 64 bit machines with OpenBSD, even before the _SC_GETGR_R_SIZE_MAX
> sysconf had been introduced.
> 
> Instead of fiddling with stupid numbers again, I just implemented the
> try / enlarge / try harder scheme mentioned for example at
> 
> http://www.opengroup.org/onlinepubs/9699919799/functions/getgrgid.html
> 
> And I did so for all four functions, just in case there are existing
> problems with other unices (OpenBSD only needs the getGroupEntryFor*
> fixes).
> 
> My Haskell sucks badly, so if someone has a cleaner solution: feel
> free use it instead of my patch ;-)

Looks ok to me.  I'll validate and commit.  Thanks for the patch!

Cheers,
	Simon
From libraries at haskell.org  Fri Apr  3 10:59:43 2009
From: libraries at haskell.org (network)
Date: Fri Apr  3 10:46:51 2009
Subject: [network] #1: unpackFamily on Windows fails match
In-Reply-To: <053.1587b5def64e355b370143b764e5c158@haskell.org>
References: <053.1587b5def64e355b370143b764e5c158@haskell.org>
Message-ID: <062.a0637becd87f288332bb93663459b526@haskell.org>

#1: unpackFamily on Windows fails match
----------------------+-----------------------------------------------------
  Reporter:  igloo    |       Owner:     
      Type:  defect   |      Status:  new
  Priority:  major    |   Milestone:     
 Component:  network  |     Version:     
Resolution:           |    Keywords:     
----------------------+-----------------------------------------------------
Changes (by anonymous):

  * component:  component1 => network

-- 
Ticket URL: <http://trac.haskell.org/network/ticket/1#comment:3>
network <http://projects.haskell.org/network/>
Networking-related facilities
From libraries at haskell.org  Fri Apr  3 11:07:39 2009
From: libraries at haskell.org (network)
Date: Fri Apr  3 10:54:43 2009
Subject: [network] #6: Network.Socket.sClose should change socket status
Message-ID: <053.9b02f0ad54d8d85fe59b4a20c227ae76@haskell.org>

#6: Network.Socket.sClose should change socket status
---------------------+------------------------------------------------------
 Reporter:  tibbe    |       Owner:     
     Type:  defect   |      Status:  new
 Priority:  major    |   Milestone:     
Component:  network  |     Version:     
 Keywords:           |  
---------------------+------------------------------------------------------
 Initially reported here: http://hackage.haskell.org/trac/ghc/ticket/2996

 ----

 The current implementation of sClose in Network.Socket leaves the socket
 in a Connected state but frees the underlying OS resource. Thus, any
 further operations on the socket may apply to a different OS object if
 something else was assigned the same FD after the socket was closed. For
 example, sClose'ing the socket a second time can lead to some arbitrary
 other file or socket being closed.

 The attached test case was run in ghci 6.8.2 on Debian Linux sid, though
 by inspection of the Network.Socket source in 6.10.1, this is still
 present and the test case should work. It takes advantage of the way *NIX
 allocates file descriptors to demonstrate specific misbehaviors, so may or
 may not misbehave in the intended way on other platforms.

 ----

 Test case

 ----

 Simple patch to add a Closed state and make sClose idempotent. Operations
 that perform state transitions already check the socket state and will
 refuse to operate on a Closed socket, but this does not add checks for
 other operations like send/recv.

 ----

 I should mention that closed-state.patch is against the 6.8.2 network
 library. It applies cleanly (with offsets) against the 6.10.1 library, but
 I can't test it.

 ----

 Proposed patch in addition to closed-state.patch that adds checks for a
 valid FD in all operations. This is a fairly simple approach. In
 particular, it punts on the problem of one thread closing the socket in
 the middle of a socket operation in another thread. Arguably, the
 semantics of this are sufficiently unclear (especially for blocking
 operations) that applications should be doing their own synchronization in
 such situations.

 ----

 Thanks for the patches! We'll take a look.

 ----

 tibbe, this looks related to things you've been working on recently, and I
 think you are considering becoming the network maintainer? Can you take a
 look please?

 Thanks!

 ----

 Sorry for the late reply. closed-state.patch looks fine to me. As for the
 second patch I think we need to figure out the performance consequences of
 checking an MVar for every op before we make the change.

 Perhaps it would be worthwhile to write down which guarantees the API
 currently gives and could give when used in multi-threaded code. I'm not
 even entirely sure what guarantees we give at the moment, without your
 patches. If nothing else that would serve as good documentation.

 ----

 I pushed the closed-state.patch.

-- 
Ticket URL: <http://trac.haskell.org/network/ticket/6>
network <http://projects.haskell.org/network/>
Networking-related facilities
From libraries at haskell.org  Fri Apr  3 11:10:15 2009
From: libraries at haskell.org (network)
Date: Fri Apr  3 10:57:19 2009
Subject: [network] #6: Network.Socket.sClose should change socket status
In-Reply-To: <053.9b02f0ad54d8d85fe59b4a20c227ae76@haskell.org>
References: <053.9b02f0ad54d8d85fe59b4a20c227ae76@haskell.org>
Message-ID: <062.fd9df58b13df8e8b2049c03a58a7f853@haskell.org>

#6: Network.Socket.sClose should change socket status
----------------------+-----------------------------------------------------
  Reporter:  tibbe    |       Owner:  tibbe   
      Type:  defect   |      Status:  assigned
  Priority:  major    |   Milestone:          
 Component:  network  |     Version:          
Resolution:           |    Keywords:          
----------------------+-----------------------------------------------------
Changes (by tibbe):

  * owner:  => tibbe
  * status:  new => assigned

-- 
Ticket URL: <http://trac.haskell.org/network/ticket/6#comment:1>
network <http://projects.haskell.org/network/>
Networking-related facilities
From libraries at haskell.org  Fri Apr  3 12:16:24 2009
From: libraries at haskell.org (network)
Date: Fri Apr  3 12:03:26 2009
Subject: [network] #6: Network.Socket.sClose should change socket status
In-Reply-To: <053.9b02f0ad54d8d85fe59b4a20c227ae76@haskell.org>
References: <053.9b02f0ad54d8d85fe59b4a20c227ae76@haskell.org>
Message-ID: <062.3f736a424f9edfaea1757ad6759d77d3@haskell.org>

#6: Network.Socket.sClose should change socket status
----------------------+-----------------------------------------------------
  Reporter:  tibbe    |       Owner:  tibbe   
      Type:  defect   |      Status:  assigned
  Priority:  major    |   Milestone:          
 Component:  network  |     Version:          
Resolution:           |    Keywords:          
----------------------+-----------------------------------------------------
Comment (by anonymous):

 Any particular reason why sClose is idempotent? I'd have expected it to
 throw an exception on an attempt to close a closed socket.

-- 
Ticket URL: <http://trac.haskell.org/network/ticket/6#comment:2>
network <http://projects.haskell.org/network/>
Networking-related facilities
From libraries at haskell.org  Fri Apr  3 13:29:52 2009
From: libraries at haskell.org (network)
Date: Fri Apr  3 13:16:55 2009
Subject: [network] #6: Network.Socket.sClose should change socket status
In-Reply-To: <053.9b02f0ad54d8d85fe59b4a20c227ae76@haskell.org>
References: <053.9b02f0ad54d8d85fe59b4a20c227ae76@haskell.org>
Message-ID: <062.413fccbd7271c29ee087f4ed16f939e7@haskell.org>

#6: Network.Socket.sClose should change socket status
----------------------+-----------------------------------------------------
  Reporter:  tibbe    |       Owner:  tibbe   
      Type:  defect   |      Status:  assigned
  Priority:  major    |   Milestone:          
 Component:  network  |     Version:          
Resolution:           |    Keywords:          
----------------------+-----------------------------------------------------
Comment (by amthrax):

 I made sClose idempotent to mirror the interface of hClose, which is
 likewise idempotent.

-- 
Ticket URL: <http://trac.haskell.org/network/ticket/6#comment:3>
network <http://projects.haskell.org/network/>
Networking-related facilities
From wren at community.haskell.org  Fri Apr  3 18:52:58 2009
From: wren at community.haskell.org (wren ng thornton)
Date: Fri Apr  3 18:40:02 2009
Subject: ANN: logfloat 0.12.0.1
Message-ID: <49D6934A.4020702@community.haskell.org>

--------------------------------------------
-- logfloat 0.12.0.1
--------------------------------------------

This package provides a type for storing numbers in the log-domain, 
primarily useful for preventing underflow when multiplying many 
probabilities as in HMMs and other probabilistic models. The package 
also provides modules for dealing with floating numbers correctly.


--------------------------------------------
-- Now using FFI
--------------------------------------------

We now use the FFI to gain access to C's accurate log1p (and expm1) 
functions. This greatly increases the range of resolution, especially 
for very small LogFloat values. These are currently exposed from 
Data.Number.LogFloat, though they may move to a different module in 
future versions.

On GHC 6.10 the use of -fvia-C had to be disabled because it conflicts 
with the FFI (version 0.12.0.0 still used it, which is fine on GHC 6.8). 
I'm still investigating the use of -fasm and getting proper benchmarking 
numbers. Contact me if you notice significant performance degradation.

Using the FFI complicates the build process for Hugs; details are noted 
in the INSTALL file. It may also complicate building on Windows (due to 
ccall vs stdcall), though I'm not familiar with Windows FFI and don't 
have a machine to test on.

The calling convention is "unsafe" in order to avoid overhead. However, 
in the past this has been noted to cause issues with multithreaded 
applications since it locks all RTS threads instead of just the calling 
thread. If you're using logfloat in a multithreaded application and 
notice a slowdown, or if you're more familiar with these details than I, 
tell me so I can fix things.

If you have any difficulties with the FFI, let me know. As an interim 
solution the FFI can be disabled by turning off the useFFI Cabal flag 
during configure, which will compile the package to use the naive log1p 
implementation from earlier versions.


--------------------------------------------
-- Other changes since 0.11.0
--------------------------------------------

* (0.11.1) Felipe Lessa added an instance for IArray UArray LogFloat. On 
GHC we use newtype deriving; On Hugs we fall back to unsafeCoerce to 
distribute the newtype over IArray UArray Double.

* (0.11.2 Darcs) Moved the log/exp fusion rules from 
Data.Number.LogFloat into Data.Number.Transfinite where our log function 
is defined.

* Added a Storable LogFloat instance for GHC. No implementation is 
available yet for Hugs.

* Removed orphaned toRational/fromRational fusion rules, which were 
obviated by the introduction of the Data.Number.RealToFrac module in 0.11.0.

* Changed the Real LogFloat instance to throw errors when trying to 
convert transfinite values into Rational.


--------------------------------------------
-- Compatibility / Portability
--------------------------------------------

The package is compatible with Hugs (September 2006) and GHC (6.8, 
6.10). For anyone still using GHC 6.6, the code may still work if you 
replace LANGUAGE pragma by equivalent OPTIONS_GHC pragma.

The package is not compatible with nhc98 and Yhc because 
Data.Number.RealToFrac uses MPTCs. The other modules should be compatible.


--------------------------------------------
-- Links
--------------------------------------------

Homepage:
     http://code.haskell.org/~wren/

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

Darcs:
     http://code.haskell.org/~wren/logfloat/

Haddock (Darcs version):
     http://code.haskell.org/~wren/logfloat/dist/doc/html/logfloat/

-- 
Live well,
~wren
From libraries at haskell.org  Sun Apr  5 03:56:08 2009
From: libraries at haskell.org (network)
Date: Sun Apr  5 03:43:06 2009
Subject: [network] #7: Network.Socket.recv throws IOException on reading 0
 bytes
Message-ID: <053.a576a5d8395cc799d05058241cd6622b@haskell.org>

#7: Network.Socket.recv throws IOException on reading 0 bytes
---------------------+------------------------------------------------------
 Reporter:  tibbe    |       Owner:     
     Type:  defect   |      Status:  new
 Priority:  major    |   Milestone:     
Component:  network  |     Version:     
 Keywords:           |  
---------------------+------------------------------------------------------
 Initially reported here: http://hackage.haskell.org/trac/ghc/ticket/3071

 ----

 My man pages has the following to say about the return value of recv:

     These calls return the number of bytes received, or -1 if an error
 occurred.

     For TCP sockets, the return value 0 means the peer has closed its half
 side of the connection.

 This means that it's absolutely fine to read 0 bytes when using e.g. UDP
 socket.

 However, the Network.Socket.recv function always throws an exception upon
 reading 0 bytes regardless of the protocol family.

-- 
Ticket URL: <http://trac.haskell.org/network/ticket/7>
network <http://projects.haskell.org/network/>
Networking-related facilities
From johan.tibell at gmail.com  Sun Apr  5 04:15:39 2009
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sun Apr  5 04:02:38 2009
Subject: New maintainer, Darcs repository and Trac for the network library
Message-ID: <90889fe70904050115t67259531y228b259fc6b22c6@mail.gmail.com>

Hi,

I've taken over the maintainer role for the network library and per
Ian's suggestion I've moved the project to community.haskell.org. As a
result the Darcs repository and the Trac instance have moved. Here are
the new locations:

Darcs repository:

http://code.haskell.org/network/

Trac:

http://trac.haskell.org/network/

Ian and I have migrated most of the active tickets to the new Trac.
Please submit bug reports using the above Trac instance instead of the
one used for GHC.

Discussions about API changes will be conducted on the this mailing
list using the same process [1] as before. I'm still not an expert on
all parts of the code and I expect that resolving tickets will
continue to be a community effort. However, I will be the person the
reviewing changes and making (most of) the releases.

1. http://www.haskell.org/haskellwiki/Library_submissions

Cheers,

Johan
From kili at outback.escape.de  Sun Apr  5 06:51:34 2009
From: kili at outback.escape.de (Matthias Kilian)
Date: Sun Apr  5 06:39:12 2009
Subject: New maintainer,
	Darcs repository and Trac for the network library
In-Reply-To: <90889fe70904050115t67259531y228b259fc6b22c6@mail.gmail.com>
References: <90889fe70904050115t67259531y228b259fc6b22c6@mail.gmail.com>
Message-ID: <20090405105133.GA25150@petunia.outback.escape.de>

On Sun, Apr 05, 2009 at 10:15:39AM +0200, Johan Tibell wrote:
> I've taken over the maintainer role for the network library and per
> Ian's suggestion I've moved the project to community.haskell.org. As a
> result the Darcs repository and the Trac instance have moved. Here are
> the new locations:
> 
> Darcs repository:
> 
> http://code.haskell.org/network/

Will this be used for the ghc builds, too? Or will changes be pulled
from the new repository into the old one
(http://darcs.haskell.org/packages/network/)?

Ciao,
	Kili
From johan.tibell at gmail.com  Sun Apr  5 17:17:04 2009
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sun Apr  5 17:04:01 2009
Subject: New maintainer,
	Darcs repository and Trac for the network library
In-Reply-To: <20090405105133.GA25150@petunia.outback.escape.de>
References: <90889fe70904050115t67259531y228b259fc6b22c6@mail.gmail.com>
	<20090405105133.GA25150@petunia.outback.escape.de>
Message-ID: <90889fe70904051417w53a87644mc1a5d5b3c0b8e225@mail.gmail.com>

On Sun, Apr 5, 2009 at 12:51 PM, Matthias Kilian <kili@outback.escape.de> wrote:
> On Sun, Apr 05, 2009 at 10:15:39AM +0200, Johan Tibell wrote:
>> I've taken over the maintainer role for the network library and per
>> Ian's suggestion I've moved the project to community.haskell.org. As a
>> result the Darcs repository and the Trac instance have moved. Here are
>> the new locations:
>>
>> Darcs repository:
>>
>> http://code.haskell.org/network/
>
> Will this be used for the ghc builds, too? Or will changes be pulled
> from the new repository into the old one
> (http://darcs.haskell.org/packages/network/)?

I'll defer to Ian as he understands the GHC build system much better than I do.

Cheers,

Johan
From libraries at haskell.org  Mon Apr  6 05:59:33 2009
From: libraries at haskell.org (network)
Date: Mon Apr  6 05:46:29 2009
Subject: [network] #7: Network.Socket.recv throws IOException on reading
 0 bytes
In-Reply-To: <053.a576a5d8395cc799d05058241cd6622b@haskell.org>
References: <053.a576a5d8395cc799d05058241cd6622b@haskell.org>
Message-ID: <062.985f205e2651cceb9d26e4556c707224@haskell.org>

#7: Network.Socket.recv throws IOException on reading 0 bytes
----------------------+-----------------------------------------------------
  Reporter:  tibbe    |       Owner:  anonymous
      Type:  defect   |      Status:  assigned 
  Priority:  major    |   Milestone:           
 Component:  network  |     Version:           
Resolution:           |    Keywords:           
----------------------+-----------------------------------------------------
Changes (by anonymous):

  * owner:  => anonymous
  * status:  new => assigned

-- 
Ticket URL: <http://trac.haskell.org/network/ticket/7#comment:1>
network <http://projects.haskell.org/network/>
Networking-related facilities
From libraries at haskell.org  Mon Apr  6 05:59:53 2009
From: libraries at haskell.org (network)
Date: Mon Apr  6 05:46:49 2009
Subject: [network] #7: Network.Socket.recv throws IOException on reading
 0 bytes
In-Reply-To: <053.a576a5d8395cc799d05058241cd6622b@haskell.org>
References: <053.a576a5d8395cc799d05058241cd6622b@haskell.org>
Message-ID: <062.725c3d7936fbcd8b7d0e6eec8435f681@haskell.org>

#7: Network.Socket.recv throws IOException on reading 0 bytes
----------------------+-----------------------------------------------------
  Reporter:  tibbe    |       Owner:  tibbe
      Type:  defect   |      Status:  new  
  Priority:  major    |   Milestone:       
 Component:  network  |     Version:       
Resolution:           |    Keywords:       
----------------------+-----------------------------------------------------
Changes (by tibbe):

  * owner:  anonymous => tibbe
  * status:  assigned => new

-- 
Ticket URL: <http://trac.haskell.org/network/ticket/7#comment:2>
network <http://projects.haskell.org/network/>
Networking-related facilities
From ndmitchell at gmail.com  Tue Apr  7 16:26:59 2009
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Tue Apr  7 16:13:49 2009
Subject: Failure to install time package
Message-ID: <404396ef0904071326t17c8dd57p333e553fef7e337f@mail.gmail.com>

Hi,

Time is an important library, it got unbundled from GHC, and it seems
Windows users can't install the time package!

C:\Neil\hoogle>cabal install time --global
Resolving dependencies...
[1 of 1] Compiling Main             ( C:\Users\Neil\AppData\Local\Temp\time-1.1.
2.32884\time-1.1.2.3\Setup.hs, C:\Users\Neil\AppData\Local\Temp\time-1.1.2.32884
\time-1.1.2.3\dist\setup\Main.o )
Linking C:\Users\Neil\AppData\Local\Temp\time-1.1.2.32884\time-1.1.2.3\dist\setu
p\setup.exe ...
Configuring time-1.1.2.3...
setup.exe: sh: runGenProcess: does not exist (No such file or directory)
cabal: Error: some packages failed to install:
time-1.1.2.3 failed during the configure step. The exception was:
exit: ExitFailure 1

C:\Neil\hoogle>ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.2

My guess is that it would work if I installed mingw, but that it
hasn't been tested without. I consider this problem fatally serious -
we may have managed to make GHC 6.10.2 unuseable for many Windows
users...

Thanks

Neil
From haskell at list.mightyreason.com  Wed Apr  8 06:58:16 2009
From: haskell at list.mightyreason.com (Chris Kuklewicz)
Date: Wed Apr  8 06:45:09 2009
Subject: GHC threading bug in QSem
In-Reply-To: <404396ef0904080326o27539b1bh669dafbd2824bc1b@mail.gmail.com>
References: <404396ef0904080326o27539b1bh669dafbd2824bc1b@mail.gmail.com>
Message-ID: <49DC8348.6040507@list.mightyreason.com>


The code assumes newQsem is never given a negative argument without ever
documenting this fact.

http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/Control-Concurrent-QSem.html#waitQSem

change not only
     putMVar sem (0, blocked++[block])
to
     putMVar sem (avail, blocked++[block])
in waitQSem

but also change signalQSem to

> signalQSem :: QSemN -> IO ()
> signalQSem (QSemN sem) = modifyMVar_ free sem
>  where free (0,(b:bs)) = putMVar b () >> return (0,bs)
>        free (avail,blocked) = return (avail+1,blocked)

Neil: To allow negative values you have to change signalQSem and waitQSem.

And really folks, the waitQSem(N) and signalQSem(N) should be exception safe and
this is not currently true.  They should all be using the modifyMVar_ idiom ?
currently an exception such as killThread between the take and put will leave
the semaphore perpetually empty which is not a valid state.

I also hereby lobby that a non-blocking "trySem" be added, and while
Control.Concurrent is getting updated I think that Neil's last concurrency
puzzle would have been helped by having a non-blocking "tryReadChan" in
Control.Concurrent.Chan (note that the isEmptyChan is not useful for making
non-blocking read), and how about Control.Concurrent.Pony ?

"Control.Concurrent.SampleVar" is also not exception safe.



Neil Mitchell wrote:
> Hi
> 
> I believe the following program should always print 100:
> 
> import Data.IORef
> import Control.Concurrent
> 
> main = do
>     sem <- newQSem (-99)
>     r <- newIORef 0
>     let incRef = atomicModifyIORef r (\a -> (a+1,a))
>     sequence_ $ replicate 100 $ forkIO $ incRef >> signalQSem sem
>     waitQSem sem
>     v <- readIORef r
>     print v
> 
> Unfortunately, it doesn't seem to. Running on a 2 processor machine,
> with +RTS -N3 I usually get 100, but have got answers such as 49, 82,
> 95. With +RTS -N2 it doesn't seem to fail, but it does with -N4. This
> is using GHC 6.10.2 on Windows. Using GHC 6.8.3, I get answers /= 100
> roughly every other time.
> 
>>From reading the implementation of QSem, it doesn't seem that negative
> availability was considered. I think it would be need to be changed
> as:
> 
> -- Invariant: avail >= 1 ==> null blocked
> 
> waitQSem :: QSem -> IO ()
> waitQSem (QSem sem) = do
>    (avail,blocked) <- takeMVar sem  -- gain ex. access
>    if avail > 0 then
>      putMVar sem (avail-1,[])
>     else do
>      block <- newEmptyMVar
>      putMVar sem (avail, blocked++[block])   -- changed line
>      takeMVar block
> 
> signalQSem :: QSem -> IO ()
> signalQSem (QSem sem) = do
>    (avail,blocked) <- takeMVar sem
>    -- changed below
>    if null blocked || avail < 0 then
>       putMVar sem (avail+1,blocked)
>    else
>       putMVar sem (avail, tail blocked)
>       putMVar (head blocked) ()
> 
> Writing parallel code is hard, so I could have easily got this wrong.
> I haven't looked at QSemN, which may need similar fixes (or may
> already deal with this)
> 
> Thanks
> 
> Neil
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

From giulianoxt at gmail.com  Wed Apr  8 12:56:28 2009
From: giulianoxt at gmail.com (Giuliano Vilela)
Date: Wed Apr  8 12:43:16 2009
Subject: Problem with cabal-install
Message-ID: <4086423f0904080956y6a9509e8lf8606db05e91f8c4@mail.gmail.com>

Hello,

I'm having a problem installing the cabal-install tool on a linux box. Not
sure if this list is the right place do task, but was my only direction
coming from here: http://www.haskell.org/cabal/download.html

The output of the bootstrap.sh script bundled with cabal-install is bellow:

Checking installed packages for ghc-6.10.1...
parsec is already installed and the version is ok.
network is already installed and the version is ok.
Cabal is already installed and the version is ok.
HTTP is already installed and the version is ok.
zlib is already installed and the version is ok.
cleaning...
Linking Setup ...
Configuring cabal-install-0.6.2...
Preprocessing executables for cabal-install-0.6.2...
Setup: can't find source for Distribution.Client.BuildReports.Anonymous in .,
dist/build/autogen

Error during cabal-install bootstrap:
Building the cabal-install package failed


(Note that those dependency packages are already installed from a previous
run of this script)

Using GHC version 6.10.1, on a Opensuse 11.0 box:

> ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.1


Anyone has a clue on this one?


-- 
[]'s

Giuliano Vilela.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20090408/13468fec/attachment.htm
From ben.franksen at online.de  Wed Apr  8 14:20:36 2009
From: ben.franksen at online.de (Ben Franksen)
Date: Wed Apr  8 14:11:53 2009
Subject: GHC threading bug in QSem
References: <404396ef0904080326o27539b1bh669dafbd2824bc1b@mail.gmail.com>
	<49DC8348.6040507@list.mightyreason.com>
Message-ID: <griptk$cju$1@ger.gmane.org>

Chris Kuklewicz wrote:
> And really folks, the waitQSem(N) and signalQSem(N) should be exception
> safe and
> this is not currently true.  They should all be using the modifyMVar_
> idiom ? currently an exception such as killThread between the take and put
> will leave the semaphore perpetually empty which is not a valid state.
> 
> I also hereby lobby that a non-blocking "trySem" be added, and while
> Control.Concurrent is getting updated I think that Neil's last concurrency
> puzzle would have been helped by having a non-blocking "tryReadChan" in
> Control.Concurrent.Chan (note that the isEmptyChan is not useful for
> making non-blocking read),

isEmptyChan is not useful for anything because it blocks when the channel is
empty and another thread calls readChan. The following code waits forever
after printing the "1":

import Control.Concurrent
import Control.Concurrent.Chan
import Control.Monad

test = do
  c <- newChan
  forkIO $ forever $ do
    i <- readChan c
    print i
  writeChan c 1
  threadDelay 1000000
  isEmptyChan c >>= print

Test session:

ben@sarun[1]: .../hca/current > ghci Bug5.hs
GHCi, version 6.10.1: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main             ( Bug5.hs, interpreted )
Ok, modules loaded: Main.
*Main> test
1

BTW, when I interrupt this with Ctrl-C, ghc-6.10.2 crashes with a
segmentation fault. With ghc-6.10.1 I get a clean "Interrupted" message and
a new prompt. This looks like a regression to me.

Cheers
Ben

From kyagrd at gmail.com  Thu Apr  9 01:13:48 2009
From: kyagrd at gmail.com (Ahn, Ki Yung)
Date: Thu Apr  9 01:00:24 2009
Subject: unix-2.3.2.0 fails to install in ghc 6.10.1
Message-ID: <grk05m$h98$1@ger.gmane.org>

kyagrd@kyagrd:~$ uname -a
Linux kyagrd 2.6.26-1-686 #1 SMP Sat Jan 10 18:29:31 UTC 2009 i686 GNU/Linux

kyagrd@kyagrd:~$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.1

kyagrd@kyagrd:~$ which ghc
/usr/bin/ghc

kyagrd@kyagrd:~$ ghc-pkg list
/usr/lib/ghc-6.10.1/./package.conf:
    ALUT-2.1.0.0, Cabal-1.6.0.1, Diff-0.1.2, GLUT-2.1.1.2, HDBC-2.1.0,
    HDBC-postgresql-2.1.0.1, HGL-3.2.0.0, HUnit-1.2.0.3,
    OpenAL-1.3.1.1, OpenGL-2.2.1.1, QuickCheck-2.1.0.1, Stream-0.2.2,
    X11-1.4.5, X11-xft-0.3, array-0.2.0.0, arrows-0.4.1, base-3.0.3.0,
    base-4.0.0.0, binary-0.5, bytestring-0.9.1.4, cairo-0.10.0,
    cgi-3001.1.7.1, containers-0.2.0.0, convertible-1.0.2,
    directory-1.0.0.2, editline-0.2.1.0, fgl-5.4.2.2, filepath-1.1.0.1,
    gconf-0.10.0, (ghc-6.10.1), ghc-prim-0.1.0.0, gio-0.10.0,
    glade-0.10.0, glib-0.10.0, gstreamer-0.10.0, gtk-0.10.0,
    gtkglext-0.10.0, gtksourceview2-0.10.0, haskell-src-1.0.1.3,
    haskell98-1.0.1.0, hpc-0.5.0.2, hslogger-1.0.8, html-1.0.1.2,
    integer-0.1.0.0, irc-0.4.3, mtl-1.1.0.2, network-2.2.0.1,
    old-locale-1.0.0.1, old-time-1.0.0.1, packedstring-0.1.0.1,
    parallel-1.1.0.0, parsec-3.0.0, pretty-1.0.1.0, process-1.0.1.0,
    random-1.0.0.1, regex-base-0.93.1, regex-compat-0.92,
    regex-posix-0.93.1, rts-1.0, soegtk-0.10.0, stm-2.1.1.2,
    svgcairo-0.10.0, syb-0.1.0.0, syb-with-class-0.5.1, tagsoup-0.6,
    template-haskell-2.3.0.0, terminfo-0.3.0.1, time-1.1.2.3,
    unix-2.3.1.0, utf8-string-0.3.4, xhtml-3000.2.0.1, xmonad-0.8.1,
    xmonad-contrib-0.8.1, zlib-0.5.0.0
/home/kyagrd/.ghc/i386-linux-6.10.1/package.conf:
    Cabal-1.6.0.1, Cabal-1.6.0.2, HGL-3.2.0.0, HTTP-3001.1.3,
    HTTP-4000.0.4, HTTP-4000.0.5, InfixApplicative-1.0.1,
    QuickCheck-1.2.0.0, Stream-0.3.1, arrows-0.4.1, binary-0.5.0.1,
    cgi-3001.1.7.1, extensible-exceptions-0.1.1.0, filepath-1.1.0.2,
    ghc-paths-0.1.0.5, haddock-2.4.1, haskell98-1.0.1.0, irc-0.4.3,
    lazysmallcheck-0.3, network-2.2.0.1, network-2.2.1,
    old-time-1.0.0.2, parsec-2.1.0.1, process-1.0.1.1, random-1.0.0.1,
    sparsebit-0.5, terminfo-0.3.0.2, zlib-0.4.0.4, zlib-0.5.0.0

kyagrd@kyagrd:~$ cabal upgrade unix
Resolving dependencies...
Configuring unix-2.3.2.0...
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for an ANSI C-conforming const... yes
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking dirent.h usability... yes
checking dirent.h presence... yes
checking for dirent.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking grp.h usability... yes
checking grp.h presence... yes
checking for grp.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking pwd.h usability... yes
checking pwd.h presence... yes
checking for pwd.h... yes
checking signal.h usability... yes
checking signal.h presence... yes
checking for signal.h... yes
checking for string.h... (cached) yes
checking sys/resource.h usability... yes
checking sys/resource.h presence... yes
checking for sys/resource.h... yes
checking sys/times.h presence... yes
checking for sys/times.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking sys/utsname.h usability... yes
checking sys/utsname.h presence... yes
checking for sys/utsname.h... yes
checking sys/wait.h usability... yes
checking sys/wait.h presence... yes
checking for sys/wait.h... yes
checking libutil.h usability... no
checking libutil.h presence... no
checking for libutil.h... no
checking pty.h usability... yes
checking pty.h presence... yes
checking for pty.h... yes
checking utmp.h usability... yes
checking utmp.h presence... yes
checking for utmp.h... yes
checking termios.h usability... yes
checking termios.h presence... yes
checking for termios.h... yes
checking time.h usability... yes
checking time.h presence... yes
checking for time.h... yes
checking for unistd.h... (cached) yes
checking utime.h usability... yes
checking utime.h presence... yes
checking for utime.h... yes
checking for getgrgid_r... yes
checking for getgrnam_r... yes
checking for getpwnam_r... yes
checking for getpwuid_r... yes
checking for getpwnam... yes
checking for getpwuid... yes
checking for getpwent... yes
checking for getgrent... yes
checking for lchown... yes
checking for setenv... yes
checking for sysconf... yes
checking for unsetenv... yes
checking for nanosleep... yes
checking for ptsname... yes
checking for setitimer... yes
checking for shm_open in -lrt... yes
checking for shm_open... yes
checking for shm_unlink... yes
checking value of SIGABRT... 6
checking value of SIGALRM... 14
checking value of SIGBUS... 7
checking value of SIGCHLD... 17
checking value of SIGCONT... 18
checking value of SIGFPE... 8
checking value of SIGHUP... 1
checking value of SIGILL... 4
checking value of SIGINT... 2
checking value of SIGKILL... 9
checking value of SIGPIPE... 13
checking value of SIGQUIT... 3
checking value of SIGSEGV... 11
checking value of SIGSTOP... 19
checking value of SIGTERM... 15
checking value of SIGTSTP... 20
checking value of SIGTTIN... 21
checking value of SIGTTOU... 22
checking value of SIGUSR1... 10
checking value of SIGUSR2... 12
checking value of SIGPOLL... 29
checking value of SIGPROF... 27
checking value of SIGSYS... 31
checking value of SIGTRAP... 5
checking value of SIGURG... 23
checking value of SIGVTALRM... 26
checking value of SIGXCPU... 24
checking value of SIGXFSZ... 25
checking value of SIG_BLOCK... 0
checking value of SIG_SETMASK... 2
checking value of SIG_UNBLOCK... 1
checking for _SC_GETGR_R_SIZE_MAX... yes
checking for _SC_GETPW_R_SIZE_MAX... yes
checking return type of usleep... int
checking return type of unsetenv... int
checking for RTLD_NEXT from dlfcn.h... no
checking for RTLD_DEFAULT from dlfcn.h... no
checking for RTLD_LOCAL from dlfcn.h... yes
checking for RTLD_GLOBAL from dlfcn.h... yes
checking for RTLD_NOW from dlfcn.h... yes
checking for openpty... no
checking for openpty in -lutil... yes
checking for /dev/ptmx... yes
checking for /dev/ptc... no
checking for dlopen in -ldl... yes
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
configure: creating ./config.status
config.status: creating unix.buildinfo
config.status: creating include/HsUnixConfig.h
Preprocessing library unix-2.3.2.0...
Building unix-2.3.2.0...
[ 1 of 21] Compiling System.Posix.User (
dist/build/System/Posix/User.hs, dist/build/System/Posix/User.o )
[ 2 of 21] Compiling System.Posix.Unistd (
dist/build/System/Posix/Unistd.hs, dist/build/System/Posix/Unistd.o )
[ 3 of 21] Compiling System.Posix.Time (
dist/build/System/Posix/Time.hs, dist/build/System/Posix/Time.o )
[ 4 of 21] Compiling System.Posix.Resource (
dist/build/System/Posix/Resource.hs, dist/build/System/Posix/Resource.o )
[ 5 of 21] Compiling System.Posix.Process.Internals (
System/Posix/Process/Internals.hs,
dist/build/System/Posix/Process/Internals.o )

System/Posix/Process/Internals.hs:10:17:
    Module `GHC.Conc' does not export `Signal'
cabal: Error: some packages failed to install:
unix-2.3.2.0 failed during the building phase. The exception was:
exit: ExitFailure 1

From ndmitchell at gmail.com  Thu Apr  9 12:58:36 2009
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Thu Apr  9 12:45:22 2009
Subject: Failure to install time package
In-Reply-To: <404396ef0904071326t17c8dd57p333e553fef7e337f@mail.gmail.com>
References: <404396ef0904071326t17c8dd57p333e553fef7e337f@mail.gmail.com>
Message-ID: <404396ef0904090958x1434a01di21fb2fcbf8154935@mail.gmail.com>

Hi

I have raised a ticket for this bug report:
http://hackage.haskell.org/trac/ghc/ticket/3162

I consider this issue quite serious for Windows users. Time is an
important library, Windows is an important platform, GHC is an
important compiler - together we end up with a fairly important
problem.

Thanks

Neil

On Tue, Apr 7, 2009 at 9:26 PM, Neil Mitchell <ndmitchell@gmail.com> wrote:
> Hi,
>
> Time is an important library, it got unbundled from GHC, and it seems
> Windows users can't install the time package!
>
> C:\Neil\hoogle>cabal install time --global
> Resolving dependencies...
> [1 of 1] Compiling Main ? ? ? ? ? ? ( C:\Users\Neil\AppData\Local\Temp\time-1.1.
> 2.32884\time-1.1.2.3\Setup.hs, C:\Users\Neil\AppData\Local\Temp\time-1.1.2.32884
> \time-1.1.2.3\dist\setup\Main.o )
> Linking C:\Users\Neil\AppData\Local\Temp\time-1.1.2.32884\time-1.1.2.3\dist\setu
> p\setup.exe ...
> Configuring time-1.1.2.3...
> setup.exe: sh: runGenProcess: does not exist (No such file or directory)
> cabal: Error: some packages failed to install:
> time-1.1.2.3 failed during the configure step. The exception was:
> exit: ExitFailure 1
>
> C:\Neil\hoogle>ghc --version
> The Glorious Glasgow Haskell Compilation System, version 6.10.2
>
> My guess is that it would work if I installed mingw, but that it
> hasn't been tested without. I consider this problem fatally serious -
> we may have managed to make GHC 6.10.2 unuseable for many Windows
> users...
>
> Thanks
>
> Neil
>
From lemming at henning-thielemann.de  Fri Apr 10 19:06:00 2009
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Fri Apr 10 18:52:42 2009
Subject: Problem with cabal-install
In-Reply-To: <4086423f0904080956y6a9509e8lf8606db05e91f8c4@mail.gmail.com>
References: <4086423f0904080956y6a9509e8lf8606db05e91f8c4@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.0904110105370.4348@anubis.informatik.uni-halle.de>


On Wed, 8 Apr 2009, Giuliano Vilela wrote:

> Hello,
> 
> I'm having a problem installing the cabal-install tool on a linux box. Not sure if this list
> is the right place do task, but was my only direction coming from here:
> http://www.haskell.org/cabal/download.html

Do you have more luck with my binary?
   http://code.haskell.org/~thielema/cabal/
From haskell at list.mightyreason.com  Sat Apr 11 07:26:19 2009
From: haskell at list.mightyreason.com (ChrisK)
Date: Sat Apr 11 07:13:02 2009
Subject: ANN: MSem replacement for QSem
Message-ID: <49E07E5B.70709@list.mightyreason.com>

"Grasshopper, try to take the stone from my hand"

Hello all,

  After looking at the code for QSem [1], I realize it is not exception safe.
And it does more work than needed.

  I have a proposed replacement module MSem at
http://haskell.org/haskellwiki/SafeConcurrent on the wiki.

  I claim this is a safer, more correct, and more efficient replacement for
QSem.  But I may be tragically wrong which is where you come in.  Please try and
find some strange concurrency bug that I have missed.  Once there is reviewed
replacement code I will propose changing the base package.

  Exception safe replacements for QSemN and SampleVar are also needed.

  The MSem code I have can be generalized into an "MSemN", but the semantics are
be different from "QSemN".  This MSemN only considers the needs of the first
blocked waiter instead of all of them.  The code MSemN is on the same wiki page,
perhaps someone will find this variant useful.

Cheers,
  Chris

[1]
http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/Control-Concurrent-QSem.html
From haskell at list.mightyreason.com  Sun Apr 12 08:18:44 2009
From: haskell at list.mightyreason.com (ChrisK)
Date: Sun Apr 12 08:05:23 2009
Subject: Broken beyond repair: Control.Concurrent.SampleVar
Message-ID: <49E1DC24.1070506@list.mightyreason.com>

Hello all,

  The SampleVar module in base is not exception safe.  I believe that there is
no way to fix this module to be exception safe while retaining the current behavior.

  The problem with the current behavior is that the writeSampleVar pretends to
know how many blocked reader threads are waiting on a value.  In reality these
blocked threads may have been killed.

  When writeSampleVar sees blocked threads it does a blocking putMVar and then
decrements the blocked reader thread count. If any two of the blocked reader
threads ever die then eventually you get a blocked writer.

  I can find no efficient way to retain the current behavior in the presence of
exceptions.  The logic of the current behavior is that the blocked readers mean
that the previously written value should not be discarded, the previous value
belongs to the next blocked reader.

  I propose that SampleVar be either removed, or replaced with a slightly
different exception safe version.  I propose not considering the previously
written value to belong to a blocked reader, and to replace it with the new value.

  I will open a ticket about this when I get more time.

-- 
Chris
From bulat.ziganshin at gmail.com  Sun Apr 12 09:34:09 2009
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Sun Apr 12 09:21:02 2009
Subject: Broken beyond repair: Control.Concurrent.SampleVar
In-Reply-To: <49E1DC24.1070506@list.mightyreason.com>
References: <49E1DC24.1070506@list.mightyreason.com>
Message-ID: <36433184.20090412173409@gmail.com>

Hello ChrisK,

Sunday, April 12, 2009, 4:18:44 PM, you wrote:

>   The problem with the current behavior is that the writeSampleVar pretends to
> know how many blocked reader threads are waiting on a value.  In reality these
> blocked threads may have been killed.

may be it's possible to add exception handling to the write operation?

-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From ml at isaac.cedarswampstudios.org  Sun Apr 12 10:08:24 2009
From: ml at isaac.cedarswampstudios.org (Isaac Dupree)
Date: Sun Apr 12 09:55:05 2009
Subject: Broken beyond repair: Control.Concurrent.SampleVar
In-Reply-To: <36433184.20090412173409@gmail.com>
References: <49E1DC24.1070506@list.mightyreason.com>
	<36433184.20090412173409@gmail.com>
Message-ID: <200904121008.24630.ml@isaac.cedarswampstudios.org>

Bulat Ziganshin wrote:
> Hello ChrisK,
>
> Sunday, April 12, 2009, 4:18:44 PM, you wrote:
> >   The problem with the current behavior is that the writeSampleVar
> > pretends to know how many blocked reader threads are waiting on a value. 
> > In reality these blocked threads may have been killed.
>
> may be it's possible to add exception handling to the write operation?

more obviously importantly (I think, from that description,) is exception 
handling around the blocking read operation -- after all, even thread-killing 
involves an exception.

From haskell at list.mightyreason.com  Sun Apr 12 10:42:02 2009
From: haskell at list.mightyreason.com (Chris Kuklewicz)
Date: Sun Apr 12 10:28:39 2009
Subject: Broken beyond repair: Control.Concurrent.SampleVar
In-Reply-To: <36433184.20090412173409@gmail.com>
References: <49E1DC24.1070506@list.mightyreason.com>
	<36433184.20090412173409@gmail.com>
Message-ID: <49E1FDBA.1030405@list.mightyreason.com>

Bulat Ziganshin wrote:
> Hello ChrisK,
> 
> Sunday, April 12, 2009, 4:18:44 PM, you wrote:
> 
>>   The problem with the current behavior is that the writeSampleVar pretends to
>> know how many blocked reader threads are waiting on a value.  In reality these
>> blocked threads may have been killed.
> 
> may be it's possible to add exception handling to the write operation?
> 

A perfect fix would leave SampleVar's full behavior unchanged when there are no
exceptions.  This perfect fix does not exist.

I claim it is possible to create a fix that leaves the documented behavior
unchanged, but changes some of the actual detailed behavior.

One such fix is up at http://haskell.org/haskellwiki/SafeConcurrent#SampleVar

-- 
Chris

From felipe.lessa at gmail.com  Sun Apr 12 11:17:33 2009
From: felipe.lessa at gmail.com (Felipe Lessa)
Date: Sun Apr 12 11:04:26 2009
Subject: Broken beyond repair: Control.Concurrent.SampleVar
In-Reply-To: <49E1DC24.1070506@list.mightyreason.com>
References: <49E1DC24.1070506@list.mightyreason.com>
Message-ID: <20090412151733.GA10822@kira.casa>

Why not

> import Control.Applicative
> import Control.Concurrent.MVar
> import Control.Exception
>
> data SampleVar a = SV {svLock :: MVar (),
>                        svData :: MVar a}
>
> newEmptySampleVar :: IO (SampleVar a)
> newEmptySampleVar = SV <$> newMVar () <$> newEmptyMVar
>
> newSampleVar :: a -> IO (SampleVar a)
> newSampleVar x = SV <$> newMVar () <$> newMVar x
>
> emptySampleVar :: SampleVar a -> IO ()
> emptySampleVar = (>> return ()) . tryTakeMVar . svData
>
> readSampleVar :: SampleVar a -> IO a
> readSampleVar = takeMVar . svData
>
> isEmptySampleVar :: SampleVar a -> IO Bool
> isEmptySampleVar = isEmptyMVar . svData
>
> writeSampleVar :: SampleVar a -> a -> IO ()
> writeSampleVar s x = block $ withMVar (svLock s) $ const $ do
>   tryTakeMVar (svData s)
>   putMVar (svData s) x

?

--
Felipe.
From felipe.lessa at gmail.com  Sun Apr 12 11:18:30 2009
From: felipe.lessa at gmail.com (Felipe Lessa)
Date: Sun Apr 12 11:05:11 2009
Subject: Broken beyond repair: Control.Concurrent.SampleVar
In-Reply-To: <20090412151733.GA10822@kira.casa>
References: <49E1DC24.1070506@list.mightyreason.com>
	<20090412151733.GA10822@kira.casa>
Message-ID: <20090412151830.GB10822@kira.casa>

On Sun, Apr 12, 2009 at 12:17:33PM -0300, Felipe Lessa wrote:
> Why not
[...]

Modulo the silly errors, of course. Haven't tried to typecheck :).

--
Felipe.
From haskell at list.mightyreason.com  Sun Apr 12 12:12:15 2009
From: haskell at list.mightyreason.com (Chris Kuklewicz)
Date: Sun Apr 12 11:58:53 2009
Subject: Broken beyond repair: Control.Concurrent.SampleVar
In-Reply-To: <20090412151733.GA10822@kira.casa>
References: <49E1DC24.1070506@list.mightyreason.com>
	<20090412151733.GA10822@kira.casa>
Message-ID: <49E212DF.6050605@list.mightyreason.com>

Felipe Lessa wrote:
>> writeSampleVar :: SampleVar a -> a -> IO ()
>> writeSampleVar s x = block $ withMVar (svLock s) $ const $ do
>>   tryTakeMVar (svData s)
>>   putMVar (svData s) x

That is obvious, but 'block $' is not atomic.

Threads 1 and 2 get past the tryTakeMVar.

Then thread 1 succeeds with putMVar and thread 2 blocks.

Thread 2 is not supposed to block, so this is a failure to agree with the
specification.

From felipe.lessa at gmail.com  Sun Apr 12 14:25:12 2009
From: felipe.lessa at gmail.com (Felipe Lessa)
Date: Sun Apr 12 14:11:52 2009
Subject: Broken beyond repair: Control.Concurrent.SampleVar
In-Reply-To: <49E212DF.6050605@list.mightyreason.com>
References: <49E1DC24.1070506@list.mightyreason.com>
	<20090412151733.GA10822@kira.casa>
	<49E212DF.6050605@list.mightyreason.com>
Message-ID: <20090412182512.GA21072@kira.casa>

On Sun, Apr 12, 2009 at 05:12:15PM +0100, Chris Kuklewicz wrote:
> Felipe Lessa wrote:
> >> writeSampleVar :: SampleVar a -> a -> IO ()
> >> writeSampleVar s x = block $ withMVar (svLock s) $ const $ do
> >>   tryTakeMVar (svData s)
> >>   putMVar (svData s) x
>
> That is obvious, but 'block $' is not atomic.
>
> Threads 1 and 2 get past the tryTakeMVar.

That's why there is a "withMVar (svLock s)", the "const $ do"
part is executed serially. It is impossible to have two threads
past the "tryTakeMVar".

> Then thread 1 succeeds with putMVar and thread 2 blocks.
>
> Thread 2 is not supposed to block, so this is a failure to agree with the
> specification.

Well, it doesn't block. In the worst case I can imagine a thread
could be killed after the 'tryTakeMVar', leaving the 'SampleVar'
empty, but I guess the 'block' would prevent that.

--
Felipe.
From haskell at list.mightyreason.com  Sun Apr 12 16:56:41 2009
From: haskell at list.mightyreason.com (Chris Kuklewicz)
Date: Sun Apr 12 16:43:19 2009
Subject: Broken beyond repair: Control.Concurrent.SampleVar
In-Reply-To: <20090412182512.GA21072@kira.casa>
References: <49E1DC24.1070506@list.mightyreason.com>
	<20090412151733.GA10822@kira.casa>
	<49E212DF.6050605@list.mightyreason.com>
	<20090412182512.GA21072@kira.casa>
Message-ID: <49E25589.2010106@list.mightyreason.com>

and I am dumb, sorry.  Yes, you are right.  In fact the code I had posted on the
wiki at http://haskell.org/haskellwiki/SafeConcurrent#SampleVar is

> writeSampleVar :: SampleVar a -> a -> IO ()
> writeSampleVar svar value = do
>   withMVar (lockedStore svar) $ \ store -> do
>     _ <- tryTakeMVar store
>     putMVar store value

which is functionally identical to yours.  I should not write so hastily on my
way out the door...


Felipe Lessa wrote:
> On Sun, Apr 12, 2009 at 05:12:15PM +0100, Chris Kuklewicz wrote:
>> Felipe Lessa wrote:
>>>> writeSampleVar :: SampleVar a -> a -> IO ()
>>>> writeSampleVar s x = block $ withMVar (svLock s) $ const $ do
>>>>   tryTakeMVar (svData s)
>>>>   putMVar (svData s) x
>> That is obvious, but 'block $' is not atomic.
>>
>> Threads 1 and 2 get past the tryTakeMVar.
> 
> That's why there is a "withMVar (svLock s)", the "const $ do"
> part is executed serially. It is impossible to have two threads
> past the "tryTakeMVar".
> 
>> Then thread 1 succeeds with putMVar and thread 2 blocks.
>>
>> Thread 2 is not supposed to block, so this is a failure to agree with the
>> specification.
> 
> Well, it doesn't block. In the worst case I can imagine a thread
> could be killed after the 'tryTakeMVar', leaving the 'SampleVar'
> empty, but I guess the 'block' would prevent that.
> 
> --
> Felipe.

From ml at isaac.cedarswampstudios.org  Sun Apr 12 17:23:20 2009
From: ml at isaac.cedarswampstudios.org (Isaac Dupree)
Date: Sun Apr 12 17:10:01 2009
Subject: Broken beyond repair: Control.Concurrent.SampleVar
In-Reply-To: <20090412151733.GA10822@kira.casa>
References: <49E1DC24.1070506@list.mightyreason.com>
	<20090412151733.GA10822@kira.casa>
Message-ID: <200904121723.20390.ml@isaac.cedarswampstudios.org>

Felipe Lessa wrote:
> > writeSampleVar :: SampleVar a -> a -> IO ()
> > writeSampleVar s x = block $ withMVar (svLock s) $ const $ do
> >   tryTakeMVar (svData s)
> >   putMVar (svData s) x

withMVar is a blocking operation, thus interruptible despite 'block', I 
believe... perhaps moving the block inward might more clearly specify what 
happens (and be *at least* as correct, maybe more correct?) :

writeSampleVar s x = withMVar (svLock s) $ const $ block $ do
   tryTakeMVar (svData s)  --nonblocking, thus not exception-interruptible
   putMVar (svData s) x  --because the lock is taken and the MVar emptied,
                           -- this is guaranteed to succeed and not to block

-Isaac

From ashley at semantic.org  Mon Apr 13 03:14:01 2009
From: ashley at semantic.org (Ashley Yakeley)
Date: Mon Apr 13 03:00:36 2009
Subject: Failure to install time package
In-Reply-To: <404396ef0904090958x1434a01di21fb2fcbf8154935@mail.gmail.com>
References: <404396ef0904071326t17c8dd57p333e553fef7e337f@mail.gmail.com>
	<404396ef0904090958x1434a01di21fb2fcbf8154935@mail.gmail.com>
Message-ID: <49E2E639.10104@semantic.org>

Neil Mitchell wrote:
> Hi
> 
> I have raised a ticket for this bug report:
> http://hackage.haskell.org/trac/ghc/ticket/3162
> 
> I consider this issue quite serious for Windows users. Time is an
> important library, Windows is an important platform, GHC is an
> important compiler - together we end up with a fairly important
> problem.

Unfortunately I don't have GHC set up for this particular platform. If 
you or anyone with a non-Cygwin Windows GHC installation could 
investigate this, that would be very helpful. If autotools aren't 
appropriate for such an environment, it's going to need another build 
system specific to that platform.

-- 
Ashley Yakeley
From haskell at list.mightyreason.com  Mon Apr 13 05:05:17 2009
From: haskell at list.mightyreason.com (Chris Kuklewicz)
Date: Mon Apr 13 04:51:52 2009
Subject: Broken beyond repair: Control.Concurrent.SampleVar
In-Reply-To: <200904121723.20390.ml@isaac.cedarswampstudios.org>
References: <49E1DC24.1070506@list.mightyreason.com>	<20090412151733.GA10822@kira.casa>
	<200904121723.20390.ml@isaac.cedarswampstudios.org>
Message-ID: <49E3004D.6080007@list.mightyreason.com>

Isaac Dupree wrote:
> Felipe Lessa wrote:
>>> writeSampleVar :: SampleVar a -> a -> IO ()
>>> writeSampleVar s x = block $ withMVar (svLock s) $ const $ do
>>>   tryTakeMVar (svData s)
>>>   putMVar (svData s) x
> 
> withMVar is a blocking operation, thus interruptible despite 'block', I 
> believe... perhaps moving the block inward might more clearly specify what 
> happens (and be *at least* as correct, maybe more correct?) :
> 
> writeSampleVar s x = withMVar (svLock s) $ const $ block $ do
>    tryTakeMVar (svData s)  --nonblocking, thus not exception-interruptible
>    putMVar (svData s) x  --because the lock is taken and the MVar emptied,
>                            -- this is guaranteed to succeed and not to block
> 

As far as I can see, I agree: "block" and "withMVar/modifyMVar/modifyMVar_"
mostly commute.  So it is largely a matter of taste.

mostly

mostly

By blocking second, you allow interruptions between withMVar succeeding and the
block taking effect.  Also, the user could potentially wrap the call in an outer
"block".

By putting block first: if the lock is contested then once the withMVar succeeds
the operation is guaranteed to commit; and if the lock is not contested the
whole operation inside block will always commit.  In point of fact, the error
handler set up by the withMVar is superfluous and tighter code be written
(though less clear)

My taste is the latter: by moving the "block" to the outermost level it makes
the code easier to reason about (good for designer) and it means the caller
never has to think about wrapping it an outer "block" (good for the user).

The tighter code version of
http://haskell.org/haskellwiki/SafeConcurrent#SampleVar :

>  writeSampleVar svar value = block $ do
>    store <- takeMVar (lockedStore svar)
>    _ <- tryTakeMVar store
>    putMVar store x
>    putMVar (lockedStore svar) store



-- 
Chris
From ganesh.sittampalam at credit-suisse.com  Mon Apr 13 10:24:30 2009
From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh)
Date: Mon Apr 13 10:11:39 2009
Subject: Failure to install time package
In-Reply-To: <49E2E639.10104@semantic.org>
References: <404396ef0904071326t17c8dd57p333e553fef7e337f@mail.gmail.com><404396ef0904090958x1434a01di21fb2fcbf8154935@mail.gmail.com>
	<49E2E639.10104@semantic.org>
Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B01ABAA1E@ELON17P32001A.csfb.cs-group.com>

Ashley Yakeley wrote:
> Neil Mitchell wrote:
>> Hi
>> 
>> I have raised a ticket for this bug report:
>> http://hackage.haskell.org/trac/ghc/ticket/3162
>> 
>> I consider this issue quite serious for Windows users. Time is an
>> important library, Windows is an important platform, GHC is an
>> important compiler - together we end up with a fairly important
>> problem.
> 
> Unfortunately I don't have GHC set up for this particular platform.
> If you or anyone with a non-Cygwin Windows GHC installation could
> investigate this, that would be very helpful. If autotools aren't
> appropriate for such an environment, it's going to need another build
> system specific to that platform.    

Configure scripts just don't work in that environment, so there's not 
much to investigate - either an alternative build system will have to be
found, or perhaps the output of configure can be pre-generated for this
platform?

Ganesh

=============================================================================== 
 Please access the attached hyperlink for an important electronic communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 =============================================================================== 
 
From lennart at augustsson.net  Mon Apr 13 12:30:57 2009
From: lennart at augustsson.net (Lennart Augustsson)
Date: Mon Apr 13 12:17:31 2009
Subject: Failure to install time package
In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B01ABAA1E@ELON17P32001A.csfb.cs-group.com>
References: <404396ef0904071326t17c8dd57p333e553fef7e337f@mail.gmail.com>
	<404396ef0904090958x1434a01di21fb2fcbf8154935@mail.gmail.com>
	<49E2E639.10104@semantic.org>
	<16442B752A06A74AB4D9F9A5FF076E4B01ABAA1E@ELON17P32001A.csfb.cs-group.com>
Message-ID: <f4876cd70904130930j1e13d88ai98845e86ca1c6a95@mail.gmail.com>

As Ganesh said, you can't rely on executing any kind of Unix command
or any kind of shell scripts.  Nor can you assume to have any
compiler, except ghc.
For LLVM I simply captured the configuration using MinGW, and then
made a custom build step that uses this information.

What you really, really want for windows is a binary install.  It's a
great shame the time package was not included in ghc 6.10.2 (since it
was included in earlier compiler distributions).  This broke things
for Windows users.


On Mon, Apr 13, 2009 at 4:24 PM, Sittampalam, Ganesh
<ganesh.sittampalam@credit-suisse.com> wrote:
> Ashley Yakeley wrote:
>> Neil Mitchell wrote:
>>> Hi
>>>
>>> I have raised a ticket for this bug report:
>>> http://hackage.haskell.org/trac/ghc/ticket/3162
>>>
>>> I consider this issue quite serious for Windows users. Time is an
>>> important library, Windows is an important platform, GHC is an
>>> important compiler - together we end up with a fairly important
>>> problem.
>>
>> Unfortunately I don't have GHC set up for this particular platform.
>> If you or anyone with a non-Cygwin Windows GHC installation could
>> investigate this, that would be very helpful. If autotools aren't
>> appropriate for such an environment, it's going to need another build
>> system specific to that platform.
>
> Configure scripts just don't work in that environment, so there's not
> much to investigate - either an alternative build system will have to be
> found, or perhaps the output of configure can be pre-generated for this
> platform?
>
> Ganesh
>
> ===============================================================================
> ?Please access the attached hyperlink for an important electronic communications disclaimer:
> ?http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
> ?===============================================================================
>
> _______________________________________________
> Libraries mailing list
> Libraries@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
From ashley at semantic.org  Mon Apr 13 14:10:36 2009
From: ashley at semantic.org (Ashley Yakeley)
Date: Mon Apr 13 13:57:15 2009
Subject: Failure to install time package
In-Reply-To: <f4876cd70904130930j1e13d88ai98845e86ca1c6a95@mail.gmail.com>
References: <404396ef0904071326t17c8dd57p333e553fef7e337f@mail.gmail.com>	<404396ef0904090958x1434a01di21fb2fcbf8154935@mail.gmail.com>	<49E2E639.10104@semantic.org>	<16442B752A06A74AB4D9F9A5FF076E4B01ABAA1E@ELON17P32001A.csfb.cs-group.com>
	<f4876cd70904130930j1e13d88ai98845e86ca1c6a95@mail.gmail.com>
Message-ID: <49E3801C.2070203@semantic.org>

Lennart Augustsson wrote:
> As Ganesh said, you can't rely on executing any kind of Unix command
> or any kind of shell scripts.  Nor can you assume to have any
> compiler, except ghc.

Isn't there support for compiling C files in the Windows GHC installer?

-- 
Ashley Yakeley
From lennart at augustsson.net  Mon Apr 13 15:00:32 2009
From: lennart at augustsson.net (Lennart Augustsson)
Date: Mon Apr 13 14:47:04 2009
Subject: Failure to install time package
In-Reply-To: <49E3801C.2070203@semantic.org>
References: <404396ef0904071326t17c8dd57p333e553fef7e337f@mail.gmail.com>
	<404396ef0904090958x1434a01di21fb2fcbf8154935@mail.gmail.com>
	<49E2E639.10104@semantic.org>
	<16442B752A06A74AB4D9F9A5FF076E4B01ABAA1E@ELON17P32001A.csfb.cs-group.com>
	<f4876cd70904130930j1e13d88ai98845e86ca1c6a95@mail.gmail.com>
	<49E3801C.2070203@semantic.org>
Message-ID: <f4876cd70904131200k3a59ecb4wd01d079d8fea4c78@mail.gmail.com>

Yes, you can give .c files to ghc and it will compile them (using gcc).

On Mon, Apr 13, 2009 at 8:10 PM, Ashley Yakeley <ashley@semantic.org> wrote:
> Lennart Augustsson wrote:
>>
>> As Ganesh said, you can't rely on executing any kind of Unix command
>> or any kind of shell scripts. ?Nor can you assume to have any
>> compiler, except ghc.
>
> Isn't there support for compiling C files in the Windows GHC installer?
>
> --
> Ashley Yakeley
>
From ashley at semantic.org  Mon Apr 13 17:47:18 2009
From: ashley at semantic.org (Ashley Yakeley)
Date: Mon Apr 13 17:33:57 2009
Subject: Failure to install time package
In-Reply-To: <f4876cd70904131200k3a59ecb4wd01d079d8fea4c78@mail.gmail.com>
References: <404396ef0904071326t17c8dd57p333e553fef7e337f@mail.gmail.com>	<404396ef0904090958x1434a01di21fb2fcbf8154935@mail.gmail.com>	<49E2E639.10104@semantic.org>	<16442B752A06A74AB4D9F9A5FF076E4B01ABAA1E@ELON17P32001A.csfb.cs-group.com>	<f4876cd70904130930j1e13d88ai98845e86ca1c6a95@mail.gmail.com>	<49E3801C.2070203@semantic.org>
	<f4876cd70904131200k3a59ecb4wd01d079d8fea4c78@mail.gmail.com>
Message-ID: <49E3B2E6.6010405@semantic.org>

Lennart Augustsson wrote:
> Yes, you can give .c files to ghc and it will compile them (using gcc).

OK. The C file is mentioned in the Cabal file. Very likely the package 
will build with "build-type: Simple" on Windows. It needs autoconf only 
to figure out which C time functions are available on UNIX systems.

-- 
Ashley Yakeley
From manlio.perillo at gmail.com  Tue Apr 14 09:20:45 2009
From: manlio.perillo at gmail.com (Manlio Perillo)
Date: Tue Apr 14 09:07:41 2009
Subject: strict version of operations on IntMap and IntSet
Message-ID: <49E48DAD.4040804@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi.

- From a discussion I had some time ago on haskell-cafe, it seems that all
operations on IntMap and IntSet are lazy.

The only exception is `alter`, for IntMap.

This can be a problem.
As an example, using `fromList` (both from IntMap and IntSet) seems to
be rather unfriendly to the garbage collector.


Is it possible to have strict variants of the most common operations?


Thanks  Manlio Perillo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknkja0ACgkQscQJ24LbaUThzACffL9JTJv9LqmdZIEJeY9EFobT
tZgAnitfwGvaHM+kpOEHX8/mNtnYGVsF
=E7+2
-----END PGP SIGNATURE-----
From claus.reinke at talk21.com  Wed Apr 15 16:36:18 2009
From: claus.reinke at talk21.com (Claus Reinke)
Date: Wed Apr 15 16:23:03 2009
Subject: Failure to install time package
References: <404396ef0904071326t17c8dd57p333e553fef7e337f@mail.gmail.com><404396ef0904090958x1434a01di21fb2fcbf8154935@mail.gmail.com><49E2E639.10104@semantic.org><16442B752A06A74AB4D9F9A5FF076E4B01ABAA1E@ELON17P32001A.csfb.cs-group.com>
	<f4876cd70904130930j1e13d88ai98845e86ca1c6a95@mail.gmail.com>
Message-ID: <gs5gg6$6r7$1@ger.gmane.org>

|As Ganesh said, you can't rely on executing any kind of Unix command
|or any kind of shell scripts.  Nor can you assume to have any
|compiler, except ghc.
|For LLVM I simply captured the configuration using MinGW, and then
|made a custom build step that uses this information.
|
|What you really, really want for windows is a binary install.  It's a
|great shame the time package was not included in ghc 6.10.2 (since it
|was included in earlier compiler distributions).  This broke things
|for Windows users.

Simon recently collected all the pieces needed for GHC builds on
windows, so -in principle- someone could make a cabal package
that downloads and installs these pieces in their default location

http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows

and then cabal could implicitly depend on that package if seeing
a package using 'build-type: configure' on Windows. That would
solve this particular issue for all cabal packages. And once GHC
becomes able to use a standard MinGW layout

http://hackage.haskell.org/trac/ghc/ticket/1502

it could also depend on such a tools package.

That is assuming the licenses are favourable for redistribution,
and the installers can be run from the commandline.

Claus

PS. of course, unnecessary dependencies aren't necessary;-)

On Mon, Apr 13, 2009 at 4:24 PM, Sittampalam, Ganesh
<ganesh.sittampalam@credit-suisse.com> wrote:
> Ashley Yakeley wrote:
>> Neil Mitchell wrote:
>>> Hi
>>>
>>> I have raised a ticket for this bug report:
>>> http://hackage.haskell.org/trac/ghc/ticket/3162
>>>
>>> I consider this issue quite serious for Windows users. Time is an
>>> important library, Windows is an important platform, GHC is an
>>> important compiler - together we end up with a fairly important
>>> problem.
>>
>> Unfortunately I don't have GHC set up for this particular platform.
>> If you or anyone with a non-Cygwin Windows GHC installation could
>> investigate this, that would be very helpful. If autotools aren't
>> appropriate for such an environment, it's going to need another build
>> system specific to that platform.
>
> Configure scripts just don't work in that environment, so there's not
> much to investigate - either an alternative build system will have to be
> found, or perhaps the output of configure can be pre-generated for this
> platform?
>
> Ganesh
>
> ===============================================================================
> Please access the attached hyperlink for an important electronic communications disclaimer:
> http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
> ===============================================================================
>
> _______________________________________________
> Libraries mailing list
> Libraries@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
> 



From duncan.coutts at worc.ox.ac.uk  Thu Apr 16 04:46:38 2009
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Thu Apr 16 04:33:04 2009
Subject: cabal: confusing dependencies conflict between ghc-6.10.1 and
	process
In-Reply-To: <49D5DD5A.40602@van.steenbergen.nl>
References: <00D7B66A-BDE4-4870-860F-6B706567CDA1@informatik.uni-kiel.de>
	<49D5DD5A.40602@van.steenbergen.nl>
Message-ID: <1239871598.6315.14.camel@lantern>

On Fri, 2009-04-03 at 11:56 +0200, Martijn van Steenbergen wrote:
> Hi Sebastian,
> 
> Sebastian Fischer wrote:
> > There is something wrong: according to this message, the package 
> > ghc-6.10.1 requires both process==1.0.1.1 and process==1.0.1.0.
> 
> Please see Duncan's email [1].

For future reference this is now in the new Cabal FAQ:
http://haskell.org/cabal/FAQ.html

which is now linked from the cabal home page.


Duncan

From lennart at augustsson.net  Thu Apr 16 05:24:59 2009
From: lennart at augustsson.net (Lennart Augustsson)
Date: Thu Apr 16 05:11:43 2009
Subject: Failure to install time package
In-Reply-To: <404396ef0904071326t17c8dd57p333e553fef7e337f@mail.gmail.com>
References: <404396ef0904071326t17c8dd57p333e553fef7e337f@mail.gmail.com>
Message-ID: <f4876cd70904160224o4f19f182we38c3ec261b1cec5@mail.gmail.com>

Another word of warning about the time library.
If one builds and installs it using cygwin it will detect that the
localtime_r() function exists, but the actual linking is against MinGW
libraries where it does not exists, so it will fail.
The package must be build using MinGW.

Of course, had the time package not been rudely removed from ghc
6.10.2 this would not have been a problem.

Does anyone have a server where I could put an alternate 6.10.2 binary
distribution for Windows?
One that includes the time package and cabal.exe.

  -- Lennart

On Tue, Apr 7, 2009 at 10:26 PM, Neil Mitchell <ndmitchell@gmail.com> wrote:
> Hi,
>
> Time is an important library, it got unbundled from GHC, and it seems
> Windows users can't install the time package!
>
> C:\Neil\hoogle>cabal install time --global
> Resolving dependencies...
> [1 of 1] Compiling Main ? ? ? ? ? ? ( C:\Users\Neil\AppData\Local\Temp\time-1.1.
> 2.32884\time-1.1.2.3\Setup.hs, C:\Users\Neil\AppData\Local\Temp\time-1.1.2.32884
> \time-1.1.2.3\dist\setup\Main.o )
> Linking C:\Users\Neil\AppData\Local\Temp\time-1.1.2.32884\time-1.1.2.3\dist\setu
> p\setup.exe ...
> Configuring time-1.1.2.3...
> setup.exe: sh: runGenProcess: does not exist (No such file or directory)
> cabal: Error: some packages failed to install:
> time-1.1.2.3 failed during the configure step. The exception was:
> exit: ExitFailure 1
>
> C:\Neil\hoogle>ghc --version
> The Glorious Glasgow Haskell Compilation System, version 6.10.2
>
> My guess is that it would work if I installed mingw, but that it
> hasn't been tested without. I consider this problem fatally serious -
> we may have managed to make GHC 6.10.2 unuseable for many Windows
> users...
>
> Thanks
>
> Neil
> _______________________________________________
> Libraries mailing list
> Libraries@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
From simonpj at microsoft.com  Thu Apr 16 05:32:57 2009
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Thu Apr 16 05:19:48 2009
Subject: Failure to install time package
In-Reply-To: <f4876cd70904160224o4f19f182we38c3ec261b1cec5@mail.gmail.com>
References: <404396ef0904071326t17c8dd57p333e553fef7e337f@mail.gmail.com>
	<f4876cd70904160224o4f19f182we38c3ec261b1cec5@mail.gmail.com>
Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33751DDC010@EA-EXMSG-C334.europe.corp.microsoft.com>

| Of course, had the time package not been rudely removed from ghc
| 6.10.2 this would not have been a problem.

I talked to Ian about this yesterday.  I agree it was rude to remove it in a patch-level release.

We hope that someone at this weekend's will put up a binary distribution of 'time' for GHC 6.10.2.  If they don't, we'll re-roll the 6.10.2 bundle (on Windows only) including time again, so that you can re-download.

We are trying hard to get out of the library distribution business, in favour of the Haskell Platform, for which there should be binary installers.  I very very very much hope that the HP is firmly online by the time we get to 6.12.

Simon
From lennart at augustsson.net  Thu Apr 16 05:39:45 2009
From: lennart at augustsson.net (Lennart Augustsson)
Date: Thu Apr 16 05:26:09 2009
Subject: Failure to install time package
In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33751DDC010@EA-EXMSG-C334.europe.corp.microsoft.com>
References: <404396ef0904071326t17c8dd57p333e553fef7e337f@mail.gmail.com>
	<f4876cd70904160224o4f19f182we38c3ec261b1cec5@mail.gmail.com>
	<638ABD0A29C8884A91BC5FB5C349B1C33751DDC010@EA-EXMSG-C334.europe.corp.microsoft.com>
Message-ID: <f4876cd70904160239gc3fe59apd91b91b5cffd47a3@mail.gmail.com>

I very much hope that HP will be here soon too.  I understand that you
don't want to be in the library distribution business, but since you
started down that road you are stuck with it until there's a viable
replacement.

  -- Lennart

On Thu, Apr 16, 2009 at 11:32 AM, Simon Peyton-Jones
<simonpj@microsoft.com> wrote:
> | Of course, had the time package not been rudely removed from ghc
> | 6.10.2 this would not have been a problem.
>
> I talked to Ian about this yesterday. ?I agree it was rude to remove it in a patch-level release.
>
> We hope that someone at this weekend's will put up a binary distribution of 'time' for GHC 6.10.2. ?If they don't, we'll re-roll the 6.10.2 bundle (on Windows only) including time again, so that you can re-download.
>
> We are trying hard to get out of the library distribution business, in favour of the Haskell Platform, for which there should be binary installers. ?I very very very much hope that the HP is firmly online by the time we get to 6.12.
>
> Simon
>
From bulat.ziganshin at gmail.com  Thu Apr 16 06:07:09 2009
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Thu Apr 16 05:53:41 2009
Subject: Failure to install time package
In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33751DDC010@EA-EXMSG-C334.europe.corp.microsoft.com>
References: <404396ef0904071326t17c8dd57p333e553fef7e337f@mail.gmail.com>
	<f4876cd70904160224o4f19f182we38c3ec261b1cec5@mail.gmail.com>
	<638ABD0A29C8884A91BC5FB5C349B1C33751DDC010@EA-EXMSG-C334.europe.corp.microsoft.com>
Message-ID: <1856249825.20090416140709@gmail.com>

Hello Simon,

Thursday, April 16, 2009, 1:32:57 PM, you wrote:

> We hope that someone at this weekend's will put up a binary
> distribution of 'time' for GHC 6.10.2.  If they don't, we'll re-roll
> the 6.10.2 bundle (on Windows only) including time again, so that you can re-download.

Simon, this solves only part of the problems, especially second
variant. imagine 6.10.2 versions flying around with and without time
package.

i think that most reliable way to solve it is to issue 6.10.3 ASAP
with just one change - this package returned back. this means a lot of
extra work for packagers but will greatly simplify further life for
users


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From lennart at augustsson.net  Thu Apr 16 06:18:04 2009
From: lennart at augustsson.net (Lennart Augustsson)
Date: Thu Apr 16 06:04:29 2009
Subject: Failure to install time package
In-Reply-To: <1856249825.20090416140709@gmail.com>
References: <404396ef0904071326t17c8dd57p333e553fef7e337f@mail.gmail.com>
	<f4876cd70904160224o4f19f182we38c3ec261b1cec5@mail.gmail.com>
	<638ABD0A29C8884A91BC5FB5C349B1C33751DDC010@EA-EXMSG-C334.europe.corp.microsoft.com>
	<1856249825.20090416140709@gmail.com>
Message-ID: <f4876cd70904160318l510fbef6j5f9f4fd149a52e2d@mail.gmail.com>

I agree with Bulat.  Having two different versions of 6.10.2 in
circulation is bad.
You could call it 6.10.2.1 if 6.10.3 is offensive.

  -- Lennart

On Thu, Apr 16, 2009 at 12:07 PM, Bulat Ziganshin
<bulat.ziganshin@gmail.com> wrote:
> Hello Simon,
>
> Thursday, April 16, 2009, 1:32:57 PM, you wrote:
>
>> We hope that someone at this weekend's will put up a binary
>> distribution of 'time' for GHC 6.10.2. ?If they don't, we'll re-roll
>> the 6.10.2 bundle (on Windows only) including time again, so that you can re-download.
>
> Simon, this solves only part of the problems, especially second
> variant. imagine 6.10.2 versions flying around with and without time
> package.
>
> i think that most reliable way to solve it is to issue 6.10.3 ASAP
> with just one change - this package returned back. this means a lot of
> extra work for packagers but will greatly simplify further life for
> users
>
>
> --
> Best regards,
> ?Bulat ? ? ? ? ? ? ? ? ? ? ? ? ? ?mailto:Bulat.Ziganshin@gmail.com
>
From bulat.ziganshin at gmail.com  Thu Apr 16 06:48:39 2009
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Thu Apr 16 06:35:21 2009
Subject: Failure to install time package
In-Reply-To: <f4876cd70904160318l510fbef6j5f9f4fd149a52e2d@mail.gmail.com>
References: <404396ef0904071326t17c8dd57p333e553fef7e337f@mail.gmail.com>
	<f4876cd70904160224o4f19f182we38c3ec261b1cec5@mail.gmail.com>
	<638ABD0A29C8884A91BC5FB5C349B1C33751DDC010@EA-EXMSG-C334.europe.corp.microsoft.com>
	<1856249825.20090416140709@gmail.com>
	<f4876cd70904160318l510fbef6j5f9f4fd149a52e2d@mail.gmail.com>
Message-ID: <782413046.20090416144839@gmail.com>

Hello Lennart,

Thursday, April 16, 2009, 2:18:04 PM, you wrote:

6.10.2.1 will also make some things worse. every other (release)
version is x.y.z and both people and software may have troubles
dealing with non-standard version number

> I agree with Bulat.  Having two different versions of 6.10.2 in
> circulation is bad.
> You could call it 6.10.2.1 if 6.10.3 is offensive.

>   -- Lennart

> On Thu, Apr 16, 2009 at 12:07 PM, Bulat Ziganshin
> <bulat.ziganshin@gmail.com> wrote:
>> Hello Simon,
>>
>> Thursday, April 16, 2009, 1:32:57 PM, you wrote:
>>
>>> We hope that someone at this weekend's will put up a binary
>>> distribution of 'time' for GHC 6.10.2. ?If they don't, we'll re-roll
>>> the 6.10.2 bundle (on Windows only) including time again, so that you can re-download.
>>
>> Simon, this solves only part of the problems, especially second
>> variant. imagine 6.10.2 versions flying around with and without time
>> package.
>>
>> i think that most reliable way to solve it is to issue 6.10.3 ASAP
>> with just one change - this package returned back. this means a lot of
>> extra work for packagers but will greatly simplify further life for
>> users
>>
>>
>> --
>> Best regards,
>> ?Bulat ? ? ? ? ? ? ? ? ? ? ? ? ? ?mailto:Bulat.Ziganshin@gmail.com
>>



-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From duncan.coutts at worc.ox.ac.uk  Thu Apr 16 08:12:15 2009
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Thu Apr 16 07:58:40 2009
Subject: cabal: confusing dependencies conflict between ghc-6.10.1 and
	process
In-Reply-To: <49E6F1DB.3020907@van.steenbergen.nl>
References: <00D7B66A-BDE4-4870-860F-6B706567CDA1@informatik.uni-kiel.de>
	<49D5DD5A.40602@van.steenbergen.nl> <1239871598.6315.14.camel@lantern>
	<49E6F1DB.3020907@van.steenbergen.nl>
Message-ID: <1239883935.6315.36.camel@lantern>

On Thu, 2009-04-16 at 10:52 +0200, Martijn van Steenbergen wrote:
> Duncan Coutts wrote:
> > For future reference this is now in the new Cabal FAQ:
> > http://haskell.org/cabal/FAQ.html
> > 
> > which is now linked from the cabal home page.
> 
> Neat. That's gonna be helpful.
> 
> "The default version of the parsec package is version 2.x."
> 
> Is parsec special in this regard?

Only slightly special:

http://hackage.haskell.org/packages/archive/preferred-versions

-- A global set of preferred versions.
--
-- This is to indicate a current recommended version, to allow stable and
-- experimental versions to co-exist on hackage and to help transitions
-- between major API versions.
--
-- Tools like cabal-install take these preferences into account when 
-- constructing install plans.
--
base < 4
parsec < 3
HaXml == 1.13.*
QuickCheck < 2


Duncan

From claus.reinke at talk21.com  Thu Apr 16 11:53:28 2009
From: claus.reinke at talk21.com (Claus Reinke)
Date: Thu Apr 16 11:40:05 2009
Subject: Failure to install time package
References: <404396ef0904071326t17c8dd57p333e553fef7e337f@mail.gmail.com>
	<f4876cd70904160224o4f19f182we38c3ec261b1cec5@mail.gmail.com>
Message-ID: <gs7k9p$na6$1@ger.gmane.org>

|Another word of warning about the time library.
|If one builds and installs it using cygwin it will detect that the
|localtime_r() function exists, but the actual linking is against MinGW
|libraries where it does not exists, so it will fail.
|The package must be build using MinGW.

A similar thing happened with GLUT/OpenGL, when they were
dropped. For them, the workaround is to pass the --host option
for configure (which used to come via the in-GHC-tree build system).
Perhaps that would work for time as well, since it used to build using
cygwin.

There might be other fallout, eg people have run into other
configuration settings not being passed correctly when GLUT
is installed in isolation, and without a separate MinGW (not
finding includes in GHC's internal MinGW tree, usually).

Claus

>From the script I use to reinstall packages after rebuilding ghc head:

#!/bin/sh
CMD=${CMD:-"install"}
CABAL="cabal $CMD $OPTION"
$CABAL ghc-paths
$CABAL ghc-syb
$CABAL ghood
$CABAL opengl --configure-option="--host=i386-unknown-mingw32"
$CABAL glut --configure-option="--host=i386-unknown-mingw32"
$CABAL mersenne-random-pure64
$CABAL uvector
$CABAL vector




From ashley at semantic.org  Fri Apr 17 04:10:16 2009
From: ashley at semantic.org (Ashley Yakeley)
Date: Fri Apr 17 03:57:00 2009
Subject: ANN: time 1.1.2.4
Message-ID: <gs9dh9$a81$1@ger.gmane.org>

time 1.1.2.4 is available on Hackage.

This version of time should compile on Windows. It's been tested on a 
Vista machine that didn't have cygwin, just the standard GHC install.

No other changes have been made.

From duncan.coutts at worc.ox.ac.uk  Fri Apr 17 12:12:56 2009
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Fri Apr 17 11:59:18 2009
Subject: ANN: time 1.1.2.4
In-Reply-To: <gs9dh9$a81$1@ger.gmane.org>
References: <gs9dh9$a81$1@ger.gmane.org>
Message-ID: <1239984776.6315.64.camel@lantern>

On Fri, 2009-04-17 at 01:10 -0700, Ashley Yakeley wrote:
> time 1.1.2.4 is available on Hackage.
> 
> This version of time should compile on Windows. It's been tested on a 
> Vista machine that didn't have cygwin, just the standard GHC install.
> 
> No other changes have been made.

We will include this version in the first platform release.

Duncan

From sanzhiyan at gmail.com  Fri Apr 17 12:50:00 2009
From: sanzhiyan at gmail.com (Andrea Vezzosi)
Date: Fri Apr 17 12:36:22 2009
Subject: unix-2.3.2.0 fails to install in ghc 6.10.1
In-Reply-To: <grk05m$h98$1@ger.gmane.org>
References: <grk05m$h98$1@ger.gmane.org>
Message-ID: <8625cd9c0904170950u553d58cas3d3c1c07886215fe@mail.gmail.com>

you can't upgrade to that version of unix under ghc-6.10.1.
cabal-install couldn't tell that at configure because of this bug:
http://hackage.haskell.org/trac/ghc/ticket/3142

2009/4/9 Ahn, Ki Yung <kyagrd@gmail.com>:
> kyagrd@kyagrd:~$ uname -a
> Linux kyagrd 2.6.26-1-686 #1 SMP Sat Jan 10 18:29:31 UTC 2009 i686 GNU/Linux
>
> kyagrd@kyagrd:~$ ghc --version
> The Glorious Glasgow Haskell Compilation System, version 6.10.1
>
> kyagrd@kyagrd:~$ which ghc
> /usr/bin/ghc
>
> kyagrd@kyagrd:~$ ghc-pkg list
> /usr/lib/ghc-6.10.1/./package.conf:
> ? ?ALUT-2.1.0.0, Cabal-1.6.0.1, Diff-0.1.2, GLUT-2.1.1.2, HDBC-2.1.0,
> ? ?HDBC-postgresql-2.1.0.1, HGL-3.2.0.0, HUnit-1.2.0.3,
> ? ?OpenAL-1.3.1.1, OpenGL-2.2.1.1, QuickCheck-2.1.0.1, Stream-0.2.2,
> ? ?X11-1.4.5, X11-xft-0.3, array-0.2.0.0, arrows-0.4.1, base-3.0.3.0,
> ? ?base-4.0.0.0, binary-0.5, bytestring-0.9.1.4, cairo-0.10.0,
> ? ?cgi-3001.1.7.1, containers-0.2.0.0, convertible-1.0.2,
> ? ?directory-1.0.0.2, editline-0.2.1.0, fgl-5.4.2.2, filepath-1.1.0.1,
> ? ?gconf-0.10.0, (ghc-6.10.1), ghc-prim-0.1.0.0, gio-0.10.0,
> ? ?glade-0.10.0, glib-0.10.0, gstreamer-0.10.0, gtk-0.10.0,
> ? ?gtkglext-0.10.0, gtksourceview2-0.10.0, haskell-src-1.0.1.3,
> ? ?haskell98-1.0.1.0, hpc-0.5.0.2, hslogger-1.0.8, html-1.0.1.2,
> ? ?integer-0.1.0.0, irc-0.4.3, mtl-1.1.0.2, network-2.2.0.1,
> ? ?old-locale-1.0.0.1, old-time-1.0.0.1, packedstring-0.1.0.1,
> ? ?parallel-1.1.0.0, parsec-3.0.0, pretty-1.0.1.0, process-1.0.1.0,
> ? ?random-1.0.0.1, regex-base-0.93.1, regex-compat-0.92,
> ? ?regex-posix-0.93.1, rts-1.0, soegtk-0.10.0, stm-2.1.1.2,
> ? ?svgcairo-0.10.0, syb-0.1.0.0, syb-with-class-0.5.1, tagsoup-0.6,
> ? ?template-haskell-2.3.0.0, terminfo-0.3.0.1, time-1.1.2.3,
> ? ?unix-2.3.1.0, utf8-string-0.3.4, xhtml-3000.2.0.1, xmonad-0.8.1,
> ? ?xmonad-contrib-0.8.1, zlib-0.5.0.0
> /home/kyagrd/.ghc/i386-linux-6.10.1/package.conf:
> ? ?Cabal-1.6.0.1, Cabal-1.6.0.2, HGL-3.2.0.0, HTTP-3001.1.3,
> ? ?HTTP-4000.0.4, HTTP-4000.0.5, InfixApplicative-1.0.1,
> ? ?QuickCheck-1.2.0.0, Stream-0.3.1, arrows-0.4.1, binary-0.5.0.1,
> ? ?cgi-3001.1.7.1, extensible-exceptions-0.1.1.0, filepath-1.1.0.2,
> ? ?ghc-paths-0.1.0.5, haddock-2.4.1, haskell98-1.0.1.0, irc-0.4.3,
> ? ?lazysmallcheck-0.3, network-2.2.0.1, network-2.2.1,
> ? ?old-time-1.0.0.2, parsec-2.1.0.1, process-1.0.1.1, random-1.0.0.1,
> ? ?sparsebit-0.5, terminfo-0.3.0.2, zlib-0.4.0.4, zlib-0.5.0.0
>
> kyagrd@kyagrd:~$ cabal upgrade unix
> Resolving dependencies...
> Configuring unix-2.3.2.0...
> checking for gcc... gcc
> checking for C compiler default output file name... a.out
> checking whether the C compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables...
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking how to run the C preprocessor... gcc -E
> checking for grep that handles long lines and -e... /bin/grep
> checking for egrep... /bin/grep -E
> checking for ANSI C header files... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking dlfcn.h usability... yes
> checking dlfcn.h presence... yes
> checking for dlfcn.h... yes
> checking for an ANSI C-conforming const... yes
> checking for special C compiler options needed for large files... no
> checking for _FILE_OFFSET_BITS value needed for large files... 64
> checking dirent.h usability... yes
> checking dirent.h presence... yes
> checking for dirent.h... yes
> checking fcntl.h usability... yes
> checking fcntl.h presence... yes
> checking for fcntl.h... yes
> checking grp.h usability... yes
> checking grp.h presence... yes
> checking for grp.h... yes
> checking limits.h usability... yes
> checking limits.h presence... yes
> checking for limits.h... yes
> checking pwd.h usability... yes
> checking pwd.h presence... yes
> checking for pwd.h... yes
> checking signal.h usability... yes
> checking signal.h presence... yes
> checking for signal.h... yes
> checking for string.h... (cached) yes
> checking sys/resource.h usability... yes
> checking sys/resource.h presence... yes
> checking for sys/resource.h... yes
> checking sys/times.h presence... yes
> checking for sys/times.h... yes
> checking sys/time.h usability... yes
> checking sys/time.h presence... yes
> checking for sys/time.h... yes
> checking sys/utsname.h usability... yes
> checking sys/utsname.h presence... yes
> checking for sys/utsname.h... yes
> checking sys/wait.h usability... yes
> checking sys/wait.h presence... yes
> checking for sys/wait.h... yes
> checking libutil.h usability... no
> checking libutil.h presence... no
> checking for libutil.h... no
> checking pty.h usability... yes
> checking pty.h presence... yes
> checking for pty.h... yes
> checking utmp.h usability... yes
> checking utmp.h presence... yes
> checking for utmp.h... yes
> checking termios.h usability... yes
> checking termios.h presence... yes
> checking for termios.h... yes
> checking time.h usability... yes
> checking time.h presence... yes
> checking for time.h... yes
> checking for unistd.h... (cached) yes
> checking utime.h usability... yes
> checking utime.h presence... yes
> checking for utime.h... yes
> checking for getgrgid_r... yes
> checking for getgrnam_r... yes
> checking for getpwnam_r... yes
> checking for getpwuid_r... yes
> checking for getpwnam... yes
> checking for getpwuid... yes
> checking for getpwent... yes
> checking for getgrent... yes
> checking for lchown... yes
> checking for setenv... yes
> checking for sysconf... yes
> checking for unsetenv... yes
> checking for nanosleep... yes
> checking for ptsname... yes
> checking for setitimer... yes
> checking for shm_open in -lrt... yes
> checking for shm_open... yes
> checking for shm_unlink... yes
> checking value of SIGABRT... 6
> checking value of SIGALRM... 14
> checking value of SIGBUS... 7
> checking value of SIGCHLD... 17
> checking value of SIGCONT... 18
> checking value of SIGFPE... 8
> checking value of SIGHUP... 1
> checking value of SIGILL... 4
> checking value of SIGINT... 2
> checking value of SIGKILL... 9
> checking value of SIGPIPE... 13
> checking value of SIGQUIT... 3
> checking value of SIGSEGV... 11
> checking value of SIGSTOP... 19
> checking value of SIGTERM... 15
> checking value of SIGTSTP... 20
> checking value of SIGTTIN... 21
> checking value of SIGTTOU... 22
> checking value of SIGUSR1... 10
> checking value of SIGUSR2... 12
> checking value of SIGPOLL... 29
> checking value of SIGPROF... 27
> checking value of SIGSYS... 31
> checking value of SIGTRAP... 5
> checking value of SIGURG... 23
> checking value of SIGVTALRM... 26
> checking value of SIGXCPU... 24
> checking value of SIGXFSZ... 25
> checking value of SIG_BLOCK... 0
> checking value of SIG_SETMASK... 2
> checking value of SIG_UNBLOCK... 1
> checking for _SC_GETGR_R_SIZE_MAX... yes
> checking for _SC_GETPW_R_SIZE_MAX... yes
> checking return type of usleep... int
> checking return type of unsetenv... int
> checking for RTLD_NEXT from dlfcn.h... no
> checking for RTLD_DEFAULT from dlfcn.h... no
> checking for RTLD_LOCAL from dlfcn.h... yes
> checking for RTLD_GLOBAL from dlfcn.h... yes
> checking for RTLD_NOW from dlfcn.h... yes
> checking for openpty... no
> checking for openpty in -lutil... yes
> checking for /dev/ptmx... yes
> checking for /dev/ptc... no
> checking for dlopen in -ldl... yes
> checking build system type... i686-pc-linux-gnu
> checking host system type... i686-pc-linux-gnu
> checking target system type... i686-pc-linux-gnu
> configure: creating ./config.status
> config.status: creating unix.buildinfo
> config.status: creating include/HsUnixConfig.h
> Preprocessing library unix-2.3.2.0...
> Building unix-2.3.2.0...
> [ 1 of 21] Compiling System.Posix.User (
> dist/build/System/Posix/User.hs, dist/build/System/Posix/User.o )
> [ 2 of 21] Compiling System.Posix.Unistd (
> dist/build/System/Posix/Unistd.hs, dist/build/System/Posix/Unistd.o )
> [ 3 of 21] Compiling System.Posix.Time (
> dist/build/System/Posix/Time.hs, dist/build/System/Posix/Time.o )
> [ 4 of 21] Compiling System.Posix.Resource (
> dist/build/System/Posix/Resource.hs, dist/build/System/Posix/Resource.o )
> [ 5 of 21] Compiling System.Posix.Process.Internals (
> System/Posix/Process/Internals.hs,
> dist/build/System/Posix/Process/Internals.o )
>
> System/Posix/Process/Internals.hs:10:17:
> ? ?Module `GHC.Conc' does not export `Signal'
> cabal: Error: some packages failed to install:
> unix-2.3.2.0 failed during the building phase. The exception was:
> exit: ExitFailure 1
>
> _______________________________________________
> Libraries mailing list
> Libraries@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
From bjorn.buckwalter at gmail.com  Fri Apr 17 13:03:35 2009
From: bjorn.buckwalter at gmail.com (Bjorn Buckwalter)
Date: Fri Apr 17 12:50:14 2009
Subject: ANN: time 1.1.2.4
References: <gs9dh9$a81$1@ger.gmane.org>
Message-ID: <loom.20090417T165814-259@post.gmane.org>

Ashley Yakeley <ashley <at> semantic.org> writes:
 
> time 1.1.2.4 is available on Hackage.
> 
> This version of time should compile on Windows. It's been tested on a 
> Vista machine that didn't have cygwin, just the standard GHC install.
> 
> No other changes have been made.

Actually, parsing is now case-insensitive (e.g. month and timezone names). 
Also, 'Day' is an instance of 'Ix'.

Thanks,
Bjorn





From ashley at semantic.org  Fri Apr 17 14:55:51 2009
From: ashley at semantic.org (Ashley Yakeley)
Date: Fri Apr 17 14:42:19 2009
Subject: ANN: time 1.1.2.4
In-Reply-To: <loom.20090417T165814-259@post.gmane.org>
References: <gs9dh9$a81$1@ger.gmane.org>
	<loom.20090417T165814-259@post.gmane.org>
Message-ID: <49E8D0B7.3010405@semantic.org>

Bjorn Buckwalter wrote:
> Ashley Yakeley <ashley <at> semantic.org> writes:
>  
>> time 1.1.2.4 is available on Hackage.
>>
>> This version of time should compile on Windows. It's been tested on a 
>> Vista machine that didn't have cygwin, just the standard GHC install.
>>
>> No other changes have been made.
> 
> Actually, parsing is now case-insensitive (e.g. month and timezone names). 
> Also, 'Day' is an instance of 'Ix'.

Oops. I probably should have called it 1.1.3 then.

Instances of Typeable have been requested for various types. I'll add 
these for 1.1.3.

-- 
Ashley Yakeley
From jeremy at n-heptane.com  Fri Apr 17 14:59:39 2009
From: jeremy at n-heptane.com (Jeremy Shaw)
Date: Fri Apr 17 14:46:02 2009
Subject: ANN: time 1.1.2.4
In-Reply-To: <49E8D0B7.3010405@semantic.org>
References: <gs9dh9$a81$1@ger.gmane.org>
	<loom.20090417T165814-259@post.gmane.org>
	<49E8D0B7.3010405@semantic.org>
Message-ID: <87r5zr14ys.wl%jeremy@n-heptane.com>

At Fri, 17 Apr 2009 11:55:51 -0700,
Ashley Yakeley wrote:

> Instances of Typeable have been requested for various types. I'll add 
> these for 1.1.3.

Sweet! Data as well? Happstack uses Data and Typeable for
serialization. It would be nice to be able to use Data.Time instead of
System.Time.

 - jeremy
From ashley at semantic.org  Sat Apr 18 20:26:39 2009
From: ashley at semantic.org (Ashley Yakeley)
Date: Sat Apr 18 20:12:57 2009
Subject: Data and Typeable instances
In-Reply-To: <87r5zr14ys.wl%jeremy@n-heptane.com>
References: <gs9dh9$a81$1@ger.gmane.org>	<loom.20090417T165814-259@post.gmane.org>	<49E8D0B7.3010405@semantic.org>
	<87r5zr14ys.wl%jeremy@n-heptane.com>
Message-ID: <49EA6FBF.2060801@semantic.org>

Jeremy Shaw wrote:
> At Fri, 17 Apr 2009 11:55:51 -0700,
> Ashley Yakeley wrote:
> 
>> Instances of Typeable have been requested for various types. I'll add 
>> these for 1.1.3.
> 
> Sweet! Data as well? Happstack uses Data and Typeable for
> serialization. It would be nice to be able to use Data.Time instead of
> System.Time.

I'm not sure. I find the whole SYB approach unhaskellish, as it treats 
values based on their internal structure rather than their types. But 
perhaps serialisation is a harmless use of the Data class.

Typeable is also rather unhaskellish. A haskellish approach would be to 
use type witnesses, but it requires open witness declarations as a 
language extension. So, Typeable it is.

-- 
Ashley Yakeley
Seattle, WA
From s.clover at gmail.com  Sun Apr 19 10:39:32 2009
From: s.clover at gmail.com (Sterling Clover)
Date: Sun Apr 19 10:21:28 2009
Subject: Data and Typeable instances
In-Reply-To: <49EA6FBF.2060801@semantic.org>
References: <gs9dh9$a81$1@ger.gmane.org>	<loom.20090417T165814-259@post.gmane.org>	<49E8D0B7.3010405@semantic.org>
	<87r5zr14ys.wl%jeremy@n-heptane.com>
	<49EA6FBF.2060801@semantic.org>
Message-ID: <C9FA4387-2FFF-4092-A6D6-5844A917E3DE@gmail.com>

Am I to take it that you will not be providing Data instances because  
you find them "unhaskellish"? The time package is a core part of  
Haskell functionality, and those Data instances are sorely missed by  
a wide range of libraries. As the maintainer of a key part of the  
Haskell ecosystem, I think you are obligated to take into account not  
only what you find to be the "good bits," but also to provide  
instances such as Data that, even if you find them "unhaskellish"  
allow the library to better integrate into the Haskell package  
ecosystem as it now stands. Furthermore, if such instances are not  
provided, they will be created with standalone deriving. The  
instances created by standalone deriving, unlike instances which can  
be partially hand-written, will provide even less in the way of  
preservation of the abstract nature of certain data types. In the  
end, you may only be cutting off your nose to spite your face.

Cheers,
Sterl.


On Apr 18, 2009, at 8:26 PM, Ashley Yakeley wrote:

> Jeremy Shaw wrote:
>> At Fri, 17 Apr 2009 11:55:51 -0700,
>> Ashley Yakeley wrote:
>>> Instances of Typeable have been requested for various types. I'll  
>>> add these for 1.1.3.
>> Sweet! Data as well? Happstack uses Data and Typeable for
>> serialization. It would be nice to be able to use Data.Time  
>> instead of
>> System.Time.
>
> I'm not sure. I find the whole SYB approach unhaskellish, as it  
> treats values based on their internal structure rather than their  
> types. But perhaps serialisation is a harmless use of the Data class.
>
> Typeable is also rather unhaskellish. A haskellish approach would  
> be to use type witnesses, but it requires open witness declarations  
> as a language extension. So, Typeable it is.
>
> -- 
> Ashley Yakeley
> Seattle, WA
> _______________________________________________
> Libraries mailing list
> Libraries@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

From lennart at augustsson.net  Sun Apr 19 11:16:13 2009
From: lennart at augustsson.net (Lennart Augustsson)
Date: Sun Apr 19 11:02:29 2009
Subject: Data and Typeable instances
In-Reply-To: <C9FA4387-2FFF-4092-A6D6-5844A917E3DE@gmail.com>
References: <gs9dh9$a81$1@ger.gmane.org>
	<loom.20090417T165814-259@post.gmane.org>
	<49E8D0B7.3010405@semantic.org> <87r5zr14ys.wl%jeremy@n-heptane.com>
	<49EA6FBF.2060801@semantic.org>
	<C9FA4387-2FFF-4092-A6D6-5844A917E3DE@gmail.com>
Message-ID: <f4876cd70904190816k2f3acab7y507102f78773e34d@mail.gmail.com>

I agree.  I'm not a great fan of Data, but I use it for various kinds
of serializations.
If a library doesn't support data, well that just means I'll try to
avoid that library.

  -- Lennart

On Sun, Apr 19, 2009 at 4:39 PM, Sterling Clover <s.clover@gmail.com> wrote:
> Am I to take it that you will not be providing Data instances because you
> find them "unhaskellish"? The time package is a core part of Haskell
> functionality, and those Data instances are sorely missed by a wide range of
> libraries. As the maintainer of a key part of the Haskell ecosystem, I think
> you are obligated to take into account not only what you find to be the
> "good bits," but also to provide instances such as Data that, even if you
> find them "unhaskellish" allow the library to better integrate into the
> Haskell package ecosystem as it now stands. Furthermore, if such instances
> are not provided, they will be created with standalone deriving. The
> instances created by standalone deriving, unlike instances which can be
> partially hand-written, will provide even less in the way of preservation of
> the abstract nature of certain data types. In the end, you may only be
> cutting off your nose to spite your face.
>
> Cheers,
> Sterl.
>
>
> On Apr 18, 2009, at 8:26 PM, Ashley Yakeley wrote:
>
>> Jeremy Shaw wrote:
>>>
>>> At Fri, 17 Apr 2009 11:55:51 -0700,
>>> Ashley Yakeley wrote:
>>>>
>>>> Instances of Typeable have been requested for various types. I'll add
>>>> these for 1.1.3.
>>>
>>> Sweet! Data as well? Happstack uses Data and Typeable for
>>> serialization. It would be nice to be able to use Data.Time instead of
>>> System.Time.
>>
>> I'm not sure. I find the whole SYB approach unhaskellish, as it treats
>> values based on their internal structure rather than their types. But
>> perhaps serialisation is a harmless use of the Data class.
>>
>> Typeable is also rather unhaskellish. A haskellish approach would be to
>> use type witnesses, but it requires open witness declarations as a language
>> extension. So, Typeable it is.
>>
>> --
>> Ashley Yakeley
>> Seattle, WA
>> _______________________________________________
>> Libraries mailing list
>> Libraries@haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> Libraries@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
From ashley at semantic.org  Sun Apr 19 16:58:03 2009
From: ashley at semantic.org (Ashley Yakeley)
Date: Sun Apr 19 16:44:19 2009
Subject: Data and Typeable instances
In-Reply-To: <C9FA4387-2FFF-4092-A6D6-5844A917E3DE@gmail.com>
References: <gs9dh9$a81$1@ger.gmane.org>	<loom.20090417T165814-259@post.gmane.org>	<49E8D0B7.3010405@semantic.org>	<87r5zr14ys.wl%jeremy@n-heptane.com>	<49EA6FBF.2060801@semantic.org>
	<C9FA4387-2FFF-4092-A6D6-5844A917E3DE@gmail.com>
Message-ID: <49EB905B.4040309@semantic.org>

I will not expose any private structure of types via instances of the 
Data class. I can't see what benefits SYB brings that it outweighs such 
loss of abstraction. And if someone else wants to shoot themselves in 
the foot by using standalone deriving, that's their problem.

However, this might not be an issue, as I believe all the constructors 
of all or almost all types in time are public. If it is possible for a 
user of time to hand-write instances of Data using only what time 
exposes, then it is safe to include those instances in the package.

-- 
Ashley Yakeley

Sterling Clover wrote:
> Am I to take it that you will not be providing Data instances because 
> you find them "unhaskellish"? The time package is a core part of Haskell 
> functionality, and those Data instances are sorely missed by a wide 
> range of libraries. As the maintainer of a key part of the Haskell 
> ecosystem, I think you are obligated to take into account not only what 
> you find to be the "good bits," but also to provide instances such as 
> Data that, even if you find them "unhaskellish" allow the library to 
> better integrate into the Haskell package ecosystem as it now stands. 
> Furthermore, if such instances are not provided, they will be created 
> with standalone deriving. The instances created by standalone deriving, 
> unlike instances which can be partially hand-written, will provide even 
> less in the way of preservation of the abstract nature of certain data 
> types. In the end, you may only be cutting off your nose to spite your 
> face.
> 
> Cheers,
> Sterl.
> 
> 
> On Apr 18, 2009, at 8:26 PM, Ashley Yakeley wrote:
> 
>> Jeremy Shaw wrote:
>>> At Fri, 17 Apr 2009 11:55:51 -0700,
>>> Ashley Yakeley wrote:
>>>> Instances of Typeable have been requested for various types. I'll 
>>>> add these for 1.1.3.
>>> Sweet! Data as well? Happstack uses Data and Typeable for
>>> serialization. It would be nice to be able to use Data.Time instead of
>>> System.Time.
>>
>> I'm not sure. I find the whole SYB approach unhaskellish, as it treats 
>> values based on their internal structure rather than their types. But 
>> perhaps serialisation is a harmless use of the Data class.
>>
>> Typeable is also rather unhaskellish. A haskellish approach would be 
>> to use type witnesses, but it requires open witness declarations as a 
>> language extension. So, Typeable it is.
>>
>> -- 
>> Ashley Yakeley
>> Seattle, WA
>> _______________________________________________
>> Libraries mailing list
>> Libraries@haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries

From ashley at semantic.org  Sun Apr 19 16:59:50 2009
From: ashley at semantic.org (Ashley Yakeley)
Date: Sun Apr 19 16:46:05 2009
Subject: Data and Typeable instances
In-Reply-To: <f4876cd70904190816k2f3acab7y507102f78773e34d@mail.gmail.com>
References: <gs9dh9$a81$1@ger.gmane.org>	<loom.20090417T165814-259@post.gmane.org>	<49E8D0B7.3010405@semantic.org>
	<87r5zr14ys.wl%jeremy@n-heptane.com>	<49EA6FBF.2060801@semantic.org>	<C9FA4387-2FFF-4092-A6D6-5844A917E3DE@gmail.com>
	<f4876cd70904190816k2f3acab7y507102f78773e34d@mail.gmail.com>
Message-ID: <49EB90C6.9080601@semantic.org>

Lennart Augustsson wrote:
> I agree.  I'm not a great fan of Data, but I use it for various kinds
> of serializations.
> If a library doesn't support data, well that just means I'll try to
> avoid that library.

You wouldn't write your own orphan instance?

-- 
Ashley Yakeley
From duncan.coutts at worc.ox.ac.uk  Sun Apr 19 17:41:25 2009
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Sun Apr 19 17:27:41 2009
Subject: Data and Typeable instances
In-Reply-To: <49EB905B.4040309@semantic.org>
References: <gs9dh9$a81$1@ger.gmane.org>
	<loom.20090417T165814-259@post.gmane.org>	<49E8D0B7.3010405@semantic.org>
	<87r5zr14ys.wl%jeremy@n-heptane.com>	<49EA6FBF.2060801@semantic.org>
	<C9FA4387-2FFF-4092-A6D6-5844A917E3DE@gmail.com>
	<49EB905B.4040309@semantic.org>
Message-ID: <1240177286.6315.106.camel@lantern>

On Sun, 2009-04-19 at 13:58 -0700, Ashley Yakeley wrote:
> I will not expose any private structure of types via instances of the 
> Data class. I can't see what benefits SYB brings that it outweighs such 
> loss of abstraction. And if someone else wants to shoot themselves in 
> the foot by using standalone deriving, that's their problem.

It's ok, abstraction is preserved by standalone deriving. You can only
derive for types where you can import the constructors.

> However, this might not be an issue, as I believe all the constructors 
> of all or almost all types in time are public. If it is possible for a 
> user of time to hand-write instances of Data using only what time 
> exposes, then it is safe to include those instances in the package.

Right, that seems like a sensible solution, that is to include Data
instances that preserve the abstraction. As you say, that can be tested
by initially writing the instances outside the package so that you can
be sure it's only using the public interface.

Duncan

From lennart at augustsson.net  Sun Apr 19 18:42:00 2009
From: lennart at augustsson.net (Lennart Augustsson)
Date: Sun Apr 19 18:28:14 2009
Subject: Data and Typeable instances
In-Reply-To: <49EB90C6.9080601@semantic.org>
References: <gs9dh9$a81$1@ger.gmane.org>
	<loom.20090417T165814-259@post.gmane.org>
	<49E8D0B7.3010405@semantic.org> <87r5zr14ys.wl%jeremy@n-heptane.com>
	<49EA6FBF.2060801@semantic.org>
	<C9FA4387-2FFF-4092-A6D6-5844A917E3DE@gmail.com>
	<f4876cd70904190816k2f3acab7y507102f78773e34d@mail.gmail.com>
	<49EB90C6.9080601@semantic.org>
Message-ID: <f4876cd70904191542l30d4a29fs7878bf92814dd836@mail.gmail.com>

If it's easy I would.

On Sun, Apr 19, 2009 at 10:59 PM, Ashley Yakeley <ashley@semantic.org> wrote:
> Lennart Augustsson wrote:
>>
>> I agree.  I'm not a great fan of Data, but I use it for various kinds
>> of serializations.
>> If a library doesn't support data, well that just means I'll try to
>> avoid that library.
>
> You wouldn't write your own orphan instance?
>
> --
> Ashley Yakeley
>
From lennart at augustsson.net  Sun Apr 19 18:43:43 2009
From: lennart at augustsson.net (Lennart Augustsson)
Date: Sun Apr 19 18:29:57 2009
Subject: Data and Typeable instances
In-Reply-To: <1240177286.6315.106.camel@lantern>
References: <gs9dh9$a81$1@ger.gmane.org>
	<loom.20090417T165814-259@post.gmane.org>
	<49E8D0B7.3010405@semantic.org> <87r5zr14ys.wl%jeremy@n-heptane.com>
	<49EA6FBF.2060801@semantic.org>
	<C9FA4387-2FFF-4092-A6D6-5844A917E3DE@gmail.com>
	<49EB905B.4040309@semantic.org> <1240177286.6315.106.camel@lantern>
Message-ID: <f4876cd70904191543u39e16002p1d58a7deabef108b@mail.gmail.com>

It's great if the instances preserve the abstraction.
As I said, I'm not a fan of Data, but it makes certain things very convenient.

On Sun, Apr 19, 2009 at 11:41 PM, Duncan Coutts
<duncan.coutts@worc.ox.ac.uk> wrote:
> On Sun, 2009-04-19 at 13:58 -0700, Ashley Yakeley wrote:
>> I will not expose any private structure of types via instances of the
>> Data class. I can't see what benefits SYB brings that it outweighs such
>> loss of abstraction. And if someone else wants to shoot themselves in
>> the foot by using standalone deriving, that's their problem.
>
> It's ok, abstraction is preserved by standalone deriving. You can only
> derive for types where you can import the constructors.
>
>> However, this might not be an issue, as I believe all the constructors
>> of all or almost all types in time are public. If it is possible for a
>> user of time to hand-write instances of Data using only what time
>> exposes, then it is safe to include those instances in the package.
>
> Right, that seems like a sensible solution, that is to include Data
> instances that preserve the abstraction. As you say, that can be tested
> by initially writing the instances outside the package so that you can
> be sure it's only using the public interface.
>
> Duncan
>
> _______________________________________________
> Libraries mailing list
> Libraries@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
From ndmitchell at gmail.com  Mon Apr 20 04:12:07 2009
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Mon Apr 20 03:58:21 2009
Subject: Failure to install time package
In-Reply-To: <f4876cd70904160224o4f19f182we38c3ec261b1cec5@mail.gmail.com>
References: <404396ef0904071326t17c8dd57p333e553fef7e337f@mail.gmail.com>
	<f4876cd70904160224o4f19f182we38c3ec261b1cec5@mail.gmail.com>
Message-ID: <404396ef0904200112j6090aaa2n8f849acde88644f@mail.gmail.com>

Hi

> Does anyone have a server where I could put an alternate 6.10.2 binary
> distribution for Windows?
> One that includes the time package and cabal.exe.

Please do! I've always said that GHC should come with cabal.exe, and I
still stand by that. The HP thing is a nice idea, and I support it,
but shoving cabal.exe quietly in with GHC would make my life much much
easier.

You can use Google for hosting downloads:
http://code.google.com/p/ndmitchell/downloads/list - creating a new
project is easy. Plus their bug tracker is great.

Thanks

Neil


>
> ?-- Lennart
>
> On Tue, Apr 7, 2009 at 10:26 PM, Neil Mitchell <ndmitchell@gmail.com> wrote:
>> Hi,
>>
>> Time is an important library, it got unbundled from GHC, and it seems
>> Windows users can't install the time package!
>>
>> C:\Neil\hoogle>cabal install time --global
>> Resolving dependencies...
>> [1 of 1] Compiling Main ? ? ? ? ? ? ( C:\Users\Neil\AppData\Local\Temp\time-1.1.
>> 2.32884\time-1.1.2.3\Setup.hs, C:\Users\Neil\AppData\Local\Temp\time-1.1.2.32884
>> \time-1.1.2.3\dist\setup\Main.o )
>> Linking C:\Users\Neil\AppData\Local\Temp\time-1.1.2.32884\time-1.1.2.3\dist\setu
>> p\setup.exe ...
>> Configuring time-1.1.2.3...
>> setup.exe: sh: runGenProcess: does not exist (No such file or directory)
>> cabal: Error: some packages failed to install:
>> time-1.1.2.3 failed during the configure step. The exception was:
>> exit: ExitFailure 1
>>
>> C:\Neil\hoogle>ghc --version
>> The Glorious Glasgow Haskell Compilation System, version 6.10.2
>>
>> My guess is that it would work if I installed mingw, but that it
>> hasn't been tested without. I consider this problem fatally serious -
>> we may have managed to make GHC 6.10.2 unuseable for many Windows
>> users...
>>
>> Thanks
>>
>> Neil
>> _______________________________________________
>> Libraries mailing list
>> Libraries@haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
From alistair at abayley.org  Mon Apr 20 08:09:35 2009
From: alistair at abayley.org (Alistair Bayley)
Date: Mon Apr 20 07:55:47 2009
Subject: Data and Typeable instances
In-Reply-To: <49EB905B.4040309@semantic.org>
References: <gs9dh9$a81$1@ger.gmane.org>
	<loom.20090417T165814-259@post.gmane.org>
	<49E8D0B7.3010405@semantic.org> <87r5zr14ys.wl%jeremy@n-heptane.com>
	<49EA6FBF.2060801@semantic.org>
	<C9FA4387-2FFF-4092-A6D6-5844A917E3DE@gmail.com>
	<49EB905B.4040309@semantic.org>
Message-ID: <79d7c4980904200509l908f608vb82e02dabebc83c7@mail.gmail.com>

2009/4/19 Ashley Yakeley <ashley@semantic.org>:
>
> However, this might not be an issue, as I believe all the constructors of
> all or almost all types in time are public. If it is possible for a user of
> time to hand-write instances of Data using only what time exposes, then it
> is safe to include those instances in the package.

I recall trying this some time ago. I think I gave up when I decided
that I also needed Data instances for Data.Fixed. I was probably doing
it wrong, but it was too large a yak for me to shave.

Alistair
From deniz.a.m.dogan at gmail.com  Mon Apr 20 11:27:31 2009
From: deniz.a.m.dogan at gmail.com (Deniz Dogan)
Date: Mon Apr 20 11:13:43 2009
Subject: Bug in old-locale?
Message-ID: <7b501d5c0904200827h35b8b917w19049bfc7c7afaaa@mail.gmail.com>

Hi

Is there a bug in the old-locale package? I tried the following simple program:

import Data.Time
import System.Locale

main = do
 time <- getCurrentTime
 putStrLn $ formatTime defaultTimeLocale rfc822DateFormat time

The above program prints:

Mon, d Apr 2009 15:23:56 UTC

Notice "Mon, d", where "d" should be the day of the month. Looking at
the source code in the package, I see:

rfc822DateFormat = "%a, %_d %b %Y %H:%M:%S %Z"

So what's up with %_d?

--
Deniz Dogan
From vandijk.roel at gmail.com  Mon Apr 20 12:09:35 2009
From: vandijk.roel at gmail.com (Roel van Dijk)
Date: Mon Apr 20 11:55:50 2009
Subject: NFData
In-Reply-To: <c290c4f20902270956qdffe0f8m9742b18d4d6c0d3a@mail.gmail.com>
References: <16442B752A06A74AB4D9F9A5FF076E4B01ABA89E@ELON17P32001A.csfb.cs-group.com>
	<20090227171825.GB18853@whirlpool.galois.com>
	<c290c4f20902270956qdffe0f8m9742b18d4d6c0d3a@mail.gmail.com>
Message-ID: <ab9dc6fa0904200909r34f393dfp758c65bf8951ae35@mail.gmail.com>

For a package I released recently I had to define the following operators:

-- |Very strict monadic bind
(>>=|) :: (Monad m, NFData a) => m a -> (a -> m b) -> m b
m >>=| f = m >>= f $| rnf

(>>|) :: (Monad m, NFData a) => m a -> m b -> m b
m1 >>| m2 = m1 >>=| const m2

It would be nice if I could drop the dependency on parallel.
From ganesh.sittampalam at credit-suisse.com  Mon Apr 20 12:21:52 2009
From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh)
Date: Mon Apr 20 12:08:20 2009
Subject: NFData
In-Reply-To: <ab9dc6fa0904200909r34f393dfp758c65bf8951ae35@mail.gmail.com>
References: <16442B752A06A74AB4D9F9A5FF076E4B01ABA89E@ELON17P32001A.csfb.cs-group.com><20090227171825.GB18853@whirlpool.galois.com><c290c4f20902270956qdffe0f8m9742b18d4d6c0d3a@mail.gmail.com>
	<ab9dc6fa0904200909r34f393dfp758c65bf8951ae35@mail.gmail.com>
Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B01ABAA51@ELON17P32001A.csfb.cs-group.com>

Roel van Dijk wrote:
> For a package I released recently I had to define the following
> operators: 
> 
> -- |Very strict monadic bind
> (>>=|) :: (Monad m, NFData a) => m a -> (a -> m b) -> m b
> m >>=| f = m >>= f $| rnf
> 
> (>>|) :: (Monad m, NFData a) => m a -> m b -> m b
> m1 >>| m2 = m1 >>=| const m2
> 
> It would be nice if I could drop the dependency on parallel.

Now is not a good time to be changing the extralibs as the
Platform is taking over from them. Once that's made its first
release and settled down a bit I will propose this split
properly.

Ganesh

=============================================================================== 
 Please access the attached hyperlink for an important electronic communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 =============================================================================== 
 
From magnus at therning.org  Mon Apr 20 12:26:35 2009
From: magnus at therning.org (Magnus Therning)
Date: Mon Apr 20 12:12:49 2009
Subject: Bug in old-locale?
In-Reply-To: <7b501d5c0904200827h35b8b917w19049bfc7c7afaaa@mail.gmail.com>
References: <7b501d5c0904200827h35b8b917w19049bfc7c7afaaa@mail.gmail.com>
Message-ID: <e040b520904200926h178e16f4gf6f3fabf29839356@mail.gmail.com>

On Mon, Apr 20, 2009 at 11:27 PM, Deniz Dogan <deniz.a.m.dogan@gmail.com> wrote:
> Hi
>
> Is there a bug in the old-locale package? I tried the following simple program:
>
> import Data.Time
> import System.Locale
>
> main = do
> ?time <- getCurrentTime
> ?putStrLn $ formatTime defaultTimeLocale rfc822DateFormat time
>
> The above program prints:
>
> Mon, d Apr 2009 15:23:56 UTC
>
> Notice "Mon, d", where "d" should be the day of the month. Looking at
> the source code in the package, I see:
>
> rfc822DateFormat = "%a, %_d %b %Y %H:%M:%S %Z"
>
> So what's up with %_d?

That looks like an error to me.  According to the date(1) manpage, an
underbar pads with spaces.

% date +"%a, %_d %b %Y %H:%M:%S %Z"
Tue, 21 Apr 2009 00:25:50 SGT

/M

-- 
Magnus Therning                        (OpenPGP: 0xAB4DFBA4)
magnus?therning?org          Jabber: magnus?therning?org
http://therning.org/magnus         identi.ca|twitter: magthe
From ashley at semantic.org  Tue Apr 21 11:31:42 2009
From: ashley at semantic.org (Ashley Yakeley)
Date: Tue Apr 21 11:17:51 2009
Subject: Bug in old-locale?
In-Reply-To: <e040b520904200926h178e16f4gf6f3fabf29839356@mail.gmail.com>
References: <7b501d5c0904200827h35b8b917w19049bfc7c7afaaa@mail.gmail.com>
	<e040b520904200926h178e16f4gf6f3fabf29839356@mail.gmail.com>
Message-ID: <49EDE6DE.20701@semantic.org>

Magnus Therning wrote:
> On Mon, Apr 20, 2009 at 11:27 PM, Deniz Dogan <deniz.a.m.dogan@gmail.com> wrote:
>> Hi
>>
>> Is there a bug in the old-locale package? I tried the following simple program:
>>
>> import Data.Time
>> import System.Locale
>>
>> main = do
>>  time <- getCurrentTime
>>  putStrLn $ formatTime defaultTimeLocale rfc822DateFormat time
>>
>> The above program prints:
>>
>> Mon, d Apr 2009 15:23:56 UTC
>>
>> Notice "Mon, d", where "d" should be the day of the month. Looking at
>> the source code in the package, I see:
>>
>> rfc822DateFormat = "%a, %_d %b %Y %H:%M:%S %Z"
>>
>> So what's up with %_d?
> 
> That looks like an error to me.  According to the date(1) manpage, an
> underbar pads with spaces.
> 
> % date +"%a, %_d %b %Y %H:%M:%S %Z"
> Tue, 21 Apr 2009 00:25:50 SGT

It looks like old-locale and time have different ideas of date formats. 
Possibly this should be fixed in the time package.

By the way, if old-locale is "old", what should be used instead?

-- 
Ashley Yakeley
From martijn at van.steenbergen.nl  Tue Apr 21 17:07:51 2009
From: martijn at van.steenbergen.nl (Martijn van Steenbergen)
Date: Tue Apr 21 16:54:10 2009
Subject: [Haskell-cafe] ANN: list-tries-0.0 - first release
In-Reply-To: <gslbp8$qdt$1@ger.gmane.org>
References: <gslbp8$qdt$1@ger.gmane.org>
Message-ID: <49EE35A7.8060302@van.steenbergen.nl>

Matti Niemenmaa wrote:
> In order to run properly, list-tries needs a version of 'containers'
> that hasn't yet been released. I incorporated a little hack which makes
> it compile even with 0.2, but some calls will fail by calling 'error':
> 30 of my 1014 test cases do so.

1014 test cases?! Wow. :-)

FYI, list-tries installed without any problems (with containers-0.2.0.0).

Thanks,

Martijn.
From magnus at therning.org  Wed Apr 22 09:43:30 2009
From: magnus at therning.org (Magnus Therning)
Date: Wed Apr 22 09:29:57 2009
Subject: Bug in old-locale?
In-Reply-To: <49EDE6DE.20701@semantic.org>
References: <7b501d5c0904200827h35b8b917w19049bfc7c7afaaa@mail.gmail.com>
	<e040b520904200926h178e16f4gf6f3fabf29839356@mail.gmail.com>
	<49EDE6DE.20701@semantic.org>
Message-ID: <e040b520904220643p3e56b1cft39a75c8aa787f001@mail.gmail.com>

On Tue, Apr 21, 2009 at 4:31 PM, Ashley Yakeley <ashley@semantic.org> wrote:
> Magnus Therning wrote:
>>
>> On Mon, Apr 20, 2009 at 11:27 PM, Deniz Dogan <deniz.a.m.dogan@gmail.com>
>> wrote:
>>>
>>> Hi
>>>
>>> Is there a bug in the old-locale package? I tried the following simple
>>> program:
>>>
>>> import Data.Time
>>> import System.Locale
>>>
>>> main = do
>>> ?time <- getCurrentTime
>>> ?putStrLn $ formatTime defaultTimeLocale rfc822DateFormat time
>>>
>>> The above program prints:
>>>
>>> Mon, d Apr 2009 15:23:56 UTC
>>>
>>> Notice "Mon, d", where "d" should be the day of the month. Looking at
>>> the source code in the package, I see:
>>>
>>> rfc822DateFormat = "%a, %_d %b %Y %H:%M:%S %Z"
>>>
>>> So what's up with %_d?
>>
>> That looks like an error to me. ?According to the date(1) manpage, an
>> underbar pads with spaces.
>>
>> % date +"%a, %_d %b %Y %H:%M:%S %Z"
>> Tue, 21 Apr 2009 00:25:50 SGT
>
> It looks like old-locale and time have different ideas of date formats.
> Possibly this should be fixed in the time package.
>
> By the way, if old-locale is "old", what should be used instead?

I'm not sure old means deprecated... at least not yet :-)

/M

-- 
Magnus Therning                        (OpenPGP: 0xAB4DFBA4)
magnus?therning?org          Jabber: magnus?therning?org
http://therning.org/magnus         identi.ca|twitter: magthe
From magnus at therning.org  Wed Apr 22 16:02:34 2009
From: magnus at therning.org (Magnus Therning)
Date: Wed Apr 22 15:49:21 2009
Subject: ANNOUNCE: dataenc 0.12.1.0
Message-ID: <49EF77DA.5010607@therning.org>

I've just uploaded version 0.12.1.0 of dataenc with the following (visible)
changes compared to the previous version (0.12):

 - implementation of a bunch of new encodings:
   - xxencode
   - hexadecimal
   - quoted-printable
   - python escaping
   - url encoding
 - squashing of a bug in the yEncoding implementation that only
manifested on
   32-bit systems
 - an attempt to conform to the guidelines for the Haskell Platform
   regarding versioning and dependencies

This release brings the full list of encodings to

 - Base16
 - Base32
 - Base32Hex
 - Base64
 - Base64Url
 - Base85
 - Hexadecimal
 - Python string escaping
 - quoted-printable
 - URL encoding
 - uuencoding
 - xxencoding
 - yEncoding

The hackage page[1] now reads:

  Versions	0.9, 0.10.1, 0.10.2, 0.11, 0.11.1, 0.12, 0.12.1.0
  Dependencies	array (>=0.2.0 && <0.3), base (>=4.0.0 && <4.1),
containers (>=0.2.0 && <0.3)
  License	BSD3
  Copyright	Magnus Therning, 2007-2009
  Author	Magnus Therning
  Maintainer	magnus@therning.org
  Category	Codec
  Home page	http://www.haskell.org/haskellwiki/Library/Data_encoding
  Upload date	Wed Apr 22 19:40:22 UTC 2009
  Uploaded by	MagnusTherning

/M

[1]: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dataenc

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
Url : http://www.haskell.org/pipermail/libraries/attachments/20090422/eaf608cd/signature.bin
From jgoerzen at complete.org  Thu Apr 23 16:19:18 2009
From: jgoerzen at complete.org (John Goerzen)
Date: Thu Apr 23 16:05:38 2009
Subject: [Haskell-cafe] HPong-0.1.2 fails to compile in Debian ghc 6.10.1
In-Reply-To: <gsqeo8$92o$1@ger.gmane.org>
References: <9BEB5EF43B5A4042B60C0D8179782DB3D693F5C9F9@EXCHANGE10.campus.tue.nl>
	<gsqeo8$92o$1@ger.gmane.org>
Message-ID: <49F0CD46.10306@complete.org>

Ahn, Ki Yung wrote:
> I don't know the exact reason but this should not fail since I have 
> Debian packaged ghc 6.10.1 and OpenGL-2.2.1.1 on my system.
> 
> I think this is because the filename of the OpenGL shared library is 
> /usr/lib/libGL.so.1 rather than libGL.so.  This is why we have two 

No.  Do not manually create the symlink.  It sounds like you don't have
the -dev packages for OpenGL installed.  You should install them and
then you should be OK.

From trentbuck at gmail.com  Thu Apr 23 20:46:06 2009
From: trentbuck at gmail.com (Trent W. Buck)
Date: Thu Apr 23 21:06:07 2009
Subject: [Haskell-cafe] HPong-0.1.2 fails to compile in Debian ghc 6.10.1
References: <9BEB5EF43B5A4042B60C0D8179782DB3D693F5C9F9@EXCHANGE10.campus.tue.nl>
	<gsqeo8$92o$1@ger.gmane.org> <49F0CD46.10306@complete.org>
	<gsqk2m$rj7$1@ger.gmane.org>
Message-ID: <30eivij2up.fsf@alexlance.com>

"Ahn, Ki Yung" <kyagrd@gmail.com> writes:
>>> I think this is because the filename of the OpenGL shared library is
>>> /usr/lib/libGL.so.1 rather than libGL.so.
>>
>> No.  Do not manually create the symlink.  It sounds like you don't
>> have the -dev packages for OpenGL installed.
>
> I do already have the dev package libgl1-mesa-dev installed.  [...]
> It's just seems to the bug of libgl1-mesa-dev 7.4-2 packaging.  It
> doesn't seem to make the symbolic link which it claims to make.  Duh

The file exists in that package, so it seems to me the problem is on
your workstation, rather than in the package.  I suggest you just
reinstall the package in question.  You may also want to use cruft(8) to
find out if any other files have gone missing, and run a fsck over your
root partition.

$ aptitude download -t unstable libgl1-mesa-dev
[...]
Get:1 http://mirror.internode.on.net unstable/main libgl1-mesa-dev 7.4-2
$ dpkg -x libgl1-mesa-dev_7.4-2_all.deb .
$ find -name \*.so -ls
 13003 0 lrwxrwxrwx 1 twb twb 10 Apr 24 10:41 ./usr/lib/libGL.so -> libGL.so.1
$

From chris at eidhof.nl  Fri Apr 24 07:58:49 2009
From: chris at eidhof.nl (Chris Eidhof)
Date: Fri Apr 24 07:44:51 2009
Subject: Proposal: rename Data.Map.fromAscList to Data.Map.unsafeFromAscList
Message-ID: <DA0FC8C6-22C3-438D-A109-E1208FF8F8B2@eidhof.nl>

Hey all,

I had some code where the function elems said a certain key was  
present, but looking it up returned a Nothing. After some debugging I  
found out that it did work if I used Prelude's lookup in combination  
with toList. After even more debugging it turned out there was a  
fromAscList somewhere deep down in my code where it should have been a  
fromList.

Now, I know that I shouldn't have used fromAscList and that it was  
totally my fault. I also realize this is something that can't easily  
be checked using the type system, so I propose we do the next best  
thing: prefix the name with 'unsafe'.

-chris

From gtener at gmail.com  Fri Apr 24 08:08:09 2009
From: gtener at gmail.com (=?UTF-8?Q?Krzysztof_Skrz=C4=99tnicki?=)
Date: Fri Apr 24 07:54:11 2009
Subject: Proposal: rename Data.Map.fromAscList to
	Data.Map.unsafeFromAscList
In-Reply-To: <DA0FC8C6-22C3-438D-A109-E1208FF8F8B2@eidhof.nl>
References: <DA0FC8C6-22C3-438D-A109-E1208FF8F8B2@eidhof.nl>
Message-ID: <220e47b40904240508p62666605qdcf1c9700132a1be@mail.gmail.com>

I disagree. There are plenty of non-total functions in various libraries.
Prefixing all of them with "unsafe" seems like overkill. Consider fromJust:
it should be called unsafeFromJust, same for head, tail, init...

Best regards

Christopher Skrz?tnicki

On Fri, Apr 24, 2009 at 13:58, Chris Eidhof <chris@eidhof.nl> wrote:

> Hey all,
>
> I had some code where the function elems said a certain key was present,
> but looking it up returned a Nothing. After some debugging I found out that
> it did work if I used Prelude's lookup in combination with toList. After
> even more debugging it turned out there was a fromAscList somewhere deep
> down in my code where it should have been a fromList.
>
> Now, I know that I shouldn't have used fromAscList and that it was totally
> my fault. I also realize this is something that can't easily be checked
> using the type system, so I propose we do the next best thing: prefix the
> name with 'unsafe'.
>
> -chris
>
> _______________________________________________
> Libraries mailing list
> Libraries@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20090424/c0acebc6/attachment-0001.htm
From gtener at gmail.com  Fri Apr 24 08:14:37 2009
From: gtener at gmail.com (=?UTF-8?Q?Krzysztof_Skrz=C4=99tnicki?=)
Date: Fri Apr 24 08:00:37 2009
Subject: Proposal: rename Data.Map.fromAscList to
	Data.Map.unsafeFromAscList
In-Reply-To: <DA0FC8C6-22C3-438D-A109-E1208FF8F8B2@eidhof.nl>
References: <DA0FC8C6-22C3-438D-A109-E1208FF8F8B2@eidhof.nl>
Message-ID: <220e47b40904240514x3ea815b9pc50999b975e948f6@mail.gmail.com>

On the second thought, another thing can be made. Since we know that
fromAscList should take a list of ascending items, we can check whether it
is sorted. If this precondition is not met, we simply call error. We also
rename current fromAscList to unsafeFromAscList. This is similar to index
and unsafeIndex from arrays code.

What do you think about this solution?

Best regards

Christopher Skrz?tnicki

On Fri, Apr 24, 2009 at 13:58, Chris Eidhof <chris@eidhof.nl> wrote:

> Hey all,
>
> I had some code where the function elems said a certain key was present,
> but looking it up returned a Nothing. After some debugging I found out that
> it did work if I used Prelude's lookup in combination with toList. After
> even more debugging it turned out there was a fromAscList somewhere deep
> down in my code where it should have been a fromList.
>
> Now, I know that I shouldn't have used fromAscList and that it was totally
> my fault. I also realize this is something that can't easily be checked
> using the type system, so I propose we do the next best thing: prefix the
> name with 'unsafe'.
>
> -chris
>
> _______________________________________________
> Libraries mailing list
> Libraries@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20090424/58d1a678/attachment.htm
From chris at eidhof.nl  Fri Apr 24 08:20:33 2009
From: chris at eidhof.nl (Chris Eidhof)
Date: Fri Apr 24 08:06:32 2009
Subject: Proposal: rename Data.Map.fromAscList to
	Data.Map.unsafeFromAscList
In-Reply-To: <220e47b40904240514x3ea815b9pc50999b975e948f6@mail.gmail.com>
References: <DA0FC8C6-22C3-438D-A109-E1208FF8F8B2@eidhof.nl>
	<220e47b40904240514x3ea815b9pc50999b975e948f6@mail.gmail.com>
Message-ID: <1DDB3035-7B8A-45C0-8DF4-7EB5D7C3C360@eidhof.nl>

I really like that, Krzysztof. That way there's still the power to do  
it efficiently but at least you know when you're doing things in an  
erroneous way. My problem with the current way of doing this is that  
you get errors in a place where you didn't expect them.

-chris

On 24 apr 2009, at 14:14, Krzysztof Skrz?tnicki wrote:

> On the second thought, another thing can be made. Since we know that  
> fromAscList should take a list of ascending items, we can check  
> whether it is sorted. If this precondition is not met, we simply  
> call error. We also rename current fromAscList to unsafeFromAscList.  
> This is similar to index and unsafeIndex from arrays code.
>
> What do you think about this solution?
>
> Best regards
>
> Christopher Skrz?tnicki
>
> On Fri, Apr 24, 2009 at 13:58, Chris Eidhof <chris@eidhof.nl> wrote:
> Hey all,
>
> I had some code where the function elems said a certain key was  
> present, but looking it up returned a Nothing. After some debugging  
> I found out that it did work if I used Prelude's lookup in  
> combination with toList. After even more debugging it turned out  
> there was a fromAscList somewhere deep down in my code where it  
> should have been a fromList.
>
> Now, I know that I shouldn't have used fromAscList and that it was  
> totally my fault. I also realize this is something that can't easily  
> be checked using the type system, so I propose we do the next best  
> thing: prefix the name with 'unsafe'.
>
> -chris
>
> _______________________________________________
> Libraries mailing list
> Libraries@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>

From Christian.Maeder at dfki.de  Fri Apr 24 08:36:05 2009
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Fri Apr 24 08:22:05 2009
Subject: Proposal: rename Data.Map.fromAscList to
	Data.Map.unsafeFromAscList
In-Reply-To: <DA0FC8C6-22C3-438D-A109-E1208FF8F8B2@eidhof.nl>
References: <DA0FC8C6-22C3-438D-A109-E1208FF8F8B2@eidhof.nl>
Message-ID: <49F1B235.8030806@dfki.de>


There is an old thread about this, where Daan suggested "unchecked"
instead of "unsafe".
http://www.haskell.org/pipermail/haskell/2004-March/013787.html

"unsafe" reminds to "IO" stuff.

Didn't you read the comment about fromAscList? Isn't the name long
enough to scare you?

Would you have not taken "unsafeFromAscList" under the same
circumstances you've chosen "fromAscList"?

Cheers Christian

Chris Eidhof wrote:
> Hey all,
> 
> I had some code where the function elems said a certain key was present,
> but looking it up returned a Nothing. After some debugging I found out
> that it did work if I used Prelude's lookup in combination with toList.
> After even more debugging it turned out there was a fromAscList
> somewhere deep down in my code where it should have been a fromList.
> 
> Now, I know that I shouldn't have used fromAscList and that it was
> totally my fault. I also realize this is something that can't easily be
> checked using the type system, so I propose we do the next best thing:
> prefix the name with 'unsafe'.
> 
> -chris
From ndmitchell at gmail.com  Fri Apr 24 08:51:22 2009
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Fri Apr 24 08:37:20 2009
Subject: Proposal: rename Data.Map.fromAscList to
	Data.Map.unsafeFromAscList
In-Reply-To: <49F1B235.8030806@dfki.de>
References: <DA0FC8C6-22C3-438D-A109-E1208FF8F8B2@eidhof.nl>
	<49F1B235.8030806@dfki.de>
Message-ID: <404396ef0904240551o7fc143eve87cfda6826b01d2@mail.gmail.com>

Hi,

I totally disagree. unsafe/unchecked means nothing other than "beware
of the bogey monster", or for most Haskell users, "just another
function that might launch missiles". fromAscList has the specific
precondition for this function in the name. Should we call unsafeHead?
uncheckedHead? mightCrashIfNotConsHead?

Adding a check for the precondition would be the ideal thing to do,
but I wouldn't want to do it if it added an extra comparison or was
any runtime cost at all. Perhaps adding checkedFromAscList might be
acceptable, but I can't imagine anyone would call it until they'd got
it wrong the first time, at which point the chances of them getting it
wrong again are quite low.

Thanks

Neil

On Fri, Apr 24, 2009 at 1:36 PM, Christian Maeder
<Christian.Maeder@dfki.de> wrote:
>
> There is an old thread about this, where Daan suggested "unchecked"
> instead of "unsafe".
> http://www.haskell.org/pipermail/haskell/2004-March/013787.html
>
> "unsafe" reminds to "IO" stuff.
>
> Didn't you read the comment about fromAscList? Isn't the name long
> enough to scare you?
>
> Would you have not taken "unsafeFromAscList" under the same
> circumstances you've chosen "fromAscList"?
>
> Cheers Christian
>
> Chris Eidhof wrote:
>> Hey all,
>>
>> I had some code where the function elems said a certain key was present,
>> but looking it up returned a Nothing. After some debugging I found out
>> that it did work if I used Prelude's lookup in combination with toList.
>> After even more debugging it turned out there was a fromAscList
>> somewhere deep down in my code where it should have been a fromList.
>>
>> Now, I know that I shouldn't have used fromAscList and that it was
>> totally my fault. I also realize this is something that can't easily be
>> checked using the type system, so I propose we do the next best thing:
>> prefix the name with 'unsafe'.
>>
>> -chris
> _______________________________________________
> Libraries mailing list
> Libraries@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
From Christian.Maeder at dfki.de  Fri Apr 24 09:10:57 2009
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Fri Apr 24 08:56:56 2009
Subject: Proposal: rename Data.Map.fromAscList to
	Data.Map.unsafeFromAscList
In-Reply-To: <404396ef0904240551o7fc143eve87cfda6826b01d2@mail.gmail.com>
References: <DA0FC8C6-22C3-438D-A109-E1208FF8F8B2@eidhof.nl>	<49F1B235.8030806@dfki.de>
	<404396ef0904240551o7fc143eve87cfda6826b01d2@mail.gmail.com>
Message-ID: <49F1BA61.5070407@dfki.de>

Neil Mitchell wrote:
> Hi,
> 
> I totally disagree. unsafe/unchecked means nothing other than "beware
> of the bogey monster", or for most Haskell users, "just another
> function that might launch missiles". fromAscList has the specific
> precondition for this function in the name. Should we call unsafeHead?
> uncheckedHead? mightCrashIfNotConsHead?

Do I really need to point out the difference between head and fromAscList?

fromAscList is total but may badly destroy the internal (invariant of
the) representation. head at least crashes (hopefully fairly soon) when
called wrongly.

C.
From gtener at gmail.com  Fri Apr 24 09:11:51 2009
From: gtener at gmail.com (=?UTF-8?Q?Krzysztof_Skrz=C4=99tnicki?=)
Date: Fri Apr 24 08:57:51 2009
Subject: Proposal: rename Data.Map.fromAscList to
	Data.Map.unsafeFromAscList
In-Reply-To: <404396ef0904240551o7fc143eve87cfda6826b01d2@mail.gmail.com>
References: <DA0FC8C6-22C3-438D-A109-E1208FF8F8B2@eidhof.nl>
	<49F1B235.8030806@dfki.de>
	<404396ef0904240551o7fc143eve87cfda6826b01d2@mail.gmail.com>
Message-ID: <220e47b40904240611q75c08298v1942975879e0998@mail.gmail.com>

There are two kinds of functions that might be callled unsafe:
- non-total functions like head
- functions that require some precondition is met like fromAscList

First kind is too common to be prefixed with "unsafe". I has also a very
*nice* property: they crash program if they fail. Which is a good thing,
because it makes them always correct. Now, there is a second type. Those
functions may not crash the program, but they could go wrong without notice.
This is a very dangereous situation, since user may run across some strange
results in random places. So we make those functions safe by adding runtime
check. Surely there are times where the user is so much concerned about
performance they might as well choose to omit the check. But IMO Haskell
should be correct in the first place. There is no point in doing wrong
calculcations, even if we do them fast.

Best regards

Christopher Skrz?tnicki

On Fri, Apr 24, 2009 at 14:51, Neil Mitchell <ndmitchell@gmail.com> wrote:

> Hi,
>
> I totally disagree. unsafe/unchecked means nothing other than "beware
> of the bogey monster", or for most Haskell users, "just another
> function that might launch missiles". fromAscList has the specific
> precondition for this function in the name. Should we call unsafeHead?
> uncheckedHead? mightCrashIfNotConsHead?
>
> Adding a check for the precondition would be the ideal thing to do,
> but I wouldn't want to do it if it added an extra comparison or was
> any runtime cost at all. Perhaps adding checkedFromAscList might be
> acceptable, but I can't imagine anyone would call it until they'd got
> it wrong the first time, at which point the chances of them getting it
> wrong again are quite low.
>
> Thanks
>
> Neil
>
> On Fri, Apr 24, 2009 at 1:36 PM, Christian Maeder
> <Christian.Maeder@dfki.de> wrote:
> >
> > There is an old thread about this, where Daan suggested "unchecked"
> > instead of "unsafe".
> > http://www.haskell.org/pipermail/haskell/2004-March/013787.html
> >
> > "unsafe" reminds to "IO" stuff.
> >
> > Didn't you read the comment about fromAscList? Isn't the name long
> > enough to scare you?
> >
> > Would you have not taken "unsafeFromAscList" under the same
> > circumstances you've chosen "fromAscList"?
> >
> > Cheers Christian
> >
> > Chris Eidhof wrote:
> >> Hey all,
> >>
> >> I had some code where the function elems said a certain key was present,
> >> but looking it up returned a Nothing. After some debugging I found out
> >> that it did work if I used Prelude's lookup in combination with toList.
> >> After even more debugging it turned out there was a fromAscList
> >> somewhere deep down in my code where it should have been a fromList.
> >>
> >> Now, I know that I shouldn't have used fromAscList and that it was
> >> totally my fault. I also realize this is something that can't easily be
> >> checked using the type system, so I propose we do the next best thing:
> >> prefix the name with 'unsafe'.
> >>
> >> -chris
> > _______________________________________________
> > Libraries mailing list
> > Libraries@haskell.org
> > http://www.haskell.org/mailman/listinfo/libraries
> >
> _______________________________________________
> Libraries mailing list
> Libraries@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20090424/16686f21/attachment.htm
From bulat.ziganshin at gmail.com  Fri Apr 24 09:13:18 2009
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Fri Apr 24 08:59:29 2009
Subject: Proposal: rename Data.Map.fromAscList to
	Data.Map.unsafeFromAscList
In-Reply-To: <49F1BA61.5070407@dfki.de>
References: <DA0FC8C6-22C3-438D-A109-E1208FF8F8B2@eidhof.nl>
	<49F1B235.8030806@dfki.de>
	<404396ef0904240551o7fc143eve87cfda6826b01d2@mail.gmail.com>
	<49F1BA61.5070407@dfki.de>
Message-ID: <1059827605.20090424171318@gmail.com>

Hello Christian,

Friday, April 24, 2009, 5:10:57 PM, you wrote:
> fromAscList is total but may badly destroy the internal (invariant of
> the) representation. head at least crashes (hopefully fairly soon) when
> called wrongly.

well, using id for list sorting may also give wrong result. that's
implied by its name, not it?

-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From ndmitchell at gmail.com  Fri Apr 24 09:21:11 2009
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Fri Apr 24 09:07:10 2009
Subject: Proposal: rename Data.Map.fromAscList to
	Data.Map.unsafeFromAscList
In-Reply-To: <49F1BA61.5070407@dfki.de>
References: <DA0FC8C6-22C3-438D-A109-E1208FF8F8B2@eidhof.nl>
	<49F1B235.8030806@dfki.de>
	<404396ef0904240551o7fc143eve87cfda6826b01d2@mail.gmail.com>
	<49F1BA61.5070407@dfki.de>
Message-ID: <404396ef0904240621h649d970clf93674496dccf3c1@mail.gmail.com>

Hi

> Do I really need to point out the difference between head and fromAscList?
>
> fromAscList is total but may badly destroy the internal (invariant of
> the) representation. head at least crashes (hopefully fairly soon) when
> called wrongly.

Better example, sortBy f, where f isn't a valid ordering function. It
works, but destroyed internal invariants. Should it be uncheckedSortBy
f ?

Thanks

Neil
From chris at eidhof.nl  Fri Apr 24 09:21:20 2009
From: chris at eidhof.nl (Chris Eidhof)
Date: Fri Apr 24 09:07:21 2009
Subject: Proposal: rename Data.Map.fromAscList to
	Data.Map.unsafeFromAscList
In-Reply-To: <404396ef0904240551o7fc143eve87cfda6826b01d2@mail.gmail.com>
References: <DA0FC8C6-22C3-438D-A109-E1208FF8F8B2@eidhof.nl>
	<49F1B235.8030806@dfki.de>
	<404396ef0904240551o7fc143eve87cfda6826b01d2@mail.gmail.com>
Message-ID: <C2126036-6EA6-4F0E-844D-FEF230C2E1D4@eidhof.nl>

Hi,

On 24 apr 2009, at 14:51, Neil Mitchell wrote:

> I totally disagree. unsafe/unchecked means nothing other than "beware
> of the bogey monster", or for most Haskell users, "just another
> function that might launch missiles". fromAscList has the specific
> precondition for this function in the name. Should we call unsafeHead?
> uncheckedHead? mightCrashIfNotConsHead?

No, but the functions you mentioned do fail immediately. If I use a  
head on an empty list I get an error immediately. If I use fromAscList  
incorrectly I get an error only when I try to lookup elements. This  
makes it hard to debug if you didn't make this error before. I don't  
mind a runtime error in this case, but I very much want to know where  
my bug is.

Thanks,
-chris

>
>
> Thanks
>
> Neil
>
> On Fri, Apr 24, 2009 at 1:36 PM, Christian Maeder
> <Christian.Maeder@dfki.de> wrote:
>>
>> There is an old thread about this, where Daan suggested "unchecked"
>> instead of "unsafe".
>> http://www.haskell.org/pipermail/haskell/2004-March/013787.html
>>
>> "unsafe" reminds to "IO" stuff.
>>
>> Didn't you read the comment about fromAscList? Isn't the name long
>> enough to scare you?
>>
>> Would you have not taken "unsafeFromAscList" under the same
>> circumstances you've chosen "fromAscList"?
>>
>> Cheers Christian
>>
>> Chris Eidhof wrote:
>>> Hey all,
>>>
>>> I had some code where the function elems said a certain key was  
>>> present,
>>> but looking it up returned a Nothing. After some debugging I found  
>>> out
>>> that it did work if I used Prelude's lookup in combination with  
>>> toList.
>>> After even more debugging it turned out there was a fromAscList
>>> somewhere deep down in my code where it should have been a fromList.
>>>
>>> Now, I know that I shouldn't have used fromAscList and that it was
>>> totally my fault. I also realize this is something that can't  
>>> easily be
>>> checked using the type system, so I propose we do the next best  
>>> thing:
>>> prefix the name with 'unsafe'.
>>>
>>> -chris
>> _______________________________________________
>> Libraries mailing list
>> Libraries@haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>

From bulat.ziganshin at gmail.com  Fri Apr 24 09:26:23 2009
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Fri Apr 24 09:12:39 2009
Subject: Proposal: rename Data.Map.fromAscList to
	Data.Map.unsafeFromAscList
In-Reply-To: <C2126036-6EA6-4F0E-844D-FEF230C2E1D4@eidhof.nl>
References: <DA0FC8C6-22C3-438D-A109-E1208FF8F8B2@eidhof.nl>
	<49F1B235.8030806@dfki.de>
	<404396ef0904240551o7fc143eve87cfda6826b01d2@mail.gmail.com>
	<C2126036-6EA6-4F0E-844D-FEF230C2E1D4@eidhof.nl>
Message-ID: <5462653.20090424172623@gmail.com>

Hello Chris,

Friday, April 24, 2009, 5:21:20 PM, you wrote:

> No, but the functions you mentioned do fail immediately. If I use a
> head on an empty list I get an error immediately. If I use fromAscList
> incorrectly I get an error only when I try to lookup elements. This  
> makes it hard to debug if you didn't make this error before. I don't  
> mind a runtime error in this case, but I very much want to know where
> my bug is.

how about providing such check only in *debugging* version of library?


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From chris at eidhof.nl  Fri Apr 24 09:43:30 2009
From: chris at eidhof.nl (Chris Eidhof)
Date: Fri Apr 24 09:29:28 2009
Subject: Proposal: rename Data.Map.fromAscList to
	Data.Map.unsafeFromAscList
In-Reply-To: <5462653.20090424172623@gmail.com>
References: <DA0FC8C6-22C3-438D-A109-E1208FF8F8B2@eidhof.nl>
	<49F1B235.8030806@dfki.de>
	<404396ef0904240551o7fc143eve87cfda6826b01d2@mail.gmail.com>
	<C2126036-6EA6-4F0E-844D-FEF230C2E1D4@eidhof.nl>
	<5462653.20090424172623@gmail.com>
Message-ID: <582FB4C5-88A4-4D70-8C04-67B314906B2C@eidhof.nl>

On 24 apr 2009, at 15:26, Bulat Ziganshin wrote:

> Hello Chris,
>
> Friday, April 24, 2009, 5:21:20 PM, you wrote:
>
>> No, but the functions you mentioned do fail immediately. If I use a
>> head on an empty list I get an error immediately. If I use  
>> fromAscList
>> incorrectly I get an error only when I try to lookup elements. This
>> makes it hard to debug if you didn't make this error before. I don't
>> mind a runtime error in this case, but I very much want to know where
>> my bug is.
>
> how about providing such check only in *debugging* version of library?

That would give different semantics in two cases, suppose:

 > main = mapM dangerousFunction (toList (fromAscList [(1,0),(0,0)]))

When doing it without checks, this would fail after a couple of IO  
operations. When doing this with a check the function wouldn't do any  
IO at all.

-chris
From gtener at gmail.com  Fri Apr 24 09:48:13 2009
From: gtener at gmail.com (=?UTF-8?Q?Krzysztof_Skrz=C4=99tnicki?=)
Date: Fri Apr 24 09:34:13 2009
Subject: Proposal: rename Data.Map.fromAscList to 
	Data.Map.unsafeFromAscList
In-Reply-To: <5462653.20090424172623@gmail.com>
References: <DA0FC8C6-22C3-438D-A109-E1208FF8F8B2@eidhof.nl>
	<49F1B235.8030806@dfki.de>
	<404396ef0904240551o7fc143eve87cfda6826b01d2@mail.gmail.com>
	<C2126036-6EA6-4F0E-844D-FEF230C2E1D4@eidhof.nl>
	<5462653.20090424172623@gmail.com>
Message-ID: <220e47b40904240648g78ee5026o9aee3f43426bc011@mail.gmail.com>

On Fri, Apr 24, 2009 at 15:26, Bulat Ziganshin <bulat.ziganshin@gmail.com>wrote:

> Hello Chris,
>
> Friday, April 24, 2009, 5:21:20 PM, you wrote:
>
> > No, but the functions you mentioned do fail immediately. If I use a
> > head on an empty list I get an error immediately. If I use fromAscList
> > incorrectly I get an error only when I try to lookup elements. This
> > makes it hard to debug if you didn't make this error before. I don't
> > mind a runtime error in this case, but I very much want to know where
> > my bug is.
>
> how about providing such check only in *debugging* version of library?
>

I think the decision whether to include specific check should be left up to
the developer. Perhaps I would like to retain only a subset of checks, while
debugging version restricts my freedom and I would end up writing my own
version. Giving functions with and without checks is a good way of giving
such freedom.

Regards

Christopher Skrz?tnicki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20090424/99229e28/attachment.htm
From sfvisser at cs.uu.nl  Fri Apr 24 09:50:15 2009
From: sfvisser at cs.uu.nl (Sebastiaan Visser)
Date: Fri Apr 24 09:36:20 2009
Subject: Proposal: rename Data.Map.fromAscList to
	Data.Map.unsafeFromAscList
In-Reply-To: <404396ef0904240551o7fc143eve87cfda6826b01d2@mail.gmail.com>
References: <DA0FC8C6-22C3-438D-A109-E1208FF8F8B2@eidhof.nl>
	<49F1B235.8030806@dfki.de>
	<404396ef0904240551o7fc143eve87cfda6826b01d2@mail.gmail.com>
Message-ID: <AAA2FB42-4368-4EB5-BDE0-8EC4BF4D5530@cs.uu.nl>

On Apr 24, 2009, at 2:51 PM, Neil Mitchell wrote:

> Hi,
>
> I totally disagree. unsafe/unchecked means nothing other than "beware
> of the bogey monster", or for most Haskell users, "just another
> function that might launch missiles". fromAscList has the specific
> precondition for this function in the name. Should we call unsafeHead?
> uncheckedHead? mightCrashIfNotConsHead?
>
> Adding a check for the precondition would be the ideal thing to do,
> but I wouldn't want to do it if it added an extra comparison or was
> any runtime cost at all. Perhaps adding checkedFromAscList might be
> acceptable, but I can't imagine anyone would call it until they'd got
> it wrong the first time, at which point the chances of them getting it
> wrong again are quite low.
>
> Thanks
>
> Neil
>
> On Fri, Apr 24, 2009 at 1:36 PM, Christian Maeder
> <Christian.Maeder@dfki.de> wrote:
>>
>> ...

Personally I very much hope that Haskell' will change the definition  
of head to a safe version and include the current head function as  
unsafeHead. Encouraging developers to use and write total function is  
probably a good thing and prevents us from having to explain all those  
messy corners in the Haskell language to our Ruby and Python friends.

Adding a new function safeFromAscList that actually checks the  
precondition and returns a |Maybe (Map a b)| may sound as a nice  
compromise, but shouldn't all function be safe by default? I'd much  
rather see to version of which one is called the `unsafe' than two  
version of which one is called `safe'.

Safe feels like a safe default.

--
Sebastiaan
From wren at community.haskell.org  Fri Apr 24 19:30:05 2009
From: wren at community.haskell.org (wren ng thornton)
Date: Fri Apr 24 19:16:05 2009
Subject: Proposal: rename Data.Map.fromAscList
	to	Data.Map.unsafeFromAscList
In-Reply-To: <1DDB3035-7B8A-45C0-8DF4-7EB5D7C3C360@eidhof.nl>
References: <DA0FC8C6-22C3-438D-A109-E1208FF8F8B2@eidhof.nl>	<220e47b40904240514x3ea815b9pc50999b975e948f6@mail.gmail.com>
	<1DDB3035-7B8A-45C0-8DF4-7EB5D7C3C360@eidhof.nl>
Message-ID: <49F24B7D.9070500@community.haskell.org>

Chris Eidhof wrote:
> I really like that, Krzysztof. That way there's still the power to do it 
> efficiently but at least you know when you're doing things in an 
> erroneous way. My problem with the current way of doing this is that you 
> get errors in a place where you didn't expect them.
> 
> -chris
> 
> On 24 apr 2009, at 14:14, Krzysztof Skrz?tnicki wrote:
> 
>> On the second thought, another thing can be made. Since we know that 
>> fromAscList should take a list of ascending items, we can check 
>> whether it is sorted. If this precondition is not met, we simply call 
>> error. We also rename current fromAscList to unsafeFromAscList. This 
>> is similar to index and unsafeIndex from arrays code.
>>
>> What do you think about this solution?

+1

Depending on the strictness qualities of (un-)safeFromAscList[1], the 
safeFromAscList version could do this check "online" rather than 
scanning the list to verify and then calling unsafeFromAscList[2], which 
would be helpful for list fusion (assuming foldr is used).



[1] Which I think are already strict enough to give the behavior we want.

[2] Impl: just keep a copy of the previous key, if the next key isn't 
monotone then error.

-- 
Live well,
~wren
From xaotuk at gmail.com  Sat Apr 25 05:18:01 2009
From: xaotuk at gmail.com (Sasha Shipka)
Date: Sat Apr 25 05:04:05 2009
Subject: Takusen, postgres and boolean fields
Message-ID: <440a9a950904250218j3ef4eeds393586de025ba6d8@mail.gmail.com>

Let say one has to do something similar to this:

execDML $ cmdbind (sql "update some_table set some_boolean_field = ?
where ...") [bindP True, ...]

When I do it, I have an error:

DBError ("42","804") 7 "ERROR:  42804: column \"some_boolean_field\"
is of type boolean but expression is of type text ..."
From ross at soi.city.ac.uk  Thu Apr 30 08:29:43 2009
From: ross at soi.city.ac.uk (Ross Paterson)
Date: Thu Apr 30 08:15:27 2009
Subject: Eliminate/move class Alternative
In-Reply-To: <gpk0n7$rb3$1@ger.gmane.org>
References: <gpk0n7$rb3$1@ger.gmane.org>
Message-ID: <20090430122943.GA6249@soi.city.ac.uk>

On Sun, Mar 15, 2009 at 11:50:15PM +0100, Ben Franksen wrote:
> I propose to remove class Alternative and functions depending on it
> (optional, some, and many) from Control.Applicative. They can be moved into
> a separate module Control.Alternative if people desire such a class, but I
> doubt that it has many useful applications, at least in its present form.

In my opinion, the "killer app" for Alternative is "Parsing Permutation
Phrases", by Arthur Baars, Andres Loeh and S. Doaitse Swierstra, Haskell
Workshop 2001.  I've just uploaded a package action-permutations based
on this.

> Rationale:
> 
> Although the idea behind Alternative, i.e. generalize some of the functions
> commonly found in parser combinator libs, is a nice one, it doesn't work
> too well in practice, /even/ for the case that has inspired it (namely
> parsers).
> 
> This is mostly due to the class method 'empty'.
> [...]
> Second, and more important, is that some parser libs would like to, but
> cannot offer a sensible implementation for it. For instance, any
> error-correcting library of parser combinators (like those invented by
> Swierstra & Duponcheel) need to construct a valid result even in case of a
> failed parse.

That's odd: I thought all of Doaitse's parsers had pFail :: p a.
From briqueabraque at yahoo.com  Thu Apr 30 16:00:54 2009
From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=EDcio?=)
Date: Thu Apr 30 15:50:53 2009
Subject: ANN: bindings-0.1
Message-ID: <gtd01k$qkb$1@ger.gmane.org>

Hi,

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bindings

This is a package aimed at library writers, not to the everyday
Haskell programmer. This the beggining of my goal to create a
set of packages like:

bindings-common
bindings-sqlite3
bindings-openusb
bindings-gsl
bindings-yourFavoriteLibrary


Those are not going to be Haskell style bindings. Instead,
what I want is to create a set of low level bindings to the
best libraries available, so that if you want to write your
Haskell wrap to a foreign library using the latest Haskell
features, you can do that relying on low level bindings that
are comprehensive, well tested and well behaved, and with all
problems regarding building and portability already solved in
the best way the community was able to do.

Beneficts you get by using it:

- If 10 people are trying to write modules over, say, 'gsl',
all of then will help contribute with bug-hunting and thoughts
to the common package 'bindings-gsl'.

- Use your time to write cool experiences with GADTs and Template
Haskell. Leave the boring low level stuff to 'bindings-*'.

- HUnit tests can be created to all bindings. If you suggest
one in a ticket, and it does hold, it will be added to a test
package.


If you know library 'foo' very well, you won't need to read the
documentation for 'bindings-foo'. A set of guidelines ensure
that all these low-level bindings can be used after the original
library documentation. If you know the guidelines and you know
'foo', you can use 'bindings-foo' after reading in the worst
case just a few comments.

These guidelines, actually, are community driven. You can find
the current set here:

http://hackage.haskell.org/packages/archive/bindings/0.1/doc/html/Bindings.html

If you want changes or features, just open a ticket at package
home:

http://bitbucket.org/mauricio/bindings


What I really need now is help from libraries experts. If
you know your favorite library very well (specially its build
process and compile time options) and are willing to answer a
few questions on how it works, I'll add a binding to it.

This package is a byproduct of professional, paid work. If it
achieves some success, it will be maintained in the long term
and, if something important depends on it, I'm willing to give
maintenance to someone better than me.

Best,
Maur?cio

From simon.hengel at wiktory.org  Thu Apr 30 16:09:51 2009
From: simon.hengel at wiktory.org (Simon Hengel)
Date: Thu Apr 30 15:55:36 2009
Subject: Data.Map.assocs vs. Data.Map.toAscList
Message-ID: <20090430200951.GA4439@john>

In Data.Map we have three functions that do exactly the same thing
(assocs, toAscList, toList), two of them (assocs, toAscList) by
definition.

Is this by design? What about deprecating at least one of them?

Cheers,
Simon Hengel
From ml at isaac.cedarswampstudios.org  Thu Apr 30 21:22:52 2009
From: ml at isaac.cedarswampstudios.org (Isaac Dupree)
Date: Thu Apr 30 21:08:40 2009
Subject: ANN: bindings-0.1
In-Reply-To: <gtd01k$qkb$1@ger.gmane.org>
References: <gtd01k$qkb$1@ger.gmane.org>
Message-ID: <200904302122.52758.ml@isaac.cedarswampstudios.org>

Maur?cio wrote:
> These guidelines, actually, are community driven. You can find
> the current set here:
>
> http://hackage.haskell.org/packages/archive/bindings/0.1/doc/html/Bindings.
>html

Prefixing uppercase with underscore seems wrong; some people think we should 
have "caseless underscore".  Is simply lowercasing the first letter a bad 
policy?

"All foreign functions are declared safe. Also, they should all result in a 
System.IO.IO, even when they are supposed to be effect-free."  This may be 
insufficient for some speed purposes: probably we'll just wait and see.

class Bindings.Utilities.Callback confuses me. Do you have an example where 
it's used/needed?

This generally looks practical for bindings to C.  For binding to fancier 
languages such as Python (even if we had the technology to do so), some 
further design decisions might have to be made.

-Isaac

From briqueabraque at yahoo.com  Thu Apr 30 22:28:04 2009
From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=)
Date: Thu Apr 30 22:14:00 2009
Subject: ANN: bindings-0.1
In-Reply-To: <200904302122.52758.ml@isaac.cedarswampstudios.org>
References: <gtd01k$qkb$1@ger.gmane.org>
	<200904302122.52758.ml@isaac.cedarswampstudios.org>
Message-ID: <gtdmnl$kqp$1@ger.gmane.org>

>> These guidelines, actually, are community driven. You can find
>> the current set here:
>>
>> http://hackage.haskell.org/packages/archive/bindings/0.1/doc/html/Bindings.html

 > Prefixing uppercase with underscore seems wrong; some people
 > think we should have "caseless underscore".  Is simply
 > lowercasing the first letter a bad policy?

No. As long as it is a policy. If I get feedback, anything can
be changed.

 >> "All foreign functions are declared safe. Also, they should
 >> all result in a System.IO.IO, even when they are supposed
 >> to be effect-free."

 > This may be insufficient for some speed purposes: probably
 > we'll just wait and see.

Yes, maybe I'm beeing paranoid here. There are many ways in
which exceptions can be safely accepted.

 > class Bindings.Utilities.Callback confuses me. Do you have
 > an example where it's used/needed?

The point here was just to avoid a complicated policy on callback
names. To see an example, check the C code in the botton of the
page below:

http://sqlite.org/quickstart.html

There's a corresponding file named '5minutes.hs' in the
distribution where a callback type is used. Maybe a different
policy on how to type and use callbacks could be done.

 > (...) For binding to fancier languages such as Python (even if
 > we had the technology to do so), some further design decisions
 > might have to be made.

Sure. Thanks for your thoughts!
Maur?cio