Hi Cafe,
I came from the C/C++ world, recently I play with a haskell editor named
yi-editor, I find haskell build phase is very slow:
1.Compile one .hs file is slow
2. When change a little, it will recompile many many files
Compare to c, compile a c source file seems much quick then compile
I think this is probably the right approach. However, there's something
important to point out: flushing based on timing issues must be handled
*outside* of the conduit functionality, since by design conduit will not
allow you to (for example) run `await` for up to a certain amount of time.
You'll
Dear Haskell lovers,
The Haskell Prime process for standardisation of new versions of the Haskell
language is at something of an impasse. Since the Haskell 2010 Report was
issued (at the end of 2009), there has been very little momentum to formalise
existing extensions and generalisations,
Of course that is fine. But keep in mind that all parser combinator based
libraries are based on a top-down parsing strategy which in most places,
BUT NOT ALL, fits Haskell's syntax. Try to use the chaining combinators
where-ever possible. In case of doubt you can always spy on how things are
Hi,
I'm putting together a cabal package and I'd like to have some code
examples in my description file. In particular I would like to have a code
block containing markdown containing a code block of Haskell, like this:
~~~{ .haskell }
module Main where
main = putStrLn Hello World!
~~~
I don't understand why you're putting it in your .cabal file. Isn't
something like 3.8.5 over at [1] what you're trying to achieve?
...
I had a look at a package ([2]) that I know uses a multi-line code block
example. Here's what I found in its cabal file:
An example:
.
runShpider $
Hi Josef,
You should be fine if you follow Haddock formatting. For example:
http://hackage.haskell.org/package/lens
Is from the cabal file:
http://hackage.haskell.org/packages/archive/lens/3.8.5/lens.cabal
Ryan
On Mon, Feb 4, 2013 at 7:30 AM, Josef Svenningsson
On Mon, Feb 4, 2013 at 1:26 PM, Mateusz Kowalczyk
fuuze...@fuuzetsu.co.ukwrote:
I don't understand why you're putting it in your .cabal file. Isn't
something like 3.8.5 over at [1] what you're trying to achieve?
Right, I probably should have mentioned that the reason I put it in the
.cabal
I was running into serious performance problems when printing moderately sized
Doc and Xml data (HaXml goes via Doc).
So I replace Text.PrettyPrint.HughesPJ with Text.PrettyPrint.Leijen.Text,
and patched the HaXml printer in the same way. Now it is running much faster.
This confirms some of the
Hi Ryan,
As far as I can tell I'm following the Haddock formatting just fine. I'm
using bird tracks for my code block and according to the Haddock manual
those code blocks are interpreted literally without any additional markup.
To me that suggests that I should be able to write just about
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 so that it can timeout and send empty lists [1].
Then I wrote a few
While on the subject of conduits and timing, I'm using the following
conduit to add elapsed timing information:
timedConduit :: MonadResource m = forall l o u . Pipe l o o u m (u,
NominalDiffTime)
timedConduit = bracketP getCurrentTime (\_ - return ()) inner
where inner st = do r -
On Mon, Feb 4, 2013 at 3:47 PM, Simon Marechal si...@banquise.net 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
Hmm, that's an interesting trick. I can't say that I ever thought bracketP
would be used in that way. The only change I might recommend is using
addCleanup[1] instead, which doesn't introduce the MonadResource constraint.
Michael
[1]
Hi Josef,
Sorry, I misunderstood the intent. From what I can tell this is a
Cabal deficiency. The text from the description field first passes through
the `tokeniseLine` function from here:
https://github.com/haskell/cabal/blob/cabal-1.16/Cabal/Distribution/ParseUtils.hs#L428which
seems to have
On Mon, Feb 4, 2013 at 5:10 PM, Ryan Yates fryguy...@gmail.com wrote:
Hi Josef,
Sorry, I misunderstood the intent. From what I can tell this is a
Cabal deficiency. The text from the description field first passes through
the `tokeniseLine` function from here:
I also get stack overflows from HughesPJ if I format something too big.
LW is more efficient by construction than HughesPJ. The only reason I
switched to HPJ from LW is that I could never get LW to behave as I
wanted, but I'll probably wind up writing my own simpler formatter due
to the HPJ
On 13-02-04 02:56 AM, Alfredo Di Napoli wrote:
Reverse engineering (aka Google searching) for Hacklab seems to reveal
that the location is Edimburgh: Correct? :D
There are many Hacklabs worldwide. But this one is Toronto, Canada. I
know because Christopher runs the Toronto Haskell Meetup and
Ok, so not exactly around the corner for me, but thanks for clarifying :D
Alfredo
On 4 February 2013 20:53, Albert Y. C. Lai tre...@vex.net wrote:
On 13-02-04 02:56 AM, Alfredo Di Napoli wrote:
Reverse engineering (aka Google searching) for Hacklab seems to reveal
that the location is
On Mon, Feb 4, 2013 at 3:53 PM, Albert Y. C. Lai tre...@vex.net wrote:
Toronto is an international metropolis with three globally renowned
universities, multiple major-player high-tech labs, a world-class orchestra
and several world-class choirs, and fine cuisines from almost all cultures.
yi is pretty heavy, as these things go. So it's not too surprising that
it's taking a while.
GHC does try to recompile as little as possible...but as little as
possible can be quite a lot. Inlining, and other optimizations GHC
performs, makes the recompilation checker's job tricky; see [1].
Hi
I am trying to write criterion benchmarks for the pretty library.
Unfortunately, building the benchmark executable fails at some point
during the development with the following error message:
---8---
command line: cannot satisfy -package-id pretty-1.1.1.1-inplace:
pretty-1.1.1.1-inplace
On Mon, Feb 4, 2013 at 7:45 PM, Ben Doyle
benjamin.peter.do...@gmail.com wrote:
General advice on speeding compilation is here: [2].
Its first advice should already be enough to give you something
usable. Call cabal configure with the --disable-optimization flag and
see if it helps.
Cheers, =)
I'd object to your implication that Haskell is completely ready for
use in general soft real-time systems. I was unable to implement a
multi-threaded application which does a some IO-work in background
threads in a way so that its GUI won't die. Worker threads simply
starve the GUI, because
On Tue, Feb 5, 2013 at 1:56 PM, kudah kudahkuka...@gmail.com wrote:
I'd object to your implication that Haskell is completely ready for
use in general soft real-time systems. I was unable to implement a
multi-threaded application which does a some IO-work in background
threads in a way so
kudah kudahkuka...@gmail.com wrote:
I'd object to your implication that Haskell is completely ready for
use in general soft real-time systems. I was unable to implement a
multi-threaded application which does a some IO-work in background
threads in a way so that its GUI won't die. Worker
I used gtk2hs, because I couldn't find a free software design tool that was
at least as good as glade3. Last time I tried to compile wxHaskell, wxc
produced an enormous dynamic library which also linked to every
wxWidgets library out there(e.g. wxwebkit), so that the resulting mess
couldn't be
I followed dmwit's guide on threaded gtk2hs, all GUI interaction is in the
main thread, which is always bounded. This shouldn't really impact the
lag, as soon as gtk2hs calls back to haskell, nothing stops the RTS
from delaying main thread's peaceful return to C-land for arbitrary amount
of time.
28 matches
Mail list logo
