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

[Bertram Felgenhauer]

I wrote:
> With binary 0.5,

Or binary 0.4.3 and later.

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

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

[Bertram Felgenhauer]

Neil Mitchell wrote:
> Hi,
> 
> I want to read a file using Data.Binary, and I want to read the file
> strictly - i.e. when I leave the read file I want to guarantee the
> handle is closed. The reason is that (possibly immediately after) I
> need to write to the file. The following is the magic I need to use -
> is it all necessary, is it guaranteed correct, should I use something
> else?
> 
> src <- decodeFile "_make/_make"
> Map.size mp `seq` performGC

With binary 0.5,

src <- decodeFile "_make/_make"
return $! src

should close the file, assuming that all the data is read from the file,
thanks to this patch:

  Mon Aug 25 23:01:09 CEST 2008  Don Stewart 
* WHNF the tail of a bytestring on decodeFile, will close the resource

For older versions,

import qualified Data.Binary.Get as Get

data EOF = EOF
instance Binary EOF where
get = do
   eof <- Get.isEmpty
   return (if eof then EOF else error "EOF expected")
put EOF = return ()

...
(src, EOF) <- decodeFile "_make/_make"

accomplishes the same effect.

Btw, contrary to what Duncan said, Get is a lazy monad (lazy in its
actions, that is):

instance Binary EOF where
get = do
   eof <- Get.isEmpty
   when (not eof) error "EOF expected"
   return EOF
put EOF = return ()

does not help, because the result (EOF) does not depend on the value
returned by isEmpty.

The idea of using isEmpty for closing the file is not perfect though;
due to the lazy nature of Get, there's a stack overflow lurking below:

main = do
encodeFile "w.bin" [0..100 :: Int]
m <- decodeFile "w.bin"
print $ foldl' (+) 0 (m :: [Int])

One idea to fix this is to force the read data before checking for EOF,
as follows:

   data BinaryRNF a = BinaryRNF a

   instance (NFData a, Binary a) => Binary (BinaryRNF a) where
   get = (\a -> rnf a `seq` BinaryRNF a) `fmap` get
   put (BinaryRNF a) = put a

   main = do
   encodeFile "w.bin" [0..100 :: Int]
   (BinaryRNF m, EOF) <- decode `fmap` L.readFile "w.bin"
   print $ foldl' (+) 0 (m :: [Int])

HTH,

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

Re: [Haskell-cafe] popularity context with Cabal

[Brandon S. Allbery KF8NH]

On 2009 Feb 25, at 18:06, Manlio Perillo wrote:
Debian some time ago introduced the popularity context, to find the  
most installed/used packages:

http://popcon.debian.org/

Is it possible to do something similar with Cabal?


I believe that's a planned feature for Hackage.

--
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




PGP.sig
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] jhc speed

[Luke Palmer]

On Wed, Feb 25, 2009 at 7:43 PM, Bernie Pope wrote:

>
> On 23/02/2009, at 2:22 AM, Luke Palmer wrote:
>
>>
>> By the way, coming up pretty soon, I will need a desugared annotated
>> Haskell for Dana.  If anybody has something like this in the works, I'd love
>> to help with it.  If it does not exist by the time I need it, I will make
>> it, so if anyone is interested in working on it with me, let me know :-)
>>
>> Luke
>>
>
> Hi Luke,
>
> Any progress on that front?


Not yet.  It's still a few items down in the queue.


>
> How much desugaring do you want? What kind of annotations do you want?


Enough desugaring to make Haskell "simple" (yes, I know that's subjective).
 Probably somewhere around System-F (Fw perhaps, once I learn what that is).
 The main things I can think of are getting rid of special notation (do,
list comp., where clauses, infix operators) and expanding typeclasses to
dictionary passing.


> Can you get what you need from the GHC API?


I haven't looked into it, but my guess is not.  The main requirement is that
it (and its desugared target) needs to be really pure (no IO, FFI, or
polymorphic seq), and that it must be able to desugar itself.  It might
provide a good launching point though.

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

[Haskell-cafe] Re: Hoogle and Network.Socket

[Achim Schneider]

"John A. De Goes"  wrote:

> The problem is that PL research is probably not going to stop
> evolving in our lifetimes. Yes, that research needs a venue, but why
> should it be Haskell? Haskell is a good language and it's time to
> start benefiting from the research that's already gone into it. That
> means some tradeoffs.
> 
Why shouldn't it be Haskell?
So then, build an enterprise-style language using it, noone is going to
stop you. Noone is going to stop you benefiting from it, either. You
might have to have to pay the price of a moving target, though, as
people just won't stop innovating. Tradeoffs, everywhere...

> Haskell is already behind state-of-the art in PL research and it
> seems unlikely to catch up (witness the slow evolution of Haskell'
> and the non-existent progress on Haskell2). Of course, I could be
> wrong.
>
Not really, look at e.g. type families, which give you much of the
power dependently typed languages give you while saying "nah, not yet"
to the question of how to deal with non-terminating typechecking.
Haskell walks the line between well-understood and bleeding edge,
leaning a bit towards well-understood, for sanity's and stability's
sake. 

About the H' progress... It's hard to tell how many drops are needed to
make a bucket overflow, especially if you've got no idea what the
bucket looks like. What certainly isn't happening is people taking a
house, trying to overflow a badly leaking bucket.

-- 
(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

Re: [Haskell-cafe] jhc speed

[Bernie Pope]

On 23/02/2009, at 2:22 AM, Luke Palmer wrote:


By the way, coming up pretty soon, I will need a desugared annotated  
Haskell for Dana.  If anybody has something like this in the works,  
I'd love to help with it.  If it does not exist by the time I need  
it, I will make it, so if anyone is interested in working on it with  
me, let me know :-)


Luke


Hi Luke,

Any progress on that front?

How much desugaring do you want? What kind of annotations do you want?

Can you get what you need from the GHC API?

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

Re: [Haskell-cafe] Re: Hoogle and Network.Socket

[John A. De Goes]

The problem is that PL research is probably not going to stop evolving  
in our lifetimes. Yes, that research needs a venue, but why should it  
be Haskell? Haskell is a good language and it's time to start  
benefiting from the research that's already gone into it. That means  
some tradeoffs.


Haskell is already behind state-of-the art in PL research and it seems  
unlikely to catch up (witness the slow evolution of Haskell' and the  
non-existent progress on Haskell2). Of course, I could be wrong.


Regards,

John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration

http://www.n-brain.net|877-376-2724 x 101

On Feb 25, 2009, at 6:19 PM, Achim Schneider wrote:


"John A. De Goes"  wrote:


Personally, I'd be happy to see that explosion of innovation in the
library and tool spaces, even if it means the language itself stops
evolving (for the most part). It will make it a lot easier do use
Haskell commercially, and the innovators in the language space will
find or invent a new target to keep themselves occupied.


And this is why we must avoid success: It would mean instant failure.
There are already enough hype-languages around, there's not too much  
of

a point to add one to them. Haskell won't stop evolving and
(conservatively) keeping up with PL research until that's done, or
Dependent Typing is well-understood, whatever comes first.

--
(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 mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] jhc speed

[Andrea Vezzosi]

2009/2/22 Luke Palmer :
> On Sun, Feb 22, 2009 at 8:15 AM, John Meacham  wrote:
>>
>> On Sun, Feb 22, 2009 at 03:36:34PM +0100, Peter Verswyvelen wrote:
>> > Would it be possible to separate the frontend (Haskell to Core) and
>> > backend
>> > (Core to machine code) from the Haskell compilers (requiring a standard
>> > Core
>> > language?)
>> > I'm not sure how many extensions required a change to the Core language.
>>
>> Well, it depends on what you mean by 'core'. If you mean a desugared
>> version of haskell, I think such a front end could be quite useful.
>
> By the way, coming up pretty soon, I will need a desugared annotated Haskell
> for Dana.  If anybody has something like this in the works, I'd love to help
> with it.  If it does not exist by the time I need it, I will make it, so if
> anyone is interested in working on it with me, let me know :-)

The ghc-api exposes a type for annotated source:

http://haskell.org/ghc/docs/latest/html/libraries/ghc/GHC.html#t%3ATypecheckedSource

Not that i know how to use it.

> Luke
>
>
>>
>> in
>> particular, I'd like to see a standalone implementation of template
>> haskell. If you mean something lower level, as in the ghc core
>> intermediate language the compiler uses internally, or jhc's core or
>> grin representation, things get a bit more tricky.
>>
>> Although many core languages are somewhat similar, based on a typed
>> lambda calculus of some sort, the details will differ, and translating
>> between them can be lossy.
>>
>> For instance, looking at jhc core:
>> http://repetae.net/computer/jhc/manual.html#jhc-core-type-system
>> you can see it has a very rich language for dealing with strictness and
>> boxedness. For instances, a boxed value known to be in WHNF actually has a
>> different _type_ than one that is possibly unevaluated. Such
>> distinctions are quite useful for jhc's back end but not so much for
>> ghc's, hence ghc core doesn't make that distinction and any translation
>> between the two would 'lose' that useful information.
>>
>> In other cases things are even worse, for instance ghc has a powerful
>> type equality concept in its core language which jhc has no counterpart
>> for, so that information will be lost on translation. But losing that
>> information will actually cause the core to not type check, since ghc
>> core can type some things jhc core cannot (and vice versa) so coercions
>> or other mechanisms to bypass the type system will have to be
>> introduced.
>>
>> So, it is certainly possible to translate between the two, in fact, I
>> made a jhc core -> ghc core translator, but the code it produced was
>> necessarily riddled with unsafeCoerce#'s for everywhere the type systems
>> didn't quite match up.
>>
>>        John
>>
>>
>> --
>> John Meacham - ⑆repetae.net⑆john⑈
>> ___
>> 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 mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Hoogle and Network.Socket

