Hi! I almost forgot that I never responded to this, sorry.
On Tue, Apr 18, 2006 at 11:37:12AM +0100, Simon Marlow wrote:
> Frederik Eaton wrote:
> >I have a project which currently uses Cabal, and I would like to
> >switch to using a plain Makefile. I have two examples of projects that use
> >Mak
Hello Simon,
Friday, April 21, 2006, 12:22:00 PM, you wrote:
> There are several papers at the level you're interested in, I think:
> Lennart's "Implementing Haskell Overloading" is a good one, and you
> might find "Type classes in Haskell" (Hall/Hammond/Peyton Jones/Wadler)
> useful, also "Impl
Bulat Ziganshin wrote:
Thursday, April 20, 2006, 11:54:59 AM, you wrote:
lazyGet can only be used to read something that was written with
lazyPut. lazyPut writes the offset of the end of the serialised data at
the beginning, so that lazyGet can skip over it, and subsequent gets
start from th
Bulat Ziganshin wrote:
i'm tried to say that there is no such dynamic beast as virtual
functions in C++
I think you can use existential types to simulate virtual functions:
-- 'a' is a stream of b's
class StreamClass a b where
get :: a -> IO b
-- hide the particular 'a' to get any stream
Hello Simon,
Thursday, April 20, 2006, 11:54:59 AM, you wrote:
> Bulat Ziganshin wrote:
>> 1) lazyGet/lazyPut. it's no problem to copy your implementation but i
>> still don't understand how lazyGet should work - it share the same
>> buffer pointer as one used in `get`. so `get` and consuming st
On 20.04 12:06, Bulat Ziganshin wrote:
> my Streams library mainly consists of two parts - Streams and
> AltBinary. The streams part implements Handle-like interface
> (including such functions as vGetChar, vGetByte, vPutBuf, vSeek and so
> on) for various data sources - files, memory buffers, pipe
Hello John,
Wednesday, April 19, 2006, 3:27:49 AM, you wrote:
>> if that is due to the time of reading .hi files, my alternative Binary
>> library should help in some future
> Interesting, A big bottleneck
big bottleneck? ;)
> in jhc right now is reading the (quite
> large) binary ho and hl fi
Bulat Ziganshin wrote:
1) lazyGet/lazyPut. it's no problem to copy your implementation but i
still don't understand how lazyGet should work - it share the same
buffer pointer as one used in `get`. so `get` and consuming structure
returned by lazyGet should interfere
lazyGet can only be used to
Hello Simon,
Wednesday, April 19, 2006, 7:28:23 PM, you wrote:
> GHC might well be able to make use of such stuff too. In general,
> one would like to be able to treat a file much like a database, as
> you suggest, with binary serialisation of data structures into it.
what you mean by "database
Hello Simon,
Wednesday, April 19, 2006, 4:45:19 PM, you wrote:
> Believe me I've looked in detail at your streams library.
> Performance-wise it is great but the design needs to be reworked IMO.
> The main problem is that it doesn't have enough type structure. There
> are many combinations of s
EMAIL PROTECTED] [mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of John Meacham
| Sent: 19 April 2006 00:28
| To: glasgow-haskell-users@haskell.org
| Subject: Re: using ghc with make
|
| On Tue, Apr 18, 2006 at 10:26:18AM +0400, Bulat Ziganshin wrote:
| > > FWIW ginsu and DrIFT both use ma
Bulat Ziganshin wrote:
Streams library includes AltBinary functionality and also emulation of
two versions of NewBinary library - byte-aligned and bit-aligned one.
as long as you search for nhc-style serialization library (i.e., with
`get` and `put_` functions) my lib should be the best beast ar
Hello Simon,
Wednesday, April 19, 2006, 12:15:55 PM, you wrote:
> It's been on my todo list for a while to benchmark the various Binary
my lib anyway will be fastest :)))
> libraries, since there's a consensus that we need some kind of Binary
> functionality in Haskell'.
Streams library inclu
Bulat Ziganshin wrote:
Hello Simon,
Tuesday, April 18, 2006, 3:02:20 PM, you wrote:
if that is due to the time of reading .hi files, my alternative Binary
library should help in some future
I'd be suprised if you could improve on GHC's binary library. Using
BinMem (reading/writing direct
On Tue, Apr 18, 2006 at 10:26:18AM +0400, Bulat Ziganshin wrote:
> > FWIW ginsu and DrIFT both use make and don't use ghcs --make feature. I
> > find this can be faster once your projects grow beyond a certain size as
> > it takes ghc a while to figure out which files need to be rebuilt with
> > --
Hello Simon,
Tuesday, April 18, 2006, 3:02:20 PM, you wrote:
>> if that is due to the time of reading .hi files, my alternative Binary
>> library should help in some future
> I'd be suprised if you could improve on GHC's binary library. Using
> BinMem (reading/writing directly to memory), GHC'
Bulat Ziganshin wrote:
Hello John,
Tuesday, April 18, 2006, 3:25:35 AM, you wrote:
FWIW ginsu and DrIFT both use make and don't use ghcs --make feature. I
find this can be faster once your projects grow beyond a certain size as
it takes ghc a while to figure out which files need to be rebuilt
Frederik Eaton wrote:
I have a project which currently uses Cabal, and I would like to
switch to using a plain Makefile.
I have two examples of projects that use Makefiles, darcs and jhc, but
they both appear to hand-code the list of dependencies for
executables. The "-M" option to ghc should
Hello Neil,
Tuesday, April 18, 2006, 3:36:12 AM, you wrote:
> If you are not using any GHC specific features, then I find that using
> Hugs for compiler errors, then once Hugs is happy moving on to GHC can
> massively speed up development time.
it's also my beloved path of work. compiler-specifi
Hello John,
Tuesday, April 18, 2006, 3:25:35 AM, you wrote:
> FWIW ginsu and DrIFT both use make and don't use ghcs --make feature. I
> find this can be faster once your projects grow beyond a certain size as
> it takes ghc a while to figure out which files need to be rebuilt with
> --make
if th
Frederik Eaton wrote:
Hi all,
I have a project which currently uses Cabal, and I would like to
switch to using a plain Makefile.
I use something like the attached Makefile. I don't have any experience with big projects though, so
it could be that regenerating dependencies all the time is exp
Hi,
> The compile / fix compiler errors cycle is an important part
> of the development process for me, and so I want
> recompilation to go as quickly as possible.
If you are not using any GHC specific features, then I find that using
Hugs for compiler errors, then once Hugs is happy moving on to
On Mon, Apr 17, 2006 at 10:57:32PM +0100, Frederik Eaton wrote:
> I have two examples of projects that use Makefiles, darcs and jhc, but
> they both appear to hand-code the list of dependencies for
> executables. The "-M" option to ghc should let us do this
> automatically, but either because of a
Hi all,
I have a project which currently uses Cabal, and I would like to
switch to using a plain Makefile.
I have two examples of projects that use Makefiles, darcs and jhc, but
they both appear to hand-code the list of dependencies for
executables. The "-M" option to ghc should let us do this
a
24 matches
Mail list logo
