On Mon, Oct 14, 2013 at 3:42 PM, Joachim Breitner
wrote:
> Hi,
>
> Am Sonntag, den 13.10.2013, 17:50 +0200 schrieb Michael Snoyman:
>
> > I wanted to announce that FP Complete is now running a Jenkins job to
> > build Stackage with GHC 7.8. You can see the current res
Hi everyone,
I wanted to announce that FP Complete is now running a Jenkins job to build
Stackage with GHC 7.8. You can see the current results in the relevant
Github issue[1]. Essentially, we're still trying to get version bounds
updated so that a build can commence.
I'd like to ask two things f
n terms of monadic bind and return), but I think we could probably
state Applicative versions of those laws (assuming I haven't made a stupid
mistake):
lift . pure = pure
lift (x <*> y) = lift x <*> lift y
Michael
> 2013/10/1 Michael Snoyman
>
>> I'm wonderi
On Tue, Oct 1, 2013 at 12:15 PM, Dan Burton wrote:
> From what you've said, it sounds like you can already write:
>
> serverSide :: IO a -> Form a
>
> This seems elegant enough to me for your needs. Just encourage it as an
> idiom specific to Forms.
>
> myBlogForm = Blog <$> titleForm <*>
I'm wondering if anyone's run into this problem before, and if there's a
common solution.
In Yesod, we have applicative forms (based originally on formlets). These
forms are instances of Applicative, but not of Monad. Let's consider a
situation where we want to get some user input to fill out a bl
On Tue, Sep 17, 2013 at 4:25 AM, John Lato wrote:
> On Mon, Sep 16, 2013 at 4:57 AM, Michael Snoyman wrote:
>
>>
>> I think I just made a bad assumption about what you were proposing. If I
>> was going to introduce a typeclass like this, I'd want it to support `Set
On Mon, Sep 16, 2013 at 10:34 AM, John Lato wrote:
> On Fri, Sep 13, 2013 at 12:48 AM, Michael Snoyman wrote:
>
>>
>>
>>
>> On Thu, Sep 12, 2013 at 2:37 AM, John Lato wrote:
>>
>>> I didn't see this message and replied privately to Michae
On Fri, Sep 13, 2013 at 10:07 AM, Mario Blažević wrote:
> On 09/13/13 02:28, Michael Snoyman wrote:
>
>>
>>
>>
>> On Fri, Sep 13, 2013 at 9:18 AM, Mario Blažević > blama...@acanac.net>> wrote:
>>
>> On 09/13/13 01:51, Michael Snoyman w
On Fri, Sep 13, 2013 at 9:18 AM, Mario Blažević wrote:
> On 09/13/13 01:51, Michael Snoyman wrote:
>>
>> On Fri, Sep 13, 2013 at 5:38 AM, Mario Blažević > blama...@acanac.net>> wrote:
>>
>> On 09/11/13 19:37, John Lato wrote:
>>
>>
>
On Fri, Sep 13, 2013 at 5:38 AM, Mario Blažević wrote:
> On 09/11/13 19:37, John Lato wrote:
>
>> I didn't see this message and replied privately to Michael earlier, so
>> I'm replicating my comments here.
>>
>> 1. Sooner or later I expect you'll want something like this:
>>
>> class LooseMap c
g -> foo` doesn't let you know whether it's a
strict or lazy bytestring.
- I got specific feedback from Edward that it would be easier to include
instances for these classes if the names didn't clash with standard
terminology.
- It leaves the door open for inclu
That's really funny timing. I started work on a very similar project just
this week:
https://github.com/snoyberg/mono-traversable
It's not refined yet, which is why I haven't discussed it too publicly, but
it's probably at the point where some review would make sense. There's been
a bit of a disc
I'll admit, I also thought it was a joke.
On Tue, Sep 10, 2013 at 2:34 PM, Ian Ross wrote:
> Me too, but I wasn't brave enough to say so after people seemed to be
> taking it seriously...
>
>
> On 10 September 2013 13:33, Roman Cheplyaka wrote:
>
>> * John Wiegley [2013-09-10 04:48:36-0500]
>
You can build this up using the >=< operator[1] in stm-conduit, something
like:
eitherSrc :: MonadResourceBase m
=> Source (ResourceT m) a -> Source (ResourceT m) b -> Source
(ResourceT m) (Either a b)
eitherSrc src1 src2 = do
join $ lift $ Data.Conduit.mapOutput Left src1 >=<
Dat
I've actually been intending to add the client side code to that package,
but I simply haven't gotten around to it yet. It's actually not that
complicated, but it does require some thought on the right interface for
things like approving/rejecting server side certificates. If you open up an
issue o
27;d
> like to see improvements if possible. So if anyone is exploring the design
> space, I'd be willing to participate.
>
>
> On Fri, Jul 12, 2013 at 12:57 AM, Michael Snoyman wrote:
>
>>
>>
>>
>> On Thu, Jul 11, 2013 at 6:07 PM, Felipe Almeida Lessa <
On Thu, Jul 11, 2013 at 6:07 PM, Felipe Almeida Lessa <
felipe.le...@gmail.com> wrote:
> On Thu, Jul 11, 2013 at 10:56 AM, Michael Snoyman
> wrote:
> > The only
> > approach that handles the situation correctly is John's separate thread
> > approach (tryAl
On Thu, Jul 11, 2013 at 3:44 AM, John Lato wrote:
> Hi Michael,
>
> I don't think those are particularly niche cases, but I still think this
> is a bad approach to solving the problem. My reply to Erik explicitly
> covers the worker thread case, and for running arbitrary user code (as in
> your
On Wed, Jul 10, 2013 at 1:01 PM, John Lato wrote:
> On Wed, Jul 10, 2013 at 5:02 PM, Erik Hesselink wrote:
>
>> On Wed, Jul 10, 2013 at 10:39 AM, John Lato wrote:
>> > I think 'shouldBeCaught' is more often than not the wrong thing. A
>> > whitelist of exceptions you're prepared to handle makes
There's a pattern that arises fairly often: catching every exception thrown
by code. The naive approach is to do something like:
result <- try someCode
case result of
Left (e :: SomeException) -> putStrLn $ "It failed: " ++ show e
Right realValue -> useRealValue
This seems
On Thu, May 23, 2013 at 11:38 AM, Anton Kholomiov wrote:
> I wish it was possible to use an extension
>
> CustomPrelude = Prelude.Prime
>
> In the cabal file
>
>
>
I'm not necessarily opposed to this idea, but I'd like to point out that it
can have a negative impact on readability of an individua
It's quite old at this point, but you may be interested in reading the
initial motivations for creating conduit when the iteratee pattern (and
enumerator library in particular) already existed:
https://github.com/snoyberg/conduit/blob/master/README.md#general-goal
I would say the only real compon
m a Computer Science student from Argentina. I am interested in
> >> working this summer in a project related to Haskell for the Google
> >> Summer of Code. I have been discussing my idea with Michael Snoyman
> >> in order to have a clearer idea. Now, I would like to kn
On Wed, Apr 10, 2013 at 2:08 PM, Alexander V Vershilov <
alexander.vershi...@gmail.com> wrote:
>
> On 10 April 2013 14:56, Michael Snoyman wrote:
>
>> It doesn't seem like you're trying to perform multiple actions
>> simultaneously. For example, you d
It doesn't seem like you're trying to perform multiple actions
simultaneously. For example, you don't need to be able to read from the
server and send data back at the same time. Instead, you'll have a single
thread of execution. Am I right?
If so, it seems like the simplest thing would be for you
am of bytes, but
> chunks, right?
>
>
> On Tue, Apr 9, 2013 at 12:12 PM, Michael Snoyman wrote:
>
>> It's a bug in your implementation of takeLine I believe. It doesn't take
>> into account that lines can span multiple chunks. When you call takeLine
>> the first
haddock succesor. I was also
> pleasantly surprised that pandoc seems to handle all of this (even with
> code syntax highlighting).
>
> On 05/04/13 02:10, Michael Snoyman wrote:
> > In case it can be useful in any way for this project, my markdown
> > package[1] is certainly
It's a bug in your implementation of takeLine I believe. It doesn't take
into account that lines can span multiple chunks. When you call takeLine
the first time, you get "L1\n". leftover puts a chunk with exactly those
contents back. When you call takeLine the second time, it gets the chunk
"L1\n",
On Thu, Apr 4, 2013 at 7:49 PM, Johan Tibell wrote:
> Hi all,
>
> Haddock's current markup language leaves something to be desired once
> you want to write more serious documentation (e.g. several paragraphs
> of introductory text at the top of the module doc). Several features
> are lacking (bol
I'm wondering if this pattern exists and has a name. We have the concept of
joining a Monad:
join :: Monad m => m (m a) -> ma
How about joining a monad transformer?
joinT :: (Monad m, MonadTrans t) => t (t m) a -> t m a
I believe implementing this in terms of MonadTransControl[1] might be
possi
use file code
>>
>> doesn't actually ever use it (epoll() doesn't work for files)
>> * does the difference persist when the file size gets bigger?
>> * your file descriptor code doesn't handle EINTR properly, although
>>
>> you said
That demonstrated the issue: I'd forgotten to pass O_TRUNC to the open
system call. Adding that back makes the numbers much more comparable.
Thanks for the input everyone, and Gregory for finding the actual problem
(as well as pointing out a few other improvements).
On Fri, Mar 8, 2013 at 12:13
urate.
On Mar 8, 2013 8:30 AM, "Michael Snoyman" wrote:
> Hi all,
>
> I'm turning to the community for some help understanding some benchmark
> results[1]. I was curious to see how the new io-streams would work with
> conduit, as it looks like a far saner low-level ap
Hi all,
I'm turning to the community for some help understanding some benchmark
results[1]. I was curious to see how the new io-streams would work with
conduit, as it looks like a far saner low-level approach than Handles. In
fact, the API is so simple that the entire wrapper is just a few lines o
On Wed, Mar 6, 2013 at 5:48 AM, Joey Adams wrote:
> On Tue, Mar 5, 2013 at 9:24 AM, Michael Snoyman wrote:
>
>> ...
>>
>> I'm not sure if I entirely understand your use case, but in general it
>> should be possible to have multiple Conduits running one after
Wow, I hadn't realized that someone had implemented resumable sinks... and
now resumable conduits too! Very interesting.
I'm not sure if I entirely understand your use case, but in general it
should be possible to have multiple Conduits running one after the other.
Here's an example of restarting
On Sun, Mar 3, 2013 at 6:07 PM, Ertugrul Söylemez wrote:
> Arie Peterson wrote:
>
> > Would anyone have a problem with a deprecation of
> > MonadCatchIO-transformers, and a failure to update it to work with a
> > base without 'block' and 'unblock'?
>
> Yes. This is a simplified variant of a mon
On Fri, Mar 1, 2013 at 4:18 AM, Joey Adams wrote:
> Can I transform a conduit so some values are passed through unchanged, but
> others go through the conduit? For example:
>
> right :: Conduit i m o -> Conduit (Either x i) m (Either x o)
>
> This is named after the Control.Arrow combinator o
implement
> something brand new.
>
>
I personally have very little opinion about how this feature is
implemented. But would this approach implement the shallow trace, or the
full stack trace?
Michael
>
>
> Simon
>
> ** **
>
> *From:* michael.snoy...@gmai
On Mon, Feb 25, 2013 at 4:42 PM, Simon Peyton-Jones
wrote:
> I’m afraid the rewrite-rule idea won’t work. RULES are applied during
> optimisation, when tons of inlining has happened and the program has been
> shaken around a lot. No reliable source location information is available
> there.
On Mon, Feb 25, 2013 at 2:15 PM, Alexander Kjeldaas <
alexander.kjeld...@gmail.com> wrote:
> On Mon, Feb 25, 2013 at 12:46 PM, Simon Hengel wrote:
>
>> On Mon, Feb 25, 2013 at 10:40:29AM +0100, Twan van Laarhoven wrote:
>> > I think there is no need to have a separate REWRITE_WITH_LOCATION
>> > r
On Mon, Feb 25, 2013 at 11:13 AM, Simon Hengel wrote:
> On Mon, Feb 25, 2013 at 09:57:04AM +0100, Joachim Breitner wrote:
> > Hi,
> >
> > Am Montag, den 25.02.2013, 08:06 +0200 schrieb Michael Snoyman:
> > > Quite a while back, Simon Hengel and I put together
Quite a while back, Simon Hengel and I put together a proposal[1] for a new
feature in GHC. The basic idea is pretty simple: provide a new pragma that
could be used like so:
error :: String -> a
errorLoc :: IO Location -> String -> a
{-# REWRITE_WITH_LOCATION error errorLoc #-}
Then all usages of
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. Wh
ng outside of your focii's
>>> children. If we have a new datatype, that represents a node's payload,
>>> then we could conceivably represent all of the axis yielding operations
>>> except for parent / ancestor. However, those operations would be
>>
On Sun, Feb 10, 2013 at 8:51 PM, grant wrote:
> Michael Snoyman snoyman.com> writes:
>
> >
>
> Hi Michael,
>
> Just one last thought. Does it make any sense that xml-conduit could be
> rewritten as a lens instead of a cursor? Or leverage the lens package
Hi Grant,
As you might expect from immutable data structures, there's no way to
update in place. The approach you'd take to XSLT: traverse the tree, check
each node, and output a new structure. I put together the following as an
example, but I could certainly imagine adding more combinators to the
to attempt to
> delay the acquisition of the initial time (st) until the first downstream
> request for data.
>
> I would appreciate any other insights regarding concerns, issues, or
> oddities that I might encounter with the above.
>
> Thanks,
> Kevin
>
>
> On Mon, 04
On Mon, Feb 4, 2013 at 3:47 PM, Simon Marechal wrote:
> On 03/02/2013 16:06, Felipe Almeida Lessa wrote:
> > I guess you could use the Flush datatype [1] depending on how your
> > data is generated.
>
> Thank you for this suggestion. I tried to do exactly this by modifying
> my bulk Redis source
> I guess you could use the Flush datatype [1] depending on how your
> data is generated.
>
> Cheers,
>
> [1]
> http://hackage.haskell.org/packages/archive/conduit/0.5.4.1/doc/html/Data-Conduit.html#t:Flush
>
> On Fri, Feb 1, 2013 at 6:28 AM, Simon Marechal wrote:
> &
On Fri, Feb 1, 2013 at 8:42 AM, Simon Marechal wrote:
> On 02/01/2013 05:21 AM, Michael Snoyman wrote:
> > Firstly, what's the use case that you want to deal with lists? If it's
> > for efficiency, you'd probably be better off using a Vector instead.
>
> That
Firstly, what's the use case that you want to deal with lists? If it's for
efficiency, you'd probably be better off using a Vector instead.
But I think the inverse of `concat` is `singleton = Data.Conduit.List.map
return`, or `awaitForever $ yield . return`, using the list instance for
Monad. Your
On Thu, Jan 31, 2013 at 11:48 AM, Simon Marechal wrote:
> Hello,
>
> I have found the Conduit abstraction to be very well suited to a
> set of
> problems I am facing. I am however wondering how to implement
> "branching" conduits, and even conduit pools.
>
> I am currently in the
On Jan 27, 2013 8:46 AM, wrote:
>
> Sat, Jan 26, 2013 at 12:21:02PM +0600, s9gf4...@gmail.com wrote
> > > According to the documentation, SQLite stores whatever you give it,
> > > paying very little heed to the declared type. If you get SQLite to
> > > *compare* two numbers, it will at that point
Very nice to see, I'm happy to stand corrected here. We'll definitely get
some support for fixed into the next major release.
On Saturday, January 26, 2013, wrote:
> > According to the documentation, SQLite stores whatever you give it,
> > paying very little heed to the declared type. If you get
I can point you to the line of code causing you trouble[1].
The problem is, as you already pointed out, that we don't have a
PersistValue constructor that fits this case correctly. I think the right
solution is to go ahead and add such a constructor for the next release.
I've opened a ticket on Gi
I've now created a Stackage mailing list:
https://groups.google.com/d/forum/stackage
I encourage anyone who's interested to join the list.
On Sat, Dec 22, 2012 at 11:50 AM, Joachim Breitner wrote:
> Dear Michael,
>
> I’m wondering if I missed something, but is there a mailing list for
> stack
You could wrap chr with a call to spoon[1]. It's not the most elegant
solution, but it works.
[1]
http://hackage.haskell.org/packages/archive/spoon/0.3/doc/html/Control-Spoon.html#v:spoon
On Thu, Jan 3, 2013 at 9:50 AM, Myles C. Maxfield
wrote:
> Hello,
> I'm working on a general text-processin
On Thu, Dec 27, 2012 at 9:42 AM, Erik de Castro Lopo
wrote:
> Pieter Laeremans wrote:
>
> > Hi,
> >
> > The http-proxy package isn't compatible any longer with the latest
> > conduit. Since it is open source, I thought, I might as well try to adapt
> > it and submit a patch.
>
> Have you looked i
Sorry for the double-post, sent the first one from the wrong email address.
Hi Joachim,
I have not yet created a mailing list, but it should certainly be done.
There is also not yet a web site for Stackage, but there should be one in
the near future. At the very least, we'll need to host reposito
On Sat, Dec 15, 2012 at 4:25 PM, Malcolm Wallace wrote:
>
> On 13 Dec 2012, at 10:41, Petr P wrote:
>
> > In particular, we can have a BSD package that depends on a LGPL package,
> and this is fine for FOSS developers. But for a commercial developer, this
> can be a serious issue that is not appar
On Thu, Dec 13, 2012 at 9:51 PM, Daniel Trstenjak <
daniel.trsten...@gmail.com> wrote:
>
> On Thu, Dec 13, 2012 at 08:40:09PM +0200, Michael Snoyman wrote:
> > If you have a commercial use for cpphs, and feel the terms of the (L)GPL
> > are too onerous, you have th
tating that nobody is
> using cpphs as a library (which may be false, but is mostly true ;).
>
> [1] http://code.haskell.org/cpphs/README
>
> On Thu, Dec 13, 2012 at 1:08 PM, Michael Snoyman
> wrote:
> > Are you referring to:
> >
> > http://code.haskell.org/cp
<
felipe.le...@gmail.com> wrote:
> While you're at it, maybe whitelisting cpphs would be nice as well =).
>
> On Thu, Dec 13, 2012 at 12:03 PM, Michael Snoyman
> wrote:
> >
> >
> >
> > On Thu, Dec 13, 2012 at 3:53 PM, Vincent Hanquez wrote:
> >
On Thu, Dec 13, 2012 at 3:53 PM, Vincent Hanquez wrote:
> On 12/13/2012 12:51 PM, Michael Snoyman wrote:
>
>> I think that's a great idea. I just implemented this on PackDeps:
>>
>> http://packdeps.haskellers.**com/licenses<http://packdeps.haskellers.com/license
I think that's a great idea. I just implemented this on PackDeps:
http://packdeps.haskellers.com/licenses
As with all features on that site, I'll be happy to deprecate it as soon as
Hackage incorporates the feature in the future.
Michael
On Thu, Dec 13, 2012 at 12:41 PM, Petr P wrote:
> De
On Thu, Dec 13, 2012 at 11:35 AM, Ramana Kumar wrote:
> On Thu, Dec 13, 2012 at 8:09 PM, Michael Snoyman wrote:
>
>> I also don't think that distributing programs is as small a market as you
>> think, and should also be something we support for commercial users of
>>
On Thu, Dec 13, 2012 at 10:14 AM, Colin Adams wrote:
> On 13 December 2012 08:09, Michael Snoyman wrote:
>
>> To take this out of the academic realm and into the real-life realm: I've
>> actually done projects for companies which have corporate policies
>> disallow
To take this out of the academic realm and into the real-life realm: I've
actually done projects for companies which have corporate policies
disallowing the usage of any copyleft licenses in their toolset. My use
case was a web application, which would not have been affected by a GPL
library usage
On Fri, Dec 7, 2012 at 12:00 PM, Roman Cheplyaka wrote:
> * Michael Snoyman [2012-12-07 11:51:40+0200]
> > > As for toYAML/toJSON, I guess most of the time they are different
> anyway —
> > > otherwise it's defeating the purpose of YAML to be more h
On Fri, Dec 7, 2012 at 10:54 AM, Roman Cheplyaka wrote:
> * Michael Snoyman [2012-12-07 09:52:07+0200]
> > Let me bring up one other package: yaml (written by me). I think it's a
> > pretty good fit for the standard YAML packaging library, since it simply
> > reuses t
On Tue, Nov 27, 2012 at 7:25 PM, Nicolas Trangez wrote:
> Michael,
>
> On Tue, 2012-11-27 at 17:14 +0200, Michael Snoyman wrote:
> > I think the stm-conduit package[1] may be helpful for this use case.
> > Each time you get a new command, you can fork a thread and give it the
I think the stm-conduit package[1] may be helpful for this use case. Each
time you get a new command, you can fork a thread and give it the TBMChan
to write to, and you can use sourceTBMChan to get a source to send to the
client.
Michael
[1] http://hackage.haskell.org/package/stm-conduit
On Tue
I don't think there's enough information in the snippet you've given to
determine what the problem is. And in general, it's a good idea to include
the actual error message from the compiler.
On Mon, Nov 12, 2012 at 5:02 AM, Alexander V Vershilov <
alexander.vershi...@gmail.com> wrote:
> Hello.
>
On Mon, Nov 5, 2012 at 9:51 PM, Michael Snoyman wrote:
>
> On Nov 5, 2012 2:42 PM, "Hiromi ISHII" wrote:
> >
> > Hi, there
> >
> > On 2012/11/01, at 21:23, Michael Snoyman wrote:
> >
> > > Due to various technical reasons regarding the na
On Nov 5, 2012 2:42 PM, "Hiromi ISHII" wrote:
>
> Hi, there
>
> On 2012/11/01, at 21:23, Michael Snoyman wrote:
>
> > Due to various technical reasons regarding the nature of conduit, you
can't currently catch exceptions within the Pipe monad. You have two
It might have been caused by an overzealous security mechanism: I was only
consuming 1000 bytes of the header, which in some BrowserID cases may not
be enough. I've bumped that limit, can you try again?
On Sun, Nov 4, 2012 at 9:35 AM, Obscaenvs wrote:
> Excerpt from source: "Welcome to KeterThe
Due to various technical reasons regarding the nature of conduit, you can't
currently catch exceptions within the Pipe monad. You have two options:
* Catch exceptions before `lift`ing.
* Catch exceptions thrown from the entire Pipe.
Since the exceptions are always originating in the underlying mo
The important issue here is that, when using =$, $=, and =$=, leftovers
will discarded. To see this more clearly, realize that the first line of
sink is equivalent to:
out1 <- C.injectLeftovers CT.lines C.>+> CL.head
So any leftovers from lines are lost once you move past that line. In order
to
On Mon, Oct 15, 2012 at 6:30 PM, Joey Hess wrote:
> Michael Snoyman wrote:
> > I think I have a misunderstanding of how forkProcess should be working.
> > Ultimately this relates to some bugs in the development version of
> keter, but
> > I've found some behavior in
Hi all,
I think I have a misunderstanding of how forkProcess should be working.
Ultimately this relates to some bugs in the development version of keter,
but I've found some behavior in a simple test program which I wouldn't have
expected either, which may or may not be related.
With the program
Hi Johan,
I reported issue 1058 on Github:
https://github.com/haskell/cabal/issues/1058
Installing from separate folder with Custom build type fails
Thanks,
Michael
On Mon, Oct 8, 2012 at 6:39 PM, Johan Tibell wrote:
> Hi,
>
> I'll make a bugfix release for cabal-install and Cabal in a few d
On Tue, Sep 25, 2012 at 6:21 PM, 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.:
>&g
On Mon, Sep 24, 2012 at 2:53 PM, George Giorgidze wrote:
> Hi Michael,
>
> Here at the University of Tübingen, I am co-supervising (together with
> Jeroen Weijers) a student project implementing the OverloadedLists
> extension for GHC. Achim Krause is the student who is working on the
> project. W
On Sun, Sep 23, 2012 at 5:51 PM, Chris Smith wrote:
> Michael Snoyman wrote:
>> That said, it would be great to come up with ways to mitigate the
>> downsides of unbounded polymorphism that you bring up. One idea I've
>> seen mentioned before is to modify these extensio
On Sun, Sep 23, 2012 at 10:51 AM, Heinrich Apfelmus
wrote:
> Michael Snoyman wrote:
>>
>> (Prettier formatting available at: https://gist.github.com/3761252)
>>
>> Many of us use the OverloadedStrings language extension on a regular
>> basis. It provides the a
(Prettier formatting available at: https://gist.github.com/3761252)
Many of us use the OverloadedStrings language extension on a regular
basis. It provides the ability to keep the ease-of-use of string
literal syntax, while getting the performance and correctness
advantages of specialized datatype
And then `transPipe` will function on the resulting Pipe without issue.
Michael
>
> Niklas
>
> On 24/08/12 06:51, Michael Snoyman wrote:
>> I agree that the behavior is a bit confusing (Dan Burton just filed an
>> issue about this[1], I'm guessing this email is related
I agree that the behavior is a bit confusing (Dan Burton just filed an
issue about this[1], I'm guessing this email is related).
I put up a wiki page[2] to hopefully explain the issue. Can you review
it and let me know if it helps? If so, I'll link to it from the
Haddocks.
Michael
[1] https://gi
Hi all,
Just passing on this job opportunity for another company. SQream is
looking for Haskellers located in Israel. They are working on high
performance solutions for large databases using Haskell. If you're
interested, please contact me off-list, and I'll pass your information
along.
Thanks,
M
On Wed, Aug 15, 2012 at 9:54 PM, Daniel Hlynskyi wrote:
> Hello Cafe.
> Consider code, that takes input from handle until special substring
> matched:
>
> > matchInf a res s | a `isPrefixOf` s = reverse res
> > matchInf a res (c:cs) = matchInf a (c:res) cs
> > hTakeWhileNotFound
On Thu, Aug 16, 2012 at 5:38 AM, Conrad Parker wrote:
> On 16 August 2012 03:38, Bryan O'Sullivan wrote:
> > Hi, folks -
> >
> > I'm sure we are all familiar with the phrase "cabal dependency hell" at
> this
> > point, as the number of projects on Hackage that are intended to hack
> around
> > t
Hi all,
I've been working with Aristid on an enhancement to resourcet[1]. Please
see the issue for more details, this email isn't about that change.
Instead, now that we're looking at a new breaking release, I was wondering
if anyone had ideas of something they thought should be changed in
resourc
On Tue, Jul 31, 2012 at 1:13 PM, Alexander Foremny
wrote:
> Hello list,
>
> I am currently thinking that a problem of mine would best be solved if
> there was a Map-like data structure in which the value returned is
> parametrized over the lookup type.
>
> I wonder is this makes sense and if such
On Thu, Jul 12, 2012 at 7:30 PM, Tristan Ravitch wrote:
> On Thu, Jul 12, 2012 at 07:20:39PM +0300, Michael Snoyman wrote:
> > On Jul 12, 2012 7:13 PM, "Tristan Ravitch" wrote:
> > >
> > > On Thu, Jul 12, 2012 at 11:07:05AM -0500, Tristan Ravitch wrote:
&g
On Jul 12, 2012 7:13 PM, "Tristan Ravitch" wrote:
>
> On Thu, Jul 12, 2012 at 11:07:05AM -0500, Tristan Ravitch wrote:
> > Are you trying this on a 32 bit system? And when you compiled that C
> > program, did you try to add
> >
> > -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE
> >
> > to the com
On Thu, Jul 12, 2012 at 7:07 PM, Tristan Ravitch wrote:
> On Thu, Jul 12, 2012 at 06:29:41PM +0300, Michael Snoyman wrote:
> > I've come up with a minimal example that demonstrates this problem. The
> > crux of the matter is the following C code:
> >
> >
On Thu, Jul 12, 2012 at 6:29 PM, Michael Snoyman wrote:
>
>
> On Wed, Jul 11, 2012 at 9:55 PM, Bardur Arantsson wrote:
>
>> On 07/11/2012 05:12 PM, Michael Snoyman wrote:
>> >
>> > Thanks for the feedback. However, looking at sqlite3.c, I see th
On Wed, Jul 11, 2012 at 9:55 PM, Bardur Arantsson wrote:
> On 07/11/2012 05:12 PM, Michael Snoyman wrote:
> >
> > Thanks for the feedback. However, looking at sqlite3.c, I see the
> > necessary #include statements:
> >
> > #include
> > #include
> >
On Wed, Jul 11, 2012 at 5:47 PM, Brandon Allbery wrote:
> On Wed, Jul 11, 2012 at 10:25 AM, Michael Snoyman
> wrote:
>>
>> test.hs:
>> /home/ubuntu/.cabal/lib/persistent-sqlite-1.0.0/ghc-7.4.1/HSpersistent-sqlite-1.0.0.o:
>> unknown symbol `stat64'
>>
1 - 100 of 643 matches
Mail list logo
