- Glasgow-haskell-users

Using Haskell with Java
by web16p2＠p15142389.pureserver.info 07 Jan '05

07 Jan '05

Hello! I have a Java application, which has a lot of GUI and one complex algorithm. I spent many months writing and debugging that algorithm, but it still has a lot of bugs. At the moment, I am thinking about implementing that algorithm in Haskell, while leaving the GUI in Java. I would like to know whether it is possible to write algorithmic (let's call them back-end) parts of a system in Haskell and user interface in Java? Can Haskell and Java parts of a system co-operate? Will such a hybrid system run on Windows and Linux? Are there any tutorials about this? Has someone already tried it? Thanks in advance Dmitri Pissarenko

1 0

[ ghc-Feature Requests-1097471 ] amd64: adjustor creation not supported
by SourceForge.net 06 Jan '05

06 Jan '05

Feature Requests item #1097471, was opened at 2005-01-06 21:55 Message generated for change (Comment added) made by wthaller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1097471&group_… Category: None Group: None Status: Open >Priority: 3 Submitted By: Thomas Pasch (aanno) Assigned to: Nobody/Anonymous (nobody) Summary: amd64: adjustor creation not supported Initial Comment: Hello, when trying to use wxhaskell on ghc-6.2.2 on an amd64 (unregistered gentoo build) the following happend: $ ./a.out a.out: internal error: adjustor creation not supported on this platform Please report this as a bug to glasgow-haskell-bugs(a)haskell.org, or http://www.sourceforge.net/projects/ghc/ I'm not sure if this is a bug because amd64 is not officially supported. ---------------------------------------------------------------------- >Comment By: Wolfgang Thaller (wthaller) Date: 2005-01-06 22:48 Message: Logged In: YES user_id=566359 Yes, this is just a "missing feature". A small piece of platform specific code (<50 lines) is required to get foreign import "wrapper" declarations to work, and wxhaskell uses them a lot. A volunteer who wants to fix this would need enough knowledge about assembly language in general to really understand a calling convention (literature on amd64's particular calling convention is available somewhere). Most of the amd64-specific details can be picked up on the job. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1097471&group_…

1 0

RE: ghc for hp-ux 11.11...
by amyhr＠spymac.com 06 Jan '05

06 Jan '05

Actually, I had submitted the feature request before joining the list. I did follow Sven's instructions, with similer errors, and sent the requested files to the list before the holidays, did anyone get them? I haven't seend them come through myself... On Tue Jan 4 10:08 , 'Simon Marlow' <simonmar(a)microsoft.com> sent: >On 21 December 2004 17:38, Sven Panne wrote: > >> amyhr(a)spymac.com wrote: >>> Okay, I've tried to follow the directions, and ran into a couple >>> minor issues I was able to work through, but I got stuck at the "cd >>> H/libraries && make boot && make" stage. The host system is redhat >>> enterprise linux 3, the target is hp-ux >>> 11.11, the output is below: [...] >> >> It looks like you try to get GHC 6.2.2 up and running. Could you try >> the GHC from CVS HEAD instead, please? The configuration stuff has >> changed quite a bit, and I'm reluctant to work on the old STABLE >> branch. Could you send a log of the configuration/building plus all >> config.log and config.status files, please? In ancient times, I made >> GHC run on HP-UX 9, but I guess that things suffer from bit rot... > >Looks like he has given up and submitted a feature request :-) But >anyway, the HEAD is probably not in a good state for bootstrapping right >now (unless anyone has evidence to the contrary?) I plan to make sure >bootstrapping works before we release 6.4. > >Cheers, > Simon

1 0

RE: 6.4 News
by Simon Peyton-Jones 06 Jan '05

06 Jan '05

| I was curious whether type assosiated classes will make it into 6.4? I | think it would be a very useful thing. | | http://research.microsoft.com/Users/simonpj/papers/assoc-types/index.htm Definitely not, I'm afraid. Implementation isn't started. It's far from straightforward, which is why I've been putting it off. I keep hoping we'll think of a simpler story! Simon

1 0

6.4 News
by Simon Marlow 06 Jan '05

06 Jan '05

Greetings GHC users! As you may be aware, we're heading for a 6.4 release in the near future, with plenty of shiny new features. The aim is to get it out in a month or so, including a couple of weeks of release candidate testing. So we can all keep track of what still needs to be done, I've put up a wiki page to track the ToDo list. This page also has a brief rundown of the new stuff in 6.4: http://www.haskell.org/hawiki/GHC_206_2e4 Please take a look, and if your favourite bug isn't mentioned then let us know. Bugs in sourceforge have been prioritised, and we plan to look at anything with prio >=5 before the release. Cheers, Simon

