Re: [Haskell-cafe] Any precedent or plan for guaranteed-safe Eq and Ord instances?

[Carter Schonwald]

(replicating what i said on the ghc-devs thread)

one thing i'm confused by, and this wasn't properly addressed in the prior
threads,
is

for a type like

data Annotated t ann =  MkAnn t ann

would you consider the following unsafe?

instance Eq t => Eq ( Annotated t ann)
   (==) (MkAnn t1 _) (MkAnn t2 _ ) =  t1 == t2

instance Ord t => Ord (Annotated t ann)
  compare (MkAnn t1 _) (MkAnn t2 _) = compare t1 t2

by the rubric you've proposed these might be *BAD*, right? But theres many
cases where you're doing computation on data, and you wish to track origin,
time, etc, but these annotations are *irrelevant* for the actual values
computed... It sounds like the proposal you want would rule out such
instances!

your proposal would rule out these pretty natural Ord/Eq instances!

am i not understanding your proposal?

It seems like  you want LVish to be deterministic in the sense of "up to
equality/ordering equivalence", the computation will always yield the same
answer .

Haskell has no way of enforcing totality, and deriving a "SafeEq" via
generics is wrong, see the Annotated type example i made up, above.

If you define determinism up to the equivalence/ordering relations
provided, and assuming anyone using LVish can read the docs before using
it, is there really any real problem? are there any *real* example
computations that someone might naively do despite the warning where the
actual answer would be broken because of this?

If we had a richer type system (like say, Idris plus some totality info),
how would we enforce the safety conditions needed to make LVish truely
deterministically type safe?

cheers
-Carter


On Sun, Oct 6, 2013 at 6:54 PM, Tillmann Rendel <
ren...@informatik.uni-marburg.de> wrote:

> Hi,
>
>
> Ryan Newton wrote:
>
>> It is very hard for me to
>> see why people should be able to make their own Generic instances (that
>> might lie about the structure of the type), in Safe-Haskell.
>>
>
> I guess that lying Generics instances might arise because of software
> evolution. Let's say we start with an abstract data type of binary trees.
>
>   module Tree (Tree, node, empty, null, split) where
> data Tree a = Node (Tree a) (Tree a) | Empty
>   deriving Generics
>
> node = Node
>
> empty = Empty
>
> null Empty = True
> null _ = False
>
> split (Node a b) = (a, b)
>
> size Empty = 0
> size (Node x y) = size x + size y
>
> Note that this data type is not really abstract, because we export the
> Generics instance, so clients of this module can learn about the
> implementation of Tree. This is not a big deal, because the chosen
> implementation happens to correspond to the abstract structure of binary
> trees anyway. So I would expect that generic code will work fine. For
> example, you could use generic read and show functions to serialize trees,
> and get a reasonable data format.
>
> Now, we want to evolve our module by caching the size of trees. We do
> something like this:
>
>   module Tree (Tree, node, empty, null, split) where
> data Tree a = Tree !Int (RealTree a)
>
> data RealTree a = Node (Tree a) (Tree a) | Empty
>
> tree (Node a b) = Tree (size a + size b) t
> tree Empty = Tree 0 Empty
>
> node x y = tree (Node x y)
>
> empty = tree Empty
>
> null (Tree _ Empty) = True
> null _ = False
>
> split (Tree _ (Node a b)) = (a, b)
>
> size (Tree n _) = n
>
> Except for the Generics instance, we provide the exact same interface and
> behavior to our clients, we just traded some space for performance. But
> what Generics instance should we provide? If we just add "deriving
> Generics" to the two datatypes, we leak the change of representation to our
> clients. For example, a client that serialized a tree with a generic show
> function based on the old Tree cannot hope to deserialize it back with a
> generic read function based on the new Tree. The size information would be
> missing, and the structure would be different.
>
> If we write a Generics instance by hand, however, I guess we can make it
> present the exact same structure as the derived Generics instance for the
> old Tree. With this lying instance, the generic read function will happily
> deserialize the old data. The size will be computed on the fly, because our
> hand-written Generics instance will introduce calls to our smart
> constructors.
>
>
>   Tillmann
> __**_
> 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] lvish 1.0 -- successor to monad-par

[Carter Schonwald]

i  mean github


On Wed, Oct 2, 2013 at 3:53 PM, Carter Schonwald  wrote:

> that may or may not be a bug on the hackage server side,
>
> just brought it to duncan's attention and put a ticket for it on trac
>
> https://github.com/haskell/hackage-server/issues/119
>
>
> On Wed, Oct 2, 2013 at 1:05 PM, Ben Gamari  wrote:
>
>> Ryan Newton  writes:
>>
>> > Hi all,
>> >
>> > I'm pleased to announce the release of our new parallel-programming
>> > library, LVish:
>> >
>> > hackage.haskell.org/package/lvish
>> >
>> > It provides a "Par" monad similar to the monad-par package, but
>> generalizes
>> > the model to include data-structures other than single-assignment
>> variables
>> > (IVars).  For example, it has lock-free concurrent data structures for
>> Sets
>> > and Maps, which are constrained to only grow monotonically during a
>> given
>> > "runPar" (to retain determinism).  This is based on work described in
>> our
>> > upcoming POPL 2014 paper:
>> >
>> Do you have any aidea why the Haddocks don't yet exist. If I recall
>> correctly, under Hackage 1 the module names wouldn't be made links until
>> Haddock generation had completed. Currently the lvish modules' point to
>> non-existent URLs.
>>
>> Also, is there a publicly accessible repository where further
>> development will take place?
>>
>> Cheers,
>>
>> - Ben
>>
>>
>> ___
>> 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] lvish 1.0 -- successor to monad-par

[Carter Schonwald]

that may or may not be a bug on the hackage server side,

just brought it to duncan's attention and put a ticket for it on trac

https://github.com/haskell/hackage-server/issues/119


On Wed, Oct 2, 2013 at 1:05 PM, Ben Gamari  wrote:

> Ryan Newton  writes:
>
> > Hi all,
> >
> > I'm pleased to announce the release of our new parallel-programming
> > library, LVish:
> >
> > hackage.haskell.org/package/lvish
> >
> > It provides a "Par" monad similar to the monad-par package, but
> generalizes
> > the model to include data-structures other than single-assignment
> variables
> > (IVars).  For example, it has lock-free concurrent data structures for
> Sets
> > and Maps, which are constrained to only grow monotonically during a given
> > "runPar" (to retain determinism).  This is based on work described in our
> > upcoming POPL 2014 paper:
> >
> Do you have any aidea why the Haddocks don't yet exist. If I recall
> correctly, under Hackage 1 the module names wouldn't be made links until
> Haddock generation had completed. Currently the lvish modules' point to
> non-existent URLs.
>
> Also, is there a publicly accessible repository where further
> development will take place?
>
> Cheers,
>
> - Ben
>
>
> ___
> 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] Any precedent or plan for guaranteed-safe Eq and Ord instances?

[Carter Schonwald]

So i think we can conclude the following

1) things are not perfect currently. But it requires some huge type class
changes to have a better story

2) certain types of data types will need to be newtyped to have instances
that play nice with Ryans concurrency work. Thats ok. Theres often good
reasons for those "illegal" instances. There is no sound and COMPLETE way
to enforce having "good" instances, and thats a good thing, though having
more libs work correctly is always a good thing

3) as always, people complain about floats, when the real issue is the
current numerical type classes, which are wrong in a number of ways. I hope
to experiment with my own ideas in that direction soon. Not worth a boring
no ideas worth taking seriously cafe thread


On Wed, Oct 2, 2013 at 2:39 PM, Mike Meyer  wrote:

> On Wed, Oct 2, 2013 at 5:18 AM, Tom Ellis <
> tom-lists-haskell-cafe-2...@jaguarpaw.co.uk> wrote:
> > Are there examples where application programmers would like there so be
> some
> > f, a and b such that a == b but f a /= f b (efficiency concerns aside)?
>  I
> > can't think of any obvious ones.
>
> Yes, and we already handle it properly:
>
>  Prelude> let f = (1.0 /)
> Prelude> let (z, negz) = (0.0, -0.0)
> Prelude> z == negz
> True
> Prelude> f z /= f negz
> True
>
> This is *not* an "IEEE Floats are weird" thing. Application
> programmers want 0.0 to equal -0.0, but -Infinity to not be equal to
> Infinity.
>
> Of course, given how many "IEEE Floats are weird" things there are,
> you can reasonably consider ignoring this example.
>
>
>
> ___
> 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] Poll & plea: State of GUI & graphics libraries in Haskell

[Carter Schonwald]

Yay!
Thanks Paul! It's always good to have more folks confirm the problems are
solved than not!

Another cool direction 7.8 will allow is using the various llvm ffi
bindings from ghci!

On Wednesday, October 2, 2013, Paul Liu wrote:

> Thanks. I've just built GHC HEAD on Mac OS X Lion, and tested by
> installing libraries with --enable-shared and loading a GLFW program
> into GHCi. Using ghci -fno-ghci-sandbox, everything works great
> including closing and restarting GL window multiple times. Can't wait
> for the  official release of GHC 7.8!
>
> On Tue, Oct 1, 2013 at 12:09 PM, Carter Schonwald
>  wrote:
> > thats the linker bug.
> >
> > the glfw stuff has been tested on ghc HEAD / 7.7 by folks on
> #haskell-game
> > in recent memory. GHCI + foreign libs should work fine now (modulo thread
> > local storage related thing).
> >
> > the historical element doesn't matter any more.
> >
> > To the best of my knowledge, all such issues should be gone. Anyone who
> > cares about making sure GHCI+ gui libs play nice, PLEASE test with HEAD.
> >
> > the better this issue is properly tested (which i believe it has been),
> the
> > more we can actually prevent it from happening. This requires people to
> test
> > with HEAD GHCi now, rather than doing archaeology.
> >
> > anyone who cares, please play with GHCI in HEAD. If your lib doesn't work
> > with ghci, please report a bug. It would be a new bug because it wont' be
> > the previous reasons it hasnt' worked.
> >
> >
> > tl;dr to the best of my knowledge this issue is resolved in HEAD. Test
> HEAD.
> > Help us make sure it stays resolved by testing HEAD.
> >
> > thanks
> > -Carter
> >
> >
> >
> >
> > On Tue, Oct 1, 2013 at 1:20 PM, Paul Liu  wrote:
> >>
> >> I reported a problem with statically linked GLFW library on Mac OS X
> >> Lion in this thread:
> >>
> >> http://www.haskell.org/pipermail/haskell-cafe/2012-January/097355.html
> >>
> >> I do not know why this is broken on Mac OS X Lion, but not on Linux or
> >> Windows. There was an EnableGUI hack for GHC 7.2 (and previous
> >> versions) and OS X version before Lion, but it no longer works. So I'm
> >> not sure if it is OS X Lion, or GLFW, or GHC, or a combination of them
> >> that caused this problem.
> >>
> >> Regards,
> >> Paul Liu
> >>
> >> On Tue, Oct 1, 2013 at 7:04 AM, Carter Schonwald
> >>  wrote:
> >> > Hey simon, the two issues that have recurrently bit ghci interaction
> >> > with
> >> > foreign GUI libs are
> >> > 1) the ghci linker.  This is fixed in head by now having ghci use the
> >> > system
> >> > linker
> >> > 2) some GUI libs require thread local state, and ghci has a flag for
> >> > that
> >> > 3)  I'm not aware of anyone reporting newly broken libs wrt GUI
> bindings
> >> > when 7.6 rolled out.  The only fix that's relevant to 7.8 is the
> >> > dylinker
> >> > bit, but that would have been a problem historically too.
> >> >
> >> > I believe a number of folks in #haskell-game have recently tested
> point
> >> > one.
> >> > (Though I should ask to double check)
> >> >
> >> > At the very least, I'm not aware of hearing of such a 7.6 specific
> ghci
> >> > breakage before.
> >> >
> >> >
> >> > On Tuesday, October 1, 2013, Simon Peyton-Jones wrote:
> >> >>
> >> >> Dear GHC devs
> >> >>
> >> >>
> >> >>
> >> >> See below (in red).  I do not know the details of this, but it sounds
> >> >> like
> >> >> a pretty serious problem, and it used to work.  Is whatever-it-is
> >> >> confirmed
> >> >> fixed in 7.8?  Do we have a test that’ll trip if it breaks again?
>  (I’m
> >> >> guessing that the latter might be hard.)
> >> >>
> >> >>
> >> >>
> >> >> Thanks
> >> >>
> >> >>
> >> >>
> >> >> Simon
> >> >>
> >> >>
> >> >>
> >> >> -Original Message-
> >> >> From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On
> Behalf
> >> >> Of
> >> >> Paul Liu
> >> >> Sent: 30 September 2013 07:18
> >> >> To: Conal Elliott
> >> >> Cc: Haskell Cafe
> >> >> Subject: Re: [Haskell-ca--
> Regards,
> Paul Liu
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell

[Carter Schonwald]

i know nothing on the gui tooling front, but i do know this: the ffi
linking issues with GHCI *should* be fixed with ghc HEAD / 7.8.

If you have linking problems with GHCi HEAD, please report it ASAP. All
linking related issues that have historically plagued ghci should be
resolved, at least on platforms where theres support for dynamic linking
for ghc


On Thu, Sep 26, 2013 at 11:32 PM, Conal Elliott  wrote:

> I'm polling to see whether there are will and expertise to reboot graphics
> and GUIs work in Haskell. I miss working on functional graphics and GUIs in
> Haskell, as I've been blocked for several years (eight?) due to the absence
> of low-level foundation libraries having the following properties:
>
> * cross-platform,
> * easily buildable,
> * GHCi-friendly, and
> * OpenGL-compatible.
>
> The last several times I tried Gtk2hs, I was unable to compile it on my
> Mac. Years ago when I was able to compile, the GUIs looked and interacted
> like a Linux app, which made them awkward and upleasant to use. wxHaskell
> (whose API and visual appearance I prefered) has for years been
> incompatible with GHCi, in that the second time I open a top-level window,
> the host process (GHCi) dies abruptly. Since my GUI & graphics programs are
> often one-liners, and I tend to experiment a lot, using a full compilation
> greatly thwarts my flow. For many years, I've thought that the situation
> would eventually improve, since I'm far from the only person who wants GUIs
> or graphics from Haskell.
>
> About three years ago, I built a modern replacement of my old Pan and
> Vertigo systems (optimized high-level functional graphics in 2D and 3D),
> generating screamingly fast GPU rendering code. I'd love to share it with
> the community, but I'm unable to use it even myself.
>
> Two questions:
>
> * Am I mistaken about the current status? I.e., is there a solution for
> Haskell GUI & graphics programming that satisfies the properties I'm
> looking for (cross-platform, easily buildable, GHCi-friendly, and
> OpenGL-compatible)?
> * Are there people willing and able to fix this situation? My own
> contributions would be to test and to share high-level composable and
> efficient GUI and graphics libraries on top of a working foundation.
>
> Looking forward to replies. Thanks,
>
> -- Conal
>
> ___
> 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] Looking for numbers to support using haskell

[Carter Schonwald]

you can also look at the CUFP talks by various folks doing haskell based
businesses in the past year or several. worth watching some of them


On Thu, Sep 26, 2013 at 12:14 PM, Mike Meyer  wrote:

> The fpcomplete case studies are similar to what I'm looking for.
>
> Anyone have more of them? Maybe a blog post or comparison they've written?
>
> Thanks,
> 
>
> On Mon, Sep 23, 2013 at 5:05 PM, Eric Rasmussen 
> wrote:
>
>> Hi Nick,
>>
>> FP Complete has a lot of good resources on this topic, including some
>> case studies: https://www.fpcomplete.com/business/resources/case-studies/
>>
>> I believe part of their aim is making the business case for Haskell
>> (meaning many of the resources are geared towards management), which I
>> realize is not exactly what you asked for. But hopefully you'll find
>> something there that can help.
>>
>> Best,
>> Eric
>>
>>
>>
>> On Mon, Sep 23, 2013 at 12:13 PM, Nick Vanderweit <
>> nick.vanderw...@gmail.com> wrote:
>>
>>> I'd be interested in more studies in this space. Does anyone know of
>>> empirical studies on program robustness vs. other languages?
>>>
>>>
>>> Nick
>>>
>>> On 09/23/2013 11:31 AM, MigMit wrote:
>>> > The classical reference is, I think, the paper “Haskell vs. Ada vs.
>>> C++ vs. Awk vs. ... An Experiment in Software Prototyping Productivity”
>>> >
>>> > On Sep 23, 2013, at 9:20 PM, Mike Meyer  wrote:
>>> >
>>> >> Hi all,
>>> >>
>>> >> I'm looking for articles that provide some technical support for why
>>> Haskell rocks. Not just cheerleading, but something with a bit of real
>>> information in it - a comparison of code snippets in multiple languages, or
>>> the results of a study on programmer productivity (given all the noise and
>>> heat on the topic of type checking, surely there's a study somewhere that
>>> actually provides light as well), etc.
>>> >>
>>> >> Basically, I'd love things that would turn into an elevator pitch of
>>> "I can show you how to be X times more productive than you are using Y",
>>> and then the article provides the evidence to support that claim.
>>> >>
>>> >> Thanks,
>>> >> Mike
>>> >> ___
>>> >> Haskell-Cafe mailing list
>>> >> Haskell-Cafe@haskell.org
>>> >> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>> >
>>> > ___
>>> > Haskell-Cafe mailing list
>>> > Haskell-Cafe@haskell.org
>>> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>>> >
>>>
>>>
>>> ___
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe@haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>>
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Mystery of an Eq instance

[Carter Schonwald]

i had a longer email written out, but decided a shorter one is better.

I warmly point folks to use libs like the numbers package on hackage
http://hackage.haskell.org/packages/archive/numbers/2009.8.9/doc/html/Data-Number-BigFloat.html

it has some great alternatives to standard floats and doubles.

the big caveat, however, is all your computations will be painfully slower
by several orders of magnitude.  And sometimes thats a great tradeoff! but
sometimes it isnt.  At the end of the day, you need to understand how to do
math on the computer in a fashion that accepts that there is going to be
finite precision. there is no alternative but to work with that
understanding.

numbers on the computer have many forms. and many tradeoffs. there is no
one true single best approach.

cheers
-Carter


On Sat, Sep 21, 2013 at 10:11 PM, Mike Meyer  wrote:

> On Sat, Sep 21, 2013 at 5:28 PM, Bardur Arantsson 
> wrote:
> > On 2013-09-21 23:08, Mike Meyer wrote:
> > > Exactly. The Eq and Ord instances aren't what's broken, at least when
> > > you're dealing with numbers (NaNs are another story). That there are
> pairs
> > According to Haskell NaN *is* a number.
>
> Trying to make something whose name is "Not A Number" act like a
> number sounds broken from the start.
>
> > > Eq and Ord are just the messengers.
> > No. When we declare something an instance of Monad or Applicative (for
> > example), we expect(*) that thing to obey certain laws. Eq and Ord
> > instances for Float/Double do *not* obey the expected laws.
>
> I just went back through the thread, and the only examples I could
> find where that happened (as opposed to where floating point
> calculations or literals resulted in unexpected values) was with
> NaNs. Just out of curiosity, do you know of any that don't involve
> NaNs?
>
> Float violates the expected behavior of instances of - well, pretty
> much everything it's an instance of. Even if you restrict yourself to
> working with integer values that can be represented as floats.  If
> we're going to start removing it as an instance for violating instance
> expectations, we might as well take it out of the numeric stack (or
> the language) completely.
>
> 
>
> ___
> 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] PSA: do not install xcode 5 if you are using ghc 7.6

[Carter Schonwald]

glad to help.

an alternative for the discerning power user is to install a recent version
of gcc locally (eg 4.8), and build 7.6.3 with that! (or just repoint your
ghc settings file to a locally built version of real gcc.)

yes, assuming we have the time (after all, it's all volunteer time), that
is the plan.


On Fri, Sep 20, 2013 at 1:50 PM, Adam Foltzer  wrote:

> Hi Carter,
>
> Thanks for this heads up! Many of us here are cutting edge Mac users, and
> would have been bitten by this.
>
> Darin and I plan to spend some time next month preparing an unofficial
>> patched version of ghc 7.6 that should play nice with clang / xcode 5,
>> though at such a time ghc 7.8 will be in RC status at the very least.
>
>
> Can this be backported to the 7.6.3 tag and released as 7.6.4? It would be
> nice to not have to choose between running the latest xcode and the ability
> to test multiple GHC versions.
>
> Cheers,
> Adam
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] OS X ghci problem

[Carter Schonwald]

The ghci bug goes away when you use a ghc head snapshot from late summer?
Great!


On Wednesday, September 18, 2013, Jan-Philip Loos wrote:

> Sadly I was not able to use your build directly, because ghc(i)
> searched libs in a invalid path (it seems to be wired to one of your
> directories). I tried to build this ghc version from source on my own,
> without success beyond stage 1. This [1] is related to the build
> failure. I tried new alex and happy versions, without any change. A
> naive approach was to compile alex/happy with ghc_stage1 compiler,
> without success (as I expected due missing TH). I tried several ghc
> versions for bootstrapping and alex/happy rebuilding (i guess ghc >
> 7.6 is necessary for a valid 7.7 alex/happy build with the new Bool
> primops), without success too.
>
> Finally I ended in a fully self build ghc 7.7.20130730 ([2]) and with
> this ghc I can confirm that this specific error with
> Binding.GLFW.c'glfwInit is gone :) Thanks
>
> [1] http://www.mail-archive.com/ghc-devs@haskell.org/msg02357.html
> [2]
> http://darcs.haskell.org/ghcBuilder/uploads/tn23/ghc-7.7.20130730-src.tar.bz2
>
> On Mon, Sep 16, 2013 at 2:52 PM, Christiaan Baaij
> > wrote:
> > Here's a binary dist of my build:
> https://www.dropbox.com/s/d37rij0dnvjiqqy/ghc-7.7.20130915-x86_64-apple-darwin.tar.bz2
> > In case someone wants to confirm my findings.
> >
> > Cheers,
> >
> > Christiaan
> >
> > On Sep 16, 2013, at 2:24 PM, Christiaan Baaij <
> christiaan.ba...@gmail.com > wrote:
> >
> >> Hi,
> >>
> >> I saw the same issue/crash on my machine using ghc 7.6.3.
> >>
> >> I just build a "perf" build of GHC-head with
> >> "85a9e2468dc74b9e5ccde0dd61be86219fd323a2" as the latest commit.
> >>
> >> Now running, I get:
> >> 1) > cabal install bindings-glfw
> >> 2) > ghci
> >> 3) ghci> :m Bindings.GLFW
> >> 4) ghci> Bindings.GLFW.c'glfwInit
> >> 5) ghci> 1
> >>
> >> And doing:
> >> 1.) > cabal install GLFW-b
> >> 2.) > ghci -package GLFW-b
> >> 3.) ghci> import Graphics.UI.GLFW as GLFW
> >> 4.) ghci> GLFW.init
> >> 5.) ghci> True
> >>
> >> My platform:
> >> - OSX 10.8.4
> >> - ghc(i) 7.7.20130915
> >> - cabal 1.18.0.1 (using 1.18.0 of the Cabal library)
> >> - xcode cltools 4.6.2
> >>
> >> So it seems that the new ghci linking infrastructure fixes things
> >>
> >> Cheers,
> >>
> >> Christiaan
> >>
> >> On Sep 14, 2013, at 9:00 PM, Jan-Philip Loos 
> >> >
> wrote:
> >>
>  What I do for GLFW is use a dylib, then you don't rely on GHCi's
> static-ish linker.
>  The only wrinkle is figuring out where you want the dylib.
>  I think homebrew will put one in /usr/local/lib, which works out
> nicely, but they don't have GLFW 3 yet.
>  Another option is to build the dylib yourself from the GLFW source
> bundled with the GLFW-b package, then tell cabal where to find it.
> >>>
> >>> Hi,
> >>> for me the problem relocates now to the "bindings-glfw" package, since
> >>> the native bindings moved to this package and are wrapped up with
> >>> "glfw-b".
> >>>
> >>> My way to the same exception already mentioned by Brian Lewis:
> >>> 1) > cabal install bindings-glfw
> >>> 2) > ghci
> >>> 3) ghci> :m Bindings.GLFW
> >>> 4) ghci> Bindings.GLFW.c'glfwInit
> >>> 5) ghci terminates with exception: *** Terminating app due to uncaught
> >>> exception 'NSInvalidArgumentException', reason: '-[NSAutoreleasePool
> >>> init]: unrecognized selector sent to instance 0x7fc443c01b30'
> >>>
> >>> Anthony Cowley mentioned to use ghci with GLFW as a dylib, I have no
> >>> clue how to do this. I built the according glfw version on my own as a
> >>> dylib and loaded ghci with it explicitly, this didn't help. I guess
> >>> the compiled bindings-glfw is already statically packed up.
> >>>
> >>> How can I get ghci to use the native glfw dylib in combination with
> >>> bindings-glfw? If I have to compile bindings-glfw with different
> >>> settings, which settings? I have some oversight over haskell but no
> >>> really deep knowledge according to bindings and lib-loading of ghci,
> >>> but I'm willing to learn it ;)
> >>>
> >>> My Platform:
> >>> - OSX 10.8.5
> >>> - ghc(i) 7.6.3
> >>> - cabal 1.18.0.1
> >>> - xcode dev tools 4.6.3
> >>>
> >>> Thanks and Greetings
> >>>
> >>> Jan
> >>> ___
> >>> Haskell-Cafe mailing list
> >>> Haskell-Cafe@haskell.org 
> >>> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >>
> >
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] PSA: do not install xcode 5 if you are using ghc 7.6

