[ ghc-Feature Requests-1349036 ] Compiling multiple executables with -make
Feature Requests item #1349036, was opened at 2005-11-05 15:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1349036&group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: Mads Lindstrøm (supermule) Assigned to: Nobody/Anonymous (nobody) Summary: Compiling multiple executables with -make Initial Comment: Hi I am very happy with the -make option. However, I think it could be improved even further. I would like ghc to be able to compile multiple executables with one invocation of ghc, using the -make option. Compiling multiple executables in one invokation could safe a lot of compile-time, when the executables shares most of their source files. I believe the time would be saved, as it would remove the need to check all source files for possible recompilation for each executable. Furthermore, we would also only need to build the dependency graph once. /Mads Lindstrøm -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1349036&group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1340203 ] Debug.Trace.trace should work on Show
Feature Requests item #1340203, was opened at 2005-10-28 04:38 Message generated for change (Settings changed) made by jch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1340203&group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open >Priority: 2 Submitted By: Juliusz Chroboczek (jch) Assigned to: Nobody/Anonymous (nobody) Summary: Debug.Trace.trace should work on Show Initial Comment: Debug.Trace.trace has type trace :: String -> a -> a which forces me to insert calls to show. Could it be generalised to trace :: Show a => a -> b -> b Thanks, Juliusz Chroboczek -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1340203&group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1340203 ] Debug.Trace.trace should work on Show
Feature Requests item #1340203, was opened at 2005-10-28 04:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1340203&group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: Juliusz Chroboczek (jch) Assigned to: Nobody/Anonymous (nobody) Summary: Debug.Trace.trace should work on Show Initial Comment: Debug.Trace.trace has type trace :: String -> a -> a which forces me to insert calls to show. Could it be generalised to trace :: Show a => a -> b -> b Thanks, Juliusz Chroboczek -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1340203&group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1333482 ] Supertyping of classes
Feature Requests item #1333482, was opened at 2005-10-20 11:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1333482&group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Supertyping of classes Initial Comment: see "Supertyping Suggestion for Haskell" [url]http://repetae.net/john/recent/out/supertyping.html[/url] example: [code] class Num a <= Group a where (+) :: a -> a -> a negate :: a -> a [/code] apart from multiple inheritance, it could work like this: [code] import Prelude hiding ((+),negate) import qualified Prelude ((+),negate) class Group a where (+) :: a -> a -> a negate :: a -> a instance Num a => Group a where (+) = (Prelude.+) negate = Prelude.negate [/code] - coeus_at_gmx_de -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1333482&group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1157515 ] GHCi support on x86_64
Feature Requests item #1157515, was opened at 2005-03-06 00:25 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1157515&group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: GHCi support on x86_64 Initial Comment: I just installed the 64bit version of ghc on an athlon 64. ghc does work and produces correct 64bit code, but ghci fails to start. Here is the complete output: [EMAIL PROTECTED] ~]$ ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.2.2, for Haskell 98. / /_\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... /usr/lib64/ghc-6.2.2/HSbase.o: unknown architecture ghc-6.2.2: panic! (the `impossible' happened, GHC version 6.2.2): loadObj: failed Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org, or http://sourceforge.net/projects/ghc/. I'm using Fedora Core 3 and installed ghc using yum. If you have any questions, contact me: philipp.classen[AT]gmx.net Thanks, Philipp -- >Comment By: Simon Marlow (simonmar) Date: 2005-09-23 10:28 Message: Logged In: YES user_id=48280 Basic GHCi support is available in 6.4.1. However, FFI support in GHCi is missing, and there are problems with accessing data in a shared library from Haskell code. -- Comment By: Simon Marlow (simonmar) Date: 2005-03-07 12:03 Message: Logged In: YES user_id=48280 Changed to a feature request; GHCi support is simply not present on x86_64 yet. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1157515&group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1256514 ] Declare large amounts of constant data
Feature Requests item #1256514, was opened at 2005-08-11 11:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1256514&group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: Antti-Juhani Kaijanaho (ajk) Assigned to: Nobody/Anonymous (nobody) Summary: Declare large amounts of constant data Initial Comment: Simon Marlow wrote in Bug#635718: "It is true that GHC doesn't have a good way to declare large amounts of constant data. This is a shortcoming, but not a bug (please by all means submit a feature request)." Submitting as requested:) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1256514&group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1239439 ] O'Haskell
Feature Requests item #1239439, was opened at 2005-07-16 14:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1239439&group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: Monique Louise de Barros Montei (mlbm) Assigned to: Nobody/Anonymous (nobody) Summary: O'Haskell Initial Comment: Is there any project for extending GHC with support to O'Haskell or any other object-oriented Haskell extesion? That could be very useful for improving Haskell interoperability with OO languages. Thanks in advance, Monique Monteiro -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1239439&group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1212959 ] Reading source files in encodings other than Latin-1
Feature Requests item #1212959, was opened at 2005-06-01 18:53 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1212959&group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: None >Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) >Summary: Reading source files in encodings other than Latin-1 Initial Comment: For GHC 6.4 on SuSE Linux 9.2 (installed from the GHC RPM). When including SOME non-ascii characters in character or string literals, in the source code, I get a "lexical error in string/character literal" error message. Examples are some french accents and german umlauts - é,Ü,Ä. However, with other characters from the same set (like üä) there is no problem, they are processed correctly I checked with Hugs and there were no problems, so it seems to be a GHC bug. For further questions send email to: Rainer Volz, mail at vrtprj.com -- >Comment By: Simon Marlow (simonmar) Date: 2005-06-03 08:29 Message: Logged In: YES user_id=48280 I don't know about wxHaskell, it's possible that it is using your system's default encoding. Thanks for the report anyway. I'll re-brand it as a feature request. -- Comment By: Nobody/Anonymous (nobody) Date: 2005-06-02 16:24 Message: Logged In: NO Ah ok, I read so much about Haskell and Unicode that I didn't think about that. My system uses UTF-8 as standard encoding, so Emacs saves the source file also in that encoding. Using ISO-8859-1 as encoding to save the file helps with the lexical error. However the strings are still not displayed correctly. I tried it with texts in wxhaskell windows and with simple putStr "Üo" scripts. Do I have to change my system's encoding to IOS8859-1 to get proper results? -- Comment By: Simon Marlow (simonmar) Date: 2005-06-02 08:32 Message: Logged In: YES user_id=48280 It works fine for me. What encoding are you using? GHC only understands the Latin-1 (ISO8859-1) encoding for source files. If you are using Latin-1, then please attach a source file that we can test. ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1212959&group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1209056 ] functions without implementations
Feature Requests item #1209056, was opened at 2005-05-26 12:53 Message generated for change (Settings changed) made by c_maeder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1209056&group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open >Priority: 2 Submitted By: C Maeder (c_maeder) Assigned to: Nobody/Anonymous (nobody) Summary: functions without implementations Initial Comment: Allow to declare a function by only supplying its type signature. This feature shall enhance rapid prototyping by fixing an interface but leaving some functions unimplemented. Currently this can be (only) simulated by supplying dummy implementations, like f :: ... f = undefined Since it is possible to supply dummy data types by "data T" (not followed by "="), allowing functions without implementations seems almost to be a logical consequence. Surely, the compiler should emit warnings for missing implementations. It would be nice if such function declarations via type signatures could be repeated at any position within a module. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1209056&group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1209056 ] functions without implementations
Feature Requests item #1209056, was opened at 2005-05-26 12:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1209056&group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: C Maeder (c_maeder) Assigned to: Nobody/Anonymous (nobody) Summary: functions without implementations Initial Comment: Allow to declare a function by only supplying its type signature. This feature shall enhance rapid prototyping by fixing an interface but leaving some functions unimplemented. Currently this can be (only) simulated by supplying dummy implementations, like f :: ... f = undefined Since it is possible to supply dummy data types by "data T" (not followed by "="), allowing functions without implementations seems almost to be a logical consequence. Surely, the compiler should emit warnings for missing implementations. It would be nice if such function declarations via type signatures could be repeated at any position within a module. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1209056&group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1084122 ] RPM doesn't support --prefix
Feature Requests item #1084122, was opened at 2004-12-13 10:54
Message generated for change (Comment added) made by juhp
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1084122&group_id=8032
Category: None
Group: None
Status: Open
Priority: 5
Submitted By: John Skaller (skaller)
Assigned to: Nobody/Anonymous (nobody)
Summary: RPM doesn't support --prefix
Initial Comment:
After installing ghc for linux using rpm with
--prefix=/usr/local,
the ghc scriipt incorrectly thinks the libraries etc
are in /usr:
#!/bin/sh
GHCBIN="/usr/lib/ghc-6.2.2/ghc-6.2.2";
TOPDIROPT="-B/usr/lib/ghc-6.2.2";
# Mini-driver for GHC
exec $GHCBIN $TOPDIROPT ${1+"$@"}
After editing, at least the compiler actually starts up :)
--
Comment By: Jens-Ulrik Petersen (juhp)
Date: 2005-05-12 11:08
Message:
Logged In: YES
user_id=139853
This is now fixed in Fedora Haskell as of ghc-6.4-7.
I will send in a spec file patch "as soon as the dust settles".
Feel free to assign this to me. :)
--
Comment By: Jens-Ulrik Petersen (juhp)
Date: 2005-05-09 08:57
Message:
Logged In: YES
user_id=139853
Not really sure what the right solution is - one hack that
comes to mind is adding a %post install script in the spec file
that would replace the default prefix with the specified one.
--
Comment By: Nobody/Anonymous (nobody)
Date: 2005-04-12 22:06
Message:
Logged In: NO
Still a problem with 6.2.4 - Additionally, you now need to
edit the package.conf file.
Karl M. Syring
[EMAIL PROTECTED]
--
Comment By: Simon Marlow (simonmar)
Date: 2004-12-14 01:26
Message:
Logged In: YES
user_id=48280
Re-opened. Any RPM gurus out there who could knock this one
on the head?
Note it's not just the ghc script, there's a couple of other
scripts that need munging (ghci, ghc-pkg, hsc2hs maybe).
--
Comment By: John Skaller (skaller)
Date: 2004-12-13 23:54
Message:
Logged In: YES
user_id=5394
I can see it isn't supported :)
However after the change to those two lines, the compiler
works, links libraries, and the resultant binary executes
correctly
(as far as I can tell never having written any Haskell
before .. :)
So why not support it? I had no choice .. my root partition,
containing /usr is 97% full.. :)
--
Comment By: Simon Marlow (simonmar)
Date: 2004-12-13 21:54
Message:
Logged In: YES
user_id=48280
You're trying to install the binary RPM using a different
prefix? That's not supported, I'm afraid.
------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1084122&group_id=8032
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1097471 ] amd64: adjustor creation not supported
Feature Requests item #1097471, was opened at 2005-01-07 05:55 Message generated for change (Comment added) made by juhp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1097471&group_id=8032 Category: None Group: None Status: Closed 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@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: Jens-Ulrik Petersen (juhp) Date: 2005-05-09 16:33 Message: Logged In: YES user_id=139853 (Well fwiw all gtk2hs-0.9.7/demos segfault for me too.) -- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-09 09:45 Message: Logged In: YES user_id=139853 Testing more carefully today with patched ghc-6.4 instead (if it should make difference) I seeing segfaults with some wx samples demos. However I'm not certain if this is a ghc, wxhaskell, or even wxwidgets issue yet. -- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-08 17:32 Message: Logged In: YES user_id=139853 Just naively replacing DsForeign.lhs and Adjustor.c with the current versions from cvs trunk seems to work well so far though. :-) [ At least I got wxhaskell samples running with them on ghc-6-4-branch. :] -- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-07 11:07 Message: Logged In: YES user_id=139853 I tried ghc-6-4-branch to test this, but it seems the changes have not been merged there yet. -- Comment By: Simon Marlow (simonmar) Date: 2005-03-11 18:19 Message: Logged In: YES user_id=48280 Sorry :-( I implemented this yesterday. It was too late for 6.4, though (it'll be in 6.4.1). If you're interested in the code, take a look at Adjustor.c in CVS. I had to do some delicate hacking to work around the calling convention on x86_64, but fortunately it isn't as tricky as the powerpc version. Thanks for looking at this, and sorry I stepped on your toes! -- Comment By: Thomas Pasch (aanno) Date: 2005-03-11 17:31 Message: Logged In: YES user_id=349837 OK, I'm trying this. First I tried to do it the very same way as in x86: pushing hptr and obscure_ret_addr to stack. Of course, this doesn't work out because x86_64 does use REGISTER for the first 6 (in) arguments/paramenters. Next I tried to get hptr as second/#2 and obscure_ret_addr as first/#1 REGISTER parameter, shifting all REGISTER by 2 (and pushing arguments #6 and #5) to stack. Of course this does not work because obscure_ret is the (faked) return address and should be on the stack. My main problem is that I don't understand what is the the second argument (BaseReg) of StgRun(StgFunPtr f, StgRegTable *basereg) in StgCRun.c . How is this used in x86??? For me x86 stack for _ccall in Adjustor.c looks like: ??? 2nd arg to called haskell land function ??? 1st arg to called haskell land function ??? obsolete_ret_addr hptr obscure_ret_addr >From this it is difficult for me to see any BaseReg joining the game. In other architectures (i.e. sparc) the in REGISTER are a shifted by 2 as well. But in this architecture you don't need the obscure_ret_addr stuff. The bottom line is the following: I understand ghc adjustor, x86, and x86_64 calling convention. BUT the x86 part concering the BaseReg is pretty undocumented. Perhaps someone could give me a hand being more verbose in what is needed in the x86_64 adjustor... Cheers, aanno -- Comment By: Wolfgang Thaller (wthaller) Date: 2005-01-21 07:29 Message: Logged In: YES user_id=566359 The StgFunPtr that is passed to createAdjustor is a pointer to a normal C function (using the standard C calling convention) that takes as it's first argument the StgStablePtr hptr, a second "dummy" argument of the same size that is ignored (this is to help the implementation for the x86 ABI), and then all the arguments that were passed from the constructor. Note that if you need to do something to the stack after the function returns (rather than just tail-calling the function), you s
[ ghc-Feature Requests-1097471 ] amd64: adjustor creation not supported
Feature Requests item #1097471, was opened at 2005-01-07 05:55 Message generated for change (Comment added) made by juhp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1097471&group_id=8032 Category: None Group: None Status: Closed 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@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: Jens-Ulrik Petersen (juhp) Date: 2005-05-09 09:45 Message: Logged In: YES user_id=139853 Testing more carefully today with patched ghc-6.4 instead (if it should make difference) I seeing segfaults with some wx samples demos. However I'm not certain if this is a ghc, wxhaskell, or even wxwidgets issue yet. -- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-08 17:32 Message: Logged In: YES user_id=139853 Just naively replacing DsForeign.lhs and Adjustor.c with the current versions from cvs trunk seems to work well so far though. :-) [ At least I got wxhaskell samples running with them on ghc-6-4-branch. :] -- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-07 11:07 Message: Logged In: YES user_id=139853 I tried ghc-6-4-branch to test this, but it seems the changes have not been merged there yet. -- Comment By: Simon Marlow (simonmar) Date: 2005-03-11 18:19 Message: Logged In: YES user_id=48280 Sorry :-( I implemented this yesterday. It was too late for 6.4, though (it'll be in 6.4.1). If you're interested in the code, take a look at Adjustor.c in CVS. I had to do some delicate hacking to work around the calling convention on x86_64, but fortunately it isn't as tricky as the powerpc version. Thanks for looking at this, and sorry I stepped on your toes! -- Comment By: Thomas Pasch (aanno) Date: 2005-03-11 17:31 Message: Logged In: YES user_id=349837 OK, I'm trying this. First I tried to do it the very same way as in x86: pushing hptr and obscure_ret_addr to stack. Of course, this doesn't work out because x86_64 does use REGISTER for the first 6 (in) arguments/paramenters. Next I tried to get hptr as second/#2 and obscure_ret_addr as first/#1 REGISTER parameter, shifting all REGISTER by 2 (and pushing arguments #6 and #5) to stack. Of course this does not work because obscure_ret is the (faked) return address and should be on the stack. My main problem is that I don't understand what is the the second argument (BaseReg) of StgRun(StgFunPtr f, StgRegTable *basereg) in StgCRun.c . How is this used in x86??? For me x86 stack for _ccall in Adjustor.c looks like: ??? 2nd arg to called haskell land function ??? 1st arg to called haskell land function ??? obsolete_ret_addr hptr obscure_ret_addr >From this it is difficult for me to see any BaseReg joining the game. In other architectures (i.e. sparc) the in REGISTER are a shifted by 2 as well. But in this architecture you don't need the obscure_ret_addr stuff. The bottom line is the following: I understand ghc adjustor, x86, and x86_64 calling convention. BUT the x86 part concering the BaseReg is pretty undocumented. Perhaps someone could give me a hand being more verbose in what is needed in the x86_64 adjustor... Cheers, aanno -- Comment By: Wolfgang Thaller (wthaller) Date: 2005-01-21 07:29 Message: Logged In: YES user_id=566359 The StgFunPtr that is passed to createAdjustor is a pointer to a normal C function (using the standard C calling convention) that takes as it's first argument the StgStablePtr hptr, a second "dummy" argument of the same size that is ignored (this is to help the implementation for the x86 ABI), and then all the arguments that were passed from the constructor. Note that if you need to do something to the stack after the function returns (rather than just tail-calling the function), you should arrange for the function to return to some static piece of code (see obscure_ccall_ret_code for x86) rather than to the adjustor itself. This is because the function might deallocate the adjustor.
[ ghc-Feature Requests-1084122 ] RPM doesn't support --prefix
Feature Requests item #1084122, was opened at 2004-12-13 10:54
Message generated for change (Comment added) made by juhp
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1084122&group_id=8032
Category: None
Group: None
Status: Open
Priority: 5
Submitted By: John Skaller (skaller)
Assigned to: Nobody/Anonymous (nobody)
Summary: RPM doesn't support --prefix
Initial Comment:
After installing ghc for linux using rpm with
--prefix=/usr/local,
the ghc scriipt incorrectly thinks the libraries etc
are in /usr:
#!/bin/sh
GHCBIN="/usr/lib/ghc-6.2.2/ghc-6.2.2";
TOPDIROPT="-B/usr/lib/ghc-6.2.2";
# Mini-driver for GHC
exec $GHCBIN $TOPDIROPT ${1+"$@"}
After editing, at least the compiler actually starts up :)
--
Comment By: Jens-Ulrik Petersen (juhp)
Date: 2005-05-09 08:57
Message:
Logged In: YES
user_id=139853
Not really sure what the right solution is - one hack that
comes to mind is adding a %post install script in the spec file
that would replace the default prefix with the specified one.
--
Comment By: Nobody/Anonymous (nobody)
Date: 2005-04-12 22:06
Message:
Logged In: NO
Still a problem with 6.2.4 - Additionally, you now need to
edit the package.conf file.
Karl M. Syring
[EMAIL PROTECTED]
--
Comment By: Simon Marlow (simonmar)
Date: 2004-12-14 01:26
Message:
Logged In: YES
user_id=48280
Re-opened. Any RPM gurus out there who could knock this one
on the head?
Note it's not just the ghc script, there's a couple of other
scripts that need munging (ghci, ghc-pkg, hsc2hs maybe).
--
Comment By: John Skaller (skaller)
Date: 2004-12-13 23:54
Message:
Logged In: YES
user_id=5394
I can see it isn't supported :)
However after the change to those two lines, the compiler
works, links libraries, and the resultant binary executes
correctly
(as far as I can tell never having written any Haskell
before .. :)
So why not support it? I had no choice .. my root partition,
containing /usr is 97% full.. :)
--
Comment By: Simon Marlow (simonmar)
Date: 2004-12-13 21:54
Message:
Logged In: YES
user_id=48280
You're trying to install the binary RPM using a different
prefix? That's not supported, I'm afraid.
------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1084122&group_id=8032
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1097471 ] amd64: adjustor creation not supported
Feature Requests item #1097471, was opened at 2005-01-07 05:55 Message generated for change (Comment added) made by juhp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1097471&group_id=8032 Category: None Group: None Status: Closed 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@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: Jens-Ulrik Petersen (juhp) Date: 2005-05-08 17:32 Message: Logged In: YES user_id=139853 Just naively replacing DsForeign.lhs and Adjustor.c with the current versions from cvs trunk seems to work well so far though. :-) [ At least I got wxhaskell samples running with them on ghc-6-4-branch. :] -- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-07 11:07 Message: Logged In: YES user_id=139853 I tried ghc-6-4-branch to test this, but it seems the changes have not been merged there yet. -- Comment By: Simon Marlow (simonmar) Date: 2005-03-11 18:19 Message: Logged In: YES user_id=48280 Sorry :-( I implemented this yesterday. It was too late for 6.4, though (it'll be in 6.4.1). If you're interested in the code, take a look at Adjustor.c in CVS. I had to do some delicate hacking to work around the calling convention on x86_64, but fortunately it isn't as tricky as the powerpc version. Thanks for looking at this, and sorry I stepped on your toes! -- Comment By: Thomas Pasch (aanno) Date: 2005-03-11 17:31 Message: Logged In: YES user_id=349837 OK, I'm trying this. First I tried to do it the very same way as in x86: pushing hptr and obscure_ret_addr to stack. Of course, this doesn't work out because x86_64 does use REGISTER for the first 6 (in) arguments/paramenters. Next I tried to get hptr as second/#2 and obscure_ret_addr as first/#1 REGISTER parameter, shifting all REGISTER by 2 (and pushing arguments #6 and #5) to stack. Of course this does not work because obscure_ret is the (faked) return address and should be on the stack. My main problem is that I don't understand what is the the second argument (BaseReg) of StgRun(StgFunPtr f, StgRegTable *basereg) in StgCRun.c . How is this used in x86??? For me x86 stack for _ccall in Adjustor.c looks like: ??? 2nd arg to called haskell land function ??? 1st arg to called haskell land function ??? obsolete_ret_addr hptr obscure_ret_addr >From this it is difficult for me to see any BaseReg joining the game. In other architectures (i.e. sparc) the in REGISTER are a shifted by 2 as well. But in this architecture you don't need the obscure_ret_addr stuff. The bottom line is the following: I understand ghc adjustor, x86, and x86_64 calling convention. BUT the x86 part concering the BaseReg is pretty undocumented. Perhaps someone could give me a hand being more verbose in what is needed in the x86_64 adjustor... Cheers, aanno -- Comment By: Wolfgang Thaller (wthaller) Date: 2005-01-21 07:29 Message: Logged In: YES user_id=566359 The StgFunPtr that is passed to createAdjustor is a pointer to a normal C function (using the standard C calling convention) that takes as it's first argument the StgStablePtr hptr, a second "dummy" argument of the same size that is ignored (this is to help the implementation for the x86 ABI), and then all the arguments that were passed from the constructor. Note that if you need to do something to the stack after the function returns (rather than just tail-calling the function), you should arrange for the function to return to some static piece of code (see obscure_ccall_ret_code for x86) rather than to the adjustor itself. This is because the function might deallocate the adjustor. -- Comment By: Thomas Pasch (aanno) Date: 2005-01-21 05:20 Message: Logged In: YES user_id=349837 OK, I will have a try on this. I sort of understand x86 and x86_64 abi at the moment. There is only one question left at the moment: After I jump to StgFunPtr (a StgFun?) what will happen? Is this (a) a normal C land function that will require its argument (StgSt
[ ghc-Feature Requests-1097471 ] amd64: adjustor creation not supported
Feature Requests item #1097471, was opened at 2005-01-07 05:55 Message generated for change (Comment added) made by juhp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1097471&group_id=8032 Category: None Group: None Status: Closed 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@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: Jens-Ulrik Petersen (juhp) Date: 2005-05-07 11:07 Message: Logged In: YES user_id=139853 I tried ghc-6-4-branch to test this, but it seems the changes have not been merged there yet. -- Comment By: Simon Marlow (simonmar) Date: 2005-03-11 18:19 Message: Logged In: YES user_id=48280 Sorry :-( I implemented this yesterday. It was too late for 6.4, though (it'll be in 6.4.1). If you're interested in the code, take a look at Adjustor.c in CVS. I had to do some delicate hacking to work around the calling convention on x86_64, but fortunately it isn't as tricky as the powerpc version. Thanks for looking at this, and sorry I stepped on your toes! -- Comment By: Thomas Pasch (aanno) Date: 2005-03-11 17:31 Message: Logged In: YES user_id=349837 OK, I'm trying this. First I tried to do it the very same way as in x86: pushing hptr and obscure_ret_addr to stack. Of course, this doesn't work out because x86_64 does use REGISTER for the first 6 (in) arguments/paramenters. Next I tried to get hptr as second/#2 and obscure_ret_addr as first/#1 REGISTER parameter, shifting all REGISTER by 2 (and pushing arguments #6 and #5) to stack. Of course this does not work because obscure_ret is the (faked) return address and should be on the stack. My main problem is that I don't understand what is the the second argument (BaseReg) of StgRun(StgFunPtr f, StgRegTable *basereg) in StgCRun.c . How is this used in x86??? For me x86 stack for _ccall in Adjustor.c looks like: ??? 2nd arg to called haskell land function ??? 1st arg to called haskell land function ??? obsolete_ret_addr hptr obscure_ret_addr >From this it is difficult for me to see any BaseReg joining the game. In other architectures (i.e. sparc) the in REGISTER are a shifted by 2 as well. But in this architecture you don't need the obscure_ret_addr stuff. The bottom line is the following: I understand ghc adjustor, x86, and x86_64 calling convention. BUT the x86 part concering the BaseReg is pretty undocumented. Perhaps someone could give me a hand being more verbose in what is needed in the x86_64 adjustor... Cheers, aanno -- Comment By: Wolfgang Thaller (wthaller) Date: 2005-01-21 07:29 Message: Logged In: YES user_id=566359 The StgFunPtr that is passed to createAdjustor is a pointer to a normal C function (using the standard C calling convention) that takes as it's first argument the StgStablePtr hptr, a second "dummy" argument of the same size that is ignored (this is to help the implementation for the x86 ABI), and then all the arguments that were passed from the constructor. Note that if you need to do something to the stack after the function returns (rather than just tail-calling the function), you should arrange for the function to return to some static piece of code (see obscure_ccall_ret_code for x86) rather than to the adjustor itself. This is because the function might deallocate the adjustor. -- Comment By: Thomas Pasch (aanno) Date: 2005-01-21 05:20 Message: Logged In: YES user_id=349837 OK, I will have a try on this. I sort of understand x86 and x86_64 abi at the moment. There is only one question left at the moment: After I jump to StgFunPtr (a StgFun?) what will happen? Is this (a) a normal C land function that will require its argument (StgStablePtr hptr) as a 1st argument of the "universal" calling convention OR (b) some other kind of magic (from what source code?) that will pop its argument from the stack? Any answer would be appreciated. aanno -- Comment By: Gour (ggd) Date: 2005-01-08 19:34 Message: Logged In: YES use
[ ghc-Feature Requests-1191666 ] Provide a Java Backend
Feature Requests item #1191666, was opened at 2005-04-28 12:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1191666&group_id=8032 Category: None Group: None Status: Open Priority: 5 Submitted By: wangzx (rainbowang) Assigned to: Nobody/Anonymous (nobody) Summary: Provide a Java Backend Initial Comment: I hope the GHC provide a JVM backend. also: 1. GHC compile hs to bytecode(name as klass) like what javac and klass can be packed as kjar(like jar in java) 2. an KVM interpret the klass bytecode and translate it to java .class, then execute it on JVM. the KVM can be write in haskell also. now, a pure java based GHC and KVM can be used on JVM like 1. ghc.kjar contains the ghc compiler 2. happy.kjar contains the happy compiler 3. kvm.kjar contains the KVM 4. kvm.jar contains the bootstrap kvm that can be run on JVM. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1191666&group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1189559 ] incomplete patterns and GADT
Feature Requests item #1189559, was opened at 2005-04-25 08:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1189559&group_id=8032 Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: incomplete patterns and GADT Initial Comment: I would like to compile with -fwarn-incomplete-patterns and use GADTs, but I have bogus error messages. Suppose I define : data T a where C1 :: T Char C2 :: T Float then a function : exhaustive :: T Char -> Char exhaustive C1 = ' ' If I compile with incomplete pattern warnings, I get that my function "exhaustive" is not exhaustive. But if I add a case : exhaust C2 = ' ' then the compiler accurately warns me that this case is inaccessible. Would it be possible to add the accessibility check when compiling with incomplete patterns detection ? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1189559&group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1084122 ] RPM doesn't support --prefix
Feature Requests item #1084122, was opened at 2004-12-12 17:54
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1084122&group_id=8032
Category: None
Group: None
Status: Open
Priority: 5
Submitted By: John Skaller (skaller)
Assigned to: Nobody/Anonymous (nobody)
Summary: RPM doesn't support --prefix
Initial Comment:
After installing ghc for linux using rpm with
--prefix=/usr/local,
the ghc scriipt incorrectly thinks the libraries etc
are in /usr:
#!/bin/sh
GHCBIN="/usr/lib/ghc-6.2.2/ghc-6.2.2";
TOPDIROPT="-B/usr/lib/ghc-6.2.2";
# Mini-driver for GHC
exec $GHCBIN $TOPDIROPT ${1+"$@"}
After editing, at least the compiler actually starts up :)
--
Comment By: Nobody/Anonymous (nobody)
Date: 2005-04-12 06:06
Message:
Logged In: NO
Still a problem with 6.2.4 - Additionally, you now need to
edit the package.conf file.
Karl M. Syring
[EMAIL PROTECTED]
--
Comment By: Simon Marlow (simonmar)
Date: 2004-12-13 08:26
Message:
Logged In: YES
user_id=48280
Re-opened. Any RPM gurus out there who could knock this one
on the head?
Note it's not just the ghc script, there's a couple of other
scripts that need munging (ghci, ghc-pkg, hsc2hs maybe).
--
Comment By: John Skaller (skaller)
Date: 2004-12-13 06:54
Message:
Logged In: YES
user_id=5394
I can see it isn't supported :)
However after the change to those two lines, the compiler
works, links libraries, and the resultant binary executes
correctly
(as far as I can tell never having written any Haskell
before .. :)
So why not support it? I had no choice .. my root partition,
containing /usr is 97% full.. :)
--
Comment By: Simon Marlow (simonmar)
Date: 2004-12-13 04:54
Message:
Logged In: YES
user_id=48280
You're trying to install the binary RPM using a different
prefix? That's not supported, I'm afraid.
------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1084122&group_id=8032
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1097471 ] amd64: adjustor creation not supported
Feature Requests item #1097471, was opened at 2005-01-06 20:55 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1097471&group_id=8032 Category: None Group: None >Status: Closed 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@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: Simon Marlow (simonmar) Date: 2005-03-11 09:19 Message: Logged In: YES user_id=48280 Sorry :-( I implemented this yesterday. It was too late for 6.4, though (it'll be in 6.4.1). If you're interested in the code, take a look at Adjustor.c in CVS. I had to do some delicate hacking to work around the calling convention on x86_64, but fortunately it isn't as tricky as the powerpc version. Thanks for looking at this, and sorry I stepped on your toes! -- Comment By: Thomas Pasch (aanno) Date: 2005-03-11 08:31 Message: Logged In: YES user_id=349837 OK, I'm trying this. First I tried to do it the very same way as in x86: pushing hptr and obscure_ret_addr to stack. Of course, this doesn't work out because x86_64 does use REGISTER for the first 6 (in) arguments/paramenters. Next I tried to get hptr as second/#2 and obscure_ret_addr as first/#1 REGISTER parameter, shifting all REGISTER by 2 (and pushing arguments #6 and #5) to stack. Of course this does not work because obscure_ret is the (faked) return address and should be on the stack. My main problem is that I don't understand what is the the second argument (BaseReg) of StgRun(StgFunPtr f, StgRegTable *basereg) in StgCRun.c . How is this used in x86??? For me x86 stack for _ccall in Adjustor.c looks like: ??? 2nd arg to called haskell land function ??? 1st arg to called haskell land function ??? obsolete_ret_addr hptr obscure_ret_addr >From this it is difficult for me to see any BaseReg joining the game. In other architectures (i.e. sparc) the in REGISTER are a shifted by 2 as well. But in this architecture you don't need the obscure_ret_addr stuff. The bottom line is the following: I understand ghc adjustor, x86, and x86_64 calling convention. BUT the x86 part concering the BaseReg is pretty undocumented. Perhaps someone could give me a hand being more verbose in what is needed in the x86_64 adjustor... Cheers, aanno -- Comment By: Wolfgang Thaller (wthaller) Date: 2005-01-20 22:29 Message: Logged In: YES user_id=566359 The StgFunPtr that is passed to createAdjustor is a pointer to a normal C function (using the standard C calling convention) that takes as it's first argument the StgStablePtr hptr, a second "dummy" argument of the same size that is ignored (this is to help the implementation for the x86 ABI), and then all the arguments that were passed from the constructor. Note that if you need to do something to the stack after the function returns (rather than just tail-calling the function), you should arrange for the function to return to some static piece of code (see obscure_ccall_ret_code for x86) rather than to the adjustor itself. This is because the function might deallocate the adjustor. -- Comment By: Thomas Pasch (aanno) Date: 2005-01-20 20:20 Message: Logged In: YES user_id=349837 OK, I will have a try on this. I sort of understand x86 and x86_64 abi at the moment. There is only one question left at the moment: After I jump to StgFunPtr (a StgFun?) what will happen? Is this (a) a normal C land function that will require its argument (StgStablePtr hptr) as a 1st argument of the "universal" calling convention OR (b) some other kind of magic (from what source code?) that will pop its argument from the stack? Any answer would be appreciated. aanno -- Comment By: Gour (ggd) Date: 2005-01-08 10: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 l
[ ghc-Feature Requests-1097471 ] amd64: adjustor creation not supported
Feature Requests item #1097471, was opened at 2005-01-06 21:55 Message generated for change (Comment added) made by aanno You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1097471&group_id=8032 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@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: Thomas Pasch (aanno) Date: 2005-03-11 09:31 Message: Logged In: YES user_id=349837 OK, I'm trying this. First I tried to do it the very same way as in x86: pushing hptr and obscure_ret_addr to stack. Of course, this doesn't work out because x86_64 does use REGISTER for the first 6 (in) arguments/paramenters. Next I tried to get hptr as second/#2 and obscure_ret_addr as first/#1 REGISTER parameter, shifting all REGISTER by 2 (and pushing arguments #6 and #5) to stack. Of course this does not work because obscure_ret is the (faked) return address and should be on the stack. My main problem is that I don't understand what is the the second argument (BaseReg) of StgRun(StgFunPtr f, StgRegTable *basereg) in StgCRun.c . How is this used in x86??? For me x86 stack for _ccall in Adjustor.c looks like: ??? 2nd arg to called haskell land function ??? 1st arg to called haskell land function ??? obsolete_ret_addr hptr obscure_ret_addr >From this it is difficult for me to see any BaseReg joining the game. In other architectures (i.e. sparc) the in REGISTER are a shifted by 2 as well. But in this architecture you don't need the obscure_ret_addr stuff. The bottom line is the following: I understand ghc adjustor, x86, and x86_64 calling convention. BUT the x86 part concering the BaseReg is pretty undocumented. Perhaps someone could give me a hand being more verbose in what is needed in the x86_64 adjustor... Cheers, aanno -- Comment By: Wolfgang Thaller (wthaller) Date: 2005-01-20 23:29 Message: Logged In: YES user_id=566359 The StgFunPtr that is passed to createAdjustor is a pointer to a normal C function (using the standard C calling convention) that takes as it's first argument the StgStablePtr hptr, a second "dummy" argument of the same size that is ignored (this is to help the implementation for the x86 ABI), and then all the arguments that were passed from the constructor. Note that if you need to do something to the stack after the function returns (rather than just tail-calling the function), you should arrange for the function to return to some static piece of code (see obscure_ccall_ret_code for x86) rather than to the adjustor itself. This is because the function might deallocate the adjustor. -- Comment By: Thomas Pasch (aanno) Date: 2005-01-20 21:20 Message: Logged In: YES user_id=349837 OK, I will have a try on this. I sort of understand x86 and x86_64 abi at the moment. There is only one question left at the moment: After I jump to StgFunPtr (a StgFun?) what will happen? Is this (a) a normal C land function that will require its argument (StgStablePtr hptr) as a 1st argument of the "universal" calling convention OR (b) some other kind of magic (from what source code?) that will pop its argument from the stack? Any answer would be appreciated. aanno -- 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 und
[ ghc-Feature Requests-1124080 ] Implicit Parameters and monomorphism
Feature Requests item #1124080, was opened at 2005-02-16 17:01 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1124080&group_id=8032 Category: None Group: None Status: Open >Priority: 3 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) >Summary: Implicit Parameters and monomorphism Initial Comment: http://www.haskell.org/pipermail/haskell-cafe/2005-January/008571.html Notes some oddness with recursive binding of implicit parameters. Roughly, giving a type signature to a function with implicit params causes its bindings to act recursively, despite what section 7.4.5.2 of the user's guide says. -- >Comment By: Simon Marlow (simonmar) Date: 2005-03-08 10:35 Message: Logged In: YES user_id=48280 This "bug" is just to record the strange interaction between implicit parameters and monomorphism. [adding text of original message] Jim Apple wrote: > Does anyone have examples of these? This one scares the foo out of me: > >>> * It's not even safe in general to add a signature giving the same type >>> that the compiler would infer anyway Here's an example: > len :: [a] -> Int > > len xs = let ?accum = 0 in len' xs > > len' [] = ?accum > len' (x:xs) = let ?accum = ?accum + (1::Int) in len' xs *Main> :t len' len' :: forall a. (?accum :: Int) => [a] -> Int *Main> len "hello" 0 > len :: [a] -> Int > > len xs = let ?accum = 0 in len' xs > > len' :: forall a. (?accum :: Int) => [a] -> Int > > len' [] = ?accum > len' (x:xs) = let ?accum = ?accum + (1::Int) in len' xs *Main> :t len' len' :: forall a. (?accum :: Int) => [a] -> Int *Main> len "hello" 5 This happens as a side effect of the way that type inference currently works on recursive binding groups. It happens with typeclass dictionaries too, but it isn't observable because they can't be rebound in a local scope. -- Ben -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1124080&group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1157515 ] GHCi support on x86_64
Feature Requests item #1157515, was opened at 2005-03-06 00:25 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1157515&group_id=8032 >Category: None >Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) >Summary: GHCi support on x86_64 Initial Comment: I just installed the 64bit version of ghc on an athlon 64. ghc does work and produces correct 64bit code, but ghci fails to start. Here is the complete output: [EMAIL PROTECTED] ~]$ ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.2.2, for Haskell 98. / /_\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... /usr/lib64/ghc-6.2.2/HSbase.o: unknown architecture ghc-6.2.2: panic! (the `impossible' happened, GHC version 6.2.2): loadObj: failed Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org, or http://sourceforge.net/projects/ghc/. I'm using Fedora Core 3 and installed ghc using yum. If you have any questions, contact me: philipp.classen[AT]gmx.net Thanks, Philipp -- >Comment By: Simon Marlow (simonmar) Date: 2005-03-07 12:03 Message: Logged In: YES user_id=48280 Changed to a feature request; GHCi support is simply not present on x86_64 yet. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1157515&group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1155875 ] Arbitrary function sections
Feature Requests item #1155875, was opened at 2005-03-03 16:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1155875&group_id=8032 Category: None Group: None Status: Open Priority: 5 Submitted By: Dinko Tenev (a0s) Assigned to: Nobody/Anonymous (nobody) Summary: Arbitrary function sections Initial Comment: For operators we have the following shorthand: op :: a -> b -> c (`op` y) === \x -> x `op` y (x `op`) === \y -> x `op` y It would be nice to have a similar facility for functions, e.g.: f :: a -> b -> c -> d -> e f _ y _ t === \x z -> f x y z t f x _ z _ === \y t -> f x y z t f x _ z === \y -> f x y z === \y t -> f x y z t Because "_" is currently not allowed as an identifier in contexts where this facility could possibly be in effect, it seems safe to use it to indicate omitted parameters in function application. ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1155875&group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1153029 ] allow hierarchical module names with --make
Feature Requests item #1153029, was opened at 2005-02-27 20:24 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1153029&group_id=8032 Category: None Group: None >Status: Closed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: allow hierarchical module names with --make Initial Comment: It would be convenient (and consistent) to allow the use of hierarchical module names with --make, so that something like: ghc -isource_directory --make app.Main -o app would find the source_directory/app/Main.hs module to begin its processing. - Jeff Newbern [EMAIL PROTECTED] -- >Comment By: Simon Marlow (simonmar) Date: 2005-02-28 11:01 Message: Logged In: YES user_id=48280 You can use hierarchical module names with --make, but your module names must be a lexically correct; that is, each component must begin with an upper case letter. App.Main would work, app.Main is not a module name. More information on hierarchical modules here: http://www.haskell.org/hierarchical-modules/ and in the GHC User Guide. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1153029&group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1153029 ] allow hierarchical module names with --make
Feature Requests item #1153029, was opened at 2005-02-27 12:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1153029&group_id=8032 Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: allow hierarchical module names with --make Initial Comment: It would be convenient (and consistent) to allow the use of hierarchical module names with --make, so that something like: ghc -isource_directory --make app.Main -o app would find the source_directory/app/Main.hs module to begin its processing. - Jeff Newbern [EMAIL PROTECTED] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1153029&group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1097471 ] amd64: adjustor creation not supported
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_id=8032 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@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-20 23:29 Message: Logged In: YES user_id=566359 The StgFunPtr that is passed to createAdjustor is a pointer to a normal C function (using the standard C calling convention) that takes as it's first argument the StgStablePtr hptr, a second "dummy" argument of the same size that is ignored (this is to help the implementation for the x86 ABI), and then all the arguments that were passed from the constructor. Note that if you need to do something to the stack after the function returns (rather than just tail-calling the function), you should arrange for the function to return to some static piece of code (see obscure_ccall_ret_code for x86) rather than to the adjustor itself. This is because the function might deallocate the adjustor. -- Comment By: Thomas Pasch (aanno) Date: 2005-01-20 21:20 Message: Logged In: YES user_id=349837 OK, I will have a try on this. I sort of understand x86 and x86_64 abi at the moment. There is only one question left at the moment: After I jump to StgFunPtr (a StgFun?) what will happen? Is this (a) a normal C land function that will require its argument (StgStablePtr hptr) as a 1st argument of the "universal" calling convention OR (b) some other kind of magic (from what source code?) that will pop its argument from the stack? Any answer would be appreciated. aanno -- 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_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1097471 ] amd64: adjustor creation not supported
Feature Requests item #1097471, was opened at 2005-01-06 21:55 Message generated for change (Comment added) made by aanno You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1097471&group_id=8032 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@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: Thomas Pasch (aanno) Date: 2005-01-20 21:20 Message: Logged In: YES user_id=349837 OK, I will have a try on this. I sort of understand x86 and x86_64 abi at the moment. There is only one question left at the moment: After I jump to StgFunPtr (a StgFun?) what will happen? Is this (a) a normal C land function that will require its argument (StgStablePtr hptr) as a 1st argument of the "universal" calling convention OR (b) some other kind of magic (from what source code?) that will pop its argument from the stack? Any answer would be appreciated. aanno -- 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_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1104381 ] Add wxHaskell link to homepage
Feature Requests item #1104381, was opened at 2005-01-18 11:27 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1104381&group_id=8032 Category: None Group: None >Status: Closed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Add wxHaskell link to homepage Initial Comment: Hi, I am a user of wxHaskell, a wxWidgets binding for haskell. The product is very useful to me. Adding it to the homepage will ensure that more contribution is added to it though. Haskell community has to stay tight. Sorry for not knowing where to post this issue though -- >Comment By: Simon Marlow (simonmar) Date: 2005-01-18 14:09 Message: Logged In: YES user_id=48280 Done. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1104381&group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1104381 ] Add wxHaskell link to homepage
Feature Requests item #1104381, was opened at 2005-01-18 03:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1104381&group_id=8032 Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Add wxHaskell link to homepage Initial Comment: Hi, I am a user of wxHaskell, a wxWidgets binding for haskell. The product is very useful to me. Adding it to the homepage will ensure that more contribution is added to it though. Haskell community has to stay tight. Sorry for not knowing where to post this issue though -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1104381&group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1097471 ] amd64: adjustor creation not supported
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_id=8032 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@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_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1097471 ] amd64: adjustor creation not supported
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_id=8032 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@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_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1088694 ] hp-ux 11.11 binaries
Feature Requests item #1088694, was opened at 2004-12-20 16:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1088694&group_id=8032 Category: None Group: None Status: Open Priority: 5 Submitted By: Andy MyHR (amyhr) Assigned to: Nobody/Anonymous (nobody) Summary: hp-ux 11.11 binaries Initial Comment: Looks like there hasn't been a binary dist for ghc in a very long time, any chance we could see one soon? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1088694&group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1084122 ] RPM doesn't support --prefix
Feature Requests item #1084122, was opened at 2004-12-13 01:54
Message generated for change (Comment added) made by simonmar
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1084122&group_id=8032
>Category: None
>Group: None
>Status: Open
Priority: 5
Submitted By: John Skaller (skaller)
Assigned to: Nobody/Anonymous (nobody)
>Summary: RPM doesn't support --prefix
Initial Comment:
After installing ghc for linux using rpm with
--prefix=/usr/local,
the ghc scriipt incorrectly thinks the libraries etc
are in /usr:
#!/bin/sh
GHCBIN="/usr/lib/ghc-6.2.2/ghc-6.2.2";
TOPDIROPT="-B/usr/lib/ghc-6.2.2";
# Mini-driver for GHC
exec $GHCBIN $TOPDIROPT ${1+"$@"}
After editing, at least the compiler actually starts up :)
--
>Comment By: Simon Marlow (simonmar)
Date: 2004-12-13 16:26
Message:
Logged In: YES
user_id=48280
Re-opened. Any RPM gurus out there who could knock this one
on the head?
Note it's not just the ghc script, there's a couple of other
scripts that need munging (ghci, ghc-pkg, hsc2hs maybe).
--
Comment By: John Skaller (skaller)
Date: 2004-12-13 14:54
Message:
Logged In: YES
user_id=5394
I can see it isn't supported :)
However after the change to those two lines, the compiler
works, links libraries, and the resultant binary executes
correctly
(as far as I can tell never having written any Haskell
before .. :)
So why not support it? I had no choice .. my root partition,
containing /usr is 97% full.. :)
--
Comment By: Simon Marlow (simonmar)
Date: 2004-12-13 12:54
Message:
Logged In: YES
user_id=48280
You're trying to install the binary RPM using a different
prefix? That's not supported, I'm afraid.
------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1084122&group_id=8032
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1069653 ] ghci compile option
Feature Requests item #1069653, was opened at 2004-11-19 20:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1069653&group_id=8032 Category: None Group: None Status: Open Priority: 5 Submitted By: Nightmare (goronsf) Assigned to: Nobody/Anonymous (nobody) Summary: ghci compile option Initial Comment: Sometimes you want to develop something using ghci, but a lot of files are just interpreted everytime (which takes a lot time), while they could also had been compiled. (An option is writing a simple script each time (but that's not what users want.) So what I want (and some people on #haskell): an interface to compile everything instead of interpretate it. So inside ghci I want to have an option: :compile which compiles everything (except maybe for the module you are currently working on.) This is how people in #haskell would appreciate it: 21:13 < goron> Is there some command to say in ghci: precompile everything? 21:13 < goron> I had to write some scripts to do it. 21:14 < Lemmih> goron: ghc --make, perhaps. 21:15 < goron> Lemmih: I meant inside ghci. My approach was ghc --make, but I had to include a lot of paths. 21:15 < goron> And it seems something useful. 21:17 < Lemmih> Agreed. 21:18 < Lemmih> But unfortunately I haven't heard of such feature. 21:18 < Somebody else> Yep, would be immensly useful. ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1069653&group_id=8032 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-668303 ] Cygwin binaries
Feature Requests item #668303, was opened at 2003-01-15 04:46 Message generated for change (Comment added) made by hafnert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=668303&group_id=8032 Category: None Group: None Status: Open Priority: 5 Submitted By: Marcus Lindblom (fizzgig) Assigned to: Nobody/Anonymous (nobody) Summary: Cygwin binaries Initial Comment: A complete set of binaries for ghc and ghci under cygwin would be really nice. Using the win32-version works, but is far from satisfying. GHCI does not recognize the arrow keys, thus no command history (annoying errors instead) and I've heard others complain about problem with linking, since win32-ghc uses it's own gcc. I tried to compile ghc myself, but gave up after a few hours. Please compile it and include it in cygwin's auto-update system. -- Comment By: Thomas Hafner (hafnert) Date: 2004-03-23 15:06 Message: Logged In: YES user_id=573630 That would be really great! I tried to cross compile on a Linux box for Cygwin, but didn't succeed either. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=668303&group_id=8032 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-837563 ] GHCi (Mac OS X) file names
Feature Requests item #837563, was opened at 2003-11-06 16:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=837563&group_id=8032 Category: None Group: None Status: Open Priority: 5 Submitted By: Hamilton Richards (hamrichards) Assigned to: Nobody/Anonymous (nobody) Summary: GHCi (Mac OS X) file names Initial Comment: It would be nice if, in file names, "\ " were handled as " ". This would make the GHCi interface consistent with those of Terminal and Hugs. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=837563&group_id=8032 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
