I don't suppose you guys have a freebsd port of ghc-4.06 up your
sleeves do you?
We tried using the existing 4.04 port with 4.06 sources but it
complained about -lHSlang when linking hsc.
It'll be ready shortly (but probably not in time to get on the FreeBSD 4.0
CD, sadly). I had a
Marcin 'Qrczak' Kowalczyk wrote:
[...] Now it only sometimes crashes at Ctrl-C. The following progam
does so too (about 1/10 of runs): [...]
I can't reproduce this. BTW, the foreign object interface will change
in future versions of GHC:
The function is described as unsafe because the result loses the
finalizer, right?
So it is in fact unsafe to store a list of such Addrs in malloced
memory, passing the pointer to the array to a C function, because
they can be garbage collected and finalized during storing them,
before the C
The function is described as unsafe because the result loses the
finalizer, right?
So it is in fact unsafe to store a list of such Addrs in malloced
memory, passing the pointer to the array to a C function, because
they can be garbage collected and finalized during storing them,
before
George Russell wrote:
George Russell wrote:
Exactly the same happens at the same time to Processor 2.
Now somehow you have to distinguish between Processor 1 and Processor 2,
because only one is going to get to lower the flags. But I don't think
with the existing Concurrency
Marcin 'Qrczak' Kowalczyk wrote:
The function is described as unsafe because the result loses the
finalizer, right? [...]
Not exactly. The real problem (pointed out to me by Manuel Chakravarty
some time ago) is exemplified by the following code snippet:
addr - foreignObjToAddr fo -- last
Thu, 17 Feb 2000 12:04:52 +0100, Sven Panne [EMAIL PROTECTED]
pisze:
Not exactly. The real problem (pointed out to me by Manuel Chakravarty
some time ago) is exemplified by the following code snippet:
[...]
I had exactly that thing in mind.
Thu, 17 Feb 2000 14:21:12 +0100, Sven Panne [EMAIL
George Russell writes:
Tom Pledger wrote:
For two threads to have access to the same MVar, they must have a
common ancestor, right? Could a common ancestor spawn a transaction
broker thread? That would be similar to what database management
systems do. It'd still be centralised,
[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote,
I use C2HS libraries now (but the c2hs program needs so *MUCH*
memory and time to parse Perl headers that I can't use it here;
fortunately there is no need to marsh C structures).
The last version of C-HS on the Web page has a *big* space
On Thursday, February 17, 2000 7:02 PM, Fergus Henderson
[SMTP:[EMAIL PROTECTED]] wrote:
Well, I remain unconvinced. In Mercury, we give the user control
over whether instance declarations are exported or not, and it
works quite nicely, IMHO. I think the problems that you are referring
to
Fergus Henderson wrote:
On 16-Feb-2000, Jeffrey R. Lewis [EMAIL PROTECTED] wrote:
To my mind, the biggest flaw with overlapping instances is the separate
compilation issue: to whit, if the `instance Eq (Maybe String)' was in
a different module, not imported by the module defining `f',
On 17-Feb-2000, Brian Boutel [EMAIL PROTECTED] wrote:
On Thursday, February 17, 2000 7:02 PM, Fergus Henderson
Well, I remain unconvinced. In Mercury, we give the user control
over whether instance declarations are exported or not, and it
works quite nicely, IMHO. I think the problems
On Friday, February 18, 2000 1:46 AM, Fergus Henderson
[SMTP:[EMAIL PROTECTED]] wrote:
Mercury allows private instances, but it does not allow shadowing.
For any given class and type, there can only be one instance;
that instance can be public, or private, but not both.
If you allow
13 matches
Mail list logo