[Achim Schneider]

Achim Schneider  wrote:

> whatever comes first.
>
uhhh, make that "whatever comes last" 


-- 
(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] Re: Hoogle and Network.Socket

[Achim Schneider]

"John A. De Goes"  wrote:

> Personally, I'd be happy to see that explosion of innovation in the  
> library and tool spaces, even if it means the language itself stops  
> evolving (for the most part). It will make it a lot easier do use  
> Haskell commercially, and the innovators in the language space will  
> find or invent a new target to keep themselves occupied.
>
And this is why we must avoid success: It would mean instant failure.
There are already enough hype-languages around, there's not too much of
a point to add one to them. Haskell won't stop evolving and
(conservatively) keeping up with PL research until that's done, or
Dependent Typing is well-understood, whatever comes first.

-- 
(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

Re: [Haskell-cafe] Re: Hoogle and Network.Socket

[John A. De Goes]

I don't think it's that black and white.

At the lower end, when the language is controlled by a few, there's  
not much innovation poured into the language or libraries, and there  
are no tools to support development. As the community grows, you see  
much more innovation in language and libraries, and maybe a few  
primitive tools. With much greater, the community demands backward  
compatibility, so the language itself may only evolve in highly  
constrained ways (ways that are usually detrimental to consistency),  
but the library space explodes with innovation, and the tools become  
extremely powerful.


Personally, I'd be happy to see that explosion of innovation in the  
library and tool spaces, even if it means the language itself stops  
evolving (for the most part). It will make it a lot easier do use  
Haskell commercially, and the innovators in the language space will  
find or invent a new target to keep themselves occupied.


Regards,

John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration

http://www.n-brain.net|877-376-2724 x 101

On Feb 25, 2009, at 5:52 PM, Jonathan Cast wrote:


On Wed, 2009-02-25 at 17:54 -0700, John A. De Goes wrote:

It's a chicken-egg thing. A Linux or OS X developer tries Haskell and
finds he can write useful programs right away, with a minimum of  
fuss.

But a Windows user tries Haskell and finds he has access to very few
of the really good libraries, and even the cross-platform libraries
won't build without substantial effort. As a result, I bet it's  
easier
for a Linux or OS X developer to like Haskell than a Windows  
developer.


I use OS X exclusively myself, but I'll ensure my first published
Haskell library is cross-platform compatible, because I think it's
good for the community. The more people using Haskell, the more
libraries that will be written, the more bugs that will be fixed, the
more creativity that will be poured into development of libraries and
the language itself.


I don't think this is founded in experience.  The experience of the  
last

5 years is that the more people use Haskell, the more important
backward-compatibility concerns become, and the harder it becomes for
Haskell to continue evolving.

Creativity being poured into a language doesn't do much good if the
result is the language moving sideways, still less the language  
growing

sideways.

jcc




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

Re: [Haskell-cafe] Re: Hoogle and Network.Socket

[Jonathan Cast]

On Wed, 2009-02-25 at 17:54 -0700, John A. De Goes wrote:
> It's a chicken-egg thing. A Linux or OS X developer tries Haskell and  
> finds he can write useful programs right away, with a minimum of fuss.  
> But a Windows user tries Haskell and finds he has access to very few  
> of the really good libraries, and even the cross-platform libraries  
> won't build without substantial effort. As a result, I bet it's easier  
> for a Linux or OS X developer to like Haskell than a Windows developer.
> 
> I use OS X exclusively myself, but I'll ensure my first published  
> Haskell library is cross-platform compatible, because I think it's  
> good for the community. The more people using Haskell, the more  
> libraries that will be written, the more bugs that will be fixed, the  
> more creativity that will be poured into development of libraries and  
> the language itself.

I don't think this is founded in experience.  The experience of the last
5 years is that the more people use Haskell, the more important
backward-compatibility concerns become, and the harder it becomes for
Haskell to continue evolving.

Creativity being poured into a language doesn't do much good if the
result is the language moving sideways, still less the language growing
sideways.

jcc


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

Re: [Haskell-cafe] Re: Hoogle and Network.Socket

[John A. De Goes]

It's a chicken-egg thing. A Linux or OS X developer tries Haskell and  
finds he can write useful programs right away, with a minimum of fuss.  
But a Windows user tries Haskell and finds he has access to very few  
of the really good libraries, and even the cross-platform libraries  
won't build without substantial effort. As a result, I bet it's easier  
for a Linux or OS X developer to like Haskell than a Windows developer.


I use OS X exclusively myself, but I'll ensure my first published  
Haskell library is cross-platform compatible, because I think it's  
good for the community. The more people using Haskell, the more  
libraries that will be written, the more bugs that will be fixed, the  
more creativity that will be poured into development of libraries and  
the language itself.


Regards,

John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration

http://www.n-brain.net|877-376-2724 x 101

On Feb 25, 2009, at 5:29 PM, Achim Schneider wrote:


John Lato  wrote:


I really don't see anything wrong with using Hoogle to increase
awareness (although I would appreciate it if platform-specific
packages were searched as an option).


You won't hear me argue against it, in fact, I argued in favour of it.
Increasing awareness of cross-platform solutions, as well as providing
them, is a very different thing than demanding cross-platform support.

If 80% of all computer users use Windows, there shouldn't be any
problems recruiting a decent number of volunteers to care about
Haskell's Windoze support, should there?

--
(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 mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Hoogle and Network.Socket

[Achim Schneider]

John Lato  wrote:

> I really don't see anything wrong with using Hoogle to increase
> awareness (although I would appreciate it if platform-specific
> packages were searched as an option).
>
You won't hear me argue against it, in fact, I argued in favour of it.
Increasing awareness of cross-platform solutions, as well as providing
them, is a very different thing than demanding cross-platform support.

If 80% of all computer users use Windows, there shouldn't be any
problems recruiting a decent number of volunteers to care about
Haskell's Windoze support, should there?

-- 
(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] Re: Hoogle and Network.Socket

[John Lato]

Achim Schneider wrote:
> John Lato  wrote:
>> On Wed, Feb 25, 2009 at 4:45 PM, Brandon S. Allbery KF8NH
>>  wrote:
>> > On 2009 Feb 25, at 5:23, John Lato wrote:
>> >>
>> >> Brandon Allbery wrote:
>> >>>
>> >>> I have to second this; I'm a Unix sysadmin, 98% of the time if I'm
>> >>> writing a program it's for Unix *and* requires POSIX APIxs, and
>> >>> even if it could apply to Windows the program needed there would
>> >>> be very significantly different. __And we have a Windows group for
>> >>> that.
>> >>
>> >> 2. __As of now, the "Windows Group" seems to be mostly Duncan. __And
>> >
>> > Wrong Windows group: __Duncan doesn't work for us.
>> >
>>
>> Sorry, I misunderstood you.  I thought you meant a Windows group
>> within the Haskell community, not within your company.
>>
>> Honestly, what I wrote wasn't directed at you.  As I mentioned before,
>> writing code as a Unix sysadmin has very different priorities than
>> writing for many other problem domains.  Most of your code wouldn't
>> make sense outside a Unix context, whereas bytestrings, tries, or
>> graph libraries would.
>>
> I don't think it makes sense to talk about missing support on any
> platform: In a strict sense, how well a platform is supported is a
> function of how many people care to use it. While there seems to be a
> disparity between people developing programs on/for Windoze and people
> working on Windoze's cross-platform capabilities wrt. Haskell, this
> does not mean that you can rightfully expect people who chose not to use
> your favourite platform to give a damn about it. Search for allies
> amidst your pals.

Somehow I really gave off the wrong impression.  Windows is most
definitely not my favorite platform.  My primary development computer
is currently a MacBook, and my secondary system runs Linux.  I'm
advocating for Windows for two reasons:

1.  There are a non-trivial number of Windows Haskellers, and they
frequently post about problems on this list.  I would like to make
their lives a little better..

2.  A substantial portion of computer users are on Windows.  If I want
them to use my software, or even expose them to the glory of Haskell,
I need to speak their language.

A possible third reason is that I have used some number of
gnu-toolchain-developed programs on Windows (using mingw), and the
experience is frequently miserable.  Graphics libraries lag, all sorts
of configuration errors, missing packages, etc.  Compared to that, the
GHC compiler chain and libraries are fantastic.  It pretty much works,
and I think it can be better.  I would like to see a wider adoption of
Haskell in general, and improving Haskell support for windows is would
definitely help.

>
> I honestly doubt that iff a viable[1] way to support multiple platforms
> exists any developer aware of it would choose a platform-locked in
> alternative. This is the only thing you can hope for, and the only
> thing you need to provide to other developers to get platform support
> for free. There's a free lunch, after all, but you gotta bring your own
> dishes. Or pay someone to spoon-feed you, but that's another issue.
>

I think Haskell is a lot closer to this than many other languages.
Generally, Haskell packages that don't work on Windows fall into one
of three categories:

1.  Packages that link to a C library, in which case it depends on the
underlying library.
2.  Packages that are closely tied to Unix/Posix.
3.  Packages that depend on one of the above (or another in this category).

It's the third category that's mostly under discussion here.  If
Package A is posix-dependent, but a cross-platform alternative is
available, then by using the cross-platform alternative Package B
really can get Windows compatibility for free (assuming equivalent
functionality between alternatives).  I really don't see anything
wrong with using Hoogle to increase awareness (although I would
appreciate it if platform-specific packages were searched as an
option).

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

[Haskell-cafe] Re: Hoogle and Network.Socket

[Achim Schneider]

John Lato  wrote:

> you should consider that your unix-dependent software will never
> reach over 80% of the computer users available.
>
Now it's me...

wtf? Why should I care? If those users are not even willing to bend
their little finger to safe me from breaking my back attempting to
support their wretched pile of junk that is being deliberately trying
to boycott cross-platform compability, may they rot away, together with
any notion of software quality or sense of responsibility to care about
stuff you deem important that _might_ be left in the camp of
microslaves. And Microsoft itself, while I'm at it.

Being helpful and contributing to a gift society is all Good and Great,
but there's a line that has to be drawn to prevent it from collapsing:
Never, ever, let your actions be dictated by parasitary leeches. If you
want it done, do it. Let your actions tell others that you are standing
on the right side of that line, and you _will_ benefit from society. If
not, STFU or GTFO.

-- 
(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

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

[Duncan Coutts]

On Wed, 2009-02-25 at 17:15 +, Neil Mitchell wrote:
> Hi,
> 
> I want to read a file using Data.Binary, and I want to read the file
> strictly - i.e. when I leave the read file I want to guarantee the
> handle is closed. The reason is that (possibly immediately after) I
> need to write to the file. The following is the magic I need to use -
> is it all necessary, is it guaranteed correct, should I use something
> else?
> 
> src <- decodeFile "_make/_make"
> Map.size mp `seq` performGC

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.

Duncan

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

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

[Duncan Coutts]

On Wed, 2009-02-25 at 16:47 +0100, Wolfgang Jeltsch wrote:
> Am Mittwoch, 25. Februar 2009 14:33 schrieb Duncan Coutts:
> > Note that some people will tell you that by a strict interpretation of
> > the LGPL that statically linked Haskell libs under that license are a
> > pain in the backside. When we decided on that license for gtk2hs that
> > was not our intention. In other words nobody is going to sue you if you
> > statically link gtk2hs libs. Of course if you need a cast iron legal
> > guarantee then that's not good enough and you'd have to ship .a and .o
> > files to let users relink if they wanted to.
> 
> I’m not sure whether this would be enough. .a and .o files are not compatible 
> among GHC versions, as far as I know.

I recall from a FSF FAQ on this issue that it doesn't need to be easy,
just technically possible. There does not need to be a well designed
stable ABI.

> Relinking against newer Gtk2Hs versions 
> might not work. And a program using Gtk2Hs contains code from the .hi files 
> of Gtk2Hs through inlining. So it’s not pure linking.

It is pure linking. It's just not easily achievable from the source
level using standard compilers and tools. Yes if you change the sources
you change the ABI (even when you did not change the API). That's not a
problem as far as the license is concerned (I think).

> However, the LGPL only allows linking, as far as I understand.
> 
> I want to repeat what I’ve said earlier on this list: For Haskell, there is 
> no 
> real difference between LGPL and GPL, as far as I understand it. If you don’t 
> want to force the users of your library to use an open source license for 
> their work then use BSD3 or a similar license for your library.

But of course that is not the only difference. Assuming we can work
around the linking issue the main point for someone to choose LGPL is
guaranteeing that changes are contributed back. We should not tell
people who want to use LGPL that they should just use BSD. That's
changing the spirit of the license for the sake of a mere technicality.
If they want to use the LGPL then we should encourage them to use a
linking exception.

It's also worth looking at what the LGPL-3 has done about this issue.

Duncan
(who takes no position on BSD vs LGPL and has used both)

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

Re: [Haskell-cafe] Re: Hoogle and Network.Socket

[John Lato]

On Wed, Feb 25, 2009 at 3:49 PM, Jonathan Cast
 wrote:
> On Wed, 2009-02-25 at 10:23 +, John Lato wrote:
>> 4.  Cross-platform concerns are something that responsible developers
>> need to consider, just like localization and i18n.  I.e., why
>> *shouldn't* you think of that?
>
> Sorry, wtf?  I have a *responsibility* to design software for a
> miserably poorly-designed God-awful platform I'd have to pay *extra*
> for, and even then couldn't get source to or *fix* if I found a bug?
> No.  You don't control me, to the best of my knowledge you haven't done
> squat for me, and by trying to force me to develop to *that* platform
> you are actively attempting to harm me.
>

I'm not trying to force you (or anyone else) to do anything.  All I'm
saying is that, as a developer, you should consider that your
unix-dependent software will never reach over 80% of the computer
users available.  Now, I don't know anything about what sort of
software you write, maybe your market segment is big iron so you've
already made a decision to ignore Windows.  Maybe you hate Windows so
much you want to deprive its users of your code.  I honestly don't
care.  As a former ASP.Net developer, I can assure you I have no love
for MS.

By responsible developer, I meant accountable for decisions made
during development.  It's fine to say you don't know if your code
doesn't run on Windows because you've made a decision to not support
it (or actively work against it, as the case may be).  It's not fine
to say you don't know because you never thought about it.

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

[Haskell-cafe] popularity context with Cabal

[Manlio Perillo]

Hi.

Debian some time ago introduced the popularity context, to find the most 
installed/used packages:

http://popcon.debian.org/

Is it possible to do something similar with Cabal?


From popularity-context FAQ:
"For each package, popularity-contest looks at the most recently used
(based on atime) files, and reports the filename, its last access time
(atime) and last change time (ctime). However, some files are not
considered, because they have unreliable atime."

"A computer 'vote' for a package if according to the data provided in 
the report, a program provided or depending on the package was used less 
than thirty days ago. This computation is performed by the popcon server."




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

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

[Achim Schneider]

Peter Verswyvelen  wrote:

> So that is interesting. If you don't distribute a program that makes
> use of LPGL libs (e.g. a downloadable EXE), but you provide a remote
> view (in this case a web) on a server that runs that program, then
> the license does not apply...
> Oh well I should just let the lawyers look into all these licenses,
> it's not my domain.
> 
That's what the Affero GPL is designed for: You have to provide source
to everyone who's able to use the program, not just to those that are
able to run it.

-- 
(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] Re: Hoogle and Network.Socket

[Achim Schneider]

John Lato  wrote:

> On Wed, Feb 25, 2009 at 4:45 PM, Brandon S. Allbery KF8NH
>  wrote:
> > On 2009 Feb 25, at 5:23, John Lato wrote:
> >>
> >> Brandon Allbery wrote:
> >>>
> >>> I have to second this; I'm a Unix sysadmin, 98% of the time if I'm
> >>> writing a program it's for Unix *and* requires POSIX APIxs, and
> >>> even if it could apply to Windows the program needed there would
> >>> be very significantly different. __And we have a Windows group for
> >>> that.
> >>
> >> 2. __As of now, the "Windows Group" seems to be mostly Duncan. __And
> >
> > Wrong Windows group: __Duncan doesn't work for us.
> >
> 
> Sorry, I misunderstood you.  I thought you meant a Windows group
> within the Haskell community, not within your company.
> 
> Honestly, what I wrote wasn't directed at you.  As I mentioned before,
> writing code as a Unix sysadmin has very different priorities than
> writing for many other problem domains.  Most of your code wouldn't
> make sense outside a Unix context, whereas bytestrings, tries, or
> graph libraries would.
> 
I don't think it makes sense to talk about missing support on any
platform: In a strict sense, how well a platform is supported is a
function of how many people care to use it. While there seems to be a
disparity between people developing programs on/for Windoze and people
working on Windoze's cross-platform capabilities wrt. Haskell, this
does not mean that you can rightfully expect people who chose not to use
your favourite platform to give a damn about it. Search for allies
amidst your pals.

I honestly doubt that iff a viable[1] way to support multiple platforms
exists any developer aware of it would choose a platform-locked in
alternative. This is the only thing you can hope for, and the only
thing you need to provide to other developers to get platform support
for free. There's a free lunch, after all, but you gotta bring your own
dishes. Or pay someone to spoon-feed you, but that's another issue.


[1] Which mostly means "negligible additional work for the developer"

-- 
(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] differences between Data.Array and Data.Vector

[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?


Thanks   Manlio Perillo
___
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

[Peter Verswyvelen]

So that is interesting. If you don't distribute a program that makes use of
LPGL libs (e.g. a downloadable EXE), but you provide a remote view (in this
case a web) on a server that runs that program, then the license does not
apply...
Oh well I should just let the lawyers look into all these licenses, it's not
my domain.

2009/2/25 Tristan Seligmann 

> * Peter Verswyvelen  [2009-02-25 23:15:24 +0100]:
>
> > On Wed, Feb 25, 2009 at 11:02 PM, Peter Hercek 
> wrote:
> >
> > > * An LGPL library will force commercial users to release their source
> code
> > > only to the users of their program (which already bought it) and only
> for
> > > the purpose of recompiling with a newer version of the LGPL library.
> >
> > Does this also mean one can't make closed source but *free* software
> > that uses LGPL libs? Since all users can then potentially request the
> > source code? E.g. suppose Google would have used LGPL libraries to
> > implement parts of their search engine...
>
> Google doesn't distribute code or binaries for google.com, though
> (although there is the appliance stuff..)
> --
> mithrandi, i Ainil en-Balandor, a faer Ambar
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.9 (GNU/Linux)
>
> iEYEARECAAYFAkmlx4YACgkQpNuXDQIV94rO6gCeLp5pkzXQkXIfFmwwCSWHQX3o
> QscAn1ipd1Sft/K5QKiYtT9y15ssdnrk
> =sZXJ
> -END PGP SIGNATURE-
>
> ___
> 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] Re: base-4 + gtk2hs-0.10.0 licensing

[Peter Hercek]

Peter Verswyvelen wrote:

On Wed, Feb 25, 2009 at 11:02 PM, Peter Hercek  wrote:

  

* An LGPL library will force commercial users to release their source code
only to the users of their program (which already bought it) and only for
the purpose of recompiling with a newer version of the LGPL library.



Does this also mean one can't make closed source but *free* software
that uses LGPL libs? Since all users can then potentially request the
source code? E.g. suppose Google would have used LGPL libraries to
implement parts of their search engine...
  
I think so. If you acknowledge them as legitimate users and you 
distribute the free program then you must allow them to upgrade the LGPL 
library. With Haskell this may mean releasing the source code. I'm vary 
about this part though. *.o and *.hi may be enough since:

* GHC is not LGPL but some kind of BSD
* only the gmp and gtk2hs are LGPL
* so you do not need to make sure ghc can be upgraded
* you need to make sure gmp can be upgraded and gtk2hs can be upgraded 
but forcing users on the same version of ghc
* requirement to allow upgrade is there only while the LGPL library does 
not change interface


The above should allow to distribute only *.o and *.hi files. If user 
wants to to upgrade GMP or GTK2HS they can do it and recompile with the 
old version of GHC (the one for which you provided *.o and *.hi files.


So my opinion (IAMNAL):
1) source code under very limiting commercial license (just to allow 
recompile with a newer LGPL lib and nothing else) is OK
2) it is probable that only the *.o, *.hi files and a linking script are 
OK too


As for as Google: That is a different case. The GPL/LGPL limitations 
kick in *only* when you redistribute your program. Goolge is not 
redistributing their search engine! They only provide you a service over 
internet! That is very different.


Peter.

___
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

[Tristan Seligmann]

* Peter Verswyvelen  [2009-02-25 23:15:24 +0100]:

> On Wed, Feb 25, 2009 at 11:02 PM, Peter Hercek  wrote:
> 
> > * An LGPL library will force commercial users to release their source code
> > only to the users of their program (which already bought it) and only for
> > the purpose of recompiling with a newer version of the LGPL library.
> 
> Does this also mean one can't make closed source but *free* software
> that uses LGPL libs? Since all users can then potentially request the
> source code? E.g. suppose Google would have used LGPL libraries to
> implement parts of their search engine...

Google doesn't distribute code or binaries for google.com, though
(although there is the appliance stuff..)
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


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

Re: [Haskell-cafe] Re: Hoogle and Network.Socket

[John Lato]

On Wed, Feb 25, 2009 at 4:45 PM, Brandon S. Allbery KF8NH
 wrote:
> On 2009 Feb 25, at 5:23, John Lato wrote:
>>
>> Brandon Allbery wrote:
>>>
>>> I have to second this; I'm a Unix sysadmin, 98% of the time if I'm
>>> writing a program it's for Unix *and* requires POSIX APIxs, and even
>>> if it could apply to Windows the program needed there would be very
>>> significantly different.  And we have a Windows group for that.
>>
>> 2.  As of now, the "Windows Group" seems to be mostly Duncan.  And
>
> Wrong Windows group:  Duncan doesn't work for us.
>

Sorry, I misunderstood you.  I thought you meant a Windows group
within the Haskell community, not within your company.

Honestly, what I wrote wasn't directed at you.  As I mentioned before,
writing code as a Unix sysadmin has very different priorities than
writing for many other problem domains.  Most of your code wouldn't
make sense outside a Unix context, whereas bytestrings, tries, or
graph libraries would.

Cheers,
John Lato
___
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

[Peter Verswyvelen]

On Wed, Feb 25, 2009 at 11:02 PM, Peter Hercek  wrote:

> * An LGPL library will force commercial users to release their source code
> only to the users of their program (which already bought it) and only for
> the purpose of recompiling with a newer version of the LGPL library.

Does this also mean one can't make closed source but *free* software
that uses LGPL libs? Since all users can then potentially request the
source code? E.g. suppose Google would have used LGPL libraries to
implement parts of their search engine...
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

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

[Peter Hercek]

Wolfgang Jeltsch wrote:
I want to repeat what I’ve said earlier on this list: For Haskell, there is no 
real difference between LGPL and GPL, as far as I understand it. If you don’t 
want to force the users of your library to use an open source license for 
their work then use BSD3 or a similar license for your library


Of course there is a difference and a *significant* one.

* A GPL library will force commercial users of the library to release 
their code under GPL.


* An LGPL library will force commercial users to release their source 
code only to the users of their program (which already bought it) and 
only for the purpose of recompiling with a newer version of the LGPL 
library. The users of the commercial program maybe be forbidden to 
redistribute the application source code as well as modifying the 
application source code e.g. to avoid licensing restrictions imposed on 
them by the application seller (the LGPL library user). The commercial 
program owner does not even need to distribute the source code with the 
application by default. It just needs to provide an easy way to obtain 
the source code for all licensed customers (those who bought it) and let 
them prominently know (maybe in the about box of the application) where 
to get the source for the purpose of recompilation with a newer version 
of the LGPL libs.
Providing source code without any other rights than to recompile with a 
newer version of a LGPL lib should not be such a big deal ... that is if 
the commercial application author's business model does not depend on 
some super secret process in the code or does not have something fishy 
stuff to hide :)


The above does not represent a difference only when you assume that all 
your users are crooks which will redistribute everything without a bit 
of hesitation. Then it is up to you whether you wan to sue them :)


