Dear All,
I'm trying toupdate the Portfile so that ghc-6.8.2 can be built using MacPorts
(handy for installing other ghc-dependent material from MacPorts like
gtk2hs). The problem seems to be that the available bootstrap binary
Judah Jacobson wrote:
On OS X 10.4, I have readline.h,v 1.11 as the libedit readline
compatibility header. Can you please try linking a simple program
that uses System.Console.Editline.Readline on your Solaris machine and
see if it throws up any link errors? If so, I may be able to fix
I've installed Christian's 6.8.2 binary on my PPC Mac at home (OS X
10.4)
and wen I try to install HAppS :
manu-2:~/Sites/MyProject manu$ sp ghc -isrc src/Main.hs --make --run --
http-port=5000
I get :
downloading modules...
sp: Maybe.fromJust: Nothing
It's strange the same command
Christian Maeder:
Manuel M T Chakravarty wrote:
Christian Maeder:
1. a _new_ readline package that only contains the interface that
can be
implemented using libeditline _or_ libreadline. If this package is
call
readline (with a new version number) most libraries i.e. like
Shellac
would
Manuel M T Chakravarty wrote:
Christian Maeder:
Manuel M T Chakravarty wrote:
Christian Maeder:
1. a _new_ readline package that only contains the interface that
can be
implemented using libeditline _or_ libreadline. If this package is call
readline (with a new version number) most
Christian Maeder wrote:
Where are the users that use the functionality not supported by
editline's emulation layer? (Shout now or be quiet ever after)
I only wanted to find out which user group would need to change readline
to editline and (if following my suggestion) which group readline to
Christian Maeder wrote:
Simon Marlow wrote:
It would be a bad idea to remove functionality from the readline
package. It's a binding to the GNU readline library, and as such it does
a fine job.
I only want to move (not remove).
I don't think it's necessary to remove (or move) anything from
Yitzchak Gale wrote:
We should not cause people's programs to break silently by
changing a fundamental API, unless there is no alternative.
In this case there is a reasonable alternative. Anyone who wants
to change over to editline - native or readline-compatible - can
easily do so, at their
Christian Maeder wrote:
3. if ghci is going to use editline... then readline would not
need to be a core package und users might need to
install package readline explicitly.
OK, I get it.
Even if we leave readline as it is, so that the package system will
theoretically not force the person to
(my previous mail went to the bugs list by accident)
Christian Maeder wrote:
I would like to know from package maintainers if there packages can be
easily ported from libreadline to libedit.
The best indication for this would be if the package is also happy with
a restricted interface of
Hi Frederik,
(I'm CC:ing the libraries list, so that anyone who wants to have
Network.CGI.Compat back in the cgi package can shout.)
That exact module actually used to exist in the cgi package as well (it
implemented the complete API of the old Network.CGI), but after a few
releases I
Hi Bjorn,
Well, I don't know what the solution is. As I have said, I think it
would be best to keep Network.CGI.Compat. That way, users of the old
module just have to change the module name, plus they don't have to
hack cgi-compat to get it to compile when cgi is already working.
A typical
12 matches
Mail list logo
