I think process-conduit is what you are looking for.
On Apr 8, 2012 1:22 AM, "Clark Gaebel" wrote:
> Has anyone built an adapter between unix pipes and conduits? Something
> like:
>
> upipe2conduit :: String -> Conduit Char Char
>
> let someLines = "hello\nworld"
> nLines <- (read . runResourceT
Hi, Oleg
Thanks for your time and your brilliant code. I think this problem is
solved.
Best wishes to you
Regards
Bin
On Wed, Nov 9, 2011 at 2:05 PM, wrote:
>p2num :: Dep a b
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskel
Hi,
Thanks for your reply!
I made some changes according to your suggest. Now I get rid of
argument p. Unfortunately, GHC is not smart enough to memorize
this true polymorphic constant.
Can you give some hints on what kind of specialize pragmas I should
use?
Regards,
Bin Jin
On Tue, Nov 8, 2011
teral
with type "Integral a=>a", so a reasonable implementation should handle
these two function in constant time(in amortized time, of course).
On Nov 7, 2011 2:27 PM, "Ivan Lazar Miljenovic"
wrote:
> On 7 November 2011 16:54, Bin Jin wrote:
> > The actual time to c
The actual time to calculate p2num and montgKeys are both O(log P). What
I'm looking is a constant time lookup.
On Nov 7, 2011 1:51 PM, "Yucheng Zhang" wrote:
> On Mon, Nov 7, 2011 at 9:29 AM, Bin Jin wrote:
> > Hi
> > This method is what I'm looking for. i
think caching values with dynamic types is complicated in ghc's runtime
environment. Anyone knows the details?
On Nov 7, 2011 7:07 AM, "wren ng thornton" wrote:
> On 11/6/11 10:51 AM, Bin Jin wrote:
>
>> Yes, but I think it's not a funtion since the function did
In order to represent Z/nZ, regular way need to store two integers, and a
data constructer. With number parameterized types, newtype+Integer can be
used, it's much more efficient.
For this project, montg reduce require to calculate a key for each modulus,
but the modulus won't be changed within Num
t; wrote:
> On Sun, Nov 6, 2011 at 10:31, Bin Jin wrote:
>
>> Then how about p2num, how to memorize this function.
>>
>> Also I think it's okay to memorize this kind of function. The type system
>> ensure all calling of montgKeys have the same type, e.g., it's
upy
more memory than representing dynamic generated types.
On Nov 6, 2011 11:06 PM, "Yucheng Zhang" wrote:
> On Sun, Nov 6, 2011 at 9:35 PM, Bin Jin wrote:
> > Hi,
> > Since I actually didn't use the parameter in calculation, the return
> value
> > only depend
rote:
> On Sun, Nov 6, 2011 at 9:10 PM, Bin Jin wrote:
> > Hi, everyone
> >
> > I'm recently trying to implement the Montgomery reduction algorithm[1] in
> > Haskell, the code can be found on
> > my Github page[2]. After doing some benchmark testing I found th
Hi, everyone
I'm recently trying to implement the Montgomery reduction algorithm[1] in
Haskell, the code can be found on
my Github page[2]. After doing some benchmark testing I found that the
library works rather slow. With the
help of `trace` function from Debug.Trace, I found that GHC is not mag
sorry, it's 15 seconds. It's a typo
On Wed, May 11, 2011 at 3:20 PM, Bin Jin wrote:
> Hi, cafe
>
> I'm recently solving some algorithm puzzles from previous Google Code Jam
> rounds, and today I met some problem I can't solve now.
> It's a problem (Round
bnds edges
> >
> > graph = buildGraph bnds edges
> >
> > edges = [ (i, (y, 1 - x::Int))
> > | i <- range bnds
> > , j <- [2..50]
> > , let (x, y) = if i + j >= n then (1, i + j - n) else (0, i + j)
> > ]
&g
Hello,
Can you give some brief notes on the new introduced clock-related stuff like
Comp?
Thanks
--Bin Jin
On Wed, Mar 23, 2011 at 1:43 AM, Christiaan Baaij <
christiaan.ba...@gmail.com> wrote:
> Hello,
>
> I am pleased to announce an incremental update to CLaSH, version 0.1.3.0
14 matches
Mail list logo
