Re: [Haskell-cafe] timing question

[Arie Groeneveld]

Thanks for all the advises so far.

Ok, here's my monster that need to be timed in order to make a comparison:
(it's about the control digit of SEDOL numbers  
http://en.wikipedia.org/wiki/SEDOL ):



knip _ [] = Nothing
knip k xs = Just (splitAt k xs)

ip xs = sum . zipWith (*) xs

an =  ['0'..'9']++['A'..'Z']

s = take 841 $ cycle "0987654321"
f = \xs -> xs ++ [(sna!!).ip [1,3,1,7,3,9]. map (flip (fromJust .) an . 
findIndex . (==))$xs]




Here's my try for timing:

*Main> (foldl1 (\x y -> f y) .concat.replicate 100 $ unfoldr (knip 
6) an)

"UVWXYZ7"
(1.31 secs, 330291000 bytes)

(It's incl. the construction of the test list, as is in the language to 
compare )


I need the whole list to be evaluated.
Interpreted mode IS A MUST :-)

BTW I increased stack size


thanks


Don Stewart schreef:

bradypus:
  

Suppose I've:

f = map g

I want to know how much time it takes (interpreted mode) to fully 
process list xs (at least 1e6 elements) with function g. Is it 
sufficient to execute:


*Main> last . f $ xs

(x.xx secs, yyy bytes)

Are there any hidden difficulties involved?

Reason is: comparing timings Haskell vs an interpreted language without 
laziness.





If you care about timings, it's probably a better idea to compile the
code (with optimisations on), to get a better idea of what the code
would do in a production environment.

You could then just time the binary,

main = print . sum $ 

ghc -O2 A.hs --make
time ./A

-- Don


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

Re: [Haskell-cafe] poll: how can we help you contribute to darcs?

[Ketil Malde]

Ketil Malde <[EMAIL PROTECTED]> writes:

> Duncan Coutts <[EMAIL PROTECTED]> writes:

>> It would be useful if some darcs 2 hackers, contributors could help the
>> ghc people evaluate if darcs 2 is still in the running. 

> This looks like a very easy and low-investement way to get involved.

...and now I feel I've done my part :-)

Anyway: I took the 'biolib' repo with 2005 patches, and made three
copies, here's the timing results:

   darcs get ../biolib biolib-1  0.20s user 0.16s system 100% cpu 0.360 total
   darcs get --hashed ../biolib biolib-h  0.64s user 0.17s system 98% cpu 0.813 
total
   darcs convert ../biolib biolib-2  0.62s user 0.18s system 7% cpu 11.101 total

(The 11 seconds in the last one is me typing in "I understand the
consequences of my action".  The warnings are almost scary enough for
me to worry about the state of my source repo, but I trust it is safe
to do this and discard the new repos afterwards..)

The 'convert' printed something looking like a patch:

merger 0.0 (
hunk ./Bio/Alignment/AlignData.hs 5
-module Bio.EditList.AlignData ( $
+module Bio.Alignment.AlignData ( $
hunk ./Bio/Alignment/AlignData.hs 3
-{-# OPTIONS -fglasgow-exts #-}
-
-module Bio.EditList.AlignData ( $
+module Bio.EditList.AlignData (
)

and I'm not quite sure what this is about?

Anyway, I then proceeded to run various queries (what, changes, diff),
but apparently, this repo is way too small to actually show anything
useful, it all completes in about 0.05-0.2 seconds.  

The consequences of moving to the darcs-2 format are a bit unclear to
me. For instance, I'd like to keep my main (export) repo in darcs-1
format, in order to make it as accessible as possible (Ubuntu still
ships with darcs-1.0.9, and that's a fairly cutting edge
distribution.)  Can I convert my working repos to darcs-2?  Should I?
How about darcs-hashed?  In short, I'd like to see examples of
recommended migration strategies, and associated benefits.

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] code review? store server, 220loc.

[Brandon S. Allbery KF8NH]

On 2008 Aug 4, at 23:45, Tim Newsham wrote:


Anyway, I haven't yet used any ByteString IO functions.  I ran
some tests when I was starting and it seems that using Handle IO
functions was a bit slower than using the Socket IO functions  
directly.

It looks like there are a bunch of Handle IO functions that can
return ByteStrings but I don't see any for sockets...  Are there any?


There's something on hackage...
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/network-bytestring

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


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

Re: [Haskell-cafe] code review? store server, 220loc.

[Tim Newsham]

You should try profiling this. I can see a few possible problems (such
as reading String from a socket, instead of a ByteString), but it's
difficult to predict what might be causing your code to be so slow.
Haskell code ought to be much more competitive with C for an
application like this.


I haven't tried profiling yet, I should do that (ugh, will prob
have to rebuild some libraries I'm using to support that).

Anyway, I haven't yet used any ByteString IO functions.  I ran
some tests when I was starting and it seems that using Handle IO
functions was a bit slower than using the Socket IO functions directly.
It looks like there are a bunch of Handle IO functions that can
return ByteStrings but I don't see any for sockets...  Are there any?
If not, I suspect it will be a wash switching to Handles and ByteStrings
(especially since most of my requests and responses are quite small).

I'll write up some tests to see how well those perform..

Tim Newsham
http://www.thenewsh.com/~newsham/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] code review? store server, 220loc.

[Bryan O'Sullivan]

On Sat, Aug 2, 2008 at 10:13 PM, Tim Newsham <[EMAIL PROTECTED]> wrote:
> Anyone interested in critiquing some code?  I'm looking for ideas
> for making it faster and/or simpler:
>
>   http://www.thenewsh.com/%7Enewsham/store/Server5.hs

The code looks fairly reasonable, although most of your strictness
annotations are unlikely to do much (particularly those on String
fields).

You should try profiling this. I can see a few possible problems (such
as reading String from a socket, instead of a ByteString), but it's
difficult to predict what might be causing your code to be so slow.
Haskell code ought to be much more competitive with C for an
application like this.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Capitalization and associated type families

[Jonathan Cast]

On Mon, 2008-08-04 at 23:04 +0100, Brian Hulley wrote:
> Jonathan Cast wrote:
> > On Mon, 2008-08-04 at 19:51 +0100, Brian Hulley wrote:
> >> For example, why is there any distinction between a type "variable" and 
> >> a type "constant"?
> >>
> >>forall a b. (a -> b) -> List a -> List b
> >>
> >> Now this begs the question: why does "List" need to start with a 
> >> capital? (supposing that quantifiers were always written explicitly)
> > 
> > AFAIK, it doesn't; the variable/constant distinction is just there to
> > let the implementation put the foralls in for you.
> 
> Hi Jonathan - thanks - this confirms what I've been thinking. However 
> consider:
> 
>   class Foo a where
> 
>   f :: a -> b -> (a, b)
> 
> Here there is no capitalization distinction in the type of (f) but the 
> implementation can still insert the "forall b." since (a) is already in 
> scope. Therefore similarly, if type constructors like "List" were 
> instead written using lowercase, since they would already be in scope it 
> would be clear even without explicit quantifiers that (a) and (b), but 
> not (list), were to be quantified in the type of (map) (assuming of 
> course that there was no top level data decl for (a) or (b)).

Sure.  ML does it this way, in fact.  Not for type variables, but for
regular pattern variables.  So, IIRC, in ML the empty list is written
nil.  But (playing Devil's advocate) if you have a function declaration

f niil = ...

That's a variable pattern...

The Miranda capitalization rule (which Haskell adopted) is designed to
find such typos automatically, since now you have to write

f Niil

and Niil can't be a variable.

The fact that type signatures in Haskell type classes are subject to the
same problem is certainly a weakness of the design.  I think if new type
variables (universally quantified locally) had a different syntax, so
you said

f :: a -> 'b -> (a, 'b)

where a by itself meant a had better already be in scope, that would be
more consistent.  Then you could drop the capitalization convention
entirely.

> >  Similarly, if we had
> > explicit foralls on equations, we could say
> > 
> > forall n x xn. drop (n+1) (x:xn) = drop n xn
> > 
> > but
> > 
> > forall n. drop n nil = nil
> > 
> > and it would be perfectly clear that `nil' in the latter case was a
> > constructor.
> 
> Actually I quite like the above because it shows that pattern matching 
> can be understood in terms of universally quantified predicates.
> 
> Regarding the verbosity, patterns are something of a special case since 
> variables (that are introduced in the pattern) can only occur once and 
> there is no need to have higher rank quantification in value patterns 
> (disregarding explicit tests for _|_). Therefore special syntax could be 
> used to make the above shorter e.g. borrowing the '?' from Felix 
> (http://felix.sourceforge.net/doc/tutorial/introduction/en_flx_tutorial_top.html
>  
>   (section 2.11/2.17 etc)):
> 
>   drop (?n + 1) (_ : ?xn) = drop n xn
>   drop ?n nil = nil
> 
> (where glued prefix binds tighter than application).

I think this goes with ML's type variable syntax ('a), actually.

> > Of course, if you want to introduce this rule, you'd better start out
> > with it and be consistent --- require every variable to be explicitly
> > brought into scope.  I think you'd find it pretty annoying after trying
> > to program in your new language for a while, though.
> > 
> 
> I agree that there are many good points in favour of Haskell's use of a 
> case distinction, not the least being that it gives definite guidance on 
> when to use lower or upper case identifiers and therefore avoids the 
> mess you find in C++ programs where every programmer has their own 
> private conventions which can lead to confusion and useless debate.

Another system with this advantage would be to invalidate identifiers
beginning with upper case letters entirely :)  (If you really wanted to
go B&D, disallow underscores as well.  Then every identifier /has/ to be
camel-case.)

> However it still seems to me that the case distinction, at least on the 
> level of type constructors, becomes problematic and possibly 
> inconsistent especially if I consider the effects of trying to 
> incorporate something like the ML module system as well as type classes. 
> (For example the Moby language (http://moby.cs.uchicago.edu/ ), a 
> possible successor to SML, uses capitalization for type constructors 
> similar to Haskell which means that type parameters in functor 
> applications must be uppercase, which conflicts with the use of 
> lowercase type params for classes which are a special kind of functor... 
> (Moby itself doesn't encounter any difficulty since it doesn't have type 
> classes)).

It's weird.  ML-derived languages are functional languages at the value
level (and have regular lambda-bound variables in consequence), but are
logical languages at the type level (and have logical variables in
consequence).  

[Haskell-cafe] Looking for a more functional way to do this

[Jefferson Heard]

Working with HOpenGL and GLUT, I find myself approaching a common
problem with a common solution that I don't really like all that much,
as it reeks of procedural programming.  Basically the problem is that
of complex program state, such that when the user provides input to
the program in the form of a mouse click or a typed string or
character, the program updates its internal state to reflect this,
whether that's changing the rotation, scale, or position of a screen
element, or deciding what data to have loaded from disc.

What I often do is something that looks like this:

data ProgramState  = ProgramState {
some_associative_data :: Map String String
  , position :: GL.Vector3 Float
  , look_at :: GL Vector3 Float
  , selectables :: Map GLuint NamedObject
  }

render :: IORef ProgramState -> IO ()
render state = do
  st <- readIORef state
  ...

handleMouseClicks :: IORef ProgramState -> GLUT.KeyboardMouseHandler
handleMouseClicks state ... = do
  st <- readIORef state
  ...

main = do
  ...
  let st = ProgramState { Map.empty ... }
  render' = render st
  mouse' = handleMouseClicks st

  GLUT.renderCallback $= render
  GLUT.keyboardMouseCallback $= Just mouse'

and so on and so forth.   Generally there are not fewer than 5 and not
more than about 32 variables that I have to track between mouse
clicks, and there's all this boilerplate code as well.  I'm searching
for a better way to do this, and I feel sure there is one.  I'm
considering using Template Haskell or possibly SYB to generate this
code, but it also seems like I also ought to be able to declare some
kind of state monad or continuation monad that can encapsulate
ProgramState without having to declare an explicit structure for it
everytime.

For one thing, I'd like to genericize this code and write something
akin to Processing for Haskell (http://www.processing.org).
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Capitalization and associated type families

[Brian Hulley]

Jonathan Cast wrote:

On Mon, 2008-08-04 at 19:51 +0100, Brian Hulley wrote:
For example, why is there any distinction between a type "variable" and 
a type "constant"?


forall a b. (a -> b) -> List a -> List b

Now this begs the question: why does "List" need to start with a 
capital? (supposing that quantifiers were always written explicitly)


AFAIK, it doesn't; the variable/constant distinction is just there to
let the implementation put the foralls in for you.


Hi Jonathan - thanks - this confirms what I've been thinking. However 
consider:


class Foo a where

f :: a -> b -> (a, b)

Here there is no capitalization distinction in the type of (f) but the 
implementation can still insert the "forall b." since (a) is already in 
scope. Therefore similarly, if type constructors like "List" were 
instead written using lowercase, since they would already be in scope it 
would be clear even without explicit quantifiers that (a) and (b), but 
not (list), were to be quantified in the type of (map) (assuming of 
course that there was no top level data decl for (a) or (b)).



 Similarly, if we had
explicit foralls on equations, we could say

forall n x xn. drop (n+1) (x:xn) = drop n xn

but

forall n. drop n nil = nil

and it would be perfectly clear that `nil' in the latter case was a
constructor.


Actually I quite like the above because it shows that pattern matching 
can be understood in terms of universally quantified predicates.


Regarding the verbosity, patterns are something of a special case since 
variables (that are introduced in the pattern) can only occur once and 
there is no need to have higher rank quantification in value patterns 
(disregarding explicit tests for _|_). Therefore special syntax could be 
used to make the above shorter e.g. borrowing the '?' from Felix 
(http://felix.sourceforge.net/doc/tutorial/introduction/en_flx_tutorial_top.html 
 (section 2.11/2.17 etc)):


drop (?n + 1) (_ : ?xn) = drop n xn
drop ?n nil = nil

(where glued prefix binds tighter than application).



Of course, if you want to introduce this rule, you'd better start out
with it and be consistent --- require every variable to be explicitly
brought into scope.  I think you'd find it pretty annoying after trying
to program in your new language for a while, though.



I agree that there are many good points in favour of Haskell's use of a 
case distinction, not the least being that it gives definite guidance on 
when to use lower or upper case identifiers and therefore avoids the 
mess you find in C++ programs where every programmer has their own 
private conventions which can lead to confusion and useless debate.


However it still seems to me that the case distinction, at least on the 
level of type constructors, becomes problematic and possibly 
inconsistent especially if I consider the effects of trying to 
incorporate something like the ML module system as well as type classes. 
(For example the Moby language (http://moby.cs.uchicago.edu/ ), a 
possible successor to SML, uses capitalization for type constructors 
similar to Haskell which means that type parameters in functor 
applications must be uppercase, which conflicts with the use of 
lowercase type params for classes which are a special kind of functor... 
(Moby itself doesn't encounter any difficulty since it doesn't have type 
classes)).


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

[Haskell-cafe] ICFP08 Call for Participation

[Matthew Fluet (ICFP Publicity Chair)]

=
Call for Participation

The 13th ACM SIGPLAN International Conference
on Functional Programming (ICFP 2008)

http://www.icfpconference.org/icfp2008

  Victoria, BC, Canada, 22-24 September 2008
=

ICFP 2008 provides a forum for researchers and developers to hear
about the latest work on the design, implementations, principles, and
uses of functional programming. The conference covers the entire
spectrum of work, from practice to theory, including its peripheries.

Preliminary program:
 * http://www.icfpconference.org/icfp2008/schedule.html
 * Invited speakers:
   + Butler Lampson, Microsoft Research;
 Lazy and Speculative Execution in Computer Systems
   + Olivier Danvy, University of Aarhus;
 Defunctionalized Interpreters for Higher-Order Languages
   + Mark Jones, Portland State University;
 Polymorphism and Page Tables -- Systems Programming From a
 Functional Programmer's Perspective

Schedule including related workshops:
 * Sep 20: ACM SIGPLAN Workshop on Generic Programming
 * Sep 20: ACM SIGPLAN Workshop on Mechanizing Metatheory
 * Sep 20: ACM SIGPLAN Workshop on Scheme and Functional Programming
 * Sep 21: ACM SIGPLAN Workshop on ML
 * Sep 21: ACM SIGPLAN Functional and Declarative Programming in Education
 * Sep 22-24: ICFP08
 * Sep 25: ACM SIGPLAN Haskell Symposium
 * Sep 25: Functional Programming Developer Tracks
 * Sep 26: Commercial Users of Functional Programming
 * Sep 27: ACM SIGPLAN Erlang Workshop
 * Sep 27: Functional Programming Developer Tracks

Registration information:
 * http://www.regmaster.com/conf/icfp2008.html
 * Early registration deadline: August 20, 2008

Conference hotel accommodation information:
 * http://www.deltahotels.com/groups/online/VIC/acm.php
 * Conference rate deadline: August 18, 2008
 * Wiki page to coordinate room-sharing:
   http://www.icfpconference.org/pmwiki/pmwiki.php?n=Main.ICFP08RoomShare


Conference organizers:
 * General Chair: James Hook (Portland State University)
 * Program Chair: Peter Thiemann (Universität Freiburg)
 * Local Arrangements Chair: George Tzanetakis (University of Victoria)
 * Workshop Co-Chairs: Michael Sperber (DeinProgramm)
   and Graham Hutton (University of Nottingham)
 * Programming Contest Co-Chairs: John Reppy (University of Chicago)
   and Tim Sheard (Portland State University)
 * Publicity Chair: Matthew Fluet (Toyota Technological Institute at Chicago)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: ANN: Haddock version 2.2.1

[Gwern Branwen]

On 2008.08.04 20:47:12 +0200, Christian Maeder <[EMAIL PROTECTED]> scribbled 
1.1K characters:
> Right,
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Cabal-1.4.0.1
> works.
>
> It seems that the dependencies for ghc-paths could be improved.
>
> Thanks Christian

Yes, I emailed Marlow suggesting that yesterday. (Or perhaps it was the day 
before.)

--
gwern
Firewalls CAVE Richard Croatian Honduras WAS AKR 701 hrt varon



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

Re: [Haskell-cafe] Capitalization and associated type families

[Jonathan Cast]

On Mon, 2008-08-04 at 19:51 +0100, Brian Hulley wrote:
> Hi,
> I'm familiar with the capitalization rules for identifiers in Haskell 
> and know that they are very useful and practical e.g. by allowing 
> variables to be distinguished from "constants" in patterns etc.
> 
> However I'm trying to understand on a much deeper level whether or not 
> they can really be justified and indeed if there is a danger that they 
> can lead to inconsistency in the light of future extensions to the language.
> 
> For example, why is there any distinction between a type "variable" and 
> a type "constant"?
> 
> To make this clearer consider the type of (map):
> 
>   (a -> b) -> List a -> List b
> 
> (ignoring the special [] syntax for list types which would just confuse 
> the issue here).
> 
> With explicit quantifiers, we'd write:
> 
>   forall a b. (a -> b) -> List a -> List b
> 
> Now this begs the question: why does "List" need to start with a 
> capital? (supposing that quantifiers were always written explicitly)

AFAIK, it doesn't; the variable/constant distinction is just there to
let the implementation put the foralls in for you.  Similarly, if we had
explicit foralls on equations, we could say

forall n x xn. drop (n+1) (x:xn) = drop n xn

but

forall n. drop n nil = nil

and it would be perfectly clear that `nil' in the latter case was a
constructor.

Of course, if you want to introduce this rule, you'd better start out
with it and be consistent --- require every variable to be explicitly
brought into scope.  I think you'd find it pretty annoying after trying
to program in your new language for a while, though.

jcc



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

[Haskell-cafe] Capitalization and associated type families

[Brian Hulley]

Hi,
I'm familiar with the capitalization rules for identifiers in Haskell 
and know that they are very useful and practical e.g. by allowing 
variables to be distinguished from "constants" in patterns etc.


However I'm trying to understand on a much deeper level whether or not 
they can really be justified and indeed if there is a danger that they 
can lead to inconsistency in the light of future extensions to the language.


For example, why is there any distinction between a type "variable" and 
a type "constant"?


To make this clearer consider the type of (map):

(a -> b) -> List a -> List b

(ignoring the special [] syntax for list types which would just confuse 
the issue here).


With explicit quantifiers, we'd write:

forall a b. (a -> b) -> List a -> List b

Now this begs the question: why does "List" need to start with a 
capital? (supposing that quantifiers were always written explicitly)


The same distinction between "constants" and "variables" is also used in 
predicate logic e.g.


On(x, Table) & Colour(x, Red)

but similarly the above could surely be written just as easily by:

exists x. on(x, table) & colour(x, red)

where (on), (table), (colour), and (red) are just considered to be 
variables that have already been introduced (by some enclosing scope) 
instead of having to think of them as "constants" and make a distinction 
between "constant" and "variable".


Anyway to get to the point of this post what I'm really trying to find 
is some explanation of why there is the concept of "constant" as opposed 
to "variable" or whether this concept is now redundant in the light of 
lexical scoping/ explicit quantification?


Somewhat related to this issue is the syntax of associated type 
families. For example in section 5.2.2 of 
http://www.haskell.org/haskellwiki/GHC/Indexed_types there is the example:


class C a b where
data T a

which raises in my mind several questions:

1) Why is (T) given a parameter? I.e. why does an associated type 
declared inside a class decl not automatically get all the parameters of 
the class passed to it so that one would just write:


class C a b where
data T
f :: T -> T
===
data family T a b
class C a b where ...
f :: T a b -> T a b

2) Compare:

class C a b t | a b -> t
with
class C a b where
data T

In other words, why is (T) a "constant" when it is declared inside the 
class but a "variable" when passed as a parameter?


Is the fact that (T) needs to be given a parameter even when it is 
declared inside the "scope" of the class type parameters the result of 
needing to fulfill the idea of "constant" vs "variable"?


3) In the syntax:

class C a b
data T a

it seems rather odd that the "a" in "T a" should be related to the "a" 
in "C a b" since one might expect that the name chosen for a parameter 
should be local to the data decl.


Apologies for such a rambling post. I've spent literally at least 6 
months scouring the internet trying to find a real discussion about 
capitalization rules because I'm trying to answer the following 
question: if I make use of a similar capitalization rule in my own 
language, can I guarantee that this rule will not lead to an 
inconsistency at some future point? Ie is there a real rock solid 
theoretical basis for making a distinction between "constants" and 
"variables" that holds even in the presence of lexical scoping?


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

Re: [Haskell-cafe] Re: ANN: Haddock version 2.2.1

[Christian Maeder]

Right,
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Cabal-1.4.0.1
works.

It seems that the dependencies for ghc-paths could be improved.

Thanks Christian

Gwern Branwen wrote:

On 2008.08.04 19:32:13 +0200, Christian Maeder <[EMAIL PROTECTED]> scribbled 
3.0K characters:

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haddock-2.2.1
depends on ghc-paths
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ghc-paths-0.1.0.2
ghc-paths failed for me with:

Setup.hs:7:7:
Could not find module `Distribution.Simple.PackageIndex':

I've ghc-6.8.3 and Cabal-1.2.4.0

Can haddock-2.2.1 replace may old haddock-0.8 (or haddock-0.9)?


I'm still struggling with this point. haddock-0.8 accepted the same file 
multiple times and several Main modules.




Cheers Christian


ghc-paths is very picky about its cabal version. Apparently Cabal 1.4.x works; you 
can get it from darcs at  
(dunno about any packages).

--
gwern
monarchist emc Taiwan SIGDASYS ation HRT SURSAT GNU OPS Ingram

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

Re: [Haskell-cafe] HDBC-ODBC linking problems in windows.

[PJ Durai]

On 8/3/08, Andrew Appleyard <[EMAIL PROTECTED]> wrote:
> Hi PJ,
>
> On 2/08/2008 4:09 AM, you wrote:
> > I am having issues getting hdbc/odbc working on windows.
> >
> > When using GHC, I am not able to compile a simple program. It ends up
> > with linker errors like
> > [...]
> > Is there an easy workaround for this? Or am I doing something wrong?
> >
> > MySetup
> > ===
> > Windows XP SP2
> > ghc 6.8.3
> > hdbc  1.1.5.0
> > hdbc-odbc 1.1.4.3.0
> >
>
> hdbc-odbc 1.1.4.4 contains a patch to the calling convention of the ODBC
> functions (from ccall to stdcall).
>
> Grab version 1.1.4.4 from Hackage [1] and hopefully that'll fix your
> problem.
>
> [1]
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HDBC-odbc

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

Re: [Haskell-cafe] Re: ANN: Haddock version 2.2.1

[Gwern Branwen]

On 2008.08.04 19:32:13 +0200, Christian Maeder <[EMAIL PROTECTED]> scribbled 
3.0K characters:
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haddock-2.2.1
> depends on ghc-paths
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ghc-paths-0.1.0.2
> ghc-paths failed for me with:
>
> Setup.hs:7:7:
> Could not find module `Distribution.Simple.PackageIndex':
>
> I've ghc-6.8.3 and Cabal-1.2.4.0
>
> Can haddock-2.2.1 replace may old haddock-0.8 (or haddock-0.9)?
>
> Cheers Christian

ghc-paths is very picky about its cabal version. Apparently Cabal 1.4.x works; 
you can get it from darcs at 
 (dunno about any packages).

--
gwern
monarchist emc Taiwan SIGDASYS ation HRT SURSAT GNU OPS Ingram


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

[Haskell-cafe] Re: ANN: Haddock version 2.2.1

[Christian Maeder]

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haddock-2.2.1
depends on ghc-paths
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ghc-paths-0.1.0.2
ghc-paths failed for me with:

Setup.hs:7:7:
Could not find module `Distribution.Simple.PackageIndex':

I've ghc-6.8.3 and Cabal-1.2.4.0

Can haddock-2.2.1 replace may old haddock-0.8 (or haddock-0.9)?

Cheers Christian


David Waern wrote:


-- Haddock 2.2.1


A new version of Haddock, the Haskell documentation tool, is out.

The homepage will be updated soon, containing a windows binary release.

Please use the bug tracker to submit bug reports and feature requests.


-- Changes since version 2.1.0


 * Support for GHC 6.8.3

 * The Hoogle backend is back

 * Show associated types in the documentation for class declarations

 * Show type family declarations

 * Show type equality predicates

 * Major bug fixes (#1 and #44)

 * It is no longer required to specify the path to GHC's lib dir

 * Remove unnecessary parenthesis in type signatures

 * Minor bug fixes


-- Links


Homepage:
 http://www.haskell.org/haddock

Hackage page:
 http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haddock-2.2.1

Bugtracker and wiki:
 http://trac.haskell.org/haddock

Mailing list:
 [EMAIL PROTECTED]

Code repository:
 http://code.haskell.org/haddock


-- Details


This release contains experimental and incomplete support for GHC's
Type Families extension. We have basic support for rendering of type
family declarations and associated types in the documentation.
Type/Data instances are not shown in the documentation at all, and
associated types are not shown for class instances. Feedback is
appreciated, especially for ideas of how to render type family
instances. Use either the bugtracker, or send a mail to the mailing
list.

We have also got the Hoogle backend back, thanks to Neil Mitchell! The
plan is to be compatible with the upcoming pre-release of Hoogle 4,
which is being developed by Neil as a Summer of Code project.


-- Get Involved


Haddock is an important project, as it is part of the Haskell
infrastructure core. The code base is gradually becoming easier to
read, better documented and more stable, but more work is needed. To
get involved, start by grabbing the code at

 http://code.haskell.org/haddock

then take a look at the bug and feature tracker at

 http://trac.haskell.org/haddock

for things to work on.

David

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

Re: [darcs-users] [Haskell-cafe] poll: how can we help you contribute to darcs?

[Jason Dusek]

zooko <[EMAIL PROTECTED]> wrote:
> Jason Dusek wrote:
> > Eric Kow <[EMAIL PROTECTED]> wrote:
> > >
> > > "I would contribute to darcs if only..."
> >
> >  ...there were interest in binary file handling.
>
> ...what do you mean -- do you want darcs to do some kind of
> binary deltas and then merge them? Sounds crazy. Or do you
> just want it to be efficient in time and space to hurl big
> files around without applying patches to binaries?

  I don't see how you can be efficient in space without doing
  binary deltas, but I don't care for binary merging (mergelets,
  anyone?).

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

Re[2]: [darcs-users] [Haskell-cafe] poll: how can we help you contribute to darcs?

[Bulat Ziganshin]

Hello zooko,

Monday, August 4, 2008, 7:13:51 PM, you wrote:

> By the way, one of the things that intrigues me is that the best open
> source compression tool out there is written in Haskell:

> https://haskell.org/bz

> There might be some interesting advantages that a revision control  
> tool could gain with the use of a good compression tool like that...

1. it is most efficient around all programs around, either open-source
or commercial: http://www.maximumcompression.com/data/summary_mf2.php#data

2. compression libs used in freearc all written in C++. the only good
thing is that i provide Haskell interface to these libs:
http://haskell.org/haskellwiki/Library/Compression

it really may be good idea to use, say, grzip instead of bzip2 to
compress patch files, but i don't think this is highly important. at
least interface is simple


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

Re: [Haskell-cafe] Brainstorming on how to parse IMAP

[Brandon S. Allbery KF8NH]

On 2008 Aug 4, at 6:10, Malcolm Wallace wrote:


A283 SEARCH {4} {21}
TEXTstring not in mailbox


Assuming the first line can be read strictly, and the remainder should
be lazy, the parser might look something like this:


FWIW, the actual data looks more like

  A283 SEARCH {4}
  TEXT
   {21}
  string not in mailbox

(the literal declaration is followed immediately by CRLF, the literal,  
CRLF, then the command line context resumes)


also, literals require multiple exchanges with the server unless the  
LITERAL+ extension is present and being used ({4+} instead of {4}).


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


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

Re: [darcs-users] [Haskell-cafe] poll: how can we help you contribute to darcs?

[zooko]

On Aug 2, 2008, at 19:26 PM, Jason Dusek wrote:


Eric Kow <[EMAIL PROTECTED]> wrote:

"I would contribute to darcs if only..."


  ...there were interest in binary file handling.


I'm interested in binary file handling.

But what do you mean -- do you want darcs to do some kind of binary  
deltas and then merge them?  Sounds crazy.  Or do you just want it to  
be efficient in time and space to hurl big files around without  
applying patches to binaries?


By the way, one of the things that intrigues me is that the best open  
source compression tool out there is written in Haskell:


https://haskell.org/bz

There might be some interesting advantages that a revision control  
tool could gain with the use of a good compression tool like that...


Regards,

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

Re: [Haskell-cafe] ActiveX and COM

[Olivier Boudry]

Ooops, I just realized that hpaste truncated my source file at 5k
(it's 8k long). Unfortunately the Excel file creation code is in the
truncated part of the file ;-)

So if you are interested in getting the full source, just ask.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ActiveX and COM

[Olivier Boudry]

On Mon, Aug 4, 2008 at 2:14 PM, Fernand <[EMAIL PROTECTED]> wrote:
> If you need to simply create and Excel Sheet, you may also try it using the
> new Microsoft XML format (it will only work with Office 2007, though) ; then
> you do not need COM.
>
> Sincerely yours,
>
> Fernand

Hi Fernand and Günther,

A few month ago I wrote some haskell to parse an XML document and
create an Excel XML document from the data. I just pasted the code
here: http://hpaste.org/9381

I'm using Excel 2003 and it works with XML.

Best regards,

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

Re: [Haskell-cafe] poll: how can we help you contribute to darcs?

[Claus Reinke]

Could darcs 2 performance be improved by making use of the
order of patches in the reference repo, to identify reference
versions and reign in exponential permutation issues? In other
words, all repos are equal, all patches are equal, but once a patch has made the
roundtrip through the reference repo, it i


s more than equal - there would be unlocated and located (wrt
to the reference repo) patches.

Claus

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

Re: [Haskell-cafe] poll: how can we help you contribute to darcs?

[Claus Reinke]

It would be useful if some darcs 2 hackers, contributors could help the
ghc people evaluate if darcs 2 is still in the running. That would mean
identifying the key bugs (eg windows case-insensitive file bugs, slow
pulls) and seeing how hard they are to fix. Also doing a test conversion
to darcs 2 format and benchmarking some of the key operations described
on the ghc evaluation page.

http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation


I think Simon Marlow has been running a converted ghc repo 
for a while, reporting performance and other issues arising;

he even put up a fixed darcs 2 binary for windows.

One thing I have been wondering about, assuming that darcs 2
(with darcs 2 format) really fixes the bugs that make darcs 1 such 
a headache with ghc, so that performance on large repos would 
be the major remaining hurdle, is this:


- according to specs, all darcs repos are equal, patches have 
   no particular order, other than calculated dependencies, and

   versions are just sets of patches

- in practice, major projects tend to have a reference repo,
   and lots of developer or branch repos; in the ghc case, any
   successful patch ultimately makes it into the main repo and
   is pulled from there into every other repo (some of which
   might have the patch already)

Could darcs 2 performance be improved by making use of the
order of patches in the reference repo, to identify reference
versions and reign in exponential permutation issues? In other
words, all repos are equal, all patches are equal, but once a patch has made the
roundtrip through the reference repo, it i

Claus

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

Re: [Haskell-cafe] poll: how can we help you contribute to darcs?

[Bit Connor]

What about the idea of creating a GUI interface to darcs? I love the
command line as much as the next guy, but I think darcs could really
benefit from a polished GUI. I used tortoise darcs on a small project
a while ago and it was pretty nice, but I think there is potential for
much better.

I think that if darcs had a usable GUI then it would be a great
advantage over other its competitors and it could tremendously
increase its user base.

I have been thinking about making a gtk2hs darcs frontend for a while
now, what does everyone think about this?

On Fri, Aug 1, 2008 at 6:45 PM, Eric Kow <[EMAIL PROTECTED]> wrote:
> Dear Haskellers,
>
> I would like to take an informal poll for the purposes of darcs
> recruitment.  Could you please complete this sentence for me?
>
>   "I would contribute to darcs if only..."
>
> The answers I am most interested in hearing go beyond "... I had more
> time".  For instance, if you are contributing to other Haskell/volunteer
> projects, why are you contributing more to them, rather than darcs?
>
>
>
>
>
>
>
> The context:
>
> Lately, darcs has suffered a setback: the GHC team has decided that it
> is now time to switch to a different system, like git or Mercurial.
> This is probably a good thing for GHC and for us.  By the way, good
> luck to them, and thanks for everything! (better GHC == better darcs)
>
> But where is darcs going?  For now, we are going to have to focus on
> what we do best, providing precision merging and a consistent user
> interface for small-to-medium sized projects.  I want more, though!  I
> want to see darcs 2.1 come out next year, performance enhanced out the
> wazoo, and running great on Windows.  And I want to see Future Darcs,
> the universal revision control system, seamlessly integrating with
> everybody else.
>
> We need to learn to do better so that darcs can achieve this kind of
> wild success.  For example, whereas darcs suffers from the "day job"
> problem, xmonad has had to turn developers away!
>
> As Don mentions, this is partly thanks to their extreme accessibility
> (better self-documentation).  But does anyone have more specific ideas
> about things we need to change so that you can contribute to darcs?
> How do we hit critical hacker mass?
>
> I have jotted down some other thoughts here regarding recruitment here:
>  http://wiki.darcs.net/index.html/Recruitment
>
> In the meantime, if you have been discouraged from hacking on darcs,
> we want to know why, and how we can change things!
>
> Thanks,
> ___
> 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] ActiveX and COM

[Fernand]

GüŸnther Schmidt пишет:

Hi,

what is currently the recommend way to interface with COM from haskell?

I need to create an Excel Sheet and thus need to use Excel via COM.

Günther
You have the HDirect package, you need some tweaking to compile it with 
the current GHC.
I only have a professionnal access to a Windows box, so I have no time 
to work on an official patch.
You may contact me by e-mail, and I'll send you my patched version of 
the library and some instruction on how to build something that should 
be workable.


If you need to simply create and Excel Sheet, you may also try it using 
the new Microsoft XML format (it will only work with Office 2007, 
though) ; then you do not need COM.


Sincerely yours,

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

[Haskell-cafe] ANN: Haddock version 2.2.1

[David Waern]

-- Haddock 2.2.1


A new version of Haddock, the Haskell documentation tool, is out.

The homepage will be updated soon, containing a windows binary release.

Please use the bug tracker to submit bug reports and feature requests.


-- Changes since version 2.1.0


 * Support for GHC 6.8.3

 * The Hoogle backend is back

 * Show associated types in the documentation for class declarations

 * Show type family declarations

 * Show type equality predicates

 * Major bug fixes (#1 and #44)

 * It is no longer required to specify the path to GHC's lib dir

 * Remove unnecessary parenthesis in type signatures

 * Minor bug fixes


-- Links


Homepage:
 http://www.haskell.org/haddock

Hackage page:
 http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haddock-2.2.1

Bugtracker and wiki:
 http://trac.haskell.org/haddock

Mailing list:
 [EMAIL PROTECTED]

Code repository:
 http://code.haskell.org/haddock


-- Details


This release contains experimental and incomplete support for GHC's
Type Families extension. We have basic support for rendering of type
family declarations and associated types in the documentation.
Type/Data instances are not shown in the documentation at all, and
associated types are not shown for class instances. Feedback is
appreciated, especially for ideas of how to render type family
instances. Use either the bugtracker, or send a mail to the mailing
list.

We have also got the Hoogle backend back, thanks to Neil Mitchell! The
plan is to be compatible with the upcoming pre-release of Hoogle 4,
which is being developed by Neil as a Summer of Code project.


-- Get Involved


Haddock is an important project, as it is part of the Haskell
infrastructure core. The code base is gradually becoming easier to
read, better documented and more stable, but more work is needed. To
get involved, start by grabbing the code at

 http://code.haskell.org/haddock

then take a look at the bug and feature tracker at

 http://trac.haskell.org/haddock

for things to work on.

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

[Haskell-cafe] Re: [darcs-users] poll: how can we help you contribute to darcs?

[Ferenc Wagner]

wren ng thornton <[EMAIL PROTECTED]> writes:

> [Bug trackers are an excellent source of tasks for active developers to 
> use so things don't get lost, but they're awful for new developers. For 
> someone just joining the project it's rarely clear how important a task 
> is, how hard, or how far reaching its consequences (or whether someone's 
> already working on it). Good trackers have fields to note these things, 
> but the notes are engineered for active developers; the extent to which 
> those notes are even used or accurate varies wildly from project to 
> project. Hence, having a clear discussion about what things really are 
> important and how much they interact with everything else is a great boon.]

Agreed.  In short, shouldn't Darcs come up with sth like
http://wiki.winehq.org/JanitorialProjects or
http://janitor.kernelnewbies.org/ perhaps?

And of course with some serious up-to-date documentation on the theory
behind Darcs.  AFAIK Ian Lynagh started working on one.  I'd say:
first be precise.  Don't be afraid of abstract algebra, it's
university material, quite some people actually understands it.  And
those can later explain the hard to grasp parts.  But I never felt
like diving into the bunch of hazy metaphors I found about the inner
workings of Darcs, even though I was and still am interested.  So I
nevert felt qualified to touch anything important or assess the
performance problems for example.
-- 
Cheers,
Feri.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ActiveX and COM

[GüŸnther Schmidt]

Hi,

what is currently the recommend way to interface with COM from haskell?

I need to create an Excel Sheet and thus need to use Excel via COM.

Günther

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

Re: [Haskell-cafe] Brainstorming on how to parse IMAP

[Malcolm Wallace]

> 1) Ideally I could parse stuff lazily.  I have tried this with FTP and
> it is more complex than it seems at first, due to making sure you
> never, never, never consume too much data.

PolyParse has lazy variants of its combinators, which would probably be
of use here.

Software:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/polyparse
Paper:
http://www-users.cs.york.ac.uk/~malcolm/partialparse.html

> 2) Avoiding Strings wherever possible.

PolyParse is completely independent of token type.  There is a
rudimentary module implementing the combinators on top of ByteString.
(Not currently exposed in the package interface, BTW.) I'm sure it would
not be difficult to build on top of LazyByteString also.  Patches
gratefully accepted.

> 3) Avoiding complex buffering schemes where I have to manually buffer
> data packets.

Provided the parser is lazy enough, the buffering would be done at the
level of Lazy ByteString (but I don't know whether LBS is suitable for
network-reading or not).

> Thoughts and ideas?

> A283 SEARCH {4} {21}
> TEXTstring not in mailbox

Assuming the first line can be read strictly, and the remainder should
be lazy, the parser might look something like this:

  searchResult = do n <- qnumber
word "SEARCH"
extents <- many1 (braces number)
return SearchResult n `apply`
   (mapAF (\m-> exactly m char) extents)
where
  -- embed map in an applicative functor
  mapAF :: (a -> Parser b) -> [a] -> Parser [b]
  mapAF p [] = return []
  mapAF p (x:xs) = return (:) `apply` p x `apply` mapAF p xs

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

Re: [Haskell-cafe] poll: how can we help you contribute to darcs?

[Ketil Malde]

Duncan Coutts <[EMAIL PROTECTED]> writes:

> It would be useful if some darcs 2 hackers, contributors could help the
> ghc people evaluate if darcs 2 is still in the running. 

This looks like a very easy and low-investement way to get involved.

Expanding a bit on this:  The page at
 asks for people to hammer
the hashed and darcs-2 repo formats.  While I haven't really had any
trouble with the old darcs-1 format, I can still experiment a bit.

However, the page looks to be a bit stale, can somebody in the know
look over it and update it so that it is current?  It'd be nice if
there were some suggestions or a 'howto' on how to go about testing.

Anyway, I just want to say that I really enjoy using darcs, and in
addition to being a really nice and easy to use VCS, it is also a
high-profile Haskell project with substantial PR value.  If we really
want Haskell to fail in attaining its goal of not attaining popularty,
darcs is an important piece.

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe