from:"Niklas Hambüchen"

On Fri 06 Sep 2013 22:13:58 JST, Yuri de Wit wrote:
 The right solution, imho, is to review these dependencies and move
 the low level ones out into a separate package that is shared by both
 ghc and cabal and that will rarely change. The direct side effect of
 this is that ghc would not be tied directly to a specific cabal
 version and you would not have to deal with this issue.

This sounds very right to me.

There should be something that describes what a GHC package database 
is, as minimally as possible (perhaps even only the data types).

In the end, ghc is the defining side here - cabal is only a tool that 
builds on top of these definitions.

Then ghc could finally be decoupled from Cabal.

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

Re: [Haskell-cafe] GHC API + Cabal API + Cabal version checks: is there a way out?

On Fri 06 Sep 2013 22:52:40 JST, Roman Cheplyaka wrote:
 The right solution for Cabal would be not to know anything about the
 GHC's database format at all.

 GHC and cabal communicate via a command line interface (`ghc-pkg dump`
 in our direction; `ghc-pkg update` in the other). So it would suffice to
 have a library which implements parsing and printing of the package
 description, and have that library shared between GHC and Cabal.

You are right. This is better.

GHC's dependency on cabal seems to actually be quite minimal!

I did a quick grep:

% grep -rI import Distribution --include *.hs --include *.lhs* . 
| grep -v libraries/ | grep -v Setup.hs | grep -v Setup.lhs | grep -v 
utils/haddock
./utils/ghc-cabal/Main.hs:import Distribution.PackageDescription
./utils/ghc-cabal/Main.hs:import Distribution.PackageDescription.Check 
hiding (doesFileExist)
./utils/ghc-cabal/Main.hs:import 
Distribution.PackageDescription.Configuration
./utils/ghc-cabal/Main.hs:import Distribution.PackageDescription.Parse
./utils/ghc-cabal/Main.hs:import Distribution.System
./utils/ghc-cabal/Main.hs:import Distribution.Simple
./utils/ghc-cabal/Main.hs:import Distribution.Simple.Configure
./utils/ghc-cabal/Main.hs:import Distribution.Simple.LocalBuildInfo
./utils/ghc-cabal/Main.hs:import Distribution.Simple.Program
./utils/ghc-cabal/Main.hs:import Distribution.Simple.Program.HcPkg
./utils/ghc-cabal/Main.hs:import Distribution.Simple.Utils 
(defaultPackageDesc, writeFileAtomic, toUTF8)
./utils/ghc-cabal/Main.hs:import Distribution.Simple.Build 
(writeAutogenFiles)
./utils/ghc-cabal/Main.hs:import Distribution.Simple.Register
./utils/ghc-cabal/Main.hs:import Distribution.Text
./utils/ghc-cabal/Main.hs:import Distribution.Verbosity
./utils/ghctags/Main.hs:import Distribution.Simple.GHC ( 
componentGhcOptions )
./utils/ghctags/Main.hs:import Distribution.Simple.Configure ( 
getPersistBuildConfig )
./utils/ghctags/Main.hs:import Distribution.Simple.Compiler ( 
compilerVersion )
./utils/ghctags/Main.hs:import Distribution.Simple.Program.GHC ( 
renderGhcOptions )
./utils/ghctags/Main.hs:import Distribution.PackageDescription ( 
library, libBuildInfo )
./utils/ghctags/Main.hs:import Distribution.Simple.LocalBuildInfo
./utils/ghc-pkg/Main.hs:import 
Distribution.InstalledPackageInfo.Binary()
./utils/ghc-pkg/Main.hs:import Distribution.ModuleName hiding (main)
./utils/ghc-pkg/Main.hs:import Distribution.InstalledPackageInfo
./utils/ghc-pkg/Main.hs:import Distribution.Compat.ReadP
./utils/ghc-pkg/Main.hs:import Distribution.ParseUtils
./utils/ghc-pkg/Main.hs:import Distribution.Package hiding (depends)
./utils/ghc-pkg/Main.hs:import Distribution.Text
./utils/ghc-pkg/Main.hs:import Distribution.Version
./compiler/ghci/Linker.lhs:import Distribution.Package hiding (depends, 
PackageId)
./compiler/main/Packages.lhs:import Distribution.InstalledPackageInfo
./compiler/main/Packages.lhs:import 
Distribution.InstalledPackageInfo.Binary
./compiler/main/Packages.lhs:import Distribution.Package hiding 
(PackageId,depends)
./compiler/main/PackageConfig.hs:import 
Distribution.InstalledPackageInfo
./compiler/main/PackageConfig.hs:import Distribution.ModuleName
./compiler/main/PackageConfig.hs:import Distribution.Package hiding 
(PackageId)
./compiler/main/PackageConfig.hs:import Distribution.Text
./compiler/main/PackageConfig.hs:import Distribution.Version
./compiler/main/Finder.lhs:import Distribution.Text
./compiler/main/Finder.lhs:import Distribution.Package hiding 
(PackageId)

As you can see, there are only 4 files in ghc itself that depend on 
Cabal:

./compiler/ghci/Linker.lhs
./compiler/main/Packages.lhs
./compiler/main/PackageConfig.hs
./compiler/main/Finder.lhs

(plus 1 file for ghc-pkg: ./utils/ghc-pkg/Main.hs)

The ones in GHC core seem to rely only on quite basic data types.

 From this, I would boldly claim that people have spent more time making 
the GHC build system work with this Cabal dependency than it would take 
stripping it off!

(In fact, I would try to do this right now if the GHC build system 
wouldn't take so long to compile even the smallest changes ...)

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

Re: [Haskell-cafe] GHC API + Cabal API + Cabal version checks: is there a way out?

It looks to me that technically it should be easy to split off the part
required by GHC.

Maybe somebody could just try that (currently it does not seem to take
longer than a few hours) so that we have some basic proposal and momentum.

On 07/09/13 00:04, JP Moresmau wrote:
 Oh, I'm happy to help as well if somebody is needed to do the change

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

Re: [Haskell-cafe] GHC API + Cabal API + Cabal version checks: is there a way out?

We just had a short discussion on #ghc, I copy-paste:

http://lpaste.net/92639

dcoutts_: nh2: Cabal does not depend on the ghc-pkg format. Cabal
specifies a compiler-independent package registration format. GHC uses
it in its external interface (and internally too). It uses the Cabal lib
for the parser+printer because it's easier than making its own and
keeping up with spec changes..
dcoutts_: type+parser+printer
nh2: dcoutts_: would it still not be easier to make this package
database specification a separate thing that both ghc and cabal can
depend on? It seems to me that this would be much less a moving target
than Cabal-the-build-system is
dcoutts_: nh2: what does make sense is to split the Cabal lib into the
Distribution.* bits and the Distribution.Simple.* bits
dcoutts_: nh2: it's not a natural split
hvr: nh2: btw, a related thread:
http://www.haskell.org/pipermail/ghc-devs/2013-March/000800.html
dcoutts_: nh2: there's a lot of types shared between the .cabal format
and the InstalledPackageInfo type
dcoutts_: as well as parser + printer infrastructure
dcoutts_: nh2: it makes sense to keep that all together, that's the
Distribution.* stuff
dcoutts_: as I said, what does make sense to split (it's been
deliberately kept mostly-separate) is the Distribution.Simple.* part
dcoutts_: nh2: and we need a parser for that part, that's the dependency
that's annoying
thoughtpolice: so yes, i'm going to look into it today if at all possible
nh2: dcoutts_: that makes sense. ghc does not depend on
Distribution.PackageDescription either, right?
dcoutts_: nh2: right, it doesn't need the source package type
(PackageDescription), just the installed package type (InstalledPackageInfo)
dcoutts_: nh2: but splitting these into different packages would not buy
us much and it's not a natural split
nh2: leaving away Distribution.Simple.*, the remaining part is already
so small that it indeed looks like a small enough interface
dcoutts_: nh2: it'd only help JP M if the remaining part (lets call it
cabal-build-simple) could build with an earlier core part (lets call it
cabal-lib) (in his request in
http://www.haskell.org/pipermail/haskell-cafe/2013-September/108746.html)
dcoutts_: nh2: and doesn't help me with my parser problems, we still
cannot depend on a decent parser combinator lib
dcoutts_: still have to use the crappy ReadP
nh2: dcoutts_: Distribution.PackageDescription is the .cabal file format
itself, right? Not sure if that should be part of the package DB spec,
it changes more often and ghc can't make use of it
nh2: why is it that you cannot depend on something better?
dcoutts_: nh2: because ghc cannot depend on parsec easily
dcoutts_: because it pulls in too many other things
dcoutts_: the ghc devs objected to my suggestion
dcoutts_: nh2: that's true but what does it really buy us if they're in
separate packages? We still cannot guarantee to support JP M's request
dcoutts_: e.g. in the switch to 1.18, there have been enough changes
that we'd need the latest version of the InstalledPackageInfo
hvr: dcoutts_: ...seems you have to explain that again everytime
somebody brings it up =)
nh2: dcoutts_: but do I not understand it right that if you put
PackageDescription not into cabal-lib and only in Cabal, Cabal could
actually depend on a proper parser since GHC doesn't depend on it any more?
dcoutts_: nh2: it's not a monolithic parser
dcoutts_: nh2: we have that Text class
dcoutts_: with the combinator parsers for all the various types used in
.cabal and installed package files
dcoutts_: these types + parser/printer infrastructure are shared between
the source and installed package files
dcoutts_: so even if we split it, we still have the problem of needing a
parser lib
lemao: dcoutts_: I hear you wrt to the difficulties and mixed results of
splitting Distribution.Simple at the same time that this GHC dependency
on cabal is really problematic for all the reasons already discussed
dcoutts_: lemao: I don't think splitting it would fix that
lemao: dcoutts_: yes, I hear you. Maybe the right solution here is to
have GHC own their own internal package info impl so Cabal and GHC can
go their separate ways
dcoutts_: you'd still have ghc depending on this smaller part, and
Cabal/cabal-install would still depend on (usually) the latest version
of that
dcoutts_: lemao: but that's also not satisfactory (for cabal-lib to be a
private dep of ghc) because ghc api exposes the InstalledPackageInfo type
dcoutts_: it's not a private dependency of the ghc api package, it's a
public dependency
lemao: dcoutts_: I guess what I meant is that ghc-pkg package
format/parser/etc would be a complete fork
dcoutts_: which then means you cannot pass the InstalledPackageInfo from
ghc api functions to anything else
lemao: dcoutts_: at the same time that there are issues with the split
there are real issues witht he current status quo
dcoutts_: as well as meaning it'd get out of sync
nh2: dcoutts_: InstalledPackageInfo looks like a very

