RE: Memory leak in FFI callback: GHC 6.6
Matthew Thanks for submitting the Trac bug. I don't know what the answer to your qn below is, but maybe someone else on ghc-users does. Meanwhile, I added the qn to the bug report. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | On Behalf Of SevenThunders | Sent: 03 November 2006 19:04 | To: glasgow-haskell-users@haskell.org | Subject: RE: Memory leak in FFI callback: GHC 6.6 | | | | Simon Peyton-Jones wrote: | | Dear SevenThunders (if that is how you like to addressed) | | Thanks for extracting a small program that exhibits the leak; that is | really helpful. We'll look into it. Would you like to create a Trac bug | and attach your files? | | Simon | | | | | You can call me Matthew. The bug, if that's what it is, is now ticket | number 985. By the way, why can't I get the callback to actually work in | this example? If I for example uncomment the line | -- pd - cfunc pcf | | and say print out the value of pd, I get garbage values. | | Should I have used CDouble? I think for windows HsDouble = double in C | land. | -- | View this message in context: http://www.nabble.com/Memory-leak-in-FFI-callback%3A-GHC-6.6- | tf2565446.html#a7165550 | Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. | | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: seq vs. pseq
Malcolm Wallace wrote: Simon Marlow [EMAIL PROTECTED] wrote: The difference is subtle. The semantics of seq and pseq are identical; however, GHC can see that seq is strict in both its arguments and hence could choose to evaluate them in either order, whereas pseq is only strict in its first argument as far as the strictness analyser is concerned. The point is that pseq is useful for controlling evaluation order, which is what you want for adding parallelism to a program. seq, on the other hand, is not useful for controlling evaluation order. This is a rather weird thing, and I would consider it a bug in the Haskell Report, rather than a bug in ghc. (It bites hard when you are trying to implement something like HPC.) The very name 'seq' surely suggests that you are controlling the evaluation order. Please evaluate this thing on the left first. But that is _not_ what the Haskell Report says! Ghc takes the Report literally, and so the thing on the right is just as likely to be evaluated before the thing on the left! The report is in general very careful to say absolutely *nothing* about evaluation order, leaving the implementation free to choose, either at compile time or possibly even runtime. This is an important principle, and something I feel quite strongly should be kept at the front of our minds for Haskell Prime. If it isn't already mentioned explicitly in the Haskell 98 report, I think it should be. Incedentally, this is also one reason I think lazy I/O is a wart (despite its obvious usefulness): because it necessarily requires talking about evaluation order. However, having said all that, arguably an exception should be made in this case. The main use of seq (and strictness annotations) is to control operational behaviour, rather than to change the semantics of the program - for example, it is most often used to prevent space leaks by evaluating something earlier than it would otherwise be (inverted commas because this isn't currently what seq actually does, as pointed out above). Indeed, if GHC was in the habit of causing the second argument of seq to be evaluated before the first, then a lot of people would probably be surprised. eg. imagine what happens to foldl': foldl' f a [] = a foldl' f a (x:xs) = let a' = f a x in a' `seq` foldl' f a' xs It wouldn't do what you want at all. So I'm agreeing with Malcolm, except that I believe that the evaluation-order property of seq should be a strong hint, not a requirement - otherwise we fall into the trap of mandating evaluation order. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: seq vs. pseq
Simon Marlow [EMAIL PROTECTED] wrote: The report is in general very careful to say absolutely *nothing* about evaluation order, leaving the implementation free to choose, Yes, this is a highly desirable goal. However, having said all that, arguably an exception should be made in this case. The main use of seq (and strictness annotations) is to control operational behaviour, rather than to change the semantics of the program Indeed, `seq` is widely viewed as a wart on the language _because_ it specifies the evaluation order, which is something otherwise avoided in the Report. So the doubly bizarre thing is that, actually, `seq` does not control the evaluation order (which is the only valid reason for wanting to use it in the first place), but nevertheless it undesirably changes the semantics of programs such that equational reasoning no longer holds. I think if we are going to allow ourselves the luxury of semantic breakage, it should at least be worth the cost - we should get some real and definite operational control in return. That is why I think this: the evaluation-order property of seq should be a strong hint, not a requirement - otherwise we fall into the trap of mandating evaluation order. is not strong enough. `seq` should guarantee sequential evaluation. If you want a strong (but not mandatory) hint to the compiler about strictness, than that should be a different construct at the user level. At the moment, these alternatives are named `pseq` and `seq`. One suggestion is just to reverse their sense. Another is to use bang patterns for hints. Another might be to introduce strictness hints in type signatures. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: seq vs. pseq
On Mon, Nov 06, 2006 at 01:53:52PM +, Malcolm Wallace wrote: So the doubly bizarre thing is that, actually, `seq` does not control the evaluation order (which is the only valid reason for wanting to use it in the first place), but nevertheless it undesirably changes the semantics of programs such that equational reasoning no longer holds. When I've used seq, it's to ensure that a function is strict in that argument, and therefore has been evaluated before the function is called. (If the language had unlifted types, I might have used those instead). Beyond that, I don't care exactly when it was evaluated; it might be long before, thanks to propagation of strictness information. seq has a clear denotational semantics. One can still do equational reasoning with it, though there will be side conditions about whether something is _|_ or not. The downside is that the eta rules get such side conditions, and polymorphic seq greatly weakens parametricity. Apart from that, the only thing wrong with seq is its name. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: seq vs. pseq
On Mon, November 6, 2006 9:21 am, Ross Paterson wrote: On Mon, Nov 06, 2006 at 01:53:52PM +, Malcolm Wallace wrote: So the doubly bizarre thing is that, actually, `seq` does not control the evaluation order (which is the only valid reason for wanting to use it in the first place), but nevertheless it undesirably changes the semantics of programs such that equational reasoning no longer holds. When I've used seq, it's to ensure that a function is strict in that argument, and therefore has been evaluated before the function is called. (If the language had unlifted types, I might have used those instead). Beyond that, I don't care exactly when it was evaluated; it might be long before, thanks to propagation of strictness information. seq has a clear denotational semantics. One can still do equational reasoning with it, though there will be side conditions about whether something is _|_ or not. The downside is that the eta rules get such side conditions, and polymorphic seq greatly weakens parametricity. Apart from that, the only thing wrong with seq is its name. What would be the correct way to get the effect that he expected from seq? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Seth Kurtzberg [EMAIL PROTECTED] Software Engineer Specializing in Reliability and Security ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: seq vs. pseq
On Mon, Nov 06, 2006 at 06:25:48PM +, Malcolm Wallace wrote: When I use `seq`, it is sometimes in a construction like unsafePerformIO (emit squawk!) `seq` x where I am trying to force the impure side-effect to happen, exactly and immediately before x is evaluated. Whilst this is not good style in a general sense, I argue that it is perfectly safe inside certain kinds of library (e.g. for calculating coverage information, or for emitting tracing information). But if the language itself cannot guarantee this exact placement of side-effects, then it becomes impossible to write computation-reflective tools like Hat and hpc for Haskell, in Haskell. That would surely be a sad state of affairs. Without admitting the existence of unsafePerformIO, I submit unsafePerformIO (emit squawk! return x) where really does imply sequencing. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Desugaring overloaded functions
Dear GHC Hackers,
I'm using the GHC API for a project of mine. I have a question about the way
GHC 'desugars' the following overloaded function:
incL :: (Num a) = [a] - [a]
incL [] = []
incL (x : xs) = (1 + x) : (incL xs)
After calling 'Desugar.deSugar' on this function I get the following Core
representation:
Test.incL =
\ (@ a_ag0) ($dNum_al8 :: {GHC.Num.Num a_ag0}) -
__letrec {
incL_afU :: [a_ag0] - [a_ag0]
incL_afU =
\ (ds_dlZ :: [a_ag0]) -
case ds_dlZ of wild_B1 {
[] - __letrec { } in GHC.Base.[] @ a_ag0;
: x_adm xs_adn -
__letrec { } in GHC.Base.: @ a_ag0 (+_al3 lit_al2 x_adm)
(incL_afU xs_adn)
};
$dNum_alp :: {GHC.Num.Num a_ag0}
$dNum_alp = $dNum_al8;
fromInteger_alm :: GHC.Num.Integer - a_ag0
fromInteger_alm = GHC.Num.fromInteger @ a_ag0 $dNum_alp;
lit_al2 :: a_ag0
lit_al2 = fromInteger_alm (GHC.Num.S# 1);
+_al3 :: a_ag0 - a_ag0 - a_ag0
+_al3 = GHC.Num.+ @ a_ag0 $dNum_al8;
} in incL_afU;
This is great! However, I don't understand why:
'incL_afU',
'$dNum_alp',
'fromInteger_alm',
'lit_al2' and
'+_al3' are all listed under the same letrec?
What I expect is that a dependency analysis is also applied to this letrec
resulting in something like:
Test.incL =
\ (@ a_ag0) ($dNum_al8 :: {GHC.Num.Num a_ag0}) -
let $dNum_alp :: {GHC.Num.Num a_ag0}
$dNum_alp = $dNum_al8;
in ( let +_al3 :: a_ag0 - a_ag0 - a_ag0
+_al3 = GHC.Num.+ @ a_ag0 $dNum_al8;
in ( let fromInteger_alm :: GHC.Num.Integer - a_ag0
fromInteger_alm = GHC.Num.fromInteger @ a_ag0 $dNum_alp;
in ( let lit_al2 :: a_ag0
lit_al2 = fromInteger_alm (GHC.Num.S# 1);
in ( __letrec { incL_afU :: [a_ag0] - [a_ag0]
incL_afU = \ (ds_dlZ :: [a_ag0]) -
case ds_dlZ of wild_B1
{ [] - __letrec
{ } in GHC.Base.[] @ a_ag0;
: x_adm xs_adn - __letrec
{ } in GHC.Base.: @ a_ag0 (+_al3 lit_al2 x_adm)
(incL_afU xs_adn)
};
} in incL_afU;
)
)
)
)
I would really like the output of 'Desugar.deSugar' to be like the latter.
Because than I can apply some beta-reductions to get rid of the non-recursive
lets and use that as input for the rest of my project...
So, why isn't a dependency analysis applied to the letrec? And is it possible
to manually apply a dependency analysis? If so, where can I find such a
function?
Many thanks in advance,
Bas van Dijk
P.S.
I know that applying 'SimplCore.core2core' will result in something that I
almost want:
[Test.incL :: forall a_ad8. (GHC.Num.Num a_ad8) = [a_ad8] - [a_ad8]
Test.incL =
\ (@ a_akG) ($dNum_akS :: {GHC.Num.Num a_akG}) -
let {
lit_akM :: a_akG
lit_akM =
case $dNum_akS
of tpl_Xb { GHC.Num.:DNum tpl_B2 tpl_B3 tpl_B4 tpl_B5 tpl_B6 tpl_B7
tpl_B8 tpl_B9 tpl_Ba -
tpl_Ba (GHC.Num.S# 1)
} } in
__letrec {
incL_akH [LoopBreaker Nothing] :: [a_akG] - [a_akG]
incL_akH =
\ (ds_dle :: [a_akG]) -
case ds_dle of wild_B1 {
[] - GHC.Base.[] @ a_akG;
: x_adb xs_adc -
GHC.Base.:
@ a_akG
(case $dNum_akS
of tpl_X9 { GHC.Num.:DNum tpl_B2 tpl_B3 tpl_B4 tpl_B5 tpl_B6
tpl_B7 tpl_B8 tpl_B9 tpl_Ba -
tpl_B4 lit_akM x_adb
})
(incL_akH xs_adc)
};
} in incL_akH]
However the rest of my project has trouble with the way 'fromInteger_alm'
and '+_al3' are optimzed to case-expressions. So I would rather not
use 'core2core'.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
make option suggestion
Hello, I have a proposal for ghc. I think that it should take a new option, say --make-command. This will specify a command to be run whenever a source file is read in by ghc. The command will be passed an argument, which is the name of the source file. The idea is that the command can be used to create auto-generated source files when ghc needs them. The purpose of this would be the following. Suppose I have a source file, say Source.hs, which is generated from some template, say Source.hs.in. If I edit Source.hs.in, and compile my program with 'ghc --make', then the copy of Source.hs which ghc uses will be out of date. That's because ghc doesn't know about the fact that Source.hs is generated from Source.hs.in. If I use ghc, then I'll have to remember to manually generate a new version of Source.hs every time I modify Source.hs.in. But under the present proposal, I would simply write a Makefile with the rules for generating Source.hs, and then pass --make-command=make to ghc. For instance, my Makefile might say: Source.hs: Source.hs.in $(TAC) $ $@ Then every time I run ghc, and Source.hs is out of date, an up-to-date version of Source.hs will be generated automatically - because ghc will call 'make Source.hs' before reading it in. Does this sound like a good idea? Frederik -- http://ofb.net/~frederik/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: make option suggestion
Hi
Just for completeness, I came up with a proposal that would solve all
this, but in a very non-cabal style way.
Taking an example of happy, every generated file (File.hs) would have
as its first line:
{-# ORIGIN happy sourcefile.y -options -to -happy #-}
Then you just modify all haskell generating tools to output this
(easy) and suddenly the whole problem of preprocessors goes away.
I realise its not the cabal style way of doing it - since the
information gets put in the generated files etc - but it is pretty
simple.
You can also add to the file Happy.y:
{-# GENERATE happy sourcefile.y -options -to -happy #-}
To complete the other side of the generation.
Thanks
Neil
On 11/6/06, Duncan Coutts [EMAIL PROTECTED] wrote:
I think this kind of build system feature ought to go into Cabal so it
can be used more widely and without people needing Makefiles.
I admit that we're not there yet with how easy it is to generate source
files.
Duncan
On Mon, 2006-11-06 at 21:12 +, Frederik Eaton wrote:
Hello,
I have a proposal for ghc. I think that it should take a new option,
say --make-command. This will specify a command to be run whenever a
source file is read in by ghc. The command will be passed an argument,
which is the name of the source file. The idea is that the command can
be used to create auto-generated source files when ghc needs them.
The purpose of this would be the following. Suppose I have a source
file, say Source.hs, which is generated from some template, say
Source.hs.in. If I edit Source.hs.in, and compile my program with 'ghc
--make', then the copy of Source.hs which ghc uses will be out of
date. That's because ghc doesn't know about the fact that Source.hs is
generated from Source.hs.in. If I use ghc, then I'll have to remember
to manually generate a new version of Source.hs every time I modify
Source.hs.in.
But under the present proposal, I would simply write a Makefile with
the rules for generating Source.hs, and then pass --make-command=make
to ghc. For instance, my Makefile might say:
Source.hs: Source.hs.in
$(TAC) $ $@
Then every time I run ghc, and Source.hs is out of date, an up-to-date
version of Source.hs will be generated automatically - because ghc
will call 'make Source.hs' before reading it in.
Does this sound like a good idea?
Frederik
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
hsman
Hello, I have a perl script which I call 'hsman', which indexes Haddock-generated HTML files, and allows users to search for functions and also GHC manual topics. For instance, I can run: $ hsman foldl to open the documentation on 'foldl'. There is also tab-completion in zsh. If people think this would be useful to others, then I can polish it up to be included with 'ghc' distribution. Does that sound like a good idea? Best, Frederik -- http://ofb.net/~frederik/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: make option suggestion
I would definitely like something like this.
like
{-# PREPROCESS drift-ghc #-}
to specify the file should be preprocced by drift-ghc.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hsman
On Mon, 6 Nov 2006 21:32:39 -0600 Quan Ta [EMAIL PROTECTED] wrote: how about searching code that's outside of the standard library? Hoogle doesn't seem to know about HaXml, or haskelldb for example (maybe I am missing something obvious) You want to distinguish between capabilities, and the fact that the database for hoogle may not include all the data that is available. If the issue is only the availability of the data, perhaps the best option is to add the data to hoogle. Quan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
