Re: [Haskell-cafe] Interfacing real-time stocks data API
There is also Interactive Brokers API, which used to be a lower cost alternative. On Wed, Oct 9, 2013 at 1:57 PM, wrote: > Yes, I also like that one. Problem is that they give access only to US > citizens and some limited countries. > > m. > > > -Original Message- > From: David Fox > To: miroslav.kar...@gmail.com > Cc: Haskell Cafe > Sent: Wed, 09 Oct 2013 18:54 > Subject: Re: [Haskell-cafe] Interfacing real-time stocks data API > > I would love to see Haskell bindings for this: > https://us.etrade.com/active-trading/api > > > On Tue, Oct 8, 2013 at 1:26 PM, Miro Karpis wrote: > >> Please, did/does anybody tried to interface with Haskell some real-time >> stocks data API? If yes, please which one? So far I came down to >> ActveTick,... >> >> thanks, >> m. >> >> ___ >> 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] GHC API + Cabal API + Cabal version checks: is there a way out?
That is a good point. I am usually there in #ghc with nickname lemao. Niklas is nh2 afaik. On Sat, Sep 7, 2013 at 7:17 AM, Niklas Hambüchen wrote: > Would you mind hanging around in #ghc when working on it? > > A few people found this interesting, so this might be useful to avoid > duplicate effort. > > On Sat 07 Sep 2013 18:24:43 JST, JP Moresmau wrote: > > I'll be happy to give it a shot! > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC API + Cabal API + Cabal version checks: is there a way out?
Alejandro, that is correct, as I see it. Duncan has very good points there but it seems to me that we need a concrete proposal so we can propose solutions to the problem. The fact is that the current situation is a middle of the ground that doesn't help Cabal nor Ghc. On Fri, Sep 6, 2013 at 10:54 AM, Alejandro Serrano Mena wrote: > I'm willing to help in the process, if some directions were given to me on > how to tackle this problem. > > In any case, for me is seems fine to have a dependency from cabal to ghc, > the only problem is the converse: ghc depending on cabal. Is this right? > > > 2013/9/6 Herbert Valerio Riedel > >> On 2013-09-06 at 15:13:58 +0200, Yuri de Wit wrote: >> > I spent some time looking into the touch points between ghc and cabal in >> > the past, and the first oddity i saw was a direct dependency from ghc to >> > the cabal sources. After taking a closer look it seems that ghc shares >> some >> > common, low level modules with cabal that didnt seem to justify the >> whole >> > dependency. >> > >> > The right solution, imho, is to review these dependencies and move the >> low >> > level ones out into a separate package that is shared by both ghc and >> cabal >> > and that will rarely change. The direct side effect of this is that ghc >> > would not be tied directly to a specific cabal version and you would >> > not have to deal with this issue. >> >> [...] >> >> fyi, a similiar/related discussion took place few months ago on ghc-devs: >> >> http://www.haskell.org/pipermail/ghc-devs/2013-March/000800.html >> >> hth, >> hvr >> >> ___ >> 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] GHC API + Cabal API + Cabal version checks: is there a way out?
I spent some time looking into the touch points between ghc and cabal in the past, and the first oddity i saw was a direct dependency from ghc to the cabal sources. After taking a closer look it seems that ghc shares some common, low level modules with cabal that didnt seem to justify the whole dependency. The right solution, imho, is to review these dependencies and move the low level ones out into a separate package that is shared by both ghc and cabal and that will rarely change. The direct side effect of this is that ghc would not be tied directly to a specific cabal version and you would not have to deal with this issue. Re: specific workaround i am not sure. On Friday, September 6, 2013, JP Moresmau wrote: > Hello all, > > I have an issue that has been nagging me for a while, and I'd like to make > sure I haven't missed a solution to it. > I'm the maintainer for the buildwrapper package. This package has > dependencies on the Cabal and GHC libraries, and also uses the > cabal-install executable. For example it will run cabal configure by > invoking the executable, then it will load the LocalBuildInfo via the Cabal > API, and extract the relevant information to start a GHC session with the > proper flags, etc. > Now yesterday some great news were announced, a new version of Cabal! > However, I can't use it. I can of course install the Cabal library and > rebuild the cabal executable but > - buildwrapper will only use the version of the Cabal library that was > bundled with GHC, since the GHC library has a dependency on that version of > Cabal > - so the library access will be using Cabal 1.16, but the executable will > be 1.18 > - and the library checks when reading the setup-config file that the Cabal > versions match. Hence, running configure with 1.18 create build information > I can't read back in 1.16. > > So I'm stuck. People can easily install cabal 1.18 and build their > projects with it, but I can't use it in conjunction with buildwrapper. > Some solutions I've considered > - do not use the Cabal API and write my own code to read the local build > info, and to replace all the Cabal library code I use > - do not use the cabal-install executable but do everything by the API > > Both solutions reek of madness, and involve rewriting code that others > have already written, and a maintenance nightmare with each Cabal release. > > So, do I have to wait a new release of GHC/Haskell Platform or is there a > better solution? I suspect ghc-mod and other similar packages have the same > issues. > > Thanks for any help! > > -- > JP Moresmau > http://jpmoresmau.blogspot.com/ > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Cabal v1.18.0 released
It is easy enough to recreate the link manually or as easy to run cabal install again, but that is not the point here. The point is that it will bite the next dozen of unsuspecting users since, at first, they have no idea of what is going on. In any case, apologies for sending this in this thread as it doesn't seem the right forum to discuss it. On Thu, Sep 5, 2013 at 7:53 AM, Paolo Giarrusso wrote: > On Wednesday, September 4, 2013 11:41:33 PM UTC+2, Yuri de Wit wrote: > >> Thanks for all the hard work! >> >> If you see this in OSX (#1009) while installing cabal 1.18: >> >> *Warning: could not create a symlink in /Users/lemao/Library/Haskell/bin >> for* >> *cabal because the file exists there already but is not managed by >> cabal. You* >> *can create a symlink for this executable manually if you wish. The >> executable* >> *file has been installed at* >> */Users/user/Library/Haskell/ghc-7.6.3/lib/cabal-install-1.18.0/bin/cabal >> * >> >> You will need to manually remove the pre-existing 1.16 links in >> ~/Library/Haskell/bin before installing again. >> > > Instead of installing again, you can even just recreate the symlink as > mentioned by the message (if you know how to do that). > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Cabal v1.18.0 released
Thanks for all the hard work! If you see this in OSX (#1009) while installing cabal 1.18: *Warning: could not create a symlink in /Users/lemao/Library/Haskell/bin for * *cabal because the file exists there already but is not managed by cabal. You* *can create a symlink for this executable manually if you wish. The executable* *file has been installed at* */Users/user/Library/Haskell/ghc-7.6.3/lib/cabal-install-1.18.0/bin/cabal* You will need to manually remove the pre-existing 1.16 links in ~/Library/Haskell/bin before installing again. On Wed, Sep 4, 2013 at 5:11 PM, Johan Tibell wrote: > Hi all, > > On behalf of the cabal maintainers and contributors I'm proud to > announce the Cabal (and cabal-install) 1.18.0 release. To install run > > cabal update && cabal install Cabal-1.18.0 cabal-install-1.18.0 > > With 854 commits since the last release there are two many > improvements and bug fixes to list them here, but two highlights are: > > * Hermetic builds using sandboxes. This should reduce the number of > "dependency hell" and broken package DB problems. > > * GHCi support. It's now much easier to use ghci when developing your > packages, especially if those packages require preprocessors (e.g. > hsc2hs). > > Here's how working on a package might look like using the new features: > > # Only once: > cabal sandbox init > cabal install --only-dependencies --enable-tests > # Configure, build, and run tests: > cabal test # now implies configure and build > # Play around with the code in GHCi: > cabal repl > > Mikhail wrote a bit more about the user visible changes on his blog: > > http://coldwa.st/e/blog/2013-08-21-Cabal-1-18.html > > For a complete list of changes run > > git log cabal-install-v1.16.0.2..cabal-install-v1.18.0 > > in the cabal repo or look at the GitHub compare page: > > > https://github.com/haskell/cabal/compare/cabal-install-v1.16.0.2...cabal-install-v1.18.0 > > (only shows the last 250 commits). > > 57 people contributed to this release! > >503 Mikhail Glushenkov > 99 Johan Tibell > 41 Duncan Coutts > 39 Ian Lynagh > 19 Brent Yorgey > 19 Thomas Tuegel > 18 Ben Millwood > 16 Eyal Lotem > 10 Thomas Dziedzic > 7 Andres Loeh > 6 John Wiegley > 6 Benno Fünfstück > 5 Gregory Collins > 4 Herbert Valerio Riedel > 4 Simon Hengel > 3 Joachim Breitner > 3 Luke Iannini > 3 Bryan Richter > 3 Richard Eisenberg > 3 Tuncer Ayaz > 3 Jens Petersen > 2 Arun Tejasvi Chaganty > 2 Bryan O'Sullivan > 2 Eric Kow > 2 Jookia > 2 Paolo G. Giarrusso > 2 Paolo Capriotti > 1 Sönke Hahn > 1 Yitzchak Gale > 1 Albert Krewinkel > 1 stepcut > 1 Alexander Kjeldaas > 1 Austin Seipp > 1 Bardur Arantsson > 1 Ben Doyle > 1 Ben Gamari > 1 Bram > 1 Carter Tazio Schonwald > 1 Clint Adams > 1 Daniel Wagner > 1 David Lazar > 1 Erik Hesselink > 1 Eugene Sukhodolin > 1 Gabor Greif > 1 Jack Henahan > 1 Jason Dagit > 1 Ken Bateman > 1 Mark Lentczner > 1 Masahiro Yamauchi > 1 Merijn Verstraaten > 1 Michael Thompson > 1 Niklas Hambüchen > 1 Oleksandr Manzyuk > 1 Patrick Premont > 1 Roman Cheplyaka > 1 Sergei Trofimovich > 1 Stephen Blackheath > > -- Johan, on behalf of the cabal maintainers and contributors. > > ___ > 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
Re: [Haskell-cafe] Sparse records/ADTs
Would this be relevant? https://github.com/jonsterling/Data.Records On Fri, Oct 26, 2012 at 11:17 AM, Jon Fairbairn wrote: > Twan van Laarhoven writes: > > > On 24/10/12 12:08, Jon Fairbairn wrote: > >> > >> Is there a convenient way of handling a data structure with lots > >> of fields of different types that may or may not be filled in? > >> > > > > Not sure about convenience, but here is a type safe solution > > with O(log n) lookups and updates. The idea is to define a > > GADT tree type with a fixed layout: > > Thanks for your reply (and for all the others). Since type safe > is something that (for me) goes without saying, this is the best > solution, but it doesn’t really satisfy the convenience aspect. > (I had already looked at solutions using Map and contemplated a > tree structure, but didn’t like anything I had come up with). In > short, it looks like the answer to my question is “No.” :-/ > > -- > Jón Fairbairn jon.fairba...@cl.cam.ac.uk > > > ___ > 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
