- Glasgow-haskell-users

RE: ghc/cygwin filename resolution issue.
by Simon Peyton-Jones 03 Feb '03

03 Feb '03

Alex As Simon M says, if you (or anyone else) felt able to write up a standalone summary of what the problem is, and what the solution is, I'd love to add it to the GHC FAQ or documentation somewhere. In my experience, simply explaining the problem clearly is quite tricky. (E.g. the cygwin vs mingw issues, described in the Building Guide, took me ages to understand well enough to write down.) Simon | -----Original Message----- | From: Alex Ferguson [mailto:abf@cs.ucc.ie] | Sent: 29 January 2003 16:29 | To: glasgow-haskell-users(a)haskell.org | Subject: Re: ghc/cygwin filename resolution issue. | | | | Thanks to all for the replies; Hal's resolution rings a | bell, now that I think about it, from Ye Olde Days when | cygwin was a ghc pre-req -- just didn't think of it when | installing more recently on a new machine. (Install in | haste, repent at leisure.) Claus' suggestion about relative | paths does the ticket, though: didn't occur to me as the | paths were being generated by a configure script, but yes, it | was possible to override them, which works as advertised. | | Cheers, | Alex. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

4 3

GHC and C++
by Simon Peyton-Jones 03 Feb '03

03 Feb '03

Daan, Kevin, (and Mike, Sarah?) You two/three seem to be the de-facto experts when it comes to building DLLs with GHC and linking them to C++ DLLs. Would either of you like to write up some stand-alone notes that explain how to do it, and what the pitfalls are? You can make suggestions for improving GHC too! What otherwise happens is that everyone has to reinvent the wheel. And, to be honest, we're not well up on this at GHC home base, so you could do a far better job than we could. The important thing is to explain enough context that someone does not have to be a total Win 32 expert to understand what's going on. Claus's recent message explaining about Cygwin paths was an excellent example of how to do it. It'd be a real service. Simon | -----Original Message----- | From: Daan Leijen [mailto:daanleijen@xs4all.nl] | Sent: 02 February 2003 22:34 | To: Nick Name; gui(a)haskell.org | Subject: Re: [GUI] ByeDemo | | > > I have been thinkering with the wxWindows library | > > and made a small Haskell binding to it that just supports this | > > example. It was an interesting exercise since the wxWindows library | > > is a large object-oriented C++ library. (but very portable, well | > > supported, efficient and with lots of super widgets, like an openGL | > > canvas and a HTML renderer) | > | > It is really interesting. How did you bind the library? Could you make a | > tarball of the binding, the example and a makefile? It could be used as | > an "Haskell->C++" tutorial. | | (warning: rather detailed and long answer...) | | I have only done it for windows yet, both with mingw32 and visual C++. | Funny thing: the final (stripped) DLL with mingw32 was 2.8mb, while the | visual C++ DLL (with the same functionality) was just 640kb :-). | | In the end, I couldn't link it directly with a haskell application due to the | difference between the C++ and plain C runtimes, so I have made dynamic | link library (.dll) of the C++ code. This code exposes a plain C interface (with "extern | "C""). | This interface is basically a flat C view on the object oriented wxWindows library. | | This DLL is accessed with foreign imports from Haskell. Call backs are dynamically | created using dynamic exports ("wrapper"). Actually, the hardest part was to | make sure that the resource files (.rc) were properly linked in the DLL, as we don't | want to deal with those from Haskell. | | I don't know yet if this approach also works for unix's (.so files?) or MacOSX, | but there probably is a way to do this. In the end, it is good enough if there is | some way of wrapping the C++ code into a C library. Maybe someone on this list | can tell me more about how this could work on unix like platforms??? | | The part that is most challenging, and which I am still working on, is trying to fit | the event model of wxWindows into a reasonable model for Haskell (or other | languages for that matter). Somehow, I need to create "universal" widget objects | that are programmable from outside (i.e. Haskell) but normally, one derives | application | specific objects for each widget in wxWindows. There are mechanisms for more | dynamic | applications (like I want) but I am still trying to figure out the right way to do it. | | I think this is basically a universal problem when trying to interface to foreign object | oriented | (or any other paradigm for that matter) with a functional language. It is not just the | marshalling | and calling conventions, but the programming model makes a huge difference. Years | ago, when | designing H/Direct we automated the marshalling process, but it seems that that is | just a small | part of the problem. Trying to fit into an entirely different programming model is very | hard. For | an extreme example, I think that there is no reasonable way of interfacing to the Java | Swing model. | | Fortunately, it seems that the wxWindows library is much more flexible, and up till | now, I haven't | encountered any hard problems. Maybe this is actually the right way to go for a | Haskell GUI library | -- let others do the hard work of maintaining a rich,portable gui library, and we just | have to do | the hard work of interfacing to c++ once. | | All the best, | Daan. | | | > Vincenzo | > | > -- | > First they ignore you, then they laugh at you, | > then they fight you, then you win. | > [Gandhi] | > | > _______________________________________________ | > GUI mailing list | > GUI(a)haskell.org | > http://www.haskell.org/mailman/listinfo/gui | > | > | | | _______________________________________________ | GUI mailing list | GUI(a)haskell.org | http://www.haskell.org/mailman/listinfo/gui

