Re: [Haskell-cafe] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
Carter: Not yet. I'll get round to it once I'm done with with an Agda presentation I'm working on. Until then I can't afford to break my environment. On Fri, Sep 28, 2012 at 1:56 PM, Carter Schonwald carter.schonw...@gmail.com wrote: 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 maydw...@gmail.com 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 christiaan.ba...@gmail.com 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 unpacked-folder/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?
The GLUT-backend calls system.exit when the window is closed, because 'exitMainLoop' is only defined within freeglut, which is not by default installed on non-linux platforms. There is hence no real point in running gloss applications with the GLUT-backend from GHCi. I'll try to find a mountain lion install, and test if there's a difference between GLUT and GLFW On Sep 28, 2012, at 7:56 AM, Carter Schonwald wrote: 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? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Call for discussion: OverloadedLists extension
Michael Snoyman wrote: Heinrich Apfelmus wrote: Michael Snoyman wrote: Note that I wasn't necessarily advocating such a pragma. And a lot of my XML code actually *does* use two IsString instances at the same time, e.g.: Element (img :: Name) (singleton (href :: Name) (foo.png :: Text)) [NodeComment (No content inside an image :: Text)] In this particular case, would it make sense to use smart constructors instead? The idea is that you can put the polymorphism in two places: either make the output polymorphic, or make the input polymorphic. The latter would correspond to a type element :: (IsString name, IsString s, IsMap map) = name - map name s - [Element] element name map = Element (toName name) (toMap map) One benefit would be that the function will accept any list as a map, not just list literals. Just to clarify: this would be a *replacement* for OverloadedStrings usage, right? If used in conjunction with OverloadedStrings, we'd run into the too-much-polymorphism issue you describe in your initial email in this thread, since `element foo'` would become `element (fromString foo)` which would become `Element ((toName . fromString) foo)`, and `toName . fromString` makes it ambiguous what the intermediate data type is. Yes, indeed, it would be an alternative approach. Assuming this is meant are a replacement, I see two downsides. Firstly, this would work for construction, but not for deconstruction. Currently, I can do something like: handleList :: Element - Element handleList (Element ul _ _) = ... handleList e = e Good point. On the other hand, there is another extension, ViewPatterns, which solves the problem of pattern matching on abstract data types in full generality, allowing things like handleList (viewAsStrings - Element ul _ _) = ... While more intrusive, the benefit of this extension is that a lot of other code could likely become neater as well. The other is that we've only solved one specific case by providing a replacement function. In order to keep code just as terse as it is now, we'd have to provide a whole slew of replacement functions. For example, consider the code: handleList (Element ul attrs _) = case Map.lookup class attrs of If we get rid of OverloadedStrings, then we need to either provide a replacement `lookup` function which performs the conversion from String to Name, or change all lookup calls to explicitly perform that lookup. Ah, I see. Since the Name type is abstract, I feel it's alright to add the polymorphism to functions like element , but Map.lookup is indeed a problem. One option would be to make a new type NameMap specifically for Name as key, but that seems a little overkill. The other option is to bite the bullet and add the conversion by hand Map.lookup (name class) . In this case, I think I would go with a lightweight first option and simply give a new name to the Map.lookup combination and use the opportunity to sneak in some polymorphism. getAttribute name = Map.lookup (toText name) In my experience, turning all data types into abstractions works quite well, but I can see that you can't avoid an annoying conversion if you just want to use a quick Map.lookup . Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Sylvia, a lambda calculus visualizer
Sylvia is a lambda calculus visualizer. Such a thing is certainly nice to have. I use this one for teaching: http://joerg.endrullis.de/lambdaCalculator.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 6.13 and GHC 7.6 in parallel on Linux
How is it possible to run 2 different versions of GHC if you installed the binary packages in standard locations, look in /usr/local/bin/ghc* : you have ghc-6.12.3, ghc-7.6.1 etc. and each one knows how to find their libraries. you can even say cabal install --with-ghc=ghc-7.6.1 foo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Class constraints with free type variables and fundeps
I would expect this to work, maybe with some additional notation (a la
ScopedTypeVariables)
{-# LANGUAGE FunctionalDependencies #-}
{-# LANGUAGE MultiParamTypeClasses #-}
class Foo a b | a - b
class Foo a b = Bar a where
foo :: a - b - c
The type family equivalent works as expected:
{-# LANGUAGE TypeFamilies #-}
class Foo a where
type T a :: *
class Bar a where
foo :: a - T a - c
I can't use type families because the `Foo' I'm using is in an external library.
Is there any way to achieve what I want without adding `b' to `Bar'?
--
Francesco * Often in error, never in doubt
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ticketimer - haskell project on Gruender-Garage contest!
I'd like to announce ticketimer.com -- it's a website that is not done yet. With ticketimer you can choose films for your local cinema. People can buy tickets in advance and promote the films they like. Do we need to eat this blockbuster stuff all the time? See how to vote for a change on http://www.indiegogo.com/ticketimer?a=1301421 We are going to use Yesod as a main weapon. Anton ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] a parallel mapM?
I'm new to concurrent programming in Haskell. I'm looking for a drop-in replacement for 'mapM' to parallelize a set of independent IO operations. I hoped 'mapConcurrently' might be it, but I need something that will only spawn as many threads as I have CPUs available [1]. I also tried Control.Parallel.Strategies [2]. While that route works, I had to use unsafePerformIO. Considering that IO is for sequencing effects and my IO operation doesn't cause any side-effects (besides hogging a file handle), is this a proper use of unsafePerformIO? Attempt 1 -- import System.Process(readProcess) import Control.Concurrent.Async(mapConcurrently) main :: IO [String] main = mapConcurrently (\n - readProcess echo [test: ++ show n] ) [0..1000] $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.1 $ runghc test.hs test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: echo: createProcess: resource exhausted (Too many open files) Attempt 2 -- import System.Process(readProcess) import Control.Parallel.Strategies(parMap, rpar) import System.IO.Unsafe(unsafePerformIO) main :: IO [String] main = myMapConcurrently (\n - readProcess echo [test: ++ show n] ) [0..1000] where myMapConcurrently f = return . parMap rpar (unsafePerformIO . f) $ runghc test.hs /dev/null echo Success Success Thanks, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Discovery of unnecessary build-depends
Is there a tool available that will tell me if the cabal file for my library or application has any unnecessary build-depends? I have a habit of developing new modules within an application and then moving them out to separate libraries. For instance, I might move module Foo out of my application and into a new or existing library package. If Foo was the only module in my application to explicitly import any modules from the Bar package, I would like to know that I can now remove the dependency on Bar from my application's build-depends in the cabal file. My strategy right now would be to search my whole application for other imports of any of the modules from the Bar package, or just remove Bar from build-depends and check if the application still compiles. Neither solution is particularly scalable or satisfying. Cheers, Jason Whittle ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Call for discussion: OverloadedLists extension
On 12-09-26 08:07 PM, wren ng thornton wrote: On 9/25/12 1:57 PM, Sjoerd Visscher wrote: Maybe we could make a literal [a,b,c] turn into unpack [a,b,c]# where [a,b,c]# is a statically-allocated vector? I'm kinda surprised this isn't already being done. Just doing this seems like it'd be a good undertaking, regardless of whether we get overloaded list literals. Just storing the literal as a C-like array and inflating it to a list/array/vector at runtime seems like it should be a big win for code that uses a lot of literals. Why? I'm surprised that this is an issue at all. If list literals you are talking about are constant, wouldn't GHC apply constant folding and construct the list only the first time it's needed? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a parallel mapM?
Check out the parallel combinators in parallel-io: http://hackage.haskell.org/packages/archive/parallel-io/0.3.2/doc/html/Control-Concurrent-ParallelIO-Global.html On Fri, Sep 28, 2012 at 1:01 PM, Greg Fitzgerald gari...@gmail.com wrote: I'm new to concurrent programming in Haskell. I'm looking for a drop-in replacement for 'mapM' to parallelize a set of independent IO operations. I hoped 'mapConcurrently' might be it, but I need something that will only spawn as many threads as I have CPUs available [1]. I also tried Control.Parallel.Strategies [2]. While that route works, I had to use unsafePerformIO. Considering that IO is for sequencing effects and my IO operation doesn't cause any side-effects (besides hogging a file handle), is this a proper use of unsafePerformIO? Attempt 1 -- import System.Process(readProcess) import Control.Concurrent.Async(mapConcurrently) main :: IO [String] main = mapConcurrently (\n - readProcess echo [test: ++ show n] ) [0..1000] $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.1 $ runghc test.hs test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: echo: createProcess: resource exhausted (Too many open files) Attempt 2 -- import System.Process(readProcess) import Control.Parallel.Strategies(parMap, rpar) import System.IO.Unsafe(unsafePerformIO) main :: IO [String] main = myMapConcurrently (\n - readProcess echo [test: ++ show n] ) [0..1000] where myMapConcurrently f = return . parMap rpar (unsafePerformIO . f) $ runghc test.hs /dev/null echo Success Success Thanks, Greg ___ 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 parallel mapM?
On 28/09/12 19:58, Patrick Mylund Nielsen wrote: Check out the parallel combinators in parallel-io: http://hackage.haskell.org/packages/archive/parallel-io/0.3.2/doc/html/Control-Concurrent-ParallelIO-Global.html also http://hackage.haskell.org/packages/archive/spawn/latest/doc/html/Control-Concurrent-Spawn.html#v:parMapIO combined with http://hackage.haskell.org/packages/archive/spawn/latest/doc/html/Control-Concurrent-Spawn.html#v:pool might be a solution Claude -- http://mathr.co.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a parallel mapM?
Check out the parallel combinators in parallel-io: Cool, that's the library I'm looking for! I see it uses 'numCapabilities' to get the command-line value for '-N' and not 'getNumCapabilities' to query the system for how many cores are available. So using the 'Local' module, this works: parMapM f xs = do n - getNumCapabilities withPool n $ \pool - parallel pool (map f xs) Thanks, Greg On Fri, Sep 28, 2012 at 11:58 AM, Patrick Mylund Nielsen hask...@patrickmylund.com wrote: Check out the parallel combinators in parallel-io: http://hackage.haskell.org/packages/archive/parallel-io/0.3.2/doc/html/Control-Concurrent-ParallelIO-Global.html On Fri, Sep 28, 2012 at 1:01 PM, Greg Fitzgerald gari...@gmail.com wrote: I'm new to concurrent programming in Haskell. I'm looking for a drop-in replacement for 'mapM' to parallelize a set of independent IO operations. I hoped 'mapConcurrently' might be it, but I need something that will only spawn as many threads as I have CPUs available [1]. I also tried Control.Parallel.Strategies [2]. While that route works, I had to use unsafePerformIO. Considering that IO is for sequencing effects and my IO operation doesn't cause any side-effects (besides hogging a file handle), is this a proper use of unsafePerformIO? Attempt 1 -- import System.Process(readProcess) import Control.Concurrent.Async(mapConcurrently) main :: IO [String] main = mapConcurrently (\n - readProcess echo [test: ++ show n] ) [0..1000] $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.1 $ runghc test.hs test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: echo: createProcess: resource exhausted (Too many open files) Attempt 2 -- import System.Process(readProcess) import Control.Parallel.Strategies(parMap, rpar) import System.IO.Unsafe(unsafePerformIO) main :: IO [String] main = myMapConcurrently (\n - readProcess echo [test: ++ show n] ) [0..1000] where myMapConcurrently f = return . parMap rpar (unsafePerformIO . f) $ runghc test.hs /dev/null echo Success Success Thanks, Greg ___ 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 parallel mapM?
On Fri, Sep 28, 2012 at 11:01 AM, Greg Fitzgerald gari...@gmail.com wrote: I also tried Control.Parallel.Strategies [2]. While that route works, I had to use unsafePerformIO. Considering that IO is for sequencing effects and my IO operation doesn't cause any side-effects (besides hogging a file handle), is this a proper use of unsafePerformIO? That's actually a perfectly fine use for unsafePerformIO, since the IO action you are performing is pure and therefore safe (modulo your file handle stuff). unsafePerformIO is a problem when the IO action being run has side effects and their order of evaluation matters (since unsafePerformIO will cause them to be run in an unpredictable order) One common use for unsafePerformIO is to run a query against an external library. It has to be done in the IO monad, but it is a pure computation insofar as it has no side-effects that matter. Doing this lets us promote values defined in external libraries to bona fide pure Haskell values. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Class constraints with free type variables and fundeps
CCing the list back. At Fri, 28 Sep 2012 13:30:52 -0700, Alexander Solla wrote: What is the problem, exactly? It looks to me like UndecidableInstances and ScopedTypeVariables (on foo, or its arguments) would be enough. I'm not sure what you mean. I don't see the need for UndecidableInstances, and there is no way I can see to bring the `b' into scope in the type sig for foo, ScopedTypeVariables or not - unless I'm missing something. Also note that as stated, foo's type is a bottom (more specifically, is a function onto bottom, since c is free in the class, and so foo must be parametrically polymorphic in its return type, and so is devoid of real Haskell values). Hopefully that is just an artefact of the translation to Foo's and Bar's. Yeah the type for `foo' is irrelevant, I just needed to put something there. -- Francesco * Often in error, never in doubt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Class constraints with free type variables and fundeps
On Fri, Sep 28, 2012 at 5:04 PM, Francesco Mazzoli f...@mazzo.li wrote: CCing the list back. At Fri, 28 Sep 2012 13:30:52 -0700, Alexander Solla wrote: What is the problem, exactly? It looks to me like UndecidableInstances and ScopedTypeVariables (on foo, or its arguments) would be enough. I'm not sure what you mean. I don't see the need for UndecidableInstances, and there is no way I can see to bring the `b' into scope in the type sig for foo, ScopedTypeVariables or not - unless I'm missing something. Well, then what exactly is the problem? Are you getting an error? You don't need to bring 'b' into scope. You will already have real types in scope. instance Foo A B instance Bar A where foo A B = C tryIt = (foo :: A - B - C) A B ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Class constraints with free type variables and fundeps
At Fri, 28 Sep 2012 17:19:36 -0700, Alexander Solla wrote: Well, then what exactly is the problem? Are you getting an error? ...well yes. The error I get with the posted class declarations is Not in scope: type variable `b' at the line with class Foo a b = Bar a where Which I get because all the type vars in the LHS must be referenced on the RHS (or so it seems). Now, in my case the problem does not stop there, because I also want to reference the tyvar on the LHS in a type signature of a method, since in that case there is a fundep on b (`a - b'), which makes `b' decidable if you have `a' and `Foo a b'. You don't need to bring 'b' into scope. You will already have real types in scope. instance Foo A B instance Bar A where foo A B = C Again, I'm not sure what you mean here. -- Francesco * Often in error, never in doubt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Class constraints with free type variables and fundeps
On Fri, Sep 28, 2012 at 5:36 PM, Francesco Mazzoli f...@mazzo.li wrote: At Fri, 28 Sep 2012 17:19:36 -0700, Alexander Solla wrote: Well, then what exactly is the problem? Are you getting an error? ...well yes. The error I get with the posted class declarations is Not in scope: type variable `b' at the line with class Foo a b = Bar a where Which I get because all the type vars in the LHS must be referenced on the RHS (or so it seems). Yes, indeed. Now, in my case the problem does not stop there, because I also want to reference the tyvar on the LHS in a type signature of a method, since in that case there is a fundep on b (`a - b'), which makes `b' decidable if you have `a' and `Foo a b'. Only with respect to type inference. You don't need to bring 'b' into scope. You will already have real types in scope. instance Foo A B instance Bar A where foo A B = C Again, I'm not sure what you mean here. I wouldn't have replied with that line of thought if you had just told us what the problem was in the first place. I /was/ saying that you can use explicit type annotations to disambiguate instances. Most of us haven't memorized the Haskell 2010 report. We let the compiler tell us what's wrong and either learn why, or how to fix it. So post your errors. By the way, it is rather rude to publicly post a private email... Now, on to your real problem. Use TypeFamilies instead: class Foo a where type BarThing a :: * class Foo a = Bar a where foo :: a - BarThing a - b This is pretty pointless, since you can just refactor into the nearly equivalent: class Foo a class Foo a = Bar a where type BarThing a :: * foo :: a - BarThing a - c It may or may not matter to which family the type synonym belongs. What is the problem you are actually trying to solve? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
