Re: [Haskell-cafe] Bug in HTTP (bad internal error handling)
On Fri, Oct 22, 2010 at 9:35 AM, Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com wrote: Bit Connor wrote: On Sat, Oct 16, 2010 at 10:29 AM, Claus Reinke claus.rei...@talk21.com wrote: After it catches this error, the function returns (line 376): return (fail (show e)) The fail is running in the Either monad (The Result type = Either). This calls the default Monad implementation of fail, which is just a call to plain old error. This basically causes the entire program to crash. Actually, it appears that simpleHTTP isn't actually supposed to throw an IOException, and it is instead supposed to return a ConnError result. So the real fix is to fix the code to make this happen. But Sounds like a victim of http://hackage.haskell.org/trac/ghc/ticket/4159 For mtl clients, 'fail' for 'Either' used to call 'Left'. That was changed, though the ticket does not indicate the library versions affected. This looks like the problem. Any idea how to get the HTTP package fixed? I could try making a patch myself, but I would prefer hearing from the HTTP maintainer first, who doesn't seem to be around. I've tried contacting him a few times about getting the base dependencies in HTTP bumped and an upload made, without success. This is a widely used package that's in the platform and that won't work with GHC 7.0 with the current dependencies, so it really needs to get fixed soon. libraries@, what's the right way to proceed? Can I make a Debian-style non-maintainer upload with minimal changes to fix urgent issues like these? I'd be much obliged if you could, and I do apologise for leaving all of this just hanging. No time available for Haskell projects these days unfortunately, Opera engine development taking up most of my waking hours. Getting someone to take over HTTP would be best, or maybe rewrite it altogether..it is not the prettiest thing around :) --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHCI Curl under Windows
On Wed, 03 Jun 2009 05:27:53 -0700, Martin Huschenbett hus...@gmx.org wrote: Hi Haskellers, I've installed the newest Haskell Platform under Vista and downloaded a pre compiled version of curl-7.19.4 for MinGW. After changing the build type in curl.cabal to Simple and supplying the needed paths I could even build and install curl for haskell. If I write a program using curl and compile it with GHC everything works fine. But if I try to execute the main function of my program in GHCI I always get the following error message: Loading package curl-1.3.5 ... linking ... interactive: C:\Devel\Haskell\curl-1.3.5\ghc-6.10.3\HScurl-1.3.5.o: unknown symbol `__imp__curl_easy_getinfo': unable to load package `curl-1.3.5' Did anybody have the same problem and knows how to fix it? Hi Martin, perhaps you already have, but did you go through this writeup http://haskell.forkio.com/Home/curl-win32 and see if there are useful pointers there that might help? --sigbjorn -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiling on windows - again
-optl-mwindows is the magic incantation to use. --sigbjorn On 4/28/2009 17:37, Gü?nther Schmidt wrote: Hi guys, I'm sorry, I asked this before ... What is the flag you have to pass during ghc --make in order to produce an exe on Windows that doesn't open a DOS window. Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Bamse-0.9.4, a Windows Installer generator
Hi, various people have over the years suggested and tried using WiX from Haskell, so I'll leave it to them to comment possibly compare the two. I'm sure it blows Bamse out of the water as far as functionality goes. --sigbjorn On 4/26/2009 11:00, Justin Bailey wrote: How does this compare to WiX? I haven't looked at the docs yet ... On Sat, Apr 25, 2009 at 4:59 PM, Sigbjorn Finne sigbjorn.fi...@gmail.com wrote: Hi, a new version of Bamse has been uploaded to hackage, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bamse Bamse is a package and application for letting you quickly put together Windows Installers for your software projects/products from within the comforts of Haskell. New in this release is the support for generating MSIs from your Cabal projects, having them either be built from source or just have them be installed and registered at install-time. i.e., one-click installation of Cabal packages. See examples/Cabal.hs for a worked example of how to bundle up Cabal packages. I've found this functionality a bit useful, hope others do too. The new version also adds support for handling .NET assemblies. enjoy --sigbjorn ___ 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] ANN: Bamse-0.9.4, a Windows Installer generator
Hi, a new version of Bamse has been uploaded to hackage, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bamse Bamse is a package and application for letting you quickly put together Windows Installers for your software projects/products from within the comforts of Haskell. New in this release is the support for generating MSIs from your Cabal projects, having them either be built from source or just have them be installed and registered at install-time. i.e., one-click installation of Cabal packages. See examples/Cabal.hs for a worked example of how to bundle up Cabal packages. I've found this functionality a bit useful, hope others do too. The new version also adds support for handling .NET assemblies. enjoy --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haxr build failure from cabal
Hi Jeff, I have an updated and _seemingly_ working version of the haxr codebase, but haven't had a chance to test it more than a gentle poke at the tires. Will see if I can upload commit the bits. --sigbjorn On 4/22/2009 07:37, Jeff Heard wrote: haxr will no longer compile from cabal because of the dependency marked HTTP 1.0. The current version of the library requires HTTP 4000.0.0 as it stands. Can it be updated real quick in hackage? -- Jeff ___ 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] haxr build failure from cabal
OK, new release of haxr available via hackage; compilable with ghc-6.10.1 (but may very well have bootstrap issues with 6.10.2 due to 'time' dependency) http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haxr enjoy --sigbjorn Sigbjorn Finne wrote: Hi Jeff, I have an updated and _seemingly_ working version of the haxr codebase, but haven't had a chance to test it more than a gentle poke at the tires. Will see if I can upload commit the bits. --sigbjorn On 4/22/2009 07:37, Jeff Heard wrote: haxr will no longer compile from cabal because of the dependency marked HTTP 1.0. The current version of the library requires HTTP 4000.0.0 as it stands. Can it be updated real quick in hackage? -- Jeff ___ 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] ANN: HTTP-4000.0.6
Hi, a refresh release of the HTTP package has been uploaded to Hackage, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HTTP Robust handling of ill-formed cookies + squash a bug in normalization of certain proxy-bound requests would be the (minor) headlines of this release. enjoy --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: curl-1.3.5
Hi, a refresh release of the Haskell (lib)curl package has been uploaded to Hackage, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/curl It enables 6.10.2 use, taking into account the updated story on how to register Haskell-based finalizers. Thanks to Carl Howells for reporting this problem. Bug reports / feature requests etc. most welcome, btw. enjoy --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Announce: A pragmatic Haskell .NET interop layer, 0.4.0
A new version of a Haskell .NET interop layer, hs-dotnet, has just been released and is now available for download, http://haskell.forkIO.com/dotnet It lets you access .NET functionality from Haskell and vice versa. Tool support is included in this release to aid such interop. The new version includes development done since the start of the year. Apart from rewriting the internals completely to put it all on a sounder footing, this release includes proper support for .NET generic types (classes and interfaces), mapping them naturally on to Haskell parameterized types. The support for generics enables for instance mixed Haskell-.NET LINQ programming; see the distribution for examples of this along with some other interesting applications of the hs-dotnet interop layer. enjoy --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: new release of HTTP, version 4000.0.5
Hi, a new version of the HTTP package - 4000.0.5 has been uploaded, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HTTP Includes a bunch of fixes and cleanups (thanks to all that have reportedcontributed), along with some (shock, horror) API documentation. Let me know if it appears to be well behaved and dependable. thanks --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haxr doesn't compile from cabal (HTTP 4000 breaks it)
On 3/12/2009 07:51, Jeff Heard wrote: The haxr cabal library dependencies seem to be off. I wonder, since haxr would benefit highly from the HTTP 4k series of performance improvements, is it trivial to make it compatible with the latest library? Hi Jeff, the required changes shouldn't be pervasive nor hard, but if it turns out non-trivial or unappealing in any way, please get in touch. thanks --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Help on using System.Win32.Com.Automation
Hi Wilkes,
you may want to have a look at a simple example of how to
interop with Windows WMI using the COM package at --
http://haskell.forkio.com/com-examples
Hope it is of some help to you.
--sigbjorn
On 3/19/2009 16:49, Wilkes Joiner wrote:
I'm playing around with the com package, but I'm having a hard time
understanding how to map a COM call to the appropriate methodN or
functionN call. Does anyone have any example code that uses the
method1 or higher. Any help or pointers would be appreciated.
Here's the code I have so far:
import System.Win32.Com
import System.Win32.Com.Automation
dsn = Provider=vfpoledb.1;Data Source=C:\\SomeDirectory\\
main = coInitialize
openConnection = \con -
closeConnection con
openDSN :: String - IDispatch a - IO ()
openDSN dsn con = method0 Open [inString dsn] con
openConnection :: IO (IDispatch a)
openConnection = createObject ADODB.Connection = \con - openDSN
dsn con return con
closeConnection :: IDispatch a - IO ()
closeConnection = method0 Close []
{-
Wraps ADO Connection.Execute
http://msdn.microsoft.com/en-us/library/ms675023(VS.85).aspx
Set recordset = connection.Execute (CommandText, RecordsAffected, Options)
execute :: String - IDispatch a - IO a
execute cmd con = method1 Execute [inString cmd] (inEmpty,resWord64) con
-}
Thank You,
Wilkes
___
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] Help on using System.Win32.Com.Automation
Alexandr N. Zamaraev wrote: Sigbjorn Finne wrote: Hi Wilkes, you may want to have a look at a simple example of how to interop with Windows WMI using the COM package at -- http://haskell.forkio.com/com-examples I try compile WMIDemo.hs but recive error: [code] c:\htestghc --make WMIDemo.hs [2 of 2] Compiling WMIDemo ( WMIDemo.hs, WMIDemo.o ) WMIDemo.hs:24:2: Couldn't match expected type `[a]' against inferred type `(a1, b)' ... Hi, please upgrade to the latest version - 1.2.2 - of the com package for this example, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/com There's been some improvements to the lib, esp. the handling of enumerations (which is where that type error is coming from.) hth --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] curl w/ ghc-win32
Hi, there's a steady stream of people reporting that getting started with curl on Windows is cumbersome and tricky to get right. A legitimate complaint! :-) To hopefully help out a bit in that regard, I've put together some notes covering the steps reqd + made available a pre-packaged curl binary dist -- http://haskell.forkio.com/Home/curl-win32 enjoy.. :) --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Error in HTTP 4.004 + CouchDB?
Thanks Alex,
contacting the maintainer of a package rather than author is probably
the best course of action in general. They may both be out of date,
but the former maybe less so. :)
As verified offline, you issue this request via sendHTTP when experiencing
this misbehavior.
A couple of suggestions on what to do:
* Use Network.Browser instead and send it via (browse $ request req),
which will normalize the path and Host: headers as you expect for
(non-proxy)
use.
* pull down the latest bits from the repository and normalize your request
prior to calling sendHTTP by using
(Network.HTTP.Base.normalizeRequest False{-no proxy-} req)
(we're in a tight spot wrt. backwards compatibility for sendHTTP, so
having
it perform this normalization step by default would break code that
now interacts
with proxies via sendHTTP.)
The repository version also has support for custom request verbs, which
might be
of interestuse to some.
Let me know how it goes -- git repository URL available via
http://projects.haskell.org/http/
hth
--sigbjorn
On 1/22/2009 11:32, Alex Ott wrote:
Hello
(i sent this message to the mail of author, specified at hackage, but it
returned to me, so i decided to resend it here)
I found strange thing during work with latest versions of CouchDB HTTP
module on my Mac OS X 10.4. The problem is, that when i send document to
the couchdb server, it name was cut to the 2 characters.
After some investigation i found, that this is problem in combination of
the CouchDB + HTTP usage. CouchDB module fills out the Request structure,
and specify scheme authority fields. This lead that i see (in network
dumps) following data:
I tried to fix this problem myself, but I'm novice in the industrial
Haskell programming ;-)
P.S. this code from (CouchDB/HTTP.hs) will restore proper behaviour of the
code, but break Host header
makeURL path query = CouchMonad $ \conn - do
return ( (ccURI conn) { uriPath = '/':path
, uriQuery = if null query then else
'?':(urlEncodeVars query)
, uriScheme =
, uriAuthority = Nothing
}
,conn )
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: HTTPbis / HTTP-4000.x package available
On 1/17/2009 08:21, Tim Newsham wrote: There's however still no framework which supports both HTTP client and server functions using the same Request and Response data type, right? I don't know whether I am the only one who needs this (e.g. for the Real Monad Transformer). E.g. a proxy would need this, too. I've wanted this for a while now. Me Too. Tim Newsham http://www.thenewsh.com/~newsham/ There's the basic receiveHTTP and respondHTTP that Network.HTTP.Stream Network.HTTP.HandleStream exports. But that is probably not enough for your uses, I suspect. To ensure that this feature request isn't dropped or forgotten about, please add a ticket for it via the (new-homed) HTTP web pages -- http://projects.haskell.org/http/ Or, better still :-), contribute the code...to HTTP or some existing web server framework. thanks --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: HTTP-4000.0.4 released
Hi, a new release of HTTP, version 4000.0.4, is now available http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HTTP It is also pointed at via the updated HTTP web page -- http://projects.haskell.org/http/ The main change is the addition of registering a Browser event handler for capturing state changes to the request-response processing pipeline. An experimental change, see Network.Browser.setEventHandler (Feature suggested by Yuval Kogman in order to accommodate load testing.) enjoy --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Slow Text.JSON parser
Maybe. Handling the common cases reasonably well is probably worth doing first (+profiling) before opting for a heartlung transplant.. To wit, I've trivially improved the handling of string and integer lits in version 0.4.3 (just released.) It cuts down the running times by a factor of 2-3 on larger inputs -- http://hackage.haskell.org/cgi-bin/hackage-scripts/package/json Not saying that there aren't additional wins to be had :) hth --sigbjorn On 1/17/2009 14:50, Don Stewart wrote: It occurs to me you could also use attoparsec, which is specifically optimised for bytestring processing. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: HTTPbis / HTTP-4000.x package available
Thanks Jeff, regarding having to use both HTTP and cURL -- or perhaps only the latter for code simplicitly -- that will probably remain the case for quite a while still. To help with that situation, I put together an over-arching 'webclient' library that abstracts over the transport layers (HTTP, curl, curl-shell) giving you an API that's consistent across backends. I could release that at some point if there's sufficient interest.. It also adds WebDAV support. Re: curl - as an author of the 'curl' package, I'm also keen on finding ways of making that better -- both in terms of using the underlying lib functionality and API on the Haskell side. Suggestions/contribs most welcome. Ditto for HTTP too, of course :) --sigbjorn On 1/16/2009 05:47, Jeff Heard wrote: Just as a reported speedup, downloading a 5MB file from my own local machine (via http) went from 1.05 secs to 0.053 secs. Yes, it's really an order of magnitude better. Performance now is on par or slightly better than cURL (however to get more protocols than HTTP, you'll still need the ubiquitous cURL library) On Fri, Jan 16, 2009 at 1:36 AM, Sigbjorn Finne sigbjorn.fi...@gmail.com wrote: Hi, I guess it's time to publish more widely the availability of a modernization of the venerable and trusted HTTP package, which I've been working on offon for a while. Bunch of changes, but the headline new feature of this new version is the parameterization of the representation of payloads in both HTTP requests and responses. Two new representations are supported, strict and lazy ByteStrings. Some people have reported quietly pleasing speedups as a result of this change. (If they want to report numbers, please do..) Another change/fix in this release is the _alleged_ fix to the long-standing bug in the use of absolute URIs vs absolute paths in requests (for non-proxied and proxied use.) Give it a go.. Notice that the HTTP-4000.x version will require you to make some modifications to your existing HTTP-using code -- I've tried to keep the API backwards compatible minimal despite the change in functionality and underlying types. If you do not want to deal with this right away, please introduce a 4000 dependency on the HTTP package in your .cabal files. I've also taken on the maintainership of the package, with the highly esteemed Bjorn Bingert no longer having the usual abundance of cycles to look after it (hope I'm not misrepresenting facts here, Bjorn!) However, I've yet to gain access to www.haskell.org and update http://www.haskell.org/http, so for now you may pick up a new version the lib via http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HTTP GIT repo for HTTP-4000 / HTTPbis is here git://code.galois.com/HTTPbis.git enjoy --sigbjorn ___ 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] ANN: HTTPbis / HTTP-4000.x package available
Hi Levi, I'm guessing that you are reading something different into that than what's intended - it's client-side in the sense that it can only issue web requests and handle their responses. i.e., it doesn't handle incoming HTTP requests and issue suitable responses. Web server implementation is an interesting problem in its own right, and many packages/frameworks do an admirable job of that already, so no plans (by me) to tackle that via the HTTP package. But, utilizing the HTTP package as part of any web app you expose on a web server is very much on and not out of bounds. Go for it! :-) Does that answer your Q? (my apologies if I'm stating the obvious above.) cheers --sigbjorn Levi Greenspan wrote: Sounds very good to me. However I would like to as one question regarding the HTTP lib. On hackage I read: HTTP: A library for client-side HTTP. Maybe you or someone on this list can tell me what the restrictions of the HTTP library are that restrict it to client side. What would be required to enable it for server-side use as well? Is it planed to complete HTTP this way? Many thanks, Levi ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: hs-dotnet, version 0.3.0
On 1/15/2009 06:19, John Goerzen wrote: Sigbjorn Finne wrote: ... Nice! Has there been any effort to support Mono? Only in spirit so far. I'm keen to find the time to do it and if it would directly help people having Mono as a deployment target, even better. thanks --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: hs-dotnet, version 0.3.0
Thanks Yitzchak, I'm thinking and acting on having that available in your quiver have prototyped the ability to do so a couple of times in the past (stand-alone Haskell code as fully fledged .NET classes/assemblies, both the dynamic and static kind.) I didn't want to hold up the initial release to do this right now _and_ would really like to get a better gauge at how important having that piece would be to users looking to use Haskell in a .NET context. There's only so much time it seems, but no shortage of interesting projects to hack on :-) cheers --sigbjorn On 1/15/2009 03:14, Yitzchak Gale wrote: Sigbjorn Finne wrote: the first public release of hs-dotnet is now available Fantastic accomplishment! I can only repeat dons' comment - this could be game-changing. Some obvious questions that come to mind: We see that it is already possible to expose a Haskell function to .NET as a callback. That's exciting! Can we go to the next step and register it as part of an assembly? Is it be possible for a running .NET app to fire up the GHC runtime and call into compiled Haskell? Is it possible at all for a .NET function not to have any side effects? If so, is there any way to label it as such and then call it from Haskell outside of the IO monad? Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: HTTPbis / HTTP-4000.x package available
Hi, I guess it's time to publish more widely the availability of a modernization of the venerable and trusted HTTP package, which I've been working on offon for a while. Bunch of changes, but the headline new feature of this new version is the parameterization of the representation of payloads in both HTTP requests and responses. Two new representations are supported, strict and lazy ByteStrings. Some people have reported quietly pleasing speedups as a result of this change. (If they want to report numbers, please do..) Another change/fix in this release is the _alleged_ fix to the long-standing bug in the use of absolute URIs vs absolute paths in requests (for non-proxied and proxied use.) Give it a go.. Notice that the HTTP-4000.x version will require you to make some modifications to your existing HTTP-using code -- I've tried to keep the API backwards compatible minimal despite the change in functionality and underlying types. If you do not want to deal with this right away, please introduce a 4000 dependency on the HTTP package in your .cabal files. I've also taken on the maintainership of the package, with the highly esteemed Bjorn Bingert no longer having the usual abundance of cycles to look after it (hope I'm not misrepresenting facts here, Bjorn!) However, I've yet to gain access to www.haskell.org and update http://www.haskell.org/http, so for now you may pick up a new version the lib via http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HTTP GIT repo for HTTP-4000 / HTTPbis is here git://code.galois.com/HTTPbis.git enjoy --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HEADS UP: finalizer changes coming in GHC 6.10.2
Thanks Simon, great stuff; I like the introduction of these 'native code finalizers', they've been sorely missed at times. You don't say, but will there be a dynamic check to catch such re-entries? --sigbjorn On 1/14/2009 04:14, Simon Marlow wrote: By popular demand, GHC 6.10.2 will support finalizers that are actually guaranteed to run, and run promptly. There aren't any API changes: this happens for finalizers created using newForeignPtr as normal. However, there's a catch. Previously it was possible to call back into Haskell from a finalizer (finalizers are C functions), by using foreign import wrapper or foreign export. According to the FFI spec, whether this is allowed or not is system dependent. In GHC 6.10.1 and earlier it was allowed, but in 6.10.2 and later it is not. The reason being that C finalizers are now executed directly by the GC, when the runtime is not in a position to handle callbacks. You can still have fully-fledged Haskell finalizers if you want: we have Foreign.Concurrent.newForeignPtr for that purpose. But those finalizers are not subject to the same promptness guarantees that you get with C finalizers - they run in a separate thread, and are not guaranteed to be run at program exit. We'll make sure this is documented prominently in the 6.10.2 release notes, but I thought a heads-up would be a good idea right now as it turns out that there are existing libraries (e.g. LLVM) that will be affected. Cheers, Simon ___ 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] ANN: hs-dotnet, version 0.3.0
Hi, the first public release of hs-dotnet is now available - a pragmatic take on interoperating between Haskell (via GHC) and .NET. For downloads and (some) info, see: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hs-dotnet http://haskell.forkIO.com/dotnet Feedback most welcome, both on what's there and what you would like to see better handled/supported next. enjoy --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: json-0.4.1
Hi, a new release of the 'json' package is now available via hackage, version 0.4.1 http://hackage.haskell.org/cgi-bin/hackage-scripts/package/json [no claims that it represents rocket science, but a number of downstream codebases depend on this package for their operation, hence the announcement here.] New in this release is a generic JSON encoder contributed by Lennart Augustsson (Text.JSON.Generic ; thanks Lennart!) along with a number of other, smaller changes (including changes to the default encoding for constructors and prelude types - no longer down-cased; see release notes for more.) Enjoy --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Linking in GMP as a Windows DLL w/ GHC
Hi, a number of folks have been asking/looking for ways to avoid statically linking in GMP into GHC binaries under Windows. I've written up some notes on how to go about doing this, which are now available from http://haskell.forkio.com/gmpwindows Let me know if it is useful (or works ;-) ) enjoy --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: getServiceEntry: does not exist on Windows
I don't really have the time, but here's some debugging code that'll maybe help diagnosing why/if WinSock is failing to start up: - compile the attached initws.c via ghc, foo$ ghc -c initws.c - run some tests foo$ ghc -package net IWS.hs initws.o -e initWS 1 1 = print foo$ ghc -package net IWS.hs initws.o -e initWS 2 2 = print foo$ ghc -package net IWS.hs initws.o -e initWS 1 1 Network.BSD.getProtocolByName \tcp\ = print foo$ ghc -package net IWS.hs initws.o -e initWS 2 2 Network.BSD.getProtocolByName \tcp\ = print initWS returns 0 on success. The GHC networking support is ultra-conservative wrt WinSock versioning, sticking with 1.1 for max portability. Perhaps that's working against us here? Needless to say, this is working for me (on a pair of XP boxes.) --sigbjorn - Original Message - From: Joel Reymont [EMAIL PROTECTED] To: Simon Marlow [EMAIL PROTECTED] Cc: Haskell Cafe haskell-cafe@haskell.org; [EMAIL PROTECTED] Sent: Friday, October 21, 2005 06:31 Subject: Re: [Haskell-cafe] Re: getServiceEntry: does not exist on Windows It stopped happening for me on WinXP but it's still happening for my customer on Win2K. On Oct 21, 2005, at 1:45 PM, Simon Marlow wrote: Nope, actually it also happens for me with the updated installer. Sigbjorn - any ideas? It doesn't happen with my local STABLE build, but I'm still using gcc 3.2.x. initws.c Description: Binary data IWS.hs Description: Binary data ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hugs segmentation fault
Jon Fairbairn [EMAIL PROTECTED] writes: On 2004-10-29 at 00:50BST Ben Rudiak-Gould wrote: Jon Fairbairn wrote: Well, here's a sample session I recorded just now: C:\\ghc\ghc-6.2.1\bin\ghci Prelude let p = 1 : [2 * x | x - p, x 1] in p [1*** Exception: loop Prelude 123 Fail: thread blocked indefinitely C:\ Does this only happen to me? I'm using Linux, you Windows. I suspect there's a hint there. Has this been reported to Glasgow Haskell bugs? (cc'd) Plenty of times, but maybe not that particular manifestation of the problem. Fixed in 6.2.2 --sigbjorn ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: HDirect, [unique], troubles again!
Two things not quite working out here:
- HDirect treated 'unique' as 'ref' for function pointers;
that's easier to work with if 'unique' was the inferred/default
kind, but clearly not what you want if you explicitly supplied
a 'unique' attribute.
- The by-ref marshallers for function types have types with shapes
slightly different from other by-ref marshallers. Hence, extra
care is required when emitting marshallers for types that contain
them.
Both of these issues have now been fixed in the CVS repository.
--sigbjorn
- Original Message -
From: Vincenzo aka Nick Name [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Sigbjorn Finne [EMAIL PROTECTED]
Sent: Wednesday, May 05, 2004 13:51
Subject: HDirect, [unique], troubles again!
In my quest for a fuse binding for Haskell, which I really need at the
moment, I have the following definition working:
module HSFuse {
interface stat{};
typedef int getattrT([string] char *,stat);
typedef struct fuseOps {
[ref] getattrT * getattr;
} fuseOps;
void fuse_main(int argc,[in,string,size_is(argc)]char** argv,[ref]
fuseOps * op);
};
but when I substitute ref with unique, because some operations can
be null, I get the errors below. The problem is that in the generated
hs file there is
data FuseOps = FuseOps {getattr :: GetattrT}
which completely ignores my type declaration! Did I do something wrong?
Commands invoked and errors follow, thanks for attention:
ihc -fhs-to-c -fuse-ints-everywhere -c HSFuse.idl
ghc -package hdirect -fglasgow-exts HSFuse.hs -c
HSFuse.hs:136:
Couldn't match
`GHC.Base.String - Stat - GHC.IOBase.IO GHC.Base.Int'
against
`GHC.Ptr.Ptr
(GHC.Base.String - Stat - GHC.IOBase.IO GHC.Base.Int)'
Expected type: GHC.Ptr.Ptr
(GHC.Ptr.Ptr
(GHC.Base.String - Stat -
GHC.IOBase.IO GHC.Base.Int))
- GHC.Ptr.Ptr
(GHC.Base.String - Stat - GHC.IOBase.IO
GHC.Base.Int)
- GHC.IOBase.IO ()
Inferred type: GHC.Ptr.Ptr
(GHC.Ptr.Ptr
(GHC.Base.String - Stat -
GHC.IOBase.IO GHC.Base.Int))
- (GHC.Base.String - Stat - GHC.IOBase.IO
GHC.Base.Int)
- GHC.IOBase.IO ()
In the second argument of `HDirect.writeunique', namely
`writeGetattrT'
In the definition of `writeFuseOps':
writeFuseOps ptr (FuseOps getattr)
= let
pf0 = ptr
pf1 = HDirect.addNCastPtr pf0 0
in
HDirect.writeunique (HDirect.allocBytes
(GHC.Real.fromIntegral sizeofGetattrT))
writeGetattrT
pf1
getattr
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: read from URL
Sebastian Schulz [EMAIL PROTECTED] writes:
Is it possible to read a file from a webaddress? Something like:
... do file - readFile_ "http://..."
dosomething file
...
Attached is a from-the-hip Haskell module I wrote sometime ago
to do this. It provides the action:
getURL :: String{-the URL-} - IO String
As is, it only supports the http:// protocol, but hopefully a
useful starting point. The module depends on hslibs libraries,
which effectively means that it is currently GHC dependent(?)
hth
--sigbjorn
begin 600 WWWLib.lhs
M)0T*)2`H8RD@,3DY.2P@V]F#0HE#0H-"DQI8G)AGD@9F]R(')E861I;F@
MW1U9F8@9G)O;2!54DQS+B!5V5S('-O8VME="!L:6)R87)I97,N#0H-"EQB
M96=I;GMC;V1E?0T*;6]D=6QE(%=75TQI8B`H9V5T55),+"!D96-O9554DPI
M('=H97)E#0H-"BTM:6UP;W)T($=L845X=',-"FEM]R="!3;V-K970-"FEM
M]R="!)3PT*:6UP;W)T($-H87(@*"!IT1I9VET("D-"FEM]R="!,:7-T
M#0I96YDV-O95]#0H-"F=E=%523"!D96-O95S($@55),(%N9"!IW-U
M97,@=AE(')E75EW0@=\@9F5T8V@-"G1H92!R97-O=7)C92]D;V-U;65N
M="!H:61I;F@8F5H:6YD(ET+B!!="!T:4@;6]M96YT#0I(5%10(ES('1H
M92!O;FQY('!R;W1O8V]L('-U'!OG1E9"X-"@T*7)E9VENV-O95]#0IG
M97154DP@.CH@4W1R:6YG("T^($E/(%-TFEN9PT*9V5T55),('5R;"`](`T*
M("`@8V%S92!D96-O9554DP@=7)L(]F(`T*("`@("!.;W1H:6YG(`DM/B`@
MF5T=7)N("(B#0H@("`@($IUW0@*'!R;W1O+"!M86-H:6YE+"!P;W)T+"!F
M:6QE*2`M/@T*("`@("`@("`@(9E=-H55),('!R;W1O(UA8VAI;F4@]R
M="!C;VUM86YD(#X^/2!H1V5T0V]N=5N=',-"@EW:5R90T*("`@"2!C;VUM
M86YD(#T@#0H@("`@("`@("`@("!C87-E('!R;W1O(]F#0H@("`@("`@("`@
M("`@(")H='1P(B`M/B`B1T54("(@*RL@9FEL92`M+2!W86YT('1O()E(%B
M;4@=\@W5PQY(UOF4@:5R92X-"B`@("`@("`@("`@("`@7R`@("`@
M("T^(9I;4-"@T*75N9'MC;V1E?0T*#0I4:4@')I;6ET:79E(%C=EO
M;B!F;W(@;W!E;FEN9R!A;F0@:7-S=6EN9R!A(%523"!R97%U97-T+@T*#0I)
M;G-T96%D(]F('1A:VEN9R!A('-TFEN9R!W:EC:"!IR!T:4@8V]M;6%N
M9"!T;R!F:7)E(]F9@T*=\@=AE('-EG9EBP@:70@=VEL;"!PF]B86)L
M2!H879E('1O()E(5X=5N95D('1O(%C8V5P=`T*86X@:6YI=EA;ES
M871I;VX@86-T:6]N("AW86YT('1O()E(%B;4@=\@8W)E871E("=R96%L
M)PT*2%144"!R97%U97-TRP@9F]R(ENW1A;F-E+BD-"@T*7)E9VENV-O
M95]#0IF971C:%523"`Z.B!3=')I;F-"@D@+3X@4W1R:6YG#0H)("T^($EN
M=`T*"2`M/B!3=')I;F-"@D@+3X@24\@2%N9QE#0IF971C:%523"!PF]T
M;R!M86-H('!OG0@8V]M;6%N9"`](1O#0H@(AD;"`@/"T@8V]N;F5C=%1O
M(UA8V@@*%!OG1.=6UB97(@*UK4]R=$YU;6)EB!P;W)T*2D-"B`@:%!U
M=%-TDQN(AD;"!C;VUM86YD#0H@(A3971"=69F97)I;F@:1L($QI;F5"
M=69F97)I;F-"B`@F5T=7)N(AD;`T*75N9'MC;V1E?0T*#0HJ0F%S:6,J
M(%523"!P87)S97(N#0H-"EQB96=I;GMC;V1E?0T*95C;V1E55),(#HZ(%-T
MFEN9R`M/B!-87EB92`H4W1R:6YG+"!3=')I;FL($EN="P@4W1R:6YG*0T*
M95C;V1E55),('5R;"`]('!AG-E55),('5R;`T*("!W:5R90T*("`@%R
MV554DP@;',@/2!R=6Y-32!LR`D(1O#0H@("`@("`@')O=\@/"T@9V5T
M4')O=]C;VP-"B`@("`@("!M86-H("`\+2!G971-86-H:6YE#0H@("`@("`@
M]R="`@/"T@9V5T4]R=`T*("`@("`@(9I;4@(#PM(=E=$9I;4-"B`@
M("`@("!R971UFX@*'!R;W1O+UA8V@L]R="QF:6QE*2`-"@T*9V5T4')O
M=]C;VP@/2!L:69T("`H8G)E86M!=%-U8E-TFEN9R`B.B\O(BD-"F=E=$UA
M8VAI;F4@(#T@;EF=#$@*)R96%K("A(-H("T^(-H(#T]("Z)R!\?"!C
M:"`]/2`G+RI*0T*#0IG9710;W)T(#T@#0H@("`@(QI9G0Q("0@7"!LR`M
M/@T*("`@("!C87-E(QS(]F#0H@("`@("`@*"Z)SIXRD@+3X-"B`@("`@
M("`@(-AV4@8G)E86L@*YO="YIT1I9VET*2!XR!O9@T*("`@("`@("`@
M("APG0L('ES*2`M/B`-"@D@("`@("!C87-E(')E861S('!R="!O9@T*"2`@
M("`@("`@6UT@("`@+3X@*#@P+"!YRD-"@D@("`@("`@("@H"Q?*3I?*2`M
M/B`H"P@('ES*0T*("`@("`@(%\@+3X@*#@P+"!LRD-"B`@("`-"@T*9V5T
M1FEL92`](QI9G0Q("A('@@+3X@*'@L6UTI*0T*75N9'MC;V1E?0T*#0I
M8F5G:6Y[8V]D97T-"FYE=W1Y4@34T@82`]($U-("A3=')I;F@+3X@36%Y
M8F4@*$L(%-TFEN9RDI#0H-"G)U;DU-(#HZ(%-TFEN9R`M/B!-32!A("T^
M($UA6)E($-"G)U;DU-('-TB`H34T@9BD@/2`-"B`@8V%S92!F('-TB!O
M9@T*("`@($YO=AI;F@("`@+3X@3F]T:EN9PT*("`@($IUW0@*'@L7RD@
M+3X@2G5S="!X#0H-"FQI9G0@.CH@*%-TFEN9R`M/B!-87EB92`H82Q3=')I
M;FI*2`M/B!-32!A#0IL:69T(8@/2!-32!F#0H-"FQI9G0Q(#HZ("A3=')I
M;F@+3X@*$L4W1R:6YG*2D@+3X@34T@80T*;EF=#$@9B`]($U-("A('@@
M+3X@2G5S="`H9B!X*2D-"@T*:6YS=%N8V4@36]N860@34T@=VAEF4-"B`@
MF5T=7)N('@@("`@(#T@34T@*%P@R`M/B!*=7-T("AX+',I*0T*("`H34T@
M;2D@/CX](L@/2`-"B`@("!-32`H7"!S("T^(`T*("`@("`@("`@(-AV4@
M;2!S(]F#0H)("`@($YO=AI;F@("`@("T^($YO=AI;F-"@D@("`@2G5S
M="`H"QS)RD@+3X@#0H)("`@("`@(QE=`T*"2`@("`@("`@*$U-(XI(#T@
M:R!X#0H)("`@("`@(EN#0H)("`@("`@(X@RI#0H-"EQE;F1[8V]D97T-
M"@T*7)E9VENV-O95]#0HM+4-O=6QD()E(=E;F5R86QIV5D('1O($5Q
M+@T*8G)E86M!=%-U8E-TFEN9R`Z.B!3=')I;F@#0H)"2`M/B!3=')I;F-
M"@D)("T^($UA6)E#0H)"2`@("`@*"!3=')I;F@("TM('=H870@8V%M92!B
M969OF4-"@D)("`@("`L(%-TFEN9R`@+2T@=VAA="!C;VUER!A9G1EBP@
M*F5X8VQU9EN9RH@=AE('-TFEN9R!T:%T('=AR!M871C:5D(%G86EN
MW0N#0H)"2`@("`@*0T*8G)E86M!=%-U8E-TFEN9R!S=6(@6UT@("`]($YO
M=AI;F-"F)R96%K0713=6)3=')I;F@W5B('-TD`H#IXRD-"B`@("!\
M('-U8B!@:7-0F5F:7A/9F`@W1R(#T@2G5S="`H6UTL(1R;W`@*QE;F=T
M:"!S=6(I('-TBD-"B`@("!\(]T:5R=VES90D)("`@/2!R97,-"B`@("`)
M=VAEF4-"@D@(')ER`](`T*"2`@("!C87-E()R96%K0713=6)3=')I;F@
MW5B('AS(]F#0H)("`@("`@3F]T:EN9R`@("`M/B!.;W1H:6YG#0H)("`@
M("`@2G5S="`H8BQA*2`M/B!*=7-T("AX.F(L82D-"@T*75N9'MC;V1E?0T*
`
end
