#736: Allowing any newtype of the IO monad to be used in FFI and extra optional
entry point
+---
Reporter: [EMAIL PROTECTED] |Owner:
Type: feature request |
On Wed, 2006-03-29 at 03:37 +0100, Duncan Coutts wrote:
Well the full build finished and appears to work. We're going to try
again with what I think is a better fix than just picking another fixed
register. Instead of fixing a register we could let gcc pick any
suitable register by use a
On Thu, 2006-03-30 at 20:23 +0100, Duncan Coutts wrote:
Things are very slowly becoming clearer...
We compiled a little module with the stage1 compiler. So we get
registerised output assembly. It is using machine registers and making
tail calls. We've looked through the assembly but we can't
#737: Pattern match failure in coreSyn/CoreUtils.lhs
+---
Reporter: ekarttun@cs.helsinki.fi |Owner:
Type: bug | Status: new
Priority: normal
Chris Brown [EMAIL PROTECTED] writes:
ld: Undefined symbols:
_TypeRep_AClass_stauic_info
I have noticed that there are spelling mistakes in these error messages.
_TypeRep_AClass_stauic_info
should be
_TypeRep_AClass_static_info
Earlier there was something with
DISCASD
instead of
John Meacham wrote:
On Thu, Mar 30, 2006 at 03:50:06AM +0100, Brian Hulley wrote:
where the intention is that the callback will take the width and
height of the window and return a RenderM action, the problem is
that because the FFI does not allow RenderM to appear in a foreign
type.
it
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Brian Hulley
| Sent: 30 March 2006 13:14
| To: John Meacham; glasgow-haskell-users@haskell.org
| Subject: Re: Possible runtime overhead of wrapping the IO monad?
|
| John
Simon Peyton-Jones wrote:
GHC does unwrap newtype result types, as in
foreign import foo :: Int - IO Boogle
newtype Boogle = B Int
which is what the manual meant. I'd never thought of newtyping the IO
monad itself. Why are you doing that, incidentally?
I'm designing a simple API for
Duncan Coutts wrote:
On Tue, 2006-03-28 at 12:34 +0100, Simon Marlow wrote:
Hi Folks,
We're finally in release-candidate mode for 6.4.2. Please grab a
snapshot and try it out:
http://www.haskell.org/ghc/dist/stable/dist/
(scroll to the bottom for the latest). The available builds are:
Hi,
I had to chuckle at this one in particular, since the implementation
of transactions in Haskell was based on experiences with prototype
software TM in Java and C#! In truth, Haskell adds a few things to
the mix that make STM dramatically better. Most important are STM
and STRef---it's
On Thu, Mar 30, 2006 at 11:39:34AM +0100, Tim Harris wrote:
BTW, I've put a copy of another recent STM-Haskell paper online at
http://research.microsoft.com/~tharris/drafts/2006-invariants-draft.pdf.
It's about defining invariants over transactionally-managed data
structures -- feedback's very
Hallo!
While I am not a Haskell newbie I am a network newbie and need your advice.
A few years ago I coded some business logic in Haskell which is used in an
application. The application mainly consists of a GUI which calls the
Haskell program. The whole application is installed at the
On Thu, Mar 30, 2006 at 10:44:36AM +0100, Simon Marlow wrote:
You're optimising for the single-threaded case, and that's fine. In
GHC, a call-in is similar to what I outlined above except that we can
optimise away the RPC and perform the call directly in the OS thread
that requested it, due
On 29 March 2006 17:34, Neil Mitchell wrote:
context-switches happen only on specific events, which every
thread will usually engage in, although it need not always do so:
1 only calls to yield
2 any calls to concurrency library api
3 any allocation
The Yhc concurrency switches every n
On Thu, Mar 30, 2006 at 10:54:01AM +0100, Simon Marlow wrote:
Not true - in GHC with SMP a thread doing no allocation can be running
concurrently with any number of other threads. It's only the
single-threaded implementation that has this bug where a thread that
doesn't allocate can starve
GHC's SMP mode is truly preemptive, operations from multiple threads can
be arbitrarily interleaved. So let's stop saying that all known
implementations are non-preemptive, please ;-)
but gladly, if that is the default!-)
so if we take that hypothetical example of foreign exporting GHC's
It is not like inserting yields needs to be done much at all since we have
progress guarentees, so we know the program is doing something and on
any blocking call that could potentially take a while, the library will
yield for you.
where do we get the progress guarantees from? do we need a
On Thu, Mar 30, 2006 at 01:16:08PM +0100, Claus Reinke wrote:
It is not like inserting yields needs to be done much at all since we have
progress guarentees, so we know the program is doing something and on
any blocking call that could potentially take a while, the library will
yield for you.
On 30 March 2006 13:05, John Meacham wrote:
but the debugging/deterministic
benefits could be useful. you could be guarenteed to reproduce a given
sequence of context switches which could make finding concurrent
heisenbugs easier.
Actually +RTS -C0 already gives deterministic concurrency in
On 30 March 2006 12:44, Claus Reinke wrote:
so if we take that hypothetical example of foreign exporting GHC's
concurrency support, can we assume that the (IO a)s implemented in
foreign code will be given their own OS thread when using that
concurrency library? all of them, or only the
Hi Andy,
This is a good question, and something we hit in GHC quite often too.
Our solution is to use a mixture of strictness annotations, deepSeq,
smart constructors, and hand-waving optimism that things will be
evaluated soon enough anyway.
Having to occasionally deepSeq the structore to force
Simon Marlow [EMAIL PROTECTED] wrote:
I thought yhc supported unboxed values, so a loop like
count 0 = 0
count n = count (n - 1)
count 10
could block the runtime (assuming it was properly unboxed by the
compiler) since it never calls back into it and is just a straight
On Wed, Mar 29, 2006 at 12:50:02PM +0100, Jon Fairbairn wrote:
[...]
but add [a] pragma[s] to the effect that evaluation should
be input driven, and that ll, ww, and cc are to be given
equal time. Something like {-# STEPPER cs; ROUND_ROBIN
ll,ww,cc #-} (please do not take this as a
Hi
What does YHC do about in-progress thunk evaluations when a context
switch happens? Does it use blackholing like GHC, or does it
portentially duplicate the work, or something else?
As far as I am aware, since it only switches on instruction
boundaries, it never has to worry about this. It
The Trac page for 'Generalised deriving for newtype' remarks that it is
'difficult to specify without saying the same representation'.
I assume that no one has tried yet, so I'll take a shot at it.
Say we have a declaration of the form:
class C a where
x :: T a -- any type that can
On Wed, Mar 29, 2006 at 05:58:24PM +0100, Jon Fairbairn wrote:
Or do what I suggested in
http://www.haskell.org//pipermail/haskell-prime/2006-March/001120.html
[EMAIL PROTECTED] and make seq a
pragma. It really doesn't matter that pragmas in C are
optional: we don't have to follow that.
I updated the ForeignBlocking wiki page with what I believe is the
current state of this proposal; see
didn't I mention that concurrent may be inappropriate and misleading,
and that I think it is bad practice to rely on the programmer annotating
the dangerous cases, instead of the safe cases?
On Thu, Mar 30, 2006 at 09:39:44PM +0100, Claus Reinke wrote:
I updated the ForeignBlocking wiki page with what I believe is the
current state of this proposal; see
didn't I mention that concurrent may be inappropriate and misleading,
and that I think it is bad practice to rely on the
For the reasons talked about in previous posts, I'd like to propose a
deepSeq
for Haskell'.
- It provides a mechanism to allow an effective, systematic
tracking down of
a class of space leaks.
- It provides a mechanism to simply stomp on a class of space leaks.
- It avoids the user
Based on discussion, I'd like to offer up this concrete proposal when it
comes to MVars, IORefs, and what we can guarentee when it comes to their
interaction with concurrency.
My wording can use some cleaning up but I want to get this out there
while it is fresh in mind and before I forget the
didn't I mention that concurrent may be inappropriate and misleading,
and that I think it is bad practice to rely on the programmer annotating
the dangerous cases, instead of the safe cases?
I think dangerous is a misleading term here. you are already using the
FFI, all bets are off. and it is
On Fri, Mar 31, 2006 at 12:52:11AM +0100, Claus Reinke wrote:
didn't I mention that concurrent may be inappropriate and misleading,
and that I think it is bad practice to rely on the programmer annotating
the dangerous cases, instead of the safe cases?
I think dangerous is a misleading
Thinking about it some. I think we will need some sort of very basic
thread priorities.
honoring these priorities will be _manditory_ for cooperative
implementations but advisory for preemptive ones that meet the fairness
guarentees. priorities are sometimes needed in cooperative systems to
On Tue, Mar 28, 2006 at 10:49:36AM +0100, Malcolm Wallace wrote:
Tomasz Zielonka [EMAIL PROTECTED] wrote:
http://www.uncurry.com/repos/FakeSTM/
Perhaps it could serve as a drop-in replacement for STM in haskell
compilers which don't implement STM directly.
Nice idea. But your
-- i think that this may be interesting for other haskellers
Hello Wolfgang,
Wednesday, March 29, 2006, 8:24:09 PM, you wrote:
so, the concurrent programming, may be, the only area at now, where
real-world, commercial programmers should prefer Haskell over all
other languages.
are you a
Hello,
please suppose the following setting: (see [1] too)
{-# OPTIONS_GHC -fglasgow-exts #-}
module C where
class C a where name :: a - String ; pre :: a - a
data Cs = forall a . (C a) = Cs a
instance C Cs where name (Cs a) = name a ; pre (Cs a) = Cs (pre a)
mkCs :: C a = a - Cs
mkCs = Cs
On Wed, Mar 29, 2006 at 12:50:02PM +0100, Jon Fairbairn wrote:
[...]
but add [a] pragma[s] to the effect that evaluation should
be input driven, and that ll, ww, and cc are to be given
equal time. Something like {-# STEPPER cs; ROUND_ROBIN
ll,ww,cc #-} (please do not take this as a
My understanding is that type classes in Haskell are meant to be
open, so that any code that uses your type class will work with any
new instances of that type class. This inherent open endedness causes
a problem if you are trying to enumerate all instances because at any
time someone can create a
Hi -
In a discussion started on the GHC mailing list
http://www.haskell.org//pipermail/glasgow-haskell-users/2006-March/009923.html I
discovered an idea for typing imperative API functions that may be of
interest to other people, and which makes use of Haskell's type system to
achieve a level
I ran into the following problem with parsec's handling of operators.
I hope someone on the list can show me a trick that resolve my
current issue. At the end of this message is the full code for the
reproducer.
The language I'm parsing has infix operators of two forms. Some are
special
On Thu, Mar 30, 2006 at 05:05:30PM +0200, Tomasz Zielonka wrote:
Actually, it may require no effort from compiler implementors.
I just managed to get the desired effect in current GHC! :-)
More specifically: in uniprocessor GHC 6.4.1.
I implemented your idea of stepper by writing the function
41 matches
Mail list logo
