Re: [Haskell-cafe] holumbus error message -- unexpected package db stack

[Jonathan Daugherty]

> Ok, figured it out, based on your link, Jonathan, I thought of just running:
> make clean
> ./Setup configure
> ./Setup build
> ./Setup install
> WHICH of course imports Distribution.Simple, whereas calling "make blah" on
> the Makefile will not do the import of Distribution.Simple

I'm glad the link helped.

The error message you're seeing is actually in several places in the
source.  In the case where I've encountered this message, it's
generated at the point where the Setup program is about to be compiled
by cabal-install for a package with Build-Type: Custom; in this case,
extra arguments were passed to cabal to set the GHC package database
location, but those arguments failed a sanity check and resulted in
the error message you saw.  However, if you compile the Setup program
by hand and bypass the check, you can still run it with whatever
arguments you want and you won't see the error.

The workaround I've used is to run "cabal configure" without the extra
arguments.  This will build the Setup program and then the Setup
program can be run with whatever package-database-related arguments
caused the error originally.  So you may find that you see the error
only when there is no preexisting dist/setup/setup program.  But,
again, I'd want to see how cabal is being invoked by the Makefile.

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

Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0

[David Menendez]

On Sat, Sep 4, 2010 at 1:31 AM, John Millikin  wrote:
> On Fri, Sep 3, 2010 at 20:39, Albert Y. C. Lai  wrote:
>> In theory, what does file extension matter? Media type is the dictator. The
>> normative Section 5.1 permits the choice of application/xhtml+xml or
>> text/html. While the latter entails extra requirements in the informative
>> Appendix C, as far as I can see (after all IDs are repaired) they are all
>> met.
>>
>> In a cunning combination of theory and practice in our reality, the file
>> extension .html implies the media type text/html unless the server specifies
>> otherwise. But since text/html is allowed in theory, so is .html allowed in
>> practice. Indeed, Internet Explorer plays along just fine with text/html; it
>> stops only when you claim application/xhtml+xml. For example
>> http://www.vex.net/~trebla/xhtml10.html works.
>>
>> This is a correct use of xhtml 1.0, and I fully endorse it.
>
> It's not correct. Here's the exact same XHTML document (verify by
> viewing the source), served with different mimetypes:
>
> http://ianen.org/temp/inline-svg.html
> http://ianen.org/temp/inline-svg.xhtml
>
> Notice that the version served as HTML does not render properly. This
> is because the browser is treating it as HTML with an unknown doctype,
> not as XHTML.

Yes, using foreign namespaces is one of the things recommended against
when serving XHTML as text/html. This says nothing about documents
following the recommendations in Appendix C.

> I'm not debating that it's *possible* to serve HTML with an XHTML
> mimetype and still see something rendered to the screen. Hundreds of
> thousands of sites do so every day. But to call this XHTML is absurd.

I agree, if by "absurd" you mean "consistent with the letter and
spirit of the XHTML recommendation".

-- 
Dave Menendez 

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

Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0

[John Millikin]

On Fri, Sep 3, 2010 at 20:39, Albert Y. C. Lai  wrote:
> In theory, what does file extension matter? Media type is the dictator. The
> normative Section 5.1 permits the choice of application/xhtml+xml or
> text/html. While the latter entails extra requirements in the informative
> Appendix C, as far as I can see (after all IDs are repaired) they are all
> met.
>
> In a cunning combination of theory and practice in our reality, the file
> extension .html implies the media type text/html unless the server specifies
> otherwise. But since text/html is allowed in theory, so is .html allowed in
> practice. Indeed, Internet Explorer plays along just fine with text/html; it
> stops only when you claim application/xhtml+xml. For example
> http://www.vex.net/~trebla/xhtml10.html works.
>
> This is a correct use of xhtml 1.0, and I fully endorse it.

It's not correct. Here's the exact same XHTML document (verify by
viewing the source), served with different mimetypes:

http://ianen.org/temp/inline-svg.html
http://ianen.org/temp/inline-svg.xhtml

Notice that the version served as HTML does not render properly. This
is because the browser is treating it as HTML with an unknown doctype,
not as XHTML.

I'm not debating that it's *possible* to serve HTML with an XHTML
mimetype and still see something rendered to the screen. Hundreds of
thousands of sites do so every day. But to call this XHTML is absurd.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] holumbus error message -- unexpected package db stack

[Roderick Ford]

Ok, figured it out, based on your link, Jonathan, I thought of just running:
make clean
./Setup configure
./Setup build
./Setup install
WHICH of course imports Distribution.Simple, whereas calling "make blah" on the 
Makefile will not do the import of Distribution.Simple 

Anyway, THANKS for the link ... it DID help :)

Cheers,
Roderick Ford 

> > This gave me a buildable make of the code
> > (make just calls Setup for each step) but in the "make install" I get:
> > localhost:/home/roderick/Source/hs/src/distribution # make install
> > Installing library in
> > /usr/local/lib/Holumbus-Distribution-0.0.2.0/ghc-6.10.4
> > Installing executable(s) in /usr/local/bin
> > Registering Holumbus-Distribution-0.0.2.0...
> > Setup.hs: internal error: unexpected package db stack
> > make: *** [install] Error 1
> >
> >
> > So, my question is "What is the 'unexpected package db stack' caused by?"
> > Does this give me any hints about the actual problem?
> 
> Is cabal using a custom GHC package database?  You might find this 
> illuminating:
> 
>   http://hackage.haskell.org/trac/hackage/ticket/731
> 
> -- 
>   Jonathan Daugherty
  ___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0

[wren ng thornton]

On 9/2/10 9:57 PM, John Millikin wrote:

Is there any particular reason you're using XHTML instead of HTML?
You're using a transitional doctype, invalid IDs, and the .html file
extension -- in short, HTML with an incorrect doctype. The markup
doesn't even validate.


Because HTML is evil? Though, yes, invalid XHTML is evil too...


In case you're not aware, HTML and XHTML are separate file formats.
HTML is a dialect of SGML, whereas XHTML is a dialect of XML.


And XML is just a dialect of SGML if we want to get picky.

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

RE: [Haskell-cafe] holumbus error message -- unexpected package db stack

[Roderick Ford]

> Date: Fri, 3 Sep 2010 21:31:53 -0700
> Subject: Re: [Haskell-cafe] holumbus error message -- unexpected package db 
> stack
> From: drcyg...@gmail.com
> To: haskell-cafe@haskell.org
> Is cabal using a custom GHC package database?  You might find this 
> illuminating:
> 
>   http://hackage.haskell.org/trac/hackage/ticket/731
> 
> -- 
>   Jonathan Daugherty

I don't know what else to check for to confirm/deny this question other than 
doing a `grep -r "package-db" *` in the distribution source, which simply 
returned that the binary file Setup contained it...that I suppose is just from 
the requirement in Setup.hs for "Distribution.Simple".  Other than that, I have 
not specified ANY database specific parameters.  I have however installed the 
cabal package HDBC-mysql ... probably unrelated to the problem???  So, I have 
to say, the link really didn't provide me any helpful information or hints 
about what I might have done wrong...sorry.

What else could I check for?


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

Re: [Haskell-cafe] holumbus error message -- unexpected package db stack

[Jonathan Daugherty]

> This gave me a buildable make of the code
> (make just calls Setup for each step) but in the "make install" I get:
> localhost:/home/roderick/Source/hs/src/distribution # make install
> Installing library in
> /usr/local/lib/Holumbus-Distribution-0.0.2.0/ghc-6.10.4
> Installing executable(s) in /usr/local/bin
> Registering Holumbus-Distribution-0.0.2.0...
> Setup.hs: internal error: unexpected package db stack
> make: *** [install] Error 1
>
>
> So, my question is "What is the 'unexpected package db stack' caused by?"
> Does this give me any hints about the actual problem?

