January 2005 - Glasgow-haskell-users

Using Haskell with Java
by Dmitri Pissarenko 08 Jan '05

08 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 ----- Ende der weitergeleiteten Nachricht -----

5 5

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

08 Jan '05

Feature Requests item #1097471, was opened at 2005-01-06 21:55 Message generated for change (Comment added) made by ggd 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: Gour (ggd) Date: 2005-01-08 11:34 Message: Logged In: YES user_id=728695 Hi! Just to add it's important issue for me since it affects the general gui-availability for Haskell language on amd64 platform since gtk2hs bindings also depend on it. Pls. raise this priority a little bit - amd64 is really a very 'natural' platform for Haskell :-) Sincerely, Gour ---------------------------------------------------------------------- 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

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