On 3-Jan-08, at 4:47 PM, Christian Maeder wrote:
Hi,
can someone explain the linking error below? (on Intel-Mac (Tiger?))
Preprocessing library HDBC-sqlite3-1.1.3.0...
Building HDBC-sqlite3-1.1.3.0...
[1 of 7] Compiling Database.HDBC.Sqlite3.Consts ( dist/build/Database/
HDBC/Sqlite3/Consts.hs
I'm trying to build the HEAD on a somewhat old PowerBook G4 running
Mac OS 10.2.1. It would seem that I don't have a new enough version of
gcc:
% gcc --version
gcc (GCC) 3.1 20020420 (prerelease)
Well, support for that version has definitely bitrotted, but it
shouldn't be impossible to fix. Ho
On 21-Dec-06, at 1:26 PM, Michael T. Richter wrote:
Global Register Variables -- I'm not sure I understand the point
here. LLVM is a... well, a virtual machine. It's not a real
target. The LLVM code is then either simulated in a VM (as per,
say, Java) or it is further compiled to a nativ
On 20-Dec-06, at 10:10 AM, Michael T. Richter wrote:
Well, I'm almost entirely ignorant of LLVM and of Haskell --
especially the internals of both. That makes me ideally suited for
this project since I'm not aware that it's impossible.
I'm afraid LLVM currently lacks some features that are
The NeHe tutorials work for me with both GHC 6.6 and HEAD on my Intel
Mac; however, I'm not using MacPorts.
Is anyone else here who uses MacPorts on an Intel Mac, to confirm or
deny the bug?
Cheers,
Wolfgang
___
Glasgow-haskell-users mailing list
G
Could someone on MacOS X try the 6.4.x branch again? I just
committed a fix that makes the threaded RTS more stable on Solaris,
and I'm hoping it clears up the problems on MacOS X too. Remember
to re-enable -threaded in ghc/compiler/Makefile if you previously
disabled it.
The problem se
X (at least I assume he's busy,
that's the last I heard, but he didn't respond to my latest ping).
Oops, sorry about that. Yes, I'm quite busy, trying to get a degree
here.
Proper Mac OS X support will resume on September 1st :-).
So the mantle of powerpc-apple-darwin maintainer is probably
On 28-Mar-06, at 4:52 AM, Simon Marlow wrote:
This seems very strange indeed - I immediately suspect something
odd with your hardware. Try swapping out RAM, if you can.
Strange that it only seems to affect Perl (Perl is running the
mangler that generates that .s file). I suppose it's poss
Even as the author of some parts of Adjustor.c and some parts of
Hugs' FFI
implementation I have to admit that it isn't clear to me at all if
tail-calls
are used everywhere. %-)
Hugs uses tail-jumps or static return code on all supported
platforms, GHC on all platforms except IA64.
And
C -> adjustor -> stub -> Haskell -> stub -> adjustor -> CIt could be the case that the adjustor tail-jumps to the stub, but this is not guaranteed to be the case for all platforms.Hmmm, I thought it was.Well, the FFI addendum is rather vague on this point; this seems to be all it says about free
On 4-Mar-06, at 3:33 PM, Geoffrey Alan Washburn wrote:
I don't have MacOS X Intel handy to verify, but I was under the
impression that Rosetta was only automagically invoked by the
operating system on application bundles. However, there is a
dearth of information regarding this point
On 4-Mar-06, at 11:07 AM, S. Alexander Jacobson wrote:
Does ghc work on the (intel) macbooks or does it need to be rebuilt?
Will code compiled for the old macs work on the macbooks or does it
need to be recompiled?
Yes and no.
GHC, and programs compiled by it, should run without recompiling
On 2-Mar-06, at 7:35 PM, Ashley Yakeley wrote:
Thanks. Now the build process gets stuck here:
I ran into this yesterday, but didn't have time to look into it;
today, ./darcs-all pull seems to have fixed it.
Cheers,
Wolfgang
___
Glasgow-haskell-u
Another shortcoming is that the native code generator in GHC isn't
capable of dealing with backward jumps to labels (because GHC hasn't
needed that so far). But if you did C-- optimisation, you'd probably
generate such jumps. It'd be great to beef up the native code gen to
handle that.
I'm alr
My GHC 6.4.1 packages for Mac OS X are finally ready.
Mac OS X 10.3.9 (Panther) and 10.4.x (Tiger)
http://www.uni-graz.at/imawww/haskell/GHC-6.4.1.pkg.zip
This is an installer package that will install a full version of GHC
with GHCi, profiling, dynamic linking, double-clickable icons a
we have tried long and hard to call Haskell functions from C++ usingthe FFI mechanism but without success. Don't forget to say which platform you're on - the solution might be slightly platform-dependent. $ ghc -fffi Foo.o Foo_stub.o main.cpp main.o(.text+0x22): In function `main': main.cpp: un
Hi,
I am trying to make an unregisterised build. As my host machine, i use
a Mac running Mac OS X 10.4. When building ghc 6.2.2 on the host
machine (also running GHC 6.2.2), i get the error attached below
when doing 'make all' in ghc/. Does anyone
have an idea how to solve this ?
thanks,
Re
=
The (Interactive) Glasgow Haskell Compiler -- version 6.4
=
A Mac OS X installer package for Mac OS 10.3 (Panther) is available at
http://www.uni-graz.at/imawww/haskel
=
The (Interactive) Glasgow Haskell Compiler -- version 6.4
=
A Mac OS X installer package for Mac OS 10.3 (Panther) is available at
http://www.uni-graz.at/imawww/haskel
=
The (Interactive) Glasgow Haskell Compiler -- version 6.4
=
A Mac OS X installer package for Mac OS 10.3 (Panther) is available at
http://www.uni-graz.at/imawww/haskel
When I double-click the icon, I get *two* Terminal windows started, one
running ghci, the other just an ordinary shell. Is this intended?
No, that's the Terminal's default behaviour of opening an empty window
when it is launched, before receiving the command to "open a new
terminal window and ex
Another Mac OS X installer:
http://opeongo.cas.mcmaster.ca/~wolfgang/GHC-6.4.20050308.pkg.zip
Features:
*) all the normal GHC 6.4 features
*) dynamic linking
*) nice icons you can double-click to open a terminal window with ghci
(one for H98 and one for -fglasgow-exts)
*) You can even drag your fav
On 4-Mar-05, at 11:57 AM, Simon Marlow wrote:
Don't hold your breath, I have some bad news. It seems that gcc is
still generating incorrect code for register variables (or maybe it's
broken again?).
So maybe this will be the first NCG-only port of GHC :-).
Death to the Mangler!
Cheers,
Wolfgang
__
On 4-Mar-05, at 11:35 AM, Malcolm Wallace wrote:
Wolfgang Thaller <[EMAIL PROTECTED]> wrote:
I've uploaded a Mac OS X installer based on the stable tree from March
2nd + the patches I committed yesterday at:
http://opeongo.cas.mcmaster.ca/~wolfgang/GHC-6.4.20050302.pkg.zip
$ gh
I've uploaded a Mac OS X installer based on the stable tree from March
2nd + the patches I committed yesterday at:
http://opeongo.cas.mcmaster.ca/~wolfgang/GHC-6.4.20050302.pkg.zip
This package is built with support for dynamic libraries (some human
intervention was required to build it).
Mac u
[...]
warning: don't know how to split object files on this architecture
[...]
Wolfgang, Ryan - that looks like a splitter problem, no?
Definitely. Looks like there is no splitter for x86-64. SplitObjs=NO is
definitely required.
(The splitter is more of a dark art than the evil mangler, I propos
I've written a binding to a C++ library where I use a simple wrapper
file to overcome the name mangling (extern "C" functions calling C++,
nothing fancy). Is there a way to make that more GHCi friendly or
should I explore other options?
What exactly is going wrong?
Try wrapping your binding in a .s
During my ongoing research on "doing whatever I feel like", I
discovered that using C++ libaries in GHCi (no problems with GHC)
wasn't as pleasant as I had hoped.
Apparently C++ sources requires to be linked with crtbegin.o and
crtend.o (and others?) and I was wondering how to solve this nicely.
An
Brian Strand wrote:
I originally tried the binary distribution but ran into library
issues. That is of course the obvious path to try, and try it I did.
Rather than going straight to installing deprecated libraries, I tried
to provide some feedback on ghc (especially since 6.4 RCs are out).
We
Hi
I got ghc-6.5 prerelease from the CVS and managed to get it up and
running, *except* for ghci, the interactive part.
It worked last time I tried.
Is there something in particular that I need to think about to make
ghci support get compiled into ghc?
When using ghc-inplace, make sure you're usi
Thanks, good to know; I'll read through 10.2 more carefully. I didn't
think I'd need to cross-compile x86-linux to x86-linux.
You don't need to - the recommended way is to download a binary
version. If you don't like using binary distributions, then use it for
bootstrapping only, i.e. use it to
/tmp/ghc21284.split__33.s:308:Fixup of 486 is not to a 4 byte address
I've fixed this bug in CVS quite recently, so getting the newest STABLE
branch from CVS should make this work.
Alternatively, you can work around it by adding SplitObjs=NO to your
mk
If I understood this right, then I can use forkIO to run a
"safe" FFI function which blocks, but in the threaded RTS
this will not block all other FFI calls.
Right.
So what happens in the non-threaded RTS? Now the blocking
yet "safe" FFI invocation _would_ block other FFI calls but
not evaluation o
So I guess I can't really use them in code that's supposed
to be portable among different platforms?
Maybe 'forkOS' combined with calling poll() through FFI
really is the best solution? I seem to recall reading
somewhere that the threaded RTS was more efficient for these
applications anyway?
Two mi
It seems they should always be flushed. certainly if a program fails
via
'fail' in IO or 'error' as these are common ways for programs to report
an error and losing output would definitly be counter intuitive and
make
it quite tricky to debug. especially when you can't flush stdout before
calling
The temporary file is
created but it is empty. It seems like the stdout/stderr handles are
flushed in GHC.TopHandler.runMainIO but only if the program terminates
without exception.
Should be fixed now; when terminating using exitWith, the handles are
now flushed.
Note that they are still not flush
The "hook" idea works with static linking: the RTS provides a default
version of the hook, that can be overriden by a user-supplied function
of the same name. This is what GHC does. However, our dynamic linker
doesn't support this kind of overriding. The system's dynamic linker
does, though: tha
Ian Lynagh wrote:
Hi all,
I was under the impression that simple code like the below, which swaps
the endianness of a block of data, ought to be near C speed:
[...]
poke p (shiftL x 24 .|. shiftL (x .&. 0xff00) 8
.|. (shiftR x 8 .&. 0xff00)
Benjamin Franksen wrote:
main = let ?b = True in use_b
--use_b :: (?g::Bool) => IO ()
use_b = print ?b
It isn't: ghc -fimplicit-params says
Unbound implicit parameter (?b :: a)
arising from use of implicit parameter `?b' at TestBug.hs:4
In the first argument of `print', namely `?b'
Now, some of the most common operations used in dynamic web pages
relate to directory listing/manipulation. I was happily thinking that
System.Directory would provide the needed functionality. Indeed it
does, but unfortunately setCurrentDirectory breaks the thread
abstraction.
What I mean is that
=
The (Interactive) Glasgow Haskell Compiler -- version 6.2.2
=
A Mac OS X double-clickable package is now available at:
http://www.uni-graz.at/imawww/haskell/GHC.6.2.2.
Now, compiling in the ghc folder starts correctly and I get errors
about missing itimer (can I safely disable that or should I add an
emulator for it?) and mmap. Will the libraries be compiled after that?
Those errors are coming from the runtime system in ghc/rts.
Both functions are used in fair
and compiled this. So I created a file named project.obj.
We normally use .o rather than .obj; I don't know if using .obj can
cause any problems with ghc.
After that I wrote ghc -fffi -c test.lhs. But when I call blah from
ghci I get the error message: "test.o unknown symbol '_test'
I think ghc
So here's what I don't understand: we make a non-blocking call to
gtk+'s
main loop
So far, so good.
(which makes a blocking call in a new OS thread).
With (the current version of) GHC's threaded RTS, there's only one OS
thread involved until you spawn a second thread (with forkIO or
forkOS).
S
Is there any chance that GHC 6.04, or any GHC version in the next few
months, will support the following on Windows:
1) use of native threads so that the world won't be stopped every time
you wait for a character;
Should already be in 6.02.1 - add the -threaded flag when linking, and
you'll get th
"Sigbjorn Finne" <[EMAIL PROTECTED]> writes:
Thanks to the hard work of Jeff Lewis, the
CVS pserver at cvs.haskell.org is now back up again,
Malcolm Wallace wrote:
Good, and well done. Unfortunately, ssh-based connections to the
writable repository have now started to fail for me. The ssh serve
The (Interactive) Glasgow Haskell Compiler -- version 6.2.1
A Mac OS X 10.3 (Panther) binary installer package is now available at:
http://www.uni-graz.at/imawww/haske
On 09.03.2004, at 15:53, Ian Lynagh wrote:
On Tue, Mar 09, 2004 at 01:04:59AM +0100, Wolfgang Thaller wrote:
So I assume this is on powerpc-linux?
Yup, sorry (and the others are all Linux too).
Ah yes, that -static flag was lurking there from the old AIX port. It's
definitely OK to remo
What platform? Does everything work if you remove the -static?
alpha, powerpc and hppa so far. I expect the same will happen for mips
and mipsel.
If, on powerpc, I run the final link command without -static
(that's the
only place it should make a difference, right?) then it links without
warnings
On 23.02.2004, at 13:32, MR K P SCHUPKE wrote:
b <- mapArray id a
The reason it is slow is because the array type is copied every time
a member is assigned.
The array in question is already a mutable array, and even for
non-mutable arrays, mapArray would use mutable arrays internally.
The proble
The (Interactive) Glasgow Haskell Compiler -- version 6.2
A binary package for Mac OS X version 10.3 (Panther) is now available at
http://www.uni-graz.at/imawww/haske
George Russell wrote:
For the development snapshot 6.3.20031201, System.Posix.forkProcess
has the type IO () -> IO System.Posix.Types.ProcessID. In 6.0.1
it has type IO () -> IO (Maybe System.Posix.Types.ProcessID). Is
this change intentional, and if so how are you supposed to test
after the for
George Russell wrote:
I was producing it by invoking "ld" directly, since I wrote the
Makefile before the --auto-ghci-lib was introduced. However now I use
--auto-ghci-lib and it seems to work, thanks.
Thank you, that seems to work. Now what should I do to prevent the
GHCi linker
complaining a
(follow-ups to the FFI list please)
Rafael Martinez Torres wrote:
HI:
Reading Haskell 98 FFI report, one question arised:
Imported and declared a foreign function , via
foreign import ccall foo:: IO(CInt)
Is it guaranteed to be executed in atomic way ? I mean , should it
block the whole STG s
Yes I know this is really Apple's fault, but according to
http://developer.apple.com/documentation/ReleaseNotes/DeveloperTools/
GCC3.html
> The GCC 3.3 preprocessor inserts a new pragma, #pragma GCC
set_debug_pwd, as part
> of the new Distributed Builds feature. (See below.) This may
su
On 29.10.2003, at 21:15, Gregory Wright wrote:
Hi Wolfgang,
I tried building 6.0.1 on Panther using 6.0.1 built on Jaguar. (The
build was run under
darwinports.) It failed with the following:
[...]
Ever see anything like this before?
Hmm... now that you mention it, probably yes. There was some
On 25.10.2003, at 00:01, Diederik van Arkel wrote:
Not necessary, the 10.3 dev tools includes the headers for 10.1 and
10.2 so you can compile for all three OS revisions from your 10.3 box.
Well, but those are only easily accessible from Apple's Xcode IDE; I
have no idea how to get the command-l
Dear GHC for Mac OS X Users,
As you probably know, Mac OS X 10.3 a.k.a. Panther is being officially
released today. I'm going to upgrade my Powerbook right away.
Panther adds some new functions in Darwin (for example, dlfcn.h and
proper wchar support). GHC will automatically make use of these n
Peter Strand wrote:
Hi,
I'd like to use a C-library which calls back into the haskell
program, potentially from different threads at the same time.
That is, the following calling sequence takes place:
(haskell) Calls C via foreign import.
(c) Creates threads, which in turn calls back into
=
The (Interactive) Glasgow Haskell Compiler -- version 6.0.1
=
A Mac OS X package id now available at:
http://www.uni-graz.at/imawww/haskell/GHC.6.0.1.dmg
Cheers,
W
Hi Wolfgang,
I had a good compile of 6.0.1 from Thursday's cvs on Mac OS X 10.2.6.
I did a stage 2 build using your 6.0 package, then installed 6.0.1 and
rebuilt everything. I ran but a few test programs (mostly some
networking
stuff I've been playing with); superficially it all works.
Good... if
I'm not sure it's worth making a threaded-rts variant distribution
right
now, given that we'd just throw it away later. But you're welcome to
try.
We might not need the variant business when the new threaded-rts is
finished, but personally, I like the thought of getting the "Threaded
RTS classi
That, along with your HSrts.o later, ties in with the files that change
file size except that /usr/lib/ghc-6.0/package.conf gains a "pthread"
in
the rts extra libraries.
Ah yes, I overlooked that, because it doesn't happen on Mac OS X :-).
It looks like I want to make a package-threaded.conf that
Hi all,
I've had a request for --enable-threaded-rts support in the Debian
packages, but I don't want to just build with it as then HOpenGL can't
be used.
My hope was that I could share most files and just have a different
binary or something for the threaded-rts
This is indeed the case. The threa
Sean Seefried <[EMAIL PROTECTED]> wrote:
Dear GHC users on the Mac,
I'm addressing this primarily to Wolfgang but also to anyone who
has built GHC HEAD successfully on Mac OS X.
I'm having difficulty doing it myself and I was just wondering if someone
could put together a small set of instruction
I think the problem with readline on Mac OS X might have been
an re-occurring one. Browsing through the list archive for
the past few months, however, I have not found much discussion
about it. So I'd still raise the question again..
Sorry for not keeping everybody on the list up to date...
I analy
Hi,
The Haskell Web Server claims that the .dmg file for the MacOS Package
is of type "text/plain"; some browsers on MacOS (IE and Netscape)
therefore try to display it as plain text instead of downloading it.
Is anyone able to fix that somehow?
Cheers,
Wolfgang
__
I've now uploaded a binary package for Mac OS X
(Apple Installer .pkg inside a .dmg)
at
http://www.uni-graz.at/imawww/haskell/GHC.6.0.dmg
Enjoy!
Cheers,
Wolfgang
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/li
Dear Wolfgang,
I maintain the Hugs port for the darwinports system (a cousin of fink
and
perhaps the successor to the *bsd ports system). I'd like to add a port
for ghc-6.0. I tried to build it but ran into some problems.
1. configure doesn't pass the CPPFLAGS and LDFLAGS environment
variables
Seth Kurtzberg wrote:
Is there, or is anyone working on, ports for Mac OSX and/or Mac OS9?
I'm currently responsible for the Mac OS X version of GHC. I'll upload
a GHC 6.0 binary for Mac OS X binary as soon as possible, but I'm short
on time and processor cycles, so it might take a few more days
Ahn Ki-yung wrote:
> C call blocks the whole process, and Concurret
> module become meaningless. Isn't there any
> library or wrapper that can avoid ccall from
> blocking entire process ?
There is an extension to the GHC runtime system in the CVS version which
addresses this problem, but that mean
It includes profiling libraries (this time, they should work), but not
the documentation (use the online docs instead).
This binary requires Mac OS X 10.2 (Jaguar). It will not work on Mac OS
X 10.1.
Regards,
Wolfgang Thaller
___
Glasgow-haskell
As far as I can tell right now, "sendfile" is not supported on Mac OS X.
There's no manual page, and it doesn't seem to be in any sytem library.
There is a prototype in sys/socket.h, but it's wrapped in an #ifdef
that's never #defined.
When I last build the HEAD here, I didn't have any problems -
I had wanted to CC this to the list, but of course I forgot:
Stephen Pitts <[EMAIL PROTECTED]> wrote:
Is there an easy way to profile stack usage without rebuilding with
ticky-ticky profiling? I have two implementations of an algorithm;
the one with straight lists seems to use constant stack, wh
Can someone add OSX("darwin") to the "mk/config.mk.in" file?
Done. I had it enabled in my build.mk file and I hadn't noticed that it
wasn't yet on by default. Sorry for wasting your time.
Cheers,
Wolfgang
___
Glasgow-haskell-users mailing list
[EMAI
GPR13 is indeed considered nonvolatile, so it looks like the JVM is
correct and the function made by createAdjustor is wrong.
Thanks, fixed.
(both in the HEAD and in the stable branch)
I'm beginning to think that the PowerPC has way too many registers (and
Intel still has too few - the good old
Should/can I use rts_eval()?
Yes.
Any pointers on what this does (start new threads, cause garbage
collection
...) would be appreciated. I can (and have) gone over the code but a
more
high level description would be helpful.
rts_eval() may cause garbage collection to happen. This means tha
I'm almost ready to send in a patch that should fix most of the current
issues with the threaded RTS.
But I'm stuck at the problem of terminating the RTS in a proper way.
According to the GHC manual, a concurrent Haskell program should
terminate when the main action terminates. This sounds r
ends, they don't work.
Instead, try to use:
installHandler sigPIPE Ignore Nothing
I hope that works, I haven't tried it.
Cheers,
Wolfgang Thaller
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/list
I've been watching the discussion about native threads, and getting
thoroughly confused.
Understandable ;-) .
But before investing effort in fiddling with it, I thought it'd be good
to see whether anyone finds it helpful.
Yes, it does seem to be a good idea.
Feel free to modify it. E.g. ad
the Test application before compiling, the Finder
will report an "unexpected error" (because the Test.app wrapper doesn't
contain a binary).
---
(C) 2003 Wolfgang Thaller
Permission is granted to use it for any purpose you like. It is
provided AS IS, there are absolutely no warran
Reto Kramer wrote:
I'm trying to deliver a self contained app that I developed with ghc
5.04.1 on Mac OS X (10.2.2). It all works well if ghc is installed on
the machine, but on a user-machine w/o ghc, the following file is
needed:
HaskellSupport.framework/Versions/A/HaskellSupport
Yes. It's
C uses the syntax (# a, b #) for unboxed tuples.
When GHC's language extensions are enabled, GHC parses '(#)' as '(#'
and ')', which doesn't make sense.
Solutions:
1) switch off the language extensions
2) use spaces around the has
Mac OS X 10.1).
Regards,
Wolfgang Thaller
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Dean Herrington wrote:
[...] Rather, I find it
nonintuitive that calling from Haskell to foreign code and back into
Haskell
should create a new Haskell thread, when these two Haskell threads
really
are just different portions of a single "thread of computation"
(deliberately vague term).
I agr
it's not
worth the effort, especially as the LGPL places some requirements on
your program that you might not be aware of. If you want to do it
anyway and you need more assistance, just yell.
Regards,
Wolfgang Thaller
___
Glasgow
I've postponed writing up a new proposal again...
But I'm going to sum up some requirements that I would like to see
fulfilled - to make it clearer to others why I'm proposing such strange
things...
*) It should be possible for Haskell code to arrange that a sequence of
calls to a given librar
So, we can say that foreign functions of the form:
foreign import bound unsafe bar :: ...
are illegal or we can allow them and provide warnings or we can allow
them and trust the programmer to know that bar is much more expensive
than they think. (I favour the first two.)
NOOO! Don't do that
I'll write up a new version of the proposal tomorrow. For now, here are
some answers and [at the end] a question about the current FFI
specification.
Simon Peyton Jones wrote:
You don't say (but you do mean)
A bound Haskell thread can be executed only by its associated
native thread
No I don
Simon Marlow wrote:
I don't see the problem with forking a new Haskell thread for each
foreign export, and associating it with the current native thread if
the
foreign export is marked "bound". It does mean we can get multiple
Haskell threads bound to the same native thread, but only one can be
Nice design, Alastair. I've stolen lots of ideas and some text for the
complete rewrite of the proposal. The concept of "associating" haskell
threads to native threads proved to be a good way of explaining my
original idea in a different way --- and then I found out that
forkNativeThread needn'
Nicolas Oury a écrit:
* I think that, if it is not too much complicated, it could be great
to put many threads in the OpenGL OS thread. The goal of concurrent
Haskell was to allow concurrency for expressivity. It would be a pity
to lose this in part of programs for technical reason. Having thi
Great, thanks. I hope you'll keep it up to date so that by the time
the
discussion converges it can serve as a specification and rationale. We
can put it in CVS too... Simon will think of where!
Until then, I'll play the role of a "human CVS server".
Ultimately it'd be
worth integrating with
I've now written up a slightly more formal proposal for native threads.
(OK, it's only a tiny bit more formal...)
I doubt I have explained everything clearly, please tell me which
points are unclear. And of course please tell me what you like/don't
like about it.
I have some rough ideas on how t
of bugs].
I'll first write up something in order to explain/accurately define the
simple solution I proposed. After that, we can still design a more
complex solution that addresses these two issues.
Cheers,
Wolfgang Thaller
___
Gl
I wrote:
> [...] Note that the fact that only one Haskell thread may execute at
a
> time remains unchanged. [...]
Sven Panne wrote:
I haven't thought very deeply about your proposal yet, but I don't
understand
the remark above: What about e.g. a multi-processor Solaris machine
(where
pthreads
Hello All,
A while ago there was a discussion on the shortcomings of the threaded
RTS (in short, it doesn't work with foreign APIs that use thread-local
state, and that breaks HOpenGL). Back then, it was decided to just keep
the threaded RTS off by default and to do something about it some time
4.3.
Unpack it, and use the usual commands for building & installing GNU
software:
./configure
make
sudo make install
If there are any problems, e-mail me (auf Deutsch).
Cheers,
Wolfgang Thaller
___
Glasgow-haskell-users mailing list
[EMAIL PROTE
Many platforms have the C++ runtime and the C++ standard library as a
static library (probably because the C++ ABI is not as stable as it
should be...). I think this applies to both Mac OS and to Windows
[mingw32], perhaps it's the same with Solaris.
If that is the case, it would explain the pro
nary, source drop, or should I rebuild?
Just check the mailing list:
> From: Wolfgang Thaller <[EMAIL PROTECTED]>
> Date: Fre Aug 30, 2002 22:43:34 Europe/Graz
> To: GHC List <[EMAIL PROTECTED]>
> Subject: GHC on Mac OS X 10.2 (Jaguar)
>
> The new Mac OS X 10.2 has ar
1 - 100 of 129 matches
Mail list logo
