Bugs item #1344553, was opened at 2005-11-01 05:40
Message generated for change (Comment added) made by simonpj
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1344553group_id=8032
Please note that this message will contain a full copy of the comment
Bugs item #1330166, was opened at 2005-10-18 14:28
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1330166group_id=8032
Please note that this message will contain a full copy of the comment
Bugs item #1330166, was opened at 2005-10-18 23:28
Message generated for change (Comment added) made by arekm
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1330166group_id=8032
Please note that this message will contain a full copy of the comment thread,
* John Meacham:
loop:
if () goto loop;
is not equivalent to a do-while loop, loop invarients cannot be hoisted out of
the above for instance (except in some cases... it is all quite tricky and we
want gcc to have as much freedom as possible).
do-while loops are converted to this form by
* Simon Marlow:
gcc started generating this rubbish around version 3.4, if I recall
correctly. I've tried disabling various optimisations, but can't seem
to convince gcc not to generate the extra jump. You don't get this from
the native code generator, BTW.
But the comparison is present in
On Tue, 2005-11-01 at 17:30 +0100, Florian Weimer wrote:
use C control constructs rather than gotos.
With GCC version 4, this will have no effect because the gimplifier
converts everything to goto-style anyway.
Felix generates C with gotos. The result is FASTER
than native C using gcc 4.0
* On Tue, 2005-11-01 at 17:30 +0100, Florian Weimer wrote:
use C control constructs rather than gotos.
With GCC version 4, this will have no effect because the gimplifier
converts everything to goto-style anyway.
Felix generates C with gotos. The result is FASTER
than native C using gcc
On Tue, 2005-11-01 at 19:03 +0100, Florian Weimer wrote:
Felix generates C with gotos. The result is FASTER
than native C using gcc 4.0 on x86_64.
Coincidence. 8-)
Possibly :)
Felix generated C(++) code -- compiled with same options:
int FLX_REGPARM _i1860_f1301_ack(
int
Rene de Visser [EMAIL PROTECTED] wrote in article [EMAIL PROTECTED] in
gmane.comp.lang.haskell.general:
To do this I need to cast my 5 dimensional array to a 1 dimensional
array? Does this work? i.e. how do I know that GHC uses a flat array
representation for multidemsional arrays (rather
Haskell Weekly News: November 1, 2005
Greetings, and thanks for reading the 13th issue of HWN, a weekly
newsletter for the Haskell community. Each Tuesday, new editions will be
posted (as text) to [1]the Haskell mailing list and (as HTML) to [2]The
Haskell
Gregory Woodhouse [EMAIL PROTECTED] wrote in article [EMAIL PROTECTED] in
gmane.comp.lang.haskell.general:
Okay, this seems sensible enough. Loosely speaking, I see this code
as getting a line, checking to see if it's empty. If it is, it just
quits (returning the empty value). Otherwise,
I was wondering... In my experience, it's worked much better to use
sum' = foldl' (+) 0
than the built-in sum function, which leaks memory like crazy for
large input lists. I'm guessing the built-in definition is
sum = foldr (+) 0
But as far as I know, (+) is always strict, so foldl' seems
I'm pleased to announce the first release of Frown (version 0.6,
andromeda release), an LALR(k) Parser Generator for Haskell 98.
This is a beta quality release.
Frown's salient features are:
o The generated parsers are time and space efficient. On the downside,
the parsers are quite large.
On 11/1/05, Scherrer, Chad [EMAIL PROTECTED] wrote:
I was wondering... In my experience, it's worked much better to use
sum' = foldl' (+) 0
than the built-in sum function, which leaks memory like crazy for
large input lists. I'm guessing the built-in definition is
sum = foldr (+) 0
But
On 01/11/05, Sebastian Sylvan [EMAIL PROTECTED] wrote:
On 11/1/05, Scherrer, Chad [EMAIL PROTECTED] wrote:
I was wondering... In my experience, it's worked much better to use
sum' = foldl' (+) 0
than the built-in sum function, which leaks memory like crazy for
large input lists. I'm
On 01/11/05, Scherrer, Chad [EMAIL PROTECTED] wrote:
I was wondering... In my experience, it's worked much better to use
sum' = foldl' (+) 0
than the built-in sum function, which leaks memory like crazy for
large input lists. I'm guessing the built-in definition is
sum = foldr (+) 0
But
Cale Gibbard wrote:
On 01/11/05, Sebastian Sylvan [EMAIL PROTECTED] wrote:
On 11/1/05, Scherrer, Chad [EMAIL PROTECTED] wrote:
I was wondering... In my experience, it's worked much better to use
sum' = foldl' (+) 0
than the built-in sum function, which leaks memory like crazy for
large
You don't always want (+) to be strict. Consider working with
the ring of formal power series over, say, the integers. You
don't want (+) to force the evaluation of an infinite formal
summation which is passed to it, since that's an infinite
loop, so it will have to be non-strict,
On 01/11/05, Lennart Augustsson [EMAIL PROTECTED] wrote:
Cale Gibbard wrote:
On 01/11/05, Sebastian Sylvan [EMAIL PROTECTED] wrote:
On 11/1/05, Scherrer, Chad [EMAIL PROTECTED] wrote:
I was wondering... In my experience, it's worked much better to use
sum' = foldl' (+) 0
than the
The solution would be to bring 'sum' and 'product' into the Num class so
the most efficient version for each type can be used and the default is
no worse than the current non-class versions. (this is even pretty much
completly backwards compatable so could be considered for haskell 06)
I'd also
On 01/11/05, John Meacham [EMAIL PROTECTED] wrote:
The solution would be to bring 'sum' and 'product' into the Num class so
the most efficient version for each type can be used and the default is
no worse than the current non-class versions. (this is even pretty much
completly backwards
The solution would be to bring 'sum' and 'product' into the Num class so
the most efficient version for each type can be used and the default is
no worse than the current non-class versions. (this is even pretty much
completly backwards compatable so could be considered for haskell 06)
I'd
I have a file in my repo (HSX11/Xauthority.hs) and I want to rename it
changing just case of one letter:
bash$ darcs mv HSX11/Xauthority.hs HSX11/XAuthority.hs
darcs failed: A file or dir named HSX11/XAuthority.hs already exists in
working directory.
bash$ ls HSX11/X[aA]*.hs
On 2005-11-01, Dimitry Golubovsky [EMAIL PROTECTED] wrote:
I have a file in my repo (HSX11/Xauthority.hs) and I want to rename it
changing just case of one letter:
bash$ darcs mv HSX11/Xauthority.hs HSX11/XAuthority.hs
It's Darcs. See the --case-ok option.
-- John
Hi there,
I would like to use evaluate arbitrary expressions in the context of a
mixed-language (Ada, Haskell and about twelve lines of C glue)
applications. Is it possible to use dynload from hs-plugins to
load a module that references symbols in the loading program?
For example, the
The symbols must be exported from the main program... I think you can
pass the linker an option to force it to export symbols.
Keean.
Fraser Wilson wrote:
Hi there,
I would like to use evaluate arbitrary expressions in the context of a
mixed-language (Ada, Haskell and about twelve lines
Joel Reymont wrote:
I'm trying to optimize this and I thought that things that return
Nothing in the Maybe monad should fail the whole computation
sequence.
No, it shouldn't. 'return Nothing' ist a perfectly valid result of type
'Maybe (Maybe a)', which is not what you want. However,
(Moving this to the cafe.)
G'day all.
Quoting Cale Gibbard [EMAIL PROTECTED]:
We already do rely on them in most cases. Of course, not every
property can be proved by the compiler, but many pieces of code are
going to assume quite a lot.
Agreed.
I think that the assumption that (+) and
28 matches
Mail list logo