Re: [Haskell-cafe] GHC API + Cabal API + Cabal version checks: is there a way out?

I have filed a GHC ticket under

http://ghc.haskell.org/trac/ghc/ticket/8244

I hope this way we can find a solution soon.

On 07/09/13 00:04, JP Moresmau wrote:
 Oh, I'm happy to help as well if somebody is needed to do the change,
 since I have much to win in the future if EclipseFP can take advantage
 of a new version of Cabal without having to wait for a new GHC. The
 split in two libraries that Duncan mentions seems the best approach to
 me, having InstalledPackageInfo and related classes + parsers + pretty
 printers available as one reasonably stable library, while having
 another one for the real Cabal functionality...

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

Re: [Haskell-cafe] Strange IO sequence behaviour (Was: sequence causing stack overflow on pretty small lists)

Ah, that's enlightening, and a good addition to 
http://ghc.haskell.org/trac/ghc/ticket/8189

On Sat 07 Sep 2013 04:31:31 JST, Tom Ellis wrote:
 FYI, rwbarton on Reddit produced a nice answer:

 
 http://www.reddit.com/r/haskell/comments/1luan1/strange_io_sequence_behaviour/cc32ec4


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

Re: [Haskell-cafe] Tutorial on JS with Haskell: Fay or GHCJS?

2013-09-04 Thread Niklas Hambüchen

Hi, I'm also interested in that.

Have you already evaluated haste?

It does not seem to have any of your cons, but maybe others.

What I particularly miss from all solutions is the ability to simply 
call parts written in Haskell from Javascript, e.g. to write `fib` and 
then integrate it into an existing Javascript application (they are all 
more interested in doing the other direction).

On Wed 04 Sep 2013 17:14:55 JST, Alejandro Serrano Mena wrote:
 Hi,
 I'm currently writing a tutorial on web applications using Haskell. I
 know the pros and cons of each server-side library (Yesod, Snap,
 Scotty, Warp, Happstack), but I'm looking for the right choice for
 client-side programming that converts Haskell to JavaScript. I've
 finally come to Fay vs. GHCJS, and would like your opinion on what's
 the best to tackle. My current list of pros and cons is:

 Fay
 ===
 Pros:
 - Does not need GHC 7.8
 - Easy FFI with JS
 - Has libraries for integration with Yesod and Snap

 Cons:
 - Only supports a subset of GHC (in particular, no type classes)


 GHCJS
 ==
 Pros:
 - Supports full GHC
 - Easy FFI with JS
 - Highly opinionated point: will stay longer than Fay (but it's very
 important for not having a tutorial that is old in few months)

 Cons:
 - Needs GHC 7.8 (but provides a Vagrant image)


 ___
 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] On Markdown in Haddock and why it's not going to happen

2013-09-03 Thread Niklas Hambüchen

On 30/08/13 10:30, Mateusz Kowalczyk wrote:
 I would also like to remind you that if there's something that you'd
 like to see in Haddock or something that you feel is broken, a good way
 express this is to make a ticket on the Haddock Trac[2].

I made one:

http://trac.haskell.org/haddock/ticket/257

This is very useful for us because haddock is broken by some TH issue.
This way, we can have most of our docs anyway.

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

Re: [Haskell-cafe] On Markdown in Haddock and why it's not going to happen

2013-09-01 Thread Niklas Hambüchen

On 01/09/13 04:27, Mateusz Kowalczyk wrote:
 It doesn't have to be 1-to-1 but the features have to be expressible in
 both: it's useless if we have different features with one syntax but not
 the other.

I don't find that useless. Markdown does not have definition lists, but
we use a normal list to achieve the same documentation goals.

Already being able to simply write basic markdown would bring me big
practical benefits, and I would prefer minor theoretical misalignments
not to outweigh them.

 If Markdown can do
 something new, that something can be added; if something doesn't make
 sense in Haddock (like horizontal rules), we ignore them.
 This is precisely what I have been doing and why my post went over every
 point from the original Markdown documentation, talking about why each
 of these does or doesn't make sense. In the end, Markdown offers us
 nothing new feature wise

If the features are the same, I would prefer to write them in markdown.

 and either forces us to make up new syntax for
 things it doesn't know about (definition lists) or makes us remove
 existing features all together.

As I said, I think it doesn't matter. The basic functionality that
people use is all there. I have not seen a haddock definition list in my
life, the first one is encountered is the single one in attoparsec
because I grepped for [@ after reading your post.

 As for which markdown implementation to use: I think it really doesn't
 matter that much in practice. Github and pandoc can both render
 documentation to my pleasing; I have yet to find a difference between
 them that would be a practical problem for my documentation efforts.
 Unfortunately it _does_ matter in practice because each flavour solves
 Markdown quirks differently. On top of this, we have to accomodate for
 Haddock specific features. We're effectively creating our own flavour of
 Markdown + extra syntax. This sounds like… Haddock markup!

Once we have picked one of the flavours, I do not care about the others.
These quirks have little practical relevance: I have put the markdown
from my main github projects into the tool you mentioned, and into
pandoc, and there were no bad surprises for me.

Given that, even if I were to step into a pathologic case, after I write
the documentation, a quick look at it immediately tells me whether
everything is to my liking or not.

 Regarding module and type links: They are links, so probably just
 representing them as Markdown links would be cleanest. [SomeThing]()
 with an empty reference could make haddock automatically figure out what
 is wanted or default to a type, and you could be explicit with
 [SomeThing](module), [SomeThing](type) and [SomeThing](class).

 For headings, why is CPP a problem? CPP ignores haddock comments,
 haddock should ignore CPP. There is no reason to put CPP macros into
 comments.
 I have to admit that I did not explore this very carefully but you we
 can't simply guarantee that no one every will run CPP on their files by
 hand. Better safe than sorry.

This is unreasonable. You also can't guarantee that nobody will run the
Handlebars templating language either, or any other tool.

You cannot even tell what the user wants to achieve: Should

-- | You can use `#if SHELL a #else b #endif`

go into the documentation unexpanded or template processed?

The only sane way is to make haddock agnostic of all those tools in the
world, save the Haskell compiler which it addresses by being inside
comments.

If somebody wanted to run their custom tool by hand before running
haddock by hand, sure they would write

#if ...
-- | Some haddock
#else
-- | Some other haddock
# endif

if they wished to conditionally generate different haddock.

 Regarding emphasis, **foo** would simply not be a heading in an export
 list. Using markdown haddock, we will have markdown headings for that.
 But what if I want it to be a heading? Are we picking rules arbitrarily now?

I do not understand what you mean. If you want it to be a heading, you
write:

# My heading

I don't find that worse than

* My heading

 Markdown being claimed to be for editing documents for the Web doesn't
 make our efforts impossible. Pandoc can easily create latex output from
 it, and Github can use it as a documentation language for programming
 perfectly fine. So can we.
 That's because you can use LaTeX to render everything that HTML can (but
 not the other way around!).

Yes, so what is the problem? You write markdown and it can be compiled
to your target languages. Why is it a problem that you cannot go the
other way around?

My point here was saying that markdown can be compiled to the three
targets you mentioned.

 GitHub can use it because they don't have the burden of having to
 accommodate for an existing feature set of a different markup language.
 Note how GitHub Markdown doesn't have all the features of Haddock,
 therefore it is _not_ compatible with it. We can't just use their
 Markdown because

Re: [Haskell-cafe] On Markdown in Haddock and why it's not going to happen

2013-08-31 Thread Niklas Hambüchen

Hello,

I disagree.

While none of your detail points are wrong, they mainly focus on the
fact that there is no 1-to-1 mapping between the existing haddock markup
and Markdown. I don't think there needs to be. If Markdown can do
something new, that something can be added; if something doesn't make
sense in Haddock (like horizontal rules), we ignore them.

I don't think original and markdown syntax should be mixed in the same
file. That would make everything impossible to parse and difficult to write.

As for which markdown implementation to use: I think it really doesn't
matter that much in practice. Github and pandoc can both render
documentation to my pleasing; I have yet to find a difference between
them that would be a practical problem for my documentation efforts.

Regarding module and type links: They are links, so probably just
representing them as Markdown links would be cleanest. [SomeThing]()
with an empty reference could make haddock automatically figure out what
is wanted or default to a type, and you could be explicit with
[SomeThing](module), [SomeThing](type) and [SomeThing](class).

For headings, why is CPP a problem? CPP ignores haddock comments,
haddock should ignore CPP. There is no reason to put CPP macros into
comments.

Regarding emphasis, **foo** would simply not be a heading in an export
list. Using markdown haddock, we will have markdown headings for that.

Markdown being claimed to be for editing documents for the Web doesn't
make our efforts impossible. Pandoc can easily create latex output from
it, and Github can use it as a documentation language for programming
perfectly fine. So can we.

Did I address all your points?

Niklas


On Fri 30 Aug 2013 10:30:51 JST, Mateusz Kowalczyk wrote:
 Greetings café,

 Perhaps some saddening news for Markdown fans out there. As you might
 remember, there was a fair amount of push for having Markdown as an
 alternate syntax for Haddock.

 Unfortunately, this is probably not going to happen for reasons listed
 on the post I just published at [1].

 This thread is meant to be for discussion about the post as many people,
 myself included, felt that Markdown would be a nice thing to have.

 I feel like I covered the topic fairly well on the post but feel free to
 give suggestions or ask questions.

 I would also like to remind you that if there's something that you'd
 like to see in Haddock or something that you feel is broken, a good way
 express this is to make a ticket on the Haddock Trac[2].

 I will close the relevant Markdown ticket on the Trac[3] in about 3
 days, unless someone can come up with a reasonable solution that meets
 the initial intent of this part of the project: a widely known markup
 format that could be used as an alternate syntax for Haddock so that
 it's possible to write the documentation without learning the vanilla
 syntax itself.

 [1]:
 http://fuuzetsu.co.uk/blog/posts/2013-08-30-why-Markdown-in-Haddock-can't-happen.html

 [2]: http://trac.haskell.org/haddock

 [3]: http://trac.haskell.org/haddock/ticket/244

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

Re: [Haskell-cafe] cpphs calls error when it finds an #error declaration

2013-08-28 Thread Niklas Hambüchen