[Carter Schonwald]

Hey everyone,

if you are actively using ghc 7.6 on your mac,
for now please do not install xcode 5.

It will break your ghc install, because 7.6 doesn't  know how to correctly
use Clang for the CPP work. (ghc head / and thus 7.8 will work fine with
xcode 5, thanks to some outstanding work by Austin Seipp, 7.6 does not)

if you do not need xcode 5, and you're actively using ghc 7.6, stay with
xcode 4.6 for now.

if you installed xcode 5 because its there, and now your ghc 7.6 is
occasionally giving you strange errors involving CPP parse failures on
fragments  like "#-}", you should go to the apple developers website,
download, and reinstall the xcode 4.6 CLI tools.


if you need both xcode 5 and ghc in working order *right now, tomorrow*,
either

a) live on the wildside: test out using ghc head: also means you could play
with ghc-ios too!

b) if you need both in working order now, and stabilish, Darin Morrison has
a set of mac-homebrew taps that should be you use
 https://github.com/darinmorrison/homebrew-haskell
these taps should be regarded as more "official" and "canonical" than the
formula's that brew provides (the normal brew ones recurrently have
problems induced by folks who aren't haskell devs)

c) wait  a wee bit till 7.8 lands in all its glory, and have both the
freshest of xcodes, and the newest of  awesome ghcs

tl;dr

if you don't  need xcode 5, having xcode 4.6 CLI tools installed will stand
you in good stead.

if you are on os x mavericks, or absolutely need xcode 5 installed, and you
want a ghc thats already released, use darin's brew formulae
https://github.com/darinmorrison/homebrew-haskell


Darin and I plan to spend some time next month preparing an unofficial
patched version of ghc 7.6 that should play nice with clang / xcode 5,
though at such a time ghc 7.8 will be in RC status at the very least.


cheers

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

Re: [Haskell-cafe] OS X ghci problem

[Carter Schonwald]

Christian,
Yes, ghc 7.7/7.8 *should* fix all the ghci linker related problems on
platforms that support dynamic linking!

If (or anyone else) finds problems with the ghci linker on 7.7, please
report them post haste!

I'm also glad to hear that someone's finally tested out the new ghci
functionality properly!

-Carter


On Mon, Sep 16, 2013 at 8:52 AM, Christiaan Baaij <
christiaan.ba...@gmail.com> wrote:

> Here's a binary dist of my build:
> https://www.dropbox.com/s/d37rij0dnvjiqqy/ghc-7.7.20130915-x86_64-apple-darwin.tar.bz2
> In case someone wants to confirm my findings.
>
> Cheers,
>
> Christiaan
>
> On Sep 16, 2013, at 2:24 PM, Christiaan Baaij 
> wrote:
>
> > Hi,
> >
> > I saw the same issue/crash on my machine using ghc 7.6.3.
> >
> > I just build a "perf" build of GHC-head with
> > "85a9e2468dc74b9e5ccde0dd61be86219fd323a2" as the latest commit.
> >
> > Now running, I get:
> > 1) > cabal install bindings-glfw
> > 2) > ghci
> > 3) ghci> :m Bindings.GLFW
> > 4) ghci> Bindings.GLFW.c'glfwInit
> > 5) ghci> 1
> >
> > And doing:
> > 1.) > cabal install GLFW-b
> > 2.) > ghci -package GLFW-b
> > 3.) ghci> import Graphics.UI.GLFW as GLFW
> > 4.) ghci> GLFW.init
> > 5.) ghci> True
> >
> > My platform:
> > - OSX 10.8.4
> > - ghc(i) 7.7.20130915
> > - cabal 1.18.0.1 (using 1.18.0 of the Cabal library)
> > - xcode cltools 4.6.2
> >
> > So it seems that the new ghci linking infrastructure fixes things
> >
> > Cheers,
> >
> > Christiaan
> >
> > On Sep 14, 2013, at 9:00 PM, Jan-Philip Loos  wrote:
> >
> >>> What I do for GLFW is use a dylib, then you don't rely on GHCi's
> static-ish linker.
> >>> The only wrinkle is figuring out where you want the dylib.
> >>> I think homebrew will put one in /usr/local/lib, which works out
> nicely, but they don't have GLFW 3 yet.
> >>> Another option is to build the dylib yourself from the GLFW source
> bundled with the GLFW-b package, then tell cabal where to find it.
> >>
> >> Hi,
> >> for me the problem relocates now to the "bindings-glfw" package, since
> >> the native bindings moved to this package and are wrapped up with
> >> "glfw-b".
> >>
> >> My way to the same exception already mentioned by Brian Lewis:
> >> 1) > cabal install bindings-glfw
> >> 2) > ghci
> >> 3) ghci> :m Bindings.GLFW
> >> 4) ghci> Bindings.GLFW.c'glfwInit
> >> 5) ghci terminates with exception: *** Terminating app due to uncaught
> >> exception 'NSInvalidArgumentException', reason: '-[NSAutoreleasePool
> >> init]: unrecognized selector sent to instance 0x7fc443c01b30'
> >>
> >> Anthony Cowley mentioned to use ghci with GLFW as a dylib, I have no
> >> clue how to do this. I built the according glfw version on my own as a
> >> dylib and loaded ghci with it explicitly, this didn't help. I guess
> >> the compiled bindings-glfw is already statically packed up.
> >>
> >> How can I get ghci to use the native glfw dylib in combination with
> >> bindings-glfw? If I have to compile bindings-glfw with different
> >> settings, which settings? I have some oversight over haskell but no
> >> really deep knowledge according to bindings and lib-loading of ghci,
> >> but I'm willing to learn it ;)
> >>
> >> My Platform:
> >> - OSX 10.8.5
> >> - ghc(i) 7.6.3
> >> - cabal 1.18.0.1
> >> - xcode dev tools 4.6.3
> >>
> >> Thanks and Greetings
> >>
> >> Jan
> >> ___
> >> Haskell-Cafe mailing list
> >> Haskell-Cafe@haskell.org
> >> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] An APL library for Haskell

[Carter Schonwald]

Hey All,

As Dan Peebles remarks, Repa and similar libs give a great haskelly
vocabulary for this. Indeed, most of the examples in the wiki page are very
much expressible with the REPA data model.

I'd like to take this opportunity note that I'll be releasing a prototype
library for numerical arrays / numerical computation / etc that draws from
Repa and adds some ideas i've developed over the past year, later this
month. (yes and the core stuff will be bsd3)

barring irresolvable design flaws, i'm very much committed to building
tools in this space that hopefully can see widespread adoption (and use) by
the community.

I'm pretty buried with some other matters for the next week or so, but I
hope to get that preview out at the end of the month. stay tuned ;)
-Carter






On Sun, Sep 15, 2013 at 9:57 PM, Daniel Peebles wrote:

> Interesting idea. It seems like building this on top of REPA would save a
> lot of work, since it has a native notion of "rank" encoded in the type
> system. I'd then see the APL-like combinators as a "niche" API for REPA,
> rather than as a library of their own. And of course, you'd get
> parallelization for free, more or less. I think some of the combinators on
> that wiki page already have counterparts in the REPA API.
>
>
>
>
> On Thu, Mar 8, 2012 at 8:44 AM, Simon Peyton-Jones 
> wrote:
>
>>  Friends
>>
>> ** **
>>
>> Many of you will know the array language 
>> APL.
>> It focuses on arrays and in particular has a rich, carefully-thought-out
>> array algebra. 
>>
>> ** **
>>
>> An obvious idea is: *what would a Haskell library that embodies APL’s
>> array algebra look like*?  In conversation with John Scholes and some of
>> his colleagues in the APL community a group of us developed some ideas for
>> a possible API, which you can find on the Haskell wiki here:
>> http://www.haskell.org/haskellwiki/APL
>>
>> ** **
>>
>> However, we have all gone our separate ways, and I think it’s entirely
>> possible that that the idea will go no further.  So this message is to ask:
>> 
>>
>> **· **Is anyone interested in an APL-style array library in
>> Haskell?
>>
>> **· **If so, would you like to lead the process of developing
>> the API?
>>
>> ** **
>>
>> I think there are quite a few people who would be willing to contribute,
>> including some core gurus from the APL community: John Scholes,  Arthur
>> Whitney, and Roger Hui.   
>>
>> ** **
>>
>> Simon
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Bytestring map/zipWith rationale

[Carter Schonwald]

Scott: benchmark the two and you'll see why we have both :-)

On Thursday, September 12, 2013, Scott Lawrence wrote:

> On Thu, 12 Sep 2013, Tom Ellis wrote:
>
>  On Thu, Sep 12, 2013 at 09:21:20AM -0400, Scott Lawrence wrote:
>>
>>> Something's always bothered me about map and zipWith for ByteString. Why
>>> is it
>>>
>>> map :: (Word8 -> Word8) -> ByteString -> ByteString
>>>
>>> but
>>>
>>> zipWith :: (Word8 -> Word8 -> a) -> ByteString -> ByteString -> [a]
>>>
>>
>> Well, what if you wanted to zipWith a function of type "Word8 -> Word8 ->
>> Foo" instead of "Word8 -> Word8 -> Word8"?
>>
>
> Then I would do what I do with map, and call `unpack` first.
>
> Either of the two options is usable:
>
>  map :: (Word8 -> Word8) -> ByteString -> ByteString
>  zipWith :: (Word8 -> Word8 -> Word8) -> ByteString -> ByteString ->
> ByteString
>(or)
>  map :: (Word8 -> a) -> ByteString -> [a]
>  zipWith :: (Word8 -> Word8 -> a) -> ByteString -> ByteString -> [a]
>
> I just don't understand why we have one from each.
>
> --
> Scott Lawrence
> __**_
> 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] GLFW not working in Cabal 1.18

[Carter Schonwald]

the work around i did for cabal 1.18 compatibility for llvm-base can be
found here:

https://github.com/bos/llvm/blob/master/base/Setup.hs#L116-L144
this used the fact that cabal exposes the cabal version as a library value
to generate a correct wrapper for either API version

alternatively, you can change your setup.hs so that api isn't needed.

also: before emailing cafe, its always good to email the listed maintainers
first! (i've included them on CC for this email)



On Tue, Sep 10, 2013 at 9:27 PM, Thiago Negri  wrote:

> The package GLFW is not building in Cabal 1.18.
>
> Setup.hs [1] depends on `rawSystemStdInOut` [2] that changed signature
> between 1.16 and 1.18.
>
> Is this considered a public API of Cabal?
>
>
> Cabal 1.16
> rawSystemStdInOut
>  :: Verbosity
>  -> FilePath
>  -> [String]
>  -> Maybe (String, Bool)
>  -> Bool
>  -> IO (String, String, ExitCode)
>
>
> Cabal 1.18
> rawSystemStdInOut
>  :: Verbosity
>  -> FilePath
>  -> [String]
>  -> Maybe FilePath -- new arg
>  -> Maybe [(String, String)] -- new arg
>  -> Maybe (String, Bool)
>  -> Bool
>  -> IO (String, String, ExitCode)
>
>
>
> Compilation output:
>
> [1 of 1] Compiling Main (
> /tmp/GLFW-0.5.1.0-4035/GLFW-0.5.1.0/Setup.hs,
> /tmp/GLFW-0.5.1.0-4035/GLFW-0.5.1.0/dist/setup/Main.o )
>
> /tmp/GLFW-0.5.1.0-4035/GLFW-0.5.1.0/Setup.hs:167:33:
> Couldn't match expected type `IO (t0, t1, ExitCode)'
> with actual type `Maybe (String, Bool)
>   -> Bool -> IO (String, String, ExitCode)'
> In the return type of a call of `rawSystemStdInOut'
> Probable cause: `rawSystemStdInOut' is applied to too few arguments
> In a stmt of a 'do' block:
>   (out, err, exitCode) <- rawSystemStdInOut
> verbosity "cc" (["-c", path, "-o",
> objPath] ++ flags) Nothing False
> In the expression:
>   do { hClose outHandle;
>hPutStr inHandle contents;
>hClose inHandle;
>(out, err, exitCode) <- rawSystemStdInOut
>  verbosity "cc" (["-c", path, ] ++
> flags) Nothing False;
> }
>
> /tmp/GLFW-0.5.1.0-4035/GLFW-0.5.1.0/Setup.hs:167:113:
> Couldn't match expected type `Maybe [(String, String)]'
> with actual type `Bool'
> In the fifth argument of `rawSystemStdInOut', namely `False'
> In a stmt of a 'do' block:
>   (out, err, exitCode) <- rawSystemStdInOut
> verbosity "cc" (["-c", path, "-o",
> objPath] ++ flags) Nothing False
> In the expression:
>   do { hClose outHandle;
>hPutStr inHandle contents;
>hClose inHandle;
>(out, err, exitCode) <- rawSystemStdInOut
>  verbosity "cc" (["-c", path, ] ++
> flags) Nothing False;
> }
> Failed to install GLFW-0.5.1.0
>
>
> [1] http://code.haskell.org/GLFW/Setup.hs
> [2]
> https://github.com/haskell/cabal/blob/d16c307c33fb7af19d8f17a2ad8be4902a3af21e/Cabal/Distribution/Simple/Utils.hs#L454
>
>
> ___
> 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] GHC API question: Getting access to cpp processed source

[Carter Schonwald]

you need to run a preprocessor on it to remove the directives


On Tue, Sep 10, 2013 at 4:03 PM, AlanKim Zimmerman wrote:

> Hi Cafe
>
> I have just discovered that GHC.getTokenStream fails if it is used on a
> module with CPP directives in it.
>
> This is reported in http://ghc.haskell.org/trac/ghc/ticket/8265
>
> Is there an easy way to get access to the pre-processed source, without
> having to explicitly write it to an output file in a temporary location?
>
> In other words an equivalent to getModuleSourceAndFlags that does the
> right thing.
>
> This currently prevents HaRe from processing files with preprocessor
> directives in them, I would like to come up with a workaround for current
> GHC versions, rather than having to wait for a future one.
>
> Regards
>   Alan
>
> ___
> 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] Reasoning about performance

[Carter Schonwald]

Awesome/ thanks for sharing.  It's worth noting that criterion is also
pretty great for microbenchmarks too. On my machine I get pretty good
timing accuracy on anything that takes more than 20 nanoseconds.

On Wednesday, September 4, 2013, Scott Pakin wrote:

> On 09/03/2013 06:02 PM, Carter Schonwald wrote:
>
>> It's also worth adding that ghci does a lot less optimization than ghc.
>>
>
> Yes, I discovered that before I posted.  Note from my initial message
> that I used ghc to compile, then loaded the compiled module into ghci:
>
>  Prelude> :!ghc -c -O2 allpairs.hs
>  Prelude> :load allpairs
>  Ok, modules loaded: AllPairs.
>  Prelude AllPairs> :m +Control.DeepSeq
>  Prelude Control.DeepSeq AllPairs> :show modules
>  AllPairs ( allpairs.hs, allpairs.o )
>
>  Likewise, the best tool for doing performance benchmarking is the
>> excellent Criterion library.
>>
>
> Ah, I didn't know about Criterion; that does look useful.  For the
> record, here's what Criterion reports for my three all-pairs
> implementations:
>
> Prelude Criterion.Main AllPairs> defaultMain [bench "allPairs1" $ nf
> allPairs1 [1..1]]
>  ...
> mean: 5.184160 s, lb 5.156169 s, ub 5.212516 s, ci 0.950
> std dev: 144.4938 ms, lb 127.3414 ms, ub 164.8774 ms, ci 0.950
>
> Prelude Criterion.Main AllPairs> defaultMain [bench "allPairs2" $ nf
> allPairs2 [1..1]]
>  ...
> mean: 2.310527 s, lb 2.290451 s, ub 2.329349 s, ci 0.950
>
> Prelude Criterion.Main AllPairs> defaultMain [bench "allPairs3" $ nf
> allPairs3 [1..1]]
>  ...
> mean: 10.05609 s, lb 10.02453 s, ub 10.08866 s, ci 0.950
>
> As before, allPairs2 is the fastest, followed by allPairs1, with
> allPairs3 in last place.
>
> -- Scott
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Reasoning about performance

[Carter Schonwald]

It's also worth adding that ghci does a lot less optimization than ghc.
Likewise, the best tool for doing performance benchmarking is the excellent
Criterion library.

To repeat: use compiled code for benchmarking, and use criterion.  Ghci is
not as performance tuned as compiled code, except when ghci is linking in
code that's already been compiled

On Tuesday, September 3, 2013, Bob Ippolito wrote:

> Haskell's non-strict evaluation can often lead to unexpected results when
> doing tail recursion if you're used to strict functional programming
> languages. In order to get the desired behavior you will need to force the
> accumulator (with something like Data.List's foldl', $!,
> seq, BangPatterns, etc.).
>
> One issue with the tail recursive version is that you're basically
> sequencing it twice, forcing the result is going to force the whole spine
> of the list, and then you're walking it again with deepseq. The overhead of
> the deepseq call with that size list on my machine is 2.2 seconds, so
> you're basically paying that cost twice with a tail recursive version.
> allPairs2 only forces what is needed, so deepseq isn't traversing any data
> structures that are already forced.
>
> I think what's happening with allPairs2 is that GHC is throwing away the
> the list during the traversal since the result of the computation isn't
> used at all. I get very different timings (still fast, but no longer orders
> of magnitude difference) for allPairs2 if the result is still around. You
> could probably figure this out with the heap profiler.
>
> h> deepseq (allPairs2 [1..1]) True
> True
> (2.47 secs, 4403724176 bytes)
> h> let x = allPairs2 [1..1]
> (0.00 secs, 510488 bytes)
> h> deepseq x True
> True
> (10.47 secs, 4401625192 bytes)
> h> deepseq x True
> True
> (2.21 secs, 1031864 bytes)
>
> I'm no expert, but I think that allPairs2 is likely as good as you're
> going to get with straightforward Haskell using lists. It doesn't build up
> a lot of unevaluated computation, and if you only need to see the first n
> elements it's not going to have to process the entire input. allPairs1 has
> most of the good properties of allPairs2 but is a bit worse because of the
> concatenation, though concatenating in this way isn't a disaster like it
> would be in a strict functional programming language.
>
> -bob
>
>
>
> On Tue, Sep 3, 2013 at 3:28 PM, Scott Pakin  'cvml', 'pa...@lanl.gov');>
> > wrote:
>
>> I'm a Haskell beginner, and I'm baffled trying to reason about code
>> performance, at least with GHC.  For a program I'm writing I needed to
>> find all pairs of elements of a list.  That is, given the list "ABCD"
>> I wanted to wind up with the list
>> [('A','B'),('A','C'),('A','D')**,('B','C'),('B','D'),('C','D')**], where
>> the order of elements in the resulting list is immaterial, but I don't
>> want both ('A', 'B') and ('B', 'A'), for example.
>>
>> My first attempt looked like this:
>>
>> allPairs1 :: [a] -> [(a, a)]
>> allPairs1 [] = []
>> allPairs1 (x:xs) = map (\a  -> (x, a)) xs ++ allPairs1 xs
>>
>> Benchmarking with ghci's ":set +s" reveals the following performance
>> (median of three runs shown):
>>
>> $ ghci
>> GHCi, version 7.6.3: http://www.haskell.org/ghc/  :? for help
>> Loading package ghc-prim ... linking ... done.
>> Loading package integer-gmp ... linking ... done.
>> Loading package base ... linking ... done.
>> Prelude> :!ghc -c -O2 allpairs.hs
>> Prelude> :load allpairs
>> Ok, modules loaded: AllPairs.
>> Prelude AllPairs> :m +Control.DeepSeq
>> Prelude Control.DeepSeq AllPairs> :show modules
>> AllPairs ( allpairs.hs, allpairs.o )
>> Prelude Control.DeepSeq AllPairs> :set +s
>> Prelude Control.DeepSeq AllPairs> deepseq (allPairs1 [1..1]) True
>> True
>> (4.85 secs, 4004173984 bytes)
>>
>> A colleague suggested getting rid of the list append as follows:
>>
>> allPairs2 :: [a] -> [(a, a)]
>> allPairs2 [] = []
>> allPairs2 (x:xs) = allPairs2' x xs xs
>>   where allPairs2' x [] [] = []
>> allPairs2' x (y:ys) zs = (x,y) : allPairs2' x ys zs
>> allPairs2' x [] (z:zs) = allPairs2' z zs zs
>>
>> Not surprisingly, that runs faster:
>>
>> Prelude Control.DeepSeq AllPairs> deepseq (allPairs2 [1..1]) True
>> True
>> (2.14 secs, 4403686376 bytes)
>>
>> I then figured I could do even better by rewriting the code
>> tail-recursively:
>>
>> allPairs3 :: [a] -> [(a, a)]
>> allPairs3 [] = []
>> allPairs3 (x:xs) = allPairs3' x xs xs []
>>   where allPairs3' :: a -> [a] -> [a] -> [(a, a)] -> [(a, a)]
>> allPairs3' h (x:xs) ys result = allPairs3' h xs ys ((h,
>> x):result)
>> allPairs3' _ [] (y:ys) result = allPairs3' y ys ys result
>> allPairs3' _ [] [] result = result
>>
>> This takes half the memory as the above (yay!) but runs substantially
>> *slower* (and appears to be thrashin

Re: [Haskell-cafe] function arithmetic?

[Carter Schonwald]

To clarify in Bobs remark : while you're still learning Haskell and the
type system , things like lifted Num on functions can lead to some
potentially confusing type errors.

That said, it's absolutely doable, and can be a very nice / powerful tool
when used appropriately.

On Sunday, September 1, 2013, Bob Ippolito wrote:

> Yes, you can do that, but you probably shouldn't.
>
> See also:
> http://www.haskell.org/haskellwiki/Num_instance_for_functions
> http://hackage.haskell.org/package/applicative-numbers
>
>
>
> On Sat, Aug 31, 2013 at 10:01 PM, Christopher Howard <
> christopher.how...@frigidcode.com  'christopher.how...@frigidcode.com');>> wrote:
>
>> Hi. I was just curious about something. In one of my math textbooks I see
>> expressions like this
>>
>> f + g
>>
>> or
>>
>> (f + g)(a)
>>
>> where f and g are functions. What is meant is
>>
>> f(a) + g(a)
>>
>> Is there a way in Haskell you can make use of syntax like that (i.e.,
>> expressions like f + g and f * g to create a new function), perhaps by
>> loading a module or something?
>>
>> __**_
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org > '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

[Carter Schonwald]

Is there an up todate copy of the haddock manual online anywhere?

On Saturday, August 31, 2013, Omari Norman wrote:

>
> On Thu, Aug 29, 2013 at 9:30 PM, Mateusz Kowalczyk <
> fuuze...@fuuzetsu.co.uk  'fuuze...@fuuzetsu.co.uk');>> 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.
>>
>>
> This is a little off-topic, but the Haddock website apparently is years
> out of date.
>
> http://www.haskell.org/haddock/
>
> says the latest version is 2.8.0 released in September 2010, but
> apparently I have 2.13.2 on my machine.
>
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compiler stops at SpecConstr optimization

[Carter Schonwald]

This is a known GHC bug that (i believe?) is fixed in head. Links to the
relevant tickets from when I hit this problem trying to build lambdabot are
here https://github.com/mokus0/random-fu/issues/13

The work around is to build those libraries with -O1


On Thu, Aug 29, 2013 at 1:00 PM, Manuel Gómez  wrote:

> On Thu, Aug 29, 2013 at 12:08 PM, Daniel Díaz Casanueva
>  wrote:
> > Since this problem can be OS-dependent, my system is Debian 7 and I
> didn't
> > try yet to reproduce my problem in other systems (mainly because I don't
> > have access to other systems at the moment).
>
> FWIW, it’s not just you — I can reproduce this on 7.4.2 (vector-0.10.0.1).
>
> > $ uname -a
> > Linux lechuza 2.6.38-13-generic #57-Ubuntu SMP Mon Mar 5 18:10:14 UTC
> 2012 i686 i686 i386 GNU/Linux
>
> ___
> 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] Categories with associated constraints?

[Carter Schonwald]

I've not seen such, Mike Izbicki has something related for most of the
other standard classes (though i've not looked closely at it myself)

http://hackage.haskell.org/package/ConstraintKinds-1.1.0.0


On Mon, Aug 19, 2013 at 6:45 PM, Conal Elliott  wrote:

> Has anyone given a go at a Category class and friends (including cartesian
> and closed) with associated constraints (presumably using the
> ConstraintKinds language extension)? I gave it a try a while back and
> wasn't able to keep the signatures from getting very complicated.
>
> Thanks,   -- Conal
>
> ___
> 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] MongoDB single insertions super slow

[Carter Schonwald]

Have you contacted the maintainer? I believe that the Haskell mongodb
driver is maintained by someone at 10gen? (Or at least at some point was )

Without spending time looking at the mongo driver, it's hard to know.
On Aug 18, 2013 3:58 PM, "Kyle Hanson"  wrote:

> I am trying to write a simple benchmark of testing 1000 single inserts in
> mongodb, but doing single insertions is super slow. It takes nearly 40
> seconds to perform these operations with the haskell mongodb driver, but
> under a second to perform the same number of operations of single inserts
> in python.
>
> Here are the two files I am working with:
>
> https://gist.github.com/hansonkd/6263648
>
> I checked the BSON serialization, and writing it to a socket instead of
> mongodb driver, makes the script run in under a second so the problem seems
> to be with the mongodb driver.
>
> Any insights would be appreciated.
>
> --
> Kyle Hanson
>
>
> ___
> 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] llvm on macos

[Carter Schonwald]

Huh.  I thought the 3.3 llvm problems only happened when building ghc.
 Oops.  Your absolutely right.  Ghc < 7.7 does not generate in general, IR
that llvm >= 3.3 will be happy with.

On Thursday, August 15, 2013, Ozgur Akgun wrote:

> Hi.
>
> On 15 August 2013 20:35, Carter Schonwald 
>  'carter.schonw...@gmail.com');>
> > wrote:
>
>> Just brew install llvm should work fine.
>>
>
> I wonder what makes you think this is the case.
>
> At this moment in time, `brew install llvm` will install llvm-3.3.
> Using llvm-3.3, I get warnings and errors. Using llvm-3.2, I get warnings
> but I never got any errors. This is not to say that they cannot happen on
> other packages.
>
> I've just uninstalled 3.2, installed 3.3, and tried to compile a project
> of mine. One of its dependencies, data-default-class, failed to compile.
> The following is what happened on my computer.
>
> Hope this helps,
> Ozgur.
>
>
> $ ghc --version
> The Glorious Glasgow Haskell Compilation System, version 7.6.3
> $ cabal --version
> cabal-install version 1.16.0.2
> using version 1.16.0 of the Cabal library
> $ cabal install --force-reinstalls --disable-documentation
> --disable-library-profiling --disable-executable-profiling
>  --ghc-options="-fllvm" data-default-class
> Resolving dependencies...
> Configuring data-default-class-0.0.1...
> Building data-default-class-0.0.1...
> Preprocessing library data-default-class-0.0.1...
> [1 of 1] Compiling Data.Default.Class ( Data/Default/Class.hs,
> dist/build/Data/Default/Class.o )
> You are using a new version of LLVM that hasn't been tested yet!
> We will try though...
> wrong initalizer for intrinsic global variable
> [0 x i8*] undef
> Broken module found, compilation aborted!
> 0  libLLVM-3.3.dylib 0x00010223faee
> llvm::sys::PrintStackTrace(__sFILE*) + 40
> 1  libLLVM-3.3.dylib 0x00010223fef5 SignalHandler(int) + 241
> 2  libsystem_c.dylib 0x7fff8601f94a _sigtramp + 26
> 3  libsystem_c.dylib 0x000102a10a00 _sigtramp + 2090799312
> 4  libLLVM-3.3.dylib 0x00010223fd6d abort + 22
> 5  libLLVM-3.3.dylib 0x000101f08466 (anonymous
> namespace)::Verifier::abortIfBroken() + 236
> 6  libLLVM-3.3.dylib 0x000101f07b97 (anonymous
> namespace)::Verifier::doFinalization(llvm::Module&) + 3477
> 7  libLLVM-3.3.dylib 0x000101ef63a4
> llvm::FPPassManager::doFinalization(llvm::Module&) + 56
> 8  libLLVM-3.3.dylib 0x000101ef5e52
> llvm::FunctionPassManagerImpl::doFinalization(llvm::Module&) + 62
> 9  libLLVM-3.3.dylib 0x000101ef5d43
> llvm::FunctionPassManager::doFinalization() + 21
> 10 opt   0x000101be19aa
> std::vector llvm::SuccIterator >,
> std::allocator llvm::SuccIterator > >
> >::_M_insert_aux(__gnu_cxx::__normal_iterator llvm::SuccIterator >*,
> std::vector llvm::SuccIterator >,
> std::allocator llvm::SuccIterator > > > >,
> std::pair llvm::BasicBlock> > const&) + 6988
> 11 libdyld.dylib 0x7fff8959c7e1 start + 0
> 12 libdyld.dylib 0x0006 start + 1990604837
> Stack dump:
> 0. Program arguments: opt
> /var/folders/h5/3mmbxydn5qs3w9f3j6mgmhscgn/T/ghc11789_0/ghc11789_0.ll
> -o
> /var/folders/h5/3mmbxydn5qs3w9f3j6mgmhscgn/T/ghc11789_0/ghc11789_0.bc
> -O1 --enable-tbaa=true
> llc:
> /var/folders/h5/3mmbxydn5qs3w9f3j6mgmhscgn/T/ghc11789_0/ghc11789_0.bc:
> error: Could not open input file: No such file or directory
> Failed to install data-default-class-0.0.1
> cabal: Error: some packages failed to install:
> data-default-class-0.0.1 failed during the building phase. The exception
> was:
> ExitFailure 1
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] llvm on macos

[Carter Schonwald]

Just brew install llvm should work fine.

The version warning is just the ghc devs beig conservative about what they
are committing to supporting given finite resources and llvm changing over
time.

On Thursday, August 15, 2013, Anton Nikishaev wrote:

> Ozgur Akgun > writes:
>
> > Hi.
> >
> > On 10 August 2013 18:20, Brandon Allbery >
> wrote:
> >
> > There may be some support for requesting specific versions from
> > Homebrew.
> >
> >
> > Try `brew versions llvm`. Then, you'll need to run the git checkout
> > command in `brew --prefix` directory.
> >
>
> Or brew tap homebrew/versions and then install llvm31 or whatever
>
>
> --
> lelf
>
>
> ___
> 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] Haskell Platform and Leksah on Windows

[Carter Schonwald]

Hey Dorin,
I don't understand your claims.

1) haskell has worked perfectly well on windows for quite some time. I used
HUGs nearly a decade ago, and in more recent time (2-3 years ago) I helped
teach an introductory first computer science class using GHC where many
students were doing great work using notepad++ and ghci.

 I don't understand your focus on emacs and make files.

2)  if you want an "IDE" experience, Sublime Text with the right plugins,
or perhaps EclipseFP are worth checking out.

3) likewise, if you're finding tooling on windows unsatisfactory, help fix
it! Bug reports, patches, or new tools and libraries are always welcome.
Haskell is a relatively small community, and thusly limited manpower (we're
all volunteers), so way to fix any problem is help out!

cheers


On Thu, Aug 8, 2013 at 3:30 AM, Dorin Lazar  wrote:

>  Hello,
>  I am the original author of the post, and I finally received the
> emails from the mailman (probably there was an issue with the
> automated requests).
>   My answers are inlined.
>
> > 1) Leksah should not be considered an "official haskell ide", but merely
> one of
> > many community supported editing tools. And frankly one of the less
> widely
> > used ones at that! Leksah is not used much at all by anyone, though
> theres
> > probably a handful of folks who do use it.
> >  Many folks use editors like Sublime Tex (2/3), Emacs, Vi(m), textmate,
> and
> > many more.  Its worth noting that the sublime-haskell plugin for sublime
> > text, and analogous packages for many other editors, provide haskell
> > IDE-like powers, or at least a nice subset thereof.
>   Unfortunately, I think the problem with this is that we have a
> different vision on how development should be done. I have extensive
> experience of working from console, with a simple text editor and
> hand-made Makefiles or anything similar. However, an IDE should be a
> productivity tool, that can help you improve your understanding of the
> language, and can assist you in following the proper syntax for a new
> language. While learning by doing 'write, save, compile, examine error
> message' is ok with me, it is slow, and it limits the time I can
> dedicate to learning the language itself. A better cycle is the
> current 'write, examine error message' of most IDEs, since it's faster
> and requires no context switch. Sure, editors can help there. IDEs do
> this by default.
>   So it's normal of me to search for an IDE to better learn the
> language, I'll leave the emacs + console version for when I am
> productive in the language.
>
> > 2) There are people working on building better easily portable native gui
> > toolkits, but in many respects, a nice haskelly gui toolkit is still
> > something people are experimetning with how to do well. theres lots of
> great
> > tools out as of the past year or two, many more in progress on various
> time
> > scales, and gtk2hs is great for linux (and thats fine).
>   Unfortunately, this is not what's advertised. In fact, on the leksah
> site, the recommended method is to have the IDE installed via cabal.
> In another mail Mihai calls me unreasonable, but I think it's
> reasonable to think that the recommended method should be the one that
> works.
>   But the easy to tell truth is that the Haskell Platform for Windows
> is not mature enough yet. That is something I can understand, and I
> can recommend other beginners to install a Linux VM for Haskell. That
> is perfectly fine, zero cost, 100% gain. However, the mistakes from
> the Haskell Platform as it is now on Windows should be pointed out,
> and although I've been called a mystical animal that wants only free
> support, I think what I had in that blog post was actually a bug
> report for the people that can actually add 1+1 to make 2 when it
> comes to the Haskell Platform for Windows. Surely, I was harsh. But
> that's the first experience of a beginner with Haskell, and I chose to
> contribute my experience to people more knowledgeable instead of
> shutting up and hiding the dust under the rug.
>
>   Many thanks,
>  Dorin
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Importing more modules by default

[Carter Schonwald]

Hello Aditya,
you could write a script to generate a starter file for yourself. I do
something like that with my own latex documents. Or have your own special
module that reexports all of those that you import for you own projects.
Its very easy to write your own module that reExports other modules. try it
out. many libraries that you use, such as containers, do that

theres enough variety and complexity to nontrivial  projects that such a
"enforced import" would end badly


On Wed, Aug 7, 2013 at 10:23 PM, aditya bhargava
wrote:

> Hi there,
> It seems like every Haskell program I write imports the following modules:
>
> Control.Monad
> Control.Applicative
> Data.Maybe
> Data.List
>
> Is there a good reason why these modules aren't imported by default? When
> I write a simple script usually a 1/4th of the script is just imports, and
> my code just looks uglier.
>
> Adit
>
> ___
> 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] Haskell Platform and Leksah on Windows

[Carter Schonwald]

Hello Mihai,

you bring up 2 unrelated questions, i'll address them seperately


1)

Leksah should not be considered an "official haskell ide", but merely one
of many community supported editing tools. And frankly one of the less
widely used ones at that! Leksah is not used much at all by anyone, though
theres probably a handful of folks who do use it.

 Many folks use editors like Sublime Tex (2/3), Emacs, Vi(m), textmate, and
many more.  Its worth noting that the sublime-haskell plugin for sublime
text, and analogous packages for many other editors, provide haskell
IDE-like powers, or at least a nice subset thereof.


2) There are people working on building better easily portable native gui
toolkits, but in many respects, a nice haskelly gui toolkit is still
something people are experimetning with how to do well. theres lots of
great tools out as of the past year or two, many more in progress on
various time scales, and gtk2hs is great for linux (and thats fine).

cheers
-Carter





On Wed, Aug 7, 2013 at 1:18 AM, Mihai Maruseac wrote:

> Hello,
>
> A friend of mine tried to install Haskell Platform and Leksah on
> Windows and was troubled by the amount of problems he encountered as a
> beginner in this. I've told him to ask over IRC and mailing list but
> it seems he has some problems with registration.
>
> Anyway, he blogged about his problems at
> http://dorinlazar.ro/haskell-platform-windows-crippled/ and I'm sure
> that we can work on fixing some of them.
> --
> MM
> "All we have to decide is what we do with the time that is given to us"
>
> ___
> 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] ANNOUNCE: tasty, a new testing framework

[Carter Schonwald]

Awesome.  Ill take a look at tasty sometime this month.  Thanks for taking
the time to patiently answer all of our questions.

On Tuesday, August 6, 2013, Roman Cheplyaka wrote:

> * Carter Schonwald >
> [2013-08-05 16:58:37-0400]
> > fair enough. I take it that you're also (implicitly) committing to
> > maintaining this for the next few years? :)
>
> That's correct.
>
> Roman
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: tasty, a new testing framework

[Carter Schonwald]

fair enough. I take it that you're also (implicitly) committing to
maintaining this for the next few years? :)


On Mon, Aug 5, 2013 at 4:02 PM, Roman Cheplyaka  wrote:

> * Andrey Chudnov  [2013-08-05 15:31:16-0400]
> > On 08/05/2013 02:48 PM, Roman Cheplyaka wrote:
> > >(which is unmaintained).
> >   Has this been confirmed by the author/maintainer?
>
> I've sent a couple of emails to Max (one in January, one in April) and
> haven't heard anything from him. My patches, which he applied in
> January, are still not released. That's why I regard test-framework as
> unmaintained.
>
> You can also make your own impression by browsing github (commit
> activity, outstanding pull requests, open issues...)
>
> > Is it a drop-in replacement for test-framework, e.g. if I substitute
> > "test-framework" for "tasty" in my .cabal files, will it work?
> > If not, could you provide a quick guide for porting?
>
> Not quite.
>
> At the very least, you'll have to change module names
> (Test.Framework -> Test.Tasty,
>  Test.Framework.Providers.HUnit -> Test.Tasty.HUnit, ...),
> and wrap the top-level list of tests into a testGroup.
>
> If you have type signatures, you'll need to rename Test to TestTree.
>
> That should be enough in most cases. If you use plusTestOptions, you'll
> need to look up appropriate functions from Test.Tasty.Options.
>
> > Also, is the
> > current version (0.1) recommended for general use?
>
> I'd love to see people using it. But you should treat this as beta
> software. I am in the process of migrating my own packages to use Tasty.
>
> Roman
>
> ___
> 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] ANNOUNCE: tasty, a new testing framework

[Carter Schonwald]

Likewise, is test-framework explicitly unmaintained? I'd generally think a
testing tool should stabilize after a while... though I guess that
test-framework's author is pretty busy with some other work this year, but
I could be wrong.


On Mon, Aug 5, 2013 at 3:31 PM, Andrey Chudnov  wrote:

> On 08/05/2013 02:48 PM, Roman Cheplyaka wrote:
>
>> (which is unmaintained).
>>
>   Has this been confirmed by the author/maintainer?
>
>  Tasty supports HUnit, SmallCheck, QuickCheck, and golden tests out of
>> the box (through the standard packages), but it is very extensible, so
>> you can write your own test providers.
>>
>> Please see the home page for more information:
>> http://documentup.com/**feuerbach/tasty
>>
> Is it a drop-in replacement for test-framework, e.g. if I substitute
> "test-framework" for "tasty" in my .cabal files, will it work? If not,
> could you provide a quick guide for porting? Also, is the current version
> (0.1) recommended for general use?
>
>
> __**_
> 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] [ANNOUNCE] fficxx : haskell-C++ FFI binding generator

[Carter Schonwald]

speaking as the principle mentor on the relevant GSOC project (Ian is also
co monetoring, so he can correct me if i'm wrong anywhere)

The QT binding project is a *subproject* of the *gsoc project*  whose
principal focus for the summer is making a swig + fficxx based C++ ffi
wrapper for haskell. the GSOC core project is moving apace, and will likely
be usable by the close of the summer. realistically, the QT bit is  gold
plating / a nontrivial demo use case. Currently its unclear if we'll have
time to get the QT ball rolling, but a lot of the support tooling for that
subproject should be done by the close of the summer!

cheers
-Carter


On Thu, Aug 1, 2013 at 7:25 PM, kudah  wrote:

> Any progress on Qt bindings yet?
>
> On Sat, 8 Jun 2013 18:00:36 -0400 Ian-Woo Kim 
> wrote:
>
> > Dear Haskellers,
> >
> > Hello.
> >
> > I am very happy to announce the first version of fficxx
> > (http://ianwookim.org/fficxx, also, please look at
> > http://github.com/wavewave/fficxx )
> >
> > fficxx is a haskell Foreign Function Interface (FFI) generator to C++.
> > This tool automatically generates
> > haskell FFI package for a given C++ class structure. It has been used
> > for generating my haskell binding to the ROOT library [1] called HROOT
> > [2]. Now I made it as a separate tool to benefit everyone trying to
> > make a haskell-C++ binding.
> >
> > I am going to explain how to use the library/tool one by one in my
> > blog ( http://ianwookim.org/blog ). Currently, in the fficxx cabal
> > package, I provide a very simple sample in the sample directory.
> >
> > If interested, please try this and give me some comments on it in the
> > discussion mailing list: http://ianwookim.org/fficxx/discuss.html
> >
> > I hope that this is useful to many haskellers.
> > Have fun with it!
> >
> > Thanks,
> > Ian-Woo Kim (wavewave)
> >
> > [1] : http://root.cern.ch
> > [2] : http://ianwookim.org/HROOT
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Rank N Kinds

[Carter Schonwald]

hello Wvv,

a lot of these ideas have been explored before in related (albeit
"simpler") languages to haskell, are you familiar with idris, coq, or agda?

cheers
-Carter


On Fri, Jul 26, 2013 at 4:42 PM, Wvv  wrote:

> It was discussed a bit here:
> http://ghc.haskell.org/trac/ghc/ticket/8090
>
> Rank N Kinds:
> Main Idea is:
>
> If we assume an infinite hierarchy of classifications, we have
>
> True :: Bool :: * :: ** :: ***  ::  :: ...
>
> Bool  = False, True, ...
> *  = Bool, Sting, Maybe Int, ...
> **= *, *->Bool, *->(*->*), ...
> ***  = **, **->*, (**->**)->*, ...
> ...
>
> RankNKinds is also a part of lambda-cube.
>
> PlyKinds is just type of ** (Rank2Kinds)
>
> class Foo (a :: k)  where <<==>> class Foo (a :: **) where
>
> *** is significant to work with ** data and classes;
> more general: Rank(N)Kinds is significant to work with Rank(N-1)Kinds
>
> First useful use is in Typeable.
> In GHC 7.8
> class Typeable (a::k) where ... <<==>> class Typeable (a ::**) where ...
>
> But we can't write
> data Foo (a::k)->(a::k)->* ... deriving Typeable
>
> If we redeclare
> class Typeable (a ::***) where ...
> or even
> class Typeable (a ::**) where ...
> it becomes far enough for many years
>
> I'm asking to find other useful examples
>
>
>
> --
> View this message in context:
> http://haskell.1045720.n5.nabble.com/Rank-N-Kinds-tp5733482.html
> Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Dynamic and equality

[Carter Schonwald]

the tricky part then is to add support for other types.

another approach to existentially package type classes with the data type!

eg
data HasEq  = forall a . HasEq ( Eq a => a)
or its siblinng
data HasEq a = Haseq (Eq a => a )

note this requires more planning in how you structure your program, but is
a much more pleasant approach than using dynamic when you can get it to
suite your application needs.

note its also late, so I've not type checked these examples ;)

-Carter



On Fri, Jul 19, 2013 at 12:54 PM, adam vogt  wrote:

> On Fri, Jul 19, 2013 at 5:19 AM, Jose A. Lopes 
> wrote:
> > Hello,
> >
> > How to define equality for Data.Dynamic ?
>
> Hi Jose,
>
> You could try casting the values to different types that do have an
> (==). You can treat the case where you have the types matching, but
> didn't list that type beforehand differently.
>
>
> eqTys a b
> | Just a' <- fromDynamic a, Just b' <- fromDynamic b = a' == (b' ::
> Int)
> | Just a' <- fromDynamic a, Just b' <- fromDynamic b = a' == (b' ::
> Integer)
> | show a == show b = error "equal types, but don't know if there's an
> (==)!"
> | otherwise = False
>
>
> {-
>
> > eqTys (toDyn 4) (toDyn 5)
> False
>
> > eqTys (toDyn 4) (toDyn 4)
> True
>
> > eqTys (toDyn 4) (toDyn 4.5)
> False
>
> > eqTys (toDyn 4.5) (toDyn 4.5)
> *** Exception: equal types, but don't know if there's an (==)!
>
> -}
>
>
> --
> Adam
>
> ___
> 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] OS X ghci problem

[Carter Schonwald]

relatedly: johnW has nightly builds of GHC head for OS X 10.8 available for
download for those who would be up for braving such experimentation
ghc.newartisans.com


On Sat, Jul 13, 2013 at 10:16 PM, Jason Dagit  wrote:

> On Sat, Jul 13, 2013 at 6:44 PM, Carter Schonwald
>  wrote:
> > has anyone tried using ghci HEAD? If the problem is linker based...
> perhaps
> > ghci that uses the system Dylinker might resolve it?
>
> If someone gets brave and tries this I'd love to hear if it works.
> Although, that's too new for something we hope most people can use.
> I'm already feeling sheepish about requiring a minimum of 7.2.1 on OSX
> (that was the first version that knew what to do with .m files).
>
> Jason
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] OS X ghci problem

[Carter Schonwald]

has anyone tried using ghci HEAD? If the problem is linker based... perhaps
ghci that uses the system Dylinker might resolve it?

-Carter


On Sat, Jul 13, 2013 at 8:32 PM, Anthony Cowley  wrote:

> On Jul 13, 2013, at 8:04 PM, Jason Dagit  wrote:
>
> > On Sat, Jul 13, 2013 at 4:39 PM, Mark Lentczner
> >  wrote:
> >> Bizarre - this just happened to me today, too. Anyone? Did you figure
> out a
> >> work around? For the record, I'm trying to bring Euterpea up.
> >
> > After some digging, experimenting, asking around, and head scratching
> > my best guesses are:
> >
> >  * GHCi's custom linker isn't doing the right thing (some versions of
> > llvm/clang gave crashes like this and it was a linker bug for them,
> > you can find reports on sites like StackOverflow).
> >  * We need to feed .m files to clang instead of ghc/gcc
> >  * GHCi needs to be built with Cocoa in mind (is it already?)
> >  * Some rts component of objective-c is not properly initialized (ARC
> > vs. -fobjc-gc vs. -fnext-step, etc)
> >
> >>
> >> My system is OS X 10.8.4, and I'm running HP 2013.2, so 7.6.3. And
> >> GLFW-0.5.1.0.
> >
> > In terms of experimentation, you can hand desugar the objective-c code
> > in the GLFW init and when I do that I get segfaults. Also, the address
> > mentioned in the objective-c exception has a suspicious value, which
> > would further implicate the linker. Add to that, it works for a
> > compile program (which uses the system linker, IIRC).
> >
> > Basically, I'm pretty sure it's GHCi's linker to blame here but I
> > don't have a smoking gun.
> >
> > Jason
>
> I thought I'd had some success desugaring the Objective-C code, but I
> never went the whole way, so perhaps I just didn't get to the segfault.
> What I do for GLFW is use a dylib, then you don't rely on GHCi's static-ish
> linker. The only wrinkle is figuring out where you want the dylib. I think
> homebrew will put one in /usr/local/lib, which works out nicely, but they
> don't have GLFW 3 yet. Another option is to build the dylib yourself from
> the GLFW source bundled with the GLFW-b package, then tell cabal where to
> find it.
>
> It's worth the trouble, as having a GHCi-based workflow for graphics work
> is wonderful. A fancy Setup.hs that works out installation paths could
> generate the dylib, and I thought such code existed in the past. Was some
> problem found with that approach?
>
> Anthony
> ___
> 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] Proposal: Non-recursive let

[Carter Schonwald]

Yup. Nested cases *are* non recursive lets.

(Can't believe I forgot about that )

On Thursday, July 11, 2013, Edward Kmett wrote:

> On Wed, Jul 10, 2013 at 3:47 AM,  'cvml', 'o...@okmij.org');>> wrote:
>
>>
>> Jon Fairbairn wrote:
>> > It just changes forgetting to use different variable names because of
>> > recursion (which is currently uniform throughout the language) to
>> > forgetting to use non recursive let instead of let.
>>
>> Let me bring to the record the message I just wrote on Haskell-cafe
>>
>> http://www.haskell.org/pipermail/haskell-cafe/2013-July/109116.html
>>
>> and repeat the example:
>>
>> In OCaml, I can (and often do) write
>>
>> let (x,s) = foo 1 [] in
>> let (y,s) = bar x s in
>> let (z,s) = baz x y s in ...
>>
>> In Haskell I'll have to uniquely number the s's:
>>
>> let (x,s1)  = foo 1 [] in
>> let (y,s2)  = bar x s1 in
>> let (z,s3)  = baz x y s2 in ...
>>
>
>
>> and re-number them if I insert a new statement.
>>
>
> blah = case foo 1 [] of
>   (x, s) -> case bar x s of
>  (y, s) -> case baz x y s of
>(z, s) -> ...
>
> -Edward
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Proposal: Non-recursive let

[Carter Schonwald]

theres a very simple way to do non recursive let already! do notation in
the identity monad. I use it quite a lot lately.


On Wed, Jul 10, 2013 at 1:49 PM, Ertugrul Söylemez  wrote:

> "Ezra e. k. Cooper"  wrote:
>
> > As starter suggestions for the keyword or syntax, I submit:
> >
> >   let new x = expr in body   -- Not the old x!
>
> It's not the old x in either case (recursive and non-recursive).
>
>
> >   let shadowing x = expr in body
> >
> >   shadow x = expr in body
>
> It's shadowing in either case.
>
>
> >   let x =! expr in body  -- The explosive bang gives an imperative
> >   flavor.
>
> (=!) is a valid operator name.
>
>
> > Other suggestions would be welcome.
>
> My suggestion:  Don't add a non-recursive let.  See my other post about
> general recursion and totality checking.
>
>
> Greets,
> Ertugrul
>
> --
> Not to be or to be and (not to be or to be and (not to be or to be and
> (not to be or to be and ... that is the list monad.
>
> ___
> 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] Array, Vector, Bytestring

[Carter Schonwald]

I really don't understand this concern.

These libraries are tuned for wildly different workloads and use cases, so
these sorts of micro benchmarks are an Apples to Frogs comparisons.
(even aside from the fact that you'll get very different perf if you used
-fllvm and set things up so the array indexing and associated loop code get
inlined and fused together!)

what is the actual concern? Strawman micro benchmarks that don't even
compare the respective libraries for their intended use cases seeems
weird.






On Tue, Jun 4, 2013 at 12:49 PM, silvio  wrote:

> Just to clarify for those on the sidelines, the issue is duplication of
>> implementation details, rather than duplication of functionality?
>>
>
> Well to me, that is not the main issue. The main issue is that you have to
> study all of them and depending on which libraries you want to use have to
> convert between them, which could be expensive and is definitely annoying.
>
> I made a few simple benchmarks comparing the three libraries you can find
> the code attached.
>
> this is compiled with -O2
>
> # simple sum of 100 Word8 elements
>
> Unboxed Vector   1.114060 ms
> Storable Vector  795.1207 us
> Primitive Vector 1.116145 ms
>
> ByteString   9.076256 ms
>
> array library has no fold or sum function
>
> # simple sum of 100 more or less randomly chosen elements
>
> Unboxed Vector (unsafe)33.74364 ms
> Storable Vector (unsafe)   50.27273 ms
> Storable Vector (safe) 67.01634 ms
> Primitive Vector (unsafe)  56.29919 ms
>
> ByteString (unsafe)19.29611 ms
> ByteString (safe)  18.29065 ms
>
> UArray (safe)  46.88719 ms
> unsafe does not exist for array
>
> So Unboxed can be better than Storable but doesn't need to be.
> Also, which implementation is faster depends very much on the problem at
> hand. And array is just missing half the needed features.
>
> Silvio
>
> ___
> 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] Int is broken [Was: Different answers on different machines]

[Carter Schonwald]

GHC is not the spec, I am talking about GHC Haskell, not Haskell the
standard that I don't use.

On 32bit machines, GHC Int is 32bits. On 64bit GHC on 64bit machines Int is
64 bits.

If you have another well engineered suitable for wide use Haskell compiler
in mind, I'd love to try it out, but with interesting software you will be
using none portable features per target platform. And thats OK. Its a
tradeoff thats sometimes worth making.
On Jun 3, 2013 4:19 AM, "Tommy Thorn"  wrote:

> On Jun 3, 2013, at 00:23 , Carter Schonwald 
> wrote:
>
> > Int is "native register sized integer"
>
> Actually it's not. Read the definition. Int is only guaranteed to be 29
> bits.
>
> Here's *one* _actual_ data point (from a 2.8 GHz i7, 64-bit code):
>
> time ./fib
> fib(43) = 701408733
> 3.27 real 3.27 user 0.00 sys
> time ./fib-safe
> fib(43) = 701408733
> 3.45 real 3.45 user 0.00 sys
>
> (NB: I do not check the n-1 and n-2 as it's trivial to see from a data
> flow analysis
> that the proceeding conditional guarantees that those can't overflow.
> The empty asm() is necessary to get GCC to generate comparable code).
>
>
>
>
> Obviously, for some examples this will be much worse, for others, much
> better, but without
> this implemented in GHC it will be difficult to measure.
>
> Tommy
>
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Int is broken [Was: Different answers on different machines]

[Carter Schonwald]

Tommy, respectfully,

I have quite a few bits of code where a bad branch predictor in a tight
inner loops makes code 10x slower.

you are welcome to do your own experimentation so that you too can learn by
branches are bad in tight loops.  (even if the branch predictor is doing
its job, there will be a measurable slow down, albeit less than 10x)

Please shift this conversation to the libraries list if you want to
actually make a concrete libraries change proposal. Otherwise I don't
understand your contentions. Int is "native register sized integer" not
"integer that i need to exception handle because I used int instead of
integer because of premature optimization in my web app or project euler
codes"

My opinions are based upon spending all of my time over the past year
working on writing robustly performant numerical codes. Some of them are
actually faster than the standard fortran ones.

My point being: as mentioned above, by others much more articulate than I,
unless you have performance related reasons, always use Integer instead of
Int. There is never a good reason to use Int instead of Integer unless it
will change the performance characteristics of your code. Asking for Int to
pretend to be Integer because you wanted to do premature optimization and
then it didn't behave like Integer is a no go.

I am happy to direct you towards further reading if you'd like to learn
about writing performance sensitive software:

the intel optimization
manual<http://www.intel.com/content/dam/doc/manual/64-ia-32-architectures-optimization-manual.pdf>has
many good ideas (eg Structure of Arrays, which is essentially used by
the haskell Vector lib) that are actually realized by the more performant
haskell libraries.

 Likewise, for an informative idea of the cost models for various
operations on the CPU, the agner fog
<http://agner.org/optimize/#manuals> manuals
are actually very educational.

merry hacking
-Carter



On Mon, Jun 3, 2013 at 3:07 AM, Tommy Thorn  wrote:

> On Jun 2, 2013, at 23:58 , Carter Schonwald 
> wrote:
>
> > Indeed, as Dan says, theres the safeint library and the Integer type.
> >
> > If the Int type had either of these semantics by default, many many
> performance sensitive libraries would suddenly have substantially less
> compelling performance.  Every single operation that was branchless before
> would have a branch *every* operation. this would be BAD.
>
> I'd like to see actual data, measurements of actual wall-time impact on
> real code on modern hardware,
> not assumptions.
>
> Tommy
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to write a pure String to String function in Haskell FFI to C++

[Carter Schonwald]

as the others have said, if you want to have text data go between ghc and
c++, please use Text or Bytestring,

String... would get weird.

If you seriously want to experiment with writing low level code
manipulating the String type, it *MIGHT* be possible using the GHC C minus
minus (CMM). This would be very very very subtle to do correctly, and also
just be really really complicated and hard.

Likewise, for writing a "pure" looking ffi function, a good example is in
the lz4hs lib, where all the allocation occurs on the haskell side, and the
ffi is only mutating freshly allocated memory. Subject to this,
unsafePerformIO can be safely used to give a safe pure thread safe api.

cheers
-Carter


On Sun, Jun 2, 2013 at 10:55 PM, Chris Wong  wrote:

> > The C++/C function (e.g. toUppers) is computation-only and as pure as cos
> > and tan. The fact that marshaling string incurs an IO monad in current
> > examples is kind of unintuitive and like a bug in design. I don't mind
> > making redundant copies under the hood from one type to another..
>
> If you can guarantee that the call is pure, then you can execute it
> directly using `unsafePerformIO`. Simply call the external function as
> usual, then invoke `unsafePerformIO` on the result.
>
> See <
> http://hackage.haskell.org/packages/archive/base/4.6.0.1/doc/html/System-IO-Unsafe.html
> >.
>
> On another note, if you really care about performance, you should use
> the `bytestring` and `text` packages instead of String. They are
> implemented in terms of byte arrays, instead of linked lists, hence
> are both faster and more FFI-friendly.
>
> >
> >
> >
> > On Sun, Jun 2, 2013 at 8:08 PM, Brandon Allbery 
> wrote:
> >>
> >> On Sun, Jun 2, 2013 at 8:01 PM, Thomas Davie 
> wrote:
> >>>
> >>> On 2 Jun 2013, at 16:48, Brandon Allbery  wrote:
> >>>
> >>> (String is a linked list of Char, which is also not a C char; it is a
> >>> constructor and a machine word large enough to hold a Unicode
> codepoint. And
> >>> because Haskell is non-strict, any part of that linked list can be an
> >>> unevaluated thunk which requires forcing the evaluation of arbitrary
> Haskell
> >>> code elsewhere to "reify" the value; this obviously cannot be done in
> the
> >>> middle of random C code, so it must be done during marshalling.)
> >>>
> >>>
> >>> I'm not convinced that that's "obvious" – though it certainly requires
> >>> functions (that go through the FFI) to grab each character at a time.
> >>
> >>
> >> I think you underestimate the complexity of the Haskell runtime and the
> >> interactions between it and the FFI. Admittedly it is probably not
> "obvious"
> >> in the sense of "anyone can tell without knowing anything about it that
> it
> >> can't possibly work", but it should be at least somewhat obvious to
> someone
> >> who sees why there needs to be an FFI in the first place that the
> situation
> >> is not trivial, and that they probably should not blindly assume that
> the
> >> only reason one can't just pass Haskell values directly to C is that
> some
> >> GHC developer was feeling lazy at the time.
> >>
> >> --
> >> brandon s allbery kf8nh   sine nomine
> >> associates
> >> allber...@gmail.com
> >> ballb...@sinenomine.net
> >> unix, openafs, kerberos, infrastructure, xmonad
> >> http://sinenomine.net
> >
> >
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
>
>
> --
> 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] Int is broken [Was: Different answers on different machines]

[Carter Schonwald]

Indeed, as Dan says, theres the safeint library and the Integer type.

If the Int type had either of these semantics by default, many many
performance sensitive libraries would suddenly have substantially less
compelling performance.  Every single operation that was branchless before
would have a branch *every* operation. this would be BAD.

I'm actually quite happy with (ab)using Int as just a sequence of bits that
sometimes i treat as a number, and sometimes i treat as a bitvector. In
fact thats actually most of my work these days. GHC generates VERY nice
code for Ints and Words, similar to what i'd expect to be Generated by a
decent C compiler when not explicitly using SIMD operations.  This is a
good thing!

Additionally, theres work in progress to support "branchless" Bool
operations in GHC by having Bool be represented internally With 0,1 valued
Ints, http://hackage.haskell.org/trac/ghc/wiki/PrimBool

point being: its easy to have the safety with SafeInt, or Using Integer,
and fast inner loops can't have branches, and that actually matters in many
applications.

cheers
-Carter


On Sun, Jun 2, 2013 at 6:42 PM, Dan Doel  wrote:

> There is a package that implements an Int that throws an exception on
> overflow:
>
> http://hackage.haskell.org/package/safeint
>
> Since Int's existence is pretty much all about trading for performance, I
> wouldn't recommend holding your breath on the above becoming the default.
>
> If you want things to work like Scheme, that's exactly what Integer is (in
> GHC, anyhow). And Integer is what you get by default(ing) unless you use
> something else that is specifically defined to use Int, or specify it
> yourself.
>
>
>
> On Sun, Jun 2, 2013 at 5:02 PM, Tommy Thorn  wrote:
>
>> On Jun 2, 2013, at 12:52 , Henry Laxen 
>> wrote:
>>
>> > Yes, that was it.  The dell was a 32 bit system, and the desktop a 64.
>>  I
>> > changed everything from Int to Integer, and now both agree.  Thanks for
>> the
>> > pointer.
>>
>> Isn't that just terrible? I hate the fact that Haskell was defined to
>> neither trap the overflow
>> or just treat everything as Integer [like Scheme]. A sacrifice of program
>> safety in the name
>> of efficiency.
>>
>> I disagree with this choice and posit that a clever implementation can
>> minimize the cost
>> of the overflow checking in most relevant cases.
>>
>> I wish this fatal flaw would be reconsidered for the next major revision.
>>
>> Tommy
>>
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [haskell.org Google Summer of Code 2013] Approved Projects

[Carter Schonwald]

thanks for these references all.

As some folks who help with GSOC mentoring have pointed out offline, this
summers work is not to be a research project, but a concretely achievable
over the summer by a single student project. if we hit hard obstacles i'll
help sort out a concrete path that maintains a path to success, but
research here isn't the goal. rather "lets make something that WORKS WELL".
Sometimes the novelty requirements for research are contrary to the best
tech choices for building robust usable tools.

point being, thanks for sharing the fun reading, if any can help the
student along, i'm happy to pass it along, but lets not nerd snipe students
into other projects. (i'm bad enough with that for myself as is :) )


On Thu, May 30, 2013 at 2:27 PM, Stephen Tetley wrote:

> Similarly (to some degree), in the ML world John Reppy had a very nice
> system that employed user customization via combinators rather than
> inference to generate application/library specific FFIs, see:
>
> http://people.cs.uchicago.edu/~jhr/papers/2006/gpce-fig.pdf
>
> On 29 May 2013 18:57, Jason Dagit  wrote:
>
> > Are you folks aware of the work on this topic by Tristan Ravitch?
> > https://github.com/travitch/foreign-inference
> >
> > Jason
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [haskell.org Google Summer of Code 2013] Approved Projects

[Carter Schonwald]

Ooo. Thanks Jason.

That looks like a fleshed out version of the approach I was leaning towards
at least thinking about. I'll check it out when I have time in a few days.
On May 29, 2013 1:57 PM, "Jason Dagit"  wrote:

> On Wed, May 29, 2013 at 10:47 AM, Carter Schonwald
>  wrote:
> > indeed, i'm the principal mentor for this project, though as mentioned
> > Ian-Woo will hopefully be helping out too.
> >
> > I'm going to *help* focus the project on being a tool thats not focused
> on
> > QT, though if something nice can be worked out in that direction, great!
>
> Are you folks aware of the work on this topic by Tristan Ravitch?
> https://github.com/travitch/foreign-inference
>
> Jason
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [haskell.org Google Summer of Code 2013] Approved Projects

[Carter Schonwald]

indeed, i'm the principal mentor for this project, though as mentioned
Ian-Woo will hopefully be helping out too.

I'm going to *help* focus the project on being a tool thats not focused on
QT, though if something nice can be worked out in that direction, great!

indeed, I suspect Edward, Ian-Woo and I will spend some small amount of
time at HackPhi trying to figure out some good avenues of attack to make
this a successful project that is used by the community and as actively
maintained.

cheers
-Carter


On Wed, May 29, 2013 at 12:55 PM, Edward Kmett  wrote:

> When submissions are put in, there is a way for mentors to talk to
> students to ask for more details. Those don't show up in the published
> abstract you can see at the end.
>
> The discussion shifted towards focusing on getting things to a point where
> Haskell can meaningfully use SWIG rather than on Qt per se but it is good
> to keep such a concrete goal in mind when working on something as abstract
> as SWIG.
>
> I agree that Qt has a somewhat horrible API. =)
>
> -Edward
>
>
> On Wed, May 29, 2013 at 12:34 PM, harry  wrote:
>
>> Edward Kmett  gmail.com> writes:
>>
>> > There should be a link from the google-melange website, but one slight
>> shift in focus is on either getting SWIG bindings or possibly even using
>> Ian-Woo Kim's C++FFI tools. Carter may be able to go into more detail.
>>
>> There's almost no information in the google project abstract. My concern
>> is
>> that the problem isn't generating the bindings (as I've said, that's been
>> done twice before). It's that Qt's slots-and-signals are horrible to use
>> from the Haskell side. If the student hasn't already got a good idea of
>> how
>> to solve this, I fear that this project will be just generate another
>> unusable set of bindings.
>>
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to throw an error if using "cabal-install" < version XYZ?

[Carter Schonwald]

constraining it to >= 1.17 would be better while 1.18 isn't out yet..


On Thu, May 23, 2013 at 1:42 AM, Roman Cheplyaka  wrote:

> Perhaps I'm missing something, but why not just
>
>   cabal-version:   >=1.18
>
> ?
>
> It will constrain the Cabal version, not cabal-install, but judging from
> the fix[1] this is what you actually need.
>
> [1]:
> https://github.com/haskell/cabal/commit/d148336e97cda2e3585c453cf9af61bc3635131a
>
> Roman
>
> * Ryan Newton  [2013-05-22 22:50:08-0400]
> > A cabal-install bug  was
> > fixed recently that pertains to building C libraries with profiling.
> >
> > As a result, I want a certain
> > packageto
> > test if cabal-install < 0.17.0 is used, and throw a preemptive error.
> >  Otherwise this package fails in weird ways at runtime (it's a nasty
> one).
> >
> > I noticed with some surprise the following sequence:
> >
> > *   $ cabal --version*
> > *   cabal-install version 1.16.0.2*
> > *   using version 1.16.0.3 of the Cabal library*
> > *   $ cabal clean*
> > *   $ cabal install*
> > *   $ cat dist/build/autogen/cabal_macros.h  | grep VERSION_Cabal*
> > *   #define VERSION_Cabal "1.17.0"*
> >
> > Alright, so that, in retrospect, makes sense.  The version is which *my*
> > library is linked with is the relevant one, not the one cabal-install was
> > linked with [1].
> >
> > So the natural next thought is to move the MIN_VERSION_Cabal test into
> > Setup.hs, and force cabal to use it by setting the build type to Custom.
> >  But... I just learned from this ticket that the cabal macros are not
> > available in Setup.hs:
> >
> >http://hackage.haskell.org/trac/hackage/ticket/326
> >
> > Uh oh, what's left?
> >
> >  -Ryan
> >
> > [1] P.S. Personally I'm now using a bash function like below, to force
> the
> > two versions to be the same:
> >
> > function safe_cabal_install () {
> >   VER=`cabal --version | tail -n1 | awk '{ print $3 }'`
> >   cabal install --constraint="Cabal==$VER" $*
> > }
>
> > ___
> > cabal-devel mailing list
> > cabal-de...@haskell.org
> > http://www.haskell.org/mailman/listinfo/cabal-devel
>
>
> ___
> 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] How to throw an error if using "cabal-install" < version XYZ?

[Carter Schonwald]

Hey Ryan,
I ran into a related issue, heres a a way you can do this safe IN the cabal
file (or at least you can modify my hack for your purposes)

heres a link to the workaround I did for making LLVM-hs work across >= 1.17
and < 1.17 cabal, but you could abuse it to make sure setup.hs barfs on old
cabal https://github.com/bos/llvm/blob/master/base/Setup.hs#L89-L116

heres a quick one off gist that takes my trick and does something helpful
for you variant + makes sure the tool can't build otherwise

https://gist.github.com/cartazio/5632636

I just wrote a snippet that you can just add to your setup.hs and it should
guarantee the setup.hs will barf with a helpful error message on cabal <
1.17.0


On Wed, May 22, 2013 at 10:50 PM, Ryan Newton  wrote:

> A cabal-install bug  was
> fixed recently that pertains to building C libraries with profiling.
>
> As a result, I want a certain 
> packageto test if 
> cabal-install < 0.17.0 is used, and throw a preemptive error.
>  Otherwise this package fails in weird ways at runtime (it's a nasty one).
>
> I noticed with some surprise the following sequence:
>
> *   $ cabal --version*
> *   cabal-install version 1.16.0.2*
> *   using version 1.16.0.3 of the Cabal library*
> *   $ cabal clean*
> *   $ cabal install*
> *   $ cat dist/build/autogen/cabal_macros.h  | grep VERSION_Cabal*
> *   #define VERSION_Cabal "1.17.0"*
>
> Alright, so that, in retrospect, makes sense.  The version is which *my*
> library is linked with is the relevant one, not the one cabal-install was
> linked with [1].
>
> So the natural next thought is to move the MIN_VERSION_Cabal test into
> Setup.hs, and force cabal to use it by setting the build type to Custom.
>  But... I just learned from this ticket that the cabal macros are not
> available in Setup.hs:
>
>http://hackage.haskell.org/trac/hackage/ticket/326
>
> Uh oh, what's left?
>
>  -Ryan
>
> [1] P.S. Personally I'm now using a bash function like below, to force the
> two versions to be the same:
>
> function safe_cabal_install () {
>   VER=`cabal --version | tail -n1 | awk '{ print $3 }'`
>   cabal install --constraint="Cabal==$VER" $*
> }
>
>
> ___
> 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] Problem with mailman at projects.haskell.org

[Carter Schonwald]

I've had this problem too. Was trying to sign up for the llvm HS lib list
but cant. I asked on Haskell irc and no one seems to know who admins the
lists currently.
On May 12, 2013 7:24 AM, "Tim Docker"  wrote:

> Hi,
>
> Has anyone noticed problems with the mailman instance running at
> projects.haskell.org? As best I can see there are no new posts in any of
> the hosted list archives since mid April. I know that there have been posts
> made to ch...@projects.haskell.org in May, and these have neither be
> distributed or archived.
>
> I've not had a response from mail...@projects.haskell.org.
>
> Tim
>
> __**_
> 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] Hackage checking maintainership of packages

[Carter Schonwald]

is that really a problem though?

Who's problem are we trying to solve? Is this being proposed to help
seasoned haskellers, or make getting started easier for new folks?

those are two VERY different problems. Also many of the maintainers for
heavily used packages are incredibly busy as is, do they need to keep track
of even *more* email? I'd hope not.

In some respects,  just having the hackage2 deps and revdeps stats is a
good proxy for how likely a package is to be well maintained.


On Mon, May 6, 2013 at 8:45 AM, Niklas Hambüchen  wrote:

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

Re: [Haskell-cafe] Backward compatibility

[Carter Schonwald]

What pray tell are those missing pieces? Aren't they mostly building a
browser based ide plus doing training courses ?
On May 4, 2013 1:42 PM, "Ben Doyle"  wrote:

> You might want to check out 
> FPComplete,
> if you haven't already. They're far more focused on making it easy for
> organizations to adopt Haskell than the community can be. As they say: "Where
> the open-source process is not sufficient to meet commercial adoption
> needs, we provide the missing pieces."
>
> ___
> 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] Backward compatibility

[Carter Schonwald]

Emphatic agreement on this point.

Likewise, the strong type system and the often helpful type error messages
make it really easy to update code to work with more modern libs!

-Carter


On Thu, May 2, 2013 at 9:39 AM, David Thomas wrote:

> If you are actively using something then keep it up to date, encourage
> someone to keep it up to date, pay someone to keep it up to date, or
> migrate off of it.  If you try building with a fresh set of packages every
> so often, you can catch breaking changes early and deal with them when it's
> typically pretty clear why things broke.
>  On May 2, 2013 6:33 AM, "Adrian May" 
> wrote:
>
>> So WASH is ancient history. OK, lets forget it.
>>
>> How about the Haskell Platform? Is that ancient history? Certainly not:
>> it doesn't compile on anything but the very newest GHC. Not 7.4.1 but
>> 7.4.2. Now that's rapid maintenance, but it's still version hell because
>> you've got to have that compiler installed first (even though HP is
>> supposed to be a way to acquire haskell) and you probably haven't. You've
>> probably got the one from the linux package which hasn't been maintained
>> since, ooh, must have been at least a week ago, so you install the new one
>> and you've trashed cabal. How long is that puzzle gonna take to unravel?
>> That's how I spent my afternoon today, instead of getting on with my job.
>> Now you might think I was silly not to have uninstalled the linux package
>> first, but I tried, and then decided against it because it thought the
>> entire OS depended on it and actually proposed to remove everything from
>> clib to googleearth as a solution. It's not Haskell's fault that linux
>> package management is as broken as any other for the same reasons, but in
>> an imperfect world, it's better not to keep moving the furniture around.
>>
>> Why was I trying to build the Haskell Platform at all? Because it wasn't
>> obvious to me that a 7 year old library would be doomed. I find it
>> perfectly normal to be able to compile C code from the 1970s but still run
>> STL through the same compiler. That's why I blamed the system instead of
>> the library. And unless somebody can explain to me how I would rescue my
>> business now if I had opted for WASH in that long-forgotten era when Barack
>> Obama was barely known, a Russian spy was poisoned with Polonium and a
>> Sudanese man was ordered to marry a goat he was caught in an intimate
>> position with, then I still see it that way.
>>
>> Adrian.
>>
>>
>>
>>
>>
>>
>>
>>
>> On 2 May 2013 19:57, Ertugrul Söylemez  wrote:
>>
>>> John Lato  wrote:
>>>
>>> > I don't think there's anything wrong with moving at a fast pace, nor
>>> > do I think backwards compatibility should be maintained in perpetuity.
>>>
>>> I think this statement pretty much covers the mindset of the Haskell
>>> community and also explains the higher breakage rate of Haskell packages
>>> when compared to other languages, in particular non-static ones:  We
>>> move at a very fast pace.  Innovations are made all the time.  Without
>>> this feature we wouldn't be where we are today.
>>>
>>> Of course Haskell, being a rigorously static and correct language and a
>>> community that equally rigorously insists on correctness of design
>>> patterns we have to live with the fact that we need to fix the breakages
>>> we introduce, and we do that.  This is a good thing.
>>>
>>>
>>> > Unfortunately this leaves a lot of scope for migrations to be handled
>>> > poorly, and for unintended consequences of shiny new systems.  IMHO
>>> > both have caused issues for Haskell developers and users in the recent
>>> > and more distant past.  This is an issue where I think the community
>>> > should continually try to improve, and if a user calls out a
>>> > difficulty we should at least try to learn from it and not repeat the
>>> > same mistake.
>>>
>>> I think we do that.  The most severe breakages are introduced by new GHC
>>> versions.  That's why there is the Haskell Platform.  If users decide to
>>> move to new versions sooner they should be prepared to handle the
>>> breakages.  In particular a Haskell beginner simply shouldn't use
>>> GHC-HEAD.  Our type system makes us aware of the breakages we introduce
>>> and gives us the opportunity to fix them properly before exposing them
>>> to the users.
>>>
>>> With this in mind I don't think there is anything to learn from this
>>> particular case.  You wouldn't use WASH today for the same reasons you
>>> wouldn't use Linux 0.x.  It's a legacy, and the ideas from it have
>>> inspired the more recent web frameworks, which are more convenient,
>>> faster, more real-world-oriented.  In fact I totally expect a new
>>> generation of web frameworks to pop up in the future, more categorical,
>>> even more convenient and less error-prone.
>>>
>>>
>>> Greets,
>>> Ertugrul
>>>
>>> --
>>> Key-ID: E5DD8D11 "Ertugrul Soeylemez "
>>> FPrint: BD28 3E3F BE63 BADD 4157  9134 D56A 37FA E5DD 8D11
>>> Keysrv: hkp://subkeys.pgp.net/
>>>

Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project

[Carter Schonwald]

indeed. That approach seems like the most likely to be successful within
the scope of a single summer.

That said, this does raise the question of what needs to be fixed up /
added to the  haddock grammar to
a) make it a rich target for pandoc
b) make sure the augmented haddock grammar is human friendly and we can
give helpful syntax errors etc.

Whats the status of this proposal for this years GSOC? Done well / right,
it'd be super valuable for the community

-Carter


On Thu, May 2, 2013 at 4:46 AM, Mateusz Kowalczyk
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 02/05/13 09:26, Andrew Butterfield wrote:
> > My 2c (before such coins disappear...)
> >
> > On 2 May 2013, at 09:14, Petr Pudlák wrote:
> >
> >> Hi,
> >>
> >>
> >> Personally I'd incline to choose some existing, well-established
> >> markup language with formal specification that supports math
> >> (hopefully there is one).
> >
> > So TeX/LaTeX is out then   :-(
> >
> >
> >
> > 
> >
> >
> Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204
> > Lero@TCD, Head of Foundations & Methods Research Group Director of
> > Teaching and Learning - Undergraduate, School of Computer Science
> > and Statistics, Room G.39, O'Reilly Institute, Trinity College,
> > University of Dublin http://www.scss.tcd.ie/Andrew.Butterfield/
> > 
> >
> >
> >
> >
> >
> > ___ Haskell-Cafe
> > mailing list Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
> With a reader and write module for new Haddock, you should be able to
> write LaTeX and convert that to Haddock and vice-versa. Some kind of
> Markdown was requested by popular demand but if we end up going the
> Pandoc way, we'll end up getting the plethora of already supported
> formats basically for free.
> - --
> Mateusz K.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.19 (GNU/Linux)
>
> iQIcBAEBAgAGBQJRgifxAAoJEM1mucMq2pqXtS0P/Rxx/JHS0vprqi0oCVDPcVTG
> 0ZCzptgVUYGlbVfdJYsbFChC+7SjWnb6/AXlsEfVnwhpVTparlwRdWu11+LxWWaH
> sHWqWX6mHk236rBcxllbpE92u/WqOcn4YsOLArClz8xbTVw2YkUHzFUBnnSGvClS
> V7Qq2jf0xnJWzPcFw1WY9/UdIhcOUif526VW41pkggXCzxp6/gr2VtKJbWJ/ljHX
> YCdrRRZXypT9UZKKt1oeKWp+XCs5Oh6nBZuJNNTeBQo03wyap4SYrnDlAnhPu911
> Fb8+eqGTJKDsKIstERwgWfVSO/qzWUfOTc0orsvJHvy9SCATGKNkwRIvWX2SZj12
> bl1D1Z0YQhHl3yRb2G7ZZXGcC6GXfAMk9/I/tgu74HtqM0hxHvZwGwPCX0Ql30EU
> GJsVBgabv8v6TS96/iipRTZTAUphqSTopl/JWhg0n+p5OVtZKOu/OI/xefmgqI26
> Hx1I4yZKDMHkzYJFYhoi9QBLy+XzwlRctjNcEZClse+St1hlgR6lLLjhLHJQoRDg
> V5TWkzkaO3SvrnKFeObaRdt/Q8BxNgfOcWqyLcioobbu4Un0j6ncpcHZnAFHF0i7
> FkE0CGxMiwLrB9F8sw+VTgFnCk3xm0QwgfpDeQVifhD83Jk51pJc8L/vg63ANEGN
> FI4KKji7k/J2NbfQHxDG
> =2xQm
> -END PGP SIGNATURE-
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Two GHC-related GSoC Proposals

[Carter Schonwald]

Hey Patrick,
both are excellent ideas for work that would be really valuable for the
community!
(independent of whether or not they can be made into GSOC sided chunks )

---
I'm actually hoping to invest some time this summer investigating improving
the numerics optimization story in ghc. This is in large part because I'm
writing LOTs of numeric codes in haskell presently (hopefully on track to
make some available to the community ).

That said, its not entirely obvious (at least to me) what a tractable
focused GSOC sized subset of the numerics optimization improvement would
be, and that would have to also be a subset that has real performance
impact and doesn't benefit from eg using -fllvm rather than -fasm .
-

For helping pave the way to better parallel builds, what are some self
contained units of work on ghc (or related work on cabal) that might be
tractable over a summer? If you can put together a clear roadmap of "work
chunks" that are tractable over the course of the summer, I'd favor
choosing that work, especially if you can give a clear outline of the plan
per chunk and how to evaluate the success of each unit of work.

basically: while both are high value projects, helping improve the parallel
build tooling (whether in performance or correctness or both!) has a more
obvious scope of community impact, and if you can layout a clear plan of
work that GHC folks agree with and seems doable, i'd favor that project :)

hope this feedback helps you sort out project ideas

cheers
-Carter




On Sun, Apr 21, 2013 at 12:20 PM, Patrick Palka wrote:

> Hi,
>
> I'm interested in participating in the GSoC by improving GHC with one of
> these two features:
>
> 1) Implement native support for compiling modules in parallel (see 
> #910).
> This will involve making the compilation pipeline thread-safe, implementing
> the logic for building modules in parallel (with an emphasis on keeping
> compiler output deterministic), and lots of testing and benchmarking. Being
> able to seamlessly build modules in parallel will shorten the time it takes
> to recompile a project and will therefore improve the life of every GHC
> user.
>
> 2) Improve existing constant folding, strength reduction and peephole
> optimizations on arithmetic and logical expressions, and optionally
> implement a core-to-core pass for optimizing nested comparisons (relevant
> tickets include #2132 ,
> #5615 
> ,#4101).
> GHC currently performs some of these simplifications (via its BuiltinRule
> framework), but there is a lot of room for improvement. For instance, the
> core for this snippet is essentially identical to the Haskell source:
>
> foo :: Int -> Int -> Int -> Int
> foo a b c = 10*((b+7+a+12+b+9)+4) + 5*(a+7+b+12+a+9) + 7 + b + c
>
> Yet the RHS is actually equivalent to
>
> 20*a + 26*b + c + 467
>
> And:
>
> bar :: Int -> Int -> Int
> bar a b = a + b - a - b -- the RHS is should be optimized away to 0
>
> Other optimizations include: multiplication and division by powers of two
> should be converted to shifts; multiple plusAddr calls with constant
> operands should be coalesced into a single plusAddr call; floating point
> functions should be constant folded, etc..
>
> GHC should be able to perform all these algebraic simplifications. Of
> course, emphasis should be placed on the correctness of such
> transformations. A flag for performing unsafe optimizations like assuming
> floating point arithmetic is associative and distributive should be added.
> This proposal will benefit anybody writing or using numerically intensive
> code.
>
>
> I'm wondering what the community thinks of these projects. Which project
> is a better fit for GSoC, or are both a good fit? Is a mentor willing to
> supervise one of these projects?
>
> Thanks for your time.
> Patrick
>
> (A little about myself: I'm a Mathematics student in the US, and I've been
> programming in Haskell for about 3.5 years. Having a keen interest in
> Haskell and compilers, I began studying the GHC source about 1 year ago and
> I've since gotten a good understanding of its internals, contributing a few
> patches along the way.)
>
>
> ___
> 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] GSoC proposal: Data Visualization

[Carter Schonwald]

Heinrich, you hit the nail on the head.

for an interactive plotting story to work well, we wind up needing to have
better tools in the ecosystem on the gui / computational notebook side.


on the other hand, similar work was done last summer, as heinrich mentions,
in the form of ghc live https://github.com/shapr/ghclive, by
a very strong GSOC participant, and while it works, its not really being
used, and is still quite immature.

Additionally, the folks at FPcomplete have their browser based haskell
interaction tool thats seeing quite a lot of use by folks learning haskell,
which in turn raises the quality bar that any other effort must achieve to
see serious usage.

its also worth wondering if the scala notebook port of the ipython notebook
could be used to guid writing a similar tools for haskell.

 Either way,  would require a very concrete plan of attack to be a
tractable GSOC project

-Carter




On Sat, Apr 13, 2013 at 4:33 AM, Heinrich Apfelmus <
apfel...@quantentunnel.de> wrote:

> Ernesto Rodriguez wrote:
>
>> Dear Haskell Community,
>>
>> During the last months I used Haskell for machine learning, particularly
>> in
>> the field of Echo State Neural Networks. The main drawback I encountered
>> is
>> that its difficult to visualize and plot data in Haskell in spite the fact
>> there are a couple of plotting libraries. Data visualization is very
>> important in the field of machine learning research (not so much in
>> machine
>> learning implementation) since humans are very efficient to analyze
>> graphical input to figure out what is going on in order to determine
>> possible adjustments. I was wondering if other members of the community
>> have experienced this drawback and would be interested in improved data
>> visualization for Haskell, especially if there is interest to use Haskell
>> for machine learning research. I collected my ideas in the following page:
>>  
>> https://github.com/netogallo/**Visualizer.
>>  Please provide me with feedback
>> because if the proposal is interesting for the community I would start
>> working with it, even if it doesn't make it to this GSoC, but a project
>> like this will need a lot of collaboration for it to be successful.
>>
>
> Your project is very ambitious! In fact, too ambitious.
>
> Essentially, you want to build an interactive environment for evaluating
> Haskell expressions. The use case you have in mind is data visualization
> for machine learning, but that is just a special case. If you can zoom in
> and out of plots of infinite time series, you can zoom in and out of audio
> data, and then why not add an interactive synthesizer widget to create that
> audio data in the first place.
>
> Your idea decomposes into many parts, each of which would easily fill an
> entire GSoC project on their own.
>
> * GUI. Actually, we currently don't have a GUI library that is easy to
> install for everyone. Choosing wxHaskell or gtk2hs immediately separates
> your user base into three disjoint parts. I think it's possible to use the
> web browser as GUI instead ( HeinrichApfelmus/threepenny-**gui
> >).
>
> * Displaying Haskell values in a UI. You mentioned that you want matrices
> to come with a contextual menu where you can select different
> transformations on them. It's just a minor step to allow any Haskell
> function operating on them. I have a couple of ideas on how to do this is
> in a generic fashion. Unfortunately, the project from last year <
> http://hackage.haskell.org/**trac/summer-of-code/ticket/**1609>
> did not succeed satisfactorily. There were some other efforts, but I
> haven't seen anything released.
>
> * UI programming is hard. You could easily spend an entire project on
> implementing a single visualization, for instance an infinite time series
> with responsive zoom. It's not difficult to implement something, but adding
> the right level of polish so that people want to use it takes effort.
> There's a reason that Matlab costs money, and there's a reason that your
> mentor relies on it.
>
> * Functionality specific to machine learning. Converting Vector to a
> format suitable for representation of matrices, etc. This is your primary
> interest.
>
>
> Note that, unfortunately, the parts depend on each other from top to
> bottom. It's possible to write functionality specific to machine learning,
> but it would be of little impact if it doesn't come with a good UI.
>
>
> Best regards,
> Heinrich Apfelmus
>
> --
> http://apfelmus.nfshost.com
>
>
>
> __**_
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/**mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http:/

Re: [Haskell-cafe] GSoC proposal: Data Visualization

[Carter Schonwald]

Hello Ernesto,

There are a number of efforts underway to provide better data vis libraries
for haskell. Likewise, there was some recent discussion on the Diagrams
mailing list about data vis tooling, and there should be a few interesting
tools surfacing over the coming few months.


My immediate concern is that this project is too broad and undefined in
scope to be a successful Haskell GSOC.
A successful GSOC project should have
a) a clear notion of what project's goal is
b) clear evidence that the planned work can reasonably be done over the
summer
c) the result of a successful project would be  valuable to the general
haskell community

It sounds like the core of what you want to do is write a small lib that
transforms a data set from some initial "schema" into the "schema" thats
suitable for some underlying choice in plotting tool.  This is a useful
thing to do, but not large enough in scope for a GSOC project.

On the flip side, interactive data vis tools are *hard* to do well, and a
GSOC that proposed to work on that from scratch would be very very risky
unless you've spent a lot of time working on building such tools.


You're definitely pointing at region of library space where more nice tools
for haskell would be very valuable, and which a number of folks are trying
to address.  But, for GSOC, unless its a very very clearly laid out
proposal, it will be deemed too risky.

I warmly recommend you look at prior years' Haskell GSOC projects to get a
feel for what strong successful projects/proposals look like.


cheers
-Carter






On Fri, Apr 12, 2013 at 5:10 PM, Ernesto Rodriguez  wrote:

> Dear Haskell Community,
>
> During the last months I used Haskell for machine learning, particularly
> in the field of Echo State Neural Networks. The main drawback I encountered
> is that its difficult to visualize and plot data in Haskell in spite the
> fact there are a couple of plotting libraries. Data visualization is very
> important in the field of machine learning research (not so much in machine
> learning implementation) since humans are very efficient to analyze
> graphical input to figure out what is going on in order to determine
> possible adjustments. I was wondering if other members of the community
> have experienced this drawback and would be interested in improved data
> visualization for Haskell, especially if there is interest to use Haskell
> for machine learning research. I collected my ideas in the following page:
>  
> https://github.com/netogallo/Visualizer
>  .
> Please provide me with feedback because if the proposal is interesting for
> the community I would start working with it, even if it doesn't make it to
> this GSoC, but a project like this will need a lot of collaboration for it
> to be successful.
>
> Thank you very much,
>
> Best Regards,
>
> Ernesto
>
> --
> Ernesto Rodriguez
>
> Bachelor of Computer Science - Class of 2013
> Jacobs University Bremen
>
>
>
>
> ___
> 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] Compiled program using OpenGL fails to trigger GPU switch on Mac, but works in GHCi

[Carter Schonwald]

Hey Jesper,
thanks for the headsup!

please continue to share you findings on this matter, It sounds like it'll
be really useful for folks!

-Carter


On Mon, Mar 18, 2013 at 9:19 AM, Jesper Särnesjö  wrote:

> On Mon, Mar 18, 2013 at 11:27 AM, Brandon Allbery 
> wrote:
> > On Sun, Mar 17, 2013 at 7:58 PM, Jason Dagit  wrote:
> >> On Sat, Mar 16, 2013 at 6:53 PM, Jesper Särnesjö  >>>
> >>> To be clear, I think this isn't really an OpenGL problem, but rather
> >>> one related to FFI or event handling. If anyone could explain to me,The
> >>> release notes for 7.0.1 said this about that flag:
> >>
> >> There is a new -fno-ghci-sandbox flag, which stops GHCi running
> >> computations in a separate thread. In particular, this is useful for
> GLUT on
> >> OS X, which only works if being run on the main thread.
> >
> > Worth noting is that Jesper said it *works* in ghci, and fails when
> > compiled
>
> Interestingly, running the program in GHCi with the -fno-ghci-sandbox
> flag, causes it to misbehave in the same way as when compiled:
>
> $ ghci -fno-ghci-sandbox -lglfw glfw_test.hs
> [...]
> *Main> main
> Apple Software Renderer
>
> This is starting to smell like a concurrency-related issue, then. I
> should note that the GLFW library does use multiple OS threads, and I
> know from previous experience that Mac OS X is fussy about GUI actions
> being run on the main thread. The curious thing here, of course, is
> that the behavior I am seeing is the exact opposite of that mentioned
> in the release notes.
>
> I've found some interesting reading material on how GHC handles the
> interaction of concurrency and FFI, in particular the paper "Extending
> the Haskell Foreign Function Interface with Concurrency" by Simon
> Marlow and Simon Peyton-Jones [1], which even brings up OpenGL as an
> example of why a programmer must be able to "specify that a related
> group of foreign calls are all made by the same OS thread". I haven't
> yet had the time to dig too deep into this, but I have tried a few
> things:
>
> * I've compiled the program with -threaded (as suggested by John
> Lato), with the foreign functions marked as safe and unsafe (as
> suggested by Carter Schonwald).
> * I've checked that the main thread of my Haskell program is bound to
> an OS thread [2], which it is when using the threaded runtime. I've
> also tried explicitly running the block of foreign calls in a bound
> thread [3].
> * I've made sure that there is only one GLFW library on my machine for
> -lglfw to link with, and that it is the very same library my C program
> links with.
>
> None of the above helped. However, I will keep investigating and see
> what I find.
>
> As I final note, I did learn that the GHC runtime generates SIGVTALRM
> signals to cause the scheduler to switch contexts [4][5]. Perhaps this
> prevents GLFW from running properly? Looks like I'll need to brush up
> on my dtrace.
>
> --
> Jesper Särnesjö
> http://jesper.sarnesjo.org/
>
> [1] http://community.haskell.org/~simonmar/papers/conc-ffi.pdf
> [2]
> http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Concurrent.html#v:isCurrentThreadBound
> [3]
> http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Concurrent.html#v:runInBoundThread
> [4] http://joeyh.name/blog/entry/ghc_threaded_runtime_gotchas/
> [5]
> http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Signals#RTSAlarmSignalsandForeignLibraries
>
> ___
> 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] Compiled program using OpenGL fails to trigger GPU switch on Mac, but works in GHCi

[Carter Schonwald]

Hey Jesper:
hrm... have you tried other compilation / ffi choices that can influence
the function call?

eg: using the "safe" rather than "unsafe" modifier?
http://www.haskell.org/haskellwiki/GHC/Using_the_FFI#Introduction
(the safe modifier doesn't seem like it matters here, but its a simple
experiment to check)

likewise, another experiment would be write your own c code wrapper around
that opengl call, and  call that wrapper from haskell.

OH, and your code snippet isn't specifying *where* the glfw code is linked
from! might it be linking to the *wrong* variant of the library since
you're not specifying where the code is? You might want to set up a little
cabal configured project that specifies all of that stuff.

additionally, have you tried your code on ghc 7.6.2 ?  (do this last i
suppose)


I don't know if any of these ideas are actually helpful, but if they are,
please share what you've learned.

cheers
-Carter



On Sat, Mar 16, 2013 at 9:53 PM, Jesper Särnesjö  wrote:

> On Thu, Mar 14, 2013 at 12:51 AM, Jesper Särnesjö 
> wrote:
> > In short, I have two programs, one written in Haskell [1] and one
> > written in C [2], that consist of calls to the same functions, in the
> > same order, to the same C library, but which do not exhibit the same
> > behavior. Further, the Haskell program behaves differently when
> > compiled using GHC, and when run in GHCi. I would like to know why
> > this is, and how to fix it.
>
> To be clear, I think this isn't really an OpenGL problem, but rather
> one related to FFI or event handling. If anyone could explain to me,
> in general, how and why a call to a foreign function returning IO ()
> might cause different behavior in Haskell than in C, that might help
> me track down the problem.
>
> I've updated my test programs to use glGetString [3] to check which
> renderer is active. On my machine, it should return "NVIDIA GeForce GT
> 330M OpenGL Engine" if rendering happens on the discrete GPU, and
> "Intel HD Graphics OpenGL Engine" or "Apple Software Renderer"
> otherwise. These are the results of running the C and Haskell programs
> in various ways:
>
> $ gcc -lglfw -framework OpenGL glfw_test.c && ./a.out
> NVIDIA GeForce GT 330M OpenGL Engine
>
> $ ghc -lglfw -framework OpenGL -fforce-recomp glfw_test.hs &&
> ./glfw_test
> [...]
> Apple Software Renderer
>
> $ runhaskell -lglfw glfw_test.hs
> NVIDIA GeForce GT 330M OpenGL Engine
>
> $ ghci -lglfw glfw_test.hs
> [...]
> Prelude Main> main
> NVIDIA GeForce GT 330M OpenGL Engine
>
> The C program behaves as expected, as does the Haskell one when run
> using runhaskell or GHCi. Only the Haskell program compiled using GHC
> behaves incorrectly. Again, the OS event that signifies that a GPU
> switch has occurred fires either way, but for the compiled Haskell
> program, it fires with roughly a second's delay. Why would that be?
>
> --
> Jesper Särnesjö
> http://jesper.sarnesjo.org/
>
> [1] https://gist.github.com/sarnesjo/5151894#file-glfw_test-hs
> [2] https://gist.github.com/sarnesjo/5151894#file-glfw_test-c
> [3] http://www.opengl.org/sdk/docs/man3/xhtml/glGetString.xml
>
> ___
> 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] Optimization flag changing result of code execution

[Carter Schonwald]

Hey Azeem,
have you tried running the same calculation using rationals? Theres some
subtleties to writing numerically stable code using floats and doubles,
where simple optimizations change the orders of operations in ways that
*significantly* change the result. In this case it looks like you're
averaging the averages, which i *believe* can get pretty nasty in terms of
numerical precision.  Rationals would be a bit slower, but you could then
sort out which number is more correct.


On Fri, Mar 15, 2013 at 4:07 PM, Azeem -ul-Hasan  wrote:

> I was trying to solve a computational problem form James P Sethna's book
> Statistical Mechanics: Entropy, Order Parameters, and Complexity[1]. The
> problem is on page 19 of the pdf linked and is titled Six degrees of
> separation. For it I came up with this code: http://hpaste.org/84114
>   
> It runs fine when compiled with -O0 and consistently yields an answer
> around 10, but with -O1 and -O2 it consistently gives an answer around 25.
> Can somebody explain what is happening here?
>
> [1]
> http://pages.physics.cornell.edu/~sethna/StatMech/EntropyOrderParametersComplexity.pdf
>
> Azeem
>
>
> ___
> 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] Open-source projects for beginning Haskell students?

[Carter Schonwald]

+ 1000,

there are so many widely used niche libs which would greatly benefit from
more examples in their test suites, or which have tractable small
improvement / enhancement  tickets languishing.   Plus most large systems
engineering does involve helping improve preexisting some part of the time.


On Mon, Mar 11, 2013 at 10:52 PM, Michael Orlitzky wrote:

> On 03/11/2013 11:48 AM, Brent Yorgey wrote:
> >
> > So I'd like to do it again this time around, and am looking for
> > particular projects I can suggest to them.  Do you have an open-source
> > project with a few well-specified tasks that a relative beginner (see
> > below) could reasonably make a contribution towards in the space of
> > about four weeks? I'm aware that most tasks don't fit that profile,
> > but even complex projects usually have a few "simple-ish" tasks that
> > haven't yet been done just because "no one has gotten around to it
> > yet".
>
> It's not exciting, but adding doctest suites with examples to existing
> packages would be a great help.
>
>   * Good return on investment.
>
>   * Not too hard.
>
>   * The project is complete when you stop typing.
>
>
> ___
> 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] Embedded haskell?

[Carter Schonwald]

in addition to atom http://hackage.haskell.org/package/atom/

theres also copilot http://hackage.haskell.org/package/copilot

point being: theres lots of great tools you can use to target embedded
systems that leverage haskell in cool ways!

(eg: hArduino on the more hobbyist side, which I need to check out myself! )

enjoy your explorations!
-Carter


On Wed, Feb 20, 2013 at 10:51 PM, Jeremy Shaw  wrote:

> Ah, nice. Building Haskell applications on the Raspberry Pi which is a
> 32-bit 700 Mhz CPU with 512MB of RAM is still pretty painful. So, I
> think that running GHC on something even less powerful is probably not
> going to work well. But, handling a subset of Haskell for onsite
> programming could work. Using Haskell Source Extensions and the new
> Haskell Type Extensions should be enough to allow you to create an
> onboard mini-Haskell interpreter? It would actually be pretty neat to
> be able to extend all sorts of Haskell applications with a
> Haskell-subset scripting language..
>
> I'd definitely be interested in exploring this more. I recently got
> into multirotors and I am also working on a semi-autonomous rover
> project -- plus I just want to see Haskell used more in educational
> robotics (http://www.haskell.org/haskellwiki/RoboticOverlords).
>
> - jeremy
>
> On Wed, Feb 20, 2013 at 4:28 PM, Mike Meyer  wrote:
> > On Wed, Feb 20, 2013 at 4:01 PM, Jeremy Shaw 
> wrote:
> >> Another option would be to use Atom. I have successfully used it to
> >> target the arduino platform before. Running the entire OS on the
> >> embedded system seems dubious. Assuming you are using something the 9x
> >> family of transmitters -- they are slow and have very little internal
> >> memory. Plus trying to programming using a 6 buttons would be a royal
> >> pain. If you really want in-field programming, then you might at least
> >> using a raspberry pi with a small bluetooth keyboard and have it
> >> upload to the transmitter.
> >
> > Atom does look interesting. Thanks for the pointer.
> >
> > The target transmitter is the Walkera Devo line.  These have much more
> > capable CPUs than the various 9x boards: 32 bit ARMs at 72MHz with
> > comparable amounts of storage.  Some have 9x-like screen/button
> > combos, others have touch screens. The deviationTx software runs on
> > all of them.
> >
> > Settings are stored in a FAT file system that can be accessed as a USB
> > drive. I'm thinking that a traditional configuration interface on the
> > transmitter, storing the config information as program text. The only
> > actual programming would be done by replacing the virtual
> > channel/switch feature with expressions or short programs.
>
> ___
> 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] [Announcement] HsLlvm v0.1: Using Hoopl to optimize LLVM Code

[Carter Schonwald]

Hey Ning,
impressive start and I look forward to seeing how this evolves!

best
-Carter


On Tue, Feb 12, 2013 at 12:37 AM, Ning Wang  wrote:

>  My focus is on
>
> - Providing util to support developing LLVM->LLVM transformation
> - Providing EDSL to generate LLVM code (I'm thinking of something like
> alphaHeavy's LLVM combinators)
>
> I'm not aware of other effort to do native code generation from LLVM in
> Haskell.
>
> You can build them with HsLlvm, if there is a need to support your work,
> please let me know.  I believe the new GHC code generator is based on
> Hoopl, you might get inspiration from it.
>
> Cheers,
> Ning
>
>
>
> On 02/11/2013 03:13 AM, Alejandro Serrano Mena wrote:
>
> Hi,
> This seems a fantastic job!
>
>  Do you have any plan to support LLVM -> target phase, or do you know any
> project doing something similar?
>
>  Thanks in advance.
>
>
> 2013/2/11 Ning Wang 
>
>> Hi all,
>>
>> It is my dream for years to be able to manipulate LLVM in type safe
>> language. I has explored the possibility of reimplementing LLVM in Haskell
>> with Hoopl and made a small step to realize this dream. I am writing to
>> announce the release of HsLlvm v0.1, which is a pure Haskell implementation
>> (Not LLVM C++ binding) of LLVM. It is available through the link below.
>>
>> https://github.com/mlite/HsLlvm
>>
>> Hightlight of this release:
>> - Support LLVM 3.1 syntax
>> - LLVM normalization
>> - Dominator, mem2reg, DCE passes
>>
>>
>> Project goals:
>> - port all LLVM optimizations
>> - provide functionalities to generate and manipulate LLVM code.
>>
>> Since LLVM is a complex IR and there are many sophisticated
>> optimizations, this job won't be easy.  Your contribution would be of value
>> to eventually achieve this goal.
>>
>> Cheers,
>> Ning
>>
>>
>>
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] reviving HaNS (haskell network stack)

[Carter Schonwald]

wooops,
seems theres a galois repo on github here https://github.com/GaloisInc/HaNS




On Wed, Dec 12, 2012 at 3:04 PM, Carter Schonwald <
carter.schonw...@gmail.com> wrote:

> Hey All,
>
> I noticed that the really cool HaNS work
> (a mostly pure HS + bits of C networking stack)
> seems to have languished for quite some time, and the absence of a
> publicly visible repo certainly doesnt help!
>
> accordingly, i've taken the most recent code snapshot from the galois
> archive repo and created a copy on github!
>
> https://github.com/cartazio/HaNS
>
> I'll be having a go at trying to get things to build on ghc 7.6 + seeing
> about doing travisCI integration over the next few days, but if anyone else
> might be interested in helping out, that'd be welcome!
>
> cheers
> -Carter
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] reviving HaNS (haskell network stack)

[Carter Schonwald]

Hey All,

I noticed that the really cool HaNS work
(a mostly pure HS + bits of C networking stack)
seems to have languished for quite some time, and the absence of a publicly
visible repo certainly doesnt help!

accordingly, i've taken the most recent code snapshot from the galois
archive repo and created a copy on github!

https://github.com/cartazio/HaNS

I'll be having a go at trying to get things to build on ghc 7.6 + seeing
about doing travisCI integration over the next few days, but if anyone else
might be interested in helping out, that'd be welcome!

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

Re: [Haskell-cafe] Large, numerical calculations in Haskell

[Carter Schonwald]

Emil, there is an actively maintained set of FFTW bindings on hackage,
would that help you?

cheers
-Carter


On Wed, Dec 12, 2012 at 5:03 AM, Emil Hedevang wrote:

> Hi A.M. and Dominic,
>
> I have been following the development of Repa for some time, mostly
> reading blogs and papers about it, not actually writing any code. It's some
> quite cool stuff the developers are doing.
>
> A discrete convolution is a stencil computation. There are (to my
> knowledge) essentially two approaches to calculate a discrete convolutions
> Y = K * X:
> (1) from the definition, and
> (2) using discrete Fourier transforms
>
> Approach no. 1 runs in O(nK nX) where nK and nX are the number of elements
> in the arrays K and X, respectively, whereas approach no. 2 runs in O(nX
> log nX). If nK is very, very small, then approach no. 1 is fastest,
> otherwise approach no. 2 is fastest. If nK is somewhat smaller than nX,
> then some tricks can be applied to obtain something a bit faster than
> approach no. 2.
>
> To my knowledge, Repa applies approach no. 1 in its stencil computations
> and discrete convolutions. Therefore it cannot be applied in my case, since
> I have nK = 10^6 and nX = 10^9 (or something similar), and so I must use
> approach no. 2 with discrete Fourier transforms (DFT). In Repa, the DFT for
> arbitrary array sizes is implemented using the slow O(n^2) algorithm, i.e.,
> implemented using the definition of the DFT. If the size of the array is a
> power of two, then the DFT is implemented using the fast Fourier transform
> (FFT). Unfortunately, the Repa documentation states that the Repa FFT is
> approximately 50 times slower than the FFT from FFTW. (And the FFT from
> FFTW is even capable of calculating fast DFTs of arbitrary size). This
> essentially forces my to use FFTW for the actual number crunching.
>
> I suppose it would be a very interesting research project to implement
> FFTW entirely in Haskell. Unfortunately, I currently do not have the time
> to embark on such a quest.
>
> Regarding the generation of random numbers, Repa implements what they call
> a minimal standard Lehmer generator. I am not sure if that random number
> generator is of high enough qualify for my needs.
>
> Cheers,
> Emil
>
>
> On 12 December 2012 10:15, Dominic Steinitz  wrote:
>
>> Emil Hedevang  gmail.com> writes:
>>
>> >
>> >
>> > Hi Haskell Cafe,
>> >
>> > I need to perform very large numerical computations requiring tens of
>> GB of
>> memory. The computations consist essentially of generation of random
>> numbers
>> and discrete convolutions of large arrays of random numbers with somewhat
>> smaller kernel arrays. Should I use Haskell and call some C libraries when
>> necessary? Should I just write everything in C? Or should I use e.g.
>> Chapel
>> (chapel.cray.com)?
>> >
>> >
>> Hi Emil,
>>
>> The first place I would look would be repa http://repa.ouroborus.net/.
>> IIRC it
>> supports discrete convolutions and repa folks seem quite responsive.
>>
>> Dominic.
>>
>> PS I am planning to use repa to solve PDEs and address, at least
>> partially, "the curse of dimensionality" with it.
>>
>>
>>
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Is anyone working on a sparse matrix library in Haskell?

[Carter Schonwald]

I look forward to see what comes of this!



On Fri, Nov 30, 2012 at 4:58 PM, Mark Flamer  wrote:

> Thanks for all the replies,
>  It sounds like there is enough interest and even some potential
> collaborators out there. I have created a few data structures to represent
> sparse vectors and matrices. The vector was a simple binary tree and the
> matrix a quad tree. As I suspected a standard IntMap was around 3X as fast
> as my binary tree, so I have switched to the IntMap for now. I was hoping
> to
> hold on to my quad tree for the matrix rep. because I like the elegance of
> the recursive algorithms like Strassen’s for multiplication. In the end it
> will most likely be best to have a few different matrix representations
> anyway. For instance, I know that compressed row form is most efficient for
> certain algorithms. I have a Gauss iterative solver working currently and
> am
> thinking of moving on to a parallel Conjugate gradient or direct solver
> using LU decomposition. I’m no expert in Haskell or numeric methods but I
> do
> my best. I’ll clean up what I have and open up the project on Github or
> Bitbucket. Any other thoughts or ideas are welcome.
> I’m currently using the Matrix Market files for testing. It would be nice
> to
> benchmark this against an industry standard solver in C or Fortran, without
> having to do a lot of work to set it up. Does anyone know of an easy way to
> do this? I’m just trying to get results to compare in orders of magnitude
> for now. It would be motivating to see these comparisons.
>
>
>
>
> --
> View this message in context:
> http://haskell.1045720.n5.nabble.com/Is-anyone-working-on-a-sparse-matrix-library-in-Haskell-tp5721452p5721556.html
> Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Taking over ghc-core

[Carter Schonwald]

how would ghc-core enable targetting core for Agda?


On Wed, Nov 14, 2012 at 6:32 PM, Andreas Abel wrote:

> Excellent!
>
> With ghc-core being maintained again, we can start thinking about
> compiling Agda to core instead of hs.
>
> Andreas
>
>
> On 11.11.12 11:41 AM, Bas van Dijk wrote:
>
>> Great!
>>
>> On 10 November 2012 16:17, Shachaf Ben-Kiki  wrote:
>>
>>> With Don Stewart's blessing
>>> (>),
>>> I'll be
>>> taking over maintainership of ghc-core, which hasn't been updated
>>> since 2010. I'll release a version with support for GHC 7.6 later
>>> today.
>>>
>>>  Shachaf
>>>
>>
>> __**_
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/**mailman/listinfo/haskell-cafe
>>
>>
> --
> Andreas Abel  <><  Du bist der geliebte Mensch.
>
> Theoretical Computer Science, University of Munich
> Oettingenstr. 67, D-80538 Munich, GERMANY
>
> andreas.a...@ifi.lmu.de
> http://www2.tcs.ifi.lmu.de/~**abel/ 
>
>
> __**_
> 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: fixed-vector

[Carter Schonwald]

Michael, I think that calls for a type-class!
(though I imagine theres a slicker way of writing it)


On Sun, Nov 11, 2012 at 11:18 PM, Michael Orlitzky wrote:

> On 11/10/2012 06:59 AM, Aleksey Khudyakov wrote:
> > Hello cafe!
> >
> > I want to announce library for the small vectors of fixed length
> > fixed-vector[1]. Fixed means that vector's length is determined
> > by its type.
> >
> > Generic API can work with both ATD-based vector like complex or
> > Vec written below and array-based ones.
> >
> >> data Vec a = Vec a a a
> >
> > It's based on post by Roman Leschinsiy[2].
> >
> >
> > Library also provide array-based vectors with memory
> > representation similar to onves from vector package. It's more
> > compact though because there is no need to store lengh and and
> > offset to first element.
> >
> > [1] http://hackage.haskell.org/package/fixed-vector
> > [2]
> http://unlines.wordpress.com/2010/11/15/generics-for-small-fixed-size-vectors/
>
>
> I have a lot of one-off code where I've defined these myself. Is it
> possible to e.g. define vectors in R^2 and R^3, and write the p-norm
> functions only once?
>
> ___
> 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] Why doesn't GHC optimize recursive functions by converting them into `let`?

[Carter Schonwald]

Hey Petr, interesting post! (and links)
I imagine that one issue that would make it not a default activity by GHC
is that this sort of strategy has the following implications:

1) ghc in general doesn't always want to inline in general, inlining
increases the size of code! and depending on how that happens that can
increase compilation time and sometime decrease performance. That said,
there are many instances where perfomance is

2) This approach *can* be extended to mutually recursive functions, but
again, the naive inlining to "depth k" would have on the order of ~ 2^k
code blow up potentially (or so I think offhand)

theres probably a few other problems with doing this automatically, but it
looks like a nice performance trick I may consider using time.

cheers
-Carter



On Thu, Nov 8, 2012 at 10:00 AM, Petr P  wrote:

>   Hi,
>
> recently I found out that some recursive functions can be greatly
> optimized just by rewriting them using `let` so that they're not recursive
> themselves any more (only the inner let is). To give an example:
>
> > fix :: (a -> a) -> a
> > fix f = f (fix f)
>
> isn't optimized, because it's a recursive function and so it isn't inlined
> or anything. However, defining it as
>
> > fix f = let x = f x in x
>
> makes it much more efficient, since `fix` is not recursive any more, so it
> gets inlined and then optimized for a given argument `f`.
> (See
> http://stackoverflow.com/questions/12999385/why-does-ghc-make-fix-so-confounding
> )
>
> Another example is the well-known generic catamorphism function:
>
> > newtype Fix f = Fix { unfix :: f (Fix f) }
> >
> > catam :: (Functor f) => (f a -> a) -> (Fix f -> a)
> > catam f = f . fmap (catam f) . unfix
>
> is not optimized. When `catam` is used on a data structure such as [] or a
> tree, at each level `fmap` creates new constructors that are immediately
> consumed by `f`. But when written as
>
> > catam f = let u = f . fmap u . unfix in u
>
> this gets inlined and then optimized, and constructor creation/consumption
> is fused into very effective code.
> (See http://stackoverflow.com/q/13099203/1333025)
>
> As one comment asked, this seems like something GHC could do
> automatically. Would it be difficult? Is there a reason against it? I
> suppose in cases where it doesn't help, the additional `let` would get
> optimized away, so no harm would be done. And in cases like `fix` or
> `catam` the gain would be substantial.
>
>   Best regards,
>Petr
>
> ___
> 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] Ordering of BigFloats in numbers-3000.0.0.0

[Carter Schonwald]

you should probably file a ticket on the DanBurton repo if he's the one
doing the uploading
 :-)


On Tue, Oct 9, 2012 at 12:55 PM, Michael Orlitzky wrote:

> On 10/09/2012 12:29 PM, Chaddaï Fouché wrote:
> > On Sun, Oct 7, 2012 at 8:00 PM, Michael Orlitzky 
> wrote:
> >> I'm trying to use,
> >>
> >>   http://hackage.haskell.org/package/numbers-3000.0.0.0
> >>
> >> to get better precision "for free" out of some numerical code. I ran
> >> into an issue pretty quickly, though. In Data.Number.BigFloat, we have,
> >>
> >>   data BigFloat e = BF (Fixed e) Integer
> >> deriving (Eq, Ord)
> >>
> >> and the derived Ord is obviously incorrect:
> >>
> >>   Prelude Data.Number.BigFloat> let x = 0.1 :: BigFloat Prec50
> >>   Prelude Data.Number.BigFloat> let y = 0.02 :: BigFloat Prec50
> >>   Prelude Data.Number.BigFloat> x < y
> >>   True
> >>
> >
> > That's pretty strange since the derived Ord should be the same as
> > Fixed Ord, which itself is just a newtype over Rational (and 1%10 <
> > 2%100 == False), did you try to convert those BigFloat back to
> > Rational to see if they're still correct ? That may be worse than a
> > misbehaving Ord instance.
> >
>
> The BigFloat constructor doesn't do what you think it does... I chose a
> bad spot to snip the comments:
>
>   -- This representation is stupid, two Integers makes more sense,
>   -- but is more work.
>   -- | Floating point number where the precision is determined by the
>   --   type /e/.
>   data BigFloat e = BF (Fixed e) Integer
> deriving (Eq)
>
> If it was two Integers, I think it would be more clear that this is what
> will happen:
>
>   *Data.Number.BigFloat> let x = 0.1 :: BigFloat Prec50
>   *Data.Number.BigFloat> let y = 0.02 :: BigFloat Prec50
>   *Data.Number.BigFloat> let BF m1 e1 = x
>   *Data.Number.BigFloat> let BF m2 e2 = y
>   *Data.Number.BigFloat> (m1,e1)
>   (1.00,-1)
>   *Data.Number.BigFloat> (m2,e2)
>   (2.00,-2)
>
> The fast way to compare them would be to check the mantissa/exponent
> directly, but toRational works just fine. I made a pull request
> yesterday that compares them as rationals.
>
> ___
> 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] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?

[Carter Schonwald]

Eugene: I think thats a bug / ticket for the haskell platform trac, rather
than ghc's trac.

look forward to seeing how to reproduce those problems / helping fix em!

On Mon, Oct 8, 2012 at 3:08 PM, Eugene Kirpichov wrote:

> Johan, should I also file the bugreport "remove the suggestion to
> install 32-bit platform" there, or is there a different place for bugs
> of the platform website?
>
> On Mon, Oct 8, 2012 at 7:25 AM, Johan Tibell 
> wrote:
> > On Mon, Oct 8, 2012 at 3:28 AM, Christiaan Baaij
> >  wrote:
> >> Hi,
> >>
> >> I finally found another OS X mountain lion install and can confirm the
> behaviour I described earlier:
> >> 32-bit: compiled code works, interpreted code works
> >> 64-bit: compiled code works, interpreted code fails
> >>
> >> Here's the test case:
> >> - cabal install gloss --flags"-GLUT GLFW"
> >> - cabal unpack gloss-examples
> >> - cd gloss-examples-1.7.6.2/picture/GameEvent
> >> - ghci -fno-ghci-sandbox Main.hs
> >> - main
> >>
> >> I get the following crash report: http://pastebin.com/jZjfFtm7
> >>
> >> The weird thing is the following:
> >> When I run 'ghci' from inside 'gdb' (to find the origin for the
> segfault), everything works fine:
> >> ghci: segfault
> >> ghci from gdb: everything works
> >>
> >> I have no idea what's going on, so if anyone has any pointers on how to
> make sure ghci behaves the same in gdb please let me know.
> >
> > Could you please file a bug report at:
> >
> > http://hackage.haskell.org/trac/ghc/
> >
> > Thanks!
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>
> --
> Eugene Kirpichov
> http://www.linkedin.com/in/eugenekirpichov
> We're hiring! http://tinyurl.com/mirantis-openstack-engineer
>
> ___
> 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] Strange things with type literals of kind Nat

[Carter Schonwald]

Hello Troels,
there is no solver included with ghc 7.6, if you wish to experiment with
equational reasoning with the type level nats, you'll have to look into the
ghc type-lits branch which includes a solver.

(yes, confusng, but true)

On Tue, Oct 2, 2012 at 2:54 PM, Troels Henriksen  wrote:

> Consider the following definition of lists with a statically determined
> minimum length.
>
> data Nat' = Z | S Nat'
>
> data NList (n::Nat') a where
>   Rest :: [a] -> NList Z a
>   (:>) :: a -> NList n a -> NList (S n) a
>
> uncons :: NList (S n) a -> (a, NList n a)
> uncons (x :> xs) = (x, xs)
>
> This works fine.  Now consider an implementation using the new type
> literals in GHC:
>
> data NList (n::Nat) a where
>   Rest :: NList 0 [a]
>   (:>) :: a -> NList n a -> NList (n+1) a
>
> uncons :: NList (n+1) a -> NList n a
> uncons (x :> l) = l
>
> This gives a type error:
>
> /home/athas/code/nonempty_lists.hs:41:19:
> Could not deduce (n1 ~ n)
> from the context ((n + 1) ~ (n1 + 1))
>   bound by a pattern with constructor
>  :> :: forall a (n :: Nat). a -> NList n a -> NList (n +
> 1) a,
>in an equation for `uncons'
>   at /home/athas/code/nonempty_lists.hs:41:9-14
>   `n1' is a rigid type variable bound by
>a pattern with constructor
>  :> :: forall a (n :: Nat). a -> NList n a -> NList (n + 1) a,
>in an equation for `uncons'
>at /home/athas/code/nonempty_lists.hs:41:9
>   `n' is a rigid type variable bound by
>   the type signature for uncons :: NList (n + 1) a -> NList n a
>   at /home/athas/code/nonempty_lists.hs:40:11
> Expected type: NList n a
>   Actual type: NList n1 a
> In the expression: l
> In an equation for `uncons': uncons (x :> l) = l
>
> I don't understand why GHC cannot infer that the two types are the same.
> My guess is that 'n+1' is not "structural" to GHC in the same way that
> 'S n' is.  The page
> http://hackage.haskell.org/trac/ghc/wiki/TypeNats/MatchingOnNats
> mentions that "type level numbers of kind Nat have no structure", which
> seems to support my suspicion.  What's the complete story, though?
>
> --
> \  Troels
> /\ Henriksen
>
> ___
> 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] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?

[Carter Schonwald]

do these problems also happen if your'e using the glut backend? (because if
its only glfw that has problems, then its something wrong in the ffi code,
but if its both, that suggests there may be some sort of systematic
problem?)

@Lyndon, that sounds like a bug... especially since scotty seems to have no
C code in package... have you filed a bug report with the maintainers thats
reproducible?

On Thu, Sep 27, 2012 at 3:49 AM, Lyndon Maydwell  wrote:

> I'm experiencing the same issues with compiled 64 bit working
> correctly, but interpreted causing all sorts of issues with Scotty.
>
> On Thu, Sep 27, 2012 at 3:45 PM, Christiaan Baaij
>  wrote:
> > The behaviour seems to differ between versions of OS X.
> >
> > A student has OS X 10.8 installed and is observing the described
> behaviour:
> > 32-bit: interpreted and compiled work correctly
> > 64-bit: only compiled code works correctly
> >
> > However, I have OS X 10.6, and I'm observing the following behaviour:
> > 32-bit: interpreted and compiled code work correctly
> > 64-bit: interpreted and compiled code work correctly
> >
> > To test:
> > cabal install gloss --flags="-GLUT GLFW"
> > cabal unpack gloss-examples
> > cd /picture/GameEvent
> > ghci -fno-ghci-sandbox Main.hs
> > main
> >
> > I'll try to find another OS X 10.8 install (I don't want to upgrade) and
> see if the behaviour still emerges.
> >
> >
> > On Sep 26, 2012, at 11:03 PM, Carter Schonwald wrote:
> >
> >> really? does the 64 bit code work correctly when compiled?
> >> if the compiled version works correctly, could you post a repo of some
> example codlets that *should work* on ghc 7.6 so i can sort out if its
> fixable.   There were some similar problems with gtk / cairo for a while on
> OS X, and i was able to sort out reproducible instructions for getting
> things to work in that case.
> >
> > ___
> > 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] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?

[Carter Schonwald]

really? does the 64 bit code work correctly when compiled?
if the compiled version works correctly, could you post a repo of some
example codlets that *should work* on ghc 7.6 so i can sort out if its
fixable.   There were some similar problems with gtk / cairo for a while on
OS X, and i was able to sort out reproducible instructions for getting
things to work in that case.





On Wed, Sep 26, 2012 at 10:43 AM, Christiaan Baaij <
christiaan.ba...@gmail.com> wrote:

> Running gloss [1] programs from GHCi only works with the 32bit version of
> the latest Haskell Platform.
> The 64-bit version just shows a black window and GHCi becomes unresponsive.
>
> I use gloss to display trees and graphs in the functional programming
> course given at our university.
> The ability to work within the interpreter, and able to depict the
> graphs/trees, really enhances the student's understanding of their programs.
>
> I am hence glad that there is still the 32-bit recommendation for OS X.
>
> Cheers,
>
> Christiaan
>
> [1] http://hackage.haskell.org/package/gloss - install with: cabal
> install gloss --flags="-GLUT GLFW"
>
>
> On Sep 26, 2012, at 1:16 PM, Bob Hutchison wrote:
>
> >
> > On 2012-09-26, at 1:44 AM, Carter Schonwald 
> wrote:
> >
> >> what can we (the community ) do to address the fact that the haskell
> platform installer suggestions for os x are sadly completely backwards? (or
> am I completely wrong in my personal stance on this matter)
> >>
> >
> > I'd much prefer the 64 bit myself, unfortunately
> http://hackage.haskell.org/trac/ghc/ticket/7040 affects the current
> version of the Haskell Platform. It's fixed in 7.6.x. This bug prevents me
> from using Yesod with the 64 bit version of 7.4.2, and it's not just Yesod
> affected…
> >
> > Cheers,
> > Bob
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?

[Carter Schonwald]

Hi Eugene,
To the best of my knowledge there is absolutely no reason to use the 32bit
haskell on OS X (aside from memory usage optimization cases which likely do
not matter to the *typical* user), and the community should probably update
the recommendation to reflect this.

I can certainly attest to having to baby sit new haskellers when installing
and repeatedly say  "yes, do the 64 bit version, please, no, ignore the
recommendation for 32bit, no one knows why its there, but its wrong"

what can we (the community ) do to address the fact that the haskell
platform installer suggestions for os x are sadly completely backwards? (or
am I completely wrong in my personal stance on this matter)

cheers
-Carter

On Tue, Sep 25, 2012 at 7:52 PM, Eugene Kirpichov wrote:

> Hi,
>
> I installed Haskell Platform 32-bit on a fresh 64-bit mac, because the
> page http://www.haskell.org/platform/mac.html says: "Pick the 32-bit
> vesion, unless you have a specific reason to use the 64-bit version.
> The 32-bit one is slightly faster for most programs."
>
> Then, during the installation of a package, the following happeed:
>
> Loading package cairo-0.12.3.1 ... : can't load .so/.DLL
> for: /opt/local/lib/libz.dylib (dlopen(/opt/local/lib/libz.dylib, 9):
> no suitable image found.  Did find:
> /opt/local/lib/libz.dylib: mach-o, but wrong architecture)
>
> That libz.dylib is a 64-bit library and it can't be used by 32-bit
> Haskell platform.
>
> QUESTION: It seems to me that most people, at least most who care
> about "slightly faster" programs, are likely to run into something
> like this - using native 64-bit libraries. Compatibility exists only
> in the opposite direction. Wouldn't it be appropriate to remove this
> notice and ask people to use the 64-bit version unless they have a
> specific reason not to?
>
>
> --
> Eugene Kirpichov
> http://www.linkedin.com/in/eugenekirpichov
> We're hiring! http://tinyurl.com/mirantis-openstack-engineer
>
> ___
> 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] Haskell seems setup for iterative numerics; i.e. a standard example is Newton's method where lazy evaluation ...

[Carter Schonwald]

in the mean time I suggest using Hmatrix then :)

On Wed, Sep 5, 2012 at 4:10 PM, KC  wrote:

> The REPA package/library doesn't have LU factorization, eigenvalues, etc.
>
>
> On Wed, Sep 5, 2012 at 12:59 PM, Carter Schonwald
>  wrote:
> > Hello KC,
> > you should check out the Repa library then and see how it works for you.
> > Cheers
> > -Carter
> >
> > On Wed, Sep 5, 2012 at 12:46 PM, KC  wrote:
> >>
> >> separates control from computation.
> >>
> >> It seems as if Haskell would be better for iterative matrix methods
> >> rather than direct calculation.
> >>
> >> --
> >> --
> >> Regards,
> >> KC
> >>
> >> ___
> >> Haskell-Cafe mailing list
> >> Haskell-Cafe@haskell.org
> >> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> >
>
>
>
> --
> --
> Regards,
> KC
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskell seems setup for iterative numerics; i.e. a standard example is Newton's method where lazy evaluation ...

[Carter Schonwald]

Hello KC,
you should check out the Repa library then and see how it works for you.
Cheers
-Carter

On Wed, Sep 5, 2012 at 12:46 PM, KC  wrote:

> separates control from computation.
>
> It seems as if Haskell would be better for iterative matrix methods
> rather than direct calculation.
>
> --
> --
> Regards,
> KC
>
> ___
> 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] hellno - a somewhat different approach to tackling cabal hell

[Carter Schonwald]

perhaps the *right* solution is to view that as a bootstrap build, and then
have hellno build itself?  :)
That said, its also an executable rather than library, so its not quite the
same problem.

On Sun, Sep 2, 2012 at 11:15 PM, Richard Wallace <
rwall...@thewallacepack.net> wrote:

> I like the approach so far.  But hellno itself seems to have several
> dependencies itself.  So installing with cabal pulls these in as
> "fixed" libraries ("text", "mtl", "transformers", and "parsec").  Any
> plans to make these not have to be fixed? Or is there a trick I'm
> missing?
>
> On Sun, Sep 2, 2012 at 11:25 AM, Danny B  wrote:
> > Like many of us, I've suffered from cabal dependency hell and sought
> relief.
> >
> > I wasn't exactly happy with sandboxes - because using per-project ones
> > meant package duplication and shared sandboxes suffer from the same
> > issues as the GHC package database itself, i.e. reinstalls can break
> > other projects, etc. So I wrote hellno, which is so named because that's
> > the expression one makes when seeing cabal hell suddenly manifest itself
> > and that's also the expression one makes upon encountering yet ANOTHER
> > cabal wrapper.
> >
> > To quote the README:
> >> Generally, with hellno you'll get the same result as for blowing away
> your user
> >> package database and doing a nice clean install but without having to
> recompile
> >> everything and with ability to easily revert back and change between
> projects.
> >
> > Hellno works by keeping all the compiled packages to itself in a
> > database, so that when you ask it to bring in the dependencies of a
> > project, it will use the precompiled packages if available or install
> > the deps and save them for later reuse.
> >
> > Hellno puts symlinks in the user package database pointing to packages
> > in its storage to make them visible. Mutating the user db is hardly
> > elegant, although shouldn't result in much trouble.
> >
> > It's been working fine for me, so I figured it may be useful to others.
> > You can get hellno from GitHub:
> > https://github.com/db81/hellno
> >
> > I don't mean to say that sandboxing is inherently bad or should not be
> > used, but I guess it's better to consider more than one way.
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] hellno - a somewhat different approach to tackling cabal hell

[Carter Schonwald]

awesome! I look forward to playing with this and hopefully saying "hell
yeah" when i'm done :)
-Carter

On Sun, Sep 2, 2012 at 2:51 PM, Niklas Hambüchen  wrote:

> Hell yeah!
>
> Looks like a nice approach.
>
> On Sun 02 Sep 2012 19:25:08 BST, Danny B wrote:
> > Like many of us, I've suffered from cabal dependency hell and sought
> relief.
> >
> > I wasn't exactly happy with sandboxes - because using per-project ones
> > meant package duplication and shared sandboxes suffer from the same
> > issues as the GHC package database itself, i.e. reinstalls can break
> > other projects, etc. So I wrote hellno, which is so named because that's
> > the expression one makes when seeing cabal hell suddenly manifest itself
> > and that's also the expression one makes upon encountering yet ANOTHER
> > cabal wrapper.
> >
> > To quote the README:
> >> Generally, with hellno you'll get the same result as for blowing away
> your user
> >> package database and doing a nice clean install but without having to
> recompile
> >> everything and with ability to easily revert back and change between
> projects.
> >
> > Hellno works by keeping all the compiled packages to itself in a
> > database, so that when you ask it to bring in the dependencies of a
> > project, it will use the precompiled packages if available or install
> > the deps and save them for later reuse.
> >
> > Hellno puts symlinks in the user package database pointing to packages
> > in its storage to make them visible. Mutating the user db is hardly
> > elegant, although shouldn't result in much trouble.
> >
> > It's been working fine for me, so I figured it may be useful to others.
> > You can get hellno from GitHub:
> > https://github.com/db81/hellno
> >
> > I don't mean to say that sandboxing is inherently bad or should not be
> > used, but I guess it's better to consider more than one way.
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] A first glimps on the {-# NOUPDATE #-} pragma

[Carter Schonwald]

You got me there. Excellent point

On Tuesday, August 28, 2012, Yves Parès wrote:

> Monad? Simple strictness anotation is enough in that case:
>
> upd_noupd n =
> let l = myenum' 0 n
> h = head l
> in h `seq` last l + h
>
> Le mardi 28 août 2012 22:39:09 UTC+2, Carter Schonwald a écrit :
>>
>> Hey Joachim,
>> isn't this an example where the exact same issue could be solved via some
>> suitable use of a monad for ordering those two computations on l?
>>
>> cheers
>> -Carter
>>
>> On Tue, Aug 28, 2012 at 12:44 PM, Joachim Breitner wrote:
>>
>>> Dear GHC users,
>>>
>>> I am experimenting with ways to /prevent/ sharing in Haskell, e.g. to
>>> avoid space leaks or to speed up evaluation. A first attempt was to
>>> duplicate closures on the heap to preserve the original one, see
>>> http://arxiv.org/abs/1207.2017 for a detailed description and
>>> information on the prototype implementation; no GHC patching required
>>> for that.
>>>
>>> Currently I am trying a different angle: Simply avoid generating the
>>> code that will update a closure after its evaluation; hence the closure
>>> stays a thunk and will happily re-evaluate the next time it is used.
>>>
>>> Here is a classical example. Take this function (it is basically [f..t]
>>> but with a fixed type and no risk of existing rules firing):
>>>
>>> myenum :: Int -> Int -> [Int]
>>> myenum f t = if f <= t
>>>  then f : myenum (f + 1) t
>>>  else []
>>>
>>> and this example where sharing hurts performance badly:
>>>
>>> upd_upd n =
>>> let l = myenum 0 n
>>> in last l + head l
>>>
>>> The problem is that during the evaluation of "last l", the list is live
>>> and needs to be kept in memory, although in this case, re-evaluating l
>>> for "head l" would be cheaper. If n is 5000, then this takes 3845ms
>>> on my machine, measured with criterion, and a considerable amount of
>>> memory (3000MB).
>>>
>>> So here is what you can do now: You can mark the value as
>>> non-updateable. We change myenum to
>>>
>>> myenum' :: Int -> Int -> [Int]
>>> myenum' f t = if f <= t then f : ({-# NOUPDATE #-} myenum' (f +
>>> 1) t) else []
>>>
>>> and use that:
>>>
>>> upd_noupd n =
>>> let l = myenum' 0 n
>>> in last l + head l
>>>
>>> The improvement is considerable: 531ms and not much memory used (18MB)
>>>
>>>
>>> Actually, it should suffice to put the pragma in the definition of l
>>> without touching myenum:
>>>
>>> noupd_noupd n =
>>> let l = {-# NOUPDATE #-} myenum 0 n
>>> in last l + head l
>>>
>>> but this does not work with -O due to other optimizations in GHC. (It
>>> does work without optimization.)
>>>
>>>
>>> The next step would be to think of conditions under which the compiler
>>> could automatically add the pragma, e.g. when it sees that evaluation a
>>> thunk is very cheap but will increase memory consumption considerable.
>>>
>>>
>>> Also this does not have to be a pragma; it could just as well be a
>>> function "noupdate :: a -> a" that is treated specially by the compiler,
>>> similar to the "inline" function.
>>>
>>>
>>> If you want to play around this, feel free to fetch it from the unshare
>>> branch of my ghc repository at 
>>> http://git.nomeata.de/?p=ghc.**git<http://git.nomeata.de/?p=ghc.git>or
>>> https://github.com/nomeata/ghc for the GitHub-lovers. Note that the
>>> branch is repeatedly rebased against ghc master.
>>>
>>>
>>> Greetings,
>>> Joachim
>>>
>>>
>>> --
>>> Dipl.-Math. Dipl.-Inform. Joachim Breitner
>>> Wissenschaftlicher Mitarbeiter
>>> http://pp.info.uni-karlsruhe.**de/~breitner<http://pp.info.uni-karlsruhe.de/%7Ebreitner>
>>>
>>> __**_
>>> Haskell-Cafe mailing list
>>> haskel...@haskell.org
>>> http://www.haskell.org/**mailman/listinfo/haskell-cafe<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] A first glimps on the {-# NOUPDATE #-} pragma

[Carter Schonwald]

Hey Joachim,
isn't this an example where the exact same issue could be solved via some
suitable use of a monad for ordering those two computations on l?

cheers
-Carter

On Tue, Aug 28, 2012 at 12:44 PM, Joachim Breitner  wrote:

> Dear GHC users,
>
> I am experimenting with ways to /prevent/ sharing in Haskell, e.g. to
> avoid space leaks or to speed up evaluation. A first attempt was to
> duplicate closures on the heap to preserve the original one, see
> http://arxiv.org/abs/1207.2017 for a detailed description and
> information on the prototype implementation; no GHC patching required
> for that.
>
> Currently I am trying a different angle: Simply avoid generating the
> code that will update a closure after its evaluation; hence the closure
> stays a thunk and will happily re-evaluate the next time it is used.
>
> Here is a classical example. Take this function (it is basically [f..t]
> but with a fixed type and no risk of existing rules firing):
>
> myenum :: Int -> Int -> [Int]
> myenum f t = if f <= t
>  then f : myenum (f + 1) t
>  else []
>
> and this example where sharing hurts performance badly:
>
> upd_upd n =
> let l = myenum 0 n
> in last l + head l
>
> The problem is that during the evaluation of "last l", the list is live
> and needs to be kept in memory, although in this case, re-evaluating l
> for "head l" would be cheaper. If n is 5000, then this takes 3845ms
> on my machine, measured with criterion, and a considerable amount of
> memory (3000MB).
>
> So here is what you can do now: You can mark the value as
> non-updateable. We change myenum to
>
> myenum' :: Int -> Int -> [Int]
> myenum' f t = if f <= t then f : ({-# NOUPDATE #-} myenum' (f + 1)
> t) else []
>
> and use that:
>
> upd_noupd n =
> let l = myenum' 0 n
> in last l + head l
>
> The improvement is considerable: 531ms and not much memory used (18MB)
>
>
> Actually, it should suffice to put the pragma in the definition of l
> without touching myenum:
>
> noupd_noupd n =
> let l = {-# NOUPDATE #-} myenum 0 n
> in last l + head l
>
> but this does not work with -O due to other optimizations in GHC. (It
> does work without optimization.)
>
>
> The next step would be to think of conditions under which the compiler
> could automatically add the pragma, e.g. when it sees that evaluation a
> thunk is very cheap but will increase memory consumption considerable.
>
>
> Also this does not have to be a pragma; it could just as well be a
> function "noupdate :: a -> a" that is treated specially by the compiler,
> similar to the "inline" function.
>
>
> If you want to play around this, feel free to fetch it from the unshare
> branch of my ghc repository at http://git.nomeata.de/?p=ghc.git or
> https://github.com/nomeata/ghc for the GitHub-lovers. Note that the
> branch is repeatedly rebased against ghc master.
>
>
> Greetings,
> Joachim
>
>
> --
> Dipl.-Math. Dipl.-Inform. Joachim Breitner
> Wissenschaftlicher Mitarbeiter
> http://pp.info.uni-karlsruhe.de/~breitner
>
> ___
> 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] Platform Versioning Policy: upper bounds are not our friends

[Carter Schonwald]

no one is disputing that there are conditional changes in dependencies
depending on library versions.

an interesting intermediate point would be have a notion of "testing with "
constraints in cabal and engineering cabal to support a
"--withTestedConstraints" to have a simple composable way of handling
constructing build plans.

at the end of the day, its an engineering problem coupled with a social
factors problem. Those are hard :)


On Wed, Aug 15, 2012 at 5:44 PM, Brandon Allbery wrote:

> On Wed, Aug 15, 2012 at 4:44 PM, Johan Tibell wrote:
>
>> On Wed, Aug 15, 2012 at 1:02 PM, Brandon Allbery 
>> wrote:
>> > So we are certain that the rounds of failures that led to their being
>> > *added* will never happen again?
>>
>> It would be useful to have some examples of these. I'm not sure we had
>>
>
> Upper package versions did not originally exist, and nobody wanted them.
>  You can see the result in at least half the packages on Hackage:  upper
> versions came in when base got broken up, and when bytestring was merged
> into base --- both of which caused massive breakage that apparently even
> the people around at the time and involved with it no longer remember.
>
> I'm not going to argue the point though; ignore history and remove them if
> you desire.
>
> --
> brandon s allbery  allber...@gmail.com
> wandering unix systems administrator (available) (412) 475-9364 vm/sms
>
>
> ___
> 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] Platform Versioning Policy: upper bounds are not our friends

[Carter Schonwald]

As someone who recurrently is nudging a large number of maintainers every
major ghc release to bump their bounds, I favor the no upper bounds
approach! :)

plus the whole improving ecosystem of build bot tools which play nice with
cabal et al that are cropping up mean that "in principal" we could debug
missing upper bounds via sort of temporal bisecting over the "event stream"
of maximum available versions at a given time to sort that. (but that piece
isn't that important)

more pragmatically, cabal when used with hackage doesn't let you override
version constraints, it just lets you add additional constraints. This
makes sense if we assume that the library author is saying "things will
definitely break if you violate them", but in practice upper bounds are
made up guesstimation.

YES, its presumably semantic versioning doesn't create a problem, but with
the hackage eco system, when dealing with intelligently engineering libs
that are regularly maintained, version upper bounds create more problems
than than solve.

just my two cents. (yes yes yes, please drop upper bounds!)

cheers
-Carter

On Wed, Aug 15, 2012 at 5:04 PM, Michael Blume  wrote:

> > it's usual for the existing upper bounds to refer to versions that don't
> exist at the time of writing (and hence can't be known to be stable).
>
> Well, known to be stable given semantic versioning, then.
>
> http://semver.org/
>
> On Wed, Aug 15, 2012 at 1:55 PM, Bryan O'Sullivan 
> wrote:
> > On Wed, Aug 15, 2012 at 1:50 PM, David Thomas 
> > wrote:
> >>
> >> Would it make sense to have a known-to-be-stable-though soft upper bound
> >> added proactively, and a known-to-break-above hard bound added
> reactively,
> >> so people can loosen gracefully as appropriate?
> >
> > I don't think so. It adds complexity, but more importantly it's usual for
> > the existing upper bounds to refer to versions that don't exist at the
> time
> > of writing (and hence can't be known to be stable).
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskell Platform - BSD License?

[Carter Schonwald]

it looks like ghc itself is under a BSD3 style license, if thats any help.
So per se, I think you can assume youre dealing with a BSD3 through and
through system.

see here for the ghc info
http://www.haskell.org/ghc/license

(this is something i've been sorting out for my own projects too, and to
the best of my knowledge its all bsd3)

admission: I'm actually likely to be providing a repackaging of ghc & the
haskell platform with some additional tools for data analysis / machine
learning to some enterprise customers come the fall, so thats why I have
any thoughts on this matter. (but bear in mind that folks are this list
aren't lawyers :) )

On Tue, Jul 31, 2012 at 7:46 AM, Sai Hemanth K  wrote:

> Thanks Magnus.
> I guess it means that the license of individual packages is what
> that matters.
> The platform on the whole does not have any single license.
>
> In other words, I cannot just say that am using haskell platform but that
> I have to say, I am using x,y and z libraries which in turn are using a, b,
> c and d libraries.
>
>
> > A quick search suggests that ..:
> Ouch! Apologies. Guess I was looking at all the wrong places or my
> google-fu is embarrassingly bad.
>
>
>
> Thanks again for the links!
>
> Hemanth K
>
>
> On Tue, Jul 31, 2012 at 4:41 PM, Magnus Therning wrote:
>
>> On Tue, Jul 31, 2012 at 12:29 PM, Sai Hemanth K 
>> wrote:
>> > Hi,
>> >
>> >
>> > I am trying to use haskell for building a tool (in a commercial
>> setting).  I
>> > am trying to figure out what all licenses are involved here.
>> > Is there a single license for the entire haskell platform (and the
>> runtime)
>> > or is it that I need to look at the individual licenses of all the
>> > libraries and tools that make up the platform and point to them
>> separately?
>> >
>> > The wikipedia page on haskell platform [0] says Haskell Platform is BSD
>> > licensed. But I do not find any such info elsewhere.
>> > Any pointers on this would be greatly appreciated,
>>
>> A quick search suggests that this still hasn't been decided:
>>
>> http://trac.haskell.org/haskell-platform/ticket/85
>>
>> http://trac.haskell.org/haskell-platform/wiki/AddingPackages#Interimlicensepolicy
>>
>> I believe it still holds that all packages included in
>> haskell-platform are BSD3 licensed.
>>
>> /M
>>
>> --
>> Magnus Therning  OpenPGP: 0xAB4DFBA4
>> email: mag...@therning.org   jabber: mag...@therning.org
>> twitter: magthe   http://therning.org/magnus
>>
>
>
>
> --
> I drink I am thunk.
>
> ___
> 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] Relational Algebra library: first version on GitHub

[Carter Schonwald]

Great / thanks!!! This will be incredibly helpful for some of my present
work. :-)

On Saturday, July 21, 2012, Paul Visschers wrote:

> Hello,
>
> A couple of weeks ago I asked if there was interest in a library that
> implements a type-safe relational algebra. The response was positive, so I
> have spruced up the code I had a bit and created a repository on GitHub at:
>
> https://github.com/PaulVisschers/relational-algebra
>
> It is a very rudimentary version. The code is not documented and there is
> only a very basic example database in Test.hs. It might be helpful to look
> at HaskellDB's PrimQuery and PrimExpr, as this library is mostly a direct
> copy from that (but typed). I will add some decent examples of expressions
> and queries shortly.
>
> If you check it out, please comment on it and let me know if you want to
> contribute. Since this is going to be my first release, any feedback is
> welcome.
>
> Paul Visschers
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Interest in typed relational algebra library?

[Carter Schonwald]

I'd be interested in at least playing with it.

On Saturday, July 7, 2012, Paul Visschers wrote:

> Hello,
>
> I've been out of the Haskell game for a bit, but now I'm back. A couple of
> years ago I made a small library that implements relational algebra with
> types so that malformed queries and other operations are caught at compile
> time. It is heavily based off of the internals of HaskellDB (see
> http://hackage.haskell.org/packages/archive/haskelldb/2.1.1/doc/html/Database-HaskellDB-PrimQuery.html),
> but types so that it can actually be used directly instead of having to use
> HaskellDB's query monad. Besides the joy of using relational algebra
> directly in your code, this also means that you can make query-optimizing
> code in a type-safe way, you can subquery results returned by the database
> directly without accessing the database again and you have more options
> when converting from relation algebra to SQL or another query language. The
> library isn't quite ready for release, but I might want to work on it a bit
> and then release it. Is anyone interested in such a library?
>
> Paul Visschers
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Two parallel libraries from Japan

[Carter Schonwald]

Thanks these look very interesting!

It seems that the parallelism is only available vai the JoinList module, am
i correct in thinking this (or at least that is the only place where it is
clearly inidicated in the haddock and source code).  Are there any plans to
leverage "Cloud Haskell" once the mature variant is released?
-Carter

On Thu, Jun 7, 2012 at 4:21 AM, Kazu Yamamoto  wrote:

> Hello cafe,
>
> I would like to announce two parallel libraries from Japan.
>
> - Paraiso (http://hackage.haskell.org/package/Paraiso)
>
>The purpose of this library is to design a high-level language for
>implementing explicit partial-differential equations solvers on
>supercomputers as well as today's advanced personal computers.
>
>Muranushi-san is also known as the author of Monadius and one of
>the two translators of "Learn you".
>
> - GTALib (http://hackage.haskell.org/package/GTALib)
>
>This package provides the core functionalities of the GTA
>(Generate, Test, and Aggregate) programming framework on Haskell
>See "Test, and Aggregate - A Calculation-based Framework for
>Systematic Parallel Programming with MapReduce" for more
>information.
>
> Regards,
>
> --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] Mac and Gtk2hs problem

[Carter Schonwald]

Thats almost certainly what happened.

 (and that HP detail even had an unfortunate effect of having the
machomebrew install defaults for ghc & haskell-platform default to 32bit
rather than 64bit for a while, though that was recently corrected)

On Thu, Jun 7, 2012 at 9:05 AM, Brandon Allbery  wrote:

> On Thu, Jun 7, 2012 at 8:40 AM, Heinrich Apfelmus <
> apfel...@quantentunnel.de> wrote:
>
>> Tanja Piechnick wrote:
>>
>>> Loading package glib-0.12.3.1 ... can't load .so/.DLL for: intl
>>> (dlopen(/usr/local/Cellar/**gettext/0.18.1.1/lib/libintl.**dylib,
>>> 9): no suitable image found.  Did find:
>>>
>>> /usr/local/Cellar/gettext/0.**18.1.1/lib/libintl.dylib:
>>> mach-o, but wrong architecture)
>>> *Main>
>>>
>>
>> That's a 64bit / 32bit problem. The gtk library you installed via
>> homebrew is probably 64bit while the GHC you use (7.0.4) seems to be 32bit.
>> Either you reinstall GTK with 32bit support, or you use the 64bit version
>> of the recently released Haskell Platform.
>>
>
> The 7.0.4 HP package strongly suggested use of the 32-bit package even on
> 64-bit systems, so this is very likely.
>
> --
> brandon s allbery  allber...@gmail.com
> wandering unix systems administrator (available) (412) 475-9364 vm/sms
>
>
> ___
> 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] Mac and Gtk2hs problem

[Carter Schonwald]

Also: if you have only very recently built gtk etc via mac homebrew, you
need to build the head version of gtk2hs and family. (there was a header
file / api change at some point regarding gtk, and only the darcs HEAD
version of gtk2hs et al has been updated to reflect that.)


On Wed, Jun 6, 2012 at 6:27 PM, Ivan Lazar Miljenovic <
ivan.miljeno...@gmail.com> wrote:

> On 7 June 2012 03:01, Tanja Piechnick 
> wrote:
> > Hey Haskell-Cafe,
> >
> > I would like to run GTK2HS on my Mac 10.6.8 but after the successful
> > installation with Homebrew of all modules (GTK+, GTK2HS) I get this
> failure
> > message:
> >
> > Prelude> :l guitest.hs
> >
> > guitest.hs:1:8:
> > Could not find module `Graphics.UI.Gtk':
> >   Use -v to see a list of the files searched for.
> > Failed, modules loaded: none.
>
> Just to confirm for us, as the same user can you please run the following:
>
>  ghc-pkg list gtk
>
> As well as:
>
>  ghc-pkg check
>
> >
> >
> > I always changed my PATH. This is the content of my PATH:
> >
> > /usr/bin
> > /bin
> > /usr/sbin
> > /sbin
> > /usr/local/bin
> > /Developer/usr/bin
> > /Users/tanjapiechnick/.cabal/bin
> > $HOME/.cabal/bin
>
> I don't think this is a PATH problem; possibly a problem with library
> paths.
>
> >
> > Is that correct? Where is the mistake?
> >
> > Thank you for any help!
> > Greetings from Namibia
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
>
>
> --
> Ivan Lazar Miljenovic
> ivan.miljeno...@gmail.com
> http://IvanMiljenovic.wordpress.com
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Error in installing dph-examples on Mac OS X 10.7.3

[Carter Schonwald]

ok, this is because i think you need a stand alone LLVM backend because ghc
7.4 provides some vectorization stuff that
dph uses, and  so i'd suggest installing llvm on its own, or maybe its that
dph calls llvm tools as its compliling?

eg
brew install llvm

because if you look in cabal file
http://hackage.haskell.org/packages/archive/dph-examples/0.6.1.3/dph-examples.cabal
you'll see that the build's have the -fllvm flag, and llvm as a standalone
backend isn't installed by developer tools or anything else you ahve

On Fri, Feb 10, 2012 at 2:40 PM, Brandon Allbery wrote:

> On Fri, Feb 10, 2012 at 13:38, mukesh tiwari  > wrote:
>
>> Hi Carter
>> Thank you for reply. My mac is 32 bit ( I remember having some issue
>> with ghc-7.2.1 64 bit on 32 bit machine but probably that was on
>> Linux ). I will give it a shot.
>>
>> Macintosh-0026bb610428:tmp mukesh$ uname -a
>> Darwin Macintosh-0026bb610428.local 11.3.0 Darwin Kernel Version
>> 11.3.0: Thu Jan 12 18:48:32 PST 2012; root:xnu-1699.24.23~1/
>> RELEASE_I386 i386
>>
>
> That just means you have the 32-bit kernel; 64-bit executables still work
> on most Intel-based Macs even with a 32-bit kernel (the exceptions being
> early Core 1-based machines), and only machines made within the past year
> or so boot to a 64-bit kernel by default.
>
>
>> Some where on the internet I saw that llvm comes with Xcode 4.2
>>
>
> I believe it was mentioned to you in #haskell that it is an incomplete
> LLVM distribution, and you need to install a full LLVM distribution for
> -fllvm to work properly.  IIRC you also need to avoid the just-released
> LLVM 3 (this may also be part of the problem with Xcode 4.2, which is
> actually a partial LLVM 3 prerelease).
>
> --
> brandon s allbery  allber...@gmail.com
> wandering unix systems administrator (available) (412) 475-9364 vm/sms
>
>
> ___
> 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] Error in installing dph-examples on Mac OS X 10.7.3

[Carter Schonwald]

/Users/mukesh/.ghc/i386-darwin-7.4.1/package.conf.d


you need the 64bit version of ghc on mac, not the 32 bit one, by default
all mac libs are 64 bit so this yields problems when linking to c libs


On Fri, Feb 10, 2012 at 10:58 AM, mukesh tiwari <
mukeshtiwari.ii...@gmail.com> wrote:

> Hi Carter
> Yes both of these packages gloss-1.6.1.1 , OpenGL-2.5.0.0 (
> http://hpaste.org/63397 ) are installed on my system.Could you please
> tell me how did you resolve the issue.
>
> Regards
> Mukesh Tiwari
>
> On Feb 10, 12:11 pm, Carter Schonwald 
> wrote:
> > It may be a problem with the gloss / opengl dependencies? do you have
> those
> > packages installed?
> >
> > I had similar trouble earlier this week wrt dph-examples, and that was
> the
> > root of the matter in my case
> >
> > -Carter
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Feb 9, 2012 at 7:04 PM, Ben Lippmeier 
> wrote:
> >
> > > On 10/02/2012, at 6:12 AM, mukesh tiwari wrote:
> >
> > > Hello all
> > > I am trying to install dph-examples on Mac OS X version 10.7.3 but
> getting this
> > > error <http://hpaste.org/57699>. I am using ghc-7.4.1.
> >
> > > This probably isn't DPH specific. Can you compile a "hello world"
> program
> > > with -fllvm?
> >
> > > Ben.
> >
> > > ___
> > > Haskell-Cafe mailing list
> > > haskell-c...@haskell.org
> > >http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> >
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-C...@haskell.orghttp://
> 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] Error in installing dph-examples on Mac OS X 10.7.3

[Carter Schonwald]

It may be a problem with the gloss / opengl dependencies? do you have those
packages installed?

I had similar trouble earlier this week wrt dph-examples, and that was the
root of the matter in my case

-Carter

On Thu, Feb 9, 2012 at 7:04 PM, Ben Lippmeier  wrote:

>
> On 10/02/2012, at 6:12 AM, mukesh tiwari wrote:
>
> Hello all
> I am trying to install dph-examples on Mac OS X version 10.7.3 but getting 
> this
> error . I am using ghc-7.4.1.
>
>
> This probably isn't DPH specific. Can you compile a "hello world" program
> with -fllvm?
>
> Ben.
>
> ___
> 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: combinatorics

[Carter Schonwald]

ditto

On Thu, Feb 2, 2012 at 4:06 PM, Ivan Lazar Miljenovic <
ivan.miljeno...@gmail.com> wrote:

> On 3 February 2012 07:11, Brent Yorgey  wrote:
> > On Wed, Feb 01, 2012 at 01:53:03AM -0500, wren ng thornton wrote:
> >>
> >> [2] HaskellForMaths, gamma, statistics, erf, math-functions,
> >> combinat,...
> >
> > To this list I'd like to add 'species' and also the specialized
> > 'multiset-comb' packages.  The former doesn't build under recent GHCs
> > but I plan to fix that (and continue extending the library) soon.
> >
> > Would people be interested in creating a mailing list for those
> > interested in combinatorics+Haskell?
>
> I would.
>
> >
> > -Brent
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>
> --
> Ivan Lazar Miljenovic
> ivan.miljeno...@gmail.com
> IvanMiljenovic.wordpress.com
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: mecha-0.0.5

[Carter Schonwald]

the algorithms in the CGAL library might be a good starting point in terms
of looking into other algorithmic approaches
http://www.cgal.org/
it has a excellent set of references for its component parts

On Sun, Jun 5, 2011 at 11:41 AM, Andrew Coppin
wrote:

> On 04/06/2011 08:25 PM, Tom Hawkins wrote:
>
>  What is the easiest way to generate polygon meshes from constructive
>> solid geometry?  Marching cubes [4] seems pretty involved.
>>
>
> As I understand it, this is a Very Hard Problem. This is (one of the
> reasons) why there are so few converters from POV-Ray to mesh-based formats;
> it's highly non-trivial to tesselate CSG.
>
>
> ___
> 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] Can't figure out cmap in hmatrix

[Carter Schonwald]

this is actually a bug in the type of cmap, a fix is due in the next release
(at least thats what Alberto indicated to me when I asked about this a
monthish ago) (note how you have the container type c e, but we want c a and
c b ). Instead  use the vector map or matrix map ops directly

cheers
-Carter schonwald

On Mon, May 30, 2011 at 3:27 PM, Mats Klingberg wrote:

> Hello,
>
> I'm playing around a bit with the hmatrix package (
> http://hackage.haskell.org/package/hmatrix) but can't quite figure out how
> to make the cmap function in Numeric.Container work.
>
> An example:
>
> ghci> import Numeric.LinearAlgebra
> ghci> let v = fromList [1.0,2.0,3.0]
> ghci> v
> fromList [1.0,2.0,3.0] :: Data.Vector.Storable.Vector
> ghci> :t v
> v :: Vector Double
> ghci> cmap sqrt v
>
> :1:1:
>No instance for (Container Vector e0)
>  arising from a use of `cmap'
>Possible fix: add an instance declaration for (Container Vector e0)
>In the expression: cmap sqrt v
>In an equation for `it': it = cmap sqrt v
>
> ghci> :t cmap
> cmap
>  :: (Container c e, Element b, Element a) => (a -> b) -> c a -> c b
>
> There is an instance for (Container Vector Double) but I assume that since
> the signature of cmap doesn't mention the type variable 'e' GHCi can't infer
> it. Googling hasn't helped me so far, except for digging up another post to
> this list with the same (?) problem, but no answer:
> http://www.haskell.org/pipermail/haskell-cafe/2011-April/091390.html
>
> Is there a way to tell GHC what instance to use, or how should cmap be
> used?
>
> Thanks!
> Mats
>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] typing hmatrix expressions

[Carter Schonwald]

hello alberto,
i've had some funny issues with using the cmap function, and i'd like
understand what i'm doing wrong
namely it wont correctly instantiate for vectors or matrices and I don't
understand why.

basically my question  is:

what is the correct type for the hmatrix expression

mapMat f  =liftMatrix $! cmap f


I'd like to just give it a type like
Storable a => (a->a)-> Matrix a -> Matrix a

but i get an error message like
Electrical.lhs:89:29:
No instance for (Container Vector e0)
  arising from a use of `cmap'
Possible fix: add an instance declaration for (Container Vector e0)
In the second argument of `($!)', namely `cmap f'
In the expression: liftMatrix $! cmap f
In an equation for `mapMat': mapMat f = liftMatrix $! cmap f

which i feel shouldn't be happening.

is the type of cmap in some way too polymorphic, or am I just not turning on
the right ghc type extensions for this to work,
or is this something that would have been well typed prior to ghc 7? Or am i
just not correctly understanding this type error and i'm making a simple
mistake?

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

Re: [Haskell-cafe] impoosible dependencies

[Carter Schonwald]

Kevin,
what version of cabal install are you using?

I ask because prior to the 1.10.* version series, cabal would have a much
harder time "correctly" choosing versions of dependencies, which at least
for me often manifested as such confusions in caba regarding selecting
versions. Prior to said cabal version the solution I'd often do is figure
out what the "transitive " dependencies were, recompile them together,
iterate that, and that would eventually make the problems  go away.

point being: the issue is probably conflicting versions of the same
libraries are being used by different libraries that are among the
dependencies, and cabal is getting confused

On Wed, Apr 20, 2011 at 7:34 PM, Rogan Creswick  wrote:

> On Wed, Apr 20, 2011 at 4:18 PM, Kevin Quick  wrote:
> >
> > With --verbose=3 this appears to be post-link running cabal-dev itself:
> >
> > $ cabal install cabal-dev --verbose=3
> >
>
> Could you send me (or post to hpaste) the complete output of 'cabal
> install cabal-dev --verbose=3' ?
>
> --Rogan
>
> > ...
> >
> > *** Deleting temp files:
> > Deleting:
> > link: linkables are ...
> > LinkableM (Wed Apr 20 16:14:58 MST 2011) main:Main
> >   [DotO /tmp/cabal-dev-0.7.4.113193/cabal-dev-0.7.4.1/dist/setup/Main.o]
> > Linking /tmp/cabal-dev-0.7.4.113193/cabal-dev-0.7.4.1/dist/setup/setup
> ...
> > *** Linker:
> > ...[verbose GCC output elided]...
> > rtend.o
> /nix/store/l8x3fdy1r6zf441vnqa87lzsvxrjbdz9-glibc-2.11.1/lib/crtn.o
> > link: done
> > *** Deleting temp files:
> > Deleting:
> > *** Deleting temp dirs:
> > Deleting: /tmp/ghc13224_0
> > /tmp/cabal-dev-0.7.4.113193/cabal-dev-0.7.4.1/dist/setup/setup configure
> > --verbose=3 --ghc --prefix=/home/kquick/.cabal --user
> --flags=-build-tests
> > --flags=-no-cabal-dev
> --extra-include-dirs=/home/kquick/.nix-profile/include
> > --extra-lib-dirs=/home/kquick/.nix-profile/lib --constraint=Cabal
> ==1.10.1.0
> > --constraint=HTTP ==4000.1.1 --constraint=base ==4.2.0.2
> > --constraint=bytestring ==0.9.1.9 --constraint=directory ==1.0.1.1
> > --constraint=filepath ==1.1.0.4 --constraint=mtl ==2.0.1.0
> > --constraint=network ==2.3.0.2 --constraint=pretty ==1.0.1.1
> > --constraint=process ==1.0.1.3 --constraint=tar ==0.3.1.0
> --constraint=zlib
> > ==0.5.3.1
> > cabal: Error: some packages failed to install:
> > cabal-dev-0.7.4.1 failed during the configure step. The exception was:
> > ExitFailure 11
> > $
> >
> >
> > --
> > -KQ
> >
>
> ___
> 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] Uncertainty analysis library?

[Carter Schonwald]

i'm now seeing that they've been moved to github, never mind!

On Mon, Mar 21, 2011 at 6:01 PM, Carter Schonwald <
carter.schonw...@gmail.com> wrote:

> by the way, the link to the patch-tag repo for your intervals lib seems to
> be dead / patch-tag gets confused,
> is it that the link is outdated or that there are problems on patch-tag?
>
> -Carter
>
> On Mon, Mar 21, 2011 at 4:57 PM, Edward Kmett  wrote:
>
>>
>> On Mon, Mar 21, 2011 at 2:42 PM, Edward Amsden wrote:
>>
>>>
>>> So I'm feeling a bit elated that I've sparked my first theoretical
>>> discussion in cafe, though I don't have much to contribute. :\
>>>
>>> However in the interests of the original question, I guess I should
>>> clarify.
>>>
>>> What we do in our physics class seems to be what is being called
>>> "interval analysis" in this discussion. We have experimental values
>>> with absolute uncertainties, and we need to propagate those
>>> uncertainties in a deterministic way through formulas. I don't think
>>> my professor would take kindly to a random sampling approach.
>>>
>>> The intervals library seemed a bit like what I'm looking for, except
>>> that it appears to be broken for the later ghc 6 versions and ghc 7.
>>
>>
>> The package should build fine, but hackage was flipping out because I
>> commented out a pattern guard, and it looked like a misplaced haddock
>> comment.
>>
>> I've pushed a new version of intervals to mollify hackage.
>>
>> It (or the old version) should cabal install just fine.
>>
>> -Edward Kmett
>>
>> ___
>> 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] Uncertainty analysis library?

[Carter Schonwald]

by the way, the link to the patch-tag repo for your intervals lib seems to
be dead / patch-tag gets confused,
is it that the link is outdated or that there are problems on patch-tag?

-Carter

On Mon, Mar 21, 2011 at 4:57 PM, Edward Kmett  wrote:

>
> On Mon, Mar 21, 2011 at 2:42 PM, Edward Amsden  wrote:
>
>>
>> So I'm feeling a bit elated that I've sparked my first theoretical
>> discussion in cafe, though I don't have much to contribute. :\
>>
>> However in the interests of the original question, I guess I should
>> clarify.
>>
>> What we do in our physics class seems to be what is being called
>> "interval analysis" in this discussion. We have experimental values
>> with absolute uncertainties, and we need to propagate those
>> uncertainties in a deterministic way through formulas. I don't think
>> my professor would take kindly to a random sampling approach.
>>
>> The intervals library seemed a bit like what I'm looking for, except
>> that it appears to be broken for the later ghc 6 versions and ghc 7.
>
>
> The package should build fine, but hackage was flipping out because I
> commented out a pattern guard, and it looked like a misplaced haddock
> comment.
>
> I've pushed a new version of intervals to mollify hackage.
>
> It (or the old version) should cabal install just fine.
>
> -Edward Kmett
>
> ___
> 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] Weird warnings from recent GHC snapshot

[Carter Schonwald]

1) if you copy the 10.5sdk from developer-old into the new developer folder
sdk folder, the standard ghc distro will work again
2) theres a ghc ticket for that, its apparently partly because theres no
-nowarnunwind flag or the like

On Thu, Mar 17, 2011 at 6:11 AM, Michael Vanier  wrote:

> I run haskell on Mac OS X (Snow Leopard).  After upgrading my Xcode
> installation to 4.0 I had a tricky time getting ghc working again; the
> version bundled with the Haskell Platform no longer works and I had to
> compile a recent snapshot (ghc-7.1.20110315) from source.  This worked fine,
> but now when I compile my code I keep getting really weird warnings.  For
> instance:
>
> ld: warning: could not create compact unwind for .LFB3: non-standard
> register 5 being saved in prolog
>
> and
>
> SpecConstr
>Function `$w$j{v s3hL} [lid]'
>  has one call pattern, but the limit is 0
>Use -fspec-constr-count=n to set the bound
>Use -dppr-debug to see specialisations
> SpecConstr
>Function `$w$j{v s3ic} [lid]'
>  has two call patterns, but the limit is 1
>Use -fspec-constr-count=n to set the bound
>Use -dppr-debug to see specialisations
>
> The code seems to work, but this is quite irritating.  Is there anything
> that can be done about these warnings?
>
> Thanks,
>
> Mike
>
>
>
> ___
> 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