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 > > 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 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 ... : 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 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
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
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
[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 reported&contributed), 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
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:\htest>ghc --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
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
[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 interest&use 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
[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] 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
Re: [Haskell-cafe] Slow Text.JSON parser
Maybe. Handling the common cases reasonably well is probably worth doing first (+profiling) before opting for a heart&lung 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
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: 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 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 off&on 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
[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 off&on 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] 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
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
[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
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
Re: [Haskell-cafe] ANN: json-0.4.1
Thanks Bas for the helpful & clear advice.
While I'm not on top of it yet why some installs of 6.10.1 experience
this build
failure, but others don't, I've put together an updated .cabal file +
source dist
that I hope gets at it. It's available from
http://www.galois.com/~sof/json-0.4.1.tar.gz
I've pointed Alex at this bundle earlier, but if others that have run
into the same
problem could test using above bits and see if that fixes it, that'd be
great.
If cool, I'll upload the bits to hackage. My apologies if this is
breaking people's
cabal builds at the moment.
cheers
--sigbjorn
On 1/13/2009 11:58, Bas van Dijk wrote:
On Tue, Jan 13, 2009 at 8:47 PM, Alex Ott wrote:
Hello
"SF" == Sigbjorn Finne writes:
SF> Hi, a new release of the 'json' package is now available via hackage,
SF> version 0.4.1
SF> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/json
I tried to upgrade it via cabal on mac os x & linux (both use ghc 6.10.1)
and it fails with
Building json-0.4.1...
Text/JSON/Generic.hs:33:7:
Could not find module `Data.Generics':
it was found in multiple packages: base-3.0.3.0 syb
cabal: Error: some packages failed to install:
json-0.4.1 failed during the building phase. The exception was:
exit: ExitFailure 1
The standard solution for this is to add a cabal flag that controls
wether to depend on base-4 or base-3:
--
flag small_base
description: Choose the new smaller, split-up base package.
Library
if flag(small_base)
Build-Depends: base == 4.*, syb
CPP-Options:-DBASE_4
else
Build-Depends: base == 3.*
--
And use some CPP in your modules like this:
--
{-# LANGUAGE CPP #-}
#ifdef BASE_4
import Data.Data (Data)
#else
import Data.Generics (Data)
#endif
--
See for example how I do it in http://code.haskell.org/Stream
regards,
Bas
___
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" ; <[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: <> 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: Trying to get a copy of HaskellDirect urgently...
I can't remember having put together a binary release after that one. A recent'ish (Aug 2002) source release is available via http://galois.com/~sof/hdirect-0.19-src.tar.gz --sigbjorn - Original Message - From: "Simon Peyton-Jones" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, January 21, 2003 07:11 Subject: RE: Trying to get a copy of HaskellDirect urgently... > I've just grabbed it ok, so I'll send it to you in a separate message. > > It says that it's built for GHC 4.08.1 which is pretty old. I wonder if > you've made a more recent release somewhere, Sigbjorn? > > Sarah: you can always get the sources from the CVS tree > > Simon > > | -Original Message- > | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > | Sent: 21 January 2003 13:26 > | To: [EMAIL PROTECTED] > | Subject: Trying to get a copy of HaskellDirect urgently... > | > | Hi Folks, > | > | I'm currently trying to urgently get a copy of the HaskellDirect > release, but I'm > | finding it impossible to get to the ftp server at Glasgow (it seems to > be > | refusing connections - it's not a firewall problem). > | > | If anyone has a copy they could email me, or knows of somewhere else I > can get > | the release, I would be extremely grateful. > | > | TIA, > | Sarah Thompson > | > | PS: Are there any known issues using HaskellDirect with the latest GHC > release > | (GHC 5.04.2)? > | ___ > | Haskell-Cafe mailing list > | [EMAIL PROTECTED] > | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: win32 stand alone binaries?
Brett Morgan [EMAIL PROTECTED] writes: > > Is it possible to build win32 stand alone binaries using cygwin hosted > ghc tools? Hi, that's what you get by default these days, GHC doesn't rely on cygwin (nor the applications it produces). If you _really_ want to, you could compile up the GHC sources to use cygwin though, of course. hth --sigbjorn ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: compiling hdirect
Johannes Goetx [EMAIL PROTECTED] writes:
>
...
> gcc -O -mno-cygwin -mwin32-c mkNativeInfo.c -o mkNativeInfo.o
> mkNativeInfo.c:0: malformed option `-D __WIN32__-DWIN32'
...
>
> malformed option `-D __WIN32__-DWIN32'
>
> Where can I change this? I could not find a file containing this
> option string.
Hi,
you're using a version of gcc with a broken 'specs' file.
Locate the specs file inside your cygwin(?) install tree & change
the portion of the "*cpp:" section which expands -mwin32 and
-mno-cygwin to the following:
%{mwin32|mno-cygwin:-DWIN32 -D_WIN32 -D__WIN32
-D__WIN32__ -DWINNT }
i.e., add a space after -DWINNT and the '}'
This issue will soon go away, as the use of -mwin32 in GHC's
fptools/ tree is in the process of being nuked.
hth
--sigbjorn
___
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-O9&5]#0IG
M97154DP@.CH@4W1R:6YG("T^($E/(%-T2!H879E('1O(&)E(&5X=&5N9&5D('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-TV-O
M9&5]#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&%N9&QE#0IF971C:%523"!P"Q?*3I?*2`M
M/B`H>"P@('ES*0T*("`@("`@(%\@+3X@*#@P+"!L6)E(&$-"G)U;DU-('-TV-O9&5]#0HM+4-O=6QD(&)E(&=E;F5R86QI6)E#0H)"2`@("`@*"!3=')I;F<@("TM('=H870@8V%M92!B
M969O#IX
RE: lazy file reading in H98
The behaviour is well defined, Haskell98 enforces a single-writer, multiple reader locking on files (Sec. 11.3.1 of the library report) which also extends to semi-closed handles/files. A bug report to the maintainers of whatever produced the reported misbehaviour would be good. --sigbjorn > -Original Message- > From: Simon Peyton-Jones > Sent: Tuesday, September 05, 2000 01:10 > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Cc: Simon Peyton-Jones > Subject: RE: lazy file reading in H98 > > > Folks, > > Finalising the Haskell 98 report is (still) on my to-do list. > I plan to > do it after ICFP, but I need a clear week which is why I've been > procrastinating. > And comments do keep coming in occasionally. Manuel's is a > case in point. > > > I'd be interested to hear people's opinion about the lazy-file read > question. > I'm not prepared to add new functions to Haskell 98, but I think > the clarification of (1) or (2) below would be useful. (2) is nice > but it makes *all* file reading more expensive, perhaps significantly > so (e.g. making a complete copy of the file). So I am > personally inclined > to go for (1) and require Haskell programmers to do the > consequent file-name > changing themselves. > > I'm sending this message to the haskell-cafe! > > Simon > > | -Original Message- > | From: Manuel M. T. Chakravarty [mailto:[EMAIL PROTECTED]] > | Sent: 05 September 2000 02:10 > | To: [EMAIL PROTECTED] > | Subject: lazy file reading in H98 > | > | > | In an assignment, in my class, we came across a lack of > | specification of the behaviour of `Prelude.readFile' and > | `IO.hGetContents' and IMHO also a lack of functionality. As > | both operations read a file lazily, subsequent writes to the > | same file are potentially disastrous. In this assignment, > | the file was used to make a Haskell data structure > | persistent over multiple runs of the program - ie, > | > | readFile fname >>= return . read > | > | at the start of the program and > | > | writeFile fname . show > | > | at the end of the program. For certain inputs, where the > | data structure stored in the file was only partially used, > | the file was overwritten before it was fully read. > | > | H98 doesn't really specify what happens in this situation. > | I think, there are two ways to solve that: > | > | (1) At least, the definition should say that the behaviour > | is undefined if a program every writes to a file that it > | has read with `readFile' or `hGetContents' before. > | > | (2) Alternatively, it could demand more sophistication from > | the implementation and require that upon opening of a > | file for writing that is currently semi-closed, the > | implementation has to make sure that the contents of the > | semi-closed file is not corrupted before it is fully > | read.[1] > | > | In the case that solution (1) is chosen, I think, we should > | also have something like `strictReadFile' (and > | `hStrictGetContents') which reads the whole file before > | proceeding to the next IO action. Otherwise, in situations > | like in the mentioned assignment, you have to resort to > | reading the file character by character, which seems very > | awkward. > | > | So, overall, I think solution (2) is more elegant. > | > | Cheers, > | Manuel > | > | [1] On Unix-like (POSIX?) systems, unlinking the file and > | then opening the writable file would be sufficient. On > | certain legacy OSes, the implementation would have to > | read the rest of the file into memory before creating > | a new file under the same name. > | >
