Re: [Fwd: Re: Problem building hdbc-sqlite3 with ghc 6.8.2]
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, dist/build/Database/HDBC/Sqlite3/Consts.o ) [...] ar: creating archive dist/build/libHSHDBC-sqlite3-1.1.3.0.a ld: atom sorting error for _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziTypes_CSqlite3_closure_tbl [...] To the best of my knowledge, this is harmless and can be ignored. Linking continues after this message is printed, and I haven't yet found any adverse side-effects. The message is triggered (in Apple's recently-rewritten linker) when there are two or more labels pointing to the very end of a section in an object file. This sometimes happens when empty _closure_tbls are emitted by GHC; it's probably not too hard to prevent this from happening. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: LLVM back end
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 native representation.
(Or it is JITted, etc.) If it's run in a VM, there is no register
anythings. [...]
Reading between the lines, I take it that you want to port GHC to
LLVM in its entirety; LLVM-ghc would not support -fvia-C or -fasm
code generation but leave everything to LLVM only. If you want to
keep any of the other code generation routes, then the global
register variables used by GHC are part of the ABI and have to be
specified explitly.
It sounds like an optimiser that does just that could be written
pretty simply.
Well, it wouldn't be just another optimiser, it would require support
from the code generators, I guess...
On the other hand... if we're not trying to mix LLVM code with
traditional GHC code anyway, then who says those variables should be
global? They should probably be parameters to every function, and
then lets hope that the calling convention used for tail-calls puts
them in registers:
void %foo(sbyte* %stackPointer, sbyte* %stackLimit, sbyte* %
heapPointer, sbyte* %heapLimit) {
entry:
tail call void %bar( sbyte* %stackPointer, sbyte* %
stackLimit, sbyte* %heapPointer, sbyte* %heapLimit )
ret void
}
The ability to put data next to code -- I'm not exactly sure what
you mean by this. Do you mean some kind of inlined data like this
kind of psuedo-assembler?
move r1,mem-whatever
jmp foo
mem-data-inline db 1, 2, 3, 4, 5, 6, 7, 8
:foo
move r2,mem-data-inline
...
Well, basically, a heap object will start with a pointer to foo;
sometimes we will want to tail-call foo, and sometimes we will want
to access things at (foo-4) etc, i.e. the things at mem-data-inline.
We want both things to be blindingly fast, i.e. we don't want to
dereference another pointer.
Unless we want to link the LLVM-compiled code with -fasm and -fvia-C-
compiled code, all we need is *any* mechanism to quickly access a
block of data and a block of code from the same pointer.
On 21-Dec-06, at 9:14 AM, Simon Peyton-Jones wrote:
How about
* concurrency (the ability to have zillions of little stacks,
with stack overflow checks and growing the stck on overflow)?
* exception handling (the ability to crawl over the stack
looking for exception catch frames)?
* garbage collection (the ability to find pointers in the stack)
The alternative to using LLVM's support for all those things is to
keep using GHC's run-time system and a stack we manage ourselves.
Then we don't need to care about LLVM's support for those yet
(although it might still be a good idea later, to give the optimiser
more opportunities to help us).
Cheers,
Wolfgang
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: LLVM back end
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 required for efficient GHC code generation, specifically: a) Global Register Variables b) The ability to put data next to code c) (maybe, I'm not sure) Tailcalls ad a) We need to keep some things in global registers for speed reasons (depending on the number of available registers); among other things, the haskell stack pointer and the heap pointer. Using regular global variables instead would be a lot slower. ad b) With (almost) every chunk of code, we want to associate a smal chunk of data (the info table) which contains information used by the garbage collector and other parts of the run time system. We want to use only one pointer to point to both of those things, and we don't want to waste time with any additional indirections, so we make the pointer point between the data chunk and the code chunk. ad c) While they are supported in theory, I couldn't get LLVM to generate any tailcalls. Maybe I've done something wrong, maybe they're not really implemented yet. So I guess step one would be to start negotiating about those things with the LLVM people. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: OpengGL lockup using GHC 6.6 on Intel Mac
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 Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.4.3 and threaded RTS problems
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 seems to be solved now, great work! Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: MacOS X / PowerPC
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 up for grabs. 6.4.3 is held up because of this (but not just because of this). Can anyone help out? GHC/Mac OS X users, I know you are out there, and I know that many of you are capable of building GHC and running gdb on it! Please step forward now! Similar things to be said for the Mac OS X/Intel port, which is basically there, but which I will not finish before I both a) finish my degree and b) get an actual Intel based Mac of my own. So another job opening there. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.5 on Mac Os X
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 possible there could be something strange with your Perl - maybe try replacing that? If you run GHC with -keep-tmp-files, you can capture the erroneous .s file for later inspection; that might give us more clues. We went through that off-list on the weekend. Perl really seems to be misbehave in a strange, non-deterministic way on Christopher's machine. I, too, suspect a strange hardware problem, but the fact is that I am clueless. Did you know that the Catholic Church still has trained exorcists? Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to access hs_free_fun_ptr from a Visual Studio DLL
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 even if this is currently the case: Can we really guarantee this for all eternity for every strange ABI people will come up with? I'm not so sure about this, therefore I'd recommend against self-destruction, as handy as it admittedly is. I'd be happy to be convinced of the opposite... You'd be happy? OK, I'll try. I think it will be possible for all ABIs. Tearing down the stack frame or whatever needs to be done on the way out can always be done by a piece of static code; even if some dynamic information (like, for example, the size of the stack frame) is needed, this information can be stored in the stack frame or in a register by the function that sets up the stack frame. Or if you want to look at it differently: 1.) We can generate a thunk that will tail-call to a static piece of code and pass an additional constant argument to that static piece of code, with a custom calling convention. 2.) We can dynamically generate a call to the stub function. If those two axioms are fulfilled for a platform, we can support self- destruction. 2 will definitely be supported (otherwise NO interpreters with FFI would work on that platform), and I can't imagine how a platform can NOT support 1 Grüße, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to access hs_free_fun_ptr from a Visual Studio DLL
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 freeHaskellFunPtr.freeHaskellFunPtr :: FunPtr a - IO () Release the storage associated with the given \code{FunPtr}, which must have been obtained from a wrapper stub. This should be called whenever the return value from a foreign import wrapper function is no longer required; otherwise, the storage it uses will leak.Do I need the FunPtr value in order to return to C land? I didn't think so. The addendum doesn't say so. (It doesn't clearly say otherwise, though).All of the implementations in Adjustor.c *except* for the IA-64 one go to some lengths to ensure that a tail-calll is used:C - adjustor - stub - Haskell - stub - (maybe some static code) - CI think this confusion should be fixed...Cheers,Wolfgang___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc on on macbook pro (fwd)
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 under Apple's Rosetta emulator, but that will be slower than on (powerpc) PowerBooks. A port to Mac OS X on Intel is in progress and mostly finished. GHC 6.6 will support building native Intel code for the new Macs; if there is sufficient demand, I could also backport this support to the GHC 6.4.x line once it's finished. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc on on macbook pro (fwd)
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 the web, so I could be wrong. Fortunately, you are :-). It's automagically invoked by the kernel's executable loader whenever any Mach-O binary is loaded that only has ppc code. You're right about the lack of (easily available) information though. A friend of mine was at the conference when they announced the switch, so I just asked him to try it out; I have found no place on the web that spells it out. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Missing Folder in ghc?
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-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: inside the GHC code generator
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 already working on that. It's basically done, I think I only need to get around to one more session with the code for final cleanup. (Just to avoid any duplication of effort). Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ANNOUNCE: GHC 6.4.1 binary package for Mac OS X
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 and HTML documentation on Mac OS X 10.3.9 or later. Darwin/PPC 8.x and Mac OS X 10.4 (Tiger) http://www.uni-graz.at/imawww/haskell/ghc-6.4.1dyn-powerpc-apple- darwin.tar.bz2 This is a standard unix-style binary package with GHCi, profiling, dynamic linking and HTML docs. It requires Mac OS X 10.4 (Tiger) and libreadline.5.0.dylib. The readline library is expected to be installed in /usr/local/lib, but you can change those expectations using the following command: install_name_tool -change /usr/local/lib/libreadline.5.0.dylib /some/ new/path/libreadline.5.0.dylib ghc-6.4.1/lib/powerpc-apple-darwin/ ghc-6.4.1 Enjoy, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FFI: calling Haskell from C++?
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: undefined reference to `__stginit_Foo()'#ifdef __GLASGOW_HASKELL__extern void __stginit_Foo ( void );#endifThis should be...extern "C" void __stginit_Foo ( void ); main.o(.eh_frame+0x11): undefined reference to `__gxx_personality_v0' collect2: ld returned 1 exit statusOn Mac OS X, all you need to do is add -lstdc++ to your ghc command line; it may or may not be that easy on other platforms.Cheers,Wolfgang___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.2.2 Compile problem on Mac OS X 10.4
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, Remko /tmp/ghc6793.s:83646:Fixup of 78156 too large for field width of 16 bits /tmp/ghc6793.s:83644:Fixup of 78164 too large for field width of 16 bits It looks like you have -fasm in your mk/build.mk. In 6.2.2, the native code generator has a problem that can cause an error like the one you encountered, so try removing the -fasm or adding -fvia-C. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.4
= 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/haskell/GHC-6.4.pkg.zip I just found a problem with my package: I accidentally included '/usr/local/bin/runhugs' in the package (which obviously has no business there). I have replaced the package with a fixed version. I apologize if this has messed up anyone's hugs installation. I've also made the double-clickable launcher icons work correctly with directory names that contain spaces. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.4
= 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/haskell/GHC-6.4.pkg.zip This package includes GHCi, profiling, dynamic linking support (experimental), documentation, and double-clickable icons. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.4
= 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/haskell/GHC-6.4.pkg.zip This package includes GHCi, profiling, dynamic linking support (experimental), documentation, and double-clickable icons. Additional Note: This requires XCode Tools 1.5 or later (available from Apple's web page for free, registration required). Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Another GHC 6.4 Release Candidate Binary for Mac OS X
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 execute a command. I might be able to work around this, though, by first checking whether Terminal is already open, and using different commands based on that. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Another GHC 6.4 Release Candidate Binary for Mac OS X
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 favourite .hs files onto those icons! *) a simple uninstaller *) html documentation now included Mac users, please start testing and send lots of feedback to me and to the list. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 6.4 Release Candidate Binary for Mac OS X
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 users, please start testing and send lots of feedback to me and to the list. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: x86_64 port
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCi and C++.
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. Any hints or pointers would be greatly appreciated. I think the files crtbegin.o and crtend.o are Linux-specific or maybe GNU-binutils-specific. Different platforms tend to have different strange requirements for C++ code. Loading shared libraries that happen to be written in C++ into GHCi shouldn't be a problem (or is it? definitely works on Mac OS X). Loading C++ .o files is a different story. Generally speaking, there are at least two things that set C++ .o files apart from normal C .o files: *) static constructors/destructors Sometimes there are pieces of code that expect to be called before main() or at program termination. The GHCi Linker doesn't support this, so some code may crash because things haven't been initialised properly. *) multiple definitions There is often some code in C++ header files (e.g. templates, inline functions, class members declared in the class declaration). These pieces of code are sometimes inlined, but sometimes they are not; in that case, gcc generates code for them in every .o file that uses them and counts on the linker to just include one version in the final executable. The GHCi linker will probably just abort and complain about multiply-defined symbols. The above is just theory, there might be even more problems in practice :-( . Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCi and C++.
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 .so, that should hide all the C++ stuff from GHCi. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4 release candidates available (breakage on x86-64)
[...] 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 propose we name it the diabolical splitter from now on.) Hmmm, even 'diabolical' doesn't quite seem to capture it. While the Evil Mangler is Evil, it is not Entirely Evil. We have to ask ourselves, what would the world be like without the Evil Mangler? Can there be Good without Evil? Would the Noble Code Generator (NCG) still be Noble if there were no Evil Mangler? The Evil Mangler is the kind of Evil that still has honor. Years after the forces of Good have finally prevailed, the broken remains of the Evil Mangler will still be proudly displayed in the castle's repositories, and the descendants of the Knights who overcame It will utter Its name with respect for an honoured adversary. The Satanic Splitter however, or whatever that Nameless Nemesis should be called, is an enemy of a different kind. Instead of attacking directly and honestly, it relies on treachery to destroy its foes. It lurks in the shadow of its big brother, the Evil Mangler, and it seeks to make the unsuspecting world believe that it is relatively benign. It does nothing that is essential to The Cause, and it tells its unsuspecting victims that can say SplitObjs=NO at any time, but when they do, it punishes them with multi-megabyte executables. And it cannot even do its evil deeds by itself - without the help of a Traitor in the code generator who puts split markers into the Code, the Splitter would be helpless. And I'm quite convinced that the Splitter's agents infiltrated Apple to make sure that the dead-stripping code in Apple's linker runs really slow. If Apple's code was efficient, the Splitter would already be banished from the Land of Apples. So go ahead and call the Splitter any bad names you like :-). Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4 release candidates available (breakage on suse 9.2 x86 or x86-64)
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 build a ghc of your choice and then delete it again. This is just like what you usually do when you install gcc on your box for the first time. Would it be unreasonable to include the unregisterised .hc files with a source distribution (or .hc files for popular platforms), so that a Haskell novice such as myself could do a ./configure make make install? If configure detected no ghc, perhaps it could do the bootstrap automagically. Well, the contents of the .hc files heavily depend on the results of ./configure - so unregistered .hc files still have to be tailor-made for the target platform. As far as registerised .hc files for popular platforms go, I fail to see the point. In what way is bootstrapping from platform-specific .hc files superior to installing a binary (apart from the fact that it takes longer and looks cooler)? It would be like shipping GCC as a bunch of x86 .s files. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Getting ghci to work (Mac OS X ghc-6.5 from CVS)
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 using stage2/ghc-inplace. If it's not that, what exactly did you do and what are the symptoms? Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4 release candidates available (breakage on suse 9.2 x86 or x86-64)
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). Well, it seems like I should have read your previous posts more attentively before mentioning the recommended way of doing things again - sorry. Not being intimately familiar with ghc internals, I don't know how much work this is, and whether the implementation cost exceeds the benefit (easier installation for Haskell novices like me). My guess is that for GHC, it won't work; the .hc files are really too low-level. Just about the only thing that's not already decided in the .hc files (that I can think of now) is the actual names of the libraries that the app links to. We'd need to supply .hc files for nearly as many platforms as we need binaries for. So maybe x86-Linux needs a ghc binary with as few library dependencies as possible, to facilitate bootstrapping on different Linux distros? Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Waiting on Sockets or File Descriptors
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 minor points: a) poll() is not supported on Mac OS X and (at least some popular versions of) BSD. b) 'forkIO' in the threaded RTS would suffice in this case, as the poll() or select() system calls don't use any thread-local state. In the threaded RTS, safe foreign imports never affect other threads, and you only need forkOS if the actual identity of the OS thread matters (i.e. when using thread-local state, OpenGL, some GUI libraries). Apart from that, my guess is that it would be fairly efficient with the threaded RTS. The only inefficiency would be that if you're doing regular IO to slow file handles at the same time, you'd get one (OS) thread in GHC's libraries calling select() for the regular fds, plus a separate (OS) thread running your call to select()/poll(). I'm not sure if cleaning this up would be worth the effort - you get at least two OS threads anyway. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem with handles in GHC from CVS
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 flushed for other exceptions. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem with handles in GHC from CVS
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 error. I would think it should flush all buffers on any type of exit. I agree (after thinking about it again). Done. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Loading package ghc within GHCi
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: that's why you can still provide your own malloc() and functions in libc.so will use yours rather than the default one. Note that the Darwin and (AFAIK) Windows dynamic linker do not support this behaviour. They explicitly avoid that kind of behaviour to prevent accidental overriding. (What happens on Linux if you link a GHC-compiled program to a shared library that internally uses a function named allocate? What if the next revision of that library introduces such a function?) What are the alternatives to using these hook functions? Explicitly looking for a OutOfHeapHook symbol in the executable using dlsym and friends? Exporting a RegisterOutOfHeapCallback function from the rts? Both seem a bit inconvenient to me, but some change might be necessary when we use dylibs/dlls. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Implicit parameter constraints not inferred
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' In the definition of `use_b': use_b = print ?b It works if I uncomment the signature. Using ghc-6.2.2, btw. My question: Is this as it should be or is it a bug? The Monomorphism Restriction. It's intended to prevent people from shooting themselves in the foot by defining things that look like constants (like use_b) but really are polymorphic values that still depend on some context and therefore are not constant. So in this case (use_b defined with no arguments), you need to specify a type signature. The monomorphism restriction would be useful in situations like: foo = expensiveOp bar How often will foo be evaluated? With the monomorphism restriction, at most once. Without it, well, that depends on the type of bar. With bar :: (?g :: Bool) = Int, foo also gets the (?g :: Bool) = context, and it's reevaluated whenever it's used; but you won't be able to tell that by looking at foo alone. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: setCurrentDirectory and lightweight threads
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 if one page wants to change directory using setCurrentDirectory, this change affects all other (lightweight) threads as well, which is not how ordinary system threads works. AFAIK, this _is_ how ordinary system threads work. See, for example: http://www.uwm.edu/cgi-bin/IMT/wwwman?topic=chdir(2)msection=3f, and http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ fileio/base/setcurrentdirectory.asp Also it is clearly not what one would want in the kind of application I'm writing. Is this behavior of setCurrentDirectory intended? I can't see a situation in which you could take advantage of it, but that doesn't mean there can't be any. =) If it is not intended, is there any hope of it being fixed? The behaviour is intended because it is the way the underlying operating systems work. It's hard to work around that; while it would be definitely possible (but tedious) to fix this for Haskell's IO library, we'd run into serious trouble with FFI calls (if you call two C functions from different Haskell threads, which will be the current directory of the process while both functions execute simultaneously?) So I fear that the only thing you can do is not to change the current directory in multi-threaded programs. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.2.2
= 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.dmg Enjoy, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using GHC and FFI
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 doen't link test.o to projekt.obj. What do I have to do? Start GHCi with the following command line: ghci -fffi test.lhs project.o GHCi should just load the object file, and you shouldn't have a problem. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating ghc's rts into other single-threaded frameworks
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). So we get callbacks from gtk in this other thread, which is fine. I'd expect you to get the callbacks in the same thread as the call-out, that is in your main thread (the same thread that was used to run the main action). However if we launch any other Haskell threads that want to update the GUI in any way they need to make calls in the GUI OS thread. But the GUI OS thread is not in Haskell land at this point, it's blocked in a call to the gtk+ main loop. Correct. GTK will need to help you a bit here for this to work. Many GUI toolkits offer a post event to main event loop function that may be called from any thread, at any time. You could use that to send a StablePtr (IO ()) to the GUI thread. You could also use a pipe to send that StablePtr to the GUI thread (I'm sure you can make GTK's event loop wait until a file descriptor is readable). I don't think that this machinery should take more than ten or twenty lines of code to implement. The absolute worst-case scenario involves registering a timer callback with GTK and regularily polling a Chan (IO ())... Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Windows ghc6.04
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 the threaded rts which uses native thread to make sure that (safe) ffi calls don't block. Waiting for a character sounds like a job for the standard input routines, and they should support concurrency even without the threaded RTS, but I don't know about the windows version. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC CVS refusing connections...
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 server does not respond to my public key, and instead asks for my password. I don't even know my password on cvs.haskell.org! Has there been an inadvertent configuration change somewhere? ... and I have the same problem. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.2.1
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/haskell/GHC.6.2.1.dmg Enjoy! Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: -static
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 remove it. I've just done so in the CVS HEAD. According to the source, alpha, hppa and mips also pass the -static flag to the linker. I've done nothing about that yet, as I have no idea why they do so. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: -static
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 and looks to be working fine. I haven't looked at the others yet. Wolfgang: can -static be removed on powerpc as far as you know? On powerpc-darwin, GHC has always passed -dynamic to the linker (otherwise, nothing would work at all). So I assume this is on powerpc-linux? If so, I don't see why the PPC should be any different from Intel in this respect. I cant test it now, but maybe I'll get around to having a short look at it tomorrow. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc and signal processing
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 problem here is that mapArray's implementation isn't perfect, and that GHC doesn't generate perfect code for it. I was able to get a 16% performance increase by using the following instead of GHC's built-in mapArray: import Data.Array.Base myMapArray :: (MArray a e' m, MArray a e m, Ix i) = (e' - e) - a i e' - m (a i e) myMapArray f marr = case Data.Array.IO.bounds marr of (l,u) - do marr' - newArray_ (l,u) let loop i n | i == n = return () | otherwise = do e - unsafeRead marr i unsafeWrite marr' i (f e) loop (i+1) n loop 0 (rangeSize (l,u)) return marr' The difference is that I use an explicit loop rather than an intermediate list of indices ([1 .. rangeSize (l,u) - 1]) that GHC fails to optimize away. There are two solutions: 1) Use a mutable-array in the StateMonad then freeze it. This won't help in this case (see above). 2) In this particular case where processing is sequential (IE you are only altering values based on *nearby* values, you can use streams. One of the nicest features of Haskell is how lists (being lazy) operate just like streams... [...] This should be fast, and also use very little memory. I second that. You might need to use arrays for input and output, but for everything in between, lists are probably a very good choice. Using lists this way in Haskell is probably more efficient that using an equivalent data structure in C. When you use arrays, GHC often ends up using lists internally, as we saw above. So the luxury of using lists really shouldn't cost too much. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.2
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/haskell/GHC.6.2.dmg Includes OpenGL support. It will probably not work on Mac OS X 10.2 (Jaguar). I don't have a machine with 10.2 left, so I won't be able to release a package for 10.2. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: forkProcess type changed?
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 fork if this is the parent or child process? The following example should explain everything: Old Version: do mbPid - forkProcess case mbPid of Nothing - putStrLn Child Just pid - putStrLn $ Parent of ++ show pid New Version: do pid - forkProcess (putStrLn Child) putStrLn $ Parent of ++ show pid Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Foreign Function Interface (FFI)
(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 system ? No, it's not guaranteed to be executed atomically. With current implementations, it does block the whole STG system, but only until a callback is made, and when multiple (forkIO'ed) Concurrent Haskell threads call foreign imported functions that might call back into Haskell, things become almost unpredictable. GHC supports an optional feature (pass --enable-threaded-rts to configure when compiling GHC) that makes GHC guarantee that the STG system is never blocked by foreign calls. It will probably become the default in the future (after the remaining bugs are fixed). Idea: To implement a monitor , in a external context , and threads around him to access it, bypassing the Mvar paramter-pass among them... Well, similar ideas have been brought up before, and I'm a bit sceptical: *) Why should we introduce a feature at the language level for solving a problem that is already solved by MVars? You can write your own combinators to reduce the hassle of using MVars to a minimum. *) Why would we want all external calls to be serialized? In most circumstances, I'd like more granularity than that. What exactly do you have in mind? Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Pestilential behaviour of gcc3.3 on Macs
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 surprise tools and scripts that depended on the exact form of preprocessed output from GCC. These scripts should be rewritten to ignore unrecognized pragmas. Would it be possible for GHC to ignore this line? Otherwise ghc -cpp is going to fall over with gcc3.3 on Macs. Yes, GHC 6.2 and later will ignore that line. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.0.1 on OS X Panther build
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 split-objs-related problem with gcc 3.3 that I fixed in September - I don't remember the exact error message that gave me. You should be fine if you sudo gcc_select 3.1 or use a configure option to make GHC use gcc3 as it's C compiler. Or you could just take the latest revision of fptools/ghc/driver/split/ghc-split.lprl from the HEAD or STABLE cvs trees and use plug it into the old 6.0.1 sources. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Job Opening - Mac OS X 10.2 Binary Packages
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 new features, but that means that versions of GHC built on Panther will not work on previous versions of Mac OS X. Which brings me to the point of this mail: When GHC 6.2 is released, I probably won't have access to a Mac running Mac OS 10.2 any more, which means that my binaries for GHC 6.2 will _require_ Mac OS X 10.3. So would someone please step forward and accept the role of GHC packager for Mac OS X 10.2? Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Job Opening - Mac OS X 10.2 Binary Packages
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-line GCC to use them, let alone how to get GHC's makefiles and configure script to pass the correct flags on to GCC. And as I really dislike digging around in Makefiles and configure scripts, I think it would be much simpler if somebody else did the 10.2 build. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Threaded foreign functions calling back.
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 haskell via foreign exported functions. Is this supported in ghc? Some simple tests suggests that it does work, at least I don't get any crashes, if ghc is compiled with --enable-threaded-rts. But is this intended to work or am I just lucky? Yes, this is indeed what --enable-threaded-rts is intended for. Beware that the code is not well-tested (that's why it's a separate option); however, there are no known bugs (if you encounter any, please tell me). You should also be aware of one remaining problem, which will be fixed in the upcoming GHC 6.2:Your C-library must not rely on the use of thread-local state (that is, pthread_key_create on unix and TlsAlloc on Win32); basically, when you call a foreign import, you don't know in what thread it will be executed (there's some interthread messaging and some black magic going on here). For the same reason, the value of errno cannot be reliably accessed from Haskell with GHC 6.0. Most libraries are entirely unaffected by this problem, but I thought I'd warn you just in case. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.0.1
= 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, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: threaded-rts
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 classic out there so it gets tested a little more. The new bound threads variant will share a lot of code with the classic variant, so testing the old code a little more does make sense. Wolfgang, do you have a timescale in mind? Well, let's see. I got my Powerbook back from repairs yesterday; now I have to track down one Mac-specific issue for 6.0.1. Then I'll have a look at the head and my old bound-threads prototypes. I might have some (preliminary, experimental, hackish, untested, ugly) patches ready on the weekend. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: threaded-rts
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 thinks the rts package is 'hs_libraries = [HSrts-threaded],' which I install into the same directory [...] Something like that, I guess. As for the .hi files... no idea why they should be different, the configure flag absolutely positively doesn't affect how the libraries are built - do the hi files perhaps contain a timestamp or something else that might change on its own? Could be - looking at one of the .a files at random (libHSposix.a) it looks like it is the timestamps of the files inside it that has changed. FWIW the .hi differences on /usr/lib/ghc-6.0/imports/GHC/Int.hi are: (again chosen at random) (note that these are not contiguous) I don't see anything here. One more thing - is there an easy way to check to see if it has worked? I assume a Haskell program can't tell whether or not it is being run in a threaded-rts? I have access to a dual-CPU machine so I can time things with and without if that makes sense. Dual-CPU doesn't help, as the threaded RTS still only runs one Haskell thread at a time (SMP is a lot harder). However, import Foreign foreign import ccall sleep :: Int - IO () -- slightly wrong signature, but still works :-) main = do forkIO $ sequence_ $ repeat $ putStrLn Hello, world. sleep 10 If the above program prints Hello, world. like mad for 10 seconds, it's the threaded RTS; if it prints it at most a few times and then stops for 10 seconds, it's the non-threaded RTS. Hope that helps, Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Building on Mac OS X
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 instructions for building it. If you have a set of build scripts that would be even better. I'll be getting my Powerbook back from repairs tomorrow, and I'll have to install everything from scratch anyway; that's a perfect occasion to write up accurate instructions. Stay tuned! Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Incorrect Mime Type for Mac OS Package
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 6.0 for Mac OS X
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/listinfo/glasgow-haskell-users
Re: Mac Port
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 to the haskell build. This means you can't have libreadline and libdl in non-standard locations. Grmpf... I know I don't like configure scripts. I prefer IDEs. Do you know how to fix it/have time to do it? If not, would somebody else _PLEASE_ do that for us? (It wouldn't enjoy digging into the build system code to fix that; in fact, I would positively hate it). This is a problem for darwinports and fink because of their automatic dependency management. 2. Even if I put symlinks to the above libraries in the standard locations, I still get a build failure. This is building 6.0 using 5.04.3. (5.04.3 was built from source successfully using your 5.04.2 binary.) The build ends with [...] Ahem, yes. I didn't have a chance to test GHC 6 in the last five days before the release, and, of course, the last commit broke the Mac OS X build. I have meanwhile committed a fix to CVS, but that was a day after the official relase for 6.0. If you check out the newest stable branch from CVS (or ask me to send you diffs tomorrow), it should work. (That last commit made GHC quote all arguments it passes on to GHC; for Mac OS X, it passed -framework HaskellSupport instead of -framework HaskellSupport. GCC doesn't report an error but it just ignores the former. Strange.) The HaskellSupport framework (which is not used if it's not detected at configure time; there should really be a configure switch for that) is just an aggregation of libgmp and libdl packaged as a framework. I figured that would be easier for end users of Haskell programs, as libgmp is required for all Haskell programs, and libdl is used by the Posix library (and how do you install a dylib using the Finder?). For something like darwinports, it might be better to just rely on the gmp and dl libraries installed with darwinports, but that makes programs compiled using ghc dependent on darwinports, too. And you just reminded me that I still haven't uploaded the 10 line shell script for creating the HaskellSupport.framework anywhere, because I could never figure out the appropriate place in CVS: #!/bin/sh cd dlcompat-20020413 cp dlfcn.o ../ make cd ../gmp-4.0.1 ./configure make ld -r -d ./libs/libgmp.a -o ../libgmp.o cd .. ld -dylib -o HaskellSupport.framework/Versions/A/HaskellSupport libgmp.o dlfcn.o /usr/lib/dylib1.o -lSystem OK, that's all for now... Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Mac Port
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. I could definitely use more people who regularily build GHC on MacOS X and do some testing, and alert me of any breakage _before_ I make a buggy release... I don't have the computing capacity to do nightly builds. Mac OS 9 is a different story. GHC doesn't work on Mac OS 9, and it will probably stay that way: *) There is no GCC that runs on Mac OS 9. *) There is no GCC that cross-compiles to Mac OS 9. ... and the ABI is different from other PowerPC platforms, including Mac OS X. *) Mac OS 9 doesn't support the POSIX API. GHC's run time system and libraries require either Posix or Win32. A lot would have to be rewritten for Mac OS 9. *) There's no unix-style shell on Mac OS 9 That means we have to cross-compile or use a completely different build system. *) Mac OS 9 is obsolete There are people using it now, and there will still be people who use it in the future, but by the time any port is finished, they will be very hard to find. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FFI and Concurrency
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 means you have to compile a prerelease version of GHC yourself (and pass a special ./configure flag, --enable-threaded-rts). The only other way I could think of would be to write a C language module that uses pthreads to achieve the purpose (has to be mostly in C because you mustn't enter the Haskell runtime system from a second thread). Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: More problems compiling GHC on Mac OS X
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 - ./configure found out that sendfile is not supported, and everything is fine until I try to use it (there wasn't yet a fallback implementation then). What did configure say on the subject of sendfile? Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Stack profiling
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, while the one with a JoinList is eating up stack at an O(n) rate. No idea. I haven't used all features of the profiler yet. I'm taking the liberty of CCing the [EMAIL PROTECTED] mailing list, I hope somebody else can provide an answer. If not, could I have your build script to generate a MacOS X package for a rebuilt GHC with ticky-ticky libraries? No matter what I do, all roads lead to rebuilding from source ;-). There's no build script for making Mac OS X packages - I need to use Apple's GUI tools to create the package, and the rest is a relatively simple matter of configure and make. You'd have to download the source, create a build.mk file saying that you want ticky-ticky profiling, and then configure, make and make install... Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Building snapshot ghc-5.05.20030123 on macOSX
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 [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug in GHC 5.04.2 for Mac OS X
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 68K was perfect!). Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: forcing a haskell object to WHNF from C
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 that every HaskellObj value might be invalid after a call to rts_eval (except for the return value). rts_eval starts a new concurrent Haskell thread to do the evaluation. In essence I want a C version of seq (perhaps I can call to Haskell to perform a seq on it, but I think this might be overkill). Calls to Haskell are implemented using rts_eval/rts_evalIO too, so writing it in Haskell is the same thing with a little bit more overhead. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Shutting Down the RTS
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 reasonable and matches the behaviour of C programs on most platforms. In the threaded RTS, this behaviour has never been implemented. We can't simply return from schedule(), because we might no longer be running in the thread of the RTS main() routine. The thread where rts_mainEvalIO was called might be busy executing some foreign code that we know nothing about. (Im)possible solution #1: As soon as the main action terminates, call shutdownHaskellAndExit(). At first, this seems to work fine. But then, shutdownHaskellAndExit() comes along and tries to run finalizers. For every finalizer, the RTS is started back up again using rts_mainEvalIO(), and this time, we really have to exit by returning from rts_mainEvalIO(). Possible solution #2: Forget about running finalizers at program termination and just exit(). In most of the situations where I'd use finalizers, I don't need to run them upon program termination, the OS cleans up after me. Also, the finalizers are not run in the correct order anyway, and there are situations where running them in the wrong order might be worse than not running them at all. And, most of all, solution #2 is easy to implement. Can somebody suggest a third solution, or shall I go for #2 for the time being? Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Native Threads in the RTS
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. add inline comments, alternative rules, and whatever. OK, I'll get to work :-) Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: signal masks and garbage collection.
Keean Schupke wrote: I am trying to block the SIGPIPE signal, I have used the Posix sigprocmask call to set the signal to blocked. However the program sill bails out if the client closes its socket. The exception handler appears to be called then the program terminates. When I run the program in gdb, it gives a SIGPIPE signal just after the thread swap happens... Heres the report from gdb: I think I know what's going on: The runtime system is using sigprocmask for it's own purposes and accidentally overwrites your signal mask. In short: stay away from sigProcMask and friends, 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/listinfo/glasgow-haskell-users
ANNOUNCE - HOC - Haskell to Objective C binding for Mac OS X
My first experiment with Template Haskell is available for download (16KB) at: http://www.kfunigraz.ac.at/imawww/thaller/wolfgang/HOC020103.tar.bz2 HOC --- Haskell to Objective C == This is a first development snapshot of HOC, an experimental Haskell binding to Apple's Objective C runtime on Mac OS X. It is intended to be used in order to access the Cocoa API for writing graphical user interfaces entirely in Haskell. HOC relies on Template Haskell to achieve its goals and therefore requires a prerelease GHC 5.05 (from CVS) in order to run. No additional code-generating tools are required. You can: *) create objects *) send messages *) define classes Not yet supported: *) floating-point parameters *) messages to super *) ghci (the ghci Linker doesn't currently load Objective-C object files) Other disappointments: *) Memory management of Objective C objects has to be done manually. *) You have to declare Cocoa classes, selectors and their types first, they are not predefined. Compile using sh build.sh and run by double-clicking the Test application or by typing Test.app/Contents/MacOS/Test If you double-click 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 warranties. --- Have fun! Wolfgang Thaller [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: MacOS X (10.2.2) standalone ghc app
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 briefly mentioned in the README that you saw in the installer :-) Could someone explain why this is needed on OSX? It seems OS specific, for I don't have any of these issues on Windows and Linux. The HaskellSupport.framework contains two required support libraries, libgmp and dlcompat. Libgmp is distributed under the GNU Lesser General Public License (LGPL), which means that statically linking to it places special requirements on your program. Therefore static linking is not really an option in this case. I've packaged the two required libraries as one framework because that's easier to install for end-users than unix-style dynamic libraries. Programs compiled using GHC for Linux just expect libgmp to be installed (which is often the case on Linux). On Windows, libgmp is statically linked, which means that you should at least read the LGPL before distributing your program. Any hint about how to do the linking statically on OSX would be greatly appreciated. Just don't. Instead, read section 6 of the LGPL (somewhere at www.gnu.org) for the complete list of conditions you would have to fulfill, and then think about how easy and convenient dynamic linking is :-). Happy New Year, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: small problem with ghc(i) on Windows
Jerzy Karczmarczuk wrote: Apparently the form (#) is considered illegal. It works on my Linux. On Win2000: parse error on input ')' (#) is legal Haskell 98, but it is illegal in GHC when -fglasgow-exts is on. It should have nothing to do with the platform. Thre reason is that GHC 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 hash: write ( # ) instead. Cheers, Wolfgang Thaller ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 5.04.2 released
== The (Interactive) Glasgow Haskell Compiler -- version 5.04.2 == A Mac OS X installer package is now available at http://www.uni-graz.at/imawww/haskell/GHC.5.04.2.dmg It includes profiling libraries, 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. Note to the webmaster: If you can spare the space, keep the old 5.04 binary online (there are still many people using Mac OS X 10.1). Regards, Wolfgang Thaller ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Native Threads in the RTS
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 agree to that. Creating a new thread for calling back into Haskell _only_ makes sense if you look at it from inside the GHC RTS. Before I had a look at the relevant parts of the RTS, I would never have thought of that. I don't know if there's any advantage/disadvantage to changing GHC's internals. The only _observable_ difference is the thread's ThreadIds, and this should at least be clearly documented (or, even better, it should be explicitly undocumented, so that no one will be suprised if the behaviour is changed in the future). Off the top of my head I can think of two situations in which having separate threads is bothersome. 3. Throwing exceptions to a thread If I manually translate haskell exceptions to foreign exceptions and back, there is no reason why I shouldn't want to raise an exception in a thread I have a threadId for, even if that thread called a foreign function which in turn called back to haskell. I think that the behaviour can always be emulated using MVars however, so I think there's no immediate action required. --- I've tried to rephrase my proposal for native threads, this time treating GHC's behaviour in this situation as an implementation detail. I think the meaning of the proposal becomes clearer because of this. The proposal doesn't comment on ThreadIds, so the non-intuitive (IMHO) behaviour in GHC is independent of the bound threads proposal. I think I've understood both my own specification and the current RTS well enough to start trying to implement a prototype soon. The intended meaning of the specification hasn't changed for the third revision in a row. Does anyone have concrete suggestions for the syntax change to foreign export and foreign import wrapper? Cheers, Wolfgang = Bound Threads Proposal, version 5 Goals ~ Since foreign libraries sometimes exploit thread local state, it is necessary to provide some control over which thread is used to execute foreign code. In particular, it is important that it should be possible for Haskell code to arrange that a sequence of calls to a given library are performed by the same native thread and that if an external library calls into Haskell, then any outgoing calls from Haskell are performed by the same native thread. This specification is intended to be implementable both by multithreaded Haskell implementations and by single-threaded implementations and so it does not comment on which particular OS thread is used to execute Haskell code. Definitions ~~~ A native thread is a thread as defined by the operating system. A Haskell thread encapsulates the execution of a Haskell I/O action. A Haskell thread is created by forkIO, and dies when the I/O action completes. When a Haskell thread calls a foreign imported function, it is not considered to be blocked (in the GHC runtime system, the calling thread is blocked; This is considered an implementation detail for the purposes of this specification, but be aware that myThreadId might return several different values for one Haskell thread as defined here). If the foreign function calls back to Haskell, the callback is said to run in the same Haskell thread. Design ~~ Haskell threads may be associated at thread creation time with either zero or one native threads. Each Native thread is associated with at most one Haskell thread. A native thread that is associated with a Haskell thread is called a bound Haskell thread. A Haskell thread that is associated with a native thread is called a bound native thread. A Haskell thread is always executed by a native thread. This specification places absolutely no restrictions on which native thread is used to execute a particular Haskell thread. The Haskell thread need not be associated with the native thread used to execute it, and one Haskell thread may be executed by more than one native thread during its lifetime [but not by several native threads at once]. A bound native thread may not be used for executing any Haskell thread except the one it is bound to. It is implementation dependent whether the main thread, threads created using forkIO and threads created for running finalizers or signal handlers are bound or not. When a foreign imported function is invoked [by Haskell code], the foreign code is executed in the native thread associated with the current Haskell thread, if an association exists. If the current Haskell thread is not associated to a native thread, the implementation may decide which native thread to run the foreign function in. The native thread that is used may not be bound to another Haskell thread. The existing distinction
Re: Native Threads in the RTS
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 library are performed by the same native thread and that if an external library calls into Haskell, then any outgoing calls from Haskell are performed by the same native thread. *) The specification should be implementable in a way that allows a lot of foreign calls to be made with no additional overhead with respect to GHC's current unsafe foreign calls. *) The good performance of the existing lightweight green threads in GHC should not be sacrificed. Performance should still OK when using the new features with only a few threads (i.e. not more than commonly used from multithreaded C programs). *) The specification shouldn't explicitly require lightweight green threads to exist. The specification should be implementable in a simple and obvious way in haskell systems that always use a 1:1 correspondence between Haskell threads and OS threads. *) The specification shouldn't specify which particular OS thread should be used to execute Haskell code. It should be possible to implement it with e.g. a Haskell interpreter running in one OS thread that just uses other OS threads for foreign calls. *) There should be no unexpected blocking. Especially, threadsafe calls should never cause other threads to block. I'm currently stuck thinking about one particular problem that I discovered in my current version of the spec. What happens when an unbound Haskell thread calls a threadsafe foreign function which in turn calls a bound foreign exported function? Well, I think my current proposal says relatively clearly what's supposed to happen, but I discovered it's not as easy to fit that in the current implementation of GHC as I thought... in fact it might be quite difficult. I'll have to do more thinking before I can be sure, though. That's it for today, Regards, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: MacOS X (10.2.2) standalone ghc app
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 Could someone explain why this is needed on OSX? It seems OS specific, for I don't have any of these issues on Windows and Linux. GHC requires the GNU MP library (libgmp) and, on Mac OS X, also a small compatibility layer for dlopen() and friends. On Linux, GHC simply relies on libgmp to be installed, and most of the time, this is the case. For Windows, GHC currently statically links libgmp into your program, but this might violate the Lesser GNU General Public License under which libgmp is distributed (IANAL). For this reason, I chose _not_ to use static linking on Mac OS X. Normal Mac-users don't want to install a UNIX-style shared library into /usr/local/lib (after all, /usr is not visible in the Finder). The HaskellSupport.framework can be installed much more conveniently. Any hint about how to do the linking statically on OSX would be greatly appreciated. 1) Distribute HaskellSupport.framework along with your app, with instructions on how to install it or with an installer. It should go into /Libraries/Frameworks/ 2) If you already have a MacOS X-Style .app-package for your application, you can put HaskellSupport.framework into MyApplication.app/Contents/Frameworks/. Unfortunately, .app-packages aren't very useful for non-graphical applications. 3) Forcing static linking is not as easy as it could be. Make sure you have static versions of libgmp and dlcompat (you can get sources at www.gnu.org and fink.sourceforge.net respectively). Then use ghc -v for linking and copy the linker command line passed to Apple's linker. Then run Apple's linker directly but replace -framework HaskellSupport by the absolute paths to the static versions of the libraries (if you use -l, the linker will use dynamic libs if present). I'd say 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-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Native Threads in the RTS
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! Please don't! I see two potential problems with this (but would like to hear which, if either, dominates your thoughts): 1) If foreign threads cannot be used to execute Haskell code, foreign calls require (OS-level) context switches which are expensive. 2) Adding an implicit lock to foreign calls might surprise programmers. I'm slightly concerned about 2), but 1) Is an absolute show-stopper for me. It should stay possible to implement an unsafe call as just a call - no special RTS management, no context switches, no nothing, just a few machine code instructions to move the parameters to the stack and/or registers. And I definitely do want to keep that efficiency for bound Haskell threads. The reason why I startet this discussion is that I want to use OpenGL in my Haskell Programs (which works fine with GHC's current non-threaded RTS). OpenGL requires a lot of calls to functions that don't take much time to execute and that don't call back to haskell land. Using safe or even threadsafe for these calls would kill performance utterly and completely. *) Exactly one Haskell thread associated with the native thread is executing. All other associated Haskell threads are blocked. No foreign code is being executed by the native thread. This isn't quite right - or, at least, needs clarified. Consider Haskell functions a,b,c,d and C functions A,B,C,D and a call pattern a - A - b - B - c - C - d - D That is, a calls A, calls b, calls B, calls ... Suppose we want A,B,C,D executed by the same foreign thread. [...] I think the quoted text assumes that a,b,c,d are blocked during the call to D. Yes. For the purpose of the above paragraph (and the neighboring paragraphs in the spec), a Haskell thread is considered blocked during a call to a foreign imported function. I admit that this terminology is inspired by implementation details of GHC, but it makes [some] sense: After all, if there is no Haskell code to execute [it's foreign code only now], the Haskell thread can not be executed. A Haskell thread can be either blocked or executing Haskell code. This needs careful interpretation if we want to be able to bind finalizers to foreign threads. In particular, if a finalizer is bound to a foreign thread, we don't increment 'bindees(f)' until the finalizer starts and we don't start the finalizer unless either: I'm not currently planning to allow finalizers to be bound to native(foreign) threads, as I have so far failed to see a solution that I'm happy with. [...] From an implementation point of view, this requires: 1) That foreign threads are _not_ used to execute Haskell code. One of my design goals is to allow the native threads to be used to execute Haskell code. Implementations are not required to do so, but it should be possible. For that reason I also dislike the term foreign thread. It sounds great until I want to say the implementation may use the foreign thread to execute Haskell code. And just as I went back to the computer after a long pause in order to finish this message, a new proposal arrived. I'll take more time to study it more completely. I just want to reiterate one thing: The notion of bound foreign imports could be eliminated by saying that all foreign calls are performed by the bound thread if one exists and eliminate the concept of 'bound foreign imports'. The only reason to allow any flexibility is to allow for faster implementations which perform less context switching - this is especially important for 'unsafe' foreign calls. I definitely need zero-overhead bound unsafe calls. Everything else would be basically unusable for me. I'll be back later. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Native Threads in the RTS
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't mean that, and I've been avoiding to say that. This is how the GHC implementation will probably handle it, but I do not want to put that in the general specification. Alastair remarked a while ago: For that matter, I'd like it to be possible to implement this spec in Hugs. Hugs is internally single-threaded but this spec is concerned with what happens when Haskell calls out to C and we could arrange to switch into the appropriate native thread when Hugs calls out to C. After all, the only thing which needs to be guaranteed is that foreign functions called by the Haskell thread are executed in the associated native thread. You don't say (and I'm not sure if you mean) If a bound native thread blocks, all of its associated Haskell threads are blocked too If a bound Haskell thread blocks, its associate native thread and all its associated Haskell threads also block. Does this sound clearer: *) Exactly one Haskell thread associated with the native thread is executing. All other associated Haskell threads are blocked. No foreign code is being executed by the native thread. *) The native thread is executing foreign code. No Haskell code is executing in any of the associated Haskell threads. *) The native thread and all Haskell threads associated with it are blocked. | The thread that main runs in, threads created using forkIO and threads | created for running finalizers or signal handlers are not necessarily | associated with a native thread. However, an implementation might | choose to do so. But the impl may *not* choose a bound native thread. These must be kept inviolate. [...] Again, it must not be a bound native thread. Good point, I had overlooked that. If a bound Haskell thread calls a foreign import that is not labelled 'threadsafe' which calls a bound foreign export does that work? What if the foreign export was not bound? Similarly, if the foreign import was labelled 'threadsafe', would it work? It's not obvious to me. Some kind of semantics would be good. Good question. I reread Section 3.3 of the FFI document (RC7), and now I think I cannot clarify my specification in this respect without first asking others to clarify the current specs - can someone explain the distinction between unsafe, safe and threadsafe in the current FFI to me? I think I know what it does in GHC, but what's the general definition? I've read the description in the FFI document, but it's not clear to me. Is there any reason why safe is the default and not threadsafe? After all, safe is less safe (it might cause the whole program to block). To me, safe seems to be an odd middle ground between speed and safety. What is safe guaranteed/allowed to do? Is it _guaranteed_ to block other Haskell threads under certain conditions? Or is that only an artifact of current implementations? Why are implementations allowed to _silently_ fall back to safe when threadsafe is not supported? Isn't that dangerous? If I'm not mistaken, threadsafe calls from bound Haskell threads would have exactly the same overhead as safe calls. Should we make sure that safe calls somehow block other threads? If so, why? Thats all for now Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Native Threads in the RTS
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 runnable at any one time (this is an important invariant from the point of view of the implementation, I believe). Of course, you're right. Simon Peyton-Jones wrote: I offer myself as such a guinea pig. I'm afraid I don't understand it yet. It's hard to describe precisely. Comments below. Yes, I do need a guinea pig ;-) . I really have trouble expressing my ideas accurately, and I keep changing them. Better start with some definitions, for 'Haskell thread' and'native thread' I think I know what you mean, but better to be sure. Well, yes. I didn't manage to come up with a decent definition for it yet. I intend native thread to be the thing you get using pthread_create on unix, and Haskell thread to be the same thing as it currently is in the GHC RTS. Can anyone think of a way of defining that in a way that is accurate, general and understandable? | If there is one, this Haskell thread is used to execute the callback. OK, so this is where I get completely confused. A Haskell thread is not (currently) an execution platform. Oops... The best way to confuse other people is to be confused yourself ;-) --- I had a slight misconception about the RTS there --- I think I've corrected that. === Threads Proposal, version 4 Goals ~ Since foreign libraries sometimes exploit thread local state, it is necessary to provide some control over which thread is used to execute foreign code. In particular, it is important that it should be possible for Haskell code to arrange that a sequence of calls to a given library are performed by the same native thread and that if an external library calls into Haskell, then any outgoing calls from Haskell are performed by the same native thread. This specification is intended to be implementable both by multithreaded Haskell implementations and by single-threaded implementations and so it does not comment on which particular OS thread is used to execute Haskell code. Definitions ~~~ A native thread (aka OS thread) is a thread as defined by the operating system. A Haskell thread is [*** FIXME - How shall I put this? ***] the thing you see from Haskell land. Design ~~ Haskell threads may be associated at thread creation time with either zero or one native threads. Each Native thread is associated with zero or more native threads. If a native thread is associated with one or more Haskell threads, exactly one of the following must be true: *) Exactly one Haskell thread associated with the native thread is executing. *) The native thread is executing foreign code. *) The native thread and all Haskell threads associated with it are blocked. The thread that main runs in, threads created using forkIO and threads created for running finalizers or signal handlers are not necessarily associated with a native thread. However, an implementation might choose to do so. There are now two kinds of foreign exported [and foreign import wrapped] functions: bound and free. The FFI syntax should be extended appropriately [which of the two should be the default, if any?]. When a bound foreign exported function is invoked [by foreign code], a new Haskell thread is created and associated with the native thread. The new associated Haskell thread is then used to execute the callback. When a free foreign exported function is invoked, the implementation may freely choose what kind of Haskell thread the function is executed in. It is not specified whether this thread is associated with a particular OS thread or not. When a foreign imported function is invoked [by Haskell code], the foreign code is executed in the native thread associated with the current Haskell thread, if an association exists. If the current Haskell thread is not associated to a native thread, the implementation may freely decide which thread to run the foreign function in. The existing distinction between unsafe, safe and threadsafe calls remains unchanged. A new library routine, forkNativeThread :: IO () - IO ThreadID, should spawn a new Haskell Thread (like forkIO) and associate it with a new native thread (forkIO is not guaranteed to do this). It may be implemented using the FFI and an OS-specific thread creation routine. It would just pass a bound callback as an entry point for a new OS thread. Issues ~~ Finalizers and signal handlers cannot be associated with a particular native thread. If they have to trigger an action in a particular native thread, a message has to be sent manually (via MVars and friends) to the Haskell thread associated with the native thread in question. This introduces a change in the syntax for
Re: Native Threads in the RTS
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't be a primitive, but can be implemented on top of the FFI. After that I found out what the bound/free exports buisiness was all about and why we might need it. As for the questions regarding my previous proposal, I think they are answered in the new one. If they aren't, let me know. [It's no use explaining what I meant to say if I already want to say something different ;-) ] Cheers, Wolfgang === Threads Proposal, version 3 Goals ~ Since foreign libraries sometimes exploit thread local state, it is necessary to provide some control over which thread is used to execute foreign code. In particular, it is important that it should be possible for Haskell code to arrange that a sequence of calls to a given library are performed by the same native thread and that if an external library calls into Haskell, then any outgoing calls from Haskell are performed by the same native thread. This specification is intended to be implementable both by multithreaded Haskell implementations and by single-threaded implementations and so it does not comment on which particular OS thread is used to execute Haskell code. Design ~~ Haskell threads may be associated at thread creation time with either zero or one native threads. Each Native thread is associated with zero or one Haskell threads (no native thread may be associated with two Haskell threads at a time). An associated pair of a Haskell thread and a native thread can only execute either foreign code or haskell code at any one time. The thread that main runs in, threads created using forkIO and threads created for running finalizers or signal handlers are not associated with a native thread [Actually, we might make this an implementation detail: These Haskell threads are not guaranteed to be associated with a native thread. If it makes sense for some implementation, all threads might be associated with native threads]. There are now two kinds of foreign exported [and foreign import wrapped] functions: bound and free [I'm not happy with these names, for the same reasons as given by Seth before]. When a bound foreign exported function is invoked [by foreign code], the implementation checks whether a Haskell thread is associated with the current OS thread. If there is one, this Haskell thread is used to execute the callback. If there is none, a new Haskell thread is created and associated with the native thread. This is the only situation where a Haskell thread is associated with a native thread. The new associated Haskell thread is then used to execute the callback. When the callback finishes, the Haskell thread is terminated, the association is dissolved, but the OS thread continues to run. When a free foreign exported function is invoked, the implementation may freely choose what Haskell thread the function is executed in. It is not specified whether this thread is associated with a particular OS thread or not. When a foreign imported function is invoked [by Haskell code], the foreign code is executed in the native thread associated with the current Haskell thread, if an association exists. If the current Haskell thread is not associated to a native thread, the implementation may freely decide which thread to run the foreign function in. This must be done for all foreign imports, including unsafe. An unsafe call must not call back to Haskell or otherwise cause a garbage collection. Other Haskell threads may be blocked while the unsafe call executes. A safe call allows callbacks to Haskell. Other Haskell threads may be blocked while the unsafe call executes. A threadsafe call additionally guarantees other Haskell threads not to block. forkNativeThread :: IO () - IO ThreadID may be implemented using the FFI and an OS-specific thread creation routine. Issues ~~ Finalizers and signal handlers cannot be associated with a particular native thread. If they have to trigger an action in a particular native thread, a message has to be sent manually (via MVars and friends) to the Haskell thread associated with the native thread in question. This might be tedious, but if we want to avoid the nastiness of multiple Haskell threads associated with one OS thread (lots of unpredictable blocking), it looks like our only choice. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Native Threads in the RTS
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 this possibility would also be a pro this language : Haskell would be the only language to have safe multithreaded OpenGL programming. You can safely render into two different OpenGL contexts from two different OS threads. I don't think that rendering into the same context from two green threads would work - the OpenGL interface is far too thread-based for this to be useful. *Another problem can raise : if one render in two different OpenGL windows, he may want to use different threads for these rendering. However, this is impossible for the moment because it would implies that user threads know when a switch has occurred to a thread rendering in another context and swap OpenGL context. This implies a notion of either : allowing to execute arbitrary code on switch ; [...] If we want to render into two different OpenGL windows in parallel, we can use two OS threads. OpenGL keeps a reference to its current OpenGL context on a per-OS-thread basis (some old OpenGL implementations might not support this, but I think we can ignore them). [...] some user defined code should be executed (in that case the code perform a context switch) [...] Haskell Code won't work here [after all, we're between two haskell threads...]. C code would be no problem. I actually proposed something like this as a stopgap measure for making OpenGL work with the threaded RTS in summer, but I was convinced by others on this list that this is a hackish solution that relies on internals of the RTS far too much. It seems that family and OS threads are independent : it could either be multiple OS threads for a family or multiple families for an OS threads. I think a thread could be member of multiple families (even if I can't see pertinent example so far). I also think that multiple threads can be the same member of a family (multiple threads drawing in the same window). What would it mean if a thread was a member of more than one thread families? Would it mean that it might execute in several different OS threads? Also, how would these thread groups interact with the existing threaded RTS? Would the existing features still be available without additional effort? Would they be implemented on top of these thread families? I'm not quite convinced that the thread families approach would be worth the additional complexity. What would it be used for? * To protect OpenGL operations, it would perhaps be useful to introduce a mechanism forbidding to switch between members of a family between a critical section. (I don't know what do a context switch between a glBegin and glEnd). We already have MVars, they can be used for things like that. Can anybody else think of reasons why we should need a more complicated design where threads are put into different families or groups, where each thread group executes in exactly one OS thread? This has been proposed at least twice now, but I fail to see the advantages (it looks more flexible, but what's it _for_?). Some disadvantages of a thread groups approach are: *) More complexity. *) Foreign calls will block other threads in the same group. *) It would be even less meaningful for a haskell implementation that always uses OS threads --- the native/green threads proposal could be implemented as a no-op (forkNativeThread = forkIO) without breaking programs that use it. Somebody else please fill in the advantages. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Native Threads in the RTS
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 http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/rts-libs/multi- thread. html Of course. Some parts should be part of the user documentation, while others should probably be considered implentation details. | A foreign exported | callback that is called from C code executing in that OS thread is | executed in the native haskell thread. This is the bit I don't understand. Is the only scenario you have in mind here native Haskell thread calls C which calls Haskell and you want all that in the same native thread? Yes, exactly. What about this? native Haskell thread calls C which installs a pointer to a foreign-exported Haskell function in some C data structure Later... some other Haskell thread calls C which waits for an event which calls the callback So the callback was installed by a native thread, but won't be executed by it. Is that ok? Definitely. It's the same way it works in C. What thread some code executes in depends on what thread the code is called from. Anyway I think it would be worth explaining what is guaranteed a bit more clearly. I'm not sure how... to me it looks like I already specified this exactly ;-). Anyway, I've added some examples to the proposal to clarify what I mean. | If a green haskell thread enters a foreign imported function marked | as safe, all other green threads are blocked. Native haskell threads | continue to run in their own OS threads. No, I don't think so. The reason that 'safe' is cheaper than 'threadsafe' is that the current worker OS thread does not need to release the Big Lock it holds on the Haskell heap, thereby allowing other green threads to run. Instead, it holds the lock, executes the call, and returns. At least I think this is the idea, but it's all jolly slippery. I thought that was unsafe? The safe version still does quite a lot (after all, a callbacks are allowed, so is GC). In addition, threadsafe may start a new OS thread in order to keep executing green threads. On the other hand, we might simply leave it unspecified: If people want to know what happens to other threads, they should use threadsafe or unsafe. The exact behaviour of safe seems to be an implementation detail. | Other things I'm not sure about: Presumably if a native thread spawns a thread using forkIO, it gets just a green thread? If it used forkNativeThread it gets a distinct native thread. Better say this. The main program and all haskell threads forked using forkIO are green threads. Threads forked using forkNativeThread :: IO () - IO () are native threads. I thought that was clear enough... I've added a note. Cheers, Wolfgang * Native Threads Proposal, version 2 Some foreign libraries (for example OpenGL) rely on a mechanism called thread-local storage. The meaning of an OpenGL call therefore usually depends on which OS thread it is called from. Therefore, some kind of direct mapping from Haskell threads to OS threads is necessary in order to use the affected foreign libraries. Executing every haskell thread in its own OS thread is not feasible for performance reasons. However, perfomance of native OS threads is not too bad as long as there aren't too many, so I propose that some threads get their own OS threads, and some don't: Every Haskell Thread can be either a green thread or a native thread. For each native thread, there is exactly one OS thread created by the RTS. For a green thread, it is unspecified which OS thread it is executed in. The main program and all haskell threads forked using forkIO are green threads. Threads forked using forkNativeThread :: IO () - IO () are native threads. (Note: The type of the current haskell thread does _not_ matter when forking new threads) Execution of a green thread might move from one OS thread to another at any time. A green thread is never executed in an OS thread that is reserved for a native thread. A native haskell thread and all foreign imported functions that it calls are executed in its associated OS thread. A foreign exported callback that is called from C code executing in that OS thread is executed in the native haskell thread. A foreign exported callback that is called from C code executing in an OS thread that is not associated with a native haskell thread is executed in a new green haskell thread. Only one OS thread can execute Haskell code at any given time. If a native haskell thread enters a foreign imported function that is marked as safe or threadsafe, all other Haskell threads keep running. If the imported function is marked as unsafe, no other threads are executed until the call
Re: Native Threads in the RTS
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 work as intended, [...] We can't currently allow several Haskell threads to really run simultaneosly [e.g. on two separate processors, or preemtively scheduled on a single processor], because they always mutate the same global heap. Currently, GHC switches its green threads only at times when the heap is in a defined state [not truly preemptively]. There seems to be some SMP support in the RTS, I don't know if it ever worked. If anyone wants to fix/finish it, that would be great, but it's not what I'm proposing here. My proposal is only a minimum solution intended to resolve the inherent incompatibility between the threaded RTS and libraries like OpenGL, which require thread-local-state. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Native Threads in the RTS
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 after 5.04. I believe it's time to think about it again, so I'll take the liberty of proposing an extension to the RTS that might solve the problem. I propose adding something like forkNativeThread :: IO () - IO () which forks a new Haskell thread that has its own OS thread to execute in. Note that the fact that only one Haskell thread may execute at a time remains unchanged. Whenever the scheduler determines that a native haskell thread is next, it sends the OS worker thread to sleep and wakes up the OS thread corresponding to the native haskell thread. When the native haskell thread yields again, so does the corresponding OS thread. Foreign calls from normal (non-native) haskell threads should be handled in exactly the same way as they are currently. If a callback is entered and the current OS thread corresponds to a native haskell thread, the callback should be executed in the current OS thread. Other haskell threads continue to run in the worker thread or in their own dedicated OS thread. Programs that don't use forkNativeThread won't be affected by the change. Thread switching to and from native threads will be slower, but not painfully slow. Wrapping an entire HOpenGL program in forkNativeThread should solve the OpenGL/GLUT thread-local-state problem, for example, and who knows what else it is good for. Any comments? Opinions? Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCi on Mac OS X
I know that I must install the readline library seperately; can anybody tell me how to do this? It may be that you have the wrong version of the readline library installed. Probably no version at all... Go to http://www.gnu.org/order/ftp.html choose a mirror, download the sources for version 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 PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FFI C++
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 problem, I think. GHCi can't load static libraries [yet - the ar format shouldn't be too difficult to implement], so everything that's needed from static libraries has to be linked into the ghc binary and probably also listed in Linker.c (who else doesn't like those hard-coded symbol references?) Just my EUR 0.02 :-) Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic linker problems on Jaguar
I get the following with the package for Mac OS X 10.2: [...] I get the impression from Google Groups that rebuilding from the source will fix this. Basically, yes. However, in order to rebuild GHC from source, you need a working copy of GHC :-). Is there a Jaguar binary, 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 arrived, and GHC has stopped working. I've compiled a new GHC binary that runs on 10.2 (but not anymore on 10.1). It is available at: http://www.uni-graz.at/imawww/haskell/JaguarGHC.tar.gz This archive contains just a new GHC binary, the rest of the binary release already has to be already installed. What happened: With Mac OS X 10.1, Apple had included a 'curses' library in it's main 'libSystem.dylib' library. For 10.2, they removed that, and instead added a separate ncurses library (which wasn't included in 10.1.). GHC relies on one of those libraries (via readline), but readline has to be recompiled to use the other library. GHC-compiled programs that don't explicitly link against readline are not affected by this problem. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: trying to compile a cgi library from hugs
[04:14pm 0.11 0.15 0.16 ~/CGI]$ ghc Counter.lhs compilation IS NOT required Counter.o: In function `__stginit_Main': Counter.o(.text+0x16): undefined reference to `__stginit_CGI' [...] Your invocation of the ghc command is telling GHC to just compile Counter.lhs to Counter.o and then create an executable (link) with just Counter.o, not CGI.o. The linker then complains about undefined references to the CGI module. Solution 1: GHC works just like an ordinary UNIX-style C compiler. Specify CGI.o on the command line. Solution 2: use ghc --make Counter.lhs GHC will automatically look for all required modules and compile them if necessary (for GHC versions = 5). Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Summary so far (was: HOpenGL and --enable-threaded-rts)
Simon Marlow wrote: This discussion is getting rather long, so I thought I'd summarise (as much for my benefit as everyone else's). Please let me know if I get anything wrong. I haven't found anything wrong. I'm pretty sure (1) and (2) aren't viable, though. I basically agree. In the presence (3) or (4) [or (5) ;-) ], my own hack looks like - well - a hack. I'll definitely use it as a short term solution for my own toy projects, though. I won't commit any code, but if anyone else needs a short-term solution for HOpenGL, they can ask me. Personally I can't decide whether (3) or (4) is the better solution. I'd say, let's go for (5) - that is, some blend between (3) or (4). (4) almost sounds like (3) could be implemented on top of it. The simplicity of (3) is needed in most cases, the power of something like (4) in some. Some other random thoughts: Does the "OS-thread"-binding have to be a permanent attribute of a thread, or can we also have something like: inOSThread theGLUTThread $ do ... This could be useful for finalizers, or when some thread-sensitive API is used only "some of the time". The problem is that the haskell thread in question could be blocked indefinitely until the OS thread decides to return to Haskell code. I do also like the idea of a forkHeavyIOThread primitive. If something like (4) is implemented, it should still be possible to say that a Haskell thread can run in any OS thread. We never know what new ways of juggling threads (SMP, distributed systems?) will be supported in the future for code that "doesn't mind" being executed in different threads. The current limitations of the RTS (i.e. haskell code can only run in one OS thread at one time) should be a well-documented implementation detail, not a fundamental assumption for the threading primitives. The "don't care" thread group could still support features like the current threaded rts. The documentation will just have to make clear that it can't be predicted which OS thread those haskell threads will be run in, and that some libraries don't like that. CU, Wolfgang
HOpenGL and --enable-threaded-rts
In short, it doesn't work :-( . OpenGL (at least on MacOS) keeps track of the current context on a per-thread basis. The GLUT library sets the current context and calls back to the program. With GHC 5.03 compiled with --enable-threaded-rts, the callback gets executed in a different thread. There is no OpenGL context set up for that thread, so the first OpenGL call crashes. This might also be a problem for other state-based interfaces that use thread-local state. Has anyone already thought about how to solve this problem? I'm thinking about adding hooks to the RTS (in grabCapability, releaseCapability and scheduleThread_) which would be used for setting up the correct thread-local state whenever Haskell execution switches to a different OS thread. Those hook routines would have to be written in C and would be platform-specific most of the time. It's not a nice solution, but it's the only one I can think of at this time. Unless someone comes up with a better idea _quickly_, I'll try it out and then report how ugly it really is... :-) Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: possible readline license problem with ghc and -package util
I'm being provocative, I know. I'm not trying to insult though, just to encourage a creative discussion. Me too. But I've never seen a flame war on any haskell list, so I trust that no one will be insulted if we present our differing opinions in a strong way. We'll just have to take this discussion elsewhere (where?) in case it starts to generate too much noise on this list. This list shouldn't become "glasgow-haskell-politics", after all. --- cut here if you aren't interested in political rants --- :) The question here is, are you (plural) really trying to write Free Software or just giving something away now, which will be closed and hogged later? They probably don't want to restrict people's freedom to create non-free versions. At least that would be my motive. My main problem with the GPL is that if my code is placed under GPL, it is misused as a political tool to enforce a rather extreme vision - a world _without_ proprietary software. While it is a "valid" viewpoint, it's far too extreme for me - I _want_ to write proprietary software. Let's suppose that Microsoft decides that it's time to integrate a proprietary version of GHC into Visual Studio... and suppose that the current main GHC developers will work on the non-free version. Is that a problem? No. It would generate enough additional interest in Haskell to keep up development on the free version. Let's suppose on the other hand, that the main GHC developers decide to release the next version of GHC and its libraries under GPL. That would mean that it cannot be used to create proprietary software, or to create software that doesn't include a political manifesto by RMS. I doubt that there will be enough talented people available to develop a non-GPLed free version of GHC in parallel. It would destroy any hope of widespread use of Haskell in the "real world". Anybody writing truly Free Software should have no problem with it, while any non-free efforts are left out. I feel that Truly Free Software doesn't leave anyone out. I feel that Truly Free Software doesn't force anyone to distribute political manifestoes that he/she doesn't necessarily agree with. I feel that Truly Free Software doesn't impose silly restrictions on static vs dynamic linking (as the LGPL does). I believe that Truly Free Software shouldn't have a license that could be classified as a (admittedly relatively benign) computer virus. I have a problem with the GPL because, while I'm strongly in favor of Free Software, I have no problem with proprietary software. If my code is released under GPL, It becomes a political tool. "GHC doesn't want to be GPL... why? - Would they close it once they smell money in it?". Well, they can't really close it -- the license is a value, not an IORef :-). They can make a closed copy of it. While it would be a pity if those talented people who are currently employed at Microsoft Research would stop contributing code to the free version, it would concern me less than if GHC was put under GPL. And everyone who has seen the GPLed version would then be forbidden to work on a proprietary version of the old non-GPLed source base, because the FSF could sue him for copyright infringement if RMS feels that there is an opportunity to take out a non-free competitor to a free software product. Not my idea of freedom. The current license leaves the most freedom to everyone. That includes things that some of us would not like to happen - but why give up freedom just because some "bad guys" might come along and do something that some (not all) "good guys" don't like? I have that fear, and I'd be really happy if someone could relieve me of it. And while you're at it, you could relieve me of my fear that the official GHC distribution could switch to a GNU license... I'll admit here (for the sake of honesty) that `grep microsoft ghc/README` adds to the effect. It might be scary at first, but it actually has helped improve my opinion of Microsoft a lot over the course of the last year :-). After all, Microsoft already has made a donation to the free software community. I wouldn't have expected that... CU, Wolfgang
RE: problems with FFI including h files
On 2002-06-03 12:46:19 +0100 Simon Marlow [EMAIL PROTECTED] wrote:
We really *should* do this, I know. The problem is that it isn't free
by a long shot: it'll make .hc files significantly larger, and obfuscate
a lot of code.
Anyone have any ideas that don't have such a big impact?
Well, what about including FFI headers _before_ the RTS headers? This should solve the
problem here (parameter names taken by RTS). The problem would of course persist if
someone wants to foreign import an entity called R1 or something like that.
The only disadvantage I can think of is that FFI-included headers that rely on RTS
definitions would have to be changed to manually include the RTS headers they depend
upon - not a common case, IMHO.
By the way, I just noticed that using {-# OPTIONS -#include ... #-} with GHC 5.03
causes the include file to be included _twice_. It's only included once if I specify
it on the command line. No double-including in any case with 5.02.
Regards,
Wolfgang
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
LGPL and static linking of libgmp
I just re-read the GNU Lesser General Public License today - and I discovered that it places some utterly strange (IMHO) restrictions on executables statically linked with LGPLed libraries. Unfortunately, GHC for Windows produces such executables by linking in libgmp statically. Dynamically linking with libgmp would cause no restrictions, but if it is statically linked, the LGPL says that everyone distributing a program compiled with GHC has to 'Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable work that uses the Library, as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.)' I think it would be best to have future distributions of GHC for Windows include libgmp as a DLL. That's what I'll be doing for my future releases of GHC for MacOS X. Cheers, Wolfgang Thaller ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-pkg info
[...] readlink -f `which ghc` and get it from there, but that fails with the latest MacOS X version because it uses small shell scripts in unusual places instead of symlinks. Those shell scripts were installed by a standard make install, so I expect them to be there for any platform - it has nothing to do with MacOS X. Regards, Wolfgang Thaller ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
New Patches Binary for MacOS X
Here are some new patches for GHC for MacOS X. The patches are relative to the CVS HEAD from 9th of April. I also have prepared a binary snapshot [a double-clickable installer package this time], but as last time, I don't have the webspace to upload it myself - I'd be happy to FTP it wherever there might be 25 megs of webspace available for it. What's new in this version: *) foreign export dynamic: createAdjustor now flushes the instruction cache, this should fix some crashes. *) Profiling now works. *) improved mangling: the mangler now _completely_ removes all references to __DISCARD__. *) Much simpler (and perhaps more compatible) code for detecting MacOS X memory layout (-27 +5 lines of code). The following are not really new, but not in CVS: *) Completely new implementation of StgRun (fixes some serious segfaults). *) Added a missing #include config.h to AbsCUtils.lhs - this should fix a bug for all Big-Endian platforms. *) Brutal changes to ClosureFlags.c to make it compile with Apple's strange version of gcc. What's still missing: *) --split-objs *) GHCi Cheers, Wolfgang GHC-MacOSX-150302.patch.gz Description: Mac BinHex archive
GHC for MacOS X: Success!
After weeks of wrestling with Apple's buggy version of gdb, registerized compilation on MacOS X finally works! I've tested it on GHC itself and on my own (H)OpenGL program, VOP, and it seems to work now. I'm attaching my patches. I've had trouble compiling the newest version from CVS. Instead, I've stayed behind by one week (13th of March, to be exact). Bootstrapping from the old ghc 5.00.2 binary version seems to work only up to around 4th of March (Binary IO doesn't work properly with GHC 5.00.2/MacOS X). If I find enough webspace, I'll upload a binary version, too, to save other people the work of recompiling GHC twice in a row. Profiling doesn't work, I just get some segfaults. Is there anything specific that needs to be done to get profiling to work, or should I just go on another long bug-hunt? So, Mac users, please try it out and tell me if it works for your programs, too! Cheers, Wolfgang P.S. to Simon Marlow: You were right, those segfaults _are_ fun! Who would have thought that the PowerPC has so many registers that a clobbered callee-save only shows up _seconds_ later? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC for MacOS X: Success!
I'm attaching my patches. Well, I'm attaching them _now_. Cheers, Wolfgang %ghc-5.03-macosx.patch.gz Description: application/applefile ghc-5.03-macosx.patch.gz Description: Binary data
MacOS X GHC Status
Some programs work, including green-card and some HOpenGL programs. GHC, compiled with my registerized version, crashes. At some point, there is pointer on the Stg Stack that points into data space. However, it doesn't point to a closure. In points to a place just after the last data symbol in of one GHC module, and before the next (there's quite some stuff between those two modules, and I have no idea what the linker puts there). The word at that position is definitely not a valid info pointer, it points about 300 megabytes above the heap (into unmapped space). MacOS X doesn't yet support watchpoints, so I still have no idea who put this strange pointer onto the stack. Under what conditions are pointers into data space put on the stack? Any ideas how I could go about debugging this? How can I possibly ever find out what code is putting this nonsense value on the stack? For now, I'll try to find some smaller programs that crash, too. Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Weird Activation Records (RTS wizards, please help!)
I can't seem to get the Garbage Collector to work properly on MacOS X. When a program triggers the Garbage Collector, it aborts with the following message: a.out: fatal error: scavenge_stack: weird activation record found on stack: 0 The same error happens both in unregistered mode and using my half-finished powerpc mangler (BTW, Hello World already works in registered mode!). In unregistered mode, I have also observed different numbers instead of zero in the error message. I'm positive that the problem is in the basic day-to-day workings of the STG machine. main = print $ length $ [1..500] -- aborts the first time GC is invoked It has nothing to do with the libs, I can replace length and the list generation with my own functions and print with a foreign import, and the result stays the same: crash on first GC, fine otherwise. Now I'm stuck. Are there any reasonably up-to-date docs on what a normal activation record should look like? The file GC.c is not exactly the kind of code that I understand the first time that I read it... One of my random guesses is that there is a problem with struct alignment, which has more padding on PPC than on Intel --- on the other hand, GHC is supposed to work on Sparc, and that doesn't use Intel alignment either, AFAIK (does the HEAD currently work on Sparc? The ghc-5.03 snapshot on the download page seems to have only intel versions). Can anyone give me any hints? Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC on MacOS X
I realize that you would rather clean things up first, but could I talk you into passing on your patches? We could use a build on MacOS X today (and I literally mean today) It's not easy when I say unclean, I _mean_ unclean However, here it is I even added a new file in a place where it definitely doesn't belong - the attached archive contains a cvs diff plus the extra file, sigaddsetwtth (wtt are my initials), which belongs in libraries/base/ One more thing: the build system passed --split-objs to the compiler for one or two library modules (which doesn't work for unregisterd builds) Not knowing much about the build system, I simply copied the failed command, removed the --split-objs and ran it by hand Then just ran make again, and everthing went fine Interestingly enough, [] checked in the changes today Perhaps the problems that you noticed with your own modules are related to the problems that Sigbjorn fixed Thanks for the hint, I'll check that out (pun intended) Wolfgang -- GMX - Die Kommunikationsplattform im Internet http://wwwgmxnet -- GMX - Die Kommunikationsplattform im Internet http://wwwgmxnet -- GMX - Die Kommunikationsplattform im Internet http://wwwgmxnet ghc-macosx.tar.gz Description: application/gzip-compressed
