Re: [Haskell-cafe] building ghc on arch linux ARM?
On 04/ 9/12 10:35 AM, Graham Klyne wrote: It ships with Debian, along with the full Haskell Platform built for ARM and lots of other libraries. Other than speed, it's fine. Hmmm... I wonder if it will squeeze onto a Raspberry Pi :) It should, if not report a bug since I regularly test on ARMv7 (even GHC buildbot is using ARMv7) (side note: GHC HEAD currently broken), but Raspberry Pi provides just Broadcom BCM2835 which should be ARM1176JZFS, i.e. ARMv5. But rest assured, ARMv5 should be supported by GHC... Karel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] building ghc on arch linux ARM?
On 04/ 9/12 01:03 AM, Francesco Mazzoli wrote: No, it is not possible to build GHC without GHC. Building GHC on ARM is going to be extremely tricky (I'm not sure anyone has ever done it). It's not that tricky at the end. Just install LLVM 3.0 and some OS supplied unregisterised GHC. Grab 7.4.1. sources and attempt to compile. This should produce even registerised build for you as a result of project initiated last summer by Stephen Blackheath. If you are curious about its history read some posts on http://ghcarm.wordpress.com/ Cheers, Karel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHCi runtime linker: fatal error (was Installing REPA)
On 08/04/2012, at 2:41 AM, Dominic Steinitz wrote: >> Hi Ben, Chris and Others, >> >> Thanks for your replies and suggestions. All I want to do is invert (well >> solve actually) a tridiagonal matrix so upgrading ghc from the version that >> comes with the platform seems a bit overkill. I think I will go with Chris' >> suggestion for now and maybe upgrade ghc (and REPA) when I am feeling braver. >> >> Dominic. > Sadly I now get this when trying to mulitply two matrices. Is this because I > have two copies of Primitive? I thought Cabal was supposed to protect me from > this sort of occurrence. Does anyone have any suggestions on how to solve > this? You'll need to upgrade. Trying to support old versions of software is a lost cause. I pushed Repa 3.1 to Hackage on the weekend. It has a *much* cleaner API. I can't recommend continuing to use Repa 2. You will just run into all the problems that are now fixed in Repa 3. Ben. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I Need a Better Functional Language!
A concurring opinion here, and an example. iff :: Bol -> a -> a -> a iff True x _ = x iff False _ x = x f, g :: Bool -> Bool f x = x g x = iff x True False Are these two functions equal? I would say yes, they are. Yet once you can pattern match on functions, you can easily tell these functions apart, and create a function h :: (Bool -> Bool) -> Bool such that h f => True but h g => False. -- ryan On Thu, Apr 5, 2012 at 8:52 AM, Dan Doel wrote: > On Thu, Apr 5, 2012 at 10:14 AM, Grigory Sarnitskiy > wrote: > > First, what are 'functions' we are interested at? It can't be the usual > set-theoretic definition, since it is not constructive. The constructive > definition should imply functions that can be constructed, computed. Thus > these are computable functions that should be of our concern. But > computable functions in essence are just a synonym for programs. > > This is a flawed premise. The point of working with functions is > abstraction, and that abstraction is given by extensional equality of > functions: > >f = g iff forall x. f x = g x > > So functions are not synonymous with programs or algorithms, they > correspond to an equivalence class of algorithms that produce the same > results from the same starting points. If you can access the source of > functions within the language, this abstraction has been broken. > > And this abstraction is useful, because it allows you to switch freely > between programs that do the same thing without having to worry that > someone somewhere is relying on the particular algorithm or source. > This is the heart of optimization and refactoring and the like. > > There are places for metaprogramming, or perhaps even a type of > algorithms that can be distinguished by means other than the functions > they compute. But to say that functions are that type is false, and > that functions should mean that is, I think, wrong headed. > > -- Dan > > ___ > 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] ANNOUNCE: pipes-core 0.1.0
I'm pleased to announce the release of version 0.1.0 of pipes-core, a library for efficient, safe and compositional IO, similar in scope to iteratee and conduits. http://hackage.haskell.org/package/pipes-core This release fixes a mistake in the previous version which violated the category laws in certain cases. I have now written a fairly explicit proof of the category laws for the current implementation, which I'll try to keep updated as the library evolves: https://github.com/pcapriotti/pipes-core/wiki/Category-laws-for-pipes --- # CHANGELOG for pipes-core: ## Version 0.1.0 - Significant simplification of the internals. - Removed `ensure` primitive. # CHANGELOG for pipes-extra: ## Version 0.1.0 - Improved naming in Control.Pipe.Coroutine. - Replaced ChunkPipe with PutbackPipe. --- BR, Paolo Capriotti ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: plugins-1.5.2.1
Hello, I will update the description. The documentation is not on hackage yet because the haddock builder only runs a few times a day. That should correct itself in a few hours -- unless the build fails for some reason. However, the API has not changed from the previous version, so these docs are still valid: http://hackage.haskell.org/package/plugins-1.5.1.4 - jeremy On Mon, Apr 9, 2012 at 1:21 PM, Jeremy Shaw wrote: > Hello! > > I am pleased to announce the release of plugins-1.5.2.1: > > http://hackage.haskell.org/package/plugins > > The plugins library provides facilities to compile and dynamically > load/link Haskell code into a running Haskell application. (The > related, plugins-auto package adds support for file watching via > inontify and automatic recompilation and reloading, > http://hackage.haskell.org/package/plugins). > > There are three important changes in this release: > > 1. Support for GHC 7.0, 7.2. and 7.4. We have not *knowingly* dropped > support for GHC 6.12. So, if you still use an older compiler and we > broke it.. we might be willing to fix it still :) > > 2. New maintainer: Don Stewart has graciously allowed me to take over > the project. I do not have any immediate plans for big changes. But I > do plan to: keep it compiling, apply patches in a timely manner, and > deal with other minor bug fixes. I would certainly love to see some > major improvements. I believe plugins predates the GHC API and, > accordingly, does not use it as well as it could. If someone wanted to > give plugins some major love, that would be awesome. While plugins has > not much recent development, there are still a lot of people that are > using it, or would like to. > > 3. the source has moved to patch-tag and darcs 2, > > http://patch-tag.com/r/stepcut/plugins > > patch-tag only supports darcs 2 format repositories, so this forced > me to run darcs convert to switch from darcs 1 to darcs 2 format. In > the end that is a good thing. The only downside is that I can not > directly apply any darcs 1 patches to the repo now. But I doubt there > are many floating around anyway. And I can still apply them the hard > way. > > - jeremy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I Need a Better Functional Language!
On Thu, Apr 5, 2012 at 7:14 AM, Grigory Sarnitskiy wrote: > Hello! I've just realized that Haskell is no good for working with > functions! > > First, what are 'functions' we are interested at? It can't be the usual > set-theoretic definition, since it is not constructive. The constructive > definition should imply functions that can be constructed, computed. Thus > these are computable functions that should be of our concern. But > computable functions in essence are just a synonym for programs. > The usual set theoretic definition is constructive -- it is the extension of the definition which is non-constructive. We can restrict the extension to constructive domains. Note that we do not need the law of the excluded middle or double negation to define a function. We can easily define: > newtype Function a b = Function (Set (a,b)) > apply :: (Function a b) -> a -> b > apply f a = findMin . filter (\(a',_) -> a == a') $ f and enforce the function definition/axioms with a smart constructor. (A Map is probably a better data structure for this purpose) Obviously, that's not all of the imaginable possibilities. One also can > rewrite programs. And write programs that rewrite programs. And write > programs that rewrite programs that rewrite the first programs and so on. > But there is no such possibility in Haskell, except for introducing a DSL. > > You will always need a DSL of some kind. Otherwise, what will you quantify over? This is an important point. In order to give a function semantics, it /must/ be interpreted. This will either happen by the compiler, which interprets a function definition in terms of machine code (or Haskell code, if you use Template Haskell), or at run-time, as in the "Function a b" type above. With some appropriate constraints, you can even rewrite a (->)-function in terms of a "Function"-function, and vice-versa. toFunction :: (Enum a, Bounded a) => (a -> b) -> (Function a b) toFunction f = Set.fromList . fmap f $ [minBound..maxBound] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: plugins-1.5.2.1
Hello! I am pleased to announce the release of plugins-1.5.2.1: http://hackage.haskell.org/package/plugins The plugins library provides facilities to compile and dynamically load/link Haskell code into a running Haskell application. (The related, plugins-auto package adds support for file watching via inontify and automatic recompilation and reloading, http://hackage.haskell.org/package/plugins). There are three important changes in this release: 1. Support for GHC 7.0, 7.2. and 7.4. We have not *knowingly* dropped support for GHC 6.12. So, if you still use an older compiler and we broke it.. we might be willing to fix it still :) 2. New maintainer: Don Stewart has graciously allowed me to take over the project. I do not have any immediate plans for big changes. But I do plan to: keep it compiling, apply patches in a timely manner, and deal with other minor bug fixes. I would certainly love to see some major improvements. I believe plugins predates the GHC API and, accordingly, does not use it as well as it could. If someone wanted to give plugins some major love, that would be awesome. While plugins has not much recent development, there are still a lot of people that are using it, or would like to. 3. the source has moved to patch-tag and darcs 2, http://patch-tag.com/r/stepcut/plugins patch-tag only supports darcs 2 format repositories, so this forced me to run darcs convert to switch from darcs 1 to darcs 2 format. In the end that is a good thing. The only downside is that I can not directly apply any darcs 1 patches to the repo now. But I doubt there are many floating around anyway. And I can still apply them the hard way. - jeremy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Guide for converting existing code to Conduit 0.4?
On Mon, Apr 9, 2012 at 2:37 PM, Ivan Lazar Miljenovic wrote: > On 9 April 2012 21:34, Michael Snoyman wrote: >> >> It's caused by fmap. This is one of the downsides with the move to a >> single type: > > I've been reading the various posts you've been making about Conduit, > and this is something I still don't get: wasn't one of the original > strengths you touted for Conduit that usage of different types made > for better error messages, etc.? As such, why have you now switched > to a single type and thus causing these kinds of problems again? Honestly, I'm still torn on this. If you read through the arguments in Reddit, you'll see a lot of: Everyone else: Well, obviously this is more elegant because it's a single type Me: Err I'm not convinced. There *are* definitely advantages to this new approach, but there are also costs. The fact that such a huge part of the codebase simply disappeared, and that it's easier to step through the remaining code and convince myself that it's doing the right thing, is what put me over the edge on this one. To clarify just a bit: the *main* advantage of conduit's multiple types approach (versus enumerator where everything is an Iteratee) is that (1) it's easier to understand, and (2) it makes it possible to do things like resumable sources. Both of those advantages still hold: writing a Conduit retains its relative simplicity versus an Enumeratee in this new system, for example. The downside is really the error messages and the instances. It might be that we decide to introduces newtype wrappers for Source, Conduit, and Sink in the future to solve these problems, I'm not sure. For now, it seems like an acceptable trade-off. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Guide for converting existing code to Conduit 0.4?
On 9 April 2012 21:34, Michael Snoyman wrote: > > It's caused by fmap. This is one of the downsides with the move to a > single type: I've been reading the various posts you've been making about Conduit, and this is something I still don't get: wasn't one of the original strengths you touted for Conduit that usage of different types made for better error messages, etc.? As such, why have you now switched to a single type and thus causing these kinds of problems again? -- 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
Re: [Haskell-cafe] Guide for converting existing code to Conduit 0.4?
On Mon, Apr 9, 2012 at 2:27 PM, Erik de Castro Lopo wrote: > Michael Snoyman wrote: > >> Hmm... I'd be surprised if you really need the Pipe signature that >> you're providing. > > I'm not providing it, the compiler is suggesting it: > > Network/HTTP/Proxy.hs:835:47: > Couldn't match expected type `ByteString' with actual type `()' > Expected type: C.Pipe Void ByteString (ResourceT IO) ByteString > Actual type: C.Source (ResourceT IO) ByteString > In the return type of a call of `requestBody' > In the second argument of `($)', namely `requestBody req' > > For the code: > > HC.requestBody = HC.RequestBodySource contentLength > $ fmap copyByteString > $ Wai.requestBody req > > but the type of the RequestBodySource constructor and Wai.requestBody > hasn't changed. > > Erik > -- > -- > Erik de Castro Lopo > http://www.mega-nerd.com/ > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe It's caused by fmap. This is one of the downsides with the move to a single type: some of the instances don't make sense anymore. In particular, Functor will allow you to map the *result* type, not the *output* type. I think I'll add a helper function- mapOutput- to the next version of conduit. Meanwhile, you can use: Wai.requestBody req $= Data.Conduit.List.map copyByteString Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Guide for converting existing code to Conduit 0.4?
Michael Snoyman wrote: > Hmm... I'd be surprised if you really need the Pipe signature that > you're providing. I'm not providing it, the compiler is suggesting it: Network/HTTP/Proxy.hs:835:47: Couldn't match expected type `ByteString' with actual type `()' Expected type: C.Pipe Void ByteString (ResourceT IO) ByteString Actual type: C.Source (ResourceT IO) ByteString In the return type of a call of `requestBody' In the second argument of `($)', namely `requestBody req' For the code: HC.requestBody = HC.RequestBodySource contentLength $ fmap copyByteString $ Wai.requestBody req but the type of the RequestBodySource constructor and Wai.requestBody hasn't changed. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Guide for converting existing code to Conduit 0.4?
On Mon, Apr 9, 2012 at 12:58 PM, Erik de Castro Lopo wrote: > Hi all, > > Is there some sort of a guide for converting existing code Conduit 0.4? > > What happened to Control.Monad.Trans.Resource.with? > > What happens to stuff that used to to have a type "C.Source m a" which > now seems to need type "C.Pipe Void a (ResourceT m) a"? Hmm... I'd be surprised if you really need the Pipe signature that you're providing. That would mean that you are providing an output stream of `a`, PLUS a final result of `a`. Most likely, what you want is: Pipe Void a (ResourceT m) () which would be identical to: Source (ResourceT m) a The recommended approach though would be more like: MonadResource m => Source m a Since that gives more flexibility about where in your monad stack you place the ResourceT. Michael > > Cheers, > Erik > -- > -- > Erik de Castro Lopo > http://www.mega-nerd.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] Guide for converting existing code to Conduit 0.4?
Dmitry Olshansky wrote: > I transfered my code from 0.3 to 0.4 without any changes. There are type > synonyms in Conduit for that. > > Changes were from 0.2 to 0.3. Michael discribed it here > http://www.yesodweb.com/blog/2012/03/announcing-conduit-0-3 Ok, so Control.Monad.Trans.Resource.with gets replaced with Control.Monad.Trans.Resource.allocate. > Actually, in 0.4 > > no changes with Control.Monad.Trans.Resource. > type Source m a = Pipe Void a m () > old Conduit-API use type synonyms and not changed My code has a lot of low level Conduit stuff and hence I run into a bunch of the lower level issues. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Guide for converting existing code to Conduit 0.4?
I transfered my code from 0.3 to 0.4 without any changes. There are type synonyms in Conduit for that. Changes were from 0.2 to 0.3. Michael discribed it here http://www.yesodweb.com/blog/2012/03/announcing-conduit-0-3 Actually, in 0.4 no changes with Control.Monad.Trans.Resource. type Source m a = Pipe Void a m () old Conduit-API use type synonyms and not changed 2012/4/9 Erik de Castro Lopo > Hi all, > > Is there some sort of a guide for converting existing code Conduit 0.4? > > What happened to Control.Monad.Trans.Resource.with? > > What happens to stuff that used to to have a type "C.Source m a" which > now seems to need type "C.Pipe Void a (ResourceT m) a"? > > Cheers, > Erik > -- > -- > Erik de Castro Lopo > http://www.mega-nerd.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
[Haskell-cafe] Guide for converting existing code to Conduit 0.4?
Hi all, Is there some sort of a guide for converting existing code Conduit 0.4? What happened to Control.Monad.Trans.Resource.with? What happens to stuff that used to to have a type "C.Source m a" which now seems to need type "C.Pipe Void a (ResourceT m) a"? Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] building ghc on arch linux ARM?
On 09/04/2012 00:45, Joey Hess wrote: Thomas DuBuisson wrote: On Sun, Apr 8, 2012 at 4:03 PM, Francesco Mazzoli wrote: No, it is not possible to build GHC without GHC. Building GHC on ARM is going to be extremely tricky (I'm not sure anyone has ever done it). I used to use an unregistered build of GHC built by someone in the Debian community - it worked well enough. It ships with Debian, along with the full Haskell Platform built for ARM and lots of other libraries. Other than speed, it's fine. Hmmm... I wonder if it will squeeze onto a Raspberry Pi :) #g -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory Questions
On Mon, Apr 9, 2012 at 9:47 AM, wren ng thornton wrote: > On 4/9/12 12:37 AM, Sergiu Ivanov wrote: >> >> I am currently studying category theory by the book Joy of Cats. Are >> there any people whom I could ask some questions related to category >> theory from time to time? Or could I just post my questions here >> directly? > > > In addition to the math venues others've mentioned, if you're into IRC then > you can also try #haskell-in-depth and ##categorytheory for a more real-time > interaction. For quick/beginner questions that's probably better than either > mailing lists or stackoverflow (unless the latter are specifically dedicated > to the topic). Ah, that's great, thank you! I couldn't even imagine that there was an IRC channel on CT! > That said, there are a number of us here who're familiar with CT and willing > to provide pointers, insights, and discussions. I think I could notice that, this is why I asked this question here :-) Thank you everyone for your feedback! Sergiu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