2 1

RE: Loading package ghc within GHCi
by Simon Marlow 06 Jan '05

06 Jan '05

On 05 January 2005 22:20, Wolfgang Thaller wrote: >> 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. I'm not a big fan of the overriding semantics either. The problem with RegisterOutOfHeapCallback() is that you have to actually provide some code that gets run to register the callback, which means you have to provide your own main() (and therefore override the RTS-supplied main() :-). Can we use weak symbols for this? Are weak symbols widely-supported enough? Cheers, Simon

1 0

RE: Loading package ghc within GHCi
by Simon Marlow 05 Jan '05

05 Jan '05

On 20 December 2004 04:29, Sean Seefried wrote: > GHCi runtime linker: fatal error: I found a duplicate definition for > symbol > _OutOfHeapHook > whilst processing object file > /usr/local/lib/ghc-6.3/HSghc.o > This could be caused by: > * Loading two different object files which export the same symbol > * Specifying the same object file twice on the GHCi command line > * An incorrect `package.conf' entry, causing some object to be > loaded twice. > GHCi cannot safely continue in this situation. Exiting now. Sorry. > > I see that these symbol is exported by HSrts.o and HSghc.o so it makes > sense that this error should occur. But since the symbol in HSghc.o > originally comes from ghc/parser/hschooks.c and its purpose is to > override the hooks in the RTS it seems strange that this should be an > error. > Is there any way that I can suppress this error through use of flags > in the package.conf for package ghc? 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. We can't really support this in GHC's dynamic linker, because we're linking in objects that are already partially linked. I guess we should probabaly just work around it for now - you could just remove the OutOfHeapHook() in package ghc, for example. > I've been told that their may be other good reasons why package ghc > doesn't load into GHCi by Don Stewart. What are these reasons > exactly? My final question is, if GHCi can't load package ghc just > yet then what are the major issues that would need to be solved > before it could? Problems arise when the are RTS resources used by both the running GHC's. For example, both GHC's will try to hook the signal handler for ^C. If the package ghc tries to do dynamic linking, then lots of things will go wrong (ie. don't try to compile any template haskell, and definitely don't try to run GHCi inside GHCi). I'm sure there are more things on this list... Cheers, Simon

2 1

RE: internal error: weird activation record found on stack: 9
by Simon Marlow 05 Jan '05

05 Jan '05

On 03 January 2005 15:19, Peter Simons wrote: > I wrote: > > > Simon Marlow writes: > > >> Please compile the program with -debug, then open it > >> with gdb. > > > Unfortunately, -debug seems to conflict with -threaded: > > > ghc --make -threaded -debug -O -Wall [...] -o postmaster > tutorial.lhs [...] > Chasing modules from: tutorial.lhs > > [...] > > Compiling Main ( tutorial.lhs, .objs/Main.o ) > > Linking ... > > /usr/lib/gcc-lib/i686-pc-linux-gnu/bin/ld: cannot find > -lHSrts_thr_debug > collect2: ld returned 1 exit status > > It has been a while since this problem came up, and I was > wondering what to do now, because the software keeps > crashing (or freezing) every few days. > > Any advice, anyone? If your program still works without -threaded, then that's an option. Otherwise, you'll need to compile up a local copy of the debug/threaded RTS so you can use -debug and -threaded together. The way to do that is to add "GhcRtsWays += thr_debug" to mk/build.mk in a GHC tree, and build as normal. You can then either use this GHC to build your app, or just use the thr_debug version of the RTS with your existing GHC installation by giving the appropriate -L option when linking (it better be the same GHC version, of course). Cheers, Simon

2 1

RE: [Haskell-cafe] GHC for .NET?
by Simon Peyton-Jones 05 Jan '05

05 Jan '05

| Understandably, however, there is real resistance in language communities like Haskell's to changing | or even extending a language for the sake of interoperability and API access: instead people work | incredibly hard to encode interoperability via existing mechanisms. In the end, whoever picks up the | burden of doing Haskell.NET will face the same unenviable choice that every other .NET language | design group has faced: | | (a) do you modify and/or extend the language to make "the nicest possible Haskell-like language in | the context of .NET" | | or (b) do you implement Haskell faithfully without language extensions, but where using the .NET | libraries is in practice somewhat arcane and unpleasant, probably sufficiently so that you'll be unable | to attract .NET-savvy programmers to your language. | | Personally I think language designs in space (a) are more interesting, since perfectly good native | implementations of Haskell are already available on most platforms. I also think you learn a lot more | by trying to create something new, and you give yourself the maximum possible long-term chance of | rivalling other .NET languages (which I think should be an important goal for a Haskell.NET) I agree with all of that, including leaning towards (a) -- and it also helps to explain why we have moved so slowly on the GHC.net front. GHC is a big system already, and specifically tries to be multi-platform. Making substantial, but platform-specific, language changes is arguably the Right Thing (as Don says), but not so attractive for GHC. Simon

1 0

RE: [Haskell-cafe] GHC for .NET?
by Don Syme 05 Jan '05

05 Jan '05

> There is some good groundwork already done... I'd add that during my first effort to do GHC.NET I modified GHC to optionally preserve full type information through to the backend, including type applications. This is necessary if you're going to produce verifiable code. > The trouble here is that Haskell's type system is more expressive > than the CLR's in some ways, notably the use of higher-kinded > type variables. The problem with higher-kinded type variables is quite significant, and were one of the reasons I stopped work on ghc.net. It is an open question as to whether you can compile type parameters to .NET generics and higher-kinded parameters by some other means (i.e. to casts etc.) - I believe it is possible by passing term parameters in place of higher-kinded type variables, where the term parameters are called whenever the type function is applied. However when I tried to implement this scheme it got too complex, especially given how few uses of higher-kinded polymorphism there are in practice. It would probably be better to initially simply inline all higher-kinded code at the callsites. Cheers Don -----Original Message----- From: Simon Peyton-Jones Sent: 04 January 2005 12:18 To: Don Syme; John Goerzen; haskell-cafe(a)haskell.org Cc: GHC users Subject: RE: [Haskell-cafe] GHC for .NET? | "The GHC compiler for .NET is currently under development at | Microsoft Research, Cambridge". | | Hmm. That location sounds familiar :-) Does anyone know if this is | actually going to happen? Or if there's any code anywhere, however | experimental, to try? It'd make a lot of sense to give GHC a .NET back end, and it's a question that comes up regularly. The reason that we haven't done it here, at GHC HQ, is because it's a more substantial undertaking than might at first appear (see below). Furthermore, it'd permanently add a complete new back-end platform for us to maintain. Given our rather limited development effort (= Simon and me), we have so far not bitten the bullet, and we have no immediate plans to do so. It'd be a good, well-defined project for someone else to tackle, and there is some good groundwork already done: * Sigbjorn Finne did a simple interop implementation that allows a Haskell program to be compiled to native code (as now) but to call .NET programs via a variant of the FFI. I don't think this work is in active use, and I'd be surprised if it worked out of the box, but it could probably be revived with modest effort * Andre Santos and his colleagues at UFPE in Brazil are working on a .NET back end, that generates CLR IL, though I don't know where they are up to. * GHC.Net would be extra attractive if there was a Visual Studio integration for GHC. Substantial progress on this has been made in 2004 by Simon Marlow, Krasimir Angelov, and Andre Santos and colleagues. There may be others that I don't know of. If anyone wants to join in this effort, do contact the above folk. And please keep us informed! Simon Here's a summary of why it's a non-trivial thing to do: - The first thing is to generate native CLR Intermediate Language (IL). That's not really hard. Requires thinking about representations for thunks and functions, and it may not be particularly efficient, but it can surely be done. An open question is about whether to generate verifiable IL or not. The trouble here is that Haskell's type system is more expressive than the CLR's in some ways, notably the use of higher-kinded type variables. So, to generate verifiable IL one is bound to need some run-time casts, and it's not clear how to minimise these. At first blush this is *all* you need do. But it isn't! - Next, you need to think about how to inter-operate with .NET libraries. You don't really want to write "foreign import..." for each and every import. You'd like GHC to read the CLR meta-data directly. But there are lots of tricky issues here; see the paper that Mark Shields and I wrote about "Object-oriented style overloading for Haskell". - Now you need to figure out how to implement GHC's primitive operations: the I/O monad arbitrary precision arithmetic concurrency exceptions finalisers stable pointers software transactional memory Not all of these are necessary, of course, but many are used in the libraries. The CLR supports many of them (e.g. concurrency) but with a very different cost model. - Last, you have to figure out what to do for the libraries. GHC has a pretty large library, and you either have to implement the primops on which the library is based (see previous point), or re-implement it. For example, GHC's implementation of I/O uses mutable state, concurrency, and more besides. For each module, you need to decide either to re-implement it using .NET primitives, or to implement the stuff the module is based on. These challenges are mostly broad rather than deep. But to get a production quality implementation that runs a substantial majority of Haskell programs "out of the box" requires a decent stab at all of them.

1 0