[Haskell-cafe] ANNOUNCE: text and text-icu, fast and comprehensive Unicode support using stream fusion

[Bryan O'Sullivan]

On behalf of the Data.Text team, I am delighted to announce the release of
preview versions of two new packages:

text 0.1
Fast, packed Unicode text support, using a modern stream fusion framework.
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/text

text-icu 0.1
Augments text with comprehensive character set conversion support and
normalization (and soon more), via bindings to the ICU library.
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/text-icu

These packages fill out critical pieces of functionality for the Haskell
platform, without compromising on either performance or safety.

We are referring to these as *preview* releases because although the text
package in particular has been quite heavily tested, it has not been
thoroughly tuned, and we have not yet implemented a chunked lazy text
representation suitable for streaming gigabytes of data. The APIs are pretty
conventional, but are still subject to change.

If you want to contribute, please get copies of the source trees from here:

darcs get http://code.haskell.org/text
darcs get http://darcs.serpentine.com/text-icu

Please send bug reports and patches to your friendly Data.Text team:

Tom Harper 
Duncan Coutts 
Bryan O'Sullivan 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

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

[Thomas Davie]

On 27 Feb 2009, at 08:17, Arne Dehli Halvorsen wrote:


Manuel M T Chakravarty wrote:

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


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


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


Good advice, but I've generally found the MacPorts version more  
consistantly built – plus, sudo port install ghc is nice and easy :)



Hi, following on from this point:

How does one get gtk2hs running on a mac?

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

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

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

gtk2hs 0.10?


For me, this worked:
sudo port install ghc
sudo port install gtk2
sudo port install cairomm
curl http://downloads.sourceforge.net/gtk2hs/gtk2hs-0.10.0.tar.gz >  
gtk2hs-0.10.0.tar.gz

tar xvfz gtk2hs-0.10.0.tar.gz
normal install stuff here.

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

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

[Wolfgang Jeltsch]

Am Donnerstag, 26. Februar 2009 21:39 schrieb Peter Hercek:
> The acceptable size of inlined fuctions for a C code is about 10 lines.
> I did not read any info how it would be for Haskell.

At least, GHC inlines very massively, to my knowledge. And I think you need 
this massive inlining for reasonable performance because of Haskell’s high 
level nature, lazy evaluation, etc.

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

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

[Wolfgang Jeltsch]

Am Donnerstag, 26. Februar 2009 20:20 schrieb Achim Schneider:
> Wolfgang Jeltsch  wrote:
> > Am Donnerstag, 26. Februar 2009 09:17 schrieb Ketil Malde:
> > > Peter Hercek  writes:
> > > >> Relinking against newer Gtk2Hs versions might not work.
> > >
> > > You have the option of recompiling the new Gtk2Hs with the old GHC
> > > and relinking, don't you?
> >
> > Relinking is technically not possible because of inlining.
>
> I don't think the situation is any different from providing C headers
> that contain macros or inline functions.

But as Peter Hercek said, the LGPL limits the amount of macro expansion for C 
libraries. And the amount of GHC’s inlining would probably exceed all 
limits. ;-) 

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

Re: [Haskell-cafe] ANNOUNCE: text and text-icu, fast and comprehensive Unicode support using stream fusion

[George Pollard]

On Fri, 2009-02-27 at 00:01 -0800, Bryan O'Sullivan wrote:


> text-icu 0.1
> Augments text with comprehensive character set conversion support and
> normalization (and soon more), via bindings to the ICU library.
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/text-icu

Excellent! I was just wishing for this two days ago :D


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

Re: [Haskell-cafe] ANNOUNCE: text and text-icu, fast and comprehensive Unicode support using stream fusion

[George Pollard]

Unfortunately it doesn’t build for me. I have libicu-dev 3.8.1
installed.

> $ cabal install text-icu
> Resolving dependencies...
> 'text-icu-0.1' is cached.
> Configuring text-icu-0.1...
> Preprocessing library text-icu-0.1...
> Error.hsc: In function ‘main’:
> Error.hsc:229: error: ‘U_ARGUMENT_TYPE_MISMATCH’ undeclared (first use in 
> this function)
> Error.hsc:229: error: (Each undeclared identifier is reported only once
> Error.hsc:229: error: for each function it appears in.)
> Error.hsc:230: error: ‘U_DUPLICATE_KEYWORD’ undeclared (first use in this 
> function)
> Error.hsc:231: error: ‘U_UNDEFINED_KEYWORD’ undeclared (first use in this 
> function)
> Error.hsc:232: error: ‘U_DEFAULT_KEYWORD_MISSING’ undeclared (first use in 
> this function)
> Error.hsc:260: error: ‘U_REGEX_OCTAL_TOO_BIG’ undeclared (first use in this 
> function)
> Error.hsc:261: error: ‘U_REGEX_INVALID_RANGE’ undeclared (first use in this 
> function)
> Error.hsc:262: error: ‘U_REGEX_STACK_OVERFLOW’ undeclared (first use in this 
> function)
> Error.hsc:263: error: ‘U_REGEX_TIME_OUT’ undeclared (first use in this 
> function)
> Error.hsc:264: error: ‘U_REGEX_STOPPED_BY_CALLER’ undeclared (first use in 
> this function)
> compiling dist/build/Data/Text/ICU/Error_hsc_make.c failed
> command was: /usr/bin/gcc -c -D__GLASGOW_HASKELL__=610 
> -I/usr/local/lib/ghc-6.10.1/bytestring-0.9.1.4/include 
> -I/usr/local/lib/ghc-6.10.1/base-4.0.0.0/include 
> -I/usr/local/lib/ghc-6.10.1/include -IPAPI_INCLUDE_DIR 
> dist/build/Data/Text/ICU/Error_hsc_make.c -o 
> dist/build/Data/Text/ICU/Error_hsc_make.o
> cabal: Error: some packages failed to install:
> text-icu-0.1 failed during the building phase. The exception was:
> exit: ExitFailure 1



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

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

[Colin Paul Adams]

> "Toby" == Toby Hutton  writes:

Toby> But I don't want to try and refactor the code you've
Toby> provided without some tests to ensure everything is correct.
Toby> Rule number one for refactoring. :) 

A very good reminder.

I'll write some simple (data, that is) test cases - I intend to
package it as a small library anyway - with type classes so I can
plug-in different search algorithms, and it's time I got to grips with
HUnit and QuickCheck.

   Anton> It's worth keeping in mind the lesson of the lambda
   Anton> calculus: that a local variable is just a
   Anton> function in disguise.

I'd never thought about that before.

Thanks to both of you for your suggestions. Most helpful.
-- 
Colin Adams
Preston Lancashire
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

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

[Johan Tibell]

On Fri, Feb 27, 2009 at 12:03 AM, Bryan O'Sullivan  wrote:
> On Thu, Feb 26, 2009 at 1:45 PM, Johan Tibell 
> wrote:
>>
>> I find it quite inconvenient to use the `recv` function in
>> Network.Socket as it throws an exception when reaching EOF and there's
>> no way to check whether EOF has been reached before calling `recv`.
>
> I agree, the current behaviour is quite unfortunate. In fact, I'm pretty
> sure I added an entry point named recv_ to network-bytestring to work around
> precisely this problem.

Yes, that's indeed the reason we added it. My current thinking is that
we'd drop `recv` from network-bytestring in favor of `recv_`. I've
checked how many libraries on Hackage depend on network-bytestring and
there are few enough that we could make such a change. It's a bit
unfortunate that these libraries have an open dependency on
network-bytestring (e.g. network-bytestring >= 0.1.1.2). I will
contact the maintainers of those libraries before making a new
release.

> There's another problem with the network APIs: they mirror the BSD socket
> API too faithfully, and provide insufficient type safety. You can try to
> send on an unconnected socket, and to bind a socket that's already
> connected, both of which should be statically forbidden. The APIs for
> datagram-oriented networking ought to be distinct from the stream-oriented
> variety, I think, even if the underlying C-level calls end up being
> substantially the same.
>
> Really, the big thing that's missing here is enough application of elbow
> grease from someone who's got a good eye for design and doesn't mind all the
> slog involved. I think that if someone published a network-alt package (much
> like the one that was published a few years ago) and tooted their horn
> vigorously enough, we could put the existing network package out to pasture
> in fairly short order.

I would be interested in trying to create a better API. However, I'm
not sure what it would look like. The design space is pretty big.

* How can we provide the static guarantees we want? Perhaps with some
kind of lightweight monadic regions but if so which definition should
we use i.e. can a region return a Socket to the parent region or not?
This has implications on how easy the API is to understand.

* Should we use enumerators or not? Can they be added as a convenience
layer on top of type safe low-level layer?

Cheers,

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

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

[Johan Tibell]

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

I would very much like that. However, even after thinking about the
problem for several problems I don't know of a generic definition that
feels right. Hopefully someone smarter will come up with one.

Cheers,

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

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

[Johan Tibell]

2009/2/27 Brandon S. Allbery KF8NH :
> On 2009 Feb 26, at 23:41, Achim Schneider wrote:
>> "Brandon S. Allbery KF8NH"  wrote:
>>> On 2009 Feb 26, at 16:45, Johan Tibell wrote:
>>> Anyway, the reason recv doesn't return 0 is that if you have a
>>> datagram socket, a zero-length recv is valid and doesn't mean EOF.
>>>
>> My man page says a retval of 0 means that "the peer has performed an
>> orderly shutdown", which, in the UDP case, means that it has send a
>> complete datagram... no mention of EOF. A true EOF in the sense of "no
>> more data will be received" would mean unbinding the socket.
>
> Right.  Just have to realize that a zero-length datagram packet is possible
> and even meaningful, so 0 isn't available as an EOF flag.

If this is the case then the Network.Socket module is broken when used
for UDP as it throw an exception on receiving a valid message.

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

I'm not sure I agree. I think using exceptions in this case is fine as
loosing the connection is indeed an exceptional condition and the best
thing a program can do in this case is probably to abort processing of
the disconnected client.

Cheers,

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

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

[Colin Paul Adams]

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

Johan> I'm not sure I agree. I think using exceptions in this case is fine as
Johan> loosing the connection is indeed an exceptional condition and the best
Johan> thing a program can do in this case is probably to abort processing of
Johan> the disconnected client.

I guess this depends upon how exceptional you want an exception to be.

To my mind, a lost connection is a fairly normal condition (FAR to
normal for my teleworking situation :-( ). That is, I would expect
the exception to occur rather than not, during one run of a
program. On that basis, I would suggest Nothing is better than an
exception.

But I guess it depends upon the program. For long running servers,
my expectation above is surely true. But other "servers" might not
share the same expectation.
Perhaps it should be configurable?

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

Re: [Haskell-cafe] Performance question

[Lennart Augustsson]

The random() function is only marginally better than rand().

On Fri, Feb 27, 2009 at 6:50 AM, Ketil Malde  wrote:
> Lennart Augustsson  writes:
>
>> C's rand() function is very bad and should never be used really.
>
> On Linux (really GNU libc, I suppose) it is the same as random().  But
> for portability, one is encouraged to spend the two extra letters.  I
> don't understand the details, but I think the Mersenne twister is much
> better in any case.
>
> -k
> --
> If I haven't seen further, it is by standing in the footprints of giants
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

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

[Arne Dehli Halvorsen]

Thomas Davie wrote:

For me, this worked:
sudo port install ghc
sudo port install gtk2
sudo port install cairomm
curl http://downloads.sourceforge.net/gtk2hs/gtk2hs-0.10.0.tar.gz > 
gtk2hs-0.10.0.tar.gz

tar xvfz gtk2hs-0.10.0.tar.gz
normal install stuff here.


It worked!
I had to throw out gtk2, which was present in an incompatible version.

Then I did make/make install, and tried compiling a few apps in the demo 
catalog.

Most of them show up, but with these errors:
Xlib:  extension "RANDR" missing on display "/tmp/launch-UoNAfJ/:0".
Xlib:  extension "Generic Event Extension" missing on display 
"/tmp/launch-UoNAfJ/:0".


Testing out the demos, it seems it can't find
Graphics.UI.Gtk.Glade,
Graphics.Rendering.OpenGL
System.Gnome.GConf
System.Gnome.VFS
Media.Streaming.GStreamer
Graphics.UI.Gtk.MozEmbed
Graphics.UI.Gtk.SourceView
Graphics.Rendering.Cairo.SVG


Any idea on whether I should:
port install some package
port install some package + reinstall gtk2hs
haskell install some package
haskell install some package + reinstall gtk2hs?



In pango, I get
Layout.hs:41:44: Not in scope: type constructor or class `Event'
Layout.hs:42:20: Not in scope: data constructor `Expose'
..but I got that on Windows too.

...and demo/arabic does not show any arabic




Bob



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

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

[Thomas Davie]

On 27 Feb 2009, at 11:21, Arne Dehli Halvorsen wrote:


Thomas Davie wrote:

For me, this worked:
sudo port install ghc
sudo port install gtk2
sudo port install cairomm
curl http://downloads.sourceforge.net/gtk2hs/gtk2hs-0.10.0.tar.gz >  
gtk2hs-0.10.0.tar.gz

tar xvfz gtk2hs-0.10.0.tar.gz
normal install stuff here.


It worked!
I had to throw out gtk2, which was present in an incompatible version.

Then I did make/make install, and tried compiling a few apps in the  
demo catalog.

Most of them show up, but with these errors:
Xlib:  extension "RANDR" missing on display "/tmp/launch-UoNAfJ/:0".
Xlib:  extension "Generic Event Extension" missing on display "/tmp/ 
launch-UoNAfJ/:0".

Yep, I see these errors too – even after sudo port install randr.


Testing out the demos, it seems it can't find
Graphics.UI.Gtk.Glade,
Graphics.Rendering.OpenGL
System.Gnome.GConf
System.Gnome.VFS
Media.Streaming.GStreamer
Graphics.UI.Gtk.MozEmbed
Graphics.UI.Gtk.SourceView
Graphics.Rendering.Cairo.SVG
Perhaps the demos are out of date?  Graphics.Rendering.OpenGL is found  
in the OpenGL package, and System.Gnome looks unlikely to work on OS X.


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

[Haskell-cafe] Missing documentation for Haddock

[Colin Paul Adams]

On http://haskell.org/haddock/doc/html/module-attributes.html the
not-home attribute is missing (it's documentation is present, but the
attribute itself is not named).
-- 
Colin Adams
Preston Lancashire
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Missing documentation for Haddock

[David Waern]

2009/2/27 Colin Paul Adams :
> On http://haskell.org/haddock/doc/html/module-attributes.html the
> not-home attribute is missing (it's documentation is present, but the
> attribute itself is not named).

Thanks for the report.

By the way, the Haddock trac page is at:

  http://trac.haskell.org/haddock

We also have a mailing list:

  hadd...@projects.haskell.org

I will fix this bug directly, so we don't need a bug ticket of course.
But it may be nice for you to know where to report bugs in the future.

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

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

[Holger Siegel]

Am Donnerstag, den 26.02.2009, 20:54 + schrieb Colin Paul Adams:
> Hello Haskellers,
> 
> I want to implement the negascout algorithm for the game I'm writing.
> 
> Wikipedia gives the algorithm in imperative terms:
> 
> http://en.wikipedia.org/wiki/Negascout
> 
> I've tried to translate this into Haskell. I'm not sure if I'm going
> about it the right way, and if I am, if I've done it correctly.
> 
> 
> Any comments on my effort here, are welcome:

A more systematic transformation may lead to a more efficient
loop:

In the pseudocode, I have replaced the first conditional with the max
function and pulled the calculation of (depth - 1) out of the loop:

function negascout(node, depth, alpha, beta)
if node is a terminal node or depth = 0
return the heuristic value of node
b := beta
d := depth - 1
foreach child of node
alpha := max(alpha, -negascout (child, d, -b, -alpha))
if alpha >= beta
return alpha
if alpha >= b
   alpha := -negascout(child, d, -beta, -alpha)
   if alpha >= beta
   return alpha
b := alpha+1
return alpha


In order to make this more Haskell-ish, we assume three self-explaining
functions:

> terminal:: Node -> Bool
> heuristicValue  :: Node -> Int
> children:: Node -> [a]

(Idiomatic) Haskell does not use mutable state or conditionals without
else-branch, so we make three modifications:

1) We use pattern matching for the first conditional
 
2) Every other conditional

 if c then a
 rest

   is rewritten as

 if c
 then do a
 rest
 else rest
 
   and

 do return x
rest

   is abbreviated as

 return x

   (Here, 'return' is the imperative return statement, not the monadic
   unit)

3) We bring the program into single static assignment form. That is, we
   introduce new variables, so that every variable is assigned to only
   once. This is not always possible, because the loop would require
   us to introduce an unknown number of variables. Therefore, we allow
   reassignments at the end of an iteration.

And there it is, written in Haskell-like pseudocode:

> negascout :: Node -> Int -> Int -> Int -> Int
> negascout node depth alpha beta
> | terminal node || depth == 0
> = heuristicValue node
> | otherwise
> = do b := beta
>  d := depth - 1
>  foreach child of node do
>  alpha' := max(alpha, - negascout child d (-b)
(-alpha))
>  if alpha' >= beta
>  then return alpha'
>  else if alpha' >= b
>   then do alpha'' := - negascout child d (-beta)
(-alpha')
>   if alpha'' >= beta
>   then return alpha''
>   else do alpha := alpha''
>   b := alpha'' + 1
>   else do alpha := alpha'
>   b := alpha' + 1
>  return alpha

Now we see that only alpha and b are modified by the loop. From that it
follows how the loop can be turned into a recursive function: This
function takes alpha, b and the list of remaining children as its
argument:

> negascout node depth alpha beta
>| terminal node || depth == 0
>= heuristicValue node
>| otherwise
>= loop alpha beta (children node)
>where
>d = depth - 1
>loop alpha b (c:cs) 
>= let alpha' = max(alpha, - negascout c d (-b) (-alpha))
>  in if alpha' >= beta
> then alpha'
> else if alpha' >= b
>  then let alpha'' = - negascout c d (-beta) (-alpha')
>   in if alpha'' >= beta
>  then alpha''
>  else loop alpha'' (alpha'' + 1) cs 
>  else loop alpha' (alpha' + 1) cs
>loop alpha _ [] = alpha

Now you can move around the declarations, introduce some nice guards,
optimize the calls where b==alpha+1 or beta==alpha+1 and hunt for
hidden folds.

(Warning: I didn't test it)



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

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

[Arne Dehli Halvorsen]

Thomas Davie wrote:

Testing out the demos, it seems it can't find
Graphics.UI.Gtk.Glade,
Graphics.Rendering.OpenGL
System.Gnome.GConf
System.Gnome.VFS
Media.Streaming.GStreamer
Graphics.UI.Gtk.MozEmbed
Graphics.UI.Gtk.SourceView
Graphics.Rendering.Cairo.SVG
Perhaps the demos are out of date?  Graphics.Rendering.OpenGL is found 
in the OpenGL package, and System.Gnome looks unlikely to work on OS X.

Did a macports install of glade (took ages!), gtkglext, gconf, glut.
Reran configure/make/make install for gtk2hs

Also did macports install of hs-cabal, then
cabal update
cabal install opengl
cabal install glut

Was a little confused for a while because Porticus (ports GUI) was out 
of date.


Maybe I could have installed ghc, hs-cabal + all gtk preconditions, and 
then installed gtk2hs++ via cabal?


Anyway, the opengl demo and the glade demos run now, and if I need 
mozembed and similar, I trust I will be able to get them in in a similar 
way.


Thanks for helping, I am looking forward to creating GUIs.



Bob


Arne D Halvorsen

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

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

[Bulat Ziganshin]

Hello Eugene,

Thursday, February 26, 2009, 10:28:13 PM, you wrote:

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

does this mean that type classes from Edison and Container (Collection?)
libraries are not good enough or you don't checked them?


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

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

Re: [Haskell-cafe] ByteString questions

[Peter Verswyvelen]

isn't this sufficient? might require some more Win32 bindings...
http://msdn.microsoft.com/en-us/library/ms810467.aspx


2009/2/27 Galchin, Vasili 

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

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

[Eugene Kirpichov]

I'm exactly basing on them, but they don't have at least these things:
 - Monad-mutable collections like MArray
 - Instances of something like Assoc for arrays (arrays are
collections in some sense, after all)
 - Treatment for unboxed types (I don't know yet, whether it is
needed; but why do STUArrays have special treatment then?)

It's not that I am in desperate need for these, but making the
already-good collection API even better sounds like fun :)

Actually, it started with me writing a monad-mutable hashtable and
thinking about what its interface should be, so probably I should just
upload the hashtable to hackage as is and look what comes next :)


2009/2/27 Bulat Ziganshin :
> Hello Eugene,
>
> Thursday, February 26, 2009, 10:28:13 PM, you wrote:
>
>> Thanks, I'll have a look at these. Treating unboxed stuff
>> polymorphically is anyways very interesting and would be good to use
>> in collections API that has been recently discussed (and which I
>> occasionally try to continue inventing with scarce success :-/ ).
>
> does this mean that type classes from Edison and Container (Collection?)
> libraries are not good enough or you don't checked them?
>
>
> --
> Best regards,
>  Bulat                            mailto:bulat.zigans...@gmail.com
>
>



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

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

[Bulat Ziganshin]

Hello Eugene,

Friday, February 27, 2009, 4:42:03 PM, you wrote:

> I'm exactly basing on them, but they don't have at least these things:

"them" means Edison or Collections typeclasses?

>  - Treatment for unboxed types (I don't know yet, whether it is
> needed; but why do STUArrays have special treatment then?)

imho, this doesn't need its own typeclass

> Actually, it started with me writing a monad-mutable hashtable and
> thinking about what its interface should be, so probably I should just
> upload the hashtable to hackage as is and look what comes next :)

what are the differences against Data.Hashtable?


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

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

[Haskell-cafe] Re: ANNOUNCE: pqueue-mtl, stateful-mtl

[Chung-chieh Shan]

Ryan Ingram  wrote in article 
<2f9b2d30902151615n1e8e25e8ubbee20d93c8ec...@mail.gmail.com> in 
gmane.comp.lang.haskell.cafe:
> You can roll your own pure STT monad, at the cost of performance:

Do you (or anyone else) know how to prove this STT implementation
type-safe?  It seems to be safe but I'm not sure how to prove it.

-- 
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
A mathematician is a device for turning coffee into theorems.
Paul Erdos (1913-1996)

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

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

[Eugene Kirpichov]

2009/2/27 Bulat Ziganshin :
> Hello Eugene,
>
> Friday, February 27, 2009, 4:42:03 PM, you wrote:
>
>> I'm exactly basing on them, but they don't have at least these things:
>
> "them" means Edison or Collections typeclasses?
The EdisonAPI.

>
>>  - Treatment for unboxed types (I don't know yet, whether it is
>> needed; but why do STUArrays have special treatment then?)
>
> imho, this doesn't need its own typeclass
I hope so :)

>
>> Actually, it started with me writing a monad-mutable hashtable and
>> thinking about what its interface should be, so probably I should just
>> upload the hashtable to hackage as is and look what comes next :)
>
> what are the differences against Data.Hashtable?
>
Support for ST monad and stuff like insertWith, mergeWith.

>
> --
> Best regards,
>  Bulat                            mailto:bulat.zigans...@gmail.com
>
>



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

[Haskell-cafe] Hidden module?

[Cristiano Paris]

Cabalising hsc2hc I get (this is actually from manually building the package):

---
[pa...@bagend hsc2hs-0.67.20061107]$ runghc Setup.hs build
Preprocessing executables for hsc2hs-0.67.20061107...
Building hsc2hs-0.67.20061107...

Main.hs:32:7:
Could not find module `System.Process':
  it is a member of package process-1.0.1.0, which is hidden
[pa...@bagend hsc2hs-0.67.20061107]$

which I cannot understand. Please help!
---

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

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

[David Leimbach]

On Fri, Feb 27, 2009 at 12:04 AM, Thomas Davie  wrote:

>
> On 27 Feb 2009, at 08:17, Arne Dehli Halvorsen wrote:
>
>  Manuel M T Chakravarty wrote:
>>
>>> I'm planning to purchase a MacBookPro so I'm wondering how well
 Haskell is supported under this platform.

>>>
>>> At least two of the regular contributors to GHC work on Macs.  That
>>> should ensure that Mac OS X is well supported.  Installation is trivial with
>>> the Mac OS X installer package:
>>>
>>>  http://haskell.org/ghc/download_ghc_6_10_1.html#macosxintel
>>>
>>
> Good advice, but I've generally found the MacPorts version more
> consistantly built – plus, sudo port install ghc is nice and easy :)


Does the MacPort have GMP linked statically or dynamically?  I haven't
gotten around to trying to build things with a dynamic libgmp yet... but
it's not fun to have LGPL statically linked stuff if you care about your own
licensing terms.


>
>
>  Hi, following on from this point:
>>
>> How does one get gtk2hs running on a mac?
>>
>> I have a MacBook Pro, and I've had ghc installed for some time now.
>>
>> (first in 6.8.2 (packaged),
>> then 6.10.1 (packaged),
>> then 6.8.2 via macports 1.6
>> then 6.10.1 via macports 1.7)
>>
>> I tried to install gtk2hs via macports, but it didn't work.
>> (0.9.12? on 6.8.2, then on 6.10.1)
>> Is there a recipe one could follow?
>> Can I get the preconditions via macports, and then use cabal to install
>> gtk2hs 0.10?
>>
>
> For me, this worked:
> sudo port install ghc
> sudo port install gtk2
> sudo port install cairomm
> curl http://downloads.sourceforge.net/gtk2hs/gtk2hs-0.10.0.tar.gz >
> gtk2hs-0.10.0.tar.gz
> tar xvfz gtk2hs-0.10.0.tar.gz
> normal install stuff here.
>
> Bob___
>
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hidden module?

[Daniel Fischer]

Am Freitag, 27. Februar 2009 15:13 schrieb Cristiano Paris:
> Cabalising hsc2hc I get (this is actually from manually building the
> package):
>
> ---
> [pa...@bagend hsc2hs-0.67.20061107]$ runghc Setup.hs build
> Preprocessing executables for hsc2hs-0.67.20061107...
> Building hsc2hs-0.67.20061107...
>
> Main.hs:32:7:
> Could not find module `System.Process':
>   it is a member of package process-1.0.1.0, which is hidden
> [pa...@bagend hsc2hs-0.67.20061107]$
>
> which I cannot understand. Please help!
> ---
>
> Cristiano

Cabal hides all packages not listed among the build-depends when building the 
libraries. I think in 2006, System.Process was in the base package ('twas 
before the base-split), so process is not listed among the build-depends in 
hsc2hs' .cabal file.
Add it and try again.

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

Re: [Haskell-cafe] ANNOUNCE: text and text-icu, fast and comprehensive Unicode support using stream fusion

[minh thu]

2009/2/27 Bryan O'Sullivan :
> On behalf of the Data.Text team, I am delighted to announce the release of
> preview versions of two new packages:
>
> text 0.1
> Fast, packed Unicode text support, using a modern stream fusion framework.
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/text

This is a nice news. What is the preferred way to parse some Text ?

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

[Haskell-cafe] Re: [darcs-users] darcs and Google Summer of Code

[Eric Kow]

Hi,

(carefully avoiding your name :-P)

On Mon, Feb 23, 2009 at 16:08:18 +0100, Wolfgang Jeltsch wrote:
> Tomorrow, I will discuss with the first half of my student project students 
> (3 students) about what exact topic they will pursue. My idea is to let them 
> start a Grapefruit-based darcs GUI. They should not use the currenct darcs 
> interface directly where it doesn’t fit GUI frontends well. Instead they 
> should write a wrapper around the “ugly” parts which exposes a “nice” 
> interface. Later, one could merge this wrapper into the darcs codebase so 
> that darcs exports the “nice” interface then. The GUI code wouldn’t have to 
> change much then.

It would be interesting to see how they get on writing their wrapper
around the darcs "library" as opposed to making darcs invocations
(although if you were to go the latter route, I noticed that the
patch-tag folks have uploaded a 'DarcsHelpers' package which may be
of some use.

> In April, the second half of the students will start with their project. If 
> there is some graphics support in Grapefruit at that time then they might 
> work on a patch viewer.
> 
> What do you think about that?

In addition to my previous suggestion that the students hang out in
#darcs, maybe they could start some sort of blog detailing their
progress, and with the occasional screenshot?  It would be a great
addition to the darcs planet:

  http://planet.darcs.net

Thanks!

-- 
Eric Kow 
PGP Key ID: 08AC04F9


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

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

[Edsko de Vries]

I guess so. Maybe using mapAccum helps:

 import qualified Data.Map as M

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

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


Very clever. I had tried to use mapAccum but I couldn't figure out  
what to put in the accumulator. I didn't realize it didn't make a  
difference (unit will do) as long as it is evaluated when the Map is.


Seq wrecks my head ;)

Thanks!

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

[Haskell-cafe] Sparse vector operations

[Grzegorz Chrupala]

Hi all,
In a couple of my projects I have needed to perform operations on (very)
sparse vectors.
I came up with the attached simple module which defines a typeclass and
implements instances for
simple and nested (Int)Maps.
Is this the right way to go about it? Am I reinventing some wheels?
Comments welcome.
Best,
--

Grzegorz

http://www.nabble.com/file/p22247686/SparseVector.hs SparseVector.hs 
-- 
View this message in context: 
http://www.nabble.com/Sparse-vector-operations-tp22247686p22247686.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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

Re: [Haskell-cafe] ANNOUNCE: text and text-icu, fast and comprehensive Unicode support using stream fusion

[minh thu]

2009/2/27 minh thu :
> 2009/2/27 Bryan O'Sullivan :
>> On behalf of the Data.Text team, I am delighted to announce the release of
>> preview versions of two new packages:
>>
>> text 0.1
>> Fast, packed Unicode text support, using a modern stream fusion framework.
>> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/text
>
> This is a nice news. What is the preferred way to parse some Text ?

I mean it is straightforward to rewrite attoparsec to use Text instead of
(Lazy and Strict) Bytestring, but is it the way to go ?

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

[Haskell-cafe] Trouble building ArrayRef 0.1.3

[Mads Lindstrøm]

Hi

When I try to build ArrayRef 0.1.3 I get:

Control/Concurrent/LockingBZ.hs:159:54:
Ambiguous type variable `e' in the constraint:
  `Exception e'
arising from a use of `throw'
 at Control/Concurrent/LockingBZ.hs:159:54-60
Probable fix: add a type signature that fixes these type variable(s)


I am compiling with:

> runhaskell Setup.hs build

I run Debian Linux with GHC 6.10.1.

Anybody has a solution for my problem?


Greetings,

Mads Lindstrøm



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

Re: [Haskell-cafe] Hidden module?

[Cristiano Paris]

On Fri, Feb 27, 2009 at 3:19 PM, Daniel Fischer
 wrote:
>
> Cabal hides all packages not listed among the build-depends when building the
> libraries. I think in 2006, System.Process was in the base package ('twas
> before the base-split), so process is not listed among the build-depends in
> hsc2hs' .cabal file.
> Add it and try again.

I had to append process and directory as dependencies but then it
worked. How can I submit a patch to Hackage? Do I have to contact the
owner?

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

Re: [Haskell-cafe] Trouble building ArrayRef 0.1.3

[Bulat Ziganshin]

Hello Mads,

Friday, February 27, 2009, 6:27:52 PM, you wrote:

i made this lib back in the ghc 6.4 days, so it probably have a lot of
compatibility problems here and there :(  i'm self still use ghc 6.6 :)

> When I try to build ArrayRef 0.1.3 I get:

> Control/Concurrent/LockingBZ.hs:159:54:
> Ambiguous type variable `e' in the constraint:
>   `Exception e'
> arising from a use of `throw'
>  at Control/Concurrent/LockingBZ.hs:159:54-60
> Probable fix: add a type signature that fixes these type variable(s)


> I am compiling with:

>> runhaskell Setup.hs build

> I run Debian Linux with GHC 6.10.1.

> Anybody has a solution for my problem?


> Greetings,

> Mads Lindstrøm



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


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

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

Re: [Haskell-cafe] Sparse vector operations

[Don Stewart]

You might be duplicating the functionality of an existing library.

There are existing libraries for vectors (though not sure if blas
supports sparse vectors well?).

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

-- Don

grzegorz.chrupala:
> 
> Hi all,
> In a couple of my projects I have needed to perform operations on (very)
> sparse vectors.
> I came up with the attached simple module which defines a typeclass and
> implements instances for
> simple and nested (Int)Maps.
> Is this the right way to go about it? Am I reinventing some wheels?
> Comments welcome.
> Best,
> --
> 
> Grzegorz
> 
> http://www.nabble.com/file/p22247686/SparseVector.hs SparseVector.hs 
> -- 
> View this message in context: 
> http://www.nabble.com/Sparse-vector-operations-tp22247686p22247686.html
> Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
> 
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Trouble building ArrayRef 0.1.3

[Don Stewart]

bulat.ziganshin:
> Hello Mads,
> 
> Friday, February 27, 2009, 6:27:52 PM, you wrote:
> 
> i made this lib back in the ghc 6.4 days, so it probably have a lot of
> compatibility problems here and there :(  i'm self still use ghc 6.6 :)
> 
> > When I try to build ArrayRef 0.1.3 I get:
> 
> > Control/Concurrent/LockingBZ.hs:159:54:
> > Ambiguous type variable `e' in the constraint:
> >   `Exception e'
> > arising from a use of `throw'
> >  at Control/Concurrent/LockingBZ.hs:159:54-60
> > Probable fix: add a type signature that fixes these type variable(s)
> 
> 

It needs --constraint='base<4' when compiling.

Here, with cabal and ghc 6.10:

$ cabal install --constraint='base<4' arrayref
Resolving dependencies...
Downloading ArrayRef-0.1.3...
Configuring ArrayRef-0.1.3...
Preprocessing library ArrayRef-0.1.3...
Building ArrayRef-0.1.3...
[ 1 of 24] Compiling GHC.Unboxed  ( GHC/Unboxed.hs,
dist/build/GHC/Unboxed.o )
[ 2 of 24] Compiling Data.ArrayBZ.Internals.IArray (
Data/ArrayBZ/Internals/IArray.hs,
dist/build/Data/ArrayBZ/Internals/IArray.o )

...

Installing library in
/home/dons/.cabal/lib/ArrayRef-0.1.3/ghc-6.10.1
Registering ArrayRef-0.1.3...
Reading package info from "dist/installed-pkg-config" ... done.
Writing new package config file... done.

Thanks to Gwern, I believe, for packaging this up for hackage.

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

Re: [Haskell-cafe] ANNOUNCE: text and text-icu, fast and comprehensive Unicode support using stream fusion

[Bryan O'Sullivan]

On Fri, Feb 27, 2009 at 12:57 AM, George Pollard  wrote:

> Unfortunately it doesn’t build for me. I have libicu-dev 3.8.1 installed.
>

Yes, as the README states, the text-icu package needs ICU 4.0. The basic
text library has no such external dependencies.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: text and text-icu, fast and comprehensive Unicode support using stream fusion

[Bryan O'Sullivan]

On Fri, Feb 27, 2009 at 7:27 AM, minh thu  wrote:


> I mean it is straightforward to rewrite attoparsec to use Text instead of
> (Lazy and Strict) Bytestring, but is it the way to go ?
>

My first priority is to write Data.Text.Lazy, since I don't think that it
makes sense to layer a parsing library atop the current Data.Text module.
After that, porting Parsec3 and attoparsec should just be a matter of some
keyboarding.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Data.Binary, strict reading

[Duncan Coutts]

On Thu, 2009-02-26 at 09:17 +, Neil Mitchell wrote:

> > I suggest you use withFile instead and decode from the Handle that gives
> > you (via hGetContents) rather than decodeFile from the file name. That
> > makes it much clearer. Of course you have to avoid doing lazy stuff, but
> > that should be ok, Binary is strict in reading by default.
> 
> That was my first attempt, but the types didn't match up. I can
> withFile using a System.IO handle, but Data.Binary doesn't seem to be
> able to start going from a Handle. I guess I have to hop via the
> ByteString bit myself with hGetContents. That's perfectly fine, and
> much better than currently. However

Yes, you would use hGetContents.

> > readDB = io $ (dbLocation >>= r) `catch` (λ_ →  return empty)
> >   where r x = fmap (decode · BL.fromChunks · return) $ B.readFile x
> 
> This seems to be a very nice way of doing it, the strictness is
> explicit in the ByteString.readFile. I've gone for this in my code.

I still think my suggestion was nicer. It makes the resource boundedness
completely explicit, not relying on any strictness properties. It also
doesn't unnecessarily read the whole file into memory before processing,
though I expect for your example that doesn't matter too much.

Duncan

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

Re: [Haskell-cafe] differences between Data.Array and Data.Vector

[Don Stewart]

manlio_perillo:
> Hi.
>
> In Hackage there are some packages named "*array*", and others named  
> "*vector*".
>
> What are the differences?
>
>
> Is available a guide to the various data structures available in Haskell?
>

The vector packages tend to be either easily growable, or easily
fusible, or both.

There's no clear convention though.

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

Re: [Haskell-cafe] Re: ANNOUNCE: pqueue-mtl, stateful-mtl

[Ryan Ingram]

Hmm, that's a really good question now that you mention it.

So, the implementation given is trivially *not* type-safe; eventually
the Int index will wrap around and reuse indices at the potentially
wrong type.

But lets say you replaced IntMap with Map Integer, to avoid this problem.

A simple property: STTRefs cannot escape to another STT session.
Proof: See SPJ's original ST paper.

This is actually kind of useful on its own, because you can nest STTs
over each other to provide something like regions.

Then it comes down to, within a session, is there some way for an
STTRef to "mingle" and break the type-safety rule.  I can think of two
potential ways this might happen.  First, if the underlying monad is
something like List or Logic, there may be a way for STTRefs to move
between otherwise unrelated branches of the computation.  Second, if
the underlying monad is something like Cont, there may be a way for an
STTRef to get transmitted "back in time" via a continuation to a point
where it hadn't been allocated yet.

So if there is a counterexample I expect it to come down to one of
those two cases.

  -- ryan

On Thu, Feb 26, 2009 at 11:22 PM, Chung-chieh Shan
 wrote:
> Ryan Ingram  wrote in article 
> <2f9b2d30902151615n1e8e25e8ubbee20d93c8ec...@mail.gmail.com> in 
> gmane.comp.lang.haskell.cafe:
>> You can roll your own pure STT monad, at the cost of performance:
>
> Do you (or anyone else) know how to prove this STT implementation
> type-safe?  It seems to be safe but I'm not sure how to prove it.
>
> --
> Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
> A mathematician is a device for turning coffee into theorems.
> Paul Erdos (1913-1996)
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Making the pointfree package work with cabal

[Niemeijer, R.A.]

Today I was very happy to discover the pointfree package, since lambdabot 
unfortunately doesn't work on Windows. The package works just fine, but the 
installation process is less than ideal. "cabal install pointfree" doesn't work 
and to install it manually you have to add containers and array to the 
build-depends list in the cabal file. To get rid of the warning about the build 
type you have to add build-type: Simple.
I asked in the IRC channel what the best course of action was to fix this and 
they referred me here. The author of the package is Thomas Jäger, who should go 
by the IRC name TheHunter. I would hereby like to ask him to make these small 
changes and upload a new version, or to give me or someone else permission to 
do so.

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

Re: [Haskell-cafe] Trouble building ArrayRef 0.1.3

[Mads Lindstrøm]

Hi

For anyone who may care, I have googled a workaround. The problem below
is similar to the problem mentioned here
http://stackoverflow.com/questions/431527/ambiguous-type-variable-error-msg .

I wrote:
> Hi
> 
> When I try to build ArrayRef 0.1.3 I get:
> 
> Control/Concurrent/LockingBZ.hs:159:54:
> Ambiguous type variable `e' in the constraint:
>   `Exception e'
> arising from a use of `throw'
>  at Control/Concurrent/LockingBZ.hs:159:54-60
> Probable fix: add a type signature that fixes these type variable(s)
> 
> 
> I am compiling with:
> 
> > runhaskell Setup.hs build
> 
> I run Debian Linux with GHC 6.10.1.
> 
> Anybody has a solution for my problem?
> 
> 
> Greetings,
> 
> Mads Lindstrøm

/Mads


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

Re[2]: [Haskell-cafe] Trouble building ArrayRef 0.1.3

[Bulat Ziganshin]

Hello Mads,

Friday, February 27, 2009, 10:08:17 PM, you wrote:

http://haskell.org/haskellwiki/Upgrading_packages
is more appropriate, see 2.3

> Hi

> For anyone who may care, I have googled a workaround. The problem below
> is similar to the problem mentioned here
> http://stackoverflow.com/questions/431527/ambiguous-type-variable-error-msg

> I wrote:
>> Hi
>> 
>> When I try to build ArrayRef 0.1.3 I get:
>> 
>> Control/Concurrent/LockingBZ.hs:159:54:
>> Ambiguous type variable `e' in the constraint:
>>   `Exception e'
>> arising from a use of `throw'
>>  at Control/Concurrent/LockingBZ.hs:159:54-60
>> Probable fix: add a type signature that fixes these type variable(s)
>> 
>> 
>> I am compiling with:
>> 
>> > runhaskell Setup.hs build
>> 
>> I run Debian Linux with GHC 6.10.1.
>> 
>> Anybody has a solution for my problem?
>> 
>> 
>> Greetings,
>> 
>> Mads Lindstrøm

> /Mads


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


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

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

[Haskell-cafe] Re: Sparse vector operations

[Neal Alexander]

Grzegorz Chrupala wrote:

Hi all,
In a couple of my projects I have needed to perform operations on (very)
sparse vectors.
I came up with the attached simple module which defines a typeclass and
implements instances for
simple and nested (Int)Maps.
Is this the right way to go about it? Am I reinventing some wheels?
Comments welcome.
Best,
--

Grzegorz

http://www.nabble.com/file/p22247686/SparseVector.hs SparseVector.hs 


I've been working on a matrix/vector library over the last month.

The matrices are implemented as QuadTrees, using block decomposition 
techniques for various algorithms. Vectors were kind of an afterthought, 
but they are implemented as binary trees - the thought being that they 
would decompose symmetrically with matrices.


Sparsity comes free with this approach (more or less), and is already 
implemented. Divide and conquer based parallelism should fit nicely into 
the mix too, but i haven't got to that point.


From what I've tested so far, the performance is about the same as 
hmatrix and the various other matrix libraries on hackage. I've been 
trying to implement stream fusion for it over the last couple of days, 
but haven't been able to get it working right - maybe Dons can offer 
some advice.


For testing purposes, the uvector fusion based flat-matrix addition is 
twice as fast:


add a b = mapU (uncurryU (+)) $ zipU a b


With the tree based code, profiling shows matrix (*) and (+) perform a 
decent amount of memory allocation, so fusion should provide a big win i 
think.


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

[Haskell-cafe] Re: Sparse vector operations

[Neal Alexander]

Neal Alexander wrote:

Grzegorz Chrupala wrote:

Hi all,
In a couple of my projects I have needed to perform operations on (very)
sparse vectors.
I came up with the attached simple module which defines a typeclass and
implements instances for
simple and nested (Int)Maps.
Is this the right way to go about it? Am I reinventing some wheels?
Comments welcome.
Best,
--

Grzegorz

http://www.nabble.com/file/p22247686/SparseVector.hs SparseVector.hs 


I've been working on a matrix/vector library over the last month.

The matrices are implemented as QuadTrees, using block decomposition 
techniques for various algorithms. Vectors were kind of an afterthought, 
but they are implemented as binary trees - the thought being that they 
would decompose symmetrically with matrices.


Sparsity comes free with this approach (more or less), and is already 
implemented. Divide and conquer based parallelism should fit nicely into 
the mix too, but i haven't got to that point.


 From what I've tested so far, the performance is about the same as 
hmatrix and the various other matrix libraries on hackage. I've been 
trying to implement stream fusion for it over the last couple of days, 
but haven't been able to get it working right - maybe Dons can offer 
some advice.


For testing purposes, the uvector fusion based flat-matrix addition is 
twice as fast:


add a b = mapU (uncurryU (+)) $ zipU a b


With the tree based code, profiling shows matrix (*) and (+) perform a 
decent amount of memory allocation, so fusion should provide a big win i 
think.


Forgot to link the code:

http://community.haskell.org/~hexpuem/bdMatrix/

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

[Haskell-cafe] Re: Hidden module?

[Achim Schneider]

Cristiano Paris  wrote:

> I had to append process and directory as dependencies but then it
> worked. How can I submit a patch to Hackage? Do I have to contact the
> owner?
>
In general, just try the maintainer and/or author adresses given on
hsc2hs's hackage page.

I'd advice you to switch over to c2hs, which is actively developed,
while hsc2hs's last update date smells like abandonware.

-- 
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting,
performance and/or quoting of this signature prohibited.


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

[Haskell-cafe] How can you effectively manually determine the type?

[Anonymous Anonymous]

Hello,

I'm new at haskell and I have the following question:

let's say I type the following:

function = foldr until

Now my first question is what is the type of this function? Well let's see
what the type of until and foldr is:

until :: (a -> Bool) -> (a -> a) -> a -> a
foldr :: (a -> b -> b) -> b -> [a] -> b

So I would be thinking: we fill until in the position of (a -> b -> b) so, a
correspond with (a -> Bool) and b correspond with (a -> a) and b correspond
with a. Hmm a small problem, I think we can divide that as follows: b1
corresponds with (a -> a) and b2 corresponds with a. So I get:

foldr until :: b1 -> [a] -> b2
foldr until :: (a -> a) -> [a -> Bool] -> a

Is this a correct way of thinking or am I wrong?

And another question is: can someone give me an example how this can be
executed? All my code that I tried to execute resulted in errors with "foldr
until".

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

Re: [Haskell-cafe] How can you effectively manually determine the type?

[Dan Weston]

Does writing it like this help any?

until ::  (c -> Bool) -> (c -> c) -> (c -> c)
foldr :: ((   a ) -> (   b  ) -> (   b  )) -> b -> [a] -> b


Anonymous Anonymous wrote:

Hello,
 
I'm new at haskell and I have the following question:
 
let's say I type the following:
 
function = foldr until
 
Now my first question is what is the type of this function? Well let's 
see what the type of until and foldr is:
 
until :: (a -> Bool) -> (a -> a) -> a -> a

foldr :: (a -> b -> b) -> b -> [a] -> b
 
So I would be thinking: we fill until in the position of (a -> b -> b) 
so, a correspond with (a -> Bool) and b correspond with (a -> a) and b 
correspond with a. Hmm a small problem, I think we can divide that as 
follows: b1 corresponds with (a -> a) and b2 corresponds with a. So I get:
 
foldr until :: b1 -> [a] -> b2

foldr until :: (a -> a) -> [a -> Bool] -> a
 
Is this a correct way of thinking or am I wrong?
 
And another question is: can someone give me an example how this can be 
executed? All my code that I tried to execute resulted in errors with 
"foldr until".
 
Thanks!
 



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

Re: [Haskell-cafe] How can you effectively manually determine the type?

[Daniel Fischer]

Am Freitag, 27. Februar 2009 22:00 schrieb Anonymous Anonymous:
> Hello,
>
> I'm new at haskell and I have the following question:
>
> let's say I type the following:
>
> function = foldr until
>
> Now my first question is what is the type of this function? Well let's see
> what the type of until and foldr is:
>
> until :: (a -> Bool) -> (a -> a) -> a -> a
> foldr :: (a -> b -> b) -> b -> [a] -> b
>
> So I would be thinking: we fill until in the position of (a -> b -> b) so,
> a correspond with (a -> Bool) and b correspond with (a -> a) and b
> correspond with a. Hmm a small problem, I think we can divide that as
> follows: b1 corresponds with (a -> a) and b2 corresponds with a. So I get:

Not quite. The type of until, written with one parenthesis which is not 
strictly necessary, is

until :: (a -> Bool) -> (a -> a) -> (a -> a)

Now unify that with the type of the first argument of

foldr :: (s -> t -> t) -> t -> [s] -> t

You get

s = a -> Bool
t = a -> a

and

foldr until :: t -> [s] -> t, which expands to

foldr until :: (a -> a) -> [a -> Bool] -> (a -> a)

And if you don't want to do the analysis yourself,
Prelude> :t foldr until
foldr until :: (a -> a) -> [a -> Bool] -> a -> a


>
> foldr until :: b1 -> [a] -> b2
> foldr until :: (a -> a) -> [a -> Bool] -> a
>
> Is this a correct way of thinking or am I wrong?
>
> And another question is: can someone give me an example how this can be
> executed? All my code that I tried to execute resulted in errors with
> "foldr until".

I can't really see a useful application of foldr until, sorry.
But
Prelude> foldr until (+1) [(> 10), (> 12)] 4
13

However:
Prelude> foldr until (+1) [(> 10), (>8)] 4
Interrupted.


>
> Thanks!

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

Re: [Haskell-cafe] ANNOUNCE: text and text-icu, fast and comprehensive Unicode support using stream fusion

[George Pollard]

On Fri, 2009-02-27 at 08:59 -0800, Bryan O'Sullivan wrote:
> On Fri, Feb 27, 2009 at 12:57 AM, George Pollard 
> wrote:
> Unfortunately it doesn’t build for me. I have libicu-dev 3.8.1
> installed.
> 
> Yes, as the README states, the text-icu package needs ICU 4.0. The
> basic text library has no such external dependencies.

Oops, sorry for noise. I noticed that it hadn't built on hackage either,
so I thought there might be something missing.


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

[Haskell-cafe] memory issues

[Rogan Creswick]

First off, my apologies for breaking etiquette, if/when I do -- I've
only just joined Haskell-cafe, and I'm quite new to Haskell.

I have recently been trying to process a large data set (the 2.8tb
wikipedia data dump), and also replace my scripting needs with haskell
(needs that have previously been filled with bash, perl, and bits of
Java).  Last week I needed to do some quick scanning of the (7zipped)
wikipedia dump to get a feel for the size of articles, and from that
determine the best way to process the whole enchilada... cutting to
the chase, I ended up with a file consisting of byte offsets and lines
matched by a grep pattern (a 250mb file).  Specifically, 11m lines of:

1405:  
14062:  
15979:  
18665:  
920680797:  
..
2807444041476:  
2807444043623:  

I needed to know how large the lagest  elements were, so I'd
know if they would fit in memory, and some idea of how many would
cause swapping, etc. So, I wrote a simple app in haskell (below) to
find the sizes of each  and sort them.  Unfortunately, it
consumes an absurd amount of memory (3+gb) and dies with an
out-of-memory error.  Given the input size, and what it is doing, this
seems ridiculously high -- can anyone help me understand what is going
on, and how I can prevent this sort of rampant memory use?

I can provide a link to the input file if anyone wants it, but it
doesn't seem particularly useful, given the simplicity and size.
Since I needed to get results fairly quickly, I've re-implemented this
in java, so that reference implementation is also available should
anyone want it (the approach that is most similar to the haskell
requires a 1.4gb heap, but by streaming the string->long parsing, that
requirement drops to ~600mb, which seems pretty reasonable, since the
*output* is 215mb.)

Thanks!
Rogan

\begin{code}
-- Compiled with:
-- $ ghc --make offsetSorter.hs
--
--  (ghc v. 6.8.2)
--
-- Run with:
-- $ time ./offsetSorter data/byteOffsets.txt > haskOffsets.txt
-- offsetSorter: out of memory (requested 1048576 bytes)
--
-- real 4m12.130s
-- user 3m4.812s
-- sys  0m5.660s
--(OOM happened after consuming just over 3000mb of Virt, 2.6gb Res,
according to top.)
--

import System (getArgs)
import Data.Maybe
import Monad
import Text.Printf (printf)
import Data.Function (on)
import Data.List (sort)
import Data.ByteString (ByteString)
import qualified Data.ByteString.Char8 as C8
import qualified Data.ByteString as B


-- get the lines
-- parse each line to get the offset.
-- scan the list of offsets

-- | The full file size:
maxSize :: Integer
maxSize = 2807444044080

-- | Block is a contiguous chunk of data.
-- The first entry is the offset, the second is the length.
data Block = Block {
  offset::Integer
, size::Integer
} deriving (Eq)

-- | Ordering of Blocks is based entirely on the block size.
instance Ord Block where
compare = compare `on` size

instance Show Block where
show (Block o s) = (show o) ++ "  " ++ (show s)

-- turn the file into a list of offsets:
getOffsets :: ByteString -> [Integer]
getOffsets = catMaybes . map parseOffset . C8.lines

-- | Pull out the offsets frome a line of the file.
parseOffset :: ByteString -> Maybe Integer
parseOffset s = do
  (i, _) <- C8.readInteger (C8.filter (/=':') s)
  Just i

-- | Get the offsets between entries in a list
getSizes :: [Integer]  -> [Integer]
getSizes (x:y:[]) = [y - x]
getSizes (x:y:ys) = (y - x):(getSizes (y:ys))

-- | creates and returns a list of Blocks, given a file's content.
blocks :: ByteString -> [Block]
blocks s = zipWith (Block) offsets sizes
   where offsets = getOffsets s
 sizes   = getSizes (offsets ++ [maxSize])

main :: IO ()
main = do
  args <- getArgs
  content <- B.readFile (args!!0)
  printf "%s" $ unlines $ map (show) (sort $! blocks content)
\end{code}
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] memory issues

[Don Stewart]

creswick:
> First off, my apologies for breaking etiquette, if/when I do -- I've
> only just joined Haskell-cafe, and I'm quite new to Haskell.
> 
> I have recently been trying to process a large data set (the 2.8tb
> wikipedia data dump), and also replace my scripting needs with haskell
> (needs that have previously been filled with bash, perl, and bits of
> Java).  Last week I needed to do some quick scanning of the (7zipped)
> wikipedia dump to get a feel for the size of articles, and from that
> determine the best way to process the whole enchilada... cutting to
> the chase, I ended up with a file consisting of byte offsets and lines
> matched by a grep pattern (a 250mb file).  Specifically, 11m lines of:
> 
> 1405:  
> 14062:  
> 15979:  
> 18665:  
> 920680797:  
> ..
> 2807444041476:  
> 2807444043623:  
> 
> I needed to know how large the lagest  elements were, so I'd
> know if they would fit in memory, and some idea of how many would
> cause swapping, etc. So, I wrote a simple app in haskell (below) to
> find the sizes of each  and sort them.  Unfortunately, it
> consumes an absurd amount of memory (3+gb) and dies with an
> out-of-memory error.  Given the input size, and what it is doing, this
> seems ridiculously high -- can anyone help me understand what is going
> on, and how I can prevent this sort of rampant memory use?
> 
> I can provide a link to the input file if anyone wants it, but it
> doesn't seem particularly useful, given the simplicity and size.
> Since I needed to get results fairly quickly, I've re-implemented this
> in java, so that reference implementation is also available should
> anyone want it (the approach that is most similar to the haskell
> requires a 1.4gb heap, but by streaming the string->long parsing, that
> requirement drops to ~600mb, which seems pretty reasonable, since the
> *output* is 215mb.)
> 
> Thanks!
> Rogan
> 
> \begin{code}
> -- Compiled with:
> -- $ ghc --make offsetSorter.hs


YIKES!! Use the optimizer!

ghc -O2 --make


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

Re: [Haskell-cafe] Re: ANNOUNCE: pqueue-mtl, stateful-mtl

[David Menendez]

On Fri, Feb 27, 2009 at 1:28 PM, Ryan Ingram  wrote:
> Then it comes down to, within a session, is there some way for an
> STTRef to "mingle" and break the type-safety rule.  I can think of two
> potential ways this might happen.  First, if the underlying monad is
> something like List or Logic, there may be a way for STTRefs to move
> between otherwise unrelated branches of the computation.  Second, if
> the underlying monad is something like Cont, there may be a way for an
> STTRef to get transmitted "back in time" via a continuation to a point
> where it hadn't been allocated yet.

I think promoting MonadPlus would be safe. The code for mplus will end
up looking something like:

mplus (STT a) (STT b) = STT (StateT (\heap -> runStateT a heap `mplus`
runStateT b heap))

so each branch is getting its own copy of the heap.

The fancier logic stuff, like msplit, doesn't promote well through
StateT, and isn't type-safe in STT

For example:

class (MonadPlus m) => ChoiceMonad m where
msplit :: m a -> m (Maybe (a, m a))

instance ChoiceMonad [] where
msplit [] = [Nothing]
msplit (x:xs) = [Just (x,xs)]

There are at least two ways to promote msplit through StateT. The
method I used in my library is,

instance (ChoiceMonad m) => ChoiceMonad (StateT s m) where
msplit m = StateT $ \s -> msplit (runStateT m s) >>= return .
maybe (Nothing, s) (\ ((a,s'),r) -> (Just (a, StateT (\_ -> r)), s'))

If you promoted that instance through STT, it would no longer be safe.

test = do
Just (_, rest) <- msplit $ mplus (return ()) (return ())
ref1 <- newSTTRef 'a'
rest
ref2 <- newSTTRef (65 :: Int)
readSTTRef ref1

The call to "rest" effectively undoes the first call to newSTTRef, so
that ref1 and ref2 end up referring to the same cell in the heap.

I'm confident callCC and shift will cause similar problems.

-- 
Dave Menendez 

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

[Haskell-cafe] Samples for http package

[Gü?nther Schmidt]

Hi everyone,

are there any examples on how to use the current version of the http 
package?


Günther

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

Re: [Haskell-cafe] Samples for http package

[Henning Thielemann]

On Fri, 27 Feb 2009, Gü?nther Schmidt wrote:


are there any examples on how to use the current version of the http package?


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

Re: [Haskell-cafe] memory issues

[Rogan Creswick]

On Fri, Feb 27, 2009 at 2:20 PM, Don Stewart  wrote:
> creswick:
>> \begin{code}
>> -- Compiled with:
>> -- $ ghc --make offsetSorter.hs
>
> YIKES!! Use the optimizer!
>
>    ghc -O2 --make

Ah, that did drastically cut the amount of time it takes to run out of
memory (down to 1:23), but unfortunately I can't see any other
improvements -- the memory consumed seems to be about the same.
(granted, I have no indication of progress -- it may be getting
significantly more done, but it's not quite over the hump and
producing output yet.)

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

Re: [Haskell-cafe] Samples for http package

[Gwern Branwen]

2009/2/27 Henning Thielemann :
>
> On Fri, 27 Feb 2009, Gü?nther Schmidt wrote:
>
>> are there any examples on how to use the current version of the http
>> package?
>
> test/get.hs

Also, cabal-install uses HTTP 4k.

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

Re: [Haskell-cafe] memory issues

[Don Stewart]

creswick:
> On Fri, Feb 27, 2009 at 2:20 PM, Don Stewart  wrote:
> > creswick:
> >> \begin{code}
> >> -- Compiled with:
> >> -- $ ghc --make offsetSorter.hs
> >
> > YIKES!! Use the optimizer!
> >
> >    ghc -O2 --make
> 
> Ah, that did drastically cut the amount of time it takes to run out of
> memory (down to 1:23), but unfortunately I can't see any other
> improvements -- the memory consumed seems to be about the same.
> (granted, I have no indication of progress -- it may be getting
> significantly more done, but it's not quite over the hump and
> producing output yet.)
> 

Ok. Now, profile! (ghc -O2 -prof -auto-all --make)

http://book.realworldhaskell.org/read/profiling-and-optimization.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Samples for http package

[GŸuenther Schmidt]

Hi Gwern,

thanks but the test/get.hs did not actually work with the 4k version and 
was also a tad on the sparse side :)


Günther

Gwern Branwen schrieb:

2009/2/27 Henning Thielemann :
  

On Fri, 27 Feb 2009, Gü?nther Schmidt wrote:



are there any examples on how to use the current version of the http
package?
  

test/get.hs



Also, cabal-install uses HTTP 4k.

  


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

Re: [Haskell-cafe] memory issues

[Bulat Ziganshin]

Hello Rogan,

Saturday, February 28, 2009, 1:18:47 AM, you wrote:

> data Block = Block {
>   offset::Integer
> , size::Integer
> } deriving (Eq)

try
   !offset::Integer
 , !size::Integer


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

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

Re: [Haskell-cafe] memory issues

[Don Stewart]

bulat.ziganshin:
> Hello Rogan,
> 
> Saturday, February 28, 2009, 1:18:47 AM, you wrote:
> 
> > data Block = Block {
> >   offset::Integer
> > , size::Integer
> > } deriving (Eq)
> 
> try
>!offset::Integer
>  , !size::Integer
> 

offset :: !Integer

And possibly just using {-# UNPACK #-}!Int64 would be ok?

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

Re: [Haskell-cafe] memory issues

[Daniel Fischer]

Am Freitag, 27. Februar 2009 23:18 schrieb Rogan Creswick:
>
> \begin{code}
> -- Compiled with:
> -- $ ghc --make offsetSorter.hs
> --
> --  (ghc v. 6.8.2)
> --
> -- Run with:
> -- $ time ./offsetSorter data/byteOffsets.txt > haskOffsets.txt
> -- offsetSorter: out of memory (requested 1048576 bytes)
> --
> -- real   4m12.130s
> -- user   3m4.812s
> -- sys0m5.660s
> --(OOM happened after consuming just over 3000mb of Virt, 2.6gb Res,
> according to top.)
> --
>
> import System (getArgs)
> import Data.Maybe
> import Monad
> import Text.Printf (printf)
> import Data.Function (on)
> import Data.List (sort)
> import Data.ByteString (ByteString)
> import qualified Data.ByteString.Char8 as C8
> import qualified Data.ByteString as B
>
>
> -- get the lines
> -- parse each line to get the offset.
> -- scan the list of offsets
>
> -- | The full file size:
> maxSize :: Integer
> maxSize = 2807444044080
>
> -- | Block is a contiguous chunk of data.
> -- The first entry is the offset, the second is the length.
> data Block = Block {
>   offset::Integer
> , size::Integer
> } deriving (Eq)
>
> -- | Ordering of Blocks is based entirely on the block size.
> instance Ord Block where
> compare = compare `on` size
>
> instance Show Block where
> show (Block o s) = (show o) ++ "  " ++ (show s)
>
> -- turn the file into a list of offsets:
> getOffsets :: ByteString -> [Integer]
> getOffsets = catMaybes . map parseOffset . C8.lines
>
> -- | Pull out the offsets frome a line of the file.
> parseOffset :: ByteString -> Maybe Integer
> parseOffset s = do
>   (i, _) <- C8.readInteger (C8.filter (/=':') s)

Why the C8.filter (/= ':')?
That just costs and doesn't help anything (in fact, if your file contains 
lines like 1234:5678, it gives wrong results).

If you know that your file contains only lines of the form offset: ,
you can have

getOffsets = map (fst . fromJust . C8.readInteger) . C8.lines

which seems to do a little good.

>   Just i
>
> -- | Get the offsets between entries in a list
> getSizes :: [Integer]  -> [Integer]
> getSizes (x:y:[]) = [y - x]
> getSizes (x:y:ys) = (y - x):(getSizes (y:ys))
>
> -- | creates and returns a list of Blocks, given a file's content.
> blocks :: ByteString -> [Block]
> blocks s = zipWith (Block) offsets sizes
>where offsets = getOffsets s
>  sizes   = getSizes (offsets ++ [maxSize])
>
> main :: IO ()
> main = do
>   args <- getArgs
>   content <- B.readFile (args!!0)


>   printf "%s" $ unlines $ map (show) (sort $! blocks content)

Bad!
Use
mapM_ print $ sort $ blocks content

> \end{code}

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

[Haskell-cafe] Re: memory issues

[ChrisK]

Bulat is right about making Block's fields strict.



-- | Get the offsets between entries in a list
getSizes :: [Integer]  -> [Integer]
getSizes (x:y:[]) = [y - x]
getSizes (x:y:ys) = (y - x):(getSizes (y:ys))


You should change the first part to add maxSize:

> getSizes :: [Integer]  -> [Integer]
> getSizes (x:y:[]) = [y - x,maxSize]
> getSizes (x:y:ys) = (y - x):(getSizes (y:ys))

This avoids the ugly use of (++) below.  Note that appending to a singly linked 
list is a bad "code smell":




-- | creates and returns a list of Blocks, given a file's content.
blocks :: ByteString -> [Block]
blocks s = zipWith (Block) offsets sizes
   where offsets = getOffsets s
 sizes   = getSizes offsets

main :: IO ()
main = do
  args <- getArgs
  content <- B.readFile (args!!0)
  printf "%s" $ unlines $ map (show) (sort $! blocks content)
\end{code}


I think the printf "%s" should be replaced by putStr or putStrLn.

The print is forcing the unlines which forces the map which forces the result of 
sort.


The ($!) is nearly pointless...it forces only the first cons (:) cell in the 
list.

The sort starts comparing the output of blocks by applying compare.  The compare 
forces the snd part of the part from the zipWith, which is the sizes.  The size 
values force the values in the offsets in the fst part of the pair.


The fst part of the pair was actually a lazy thunk returned by the 
C8.readInteger function.  But these do not build up since the are indirectly 
getting forced during the sorting routine.


Hmmmno quick fix.

--
Chris

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

Re[2]: [Haskell-cafe] memory issues

[Bulat Ziganshin]

Hello Daniel,

Saturday, February 28, 2009, 2:21:31 AM, you wrote:

>>   printf "%s" $ unlines $ map (show) (sort $! blocks content)

> Bad!
> Use
> mapM_ print $ sort $ blocks content

are you sure? print may waste a lot of time, locking stdout for every
line printed

$! is really useless here - it will require to compute only *head* of
list before calling sort which is absolutely useless :)


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

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

Re[2]: [Haskell-cafe] memory issues

[Bulat Ziganshin]

Hello Don,

Saturday, February 28, 2009, 2:18:37 AM, you wrote:

> offset :: !Integer

oh yes

> And possibly just using {-# UNPACK #-}!Int64 would be ok?

i think that it will be even better but main problem is a
huge unevaluated thunks. as the last hope, this may be converted to

x <- getOffsets
y <- getSizes x
z <- sort y

also, "zipWith (Block) offsets sizes" and getSizes may be combined to
make only one pass through data (although it's not highly important
since sort anyway will need them all). really good technique would be
to use some sort of heap to hold only 10-100 largest page sizes

btw,

data Block = Block {
  size::Integer
, offset::Integer
} deriving (Ord)

allows to omit instance Ord Block definition


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

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

Re: [Haskell-cafe] memory issues

[Daniel Fischer]

Am Samstag, 28. Februar 2009 00:37 schrieb Bulat Ziganshin:
> Hello Daniel,
>
> Saturday, February 28, 2009, 2:21:31 AM, you wrote:
> >>   printf "%s" $ unlines $ map (show) (sort $! blocks content)
> >
> > Bad!
> > Use
> > mapM_ print $ sort $ blocks content
>
> are you sure?

Tested it. The printf "%s" is very bad. Replacing that reduced allocation and 
GC time by a factor of 2+.
The difference between 

mapM_ print

and

putStr $ unlines $ map show $ ...

is too small for me to be sure that mapM_ print is really better.

> print may waste a lot of time, locking stdout for every
> line printed

Hm, maybe

main = do
args <- getArgs
content <- B.readFile (args!!0)
hout <- openFile (args!!1) WriteMode
mapM_ (hPrint hout) $ sort $ blocks content
hClose hout

? I find hardly any difference, though.

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

[Haskell-cafe] Re: Incremental array updates

[Keith Sheppard]

I'm still learning haskell, so I may be missing something pretty
obvious, but isn't this the kind of thing that the diff array types
were created for.

http://en.wikibooks.org/wiki/Haskell/Hierarchical_libraries/Arrays#DiffArray_.28module_Data.Array.Diff.29

-Keith

>On Thu, Feb 26, 2009 at 06:45:27PM +, Ross Paterson wrote:
>> Yes, bucketing problems like this are a common case that the standard
>> functions cannot handle.  Perhaps the libraries need a canned solution.
>
>Stratch that -- as Bulat points out, accumArray is such a canned solution.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

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

[wren ng thornton]

Holger Siegel wrote:
   loop alpha b (c:cs) 
   = let alpha' = max(alpha, - negascout c d (-b) (-alpha))

 in if alpha' >= beta
then alpha'
else if alpha' >= b
 then let alpha'' = - negascout c d (-beta) (-alpha')
  in if alpha'' >= beta
 then alpha''
 else loop alpha'' (alpha'' + 1) cs 
 else loop alpha' (alpha' + 1) cs

   loop alpha _ [] = alpha



Guard-izing and where-izing that for more clarity:

> loop alpha _ [] = alpha
> loop alpha b (c:cs) = result
>where
>alpha' = max(alpha, - negascout c d (-b) (-alpha))
>result
>| alpha' >= beta  = alpha'
>| alpha' >= b = result'
>| otherwise   = loop alpha' (alpha' + 1) cs
>where
>result'
>| alpha'' >= beta = alpha''
>| otherwise   = loop alpha'' (alpha'' + 1) cs
>where
>alpha'' = - negascout c d (-beta) (-alpha')

Which makes it obvious that the "result" function is something inlined 
into itself. Uninlining may make the code clearer still, or maybe not.


--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: ANNOUNCE: pqueue-mtl, stateful-mtl

[Ryan Ingram]

I note that all of your "broken" issues revolve around calls that
can't be written in terms of lift; that is, you need access to the STT
constructor in order to create these problems.

It's obvious that anything that accesses the STT constructor will
potentially not be typesafe; the question I have is that whether you
can construct something that isn't typesafe just via the use of runSTT
& lift.

If you wanted to implement callCC directly (as opposed to lift .
callCC) you would need to be extremely careful, as you noticed.

  -- ryan

On Fri, Feb 27, 2009 at 2:27 PM, David Menendez  wrote:
> On Fri, Feb 27, 2009 at 1:28 PM, Ryan Ingram  wrote:
>> Then it comes down to, within a session, is there some way for an
>> STTRef to "mingle" and break the type-safety rule.  I can think of two
>> potential ways this might happen.  First, if the underlying monad is
>> something like List or Logic, there may be a way for STTRefs to move
>> between otherwise unrelated branches of the computation.  Second, if
>> the underlying monad is something like Cont, there may be a way for an
>> STTRef to get transmitted "back in time" via a continuation to a point
>> where it hadn't been allocated yet.
>
> I think promoting MonadPlus would be safe. The code for mplus will end
> up looking something like:
>
> mplus (STT a) (STT b) = STT (StateT (\heap -> runStateT a heap `mplus`
> runStateT b heap))
>
> so each branch is getting its own copy of the heap.
>
> The fancier logic stuff, like msplit, doesn't promote well through
> StateT, and isn't type-safe in STT
>
> For example:
>
> class (MonadPlus m) => ChoiceMonad m where
>    msplit :: m a -> m (Maybe (a, m a))
>
> instance ChoiceMonad [] where
>    msplit [] = [Nothing]
>    msplit (x:xs) = [Just (x,xs)]
>
> There are at least two ways to promote msplit through StateT. The
> method I used in my library is,
>
> instance (ChoiceMonad m) => ChoiceMonad (StateT s m) where
>    msplit m = StateT $ \s -> msplit (runStateT m s) >>= return .
>        maybe (Nothing, s) (\ ((a,s'),r) -> (Just (a, StateT (\_ -> r)), s'))
>
> If you promoted that instance through STT, it would no longer be safe.
>
> test = do
>    Just (_, rest) <- msplit $ mplus (return ()) (return ())
>    ref1 <- newSTTRef 'a'
>    rest
>    ref2 <- newSTTRef (65 :: Int)
>    readSTTRef ref1
>
> The call to "rest" effectively undoes the first call to newSTTRef, so
> that ref1 and ref2 end up referring to the same cell in the heap.
>
> I'm confident callCC and shift will cause similar problems.
>
> --
> Dave Menendez 
> 
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

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

[Eugene Kirpichov]

It is, but they are still too slow. STArrays rock the world.

2009/2/28 Keith Sheppard :
> I'm still learning haskell, so I may be missing something pretty
> obvious, but isn't this the kind of thing that the diff array types
> were created for.
>
> http://en.wikibooks.org/wiki/Haskell/Hierarchical_libraries/Arrays#DiffArray_.28module_Data.Array.Diff.29
>
> -Keith
>
>>On Thu, Feb 26, 2009 at 06:45:27PM +, Ross Paterson wrote:
>>> Yes, bucketing problems like this are a common case that the standard
>>> functions cannot handle.  Perhaps the libraries need a canned solution.
>>
>>Stratch that -- as Bulat points out, accumArray is such a canned solution.
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



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