2 1

RE: ghc/cygwin filename resolution issue.
by Simon Peyton-Jones 03 Feb '03

03 Feb '03

Thank you Claus! I've incorporated your section exactly as written. It'll be in the next release of GHC. Simon | -----Original Message----- | From: Claus Reinke [mailto:claus.reinke@talk21.com] | Sent: 31 January 2003 00:40 | To: glasgow-haskell-users(a)haskell.org | Subject: Re: ghc/cygwin filename resolution issue. | | >As Simon M says, if you (or anyone else) felt able to write up a | >standalone summary of what the problem is, and what the solution is, I'd love | >to add it to the GHC FAQ or documentation somewhere. | | Following the worse-is-better approach, here's some text for others | to fiddle with (I'd recommend to keep the result in the GHC FAQ | proper, possibly with a link from the building guide, if necessary). | I've omitted the build-ghc-with-cygwin option, lest readers in search | or solutions rush of to cause themselves even more problems;-). | | Cheers, | Claus | | Using GHC (and other GHC-compiled executables )with cygwin | ================================================ | | [background] | The cygwin tools aim to provide a unix-style API on top of the windows | libraries, to facilitate ports of unix software to windows. To this end, they | introduce a unix-style directory hierarchy under some root directory | (typically / is C:\cygwin\). Moreover, everything built against the cygwin | API (including the cygwin tools and programs compiled with cygwin's | ghc) will see / as the root of their file system, happily pretending to work | in a typical unix environment, and finding things like /bin and /usr/include | without ever explicitly bothering with their actual location on the windows | system (probably C:\cygwin\bin and C:\cygwin\usr\include). | | [the problem] | GHC, by default, no longer depends on cygwin, but is a native windows | program. It is built using mingw, and it uses mingw's ghc while compiling | your Haskell sources (even if you call it from cygwin's bash), but what | matters here is that - just like any other normal windows program - neither | GHC nor the executables it produces are aware of cygwin's pretended | unix hierarchy. GHC will happily accept either '/' or '\' as path separators, | but it won't know where to find /home/joe/Main.hs or /bin/bash or the | like. This causes all kinds of fun when GHC is used from within cygwin's | bash, or in make-sessions running under cygwin. | | [things to do] | 0) don't panic! | | 1) don't use absolute paths in make, configure & co if there is any chance | that those might be passed to GHC (or to GHC-compiled programs). Relative | paths are fine because cygwin tools are happy with them and GHC accepts | '/' as path-separator. And relative paths don't depend on where cygwin's | root directory is located, or on which partition or network drive your source | tree happens to reside, as long as you 'cd' there first. | | 2) if you have to use absolute paths (beware of the innocent-looking | ROOT=`pwd` in makefile hierarchies or configure scripts), cygwin provides | a tool called 'cygpath' that can convert cygwin's unix-style paths to their | actual windows-style counterparts. Many cygwin tools actually accept | absolute windows-style paths (remember, though, that you either need | to escape '\' or convert '\' to '/'), so you should be fine just using those | everywhere. If you need to use tools that do some kind of path-mangling | that depends on unix-style paths (one fun example is trying to interpret ':' | as a separator in path lists..), you can still try to convert paths using | cygpath just before they are passed to GHC&friends. | | 3) if you don't have cygpath, you probably don't have cygwin and hence | no problems with it.. unless you want to write one build process for several | platforms. Again, relative paths are your friend, but if you have to use | absolute paths, and don't want to use different tools on different platforms, | you can simply write a short Haskell program to print the current directory | (thanks to George Russell for this idea): compiled with GHC, this will give | you the view of the file system that GHC depends on (which will differ | depending on whether GHC is compiled with cygwin's gcc or mingw's | gcc or on a real unix system..) - that little program can also deal with | escaping '\' in paths. Apart from the banner and the startup time, | something like this would also do: | | $ echo "Directory.getCurrentDirectory >>= putStrLn . init . tail . show " | ghci | | 4) panic now. | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: GHC doesn't compile under cygwin
by Simon Peyton-Jones 03 Feb '03

03 Feb '03

Did you carefully follow the steps described in the Building Guide? http://haskell.cs.yale.edu/ghc/docs/latest/html/building/winbuild.html Simon | -----Original Message----- | From: Chris Clearwater [mailto:chris@sharkzone.com] | Sent: 28 January 2003 23:36 | To: glasgow-haskell-users(a)haskell.org | Subject: GHC doesn't compile under cygwin | | Hi, today I installed cygwin and downloaded the GHC source, however | during compilation I get the errors: | | test: 504: unknown operand | test: 500: unknown operand | test: 504: unknown operand | | In addition,I get many Error [127] (ignored) and Error [1] (ignored) | before finally quiting with the unknown operand errors. Attached is the | configure output, confiure log and make output. | | Thanks in advance for any help.

1 0

Modifying GHC to accept external Styx code
by Mark Alexander Wotton 03 Feb '03

03 Feb '03

I want to use GHC as a backend for my experimental compiler. I'm trying to modify it to accept styx code from my compiler, and I'm having some trouble working out where I need to make changes. In truth, GHC is more haskell code than I've ever seen before in one place, and I'm a bit lost: can anyone suggest which modules I should become familiar with and which I should leave alone? mrak -- please don't be too gentle with me -- The Minutemen

1 0

Re: Calling ghc dll's with MSVC++ code
by Kevin S. Millikin 31 Jan '03

31 Jan '03

Hmmm, I just now came across this: "I'm not confident that creating Haskell DLLs is working at the moment. Has anyone else done it?" I have. Or rather, I haven't. The example in Section 11.4 of the User's Guide doesn't work. The call to "startupHaskell()" hangs forever (or as long as I'm willing to wait). It works fine when the exact same call to startupHaskell is linked statically. "Trouble is, there isn't yet a critical mass of DLL users to be sure that it works and stays working. Which is a bit of a chicken and egg problem. Windows programmers unite!" Is two a critical mass? -- Kevin S. Millikin Architecture Technology Corporation Research Scientist Specialists in Computer Architecture (952)829-5864 x. 162 http://www.atcorp.com

2 3

Re: Bug in GHC 5.04.2 for Mac OS X
by Ashley Yakeley 31 Jan '03

31 Jan '03

At 2003-01-30 20:27, I wrote: >GPR13 is indeed considered nonvolatile, so it looks like the JVM is >correct and the function made by createAdjustor is wrong. See enclosed example. -- Ashley Yakeley, Seattle WA

2 1

Bug in GHC 5.04.2 for Mac OS X
by Ashley Yakeley 31 Jan '03

31 Jan '03

At 2002-12-08 02:52, Wolfgang Thaller wrote: >A Mac OS X installer package is now available at >http://www.uni-graz.at/imawww/haskell/GHC.5.04.2.dmg I seem to be having trouble with 'foreign import ccall "wrapper"' functions. It was crashing in combination with the Java VM: examination with gdb revealed that the function created with 'foreign import ccall "wrapper"' was changing register r13, and it looks like the JVM code that called it was expecting r13 to be preserved. This appears to be a bug in GHC for Mac OS X. $ ghc --version The Glorious Glasgow Haskell Compilation System, version 5.04.2 $ uname -a Darwin Ashley-Yakeleys-Computer.local. 6.3 Darwin Kernel Version 6.3: Sat Dec 14 03:11:25 PST 2002; root:xnu/xnu-344.23.obj~4/RELEASE_PPC Power Macintosh powerpc -- Ashley Yakeley, Seattle WA

1 1

RE: Profiling trouble
by Simon Marlow 30 Jan '03

30 Jan '03

> something interesting turned up again. Setting cut=8 in > Show2.hs and running it with ./show +RTS -h -i0.01 gives > > show: fatal error: main thread has been GC'd > > It may be silly, since 0.01 < 1/50, but this error message > isn't too helpful. Btw, +RTS -? says: > > -i<msec> Time between heap samples (msec, default: 100) > > which is wrong (time is given in seconds really). Both of these bugs were fixed in 5.04.2. > One more question: is there a way not to truncate the call > stacks? Ie in the hp file I see lines like > > (144)showData2/showData/ma... 12 > > and I'd like to see showData2/showData/main or so. I'm afraid there's no way at the moment, but I'll look into adding a flag. The problem is that the longer the stacks get, the less room there is for the graph - hp2ps tends to squeeze the graph up to make room for the labels, which is why we truncate them. Your other problem (misattribution of costs in the profile) seems to be related to the use of overloaded functions, and the compiler isn't translating the definition of getStates properly. I haven't found a fix yet. Cheers, Simon

2 1

RE: Profiling trouble
by Simon Marlow 30 Jan '03

30 Jan '03

> I'm also having some fun with profiling... > > First: > The GHC manual might want to mention that running ghc --show-iface > on an interface file won't work if it was compiled with -prof. > You get: "mismatched interface file versions: expected 5042, > found 5042p" > Compiling sans -prof works. This bug has been fixed. > Second: > Heap profiling falls over (seg fault) in some cases unless I > compile with -O2. This is a bug - could you provide us with the source and instructions to reproduce? > Third: > How do I tell if my functions are strict or not? > The manual says: > "Look for your function in the interface file, then for the > third field in > the pragma; it should say __S <string>. The <string> gives > the strictness of > the function's arguments. L is lazy (bad), S and E are strict > (good), P is > primitive (good), U(...) is strict and unpackable (very > good), and A is > absent (very good)." To see the pragmas, you need to compile the module with -O. You can view the interface with --show-iface. For example, here's 'not' from the Prelude: 1 not :: Bool -> Bool {-## __A 1 __C __S S __U (\ ds :: Bool -> case ds of wild {False -> $wTrue; True -> $wFalse;}) ##-}; You can see that strictness pragma (following __S) is "S", which means the function is strict in its single argument. Cheers, Simon

1 0