Is cabal using a custom GHC package database?  You might find this illuminating:

  http://hackage.haskell.org/trac/hackage/ticket/731

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

[Haskell-cafe] holumbus error message -- unexpected package db stack

[Roderick Ford]

Hello all,
I want to try out Holumbus packages, but found that they don't build when left 
to cabal-install.  So I went to the holumbus site and did the git of the latest 
source...but it still wouldn't build.  Surprisingly, one of the errors was that 
there System.IO did not export a method utf8, but alas, utf8-prelude and 
utf8-string are both installed.  
So I went into this source code tree and attempted to make minor alterations.  
First, of the script is the distribution package (of the three packages), and 
cabal wanted less than the most recent hxt package as a maximum, so I dropped 
that limit.  This gave me a buildable make of the code (make just calls Setup 
for each step) but in the "make install" I get:
localhost:/home/roderick/Source/hs/src/distribution # make install
Installing library in /usr/local/lib/Holumbus-Distribution-0.0.2.0/ghc-6.10.4
Installing executable(s) in /usr/local/bin
Registering Holumbus-Distribution-0.0.2.0...
Setup.hs: internal error: unexpected package db stack
make: *** [install] Error 1


So, my question is "What is the 'unexpected package db stack' caused by?"  Does 
this give me any hints about the actual problem?

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

Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0

[David Menendez]

On Fri, Sep 3, 2010 at 12:40 AM, John Millikin  wrote:
>
> Haddock is generating files with an .html extension, which causes
> webservers to serve it using "text/html", the incorrect MIME-type.

Secton 5.1 of the XHTML recommendation states: "XHTML Documents which
follow the guidelines set forth in Appendix C, 'HTML Compatibility
Guidelines' may be labeled with the Internet Media Type 'text/html'
[RFC2854], as they are compatible with most HTML browsers."



I haven't checked Haddock's conformance with Appendix C, but it is
incorrect to say that XHTML cannot be served as text/html.

-- 
Dave Menendez 

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

Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0

[Albert Y. C. Lai]

On 10-09-02 09:57 PM, John Millikin wrote:

Is there any particular reason you're using XHTML instead of HTML?
You're using a transitional doctype, invalid IDs, and the .html file
extension -- in short, HTML with an incorrect doctype. The markup
doesn't even validate.

[...]

XHTML is supported by most modern browsers (Firefox, Chrome,
Safari, Opera, etc), but not by any currently released version of
Internet Explorer.


Although I dislike transitional personally, it is perfectly legal xhtml 1.0.

I see in another message that the author will repair all IDs if I 
understand correctly. (If not, easy to pressure the author to repair.)


File extension is a more complicated story. Which story do you want, the 
theory story or the practice story?


(It is easy to test that enough platforms out there are happy with it. 
That should end the practice story. So if you bother to claim there is 
an issue, you likely want the theory story.)


In theory, what does file extension matter? Media type is the dictator. 
The normative Section 5.1 permits the choice of application/xhtml+xml or 
text/html. While the latter entails extra requirements in the 
informative Appendix C, as far as I can see (after all IDs are repaired) 
they are all met.


In a cunning combination of theory and practice in our reality, the file 
extension .html implies the media type text/html unless the server 
specifies otherwise. But since text/html is allowed in theory, so is 
.html allowed in practice. Indeed, Internet Explorer plays along just 
fine with text/html; it stops only when you claim application/xhtml+xml. 
For example http://www.vex.net/~trebla/xhtml10.html works.


This is a correct use of xhtml 1.0, and I fully endorse it.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANNOUNCE: AbortT-transformers version 1.0

[Gregory Crosswhite]

 For whatever reason, nobody seems to have gotten around to implementing
an Abort monad transformer (outside the monadLib package), so I decided
to write one myself since I wanted the functionality but I use
"transformers" rather than "monadLib".

An abortable monadic computation runs until either it is finished or it
is aborted by calling the "abort" function.  All steps in the
computation after "abort" has been called are ignored, which means that
abort can be assigned an arbitrary type for its value within the
computation.

My implementation uses an Either type which is Left if the computation
has been prematurely terminated and Right of the computation is
continuing to proceed as normal.  I could have implemented the
functionality using the Continuation monad, but that seemed to be
overkill in cases where the user only wants a simple abort monad.

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

Re: [Haskell-cafe] Re: TryHaskell in the classroom!

[Alec Benzer]

Out of curiosity, where do you teach (directed at Fritz) and who are your
students? (ie, undergrad, grad, ...)

On Fri, Sep 3, 2010 at 8:11 PM, Benjamin L. Russell
wrote:

> Glad to hear about your positive experience with Try Haskell (see
> http://tryhaskell.org/)!
>
> I have also enjoyed using Try Haskell.  It would be wonderful if it
> could be expanded with more content.  Many thanks to the developers for
> their efforts!
>
> -- Benjamin L. Russell
>
> Fritz Ruehr  writes:
>
> > I just wanted to send out a more public "Thanks!" to Chris Done for
> > the tryhaskell.org website and to everyone else
> > (including Chris) who was on the #haskell channel of IRC this
> > afternoon when I "tried haskell", along with the chat feature,
> > during my introductory functional programming class.
> >
> > And I want to recommend the use of tryhaskell and its tutorial to
> > anyone else teaching Haskell in the classroom:
> > it makes for an an especially friendly and approachable introduction
> > to the language for students like mine,
> > some of whom are seeing programming for the first time. I'll be using
> > Hugs and GHC(i) for the day-to-day work
> > through the semester, but I imagine my students will be showing their
> > friends tryhaskell and poking around in it
> > at odd moments from the local cafe.
> >
> > I had just begun my second lecture with a little introduction to the
> > Haskell community and how friendly it was, etc.,
> > when I realized the opportunity that the chat feature
> > represented. Sure enough, #haskellers came through for me
> > with some fun & friendly interaction as the class and I bounced back
> > and forth between the tutorial and their comments.
> >
> > It was very gratifying to have my abstract proposition about the
> > character of the community backed up by a concrete
> > existential witness, live in the classroom :) .
> >
> > Thanks again to Chris, Gwern Branwen, _why (of TryRuby) and everyone
> > else for their efforts and interactions.
> >
> >   --  Fritz Ruehr
>
> --
> Benjamin L. Russell  /   DekuDekuplex at Yahoo dot com
> http://dekudekuplex.wordpress.com/
> Translator/Interpreter / Mobile:  +011 81 80-3603-6725
> "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^
>
> ___
> 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] Why does ghci recompile the module compiled in different OS ?

[zaxis]

Both linux and freebsd has the same .ghci file.
>cat ~/.ghci
:def hoogle \str -> return $ ":! hoogle --count=15 \"" ++ str ++ "\""
:cd /media/G/www/qachina/db/doc/money

the money.hs has many functions i need to use.   

On freebsd, i use the following command to compile it:
>ghc -c -O2 money.hs
>ls 
Money.hi  Money.hs  Money.o 

When entering ghci, it indeed doesnot recompile the module.
>ghci
...
Ok, modules loaded: Money

However, when i use the same module in archlinux, the ghci does recompile
the module:
>ghci
...
[1 of 1] Compiling Money( Money.hs, interpreted )
Ok, modules loaded: Money.

Any suggestion is appreciated!

-
e^(π⋅i) + 1 = 0
-- 
View this message in context: 
http://old.nabble.com/Why-does-ghci-recompile-the-module-compiled-in-different-OS---tp29619740p29619740.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] ANNOUNCE: GotoT-transformers version 1.0

[Gregory Crosswhite]

 People want to believe that Haskell is a better language than C, but
how could this possibly be true when Haskell lacks the very basic "goto"
feature???  If the world is going to take Haskell seriously, then this
serious blight needs to be addressed immediately!  Thus I proud to
present to you the "GotoT-transformers" package which provides this
missing functionality and so finally makes Haskell a serious contender
with C.

On a more serious note, there are times when it can be useful to not
only abort a computation in the middle, but to then transfer the flow of
execution to another computation:

do [...stuff...]
 when condition1 $ goto x
 [...more stuff...]
 when condition2 $ goto y
 [...more stuff...]
 when condition3 $ goto z

Towards this end, I developed this package which provides a GotoT monad
transformer and a "goto" function that takes a monadic computation and
returns a monadic value that has the effect of transferring control to
the new computation.  Obviously this functionality can be abused, but
when it is the natural fit I believe that it is much better to use it
directly then to go through all sorts of contortions resulting in uglier
code just to avoid it on principle.

The best implementation I could think of was to use a "trampoline"
approach.  The GotoT monadic transformer is represented by a type which
contains (wrapped inside the inner monad) either a pure value or a
monadic computation.  The runGotoT function operates by returning the
value if it is pure, and evaluating the monadic computation and feeding
the result back into itself otherwise.  The "trampoline" term refers to
the fact that the flow of execution bounces back to the runGotoT
function as long as the computation keeps calling the "goto" function.

I hope that the community not only finds this functionality useful, but
also that does not kill me for committing the egregious act of bringing
"goto" into the Haskell world.

Cheers,
Greg

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

[Haskell-cafe] Re: HDBC-postgresql and safe/unsafe FFI calls

[John Goerzen]

On 09/03/2010 06:14 PM, David Powell wrote:

Hi John,

My current usage of hdbc is in a server process that takes requests from
multiple clients, queries the database, and returns a result.  Having a
single db query block everything else isn't really workable for me.  I
suspect this will also be an issue for others.  As an example, the
persistent-postgresql package which is part of the new Yesod web
framework will have the same problem.

I can send you a patch, but I am concerned with the issue Leon raised
about libpq needing to be compiled with thread support.  This is the
default on my platforms (macosx, debian), but probably is dangerous to
rely on.  I guess we can just test the result of 'PQisthreadsafe()', in
connectPostgreSQL and raise an error if it is false.


Or at least a warning to stderr -- that won't be a problem for 
single-threaded programs, right?




Cheers,

-- David


On Fri, Sep 3, 2010 at 1:36 AM, John Goerzen mailto:jgoer...@complete.org>> wrote:

Hi David,

I've had varying arguments from people that want me to mark things
safe or unsafe for various performance reasons.  I'm happy to apply
your change if you like.  Can you send me a diff (and attach your
explanation here to it, which I'll use as a commit message for
future reference)?

Thanks,

-- John


On 09/01/2010 09:40 PM, David Powell wrote:

Greetings,

I'm having an issue with the HDBC-postgresql package that
requires me to
manually patch it before installation for most of my use cases.

All the FFI calls in this package are marked "unsafe".
  Unfortunately,
this means that whenever I issue a slow sql query, all other
processing
stops.  In most places that I want to use this module, I've had to
manually patch it to at least mark the PQexec and PQexecParams
calls as
"safe".

Is there any reason these calls should not be marked as "safe"?  I
understand that there a little extra runtime overhead with this,
but I'd
have thought that negligible given all the other processing that
goes on
with these particular calls under the hood.

Cheers,

--
David Powell





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

[Haskell-cafe] Re: TryHaskell in the classroom!

[Benjamin L. Russell]

Glad to hear about your positive experience with Try Haskell (see
http://tryhaskell.org/)!

I have also enjoyed using Try Haskell.  It would be wonderful if it
could be expanded with more content.  Many thanks to the developers for
their efforts!

-- Benjamin L. Russell

Fritz Ruehr  writes:

> I just wanted to send out a more public "Thanks!" to Chris Done for
> the tryhaskell.org website and to everyone else
> (including Chris) who was on the #haskell channel of IRC this
> afternoon when I "tried haskell", along with the chat feature,
> during my introductory functional programming class.
>
> And I want to recommend the use of tryhaskell and its tutorial to
> anyone else teaching Haskell in the classroom:
> it makes for an an especially friendly and approachable introduction
> to the language for students like mine,
> some of whom are seeing programming for the first time. I'll be using
> Hugs and GHC(i) for the day-to-day work
> through the semester, but I imagine my students will be showing their
> friends tryhaskell and poking around in it
> at odd moments from the local cafe.
>
> I had just begun my second lecture with a little introduction to the
> Haskell community and how friendly it was, etc.,
> when I realized the opportunity that the chat feature
> represented. Sure enough, #haskellers came through for me
> with some fun & friendly interaction as the class and I bounced back
> and forth between the tutorial and their comments.
>
> It was very gratifying to have my abstract proposition about the
> character of the community backed up by a concrete
> existential witness, live in the classroom :) .
>
> Thanks again to Chris, Gwern Branwen, _why (of TryRuby) and everyone
> else for their efforts and interactions.
>
>   --  Fritz Ruehr

-- 
Benjamin L. Russell  /   DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile:  +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^ 

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

[Haskell-cafe] TryHaskell in the classroom!

[Fritz Ruehr]

I just wanted to send out a more public "Thanks!" to Chris Done for  
the tryhaskell.org website and to everyone else
(including Chris) who was on the #haskell channel of IRC this  
afternoon when I "tried haskell", along with the chat feature,

during my introductory functional programming class.

And I want to recommend the use of tryhaskell and its tutorial to  
anyone else teaching Haskell in the classroom:
it makes for an an especially friendly and approachable introduction  
to the language for students like mine,
some of whom are seeing programming for the first time. I'll be using  
Hugs and GHC(i) for the day-to-day work
through the semester, but I imagine my students will be showing their  
friends tryhaskell and poking around in it

at odd moments from the local cafe.

I had just begun my second lecture with a little introduction to the  
Haskell community and how friendly it was, etc.,
when I realized the opportunity that the chat feature represented.  
Sure enough, #haskellers came through for me
with some fun & friendly interaction as the class and I bounced back  
and forth between the tutorial and their comments.


It was very gratifying to have my abstract proposition about the  
character of the community backed up by a concrete

existential witness, live in the classroom :) .

Thanks again to Chris, Gwern Branwen, _why (of TryRuby) and everyone  
else for their efforts and interactions.


  --  Fritz Ruehr

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

[Haskell-cafe] Re: HDBC-postgresql and safe/unsafe FFI calls

[David Powell]

Hi John,

My current usage of hdbc is in a server process that takes requests from
multiple clients, queries the database, and returns a result.  Having a
single db query block everything else isn't really workable for me.  I
suspect this will also be an issue for others.  As an example, the
persistent-postgresql package which is part of the new Yesod web framework
will have the same problem.

I can send you a patch, but I am concerned with the issue Leon raised about
libpq needing to be compiled with thread support.  This is the default on my
platforms (macosx, debian), but probably is dangerous to rely on.  I guess
we can just test the result of 'PQisthreadsafe()', in connectPostgreSQL and
raise an error if it is false.

Cheers,

-- David


On Fri, Sep 3, 2010 at 1:36 AM, John Goerzen  wrote:

> Hi David,
>
> I've had varying arguments from people that want me to mark things safe or
> unsafe for various performance reasons.  I'm happy to apply your change if
> you like.  Can you send me a diff (and attach your explanation here to it,
> which I'll use as a commit message for future reference)?
>
> Thanks,
>
> -- John
>
>
> On 09/01/2010 09:40 PM, David Powell wrote:
>
>> Greetings,
>>
>> I'm having an issue with the HDBC-postgresql package that requires me to
>> manually patch it before installation for most of my use cases.
>>
>> All the FFI calls in this package are marked "unsafe".  Unfortunately,
>> this means that whenever I issue a slow sql query, all other processing
>> stops.  In most places that I want to use this module, I've had to
>> manually patch it to at least mark the PQexec and PQexecParams calls as
>> "safe".
>>
>> Is there any reason these calls should not be marked as "safe"?  I
>> understand that there a little extra runtime overhead with this, but I'd
>> have thought that negligible given all the other processing that goes on
>> with these particular calls under the hood.
>>
>> Cheers,
>>
>> --
>> David Powell
>>
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Unnecessarily strict implementations

[Jan Christiansen]

On 03.09.2010, at 14:38, Daniel Fischer wrote:


I can't reproduce that. For me, it leaks also with profiling.


Have you used optimizations? It disappears if I compile the program  
with -O2.


Without profiling I get the following. Here the maximum residency is  
nearly 45MB.


$ ghc --make Temp.hs -fforce-recomp
[1 of 1] Compiling Main ( Temp.hs, Temp.o )
Linking Temp ...
$ ./Temp +RTS -sstderr
./Temp +RTS -sstderr
5458199
 647,520,792 bytes allocated in the heap
 256,581,176 bytes copied during GC
  44,934,408 bytes maximum residency (11 sample(s))
   1,363,496 bytes maximum slop
 103 MB total memory in use (1 MB lost due to  
fragmentation)


  Generation 0:  1223 collections, 0 parallel,  0.83s,  0.85s  
elapsed
  Generation 1:11 collections, 0 parallel,  0.49s,  0.62s  
elapsed


  INIT  time0.00s  (  0.00s elapsed)
  MUT   time0.63s  (  0.67s elapsed)
  GCtime1.32s  (  1.46s elapsed)
  EXIT  time0.00s  (  0.00s elapsed)
  Total time1.96s  (  2.13s elapsed)

  %GC time  67.6%  (68.5% elapsed)

  Alloc rate1,022,883,082 bytes per MUT second

  Productivity  32.3% of total user, 29.6% of total elapsed


With profiling it looks as follows. Here the maximum residency is less  
than 15KB.


$ ghc --make Temp.hs -prof -auto-all -fforce-recomp
[1 of 1] Compiling Main ( Temp.hs, Temp.o )
Linking Temp ...
$ ./Temp +RTS -sstderr
./Temp +RTS -sstderr
5458199
   1,051,844,836 bytes allocated in the heap
 110,134,944 bytes copied during GC
  14,216 bytes maximum residency (96 sample(s))
  37,068 bytes maximum slop
   2 MB total memory in use (0 MB lost due to  
fragmentation)


  Generation 0:  1908 collections, 0 parallel,  0.57s,  0.59s  
elapsed
  Generation 1:96 collections, 0 parallel,  0.02s,  0.02s  
elapsed


  INIT  time0.00s  (  0.00s elapsed)
  MUT   time1.46s  (  1.51s elapsed)
  GCtime0.60s  (  0.61s elapsed)
  RPtime0.00s  (  0.00s elapsed)
  PROF  time0.00s  (  0.00s elapsed)
  EXIT  time0.00s  (  0.00s elapsed)
  Total time2.05s  (  2.12s elapsed)

  %GC time  29.0%  (28.7% elapsed)

  Alloc rate721,170,248 bytes per MUT second

  Productivity  71.0% of total user, 68.9% of total elapsed

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

Re: [Haskell-cafe] Restricted type classes

[C. McCann]

On Fri, Sep 3, 2010 at 11:47 AM, John Lato  wrote:
> On Fri, Sep 3, 2010 at 1:29 PM, Ivan Lazar Miljenovic 
>  wrote:
>> On 3 September 2010 22:23, John Lato  wrote:
>> > Do you have a kind * implementation of Foldable?  I'd be interested in
>> > seeing it, because I was unable to create a usable implementation (based
>> > upon the RMonad scheme) on my last attempt.
>>
>> I was going to make it a subset of Foldable: fold, foldr, foldl, etc.
>
> So you don't have a working implementation yet?  I ended up thinking this is
> impossible, although I don't remember the reasoning that led me to that
> conclusion (and I could very well be wrong).
> I would suggest that you check this before going too far along the
> restricted-monad path.

This sounds odd to me. An RMonad-style version of Foldable is straightforward:

class RFoldable t where
rfold :: Control.RMonad.Suitable t a => (a -> b -> b) -> b -> t a -> b

instance RFoldable Data.Set.Set where
rfold = Data.Set.fold

A similar class for types of kind * is also straightforward:

class Reduce t where
type Elem t
reduce :: (Elem t -> r -> r) -> r -> t -> r

instance Reduce Data.ByteString.ByteString where
type Elem Data.ByteString.ByteString = Word8
reduce = Data.ByteString.foldr

Both seem to work as I'd expect. Am I missing something? Foldable is
pretty trivial--perhaps it was Traversable that you found problematic?

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

Re: [Haskell-cafe] Announce: lhae

[Corey O'Connor]

Cool! Good work IMO.

-Corey O'Connor
coreyocon...@gmail.com
http://www.coreyoconnor.com




On Fri, Sep 3, 2010 at 7:10 AM, abau  wrote:
> lhae is a spreadsheet program. It features a simple formula language and
> some basic statistical methods, like descriptive statistics and pivot
> tables.
>
> Other features:
> - Import from csv files
> - Export to image files
> - Export to gnuplot diagrams (currently bar charts and box plots)
> - Multilingual (english, german)
>
> Here [1] is some documentation about how to build lhae and how to use the
> formula language.
>
> Regards,
>
> Alex
>
> [1] http://www.imn.htwk-leipzig.de/~abau/lhae/
> ___
> 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] Missing documentation in Haskell Platform on Windows

[Andrew Coppin]

Don Stewart wrote:

andrewcoppin:
  
Almost every release of GHC that I can remember has had the links for  
the "mtl" package broken. (The Control.Monad.XXX modules are mostly from  
mtl. But, for example, Control.Monad.Fix is from base. I bet you'll find  
it works just fine.)



Well spotted, Andrew!

The way to get things like this fixed is to report a bug to the relevant
project.


M'kay. And for this, that would be...?


Click on the 'bug report' button:

http://trac.haskell.org/haskell-platform/
  


Ah, right. There's a HP-specific tracker. I guess now I just have to go 
register my details with yet *another* tracker and then I can report it. 
(Right after I finish checking that nobody has already reported it for 
me...)



You installed the Haskell Platform on Windows, so please mention this in
the bug ticket. The problem will likely be in the Windows installer
script, and what docs were bundled with that specific installer.

Be as detailed in the report as you can, to make sure we can reproduce
what trouble you have.
  


The information above probably says it all, so that shouldn't be hard.


In the meantime, you can always read the 'mtl' documentation on its
package page:

http://hackage.haskell.org/package/mtl
  


Well, yeah, there is that. It's just annoying to click on certain links 
and find it's dead, even if there is a workaround. (Assuming you have 
Internet access, which you occasionally don't...)


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

Re: [Haskell-cafe] Restricted type classes

[John Lato]

On Fri, Sep 3, 2010 at 1:29 PM, Ivan Lazar Miljenovic <
ivan.miljeno...@gmail.com> wrote:

> On 3 September 2010 22:23, John Lato  wrote:
>
> > Do you have a kind * implementation of Foldable?  I'd be interested in
> > seeing it, because I was unable to create a usable implementation (based
> > upon the RMonad scheme) on my last attempt.
>
> I was going to make it a subset of Foldable: fold, foldr, foldl, etc.


So you don't have a working implementation yet?  I ended up thinking this is
impossible, although I don't remember the reasoning that led me to that
conclusion (and I could very well be wrong).

I would suggest that you check this before going too far along the
restricted-monad path.

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

Re: [Haskell-cafe] Confused about ByteString, UTF8, Data.Text and sockets, still.

[John Millikin]

On Fri, Sep 3, 2010 at 05:04, JP Moresmau  wrote:
> I have replaced JSon by AttoJson (there was also JSONb, which seems quite
> similar), which allows me to work solely with ByteStrings, bypassing the
> calls to utf8-string completely. Performance has improved noticeably. I'm
> worried that I've lost full UTF8 compatibility, though, haven't I? No double
> byte characters will work in that setup?

It should be easy enough to test; generate a file with non-ASCII
characters in it and see if it's parsed correctly. I assume it will
be, though you won't be able to perform String operations on the
resulting decoded data unless you manually decode it. Slightly more
worrisome is that AttoJson doesn't look like it works with non-UTF8
JSON -- you might have compatibility problems unless you implement
manual decoding.

I've written a binding to YAJL (a C-based JSON parser) which might be
faster for you, if the input is very large -- though it still suffers
from the "assume UTF8" problem.

http://hackage.haskell.org/package/yajl

> Is Data.Text an alternative? Can I use that everywhere, including for
> dealing with sockets (the API only mentions Handle).

Use 'Network.Socket.socketToHandle' to convert sockets to handles:

http://hackage.haskell.org/packages/archive/network/2.2.1.7/doc/html/Network-Socket.html#v%3AsocketToHandle
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: base-3 -> base-4

[Johannes Waldmann]

Ivan Lazar Miljenovic  gmail.com> writes:

> ... the only thing that changed of significance was the
> exception handling: Control.Exception now uses extensible exceptions

I'm pretty sure ghc-6.12.3 gives warnings "this will not work with base-4"
in some more places. I was hoping there is a comprehensive list somewhere.

J.W.


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

Re: [Haskell-cafe] Announce: lhae

[Victor Nazarov]

On Fri, Sep 3, 2010 at 6:10 PM, abau  wrote:
> lhae is a spreadsheet program. It features a simple formula language and
> some basic statistical methods, like descriptive statistics and pivot
> tables.
>
> Other features:
> - Import from csv files
> - Export to image files
> - Export to gnuplot diagrams (currently bar charts and box plots)
> - Multilingual (english, german)
>
> Here [1] is some documentation about how to build lhae and how to use the
> formula language.
>

I was thinking about writing my own. What I wanted was adding lists
and functions (lambdas) as values.

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

Re: [Haskell-cafe] Announce: lhae

[Serguey Zefirov]

2010/9/3 abau :
> lhae is a spreadsheet program. It features a simple formula language and
> some basic statistical methods, like descriptive statistics and pivot
> tables.

Interesting.

You had selected wxWidgets because of what?

Also, how long did it took (especially GUI part)?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Crypto-API is stabilizing

[Thomas DuBuisson]

>> If MR the more agreeable path
>> then I'll do it, though this means I use the unholy "fail" function.
>
> You don't want to use monads because the Monad class defines the fail
> function?

Sorry, I phrased this better on the blog comment.  I don't want to use
"MonadRandom m => m (p,p)" (MonadRandom + fail) instead of "Either
GenError (B,ByteString, g)" because it limits my options for failure
down to a piddly "fail :: String -> m a" (ignoring exceptions) - right
now my options for failure are much richer,  I can say ReseedRequred
or NotEnoughEntropy etc, giving the user errors that can be handled by
a simple pattern matching case expression.

>> In general, I like this approach, but what are
>>  encrypt privateKey
>>or
>>  decrypt publicKey
>>
>> supposed to do? A type-class solution also does not *prevent* programmers to 
>> perform such non-sensical calls
>
>Would it be desirable to prohibit such calls using the type system?

As was earlier pointed out, these are actually valid operations for
many public key systems.  In fact, it's possible to use these for
signing or verifying messages:

Signing ==> encrypt privateKey . encode . hash
Verifying signature ==> \sig msg -> decrypt publicKey sig == encode (hash msg)

What makes a key public and another private is simply your pick of
which to publish and which to protect as jealously as my daughter
guards her cup of water (seriously, I can't get it from her).


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

Re: [Haskell-cafe] Announce: lhae

[Henning Thielemann]

Pierre-Etienne Meunier schrieb:
> Seems cool, but I do not really get it : why write it in haskell ? I thought 
> at first that your "formula language" was haskell, but it looks more like a 
> php derivative.
> 
> Does it do more than the spreadsheet thing in openoffice ?
> 
> Also, maybe you could do the same with gnuplot, it would be really cool to be 
> able to use a friendlier language for defining functions other than 
> polynomials or the few standard floating point functions.

For gnuplot I have already written a wrapper that is called ... 'gnuplot'.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Announce: lhae

[Pierre-Etienne Meunier]

Seems cool, but I do not really get it : why write it in haskell ? I thought at 
first that your "formula language" was haskell, but it looks more like a php 
derivative.

Does it do more than the spreadsheet thing in openoffice ?

Also, maybe you could do the same with gnuplot, it would be really cool to be 
able to use a friendlier language for defining functions other than polynomials 
or the few standard floating point functions.

Good luck,
Pierre

El 03/09/2010, a las 10:10, abau escribió:

> lhae is a spreadsheet program. It features a simple formula language and
> some basic statistical methods, like descriptive statistics and pivot
> tables. 
> 
> Other features:
> - Import from csv files
> - Export to image files
> - Export to gnuplot diagrams (currently bar charts and box plots)
> - Multilingual (english, german)
> 
> Here [1] is some documentation about how to build lhae and how to use the
> formula language.
> 
> Regards,
> 
> Alex
> 
> [1] http://www.imn.htwk-leipzig.de/~abau/lhae/
> ___
> 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] Announce: lhae

[abau]

lhae is a spreadsheet program. It features a simple formula language and
some basic statistical methods, like descriptive statistics and pivot
tables. 

Other features:
- Import from csv files
- Export to image files
- Export to gnuplot diagrams (currently bar charts and box plots)
- Multilingual (english, german)

Here [1] is some documentation about how to build lhae and how to use the
formula language.

Regards,

Alex

[1] http://www.imn.htwk-leipzig.de/~abau/lhae/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] base-3 -> base-4

[Don Stewart]

ganesh.sittampalam:
> Johannes Waldmann wrote:
> > Is there a "conversion guide" for switching from base-3 to base-4?
> > 
> > I noticed that ghc-HEAD (6.13) comes with base-4.3 (and no base-3).
> > This will break an awful lot of packages (?), in fact the breakage
> > starts with cabal-install (since it depends on HTTP which depends on
> > base-3).  
> 
> HTTP can build and seems to work with base 4 if you bump the dependency.
> I contacted Sigbjorn about making a new release a while ago, but nothing
> has happened yet.

I don't know if Sigbjorn is still the maintainer. We need to set
maintainer timeouts somewhere.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] base-3 -> base-4

[Ivan Lazar Miljenovic]

On 3 September 2010 23:07, Johannes Waldmann
 wrote:
> Is there a "conversion guide" for switching from base-3 to base-4?
>
> I noticed that ghc-HEAD (6.13) comes with base-4.3 (and no base-3).
> This will break an awful lot of packages (?), in fact the breakage
> starts with cabal-install (since it depends on HTTP which depends on base-3).

>From memory, the only thing that changed of significance was the
exception handling: Control.Exception now uses extensible exceptions
(also available for base-3 in the extensible-exceptions package).  For
the very lazy Control.OldException may still be available with 6.14 to
keep using the old-style exceptions.

-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Restricted type classes

[Tobias Brandt]

On 3 September 2010 06:16, Ivan Lazar Miljenovic
 wrote:
> 2c) Should I keep the classes as-is, or should I explicitly put in the
> constraints mentioned in the Typeclassopedia (e.g. make Applicative an
> explicit superclass of Monad, and define return = pure for
> compatability reasons)?

I also opt for putting the constraints in.

> 3) Am I wasting my time with this?

Definitely not. A standard container interface is something a lot of
people want.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Confused about ByteString, UTF8, Data.Text and sockets, still.

[Daniel Fischer]

On Friday 03 September 2010 14:04:26, JP Moresmau wrote:
> Hello all
>
> After reading the modules docs and some other discussions, I'm still not
> sure what's the best choice of tools for my problem. I'm looking at the
> scion server code base. At the moment, it's reading and writing on
> sockets using Lazy ByteStrings, then converting them to Haskell Strings
> using utf8-string. The Haskell Strings are then parsed as JSON using the
> JSon package. the response is in JSON, translated back with utf8-string
> to ByteStrings.
> This is efficient for small strings, but as I'm extending the API I have
> calls with much more data, and performance degrades significantly.
> Timings seem to point to the encoding of the String to UTF8.
> I have replaced JSon by AttoJson (there was also JSONb, which seems
> quite similar), which allows me to work solely with ByteStrings,
> bypassing the calls to utf8-string completely. Performance has improved
> noticeably. I'm worried that I've lost full UTF8 compatibility, though,
> haven't I? No double byte characters will work in that setup?

That depends. I'm not familiar with JSON, but iirc, all delimiters are 
ASCII characters, so it could just work.

> Is Data.Text an alternative? Can I use that everywhere, including for
> dealing with sockets (the API only mentions Handle). Should I use
> Data.ByteString.UTF8 everywhere, rewriting the JSON parser to deal with
> this instead of the Word8 ByteStrings?

Data.ByteString.UTF8 uses the ordinary Word8 ByteStrings, it just offers 
some functions to deal with UTF8 encoding.

> In short, what's the fastest way to implement receiving/sending UTF8
> text across sockets?

The fastest way of receiving/sending UTF8 text across sockets is, I 
strongly believe, ByteString. After all, UTF8 text is just a sequence of 
bytes (with special properties). It's what you do between receiving and 
sending where other methods might prove better.
If you use Data.Text, you have to de/encode between UTF8 and UTF16 on 
receiving/sending. That won't be much faster than de/encoding between UTF8 
and String, but Data.Text offers a better API for manipulating text than 
ByteString, so overall, it could be better. Depends on what your needs are, 
you'll have to try it out.

>
> Thanks for any pointer,

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

RE: [Haskell-cafe] base-3 -> base-4

[Sittampalam, Ganesh]

Johannes Waldmann wrote:
> Is there a "conversion guide" for switching from base-3 to base-4?
> 
> I noticed that ghc-HEAD (6.13) comes with base-4.3 (and no base-3).
> This will break an awful lot of packages (?), in fact the breakage
> starts with cabal-install (since it depends on HTTP which depends on
> base-3).  

HTTP can build and seems to work with base 4 if you bump the dependency.
I contacted Sigbjorn about making a new release a while ago, but nothing
has happened yet.

Ganesh

=== 
Please access the attached hyperlink for an important electronic communications 
disclaimer: 
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
=== 

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

[Haskell-cafe] base-3 -> base-4

[Johannes Waldmann]

Is there a "conversion guide" for switching from base-3 to base-4?

I noticed that ghc-HEAD (6.13) comes with base-4.3 (and no base-3).
This will break an awful lot of packages (?), in fact the breakage
starts with cabal-install (since it depends on HTTP which depends on base-3).


PS: I use gmane.org for posting, and they have these seemingly
random "text captchas", and for this post, it reads "continuity"...

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

Re: [Haskell-cafe] Unnecessarily strict implementations

[Daniel Fischer]

On Friday 03 September 2010 12:28:43, Jan Christiansen wrote:
> Hi,
>
> On 03.09.2010, at 01:32, Daniel Fischer wrote:
> > No surprise, there aren't many 'ä's in Shakespeare's works, are there?
>
> nope
>
> > On the other hand, the current implementation of lines does not seem
> > to
> > suffer from Wadler's tuple space leak (according to one test I
> > made), so
> > I'd stick with the current implementation for the time being.
>
> Well, I think it does.

Indeed. I botched my test, allowing it to drop the reference to the first 
line too early by not using enough of it, so although lines shows the leak,

let {
  ds1_s1ts :: ([Char], [Char])
  LclId

  ds1_s1ts =
case $wbreak @ Char lvl_r1uj wild_B1
of _ { (# ww1_anp, ww2_anq #) ->
(ww1_anp, ww2_anq)
} } in
:
  @ String
  (case ds1_s1ts of _ { (l_aij, _) -> l_aij })
  (case ds1_s1ts of _ { (_, s'_ail) ->
   case s'_ail of _ {

, I managed to conceal it.


> But obviously one can argue that this is a rare application.

Yes. Ordinarily, lines in text files aren't longer than a few hundred 
characters, leaking those, who cares?
But. Occasionally, long lines occur, and avoiding the space leak seems more 
important to me than having
lines (_|_ : _|_) = _|_ : _|_
instead of
lines (_|_ : _|_) = _|_

> Hopefully I haven't made a mistake here?

No.

>
> By accident I stumbled across an odd behaviour. If I use the following
> definition and replace all occurrences of break by break' in the
> program above the memory behaviour is bad if I compile it without
> profiling. But if I compile the program with -prof -auto-all the
> program runs in constant space. Is this a known behaviour?

I can't reproduce that. For me, it leaks also with profiling.

>
> break' :: (a -> Bool) -> [a] -> ([a],[a])
> break' p xs = (ys,zs)
>   where
>(ys,zs) = break p xs
>
> Cheers, Jan

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

Re: [Haskell-cafe] Restricted type classes

[Ivan Lazar Miljenovic]

On 3 September 2010 22:23, John Lato  wrote:
>> 1) How should I name the kind * versions?  For example, the kind *
>> version of Functor is currently called Mappable with a class method of
>> rigidMap.  What should I call the kind * version of Foldable and its
>> corresponding methods?  Is there a valid system I can use for these?
>
> You could prefix (or postfix) classes with an 'R' similar to RMonad, but
> that would conflict with the rmonad package.  For just Foldable, maybe
> Reduceable?

Well, I wanted the kind * -> * versions to have the same names as the
ones in base so that they're kinda drop-in.

> Do you have a kind * implementation of Foldable?  I'd be interested in
> seeing it, because I was unable to create a usable implementation (based
> upon the RMonad scheme) on my last attempt.

I was going to make it a subset of Foldable: fold, foldr, foldl, etc.

>> 2) How far should I go?  Should I restrict myself to the
>> "data-oriented" classes such as Functor, Traversable, etc. or should I
>> try to make restricted versions of Applicative and Monad?  Assuming I
>> should:
>
> I don't have a strong opinion either way, but could you re-use RMonad and
> RFunctor from the rmonad package?

Well, I could except that I didn't want the `R' prefix.  Also, if I
end up putting in the Applicative constraint, etc. for Monad then I
obviously can't re-use RMonad.

>> 2c) Should I keep the classes as-is, or should I explicitly put in the
>> constraints mentioned in the Typeclassopedia (e.g. make Applicative an
>> explicit superclass of Monad, and define return = pure for
>> compatability reasons)?  If so, should I bring over Pointed, etc. from
>> category-extras to round out the set or just stick with classes that
>> are already in base?
>
> +1 for using the proper constraints, and especially for bringing over
> Pointed (and anything else that applies).

That's one vote for...

>> 3) Am I wasting my time with this?
>
>
> I would find it useful, and I appreciate all the care you're putting into
> the design.

