Re: [Haskell-cafe] more on my ghc package issues
On Sat, 2008-04-12 at 23:33 -0500, Galchin, Vasili wrote:
2) This strongly looks like the package database manager, i.e.
ghc-pkg. Source please so I can understand where this d*amn unknown
package: unix-2.3.0.0 message is coming from and why?
Yes, ghc/ghc-pkg is giving this message because you're trying to use a
package that depends on a package that you unregistered. In your case,
you unregistered unix-2.3.0.0 but process-1.0.0.0 depended on that.
Cabal depends on process-1.0.0.0 which means you now cannot runghc
Setup.hs scripts because they all import Cabal.
Look at the output of ghc-pkg list. It marks in {} the packages that are
broken due to missing dependencies.
Remember you also have two package databases, the per-user one and the
global one. The per-user one is stored under ~/.ghc You can see the
exact path in the ghc-pkg list output. The packages from the user db
mask those from the global db, so if you have messed up the per-user one
then you will still get problems even if you reset the global one to
default. If you're just trying to get back to a known state then you can
delete the per-user ghc package db. ghc-pkg will re-create it next time
you register a package as a user.
3) Serious rant mode on ... I am a computer industry veteran(decades)
who is trying to convince, coggle, etc. younger colleagues about the
usefulness of FPLs for correctness, etc, and then = unknown
package .
The error messages from ghc-pkg are not very helpful and it does not
prevent you from removing packages which other packages still depend on.
The best advice at the moment is, don't un-register packages, at least
not without considering what other packages still depend on them.
There's no easy way of doing a reverse dependency lookup I think yet via
ghc-pkg. You can see direct dependencies, eg
$ ghc-pkg field containers depends
depends: base-3.0.1.0 array-0.1.0.0
As it happens, the latest version of Cabal gives a much better error
message in the case that you try to configure a package that depends on
a broken package. It says exactly which package is broken due to which
missing dependency.
In this case we'd get a message like:
The following installed packages are broken because other
packages
they depend on are missing. These broken packages must be
rebuilt
before they can be used.
package process-1.0.0.0 is broken due to missing package unix-2.3.0.0
It would be nice if ghc/ghci/runghc could give a similarly helpful error
message.
Duncan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)
Good day hackers, The Python community have been successful in standardizing an interface between web server and applications or frameworks resulting in users having more control over their web stack by being able to pick frameworks independently from web servers, and vice versa. I propose we try to do the same for Haskell. I've written half a draft for a Haskell version of Python's PEP 333 [1]. If you're interested in taking part in this effort please read through the Python spec first (as it is way more complete and you can understand this proposal better by reading it, I've skipped some important issues in my first draft) and then go read the Haskell spec [2]. I'm particularly interesting in feedback regarding: * Doing in this way won't work as it violates HTTP/CGI spec part X, Y and Z (the Python spec takes lots of things from the CGI spec including naming and semantics). * My server/framework could never provide/be run under this interface. * This interface has bad performance by design. * Using a different set of data types would work better. The spec needs to be extended to cover all the corners of HTTP. Some parts need to be motivated better. It is easier for me to motivate things if people would tell me what parts are badly motivated. Note: I'm open to a complete rewrite if needed. I'm not wedded to the current design and/or wording. In fact parts of the wording is borrowed from the Python spec. The parts with bad grammar are all mine. 1. http://www.python.org/dev/peps/pep-0333/ 2. http://www.haskell.org/haskellwiki/WebApplicationInterface -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)
Johan Tibell ha scritto: Good day hackers, The Python community have been successful in standardizing an interface between web server and applications or frameworks resulting in users having more control over their web stack by being able to pick frameworks independently from web servers, and vice versa. I propose we try to do the same for Haskell. I've written half a draft for a Haskell version of Python's PEP 333 [1]. If you're interested in taking part in this effort please read through the Python spec first (as it is way more complete and you can understand this proposal better by reading it, I've skipped some important issues in my first draft) and then go read the Haskell spec [2]. I'm very interested, thanks for the effort. I'm particularly interesting in feedback regarding: * Doing in this way won't work as it violates HTTP/CGI spec part X, Y and Z (the Python spec takes lots of things from the CGI spec including naming and semantics). * My server/framework could never provide/be run under this interface. * This interface has bad performance by design. * Using a different set of data types would work better. I'm not yet an Haskell expert, however one of the great feature of WSGI is that the environ is a Python dictionary. This means that the user can add new keys/values in it. I'm using this feature, in my WSGI implementation for Nginx (and in a mini framework I'm writing) to store user configuration in the environment, and to cache the result of the parsing of request headers. I'm not sure if this make sense in Haskell. The spec needs to be extended to cover all the corners of HTTP. Some parts need to be motivated better. It is easier for me to motivate things if people would tell me what parts are badly motivated. Note: I'm open to a complete rewrite if needed. I'm not wedded to the current design and/or wording. In fact parts of the wording is borrowed from the Python spec. The parts with bad grammar are all mine. 1. http://www.python.org/dev/peps/pep-0333/ 2. http://www.haskell.org/haskellwiki/WebApplicationInterface -- Johan Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)
On Apr 13, 2008, at 10:21 , Manlio Perillo wrote: I'm not yet an Haskell expert, however one of the great feature of WSGI is that the environ is a Python dictionary. This means that the user can add new keys/values in it. I'm using this feature, in my WSGI implementation for Nginx (and in a mini framework I'm writing) to store user configuration in the environment, and to cache the result of the parsing of request headers. I'm not sure if this make sense in Haskell. Er, that's just a StateT and possibly a ReaderT. I suspect a specific monad stack wrapping IO will end up being part of the interface anyway. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] install trouble with SDL on win32+cygwin
SDL works great on Windows, and you don't even need cygwin. Only ghc is required. There are instructions in the WIN32 file. http://darcs.haskell.org/~lemmih/hsSDL/hssdl/WIN32 2008/4/12 Conal Elliott [EMAIL PROTECTED]: Now I have sdl-config, but still not able to build. Does *anyone* have the SDL package running on Windows? If not, is GLFW the recommended cross-platform GL toolkit? Thanks, - Conal On Fri, Apr 11, 2008 at 8:55 PM, Luke Palmer [EMAIL PROTECTED] wrote: 2008/4/11 Conal Elliott [EMAIL PROTECTED]: I'm trying to install the SDL package (on win32+cygwin), and configure isn't able to find my SDL.dll, though it's on my PATH. Any ideas? - Conal bash-3.2$ cabal install SDL 'SDL-0.5.3' is cached. [1 of 1] Compiling Main ( Setup.lhs, dist\setup/Main.o ) Linking dist\setup\setup.exe ... Configuring SDL-0.5.3... checking for sdl-config... no I currently am not running cygwin, so I could be wrong, but the lack of sdl-config is a red flag. Have you installed sdl and sdl-devel (I think those are the package names) with the cygwin installer yet? Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] install trouble with SDL on win32+cygwin
Thanks very much for the pointer, Bit. I had to add \SDL to the end of this def: Include-Dirs: C:\SDL-1.2.12\include and I didn't need to change the Extra-Libraries line. I'm using cygwin, which may make a difference here. Next, I 'cabal install'ed SDL-ttf and discovered that I need the SDL_ttf lib, which I got, but I don't know where to unpack it so that the (Haskell) SDL-ttf will find it. Suggestions? - Conal On Sun, Apr 13, 2008 at 12:11 PM, Bit Connor [EMAIL PROTECTED] wrote: SDL works great on Windows, and you don't even need cygwin. Only ghc is required. There are instructions in the WIN32 file. http://darcs.haskell.org/~lemmih/hsSDL/hssdl/WIN32http://darcs.haskell.org/%7Elemmih/hsSDL/hssdl/WIN32 2008/4/12 Conal Elliott [EMAIL PROTECTED]: Now I have sdl-config, but still not able to build. Does *anyone* have the SDL package running on Windows? If not, is GLFW the recommended cross-platform GL toolkit? Thanks, - Conal On Fri, Apr 11, 2008 at 8:55 PM, Luke Palmer [EMAIL PROTECTED] wrote: 2008/4/11 Conal Elliott [EMAIL PROTECTED]: I'm trying to install the SDL package (on win32+cygwin), and configure isn't able to find my SDL.dll, though it's on my PATH. Any ideas? - Conal bash-3.2$ cabal install SDL 'SDL-0.5.3' is cached. [1 of 1] Compiling Main ( Setup.lhs, dist\setup/Main.o ) Linking dist\setup\setup.exe ... Configuring SDL-0.5.3... checking for sdl-config... no I currently am not running cygwin, so I could be wrong, but the lack of sdl-config is a red flag. Have you installed sdl and sdl-devel (I think those are the package names) with the cygwin installer yet? Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)
On Sun, Apr 13, 2008 at 4:59 AM, Johan Tibell [EMAIL PROTECTED] wrote: * Using a different set of data types would work better. Give that this is Haskell, I'd suggest more types ;) HTTP headers aren't just strings and, at the risk of tooting my own horn, I'll point to the Headers structure in [1]. Likewise, URLs have lots of structure that should just be handled in one place [2] [1] http://darcs.imperialviolet.org/darcsweb.cgi?r=network-minihttp;a=headblob;f=/Network/MiniHTTP/Marshal.hs [2] http://darcs.imperialviolet.org/darcsweb.cgi?r=network-minihttp;a=headblob;f=/Network/MiniHTTP/URL.hs AGL -- Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)
On Mon, 14 Apr 2008 11:06:43 Adam Langley wrote: On Sun, Apr 13, 2008 at 4:59 AM, Johan Tibell [EMAIL PROTECTED] wrote: * Using a different set of data types would work better. Give that this is Haskell, I'd suggest more types ;) HTTP headers aren't just strings and, at the risk of tooting my own horn, I'll point to the Headers structure in [1]. And it could go further. The use of a given header is often valid only in certain requests or responses. Perhaps sprinkling some phantom types or type classes around could represent that. Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [web-devel] RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)
In a sense, the CGIT interface provided by Network.CGI already is a sort of halfway implementation of what we're discussing, no? I'd be interested in approaching this from the other way -- specifying exactly what CGIT doesn't provide and therefore what folks want to see. As far as I can tell, the main issue with CGIT is that it doesn't handle streaming/resource issues very well. The main innovation I see provided here is the enumerator interface, which is a very nice and flexible approach to I/O and provides a way to handle comet cleanly to boot. Since the application type as proposed is Env - IO (Code, Headers, ResponseEnumerator), what we're really getting is almost an equiv. (modulo enumerators) of unwrapping CGIT IO CGIResponse with a run function. So what we lose is the ability for all our nicely named record accessors and functions to be shared across frameworks -- i.e. the flexibility a monad transformer *does* provide. So my question is if we can somehow preserve that with an appropriate typeclass. I'd ideally like to see this engineered in two parts -- a cgit-like typeclass interface that allows access to the environment but is agnostic as to response type, so that comet-style and other apps that take special advantage of enumerators can be built on top of it as well as apps that simply perform lazy writes; and the lower-level enumerator interface. This ideally would let the higher-level interface be built over any stack at all (i.e. STM-based as well, or even a pure stack), while the lower level interface that calls it is some glue of the given constant type in the IO monad. This would be of great help to hvac. There's also the fact that this could be designed ground-up with greater bytestring use, but that doesn't seem immense to me. Outside of this, I'm not quite sure what else CGIT lacks. I'm with Chris Smith's arguments as to the headers question, and it seems to me that dicts are best done using MVar-style primitives. I'm a bit at sea as to why the queryString is here just represented as a bytestring -- is it seriously an issue that some apps may want to use it other than in the standard parsed way? Is the idea here that lib functions would fill in and be shared among frameworks? On the other hand, seperating GET and POST vars is a good idea, and its a shame that CGIT doesn't allow this. The openness here seems in part based on the desire to keep different forms of file upload handling available. However, the work that oleg did with regards to CGI also seems promising -- i.e., rather than using an enumerator, simply taking advantage of laziness to unpack the input stream into a lazy dictionary. Regards, S. On Apr 13, 2008, at 7:59 AM, Johan Tibell wrote: Good day hackers, The Python community have been successful in standardizing an interface between web server and applications or frameworks resulting in users having more control over their web stack by being able to pick frameworks independently from web servers, and vice versa. I propose we try to do the same for Haskell. I've written half a draft for a Haskell version of Python's PEP 333 [1]. If you're interested in taking part in this effort please read through the Python spec first (as it is way more complete and you can understand this proposal better by reading it, I've skipped some important issues in my first draft) and then go read the Haskell spec [2]. I'm particularly interesting in feedback regarding: * Doing in this way won't work as it violates HTTP/CGI spec part X, Y and Z (the Python spec takes lots of things from the CGI spec including naming and semantics). * My server/framework could never provide/be run under this interface. * This interface has bad performance by design. * Using a different set of data types would work better. The spec needs to be extended to cover all the corners of HTTP. Some parts need to be motivated better. It is easier for me to motivate things if people would tell me what parts are badly motivated. Note: I'm open to a complete rewrite if needed. I'm not wedded to the current design and/or wording. In fact parts of the wording is borrowed from the Python spec. The parts with bad grammar are all mine. 1. http://www.python.org/dev/peps/pep-0333/ 2. http://www.haskell.org/haskellwiki/WebApplicationInterface -- Johan ___ web-devel mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/web-devel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)
Haskell works fine with both the FastCGI and SCGI protocols (There are libraries floating around for both), I have found them much nicer than any mod_* web server plugin in general. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)
On Sun, Apr 13, 2008 at 6:32 PM, Chris Smith [EMAIL PROTECTED] wrote: Does old code that handled these headers stop working, just because it was looking in the other section, but now needs to check a field dedicated to that header? Yes, but it would be very sad if we couldn't do common header parsing because of this. I'd suggest that all the headers given in RFC 2616 be parsed and nothing else. That leaves the question of how we would handle the addition of any extra ones in the future. Firstly, packages could depend on a given version of this interface and we declare that the set of handled headers doesn't change within a major version. Better would be some static assertion that the interface doesn't handle some set of headers. Maybe there's a type trick to do this, but I can't think of one, so we might have to settle for a non static: checkUnparsedHeaders :: [String] - IO () Which can be put in 'main' (or equivalent) and can call error if there's a mismatch. AGL -- Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)
I am very interested in this work. One thing missing is support for all HTTP methods, not just those in RFC 2616. As-is, something like WebDAV cannot be implemented. That probably means requestMethod should be a (Byte)String. What about something like sendfile(2) available on some platforms? To allow the server to make use of such optimizations, how about an optional alternative to the enumerator? Perhaps the app can optionally pass a path or an open fd back to the server in place of an enumerator, which allows servers to do any kind of buffering optimizations, etc, that they may know about, as well as using any platform-specific optimizations like sendfile. -- Michaeljohn Clement ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)
Adam Langley wrote: On Sun, Apr 13, 2008 at 4:59 AM, Johan Tibell [EMAIL PROTECTED] wrote: * Using a different set of data types would work better. Give that this is Haskell, I'd suggest more types ;) HTTP headers aren't just strings and, at the risk of tooting my own horn, I'll point to the Headers structure in [1]. That is one of the things I don't like about Network.HTTP, which also enumerates header fields. It is inconvenient to have to look up the names in the data type, when the standard field names are already known, and it makes using non-RFC2616 headers less convenient. Automatic parsing of header fields also makes unusual usage inconvenient, (for example the Range header support in [1] is a profile of RFC2616.) I think those kinds of features belong in frameworks; they will be more of an annoyance than a help to anyone that is writing to the WSGI layer. Likewise, URLs have lots of structure that should just be handled in one place [2] Yes, I think should be parsed to the level of granularity specified by RFC 2616 (i.e. scheme, host, port, path, query string) and anything more (like parsing query strings) should be handled by frameworks. [1] http://darcs.imperialviolet.org/darcsweb.cgi?r=network-minihttp;a=headblob;f=/Network/MiniHTTP/Marshal.hs [2] http://darcs.imperialviolet.org/darcsweb.cgi?r=network-minihttp;a=headblob;f=/Network/MiniHTTP/URL.hs AGL -- Michaeljohn Clement ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)
On Mon, 14 Apr 2008 13:32:07 Chris Smith wrote: On Sun, 13 Apr 2008 16:06:43 -0700, Adam Langley wrote: On Sun, Apr 13, 2008 at 4:59 AM, Johan Tibell [EMAIL PROTECTED] wrote: * Using a different set of data types would work better. Give that this is Haskell, I'd suggest more types ;) HTTP headers aren't just strings and, at the risk of tooting my own horn, I'll point to the Headers structure in [1]. Wait, I'm not sure I agree here. How are headers not just strings? Headers, at least their values, aren't strings. The specification says so. I think headers should be represented by something more specific than a string. By assuming that, are we guaranteeing that anything using this interface cannot respond gracefully to a client that writes malformed headers? Having explicit types for headers doesn't preclude trying to handle messages with malformed headers. Soldiering on in the face of malformed messages as a general strategy is pretty dubious in my opinion. In the specific cases where you've determined it is necessary you want to be able to register a work-around parser for that section of the message, and be able to tell that it has been used. A decent framework can supply a catalogue of commonly required work-arounds. Another perspective: there is unnecessary variation there in how interfaces are represented. If I'm looking for a header, and I know its name as a string, how do I look for it? Well, apparently it's either a named field (if it's known to the interface) or in the other section (if not). So I write a gigantic case analysis? But then suppose the interface is updated later to include some headers that popped up unofficially but then are standardized in a future RFC. (This is not too odd; lots of REST web services invent new headers every day, many of which do things that make sense outside of the particular application.) Does old code that handled these headers stop working, just because it was looking in the other section, but now needs to check a field dedicated to that header? I don't like the idea of having a fixed enumeration of methods or headers. You need to be able to define new methods and headers at will, and ideally have the usage of headers constrained to valid contexts. This suggests to me type classes that establish a 'can occur in' relationship between request/response, method and a given general/request/response/entity header. By importing new method or header data type, appropriate type class instances and registering an appropriate message parser extension you can mix and match which headers and methods you support. GET and HEAD are the only ones that MUST be supported after all. Daniel___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
