Alastair:
>> (In the image processing example, images were megabytes and an
>> expression like (x + (y * mask)) would generate 2 intermediate
>> images (several megabytes) while doing just 2 reductions in
>> Haskell.)
Marcin:
> OCaml allows the programmer to specify an approximate amount of
> fo
12 Aug 2002 11:33:41 +0100, Alastair Reid <[EMAIL PROTECTED]> pisze:
> (In the image processing example, images were megabytes and an
> expression like (x + (y * mask)) would generate 2 intermediate images
> (several megabytes) while doing just 2 reductions in Haskell.)
OCaml allows the programm
George Russell <[EMAIL PROTECTED]> wrote,
> Manuel's new wording (except for the typo "advices" instead of "advises") expresses
>this
> perfectly, so there probably isn't much point in discussing this further.
Ooops - thanks.
Manuel
___
FFI mailing l
Alastair Reid wrote:
[snip]
> Region-based systems have the quite wonderful property that garbage is
> disposed of promptly - you don't have to wait for the next GC for the
> memory to be released. Which means that performGC becomes a nullop.
[snip]
This is not entirely true. Firstly, some regio
Alastair Reid <[EMAIL PROTECTED]> wrote,
> George Russell <[EMAIL PROTECTED]> writes:
> > Also there are probably hard-real-time GC algorithms (like Baker's
> > treadmill) or algorithms which are close to being hard-real-time
> > (like the train algorithm) where doing a "full GC" would be a major
Alastair wrote about performGC (snipped)
> It'd be nice to say that it has to be a full GC - but I've no idea
> how to specify that in a non-operational (i.e., implementation
> dependent) way.
George Russell <[EMAIL PROTECTED]> writes:
> I certainly don't think you should constrain implementatio
Alastair wrote about performGC (snipped)
> It'd be nice to say that it has to be a full GC - but I've no idea how
> to specify that in a non-operational (i.e., implementation dependent)
> way.
I certainly don't think you should constrain implementations to be able to perform
a "full GC" in any sen
> Do you want a stronger wording on what kind of garbage collection is
> to be performed or do we want to keep it deliberately unspecified
> (ie, leave it to the individual Haskell system)?
It'd be nice to say that it has to be a full GC - but I've no idea how
to specify that in a non-operationa
Malcolm Wallace <[EMAIL PROTECTED]> wrote,
> Alastair Reid <[EMAIL PROTECTED]> writes:
>
> > > So, my proposal is to:
> > > [...]
> >
> > I think only GHC implements anything like this (correct me if wrong,
> > Malcolm) and they haven't used it in the way John Meacham is
> > interested in.
>
>
Alastair Reid <[EMAIL PROTECTED]> wrote,
> I think the thing to do is add the existing performGC to the standard
> (perhaps giving it an hs_ prefix in the process) and leave development
> of an extended version of the function for when the GHC folk (or
> anyone else with a generational collector)
Alastair Reid <[EMAIL PROTECTED]> writes:
> > So, my proposal is to:
> > [...]
>
> I think only GHC implements anything like this (correct me if wrong,
> Malcolm) and they haven't used it in the way John Meacham is
> interested in.
At the moment, nhc98 provides a routine
void haskellInit (
I think the thing to do is add the existing performGC to the standard
(perhaps giving it an hs_ prefix in the process) and leave development
of an extended version of the function for when the GHC folk (or
anyone else with a generational collector) decide they want a
forcefulness argument. Come
> So, my proposal is to:
> [...]
Another possibility is to say that we don't really understand the
issues well enough to put in the standard yet and just comment out
that section.
I think only GHC implements anything like this (correct me if wrong,
Malcolm) and they haven't used it in the way J
> So, my proposal is to
>
> * permit multiple calls to hs_init() and hs_exit() (the
> number of calls must match of course),
>
> * command line arguments specified in the second and
> following invocations to hs_init() are ignored, and
>
> * both arguments to hs_init() may be NULL (to indic
> > > Hmmm, the garbage collector is a black box and has its own
> > > complicated heuristics for managing memory usage, but you are
> > > describing a mechanism that depends rather heavily on certain
> > > assumed behaviours. At the least, that gives the garbage
> collector
> > > less flexibil
Alastair Reid <[EMAIL PROTECTED]> wrote,
> > Hmmm, the garbage collector is a black box and has its own
> > complicated heuristics for managing memory usage, but you are
> > describing a mechanism that depends rather heavily on certain
> > assumed behaviours. At the least, that gives the garbage
"Simon Marlow" <[EMAIL PROTECTED]> wrote,
> > >> - Changes to hs_init
> > >>
> > >> http://www.mail-archive.com/ffi@haskell.org/msg00539.html
This proposal doesn't work with these types IMHO. The
reason is that you won't know which arguments to pass to
hs_set_hs_argv (int argc, char *argv
"Simon Marlow" <[EMAIL PROTECTED]> wrote,
> > >> - I see the question of Function prototypes as a portability
> > >> problem waiting to happen. Either Hugs and GHC are right (you
> > >> should use the user-supplied header file or NHC is right (you
> > >> should ignore the header file). They can
> > At the moment, there are two kinds of initialisation done for each
> > module:
>
> Both ELF and DLLs on Windows provide a way of specifying initializers.
>
> Or, easier yet, since the user is already using the hs_init function,
> you could use that. The way you'd do that in ELF is to define
> At the moment, there are two kinds of initialisation done for each
> module:
Both ELF and DLLs on Windows provide a way of specifying initializers.
Or, easier yet, since the user is already using the hs_init function,
you could use that. The way you'd do that in ELF is to define a
special se
> Hmmm, the garbage collector is a black box and has its own
> complicated heuristics for managing memory usage, but you are
> describing a mechanism that depends rather heavily on certain
> assumed behaviours. At the least, that gives the garbage collector
> less flexibility to change its own b
> > System.Mem.performGC does a major GC. When would a partial GC be
> > enough?
>
> I've described the image-processing example a bunch of times.
>
> We have an external resource (e.g., memory used to store images) which
> is somewhat abundant and cheap but not completely free (e.g.,
> eventua
> On 12-Aug-2002, Simon Marlow <[EMAIL PROTECTED]> wrote:
> >
> > I'd be equally happy (perhaps happier) if the header file spec was
> > removed altogether. In a sense, this would leave the
> Haskell part of a
> > foreign binding even more portable, because it doesn't have
> to specify
> > th
On 12-Aug-2002, Simon Marlow <[EMAIL PROTECTED]> wrote:
>
> I'd be equally happy (perhaps happier) if the header file spec was
> removed altogether. In a sense, this would leave the Haskell part of a
> foreign binding even more portable, because it doesn't have to specify
> the names of header f
> System.Mem.performGC does a major GC. When would a partial GC be
> enough?
I've described the image-processing example a bunch of times.
We have an external resource (e.g., memory used to store images) which
is somewhat abundant and cheap but not completely free (e.g.,
eventually you start t
> >> - I'd like to see a standard way to call the GC from C
> >>
> >> http://www.mail-archive.com/ffi@haskell.org/msg00565.html
> >>
> >> Note that Hugs and GHC have had this for ages except that we call
> >> the function 'performGC' and there's no way to control how many
> >> generations are c
>> - I'd like to see a standard way to call the GC from C
>>
>> http://www.mail-archive.com/ffi@haskell.org/msg00565.html
>>
>> Note that Hugs and GHC have had this for ages except that we call
>> the function 'performGC' and there's no way to control how many
>> generations are collected.
> I
Alastair Reid <[EMAIL PROTECTED]> wrote,
> For those not on the cvs mailing list:
>
> I've applied all the changes discussed over the last 2 moniths that
> received some support and no dissent.
>
> Changes since RC5:
> * Author list: changed Alastair Reid's institution
> * 4.1.1: Remove
28 matches
Mail list logo
