#289: class context restrictions in GADT types not assumed
+---
Reporter: ashley-y |Owner: simonpj
Type: bug | Status: assigned
Priority: normal
#770: Huge array leads to various crashes
-+--
Reporter: dons| Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Hello GHC,
Friday, May 12, 2006, 2:48:41 PM, you wrote:
Component: Runtime System |Version: 6.5
20:32 dons:: array (minBound,maxBound) (zip [0..] (repeat ())) ::
Array Int ()
i'm pretty sure that it's a bug in array library, because it first
constructs array of 2^31*4 = 0
for the following program:
module Bug wheref :: Maybe Bool
f = g ()
g () = do f error bug?
If I ask ghci (version: 6.4.1) what the type of g is, it says:
*Bug :t g
g :: () - Maybe Bool
As of 6.5.20050610 this still occurs on both the intel mac and intel
linux (Gcc 4.0.1 gcc 4.0.2 respectively). Setting -fno-inline for
gcc has no effect.
-reilly hayes
On May 9, 2006, at 1:20 AM, Simon Marlow wrote:
Often I find these are the result of gcc inlining something, or
Thanks, I'm looking into it.
-- Don
rfh:
As of 6.5.20050610 this still occurs on both the intel mac and intel
linux (Gcc 4.0.1 gcc 4.0.2 respectively). Setting -fno-inline for
gcc has no effect.
-reilly hayes
On May 9, 2006, at 1:20 AM, Simon Marlow wrote:
Often I find these
On 12 May 2006 00:47, John Meacham wrote:
On Thu, May 11, 2006 at 02:57:30PM +0100, Simon Marlow wrote:
On the other hand, keeping intermediate Doubles to 80-bit precision
is both (a) non-portable and (b) unpredictable (the programmer
doesn't know which intermediates are going to be stored in
simonmar:
On 12 May 2006 00:47, John Meacham wrote:
On Thu, May 11, 2006 at 02:57:30PM +0100, Simon Marlow wrote:
On the other hand, keeping intermediate Doubles to 80-bit precision
is both (a) non-portable and (b) unpredictable (the programmer
doesn't know which intermediates are going
Donald Bruce Stewart wrote:
simonmar:
On 12 May 2006 00:47, John Meacham wrote:
On Thu, May 11, 2006 at 02:57:30PM +0100, Simon Marlow wrote:
On the other hand, keeping intermediate Doubles to 80-bit precision
is both (a) non-portable and (b) unpredictable (the programmer
doesn't know
I'm pretty sure this is to do with calls to strlen() from Data.ByteString.
Can you check for sure that gcc is being passed -fno-builtin? (use ghc -v).
Failing that, we might have to use a private version of strlen() that
gcc doesn't try to inline.
Cheers,
Simon
Reilly Hayes wrote:
john:
On Fri, May 12, 2006 at 10:19:18AM +0100, Simon Marlow wrote:
Especially since even:
checking Haskell type for intmax_t... not supported
checking Haskell type for uintmax_t... not supported
aren't universal :)
Well, yes. Any suggestions for what to do here? Make
Hello Simon,
Wednesday, May 10, 2006, 4:12:18 PM, you wrote:
The GC is currently single-threaded, but we have an intern who started
here this week (Roshan James) who is working on a parallel
implementation of the GC.
GREAT! if you browse Intel/AMD news, you should know that they plan to
Bulat Ziganshin wrote:
moreover, afaiu, this means that ghc-compiled programs will no more
stall for several seconds doing major GC that is also very important
for any user-interactive program (especially games :) )
Unfortunately it won't completely remove the latency of a major GC,
although
Friends,
A couple of weeks ago Simon M advertised the possibility that he and I
might run a GHC Hackathon, in Portland, later this year prior to ICFP
(Sept 14-16 or thereabouts). The idea is that we'd give an extended
tutorial about GHC's glorious innards. Then we'd have some hacking time
in
Gentlemen,
ghc -v was not required, as I am building this using .hc files from
another host. Adding -fno-builtin to the CC opts did resolve the
problem. Furthermore, I believe I have confirmed that strlen is the
problem by succesfully compiling the library using -fno-builtin-
strlen
I'm continuing in my quest to produce a clean build of GHC for Mac
intel. I'm using registerised .hc files built on 386 linux.
I suspect today's problem is pretty easy to figure out for a GHC
expert, but I'm not. When I try to build utils/genapply, the link
fails because the symbols
On 5/13/06, Reilly Hayes [EMAIL PROTECTED] wrote:
Hi
I suspect today's problem is pretty easy to figure out for a GHC
expert, but I'm not. When I try to build utils/genapply, the link
fails because the symbols _GHCziList_lvl22_closure and
_GHCziList_zdwlen_info are undefined. I'll include the
Simon, how do you want to proceed with this? Just add
-fno-builtin-strlen to the .hc bootstrappping CC flags?
-- Don
rfh:
Gentlemen,
ghc -v was not required, as I am building this using .hc files from
another host. Adding -fno-builtin to the CC opts did resolve the
problem.
What is the idiomatic way to say in (ghc) Haskell:
run this computation for at most x seconds
(e. g. it returns Boolean; imagine a primality test)
so I want something :: Int - a - Maybe a
with the guarantee that the result is
Just x with x in whnf, or Nothing.
I guess one answer is that's
waldmann:
What is the idiomatic way to say in (ghc) Haskell:
run this computation for at most x seconds
(e. g. it returns Boolean; imagine a primality test)
so I want something :: Int - a - Maybe a
with the guarantee that the result is
Just x with x in whnf, or Nothing.
I guess one
Donald Bruce Stewart wrote:
forkIO + killThread threadDelay
OK that's nice and solves my problem. Thanks!
Is the delay measured on the wall clock
or on the user (per-process) clock?
--
-- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 --
http://www.imn.htwk-leipzig.de/~waldmann/
Donald Bruce Stewart wrote:
watchdogIO :: Int -- milliseconds
- IO a -- expensive computation
- IO a -- cheap computation
- IO a
I'm not satisfied by the given function completely. Suppose the wrappers
for pure computations
watchdog1 :: Int -
rahn:
Donald Bruce Stewart wrote:
watchdogIO :: Int -- milliseconds
- IO a -- expensive computation
- IO a -- cheap computation
- IO a
I'm not satisfied by the given function completely. Suppose the wrappers
for pure computations
Donald Bruce Stewart wrote:
rahn:
Donald Bruce Stewart wrote:
watchdogIO :: Int -- milliseconds
- IO a -- expensive computation
- IO a -- cheap computation
- IO a
I'm not satisfied by the given function completely. Suppose the wrappers
for pure
If you would extend the deadline to sometime after May 23, when the
accepted Haskell.org SoC applications are revealed, you could perhaps get
a lot of new projects to the list.
I would rather not do this. It is already later than in the previous
years for the May edition, and due to other
Arjen van Weelden wrote:
Personally, I'm often surprised by the laziness introduced by Maybe.
Yes. That's why I chose the return type Boolean in my original post,
and I included the remark on Just x with x in whnf.
Mirko used a list, where whnf is not enough.
PS: I am still curious: does
PS: I am still curious: does threadDelay use
the wall clock or the per-process clock (CPU time)?
And regardless of the answer - how could one obtain
the opposite behaviour? (I don't find this discussed
in the visible docs. Or am I missing something?)
I think it uses wall clock time. Proof:
Hello Mirko,
Friday, May 12, 2006, 4:42:02 PM, you wrote:
PS: I am still curious: does threadDelay use
the wall clock or the per-process clock (CPU time)?
I think it uses wall clock time. Proof:
And regardless of the answer - how could one obtain
the opposite behaviour? (I don't find this
It's just annoying that turning a partial function into a total one
looses so much strictness, since it prevents strictness propagation. Of
course, this is easily solved using a `strict' Maybe:
data Perhaps a = Just' !a | Nothing'
Are other people experiencing the same thing, or
Friends,
A couple of weeks ago Simon M advertised the possibility that he and I
might run a GHC Hackathon, in Portland, later this year prior to ICFP
(Sept 14-16 or thereabouts). The idea is that we'd give an extended
tutorial about GHC's glorious innards. Then we'd have some hacking time
in
On 12 May 2006 00:47, John Meacham wrote:
On Thu, May 11, 2006 at 02:57:30PM +0100, Simon Marlow wrote:
On the other hand, keeping intermediate Doubles to 80-bit precision
is both (a) non-portable and (b) unpredictable (the programmer
doesn't know which intermediates are going to be stored in
simonmar:
On 12 May 2006 00:47, John Meacham wrote:
On Thu, May 11, 2006 at 02:57:30PM +0100, Simon Marlow wrote:
On the other hand, keeping intermediate Doubles to 80-bit precision
is both (a) non-portable and (b) unpredictable (the programmer
doesn't know which intermediates are going
On Fri, May 12, 2006 at 10:19:18AM +0100, Simon Marlow wrote:
Especially since even:
checking Haskell type for intmax_t... not supported
checking Haskell type for uintmax_t... not supported
aren't universal :)
Well, yes. Any suggestions for what to do here? Make a best guess?
john:
On Fri, May 12, 2006 at 10:19:18AM +0100, Simon Marlow wrote:
Especially since even:
checking Haskell type for intmax_t... not supported
checking Haskell type for uintmax_t... not supported
aren't universal :)
Well, yes. Any suggestions for what to do here? Make
Hello Stephanie,
Thursday, May 11, 2006, 5:45:15 PM, you wrote:
- We're already in that state. There *is* a lot of Haskell code that
uses FDs, it's just not Haskell 98 code. Whenever ATs take over, we'll
still have to deal with this code.
are you sure about *lots* ? i seen only 3-4 ones
- We're already in that state. There *is* a lot of Haskell code that
uses FDs, it's just not Haskell 98 code. Whenever ATs take over, we'll
still have to deal with this code.
are you sure about *lots* ? i seen only 3-4 ones (monad transformers,
collections, may be arrays, my streams) and
Hello Johannes,
Friday, May 12, 2006, 4:18:29 PM, you wrote:
= Partial p i b | p i - b where ... -- (*)
(*) A funny visual aspect of FDs is the absurd syntax.
On the left of |, the whitespace is (type arg) application,
but on the right, it suddenly denotes sequencing (tupling)
i
| So it looks like we're stuck at pretty much the same proposals for the
| class system.
...
| More generally, our discussion about the class system seems to be
| stalled. How should we to come to a decision?
I summarise my view of the state of play in the message below, which I
see I did not
Hello Simon,
Friday, May 12, 2006, 8:05:25 PM, you wrote:
My suggestion is this:
* Specify MPTCs in the main language
* Specify FDs in an Appendix (with some reasonably conservative
interpretation of FDs).
* A Haskell' implementation should implement the Appendix, and
Johannes Waldmann wrote:
class ( Show p, ToDoc i, Reader b, ToDoc b, Measure p i b )
= Partial p i b | p i - b where ... -- (*)
(*) A funny visual aspect of FDs is the absurd syntax.
On the left of |, the whitespace is (type arg) application,
but on the right, it suddenly denotes
Simon Peyton-Jones wrote:
My suggestion is this:
* Specify MPTCs in the main language
* Specify FDs in an Appendix (with some reasonably conservative
interpretation of FDs).
* A Haskell' implementation should implement the Appendix, and
programmers can write programs against it.
Hi all,
Stephanie wrote:
Simon,
Why is an Appendix is better than just a footnote in the Standard that
says we aren't sure, one way or the other, whether FDs will stay in
the language for ever. Why do we need this extra structure?
I'm worried that this extra structure could be
It has two problems:
1- It is a very straightforward wrapper. It's not very
Haskell-friendly. Which might be a good thing or not, I'm not yet sure.
It could use some more type-safety.
2- It won't allow you to do work on a thread separate from your
message-loop thread, as any self-respecting
Donn Cave wrote:
On Thu, 11 May 2006, Brian Hulley wrote:
...
-- catenate all files in a specified directory
catenate outputFile dir = withDir dir $
ls = cat outputFile
So, you would apply this like
catenate result /etc/stuff ? String
Jeremy Shaw wrote:
At Thu, 11 May 2006 23:05:14 +0100,
Brian Hulley wrote:
Of course the above could no doubt be improved but surely it is
already far easier to understand and much more powerful than the
idiosyncratic text based approach used in UNIX shells (including rc).
The idea of
Brian == Brian Hulley [EMAIL PROTECTED] writes:
Brian Some other possibilities are:
Brian 1) Every command returns a pair consisting of result and return
Brian code
IMHO the distinction between command's output (to stdout and stderr)
and its return code is one of the faults in UNIX shells.
Brian Hulley wrote:
Donn Cave wrote:
(cd /etc/stuff; cat * result)
Well the problem here is that the command leaves you in /etc/stuff so
you have to remember this when you subsequently execute another command.
No it doesn't. The parentheses around the command sequence cause it to run
in
On Fri, 12 May 2006, Ben Rudiak-Gould wrote:
... For simple
commands and pipes, the bash syntax is perfect. For anything nontrivial, I
use some other language anyway. I long ago wrote a Perl script to do a far
more general form of the renaming example you gave above. As far as I know,
the
Ben Rudiak-Gould wrote:
My reaction to this thread is the same as Donn Cave's: even after reading
through the whole thread, I don't understand what a Haskell shell is
supposed to be.
I'd like one as a scripting environment, a bit like scsh, just strongly
typed and easier on the eyes.
Ben Rudiak-Gould wrote:
Brian Hulley wrote:
Well someone had to define the meaning of basename so if we make the
definition of renif similarly built-in the comparison is between
ls = mapM_ (renif txt hs)
and
for a in *.txt; do mv $a $(basename $a .txt); done
This comparison is
Albert Lai:
Thanks. I got the poit more or less; Each invocation creates a new
IORef instance. UnsafePerformIO appears to generate a unique IORef
that can be shared (sorry for my imperative vocabulary, I´m sill
contaminated by al these evil languages ;).
I tried with usafePerformIO NewTVar v
Udo Stenzel wrote:
I'd like one as a scripting environment, a bit like scsh, just strongly
typed and easier on the eyes. Haskell as interactive shell would be a
nightmare indeed, having to type 'system foo' instead of simply 'foo'
for everyday commands just won't cut it.
This seems to be your
On Fri, 12 May 2006, Brian Hulley wrote:
Udo Stenzel wrote:
I'd like one as a scripting environment, a bit like scsh, just strongly
typed and easier on the eyes. Haskell as interactive shell would be a
nightmare indeed, having to type 'system foo' instead of simply 'foo'
for everyday
Donn Cave wrote:
On Fri, 12 May 2006, Brian Hulley wrote:
Udo Stenzel wrote:
I'd like one as a scripting environment, a bit like scsh, just
strongly typed and easier on the eyes. Haskell as interactive
shell would be a nightmare indeed, having to type 'system foo'
instead of simply 'foo' for
I have only been skimming this thread so sorry if this was already
posted:
http://www.webcom.com/~haahr/es/es-usenix-winter93.html
es is a shell roughly based on rc but with higher order functions and a
functional nature in general. It is quite interesting and could serve as
inspiration.
Brian Hulley [EMAIL PROTECTED] writes:
Donn Cave wrote:
On Fri, 12 May 2006, Brian Hulley wrote:
Udo Stenzel wrote:
I'd like one as a scripting environment, a bit like scsh, just
strongly typed and easier on the eyes. Haskell as interactive
shell would be a nightmare indeed, having to type
On 5/13/06, Alberto G. Corona [EMAIL PROTECTED] wrote:
notglobal = newIORef True
main = do a - notglobal
b - notglobal
Thanks. I got the poit more or less; Each invocation creates a new
IORef instance.
Another way of looking at this, that might be more instructive, is
that
57 matches
Mail list logo