Am I missing something?

Peter.

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

Re: [Haskell-cafe] Memoization local to a function

[Henning Thielemann]

On Wed, 25 Feb 2009, Luke Palmer wrote:


On Wed, Feb 25, 2009 at 10:38 AM, Dusan Kolar  wrote:
   I have a function a computation of which is quite expensive, it is 
recursively
  dependent on itself with respect to some other function values - we can 
roughly
  model its behaviour with fib function (returns n-th number of Fibonacci's
  sequence). Unfortunately, it is not fib, it is far more complicated.
  Nevertheless, for demonstration of my question/problem I will use fib, 
it's quite
  good.


I suggest using data-memocombinators for this rather than rolling your own.  It 
accomplishes
the same thing, but makes the choice of memo structure independent of the code 
that uses it
(and Memo.integral has asymptotically better performance than a list).


Nice to know that there is a package for this purpose. See also
  http://haskell.org/haskellwiki/Memoization___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

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

[Daniel Peebles]

The one thing that isn't supported in GHC on Mac OS is the generation
of 64-bit code (better if you have lots of RAM you want to take
advantage of, and also has a lot more independent registers for tight
loops), but with any luck that will change soon (I've been trying to
get it to work).

Cheers,
Dan

On Wed, Feb 25, 2009 at 2:52 PM, Conrad Meyer  wrote:
> On Wednesday 25 February 2009 11:37:15 am Cristiano Paris wrote:
>> Hi,
>>
>> I'm planning to purchase a MacBookPro so I'm wondering how well
>> Haskell is supported under this platform.
>>
>> Thanks,
>>
>> Cristiano
>
> GHC on linux/ppc is not very well supported, but since all new macbooks are
> intel that shouldn't be an issue. And you're probably going to run OS X
> anyways.
>
> Regards,
> --
> Conrad Meyer 
>
> ___
> 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] Memoization local to a function

