Re: [Haskell-cafe] Data.Text.IO.hGetContents problem on windows
Re-bonjour Café, Bryan, > I have a program that works fine on linux, but doesn't on windows. > Is there something I'm doing wrong ? Checking the source code for Data.Text.IO.hGetContents, I see that the only time hFileSize is used is in chooseGoodBuffering when the buffering is in block mode, so I have a workaround: I just set the buffering in line mode, which forks for my case. The documentation for hFileSize says "For a handle hdl which attached to a physical file, hFileSize hdl returns the size of that file in 8-bit bytes." So chooseGoodBuffering should check if the handle is a physical file before trying to optimize the buffer size, right ? However, I'm not sure how to check if the handle is a physical file. hIsTerminalDevice wouldn't help here, I guess. hIsSeekable give this on windows : : hIsSeekable: invalid argument (Bad file descriptor) Maybe the solution would be to try hFileSize, and set a default buffering if an exception is caught ? David. > > David. > > The source code of the part that fails is as follows: > > -- Execute a command on a distant server using the rexec protocol. > rexec :: HostName -- server to connect to > -> Text -- user > -> Text -- password > -> TextEncoding -- server's text encoding > -> Text -- command to execute > -> IO (Maybe Text) > rexec !ip !ru !rp !enc cmd = handle rexec_error $ do > hdl <- connectTo ip (PortNumber 512) > let end_param = T.singleton (chr 0) > ctrl_string = T.concat [ > "0", end_param, > ru, end_param, > rp, end_param, > cmd, end_param > ] > hSetEncoding hdl enc > TIO.hPutStr hdl ctrl_string > -- make sure the control string is sent. > hFlush hdl > -- 1st char read is actually a error code which we ignore for now > hGetChar hdl > !res <- TIO.hGetContents hdl > hClose hdl > return (Just res) > > rexec_error :: SomeException -> IO (Maybe Text) > rexec_error err = do > putStrLn $ show err > return Nothing > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Data.Text.IO.hGetContents problem on windows
Bonjour Café, bonjour Bryan I have a program that works fine on linux, but doesn't on windows. On windows XP with the latest Haskell platform, I get: : hFileSize: invalid argument (Bad file descriptor) I think the problem is with hGetContents from Data.Text.IO, but my google-fu failed to help me find any information. Is there something I'm doing wrong ? David. The source code of the part that fails is as follows: -- Execute a command on a distant server using the rexec protocol. rexec :: HostName -- server to connect to -> Text -- user -> Text -- password -> TextEncoding -- server's text encoding -> Text -- command to execute -> IO (Maybe Text) rexec !ip !ru !rp !enc cmd = handle rexec_error $ do hdl <- connectTo ip (PortNumber 512) let end_param = T.singleton (chr 0) ctrl_string = T.concat [ "0", end_param, ru, end_param, rp, end_param, cmd, end_param ] hSetEncoding hdl enc TIO.hPutStr hdl ctrl_string -- make sure the control string is sent. hFlush hdl -- 1st char read is actually a error code which we ignore for now hGetChar hdl !res <- TIO.hGetContents hdl hClose hdl return (Just res) rexec_error :: SomeException -> IO (Maybe Text) rexec_error err = do putStrLn $ show err return Nothing ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] instance Enum Double considered not entirely great?
So I've been excising occurrences of the [n..m] syntax from my code. The reason is that I had been using [0..5] as a shorthand for [0, 1, 2, 3, 4, 5], mostly in tests. This works for integral types and it appears to work for floating point types. Then I tried switching to a fixed point format, and discovered my mistake. Enum is supposed to enumerate every value between the two points, and the result is memory exhaustion. I had already been switching from enumFrom because they accumulate floating point errors, in favor of a couple of more appropriate functions: -- | Enumerate an inclusive range. Uses multiplication instead of successive -- addition to avoid loss of precision. -- -- Also it doesn't require an Enum instance. range :: (Num a, Ord a) => a -> a -> a -> [a] range start end step = go 0 where go i | val > end = [] | otherwise = val : go (i+1) where val = start + (i*step) -- | Like 'range', but includes the end. range_end :: (Num a, Ord a) => a -> a -> a -> [a] range_end start end step = go 0 where go i | val >= end = [end] | otherwise = val : go (i+1) where val = start + (i*step) -- | Infinite range. range_ :: (Num a) => a -> a -> [a] range_ start step = go 0 where go i = start + (i*step) : go (i+1) So I think the Enum instances for Float and Double are sort of a trap. They misled me into thinking the .. syntax is the range function defaulting to a step of 1, led to precision errors I had to debug then fix (and I've noticed lead to the odd stack overflow question), then led to more disaster when I switched to an Enum instance that lived up to Enum's real purpose. The problem is that the [..] syntax is convenient and tempting, especially for tests, wanting a numeric range (rather than enumeration) is very common, and as far as I know the 'range' function isn't in the standard library. So it seems like one of these things that seem convenient in the short term but come around and bite you later. Using the right functions from the start avoids all that. Is there any support for the idea of removing Enum instances for floating point numbers? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Animas/Yampa - Using Zip as a Routing Function in a Parallel Switch with Feedback
> process > :: [Activity] > -> SF [InputEvent] SystemOutput > process activities > = proc inputEvents -> do > rec > let senses = map (\state -> (inputEvents, state)) states > states <- par route activities -< senses > returnA -< states > > route > :: [Sense] > -> [sf] > -> [(Sense, sf)] > -- route a sfs = fmap (\sf -> (head a, sf)) sfs > route = zip For those who are interested, I found a "solution" (more of a hack, really): route a sfs = zip (take num a) sfs where num = length sfs In other words, constraining the size of the input list to that of the signal functions list was the answer. This isn't an ideal solution though since it silently throws away any "extra" input that might be introduced by buggy callers, and I still don't understand the problem with my original code. -- M. George Hansen technopolit...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Animas/Yampa - Using Zip as a Routing Function in a Parallel Switch with Feedback
Greetings, I've been playing around with functional reactive programming using Animas/Yampa and ran into a strange situation. I'm using a parallel switch to route input to a collection of signal functions and using the output as feedback (to simulate state). Everything works as expected until I attempt to use zip as a routing function (i.e. pair each element of input with a signal function). Using zip as a routing function causes the program to enter an infinite loop when it evaluates the output from the parallel switch. Here is a minimal program that fails to terminate when using zip as a routing function: - {-# LANGUAGE Arrows #-} module LoopingTest ( ) where import Control.Arrow import FRP.Animas main = embed (process []) ([42], []) process :: [Activity] -> SF [InputEvent] SystemOutput process activities = proc inputEvents -> do rec let senses = map (\state -> (inputEvents, state)) states states <- par route activities -< senses returnA -< states route :: [Sense] -> [sf] -> [(Sense, sf)] -- route a sfs = fmap (\sf -> (head a, sf)) sfs route = zip type Activity = SF Sense State type InputEvent = Integer type State = [Integer] type Sense = ([InputEvent], State) type SystemInput = ([InputEvent], [State]) type SystemOutput = [State] - If you run the main function as-is the program will run forever, but if you change the route function to use the commented definition instead of zip the program terminates normally. I simply cannot wrap my brain around this issue - zip normally works just fine with infinite lists as long as one of the lists is finite, and in this case the number of Activity signal functions is known at compile time to be finite. I can't find anything conceptually wrong with using zip as a routing function either. If anyone has any thoughts I would be very grateful. -- M. George Hansen technopolit...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Library support for sorting with Text.Data.ICU.Collate.MCollator?
On Mon, Sep 19, 2011 at 04:29:03PM +0300, Michael Snoyman wrote: > On Mon, Sep 19, 2011 at 4:26 PM, Richard Cobbe wrote: > > I'm trying to sort a list of Text values using a collator obtained from the > > Text.Data.ICU.Collate module in the text-icu package on Hackage. > > Unfortunately, I can't use the normal Data.List.sortBy function with one of > > these collators, because the collators return (IO Ordering), not Ordering. > > > > It's easy to write sortWithCollator :: [Text] -> IO [Text], but I'd rather > > not have to. I haven't been able to find library support for this anywhere > > -- am I overlooking it, or do I need to write the sort function myself? > > Hi Richard, > > You want to use freeze[1] to get an immutable collator, and then use > the pure collate[2] function. Ah -- perfect. Can't think how I missed freeze. Thanks! Richard ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Library support for sorting with Text.Data.ICU.Collate.MCollator?
On Mon, Sep 19, 2011 at 4:26 PM, Richard Cobbe wrote: > I'm trying to sort a list of Text values using a collator obtained from the > Text.Data.ICU.Collate module in the text-icu package on Hackage. > Unfortunately, I can't use the normal Data.List.sortBy function with one of > these collators, because the collators return (IO Ordering), not Ordering. > > It's easy to write sortWithCollator :: [Text] -> IO [Text], but I'd rather > not have to. I haven't been able to find library support for this anywhere > -- am I overlooking it, or do I need to write the sort function myself? Hi Richard, You want to use freeze[1] to get an immutable collator, and then use the pure collate[2] function. Michael [1] http://hackage.haskell.org/packages/archive/text-icu/0.6.3.4/doc/html/Data-Text-ICU-Collate.html#v:freeze [2] http://hackage.haskell.org/packages/archive/text-icu/0.6.3.4/doc/html/Data-Text-ICU.html#v:collate ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Library support for sorting with Text.Data.ICU.Collate.MCollator?
I'm trying to sort a list of Text values using a collator obtained from the Text.Data.ICU.Collate module in the text-icu package on Hackage. Unfortunately, I can't use the normal Data.List.sortBy function with one of these collators, because the collators return (IO Ordering), not Ordering. It's easy to write sortWithCollator :: [Text] -> IO [Text], but I'd rather not have to. I haven't been able to find library support for this anywhere -- am I overlooking it, or do I need to write the sort function myself? Thanks, Richard ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] 9th Ghent Functional Programming Group meeting on Tuesday, the 4th of October, 2011
Hello all, We are glad to invite you to our 9th GhentFPG [1] meeting, which takes place on Thursday, the 4th of October, 2011 at 19:30 in the Technicum building of Ghent University. You do not have to be a Functional Programming guru to attend, everyone eager to learn is welcome. As before, the electronic sliding doors will be locked, but a phone number that you can call to get in will be provided at the doors on the far left of the building. The program is as follows: First, we will have a talk by Jurriën Stutterheim, from Utrecht: Snap Framework [2] is a relatively young, but very promising and already quite popular Haskell web framework. Its upcoming 0.6 release has seen a major redesign in the way you write (reusable) components for the framework using so-called snaplets. In this talk, we will look at how you can write snaplets and how you can put them together to create modular web applications. Then, we will have a number of lightning talks in which the following projects are presented: - hCole-server [3], a web interface to a framework for compiler optimizations (Andy Georges); - GA [4], a library to write genetic algorithms in Haskell (Kenneth Hoste); - websockets [5], a Haskell library for writing WebSocket-capable servers (Jasper Van der Jeugt). If you would also like to give a lightning talk (15 mins), please contact us and we will add you to this list. Afterwards, we will have some drinks at a local bar. [1]: http://www.haskell.org/haskellwiki/Ghent_Functional_Programming_Group [2]: http://snapframework.com/ [3]: http://github.com/itkovian/hcole-server [4]: http://github.com/boegel/GA [5]: http://github.com/jaspervdj/websockets Hoping to see you there, The GhentFPG organizing commitee ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The applicative instances for Either?
Daniel Fischer writes: >> Is there any information, or otherwise accessible source specifying >> exactly when this was changed, > Checking the sources, it wasn't in base-4.2.0.2 (ghc-6.12.3), but it was in > base-4.3.1.0 (ghc-7.0.2), so it was introduced with base-4.3 Thanks to you, and everybody else who replied. Now, it turns out, both me (who get this instance from imports) and my user (who doesn't) are using base-4.2.0.2, so it has to be elsewhere. The duplicate instance reports Control.Monad.Trans.Error - hackage insists this is part of "transformers", which I don't use, but maybe mtl imports and reexports the instances? Apparently this is the case, I tried to ghc-pkg hide mtl-2, and then I could load a file declaring an instance for Error e => Applicative (Either e) using mtl-1. So it appears I should require mtl >= 2 (and possibly base >= 4.3 as an alternative, but I guess mtl-2 is not too draconian). (This case was a bit opaque for me, I'm not sure how it could be made easier to trace down conflicts like this, perhaps I just don't know the right tools.) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe