Re: [Haskell-cafe] decoupling type classes
2012/1/16 Yin Wang yinwa...@gmail.com: The typical example would be instance Eq a = Eq [a] where [] == [] = True (a : as) == (b : bs) = a == b as == bs _ == _ = False It can handle this case, although it doesn't handle it as a parametric instance. I suspect that we don't need the concept of parameter instances at all. We just searches for instances recursively at the call site: That seems like it could work, but typically, one would like termination guarantees for this search, to avoid the type-checker getting stuck... Good point. Currently I'm guessing that we need to keep a stack of the traced calls. If a recursive call needs an implicit parameter X which is matched by one of the functions in the stack, we back up from the stack and resolve X to the function found on stack. You may want to look at scala's approach for their implicit arguments. They use a certain to conservatively detect infinite loops during the instance search, but I don't remember the details off hand. While talking about related work, you may also want to take a look at Scala's implicit arguments, GHC implicit arguments and C++ concepts... foo x = let overload bar (x:Int) = x + 1 in \() - bar x baz = in foo (1::Int) Even if we have only one definition of bar in the program, we should not resolve it to the definition of bar inside foo. Because that bar is not visible at the call site foo (1::int). We should report an error in this case. Think of bar as a typed dynamically scoped variable helps to justify this decision. So you're saying that any function that calls an overloaded function should always allow its own callers to provide this, even if a correct instance is in scope. Would that mean all instances have to be resolved from main? This also strikes me as strange, since I gather you would get something like length :: Monoid Int = [a] - Int, which would break if you happen to have a multiplicative monoid in scope at the call site? If you already have a correct instance in scope, then you should have no way defining another instance with the same name and type in the scope as the existing one. This is the case for Haskell. Yes, but different ones may be in scope at different places in the code, right? But it may be useful to allow nested definitions (using let) to shadow the existing instances in the outer scope of the overloaded call. I considered something like this for instance arguments in Agda, but it was hard to make the instance resolution deterministic when allowing such a form of prioritisation. The problem occurred if a shadower and shadowee instance had slightly different types, such that only the shadowee was actually type-valid for a certain instance argument. However, the type information which caused the shadower to become invalid only became available late in the type inference process. In such a case, it is necessary to somehow ascertain that the shadower instance is not chosen, but I did not manage to figure out how to get this right. Dominique ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Happy holidays Haskell
hey Haskell I didn't believe this at all until I started http://www.news13wise.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to make asynchronous I/O composable and safe?
This is an interesting problem, I think I might incorporate parts of it into the next revision of my Concurrent Haskell tutorial. It sounds like you're getting overwhelmed by several different problems, and dealing with them separately would probably help. e.g. you want some infrastructure to run two threads and send an exception to one whenever the other one dies. You also want to be able to avoid a thread being interrupted while performing an operation that should be atomic, like sending a message - this is slightly tricky, because there's a tradeoff between keeping the thread responsive and not interrupting an operation. The biggest hammer is maskUninterruptible, which can be used if all else fails. Whether Network.TLS supports simultaneous read and write I don't know, but you can examine the code or talk to the maintainer. If it doesn't, adding a layer of locking is straightforward, and doesn't increase overall complexity (it's localised). Cheers, Simon On 14/01/2012 05:24, Joey Adams wrote: I'm not happy with asynchronous I/O in Haskell. It's hard to reason about, and doesn't compose well. At least in my code. I'm currently trying to build a networking layer for my application using Network.TLS. Here is a rather minimalist API: newtype Connection = Connection (TLSCtx Handle) connectClient :: Handle -- ^ Connection handle, as returned by 'connectTo' - X509 -- ^ TLS certificate (i.e. public key) - IO Connection connectServer :: Handle -- ^ Connection handle, as returned by 'accept' - X509 -- ^ TLS certificate (i.e. public key) - TLS.PrivateKey -- ^ TLS private key - IO Connection close :: Connection - IO () sendMessage :: Connection - Message - IO () recvMessage :: Connection - ByteString - IO (Message, ByteString) The module provides little more than connection initialization and message serialization. I don't try to use locks or STM to multiplex the connection or, in the case of recvMessage, hide connection state. I just be sure to only use sendMessage in one thread at a time, only use recvMessage in one thread at a time, and marshal the extra bytes parameter of recvMessage from call to call (with the help of StateT). I wrote a simple chat server to test it. The client turned out okay: main :: IO () main = do cert- getCertificate handle- connectTo localhost (PortNumber 1337) conn- connectClient handle cert _- forkIO $ forever $ do s- getLine sendMessage conn $ TestMessage s forever $ flip runStateT B.empty $ do msg- StateT $ recvMessage conn case msg of TestMessage s - liftIO $ putStrLn s _ - liftIO $ hPrintf stderr Warning: unrecognized message from server: %s\n (messageTypeName msg) The only glaring problem is that, if the user presses Ctrl+D, the forked (sending) thread dies, but the main (receiving) thread lingers. I'd have to add exception handlers to ensure that when one thread dies, the other thread dies too. However, the server is an abomination (see attachment). Unfortunately, it's not as simple as spawn one thread per client. We need at least two threads, one to listen for messages from the client, and another to send messages to the client. GHC won't let us simultaneously, in the same thread, wait for input from a connection and wait for an STM transaction to succeed. Another source of complexity is: what if we throw an exception at a thread while it is in the middle of sending a packet? Then we can't shut down the connection properly (i.e. Network.TLS.bye), because the receiver might think the close_notify packet is part of the interrupted packet. Having a thread for each client is good, as it: * Lets us think about each client separately. No need to turn our code inside out or write one big loop that juggles all the clients. * Isolates exceptions. If sendMessage or recvMessage throws an exception, it doesn't bring the whole server down. On the other hand, having multiple threads interact with a single client is hard to think about: * We have to synchronize the threads (e.g. when one dies, kill the other one) * Multiple places where an exception can arise * Can multiple threads interact with the connection handle simultaneously? So why don't I make my connection API handle some of this? Well, I tried. There are so many ways to do it, and I couldn't find a way that simplified usage much. The approach used by Handle and by Network.TLS is to use MVars and IORefs to ensure that, if two threads access the same connection, the connection doesn't become totally corrupt. If I do the same, then I'll have *three* layers of locking under the hood.
[Haskell-cafe] Need advice: Haskell in Web Client
Hi all, I hope to use Haskell for graphics (charts) programming in Web client. My current implementation in brief: Server side, Haskell modules: 1) collecting various statistics from Twitter 2) generating text data for Gnuplot (http://www.gnuplot.info/) 3) Gnuplot creates png files with charts Web client: GWT (Google Web Toolkit) web UI that allows user to enter queries and see resulting charts in Web browser. Charts are png files generated by Gnuplot on the server side. Ideally, on the server side instead of using Gnuplot I would like Haskell to generate Javascript to be downloaded to Web client and draw charts in the browser. Something, very approximately, similar to what GWT does :) This code will be specific of course to plotting Javascript framework, no problem. Looking at Haskell in web browser - HaskellWiki: http://www.haskell.org/haskellwiki/Haskell_in_web_browser#Haskell_web_toolkit I feel a little confused about current state of the available Haskell tools for this task. Any ideas? Thanks! Dmitri ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need advice: Haskell in Web Client
On Tue, Jan 17, 2012 at 4:19 PM, dokondr doko...@gmail.com wrote: Hi all, I hope to use Haskell for graphics (charts) programming in Web client. My current implementation in brief: Server side, Haskell modules: 1) collecting various statistics from Twitter 2) generating text data for Gnuplot (http://www.gnuplot.info/) 3) Gnuplot creates png files with charts Web client: GWT (Google Web Toolkit) web UI that allows user to enter queries and see resulting charts in Web browser. Charts are png files generated by Gnuplot on the server side. Ideally, on the server side instead of using Gnuplot I would like Haskell to generate Javascript to be downloaded to Web client and draw charts in the browser. Something, very approximately, similar to what GWT does :) This code will be specific of course to plotting Javascript framework, no problem. Looking at Haskell in web browser - HaskellWiki: http://www.haskell.org/haskellwiki/Haskell_in_web_browser#Haskell_web_toolkit I feel a little confused about current state of the available Haskell tools for this task. Any ideas? Hi Dimitri, Perhaps HTML5's canvas element would meet your requirement. There a few JS chart implementation for HTML5 floating on the internet. Regards, Kashap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monad-control rant
On 01/17/2012 03:00 AM, Edward Z. Yang wrote: [snip] I don't think it makes too much sense have thing pick off a menu of Abort/Recover/Finally from a semantics perspective: It's easy to imagine monads that have an instance of one of the classes but not of the others I'd like to see some examples. I hypothesize that most of such monads are incoherent, semantically speaking. For example, what does it mean to have a monad that can recover exceptions, but for which you can't throw exceptions? Imagine a monad that disallows lifting of arbitrary IO actions, but can receive asynchronous events (which would probably be /implemented/ on top of asynchronous exceptions, but that's not important here) that behave like runtime-inserted left zeros. COMPUTATIONALLY_HEAVY_CODE `recover` \level → GIVE_AN_APPROXIMATION_INSTEAD(level) The vehicle of implementation here is kind of important. If they are implemented as asynchronous exceptions, I can in fact still throw in this universe: I just attempt to execute the equivalent of 'undefined :: m a'. Since asynchronous exceptions can always be thrown from pure code, I can /always/ do this, no matter how you lock down the types. Indeed, I think implementing this functionality on asynchronous exceptions is a good idea, because it lets you handle nonterminating pure code nicely, and allows you to bail out even when you're not doing monadic execution. I don't like there this is going. Arguments like this destroy the whole point of having abstract interfaces. I took liftBase from you and now you are picking lock on my back door with raise#. I can deny this by hiding the constructor of the asynchronous exception I use for passing `lavel` in my implementation. But seriously. Next thing I know you will be sneaking down my chimney with `unsafePerformIO` in your hands. It is no question that the type system cannot protect us from all the tricks RTS provides, but we still can rely on conventions of use. Personally I'm not a fan of exceptions in pure code. If something can fail it should be reflected in its type, otherwise I consider it a bug. The only scenario I'm comfortable with is using asynchronous exceptions to interrupt some number crunching. But, for the sake of argument, so let's suppose that they're not done as asynchronous exceptions; essentially, you define some 'safe points' which have the possibility to raise exceptions. In this case, I claim there will never be a *technical* difficulty against implementing manually thrown exceptions; the concern here is you don't want the user to do that. With some sets of operations, this isn't a very strong injunction; if there is a deterministic set of operations that results in an error, the user can make a gadget which is semantically equivalent to a thrown exception. I don't think I can argue anything stronger here, so I concede the rest of the point. So, to summarize, such an interface (has recovery but not masking or throwing) always has a trivial throw instance unless you are not implementing it on top of asynchronous exceptions. Your example reminds me of what happens in pure code. In this context, we have the ability to throw errors and map over errors (although I'm not sure how people feel about that, semantically), but not to catch them or mask them. But I don't think we need another typeclass for that. Hm, are you against splitting MonadPlus too? [snip] The purpose of monad-abort-fd is to provide a generic API for handling errors that have values attached to them and for guarding actions with finalizers (as the notion of failure can include more things besides the errors). Here's the reason I'm so fixated on IO: There is a very, /very/ bright line between code that does IO, and pure code. You can have arbitrary stacks of monads, but at the end of the day, if IO is not at the end of the line, your code is pure. If your code is pure, you don't need finalizers. (Indeed, this is the point of pure code...) I can abort computations willy nilly. I can redo them willy nilly. You get a lot of bang for your buck if you're pure. I don't understand what the too much IO objection is about. If there is no IO (now, I don't mean a MonadIO instance, but I do mean, in order to interpret the monad), it seems to me that this API is not so useful. You are forgetting about `ST`. For example, in `ErrorT SomeException ST` finalizers /do/ make sense. It's not about having IO, it is about having some sort of state(fulness). No, you can't. MonadFinally instances must (I really should write documentation) handle /all/ possible failures, not just exceptions. The naive finally ∷ MonadRecover e μ ⇒ μ α → μ β → μ α finally m f = do a ← m `recover` \e → f abort e void $ f return a wouldn't work in `MaybeT IO`, just consider `finally mzero f`. I think that's incoherent. To draw out your MaybeT IO example to its logical conclusion, you've just created two types of zeros, only
[Haskell-cafe] __GLASGOW_HASKELL__ for GHC 7.4
Hi, I'm fixing a build error in a package that depends on the RTS API, which changed in 7.4, using #if __GLASGOW_HASKELL__ = 740. However, build log shows that __GLASGOW_HASKELL__ is still 704, not 740 as I'd expect. Is this a bug? -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] __GLASGOW_HASKELL__ for GHC 7.4
My bad, it *should* really be 704. http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#c-pre-processor On Tue, Jan 17, 2012 at 3:35 PM, Eugene Kirpichov ekirpic...@gmail.comwrote: Hi, I'm fixing a build error in a package that depends on the RTS API, which changed in 7.4, using #if __GLASGOW_HASKELL__ = 740. However, build log shows that __GLASGOW_HASKELL__ is still 704, not 740 as I'd expect. Is this a bug? -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/ -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] __GLASGOW_HASKELL__ for GHC 7.4
On Tue, 2012-01-17 at 15:35 +0400, Eugene Kirpichov wrote: Hi, I'm fixing a build error in a package that depends on the RTS API, which changed in 7.4, using #if __GLASGOW_HASKELL__ = 740. However, build log shows that __GLASGOW_HASKELL__ is still 704, not 740 as I'd expect. Is this a bug? I don't think so. I recently came across [1]: ''' Stable Releases Stable branches are numbered x.y, where y is even. Releases on the stable branch x.y are numbered x.y.z, where z (= 1) is the patchlevel number. Patchlevels are bug-fix releases only, and never change the programmer interface to any system-supplied code. However, if you install a new patchlevel over an old one you will need to recompile any code that was compiled against the old libraries. The value of __GLASGOW_HASKELL__ (see Section 4.11.3, “Options affecting the C pre-processor”) for a major release x.y.z is the integer xyy (if y is a single digit, then a leading zero is added, so for example in version 6.8.2 of GHC we would have __GLASGOW_HASKELL__==608). ''' As such, release 7.4.0 would yield __GLASGOW_HASKELL__ 704. Nicolas [1] http://www.haskell.org/ghc/docs/7.0.4/html/users_guide/version-numbering.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Pruned Sparks in Original Strategies
Dear List, I am trying to parallelize some number of codes with using Haskell's original and second generation strategies in order to be able to compare them. As far as I understood, in original strategies, ROOT garbage collection mechanism is used which does not allow any spark to be pruned. Since, they do not return any information back to its caller. (a type of void reference making fizzling of a spark impossible, is returned), However, in most of my measurements, spraks are being pruned. I wonder the reasons why this incident occurs? Do you have any idea? Many thanks, Burak. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Please upgrade http-enumerator and/or http-conduit
Hi all, Thanks to Felipe for catching this issue[1]. Both http-enumerator and http-conduit will not properly reject invalid certificates. I've released updated versions of both packages: http-enumerator-0.7.2.4 http-conduit-1.1.2.2 All users are recommended to upgrade. Michael [1] https://github.com/snoyberg/http-conduit/pull/6 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need advice: Haskell in Web Client
On Tue, Jan 17, 2012 at 3:07 AM, C K Kashyap ckkash...@gmail.com wrote: Perhaps HTML5's canvas element would meet your requirement. There a few JS chart implementation for HTML5 floating on the internet. The Google Charting API *might* be sufficient: http://code.google.com/apis/chart/ --Rogan Regards, Kashap ___ 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] Monad-control rant
On Tue, Jan 17, 2012 at 06:29, Mikhail Vorozhtsov mikhail.vorozht...@gmail.com wrote: I wouldn't be too optimistic about convincing GHC HQ. Even making Applicative a superclass of Monad can make Haskell98 nazis come after you in ninja suits. What?! The only significant complaint I've seen here is that the necessary language support for doing so without breaking more or less every Haskell program currently in existence is difficult to achieve. On the other hand, I suppose if you're sufficiently fanatical, breaking more or less every Haskell program currently in existence might be viewed as a minor issue that you think nobody has any right to be upset about. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need advice: Haskell in Web Client
On Tue, Jan 17, 2012 at 6:42 PM, John Lenz l...@math.uic.edu wrote:
HTML5 Canvas is great for charts. If you go this route you might as well
use a library which draws charts for you instead of writing all this code
yourself.
Personally, I use extjs version 4 which has some amazing charts, but there
are other libraries out there.
http://www.sencha.com/**products/extjs/examples/#**sample-3http://www.sencha.com/products/extjs/examples/#sample-3
Essentially the server provides the data in JSON or XML some other format,
and the extjs code draws the charts on the client side.
If you go with extjs, then the server side I would suggest a small, simple
yesod or snap server. You could probably get the server under a hundred
lines of code with yesod; see some of the examples in the yesod book.
yesod or snap would serve JSON of the statistics on request, and also
serve the javascript files which draw the charts.
Yes, I was thinking about using Haskell to generate everything that
specific Javascript library needs to display charts in browser. Naturally
charts are to be displayed by this library itself. I also would like to
have Haskell tools to generate Web GUI in Javascript.
As for yesod, I am not sure that I like approach which mixes HTML with
code, or even worse - creates a new weird HTML-like language like 'whamlet
quasi-quotation', for example:
!-- a href=@{Page1R}Go to page 1! --
I prefer using Turing complete PL to program web client, like the one used
in GWT (Java) or Cappuccino (Objective-J). http://cappuccino.org/learn/
In this case you /almost/ don't need to know HTML, CSS, DOM, Ajax, etc. to
develop WebUI and good PL lets you concentrate on problem domain instead of
bothering about browser support.
It is a real pity that Haskell still has no such tools to generate Web GUI
in Javascript. (((
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to make asynchronous I/O composable and safe?
I'd say use of asynchronous exceptions should be a last resort. Developers should be encouraged to explicitly model any event notification system they use. Regards, Dave On Tue, Jan 17, 2012 at 1:42 AM, Simon Marlow marlo...@gmail.com wrote: This is an interesting problem, I think I might incorporate parts of it into the next revision of my Concurrent Haskell tutorial. It sounds like you're getting overwhelmed by several different problems, and dealing with them separately would probably help. e.g. you want some infrastructure to run two threads and send an exception to one whenever the other one dies. You also want to be able to avoid a thread being interrupted while performing an operation that should be atomic, like sending a message - this is slightly tricky, because there's a tradeoff between keeping the thread responsive and not interrupting an operation. The biggest hammer is maskUninterruptible, which can be used if all else fails. Whether Network.TLS supports simultaneous read and write I don't know, but you can examine the code or talk to the maintainer. If it doesn't, adding a layer of locking is straightforward, and doesn't increase overall complexity (it's localised). Cheers, Simon On 14/01/2012 05:24, Joey Adams wrote: I'm not happy with asynchronous I/O in Haskell. It's hard to reason about, and doesn't compose well. At least in my code. I'm currently trying to build a networking layer for my application using Network.TLS. Here is a rather minimalist API: newtype Connection = Connection (TLSCtx Handle) connectClient :: Handle -- ^ Connection handle, as returned by 'connectTo' - X509 -- ^ TLS certificate (i.e. public key) - IO Connection connectServer :: Handle -- ^ Connection handle, as returned by 'accept' - X509 -- ^ TLS certificate (i.e. public key) - TLS.PrivateKey -- ^ TLS private key - IO Connection close :: Connection - IO () sendMessage :: Connection - Message - IO () recvMessage :: Connection - ByteString - IO (Message, ByteString) The module provides little more than connection initialization and message serialization. I don't try to use locks or STM to multiplex the connection or, in the case of recvMessage, hide connection state. I just be sure to only use sendMessage in one thread at a time, only use recvMessage in one thread at a time, and marshal the extra bytes parameter of recvMessage from call to call (with the help of StateT). I wrote a simple chat server to test it. The client turned out okay: main :: IO () main = do cert- getCertificate handle- connectTo localhost (PortNumber 1337) conn- connectClient handle cert _- forkIO $ forever $ do s- getLine sendMessage conn $ TestMessage s forever $ flip runStateT B.empty $ do msg- StateT $ recvMessage conn case msg of TestMessage s - liftIO $ putStrLn s _ - liftIO $ hPrintf stderr Warning: unrecognized message from server: %s\n (messageTypeName msg) The only glaring problem is that, if the user presses Ctrl+D, the forked (sending) thread dies, but the main (receiving) thread lingers. I'd have to add exception handlers to ensure that when one thread dies, the other thread dies too. However, the server is an abomination (see attachment). Unfortunately, it's not as simple as spawn one thread per client. We need at least two threads, one to listen for messages from the client, and another to send messages to the client. GHC won't let us simultaneously, in the same thread, wait for input from a connection and wait for an STM transaction to succeed. Another source of complexity is: what if we throw an exception at a thread while it is in the middle of sending a packet? Then we can't shut down the connection properly (i.e. Network.TLS.bye), because the receiver might think the close_notify packet is part of the interrupted packet. Having a thread for each client is good, as it: * Lets us think about each client separately. No need to turn our code inside out or write one big loop that juggles all the clients. * Isolates exceptions. If sendMessage or recvMessage throws an exception, it doesn't bring the whole server down. On the other hand, having multiple threads interact with a single client is hard to think about: * We have to synchronize the threads (e.g. when one dies, kill the other one) * Multiple places where an exception can arise * Can multiple threads interact with the connection handle simultaneously? So why don't I make my connection API handle some of this? Well, I tried. There are so many ways to do it, and I couldn't find a way that
[Haskell-cafe] Book?
I've seen a book: The Practice Of Monadic Interpretation Dan Popa Nov. 2008 Or Practical Monadic Interpretation Dan Popa Which seem that they might be the same book? As reported on Haskell Wiki/books as published in 2008, but Don't find it available anywhere under either title. Any pointers or references? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Conduit versions of wai and warp?
Hi Michael, The current versions of wai and warp: http://hackage.haskell.org/package/wai http://hackage.haskell.org/package/warp still seem to be the versions that use enumerator. Any idea when the Conduit versions might show up on Hackage? Until then, should I be grabbing these packages from Github? Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] implementing a text editor swap file
I'm writing a gtk2hs-based text editor, and would like to implement continuous (swap-file based) autosave the way vim and emacs do it. Any suggestions for how to implement this in a cross-platform manner? Also, is there a library that returns standard config file locations on a per-platform basis? martin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] implementing a text editor swap file
http://hackage.haskell.org/package/bytestring-mmap On 17/01/2012, Martin DeMello martindeme...@gmail.com wrote: I'm writing a gtk2hs-based text editor, and would like to implement continuous (swap-file based) autosave the way vim and emacs do it. Any suggestions for how to implement this in a cross-platform manner? Also, is there a library that returns standard config file locations on a per-platform basis? martin ___ 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] implementing a text editor swap file
Matthew Farkas-Dyck wrote: http://hackage.haskell.org/package/bytestring-mmap Since he's editing text, its a pity there isn't a text-mmap package :-). Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] implementing a text editor swap file
Says posix only. But googling for it brought up System.IO.MMap, which does seem to be cross-platform. martin On Tue, Jan 17, 2012 at 5:46 PM, Matthew Farkas-Dyck strake...@gmail.com wrote: http://hackage.haskell.org/package/bytestring-mmap On 17/01/2012, Martin DeMello martindeme...@gmail.com wrote: I'm writing a gtk2hs-based text editor, and would like to implement continuous (swap-file based) autosave the way vim and emacs do it. Any suggestions for how to implement this in a cross-platform manner? Also, is there a library that returns standard config file locations on a per-platform basis? martin ___ 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] implementing a text editor swap file
On 17/01/2012, Erik de Castro Lopo mle...@mega-nerd.com wrote: Matthew Farkas-Dyck wrote: http://hackage.haskell.org/package/bytestring-mmap Since he's editing text, its a pity there isn't a text-mmap package :-). Yeah, I had the same thought. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ 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] implementing a text editor swap file
On Tue, Jan 17, 2012 at 5:49 PM, Erik de Castro Lopo mle...@mega-nerd.com wrote: Matthew Farkas-Dyck wrote: http://hackage.haskell.org/package/bytestring-mmap Since he's editing text, its a pity there isn't a text-mmap package :-). Further question - my internal data representation is a vector of strings (it's a line-based editor). Is there a more efficient strategy to keep an mmap buffer in sync with the vector than simply allocating some large fixed size per line? martin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] implementing a text editor swap file
Martin DeMello wrote: Further question - my internal data representation is a vector of strings (it's a line-based editor). String or ByteString or Text? If its either of the first two, I think you should definitely look at Text. Is there a more efficient strategy to keep an mmap buffer in sync with the vector than simply allocating some large fixed size per line? Very much dependent on whether you are using String or one of the other two I would think. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] implementing a text editor swap file
On Tue, Jan 17, 2012 at 6:24 PM, Erik de Castro Lopo mle...@mega-nerd.com wrote: Martin DeMello wrote: Further question - my internal data representation is a vector of strings (it's a line-based editor). String or ByteString or Text? If its either of the first two, I think you should definitely look at Text. Just plain String, mostly because it's what Gtk.Entry works with. I'll take a look at Text. martin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] implementing a text editor swap file
Martin DeMello wrote: Just plain String, mostly because it's what Gtk.Entry works with. I'll take a look at Text. Ah, maybe not. If your output representation *has* to be String its probably not worth using Text as an internal representation. I suspect that Gtk should really be updated to allow the use of Text instead of String. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to make asynchronous I/O composable and safe?
On Tue, Jan 17, 2012 at 3:20 PM, David Barbour dmbarb...@gmail.com wrote: I'd say use of asynchronous exceptions should be a last resort. ... I agree. However, network libraries in Haskell (e.g. Handle, Network.TLS) generally don't provide the primitives needed to do that on the receiving end. For example, if a thread is blocked on hGetBuf, it cannot also wait on a signal telling it to stop. Since hClose on the same handle will block until the hGetBuf is done, the only way to stop reading from the handle is to throw an asynchronous exception at the hGetBuf thread. Worse, since there is no threadWaitReadHandle :: Handle - IO (), there's no way to guarantee that hGetBuf will not be interrupted in the middle of receiving a packet. From an application perspective, this invalidates subsequent retrievals unless the protocol is self-synchronizing. -Joey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Conduit versions of wai and warp?
On Wed, Jan 18, 2012 at 2:22 AM, Erik de Castro Lopo mle...@mega-nerd.com wrote: Hi Michael, The current versions of wai and warp: http://hackage.haskell.org/package/wai http://hackage.haskell.org/package/warp still seem to be the versions that use enumerator. Any idea when the Conduit versions might show up on Hackage? Until then, should I be grabbing these packages from Github? Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ Funny, I just got a similar question on the Yesod mailing list. Currently, the plan is to release WAI/Warp 1.0 and Yesod 0.10 towards the end of the month. However, WAI and Warp are mostly ready now, just needing a bit more testing. If people want to give me some feedback on the readiness of them, and would like them released earlier, I'm definitely flexible. Meanwhile: yes, the Github version is conduit-based. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to make asynchronous I/O composable and safe?
I uploaded a package that creates an STM layer over a network connection: http://hackage.haskell.org/package/stm-channelize I haven't used it in anger yet, but I hope it's a step in the right direction. I included a sample chat client and server. The client is pretty cute: main = let connect = connectTo localhost (PortNumber 1234) = connectHandle in channelize connect $ \conn - channelize connectStdio $ \stdio - forever $ atomically $ (recv conn = send stdio) `orElse` (recv stdio = send conn) I use channelize on both the network connection, and on stdin/stdout. The server is much longer, but shouldn't be terribly confusing. It demonstrates kicking out a client without a dangerous asynchronous exception, something we can't do easily without waiting on alternatives (i.e. orElse). -Joey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