[Luke Palmer]

On Wed, Feb 25, 2009 at 10:38 AM, Dusan Kolar  wrote:

>  I have a function a computation of which is quite expensive, it is
> recursively dependent on itself with respect to some other function values -
> we can roughly model its behaviour with fib function (returns n-th number of
> Fibonacci's sequence). Unfortunately, it is not fib, it is far more
> complicated. Nevertheless, for demonstration of my question/problem I will
> use fib, it's quite good.


I suggest using
data-memocombinatorsfor
this rather than rolling your own.  It accomplishes the same thing,
but
makes the choice of memo structure independent of the code that uses it (and
Memo.integral has asymptotically better performance than a list).

Luke


>
>
>  I want to store results in a list (array, with its strong size limit that
> I do not know prior to computation, is not suitable) and then pick them up
> using (!!) operator. Well, if the list is "global" function/constant then it
> works quite well. Unfortunately, this is not, what I would like to have.
> Nevertheless, local version does not work.
>
>  Could someone point me to some text that explains it? Memoization text on
> wiki does not seem to be helpful. Time/operation consumption is deduced from
> number of reductions reported by hugs and winhugs (tested both on Linux and
> Windows).
>
>  Thank you for hints,
>
>  Dusan
>
>
> P.S.
> Code I used for testing.
>
> module Testmemo
>   (  fibW
>   ,  fibL
>   ,  fibM
>   )  where
>
>
> fibW m = allfib !! m
>  where
>   allfib = 0:1:[allfib!!n + allfib!!(n+1) | n <- [0..]]
>
>
> fibL m =
>  let
>   allfib = 0:1:[allfib!!n + allfib!!(n+1) | n <- [0..]]
>  in allfib !! m
>
>
> fibM n = myallfib !! n
> myallfib = 0:1:[myallfib!!n + myallfib!!(n+1) | n <- [0..]]
>
> ___
> 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] Status of Haskell under OsX

[Conrad Meyer]

On Wednesday 25 February 2009 11:37:15 am Cristiano Paris wrote:
> Hi,
>
> I'm planning to purchase a MacBookPro so I'm wondering how well
> Haskell is supported under this platform.
>
> Thanks,
>
> Cristiano

GHC on linux/ppc is not very well supported, but since all new macbooks are 
intel that shouldn't be an issue. And you're probably going to run OS X 
anyways.

Regards,
-- 
Conrad Meyer 

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

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

[Miguel Mitrofanov]

I've got an iMac; ghc from MacPorts seems to work fine.

On 25 Feb 2009, at 22:37, Cristiano Paris wrote:


Hi,

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

Thanks,

Cristiano
___
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] Status of Haskell under OsX

[Ross Mellgren]

I use Haskell under OSX only. I find it very well supported.

-Ross


On Feb 25, 2009, at 2:37 PM, Cristiano Paris wrote:


Hi,

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

Thanks,

Cristiano
___
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] Status of Haskell under OsX

[Cristiano Paris]

Hi,

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

Thanks,

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

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

