Re: some comments about bytestring-show package

On Wed, Mar 25, 2009 at 11:54 PM, Manlio Perillo
<manlio.perillo <at> 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

Re: some comments about bytestring-show package

Bas van Dijk ha scritto:
> On Wed, Mar 25, 2009 at 11:54 PM, Manlio Perillo
> <manlio.perillo <at> 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

cabal: confusing dependencies conflict between ghc-6.10.1 and process

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?

Re: cabal: confusing dependencies conflict between ghc-6.10.1 and process

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 <at> haskell.org/msg52659.html

Re: cabal: confusing dependencies conflict between ghc-6.10.1 and process

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

Re: System.Posix.User: make get{Group,User}EntryFor* more portable

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

Re: [network] #1: unpackFamily on Windows fails match

#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

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

[network] #6: Network.Socket.sClose should change socket status

#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

 ----

Re: [network] #6: Network.Socket.sClose should change socket status

#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

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

Re: [network] #6: Network.Socket.sClose should change socket status

#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

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries