September 2001 - Haskell-Cafe

Re: streching storage manager
by Marcin 'Qrczak' Kowalczyk 29 Sep '01

29 Sep '01

Sat, 29 Sep 2001 10:24:52 +0800 (GMT-8), Saswat Anand <saswatan(a)comp.nus.edu.sg> pisze: > As regard to Marcin's suggestion of using a list of compact arrays, > although elements can be accessed faster, there will be a lot if > redundancy since windows are overlapping. So consecutive arrays > will contain almost same data. I didn't mean to make them overlapping. Splitting into arrays is arbitrary. This can be made an abstract type. One possibility (perhaps another is needed): data CompactQueue a = CL [Array Int a] -- front [Array Int a] -- rear; becomes front (reversed) after front empty !Int -- block size, set during creation !Int -- offset in the head of front - this many elements -- logically don't exist !Int -- similarly, offset in the head of rear emptyQueue :: Int -> CompactQueue a -- Argument is block size. push :: CompactQueue a -> [a] -> CompactQueue a -- Add elements to the end. -- O(block_size) because it must copy one array. (!!) :: CompactQueue a -> Int -> a -- O(index/block_size). drop :: Int -> CompactQueue a -> CompactQueue a -- This can keep up to block_size elements too many in memory -- (in the head of front). Amortized O(n/block_size). When block_size is 1, it degenerates to a plain list or queue (implemented using one-element arrays). -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

streching storage manager
by Saswat Anand 29 Sep '01

29 Sep '01

Hi, I need some pointers and suggestion in the following problem: I have a very large time-series data. I need to perform some operation on that. At any instant of time, I only need a window-full of data, size of window being known. Starting from the first point, I slide the window towards right and operate on the data that reside in the current window. Currently, I read all of the data to arrays which takes a lot of space and hence GC takes up lot of time. After reading "Streching Storage Manager: Weak pointers, Stable names" paper, I had a feeling that I can do something better for my problem, especially weak pointers seem to be useful. But I do not really get the thread. What I would ideally like to do is: read all the data lazily into some data structure and as I slide the window towards right, I will invalidate the data that fall before the start point of current window. By invalidating, I mean I will somehow tell the GC to reclaim that space if necessary. Is there any way in which I can do this in Haskell, or there is a better(simpler) solution for this. Thanks, Saswat

3 3

Re: streching storage manager
by Marcin 'Qrczak' Kowalczyk 28 Sep '01

28 Sep '01

Fri, 28 Sep 2001 20:28:29 +0900, Dylan Thurston <dpt(a)math.harvard.edu> pisze: > This sounds perfectly suited to Haskell's standard lazy lists. If you > only keep a pointer to the beginning of the data you need to work on, > then Haskell will automatically read in exactly as much data as you > use and GC it away after you are done with it. The downside is that > accessing elements within the window will take time O(window size). Perhaps window contents should be grouped in compact arrays (ghc provides some non-standard array variants more compact than Array). So in overall it's a list of arrays, with elements accessed as with something like l !! (i `div` blockSize) ! (i `mod` blockSize). -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

RE: Haskell <-> C/C++ comunication (sockets/pipes?)
by Simon Marlow 28 Sep '01

28 Sep '01

> Can you tell me what is the problem here? > Haskell app output is redirected to C++ input app (and > vice-versa) using > pipes. (used Erays shell script sugestion) > > When I try > Hsk: 1. get, 2.send > C++: 1. send, 2 get > > It works fine, but if I try it the other way around it locks. > C++ app won't get any input. > Seems to me like Hsk is not 'flushing' the output. You may need to set the buffering mode on the handle to LineBuffering, using IO.hSetBuffering. In GHC at least, the buffering mode is set to line buffering by default if and only if the handle is connected to a terminal. Cheers, Simon

1 0

Re: Haskell <-> C/C++ comunication (sockets/pipes?)
by Marcin 'Qrczak' Kowalczyk 28 Sep '01

28 Sep '01

Thu, 27 Sep 2001 23:06:51 +0100, Jorge Adriano <jadrian(a)mat.uc.pt> pisze: > Seems to me like Hsk is not 'flushing' the output. I guess this is right (sorry, haven't checked). You can flush in two ways (using module IO): 1. At the beginning: hSetBuffering stdout LineBuffering or even hSetBuffering stdout NoBuffering (the latter slows down the I/O). 2. After each write to be flushed: hFlush stdout stdout is either line buffered or block buffered by default, depending on whether it's a terminal or not. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Re: Haskell <-> C/C++ comunication (sockets/pipes?)
by Jorge Adriano 27 Sep '01

27 Sep '01

Can you tell me what is the problem here? Haskell app output is redirected to C++ input app (and vice-versa) using pipes. (used Erays shell script sugestion) When I try Hsk: 1. get, 2.send C++: 1. send, 2 get It works fine, but if I try it the other way around it locks. C++ app won't get any input. Seems to me like Hsk is not 'flushing' the output. If this is the case, I can't really explain why it happens... if the output was not redirected I am pretty sure that, before trying to get input the output would be flushed (imagine something like putStrLn "please type an int:") So what is the issue here? Here is the code, And once again, thanks in advance. J.A. ------------------------------- Haskell app: send -> get ------------------------------- main :: IO() main = do --send hsnum putStrLn "6" -- get cnum and save num <- readLn :: IO(Int) writeFile "./reshs.txt" (show num) ---------------------------- C++ app: get -> send ---------------------------- #include <cstdio> #include <iostream> #include <fstream> nt main(){ // *get* hsnum and save int num; ofstream out("rescc.txt"); cin >> num; out << num; // *send* cnum cout << 10 << '\n' << flush; //it works without the flush return 0; }

1 0

RE: GUI Library Task Force
by Simon Marlow 26 Sep '01

26 Sep '01

> Thats great. I don't disagree. Its just a matter of priority. > So how about this agenda? Careful: we're in danger of not getting *anything* done if we try to prioritise the tasks like this. I think it's far more important to just have one complete GUI system that everyone can use, even if it isn't perfect. I'm absolutely in favour of the current GUI effort. So, when the hierarchical libraries come on-line then we'll have to rename the modules of the GUI library to place them in the hierarchy. That's not a big deal, since we're going to rename all our other library modules too. > Addendum 1: Hierarchical Library Namespace The extension is virtually finalized and all the compilers implement it. However, there's the much bigger task of actually moving over to using the hierarchically organised libraries; this effort is ongoing. We intend to move GHC over for the next version, but leave some compatibility libraries in place. > Addendum 2: Concurrency Hasn't changed much in ages, and largely independent of the others (apart from module name differences with the library hierarchy). Consider GHC's implementation as a draft proposal for a report adendum. I plan to write up a proper proposal at some point (although if someone else were to volunteer, I wouldn't complain :-). > Addendum 3: FFI Almost finalized. Again, independent apart from module names. > Addendum 4: Exceptions Consider GHC's implementation a proposal, but omit the asynchronous exception support. Hugs (in CVS) implements nearly the same interface. > Addendum 4.5?: Proc Syntax for Arrows > Addendum 5: Library Interface Compatibility Guidelines The document we've been drafting for the new library organisation has the beginnings of a set of guidelines, and contributions are of course welcome. The point I'm making is that we can parallelise these tasks to a certain extent, and that doing so is essential in order for us avoid bottlenecks and to converge at all. I agree with many of the points you raise about Haskell needing these features in order to be an "industrial strength" language, but saying things like "we must wait for X so we can do Y properly" has historically not resulted in X appearing in a timely fashion, which in turn leads to no Y at all. Manuel has done a good job of specifying the job of the GUI task force so that it doesn't depend on any of these other tasks, and I think that's the right way to go. Cheers, Simon

2 1

Haskell <-> C/C++ comunication (sockets/pipes?)
by Jorge Adriano 26 Sep '01

26 Sep '01

Hi all, I was thinking about making some GUIs in Qt/KDE for some haskell applications (compiled with ghc). My first idea was to simply run haskell applications with some args using the GUI and get the results from some file or something like that. Anyway someone told me that a better idea would be to use pipes to enable the GUI to comunicate with the application. I checked the ghc libs and there was a pipe function, but I would need named pipes here (right?) since the two processes are not related. I didn't found any function for that in the ghc libs... is there one? I was also told that another (better way) to do this would be to use sockets. I've worked a little bit with posix stuff (fork, pipes, etc) but I never worked with sockets. I was thinking about using named pipes if that's possible, anyway, Id like to know what you think. Is possible. Is sockets a good solution? better? worth the trouble of learning how to use them? Any better ideas? J.A. PS: Good luck to the GUI task force ;)

3 4

RE: Joy and Concatenative Programming
by Frank Atanassow 25 Sep '01

25 Sep '01

[redirected to haskell-cafe] > I just found out about a functional programming language called Joy (see > http://www.latrobe.edu.au/philosophy/phimvt/joy.html) > > Joy differs from Haskell in that it has no variables. Instead, all > functions are postfix, taking a stack as their argument and returning a > stack as a result. Also, IIRC, Joy is untyped. Programming in Joy is like programming with categorical combinators, but ignoring the types. Indeed, a category with one object is just a monoid, and this is supposedly the theory Joy is founded on. But if you really think variables are a nuisance to programming, you can do it in Haskell too, by using list combinators and defining a reverse composition operator. Or just go program in CAML bytecode. It's pretty much the same thing. > Joy advocates contend that the elimination of variables and environments > improves on functional languages in much the same way the elimination of > state improved on imperative languages. I think the situations are qualitatively different. Saying that Joy programs "lack variables" is pretty close to saying that its free variable environments are linearly ordered. Yet a Joy programmer can reorder the arguments on the stack if he rewrites his program to take account of that fact. So, though the ordering is really irrelevant, every Joy program must pick one, and that can be understood as non-declarative, since it has nothing to do with the result of the program. FP languages factor out that arbitrary choice by treating free variable environments as (multi-)sets. (Of course, you lose that advantage when you package up your environment in a closure, because Haskell distinguishes between a -> b -> c and b -> a -> c, even though they are isomorphic.) --- Frank Atanassow, Information & Computing Sciences, Utrecht University Padualaan 14, PO Box 80.089, 3508TB Utrecht, The Netherlands Tel +31 (0)30 253-3261 Fax +31 (0)30 251-3791

1 0

RE: gconsym
by Simon Peyton-Jones 24 Sep '01

24 Sep '01

I don't really understand the "regardless of.." part. But, yes, ":" is a qconop, with precedence and associativity infixr 5. Simon | -----Original Message----- | From: Ian Lynagh [mailto:igloo@earth.li] | Sent: 24 September 2001 13:34 | To: haskell-cafe(a)haskell.org | Subject: gconsym | | | | Just to make sure I am interpreting the report correctly, is | ":" meant to be a valid qconop regardless of the | precedence-level and associativity of the qconop? | | | Thanks | Ian | | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe |

2 1