Re: [Haskell-cafe] Re: Transformers versus monadLib versus...
Fragmenting Hackage is bad. But on the other hand I don't see why I should stick with the inconvenient mtl. Open source software is all about choice, and as long as the mtl fails to provide the same flexibility and convenience, I won't use it. Combined with the fact that fixing it would break existing packages, it appears like I won't go back to the mtl ever. So tell me how you do when you have to use a package which relies on mtl's transformers? You re-develop the package? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [C Binding] Turning the mutable to immutable?
That's indeed an advice I've read [1]. But wouldn't it damage the performances, since code will have to go through an extra layer? [1] http://blog.ezyang.com/2010/06/principles-of-ffi-api-design 2010/7/7 Chris Eidhof ch...@eidhof.nl On 5 jul 2010, at 23:48, Yves Parès wrote: Hello, I don't know if some of you are familiar with the SFML library (stands for Simple and Fast Multimedia Library) -- http://sfml-dev.org As SDL, SFML is a 2D graphics library, but conversely to SDL it provides a hardware-accelerated drawing, through OpenGL. Well, I'm currently writing its Haskell binding, and I'm stuck with design issues. What I'm heading to is a full IO binding, and that's what I'd like to avoid. Have you considered writing a low-level binding and building a high-level library on top of that? -chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [C Binding] Turning the mutable to immutable?
2010/7/7 Liam O'Connor lia...@cse.unsw.edu.au Making an immutable API from a mutable one generally damages performance (on von neumann architectures) somewhat, the goal is to minimize that impact. In fact, I would like to determine if an EFFICIENT way to make images and such immutable exists, or if it is impossible. I looked at graphics-drawingcombinators. It is nice, but it doesn't fully answer to my problem since it just loads images and draws them. It provides no ways to alter them, no problem of mutability, then. 2010/7/7 Chris Eidhof ch...@eidhof.nl Premature optimization is the root of all evil ;) Yes, you are right, this is wise. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [C Binding] Turning the mutable to immutable?
Okay, so I think that the better idea is to carry on with my low-level, imperative binding, and then build a more functional on top of this. Concerning the mutability of images, I notice that the problem with SFML is that it handles Sprites in a way that is even more imperative than OpenGL texture handling. 2010/7/7 Sebastian Sylvan sebastian.syl...@gmail.com On Wed, Jul 7, 2010 at 2:24 PM, Yves Parès limestr...@gmail.com wrote: 2010/7/7 Liam O'Connor lia...@cse.unsw.edu.au Making an immutable API from a mutable one generally damages performance (on von neumann architectures) somewhat, the goal is to minimize that impact. In fact, I would like to determine if an EFFICIENT way to make images and such immutable exists, or if it is impossible. Both OpenGL and DirectX, while supporting updates to images, make it slow enough that any image data is effectively immutable. Each animation step a completely fresh frame buffer is created, without overwriting any of the inputs, by combining these immutable images in interesting ways. You're expected to combine multiple immutable data sources in the shader to produce the final output (which will be a different image from the inputs). Examples of data sources would be images, transformation matrices, colours etc. It's extremely rare to see people poke values individually into a mutable buffer (in fact, the capability of doing this on the GPU is very recent, and even then it's highly limited). You do a big purely functional transform from inputs to outputs instead. HLSL and GLSL may not look like functional languages, but they essentially are, in that each kernel runs independently with no shared mutable state, producing outputs from immutable inputs. So, if you want to do it on the CPU, I would mimic the way GPUs have been doing it for ages. Define what operations you want to perform in terms of the inputs, and then do them all in bulk to produce the output image. You don't want people to go in and arbitrarily set pixels to anything they want at any time they want. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Transformers versus monadLib versus...
monadLib looks nice, indeed, but the major problem with using it resides in the fact that most of the libraries on hackage use MTL. Must be tedious to have to use two monad libraries at the same time... 2010/7/6 Ertugrul Soeylemez e...@ertes.de Gregory Crosswhite gcr...@phys.washington.edu wrote: What is the current state of opinion regarding transformers versus monadLib versus mmtl versus ... etc.? Transformers seems to be the blessed replacement for mtl, so when is it worthwhile to use the other libraries instead? (It hadn't even occurred to me to look closely at packages other than transformers for this purpose until I read a message earlier today from someone who said that he uses monadLib whenever he needs to use monad transformers, and it has now made me curious about them.) That would be me. When I was sick of flipping runWhateverT all the time, I had a closer look at the 'transformers' package. But my impression was that the only advantage is that I wouldn't need to flip anymore. I compared it to monadLib, which does a lot more. It saves me from having to do multi-lifts in complicated monads and it has a generalized MonadIO, called BaseM, which works for other lowest-level-monads, too, like 'ST s'. It includes a ChoiceT monad transformer, which is like ListT, but is not broken. Further it has very useful monadic functions. For example there is an 'abort' function to escape from a ContT computation, so you don't need to use that ugly callCC, if you just want early exit route. You also get labelled jumps for free, if you ever need them desperately. As an interesting feature, if you have a monad, which is isomorphic to a known monad, you can derive all the Functor/Monad instance functions from this isomorphism. All you need to do is to tell monadLib how one would turn a computation of the monad in question into a computation of the known monad. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ 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] Re: Transformers versus monadLib versus...
Yes but, for instance, every library which provides monad transformers will provides a MTL's MonadTrans instance, not a monadLib's MonadT instance. And since a library hides its types internals, you cannot write the MonadT instances yourself. For instance, I was planning to translate a little program of mine (which uses quite heavily monad transformers) to monadLib. It uses the packages operational which is based on MTL, and I cannot make myself operational's transformers instances of MonadT. How would you solve that? (btw, I like the fact that monadLib provides IdT ^^ (IdentityT)) 2010/7/6 Ertugrul Soeylemez e...@ertes.de Yves Parès limestr...@gmail.com wrote: monadLib looks nice, indeed, but the major problem with using it resides in the fact that most of the libraries on hackage use MTL. Must be tedious to have to use two monad libraries at the same time... In general this is a minor problem. Note that when using a monad from another library usually you get provided with a type alias (or even a newtype) and a number of convenience functions, so you don't have to access names from both libraries at the same time. I can only speak for myself, but I've never had a problem with this, even though my packages often have lots and lots of dependencies. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ 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] Re: Transformers versus monadLib versus...
I was wondering : wouldn't it be possible that things like BaseM be implemented on top of MTL? Couldn't just one develop a package, say mtl-missing, that would contain the functionnalities of monadLib, but compatible with MTL? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is Haskell unsuitable for?
I must have the same impediment. We should start a support group, that, or give in and write a compiler. To add insult to injury, I think it should be called Turbo Haskell. That's true... I never noticed, because in French the two words get pronounced very differently. While we're on the topic, does anyone else get funny looks when they say monads? Sadly, yes. ;) ^^ Had some puns related to genitals? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is my code too complicated?
About monad transformers, I don't really like to use them because they can get hairy in some cases, and because they have poor performance in other cases. Then what is your alternative? How do you replace monad transformers? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Subtype polymorphism in Haskell
data A_GADT where A_GADT :: A t = t - A_GADT By the way, is there an extension that enables A_GADT to be automatically declared as an instance of class A? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [C Binding] Turning the mutable to immutable?
Hello, I don't know if some of you are familiar with the SFML library (stands for Simple and Fast Multimedia Library) -- http://sfml-dev.org As SDL, SFML is a 2D graphics library, but conversely to SDL it provides a hardware-accelerated drawing, through OpenGL. Well, I'm currently writing its Haskell binding, and I'm stuck with design issues. What I'm heading to is a full IO binding, and that's what I'd like to avoid. I particularly like the way HGL works, with the Draw monad which (IMO) enables powerful composability of the drawings. But HGL is simpler in the way that, for instance, it doesn't deal with images/sprites. So that's why I would like to pick up advice concerning the design of such a binding. First, this is how SFML (in C/C++) works: The main types are RenderWindow, Drawable, Image, Sprite, Shape, Font and Text. An Image basically represents an array of pixels. It is just a resource, and is not directly drawable. An image is loaded from a file, and provides methods for accessing/altering its pixels. Its main purpose is to be bound as an OpenGL texture. A RenderWindow is the window on which the Drawables are... well... drawn. A Sprite, now, is a Drawable. One Sprite is linked to one Image. A Sprite NEVER alters its Image, it just provides positionning/rotation/resizing/colorizing methods that will be translated, when drawing on the RenderWindow, to glTranslate/glRotate/glScale/glColor, etc. So we can see a Sprite as an instance of an Image, since if a same Image is to be drawn 3 times on the same frame, we are advised to create three Sprites of it, which will differ by their position. A Font is loaded from a file, it is a simple resource, just like Image. Text and Shape are Drawables. So, now, questions: 1) For those who know HGL, can the monad Draw principle be adapted to my case? Or am I heading for disaster? 2) How would I handle images? SFML API enables the user to alter the pixels of the image, and I obviously don't wanna copy the entire Image each time a pixel is changed. 3) Is there another library on hackage that handles images in a functional way? (I mean not *all in IO*) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rank2Types and pattern matching
Okay, I understand better, now.
But I could never have guessed it just from the GHC error message.
Another question on the same code:
import Control.Monad.Identity
newtype SomeMonad s a = SomeMonad { unSome :: Identity a }
deriving (Monad)
newtype SomeType s = SomeType Int
runSomeMonad :: (forall s. SomeMonad s a) - a
runSomeMonad x = runIdentity . unSome $ x
foo :: SomeType s
foo = runSomeMonad (return $ SomeType 42)
According to what I read about ST, it should not compile because of 'foo'
(hence the protection), well it does.
What have I forgotten in my code?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rank2Types and pattern matching
That's it !
Indeed, you do not create a STRef yourself using a STRef data constructor,
you use the function:
newSTRef :: a - GHC.ST.ST s (STRef s a)
Thanks.
2010/7/4 Dan Doel dan.d...@gmail.com
On Sunday 04 July 2010 5:41:07 am Yves Parès wrote:
Okay, I understand better, now.
But I could never have guessed it just from the GHC error message.
Another question on the same code:
import Control.Monad.Identity
newtype SomeMonad s a = SomeMonad { unSome :: Identity a }
deriving (Monad)
newtype SomeType s = SomeType Int
runSomeMonad :: (forall s. SomeMonad s a) - a
runSomeMonad x = runIdentity . unSome $ x
foo :: SomeType s
foo = runSomeMonad (return $ SomeType 42)
According to what I read about ST, it should not compile because of 'foo'
(hence the protection), well it does.
What have I forgotten in my code?
The s in your SomeType isn't linked in any way to the variable quantified
in
the SomeMonad. You're producing:
return $ SomeType 42 :: forall t. SomeMonad t (SomeType s)
and running it to get the SomeType s. You need something to tie them
together,
like:
mkSomeType :: Int - SomeMonad s (SomeType s)
mkSomeType i = return (SomeType i)
and then hide the SomeType constructor, perhaps.
-- Dan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Are you a Haskell expert? [How easy is it to hire Haskell programmers]
And conversely, someone who have made a C-to-Haskell binding may not be a Haskell guru. What about Arrows: do you think one should master them so that he could be regarded as experienced? It's kind of hard to put a border between casual Haskell and skilled Haskell, since it's a very wide language and your knowledge will depend on what you have already done. 2010/7/3 Thomas Davie tom.da...@gmail.com On 3 Jul 2010, at 11:04, Brandon S Allbery KF8NH wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/3/10 05:57 , Andrew Coppin wrote: Agreed. So let me rephrase: Why should _every_ Haskell library involve C? ;-) Who says they do, or should? Dons rather implied it... The suggestion is that someone who hasn't used hsc2hs is an inexperienced Haskeller... I'd bet though that there are many *extremely* experienced haskellers who have never once in their life written a C binding. Bob___ 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] Are you a Haskell expert? [How easy is it to hire Haskell programmers]
Back to initial topic, I have a sudden fear: do you have to master Template
Haskell so as to be regarded as a guru :-{ ?
Let it be no, please, let it be no...
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Rank2Types and pattern matching
Hello everybody,
I'm trying to implement the type protection used by ST to prevent a monad
from returning a certain type.
There's my code:
import Control.Monad.Identity
newtype SomeMonad s a = SomeMonad { unSome :: Identity a }
deriving (Monad)
newtype SomeType s = SomeType Int
runSomeMonad :: (forall s. SomeMonad s a) - a
runSomeMonad (SomeMonad x) = runIdentity x
And when compiled, I got this error:
phantom.hs:10:14:
Couldn't match expected type `forall s. PwetMonad s a'
against inferred type `PwetMonad s a1'
In the pattern: PwetMonad x
In the definition of `runPwetMonad':
runPwetMonad (PwetMonad x) = runIdentity x
But when I change line 10 to:
runSomeMonad x = runIdentity . unSome $ x
then it works, so obviously, the trouble is about pattern matching.
What was I doing wrong?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Continuations and coroutines
Hello, I saw on the haskell wikibook that coroutines could be implemented by using continuations : http://en.wikibooks.org/wiki/Haskell/Continuation_passing_style#Example:_coroutines(unhappily, the section is empty) Since I'm actually learning the wonders of continuations, I just wonder : how ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Continuations and coroutines
It helps me understand better, but would you have some simple code that would do that ? 2010/6/19 Paul Johnson p...@cogito.org.uk On 19/06/10 10:36, Yves Parčs wrote: Hello, I saw on the haskell wikibook that coroutines could be implemented by using continuations : http://en.wikibooks.org/wiki/Haskell/Continuation_passing_style#Example:_coroutines(unhappily, the section is empty) Since I'm actually learning the wonders of continuations, I just wonder : how ? Coroutines depend on the ability to suspend and resume execution. A continuation acts as the resume point in the current function. The callCC function in the continuation monad takes a function that expects the continuation as an argument (which is how you get access to it). So you say something like: yield = callCC $ \continuation - Then you would typically store the continuation somewhere and call some other previously stored continuation to switch contexts. Continuations can be used to pass data back into the continuation: you call the continuation with an argument, and that argument becomes the return value of the callCC. In this case you probably just want to use (). You typically have a queue for continuations, so the new continuation goes on the back of the queue and then you call the head of the queue. Obvious modifications for priority, simulated time, real time or whatever else you are trying to schedule. This implies some kind of monadic state to store the queue in, so you will probably make your monad of type ContT (State Queue) If you want a thread to wait, say on a semaphore, then you have a queue of continuations in the semaphore data structure. Is this any help? Paul. ___ 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] Simple game: a monad for each player
Thanks, I looked at the operational package (since it seemed simpler). I see its interest when building sets of operations. I think I see how I could apply it to my current problem. I saw in the tutorial the sentence: The ability to write multiple interpreters is also very useful for implementing games, specifically to account for both human and computer opponents as well as replaying a game from a script. So I'm supposed to write 2 functions, one interpretHuman (running in IO, and prompting the user), and one interpretAI (running in Identity)? Are there examples of such games using operational? Heinrich Apfelmus wrote: Gwern Branwen wrote: Yves Parès limestr...@gmail.com wrote: [...] But when running the game, the program cannot switch from a player's monad to another. Do you have any suggestion? Your desires remind me of the MonadPrompt package http://hackage.haskell.org/package/MonadPrompt, which IIRC, has been used in some game demos to provide abstraction from IO/test harness/pure AI etc. The game demo can be found by chasing links from the package documentation: http://int-e.home.tlink.de/haskell/solitaire.tar.gz There's also my package operational http://hackage.haskell.org/package/operational which implements the same concept. It's throughly explained here: http://apfelmus.nfshost.com/articles/operational-monad.html http://projects.haskell.org/operational/ Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Simple-game%3A-a-monad-for-each-player-tp28183930p28201466.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple game: a monad for each player
I answered my own question by reading this monad-prompt example: http://paste.lisp.org/display/53766 But one issue remains: those examples show how to make play EITHER a human or an AI. I don't see how to make a human player and an AI play SEQUENTIALLY (to a TicTacToe, for instance). Yves Parès wrote: Thanks, I looked at the operational package (since it seemed simpler). I see its interest when building sets of operations. I think I see how I could apply it to my current problem. I saw in the tutorial the sentence: The ability to write multiple interpreters is also very useful for implementing games, specifically to account for both human and computer opponents as well as replaying a game from a script. So I'm supposed to write 2 functions, one interpretHuman (running in IO, and prompting the user), and one interpretAI (running in Identity)? Are there examples of such games using operational? Heinrich Apfelmus wrote: Gwern Branwen wrote: Yves Parès limestr...@gmail.com wrote: [...] But when running the game, the program cannot switch from a player's monad to another. Do you have any suggestion? Your desires remind me of the MonadPrompt package http://hackage.haskell.org/package/MonadPrompt, which IIRC, has been used in some game demos to provide abstraction from IO/test harness/pure AI etc. The game demo can be found by chasing links from the package documentation: http://int-e.home.tlink.de/haskell/solitaire.tar.gz There's also my package operational http://hackage.haskell.org/package/operational which implements the same concept. It's throughly explained here: http://apfelmus.nfshost.com/articles/operational-monad.html http://projects.haskell.org/operational/ Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Simple-game%3A-a-monad-for-each-player-tp28183930p28201834.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple game: a monad for each player
Okay for IA, which doesn't need any special monad, but what if I want to make a network player ? It would have to run in a State monad, accessing to IO, storing a ByteString. For instance, (Monad m) = StateT ByteString m. The ByteString is a lazy one, we read from it to get the data sent by the real player through the network. Then, if I want to have a human an a network player playing sequentially, how can I do this without stacking each player's monad? (See my first mail) Philippa Cowderoy wrote: On 10/04/2010 13:57, Yves Parès wrote: I answered my own question by reading this monad-prompt example: http://paste.lisp.org/display/53766 But one issue remains: those examples show how to make play EITHER a human or an AI. I don't see how to make a human player and an AI play SEQUENTIALLY (to a TicTacToe, for instance). Make them polymorphic - the human player in any MonadIO, the AI player in any monad. Then run them both in the same monad, with some kind of wrapping function around the calls setting a context for the appropriate player. -- fli...@flippac.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Simple-game%3A-a-monad-for-each-player-tp28183930p28204685.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple binary-protocol through network test
It's amazing! But I'm surprised no one else has this problem, as I assume using network + lazy bytestrings is quite frequent when you want to do network programming in Haskell. BTW, you may not have the same libraries versions as me. Maybe this problems doesn't occur in older versions of bytestring or network. I have the last versions : - network-2.2.1.7 - bytestring-0.9.1.6 (and binary-0.5.0.2, but the simple example showed that the problem came from deeper than it) Daniel Fischer-4 wrote: Am Mittwoch 07 April 2010 21:53:20 schrieb Daniel Fischer: Am Mittwoch 07 April 2010 20:43:24 schrieb Yves Parès: Yes, from what I read, I assumed it had this behavior. But, then, I don't see why the server holds... I've posted a mail on Haskell-Cafe called Network: buffering troubles, in which I put a smaller example which reproduces this problem. I know :) I have now tested it, with both (simple) servers and I can't reproduce the problem (ghc-6.12.1 and ghc-6.10.3). Installed binary-protocol and tried the original (no hSetBuffering), that also works flawlessly (ghc-6.12.1 on openSuSE 11.1). Server: $ ../BeginnersTesting/Server I wait for a client... Result: Just 1.6190478 I wait for a client... Result: Just 12.0 I wait for a client... Result: Nothing ^C Client: $ ./Client localhost Operation? Operation 3.4 Div 2.1 Operation sent. 1.6190478 Operation? Operation 17 Minus 5 Operation sent. 12.0 Operation? Stop Operation sent. Seems to be something with Ubuntu. Maybe somebody else on Ubuntu could test it? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28174807.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple binary-protocol through network test
Problem tracked! It comes from the last version of bytestring package. I tried with bytestring-0.9.1.5, and it works perfectly. Do you know where I should submit this bug? - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28175020.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple binary-protocol through network test
By the way, Gregory, concerning the package binary-protocol, I was wondering if it was possible to turn the BinaryProtocol monad from type BinaryProtocol = StateT (Handle, Handle, ByteString) IO to: type BinaryProtocol = StateT (Handle, Handle, ByteString) And then the functions, like runProtocol, would become: runProtocol :: (MonadIO m) = BinaryProtocol m a - Handle - Handle - m a I mean that BinaryProtocol could run within any MonadIO, not only IO. This would turn the BinaryProtocol into a monad trans, which would be more generic (we could for instance stack two BinaryProtocols). Yves Parès wrote: Problem tracked! It comes from the last version of bytestring package. I tried with bytestring-0.9.1.5, and it works perfectly. Do you know where I should submit this bug? - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28180773.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Simple game: a monad for each player
Hello Cafe,
I have a question about program design.
Let's say I have a simple sequential game (a TicTacToe for instance, but
with more than 2 players).
I have a Player datatype which is like:
data Player m = Player {
plName :: String, -- unique for each player
plTurn :: GameGrid - m Move -- called whenever the player must play
}
As you may guess, the 'm' type variable is intended to be a Monad.
The goal is that every player has his own monad. For instance :
- a human player needs to interact with the program, so its monad would be
IO, or an instance of MonadIO.
- a network player, which transparently sends the game state and receives
moves through network, must also have access to IO to play.
- an AI doesn't need to interact with the outside of the program, so its
monad can be the one we want (e.g. Identity).
First, do you think it is a good way to design the program?
I want the game to be totally independent of the players who are currently
playing. They can be humans, AIs, AIs and network players and humans, and so
on.
But when running the game, the program cannot switch from a player's monad
to another.
If we want every player to run in his own monad, I think we have to stack
every players' monad, and lift their actions each time they have to play.
This is not a problem, the sole condition now is that every player has type:
(Monad m, MonadTrans m) = Player m.
But I think it's a little bit of overkill, and it may be a little bit
complicated to implement such a thing.
What I try to avoid is having every player running in IO monad.
Do you have any suggestion?
-
Yves Parès
Live long and prosper
--
View this message in context:
http://old.nabble.com/Simple-game%3A-a-monad-for-each-player-tp28183930p28183930.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple binary-protocol through network test
Okay, Guess I will have to learn how to use git. I used darcs so far... Concerning the bug in bytestring, I sent a mail to dons. I just still have no answer. Gregory Crosswhite-2 wrote: That sounds like a reasonable modification; if you want, free to fork it at http://github.com/gcross/binary-protocol and push me your proposed changes. Cheers, Greg On Apr 8, 2010, at 9:12 AM, Yves Parès wrote: By the way, Gregory, concerning the package binary-protocol, I was wondering if it was possible to turn the BinaryProtocol monad from type BinaryProtocol = StateT (Handle, Handle, ByteString) IO to: type BinaryProtocol = StateT (Handle, Handle, ByteString) And then the functions, like runProtocol, would become: runProtocol :: (MonadIO m) = BinaryProtocol m a - Handle - Handle - m a I mean that BinaryProtocol could run within any MonadIO, not only IO. This would turn the BinaryProtocol into a monad trans, which would be more generic (we could for instance stack two BinaryProtocols). Yves Parès wrote: Problem tracked! It comes from the last version of bytestring package. I tried with bytestring-0.9.1.5, and it works perfectly. Do you know where I should submit this bug? - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28180773.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.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 - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28184890.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Network: buffering troubles
Hello, I have isolated a problem when using (lazy) ByteStrings through the network (GHC 6.12.1, Ubuntu 9.10 32bits): Here is my client: http://old.nabble.com/file/p28162932/Client.hs Client.hs And my server: http://old.nabble.com/file/p28162932/Server.hs Server.hs The server holds until the client closes the connection, even if I flush the handle on the client side after writing or even if I turn off buffering on both sides. - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Network%3A-buffering-troubles-tp28162932p28162932.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Network: buffering troubles
Apparently, the trouble seems to come from binary deserialization. When I read my handle with: inp - L.hGet hdl 24 and no longer with: inp - L.hGetContents hdl I get a lazy bytestring which is no longer infinite, and then deserialization occurs right. It proves that at the time of deserialization, the server has all the data it needs, and should not hold. I usually don't know the size of the structures I receive through network. I only know their type, and this should be sufficient for Data.Binary.decode, since it knows how to work with lazy bytestrings. Apparently, this example shows no problem with GHC 6.10. I think that network+binary is quite a common combination in Haskell, so is there anyone here who also uses GHC 6.12 and has this problem? Yves Parès wrote: Hello, I have isolated a problem when using (lazy) ByteStrings through the network (GHC 6.12.1, Ubuntu 9.10 32bits): Here is my client: http://old.nabble.com/file/p28162932/Client.hs Client.hs And my server: http://old.nabble.com/file/p28162932/Server.hs Server.hs The server holds until the client closes the connection, even if I flush the handle on the client side after writing or even if I turn off buffering on both sides. - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Network%3A-buffering-troubles-tp28162932p28166613.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Network: buffering troubles
News! (Sorry for the spam, but this problem turns to be a headache) The problem actually comes from ByteStrings (either lazy or strict). I reduced my server code to this: import Network import System.IO import qualified Data.ByteString(.Lazy) as L main = do (hdl,_,_) - listenOn (PortNumber ) = accept hSetBuffering hdl NoBuffering inp - L.hGetContents hdl putStrLn . show $ L.take 8 inp My client hasn't changed, and sends properly the data. So the server shouldn't hold. Well, even when trying to rawly print the first 8 bytes of the stream, it does. But when I use normal Strings, it doesn't hold: import Network import System.IO main = do (hdl,_,_) - listenOn (PortNumber ) = accept hSetBuffering hdl NoBuffering inp - hGetContents hdl putStrLn . show $ take 8 inp I think this behavior is normal for strict ByteStrings, but not for lazy ones... - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Network%3A-buffering-troubles-tp28162932p28166941.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple binary-protocol through network test
I'm wondering, would it be a problem of chunk size when using L.hGetContents? Since the data to read is shorter than the default chunk size (32k), would it cause problems? Yves Parès wrote: Okay, so I turned off every buffering using hSetBuffering hdl NoBuffering on both Client and Server, but that doesn't fix it... BTW, I tried to do the same without your package, i.e. simply through Lazy ByteString and Binary, but it doesn't work either, I come up against the same issue. Gregory Crosswhite-2 wrote: Hmm, I am guessing it is more likely that the problem is that the I/O system changed from 6.10.4 to 6.12.1 somehow in a way that broke the package. You could try turning off all buffering in the handle using hSetBuffering and seeing if that works. Cheers, Greg On Apr 6, 2010, at 3:44 PM, Yves Parès wrote: Weird... I use GHC 6.12.1, and I run Ubuntu 9.10 (32bits version). Would have I miss something? Like a flush or a close? Logically, I don't see where I would... Gregory Crosswhite-2 wrote: Yay, I'm glad to see someone else using my package. :-) Hmm, your program seems to work for me. I compiled and ran the Server (with ghc --make), then compiled and ran the Client, and then typed Operation 1.0 Mult 2.0 into the Client process, and the result it got was 2.0 with the output Just 2.0 on the Server. I got the same results running this on Mac OSX and (Gentoo) Linux, with GHC 10.4. What platform/GHC version are you running it on? Cheers, Greg On Apr 6, 2010, at 2:38 PM, Yves Parès wrote: Hello, I'm trying to use the packages Network and Control.Monad.BinaryProtocol together, with a very simple program in which a client sends an operation to the server, which computes the result and sends it back. But the server holds when trying to receive (Server.hs, line 22), whereas the client has actually sent the data (Client.hs, line 17). The server stops to hold only when the client is killed with a Ctrl-C. This should be rather simple, and I can't get to know why it doesn't work. The files are here: http://old.nabble.com/file/p28157883/Client.hs Client.hs http://old.nabble.com/file/p28157883/Server.hs Server.hs http://old.nabble.com/file/p28157883/SharedData.hs SharedData.hs - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28157883.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.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 - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28158514.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.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 - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28168542.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple binary-protocol through network test
Yes, from what I read, I assumed it had this behavior. But, then, I don't see why the server holds... I've posted a mail on Haskell-Cafe called Network: buffering troubles, in which I put a smaller example which reproduces this problem. Daniel Fischer-4 wrote: That shouldn't cause problems. When less than the default chunk size is available, it makes a chunk of what it got and tries to get more later (unless it found EOF, then it closes the handle). - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28169295.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Simple binary-protocol through network test
Hello, I'm trying to use the packages Network and Control.Monad.BinaryProtocol together, with a very simple program in which a client sends an operation to the server, which computes the result and sends it back. But the server holds when trying to receive (Server.hs, line 22), whereas the client has actually sent the data (Client.hs, line 17). The server stops to hold only when the client is killed with a Ctrl-C. This should be rather simple, and I can't get to know why it doesn't work. The files are here: http://old.nabble.com/file/p28157883/Client.hs Client.hs http://old.nabble.com/file/p28157883/Server.hs Server.hs http://old.nabble.com/file/p28157883/SharedData.hs SharedData.hs - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28157883.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple binary-protocol through network test
Weird... I use GHC 6.12.1, and I run Ubuntu 9.10 (32bits version). Would have I miss something? Like a flush or a close? Logically, I don't see where I would... Gregory Crosswhite-2 wrote: Yay, I'm glad to see someone else using my package. :-) Hmm, your program seems to work for me. I compiled and ran the Server (with ghc --make), then compiled and ran the Client, and then typed Operation 1.0 Mult 2.0 into the Client process, and the result it got was 2.0 with the output Just 2.0 on the Server. I got the same results running this on Mac OSX and (Gentoo) Linux, with GHC 10.4. What platform/GHC version are you running it on? Cheers, Greg On Apr 6, 2010, at 2:38 PM, Yves Parès wrote: Hello, I'm trying to use the packages Network and Control.Monad.BinaryProtocol together, with a very simple program in which a client sends an operation to the server, which computes the result and sends it back. But the server holds when trying to receive (Server.hs, line 22), whereas the client has actually sent the data (Client.hs, line 17). The server stops to hold only when the client is killed with a Ctrl-C. This should be rather simple, and I can't get to know why it doesn't work. The files are here: http://old.nabble.com/file/p28157883/Client.hs Client.hs http://old.nabble.com/file/p28157883/Server.hs Server.hs http://old.nabble.com/file/p28157883/SharedData.hs SharedData.hs - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28157883.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.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 - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28158514.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple binary-protocol through network test
Okay, so I turned off every buffering using hSetBuffering hdl NoBuffering on both Client and Server, but I doesn't fix it... BTW, I tried to do the same without your package, i.e. simply through Lazy ByteString and Binary, but it doesn't work either, I come up against the same issue. Gregory Crosswhite-2 wrote: Hmm, I am guessing it is more likely that the problem is that the I/O system changed from 6.10.4 to 6.12.1 somehow in a way that broke the package. You could try turning off all buffering in the handle using hSetBuffering and seeing if that works. Cheers, Greg On Apr 6, 2010, at 3:44 PM, Yves Parès wrote: Weird... I use GHC 6.12.1, and I run Ubuntu 9.10 (32bits version). Would have I miss something? Like a flush or a close? Logically, I don't see where I would... Gregory Crosswhite-2 wrote: Yay, I'm glad to see someone else using my package. :-) Hmm, your program seems to work for me. I compiled and ran the Server (with ghc --make), then compiled and ran the Client, and then typed Operation 1.0 Mult 2.0 into the Client process, and the result it got was 2.0 with the output Just 2.0 on the Server. I got the same results running this on Mac OSX and (Gentoo) Linux, with GHC 10.4. What platform/GHC version are you running it on? Cheers, Greg On Apr 6, 2010, at 2:38 PM, Yves Parès wrote: Hello, I'm trying to use the packages Network and Control.Monad.BinaryProtocol together, with a very simple program in which a client sends an operation to the server, which computes the result and sends it back. But the server holds when trying to receive (Server.hs, line 22), whereas the client has actually sent the data (Client.hs, line 17). The server stops to hold only when the client is killed with a Ctrl-C. This should be rather simple, and I can't get to know why it doesn't work. The files are here: http://old.nabble.com/file/p28157883/Client.hs Client.hs http://old.nabble.com/file/p28157883/Server.hs Server.hs http://old.nabble.com/file/p28157883/SharedData.hs SharedData.hs - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28157883.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.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 - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28158514.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.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 - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28158761.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[Haskell-cafe] mote invocations in Haskell?
Hello, Is there a way to perform some kind of remote method invocation in haskell? (Or, remote object, but I prefer not to use this term, as there are no objects strictly speaking in Haskell) I would like to use a higher level API than sockets for network programing. - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Remote-invocations-in-Haskell--tp28006793p28006793.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[Haskell-cafe] mote invocations in Haskell?
Okay, I tried to make the sample here: http://www.haskell.org/haskellwiki/HaXR But I can't get it working... Is there an external XML-RPC server that must be running? Maybe even an external HTTP server? The server launches without complaining about anything, whereas the client tells: simple_client: user error (Error calling examples.add: connect: does not exist (Connection refused)) I know I have to adapt the url the client tries to connect at (in the sample, http://localhost/~bjorn/cgi-bin/simple_server;), but I don't know how. Roman Cheplyaka-2 wrote: * Yves Parès limestr...@gmail.com [2010-03-23 13:46:25-0700] Is there a way to perform some kind of remote method invocation in haskell? (Or, remote object, but I prefer not to use this term, as there are no objects strictly speaking in Haskell) I would like to use a higher level API than sockets for network programing. There is for example XML-RPC library for Haskell. http://hackage.haskell.org/package/haxr -- Roman I. Cheplyaka :: http://ro-che.info/ Don't let school get in the way of your education. - Mark Twain ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Remote-invocations-in-Haskell--tp28006793p28007923.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[Haskell-cafe] mote invocations in Haskell?
Okay, well, apparently I have to rely on an external HTTP server. This is not very simple, is there another more suitable way to get RPC working in haskell? Yves Parès wrote: Okay, I tried to make the sample here: http://www.haskell.org/haskellwiki/HaXR But I can't get it working... Is there an external XML-RPC server that must be running? Maybe even an external HTTP server? The server launches without complaining about anything, whereas the client tells: simple_client: user error (Error calling examples.add: connect: does not exist (Connection refused)) I know I have to adapt the url the client tries to connect at (in the sample, http://localhost/~bjorn/cgi-bin/simple_server;), but I don't know how. Roman Cheplyaka-2 wrote: * Yves Parès limestr...@gmail.com [2010-03-23 13:46:25-0700] Is there a way to perform some kind of remote method invocation in haskell? (Or, remote object, but I prefer not to use this term, as there are no objects strictly speaking in Haskell) I would like to use a higher level API than sockets for network programing. There is for example XML-RPC library for Haskell. http://hackage.haskell.org/package/haxr -- Roman I. Cheplyaka :: http://ro-che.info/ Don't let school get in the way of your education. - Mark Twain ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Remote-invocations-in-Haskell--tp28006793p28008179.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Lists of Existential DT
Hello! I have a class Drawable, and some datatypes which are instances of it, and I would like to be able to draw them all at once! drawMany window [image, text, otherImage] I think the type of the function drawMany would be: drawMany :: Window - [forall a. (Drawable a) = a] - IO () However it doesn't work. I know one solution is to make a new datatype (e.g. DrawableObj) which will be: data DrawableObj = forall a (Drawable a) = DrawableObj a And then declare drawMany as: drawMany :: Window - [DrawableObj] - IO () But to use it I have to wrap up myself every drawable in a DrawableObj: drawMany window [DrawableObj image, DrawableObj text, DrawableObj otherImage] Is there another more suitable way to handle a list of drawables? - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Lists-of-Existential-DT-tp27735354p27735354.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lists of Existential DT
jkff wrote: Or like this, with the benefit of using lists. data DrawableObj a = forall a.Drawable a = DrawableObj a a , b = DrawableObj a : b drawMany (a,b,c,[]) I like this solution, but it's a pity I think that Haskell doesn't provide a way to use types like [forall a. (Drawable a) = a], which obligates you to declare an extra datatype... - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Lists-of-Existential-DT-tp27735354p27737144.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[Haskell-cafe] [2]: Threading and FFI
Dean Herington wrote: Careful. If you're calling foreign functions that rely on thread-local storage, you must call them using the same OS thread (to provide them with the correct thread state), which means using the same, *bound*, Haskell thread. It wouldn't work to call them from both the main Haskell thread and another Haskell thread, even if the latter were a bound thread, as there would be two copies of thread-local storage at play. That's alright. I'm used to putting all the related calls in the same thread as long as it is possible. It'd seem unlogical to me -- conceptually speaking -- to spread OpenGL calls between several threads. I understand better, now. Actually, I think I was getting worked up for nothing ^^. Just one last remark: when I moved all my OpenGL calls from the main thread to an unbound thread. I thought it'd not work -- because I assumed I would have to launch it in a bound thread -- and however it went right... - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Threading-and-FFI-tp27611528p27665592.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[Haskell-cafe] [2]: Threading and FFI
Ben Franksen wrote: You can leave them unsafe if you are sure that 1) they do not call (back) any function in your program 2) they do not block (or not long enough that it bothers you) Otherwise they are no less safe that the safe calls. If (1) is not fulfilled bad things might (that is, probably will) happen. Thus, if you are not sure, chose safe. Okay. Since I know which functions call back to haskell code and which make pauses, I know what need to be safe and what can be let safely unsafe (^^). Bound thread are ONLY needed if you (that is, some foreign functions you use) rely on thread-local storage. Yes, but since the main thread (if I understood well) is bound, if I call to C functions which rely on thread-local storage (like OpenGL functions, according to GHC Control.Concurrent doc) in this thread I should have no problem, shouldn't I? And if I choose to call these functions from outside the main thread it'll have to be from a thread launched with forkOS? (The C functions I call in my real code actually use OpenGL internally) If runtime is threaded and FFI call is marked safe and Haskell thread is unbound, then calls to such a function will be executed from SOME extra OS thread that is managed completely behind the scenes. Okay, that's what I didn't understand! Only the call to my safe function will be done in an external bound thread, not the whole thread in which the call is done. So, to sum up, my program will run this way (not necessarily in this order): My main is launched in a bound thread. My casual haskell I/O operations (read and print from and to the terminal) are launched in an unbound thread. Whenever my main thread reaches the call to my safe C function which 'sleeps', it launches it in another bound thread. Am I right or is it no that easy to foresee the behaviour of my program? - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Threading-and-FFI-tp27611528p27647126.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Threading and FFI
I've also discovered something interesting: when I link with the 'threaded' runtime, but let the program use only one core (with '+RTS -N1'), the problem disappears. How comes? The whole thing remains a mystery, because I think what I'm trying to do is quite common... Yves Parès wrote: There is a minimal code which produces this issue: http://old.nabble.com/file/p27613138/func.c func.c http://old.nabble.com/file/p27613138/main.hs main.hs Yves Parès wrote: Well I tried both 'unsafe' and 'safe', and actually I saw no difference... Even with 'safe', I see a huge difference between calling a C function which sleeps and another which doesn't. When there is a sleep, the other thread is really slower (it just prints numbers, and I look at which pace they're displayed). - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Threading-and-FFI-tp27611528p27621580.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Threading and FFI
Okay! So under UNIX, haskell threaded runtime uses pthreads, if I well understood. To sum up, in order to achieve what I want, I have no other choice than compiling with '-threading' and importing as 'safe' the functions which can make a 'sleep'. Thanks! Ben Franksen wrote: Yves Parès wrote: I've also discovered something interesting: when I link with the 'threaded' runtime, but let the program use only one core (with '+RTS -N1'), the problem disappears. How comes? The whole thing remains a mystery, because I think what I'm trying to do is quite common... Yves Parès wrote: There is a minimal code which produces this issue: http://old.nabble.com/file/p27613138/func.c func.c http://old.nabble.com/file/p27613138/main.hs main.hs Yves Parès wrote: Well I tried both 'unsafe' and 'safe', and actually I saw no difference... Even with 'safe', I see a huge difference between calling a C function which sleeps and another which doesn't. When there is a sleep, the other thread is really slower (it just prints numbers, and I look at which pace they're displayed). This is to be expected. From the docs (http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.2.0.0/Control-Concurrent.html#10): The downside of having lightweight threads is that only one can run at a time, so if one thread blocks in a foreign call, for example, the other threads cannot continue. The GHC runtime works around this by making use of full OS threads where necessary. When the program is built with the -threaded option (to link against the multithreaded version of the runtime), a thread making a safe foreign call will not block the other threads in the system; another OS thread will take over running Haskell threads until the original call returns. The runtime maintains a pool of these worker threads so that multiple Haskell threads can be involved in external calls simultaneously. IIRC, with -threaded, the RTS spawns a separate OS thread for 'safe' foreign calls _in addition_ to the OS threads used for Haskell code (the number of which you give with the +RTS -Nn option). Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Threading-and-FFI-tp27611528p27631980.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[Haskell-cafe] [2]: Threading and FFI
Thank you all. But there are two things that remain obscure: First, there is my situation: int the main thread, I call to some C functions binded through FFI. All of them are marked 'unsafe', except one, which is internally supposed to make pauses with 'usleep'. I then execute in another haskell thread (with forkIO) some pure haskell actions. I then compile with the threaded RTS, and let at run the default behaviour which is to use one core. Question 1) What happens to the unsafe C functions? I that simply that the threaded RTS is unable to prevent them from blocking haskell threads (which in my case is a problem only for the function which pauses, since other C calls are fast)? Or they could provoke a hazardous issue, so I have to mark all the C functions as safe (which will be much slower) because ? Question 2) In the Control.Concurrent documentation, I understood that forkIO creates unbound threads whereas forkOS creates bound threads, but what is not very clear is: when does GHC threaded runtime launches as bound instead of unbound if this one has been started with forkIO? When it detects the thread calls to a C function? When it detects it calls to a safe C function (*)? When it detects another thread calls to a (safe) C function (which is my case)? (*) according to documentation it would be this case. However as I said my C calls are done in the MAIN thread. The other thread just executes casual haskell operations, however it is not blocked, which makes me think that even if I launch it with forkIO, it is launched as an bound thread. Bulat Ziganshin-2 wrote: Hello Yves, Thursday, February 18, 2010, 2:10:42 AM, you wrote: Okay! So under UNIX, haskell threaded runtime uses pthreads, if I well understood. not exactly. it still uses lightweight (green) threads, but starts additional OS threads as required to keep N haskell threads running. it's very smart To sum up, in order to achieve what I want, I have no other choice than compiling with '-threading' and importing as 'safe' the functions which can make a 'sleep'. Thanks! - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Threading-and-FFI-tp27611528p27635260.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Undecidable instances with functional dependencies
However, TypeFamilies seems too be non portable as according to this
http://www.haskell.org/haskellwiki/GHC/Type_families, it works only as from
GHC 6.10.1.
Henning Thielemann-4 wrote:
Miguel Mitrofanov schrieb:
-- {-# LANGUAGE FunctionalDependencies#-}
-- {-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE TypeFamilies #-}
module Register where
-- class Register a r | a - r
class Register a where
type R a
-- instance Register Int Int
instance Register Int where
type R Int = Int
-- instance Register Float Float
instance Register Float where
type R Float = Float
-- instance (Register a1 r1, Register a2 r2) = Register (a1, a2) (r1,
r2)
instance (Register a, Register b) = Register (a, b) where
type R (a, b) = (R a, R b)
So type functions are undecidable by default?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
-
Yves Parès
Live long and prosper
--
View this message in context:
http://old.nabble.com/Undecidable-instances-with-functional-dependencies-tp27555079p27605436.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Threading and FFI
Hello! I was wondering: is the Haskell default runtime (that which uses only one processor) scheduler able to interrupt a thread which is currently calling to a C function in order to enable another haskell thread to progress? I think it can't, because I have starvation problems when I have a thread which calls inside its loop to a C function which makes a little sleep. BTW, what is the portable way to sleep a thread in Haskell ? Control.Concurrent.threadDelay is GHC only. - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Threading-and-FFI-tp27611528p27611528.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Threading and FFI
Well I tried both 'unsafe' and 'safe', and actually I saw no difference... Even with 'safe', I see a huge difference between calling a C function which sleeps and another which doesn't. When there is a sleep, the other thread is really slower (it just prints numbers, and I look at which pace they're displayed). Felipe Lessa wrote: On Tue, Feb 16, 2010 at 09:00:08AM -0800, Yves Parès wrote: I was wondering: is the Haskell default runtime (that which uses only one processor) scheduler able to interrupt a thread which is currently calling to a C function in order to enable another haskell thread to progress? I think it can't, because I have starvation problems when I have a thread which calls inside its loop to a C function which makes a little sleep. Did you try marking the call as safe? Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Threading-and-FFI-tp27611528p27612884.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Threading and FFI
There is a minimal code which produces this issue: http://old.nabble.com/file/p27613138/func.c func.c http://old.nabble.com/file/p27613138/main.hs main.hs Yves Parès wrote: Well I tried both 'unsafe' and 'safe', and actually I saw no difference... Even with 'safe', I see a huge difference between calling a C function which sleeps and another which doesn't. When there is a sleep, the other thread is really slower (it just prints numbers, and I look at which pace they're displayed). - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Threading-and-FFI-tp27611528p27613138.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Atom Examples
Thanks! Looks a bit complex to me at the moment, but I'll probably have a look at it when I have the time. Tom Hawkins-2 wrote: On Sun, Feb 14, 2010 at 1:30 AM, Yves Parès limestr...@gmail.com wrote: I've been interested in using Atom since I saw this: http://blog.sw17ch.com/wordpress/?p=84 However those samples are very outdated, do you have newer ones? Unfortunately, no. I wish I had the time to write Atom examples and tutorials, but I don't. So in lieu of a tutorial, here's a few modules we use on our real projects -- with limited documentation. Arbiter.hs: A general purpose non-preemptive arbiter than implements Lamport's bakery algorithm. We use this to arbitrate multiple software components that need to use the CAN protocol stacks for sending multi-packet messages. This is a good example that illustrates some of the benefits of atomic state transitions rules. What I find interesting is it works without any centralized arbiter logic; notice there are no rule declarations in mkArbiter. ECU.hs: This is the hardware abstraction layer to our ECU. Nothing too interesting, but a good example of how to wire Atom up to external C code. Note the ECU record includes a bunch of expressions (E types) and variables (V types). The expressions form the inputs, like ADCs and discrete inputs, and the mutable variables form the outputs, such as PWMs and discrete outputs. It also provides hooks to send and receive CAN messages. EVU.hs: The eVU is a little display mounted on the dash. It presents the driver with information such as charge pressure, mode settings, and fault conditions. The ECU talks to the eVU via the CAN bus. This is a good example because it illustrates a common object-oriented pattern we tend to use all over the place: the object contructor (mkEVU) creates some state variables, defines rules for stuff to do, and packages the state variables into an abstract type, or object (EVU); then methods operate on this object. In the case of EVU, the object constructor defines variables for the things the eVU displays, and it defines a rule to periodically send this information to the eVU device via CAN. And the methods set the various display elements such as the active fault code (setCode), the accumulator pressure (setCharge), and the active mode (setMode). Sensors.hs: Sensor processing, which takes data from the hardware abstraction layer (ECU.hs). One interesting feature is the oil temperature sensor computation. Based on a 1-D lookup table the 'lookup1D' function searches the table for the corresponding points and performs interpolation. In C, this probably would have been written as a for-loop that would compute the lookup on every sample. But because change in oil temperature is much slower than the sample rate of the system, we only need to search one row of the table every 50 samples or so (i.e. with rules 'below', 'above', 'next', and 'found'). This effectively spreads out the computation over many samples, thus lowering the processing latency of every sample. Doing this type of time-sharing in C would be tricky. But in Atom, it's trivial. One of the many ways Atom benefits hard realtime programming. I hope this helps. -Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Atom-Examples-tp27580935p27581803.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: atom-1.0.0
I've been interested in using Atom since I saw this: http://blog.sw17ch.com/wordpress/?p=84 However those samples are very outdated, do you have newer ones? Tom Hawkins-2 wrote: Atom is a Haskell DSL for designing hard realtime embedded software. The 1.0 release is meant to indicate some level of stability; most of the core has been unchanged for quite some time. That said, there are a few interesting changes in 1.0. First the var' family of variable declarations (bool', word8', double', etc.) are no longer part of the Atom monad. For example: bool' :: Name - V Bool This cleaned up quite a bit of code in our production design. This also made the randomization in Atom's unit testing framework monadless as well. The other significant change with 1.0 is all state variables are now packed into a hierarchical C structure that matches the hierarchy of the Atom design. Not only does this make the generated C a bit more legible, it is now possible to interface external C code directly to Atom's state variables and arrays. Prior to this change, all interfacing had to be done through var' declarations and action calls -- too often a messy process. To further aid interfacing to external code, Atom now generates a header file that exposes both the iterative function and the hierarchical state structure. -Tom http://hackage.haskell.org/package/atom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/ANN%3A-atom-1.0.0-tp27574165p27579930.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
