Re: [Haskell-cafe] System.Posix, forked processes and psuedo terminals on Linux
Quoth Erik de Castro Lopo mle...@mega-nerd.com, ... The code below *almost* works. Its currently printing out: parent : Forked child was here! parent : Message from parent. Read 21 bytes while I think it should print: parent : Forked child was here! parent : Read 21 bytes Any clues on why 'Message from parent.' is also ending up on stdout? This is ghc-6.12.1 on Debian Linux. My guess is that the default tty attributes include ECHO. So the data you write to the master fd is echoed back, as though by the fork process but actually by the terminal driver. You can turn ECHO off. Donn Cave, d...@avvanta.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Equality constraints and RankNTypes - how do I assist type inference
Brandon S Allbery KF8NH allbery at ece.cmu.edu writes: type Tensor u v = (u ~ Vect k a, v ~ Vect k b) = Vect k (TensorBasis a b) -- ** IIRC this actually substitutes as (forall k a b. (u ~ Vect k a, v ~ Vect k b) = Vect k (TensorBasis a b)) and the implicit forall will generally mess things up because it won't be floated out to the top level. (Or in other words, constraints in type declarations don't generally do what you intend.) Thanks. Is it possible to elaborate a bit - I still don't really understand what goes wrong. And is there any way to fix it? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] System.Posix, forked processes and psuedo terminals on Linux
Donn Cave wrote: My guess is that the default tty attributes include ECHO. So the data you write to the master fd is echoed back, as though by the fork process but actually by the terminal driver. You can turn ECHO off. Thanks very much Donn, that was an excellent guess. Adding: attr - getTerminalAttributes fd setTerminalAttributes fd (withoutMode attr EnableEcho) Immediately at the top of the runParent process gave me the results I expected. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Code that writes code
Andrew Coppin wrote: Well, yeah, if you've got so much boiler plate that you have to automate generating the boilerplate, you're probably doing it wrong. ;-) All I'm actually using it to do is generate a set of fixed-size containers (each of which has a bazillion class instances). I've got a variable-sized container, but sometimes it's useful to statically guarantee that a container is a specific size. Have a look at how hmatrix-static does this for linear algebra while sitting on top of hmatrix (both are on hackage). Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] ANNOUNCE: enumerator, an alternative iteratee package
On 20/08/10 23:12, John Millikin wrote: On Fri, Aug 20, 2010 at 14:58, Magnus Therning mag...@therning.org wrote: Indeed. In many protocols it would force the attacker to send well-formed requests though. I think this is true for many text-based protocols like HTTP. The looping can be handled effectively through hWaitForInput. There are also other reasons for doing non-blocking IO, not least that it makes developing and manual testing a lot nicer. I think I'm failing to understand something. Using a non-blocking read doesn't change how the iteratees react to well- or mal-formed requests. All it does is change the failure condition from blocked indefinitely to looping indefinitely. It changes the timing. The iteratee will receive the data sooner (when it's available rather than when the buffer is full). This means it can fail *sooner*, in wall-clock time. Replacing the hGet with a combination of hWaitForInput / hGetNonBlocking would cause a third failure condition, looping indefinitely with periodic blocks. This doesn't seem to be an improvement over simply blocking. It is an improvement when data is trickling in. In other cases it's no improvement (besides that it'd be possible have time-outs on a lower level). Do you have any example code which works well using a non-blocking enumerator, but fails with a blocking one? It's not about failing vs non-failing, it's about time of failure. An example would be failing after reading a few bytes (the verb of a HTTP request) vs failing after either reading 4k (which is the buffer size in iteratee, IIRC) or when the client hangs up. /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A cabal odyssey
Ivan Lazar Miljenovic wrote: Andrew Coppin andrewcop...@btinternet.com writes: (Unless you're suggesting that I should try to actually *fix* these things. The way I figure it, if an army of developers who are already experts on the subject haven't been able to fix it yet, it must be extremely hard, and so there's no way *I* can fix it.) Or maybe they have other things to do (e.g. Duncan is working, finishing off his PhD thesis and answering queries like this; when do you expect him to get any hacking done? :p). I wonder... How many people are actually working on Cabal? When I first started using Haskell, I got the impression that there were hundreds, maybe even thousands, of developers working on GHC. (After all, how else could you write such a huge codebase in less than two centuries?) But now it appears the number of active developers is nearer to 3. This is obviously a jaw-droppingly tiny number of people to be working on such a gigantic piece of software. If it's really true, it's amazing anything ever gets done at all! So now I wonder about Darcs, Cabal, Haddock, Hackage, and all those other big projects. Do they really have a bazillion people working on them? Or is it just two blokes in their spare time? (And, more importantly, how do you find out?) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A cabal odyssey
Andrew Coppin andrewcop...@btinternet.com writes: Ivan Lazar Miljenovic wrote: Andrew Coppin andrewcop...@btinternet.com writes: (Unless you're suggesting that I should try to actually *fix* these things. The way I figure it, if an army of developers who are already experts on the subject haven't been able to fix it yet, it must be extremely hard, and so there's no way *I* can fix it.) Or maybe they have other things to do (e.g. Duncan is working, finishing off his PhD thesis and answering queries like this; when do you expect him to get any hacking done? :p). I wonder... How many people are actually working on Cabal? When I first started using Haskell, I got the impression that there were hundreds, maybe even thousands, of developers working on GHC. (After all, how else could you write such a huge codebase in less than two centuries?) But now it appears the number of active developers is nearer to 3. This is obviously a jaw-droppingly tiny number of people to be working on such a gigantic piece of software. If it's really true, it's amazing anything ever gets done at all! So now I wonder about Darcs, Cabal, Haddock, Hackage, and all those other big projects. Do they really have a bazillion people working on them? Or is it just two blokes in their spare time? (And, more importantly, how do you find out?) Seeing as how we don't have a bazillion people using Haskell... ;-) My understanding is that Cabal, Haddock, Hackage (as in the web infrastructure, etc.) and GHC all have a small core team of about 3 developers and a whole bunch of people who have committed patches at one time or another and might even do so on an irregular basis. Darcs seems to have a larger team behind it. -- 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
Re: [Haskell-cafe] Re: Equality constraints and RankNTypes - how do I assist type inference
This works: -- Tensor product of two vector spaces type family Tensor u v :: * type instance Tensor (Vect k a) (Vect k b) = Vect k (TensorBasis a b) On Aug 21, 2010, at 9:15 AM, DavidA wrote: Brandon S Allbery KF8NH allbery at ece.cmu.edu writes: type Tensor u v = (u ~ Vect k a, v ~ Vect k b) = Vect k (TensorBasis a b) -- ** IIRC this actually substitutes as (forall k a b. (u ~ Vect k a, v ~ Vect k b) = Vect k (TensorBasis a b)) and the implicit forall will generally mess things up because it won't be floated out to the top level. (Or in other words, constraints in type declarations don't generally do what you intend.) Thanks. Is it possible to elaborate a bit - I still don't really understand what goes wrong. And is there any way to fix it? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Sjoerd Visscher http://w3future.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] ANNOUNCE: enumerator, an alternative iteratee package
On Sat, Aug 21, 2010 at 5:40 AM, Magnus Therning mag...@therning.org wrote: It changes the timing. The iteratee will receive the data sooner (when it's available rather than when the buffer is full). This means it can fail *sooner*, in wall-clock time. I still fail to see how this works. So I went to see the sources. In [1] we can see how hGet and hGetNonBlocking are defined. The only difference is that the former uses hGetBuf, and the latter uses hGetBufNonBlocking. [1] http://hackage.haskell.org/packages/archive/bytestring/0.9.1.7/doc/html/src/Data-ByteString.html#line-1908 hGetBuf's main loop is bufRead [2], while hGetBufNonBlocking's main loop is bufReadNonBlocking [3]. Both are very similar. The main differences are RawIO.read vs RawIO.readNonBlocking [4], and Buffered.fillReadBuffer vs Buffered.fillReadBuffer0 [5]. Reading RawIO's documentation [4], we see that RawIO.read blocks only if there is no data available. So it doesn't wait for the buffer to be fully filled, it just returns the available data. Unfortunately, BufferedIO's documentation [5] doesn't specify if Buffered.fillReadBuffer should return the available data without blocking. However, it does specify that that it should be blocking if the are no bytes available. [2] http://hackage.haskell.org/packages/archive/base/4.2.0.1/doc/html/src/GHC-IO-Handle-Text.html#line-820 [3] http://hackage.haskell.org/packages/archive/base/4.2.0.1/doc/html/src/GHC-IO-Handle-Text.html#bufReadNonBlocking [4] http://hackage.haskell.org/packages/archive/base/4.2.0.1/doc/html/src/GHC-IO-Device.html#RawIO [5] http://hackage.haskell.org/packages/archive/base/4.2.0.1/doc/html/src/GHC-IO-BufferedIO.html#BufferedIO So, assuming that the semantics of BufferedIO are the same as RawIO's, *both* are non-blocking whenever data is already available. None of them wait until the buffer is full. The difference lies in whether they block if there is no data available. However, when there isn't data the enumarator *always* wants to block. So using non-blocking IO doesn't give anything, only complicates the code. Am I misreading the docs/source somewhere? =) Cheers! -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A cabal odyssey
Ivan Lazar Miljenovic wrote: Andrew Coppin andrewcop...@btinternet.com writes: So now I wonder about Darcs, Cabal, Haddock, Hackage, and all those other big projects. Do they really have a bazillion people working on them? Or is it just two blokes in their spare time? (And, more importantly, how do you find out?) Seeing as how we don't have a bazillion people using Haskell... ;-) I don't know - how many packages are on Hackage now? That's a few GB of source code, right? It didn't write itself. ;-) My understanding is that Cabal, Haddock, Hackage (as in the web infrastructure, etc.) and GHC all have a small core team of about 3 developers and a whole bunch of people who have committed patches at one time or another and might even do so on an irregular basis. Darcs seems to have a larger team behind it. OK, wow. Makes you wonder how anything ever gets done at all, eh? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A cabal odyssey
On Saturday 21 August 2010 14:57:26, Andrew Coppin wrote: Ivan Lazar Miljenovic wrote: Andrew Coppin andrewcop...@btinternet.com writes: So now I wonder about Darcs, Cabal, Haddock, Hackage, and all those other big projects. Do they really have a bazillion people working on them? Or is it just two blokes in their spare time? (And, more importantly, how do you find out?) Seeing as how we don't have a bazillion people using Haskell... ;-) I don't know - how many packages are on Hackage now? That's a few GB of source code, right? It didn't write itself. ;-) How many people have hackage accounts? Much fewer than a bazillion (I think, how much is a bazillion anyway?). Some of them are *very* productive. My understanding is that Cabal, Haddock, Hackage (as in the web infrastructure, etc.) and GHC all have a small core team of about 3 developers and a whole bunch of people who have committed patches at one time or another and might even do so on an irregular basis. Darcs seems to have a larger team behind it. OK, wow. Makes you wonder how anything ever gets done at all, eh? It's a kind of magic. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A cabal odyssey
Daniel Fischer daniel.is.fisc...@web.de writes: On Saturday 21 August 2010 14:57:26, Andrew Coppin wrote: Ivan Lazar Miljenovic wrote: Andrew Coppin andrewcop...@btinternet.com writes: So now I wonder about Darcs, Cabal, Haddock, Hackage, and all those other big projects. Do they really have a bazillion people working on them? Or is it just two blokes in their spare time? (And, more importantly, how do you find out?) Seeing as how we don't have a bazillion people using Haskell... ;-) I don't know - how many packages are on Hackage now? That's a few GB of source code, right? It didn't write itself. ;-) How many people have hackage accounts? Much fewer than a bazillion (I think, how much is a bazillion anyway?). Some of them are *very* productive. A Bazillion is an imaginary number meant to indicate something extremely large: http://en.wikipedia.org/wiki/Bazillion#-illion Since the population of the planet is roughly 6 Billion, I would guess that Andrew is under the miscomprehension that aliens make up the vast majority of Haskell users (or else he is taking into account everyone who will ever use Haskell as well, since after all Haskell will eventually replace all other inferior languages to become the One True Language!). My understanding is that Cabal, Haddock, Hackage (as in the web infrastructure, etc.) and GHC all have a small core team of about 3 developers and a whole bunch of people who have committed patches at one time or another and might even do so on an irregular basis. Darcs seems to have a larger team behind it. OK, wow. Makes you wonder how anything ever gets done at all, eh? It's a kind of magic. I believe Don wrote a successor to lambdabot to generate all of his libraries for him, and Galois is just a front to make it appear that multiple people are working on these libraries when in reality it's just his bot. -- 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
Re: [Haskell-cafe] A cabal odyssey
On Saturday 21 August 2010 15:35:08, Ivan Lazar Miljenovic wrote: A Bazillion is an imaginary number meant to indicate something extremely large: http://en.wikipedia.org/wiki/Bazillion#-illion Yes, but 'extremely large' numbers mean different things, depending on whether we talk about for example midges in Scotland (bazillion = 10^20), people in a football stadium (bazillion = 5*10^4) or people at your sister's wedding (bazillion = 50). So how much is a bazillion when it comes to Haskell programmers? Since the population of the planet is roughly 6 Billion, I would guess that Andrew is under the miscomprehension that aliens make up the vast majority of Haskell users Ordinary people don't use Haskell, so if you're using Haskell, you're ipso facto an alien ;-) (or else he is taking into account everyone who will ever use Haskell as well, since after all Haskell will eventually replace all other inferior languages to become the One True Language!). That'd be Haskell''' rather than Haskell. It's a kind of magic. I believe Don wrote a successor to lambdabot to generate all of his libraries for him, and Galois is just a front to make it appear that multiple people are working on these libraries when in reality it's just his bot. Or that. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A cabal odyssey
Ivan Lazar Miljenovic wrote: Since the population of the planet is roughly 6 Billion, I would guess that Andrew is under the miscomprehension that aliens make up the vast majority of Haskell users. Let's face it, Haskell *does* look like a technology invented by an alien intelligence immesurably superior to our own. No surprise, then, that most of its users are also from another planet. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] ANNOUNCE: enumerator, an alternative iteratee package
I think the docs are wrong, or perhaps we're misunderstanding them. Magnus is correct. Attached is a test program which listens on two ports, 42000 (blocking IO) and 42001 (non-blocking). You can use netcat, telnet, etc, to send it data. The behavior is as Magnus describes: bytes from hGetNonBlocking are available immediately, while hGet waits for a full buffer (or EOF) before returning. This behavior obviously makes hGet unsuitable for enumHandle; my apologies for not understanding the problem sooner. import Control.Concurrent (forkIO, threadDelay) import Control.Monad (forever, unless) import Control.Monad.Fix (fix) import qualified Data.ByteString as B import Network import System.IO main :: IO () main = do blockingSock - listenOn (PortNumber 42000) nonblockingSock - listenOn (PortNumber 42001) forkIO $ acceptLoop B.hGet blockingSock Blocking forkIO $ acceptLoop nonblockingGet nonblockingSock Non-blocking forever $ threadDelay 100 nonblockingGet :: Handle - Int - IO B.ByteString nonblockingGet h n = do hasInput - catch (hWaitForInput h (-1)) (\_ - return False) if hasInput then B.hGetNonBlocking h n else return B.empty acceptLoop :: (Handle - Int - IO B.ByteString) - Socket - String - IO () acceptLoop get sock label = fix $ \loop - do (h, _, _) - accept sock putStrLn $ label ++ client connected bytesLoop (get h) putStrLn $ label ++ EOF loop bytesLoop :: (Int - IO B.ByteString) - IO () bytesLoop get = fix $ \loop - do bytes - get 20 unless (B.null bytes) $ do putStrLn $ bytes = ++ show bytes loop ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Hugs Haskore loading
When trying to load Haskore in Hugs Sept 2006 (say by :l), it does not work because it is in a subdirectory Haskore/Src/, despite that the Hugs searchpath includes /usr/local/lib/hugs/packages/* I could of course change this searchpath, but I'm curios about how to fix it without it - it seems to work for a lot of other packages. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hugs Haskore loading
On Sat, 21 Aug 2010, Hans Aberg wrote: When trying to load Haskore in Hugs Sept 2006 (say by :l), it does not work because it is in a subdirectory Haskore/Src/, despite that the Hugs searchpath includes /usr/local/lib/hugs/packages/* I could of course change this searchpath, but I'm curios about how to fix it without it - it seems to work for a lot of other packages. Did you install Haskore with Cabal or is it a version of Haskore that is shipped with Hugs? The -P option can be used to extend the search path. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hugs Haskore loading
On 21 Aug 2010, at 20:24, Henning Thielemann wrote: When trying to load Haskore in Hugs Sept 2006 (say by :l), it does not work because it is in a subdirectory Haskore/Src/, despite that the Hugs searchpath includes /usr/local/lib/hugs/packages/* I could of course change this searchpath, but I'm curios about how to fix it without it - it seems to work for a lot of other packages. Did you install Haskore with Cabal or is it a version of Haskore that is shipped with Hugs? It is the version that comes with Hugs. It is the same as listed on http://haskell.org/haskore/ . What other version do you have in mind. The -P option can be used to extend the search path. Yes, but as said above, I wondered what was needed to fix the package. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] ANNOUNCE: enumerator, an alternative iteratee package
John Millikin jmilli...@gmail.com writes: I think the docs are wrong, or perhaps we're misunderstanding them. Magnus is correct. Attached is a test program which listens on two ports, 42000 (blocking IO) and 42001 (non-blocking). You can use netcat, telnet, etc, to send it data. The behavior is as Magnus describes: bytes from hGetNonBlocking are available immediately, while hGet waits for a full buffer (or EOF) before returning. hSetBuffering handle NoBuffering? The implementation as it is is fine IMO. G -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hugs Haskore loading
On 21 Aug 2010, at 20:24, Henning Thielemann wrote: When trying to load Haskore in Hugs Sept 2006 (say by :l), it does not work because it is in a subdirectory Haskore/Src/, despite that the Hugs searchpath includes /usr/local/lib/hugs/packages/* I could of course change this searchpath, but I'm curios about how to fix it without it - it seems to work for a lot of other packages. Did you install Haskore with Cabal or is it a version of Haskore that is shipped with Hugs? The -P option can be used to extend the search path. I think the problem is that Haskore is written for an older version of Hugs that just searches all subdirectories without extra requirements, but in the current version, a module Foo in Haskore/Src must be named Src.Foo. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] lazy skip list?
Could you be more specific about what operations you want and their properties (e.g. performance laziness, etc.)? For example, do you need to be able to cons onto the front or is the list generated once and never consed onto? Do you need to be able to insert/remove elements from the middle? Do you need the tail sharing property that regular cons lists have? Michael D. Adams On Thu, Aug 19, 2010 at 9:22 PM, Evan Laforge qdun...@gmail.com wrote: Is there a data type that's spine lazy like a list, but can be seeked (sought?) efficiently? IntMap and Sequence are spine strict so if you take the head element all the elements are forced even if their contents are not. E.g., 'Sequence.index (Sequence.fromList [0..]) 0' will diverge, but obviously 'head [0..]' won't. I can get what I want from a list of lists where the outer list is is 'iterate (drop n)' on the inner one... this is a kind of skip list, right? It seems like it should be possible to generalize this to multiple levels with increasing skip amounts, then I can seek relatively efficiently and won't force the spine beyond where I seek. Effectively, this is nested list like [[[a]]], where each level above the bottom is something like 'iterate (drop n) level_below'. Alternately, it should also be possible to do something fancy like a self-modifying data structure that constructs its index as you force bits of it, but this would require some hairy unsafePerformIO, I think. Has anyone heard of a data structure like this, either the plain list of lists or the self modifying magic one? Surely efficiently indexing a lazy list is something someone else has thought about? It looks like Luke Palmer's data-inttrie might be doing this, though it's not clear from the documentation. It looks like it lacks emptiness, so it doesn't apply to finite structures. lazyarray looks like it might be doing the magic self-modifying thing, though it wants a a static bounds right off the bat, which isn't much help when the whole point is to avoid having to figure out how long the input is. ___ 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] Hugs Haskore loading
On Sat, 21 Aug 2010, Hans Aberg wrote: On 21 Aug 2010, at 20:24, Henning Thielemann wrote: Did you install Haskore with Cabal or is it a version of Haskore that is shipped with Hugs? It is the version that comes with Hugs. It is the same as listed on http://haskell.org/haskore/. What other version do you have in mind. There is Paul Hudak's original version as Cabal package http://hackage.haskell.org/package/haskore-vintage and one that I have messed http://hackage.haskell.org/package/haskore ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] ANNOUNCE: enumerator, an alternative iteratee package
On Sat, Aug 21, 2010 at 10:58 AM, John Millikin jmilli...@gmail.com wrote: I think the docs are wrong, or perhaps we're misunderstanding them. Magnus is correct. Attached is a test program which listens on two ports, 42000 (blocking IO) and 42001 (non-blocking). You can use netcat, telnet, etc, to send it data. The behavior is as Magnus describes: bytes from hGetNonBlocking are available immediately, while hGet waits for a full buffer (or EOF) before returning. This behavior obviously makes hGet unsuitable for enumHandle; my apologies for not understanding the problem sooner. You should note that in ghc=6.12, hWaitForInput tries to decode the next character of input based on to the Handle's encoding. As a result, it will block if the next multibyte sequence is incomplete, and it will throw an error if a multibyte sequence gets split between two chunks. I worked around this problem in Haskeline by temporarily setting stdin to BinaryMode; you may want to do something similar. Also, this issue caused a bug in bytestring with ghc-6.12: http://hackage.haskell.org/trac/ghc/ticket/3808 which will be resolved by the new function 'hGetBufSome' (in ghc-6.14) that blocks only when there's no data to read: http://hackage.haskell.org/trac/ghc/ticket/4046 That function might be useful for your package, though not portable to other implementations or older GHC versions. Best, -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] ANNOUNCE: enumerator, an alternative iteratee package
On Sat, Aug 21, 2010 at 11:35, Gregory Collins g...@gregorycollins.net wrote: John Millikin jmilli...@gmail.com writes: I think the docs are wrong, or perhaps we're misunderstanding them. Magnus is correct. Attached is a test program which listens on two ports, 42000 (blocking IO) and 42001 (non-blocking). You can use netcat, telnet, etc, to send it data. The behavior is as Magnus describes: bytes from hGetNonBlocking are available immediately, while hGet waits for a full buffer (or EOF) before returning. hSetBuffering handle NoBuffering? The implementation as it is is fine IMO. Disabling buffering doesn't change the behavior -- hGet h 20 still doesn't return until the handle has at least 20 bytes of input available. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A cabal odyssey
I wonder... How many people are actually working on Cabal? When I first started using Haskell, I got the impression that there were hundreds, maybe even thousands, of developers working on GHC. (After all, how else could you write such a huge codebase in less than two centuries?) But now it appears the number of active developers is nearer to 3. This is obviously a jaw-droppingly tiny number of people to be working on such a gigantic piece of software. If it's really true, it's amazing anything ever gets done at all! I haven't seen any studies about this, but my impression is that most successful open source projects will be doing well to have 3 full time contributors. There will be a much larger cloud of people who come and go and contribute a few patches, but if you've got 3 people working consistently, after a number of years that really starts to add up. Even in the closed source world... the (internal) application I work on really only has about 3 people who really understand the whole thing and wrote large parts of it. The rest of us hang out on the edges, fixing the odd bug or two. Looking at the ardour commits, it seems like basically two guys doing most of the work. When I looked at the gimp a number of years back, it was a similar story. With say python, it's maybe around 5 or so, but that includes a huge library. When you look at the core, the same names come back again and again. Anyone with experience of any other large successful open source programs care to support or refute? I do agree, though, that what Ian and the Simons (and the Ganeshs and Manuels and assorted MSR interns and...) have built over the years is remarkable and inspiring, not to mention very useful. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] ANNOUNCE: enumerator, an alternative iteratee package
On Sat, Aug 21, 2010 at 11:58, Judah Jacobson judah.jacob...@gmail.com wrote: You should note that in ghc=6.12, hWaitForInput tries to decode the next character of input based on to the Handle's encoding. As a result, it will block if the next multibyte sequence is incomplete, and it will throw an error if a multibyte sequence gets split between two chunks. I worked around this problem in Haskeline by temporarily setting stdin to BinaryMode; you may want to do something similar. Also, this issue caused a bug in bytestring with ghc-6.12: http://hackage.haskell.org/trac/ghc/ticket/3808 which will be resolved by the new function 'hGetBufSome' (in ghc-6.14) that blocks only when there's no data to read: http://hackage.haskell.org/trac/ghc/ticket/4046 That function might be useful for your package, though not portable to other implementations or older GHC versions. You should not be reading bytestrings from text-mode handles. The more I think about it, the more having a single Handle type for both text and binary data causes problems. There should be some separation so users don't accidentally use a text handle with binary functions, and vice-versa: openFile :: FilePath - IOMode - IO TextHandle openBinaryFile :: FIlePath - IOMode - IO BinaryHandle hGetBuf :: BinaryHandle - Ptr a - Int - IO Int Data.ByteString.hGet :: BinaryHandle - IO ByteString -- etc then the enumerators would simply require the correct handle type: Data.Enumerator.IO.enumHandle :: BinaryHandle - Enumerator SomeException ByteString IO b Data.Enumerator.Text.enumHandle :: TextHandle - Enumerator SomeException Text IO b I suppose the enumerators could verify the handle mode and throw an exception if it's incorrect -- at least that way, it will fail consistently rather than only in rare occasions. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hugs Haskore loading
On 21 Aug 2010, at 20:57, Henning Thielemann wrote: Did you install Haskore with Cabal or is it a version of Haskore that is shipped with Hugs? It is the version that comes with Hugs. It is the same as listed on http://haskell.org/haskore/ . What other version do you have in mind. There is Paul Hudak's original version as Cabal package http://hackage.haskell.org/package/haskore-vintage I just put the directory src/ in this package and replaced it with Haskore/ in the Hugs distribution, and then it loaded. and one that I have messed http://hackage.haskell.org/package/haskore What changes have you made? - perhaps the packages should be unified. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] ANNOUNCE: enumerator, an alternative iteratee package
On 21/08/10 18:58, John Millikin wrote: I think the docs are wrong, or perhaps we're misunderstanding them. Magnus is correct. Attached is a test program which listens on two ports, 42000 (blocking IO) and 42001 (non-blocking). You can use netcat, telnet, etc, to send it data. The behavior is as Magnus describes: bytes from hGetNonBlocking are available immediately, while hGet waits for a full buffer (or EOF) before returning. This behavior obviously makes hGet unsuitable for enumHandle; my apologies for not understanding the problem sooner. Thanks, but I suspect that it was my bad description of the issue that made understanding the issue more problematic. Anyway it's good we now understand each other, and even better that we agree :-) As an aside, has anyone written the code necessary to convert a parser, such as e.g. attoparsec, into an enumerator-iteratee[1]? /M [1] Similar to how attoparsec-iteratee does it for iteratee-iteratee. -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hugs Haskore loading
On 21 Aug 2010, at 20:57, Henning Thielemann wrote: Did you install Haskore with Cabal or is it a version of Haskore that is shipped with Hugs? It is the version that comes with Hugs. It is the same as listed on http://haskell.org/haskore/ . What other version do you have in mind. There is Paul Hudak's original version as Cabal package http://hackage.haskell.org/package/haskore-vintage and one that I have messed http://hackage.haskell.org/package/haskore I see now that the original Haskore page http://haskell.org/haskore/ has been replaced without linking by http://www.haskell.org/haskellwiki/Haskore . So just make a forward link there, I think. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hugs Haskore loading
On Sat, 21 Aug 2010, Hans Aberg wrote: On 21 Aug 2010, at 20:57, Henning Thielemann wrote: and one that I have messed http://hackage.haskell.org/package/haskore What changes have you made? - perhaps the packages should be unified. I changed almost everything: Divided modules, designed a hierarchy for module names, generalized many functions and types. In retrospective I should have given it a distinct name. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unix emulation [ANNOUNCE: Sifflet visual programming language, release 1.0!]
Thanks to both Stephen Tetley and Henk-Jan van Tuyl for pointing them out those pages on installing curl and, in general, Unixy software, on Windows. Both looked rather cryptic to me also, although I did not try them out. I will try my hand at building a Windows binary for Sifflet and making it available for folks to download. I have recently acquired a Windows 7 system, partly for this very purpose. It's a guest host under Linux/KVM, and I think it's 32-bit Windows so it'll be a 32-bit binary, although my hardware is x86_64. Will that be okay? I haven't done *anything* with Haskell on Windows yet! So the first step will be installing the Haskell Platform, which I hope will go smoothly, but the rest might take some time, if I succeed at all. Other options seem to be: - Asking for curl and hxt to be included in the Haskell Platform - Asking the author of hxt to split it into parts that do and do not depend on curl. But either of these would also probably take some time, if they are approved at all. So, don't hold your breath, Andrew, but I'll try. * http://haskell.forkio.com/Home/curl-win32 http://www.haskell.org/haskellwiki/Windows#Tools_for_compilation Greg On 2010-Aug-20, Andrew Coppin wrote: Henk-Jan van Tuyl wrote: Curl compiles without problems on my Windows XP system. There is a HaskellWiki page [0] that describes how to compile packages with Unix scripts on Windows systems. I did once try setting up MinGW and MSYS, just to see if I could make it work. But after many, many hours of trying to comprehend the terse documentation, I finally gave up. It's just too hard to get it to work. (I never even got as far as *trying* to build anything; I just couldn't install the tools.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- ___ ___ __ _ / _ \ / _ \| || | Gregory D. Weber, Associate Professor / /_\// / | | | /\ | | Indiana University East / /_\\/ /__| | |/ \| | http://mypage.iu.edu/~gdweber/ \/\_/\___/\__/ Tel. (765) 973-8420; FAX (765) 973-8550 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hugs Haskore loading
On 21 Aug 2010, at 21:51, Henning Thielemann wrote: and one that I have messed http://hackage.haskell.org/package/haskore What changes have you made? - perhaps the packages should be unified. I changed almost everything: Divided modules, designed a hierarchy for module names, generalized many functions and types. In retrospective I should have given it a distinct name. If the basic functionality is the essentially the same, it is probably better to have a single, large package, where people can add their own stuff modularly, though it is good to have a license that admits independent cloning for those that so wish. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Slightly humorous: Headhunters toolbox (example for Germany)
For what it's worth (which judging from later posts may be nothing), the link Sachsen-Anhalt goes to a page with a section Regionales Interesse with a nice blue bar line for Magdeburg, and no mention of Halle. On 2010-Aug-17, Henning Thielemann wrote: Daniel Kahlenberg schrieb: Hi list, stumbled across that: http://www.google.com/insights/search/?hl=de#q=haskellgeo=DEcmpt=q Good to know that Saxony-Anhalt is the state in Germany with leading interest in Haskell. :-) I would like to know, whether this is due to Magdeburg or Halle. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- ___ ___ __ _ / _ \ / _ \| || | Gregory D. Weber, Associate Professor / /_\// / | | | /\ | | Indiana University East / /_\\/ /__| | |/ \| | http://mypage.iu.edu/~gdweber/ \/\_/\___/\__/ Tel. (765) 973-8420; FAX (765) 973-8550 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] ANNOUNCE: enumerator, an alternative iteratee package
On Sat, Aug 21, 2010 at 12:44, Magnus Therning mag...@therning.org wrote: As an aside, has anyone written the code necessary to convert a parser, such as e.g. attoparsec, into an enumerator-iteratee[1]? This sort of conversion is trivial. For an example, I've uploaded the attoparsec-enumerator package at http://hackage.haskell.org/package/attoparsec-enumerator -- iterParser is about 20 lines, excluding the module header and imports. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] lazy skip list?
On Sat, Aug 21, 2010 at 6:52 PM, Michael D. Adams mdmko...@gmail.com wrote: Could you be more specific about what operations you want and their properties (e.g. performance laziness, etc.)? For example, do you need to be able to cons onto the front or is the list generated once and never consed onto? Do you need to be able to insert/remove elements from the middle? Do you need the tail sharing property that regular cons lists have? Good questions. It's just generated in one long iterative process (as a complex but lazy transformation of another long list), and then I want to seek to various points and read sequentially (think about music, seeking to a particular spot and then playing). Sections are then recomputed and spliced in (i.e., if you modify a bit of music in the middle, it recomputes that range of time and splices it in). The laziness is that I don't want to compute too far into the future, and it will be common to recompute the entire tail, but never actually need that tail before it needs to be tossed and recomputed again. Currently, I think I've solved my problem by just using a list of chunks. I already use the chunks as the units of recomputation, and since each one accounts for n seconds, seeking to a particular spot or replacing a chunk out of the middle should be plenty fast with a plain list. If each chunk is 5 sec, 3 hours of music is still only a list of 2160 elements, and '[0..] !! 2160' is basically instant. It looks like I need to get up to around 512 or so before I can even notice the delay, in plain old interpreted ghci. Lists are fast! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] ANNOUNCE: enumerator, an alternative iteratee package
On Sat, Aug 21, 2010 at 3:36 PM, John Millikin jmilli...@gmail.com wrote: This sort of conversion is trivial. For an example, I've uploaded the attoparsec-enumerator package at http://hackage.haskell.org/package/attoparsec-enumerator -- iterParser is about 20 lines, excluding the module header and imports. Cool, but is there a reason it won't work with version 0.2 you just released? build-depends: [...] , enumerator = 0.1 0.2 I noticed that when installing it. Paulo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] ANNOUNCE: enumerator, an alternative iteratee package
On Sat, Aug 21, 2010 at 14:17, Paulo Tanimoto ptanim...@gmail.com wrote: Cool, but is there a reason it won't work with version 0.2 you just released? build-depends: [...] , enumerator = 0.1 0.2 I noticed that when installing it. Hah ... forgot to save the vim buffer. Corrected version uploaded. Sorry about that. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] ANNOUNCE: enumerator, an alternative iteratee package
On Sat, Aug 21, 2010 at 14:41, Michael Snoyman mich...@snoyman.com wrote: Hey John, As I mentioned, I'm considering having persistent depend upon enumerator. Do you think it's too early in enumerator's life to do so and I should wait till the API stabilizes a bit more? Also, two other packages I would think to bring into the enumerator family would be: * yaml * wai-extra, providing an enumerator layer for more easily dealing with the Source and Enumerator datatypes in wai. I might just release a wai-enumerator package instead. Thanks again for your work on this, Michael I think the API is pretty stable. Most of the significant research into iteratee-based APIs has already been performed by users of the iteratee library, and by Oleg. There might be a few backwards-compatible changes (new modules, new exports, etc). I'm not planning to make any large changes, such as Mr. Lato's transition to CPS-based iteratees. As long as you import the enumerator modules with qualified (to avoid Prelude name clashes), it should be safe to start porting libraries. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] ANNOUNCE: enumerator, an alternative iteratee package
John, On Sat, Aug 21, 2010 at 5:06 PM, John Millikin jmilli...@gmail.com wrote: I think the API is pretty stable. Most of the significant research into iteratee-based APIs has already been performed by users of the iteratee library, and by Oleg. There might be a few backwards-compatible changes (new modules, new exports, etc). I'm not planning to make any large changes, such as Mr. Lato's transition to CPS-based iteratees. Apologies if I'm asking you to repeat yourself, but I couldn't find the explanation. What was the reason why you went with IterateeM instead of IterateeMCPS? Simplicity? Thanks, Paulo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] ANNOUNCE: enumerator, an alternative iteratee package
On Sat, Aug 21, 2010 at 15:35, Paulo Tanimoto ptanim...@gmail.com wrote: Apologies if I'm asking you to repeat yourself, but I couldn't find the explanation. What was the reason why you went with IterateeM instead of IterateeMCPS? Simplicity? Iteratees are difficult enough to understand already -- requiring prospective users to learn and understand CPS would just be another roadblock. The CPS implementation is also slower -- I performed some basic benchmarking of IterateeM.hs and IterateeMCPS.hs, and CPS is only faster without optimizations. At -O, they are equal, and at -O2, IterateeM is faster. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Code that writes code
Have you looked at creating Template Haskell splices to generate this for you? On Friday Aug 20, 2010, at 2:21 PM, Andrew Coppin wrote: All I'm actually using it to do is generate a set of fixed-size containers (each of which has a bazillion class instances). I've got a variable-sized container, but sometimes it's useful to statically guarantee that a container is a specific size. In addition, by being fixed-size you can get a few small performance gains. That's really all I'm using autogeneration for. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] feasability of implementing an awk interpreter.
I don't think Template Haskell will be essential for this - you will probably need a parser (probably written with Parsec), an eval function, and a state monad to represent imperative changes made by the language you're evaluating. Template Haskell is more for the elimination of boilerplate code or turning specs into compile-time constraints. On Thursday Aug 19, 2010, at 11:05 PM, Michael Litchard wrote: I'd like the community to give me feedback on the difficulty level of implementing an awk interpreter. What language features would be required? Specifically I'm hoping that TH is not necessary because I'm nowhere near that skill level. An outline of a possible approach would be appreciated. I am using http://www.math.utah.edu/docs/info/gawk_toc.html as a guide to the language description. ___ 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] feasability of implementing an awk interpreter.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/21/2010 11:22 PM, Bill Atkins wrote: I don't think Template Haskell will be essential for this - you will probably need a parser (probably written with Parsec), an eval function, and a state monad to represent imperative changes made by the language you're evaluating. Template Haskell is more for the elimination of boilerplate code or turning specs into compile-time constraints. On Thursday Aug 19, 2010, at 11:05 PM, Michael Litchard wrote: I'd like the community to give me feedback on the difficulty level of implementing an awk interpreter. What language features would be required? Specifically I'm hoping that TH is not necessary because I'm nowhere near that skill level. Something that might not be clear to a beginning Haskell programmer is that laziness subsumes many of the things you would use macros for in another language. In particular, you can trivially create new control structures because the code you control with them only executes when needed. This is why Haskell is popular for EDSLs (embedded domain-specific languages). Template Haskell can usually be ignored until you're programming in the type system or other advanced usages. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxwm14ACgkQIn7hlCsL25X+DwCfdsb+UABmQw1y9489F973EpC1 oKAAn1a2OKqrJpAzpZzUenHaP8gG6zPo =eWBI -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A cabal odyssey
Daniel Fischer wrote: On Saturday 21 August 2010 15:35:08, Ivan Lazar Miljenovic wrote: A Bazillion is an imaginary number meant to indicate something extremely large: http://en.wikipedia.org/wiki/Bazillion#-illion Yes, but 'extremely large' numbers mean different things, depending on whether we talk about for example midges in Scotland (bazillion = 10^20), people in a football stadium (bazillion = 5*10^4) or people at your sister's wedding (bazillion = 50). So how much is a bazillion when it comes to Haskell programmers? Three! -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