[Magnus Therning]

Conrad Meyer wrote:
> On Wednesday 25 February 2009 07:47:16 am Wolfgang Jeltsch wrote:
>> Am Mittwoch, 25. Februar 2009 14:33 schrieb Duncan Coutts:
>>> Note that some people will tell you that by a strict interpretation of
>>> the LGPL that statically linked Haskell libs under that license are a
>>> pain in the backside. When we decided on that license for gtk2hs that
>>> was not our intention. In other words nobody is going to sue you if you
>>> statically link gtk2hs libs. Of course if you need a cast iron legal
>>> guarantee then that's not good enough and you'd have to ship .a and .o
>>> files to let users relink if they wanted to.
>> I’m not sure whether this would be enough. .a and .o files are not
>> compatible among GHC versions, as far as I know. Relinking against newer
>> Gtk2Hs versions might not work. And a program using Gtk2Hs contains code
>> from the .hi files of Gtk2Hs through inlining. So it’s not pure linking.
>> However, the LGPL only allows linking, as far as I understand.
>>
>> I want to repeat what I’ve said earlier on this list: For Haskell, there is
>> no real difference between LGPL and GPL, as far as I understand it. If you
>> don’t want to force the users of your library to use an open source license
>> for their work then use BSD3 or a similar license for your library.
>>
>> Best wishes,
>> Wolfgang
> 
> 
> Alternatively Haskell could add shared library support, like every other 
> language.

As has already been discussed on this list, shared library support to
obtain substitutability of libraries is problematic in a language like
Haskell too, at least AFAIU. Just consider cross .o inlining...

(Using shared libraries in order to decrease system-wide memory
footprint of Haskell binaries is however a bit easier.)

/M

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

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



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

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

[Conrad Meyer]

On Wednesday 25 February 2009 07:47:16 am Wolfgang Jeltsch wrote:
> Am Mittwoch, 25. Februar 2009 14:33 schrieb Duncan Coutts:
> > Note that some people will tell you that by a strict interpretation of
> > the LGPL that statically linked Haskell libs under that license are a
> > pain in the backside. When we decided on that license for gtk2hs that
> > was not our intention. In other words nobody is going to sue you if you
> > statically link gtk2hs libs. Of course if you need a cast iron legal
> > guarantee then that's not good enough and you'd have to ship .a and .o
> > files to let users relink if they wanted to.
>
> I’m not sure whether this would be enough. .a and .o files are not
> compatible among GHC versions, as far as I know. Relinking against newer
> Gtk2Hs versions might not work. And a program using Gtk2Hs contains code
> from the .hi files of Gtk2Hs through inlining. So it’s not pure linking.
> However, the LGPL only allows linking, as far as I understand.
>
> I want to repeat what I’ve said earlier on this list: For Haskell, there is
> no real difference between LGPL and GPL, as far as I understand it. If you
> don’t want to force the users of your library to use an open source license
> for their work then use BSD3 or a similar license for your library.
>
> Best wishes,
> Wolfgang


Alternatively Haskell could add shared library support, like every other 
language.

Regards,
-- 
Conrad Meyer 

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

Re: [Haskell-cafe] MapReduce reverse engineered

[Daryoush Mehrtash]

>
> since mapReduce assumes that all the code (and the data) is in place in the
> respective nodes.
>


As far as I can tell, the Hadoop, the open source implementation of map
reduce, doesn't require your map reduce code to be in all nodes.  It copies
the jar files of the your application to the nodes that would execute the
code.
http://hadoop.apache.org/core/docs/current/mapred_tutorial.html#Job+Submission+and+Monitoring

Data is also generally available via a network protocol such as http.

I am wondering if  distribution tools (such as Cabal) would be preferable
to  hadoop model.  Instead of having the framework copy the code why not use
the existing tools to install the code prior to running the map-reduce?

daryoush

2009/2/25 Alberto G. Corona 

> Galchin,
>
> Maybe you are asking not only about remote execution, but also mobility of
> code. This is a problem that is previous to mapReduce, since mapReduce
> assumes that all the code (and the data) is in place in the respective
> nodes. In fact, the distribution of resources in order to efficiently use
> mapReduce is a design problem that the google people has done by hand.
> But  my intuition says that there are a general algorithm  for distribution
> of  code, data, bandwidth and resources in general that  moves around at
> execution time to achieve better and better performance for a given grid of
> nodes and for any task, for example, a mapReduce task. I would be very
> interesting to read something about this.
>
> I know that some efforts have been carried out the past , for example
> mobile haskell 
> 
>
>
> http://homepages.inf.ed.ac.uk/stg/workshops/TFP/book/DuBois/duboismhaskell/cameraready.pdf
>  
> 
>
>
> which is a first step for this goal but I this has been discontinued and
> the source code is not available.
>
> 2009/2/25 Galchin, Vasili 
> >
> > Hello,
> >
> >  Here is an interesting paper of Google's MapReduce reverse
> engineered into Haskell. I apologize if already posted .
> http://www.cs.vu.nl/~ralf/MapReduce/
> >
> > Kind regards, Vasili
> >
> > ___
> > 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 mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] forall & ST monad

[Jonathan Cast]

On Wed, 2009-02-25 at 10:18 -0800, Kim-Ee Yeoh wrote:
> 
> Heinrich Apfelmus wrote:
> > 
> > Now,
> > 
> >(forall a. T[a]) -> S
> > 
> > is clearly true while
> > 
> >exists a. (T[a] -> S)
> > 
> > should be nonsense: having one example of a marble that is either red or
> > blue does in no way imply that all of them are, at least constructively.
> >  (It is true classically, but I forgot the name of the corresponding
> > theorem.)
> > 
> 
> For the record, allow me to redress my earlier erroneous 
> assertion by furnishing the proof for the classical case:
> 
> (forall a. T(a)) -> S
> = not (forall a. T(a)) or S, by defn of implication

[For the record: this is the first point at which you confine yourself
to classical logic.]

> = not $ (forall a. T(a)) and (not S), by de Morgan's
> = not $ forall a. T(a) and (not S), product rule???

This step depends on the domain of quantification for the variable a
being non-empty; if the domain is empty, then the RHS is vacuously true,
while the LHS is equal to (not S).

> = exists a. not (T(a)) or S, de Morgan's again
> = exists a. T(a) -> S, by defn of implication

> The only wrinkle is obviously in the logical "and"
> of (not S) distributing under the universal quantifier.

jcc


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

Re: [Haskell-cafe] forall & ST monad

[Kim-Ee Yeoh]

Heinrich Apfelmus wrote:
> 
> Now,
> 
>(forall a. T[a]) -> S
> 
> is clearly true while
> 
>exists a. (T[a] -> S)
> 
> should be nonsense: having one example of a marble that is either red or
> blue does in no way imply that all of them are, at least constructively.
>  (It is true classically, but I forgot the name of the corresponding
> theorem.)
> 

For the record, allow me to redress my earlier erroneous 
assertion by furnishing the proof for the classical case:

(forall a. T(a)) -> S
= not (forall a. T(a)) or S, by defn of implication
= not $ (forall a. T(a)) and (not S), by de Morgan's
= not $ forall a. T(a) and (not S), product rule???
= exists a. not (T(a)) or S, de Morgan's again
= exists a. T(a) -> S, by defn of implication

The only wrinkle is obviously in the logical "and"
of (not S) distributing under the universal quantifier.

-- 
View this message in context: 
http://www.nabble.com/forall---ST-monad-tp22024677p22208626.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] MapReduce reverse engineered

[Alberto G. Corona]

2009/2/25 Alberto G. Corona 

> And it would solve a lot of problem: scalability, system re-configuraition
> and installation: just by  adding or removing nodes at runtime.. heavy
>  numerical computations are also good candidates.
>
> 2009/2/25 Rick R 
>
> I agree. A distributed database could be made as usable as a standard
>> RDBMS by offering an interface by which you supply a map/reduce pair
>> of functions and a list (range?) of keys.
>>
>> This could be easily implemented with a database such as Scalaris, in
>> which the Chord algorithm is responsible for placing and finding the
>> data among nodes.
>>
>> The user would interface with any node in the distributed database,
>> supplying a map and reduce function. It would distribute the map
>> function to nodes of its choosing (weighted by some metrics such as
>> idle cpu), retrieve the intermediate sets and run reduce if supplied.
>>
>>
>> 2009/2/25 Alberto G. Corona :
>> > Galchin,
>> >
>> > Maybe you are asking not only about remote execution, but also mobility
>> of
>> > code. This is a problem that is previous to mapReduce, since mapReduce
>> > assumes that all the code (and the data) is in place in the respective
>> > nodes. In fact, the distribution of resources in order to efficiently
>> use
>> > mapReduce is a design problem that the google people has done by hand.
>> > But  my intuition says that there are a general algorithm  for
>> distribution
>> > of  code, data, bandwidth and resources in general that  moves around at
>> > execution time to achieve better and better performance for a given grid
>> of
>> > nodes and for any task, for example, a mapReduce task. I would be very
>> > interesting to read something about this.
>> > I know that some efforts have been carried out the past , for example
>> mobile
>> > haskell
>> >
>> http://homepages.inf.ed.ac.uk/stg/workshops/TFP/book/DuBois/duboismhaskell/cameraready.pdf
>> > which is a first step for this goal but I this has been discontinued and
>> the
>> > source code is not available.
>> >
>> > 2009/2/25 Galchin, Vasili 
>> >>
>> >> Hello,
>> >>
>> >>  Here is an interesting paper of Google's MapReduce reverse
>> engineered
>> >> into Haskell. I apologize if already posted .
>> >> http://www.cs.vu.nl/~ralf/MapReduce/
>> >>
>> >> Kind regards, Vasili
>> >>
>> >> ___
>> >> 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
>> >
>> >
>>
>>
>>
>> --
>> We can't solve problems by using the same kind of thinking we used
>> when we created them.
>>- A. Einstein
>>
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] cabal install profiling and documentation

[Ben]

i've gone and cabal installed a lot of packages, but now i want to go
back and install their profiling libraries and documentation.  is
there an easy way of doing this, short of reinstalling all of them (in
the proper dependency order)?

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

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

[Gwern Branwen]

On Wed, Feb 25, 2009 at 12:15 PM, Neil Mitchell  wrote:
> Hi,
>
> I want to read a file using Data.Binary, and I want to read the file
> strictly - i.e. when I leave the read file I want to guarantee the
> handle is closed. The reason is that (possibly immediately after) I
> need to write to the file. The following is the magic I need to use -
> is it all necessary, is it guaranteed correct, should I use something
> else?
>
>        src <- decodeFile "_make/_make"
>        Map.size mp `seq` performGC
>
> Thanks for all the helpful replies to the last post, I think I've
> nearly come up with a minimal test case I can give you, or at least
> characterise where the issue might lie. But I'll post to that thread
> when I've got the details.
>
> Thanks
>
> Neil

Funnily enough, I was just grappling with this issue in Yi. My
solution was to make the read strict, so my function looked like this:

readDB ∷  YiM ArticleDB
readDB = io $ (dbLocation >>= r) `catch` (λ_ →  return empty)
where r x = fmap (decode · BL.fromChunks · return) $ B.readFile x

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

Re: [Haskell-cafe] subscription problems for projects.haskell.org mailing list

[Wolfgang Jeltsch]

Am Mittwoch, 25. Februar 2009 17:15 schrieb Wolfgang Jeltsch:
> Am Mittwoch, 25. Februar 2009 17:05 schrieb Wolfgang Jeltsch:
> > Hello,
> >
> > I created a mailing list for Grapefruit on the Haskell Community Server
> > (). If I try to subscribe to it, I
> > receive a confirmation e-mail but my answers to this e-mail seem to get
> > ignored. Does anyone have an idea what’s wrong here?
>
> Confirmation via the weblink inside the confirmation e-mail works, by the
> way.

Meanwhile, I received automatic answers to my two unsuccesful confirmation 
e-mails. They both claim that the confirmation string is invalid. However, 
the confirmation string worked when confirming via the website.

The only problem I can imagine at the moment is that the URLs with the 
confirmation string were broken into two lines in my confirmation e-mails. 
However, Mailman should take the string from the subject line, shouldn’t it?

The error notifications told me that for each of my confirmation e-mails, the 
last paragraph was “ignored” while everything before it was “unprocessed”. 
What does that mean?

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

RE: [Haskell-cafe] Memoization local to a function

[Sittampalam, Ganesh]

Dusan Kolar wrote:
> Nevertheless, local version does not
> work.  

Restructure your code like this:

> fibL m =
>   let
> allfib = 0:1:[allfib!!n + allfib!!(n+1) | n <- [0..]]
>   in allfib !! m

fibL = let allfib = 0:1:[allfib!!n + allfib!!(n+1) | n <- [0..]]
 in \m -> allfib !! m

i.e. move the definition of the memo table outside the scope of
the specific parameter you want to memoise over.

Cheers,

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] Memoization local to a function

[Dusan Kolar]

Dear all,

 I have a function a computation of which is quite expensive, it is 
recursively dependent on itself with respect to some other function 
values - we can roughly model its behaviour with fib function (returns 
n-th number of Fibonacci's sequence). Unfortunately, it is not fib, it 
is far more complicated. Nevertheless, for demonstration of my 
question/problem I will use fib, it's quite good.


 I want to store results in a list (array, with its strong size limit 
that I do not know prior to computation, is not suitable) and then pick 
them up using (!!) operator. Well, if the list is "global" 
function/constant then it works quite well. Unfortunately, this is not, 
what I would like to have. Nevertheless, local version does not work.


 Could someone point me to some text that explains it? Memoization text 
on wiki does not seem to be helpful. Time/operation consumption is 
deduced from number of reductions reported by hugs and winhugs (tested 
both on Linux and Windows).


 Thank you for hints,

  Dusan


P.S.
Code I used for testing.

module Testmemo
   (  fibW
   ,  fibL
   ,  fibM
   )  where


fibW m = allfib !! m
 where
   allfib = 0:1:[allfib!!n + allfib!!(n+1) | n <- [0..]]


fibL m =
 let
   allfib = 0:1:[allfib!!n + allfib!!(n+1) | n <- [0..]]
 in allfib !! m


fibM n = myallfib !! n
myallfib = 0:1:[myallfib!!n + myallfib!!(n+1) | n <- [0..]]

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

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

[Felipe Lessa]

On Wed, Feb 25, 2009 at 2:15 PM, Neil Mitchell  wrote:
>        src <- decodeFile "_make/_make"
>        Map.size mp `seq` performGC

Shouldn't you use rnf[1]? Also, there seems to be binary-strict on
Hackage, but I don't know if it is being maintained anymore.

HTH,

[1] 
http://www.haskell.org/ghc/docs/latest/html/libraries/parallel/Control-Parallel-Strategies.html#v%3Arnf

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

[Haskell-cafe] Re: package code duplication

[Don Stewart]

wasserman.louis:
> There was a question recently about being allowed to get into package
> internals, and I had a question.  I want to use uvector's stream internals in
> ways that the exposed methods don't permit, but I don't especially want to use
> another package (e.g. vector, which does expose its internals) or reimplement
> my own stream fusion.  Would it make sense to duplicate uvector's internals,
> copying licensing information and other stuff of course, inside my package? 
> It's a suboptimal solution, but it seems better than the alternative...

I think just exposing them as a .Internal makes more sense, and
is my preferred route (a la Data.ByteString.Internal)

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

[Haskell-cafe] package code duplication

[Louis Wasserman]

There was a question recently about being allowed to get into package
internals, and I had a question.  I want to use uvector's stream internals
in ways that the exposed methods don't permit, but I don't especially want
to use another package (e.g. vector, which does expose its internals) or
reimplement my own stream fusion.  Would it make sense to duplicate
uvector's internals, copying licensing information and other stuff of
course, inside my package?  It's a suboptimal solution, but it seems better
than the alternative...

><

Louis Wasserman
wasserman.lo...@gmail.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Data.Binary, strict reading

[Neil Mitchell]

Hi,

I want to read a file using Data.Binary, and I want to read the file
strictly - i.e. when I leave the read file I want to guarantee the
handle is closed. The reason is that (possibly immediately after) I
need to write to the file. The following is the magic I need to use -
is it all necessary, is it guaranteed correct, should I use something
else?

src <- decodeFile "_make/_make"
Map.size mp `seq` performGC

Thanks for all the helpful replies to the last post, I think I've
nearly come up with a minimal test case I can give you, or at least
characterise where the issue might lie. But I'll post to that thread
when I've got the details.

Thanks

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

Re: [Haskell-cafe] MapReduce reverse engineered

[Rick R]

I agree. A distributed database could be made as usable as a standard
RDBMS by offering an interface by which you supply a map/reduce pair
of functions and a list (range?) of keys.

This could be easily implemented with a database such as Scalaris, in
which the Chord algorithm is responsible for placing and finding the
data among nodes.

The user would interface with any node in the distributed database,
supplying a map and reduce function. It would distribute the map
function to nodes of its choosing (weighted by some metrics such as
idle cpu), retrieve the intermediate sets and run reduce if supplied.


2009/2/25 Alberto G. Corona :
> Galchin,
>
> Maybe you are asking not only about remote execution, but also mobility of
> code. This is a problem that is previous to mapReduce, since mapReduce
> assumes that all the code (and the data) is in place in the respective
> nodes. In fact, the distribution of resources in order to efficiently use
> mapReduce is a design problem that the google people has done by hand.
> But  my intuition says that there are a general algorithm  for distribution
> of  code, data, bandwidth and resources in general that  moves around at
> execution time to achieve better and better performance for a given grid of
> nodes and for any task, for example, a mapReduce task. I would be very
> interesting to read something about this.
> I know that some efforts have been carried out the past , for example mobile
> haskell
> http://homepages.inf.ed.ac.uk/stg/workshops/TFP/book/DuBois/duboismhaskell/cameraready.pdf
> which is a first step for this goal but I this has been discontinued and the
> source code is not available.
>
> 2009/2/25 Galchin, Vasili 
>>
>> Hello,
>>
>>  Here is an interesting paper of Google's MapReduce reverse engineered
>> into Haskell. I apologize if already posted .
>> http://www.cs.vu.nl/~ralf/MapReduce/
>>
>> Kind regards, Vasili
>>
>> ___
>> 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
>
>



-- 
We can't solve problems by using the same kind of thinking we used
when we created them.
- A. Einstein
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

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

[Robert Greayer]

Colin Paul Adams wrote:
> But IF there is no difference between LGPL and GPL for Haskell
> programs, then the licensing of gtk2hs as LGPL is just a smokescreen -
> it is effectively GPL, so you have to license your program as GPL.

> Which I'm all in favour of :-)

I actually don't think this is 100% true.  With the LGPL, you can distribute 
your program with under a non-GPL license, as long as you provide *some 
mechanism* for replacing the library and recreating the program.  Normally this 
means dynamic linking.  But it also allows you (I think) to distribute your 
program with a GPL-incompatible-but-nevertheless-open-source license, because 
that provides a mechanism for replacing the library (because you can rebuild 
the program from source).  If you license the library under GPL, you cannot 
even do that.  At least this is my understanding...


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

Re: [Haskell-cafe] Re: Hoogle and Network.Socket

[Brandon S. Allbery KF8NH]

On 2009 Feb 25, at 5:23, John Lato wrote:

Brandon Allbery wrote:

I have to second this; I'm a Unix sysadmin, 98% of the time if I'm
writing a program it's for Unix *and* requires POSIX APIxs, and even
if it could apply to Windows the program needed there would be very
significantly different.  And we have a Windows group for that.


2.  As of now, the "Windows Group" seems to be mostly Duncan.  And


Wrong Windows group:  Duncan doesn't work for us.

--
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




PGP.sig
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] MapReduce reverse engineered

[Alberto G. Corona]

Galchin,

Maybe you are asking not only about remote execution, but also mobility of
code. This is a problem that is previous to mapReduce, since mapReduce
assumes that all the code (and the data) is in place in the respective
nodes. In fact, the distribution of resources in order to efficiently use
mapReduce is a design problem that the google people has done by hand.
But  my intuition says that there are a general algorithm  for distribution
of  code, data, bandwidth and resources in general that  moves around at
execution time to achieve better and better performance for a given grid of
nodes and for any task, for example, a mapReduce task. I would be very
interesting to read something about this.

I know that some efforts have been carried out the past , for example mobile
haskell 


http://homepages.inf.ed.ac.uk/stg/workshops/TFP/book/DuBois/duboismhaskell/cameraready.pdf


which is a first step for this goal but I this has been discontinued and the
source code is not available.

2009/2/25 Galchin, Vasili 
>
> Hello,
>
>  Here is an interesting paper of Google's MapReduce reverse engineered
into Haskell. I apologize if already posted .
http://www.cs.vu.nl/~ralf/MapReduce/
>
> Kind regards, Vasili
>
> ___
> 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] Re: Hoogle and Network.Socket

[Sittampalam, Ganesh]

Jonathan Cast wrote:
> On Wed, 2009-02-25 at 10:23 +, John Lato wrote:
>> 4.  Cross-platform concerns are something that responsible developers
>> need to consider, just like localization and i18n.  I.e., why
>> *shouldn't* you think of that?
> 
> Sorry, wtf?  I have a *responsibility* to design software for a
> miserably poorly-designed God-awful platform I'd have to pay *extra*
> for, and even then couldn't get source to or *fix* if I found a bug?

I think there's a distinction between actively trying to support a
specific platform, and simply trying to work in a cross-platform way,
i.e. using the appropriate cross-platform APIs and packages where
possible. Other people will already have done the work of making those
things work on a specific platform, and if they don't work the issue can
be raised with those people rather than you.

> No.  You don't control me, to the best of my knowledge you haven't
> done squat for me, and by trying to force me to develop to *that*
> platform you are actively attempting to harm me.
> 
> *plonk*

Please could you moderate your tone? The original post wasn't aimed at
you personally, it just expressed a general opinion about development
practices, and certainly made no mention of forcing you or anyone else
to do anything. By making it personal and expressing your response in
rather intemperate language, you are adding more heat than light.

In addition, the original subject of this thread is Hoogle, and if we
take your comments in that context (and I do realise that your comments
may have been generic rather than specific to Hoogle), then you have the
choice of not using it at all, in which case you are not affected at all
by its design choices; but if you do use it then the author certainly
has 
done something for you, and his feeling that people should be encouraged

to use cross-platform APIs where possible should certainly be accorded 
some respect.

Cheers,

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

Re: [Haskell-cafe] MapReduce reverse engineered

[Galchin, Vasili]

The author(s) are from Microsoft .. they claimed to reverse engineer
internals. My understanding is that MapReduce internals **is** a Google
closely held secret ... hence the open source version is "dumbed down" .. I
have forgotten the name.

Vasili

On Wed, Feb 25, 2009 at 8:49 AM, Eugene Kirpichov wrote:

> I've read this article too, and I must say that it is indeed a very
> interesting and exciting read, both in terms of understanding
> MapReduce and its capabilities somewhat better, and in terms of
> beholding the beauty of Haskell.
>
> It is not exactly reverse engineering, but it is expressing the
> essense of MapReduce algorithms, prerequisites, axioms, dimensions of
> its design space etc. in Haskell.
>
> 2009/2/25 Thomas DuBuisson :
> > Vasili,
> > What do you mean?  Googles MapReduce is already a published / well
> > understood concept so no reverse engineering is needed.  If you are
> > asking about pre-existing implementations, there is at least one [1]
> > but only for reference, not speed.  If you are asking about community
> > interest, great and you might want to say something on the haskell
> > proposals reddit [2].
> >
> > [1] 
> > http://www.cs.vu.nl/~ralf/MapReduce/
> > [2] http://www.reddit.com/r/haskell_proposals
> >
> > 2009/2/24 Galchin, Vasili :
> >> Hello,
> >>
> >>  Here is an interesting paper of Google's MapReduce reverse
> engineered
> >> into Haskell. I apologize if already posted .
> >> http://www.cs.vu.nl/~ralf/MapReduce/
> >>
> >> Kind regards, Vasili
> >>
> >> ___
> >> 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
> >
>
>
>
> --
> 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: [Haskell-cafe] subscription problems for projects.haskell.org mailing list

[Wolfgang Jeltsch]

Am Mittwoch, 25. Februar 2009 17:05 schrieb Wolfgang Jeltsch:
> Hello,
>
> I created a mailing list for Grapefruit on the Haskell Community Server
> (). If I try to subscribe to it, I receive
> a confirmation e-mail but my answers to this e-mail seem to get ignored.
> Does anyone have an idea what’s wrong here?

Confirmation via the weblink inside the confirmation e-mail works, by the way.

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

[Haskell-cafe] subscription problems for projects.haskell.org mailing list

[Wolfgang Jeltsch]

Hello,

I created a mailing list for Grapefruit on the Haskell Community Server 
(). If I try to subscribe to it, I receive a 
confirmation e-mail but my answers to this e-mail seem to get ignored. Does 
anyone have an idea what’s wrong here?

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

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

[Colin Paul Adams]

> "Wolfgang" == Wolfgang Jeltsch  writes:

Wolfgang> Am Mittwoch, 25. Februar 2009 14:33 schrieb Duncan
Wolfgang> Coutts:
>> Note that some people will tell you that by a strict
>> interpretation of the LGPL that statically linked Haskell libs
>> under that license are a pain in the backside. When we decided
>> on that license for gtk2hs that was not our intention. In other
>> words nobody is going to sue you if you statically link gtk2hs
>> libs. Of course if you need a cast iron legal guarantee then
>> that's not good enough and you'd have to ship .a and .o files
>> to let users relink if they wanted to.

Wolfgang> I’m not sure whether this would be enough. .a and .o
Wolfgang> files are not compatible among GHC versions, as far as I
Wolfgang> know. Relinking against newer Gtk2Hs versions might not
Wolfgang> work. And a program using Gtk2Hs contains code from the
Wolfgang> .hi files of Gtk2Hs through inlining. So it’s not pure
Wolfgang> linking. However, the LGPL only allows linking, as far
Wolfgang> as I understand.

Wolfgang> I want to repeat what I’ve said earlier on this list:
Wolfgang> For Haskell, there is no real difference between LGPL
Wolfgang> and GPL, as far as I understand it. If you don’t want to
Wolfgang> force the users of your library to use an open source
Wolfgang> license for their work then use BSD3 or a similar
Wolfgang> license for your library.

But IF there is no difference between LGPL and GPL for Haskell
programs, then the licensing of gtk2hs as LGPL is just a smokescreen -
it is effectively GPL, so you have to license your program as GPL.

Which I'm all in favour of :-)
-- 
Colin Adams
Preston Lancashire
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Hoogle and Network.Socket

[Jonathan Cast]

On Wed, 2009-02-25 at 10:23 +, John Lato wrote:
> 4.  Cross-platform concerns are something that responsible developers
> need to consider, just like localization and i18n.  I.e., why
> *shouldn't* you think of that?

Sorry, wtf?  I have a *responsibility* to design software for a
miserably poorly-designed God-awful platform I'd have to pay *extra*
for, and even then couldn't get source to or *fix* if I found a bug?
No.  You don't control me, to the best of my knowledge you haven't done
squat for me, and by trying to force me to develop to *that* platform
you are actively attempting to harm me.

*plonk*

jcc


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

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

[Wolfgang Jeltsch]

Am Mittwoch, 25. Februar 2009 14:33 schrieb Duncan Coutts:
> Note that some people will tell you that by a strict interpretation of
> the LGPL that statically linked Haskell libs under that license are a
> pain in the backside. When we decided on that license for gtk2hs that
> was not our intention. In other words nobody is going to sue you if you
> statically link gtk2hs libs. Of course if you need a cast iron legal
> guarantee then that's not good enough and you'd have to ship .a and .o
> files to let users relink if they wanted to.

I’m not sure whether this would be enough. .a and .o files are not compatible 
among GHC versions, as far as I know. Relinking against newer Gtk2Hs versions 
might not work. And a program using Gtk2Hs contains code from the .hi files 
of Gtk2Hs through inlining. So it’s not pure linking. However, the LGPL only 
allows linking, as far as I understand.

I want to repeat what I’ve said earlier on this list: For Haskell, there is no 
real difference between LGPL and GPL, as far as I understand it. If you don’t 
want to force the users of your library to use an open source license for 
their work then use BSD3 or a similar license for your library.

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

Re: [Haskell-cafe] MapReduce reverse engineered

[Eugene Kirpichov]

I've read this article too, and I must say that it is indeed a very
interesting and exciting read, both in terms of understanding
MapReduce and its capabilities somewhat better, and in terms of
beholding the beauty of Haskell.

It is not exactly reverse engineering, but it is expressing the
essense of MapReduce algorithms, prerequisites, axioms, dimensions of
its design space etc. in Haskell.

2009/2/25 Thomas DuBuisson :
> Vasili,
> What do you mean?  Googles MapReduce is already a published / well
> understood concept so no reverse engineering is needed.  If you are
> asking about pre-existing implementations, there is at least one [1]
> but only for reference, not speed.  If you are asking about community
> interest, great and you might want to say something on the haskell
> proposals reddit [2].
>
> [1] http://www.cs.vu.nl/~ralf/MapReduce/
> [2] http://www.reddit.com/r/haskell_proposals
>
> 2009/2/24 Galchin, Vasili :
>> Hello,
>>
>>  Here is an interesting paper of Google's MapReduce reverse engineered
>> into Haskell. I apologize if already posted .
>> http://www.cs.vu.nl/~ralf/MapReduce/
>>
>> Kind regards, Vasili
>>
>> ___
>> 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
>



-- 
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: [Haskell-cafe] MapReduce reverse engineered

[Thomas DuBuisson]

Vasili,
What do you mean?  Googles MapReduce is already a published / well
understood concept so no reverse engineering is needed.  If you are
asking about pre-existing implementations, there is at least one [1]
but only for reference, not speed.  If you are asking about community
interest, great and you might want to say something on the haskell
proposals reddit [2].

[1] http://www.cs.vu.nl/~ralf/MapReduce/
[2] http://www.reddit.com/r/haskell_proposals

2009/2/24 Galchin, Vasili :
> Hello,
>
>  Here is an interesting paper of Google's MapReduce reverse engineered
> into Haskell. I apologize if already posted .
> http://www.cs.vu.nl/~ralf/MapReduce/
>
> Kind regards, Vasili
>
> ___
> 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] base-4 + gtk2hs-0.10.0 licensing

[Duncan Coutts]

On Wed, 2009-02-25 at 14:22 +0300, Victor Nazarov wrote:
> I wonder what software licence I can use to release my application.
> I've developed some education tool with the following dependencies:
> 
> % ghci Main.hs
> GHCi, version 6.10.1: http://www.haskell.org/ghc/  :? for help
> Loading package ghc-prim ... linking ... done.
> Loading package integer ... linking ... done.
> Loading package base ... linking ... done.
> Ok, modules loaded: Main, UI, Lambda, Lambda.Eval, Lambda.Zipper,
> Lambda.Show, Lambda.Parser, Lambda.Common.
> Prelude Main> main
> Loading package syb ... linking ... done.
> Loading package array-0.2.0.0 ... linking ... done.
> Loading package containers-0.2.0.0 ... linking ... done.
> Loading package bytestring-0.9.1.4 ... linking ... done.
> Loading package Win32-2.2.0.0 ... linking ... done.
> Loading package parsec-2.1.0.1 ... linking ... done.
> Loading package mtl-1.1.0.2 ... linking ... done.
> Loading package old-locale-1.0.0.1 ... linking ... done.
> Loading package time-1.1.2.2 ... linking ... done.
> Loading package glib-0.10.0 ... linking ... done.
> Loading package cairo-0.10.0 ... linking ... done.
> Loading package gtk-0.10.0 ... linking ... done.
> Loading package glade-0.10.0 ... linking ... done.
> 
> I just don't know the options and I think licensing is subtle enough
> to ask for suggestions.

Note that glib, gtk, cairo and glade are LGPL-2 (both the C libs and the
Haskell libs). So that does not affect your license much. Read the LGPL
version 2 for the details.

Note that some people will tell you that by a strict interpretation of
the LGPL that statically linked Haskell libs under that license are a
pain in the backside. When we decided on that license for gtk2hs that
was not our intention. In other words nobody is going to sue you if you
statically link gtk2hs libs. Of course if you need a cast iron legal
guarantee then that's not good enough and you'd have to ship .a and .o
files to let users relink if they wanted to.

Duncan

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

[Haskell-cafe] Re: forall & ST monad

[Heinrich Apfelmus]

Ryan Ingram wrote:
> 
> It believe that it's true that ((forall a. t a) -> t') does not entail
> (exists a. t a -> t') in constructivist logic, but I can't come up
> with a proof off the top of my head.  Intuitively, to construct a
> value of type (E t t') you need to fix an "a", and I don't think it's
> possible to do so.

Here's something close to a counterexample, but I'm really confused.


The objects of discourse are red, blue and green glass marbles

   T[a] = a is red \/ a is blue
   S= forall a. T[a] = all marbles are red or blue

Now,

   (forall a. T[a]) -> S

is clearly true while

   exists a. (T[a] -> S)

should be nonsense: having one example of a marble that is either red or
blue does in no way imply that all of them are, at least constructively.
 (It is true classically, but I forgot the name of the corresponding
theorem.)

I'm not quite sure how to make that rigorous; I would like to turn the
above into a proper model of intuitionistic logic.


The other problem is that in Haskell,  forall  does not quantify over
glass marbles, but over types/propositions. Take

   T[a] = a
   S= forall a. T[a] = _|_

Once again,

   (forall a. T[a]) -> S

is true, but what about

   exists a. (a -> _|_) = exists a. not a   ?

I mean,  a  can be a proposition now, so what about taking

   a = forall b.b = _|_   ?

Does  exists a  imply that the example proposition constructed should
true or is it enough to be able to construct a proposition at all?



Regards,
apfelmus

--
http://apfelmus.nfshost.com

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

Re: [Haskell-cafe] Cabal: local documentation

[Martijn van Steenbergen]

Duncan Coutts wrote:

On Tue, 2009-02-24 at 17:42 +0100, Svein Ove Aas wrote:

2009/2/24 Felipe Lessa :

Just pass '--enable-documentation' to 'cabal install'. On *nix they're
generated at ~/.cabal/share/doc.


Or edit ~/.cabal/config and set the documentation key to True


However this does not maintain a complete module index like I think
Martijn is after.


Thank you all for the very helpful suggestions. I edited ~/.cabal/config 
to generate documentation by default, and I set up Apache to serve the 
documentation from http://haddock. I put a small PHP (gasp!) file in 
~/.cabal/share/doc that lists all packages for which there is 
documentation; see below. This is a good enough approximation for now. 
Thanks again!


Martijn.

---



Local Hackage packages


Local Hackage packages

' . $pkg . '' . "\n";
  }
}

?>




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

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

[Victor Nazarov]

I wonder what software licence I can use to release my application.
I've developed some education tool with the following dependencies:

% ghci Main.hs
GHCi, version 6.10.1: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Ok, modules loaded: Main, UI, Lambda, Lambda.Eval, Lambda.Zipper,
Lambda.Show, Lambda.Parser, Lambda.Common.
Prelude Main> main
Loading package syb ... linking ... done.
Loading package array-0.2.0.0 ... linking ... done.
Loading package containers-0.2.0.0 ... linking ... done.
Loading package bytestring-0.9.1.4 ... linking ... done.
Loading package Win32-2.2.0.0 ... linking ... done.
Loading package parsec-2.1.0.1 ... linking ... done.
Loading package mtl-1.1.0.2 ... linking ... done.
Loading package old-locale-1.0.0.1 ... linking ... done.
Loading package time-1.1.2.2 ... linking ... done.
Loading package glib-0.10.0 ... linking ... done.
Loading package cairo-0.10.0 ... linking ... done.
Loading package gtk-0.10.0 ... linking ... done.
Loading package glade-0.10.0 ... linking ... done.

I just don't know the options and I think licensing is subtle enough
to ask for suggestions.

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

[Haskell-cafe] Re: Hoogle and Network.Socket

[John Lato]

Brandon Allbery wrote:
> On 2009 Feb 21, at 20:47, Jonathan Cast wrote:
>> On Sat, 2009-02-21 at 07:25 -0700, John A. De Goes wrote:
>>> Not showing platform-specific packages by default *might* make
>>> package
>>> writers more likely to develop cross-platform packages. We've heard
>>> many times someone say, "I don't know if it works on Windows, never
>>> really thought of that."
>>
>> Um, why *should* I think of that?
>
> I have to second this; I'm a Unix sysadmin, 98% of the time if I'm
> writing a program it's for Unix *and* requires POSIX APIxs, and even
> if it could apply to Windows the program needed there would be very
> significantly different.  And we have a Windows group for that.
>

I completely disagree, for the following reasons:
1.  It's often easier (and almost never more difficult) to design for
cross-platform support from the beginning than to add it later.
2.  As of now, the "Windows Group" seems to be mostly Duncan.  And
while I greatly appreciate all the time and effort he continues to put
into Windows support, he's got a lot to do and could use some help.
If you can't help by joining the Windows group, at least you could
make your own packages cross-platform.
3.  It contributes to the "Avoid success at all costs" mantra often
attributed to Haskell.  I'm pretty sure that some people prefer this,
but many (including myself) consider it at best misguided, and
possibly harmful.
4.  Cross-platform concerns are something that responsible developers
need to consider, just like localization and i18n.  I.e., why
*shouldn't* you think of that?

In some situations, it is true that a project is particularly tied to
a Posix (or Windows) feature, and it wouldn't make sense to attempt a
cross-platform version.  If you're a Unix sysadmin and you use
Haskell, that may be true most or all of the time.  But for many
packages, including most packages on hackage, it should be given
consideration.

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

Re: [Haskell-cafe] MapReduce reverse engineered

[Daryoush Mehrtash]

Any idea how one might implement a multi note map and reduce network?  Lets
assume I have network of nodes that act as master and salve.  How can I take
a user code  (containing his map reduce logic) and actually run it on
different nodes?

Daryoush

2009/2/24 Galchin, Vasili 

> Hello,
>
>  Here is an interesting paper of Google's MapReduce reverse engineered
> into Haskell. I apologize if already posted .
> http://www.cs.vu.nl/~ralf/MapReduce/
>
> Kind regards, Vasili
>
> ___
> 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