[Haskell-cafe] ANNOUNCE: hackage-proxy 0.1.0.0
I'd like to announce the first release of a new tool called hackage-proxy. The purpose is to provide a local proxy for a Hackage server, which somehow modifies files in transport. The motivating case for this was getting more meaningful error output from Stackage when compiling against GHC HEAD. When compiling against actual Hackage, cabal will simply refuse to try to build packages which have upper version bounds such as base 4.7. This introduces a big dilemma: * Package authors do not want to bump the version bounds on their packages until they've tested against that version. * It's very difficult to do meaningful tests of GHC until packages on Hackage have been updated. Hopefully this package can help resolve the dilemma. Instead of requiring authors to upload new versions of their packages in order to test them, this proxy will modify the cabal files it downloads and strip off the version bounds of specified packages. Then, you can test with a newer version of GHC and find actual compilation errors instead of version bound constraints. ## Example Usage 1. cabal install hackage-proxy 2. Run hackage-proxy. By default, it will use the official Hackage server as the source, drop bounds on the packages base, process, directory, template-haskell, and Cabal, and serve from port 4200. All of this can be modified via command-line options. 3. Edit your ~/.cabal/config file. Comment out the hackage.haskell.orglines, and add in something like the following: remote-repo: hackage-proxy:http://localhost:4200 4. cabal update 5. cabal install your-package-list-here I think this can be a very valuable tool for anyone wanting to test out newer versions of GHC. In addition, as part of my normal Stackage work, I'm now collecting fairly detailed error logs of a number of packages. If this would be useful for the GHC team or anyone else, let me know and I can try and provide the logs somehow. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [ANNOUNCE] London Haskell user group - Being Lazy - Wed 27-Feb-13
Wednesday 27-Feb-2013 6-45pm (prompt) City University, College Building, St John Street, London. EC1V 4PB http://www.meetup.com/London-HUG/events/103545552/ Being Lazy Speaker: Peter Marks This talk will explore lazy evaluation in Haskell. After a brief introduction to non-strictness, and establishing a basic conceptual model of evaluation in Haskell, the primary focus will be on how we can utilize laziness to allow us to write programs differently to how we would in an eagerly evaluated language. The session will be rich on code with a worked example of a complete program. We'll also touch on some of the pitfalls of laziness that we run into in real world situations. Peter Marks has been developing software for over thirty years and has been using Haskell commercially for four years. He currently leads the FPF team at Barclays and is an active member of the London Haskell community, running the Hoodlums meetup group. N.B. The start time is slightly later than previously, to make sure everybody has arrived by the time the talk starts. Doors open 6-30pm, try not to be late! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] MonadReader laws
Has anyone formulated a reasonable set of laws for MonadReader? The instances for continuation-based monad transformers contradict any intuition about local and ask. E.g. for LogicT: flip runReader 1 $ observeAllT $ local (const 2) ask [1] flip runReader 1 $ observeAllT $ local (const 2) mzero | ask [2] I wonder whether there are any real use cases for such instances (and, consequently, whether they should be removed). Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] FunPtr to C function with #arguments determined at runtime?
Hello cafe, I've been poking around and I haven't seen this addressed anywhere except obliquely in the end of section 8.5.1 of the report, where it says that variable argument C functions aren't supported: http://www.haskell.org/onlinereport/haskell2010/haskellch8.html The scenario is pretty simple. I generate C code at runtime. I compile it to a .so. I know how many arguments it expects (but only at runtime), and I get a FunPtr back from 'dlsym'. How do I call it? I was hoping there would be some Raw lower level FFI layer that I could use to invoke a C function without automagic marshaling and all the other goodness provided by the normal foreign import mechanism. Failing that, will I just have to generate complex wrappers on the C side which I call N times to load up N arguments into some stateful container before finally launching the function? Thanks, -Ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FunPtr to C function with #arguments determined at runtime?
Hi, I think libffi might be the answer here. Please see Hackage and Haskell wiki for details. Cheers, Krzysztof Skrzetnicki 17-02-2013 12:18, Ryan Newton rrnew...@gmail.com napisał(a): Hello cafe, I've been poking around and I haven't seen this addressed anywhere except obliquely in the end of section 8.5.1 of the report, where it says that variable argument C functions aren't supported: http://www.haskell.org/onlinereport/haskell2010/haskellch8.html The scenario is pretty simple. I generate C code at runtime. I compile it to a .so. I know how many arguments it expects (but only at runtime), and I get a FunPtr back from 'dlsym'. How do I call it? I was hoping there would be some Raw lower level FFI layer that I could use to invoke a C function without automagic marshaling and all the other goodness provided by the normal foreign import mechanism. Failing that, will I just have to generate complex wrappers on the C side which I call N times to load up N arguments into some stateful container before finally launching the function? Thanks, -Ryan ___ 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] JSON querying
Hi folks. Hackage contains several JSON packages but as far as I see, they all provide 'static' conversion from JSON format to Haskell data type. Is there a method of converting object containing optional filed 'a' to for example Maybe a. Thanks, Sergey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] JSON querying
On 02/17/2013 04:01 PM, Sergey Mironov wrote: Hi folks. Hackage contains several JSON packages but as far as I see, they all provide 'static' conversion from JSON format to Haskell data type. Is there a method of converting object containing optional filed 'a' to for example Maybe a. Data.Aeson does this with the .:? operator: instance FromJSON Bar where parseJSON (Object v) = Bar $ v .: required * v .:? optional ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] JSON querying
On 02/17/2013 03:01 PM, Sergey Mironov wrote: Hi folks. Hackage contains several JSON packages but as far as I see, they all provide 'static' conversion from JSON format to Haskell data type. Is there a method of converting object containing optional filed 'a' to for example Maybe a. Assuming you have some sort of 'path' to the key in question, aeson-lens might be exactly what you want: http://hackage.haskell.org/package/aeson-lens I use aeson-lens to turn a list of strings of the form [foo, bar, baz] into a query into first the 'foo' object, then the 'bar' object, then the 'baz' object, using the following: pathToLens :: Functor f = [T.Text] - (Maybe Value - f (Maybe Value)) - Maybe Value - f (Maybe Value) pathToLens [p] = key p pathToLens ps = let ps' = filter (not . T.null) ps in key (head ps') . (foldl (.) id . map pathElem $ tail ps') where pathElem p = maybe (key p) nth (readMay $ T.unpack p) So as you can see - I turn any arbitrary path into a query into JSON, with a chance of failure. Hope this helps! - Ollie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Terminal Win32/Building Haskeline/8.3 file issue
Hit this compiling darcs on a new machine. . . . But it may be more generic to Haskell platform itself. Bottom line, it presents a situation where someone could end up dead-in-the-water with respect to using haskell libraries. I burned a lot of time tracking this down, it may discourage users from the platform. The problem manifests itself when your Win32 home directory has a long name (or one with a space) and you're compiling haskeline, linking on the 15th step. Basically, ld.exe croaks when fed one of these names rather than an 8.3 I can provide more specific details on the point of failure on request; but it was a pain to track down. Maybe a change to the linker, or some specific project, may get rid of the 8.3 dependency. A solution that got me out was to enable 8.3 on the volume, and on the user directory. A fix: Logging in as a *different* user: Open a command prompt with Administrator priveleges fsutil 8dot3name query c: (tells you the current status - you probably see a 2 - volume-select of the feature) fsutil 8dot3name set c: 1 (This sets volume c to create 8.3 names - for future files only) fsutil file setshortname c:\Users\YouHaveA VeryBigName YOUHAV~1 (This only works if you're not logged in as 'YouHaveA VeryBigName', otherwise the directory will be in-use). You need this step as even though you've changed the policy on 8.3 naming, this directory was probably made during the prior policy) dir /-n (This shows you the 8.3-sensitive names. You see YOUHAV~1 in the list, you got it right) The user may need to uninstall and reinstall haskell-platform, and wipe all Cabal and GHC directories under AppData/Roaming ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ifdef based on which OS you're on
With apologies for prolonging a tangential topic, I'd like to sharpen anti-ifdef comments that have been posted already. 1. An ifdef for portability is an admission of nonportability. What it does is point out a nonportability--a useful crutch for maintainers, but a crutch nonetheless. 2. Ifdefs violate program structure. All ifdefs appear at top level. Yet, save for those that control top-level declarations, they embody conditionals at inner levels of structure. Doug McIlroy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] adding recursion to a DSL
I have a tiny DSL that actually works quite well. When I say import language.CWMWL main = runCWMWL $ do out (matrixMult, A, 1, row, matrix-row) then runCWMWL is a function that is exported by language.CWMWL. This parses the experession and takes some action. Now, A is the name of the matrix and the third tuple element would represent the numbe of the row. For example 1 to 1. I want to achieve some sort of elegant (means readable code, a good representation) recursion that would let me do something like sequence [ out (matrixMult, A, n, row, matrix-row) | n - [1..1000] ] but in a nicer manner an without expending this to 1 lines of code at compile time. How can I best introduce recursion into my DSL or borrow this from the host language Haskell effectively? --Joerg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Maintaining lambdabot
Hi all, as some of you may have noticed Lambdabot doesn't build on GHC 7.6.1 due to OldException being removed (and a few other changes). I updated the code so that it builds on latest GHC release. The updated code is available here: https://github.com/killy/lambdabot/tree/upstream It builds on Linux, but I am not 100% certain that it will build on Windows. If it doesn't I will be grateful for reporting this (and any other) issues on the bug tracker: https://github.com/killy/lambdabot/issues The changes required to make the code run weren't as small as I initially thought they will be. In some places this resulted in a bit ugly code, but aside from that I think that everything should work correctly. Now I would like to do a bit of maintanance on the project, since the code is a bit of a mess and it could use some cleanup. My plans are: - clean up the package namespace by placing existing modules in Lambdabot module - integrate lambdabot-utils into lambdabot (already done) - reformat the code so that it's easier to read ans if time allows: - cleanup some messy code - update the package dependencies so that lambdabot relies on maintained libraries (e.g. I thought about replacing readline with haskeline). This changes would be quite invasive and code wouldn't be compatible with the lambdabot repo on haskell.org. So before I start making any of them I would like to hear from the community if such changes in the source code of lambdabot would be considered helpful and acceptable. Janek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FunPtr to C function with #arguments determined atruntime?
Quoth Ryan Newton rrnew...@gmail.com, The scenario is pretty simple. I generate C code at runtime. I compile it to a .so. I know how many arguments it expects (but only at runtime), and I get a FunPtr back from 'dlsym'. How do I call it? I was hoping there would be some Raw lower level FFI layer that I could use to invoke a C function without automagic marshaling and all the other goodness provided by the normal foreign import mechanism. I feel that I might be confused about the problem, but since I don't see anyone direct answers -- in order to call a FunPtr, you can use foreign import ccall dynamic, to create a regular function. As described in the library documentation for Foreign.Ptr, which I bet you've seen, so you know this. You can cast the FunPtr to whatever type you like, so you can call the function with an argument list different from its initial declaration. There are two types of support you don't get, as I see it: 1) Haskell isn't going to make it really super convenient to use a variably typed function, and 2) there's the argument promotion issue mentioned in the document you cited. On that second point, however you go about this, you'll need to thoroughly understand what that means, but it won't strictly prevent you from calling this function, just puts you on notice that the FFI is blind to the argument types and will make default assumptions, so your C function needs to support that. On the first point, of course that's how Haskell is - and from a design point of view, if you're writing C code to be called from Haskell, wouldn't there be better ways to accommodate variable inputs than the argument list? Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FunPtr to C function with #arguments determined atruntime?
The scenario is pretty simple. I generate C code at runtime. I compile it to a .so. I know how many arguments it expects (but only at runtime), and I get a FunPtr back from 'dlsym'. How do I call it? I feel that I might be confused about the problem, but since I don't see anyone direct answers -- in order to call a FunPtr, you can use foreign import ccall dynamic, to create a regular function. As described in the library documentation for Foreign.Ptr, which I bet you've seen, so you know this. You can cast the FunPtr to whatever type you like, so you can call the function with an argument list different from its initial declaration. My problem is that I can't create a type representing what I want at the Haskell type-check time, and I need such a type for either casting or a foreign import. For example, let's say the function takes a number of Int arguments between 1 and 1000. If I find out at runtime that I need a function with 613 Int arguments, I would need to create the type (Int - Int ... - IO ()) to cast to. I suppose there may be some way to create such a dependent type with Typeable/Data.Dynamic, since it's monomorphic. Or in theory you could dynamically generate new Haskell code to create the type (System.Eval.Haskell)... libffi, which Krzysztof mentioned, is a good solution: http://www.haskell.org/haskellwiki/Library/libffi Because it allows you to pass a list of arguments callFFI :: FunPtr a - RetType b - [Arg] - IO b But it does introduce an extra dependency on a C library (read, deployment liability). It cabal install'd the first time on my linux box, but my mac said The pkg-config package libffi is required but it could not be found. (even though libffi.dylib is definitely installed globally). Anyway, in this case it wasn't *too *painful to just generate a bunch of extra boilerplate C functions for (1) creating a data structure to hold the arguments, (2) loading them in one at a time, and (3) deallocating the structure when the call is done. Yuck. But no extra dependencies. Cheers, -Ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FunPtr to C function with #arguments determined atruntime?
Quoth Ryan Newton rrnew...@gmail.com, ... Anyway, in this case it wasn't *too *painful to just generate a bunch of extra boilerplate C functions for (1) creating a data structure to hold the arguments, (2) loading them in one at a time, and (3) deallocating the structure when the call is done. Yuck. But no extra dependencies. If I understand you right, that's a better direction in my view - and when I've done stuff like this I've allocated and marshalled the data structure from the Haskell side fairly painlessly with Foreign.Storable(poke) etc., and the .hsc preprocessor macros for struct access (#poke, etc.) Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maintaining lambdabot
On 17 February 2013 18:03, Jan Stolarek jan.stola...@p.lodz.pl wrote: ... This changes would be quite invasive and code wouldn't be compatible with the lambdabot repo on haskell.org. So before I start making any of them I would like to hear from the community if such changes in the source code of lambdabot would be considered helpful and acceptable. Janek I say go for it! I'll be quite happy to start running your new code in #haskell as soon as we get GHC 7.6 installed on Jason's Linode account. :) - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maintaining lambdabot
Sounds great. Lambdabot is an important icon to the Haskell community; it will be nice to brush off the bitrot and make lambdabot easier for the average Haskeller to install without having to rely on Cale keeping it running on irc (grateful, though we are). -- Dan Burton On Feb 17, 2013 3:04 PM, Jan Stolarek jan.stola...@p.lodz.pl wrote: Hi all, as some of you may have noticed Lambdabot doesn't build on GHC 7.6.1 due to OldException being removed (and a few other changes). I updated the code so that it builds on latest GHC release. The updated code is available here: https://github.com/killy/lambdabot/tree/upstream It builds on Linux, but I am not 100% certain that it will build on Windows. If it doesn't I will be grateful for reporting this (and any other) issues on the bug tracker: https://github.com/killy/lambdabot/issues The changes required to make the code run weren't as small as I initially thought they will be. In some places this resulted in a bit ugly code, but aside from that I think that everything should work correctly. Now I would like to do a bit of maintanance on the project, since the code is a bit of a mess and it could use some cleanup. My plans are: - clean up the package namespace by placing existing modules in Lambdabot module - integrate lambdabot-utils into lambdabot (already done) - reformat the code so that it's easier to read ans if time allows: - cleanup some messy code - update the package dependencies so that lambdabot relies on maintained libraries (e.g. I thought about replacing readline with haskeline). This changes would be quite invasive and code wouldn't be compatible with the lambdabot repo on haskell.org. So before I start making any of them I would like to hear from the community if such changes in the source code of lambdabot would be considered helpful and acceptable. Janek ___ 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] JSON querying
2013/2/17 Oliver Charles ol...@ocharles.org.uk: On 02/17/2013 03:01 PM, Sergey Mironov wrote: Hi folks. Hackage contains several JSON packages but as far as I see, they all provide 'static' conversion from JSON format to Haskell data type. Is there a method of converting object containing optional filed 'a' to for example Maybe a. Assuming you have some sort of 'path' to the key in question, aeson-lens might be exactly what you want: http://hackage.haskell.org/package/aeson-lens I use aeson-lens to turn a list of strings of the form [foo, bar, baz] into a query into first the 'foo' object, then the 'bar' object, then the 'baz' object, using the following: pathToLens :: Functor f = [T.Text] - (Maybe Value - f (Maybe Value)) - Maybe Value - f (Maybe Value) pathToLens [p] = key p pathToLens ps = let ps' = filter (not . T.null) ps in key (head ps') . (foldl (.) id . map pathElem $ tail ps') where pathElem p = maybe (key p) nth (readMay $ T.unpack p) So as you can see - I turn any arbitrary path into a query into JSON, with a chance of failure. Hope this helps! - Ollie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Good news, thanks a lot! Sergey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