On 29/08/13 00:43, Malcolm Wallace wrote:
 Have you tried simply wrapping the call to runCpphs in a catch?  Something 
 like
 
 safeRunCpphs :: ... - IO (Either String String)
 safeRunCpphs foo = fmap Right (runCpphs foo) `catch` (\(UserError s)- 
 Left s

Yes, that is what I'm doing at the moment. The problem with this is that
it does not allow me to distinguish between a programmer error (error)
on the caller or implementation side, and an #error in the input file.

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

Re: [Haskell-cafe] sequence causing stack overflow on pretty small lists

Thanks for your examples.

On 27/08/13 13:59, Albert Y. C. Lai wrote:
 The correct fix is to raise the stack cap, not to avoid using the stack.
 
 Indeed, ghci raises the stack cap so high I still haven't fathomed where
 it is. This is why you haven't seen a stack overflow in ghci for a long
 time. See, ghci agrees: the correct thing to do is to raise the stack cap.

If I understand this correctly, you agree that the stack size should be
unlimited by default?

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

[Haskell-cafe] cpphs calls error when it finds an #error declaration

Hi,

after some debugging of a higher-level tool I found out that when I use
cpphs as a library and the `runCpphs` function that is to produce the
preprocessed output, when it comes across the #error directive it will
terminate my program.

This is because handling #error is implemented with Haskell's `error`.

I find that slightly unfortunate since it means I cannot distinguish
betwen an #error written in the input file and a programming error
inside cpphs.

@Malcolm, would you mind a change towards throwing an exception that is
different from error so that it can be easily caught, or even better, a
change from

runCpphs :: ... - IO String

to

runCpphs :: ... - IO (Either String String)

or similar?

If an exception based interface is kept, it would be nice to add some
haddock to `runCpphs`; not knowing about the existence of #error, it is
easy to assume that the IO is only used for accessing the FilePath
passed in.

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

Re: [Haskell-cafe] Template Haskell

Hi Jose,

Template Haskell doesn't parse code.

haskell-src-exts and the GHC API can do that.

Have a look at:

* ghc-mod browse (using ghc api)
* hscope (using haskell-src-exts)

On 27/08/13 15:45, Jose A. Lopes wrote:
 Hi,
 
 Is it possible to retrieve all definitions contained in a module using
 Template Haskell ?
 
 Thanks,
 Jose
 

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

Re: [Haskell-cafe] sequence causing stack overflow on pretty small lists

On 27/08/13 20:37, Patrick Palka wrote:
 You can use ContT to force the function to use heap instead of stack
 space, e.g. runContT (replicateM 100 (lift randomIO)) return

That is interesting, and works.

Unfortunately its pure existence will not fix sequence, mapM etc. in base.

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

[Haskell-cafe] sequence causing stack overflow on pretty small lists

On #haskell we recently had a discussion about the following:

   import System.Random

   list - replicateM 100 randomIO :: IO [Int]

I would think that this gives us a list of a million random Ints. In
fact, this is what happens in ghci. But with ghc we get:

   Stack space overflow: current size 8388608 bytes.
   Use `+RTS -Ksize -RTS' to increase it.

This is because sequence is implemented as

 sequence (m:ms) = do x - m
  xs - sequence ms
  return (x:xs)

and uses stack space when used on some [IO a].

From a theoretical side, this is an implementation detail. From the
software engineering side this disastrous because the code is

  * obviously correct by itself
  * the first thing people would come up with
  * not exaggerating: a million elements is not much
  * used a lot of places: mapM, replicateM are *everywhere*

and yet it will kill our programs, crash our airplanes, and give no
helpful information where the problem occurred.

Effectively, sequence is a partial function.

(Note: We are not trying to obtain a lazy list of random numbers, use
any kind of streaming or the likes. We want the list in memory and use it.)

We noticed that this problem did not happen if sequence were implemented
with a difference list.

What do you think about this? Should we fix functions like this,
probably trading off a small performance hit, or accept that idiomatic
Haskell code can crash at any time?

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

Re: [Haskell-cafe] sequence causing stack overflow on pretty small lists

As an example that this actually makes problems in production code, I
found this in the wildlife:

https://github.com/ndmitchell/shake/blob/e0e0a43/Development/Shake/Database.hs#L394

-- Do not use a forM here as you use too much stack space
bad - (\f - foldM f [] (Map.toList status)) $ \seen (i,v) - ...

I could bet that there is a lot of code around on which we rely, which
has the same problem but does not go that far in customisation.

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

Re: [Haskell-cafe] ordNub

On 14/07/13 20:20, Niklas Hambüchen wrote:
 As you might not know, almost *all* practical Haskell projects use it,
 and that in places where an Ord instance is given, e.g. happy, Xmonad,
 ghc-mod, Agda, darcs, QuickCheck, yesod, shake, Cabal, haddock, and 600
 more (see https://github.com/nh2/haskell-ordnub).

GHC uses nub.

Also let me stress again that the n² case happens even if there are no
duplicates.

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

Re: [Haskell-cafe] sequence causing stack overflow on pretty small lists

Maybe an unlimited stack size should be the default?

As far as I understand, the only negative effect would be that some
programming mistakes would not result in a stack overflow. However, I
doubt the usefulness of that:

* It already depends a lot on the optimisation level
* If you do the same thing in a slightly different way, and you allocate
on the heap instead of on the stack you will not get it either

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

Re: [Haskell-cafe] Renumbered mailing list posts

2013-08-25 Thread Niklas Hambüchen

Austin: Do you have any update on this?

On 11/08/13 04:48, Austin Seipp wrote:
 Henning,
 
 Thanks for the report. I'm currently investigating this, and think it
 should be possible to keep all of the old URLs intact.
 
 On Sat, Aug 10, 2013 at 11:01 AM, Niklas Hambüchen m...@nh2.me wrote:
 On 11/08/13 00:50, Brandon Allbery wrote:
 Those at least are recoverable, just replace hpaste.org
 http://hpaste.org with lpaste.net http://lpaste.net (content is
 still there). But still.

 Unfortunately I cannot amend emails that I have sent.

 Could we not just have kept the domain and set a CNAME entry to the new one?


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

Re: [Haskell-cafe] [Haskell] ANNOUNCE: haskell-src-exts 1.14.0

2013-08-20 Thread Niklas Hambüchen

Nice!

I hope that haskell-suite will eventually become awesome and solve most
of our automation-on-Haskell-code needs.

Two questions:

1) My most desired feature would be a syntax tree that does not pluck
pluck comments out and make me treat them separately. It looks much
easier to me to have a fully descriptive tree and (filter . concatMap) /
traverse them out in some way than getting a list of comments and having
to insert them back in the right places myself.
Is that possible?

2) Have you considered downloading the all-of-Hackage tarball and
running haskell-src-exts over it to get a benchmark of how much HSE can
already parse of the Haskell code out there?

Thanks!

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

Re: [Haskell-cafe] [Haskell] ANNOUNCE: haskell-src-exts 1.14.0

2013-08-20 Thread Niklas Hambüchen

On 20/08/13 18:19, Niklas Broberg wrote:
 Sadly not - it's theoretically impossible. The fact that you can put
 comments literally wherever, means that it's impossible to treat them as
 nodes of the AST. E.g.
 
   f {- WHERE -} x = -- WOULD
   -- THESE
   do -- COMMENTS
  a {- END -} - g x -- UP
  return {- ? -} a

Oh, I see what you mean.

I guess what I mean instead is:

* A lex list that contains *everything*, including comments and white space

* A full syntax tree of which each node points to (indexes) a position
in the lex list to get the precise original position; comments in
between two nodes can then be determined and more easily played with
because they are between their positions in the lex list

* An abstract syntax tree that has whitespace and comments discarded
(what HSE has now)

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

[Haskell-cafe] ANNOUNCE: posix-paths, for faster file system operations

2013-08-20 Thread Niklas Hambüchen

John Lato and I would like to announce our posix-paths package.

https://github.com/JohnLato/posix-paths

It implements a large portion of System.Posix.FilePath using ByteString
based RawFilePaths instead of String based FilePaths, and on top of that
provides a Traversal module with a fast replacement for
`getDirectoryContents` and a recursive `allDirectoryContents`.

`getDirectoryContents` is (unsurprisingly?) really slow.
Our replacement is 11 times faster in the recursive use case [1], and
only 20% slower than `find`.

Benchmarks are at [2], code is at [3].

We hope that these improvements will eventually make it into base some day.

Until then, we propose our package as a base for discussion and further
improvements.

Contributions are welcome:
Some FilePath operations are not in it yet (especially the Windows /
drive related ones), and our traversals might not work on Windows.
We would also appreciate some thorough looks at their low level
implementations.
If you find our benchmarks against getDirectoryContents unfair or would
like to add another one, please send a pull request.

We have been running this on Linux production machines for a few months
now, and are pleased by the speed-up.

[1] For the recursive version of the original `getDirectoryContents`, we
used the implementation given in Real World Haskell:
http://book.realworldhaskell.org/read/io-case-study-a-library-for-searching-the-filesystem.html

[2] Benchmarks:
On a real file system: http://johnlato.github.io/posix-paths/usrLocal.html
On tmpfs: http://johnlato.github.io/posix-paths/tmpfs.html (note that
here find is slow because of process starting overhead)

[3] Code:
Github: https://github.com/JohnLato/posix-paths
RawFilePath operations:
https://github.com/JohnLato/posix-paths/blob/master/src/System/Posix/FilePath.hs
Traversals:
https://github.com/JohnLato/posix-paths/blob/master/src/System/Posix/Directory/Traversals.hs
Benchmarks:
https://github.com/JohnLato/posix-paths/blob/master/benchmarks/Bench.hs

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

Re: [Haskell-cafe] Renumbered mailing list posts

2013-08-10 Thread Niklas Hambüchen

Yes, I also found that links from Google to archives don't work any 
more.

(Also fact that hpaste just went away, invalidating all my links to 
hpastes, is similarly bad.)

On Sat 10 Aug 2013 17:49:35 JST, Henning Thielemann wrote:
 Recently I found that links from Google search results to archive
 Haskell-Cafe messages are invalid. The messages are still there, but
 got a different number. E.g. the search result says:
   http://www.haskell.org/pipermail/haskell-cafe/2011-February/089455.html

 But the message is at
   http://www.haskell.org/pipermail/haskell-cafe/2011-February/088146.html

 Also links from Haskell-Wiki articles to the Haskell-Cafe archive are
 invalid now. This is very very very bad, since I used tons of such
 URLs in Wiki articles and it is very hard to find the message I
 referred to, if the URL does not work anymore.

 ___
 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] Renumbered mailing list posts

2013-08-10 Thread Niklas Hambüchen

On 11/08/13 00:50, Brandon Allbery wrote:
 Those at least are recoverable, just replace hpaste.org
 http://hpaste.org with lpaste.net http://lpaste.net (content is
 still there). But still.

Unfortunately I cannot amend emails that I have sent.

Could we not just have kept the domain and set a CNAME entry to the new one?

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

Re: [Haskell-cafe] casting a into Maybe a

2013-07-27 Thread Niklas Hambüchen

Put a Just around it?

transMit s now key (Just newmsgs) q m

On Sat 27 Jul 2013 20:05:43 JST, Joerg Fritsch wrote:
 If I have the following type signature
 transMit :: Serialize a = Socket - POSIXTime - KEY - Maybe a - TPSQ - 
 TMap a - IO ()


 And the function is called with
 transMit s now key newmsgs q m
 where newmsgs is whatever type a I get but _not_ a Maybe a

 then I get the error
 Could not deduce (a ~ Maybe a)
 from the context (Serialize a)

 Can I somehow when I call transmit cast newmsgs into a Maybe newmsgs or so so 
 that the function call fits the type signature?

 --Joerg


 ___
 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] Monad Transformer Space Leak

2013-07-18 Thread Niklas Hambüchen

Did you file this as a bug?

On Tue 23 Apr 2013 23:16:03 JST, Clark Gaebel wrote:
 I'm on 7.6.2, and it does. Oh no.

   - Clark

 On Tuesday, April 23, 2013, Tom Ellis wrote:

 On Tue, Apr 23, 2013 at 09:36:04AM +0200, Petr Pudlák wrote:
  I tested it on GHC 6.12.1, which wasn't affected by the recent
 ackermann
  bug, but still it leaks memory.

 I tested it on GHC 7.4.1 and I don't see any space leak.

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org javascript:;
 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] Monad Transformer Space Leak

2013-07-18 Thread Niklas Hambüchen

Sounds like a Real Good Thing to do :)

On Fri 19 Jul 2013 11:10:25 JST, Clark Gaebel wrote:
 No I haven't.

   - Clark

 On Thu, Jul 18, 2013 at 10:07 PM, Niklas Hambüchen m...@nh2.me wrote:
 Did you file this as a bug?

 On Tue 23 Apr 2013 23:16:03 JST, Clark Gaebel wrote:
 I'm on 7.6.2, and it does. Oh no.

   - Clark

 On Tuesday, April 23, 2013, Tom Ellis wrote:

 On Tue, Apr 23, 2013 at 09:36:04AM +0200, Petr Pudlák wrote:
  I tested it on GHC 6.12.1, which wasn't affected by the recent
 ackermann
  bug, but still it leaks memory.

 I tested it on GHC 7.4.1 and I don't see any space leak.

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org javascript:;
 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] ordNub

2013-07-15 Thread Niklas Hambüchen

Hey Jason,

would you mind giving a short idea of what the point of Bird's
implementation is / from what properties it is derived?

Also, running the QuickCheck tests you added, it doesn't give the same
output (order) as nub.

On 15/07/13 13:26, Jason Dagit wrote:
 Richard Bird has a book, Pearls of Functional Algorithm Design that
 is meant to teach a form of deriving algorithms from the properties we
 ask of them. In this book, he gives a possible derivation of ordNub,
 simply called nub in the book, following the methodology he is
 teaching. He notes in the text that this derivation feels more
 complicated than it ought.
 
 Here is his version: http://lpaste.net/87625
 
 I just sent you a pull request to add that one and S.toList .
 S.fromList that was suggested in this thread. I don't think those two
 implementations are faster than the others but it's nice to have them
 for completeness.
 
 Jason
 

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

Re: [Haskell-cafe] Hoogle problems?

2013-07-15 Thread Niklas Hambüchen

OK, but why does it need to go down for migration?

On Mon 15 Jul 2013 23:52:02 SGT, Daniel F wrote:
 The web site is migrating.
 IRC says: Topic for #haskell: haskell.org in the middle of migration;
 expect turbulence; use  www.haskell.org


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

[Haskell-cafe] ordNub

2013-07-14 Thread Niklas Hambüchen

tldr: nub is abnormally slow, we shouldn't use it, but we do.


As you might know, Data.List.nub is O(n²). (*)

As you might not know, almost *all* practical Haskell projects use it,
and that in places where an Ord instance is given, e.g. happy, Xmonad,
ghc-mod, Agda, darcs, QuickCheck, yesod, shake, Cabal, haddock, and 600
more (see https://github.com/nh2/haskell-ordnub).

I've taken the Ord-based O(n * log n) implementation from yi using a Set:

  ordNub :: (Ord a) = [a] - [a]
  ordNub l = go empty l
where
  go _ [] = []
  go s (x:xs) = if x `member` s then go s xs
else x : go (insert x s) xs


and put benchmarks on
http://htmlpreview.github.io/?https://github.com/nh2/haskell-ordnub/blob/1f0a2c94a/report.html
(compare `nub` vs `ordNub`).

`ordNub` is not only in a different complexity class, but even seems to
perform better than nub for very small numbers of actually different
list elements (that's the numbers before the benchmark names).

(The benchmark also shows some other potential problem: Using a state
monad to keep the set instead of a function argument can be up to 20
times slower. Should that happen?)

What do you think about ordNub?

I've seen a proposal from 5 years ago about adding a *sort*Nub function
started by Neil, but it just died.


(*) The mentioned complexity is for the (very common) worst case, in
which the number of different elements in the list grows with the list
(alias you don't have an N element list with always only 5 different
things inside).

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

Re: [Haskell-cafe] ordNub

2013-07-14 Thread Niklas Hambüchen

One of my main points is:

Should we not add such a function (ord-based, same output as nub, 
stable, no sorting) to base?

As the package counting shows, if we don't offer an alternative, people 
obviously use it, and not to our benefit.

(Not to say it this way:
We could make the Haskell world fast with smarter fusion, strictness 
analysis and LLVM backends.
Or we could stop using quadratic algorithms.)

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

Re: [Haskell-cafe] ANN: custom-hackage

2013-06-16 Thread Niklas Hambüchen

Hello Albert,

thanks for this! Please don't be reluctant with this, it is very
appreciated.

I have updated the script to use the paths as you described, and it
seems to work quite well. The fact that all tars land under package/
even makes is easier to use.

It would be great if you could give it another try.

Niklas

On 17/06/13 02:42, Albert Y. C. Lai wrote:
 On 13-06-13 11:09 AM, Niklas Hambüchen wrote:
 https://github.com/nh2/custom-hackage

 An (almost trivial) script to generate 00-index.tar.gz which is
 necessary to run your own `remote-repo`.
 
 I write the following critique with much reluctance, since I will be
 saying a lot of this cannot possibly work, here is why, but I would
 also like to think that it had worked for you before you published it.
 
 Assume the remote-repo line goes like
 
 remote-repo: custom:http://127.0.0.1:8080/packages/archive
 
 And assume it has just one package, formula-1.1
 
 Then your scheme uses this layout:
 
   http://127.0.0.1:8080/00-index.tar.gz
   http://127.0.0.1:8080/packages/archive/formula/1.1/formula-1.1.tar.gz
 
 However, cabal-install expects this layout:
 
   http://127.0.0.1:8080/packages/archive/00-index.tar.gz
   http://127.0.0.1:8080/packages/archive/package/formula-1.1.tar.gz
 
 I know this by both reading cabal-install source code and empirical
 tests, both 0.14 and 1.16.
 
 I have a working example at
 http://www.vex.net/~trebla/haskell/conrepo
 
 Lastly, I want to emphasize these points:
 
 The layout is different from Hackage's; cabal-install source code
 hardcodes treating Hackage differently. Yes, it goes out of its way to
 detect http://hackage.haskell.org/packages/archive; and do a different
 thing. Mimicking Hackage is futile, unless you go out of your way to
 also mimic the host name hackage.haskell.org.
 
 And the layout is different from local-repo's; local-repo's is in fact
 close to Hackage's.
 
 See my
 http://www.vex.net/~trebla/haskell/cabal-cabal.xhtml#remote-repo
 
 
 ___
 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] Testing invasive proposals with Hackager

On 13/06/13 10:06, Conrad Parker wrote:
 How do we add packages to the list; do you have a github repo for it?

I've put it on haskell-pkg-janitors:

https://github.com/haskell-pkg-janitors/hackage-build-deps/blob/master/ubuntu-13.04.txt

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

Re: [Haskell-cafe] Testing invasive proposals with Hackager

On 13/06/13 18:36, Vo Minh Thu wrote:
 For example, here is a run with GHC, no special options and using 4
 threads (note that this generally takes a long time, i.e. a few days):

My builds finished in  10 hours on an i7.

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

Re: [Haskell-cafe] Automating Hackage accounts

 As for the user account creation and uploading packages you don't own,
 Hackage 2 (any day now) has fixes for both.

Does Hackage 2 have SSL at least for the web interface?

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

[Haskell-cafe] ANN: custom-hackage

https://github.com/nh2/custom-hackage

An (almost trivial) script to generate 00-index.tar.gz which is
necessary to run your own `remote-repo`.

If you are a company that has to rely on that not everybody with a
Hackage account can run arbitrary code on your computer at your next
cabal install, and you want to make available only select versions of
packages (as opposed to a full hackage mirror), this is for you.

Just drop your tars into the directory structure, run the script and
serve it over HTTP.

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

Re: [Haskell-cafe] Automating Hackage accounts

 I'm not quite sure what it would achieve, though.

That if I want to upload something without my password going over in 
plain text, I can at least use the file upload form.

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

[Haskell-cafe] Testing invasive proposals with Hackager

2013-06-12 Thread Niklas Hambüchen

In many discussions we make guesses about how much code proposals like
Functor = Monad would break.

You can use https://github.com/dterei/Hackager to build all of Hackage
(preferably in a VM).

Of course many packages have external dependencies, so I'd like to share
the following list of packages to save you some time.


(These are the names of packages suited for a Ubuntu 13.04 VM, and with
these installed, 2800 packages are successfully built and 1700 failing,
so it's quite good coverage. If you find more packages that improve on
this, please add them.)

acl-dev
attr-dev
binutils-dev
cfitsio-dev
expect-dev
freeglut3-dev
libadns1-dev
libalure-dev
libasound-dev
libaspell-dev
libatlas-dev
libaugeas-dev
libavcodec-dev
libavfilter-dev
libavformat-dev
libavutil-dev
libbibutils-dev
libbluetooth-dev
libbz2-dev
libcal3d12-dev
libcmph-dev
libcrack2-dev
libcrypto++-dev
libcsound64-dev
libctemplate-dev
libcurl-dev
libcv-dev
libcwiid-dev
libdb-dev
libdevil-dev
libdpkg-dev
libev-dev
libevent-dev
libexif-dev
libfam-dev
libfcgi-dev
libfftw3-dev
libfltk1.3-dev
libfreenect-dev
libftgl-dev
libfuse-dev
libgd2-xpm-dev
libgeoip-dev
libglfw-dev
libglpk-dev
libgmime-2.6-dev
libgnome-keyring-dev
libgnutls-dev
libgnutls-dev
libgpcl-dev
libhighgui-dev
libimlib2-dev
libinsighttoolkit4-dev
libjasper-dev
libjudy-dev
libkyotocabinet-dev
liblapack-dev
libldap2-dev
libldap2-dev
libleveldb-dev
libmagic-dev
libmarkdown2-dev
libmecab-dev
libmpfr-dev
libmtp-dev
libmx-dev
libmysqlclient-dev
libncurses-dev
libncurses-dev
libnotmuch-dev
libobjc-4.7-dev
libodbc1
libode-dev
libogg-dev
libois-dev
libopenal-dev
libpam0g-dev
libpcap-dev
libpoker-eval-dev
libportaudio-dev
libpulse-dev
libqd-dev
libqrencode-dev
libraw1394-dev
libreadline-dev
libscsynth1
libselinux-dev
libsnappy-dev
libsndfile1-dev
libsqlite3-dev
libssl-dev
libssl-dev
libst-dev
libsvm-dev
libtalloc-dev
libtbb-dev
libtheora-dev
libtiff-dev
libtokyocabinet-dev
libtokyotyrant-dev
libtre-dev
libuuid-dev
libv4l-dev
libvxl1-dev
libxapian-dev
libxen-dev
libxerces-c-dev
libxine-dev
libxmmsclient-dev
libxosd-dev
libxqilla-dev
libxss-dev
libxtst-dev
libyaml-dev
libz-dev
libzephyr-dev
libzmq-dev
linux-libc-dev
tcl-dev
wx2.8-headers
xmms2-dev

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

Re: [Haskell-cafe] ANNOUNCE: standalone-haddock-1.0

2013-06-07 Thread Niklas Hambüchen

Awesome! I've wanted that many times.

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

Re: [Haskell-cafe] GADT and instance deriving

2013-05-24 Thread Niklas Hambüchen

On Sat 25 May 2013 00:37:59 SGT, TP wrote:
 Is this the right way to go? Is there any other solution?

I believe whether it's right or just depends on what you want to express.

 Do you confirm that tilde in s~s1 means s has the same type as s1?

It means: Both your s and s1 are Eqs but not necessarily the same one.

Your first example allows that, so you could have one with an Int and
one with a String inside (both are Eqs).

a = Box 1
b = Box hello

Now if that first code compiled, your code

(Box s1) == (Box s2) = s1 == s2

would effectively perform

... = 1 == hello

which is not possible.

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

Re: [Haskell-cafe] GADT and instance deriving

2013-05-24 Thread Niklas Hambüchen



On 25/05/13 06:06, Alexander Solla wrote:
 On Fri, May 24, 2013 at 10:41 AM, Niklas Hambüchen m...@nh2.me
 mailto:m...@nh2.me wrote:
 
 On Sat 25 May 2013 00:37:59 SGT, TP wrote:
  Is this the right way to go? Is there any other solution?
 
 I believe whether it's right or just depends on what you want to
 express.
 
  Do you confirm that tilde in s~s1 means s has the same type as s1?
 
 It means: Both your s and s1 are Eqs but not necessarily the same one.
 
 
 No, it doesn't.  s1 ~ s2 means the types are the same.  ~ is the
 equality constraint.
 
 http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/equality-constraints.html
  
 To say that s1 and s2 are Eq's, but not necessarily the same one, we
 would write a constraint of the form:

Sorry, I didn't formulate that clearly: I meant to describe what the
problem in the complaint about s1 ~ s2 is, not what s1 ~ s2 means.


 Your first example allows that, so you could have one with an Int and
 one with a String inside (both are Eqs).
 
  ...

 Nope.  It would perform (Just 1) == (cast hello), which is completely
 possible, since (cast hello) has the same type as (Just 1).


That's why I said your first example; there is no cast in it.

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

Re: [Haskell-cafe] Infrastructure for testing the impact of a Functor/Applicative/Monad hierarchy

2013-05-22 Thread Niklas Hambüchen

Ian Lynagh just posted a link to the hackager program:

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

That seems to be pretty much what I was looking for.

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

Re: [Haskell-cafe] ghc-mod v2.0.1

2013-05-20 Thread Niklas Hambüchen

Awesome, even with Cabal API!

Just one note: The emacs link on the left is not found.

On Tue 21 May 2013 10:31:01 SGT, Kazu Yamamoto (山本和彦) wrote:
 Hi cafe!

 I have released ghc-mod v2.0.1. From this version, ghc-mod provides
 the ghc-mod library in addition to the ghc-mod command:

   http://hackage.haskell.org/package/ghc-mod
   http://mew.org/~kazu/proj/ghc-mod/en/

 Enjoy!

 --Kazu

 ___
 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] Non-deterministic behaviour of aeson's parser

2013-05-18 Thread Niklas Hambüchen

Can't reproduce:

% ./aeson | sort | uniq -c
   2000 Right ()
% ./aeson | sort | uniq -c
   2000 Right ()
% ./aeson | sort | uniq -c
   2000 Right ()
% ./aeson | sort | uniq -c
   2000 Right ()
% ./aeson | sort | uniq -c
   2000 Right ()

Time 100:

% ./aeson | sort | uniq -c
 20 Right ()


My packages:

% ghc-pkg list
/var/lib/ghc/package.conf.d
   Cabal-1.16.0
   array-0.4.0.1
   base-4.6.0.1
   bin-package-db-0.0.0.0
   binary-0.5.1.1
   bytestring-0.10.0.2
   containers-0.5.0.0
   deepseq-1.3.0.1
   directory-1.2.0.1
   filepath-1.3.0.1
   ghc-7.6.2
   ghc-prim-0.3.0.0
   haskell2010-1.1.1.0
   haskell98-2.0.0.2
   hoopl-3.9.0.0
   hpc-0.6.0.0
   integer-gmp-0.5.0.0
   old-locale-1.0.0.5
   old-time-1.1.0.1
   pretty-1.1.1.0
   process-1.1.0.2
   rts-1.0
   template-haskell-2.8.0.0
   time-1.4.0.1
   unix-2.6.0.1
/home/niklas/.ghc/x86_64-linux-7.6.2/package.conf.d
   HTTP-4000.2.8
   HUnit-1.2.5.2
   QuickCheck-2.6
   Xauth-0.1
   aeson-0.6.1.0
   ansi-terminal-0.6
   attoparsec-0.10.4.0
   attoparsec-binary-0.2
   base-unicode-symbols-0.2.2.4
   blaze-builder-0.3.1.1
   byteorder-1.0.4
   cipher-aes-0.1.8
   convertible-1.0.11.1
   cpphs-1.16
   dlist-0.5
   ghc-paths-0.1.0.9
   ghc-syb-utils-0.2.1.1
   hashable-1.2.0.6
   haskell-lexer-1.0
   haskell-src-exts-1.13.5
   hidapi-1.0
   hlint-1.8.44
   hscolour-1.20.3
   hspec-1.5.4
   hspec-expectations-0.3.2
   io-choice-0.0.3
   lifted-base-0.2.0.4
   monad-control-0.3.2.1
   mtl-2.1.2
   network-2.4.1.2
   parsec-3.1.3
   pretty-show-1.5
   primitive-0.5.0.1
   quickcheck-io-0.1.0
   random-1.0.1.1
   robot-1.0.1.1
   robot-1.1
   setenv-0.1.0
   stm-2.4.2
   storable-record-0.0.2.5
   syb-0.4.0
   text-0.11.3.0
   transformers-0.3.0.0
   transformers-base-0.4.1
   uniplate-1.6.10
   unordered-containers-0.2.3.1
   utility-ht-0.0.9
   vector-0.10.0.1
   vector-th-unbox-0.2.0.1
   xhb-0.5.2012.11.23
   zlib-0.5.4.1


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

[Haskell-cafe] Infrastructure for testing the impact of a Functor/Applicative/Monad hierarchy

2013-05-16 Thread Niklas Hambüchen

Reading the other thread (Adding Applicative/Functor instances to all
Monads in GHC) I was wondering if there was infrastructure for testing
what effect making the often-discussed Functor/Monad change would have:
How many packages on hackage would break etc.

I have read a few times that people have compiled all of hackage to
see the impact of whatever.

How do you do that?

Do you just run a loop around cabal install or have you built some more
advanced tools to visualize the results better or compile the packages
from ground up, in order of their dependencies?

I'm interested in anything in this direction.

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

Re: [Haskell-cafe] Summary (Re: Interfacing Java/Haskell)

2013-05-15 Thread Niklas Hambüchen

For a simple interchange format, you might also look at MSGPACK; the 
bindings are nice and the format is simple.

I used it for call-haskell-from-anything 
(https://github.com/nh2/call-haskell-from-anything), a concept with 
which you can call Haskell code from any language that supports loading 
shared object files.

On Thu 16 May 2013 02:07:41 SGT, Hans Georg Schaathun wrote:
 The most common approach appears to be a network interface between
 separate java and haskell processes.  Both JSON and thrift appear to
 tools to help doing that.

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

Re: [Haskell-cafe] Parallel ghc --make

2013-05-15 Thread Niklas Hambüchen

Hello Thomas,

thanks for your detailed answer.

 Could be worthwhile re-evaluating the patch.

Does your patch still apply somewhat cleanly?
And does it address all the caches in your list already or only some
subset of them?

 To have a multi-process ghc --make you don't need thread-safety.
 However, without sharing the caches -- in particular the interface
 file caches -- the time to read data from the disk may outweigh any
 advantages from parallel execution.

That might be a big step already - I've never seen a project where I'd
care about parallel compilation that is not totally CPU-bound.

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

Re: [Haskell-cafe] ANN: Robot - Simulate keyboard and mouse events under X11

2013-05-14 Thread Niklas Hambüchen

Ah OK.

Thank you again for the fast fixes!

On Tue 14 May 2013 11:44:43 SGT, Chris Wong wrote:
 I removed the functionality because I didn't really see a use for it
 anymore. The `hold` and `tap` functions are already exception safe
 (thanks to `bracket`), and anyone who uses the unguarded `press`
 function probably wants to keep it held down anyway.

 Chris


 On Tue, May 14, 2013 at 12:46 PM, Niklas Hambüchen m...@nh2.me wrote:
 Awesome, that works very well, and it even made my program run faster /
 with less CPU.

 The reset functionality is useful, but I think optional is better. Did
 you remove it entirely or is it still available?

 On Tue 14 May 2013 08:25:04 SGT, Chris Wong wrote:
 Oh, I see now. I originally made the runRobot functions reset the
 input state when the Robot finished running. That worked well for my
 use case (testing GUIs), but as you have noticed, it causes
 unintuitive behavior when runRobot is called at a high frequency.

 In hindsight, that was a design flaw on my part: that resetting
 behavior should be specified explicitly, not attached unconditionally
 to every call to runRobot.

 I've removed the offending code, and released it as version 1.1.
 Hopefully I've ironed out the issues now :)


 On Mon, May 13, 2013 at 12:49 PM, Niklas Hambüchen m...@nh2.me wrote:
 Can you show me the code that triggers that behavior?

 It is basically

 Just connection - connect
 forever $ do
   (x,y) - getGyroMovement
   runRobotWithConnection (moveBy x y) connection



 --
 Chris Wong, fixpoint conjurer
   e: lambda.fa...@gmail.com
   w: http://lfairy.github.io/



 --
 Chris Wong, fixpoint conjurer
   e: lambda.fa...@gmail.com
   w: http://lfairy.github.io/

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

[Haskell-cafe] Parallel ghc --make

2013-05-13 Thread Niklas Hambüchen

I know this has been talked about before and also a bit in the recent
GSoC discussion.

I would like to know what prevents ghc --make from working in parallel,
who worked at that in the past, what their findings were and a general
estimation of the difficulty of the problem.

Afterwards, I would update
http://hackage.haskell.org/trac/ghc/ticket/910 with a short summary of
what the current situation is.

Thanks to those who know more!

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

Re: [Haskell-cafe] ANN: Robot - Simulate keyboard and mouse events under X11

2013-05-13 Thread Niklas Hambüchen

Awesome, that works very well, and it even made my program run faster / 
with less CPU.

The reset functionality is useful, but I think optional is better. Did 
you remove it entirely or is it still available?

On Tue 14 May 2013 08:25:04 SGT, Chris Wong wrote:
 Oh, I see now. I originally made the runRobot functions reset the
 input state when the Robot finished running. That worked well for my
 use case (testing GUIs), but as you have noticed, it causes
 unintuitive behavior when runRobot is called at a high frequency.

 In hindsight, that was a design flaw on my part: that resetting
 behavior should be specified explicitly, not attached unconditionally
 to every call to runRobot.

 I've removed the offending code, and released it as version 1.1.
 Hopefully I've ironed out the issues now :)


 On Mon, May 13, 2013 at 12:49 PM, Niklas Hambüchen m...@nh2.me wrote:
 Can you show me the code that triggers that behavior?

 It is basically

 Just connection - connect
 forever $ do
   (x,y) - getGyroMovement
   runRobotWithConnection (moveBy x y) connection



 --
 Chris Wong, fixpoint conjurer
   e: lambda.fa...@gmail.com
   w: http://lfairy.github.io/

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

Re: [Haskell-cafe] ANN: Robot - Simulate keyboard and mouse events under X11

2013-05-12 Thread Niklas Hambüchen

Yes, that works now.

I have another problem though: I move the cursor at high resolution 
(128 Hz) and it seems that when robot issues a command to X, it 
disables (keyboard) state so far. This means that it's impossible for 
me to Ctrl-C my program: Only c is sent all the time, me pressing 
Ctrl seems to be reset with the next robot event.

On Sun 12 May 2013 16:02:06 SGT, Chris Wong wrote:
 On Thu, May 9, 2013 at 1:36 PM, Chris Wong
 chrisyco+haskell-c...@gmail.com wrote:
 On Thu, May 9, 2013 at 4:47 AM, Niklas Hambüchen m...@nh2.me wrote:
 Hi,

 I just started using your library to move my cursor.

 Is it possible that it ignores negative values in moveBy?

 In other words, I can only move the cursor into one direction.

 I did some research, and traced this to a bug in an old (1.6) version
 of xcb-proto [1]. The coordinates were declared incorrectly as Word16,
 instead of Int16 as they should have been. It's been fixed in
 xcb-proto since 1.7.

 Okay, I've released a new version of Robot (1.0.1.1), that should fix
 this bug. Niklas: can you try it out please?

 Also, it turns out taking a screenshot is much easier than I thought.
 A single call to getImage returns a list of bytes, which happens to
 match exactly the internal structure used by JuicyPixels. I'll look
 deeper into this when I get the time.

 Chris

 --
 Chris Wong, fixpoint conjurer
   e: lambda.fa...@gmail.com
   w: http://lfairy.github.io/

 ___
 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] ANN: Robot - Simulate keyboard and mouse events under X11

2013-05-12 Thread Niklas Hambüchen

 Can you show me the code that triggers that behavior?

It is basically

Just connection - connect
forever $ do
  (x,y) - getGyroMovement
  runRobotWithConnection (moveBy x y) connection

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

Re: [Haskell-cafe] ghci: Difference in garbage collection etc. between REPL and function

2013-05-09 Thread Niklas Hambüchen

On 09/05/13 20:50, Brandon Allbery wrote:
 ghci is in many ways like an endless (or at least until :l/:r)
 do-block. In particular, the handle remains in scope after you run your
 commands at the prompt, so it is not garbage collected.  If you enclose
 it into its own do block, this introduces local scope and the handle
 goes out of scope and is garbage collected at the end.

I am not sure how the handle is relevant - I do not expect it to garbage
collected before the close or rely on that, and my problem happens
earlier already.

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

Re: [Haskell-cafe] ANN: Robot - Simulate keyboard and mouse events under X11

2013-05-08 Thread Niklas Hambüchen

Hi,

I just started using your library to move my cursor.

Is it possible that it ignores negative values in moveBy?

In other words, I can only move the cursor into one direction.

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

[Haskell-cafe] ghci: Difference in garbage collection etc. between REPL and function

2013-05-08 Thread Niklas Hambüchen

I have an annoying bug in a C binding that can be triggered like this:


handle - open ...

prep - makePreparedStatement handle INSERT ...

performGC

runStatement prep

close handle

If I run these steps one by one in ghci, garbage ends up in my handle as
expected.

However, if I let main = do ... this whole block in order to pack it
in a test case, it does not happen, neither in ghci nor ghc.

What might be the special magic in ghci's REPL that allows me to trigger
my bug so easily there?

Thanks
Niklas


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

Re: [Haskell-cafe] Hackage checking maintainership of packages

2013-05-06 Thread Niklas Hambüchen

On 06/05/13 17:46, Tillmann Rendel wrote:
 So what about this: Hackage could try to automatically collect and
 display information about the development status of packages that allow
 potential users to *guess*

In my opinion, that's what we have now.

Obtaining the info in the four points you mention from their respective
sources usually takes less than a minute in sum - hackage saving me that
minute would give me little added value.

Having the metrics you mention is nice, but still they are just metrics
and say little the only thing that's important:

   Is there a human who commits themselves to this package?

 I like the idea of displaying additional info about the status of
 package development, but I don't like the idea of annoying hard-working
 package maintainers with emails about their perfect packages

I really think this is not too big of a deal, getting one email every 3
months and clicking a few checkboxes.

Probably fits into one cabal update.

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

Re: [Haskell-cafe] Hackage checking maintainership of packages

2013-05-06 Thread Niklas Hambüchen

On 06/05/13 20:06, Tillmann Rendel wrote:
 Is a human clicked the check box a good metric for a human commits
 themselves to this package?

If the check box has the text Do you want this thing to be called
'maintained' on Hackage next to it, yes.

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

Re: [Haskell-cafe] Hackage checking maintainership of packages

2013-05-06 Thread Niklas Hambüchen

Well, that's what the once every 3 months is good for.

On Mon 06 May 2013 20:34:13 SGT, Tobias Dammers wrote:
 The problem is that people tend to (truthfully) check such a box, then
 stop maintaining the package for whatever reasons, and never bother
 unchecking the box.


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

Re: [Haskell-cafe] Hackage checking maintainership of packages

2013-05-05 Thread Niklas Hambüchen

I don't think that activity in the repo has too much to do with 
something being maintained.

Maintainance is a thing humans commit to, so the question of whether 
something is maintained should be a question to a human.

I often push a quick build failure fix for my packages, some of which I 
would still in not want to call maintained.

On Mon 06 May 2013 10:57:49 SGT, Clark Gaebel wrote:
 If there's a github link in the package url, it could check the last
 update to the default branch. If it's more than 6 months ago, an email
 to the maintainer of is this package maintained? can be sent. If
 there's no reply in 3 months, the package is marked as unmaintained.
 If the email is ever responded to or a new version is uploaded, the
 package can be un-marked.
   - Clark
 On Sunday, May 5, 2013, Lyndon Maydwell wrote:

 I've got it!

 The answer was staring us in the face all along... We can just
 introduce backwards-compatibility breaking changes into GHC-head
 and see if the project fails to compile for x-time! That way we're
 SURE it's unmaintained.

 I'll stop sending emails now.


 On Mon, May 6, 2013 at 10:44 AM, Clark Gaebel
 cgae...@uwaterloo.ca wrote:

 If there's a github link in the package url, it could check
 the last update to the default branch. If it's more than 6
 months ago, an email to the maintainer of is this package
 maintained? can be sent. If there's no reply in 3 months, the
 package is marked as unmaintained. If the email is ever
 responded to or a new version is uploaded, the package can be
 un-marked.

   - Clark


 On Sunday, May 5, 2013, Lyndon Maydwell wrote:

 But what if the package is already perfect?

 Jokes aside, I think that activity alone wouldn't be a
 good indicator.


 On Mon, May 6, 2013 at 9:59 AM, Conrad Parker
 con...@metadecks.org wrote:

 On 6 May 2013 09:42, Felipe Almeida Lessa
 felipe.le...@gmail.com wrote:
  Just checking the repo wouldn't work.  It may still
 have some activity
  but not be maintained and vice-versa.

 ok, how about this: if the maintainer feels that their
 repo and
 maintenance activities are non-injective they can
 additionally provide
 an http-accessible URL for the maintenance activity.
 Hackage can then
 do an HTTP HEAD request on that URL and use the
 Last-Modified response
 header as an indication of the last time of
 maintenance activity. I'm
 being a bit tongue-in-cheek, but actually this would
 allow you to
 point hackage to a blog as evidence of maintenance
 activity.

 I like the idea of just pinging the code repo.

 Conrad.

  On Sun, May 5, 2013 at 2:19 PM, Doug Burke
 dburke...@gmail.com wrote:
 
  On May 5, 2013 7:25 AM, Petr Pudlák
 petr@gmail.com wrote:
 
  Hi,
 
  on another thread there was a suggestion which
 perhaps went unnoticed by
  most:
 
  -- Forwarded message --
  From: Niklas Hambüchen m...@nh2.me
  Date: 2013/5/4
  ...
  I would even be happy with newhackage sending
 every package maintainer a
  quarterly question Would you still call your
 project X 'maintained'?
  for each package they maintain; Hackage could
 really give us better
  indications concerning this.
 
 
  This sounds to me like a very good idea. It could
 be as simple as If you
  consider yourself to be the maintainer of package
 X please just hit reply
  and send. If Hackage doesn't get an answer, it'd
 just would display some
  red text like This package seems to be
 unmaintained since D.M.Y.
 
  Best regards,
  Petr
 
 
  For those packages that give a repository, a query
 could be done
  automatically to see when it was last updated. It's
 not the same thing as
  'being maintained', but is less annoying for those
 people with many packages
  on hackage.
 
  Doug

Re: [Haskell-cafe] Backward compatibility

2013-05-04 Thread Niklas Hambüchen

 really need
 to. Does that make me ultra-conservative? Where I work, conservative is
 when you're still worried about how long it takes to dereference a virtual.
 
 Do you finally see where I'm coming from? If you want this language to
 catch on, you have to think about programming the people, not just the
 computers. You could also just soldier on as a brilliant microculture
 until you get swamped by something like F# that's not even where you
 were in 98, and one day people will tell you Haskell? Monads? That's
 not what I mean by FP. FP is something like F#. (Apologies to anybody
 who works on F#: my issue with it is that nobody I know is likely to
 figure out the functional way to do something if it's that easy for them
 to bottle out and do it the imperative way.)
 
 Maybe that is the new plan. Maybe Haskell already gave up wanting to be
 anything but a research platform. Maybe you guys calculate that if I
 really want to push FP I should be pushing some hybrid like F# or Ocaml.
 Remember how C++ succeeded where Smalltalk failed because it sneaked the
 changes under the table instead of calling for revolution. If that is
 the plan then I'd appreciate somebody putting me in the picture.
 Otherwise, please try to understand that the problems I'm up against are
 not about whether Num is derived from Eq or whatever.
 
 mfG,
 Adrian.
  
 
 
 
 On 4 May 2013 02:33, Niklas Hambüchen m...@nh2.me mailto:m...@nh2.me
 wrote:
 
 All right, here you go: https://github.com/nh2/WashNGo
 
 
 https://github.com/nh2/WashNGo/commit/08010e7404219470a827f3e4172004f9d2aedc29
 
 Took me around 75 minutes.
 
 Think about it a bit:
 
 I just ported thirty thousand lines of code that I have never seen
 before and that has bit-rotted for over six years to the latest
 programming environment.
 
 It being Haskell, I am pretty confident it does *exactly* what it's
 supposed to do.
 
 I want to see anyone do that with an equivalently sized + outdated Ruby
 / Python project.
 
 
 On 02/05/13 13:27, Adrian May wrote:
  I just tried to use Flippi. It broke because of the syntax change so I
  tried WASH. I couldn't even install it because of the syntax change. I
  persisted for a while but gave up because getPackageId doesn't
 exist in
  any form at all anymore. This was only the install script: what would
  WASH itself have in store for me to get my brain around?
 
 

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

[Haskell-cafe] runhaskell flags: What is going on?

 runhaskell -fno-warn-unused-matches Myfile.hs
[some compile error]

 runhaskell -fno-warn-unused-matches Myfile.hs
[no output whatsoever but exit code 127]

 runhaskell -asdf Myfile.hs
ghc: unrecognised flags: -asdf

 runhaskell -fasdf Myfile.hs
[no output whatsoever but exit code 127]


Not sure if that's how it should work or missing error reporting?

Thanks
Niklas

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

Re: [Haskell-cafe] Backward compatibility

While I certainly enjoy the discussion, how about addressing one of the
original problems:

On 02/05/13 13:27, Adrian May wrote:
 I just tried to use Flippi. It broke because of the syntax change so I
 tried WASH. I couldn't even install it because of the syntax change.

I just fixed that in https://github.com/nh2/flippi (note that I have
never seen this code before nor even known about it).

https://github.com/nh2/flippi/commit/5e2fa93f82b4123d0d5b486209c3b722c4c1313d

Had to delete 5 imports and convert one time value.

Took me around 3 minutes.

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

Re: [Haskell-cafe] Backward compatibility

On 04/05/13 01:52, Nicolas Trangez wrote:
 On Fri, 2013-05-03 at 10:40 -0700, Hilco Wijbenga wrote:
 Given the apparent simplicity of the changes needed to keep one's
 Haskell code up to snuff and the strong typing inherent in Haskell
 code, would it not be possible to create something similar? If there
 is a tool that moves (most of) one's code from Haskell version n to
 n+1 then making breaking changes would be even less of an issue.

 Just an idea, I have no clue about its feasibility...
 
 I mentioned the same on #haskell today. Something like Coccinelle
 (http://coccinelle.lip6.fr) semantic patches could be really useful to
 automate (some) API  language changes. Somewhat like (but better than)
 the Python '2to3' tool.
 
 I think some message about a GSoC project regarding an AST-based
 refactoring tool was posted to this list. That might be a useful
 building block for such tool?

Yes, I proposed that.

It seems to be already in the making by some, but seems to need more
concentrated community effort/support/contribution.

It would also *hugely* reduce the time spent on what my next email is about.

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

Re: [Haskell-cafe] Backward compatibility

All right, here you go: https://github.com/nh2/WashNGo

https://github.com/nh2/WashNGo/commit/08010e7404219470a827f3e4172004f9d2aedc29

Took me around 75 minutes.

Think about it a bit:

I just ported thirty thousand lines of code that I have never seen
before and that has bit-rotted for over six years to the latest
programming environment.

It being Haskell, I am pretty confident it does *exactly* what it's
supposed to do.

I want to see anyone do that with an equivalently sized + outdated Ruby
/ Python project.


On 02/05/13 13:27, Adrian May wrote:
 I just tried to use Flippi. It broke because of the syntax change so I
 tried WASH. I couldn't even install it because of the syntax change. I
 persisted for a while but gave up because getPackageId doesn't exist in
 any form at all anymore. This was only the install script: what would
 WASH itself have in store for me to get my brain around?

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

Re: [Haskell-cafe] runhaskell flags: What is going on?

Not sure what you mean; if I just run `runhaskell`, it reads from stdin.

In any way, if runhaskell exits with error code 127, should it not 
print what the error is?

On Fri 03 May 2013 22:48:33 SGT, Brandon Allbery wrote:
 If you type just 'runhaskell' you will get an error message which
 explains what is going on. (The short version is, -f has multiple
 meanings; some of them apply to runhaskell, and some to the underlying
 ghc.)


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

[Haskell-cafe] GSoC proposal: Haskell AST-based refactoring and API upgrading tool

2013-04-29 Thread Niklas Hambüchen

I would like to propose the development of source code refactoring tool
that operates on Haskell source code ASTs and lets you formulate rewrite
rules written in Haskell.

Objective
-

The goal is to make refactorings easier and allow global code changes
that might be incredibly tedious to do in a non-automated way.
By making these transformations convenient, we can make it easier to
maintain clean code, add new features or clean up leftovers faster, and
reduce the fear and effort to upgrade to newer versions of packages and
APIs.


Transformations
---

First, here are a few operations you would use this tool for. Some of
them are common operations you would also do in other programming
languages, some are more specific to Haskell.

* Changing all occurrences of import Prelude hiding (catch) to import
qualified Control.Exception as E

* Replacing all uses of a function with that function being imported
qualified or the other way around

* Adding a field to data constructor a record, setting user-supplied
defaults for construction and destruction:

-- Suppose you want to change one of these
data User = User { name :: String, age :: Int }
data User = User String Int

-- into one of these
data User = User { name :: String, age :: Int, active :: Bool }
data User = User String Int Bool

-- the refactoring tool could perform, in all relevant locations:
show (User name age) = ...
show (User name age _) = ...

-- and also this transformation:
... u { name = deleted } ...
... u { name = deleted, active = False } ...

-- or equivalently with records.

-- Special cases could be taken care of as specified, such as
--   whenever an object of [this User type] has
--of its records passed into some function 'email', do this
--now only if the user is active, so modify all relevant code
--email (name u)
--to
--if (active u) then email (name u) else return ()

-- Other examples include adding a position counter to attoparsec.

* Adding a type parameter to a type

-- This happens a lot on monad transformer stacks, e.g.
newtype MyMonad a b c = MyMonad (ReaderT a (WriterT b ...

-- and as you would probably agree on, this is not the most
-- comfortable change to make; in big project this can mean
-- hour-long grinding.

-- It has also recently happened in the basic underlying types
-- of packages like conduit and pipes.

* Adding a new transformer around a monad

* Addressing problems like mentioned in
http://blog.ezyang.com/2012/01/modelling-io/:
  There is one last problem with this approach: once the primitives
have been selected, huge swaths of the standard library have to be
redefined by “copy pasting” their definitions ...

* Extracting a value into a let or where clause

* Renaming a variable, and all its occurrences that are semantically
same variable (based on its scope)

* Changing the way things are done, such as:

* Replacing uses of fmap with $, also taking care of the
  corresponding import, and such cases were partial application
  is involved

* Replacing uses of when (isJust) to forM_

* Making imports clearer by adding all functions used to the file to the
import list of the module that gets them in scope

* Finding all places where an exported function does not have all its
arguments haddock-documented.

* Performing whole-project refactorings instead of operating on single
files only, allowing operations like

Find me all functions of this type, e.g.
 Maybe a - (a - m a) - m a
 in the project and extract them into this new module,
 with the name 'onJust'.


Some of the problems above can be tried to address using regex-based
search and replace, but this already fails in the simplest case of
import Prelude hiding (catch) in case there is more than that imported
from Prelude or newlines involved in the import list.

Transformation on the AST are much more powerful, and can guarantee that
the result is, at least syntactically, valid. No text base tool can do that.


Other uses
--

In addition to being able to perform transformations as mentioned above,
the refactoring tool as a library can be leveraged to:

* Support or be the base of code formatting tools such as
haskell-stylish, linters, style/convention checkers, static analyzers,
test coverage tools etc.

* Implement automatic API upgrades.

  Imagine the author of a library you use deprecates some functions,
introduces replacements, adds type parameters. In these cases, it is
very clear and often well-documented which code has to be replaced by
what. The library author could, along with the new release, publish
upgrade transformations that you can apply to your code base to save
most of the manual work.

  These upgrade transformations could be either parts of the packages
themselves or be separately maintained and refined on the feedback of
users

Re: [Haskell-cafe] GSoC proposal: Haskell AST-based refactoring and API upgrading tool

2013-04-29 Thread Niklas Hambüchen

Hello Malcolm,

no, I had indeed not seen this! Thanks for the link.

It goes very much in the direction I was thinking of, but it does not
seem to maintained and does not cabal install either.

It also seems very much focused on interactive editor integration as
compared to written-out transformations.

Do you know to what extent they have built and a modification-friendly AST?
Also, do you know if the people involved in this are still active in the
community and interested in working further in this direction?

Thanks
Niklas

On 29/04/13 15:36, Malcolm Wallace wrote:
 
 On 29 Apr 2013, at 07:00, Niklas Hambüchen wrote:
 
 I would like to propose the development of source code refactoring tool
 that operates on Haskell source code ASTs and lets you formulate rewrite
 rules written in Haskell.
 
 
 Seen this?
 http://www.haskell.org/haskellwiki/HaRe
 
 Regards,
 Malcolm
 

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

Re: [Haskell-cafe] package-inplace is shadowed by package package-hexstring

2013-04-14 Thread Niklas Hambüchen

Hi,

I just got the same thing with attoparsec GIT:

Preprocessing benchmark 'benchmarks' for attoparsec-0.10.4.0...
Building benchmark benchmarks...
creating dist/build/benchmarks
creating dist/build/benchmarks/benchmarks-tmp
/home/niklas/opt/haskell-7.4/bin/ghc --make -fbuilding-cabal-package -O
-odir dist/build/benchmarks/benchmarks-tmp -hidir
dist/build/benchmarks/benchmarks-tmp -stubdir
dist/build/benchmarks/benchmarks-tmp -i
-idist/build/benchmarks/benchmarks-tmp -ibenchmarks -idist/build/autogen
-Idist/build/autogen -Idist/build/benchmarks/benchmarks-tmp
-optP-include -optPdist/build/autogen/cabal_macros.h -hide-all-packages
-package-conf dist/package.conf.inplace -package-id
base-4.5.1.0-66f22db3dfcd87541c9c7e50e7095d26 -package-id
bytestring-0.9.2.1-503e91bb155301fdb1956cb5c26ce6e9 -package-id
criterion-0.6.2.1-5bc7e5a96c8208948366b8e3ea536e68 -package-id
deepseq-1.3.0.0-c26e15897417ecd448742528253d68f6 -package-id
parsec-3.1.3-771f99c8818551756b6f2ec3e86ab039 -package-id
text-0.11.2.3-db61832d0c4660614c4ceff234ed4abb -package-id
attoparsec-0.10.4.0-inplace -XHaskell98 benchmarks/Benchmarks.hs -o
dist/build/benchmarks/benchmarks
command line: cannot satisfy -package-id attoparsec-0.10.4.0-inplace:
attoparsec-0.10.4.0-inplace is shadowed by package
attoparsec-0.10.4.0-c391286d724823eaea3d4278acc0acc0
(use -v for more information)


I have no clue what's going on!

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

Re: [Haskell-cafe] ANN: psqueue-benchmarks - benchmarks of priority queue implementations

2013-04-12 Thread Niklas Hambüchen

I actually found a (potential) problem with the GHC implementation.

See here:

https://github.com/nh2/psqueue-benchmarks/blob/db89731c5b4bdd2ff2ef81022a65f894036d8453/QueueBenchmark.hs#L44

If I fromList 100 entries into the queue, it stack space overflows.

I got the same problem with the fingertree implementation, so maybe I
just construct the test case wrong and cause the stack space overflow
myself, but it works with the other two implementations.

Also, looking at the updated graph:

http://htmlpreview.github.com/?https://raw.github.com/nh2/psqueue-benchmarks/master/report.html

we can see that GHC's queue is 3 times slower than queuelike for
findmin sequential.

Where could the stack overflows come from?

Niklas

On 30/03/13 09:07, Kazu Yamamoto (山本和彦) wrote:
Hi Niklas,

No, it does not stack overflow, and it seems to perform slightly better
than the other implementations; it also doesn't suffer from the toList
slowness problem as does listlike.

Thanks. It's nice.

However, it is probably not as generally usable as it hardcodes the
priorities to be Doubles.

I think that you can import the tips of GHC PSQ to original PSQ.

P.S.

If you need test cases, you can find some properties for Heap
(priority queue) here:

https://github.com/kazu-yamamoto/llrbtree/blob/master/test/Heap.hs

You can add some properties relating dilatation to them.

--Kazu

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

[Haskell-cafe] Web servers: Running them multiple times in a ghci session

2013-04-10 Thread Niklas Hambüchen

I'm writing a web server app, which I run in ghci:

:main localhost 8000

Unfortunately, after Ctrl-C and :reload, running it again:

** Exception: bind: resource busy (Address already in use)

This is pretty annoying, because quitting-and-restarting takes a lot of
time since I have many dependencies.

How do you deal with this? Can you propose some working code that can be
wrapped around my main function to make it work?

My first idea is running main in a separate process.

If you have a working idea, please also post it as an answer on
http://stackoverflow.com/questions/15890912/how-do-i-terminate-a-socket-server-in-ghci

Thanks

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

Re: [Haskell-cafe] GSoC Project Proposal: Markdown support for Haddock

2013-04-08 Thread Niklas Hambüchen

Could you elaborate a bit on which markdown features you support (or
even better: write it into your module haddocks)?

Thinks like
- autolink detection
- ```language blocks?

Also, you build on performance-oriented libraries - it would be cool if
you could make a small benchmark comparing with the standard
C/Python/Ruby parser implementations; AFAIK there is a standard Markdown
test suite that this could run against.

Concerning the project proposal:

I especially find the last feature useful for programming documentation,
and would love to have them in a potential haddock succesor. I was also
pleasantly surprised that pandoc seems to handle all of this (even with
code syntax highlighting).

On 05/04/13 02:10, Michael Snoyman wrote:
 In case it can be useful in any way for this project, my markdown
 package[1] is certainly available for scavenging, though we'd likely
 want to refactor it to not use conduit (I can't imagine conduit being a
 good dependency for Haddock).
 
 [1] http://hackage.haskell.org/package/markdown

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

Re: [Haskell-cafe] ANN: psqueue-benchmarks - benchmarks of priority queue implementations

2013-04-06 Thread Niklas Hambüchen

On 30/03/13 06:44, Louis Wasserman wrote:
 That said, I'm not sure I follow how queuelike is a
 psqueue at all as opposed to a pqueue?

Louis,

you are actually right. I was tricked by the delete function, which
takes only the queue, not the key, so it simply pops the top - queuelike
is not a psqueue.

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

Re: [Haskell-cafe] ANN: psqueue-benchmarks - benchmarks of priority queue implementations

2013-04-06 Thread Niklas Hambüchen

@Cale, do you have a repo of fingertree-psqueue around?

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

Re: [Haskell-cafe] ANN: psqueue-benchmarks - benchmarks of priority queue implementations

Hey Scott,

I quickly tried your suggestion, plugging in foldr' from Data.Foldable 
and sprinkling a few seqs in some places, but it doesn't help the stack 
overflow.

On Fri 29 Mar 2013 16:23:55 GMT, Scott Dillard wrote:
 I do not know why it overflows. It's been a while, but isn't the
 answer usually too much laziness? Maybe try changing the foldr in
 fromList to foldr'? I would try it out quickly but do not have ghc
 installed on any computers here.

 I am happy start a repo for this library, but there is not much
 history to import so anyone else may do it. I'm not sure how hackage
 upload permissions work... I guess I just change the maintainer field
 in the .cabal file from myself to someone else...? Any volunteers?




 On Thu, Mar 28, 2013 at 11:16 PM, Kazu Yamamoto k...@iij.ad.jp
 mailto:k...@iij.ad.jp wrote:

 Hi Niklas,

  * PSQueue throws a stack space overflow if you try to put in 10
  * Ints

 A slightly different implementation is used in GHC:


 https://github.com/ghc/packages-base/blob/master/GHC/Event/PSQ.hs

 Could you test it? If this code also has the same problem, I need to
 fix it.

 --Kazu



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

Re: [Haskell-cafe] ANN: psqueue-benchmarks - benchmarks of priority queue implementations

Hey Kazu,

I added GHC's PSQ to the benchmark, the new figures are on
http://htmlpreview.github.com/?https://raw.github.com/nh2/psqueue-benchmarks/master/report.html

No, it does not stack overflow, and it seems to perform slightly better
than the other implementations; it also doesn't suffer from the toList
slowness problem as does listlike.

However, it is probably not as generally usable as it hardcodes the
priorities to be Doubles.

(So far I only benchmark really trivial things and the other functions
could be benchmarked as well.)

Niklas

On 29/03/13 06:16, Kazu Yamamoto (山本和彦) wrote:
 Hi Niklas,
 
 * PSQueue throws a stack space overflow if you try to put in 10
 * Ints
 
 A slightly different implementation is used in GHC:
 
   https://github.com/ghc/packages-base/blob/master/GHC/Event/PSQ.hs
 
 Could you test it? If this code also has the same problem, I need to
 fix it.
 
 --Kazu
 

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

Re: [Haskell-cafe] ANN: psqueue-benchmarks - benchmarks of priority queue implementations

Hey Louis,

I think that queuelike is still a nice psqueue implementation (and I
personally don't dislike the api), so may I ask two more questions:

* Do you have any clue why toList is 10 times slower than in the other
implementation? It is based on extract, and queuelike's extract is very
fast compared to the others ... that is weird.

* What could I do such that queuelike creation is not measured as
instant? Using whnf does not seem to be enough.

Thank you
Niklas

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

Re: [Haskell-cafe] [Haskell] ANN: psqueue-benchmarks - benchmarks of priority queue implementations