#645: Make tick interval configurable
---+
Reporter: simonmar|Owner:
Type: task| Status: new
Priority: normal |Milestone: 6.6
Hello Simon,
Wednesday, January 04, 2006, 11:22:50 AM, you wrote:
Simon, look at [EMAIL PROTECTED]
part of this SimonM's letter:
If anyone is interested, this turned out to be a bug in the Network.BSD
module, namely that getHostByName isn't thread safe because it is based
on the C library
#490: object code blow up by minor source code change
---+
Reporter: c_maeder | Owner: simonpj
Type: bug | Status: new
Priority: normal| Milestone:
Component:
#457: Strictness problem
-+--
Reporter: nilsanders | Owner: simonpj
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler|
#455: mkProtoBCO: stack use won't fit in 16 bits 79141
---+
Reporter: simonmar | Owner: simonmar
Type: bug | Status: assigned
Priority: normal| Milestone:
Component:
#342: GHC: panic! (compiler bug?)
---+
Reporter: nobody| Owner: nobody
Type: bug | Status: closed
Priority: normal| Milestone:
Component: Compiler |
#447: segmentation fault when profiling large case
+---
Reporter: nobody | Owner: simonmar
Type: bug| Status: new
Priority: normal | Milestone: 6.4.2
Component:
#646: ASSERT fails on newtype + forall
+---
Reporter: guest|Owner:
Type: bug | Status: new
Priority: normal |
Dimitry Golubovsky wrote:
I have encountered two issues trying to build ghc-6.4.1 from the source
tarball.
1. (fixed) GNU make v 3.79 does not work (was discussed on irc
yesterday: at least two people including myself got this issue), v 3.80
works. If not already in FAQ/wiki perhaps worth
Gaal Yahas wrote:
I have these two functions:
freezeNode node = do
ptr - newStablePtr node
new (castPtr $ castStablePtrToPtr ptr)
thawNode nodePtr = do
deRefStablePtr (castPtrToStablePtr nodePtr)
You're attempting to deref the StablePtr, and also run it as
Christian Maeder wrote:
I've a few files that produce ten times bigger .o files when compiled
with optimization (-O). This blow-up prevents linking on a mac.
How could I find out what is causing this blow up?
Compile with -ddump-simpl and investigate the Core code, both with and
without
Dimitry Golubovsky wrote:
The section 8.1.1 of the GHC User's Guide says this:
The following unboxed types may be used as basic foreign types (see
FFI Addendum, Section 3.2): Int#, Word#, Char#, etc
Does this mean that when declaring a foreign function import for a C function
int fun(int)
I
On Wed, Jan 04, 2006 at 12:36:35PM +, Simon Marlow wrote:
thawNode nodePtr = do
deRefStablePtr (castPtrToStablePtr nodePtr)
You're attempting to deref the StablePtr, and also run it as an IO
action! I bet the original value wasn't an IO action, right?
You probably want
Simon Marlow wrote:
Christian Maeder wrote:
I've a few files that produce ten times bigger .o files when compiled
with optimization (-O). This blow-up prevents linking on a mac.
I had some success by adding
{-# OPTIONS -fno-strictness #-}
to the source of the big .o file so that it's now
On Jan 4, 2006, at 2:25 AM, Dylan Thurston wrote:
On Tue, Jan 03, 2006 at 02:41:40PM -0800, Ashley Yakeley wrote:
David Roundy wrote:
On Mon, Jan 02, 2006 at 04:23:32PM -0800, Ashley Yakeley wrote:
One open question (in my mind) would be whether we'd allow
data Foo = FooInt { foo :: Int }
On Wed, Jan 04, 2006 at 11:53:59AM +0100, Ulf Norell wrote:
On Jan 4, 2006, at 2:25 AM, Dylan Thurston wrote:
On Tue, Jan 03, 2006 at 02:41:40PM -0800, Ashley Yakeley wrote:
David Roundy wrote:
On Mon, Jan 02, 2006 at 04:23:32PM -0800, Ashley Yakeley wrote:
One open question (in my mind)
On 2006-01-02, David Roundy [EMAIL PROTECTED] wrote:
My proposal is simply to remove the automatic declaration of accessor
functions. In Haskell 98,
data FooBar = Foo { foo :: Int } | FooBar = { foo :: Int, bar :: Int }
I would find this to be incredibly annoying. The fact that these
On Wed, Jan 04, 2006 at 02:17:27PM +, John Goerzen wrote:
On 2006-01-02, David Roundy [EMAIL PROTECTED] wrote:
My proposal is simply to remove the automatic declaration of accessor
functions. In Haskell 98,
data FooBar = Foo { foo :: Int } | FooBar = { foo :: Int, bar :: Int }
I
On Tue, Jan 03, 2006 at 08:25:01PM -0500, Dylan Thurston wrote:
On Mon, Jan 02, 2006 at 08:43:56AM -0500, David Roundy wrote:
data FooBar = Foo { foo :: Int } | FooBar = { foo :: Int, bar :: Int }
desugars to something like
data FooBar = Foo Int | FooBar Int Int
foo :: FooBar -
On 2006-01-04, Krasimir Angelov [EMAIL PROTECTED] wrote:
2006/1/4, John Goerzen [EMAIL PROTECTED]:
The final thing that prompted me to do this was that the PostgreSQL --
and possibly the Sqlite -- module for HSQL was segfaulting. I spent
quite a bit of time with gdb and the HSQL code, and
On 2006-01-04, David Roundy [EMAIL PROTECTED] wrote:
On Wed, Jan 04, 2006 at 02:17:27PM +, John Goerzen wrote:
Haskell 98 already requires you to code up set* functions (provided you
want them), so I'd only be doubling the amount of work you need to do. If
you can get by with the existing
On 2006-01-04, Krasimir Angelov [EMAIL PROTECTED] wrote:
I also had extremely high memory usage when dealing with large result
sets -- somewhere on the order of 700MB; the same consumes about 12MB
with HDBC. My guess from looking briefly at the code is that the entire
result set is being read
Hello,
On 1/4/06, David Roundy [EMAIL PROTECTED] wrote:
What happens to record updates?
setFoo x r = r { foo = x }
Or is the proposal to remove updates as well?
Ah, good point, I hadn't thought about that. My proposal was to keep
record updates which would indeed mean that we'd need
2006/1/4, John Goerzen [EMAIL PROTECTED]:
After looking at the code again, it's possible that it's because you're
never calling pqClear on the result set. So the results returned by
PostgreSQL linger in memory forever.
Right! This was a bug. It is fixed now. Thanks.
I did have memory issues
On 2006-01-04, John Goerzen [EMAIL PROTECTED] wrote:
It's probably the same amount of coding either way:
[hsql-esque example]
fetch sth
h1 - get sth col1
h2 - get sth col2
func h1 h2
I should add that yet another option with HDBC is:
l colname colmap = Map.lookup colname colmap = fromSql
The point isn't in the amount of coding but in the performance. It
isn't required to build intermediate data structures.
2006/1/4, John Goerzen [EMAIL PROTECTED]:
On 2006-01-04, John Goerzen [EMAIL PROTECTED] wrote:
It's probably the same amount of coding either way:
[hsql-esque example]
On Wed, Jan 04, 2006 at 09:12:42PM +0200, Krasimir Angelov wrote:
The point isn't in the amount of coding but in the performance. It
isn't required to build intermediate data structures.
Well, you've got intermediate data structures in HSQL. In particular,
each column access must traverse an
I personally feel that the inclusion of 'fail' in the Monad class is
an ugly solution to the problem of pattern matching, and gives the
incorrect impression that monads should have some builtin notion of
failure. Indeed, it's becoming common to type the result of some
function in an arbitrary
G'day Cale.
Quoting Cale Gibbard [EMAIL PROTECTED]:
I personally feel that the inclusion of 'fail' in the Monad class is
an ugly solution to the problem of pattern matching, and gives the
incorrect impression that monads should have some builtin notion of
failure.
So do I.
We ought to be
Am Mittwoch, 4. Januar 2006 21:54 schrieb Cale Gibbard:
I personally feel that the inclusion of 'fail' in the Monad class is
an ugly solution to the problem of pattern matching, and gives the
incorrect impression that monads should have some builtin notion of
failure.
I totally agree!
[...]
On 04/01/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
G'day Cale.
Quoting Cale Gibbard [EMAIL PROTECTED]:
I personally feel that the inclusion of 'fail' in the Monad class is
an ugly solution to the problem of pattern matching, and gives the
incorrect impression that monads should have
Am Mittwoch, 4. Januar 2006 22:30 schrieb [EMAIL PROTECTED]:
[...]
Though possible mchoose might be more appropriate.
These leading m's are not nice in my opinion.
Even more appropriate might be to rationalise some of these naming
conventions.
Yes, we should remove those m's and use
It seems to me that trac is mainly about the various 'fptools' projects
and hawiki is about haskell topics in general.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell mailing list
Haskell@haskell.org
what type would
f x = x { foo = hello }
have if there were multiple types with 'foo' as a field name?
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
G'day all.
I wrote:
My feeling is that do { p - xs; return e } should behave identically
(modulo the precise error message if the pattern match fails) to
map (\p - e) xs. Your proposal would make it into a map/filter
hybrid.
Which, of course, it is now. I blame lack of caffeine.
On Wed, Jan 04, 2006 at 08:55:39AM -0500, David Roundy wrote:
Ah, good point, I hadn't thought about that. My proposal was to keep
record updates which would indeed mean that we'd need to require that all
foos in a given data type have the same type. Which I don't think is a
bad thing
On Mon, Dec 26, 2005 at 06:45:09PM +0100, Niklas Sorensson wrote:
That's what I thought. But I'm still curious when it is used, and why
it isn't a suitable solution for unboxed polymorhic functions in most
cases.
I always thought A nice extension would be to allow polymorphic
functions that
(In reply to
http://www.haskell.org/pipermail/haskell/2005-December/017109.html
)
One of the key things about those nested monads is that
*often* you
don't have to write things like
return $ throwError msg
but can simply write
throwError msg
because the nest has all the features of
Cale Gibbard writes:
I personally feel that the inclusion of 'fail' in the Monad class is
an ugly solution to the problem of pattern matching, and gives the
incorrect impression that monads should have some builtin notion of
failure. Indeed, it's becoming common to type the result of some
[Moving to haskell-café]
You'd still need several versions of the code for a polymorphic function, one
for pointer values, one for 4-byte non-pointers, one for 8-byte non-pointers
etc.
That's what .net does, I believe, but via runtime code generation.
Simon
| -Original Message-
|
Dylan Thurston [EMAIL PROTECTED] writes:
http://wagerlabs.com/articles/2006/01/01/haskell-vs-erlang-reloaded
| Compare Erlang
|
| -record(pot, {
| profit = 0,
| amounts = []
|}).
[...] complain about having to explain to the customer how xyFoo is
really different from
In article
[EMAIL PROTECTED]
ft.com,
Simon Peyton-Jones [EMAIL PROTECTED] wrote:
You'd still need several versions of the code for a polymorphic function, one
for pointer values, one for 4-byte non-pointers, one for 8-byte non-pointers
etc.
Yes, but that's up to the user. A type variable
| You'd still need several versions of the code for a polymorphic
function, one
| for pointer values, one for 4-byte non-pointers, one for 8-byte
non-pointers
| etc.
|
| Yes, but that's up to the user. A type variable always has a
particular
| kind, so for instance one might want an array over
On 30 December 2005 01:23, Jan-Willem Maessen wrote:
Probably. The minimum table chunk size was rather large. I have
been experimenting (tests are running even as I type) with alternate
implementations of Data.HashTable. So far the winning implementation
is one based on multiplicative
On 03 January 2006 12:03, Chris Kuklewicz wrote:
STM* is usually slower than IO/MVar. STM has to do the transactional
record keeping and throws away work (i.e. CPU cycles and speed) when
it aborts. The Chameneos benchmark has 4 writers working *very*
quickly, so the contention is high.
Sure. Type classes, as Ketil Malde has suggested.
On Jan 4, 2006, at 2:09 AM, Dylan Thurston wrote:
Looking at this code, I wonder if there are better ways to express
what you really want using static typing. To wit, with records, you
give an example
data Pot = Pot
{
pProfit ::
On 03 January 2006 17:32, Chris Kuklewicz wrote:
Thanks for the answer, but I should I written a longer comment. I have
added such a longer comment below:
Simon Marlow wrote:
Chris Kuklewicz wrote:
Another comment: between 1000's of threads and writing a custom
continuation based
Yes, that _is_ obvious but then puts the burden on the programmer to
define the getters. It also misses the setters issue entirely.
Each field can definitely be made into a class and records can be
composed dynamically, HList-style. I think HList is _the_ facility
for doing this.
How do
| Given that actually controlling priorities is not an option, adding
| blocking like that makes sense. One can make a ring buffer instead of
a
Concerning priorities and scheduling (which affect both this shootout
thread, and perhaps Joel's timeleak program), one can take two
approaches
1. Ask
And for sanity's sake, I wish one of the entries would have documentated
a clear way to understand the permutation generator. The PHP and Lua
versions are almost legible.
Here's a neat Haskell version:
-- rotate initial n elements of the list left by one place
rotate n (x:xs) = rot' n xs
Summarizing:
I collected all of the code snippets posted to this thread into the wiki
under http://haskell.org/hawiki/ShootoutEntry including old haskell code
already on the shootout.
The Fannkuch benchmark drew a lot of interest, but a new entry that
creates the correct permutation order (for
Could you post your code to this mailing list or to the wiki at
http://haskell.org/hawiki/FannkuchEntry ?
Bertram Felgenhauer wrote:
And for sanity's sake, I wish one of the entries would have documentated
a clear way to understand the permutation generator. The PHP and Lua
versions are almost
Chris Kuklewicz wrote:
Could you post your code to this mailing list or to the wiki at
http://haskell.org/hawiki/FannkuchEntry ?
I added it to the wiki. (I added it at the top - if anyone feels
put down by this, I apologize. Feel free to move it.)
Enjoy,
Bertram
I have a clarification below:
Simon Peyton-Jones wrote:
| Given that actually controlling priorities is not an option, adding
| blocking like that makes sense. One can make a ring buffer instead of
a
Concerning priorities and scheduling (which affect both this shootout
thread, and perhaps
2006/1/3, Chris Kuklewicz [EMAIL PROTECTED]:
And finially, the haskel entry for
http://shootout.alioth.debian.org/benchmark.php?test=fannkuchlang=all
is currently the *slowest* entry out of 28 languages. It is 813x
slower than the c-code, 500x slower than OCaml. Should be easy to make
it
Krasimir Angelov wrote:
2006/1/3, Chris Kuklewicz [EMAIL PROTECTED]:
And finially, the haskel entry for
http://shootout.alioth.debian.org/benchmark.php?test=fannkuchlang=all
is currently the *slowest* entry out of 28 languages. It is 813x
slower than the c-code, 500x slower than OCaml.
On 1/4/06, Josh Goldfoot [EMAIL PROTECTED] wrote:
Keep in mind that the shootout requires that the first 30 permutations
printed out by the Fannkuch benchmark to be exactly those given in the
example.
Well I'm one step closer to just not caring about the shootout anymore.
The spec says
Hello all,
I'm trying to figure out how 'data' and 'type'. I haven't read any
documentation because I can't find any. Could someone point me to a
document explaining these? I'm happy to RTFM, I just need to know where
the FM is :)
Cheers,
Daniel.
--
/\/`) http://oooauthors.org
Sebastian Sylvan wrote:
On 1/4/06, Josh Goldfoot [EMAIL PROTECTED] wrote:
Keep in mind that the shootout requires that the first 30 permutations
printed out by the Fannkuch benchmark to be exactly those given in the
example.
Well I'm one step closer to just not caring about the shootout
Daniel Carrera [EMAIL PROTECTED] writes:
I'm trying to figure out how 'data' and 'type'.
How data and type...what? :-)
Generally, 'type' introduces type synonyms, i.e. just gives a new name
to an existing type, while 'data' defines new (algebraic) types.
So you can use
type Name = String
Daniel Carrera wrote:
Hello all,
I'm trying to figure out how 'data' and 'type'. I haven't read any
documentation because I can't find any. Could someone point me to a
document explaining these? I'm happy to RTFM, I just need to know where
the FM is :)
Hello Simon,
Tuesday, January 03, 2006, 7:43:21 PM, you wrote:
The minimum time between context switches is 20 milliseconds.
Is there any good reason why 0.02 seconds is the best that you can get
here? Couldn't GHC's internal timer tick at a _much_ faster rate (like
50-100µs or so)?
SM
Hello Josh,
Wednesday, January 04, 2006, 6:00:16 AM, you wrote:
JG I was able to significantly speed up the code by replacing the flip
function with a function that relies entirely on pattern matching (no splitAts
or reverses). It looks ugly, though:
JG mangle list@(1:xs) = list
JG mangle
Ketil Malde wrote:
I'm trying to figure out how 'data' and 'type'.
How data and type...what? :-)
oops... work :)
Generally, 'type' introduces type synonyms, i.e. just gives a new name
to an existing type, while 'data' defines new (algebraic) types.
So you can use
type Name = String
Christian Maeder wrote:
http://www.isi.edu/~hdaume/htut/tutorial.pdf
4.5 Data Types 47
8 Advanced Types 103
8.1 Type Synonyms
Thanks!
Daniel.
--
/\/`) http://oooauthors.org
/\/_/ http://opendocumentfellowship.org
/\/_/
\/_/I am not over-weight, I am under-tall.
/
On 1/4/06, Chris Kuklewicz [EMAIL PROTECTED] wrote:
Sebastian Sylvan wrote:
On 1/4/06, Josh Goldfoot [EMAIL PROTECTED] wrote:
Keep in mind that the shootout requires that the first 30 permutations
printed out by the Fannkuch benchmark to be exactly those given in the
example.
Well
On 1/4/06, Chris Kuklewicz [EMAIL PROTECTED] wrote:
Sebastian Sylvan wrote:
On 1/4/06, Josh Goldfoot [EMAIL PROTECTED] wrote:
Keep in mind that the shootout requires that the first 30 permutations
printed out by the Fannkuch benchmark to be exactly those given in the
example.
Well
On Jan 4, 2006, at 5:30 AM, Simon Marlow wrote:
On 30 December 2005 01:23, Jan-Willem Maessen wrote:
Probably. The minimum table chunk size was rather large. I have
been experimenting (tests are running even as I type) with alternate
implementations of Data.HashTable. So far the winning
On Jan 4, 2006, at 8:11 AM, Chris Kuklewicz wrote:
Krasimir Angelov wrote:
...
In this particular case the flop function is very slow.
...
It can be optimized using a new mangle function:
mangle :: Int - [a] - [a]
mangle m xs = xs'
where
(rs,xs') = splitAt m xs rs
splitAt :: Int -
Several people on this list have said that the shootout favors imperative code.
Is this really the case? Why is it Clean seems to have no trouble (for the
incomplete set of benchmarks that are written in it)?
http://shootout.alioth.debian.org/clean.php
How difficult would it be to translate
Joel Reymont wrote:
I don't think CPU usage is the issue. An individual thread will take a
fraction of a second to deserialize a large packet.
It's a combination of CPU usage by the pickler and GC load.
Those 50k packets take 0.03 seconds to unpickle (version of unstuff.hs
to measure that
Hello Joel,
Wednesday, January 04, 2006, 12:42:24 AM, you wrote:
JR contribute to my delays and timeouts. There are also quite a few
JR unanswered questions at the moment (why is 'sequ' slow?
are you tried to inline it? and all other pickling combinators
the problem is what when you write
put
Bulat Ziganshin wrote:
Tuesday, January 03, 2006, 7:43:21 PM, you wrote:
The minimum time between context switches is 20 milliseconds.
Is there any good reason why 0.02 seconds is the best that you can get
here? Couldn't GHC's internal timer tick at a _much_ faster rate (like
50-100µs or
This is my latest version. Based on Don's tweaks.
{-# INLINE sequ #-}
sequ :: (b - a) - PU a - (a - PU b) - PU b
sequ a b c | a `seq` b `seq` c `seq` False = undefined
sequ f pa k = PU fn1 fn2 fn3
where
{-# INLINE fn1 #-}
fn1 ptr b =
case f b of
a - case k
Bulat Ziganshin wrote:
Tuesday, January 03, 2006, 7:43:21 PM, you wrote:
The minimum time between context switches is 20 milliseconds.
Is there any good reason why 0.02 seconds is the best that you can get
here? Couldn't GHC's internal timer tick at a _much_ faster rate (like
50-100µs or
--- Sebastian Sylvan [EMAIL PROTECTED]
wrote:
Some of the problems seem to be heavily geared
towards an imperative *implementation*, meaning that
a Haskell
version is hardly idiomatic Haskell (and as such I ,
and I
suspect otehrs, really have no inclination to work
on it).
I agree that
On 1/4/06, Brent Fulgham [EMAIL PROTECTED] wrote:
But I think Haskell may face real-world cases where
data must
be produced in some known order. For Haskell to be a
contender
in real world use, it sometimes has to confront ugly
requirements.
I must respectfully note that you contradict
I've had some questions about my intentions for HDBC. The Current Plan
is:
Release 1.0.0 next week. Before that happens, I want to have a stable
and useful API. I have one feature request to implement yet (examinine
properties of arbitrary tables in the database). I also want to finish
the
--- Sebastian Sylvan [EMAIL PROTECTED]
wrote:
My point here was that even though you _can_
generate this data in Haskell, there's no point in
requiring
(because the order doesn't matter for the benchmark
itself).
We do need to agree on which 30 permutations should be
used
in the validation
--- Sebastian Sylvan [EMAIL PROTECTED]
wrote:
Some of the problems seem to be heavily geared towards an
imperative *implementation*, meaning that a Haskell version
is hardly idiomatic Haskell (and as such I , and I suspect
otehrs, really have no inclination to work on it).
This may be
Hello Joel,
use enclosed unstuff.hs
ghc -O2 --make unstuff.hs -o unstuff -lz
./unstuff trace.dat +RTS -s -A10m
analysis:
1) are you really don't use -O2 switch? :)
2) your origianl program spend 2/3 of it's time in GC. so i used
-A10m to reduce GC times
3) i also placed lock around `unstuff`
Bulat,
On Jan 4, 2006, at 7:57 PM, Bulat Ziganshin wrote:
3) i also placed lock around `unstuff` call to decrease GC times
This sort of invalidates the test. We have already proven that it
works much better when you do this but it just pushes the delays
upstream.
I will profile your
Hi all,
How would you compare Haskell and Clean? It looks like they are both
pure functional languages with very similar syntax. It also appears that
Clean is faster than Haskell, it appears to be fairly fast. I'm curious
to learn about relative advantages and disadvantages of each.
Thanks
Hello Joel,
Wednesday, January 04, 2006, 11:31:48 PM, you wrote:
3) i also placed lock around `unstuff` call to decrease GC times
JR This sort of invalidates the test. We have already proven that it
JR works much better when you do this but it just pushes the delays
JR upstream.
as i say,
On Wed, Jan 04, 2006 at 09:48:05AM -, Simon Peyton-Jones wrote:
Ah, now I see what you mean. I had not thought of doing that, but it'd
make sense, esp if there were lots of 4-byte-non-pointer types. But
there are only a couple (Int# and Word32#) so I'm not sure it's worth
the effort.
On Wed, 2006-01-04 at 19:25 +, John Goerzen wrote:
I hope that HDBC can be a community effort. Towards that end, I hope to
be able to get some trac pages going on somebody's server and perhaps a
mailing list where ideas and implementations for future enhancements can
be discussed.
86 matches
Mail list logo
