Re: Network.CGI changes
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 project of mine uses 10 or more packages, and something that makes me reluctant to use Haskell is the experience that after a few years I will end up having to maintain separate versions of significant numbers of those packages if I want something I wrote to stay working. Haskell is supposed to be good for writing large projects, but large projects need stable libraries or they become a maintenance nightmare. It's rather worrying to see that people seem to think that if I don't have time to participate actively in the mailing lists or upload stuff to hackage, then my code doesn't exist... Maybe there is a high cost to keeping Network.CGI.Compat in the cgi package, but I don't see any reason other than an aesthetics, which seems like less of a priority than backwards compatibility. Frederik On Tue, Jan 22, 2008 at 05:31:01PM +0100, Björn Bringert wrote: > 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 removed it > since it didn't > seem to have any users. That was quite a long time ago, and you are the first > person to > complain. > > The purpose of cgi-compat is actually not to provide Network.CGI.Compat, but > rather to be > installable on older GHC versions, hence the main module name Network.NewCGI. > > I'm not sure if there is sufficient demand for adding Network.CGI.Compat back > into the cgi > package. The old Network.CGI seemed to have very few users, due to to it's > restrictions. > You can always get Network.CGI.Compat from here, and include it in your > program: > http://www.cs.chalmers.se/~bringert/darcs/cgi-compat/Network/CGI/Compat.hs > > /Björn > > Frederik Eaton wrote: > >Dear Johannes, > >Thanks, that works for me. > >Bjorn, perhaps it would be easier to put these five lines in a module > >(Network.CGI.Compat?) in the new package, rather than having people > >maintain and download a separate cgi-compat package? Perhaps the two > >other functions in the old CGI interface can be implemented in terms > >of the new API as well? > >Best wishes, > >Frederik > >On Mon, Jan 21, 2008 at 09:50:46AM +0100, Johannes Waldmann wrote: > >>If you need the old "wrapper" function, then use something like this: > >> > >>wrapper :: ([(String,String)] -> IO Html) -> IO () > >>wrapper f = runCGI $ do > >> > >>e <- getInputs > >>a <- lift $ f $ e > >>output $ renderHtml a > >> > >>best regards, Johannes Waldmann. > >> > -- http://ofb.net/~frederik/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Network.CGI changes
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 removed it since it didn't seem to have any users. That was quite a long time ago, and you are the first person to complain. The purpose of cgi-compat is actually not to provide Network.CGI.Compat, but rather to be installable on older GHC versions, hence the main module name Network.NewCGI. I'm not sure if there is sufficient demand for adding Network.CGI.Compat back into the cgi package. The old Network.CGI seemed to have very few users, due to to it's restrictions. You can always get Network.CGI.Compat from here, and include it in your program: http://www.cs.chalmers.se/~bringert/darcs/cgi-compat/Network/CGI/Compat.hs /Björn Frederik Eaton wrote: Dear Johannes, Thanks, that works for me. Bjorn, perhaps it would be easier to put these five lines in a module (Network.CGI.Compat?) in the new package, rather than having people maintain and download a separate cgi-compat package? Perhaps the two other functions in the old CGI interface can be implemented in terms of the new API as well? Best wishes, Frederik On Mon, Jan 21, 2008 at 09:50:46AM +0100, Johannes Waldmann wrote: If you need the old "wrapper" function, then use something like this: wrapper :: ([(String,String)] -> IO Html) -> IO () wrapper f = runCGI $ do e <- getInputs a <- lift $ f $ e output $ renderHtml a best regards, Johannes Waldmann. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
(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 readline (i.e. readline-compat) or requires > the full GNU readline. > > At least testing this compatibility makes sense using a readline package > with a temporarily reduced interface (without the need to change the > packages depending on readline.) In short, consider a split up of the readline package into readline-basics and readline-exts (both with GPL licence). Unfortunately it is not possible to have the package readline to be the union of readline-basics and readline-exts. So readline-basic (or readline-compat) would be a duplication of a reduced readline package. For porting packages from libreadline to libedit it would be sufficient to replace readline-basics with editline (and change the licence) in *.cabal files. Packages depending on more then readline-basics cannot be ported. I'm only worried if any package maintainer would bother to change the build-depends from readline to readline-basic (if not forced to change it anyway, i.e. to readline-basic and readline-ext). Alternatively, if the interface of readline is reduced to that of readline-basic, package maintainers could hope that their package is still okay and if not (after compilation errors) add readline-ext to their build-depends. Is this really such a crazy idea? Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
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 take action, in practice action will be needed the next time the person upgrades GHC. So you would like to minimize overall work of changing packages over all users. Even so, I think it is more important to minimize confusion over users who are not aware of this whole discussion, and may have minimal knowledge of the package system. They don't want to have to figure things out - they just want it to keep working as before. The need to re-install some package due to the shrinking GHC library core is an annoyance all GHC users are aware of by now. You figure out what has disappeared, and you install it. Changing the semantics of the readline package would add to the confusion, I believe. Also, I think in general we should do what makes the most sense within the package system itself. GHC library core shrinkage is an external issue, though I agree that in practice it will affect everyone. So I am still in favor of keeping readline as it is. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
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 leisure. Anyone who wants things to stay > the way they are can do nothing. 1. Things don't break silently (I hope), they break during compilation. 2. With every new ghc major version (or library version) there is a list of user visible changes. 3. if ghci is going to use editline (at least on Macs by default) then readline would not need to be a core package und users might need to install package readline explicitely. (Then at least everybody using readline has to do something manually, at least users on Macs who complain most if something does not run out of the box.) > Do you see any problem with that approach? No, I've only pointed out the alternative, I hope. I don't know what fits the needs of the majority most. Let's vote? Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
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 readline at all. That would break clients unnecessarily. By all means add a new module that exports the lowest-common-denominator API. For convenience, we would like there to be an API that can be supported by both readline and editline. It would be a bad idea for this to be a package, because (as I mentioned earlier on libraries@) that package would have a variant license, depending on whether the API-provider was readline or editline at build-time (or perhaps in the future link-time or run-time). If you chose between readline and editline, then you have to make an explicit choice in your .cabal file - making a package that abstracts this choice is not good, unless said package is explicitly GPL'd. Actually, the license is not (so) important for me. I basically want the convenience to link against libedit on Macs and against libreadline on other unix system, because these libs are usually there without further ado. But other people really do care about licenses, and it's vitally important that each package has a clearly-defined license. Under my proposal you would be able to do exactly what you want. The difference is that you can't hide the choice between libedit and libreadline in a package of its own, unless that package is GPL. So the compatible API could be in a module that is exposed by *both* readline and editline, say System.Console.ReadlineCompat. So your source code wouldn't have to change to switch from one to the other, just your .cabal file. Things ghc does not support, users have to do. This isn't about GHC, it's about the readline/editline packages! Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
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 > GPL-readline in cabal files, and which of the two user groups is bigger. > > Since it's not clear yet, what portion of readline can be emulated by > editline this is difficult to estimate. It is always impossible to estimate this, because users are not required to register anyplace, and they are not required to read this or any other discussion list. 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 leisure. Anyone who wants things to stay the way they are can do nothing. Do you see any problem with that approach? I think that in most cases, people are happy with readline and will not need to change. Nevertheless, making editline available in this way is critically important, because certain projects are difficult or impossible without it. And of course, it's a great improvement for the Mac platform. So your work on this is highly appreciated. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.8.2 for mac PPC and HAppS
manu wrote:
> 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...
> <>Conf {hsFiles = ["src/Main.hs"], modLocs = [], mapLocs = [MapDir
"src",MapFile ".searchpath.default.map",MapURI
"http://searchpath.org/default.map";], cargs = ["--make"], cacheDir =
"/home/maeder/.SearchPath", exe = "ghc", maxAge = 1209600, glasgow =
True, start = 1200997905, verbose = 0, target = "Main.exe",
useDefaultMap = True, runArgs = Just ["--http-port=5000"]}
<>"darcs get --partial http://happs.org/repos/HAppS-Server";
Copying patch 192 of 192... done.
Applying patch 191 of 191... done.
Finished getting.
"darcs get --partial http://happs.org/repos/HAppS-State";
Copying patch 115 of 115... done.
Applying patch 114 of 114... done.
Finished getting.
<>"darcs get --partial http://happs.org/repos/HAppS-Data";
Copying patch 52 of 52... done.
Applying patch 51 of 51... done.
Finished getting.
"darcs get --partial --tag=0.9.1.2 http://happs.org/repos/HAppS-Util
util; echo hello world"
Copying patch 18 of 18... done.
Applying patch 17 of 17... done.
darcs: Couldn't find a tag matching "tag-name 0.9.1.2"
hello world
"darcs get --partial --tag=0.9.1.2 http://happs.org/repos/syb-with-class";
Copying patch 24 of 24... done.
Applying patch 24 of 24... done.
Unapplying 3 patches.
Finished getting.
<>"/private/var/automount/home/maeder/.SearchPath/http_www.haskell.org-HaXml-HaXml-1.13.3.tar.gz"
"tar -xzf http_www.haskell.org-HaXml-HaXml-1.13.3.tar.gz"
foo
bar
<><><><><<<><><><>< <><>"darcs get --partial --tag=0.9.1.2
http://happs.org/repos/HAppS-IxSet";
Copying patch 33 of 33... done.
Applying patch 32 of 32... done.
Unapplying 5 patches.
Finished getting.
"ghc -isrc
-i/home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-Util_util;_echo_hello_world/util/src
-i/home/maeder/.SearchPath/http_www.haskell.org-HaXml-HaXml-1.13.3.tar.gz/HaXml-1.13.3/src
-i/home/maeder/.SearchPath/http_www.haskell.org-HaXml-HaXml-1.13.3.tar.gz/HaXml-1.13.3/src
-i/home/maeder/.SearchPath
-i/home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src
-i/home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src
-i/home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src
-i/home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-IxSet/HAppS-IxSet/src
-i/home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src
-i/home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.3_http_happs.org-repos-HAppS-State/HAppS-State/src
-i/home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-State/HAppS-State/src
-i/home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-syb-with-class/syb-with-class
-i/home/maeder/.SearchPath
-i/home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-Util_util;_echo_hello_world/util/src
-i/home/maeder/.SearchPath/http_www.haskell.org-HaXml-HaXml-1.13.3.tar.gz/HaXml-1.13.3/src
-i/home/maeder/.SearchPath/http_www.haskell.org-HaXml-HaXml-1.13.3.tar.gz/HaXml-1.13.3/src
-i/home/maeder/.SearchPath
-i/home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src
-i/home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src
-i/home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Data/HAppS-Data/src
-i/home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-IxSet/HAppS-IxSet/src
-i/home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-State/HAppS-State/src
-i/home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.3_http_happs.org-repos-HAppS-State/HAppS-State/src
-i/home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-State/HAppS-State/src
-i/home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-syb-with-class/syb-with-class
-i/home/maeder/.SearchPath -o Main.exe.sp.new -cpp -fth -fglasgow-exts
-fallow-undecidable-instances -fallow-overlapping-instances src/Main.hs
--make"
[ 1 of 83] Compiling HAppS.Crypto.SHA1 (
/home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-Util_util;_echo_hello_world/util/src/HAppS/Crypto/SHA1.lhs,
/home/maeder/.SearchPath/darcs_get_--partial_--tag=0.9.1.2_http_happs.org-repos-HAppS-Util_util;_echo_hello_world/util/src/HAppS/Crypto/SHA1.o
)
[ 2 of 83] Compiling HAppS.Server.HTTP.Clock (
/home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/HTTP/Clock.hs,
/home/maeder/.SearchPath/darcs_get_--partial_http_happs.org-repos-HAppS-Server/HAppS-Server/src/HAppS/Server/HTTP/Clock.o
)
[ 3 of 83] Compi
Re: Integrating editline with ghc
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 libraries i.e. like Shellac would not need modifications. >>> >>> I disagree. Readline should stay as it is. (Why force existing >>> readline users who use functionality not supported by editline's >>> emulation layer to change the package they are using?) >> >> Your point is also supported by Yitz Gale, my point by Malcolm. >> >> Where are the users that use the functionality not supported by >> editline's emulation layer? (Shout now or be quiet ever after) > > Are you seriously suggesting that we mess up users who do not read the > various mailing lists constantly to defend the APIs they are using? 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 GPL-readline in cabal files, and which of the two user groups is bigger. Since it's not clear yet, what portion of readline can be emulated by editline this is difficult to estimate. Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
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 not need modifications. I disagree. Readline should stay as it is. (Why force existing readline users who use functionality not supported by editline's emulation layer to change the package they are using?) Your point is also supported by Yitz Gale, my point by Malcolm. Where are the users that use the functionality not supported by editline's emulation layer? (Shout now or be quiet ever after) Are you seriously suggesting that we mess up users who do not read the various mailing lists constantly to defend the APIs they are using? Manuel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 6.8.2 for mac PPC and HAppS
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... <> I had this issue too... > After manually compiling GHC (i was using Debian's package) and then > recompiling sp, It has gone away Wonder what it was. So I wonder, to what extent is it due to my ghc install ? Thanks Emmanuel___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
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 > that. I wasn't able to install your editline-0.1 package under Solaris. Our installed files are: /usr/local/lib/libeditline.so -> libeditline.so.0.0.0 /usr/local/lib/libeditline.so.0 -> libeditline.so.0.0.0 /usr/local/lib/libeditline.so.0.0.0 /usr/local/lib/libeditline.a /usr/local/lib/libeditline.la /usr/local/include/editline.h Christian checking for gcc option to accept ANSI C... none needed checking for tputs in -lncurses... yes checking for el_init in -ledit... no checking for readline in -ledit... no checking how to run the C preprocessor... gcc -E checking for egrep... egrep checking for ANSI C header files... no checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking editline/readline.h usability... no checking editline/readline.h presence... no checking for editline/readline.h... no checking readline/readline.h usability... yes checking readline/readline.h presence... yes checking for readline/readline.h... yes configure: error: editline not found, so this package cannot be built ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Bootstrapping for Leopard
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 http://www.haskell.org/ghc/dist/6.6/ghc-6.6-i386-apple-darwin-bootstrap.tar.bz2 causes a segfault on Leopard (below are the steps I took in my attempt to build ghc with this bootstrap binary). Using Manuel Chakravarty's binary distribution of ghc-6.8.1-i386-apple-darwin building ghc-6.8.2 works fine. It seemed to me that the easiest way to fix the bootstrap problem is to boot from C as described on the wiki (http://hackage.haskell.org/trac/ghc/wiki/Building/Porting). Two things were wrong, however. make hc-file-bundle Making the hc-file-bundle target failed, because not all rts/*.cmm had rts/*.hc counterparts after the build. The make fails because of this fragment from the Makefile (part of the hc-file-bundle target, starting from line 513): for f in `$(FIND) ghc-$(ProjectVersion)/compiler ghc-$(ProjectVersion)/rts -name "*.cmm" -follow -print` ""; do \ if test "x$$f" !=3D "x"; then \ echo `echo "$$f" | sed 's/cmm$$/hc/g' ` >> hc-files-to-go ; \ fi; \ done; This adds some non-existing .hc files to the hc-files-to-go list that tar will not find, later on, causing an error. I just added a test to see whether the file exists. If it does not, I call make for that .hc file explicitly, which solves the problem for most files. The files that don't have a make target, I simply omitted from the hc-files-to-go. I haven't been able to test the severity of this, because of the second problem. sh -e ./distrib/hc-build --prefix=3D$HOME/src/testbuild [--enable-hc-boot [--enable-hc-boot-unregisterised]] As a minor bug wrt. the wiki page, the hc-build is not executable by default. The more serious problem seems to be that the cold-boot option of configure is broken, because it ends in the error: checking for ld... /usr/bin/ld checking for path to top of build tree... ./configure: line 2651: -v0: command not found ./configure: line 2655: utils/pwd/pwd: No such file or directory configure: error: cannot determine current directory Upon inspection of the configure script, I found out that line 2651 uses the variable designating the ghc compiler. Are these bugs or am I messing things up? Regards, Philip ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
