[Haskell-cafe] Testing Concurrent Programs
How do you test concurrent programs in which you actually have to test over all possible interleaving schedules by the scheduler . Is this possible to do with quickcheck . Thanks , Satvik ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I Need a Better Functional Language!
On Thu, Apr 5, 2012 at 8:59 PM, Tillmann Rendel wrote: > Paul R wrote: >> >> I am curious what are interesting use-cases for that? Symbolic >> analysis? self-compilers? > > > Optimization. For example, imagine the following definition of function > composition: > > map f . map g = map (f . g) > f . g = \x -> f (g x) > > In Haskell, we cannot write this, because we cannot pattern match on > function calls. > > Tillmann On the one hand, yes we can, with RULES: http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/rewrite-rules.html On the other hand, I've never used it, but this sounds a bit like Pure: http://code.google.com/p/pure-lang/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Google Summer of Code - Lock-free data structures
+1 -- the reagents model is interesting and it would be good to see a Haskell implementation. On Thu, Apr 5, 2012 at 3:05 PM, Ben Gamari wrote: > Ben writes: > > > perhaps it is too late to suggest things for GSOC -- > > > > but stephen tetley on a different thread pointed at aaron turon's > > work, which there's a very interesting new concurrency framework he > > calls "reagents" which seems to give the best of all worlds : it is > > declarative and compositional like STM, but gives performance akin to > > hand-coded lock-free data structures. he seems to have straddled the > > duality of isolation vs message-passing nicely, and can subsume things > > like actors and the join calculus. > > > > http://www.ccs.neu.edu/home/turon/reagents.pdf > > > > he has a BSD licensed library in scala at > > > > https://github.com/aturon/ChemistrySet > > > > if someone doesn't want to pick this up for GSOC i might have a hand > > at implementing it myself. > > > Keep use in the loop if you do. I have a very nice application that has > been needing a nicer approach to concurrency than IORefs but > really can't afford STM. > > Cheers, > > - Ben > > > ___ > 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] I Need a Better Functional Language!
On Thu, Apr 5, 2012 at 11:59 AM, Tillmann Rendel < ren...@informatik.uni-marburg.de> wrote: > Paul R wrote: > >> I am curious what are interesting use-cases for that? Symbolic >> analysis? self-compilers? >> > > Optimization. For example, imagine the following definition of function > composition: > > map f . map g = map (f . g) > f . g = \x -> f (g x) > > In Haskell, we cannot write this, because we cannot pattern match on > function calls. > > Tillmann > > So, we're not talking about optimization as in Mathematical Programming but optimization in language constructs. You might want to take a look at MIN by Stephen Tse. -- -- Regards, KC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Google Summer of Code - Lock-free data structures
Ben writes: > perhaps it is too late to suggest things for GSOC -- > > but stephen tetley on a different thread pointed at aaron turon's > work, which there's a very interesting new concurrency framework he > calls "reagents" which seems to give the best of all worlds : it is > declarative and compositional like STM, but gives performance akin to > hand-coded lock-free data structures. he seems to have straddled the > duality of isolation vs message-passing nicely, and can subsume things > like actors and the join calculus. > > http://www.ccs.neu.edu/home/turon/reagents.pdf > > he has a BSD licensed library in scala at > > https://github.com/aturon/ChemistrySet > > if someone doesn't want to pick this up for GSOC i might have a hand > at implementing it myself. > Keep use in the loop if you do. I have a very nice application that has been needing a nicer approach to concurrency than IORefs but really can't afford STM. Cheers, - Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I Need a Better Functional Language!
Paul R wrote: I am curious what are interesting use-cases for that? Symbolic analysis? self-compilers? Optimization. For example, imagine the following definition of function composition: map f . map g = map (f . g) f . g = \x -> f (g x) In Haskell, we cannot write this, because we cannot pattern match on function calls. Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Google Summer of Code - Lock-free data structures
perhaps it is too late to suggest things for GSOC -- but stephen tetley on a different thread pointed at aaron turon's work, which there's a very interesting new concurrency framework he calls "reagents" which seems to give the best of all worlds : it is declarative and compositional like STM, but gives performance akin to hand-coded lock-free data structures. he seems to have straddled the duality of isolation vs message-passing nicely, and can subsume things like actors and the join calculus. http://www.ccs.neu.edu/home/turon/reagents.pdf he has a BSD licensed library in scala at https://github.com/aturon/ChemistrySet if someone doesn't want to pick this up for GSOC i might have a hand at implementing it myself. b On Mar 29, 2012, at 6:46 AM, Tim Harris (RESEARCH) wrote: > Hi, > > Somewhat related to this... > > Next month we have a paper coming up at EuroSys about a middle-ground between > using STM and programming directly with CAS: > > http://research.microsoft.com/en-us/um/people/tharris/papers/2012-eurosys.pdf > > This was done in the context of shared memory data structures in C/C++, > rather than Haskell. > > It might be interesting to see how the results carry over to Haskell, e.g. > adding short forms of specialized transactions that interact correctly with > normal STM-Haskell transactions. > > In the paper we have some examples of using short specialized transactions > for the fast paths in data structures, while keeping the full STM available > as a fall-back for expressing the cases that cannot be implemented using > short transactions. > > --Tim > > > > > -Original Message- > From: haskell-cafe-boun...@haskell.org > [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Heinrich Apfelmus > Sent: 29 March 2012 13:30 > To: haskell-cafe@haskell.org > Subject: Re: [Haskell-cafe] Google Summer of Code - Lock-free data structures > > Florian Hartwig wrote: >> Heinrich Apfelmus wrote: >> >> So while the two are related, CAS is a machine primitive that works >> for a single operation and on a single word while STM is a software >> abstraction that isolates sequences of operations on multiple memory >> locations from each other. >> >>> Is it possible to implement every data structure based on CAS in >>> terms of STM? What are the drawbacks? The other way round? >> >> I think so. Atomically reading and writing a single memory location >> (which CAS does) is just a very simple transaction. But using a CAS >> instruction should be more efficient, since STM has to maintain a >> transaction log and commit transactions, which creates some overhead. > > Ah, I see. In that case, it may be worthwhile to implement the CAS > instruction in terms of STM as well and measure the performance difference > this makes for the final data structure. After all, STM is a lot more > compositional than CAS, so I'd like to know whether the loss of > expressiveness is worth the gain in performance. > > > Best regards, > Heinrich Apfelmus > > -- > http://apfelmus.nfshost.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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] thread killed
>> I think I might know what your problem is. You're accepting file uploads >> using handleMultipart, yes? Snap kills uploads that are going too slow, >> otherwise you would be vulnerable to slowloris >> (http://ha.ckers.org/slowloris/) DoS attacks. What's probably happening here >> is that you're doing slow work inside the "Iteratee IO a" handler you pass >> to that function, which makes Snap think the client is trickling bytes to >> you. If that's the case, either finish the iteratee more quickly and do the >> slow work back in the Snap handler (preferable), or disable the minimum >> upload rate guard (although that's not recommended on a server talking to >> the public internet.) Ok, so I butchered Snap by replacing all of snap-server's killThread calls with putStrLn calls, and the putStrLn that is triggered by Snap.Internal.Http.Server.SimpleBackend's runSession (line 163 in snap-server 0.8.0.1) seems to be the culprit. Is that a rate limiter, or is that something else? Anyhow, I think there's a bug in there somewhere. I'll be poking at it a bit more, but that seems to be the top-level source of the errors. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] thread killed
>> I think I might know what your problem is. You're accepting file uploads >> using handleMultipart, yes? Snap kills uploads that are going too slow, >> otherwise you would be vulnerable to slowloris >> (http://ha.ckers.org/slowloris/) DoS attacks. What's probably happening here >> is that you're doing slow work inside the "Iteratee IO a" handler you pass >> to that function, which makes Snap think the client is trickling bytes to >> you. If that's the case, either finish the iteratee more quickly and do the >> slow work back in the Snap handler (preferable), or disable the minimum >> upload rate guard (although that's not recommended on a server talking to >> the public internet.) I tried adding a "setMinimumUploadRate 0" to my handleMultipart and doing the upload, and it's still getting killed. The uploads are pretty fast; a 150MB file takes around 10s. I really don't think the problem is with Snap, but pulling my code out of snap would be pretty painful. I have some pretty nasty crap going on with what I'm doing anyhow, with threads communicating asynchronously, sockets being held open between requests, that sort of horrid ugliness. I'm going to try to get rid of that, and then see if any bugs I had in there were causing the problem. Hopefully I'll be done with that by the end of the weekend, and I'll either have the problem fixed, or have a reasonable way to reproduce the errors. Thanks for the idea, anyhow. And, if setMinimumUploadRate 0 doesn't actually disable the rate limiter, I'd be happy to try something more correct. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I Need a Better Functional Language!
Grigory> So now I wonder, what are the languages that are functional in Grigory> the sense above? With a reasonable syntax and semantics, thus Grigory> no assembler. I guess Lisp might be of this kind, but I'm not Grigory> sure. In addition, I'm not a fan of parentheses. What else? Grigory> Pure? Mathematica? Maxima? Indeed you want a *different* programming language. But it won't be *better*, just different. Indeed, as soon as your program react to the implementation of its functions, you will be in a land where you lose a fundamental abstraction, so you won't be able to change implementation anymore whithout changing callers as well. I am curious what are interesting use-cases for that ? Symbolic analysis ? self-compilers ? -- Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I Need a Better Functional Language!
On Thu, Apr 5, 2012 at 10:14 AM, Grigory Sarnitskiy wrote: > First, what are 'functions' we are interested at? It can't be the usual > set-theoretic definition, since it is not constructive. The constructive > definition should imply functions that can be constructed, computed. Thus > these are computable functions that should be of our concern. But computable > functions in essence are just a synonym for programs. This is a flawed premise. The point of working with functions is abstraction, and that abstraction is given by extensional equality of functions: f = g iff forall x. f x = g x So functions are not synonymous with programs or algorithms, they correspond to an equivalence class of algorithms that produce the same results from the same starting points. If you can access the source of functions within the language, this abstraction has been broken. And this abstraction is useful, because it allows you to switch freely between programs that do the same thing without having to worry that someone somewhere is relying on the particular algorithm or source. This is the heart of optimization and refactoring and the like. There are places for metaprogramming, or perhaps even a type of algorithms that can be distinguished by means other than the functions they compute. But to say that functions are that type is false, and that functions should mean that is, I think, wrong headed. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I Need a Better Functional Language!
Addendum: Intel's Forte was the framework, reFLect was the language : http://www.cs.ox.ac.uk/tom.melham/res/reflect.html Quoting that page: "reFLect is a functional programming language designed and implemented by a team at Intel Corporation's Strategic CAD Labs under the direction of Jim Grundy. The language is strongly typed and similar to ML, but provides certain reflection features intended for applications in industrial hardware design and verification. Like LISP, reFLect has quotation and antiquotation constructs that may be used to construct and decompose expressions in the language itself. Unlike LISP, these mechanisms are typed. The language also provides a primitive mechanism for pattern-matching, and in particular for defining functions over code by pattern-matching on the structure of reFLect expressions." On 5 Apr 2012, at 15:14, Grigory Sarnitskiy wrote: > Hello! I've just realized that Haskell is no good for working with functions! > > First, what are 'functions' we are interested at? It can't be the usual > set-theoretic definition, since it is not constructive. The constructive > definition should imply functions that can be constructed, computed. Thus > these are computable functions that should be of our concern. But computable > functions in essence are just a synonym for programs. > > One could expect from a language that bears 'functional' as its > characteristic to be able to do everything imaginable with functions. > However, the only thing Haskell can do with functions is to apply them to > arguments and to feed them as arguments, run in parallel (run and concatenate > programs). > > Obviously, that's not all of the imaginable possibilities. One also can > rewrite programs. And write programs that rewrite programs. And write > programs that rewrite programs that rewrite the first programs and so on. But > there is no such possibility in Haskell, except for introducing a DSL. > > So now I wonder, what are the languages that are functional in the sense > above? With a reasonable syntax and semantics, thus no assembler. I guess > Lisp might be of this kind, but I'm not sure. In addition, I'm not a fan of > parentheses. What else? Pure? Mathematica? Maxima? > > Note, that the reflectivity is important. > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Lero@TCD, Head of Foundations & Methods Research Group Director of Teaching and Learning - Undergraduate, School of Computer Science and Statistics, Room G.39, O'Reilly Institute, Trinity College, University of Dublin http://www.scss.tcd.ie/Andrew.Butterfield/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I Need a Better Functional Language!
On 5 Apr 2012, at 15:14, Grigory Sarnitskiy wrote: > Hello! I've just realized that Haskell is no good for working with functions! > > > > Obviously, that's not all of the imaginable possibilities. One also can > rewrite programs. And write programs that rewrite programs. And write > programs that rewrite programs that rewrite the first programs and so on. But > there is no such possibility in Haskell, except for introducing a DSL. > > So now I wonder, what are the languages that are functional in the sense > above? With a reasonable syntax and semantics, thus no assembler. I guess > Lisp might be of this kind, but I'm not sure. Probably - but the semantics is dreadful... > > > Note, that the reflectivity is important. Intel developed a reflective functional language/system called Forte that is the basic of a lot of their formal hardware verification process... http://www.cs.ox.ac.uk/tom.melham/res/forte.html > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Lero@TCD, Head of Foundations & Methods Research Group Director of Teaching and Learning - Undergraduate, School of Computer Science and Statistics, Room G.39, O'Reilly Institute, Trinity College, University of Dublin http://www.scss.tcd.ie/Andrew.Butterfield/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell integration with C/C++ (GSOC)
Quoth Anthony Cowley , ... > I think this is a consequence of line buffering rather than a bug. If > you write your own increment function in Haskell, you get the same > behavior. If you `hSetBuffering stdout NoBuffering` before your `putStr` > call, you should get the behavior you wanted. Though if you must do one or the other, I think hFlush makes as much sense. I think his perspective may be that the C stdio library appears to recognize that a TTY read is an occasion to flush stdout. If you already know better, there are ways to solve this problem - flush, change buffering, or use stderr instead of stdout. If you weren't expecting it, though, Haskell might by comparison seem a little retarded. Maybe it isn't a bug. > As things stand, it is quite a hassle to use a Haskell library of > any complexity called from C. And Haskell is slightly handicapped in this application, if it still doesn't support any good mechanism for top level mutable state (Cf. http://www.haskell.org/haskellwiki/Top_level_mutable_state ) I wonder if the fact that we recognize these problems but haven't been super-motivated to solve them, suggests that there hasn't really been that much call for stand alone Haskell libraries? (The proposal seems to say that C++ programmers could jump at this opportunity because they've been wanting to use Haskell but were afraid of the IO Monad?) Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is this a correct explanation of FRP?
On Thu, Apr 5, 2012 at 4:30 AM, Ertugrul Söylemez wrote: > Paul Liu wrote: > >> > This isn't switching. It's selection. If fullTime decides to be >> > productive, then alterTime acts like fullTime. Otherwise it acts >> > like halfTime. If both inhibit, then alterTime inhibits. This >> > allows for a much more algebraic description of reactive systems. >> >> AFRP can do this through ArrowChoice. Maybe you can explain the >> concept of "inhibition" in more detail? >> >> I fail to grasp why this is making switches obsolete. The idea of >> switch is to completely abandoning the old state. See the broken >> pendulum example. > > Some of this can be done through ArrowChoice. The difference is > comparable to why server parts form a monoid in Happstack. You don't > have to decide when a server part reaches a request. You let the server > part decide itself. In other words ArrowChoice forces you to deal with > events in the application itself: > > -- Library code: > x = x' > y = y' > > -- Application code: > proc inp -> do > r <- request -< () > if p r > then x -< inp > else y -< inp > > Signal inhibition allows the component wires themselves to deal with the > events and you as the higher level programmer to just stick the wires > together: > > -- Library code: > x = proc inp -> do requireReq -< (); x' -< inp > y = y' > > -- Application code: > x <|> y I'm curious as to how this plays out with the usual arrow compositions. How does x *** y behave when x inhibits? what about z >>> x? This cannot replace switching though, since the structure of your arrows cannot change dynamically, while with switches it can. -- Regards, Paul Liu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I Need a Better Functional Language!
Le 5 avril 2012 16:14, Grigory Sarnitskiy a écrit : > Hello! I've just realized that Haskell is no good for working with functions! > > First, what are 'functions' we are interested at? It can't be the usual > set-theoretic definition, since it is not constructive. The constructive > definition should imply functions that can be constructed, computed. Thus > these are computable functions that should be of our concern. But computable > functions in essence are just a synonym for programs. > > One could expect from a language that bears 'functional' as its > characteristic to be able to do everything imaginable with functions. > However, the only thing Haskell can do with functions is to apply them to > arguments and to feed them as arguments, run in parallel (run and concatenate > programs). > > Obviously, that's not all of the imaginable possibilities. One also can > rewrite programs. And write programs that rewrite programs. And write > programs that rewrite programs that rewrite the first programs and so on. But > there is no such possibility in Haskell, except for introducing a DSL. > > So now I wonder, what are the languages that are functional in the sense > above? With a reasonable syntax and semantics, thus no assembler. I guess > Lisp might be of this kind, but I'm not sure. In addition, I'm not a fan of > parentheses. What else? Pure? Mathematica? Maxima? Hello, You might be interested in https://github.com/MikeHaskel/Constructiva/wiki Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] I Need a Better Functional Language!
Hello! I've just realized that Haskell is no good for working with functions! First, what are 'functions' we are interested at? It can't be the usual set-theoretic definition, since it is not constructive. The constructive definition should imply functions that can be constructed, computed. Thus these are computable functions that should be of our concern. But computable functions in essence are just a synonym for programs. One could expect from a language that bears 'functional' as its characteristic to be able to do everything imaginable with functions. However, the only thing Haskell can do with functions is to apply them to arguments and to feed them as arguments, run in parallel (run and concatenate programs). Obviously, that's not all of the imaginable possibilities. One also can rewrite programs. And write programs that rewrite programs. And write programs that rewrite programs that rewrite the first programs and so on. But there is no such possibility in Haskell, except for introducing a DSL. So now I wonder, what are the languages that are functional in the sense above? With a reasonable syntax and semantics, thus no assembler. I guess Lisp might be of this kind, but I'm not sure. In addition, I'm not a fan of parentheses. What else? Pure? Mathematica? Maxima? Note, that the reflectivity is important. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell integration with C/C++ (GSOC)
On Thursday, April 5, 2012 at 1:53 AM, Sutherland, Julian wrote:
> Hey Guys,
>
> I'm Julian, I am reaching the end of my second year as a JMC (Joint
> Mathematics and Computer science) Student at Imperial College London
> and I'd like to apply to GSOC for a project involving Haskell and I just
> wanted to run my idea past the community.
[snip]
> I found an example of such a bug, which I will test further before reporting
> it.
> It seems to be the opposite of the following bug:
> http://hackage.haskell.org/trac/ghc/ticket/5594
>
> i.e. the stdout buffer isn't always correctly flushed when calling C/C++ in a
> program whose main is written in Haskell.
>
> For example, when running the code:
>
> main.hs:
> module Main where
>
> import Foreign.C.Types
> import System.IO
>
> foreign import ccall "inc" c_inc :: CInt -> CInt
>
> main :: IO ()
> main = do
> putStr "Enter n: "
> -- hFlush stdout
> s <-getLine
> putStrLn . show . c_inc . read $ s
>
> inc.c:
>
> int inc(int i) __attribute__ ((const));
>
> int inc(int i)
> {
> return i + 1;
> }
>
> Built with
> Makefile:
> all:
> gcc -c -o inc.o inc.c
> ghc --make -main-is Main main.hs inc.o -o test
> rm *.hi *.o
>
> The output comes out as:
> [julek@cryptid inc]$ ./test
> 2
> Enter n: 3
>
> But when the " hFlush stdout" line is commented back in, the output is:
> [julek@cryptid inc]$ ./test
> Enter n: 2
> 3
>
> which is correct, but the extra line shouldn't be necessary.
>
> I am currently using ghc 7.4.1 which is the newest version, so this is a
> current bug.
I think this is a consequence of line buffering rather than a bug. If you write
your own increment function in Haskell, you get the same behavior. If you
`hSetBuffering stdout NoBuffering` before your `putStr` call, you should get
the behavior you wanted. I've seen similar issues with programs written in many
languages; it's just one of those gotchas to be aware of when dealing with
console UI.
As to the rest of your proposal, when you started out talking about calling
Haskell from C or C++, I hoped you would focus on the pain of linking the final
executable. This seems to me a more fundamental -- and addressable -- stumbling
block than the richness of interaction with C++. As things stand, it is quite a
hassle to use a Haskell library of any complexity called from C. Improved
interaction with C++ could indeed be valuable, but, unless something has
changed recently, work is still needed to improve the more basic C -> Haskell
FFI story.
Anthony
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] thread killed
On Thu, Apr 5, 2012 at 12:05 PM, Gregory Collins wrote: > +haskell-cafe, oops > > On Thu, Apr 5, 2012 at 11:04 AM, Gregory Collins > wrote: >> >> On Wed, Apr 4, 2012 at 10:09 PM, tsuraan wrote: >>> >>> > It's hard to rule Snap timeouts out; try building snap-core with the >>> > "-fdebug" flag and running your app with "DEBUG=1", you'll get a spew >>> > of >>> > debugging output from Snap on stderr. >>> >>> Heh, that was quite a spew. I normally get the exceptions tens of MB >>> into files that are hundreds of MB, and I sometimes don't get them at >>> all, so printing out the entire request body was a bit slow :) After >>> commenting out some of the more talkative debug statements, I got the >>> exception to happen, and it looks generally like this: >> >> >> I think I might know what your problem is. You're accepting file uploads >> using handleMultipart, yes? Snap kills uploads that are going too slow, >> otherwise you would be vulnerable to slowloris >> (http://ha.ckers.org/slowloris/) DoS attacks. What's probably happening here >> is that you're doing slow work inside the "Iteratee IO a" handler you pass >> to that function, which makes Snap think the client is trickling bytes to >> you. If that's the case, either finish the iteratee more quickly and do the >> slow work back in the Snap handler (preferable), or disable the minimum >> upload rate guard (although that's not recommended on a server talking to >> the public internet.) Wouldn't it make more sense to pause the timeout handler when running user code? That's what we do in Warp. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] thread killed
+haskell-cafe, oops On Thu, Apr 5, 2012 at 11:04 AM, Gregory Collins wrote: > On Wed, Apr 4, 2012 at 10:09 PM, tsuraan wrote: > >> > It's hard to rule Snap timeouts out; try building snap-core with the >> > "-fdebug" flag and running your app with "DEBUG=1", you'll get a spew of >> > debugging output from Snap on stderr. >> >> Heh, that was quite a spew. I normally get the exceptions tens of MB >> into files that are hundreds of MB, and I sometimes don't get them at >> all, so printing out the entire request body was a bit slow :) After >> commenting out some of the more talkative debug statements, I got the >> exception to happen, and it looks generally like this: >> > > I think I might know what your problem is. You're accepting file uploads > using handleMultipart, yes? Snap kills uploads that are going too slow, > otherwise you would be vulnerable to slowloris ( > http://ha.ckers.org/slowloris/) DoS attacks. What's probably happening > here is that you're doing slow work inside the "Iteratee IO a" handler you > pass to that function, which makes Snap think the client is trickling bytes > to you. If that's the case, either finish the iteratee more quickly and do > the slow work back in the Snap handler (preferable), or disable the minimum > upload rate guard (although that's not recommended on a server talking to > the public internet.) > > G > -- > Gregory Collins > -- Gregory Collins ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fail-back monad
There is also recent work by Aaron Turon and Olin Shivers - Modular Rollback through Control Logging http://www.ccs.neu.edu/home/shivers/ http://www.ccs.neu.edu/home/turon/ Note that as well as the paper on Olin Shivers's site there is a more recent monadic presentation on Aaron Turon's site with Conor McBride... On 28 March 2012 18:11, Stephen Tetley wrote: > Maybe this is a version of William Harrison's DebugT monad with > rollback, listed in his periodic table of effects? > > http://www.cs.missouri.edu/~harrisonwl/Presentations/UIUCFM05.ppt > > I've never seen a definition of the monad itself... > http://www.haskell.org/pipermail/beginners/2010-January/003371.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell integration with C/C++ (GSOC)
On Thu, Apr 5, 2012 at 03:21, Holger Siegel wrote:
> Am 05.04.2012 um 08:42 schrieb Brandon Allbery:
> > On Thu, Apr 5, 2012 at 01:53, Sutherland, Julian <
> julian.sutherlan...@imperial.ac.uk> wrote:
> > data Tree = Node Left Right | Leaf
> >
> > Could be converted to a struct in C/C++:
> >
> > struct Tree {
> > struct Tree* left;
> > struct Tree* right;
> > };
> >
> > Shouldn't this actually be a tagged union? Not that they exist as such
> in C/C++, but are easy enough to emulate (minus the extra type checking
> that real tagged unions such as even Pascal gives you):
>
> Not necessarily. The above type is equivalent to
>
> type Tree = Maybe (Left, Right)
>
But that is not the type being translated. (Also, I would still consider
translating Maybe as something other than a NULL pointer, just to enable
sanity checking.)
--
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] Haskell integration with C/C++ (GSOC)
Am 05.04.2012 um 08:42 schrieb Brandon Allbery:
> On Thu, Apr 5, 2012 at 01:53, Sutherland, Julian
> wrote:
> data Tree = Node Left Right | Leaf
>
> Could be converted to a struct in C/C++:
>
> struct Tree {
> struct Tree* left;
> struct Tree* right;
> };
>
> Shouldn't this actually be a tagged union? Not that they exist as such in
> C/C++, but are easy enough to emulate (minus the extra type checking that
> real tagged unions such as even Pascal gives you):
Not necessarily. The above type is equivalent to
type Tree = Maybe (Left, Right)
(modulo strictness, of course) and the C/C++ convention is to represent Nothing
by a NULL pointer.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fail-back monad
> I thoutgh on the use or ErrorT or something similar but the fact is
> that i need many bacPoints, not just one. That is, The user can go
> many pages back in the navigation pressing many times te back
> buttton.
The approach in the previous message extends to an arbitrary,
statically unknown number of checkpoints. If we run the following
simple code
> test1 = loop "" 1
> where
> loop acc n = inquire ("Enter string " ++ show n) >>= check acc n
> check acc n "" = liftIO . putStrLn $ "You have entered: " ++ acc
> check acc n str = loop (acc ++ str) (n+1)
>
> test1r = runContT test1 return
we can do the following:
*BackT> test1r
Enter string 1
s1
Enter string 2
s2
Enter string 3
s3
Enter string 4
s4
Enter string 5
back
Enter string 4
back
Enter string 3
back
Enter string 2
x1
Enter string 3
x2
Enter string 4
x3
Enter string 5
back
Enter string 4
y3
Enter string 5
You have entered: s1x1x2y3
I decided to go back after the fourth string, but you should feel free
to go forth.
The ContT approach is very flexible: we can not only go back, or go
back more. We can go all the way back. We can go back to the point
where certain condition was true, like when the value of the certain
named field was entered or certain value was computed.
Here is the complete code. For a change, it uses IO exceptions rather
than ErrorT.
> {-# LANGUAGE DeriveDataTypeable #-}
>
> module BackT where
>
> import Control.Monad.Trans
> import Control.Monad.Cont
> import Control.Exception
> import Data.Typeable
> import Prelude hiding (catch)
>
> data RestartMe = RestartMe deriving (Show, Typeable)
> instance Exception RestartMe
>
> -- Make a `restartable' exception
> -- (restartable from the beginning, that is)
> -- We redo the computation once we catch the exception RestartMe
> -- Other exceptions propagate up as usual.
>
> type BackT r m a = ContT r m a
> abort e = ContT(\k -> e)
>
> -- Send a prompt, receive a reply. If it is "back", go to the
> -- previous checkpoint.
> type Prompt = String
> inquire :: Prompt -> BackT r IO String
> inquire prompt = ContT loop
> where
> loop k = exchange >>= checkpoint k
> exchange = do
> putStrLn prompt
> r <- getLine
> if r == "back" then throw RestartMe
>else return r
> checkpoint k r = k r `catch` (\RestartMe -> loop k)
>
> -- Go to the previous checkpoint
> goBack :: BackT r m a
> goBack = abort (throw RestartMe)
>
>
> test1 = loop "" 1
> where
> loop acc n = inquire ("Enter string " ++ show n) >>= check acc n
> check acc n "" = liftIO . putStrLn $ "You have entered: " ++ acc
> check acc n str = loop (acc ++ str) (n+1)
>
> test1r = runContT test1 return
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
