[Haskell-cafe] Using Quick Check generators for getting arbitrary value streams
I was hoping I could use Arbitrary instances to generate streams of values for test data. It looks like you're not 'supposed' to be trying this, other than for the specific purpose of then testing some properties on these streams within Quick Check itself. I'm looking for something like the sample' function in Quick Check, only to produce an infinite stream of values (rather than the 11 values that are clearly designed simply to give you a sense of the output of a generator). Am I out of luck, or is there yet some cunning way of doing this without hacking the Quick Check package to export the MkGen constructor? -- Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Which generic zipper? [RESOLVED]
Thanks Roman. I'll probably go with Data.Data then. Certainly, I'm not looking for any significant distractions and I'll heed your cautionary note. I read that GHC.Generics is fit and fast in comparison to SYB, but that's not really a big concern for me at the moment. I just fell in to believing that GHC.Generics was the true religion given its apparent status as the adopted generics in GHC. On 2013-04-10, at 11:24 PM, Roman Cheplyaka r...@ro-che.info wrote: Note that syz is essentially based on Data.Data, which is no less official than GHC.Generics. (The compiler can derive Data with -XDeriveDataTypeable.) You can write a zipper based on GHC.Generics, but it won't be a straightforward translation of syz (nor would it be a trivial undertaking). Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Which generic zipper?
It's sometimes difficult to figure out a good choice when you're searching for a new feature/library (when you go beyond safety of the HP). I'm looking for a generic zipper to (hopefully) navigate over an AST… so a hetrogeneous structure. It's probably sufficient to make this traversable in a fixed way, but a zipper seemed like a good idea. Google says there are lots of options (various papers and their related implementations etc). I see a generic zipper in an 'syz' package that is based on generics, which looks like a nice choice as it's now easy to add the extension for deriving generics on ADTs. However, that package looks pretty old and unmaintained. Does anyone have any suggestions/advice? Cheers -- Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Which generic zipper?
Hmm, in my naivety I failed to notice that the 'official' GHC.Generics are completely different to SYB on which syz is built. Classic case of reading the same words/names and assuming they're exactly the same thing. Maybe it's not that hard to rewrite syz in terms of GHC.Generics.Generic (I'll perhaps take a look), but maybe there's a generic Zipper library already based on the GHC stuff? On 2013-04-10, at 3:19 PM, Roman Cheplyaka r...@ro-che.info wrote: ...Apart from that, I am not aware of any problems with syz. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] llvm-3.0.1.0 installation on Mac
OK, thanks again. I'll give that a whirl. On 2013-04-08, at 7:48 AM, Brandon Allbery allber...@gmail.com wrote: On Mon, Apr 8, 2013 at 1:32 AM, Luke Evans l...@eversosoft.com wrote: Unfortunately, it looks like /Library/Frameworks/GHC.framework/Versions/7.4.2-x86_64/usr/lib/ghc-7.4.2/libffi.dylib is pointing to the dodgy library too, e.g.: otool -L /Library/Frameworks/GHC.framework/Versions/7.4.2-x86_64/usr/lib/ghc-7.4.2/libffi.dylib /Users/ian/zz64/ghc-7.4.2/libffi/build/inst/lib/libffi.5.dylib (compatibility version 6.0.0, current version 6.10.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) Not sure what to patch the first reference in that one to. To itself; that's actually the internal reference that gets compiled into the others, and as such is the actual source of the problem. (In an ELF shared object, that would be the soname. Note that it *must* be a full path on OS X, unlike Linux/ELF.) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] llvm-3.0.1.0 installation on Mac [RESOLVED]
… and this works just fine. \o/ At least cabal now installs/builds the llvm 3.0.1.0 package successfully. So, normality has been restored… any remaining problems are therefore my own :-) That last reference has to be changed with the install_name_tool -id option (rather than -change) as indeed the first entry in the self-identification, rather than the paths of dependent libraries. -- Luke P.S. It would be great if the HP could have more frequent patches for critical issues like this. I've no problem with 6 monthly 'feature release' updates, but there are bound to be big defects for which a 6 month cycle is a very long time. Another similar one is that I found that yesod's development server doesn't run on 7.4.2 due to a bug (allegedly long since fixed). On 2013-04-08, at 10:08 AM, Luke Evans l...@eversosoft.com wrote: OK, thanks again. I'll give that a whirl. On 2013-04-08, at 7:48 AM, Brandon Allbery allber...@gmail.com wrote: On Mon, Apr 8, 2013 at 1:32 AM, Luke Evans l...@eversosoft.com wrote: Unfortunately, it looks like /Library/Frameworks/GHC.framework/Versions/7.4.2-x86_64/usr/lib/ghc-7.4.2/libffi.dylib is pointing to the dodgy library too, e.g.: otool -L /Library/Frameworks/GHC.framework/Versions/7.4.2-x86_64/usr/lib/ghc-7.4.2/libffi.dylib /Users/ian/zz64/ghc-7.4.2/libffi/build/inst/lib/libffi.5.dylib (compatibility version 6.0.0, current version 6.10.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) Not sure what to patch the first reference in that one to. To itself; that's actually the internal reference that gets compiled into the others, and as such is the actual source of the problem. (In an ELF shared object, that would be the soname. Note that it *must* be a full path on OS X, unlike Linux/ELF.) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] llvm-3.0.1.0 installation on Mac
I'm trying to get LLVM 3.0 installed and then have the llvm-3.0.1.0 package install and bind against it with cabal. I'm on a recent 64 bit Mac which shows up in various messages like: Target platform inferred as: x86_64-apple-darwin I was advised on the Haskell IRC channel to install a 3.0 LLVM from a location like MacPorts first, then point cabal at the location where LLVM was installed with the appropriate config option. So, I did a sudo ./port install llvm-3.0, and everything seemed to proceed fine. Then I did: cabal install llvm --configure-option=--with-llvm-prefix=/opt/local/libexec/llvm-3.0 This looks promising (compared to missing the config option), but eventually this happens: Building llvm-base-3.0.1.0... Preprocessing library llvm-base-3.0.1.0... dyld: Library not loaded: /Users/ian/zz64/ghc-7.4.2/libffi/build/inst/lib/libffi.5.dylib Referenced from: /private/var/folders/tz/vlbc03q5333897z201hkmcb4gn/T/llvm-base-3.0.1.0-3941/llvm-base-3.0.1.0/dist/build/LLVM/FFI/Analysis_hsc_make Reason: image not found running dist/build/LLVM/FFI/Analysis_hsc_make failed (exit code 5) command was: dist/build/LLVM/FFI/Analysis_hsc_make dist/build/LLVM/FFI/Analysis.hs Failed to install llvm-base-3.0.1.0 I have no idea where /Users/ian/... is coming from! My cabal-fu is extremely weak, so I'll plug on and see if I can figure out how cabal's analysis/build might be going wrong here. I'd be very grateful for any clues though! -- Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] llvm-3.0.1.0 installation on Mac
Ah, I see GHC bug #5982, which smells awfully similar. The bug suggests a fix along the lines of: install_name_tool /usr/local/lib/ghc-7.4.1/libHSrts-ghc7.4.1.dylib -change /Users/ian/zz64/ghc-7.4.1/libffi/build/inst/lib/libffi.5.dylib /usr/local/lib/ghc-7.4.1/libffi.dylib Presumably this is still an issue in the 7.4.2 build I have installed from Haskell Platform. Unfortunately, it looks like my cabal build failure occurs in a temporary and very short-lived directory. So presumably the dodgy FFI gets copied into there from elsewhere. I wonder if I can find the source... On 2013-04-07, at 8:39 PM, Luke Evans l...@eversosoft.com wrote: My cabal-fu is extremely weak, so I'll plug on and see if I can figure out how cabal's analysis/build might be going wrong here. I'd be very grateful for any clues though! -- Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] llvm-3.0.1.0 installation on Mac
Thanks Brandon. I've patched: /Library/Frameworks/GHC.framework/Versions/7.4.2-x86_64/usr/lib/ghc-7.4.2/libHSrts-ghc7.4.2.dylib and /Library/Frameworks/GHC.framework/Versions/7.4.2-x86_64/usr/lib/ghc-7.4.2/ibHSrts_thr-ghc7.4.2.dylib both pointing to: /Library/Frameworks/GHC.framework/Versions/7.4.2-x86_64/usr/lib/ghc-7.4.2/libffi.dylib Unfortunately, it looks like /Library/Frameworks/GHC.framework/Versions/7.4.2-x86_64/usr/lib/ghc-7.4.2/libffi.dylib is pointing to the dodgy library too, e.g.: otool -L /Library/Frameworks/GHC.framework/Versions/7.4.2-x86_64/usr/lib/ghc-7.4.2/libffi.dylib /Users/ian/zz64/ghc-7.4.2/libffi/build/inst/lib/libffi.5.dylib (compatibility version 6.0.0, current version 6.10.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) Not sure what to patch the first reference in that one to. On 2013-04-07, at 9:42 PM, Brandon Allbery allber...@gmail.com wrote: On Mon, Apr 8, 2013 at 12:10 AM, Luke Evans l...@eversosoft.com wrote: Unfortunately, it looks like my cabal build failure occurs in a temporary and very short-lived directory. So presumably the dodgy FFI gets copied into there from elsewhere. I wonder if I can find the source... It's running an executable it seems to have built to generate something else for the build, so I suspect you are in fact seeing the ghc bug and you should fix the ghc reference. If you installed the official HP package, you need to find libHSrts-ghc7.4.2.dylib somewhere under /Library/Haskell and use install_name_tool on that. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Enumerating functions at runtime
I'm curious about using Haskell for metaprogramming. It looks like I can dynamically compile, load and run some Haskell with the plugins package. Actually I've briefly tried this and it seems to work for some simple cases at least. Now I would like to be able to enumerate precompiled public functions in modules that I might use as building blocks in such dynamic compilation. So far I'm not seeing anything that does this directly. Can anyone provide some pointers? If it's just not possible to introspect on compiled modules, then I suppose I could use external metadata of my own, or even perhaps haddock info if it exists, to attempt to generate this info. Clearly though, that's nowhere near as good as extracting the info from something the compiler built directly. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] State of play with Haskell-Cocoa (Objective-C) bindings?
I'm planning to start an Objective-C/Cocoa project and would like to write it in Haskell as much as possible. Of course, I can contrive to split the project into app logic (Haskell) and UI (Objective-C) with some sort of minimal interface between them; possibly just plain old C FFI. However, I would like an interface that's as 'automatic' as possible - one that preferably means that I don't have to spend a lot of time maintaining a somewhat heavy-weight special interface layer as I grow my code on both sides of the divide. Preferably the suture line is as far over on the Objective-C side as possible, so that I can write pretty much everything in Haskell. Now, I see a couple of references to some options: - HOC seems very close to what I'm looking for, but the project looks pretty 'dormant'. - I see some mention of an Objective-C FFI, but am uncertain if this is in any current build of GHC. Are there any other options up anyone's sleeves? Anybody working on something interesting I could play with? Until recently, I was concerned about being able to use GC on the Objective-C side, but with Apple's new ARC memory management model, that's no longer an issue. Most Haskell-ObjC bindings that already exist are surely designed for Retain-Release, which I assume is not disrupted by ARC as this is just RR at runtime. -- Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
