Re: [Haskell-cafe] Memory and Threads - MVars or TVars
This could be useful: Beautiful concurrency by Simon Peyton Jones http://research.microsoft.com/en-us/um/people/simonpj/papers/stm/beautiful.pdf On 29 July 2010 02:23, Eitan Goldshtrom thesource...@gmail.com wrote: Hi everyone. I was wondering if someone could just guide me toward some good information, but if anyone wants to help with a personal explanation I welcome it. I'm trying to write a threaded program and I'm not sure how to manage my memory. I read up on MVars and they make a lot of sense. My real question is what is atomic and how does it apply to TVars? I don't understand what atomic transactions are and I can't seem to find a concise explanation. I also saw some stuff about TMVars? But I can't find much on them either. Any help would be appreciated. -Eitan ___ 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] data.binary get reading beyond end of input bytestring?
On 28 July 2010 23:32, Gregory Collins g...@gregorycollins.net wrote:
Conrad Parker con...@metadecks.org writes:
Hi,
I am reading data from a file as strict bytestrings and processing
them in an iteratee. As the parsing code uses Data.Binary, the
strict bytestrings are then converted to lazy bytestrings (using
fromWrap which Gregory Collins posted here in January:
-- | wrapped bytestring - lazy bytestring
fromWrap :: I.WrappedByteString Word8 - L.ByteString
fromWrap = L.fromChunks . (:[]) . I.unWrap
This just makes a 1-chunk lazy bytestring:
(L.fromChunks . (:[])) :: S.ByteString - L.ByteString
). The parsing is then done with the library function
Data.Binary.Get.runGetState:
-- | Run the Get monad applies a 'get'-based parser on the input
-- ByteString. Additional to the result of get it returns the number of
-- consumed bytes and the rest of the input.
runGetState :: Get a - L.ByteString - Int64 - (a, L.ByteString, Int64)
The issue I am seeing is that runGetState consumes more bytes than the
length of the input bytestring, while reporting an
apparently successful get (ie. it does not call error/fail). I was
able to work around this by checking if the bytes consumed input
length, and if so to ignore the result of get and simply prepend the
input bytestring to the next chunk in the continuation.
Something smells fishy here. I have a hard time believing that binary is
reading more input than is available? Could you post more code please?
The issue seems to just be the return value for bytes consumed from
getLazyByteString. Here's a small example.
con...@hunter:~/src/haskell/binary-overrun$ cat overrun.hs
{-# LANGUAGE OverloadedStrings #-}
import Data.Binary
import Data.Binary.Get
import qualified Data.ByteString.Lazy.Char8 as C
data TenChars = TenChars C.ByteString deriving (Show)
instance Binary TenChars where
get = getLazyByteString 10 = return . TenChars
put = undefined
consume bs = do
let (ret, rem, len) = runGetState (get :: Get TenChars) bs 0
putStrLn $ Input: ++ show bs ++ , length ++ (show $ C.length bs)
putStrLn $ consumed ++ (show len) ++ bytes without error.
putStrLn $ Output: ++ show ret
putStrLn $ Remain: ++ show rem
main = do
consume 1234567890ABCDE
consume 1234567890
consume 12345
con...@hunter:~/src/haskell/binary-overrun$ ./overrun
Input: Chunk 1234567890ABCDE Empty, length 15
consumed 10 bytes without error.
Output: TenChars (Chunk 1234567890 Empty)
Remain: Chunk ABCDE Empty
Input: Chunk 1234567890 Empty, length 10
consumed 10 bytes without error.
Output: TenChars (Chunk 1234567890 Empty)
Remain: Empty
Input: Chunk 12345 Empty, length 5
consumed 10 bytes without error.
Output: TenChars (Chunk 12345 Empty)
Remain: Empty
Here, the third example claims to have consumed 10 bytes out of the
available 5, and does not fail. The issue is that this return value
cannot be used for maintaining offsets. It is documented that it will
not fail, but the returned len value seems to be incorrect.
I've now added a check that fails if the returned bytestring is
shorter than required.
However I am curious as to why this apparent lack of bounds checking
happens. My guess is that Get does not check the length of the input
bytestring, perhaps to avoid forcing lazy bytestring inputs; does that
make sense?
Would a better long-term solution be to use a strict-bytestring binary
parser (like cereal)? So far I've avoided that as there is
not yet a corresponding ieee754 parser.
If you're using iteratees you could try attoparsec + attoparsec-iteratee
which would be a more natural way to bolt parsers together. The
attoparsec-iteratee package exports:
parserToIteratee :: (Monad m) =
Parser a
- IterateeG WrappedByteString Word8 m a
Attoparsec is an incremental parser so this technique allows you to
parse a stream in constant space (i.e. without necessarily having to
retain all of the input). It also hides the details of the annoying
buffering/bytestring twiddling you would be forced to do otherwise.
thanks for the pointer :)
Conrad.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: weighted-regexp-0.1.0.0
Maybe even write a blog about how it works? A whole blog is probably unnecessary ;) But a blog *post* would be nice! -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Fun with uu-parsinglib
On 29 jul 2010, at 05:04, David Place wrote: Hi, Doaitse. I am making good progress transcribing my parser to use your library. I think some ways that I have grown accustomed to working with Parsec will not work, though. Now, I am getting the run time error: Result: *** Exception: cannot compute minimal length of right hand side of monadic parser Is there an explanation of this error in the documentation? I am trying to combine with alternation some parsers which return the semantic data structures of my program. Perhaps there are restrictions on the kind of parsers that can be combined with alternation. Cheers, David David Place Owner, Panpipes Ho! LLC http://panpipesho.com d...@vidplace.com Dear David, I am cc-ing this answer to Haskell-café since the answer may be of a wider interest. Let me first explain a a sequence of design choices I made: 1) my parser combinators perform error correction by trying to insert missing tokens into and to delete superfluous tokens from the input 2) of course there are many possibilities to do so 3) hence I implemented a search process which currently prunes the tree of possible corrective choices up to depth three 4) this process may return several solutions with the same overall cost and I have to pick one of those 5) in case of a draw I give preference to those alternatives which delete something, so progress is guaranteed 6) at the end of the input this does not work, since there is nothing to delete 7) if I pick an arbitrary alternative this may lead to a choice where we get an infinite sequence of insertions; suppose e.g. we want to insert an expression, and the system picks the if_alternative. If it does so it inserts an if-token and then the process starts all over again by trying to insert a conditional expression, which in general will be an expression, which will lead to the insertion of another if-token, etc. 8) in order to prevent this behaviour internally an abstract interpretation is made which computes the minimal number of tokens a parser will recognise (and thus can insert). The recursive alternatives will get an infinite length, and will thus never be chosen unless you grammar is well-formed and all choices only can lead to an infinite sequence of insertions 9) if a choice has to be made for the correction process always a finite alternative is chosen, so the correction process is guaranteed to complete Now the monads come in; they raise the question how to compute the minimal length of a parser WHICH DEPENDS ON A PREVIOUSLY RECOGNISED part of the input. In general this is impossible. So I made the decision to generate an error message in such cases, since I did not expect many people to run into this. But now you, and probably many people used to writing parsers in the monadic (i.e. Parsec) style turn up, and you continue to use the monadic style bacuse you have become accustomed to a different way of writing parsers. Let me give an example, based on the following grammar for well-formed nested parentheses: S - (S)S ; epsilon. We want to return e.g. the maximal nesting depth. This is one of the functions in the Examples.hs file in the uu-parsinglib. The prototypical way of writing this in applicative style, without using monads is: wfp :: Parser Int wfp = max . (+1) $ pParens wfp * wfp `opt` 0 Now let us take a look at the monadic formulation: wfp = do lt - pParens wfp rt - wfp -- second call to wfp return ((lt + 1) `max` rt) | return 0 Now we see that the second call to wfp is within the scope of the binding of lt, and hence may depend on it. In this case it does not, but unfortunately the abstract interpretation cannot see this, and thus cannot do very much. This shows in my view the bad thing about monadic parser combinators: they prohibit the self-analysis of parsers, they inhibit optimisations, and they inhibit feedback based on the analysis. More on this below. Since I assume that the monadic formulation is only used as a last resort, i.e. when a parser REALLY depends on previous input, and that this will in general not be part of an alternative construct, I have decided to generate the above error message. Another solution I could have chosen is to make the choice in the correction process based on the order in which the alternatives occur in the program, but this would create the need to explain to users that the order of their alternatives matters, and it is one of the nice things that thus far it does not. In the old uulib the order even gets completely lost because we internally build tables which assist in speeding up the parsing process. There are several solutions now: a) I just remove the error message and make an educated guess, leading to situations where users might get stuck in an infinite correction process (only at the end of the file; normally in
Re: [Haskell-cafe] data.binary get reading beyond end of input bytestring?
On 29 July 2010 07:53, Conrad Parker con...@metadecks.org wrote: Something smells fishy here. I have a hard time believing that binary is reading more input than is available? Could you post more code please? The issue seems to just be the return value for bytes consumed from getLazyByteString. Here's a small example. http://hackage.haskell.org/packages/archive/binary/0.5.0.2/doc/html/Data-Binary-Get.html#v%3AgetLazyByteString getLazyByteString :: Int64 - Get ByteString An efficient get method for lazy ByteStrings. Does not fail if fewer than n bytes are left in the input. Because it does it lazily it cannot check if it's gone past the end of the input. Arguably this is crazy and the function should not exist. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] OpenGL Speed!
I'm having an unusual problem with OpenGL. To be honest I probably shouldn't be using OpenGL for this, as I'm just doing 2D and only drawing Points, but I don't know about any other display packages, so I'm making due. If this is a problem because of OpenGL however, then I'll have to learn another package. The problem is speed. I have a list of points representing the color of 800x600 pixels. All I'm trying to do is display the pixels on the screen. I use the following: renderPrimitive Points $ mapM_ display list flush where display [] = return () display ((x,y,i):n) = do color $ Color3 i i i vertex $ Vertex2 x y display n But, for some reason this takes FOREVER. I don't know how to use debugging hooks yet without an IDE -- and I don't use an IDE -- but I used a cleverly placed putStrLn to see that it was actually working, just really really slowly. Is there a solution to this speed problem or should I use a package that's more suited to 2D applications like this? Also, if I should use another package, are there any suggestions for which to use? Thanks for any help. -Eitan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] data.binary get reading beyond end of input bytestring?
On 29 July 2010 17:46, Duncan Coutts duncan.cou...@googlemail.com wrote: On 29 July 2010 07:53, Conrad Parker con...@metadecks.org wrote: Something smells fishy here. I have a hard time believing that binary is reading more input than is available? Could you post more code please? The issue seems to just be the return value for bytes consumed from getLazyByteString. Here's a small example. http://hackage.haskell.org/packages/archive/binary/0.5.0.2/doc/html/Data-Binary-Get.html#v%3AgetLazyByteString getLazyByteString :: Int64 - Get ByteString An efficient get method for lazy ByteStrings. Does not fail if fewer than n bytes are left in the input. Because it does it lazily it cannot check if it's gone past the end of the input. Arguably this is crazy and the function should not exist. cheers Duncan, that confirms my guess about the reason. Would you accept a patch quoting you on that last point to the comment? ;-) Conrad. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] data.binary get reading beyond end of input bytestring?
On Thu, 2010-07-29 at 19:01 +0900, Conrad Parker wrote: On 29 July 2010 17:46, Duncan Coutts duncan.cou...@googlemail.com wrote: On 29 July 2010 07:53, Conrad Parker con...@metadecks.org wrote: Something smells fishy here. I have a hard time believing that binary is reading more input than is available? Could you post more code please? The issue seems to just be the return value for bytes consumed from getLazyByteString. Here's a small example. http://hackage.haskell.org/packages/archive/binary/0.5.0.2/doc/html/Data-Binary-Get.html#v%3AgetLazyByteString getLazyByteString :: Int64 - Get ByteString An efficient get method for lazy ByteStrings. Does not fail if fewer than n bytes are left in the input. Because it does it lazily it cannot check if it's gone past the end of the input. Arguably this is crazy and the function should not exist. cheers Duncan, that confirms my guess about the reason. Would you accept a patch quoting you on that last point to the comment? ;-) The consensus plan amongst the binary hackers is to eliminate lazy lookahead functions and to rebuild binary on top of a continuation style using strict chunks (then with lazy decoding built on top). Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: weighted-regexp-0.1.0.0
Hello Chris, thanks for the examples. They show that by adding anchors, the meaning of regular expressions is no longer compositional. For example (^|a) accepts the empty word only if no characters have been read yet. So (^|a) =~ does hold but a(^|a) =~ a does not hold although a =~ a does. I deem compositionality an important property to compare the current implementation with its specification. As, currently, I don't know how to incorporate anchors without making a mess, I refrain from adding them for the moment. A more complicated use, perhaps as part of a crazy parser: (a(\n)?)(^|b)(c|$) That's a nice example and I don't know how to express this without anchors. Cheers, Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OpenGL Speed!
2010/7/29 Eitan Goldshtrom thesource...@gmail.com: I'm having an unusual problem with OpenGL. To be honest I probably shouldn't be using OpenGL for this, as I'm just doing 2D and only drawing Points, but I don't know about any other display packages, so I'm making due. If this is a problem because of OpenGL however, then I'll have to learn another package. The problem is speed. I have a list of points representing the color of 800x600 pixels. All I'm trying to do is display the pixels on the screen. I use the following: renderPrimitive Points $ mapM_ display list flush where display [] = return () display ((x,y,i):n) = do color $ Color3 i i i vertex $ Vertex2 x y display n But, for some reason this takes FOREVER. I don't know how to use debugging hooks yet without an IDE -- and I don't use an IDE -- but I used a cleverly placed putStrLn to see that it was actually working, just really really slowly. Is there a solution to this speed problem or should I use a package that's more suited to 2D applications like this? Also, if I should use another package, are there any suggestions for which to use? Thanks for any help. Hi, Although you can use Vertex* to put a single Point on the screen, it is not meant to be used as some kind of setPixel function. If your goal is simply to set pixels' value of a raster, you can still use OpenGL but should use a single textured quad (and thus manipulate the texture's pixels). There other possibilities to deal with raster graphics: - Use gtk; i.e. something like http://hackage.haskell.org/package/AC-EasyRaster-GTK - Output the data in some image format (if you want to do it yourself, the most simple is PPM) - Use X11 directly (if you're on unix) - ... HTH, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Memory and Threads - MVars or TVars
On Thu, Jul 29, 2010 at 3:49 AM, Eitan Goldshtrom thesource...@gmail.com wrote: Perhaps you guys could help me with Cabal now though? I'm trying to install Orc but it wants base=4.2 and =4.3 and I have 4.1 after installing the latest release of GHC. Cabal won't upgrade the base. It complains about a dependency to integer-simple. Anyone know what that's about? The latest version of GHC (6.12) comes with base 4.2. In general, base versions are tied to compiler versions, and you can't upgrade base on its own. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] data.binary get reading beyond end of input bytestring?
On Thu, 2010-07-29 at 19:17 +0900, Conrad Parker wrote: On 29 July 2010 19:13, Duncan Coutts duncan.cou...@googlemail.com wrote: On Thu, 2010-07-29 at 19:01 +0900, Conrad Parker wrote: On 29 July 2010 17:46, Duncan Coutts duncan.cou...@googlemail.com wrote: On 29 July 2010 07:53, Conrad Parker con...@metadecks.org wrote: Something smells fishy here. I have a hard time believing that binary is reading more input than is available? Could you post more code please? The issue seems to just be the return value for bytes consumed from getLazyByteString. Here's a small example. http://hackage.haskell.org/packages/archive/binary/0.5.0.2/doc/html/Data-Binary-Get.html#v%3AgetLazyByteString getLazyByteString :: Int64 - Get ByteString An efficient get method for lazy ByteStrings. Does not fail if fewer than n bytes are left in the input. Because it does it lazily it cannot check if it's gone past the end of the input. Arguably this is crazy and the function should not exist. cheers Duncan, that confirms my guess about the reason. Would you accept a patch quoting you on that last point to the comment? ;-) The consensus plan amongst the binary hackers is to eliminate lazy lookahead functions and to rebuild binary on top of a continuation style using strict chunks (then with lazy decoding built on top). I'll take that as a no on the patch. Oh, sorry, documentation patch is fine. How would that plan differ from having an iteratee version of data.binary? ie. something that is easily compatible with WrappedByteString, as the existing Data.Binary is easily compatible with Data.ByteString.Lazy? No idea what WrappedByteString is. It would look like attoparsec's resumable parser: data Result a = Fail !ByteString | Partial (ByteString - Result a) | Done !ByteString a runGet :: Get a - ByteString - Result a Point is you feed it strict bytestring chunks. Then decoding a lazy bytestring can be implemented on top easily, as can decoding a sequence lazily. I imagine you could fairly easily interface it with iteratee too. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Memory and Threads - MVars or TVars
You might try pulling downloading the package ('cabal fetch org' will do
this) and changing the base dependency (to = 4.1) in the orc.cabal file and
then build it manually (cabal configure cabal build cabal install
(while in the same directory as the .cabal file)) and see what happens.
I don't see any obvious reasons why it would need a version greater than
6.10, so it might just be an over restrictive dependency rule, but I might
be missing something.
- Job
On Wed, Jul 28, 2010 at 10:49 PM, Eitan Goldshtrom
thesource...@gmail.comwrote:
Ah! That clears that up a lot. I read the wiki page but something just
didn't make full sense about it until you used the word prevent. I
understand that the computer doesn't actually prevent other threads from
running -- that would defeat the purpose of the concurrency -- but it helped
clear it up. Perhaps you guys could help me with Cabal now though? I'm
trying to install Orc but it wants base=4.2 and =4.3 and I have 4.1 after
installing the latest release of GHC. Cabal won't upgrade the base. It
complains about a dependency to integer-simple. Anyone know what that's
about?
-Eitan
___
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] OpenGL Speed!
Yeah, using openGL Points to draw 2D images will probably be pretty slow. However, if you don't need to change your points every frame, a display list might improve the speed quite a bit (you could still transform the points as a whole). Also, you could try the SDL bindings for haskell: http://hackage.haskell.org/package/SDL SDL is better suited for 2D drawing (IMHO). http://www.libsdl.org/ - Job On Thu, Jul 29, 2010 at 6:51 AM, Vo Minh Thu not...@gmail.com wrote: 2010/7/29 Eitan Goldshtrom thesource...@gmail.com: I'm having an unusual problem with OpenGL. To be honest I probably shouldn't be using OpenGL for this, as I'm just doing 2D and only drawing Points, but I don't know about any other display packages, so I'm making due. If this is a problem because of OpenGL however, then I'll have to learn another package. The problem is speed. I have a list of points representing the color of 800x600 pixels. All I'm trying to do is display the pixels on the screen. I use the following: renderPrimitive Points $ mapM_ display list flush where display [] = return () display ((x,y,i):n) = do color $ Color3 i i i vertex $ Vertex2 x y display n But, for some reason this takes FOREVER. I don't know how to use debugging hooks yet without an IDE -- and I don't use an IDE -- but I used a cleverly placed putStrLn to see that it was actually working, just really really slowly. Is there a solution to this speed problem or should I use a package that's more suited to 2D applications like this? Also, if I should use another package, are there any suggestions for which to use? Thanks for any help. Hi, Although you can use Vertex* to put a single Point on the screen, it is not meant to be used as some kind of setPixel function. If your goal is simply to set pixels' value of a raster, you can still use OpenGL but should use a single textured quad (and thus manipulate the texture's pixels). There other possibilities to deal with raster graphics: - Use gtk; i.e. something like http://hackage.haskell.org/package/AC-EasyRaster-GTK - Output the data in some image format (if you want to do it yourself, the most simple is PPM) - Use X11 directly (if you're on unix) - ... HTH, Thu ___ 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] OpenGL Speed!
If you still want to use glVertex with GL_POINTS, instead of a display list, you'd better go with vertex array or VBO. But still, if the implicit coordinates of a raster is assumed, pairing the coordinates with their value is overkill. Cheers, Thu 2010/7/29 Job Vranish job.vran...@gmail.com: Yeah, using openGL Points to draw 2D images will probably be pretty slow. However, if you don't need to change your points every frame, a display list might improve the speed quite a bit (you could still transform the points as a whole). Also, you could try the SDL bindings for haskell: http://hackage.haskell.org/package/SDL SDL is better suited for 2D drawing (IMHO). http://www.libsdl.org/ - Job On Thu, Jul 29, 2010 at 6:51 AM, Vo Minh Thu not...@gmail.com wrote: 2010/7/29 Eitan Goldshtrom thesource...@gmail.com: I'm having an unusual problem with OpenGL. To be honest I probably shouldn't be using OpenGL for this, as I'm just doing 2D and only drawing Points, but I don't know about any other display packages, so I'm making due. If this is a problem because of OpenGL however, then I'll have to learn another package. The problem is speed. I have a list of points representing the color of 800x600 pixels. All I'm trying to do is display the pixels on the screen. I use the following: renderPrimitive Points $ mapM_ display list flush where display [] = return () display ((x,y,i):n) = do color $ Color3 i i i vertex $ Vertex2 x y display n But, for some reason this takes FOREVER. I don't know how to use debugging hooks yet without an IDE -- and I don't use an IDE -- but I used a cleverly placed putStrLn to see that it was actually working, just really really slowly. Is there a solution to this speed problem or should I use a package that's more suited to 2D applications like this? Also, if I should use another package, are there any suggestions for which to use? Thanks for any help. Hi, Although you can use Vertex* to put a single Point on the screen, it is not meant to be used as some kind of setPixel function. If your goal is simply to set pixels' value of a raster, you can still use OpenGL but should use a single textured quad (and thus manipulate the texture's pixels). There other possibilities to deal with raster graphics: - Use gtk; i.e. something like http://hackage.haskell.org/package/AC-EasyRaster-GTK - Output the data in some image format (if you want to do it yourself, the most simple is PPM) - Use X11 directly (if you're on unix) - ... HTH, Thu ___ 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] Memory and Threads - MVars or TVars
On Thu, Jul 29, 2010 at 6:53 AM, Job Vranish job.vran...@gmail.com wrote:
You might try pulling downloading the package ('cabal fetch org' will do
this) and changing the base dependency (to = 4.1) in the orc.cabal file
cabal also has an 'unpack' command for the particularly lazy (me). Ex:
cabal unpack orc ; sed s/base\W*= 4.2/base = 4.1/ orc*/*.cabal ;
cd orc* ; cabal install
Should unpack, fix the .cabal file, and install.
Cheers,
Thomas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OpenGL Speed!
Yep, no surprise there. I would suggest using bitmap[1] to construct your bitmap, and bitmap-opengl to put it into an OpenGL texture and draw it on a textured quad. I think OpenGL is actually an OK choice for this application, because it is the most portable graphics method we have available. If you are trying to redraw in realtime, eg. 30 FPS or so, I don't think you're going to be able to. There is just not enough GPU bandwidth (and probably not enough CPU) for that (unless you write it in a pixel shader, which IIRC haskell has some neat tools for, but I don't remember). If this is the case, see if you can boil down what you have into something that doesn't require so much data, e.g. polygons. [1] http://hackage.haskell.org/package/bitmap [2] http://hackage.haskell.org/package/bitmap-opengl On Thu, Jul 29, 2010 at 3:57 AM, Eitan Goldshtrom thesource...@gmail.com wrote: I'm having an unusual problem with OpenGL. To be honest I probably shouldn't be using OpenGL for this, as I'm just doing 2D and only drawing Points, but I don't know about any other display packages, so I'm making due. If this is a problem because of OpenGL however, then I'll have to learn another package. The problem is speed. I have a list of points representing the color of 800x600 pixels. All I'm trying to do is display the pixels on the screen. I use the following: renderPrimitive Points $ mapM_ display list flush where display [] = return () display ((x,y,i):n) = do color $ Color3 i i i vertex $ Vertex2 x y display n But, for some reason this takes FOREVER. I don't know how to use debugging hooks yet without an IDE -- and I don't use an IDE -- but I used a cleverly placed putStrLn to see that it was actually working, just really really slowly. Is there a solution to this speed problem or should I use a package that's more suited to 2D applications like this? Also, if I should use another package, are there any suggestions for which to use? Thanks for any help. -Eitan ___ 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] data.binary get reading beyond end of input bytestring?
On Wed, Jul 28, 2010 at 8:38 PM, Max Cantor mxcan...@gmail.com wrote: I have a similar issue, I think. The problem with attoparsec is it only covers the unmarshalling side, writing data to disk still requires manually marshalling values into ByteStrings. Data.Binary with Data.Derive provide a clean, proven (encode . decode == id) way of doing this. If there's a way to accomplish this with attoparsec, I'd love to know. Sorry, attoparsec is just a parsing library :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] data.binary get reading beyond end of input bytestring?
On Thu, Jul 29, 2010 at 6:15 AM, Duncan Coutts duncan.cou...@googlemail.com wrote: No idea what WrappedByteString is. WrappedByteString is a newtype wrapper around ByteString that has a phantom type. This allows instances of to be written such that ByteString can be used with the iteratee library. You can see the source here if you're interested: http://hackage.haskell.org/packages/archive/iteratee/0.3.5/doc/html/src/Data-Iteratee-WrappedByteString.html It would look like attoparsec's resumable parser: data Result a = Fail !ByteString | Partial (ByteString - Result a) | Done !ByteString a runGet :: Get a - ByteString - Result a Point is you feed it strict bytestring chunks. Then decoding a lazy bytestring can be implemented on top easily, as can decoding a sequence lazily. Like attoparsec you'll probably want to write some other utility functions for working with Results. Attoparsec defines feed, parseWith, maybeResult, and eitherResult. I think you'll want something similar here. I imagine you could fairly easily interface it with iteratee too. Yes that should be easy given the above API. See for example the attoparsec-iteratee package. Once that work is done how will binary differ from cereal? How will I know which one to pick? Thanks, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OpenGL Speed!
On 2010-07-29 11:30 -0600, Luke Palmer wrote: If you are trying to redraw in realtime, eg. 30 FPS or so, I don't think you're going to be able to. There is just not enough GPU bandwidth (and probably not enough CPU). Updating an 800x600 texture at 30fps on a somewhat modern system is absolutely *not* a problem. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] data.binary get reading beyond end of input bytestring?
On Thu, Jul 29, 2010 at 10:35 AM, Jason Dagit da...@codersbase.com wrote: On Thu, Jul 29, 2010 at 6:15 AM, Duncan Coutts duncan.cou...@googlemail.com wrote: No idea what WrappedByteString is. WrappedByteString is a newtype wrapper around ByteString that has a phantom type. This allows instances of to be written such that ByteString can be used with the iteratee library. You can see the source here if you're interested: http://hackage.haskell.org/packages/archive/iteratee/0.3.5/doc/html/src/Data-Iteratee-WrappedByteString.html It would look like attoparsec's resumable parser: data Result a = Fail !ByteString | Partial (ByteString - Result a) | Done !ByteString a runGet :: Get a - ByteString - Result a Point is you feed it strict bytestring chunks. Then decoding a lazy bytestring can be implemented on top easily, as can decoding a sequence lazily. Like attoparsec you'll probably want to write some other utility functions for working with Results. Attoparsec defines feed, parseWith, maybeResult, and eitherResult. I think you'll want something similar here. And I forgot to mention Given those constructors for Result, how will you decode a sequence lazily? I agree you can consume the input lazily but, decodings won't produce any values until you hit Done. This is something I noticed with attoparsec as well. You can feed it incrementally, but it doesn't produce output until it reaches a Done state. In one project, were the input was line based records, I used ByteString's hGetLine to read individual lines and then parse them individually. That gave me a Result for each line and I could build incremental processing of records on top of that. Perhaps I was using attoparsec incorrectly, but as far as I can tell it doesn't have a way to incrementally produce results. I think what needs to be added is a way to 'yield' and 'resume'. What I can't figure out, is how to meaningfully return 'partial results' in general. In cases where the top level combinator is something like manyTill it makes sense, but in other cases it's unclear to me. And I think you'd need to add a constructor above that is some variation of PartiallyDone a ByteString (ByteString - Result a). Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] data.binary get reading beyond end of input bytestring?
On Thu, Jul 29, 2010 at 10:55 AM, Jason Dagit da...@codersbase.com wrote: Given those constructors for Result, how will you decode a sequence lazily? I deliberately left incremental results out of the attoparsec API, because it's a burrito-filled spacesuit of worms. The problem is that parsers can nest and fail and backtrack and be, in general, arbitrarily perverse. For instance, if there was a yield action, I could yield you a 1, backtrack, then yield you a 10 from some completely different branch of the parser that neither I nor you could foresee. Now, lazily parsing a sequence of data is a very common need, and it's also highly constrained, and hence easy to predict. It's also something that's easy to write without any access to the attoparsec internals. It would take just a few moments to write this: parseSequence :: Parser a - Lazy.ByteString - [a] I haven't added this to attoparsec because it's (a) trivial and (b) just one possible approach. Using iteratees would be another; running with a monadic action that can refill the parser on a Partial result would be yet another. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Search for documentation as data fails with Haskell Platform on Windows 7
I contributed the CPSA package to Hackage, and tried using it on a PC running Windows 7. The package installs six executables and documentation as PDF and XHTML into the package's data directory. Haskell Platform with Cabal installs the package without a problem. It was actually quite smooth and simple. So far so good. The trouble came when I tried to locate the documentation. The XHTML document is called cpsauser.html, but the search command on Windows 7 cannot find the document. Is there some way to tell it to try harder? How are users supposed to know how to locate program documentation when using Windows 7? I'm not much of a Windows user, so let me apologize in advance if this is a silly question, and search is, in fact, easy. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [Yi Editor]Cabal Problem
Installing Yi Editor i get the following error: -- --- Missing dependencies on foreign libraries: * Missing C libraries: gobject-2.0, glib-2.0, intl, iconv - Im on windows, using Cabal in Cygwin. How should i install those missing libs? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Announce snm-0.0.2: The Simple Nice-Looking Manual Generator
Johnny Morrice sp...@killersmurf.com writes: [...] snm allows you to write clean, web-friendly reports, user guides and manuals without having to edit fickle html. Interesting project! Unlike some users, I happen to enjoy writing documentation. Perhaps you should also announce this project on the main Haskell mailing list. [...] Read the snm user guide here: http://www.killersmurf.com/static/snm_help.html 2. What snm does not do and is not [...] snm is not an adult activity. Hmm ... the term adult activity could mean many different things ... what one did you mean? Thank you for the many examples in your user guide; they help clarify usage. -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 Furuike ya, kawazu tobikomu mizu no oto. -- Matsuo Basho^ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: weighted-regexp-0.1.0.0
Sebastian Fischer schrieb: On Jul 29, 2010, at 12:47 AM, Benedikt Huber wrote: Taking a quick look at the PyPy blog post on JIT code generation for regular expressions, I thought it would be fun to implement a generator using the excellent LLVM bindings for haskell. Interesting. Would you mind elaborating on your code? Maybe even write a blog about how it works? Hi, so the current implementation (a little bit cleaned up at http://github.com/visq/llvm-regexp ), works as follows: It generates an LLVM function which matches a bytestring against a given regular expression. The state of the 'automaton' consists of one bit for each leaf of the regexp AST, corresponding to the marks in the article's figure. It then generates straight-line code updating the state given an input character (generateRegexpCode and matchCharSet in Text.RegExp.LLVM). For example, for matching '.a' , the generated code looks like this in a simplified pseudo code notation: ... next ~ first character matched ... ch ~ input character next1 = bitmask[0] -- was '.' marked ? bitmask[0] = next -- mark '.' if initial next2 = bitmask[1] -- was 'a' marked ? bitmask[1] = ch == 'a' next1 -- mark 'a' if '.' was marked -- and input is 'a' At the end of the string, code is generated to check whether the automaton is in a final state (genFinalStateCheck). In the example above, this corresponds to final = bitmask[1] The rest is either LLVM boilerplate (regexMatcher) or adaptions from weighed-regexp. Additionally, I've adapted the Parser.y from weighted-regexp, but some things (e.g. character classes like \w) are not implemented. Generating one big basic block for the whole regular expressions does not work well when there are more than a few thousand nodes in the AST. Using functions for large regular expressions and loop for repititions would be one solution. The other problem is that the matcher only operates on Word8s at the moment. Trying it out (if you have llvm+haskell bindings) is also easy (do not cabal-easy): $ git clone g...@github.com:visq/llvm-regexp.git cd llvm-regexp $ make $ ./Grep '.*spotlight.*' /etc/passwd Line 45 matches cheers, benedikt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] new Cabal user question -- installing to Haskell Platform on Windows network drive?
I have a question about finding the Gtk2Hs demos (the demos written in Haskell). To summarize what I have done so far: I'm a new Cabal user; need to use Cabal in a Windows XP environment, where it and the Haskell Platform are located on a network drive (H:) instead of C:. (Need to be able to do development on any of several PCs, using a single tools dir.) I want to write Haskell code that uses Gtk2Hs (and Glade). I have edited Cabal's config and placed it on H:, and so I have set up: H:\proc\tools\Haskell Platform H:\proc\tools\gtk H:\proc\tools\cabal etc. My edited Cabal config is listed at the end below. I modified my PATH, etc. as follows: SET P_TOOLS=H:\proc\tools SET HASK_PLAT=%P_TOOLS%\Haskell Platform\2010.1.0.0 PATH %HASK_PLAT%\bin;%P_TOOLS%\cabal\bin;%P_TOOLS%\gtk\bin;%HASK_PLAT%\lib\extralibs\bin;%HASK_PLAT%\mingw\bin REM This is so Cabal will get its config from the Haskell Platform, REM rather than C:\Documents and Settings\pschmitz\Application Data\cabal SET CABAL_CONFIG=%P_TOOLS%\cabal\config I had to add the mingw\bin dir to PATH to get cpp (needed during cabal install gtk), and the extralibs dir to get alex (for cabal install gtk2hs-buildtools). I download the GTK+ All-in-one bundle 2.20.0 (current maintained branch), and ran gtk-demo; it works. The following commands then completed okay, with various warnings, but no fatal errors: cabal install cabal-install cabal update cabal install gtk2hs-buildtools cabal install gtk (There seems to be no cabal install gtk2hs.) *** At this point I am trying to find the Gtk2Hs demos, so I can compile and run them. I cannot find them anywhere in my H:\proc\tools\ tree. If anyone can help me see what I am missing, I would appreciate it. http://code.haskell.org/gtk2hs/INSTALL says: To get started, you can compile and run one of the programs that reside in the demo/ directory in the respective packages. For example: ~/gtk2hs/gtk/demo/hello:$ make. But I don't see a gtk2hs/ dir anywhere. I tried looking for the sources directly (google gtk2hs demos, etc.) but didn't have any luck. Thanks very much, -- Peter - My Cabal config follows. The email may remove indentation, but I was careful to maintain the original indentation when editing. It seems to work fine. -- This is the configuration file for the 'cabal' command line tool. -- The available configuration options are listed below. -- Some of them have default values listed. -- Lines (like this one) beginning with '--' are comments. -- Be careful with spaces and indentation because they are -- used to indicate layout for nested sections. remote-repo: hackage.haskell.org:http://hackage.haskell.org/packages/archive remote-repo-cache: H:\proc\tools\cabal\packages -- local-repo: -- verbose: 1 -- compiler: ghc -- with-compiler: -- with-hc-pkg: -- scratchdir: -- program-prefix: -- program-suffix: -- library-vanilla: True -- library-profiling: False -- shared: False -- executable-profiling: False -- optimization: True -- library-for-ghci: True -- split-objs: False -- executable-stripping: True -- user-install: True -- package-db: -- flags: -- extra-include-dirs: -- extra-lib-dirs: -- constraint: -- cabal-lib-version: -- preference: -- documentation: False -- doc-index-file: $datadir\doc\index.html -- root-cmd: -- symlink-bindir: build-summary: H:\proc\tools\cabal\logs\build.log -- build-log: remote-build-reporting: anonymous -- username: -- password: install-dirs user prefix: H:\\proc\\tools\\cabal -- bindir: $prefix\bin -- libdir: $prefix -- libsubdir: $pkgid\$compiler -- libexecdir: $prefix\$pkgid datadir: H:\\proc\\tools\\Haskell Platform\\2010.1.0.0 -- datasubdir: $pkgid -- docdir: $prefix\doc\$pkgid -- htmldir: $docdir\html -- haddockdir: $htmldir install-dirs global prefix: H:\\proc\\tools\\Haskell Platform\\2010.1.0.0 -- bindir: $prefix\bin -- libdir: $prefix -- libsubdir: $pkgid\$compiler -- libexecdir: $prefix\$pkgid datadir: H:\\proc\\tools\\Haskell Platform\\2010.1.0.0 -- datasubdir: $pkgid -- docdir: $prefix\doc\$pkgid -- htmldir: $docdir\html -- haddockdir: $htmldir ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] new Cabal user question -- installing to Haskell Platform on Windows network drive?
On 30 July 2010 13:32, Peter Schmitz ps.hask...@gmail.com wrote: I have a question about finding the Gtk2Hs demos (the demos written in Haskell). They're not there: http://osdir.com/ml/haskell-cafe@haskell.org/2010-07/msg00724.html -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