Oh, good, so I'm not going to be the only user of this library...

-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Restricted type classes

[John Lato]

>
> From: Ivan Lazar Miljenovic 
>
> When I released the first version of container-classes (which I hacked
> on during AusHac), some people said I should split out the various
> folding, etc. into duplicates of the current Foldable class, etc.
> rather than having large monolithic classes.
>
> I've been working on this (see my more recent email with the subject
> along the lines of "fighting the type system"), and I think I've
> worked out how to do this:
>
> * Have one version of the class (when this makes sense) for values of kind
> *
>
> * Have another version that's closer to the original class for kind *
> -> *  but allowing restrictions (e.g. allowing Set to be an instance
> of Functor).  This is based upon Ganesh Sittampalam's rmonad package
> (http://hackage.haskell.org/package/rmonad).
>
> Rather than my original goal of forcing all kind * -> * values to be
> instances of the kind * classes, my new approach is to write instances
> that automatically make all instances of a * ->  * class to also be an
> instance of the kind * class, and to use a newtype wrapper with a
> phantom type value to allow lifting/promotion of a kind * value to a
> kind * -> * value (e.g. "foo :: (Word8 -> Word8) -> ByteString ->
> ByteString; foo f = unpromote . fmap f . Promote" is a valid usage,
> rather than using the kind * function of rigidMap).
>
> My goal with this is that if I have duplicated a class Foo to allow
> restricted values, then it should be a drop-in replacement for the
> original in terms of _usage_ (i.e. the class and method/function names
> are the same, but the type signatures are not).  However, I would
> appreciate the communities advice on a few matters:
>
> 1) How should I name the kind * versions?  For example, the kind *
> version of Functor is currently called Mappable with a class method of
> rigidMap.  What should I call the kind * version of Foldable and its
> corresponding methods?  Is there a valid system I can use for these?
>

You could prefix (or postfix) classes with an 'R' similar to RMonad, but
that would conflict with the rmonad package.  For just Foldable, maybe
Reduceable?

Do you have a kind * implementation of Foldable?  I'd be interested in
seeing it, because I was unable to create a usable implementation (based
upon the RMonad scheme) on my last attempt.


>
> 2) How far should I go?  Should I restrict myself to the
> "data-oriented" classes such as Functor, Traversable, etc. or should I
> try to make restricted versions of Applicative and Monad?  Assuming I
> should:
>

I don't have a strong opinion either way, but could you re-use RMonad and
RFunctor from the rmonad package?


> 2c) Should I keep the classes as-is, or should I explicitly put in the
> constraints mentioned in the Typeclassopedia (e.g. make Applicative an
> explicit superclass of Monad, and define return = pure for
> compatability reasons)?  If so, should I bring over Pointed, etc. from
> category-extras to round out the set or just stick with classes that
> are already in base?
>

+1 for using the proper constraints, and especially for bringing over
Pointed (and anything else that applies).


>
> 3) Am I wasting my time with this?
>

I would find it useful, and I appreciate all the care you're putting into
the design.

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

[Haskell-cafe] Confused about ByteString, UTF8, Data.Text and sockets, still.

[JP Moresmau]

Hello all

After reading the modules docs and some other discussions, I'm still not
sure what's the best choice of tools for my problem. I'm looking at the
scion server code base. At the moment, it's reading and writing on sockets
using Lazy ByteStrings, then converting them to Haskell Strings
using utf8-string. The Haskell Strings are then parsed as JSON using the
JSon package. the response is in JSON, translated back with utf8-string to
ByteStrings.
This is efficient for small strings, but as I'm extending the API I have
calls with much more data, and performance degrades significantly. Timings
seem to point to the encoding of the String to UTF8.
I have replaced JSon by AttoJson (there was also JSONb, which seems quite
similar), which allows me to work solely with ByteStrings, bypassing the
calls to utf8-string completely. Performance has improved noticeably. I'm
worried that I've lost full UTF8 compatibility, though, haven't I? No double
byte characters will work in that setup?
Is Data.Text an alternative? Can I use that everywhere, including for
dealing with sockets (the API only mentions Handle). Should I use
Data.ByteString.UTF8 everywhere, rewriting the JSON parser to deal with this
instead of the Word8 ByteStrings?
In short, what's the fastest way to implement receiving/sending UTF8 text
across sockets?

Thanks for any pointer,
-- 
JP Moresmau
http://jpmoresmau.blogspot.com/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Unnecessarily strict implementations

[Arie Peterson]

On Fri, 3 Sep 2010 12:02:22 +1000, Ivan Lazar Miljenovic
 wrote:
> What precisely do you mean by natural ordering?

An ordering that has relevant meaning for the information represented
by the datatype. Ideally, it should also be alone in being the order
anyone would expect this datatype to have (because instances are
global). (If there is not a single most obvious ordering, then don't
define an instance for Ord – chances are someone will use it with the
wrong expectations. We may use newtypes instead.)

>> A separate type class for types which can be ordered in some (possibly
>> arbitrary) way, for use in Data.Map, would remedy this.
> 
> Sure... except that the way Data.Map and Data.Set are implemented is
> by a binary tree, and you typically want some kind of ordering for
> those.

Yes, so you would use the (possibly arbitrary) ordering provided by the
new class.

> How is a type class that represents arbitrary ordering any different
> from what we already have?

The important thing is that there are *two* classes: one for "natural",
semantic orderings, and one for arbitrary orderings.

Henning's example of the Gaussian integers is excellent. We would be
able to have Sets of gaussians, and still catch mistaken uses of '<' on
them.

There is a further advantage to this separation. Some types may have a
"natural", obvious ordering that is hard to compute, while their
representation also allows a fast comparison, that has nothing to do
with the semantics of the type (is "arbitrary"). Further, if you change
the representation, you can also change to a new arbitrary ordering,
which is more efficient in this new situation, without ever touching the
semantic ordering, so users of the type need not know.

> The notation might not be the best if you
> consider the ordering to be arbitrary, but what else would you use?
> "isArbitrarilyBefore :: (ArbitraryOrdering a) => a -> a -> Bool" ?

Yes, something like that. If you use it a lot, say in the
implementation of Data.Set, you can make a nice local operator alias
(say, ≼ or ⊑).


Regards,

Arie

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

Re: [Haskell-cafe] Unnecessarily strict implementations

[Neil Brown]

On 03/09/10 11:11, Henning Thielemann wrote:


Ivan Lazar Miljenovic schrieb:

On 3 September 2010 04:57, Arie Peterson  wrote:

On Thu, 2 Sep 2010 19:30:17 +0200, Daniel Fischer
 wrote:

Why would one consider using Ord for Map an abuse?
A kludge, for performance reasons, but an abuse?

Because it forces one to declare Ord instances for types which have no
natural ordering. It is useful to *not* have such instances, in 
order to

catch programming errors.


What precisely do you mean by natural ordering?


E.g. I wanted to have a Set of Gaussian (complex) integers, but I did
not want to define an Ord instance for them, because writing
  a < (b :: Gaussian)
is a bug with high probability.


Isn't this what newtype is good for?  Instead of declaring Ord Gaussian 
to get Set Gaussian and risking the bug you describe, create newtype 
GaussianInSet = G Gaussian, declare Ord GaussianInSet and use Set 
GaussianInSet.


Thanks,

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

[Haskell-cafe] Ord instance of Bool (Was: Unnecessarily strict implementations)

[Henning Thielemann]

Ivan Lazar Miljenovic schrieb:

On 3 September 2010 16:49, Henning Thielemann
 wrote:



You might object, that it is seldom, that someone intentionally writes
(a

Fair enough, but on the other hand I don't think we should make a
fetish about enforcing _everything_ in the type system (non-empty
lists, etc.).


I would like to express even more in type system. For instance I have
recently invested several weeks for hunting space leaks in my code and
I'm still not sure, I catched them all. A way to express absence of
space leaks in the type system would save me a lot of time and would
give me confidence.

Regarding True=1 and False=0:
Once I programmed in a language where True was represented by -1,
because this is represented by bit pattern 11. The CPU has an
instruction to fill a byte with the content of a flag and you can use
this bit pattern for bitwise AND and OR operations. This makes this
representation very efficient. This programming language also allowed
comparison and conversion of True and False to their numeric
representations. I used this intensively. Now imagine I port such
programs to Haskell or C, I get lots of bugs for free.

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

[Haskell-cafe] Ord instance of Bool (Was: Unnecessarily strict implementations)

[Henning Thielemann]

Henning Thielemann schrieb:

Ivan Lazar Miljenovic schrieb:

On 3 September 2010 04:57, Arie Peterson  wrote:

On Thu, 2 Sep 2010 19:30:17 +0200, Daniel Fischer
 wrote:

Why would one consider using Ord for Map an abuse?
A kludge, for performance reasons, but an abuse?

Because it forces one to declare Ord instances for types which have no
natural ordering. It is useful to *not* have such instances, in order to
catch programming errors.

What precisely do you mean by natural ordering?


E.g. I wanted to have a Set of Gaussian (complex) integers, but I did
not want to define an Ord instance for them, because writing
  a < (b :: Gaussian)
is a bug with high probability.


I like to answer in advance to the objections that might come. :-)

You might object, that it is seldom, that someone intentionally writes
(ahttp://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Unnecessarily strict implementations

[Henning Thielemann]

Ivan Lazar Miljenovic schrieb:

On 3 September 2010 04:57, Arie Peterson  wrote:

On Thu, 2 Sep 2010 19:30:17 +0200, Daniel Fischer
 wrote:

Why would one consider using Ord for Map an abuse?
A kludge, for performance reasons, but an abuse?

Because it forces one to declare Ord instances for types which have no
natural ordering. It is useful to *not* have such instances, in order to
catch programming errors.


What precisely do you mean by natural ordering?


E.g. I wanted to have a Set of Gaussian (complex) integers, but I did
not want to define an Ord instance for them, because writing
  a < (b :: Gaussian)
is a bug with high probability.


A separate type class for types which can be ordered in some (possibly
arbitrary) way, for use in Data.Map, would remedy this.


Sure... except that the way Data.Map and Data.Set are implemented is
by a binary tree, and you typically want some kind of ordering for
those.

How is a type class that represents arbitrary ordering any different
from what we already have?  The notation might not be the best if you
consider the ordering to be arbitrary, but what else would you use?
"isArbitrarilyBefore :: (ArbitraryOrdering a) => a -> a -> Bool" ?


Yes, something this way. (<) suggests a notion of magnitude for me,
which some orderings do not have.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Crypto-API is stabilizing

[Sebastian Fischer]

On Sep 3, 2010, at 10:40 AM, Sebastian Fischer wrote:

An advantage of using a MonadRandom class would be that the  
CryptoAPI would be independent of RandomGen or your new alternative.  
One could define random monads based on either.


I was wrong. The MonadRandom class uses the Random class which uses  
RandomGen.





--
Underestimating the novelty of the future is a time-honored tradition.
(D.G.)



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

[Haskell-cafe] New .hs File Icons

[Christian Eltges]

Hello,

I was wondering why the File-Icon installed by GHC with the lambda for
.hs files hasn't changed to the new
bind+lambda icon used on haskel.org.
Is this because it should be the same as the icon used by hugs?
I've created a new icon myself, which I use on my pc (using the svg
file from the haskell wiki).
So if the only reason for using the old icon was, that there is no new
one, then you can use this.

Best regards

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

Re: [Haskell-cafe] Re: Crypto-API is stabilizing

[Sebastian Fischer]

In general, I like this approach, but what are

   encrypt privateKey

or

   decrypt publicKey

supposed to do? A type-class solution also does not *prevent*  
programmers to perform such non-sensical calls


Would it be desirable to prohibit such calls using the type system?


--
Underestimating the novelty of the future is a time-honored tradition.
(D.G.)



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

Re: [Haskell-cafe] Re: Crypto-API is stabilizing

[Sebastian Fischer]

[CC'ing maintainer of MonadRandom]

On Sep 3, 2010, at 1:59 AM, Thomas DuBuisson wrote:


 data Key = Key {
  encrypt   :: B.ByteString -> B.ByteString,
  decrypt   :: B.ByteString -> B.ByteString,
  keyLength :: BitLength,
  serialize :: B.ByteString}

 rsa :: RandomGen g => BitLength -> g -> ((Key,Key), g)


One reason against this is simply that all the other constructs
(block/stream cipher, hashes) are classes, it would be odd for there
to be a single exception.  A better reason is the data structure has
no way to implement generateKeyPair.


Also, the type-class approach is extensible in that new operations  
(for example for signing) can be added via subclasses. Later extending  
the key type above requires nesting.



Why not use

   generateKeypair :: MonadRandom m => BitLength -> m (Maybe (p,p))


Because MonadRandom dictates mtl, and is heavier weight than a single
class.  I was hoping to keep this agnostic (mtl is only required for
testing or benchmarks in crypto-api).


I think mtl is only used for the instances, not for the class itself.  
Maybe the maintainer of MonadRandom is inclined to split the package  
if this would raise the number of users of the class.



If MR the more agreeable path
then I'll do it, though this means I use the unholy "fail" function.


You don't want to use monads because the Monad class defines the fail  
function?



Even if that's the case (and more people weighing in would help) I
still want to include Data.Crypto.Random and welcome comments.


An advantage of using a MonadRandom class would be that the CryptoAPI  
would be independent of RandomGen or your new alternative. One could  
define random monads based on either.


Sebastian

--
Underestimating the novelty of the future is a time-honored tradition.
(D.G.)



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

Re: [Haskell-cafe] Unnecessarily strict implementations

[Alexander Solla]

On Sep 2, 2010, at 11:35 PM, Henning Thielemann wrote:


But in the lattice example the roles of 0 and 1 are interchangeable,
aren't they?


Sort of.  If you try to interchange the roles of 0 and 1, you are  
interchanging the roles of the meet and join operations.  In short,  
you are constructing the dual lattice.  A mirror image is a good  
analogy for this construction.


So, 0 and 1 are interchangeable.  In the same way that "True" and  
"False" are.  And "Top" and "Bottom".  And "Left" and "Right".   
Arbitrary structurally, but with a history of consistency across  
domains.

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