Re: [Haskell-cafe] idea for avoiding temporaries
David Roundy wrote: Actually, I was thinking this sounded a lot like DiffArrays. Except that DiffArrays are slow and expensive in both space and time (compared with strict unboxed arrays). They necesarily hold boxed values so you pay a factor of at least two in space cost (for arrays of Doubles) right off the top, and there's no way you could recover that. What about using a DiffArray with reasonably-sized (cache-friendly?) UArrays as the elements? That way, the cost of boxing can be amortized over more Doubles. Efficiency would depend on updated patterns, of course. -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] idea for avoiding temporaries
On 3/9/07, David Roundy <[EMAIL PROTECTED]> wrote: Nothing is being done concurrently, so I don't see what STM would gain us. What is it that you're thinking we could gain from STM? Its shiny and new, so it will make your code look sexy? :-) So what happened to linear types? I remember reading Once Upon A Type and Linear Types can Change the World during my hons year (and that was more than 10 years ago). Mercury uses linear modes which are much the same. One of the arguments Fergus Henderson made was that in the case of arrays, the update cost if you have to copy is too much, so you use linear types/modes to make it impossible to do so. While you can debate the pros and cons, the fact that a trivial "mistake" in your program could change it from using in-place update to using copying does lend weight to the argument for distinguishing the copying and non-copying forms at the type level. cheers, T. -- Dr Thomas Conway You are beautiful; but learn to work, [EMAIL PROTECTED] for you cannot eat your beauty. -- Congo proverb ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] idea for avoiding temporaries
Nothing is being done concurrently, so I don't see what STM would gain us. What is it that you're thinking we could gain from STM? David On Thu, Mar 08, 2007 at 03:04:43PM -0800, Dan Weston wrote: > Have you looked into using STM (Software Transactional Memory)? This > problem seems like some subset of concurrent programming. > > Dan > > David Roundy wrote: > >Ah, I was missing your point, I've heard something called copy-on-write, > >which wasn't what you describe (or I also misunderstood it when I heard it > >before). > > > >I see. But how would one manage these handles? What's to keep me from > >accidentally copying a handle? It sounds like it'd require explicit memory > >management, in order to avoid ever copying a handle, if I were to implment > >this myself. > > > >Or are you suggesting that if the simons implemented a copy-on-write scheme > >in ghc's RTS, then I'd be all set? > > > >In short, managing the reader count is exactly the problem that sounds > >hard, and I still don't have any idea how one would go about it. > > > >David > > > >On Thu, Mar 08, 2007 at 01:31:19PM -0800, Dan Weston wrote: > >>I might be missing the point, but I think you are missing mine. > >> > >>The copy-on-write I am talking about means that it's no longer "your > >>data", so you don't need any knowledge of who has access to it because > >>you don't own it or have a pointer to it. It is owned by some broker > >>from which you request a read-only or write access handle as needed. > >>Requested changes to underlying data already shared by others triggers a > >>copy and reassignment of pointers to it for your handle alone. > >> > >>The copy cost appears only when there is more than one handle to the > >>same data and one of them changes it. > >> > >>All this can be wrapped up and hidden away. If you want to escape this > >>broker business and steal back your data, just ask: the broker will > >>duplicate shared data needed by others, change their pointers to it, > >>then disown the pointer it returns to you. > >> > >>This is copying without writing (unnecessarily). Or am I missing > >>something? > >> > >>Dan > >> > >>David Roundy wrote: > >>>I'm thinking you're missing the point. The point is to copy without > >>>writing, and that requires some knowledge (whether static or runtime) of > >>>whether anyone else has a reference to my data--which copy-on-write won't > >>>give me. > >>> > >>>David > >>> > >>>On Thu, Mar 08, 2007 at 11:15:25AM -0800, Dan Weston wrote: > Or possibly more generally copy-on-write, which requires one more level > of indirection (handle instead of ptr). Since you are talking about > using ForeignPtr, this is already within your power to prototype, I > should think. > > Dan > > Dan Piponi wrote: > >On 3/8/07, David Roundy <[EMAIL PROTECTED]> wrote: > > > >>I started wondering whether there's a solution that would allow us to > >>write pretty high-level pure functional code, while the RTS can > >>realize > >>at run-time that we have the only reference to the input argument and > >>that it is therefore safe to consume it destructively. > >I think you're talking about uniqueness typing which is supported by > >the programming language Clean. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Summer of Code questions
Wolfgang Jeltsch <[EMAIL PROTECTED]> writes: > First, what organization is Haskell.org? That would be us, right here. Anyone who is interested enough in Haskell to be involved in mailing lists, IRC, distributing library code and tools, whatever. > Is this a real organization, i.e., a legal entity? No. (Unlike e.g. the Apache Foundation.) > Does Haskell.org get the $ 500 for each successful project? > If yes, what does Haskell.org do with this money? Yes, we get the money. Last year, Galois kindly served as the account holder that received the cheque. The mentors involved get to decide what happens to it. I think we are planning to spend last year's on machine/bandwidth for hosting hackage.haskell.org. > Furthermore, the Google Summer of Code FAQ talks about *the* project of a > organization which seems to indicate that each organization has only > one SoC project. The model is that an open-source organisation does indeed usually have one focus, e.g. apache, Linux kernel, GTK, Gnome, Python. But of course there can be smaller tools and focuses within each overarching theme. > What is the project of the Haskell.org organization then? Is this > the general project "The Haskell language plus associated libraries and > tools"? Exactly so. > The FAQ says "Mentor organizations must be organizations or individuals > running an active and viable open source or free software project". Does > this mean that the above-mentioned general project has to be active and > viable (which it is) or that each concrete idea has to be part of an active > and viable project? The former. Decisions about concrete ideas are made collectively by the organisation, and we could certainly decide to go for a relatively immature concrete idea, if it looks both viable and of sufficient value to the community as a whole. > That is, is it allowed to start a new concrete project > by letting a student code for it as part of the SoC or wouldnât this be > possible since a new project isnât yet active and viable? Yes, you can do. It will have to compete with other ideas for top ranking. > Who decides which ideas will be worked on and who decides which student > works on which? Each organisation (in practice, this means a group of people prepared to be mentors) reads and ranks student proposals. After a certain date, Google tell us how many projects they will fund, and the top N are given the money. > What are the obligations of a mentor? (a) To carefully read and vote on quite a lot of student proposals. (b) If chosen to mentor a funded project, to guide the student throughout the project time, primarily by email (and/or IRC). Also to write two reports on progress (mid-term and final), that directly determine whether the student gets paid. > Is it okay to create an idea, become the mentor for this idea > and propose a concrete student for it? Sure. But your idea and student will need to compete for ranking. > What do I have to do to become a mentor? Start by adding yourself to the wiki. > What are Haskell.org's criteria for selecting mentors? According to the > above-mentioned FAQ, Google wants to know these criteria as specifically as > possible. I'm not sure we have definite criteria. I guess that the community generally recognises your name as a contributor to the Haskell language, libraries, tools, or whatever. Regular and visible engagement with the community would count for a lot. > Finally, should the ideas be chosen so that they are solvable by a student > working full time on them during the three months of the SoC? Exactly so. This year, Google have set things up with a greater time period between notification of acceptance, and the official beginning of coding, so that students have more preparation time before full-time work starts. > The problem is that at many German universities lectures go until > July. At our university, for example, lecture time ends in mid of July > and is followed by two weeks for exams. So a faithful student would > only have the last month for working full time on the SoC. Google have indeed set up the timetable largely with US universities in mind. So yes, it is certainly a disadvantage to a German student that they cannot work full-time for the three months. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] idea for avoiding temporaries
Have you looked into using STM (Software Transactional Memory)? This problem seems like some subset of concurrent programming. Dan David Roundy wrote: Ah, I was missing your point, I've heard something called copy-on-write, which wasn't what you describe (or I also misunderstood it when I heard it before). I see. But how would one manage these handles? What's to keep me from accidentally copying a handle? It sounds like it'd require explicit memory management, in order to avoid ever copying a handle, if I were to implment this myself. Or are you suggesting that if the simons implemented a copy-on-write scheme in ghc's RTS, then I'd be all set? In short, managing the reader count is exactly the problem that sounds hard, and I still don't have any idea how one would go about it. David On Thu, Mar 08, 2007 at 01:31:19PM -0800, Dan Weston wrote: I might be missing the point, but I think you are missing mine. The copy-on-write I am talking about means that it's no longer "your data", so you don't need any knowledge of who has access to it because you don't own it or have a pointer to it. It is owned by some broker from which you request a read-only or write access handle as needed. Requested changes to underlying data already shared by others triggers a copy and reassignment of pointers to it for your handle alone. The copy cost appears only when there is more than one handle to the same data and one of them changes it. All this can be wrapped up and hidden away. If you want to escape this broker business and steal back your data, just ask: the broker will duplicate shared data needed by others, change their pointers to it, then disown the pointer it returns to you. This is copying without writing (unnecessarily). Or am I missing something? Dan David Roundy wrote: I'm thinking you're missing the point. The point is to copy without writing, and that requires some knowledge (whether static or runtime) of whether anyone else has a reference to my data--which copy-on-write won't give me. David On Thu, Mar 08, 2007 at 11:15:25AM -0800, Dan Weston wrote: Or possibly more generally copy-on-write, which requires one more level of indirection (handle instead of ptr). Since you are talking about using ForeignPtr, this is already within your power to prototype, I should think. Dan Dan Piponi wrote: On 3/8/07, David Roundy <[EMAIL PROTECTED]> wrote: I started wondering whether there's a solution that would allow us to write pretty high-level pure functional code, while the RTS can realize at run-time that we have the only reference to the input argument and that it is therefore safe to consume it destructively. I think you're talking about uniqueness typing which is supported by the programming language Clean. ___ 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] idea for avoiding temporaries
On Mar 8, 2007, at 17:09 , Matthias Neubauer wrote: David Roundy <[EMAIL PROTECTED]> writes: I see. But how would one manage these handles? What's to keep me from accidentally copying a handle? It sounds like it'd require explicit memory management, in order to avoid ever copying a handle, if I were to implment this myself. Because you seem to write imperative code anyways: can't you simply use a specialized state monad with the array(s) hidden inside the monad as monad state? Err, wasn't the point was that he wanted a pure way to get out of writing that imperative code? -- brandon s. allbery[linux,solaris,freebsd,perl] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] idea for avoiding temporaries
David Roundy <[EMAIL PROTECTED]> writes: > No, the point is to avoid writing imperative code. My examples used > imperative code, but that would be wrapped at the lowest level of the array > library, and all the real code would be pure. Still sounds like a state monad to me. Your 'array library', I mean. -Matthias -- Matthias Neubauer | Universität Freiburg, Institut für Informatik | tel +49 761 203 8060 Georges-Köhler-Allee 79, 79110 Freiburg i. Br., Germany | fax +49 761 203 8052 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] idea for avoiding temporaries
On Thu, Mar 08, 2007 at 11:09:35PM +0100, Matthias Neubauer wrote: > David Roundy <[EMAIL PROTECTED]> writes: > > I see. But how would one manage these handles? What's to keep me from > > accidentally copying a handle? It sounds like it'd require explicit memory > > management, in order to avoid ever copying a handle, if I were to implment > > this myself. > > Because you seem to write imperative code anyways: can't you simply > use a specialized state monad with the array(s) hidden inside the > monad as monad state? No, the point is to avoid writing imperative code. My examples used imperative code, but that would be wrapped at the lowest level of the array library, and all the real code would be pure. -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] idea for avoiding temporaries
David Roundy <[EMAIL PROTECTED]> writes: > I see. But how would one manage these handles? What's to keep me from > accidentally copying a handle? It sounds like it'd require explicit memory > management, in order to avoid ever copying a handle, if I were to implment > this myself. Because you seem to write imperative code anyways: can't you simply use a specialized state monad with the array(s) hidden inside the monad as monad state? -Matthias -- Matthias Neubauer | Universität Freiburg, Institut für Informatik | tel +49 761 203 8060 Georges-Köhler-Allee 79, 79110 Freiburg i. Br., Germany | fax +49 761 203 8052 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] idea for avoiding temporaries
On Thu, Mar 08, 2007 at 04:32:01PM -0500, Brandon S. Allbery KF8NH wrote: > On Mar 8, 2007, at 16:27 , David Roundy wrote: > >The real issue for me is that DiffArrays only make any sense at all if > >you often update a subset of your array, which I never expect to do... > >so even if they were efficiently implemented to the point of zero > >overhead, they would gain me nothing, and that's almost certainly overly > >optimistic. > > But that's not my understanding of what's *supposed* to be > happening: the point of DiffArrays is is not optimizing partial > updates, it's optimizing the head at the expense of any (by intent > few or none) references that might be held elsewhere. As such, if > there are no such references the DiffArray *should* get you cheap in- > place (destructive) updates. Ah, I see. Yes, I misunderstood. When I read about DiffArrays (ages ago), I thought they stored the old array plus differences, a mistake which makes sense given that I wasn't yet comfortable with safe encapsulation of unsafePerformIO. You're right, but the cheap destructive updates still presumably involve creating and garbage-collecting O(N) thunks, which isn't particularly cheap, in my opinion. Or if the update function holds a reference to the original array, then you'll have to store two copies of the array in a non-dense format, and we won't have gained anything, as far as the temporary goes. -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] idea for avoiding temporaries
Ah, I was missing your point, I've heard something called copy-on-write, which wasn't what you describe (or I also misunderstood it when I heard it before). I see. But how would one manage these handles? What's to keep me from accidentally copying a handle? It sounds like it'd require explicit memory management, in order to avoid ever copying a handle, if I were to implment this myself. Or are you suggesting that if the simons implemented a copy-on-write scheme in ghc's RTS, then I'd be all set? In short, managing the reader count is exactly the problem that sounds hard, and I still don't have any idea how one would go about it. David On Thu, Mar 08, 2007 at 01:31:19PM -0800, Dan Weston wrote: > I might be missing the point, but I think you are missing mine. > > The copy-on-write I am talking about means that it's no longer "your > data", so you don't need any knowledge of who has access to it because > you don't own it or have a pointer to it. It is owned by some broker > from which you request a read-only or write access handle as needed. > Requested changes to underlying data already shared by others triggers a > copy and reassignment of pointers to it for your handle alone. > > The copy cost appears only when there is more than one handle to the > same data and one of them changes it. > > All this can be wrapped up and hidden away. If you want to escape this > broker business and steal back your data, just ask: the broker will > duplicate shared data needed by others, change their pointers to it, > then disown the pointer it returns to you. > > This is copying without writing (unnecessarily). Or am I missing something? > > Dan > > David Roundy wrote: > >I'm thinking you're missing the point. The point is to copy without > >writing, and that requires some knowledge (whether static or runtime) of > >whether anyone else has a reference to my data--which copy-on-write won't > >give me. > > > >David > > > >On Thu, Mar 08, 2007 at 11:15:25AM -0800, Dan Weston wrote: > >>Or possibly more generally copy-on-write, which requires one more level > >>of indirection (handle instead of ptr). Since you are talking about > >>using ForeignPtr, this is already within your power to prototype, I > >>should think. > >> > >>Dan > >> > >>Dan Piponi wrote: > >>>On 3/8/07, David Roundy <[EMAIL PROTECTED]> wrote: > >>> > I started wondering whether there's a solution that would allow us to > write pretty high-level pure functional code, while the RTS can realize > at run-time that we have the only reference to the input argument and > that it is therefore safe to consume it destructively. > >>>I think you're talking about uniqueness typing which is supported by > >>>the programming language Clean. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] open a browser from the command line, wait a few seconds, and shut it. (ie, translate forking from bash to haskell)
tphyahoo: > I have a bash script that opens a browser for a few seconds, and then > closes it. > > Could someone point me up the equivelant(s) in haskell, h4sh, hsh, > etc,0 and friends? > > I reckon this amounts to, what's the process for translating forking > from bash to haskell. > > > > #!/bin/bash > konqueror http://www.google.com & > pid=$! # give the page some time to load > sleep 5 > kill $pid > > Something like: import System.Posix main = do p <- run "xclock" [] sleep 5 signalProcess sigTERM p r <- getProcessStatus True False p print r run x args = forkProcess $ executeFile x True args Nothing ? -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] TVars & throw
On 3/8/07, Chris Kuklewicz <[EMAIL PROTECTED]> wrote: What happens in your throw/catch case if I have stm1 = do some_stm_code_that_throws_your_exception stm2 = return Foo and I run "atomically (stm1 `orElse` stm2)" ? Answer: The exception will prevent running stm2. In the *specific* case of the external dictionary code, there is no orElse case to worry about since the algorithms are deterministic in this sense. For a more general case, it is an interesting problem to consider. You might want something like throwIfNothingElseSeemsLikeAGoodIdea, so that you can attempt any alternatives, and if none succeed then throw (and I guess choose the first if more than one alternative wants to throw - I like determinism). > Um, is >unsafeIOToSTM $ atomically trans > going to run you into problems? YES! My point is that onRetry really wants to be not "IO t" but "IO_execpt_STM t", but there's no way of ensuring that, which unfortunately antagonizes modularity in the same kind of way that locks do. It requires you to know how the implementation of the IO actions you use work, in case they use STM inside. Since the actions may come out of a library somewhere, you need to know how the library is implemented. Why are tricky problems tricky? I thought Haskell was supposed to make everything easy. ;-) T. -- Dr Thomas Conway You are beautiful; but learn to work, [EMAIL PROTECTED] for you cannot eat your beauty. -- Congo proverb ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] idea for avoiding temporaries
On Mar 8, 2007, at 16:27 , David Roundy wrote: The real issue for me is that DiffArrays only make any sense at all if you often update a subset of your array, which I never expect to do... so even if they were efficiently implemented to the point of zero overhead, they would gain me nothing, and that's almost certainly overly optimistic. But that's not my understanding of what's *supposed* to be happening: the point of DiffArrays is is not optimizing partial updates, it's optimizing the head at the expense of any (by intent few or none) references that might be held elsewhere. As such, if there are no such references the DiffArray *should* get you cheap in- place (destructive) updates. It's possible that the current *implementation* is flawed in the way you describe; if so, that should probably be brought up on the libraries list, because the documentation and the intent seem to be saying otherwise. -- brandon s. allbery[linux,solaris,freebsd,perl] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] idea for avoiding temporaries
I might be missing the point, but I think you are missing mine. The copy-on-write I am talking about means that it's no longer "your data", so you don't need any knowledge of who has access to it because you don't own it or have a pointer to it. It is owned by some broker from which you request a read-only or write access handle as needed. Requested changes to underlying data already shared by others triggers a copy and reassignment of pointers to it for your handle alone. The copy cost appears only when there is more than one handle to the same data and one of them changes it. All this can be wrapped up and hidden away. If you want to escape this broker business and steal back your data, just ask: the broker will duplicate shared data needed by others, change their pointers to it, then disown the pointer it returns to you. This is copying without writing (unnecessarily). Or am I missing something? Dan David Roundy wrote: I'm thinking you're missing the point. The point is to copy without writing, and that requires some knowledge (whether static or runtime) of whether anyone else has a reference to my data--which copy-on-write won't give me. David On Thu, Mar 08, 2007 at 11:15:25AM -0800, Dan Weston wrote: Or possibly more generally copy-on-write, which requires one more level of indirection (handle instead of ptr). Since you are talking about using ForeignPtr, this is already within your power to prototype, I should think. Dan Dan Piponi wrote: On 3/8/07, David Roundy <[EMAIL PROTECTED]> wrote: I started wondering whether there's a solution that would allow us to write pretty high-level pure functional code, while the RTS can realize at run-time that we have the only reference to the input argument and that it is therefore safe to consume it destructively. I think you're talking about uniqueness typing which is supported by the programming language Clean. ___ 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] Re: [Haskell-cafe] Google summer of code
On Mar 8, 2007, at 10:40 , Simon Marlow wrote: David House wrote: On 06/03/07, Malcolm Wallace <[EMAIL PROTECTED]> wrote: Well, our wiki to gather ideas is now up-and-running again: http://hackage.haskell.org/trac/summer-of-code We should probably remove projects that were succeessfully completed last year, along with the lists of interested students on every project. I did some general tidying up in the Trac yesterday, including closing some of the projects that were done last year. I'd urge others to go and take a look too; I didn't do a complete sweep. I think that it would be good if we this year would make a short(ish) list of the projects that we think are the most important, and let the students focus on applying for those. My impression from last year is that there were lots of project proposals, most of which could not be considered important enough to be one of the projects we pick, no matter how good the students were who wanted to do them. /Björn___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] idea for avoiding temporaries
On Thu, Mar 08, 2007 at 08:45:06PM -, Claus Reinke wrote: > >Except that DiffArrays are slow and expensive in both space and time > >(compared with strict unboxed arrays). They necesarily hold boxed values > >so you pay a factor of at least two in space cost (for arrays of Doubles) > >right off the top, and there's no way you could recover that. I'll admit > >that they could be useful for something, but I couldn't guess what. In my > >experience, arrays are always used with strict values, and updates change > >all the values in an array. > > i never quite understood why DiffArrays are so slow at the moment, so > perhaps this is a good opportunity to ask for enlightenment on this issue?-) > > and i don't understand why they should necessarily hold boxed values only: > the idea was to hold an efficient full version at the front, and slower > differences at the back. what would stop the main version from being > unboxed? I guess if you do it in this way you'd still have worse memory use than with ordinary arrays, since you'd hang onto the old unboxed version indefinitely, and also store a bunch of boxed new versions. The real issue for me is that DiffArrays only make any sense at all if you often update a subset of your array, which I never expect to do... so even if they were efficiently implemented to the point of zero overhead, they would gain me nothing, and that's almost certainly overly optimistic. And to be honest, I'm doubtful that there are many applications in which you want to update only a very small subset of an array, so I'm not really sure what DiffArrays are intended to be used for. Once you've updated all (or most of) the elements, DiffArrays are as slow as their back end, and you may as well just use their back end without the DiffArray business. -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Distributing a GHC-compiled binary for Macs (x86)
Hi, I compiled a binary using GHC 6.6 on my Mac (specifically, using ghc --make). This binary seems to depend on the GNU MP framework--I imagine GHC uses it to implement its numeric tower. However, Macs that don't have GHC installed don't seem to have GMP, so I'll guess that it was installed along with the GHC binary. Is there any way to get around this GMP dependency? I expect the binary to be used on Macs that don't have GHC installed. It would be acceptable if I instructed Mac-users to download a binary installer for GMP, but I haven't been able to find one. Any hints or suggestions would be appreciated. Thanks. Arjun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] idea for avoiding temporaries
Except that DiffArrays are slow and expensive in both space and time (compared with strict unboxed arrays). They necesarily hold boxed values so you pay a factor of at least two in space cost (for arrays of Doubles) right off the top, and there's no way you could recover that. I'll admit that they could be useful for something, but I couldn't guess what. In my experience, arrays are always used with strict values, and updates change all the values in an array. i never quite understood why DiffArrays are so slow at the moment, so perhaps this is a good opportunity to ask for enlightenment on this issue?-) and i don't understand why they should necessarily hold boxed values only: the idea was to hold an efficient full version at the front, and slower differences at the back. what would stop the main version from being unboxed? when i looked into this a while ago, it seemed that the implementation had a lot of overhead, mostly due to avoiding concurrency issues? perhaps the main version could be associated with a specific concurrent haskell thread, so that only other threads would have to pay the management fee, while the common pattern of single-threaded (pardon the pun;) access would be spared that overhead? to make sure that secondary references cannot access the main copy while it is being updated in place, perhaps each thread might need its own main copy (again, that extra price would not be payable in single-threaded practice)? or is that impossible? claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A different Maybe maybe
Hi, Am Mittwoch, den 07.03.2007, 23:32 +0100 schrieb Joachim Breitner: > [Also on > http://www.joachim-breitner.de/blog/archives/229-A-different-Maybe-maybe.html] [Skipping Church encoding] Thanks for all the answers and links. I was expecting to have discovered something that already exists, so I didn’t take it as criticism. Greetings, Joachim -- Joachim Breitner e-Mail: [EMAIL PROTECTED] Homepage: http://www.joachim-breitner.de ICQ#: 74513189 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] idea for avoiding temporaries
my line of work). This got me thinking about one of the largest problems with writing serious numerical code in Haskell, which is that of memory consumption and avoiding temporary variables. ... pretty high-level pure functional code, while the RTS can realize at run-time that we have the only reference to the input argument and that it is therefore safe to consume it destructively. My thought is to move some of the amazing rewriting streams stuff that's going on with Data.ByteStream and Manuel's array fusion work onto the memory management level. If we can rewrite high-level array manipulations into a form in which the compiler can fuse the loops and write good low-level code, why not also allow automatic in-place updates (when possible)? fusing loops over arrays already avoids temporaries, doesn't it? one thing that struck me when reading the rewriting strings paper was that it reduces structure fusion to loop-over-structure fusion which would finally provide a framework for borrowing all that nice work on with-loop-folding in SAC for Haskell arrays (all of those high-level array operations in SAC seem to be reducable to with-loops). Single Assignment C -- Efficient Support for High-level Array Operations in a Functional Setting. Sven-Bodo Scholz. In Journal of Functional Programming 13(6), pp.1005-1059, ©Cambridge University Press, 2003. http://www.sac-home.org/publications/sac-overview-jfp-03.pdf [section 4.2 in the papger is on with-loop folding] SAC home page, about SAC http://www.sac-home.org/index.php?p=.%2F11_About%2F11_About_SAC anyone for porting the array sublanguage (shape- and dimension-invariant operations on multi-dimensional arrays) of SAC to Haskell? how much of that is covered in the ongoing Haskell array work? The key is that copy will ask the GC to check whether there is more than one reference to its input, and if there isn't, then it'll return its input without making a copy. Obviously, we'd want to be careful in making calls to copy (since the GC overhead could overwhelm the potential (transient) memory savings. SAC uses reference counting for that. as for using forced GC to get similar effects, i'm not optimistic, as that would seem to invalidate the advantages of GC-based memory management. btw, the nice thing about making a copy is that you know you now have the only reference to that copy. so you could make a copy, then update in place to your heart's content, until you pass on your reference to others. claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] idea for avoiding temporaries
it seems we can almost do this now without adding any new API calls,
just have 'thawArray' and 'freezeArray' perform the check, and behave
like 'unsafeThawArray' or 'unsafeFreezeArray' when they are the only
reference.
The compiler may even be able to statically replace some
calls to thawArray or freezeArray with the unsafe versions with an
extension of the rules syntax
{-# RULES forall a | unique a . freezeArray a = unsafeFreezeArray a #-}
this syntax actually came up in a previous discussion about wanting to
fire rules only when the argument is a constant literal (though, you don't
care about the particular constant value it is)
I imagine infering the uniqueness of values shouldn't be that hard as a
form of it is already done for avoiding thunk-updates.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] idea for avoiding temporaries
On Thu, Mar 08, 2007 at 02:50:51PM -0500, Brandon S. Allbery KF8NH wrote: > On Mar 8, 2007, at 14:21 , David Roundy wrote: > >I'm thinking you're missing the point. The point is to copy without > >writing, and that requires some knowledge (whether static or > >runtime) of > >whether anyone else has a reference to my data--which copy-on-write > >won't > >give me. > > Actually, I was thinking this sounded a lot like DiffArrays. You > don't actually get a guarantee that anything else isn't holding a > reference, but you do get destructive update with any old references > being quietly changed to diffs against the head. Except that DiffArrays are slow and expensive in both space and time (compared with strict unboxed arrays). They necesarily hold boxed values so you pay a factor of at least two in space cost (for arrays of Doubles) right off the top, and there's no way you could recover that. I'll admit that they could be useful for something, but I couldn't guess what. In my experience, arrays are always used with strict values, and updates change all the values in an array. -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] idea for avoiding temporaries
On Mar 8, 2007, at 14:21 , David Roundy wrote: I'm thinking you're missing the point. The point is to copy without writing, and that requires some knowledge (whether static or runtime) of whether anyone else has a reference to my data--which copy-on-write won't give me. Actually, I was thinking this sounded a lot like DiffArrays. You don't actually get a guarantee that anything else isn't holding a reference, but you do get destructive update with any old references being quietly changed to diffs against the head. -- brandon s. allbery[linux,solaris,freebsd,perl] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] idea for avoiding temporaries
I'm thinking you're missing the point. The point is to copy without writing, and that requires some knowledge (whether static or runtime) of whether anyone else has a reference to my data--which copy-on-write won't give me. David On Thu, Mar 08, 2007 at 11:15:25AM -0800, Dan Weston wrote: > Or possibly more generally copy-on-write, which requires one more level > of indirection (handle instead of ptr). Since you are talking about > using ForeignPtr, this is already within your power to prototype, I > should think. > > Dan > > Dan Piponi wrote: > >On 3/8/07, David Roundy <[EMAIL PROTECTED]> wrote: > > > >>I started wondering whether there's a solution that would allow us to > >>write pretty high-level pure functional code, while the RTS can realize > >>at run-time that we have the only reference to the input argument and > >>that it is therefore safe to consume it destructively. > > > >I think you're talking about uniqueness typing which is supported by > >the programming language Clean. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] idea for avoiding temporaries
Or possibly more generally copy-on-write, which requires one more level of indirection (handle instead of ptr). Since you are talking about using ForeignPtr, this is already within your power to prototype, I should think. Dan Dan Piponi wrote: On 3/8/07, David Roundy <[EMAIL PROTECTED]> wrote: I started wondering whether there's a solution that would allow us to write pretty high-level pure functional code, while the RTS can realize at run-time that we have the only reference to the input argument and that it is therefore safe to consume it destructively. I think you're talking about uniqueness typing which is supported by the programming language Clean. -- Dan ___ 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] A different Maybe maybe
I was not implying that the others' responses actually were critical. I was implying that many (especially people newer to Haskell or lacking postgraduate degrees in mathematics or computer science) would interpret them as such, and if not quickly clarified, might discourage non-gurus from contributing new ideas in the off-chance that they are not new and will be shot down. :( Knowledge can only be gained, but the freshness of ideas can only be lost. Thus do libertines and virgins each have something to offer the other. I personally feel that a well-placed emoticon (such as the ;-) you have so effectively used) goes a long way in a medium without face-to-face contact. Dan Dougal Stanton wrote: On 08/03/07, Dan Weston <[EMAIL PROTECTED]> wrote: Do not let the multiple responses of how you apparently wasted your time reinventing (or do they mean stealing?) something Church did long ago dampen your enthusiasm to learn exciting things and then share them. I agree with your sentiment that discovering things is fun, no matter how many times it has been done before. But I don't think the other respondents were critical. I read them as properly congratulatory, not sarcastic. It's not everyone that gets to claim they had the same idea as Alonzo Church! ;-) Maybe we need a You Could Have Invented Church Encoding (And Maybe You Already Have) [1] blog post somewhere... D. [1]: http://sigfpe.blogspot.com/2006/08/you-could-have-invented-monads-and.html ___ 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
[Haskell-cafe] Re: EnumSet and EnumMap
On Fri, Feb 23, 2007 at 03:24:27PM +, Chris Kuklewicz wrote: > I could not quickly find anyone else writing this boiler plate, so I have > posted > this useful wrapper on the Haskell wiki at > http://haskell.org/haskellwiki/EnumSet_EnumMap concurrent evolution :) http://repetae.net/repos/jhc/Util/SetLike.hs actually, my 'SetLike' and 'MapLike' typeclasses also defined in that file are quite useful too. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] open a browser from the command line, wait a few seconds, and shut it. (ie, translate forking from bash to haskell)
I have a bash script that opens a browser for a few seconds, and then closes it. Could someone point me up the equivelant(s) in haskell, h4sh, hsh, etc,0 and friends? I reckon this amounts to, what's the process for translating forking from bash to haskell. #!/bin/bash konqueror http://www.google.com & pid=$! # give the page some time to load sleep 5 kill $pid By the way, this isn't an academic question -- I'm using this simple script to verify various html downloads by checking the konqueror html cache for text strings I'm interested in, for pages that can't be easily downloaded with wget/web mechanize because of javascript and redirect nastiness. Also, for those interested in shell-equivelance strategies, I posted essentially the same question to perlmonks at http://perlmonks.org/?node_id=603868 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] idea for avoiding temporaries
On 3/8/07, David Roundy <[EMAIL PROTECTED]> wrote: I started wondering whether there's a solution that would allow us to write pretty high-level pure functional code, while the RTS can realize at run-time that we have the only reference to the input argument and that it is therefore safe to consume it destructively. I think you're talking about uniqueness typing which is supported by the programming language Clean. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Usage of . and $
On 08/03/07, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
NB that infix type constructors must start with ":", just like infix data
constructors.
Now that's just not true.
{-# OPTIONS_GHC -fglasgow-exts #-}
type a $ b = a b
data Foo a = Foo a deriving (Show)
data Bar = Bar (Foo $ Int) deriving (Show)
main = print (Bar (Foo 4))
GHCi session:
Prelude> :load "/home/david/hs/sandbox/infix-tycons.hs"
[1 of 1] Compiling Main (
/home/david/hs/sandbox/infix-tycons.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
Bar (Foo 4)
*Main>
There would be no reason for this restriction. The only reason to
start infix data constructors with ':' would be to seperate them
lexically from infix functions -- just as a leading capital serves to
seperate prefix data constructors from prefix functions. There is no
such clash with type constructors as there are no type functions.
Hence the classic example:
class Arrow (~>) where ...
--
-David House, [EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] idea for avoiding temporaries
Hi all,
I was just teaching a class on minimization methods, with a focus on
conjugate gradient minimization in particular, and one of my main points
was that with conjugate gradient minimization we only need three or four
arrays of size N (depending on whether we use the Fletcher-Reeves or
Polak-Ribiere variant), that this was a huge win, and I was explaining that
in my code we use Fletcher-Reeves even though it's generally got less
stable convergence behavior, because avoiding one extra copy is well worth
it, when each copy is on the order of a gigabyte (which is not unusual in
my line of work). This got me thinking about one of the largest problems
with writing serious numerical code in Haskell, which is that of memory
consumption and avoiding temporary variables.
The count of three arrays requires assumes that we do in-place updates,
which presupposes an imperative model. But the main reason I'd like to
switch to Haskell is so that I can write pure functional code, which is
easier to read, easier to reason with, and easier to get right. So I
started wondering whether there's a solution that would allow us to write
pretty high-level pure functional code, while the RTS can realize at
run-time that we have the only reference to the input argument and that it
is therefore safe to consume it destructively. My thought is to move some
of the amazing rewriting streams stuff that's going on with Data.ByteStream
and Manuel's array fusion work onto the memory management level. If we can
rewrite high-level array manipulations into a form in which the compiler
can fuse the loops and write good low-level code, why not also allow
automatic in-place updates (when possible)?
My thought is to create a function like the following:
copy :: ForeignPtr a -> IO (ForeignPtr a)
This function ordinarily copies its input into a new chunk of memory, and
then calls the initialization function to update that memory. So we could
call it with something like
a `plus` b = do a' <- copy a
a' `plusEqual` b
return a'
Of course, in practice I imagine this whole business being encapsulated in
a module where it's called with unsafePerformIO (but it's really perfectly
safe, a la Data.ByteString).
The key is that copy will ask the GC to check whether there is more than
one reference to its input, and if there isn't, then it'll return its input
without making a copy.
Obviously, we'd want to be careful in making calls to copy (since the GC
overhead could overwhelm the potential (transient) memory savings. And
I've got no idea how hard it would be to find out if there are no other
references, or how effective this would be... that is, whether the compiler
might generate "false" references to the input that would prevent the
savings from ever being realized.
There are also other questions. My copy above is simple, but probably we'd
be better off with a more general:
copy :: a -> (a -> IO a) -> IO a
which could be used in the base libraries for other sorts of objects, such
as Array, which might not have a ForeignPtr at their back end.
We might also want a more general copy that would handle the case where we
would like to copy either one variable or another, and we don't care
which. i.e. we in my `plus` example above, if "a" can't be discarded, but
"b" can, we'll be out of luck. Perhaps we want something like
reuseOrNot :: a -> (a -> IO b) -> (a -> IO b) -> IO b
which would call one function or the other, depending on whether the input
is deemed expendible by the GC, so we could write
a `plus` b = reuseOrNot a
(\a' -> do { a' `plusEqual` b; return a' })
(\a' -> reuseOrNot b
(\b' -> do { b' `plusEqual` a'; return b' })
(\b' -> a' `boringAdd` b'))
where boringAdd is an addition that doesn't reuse either array.
Anyhow, all this would be predicated on the possibility of asking the GC
whether anyone else has a reference to a given object, and I've no idea how
tough (or slow) this would be. It'd also be effectively predicated on
someone like dons having the time and interest to write good fusion code
which would allow one to make use of this in referentially transparent
high-level pure functional code. I think it'd be pretty cool, and would
certainly (not immediately, but as my research group ramps up) be
interested in being a guinea pig user of this stuff.
Any thoughts? Am I crazy? Is this infeasible for some reason? Should I have
patented this idea before mentioning it on the list? Has someone else
already patented it?
--
David Roundy
Department of Physics
Oregon State University
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A different Maybe maybe
On 08/03/07, Dan Weston <[EMAIL PROTECTED]> wrote: Do not let the multiple responses of how you apparently wasted your time reinventing (or do they mean stealing?) something Church did long ago dampen your enthusiasm to learn exciting things and then share them. I agree with your sentiment that discovering things is fun, no matter how many times it has been done before. But I don't think the other respondents were critical. I read them as properly congratulatory, not sarcastic. It's not everyone that gets to claim they had the same idea as Alonzo Church! ;-) Maybe we need a You Could Have Invented Church Encoding (And Maybe You Already Have) [1] blog post somewhere... D. [1]: http://sigfpe.blogspot.com/2006/08/you-could-have-invented-monads-and.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: problems installing ghc 6.6 with extralibs (bad interface file)
Indeed, memory was the issue. By the way, serendipitiously, linode.com spontaneously upgraded all virtual root boxen to 256M ram for free right around the time I ran into this, which solved the problem. so, if anyone would like to try haskell in a hosted environment, I can now heartily recommend them :) 2007/2/28, Paul Brown <[EMAIL PROTECTED]>: On 2/27/07, Seth Gordon <[EMAIL PROTECTED]> wrote: > Thomas Hartman wrote: > > Thanks. I incorporated these changes, and it cranks longer now before > > failing. But still fails, now with a seg fault. > According to conventional wisdom, when gcc segfaults on a big > compilation job (e.g., the Linux kernel), it could be a sign of a > transient memory error; gcc exercises the RAM so much that the error > rate on a typical computer's memory chips can have a practical effect. I believe that you're probably correct in this case: I was able to get ghc 6.6 + optional packages built on a linode virtual host (guessing from the original poster's prompt) but only after expanding the amount of memory available. -- Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: LDFLAGS
[EMAIL PROTECTED] wrote: I have built ghc-6.6 twice for 64-bit OpenBSD 4.0 with LDFLAGS=-L/usr/local/lib set as an environmental variable. Both times the built ghc did not find -lgmp until I modified lib/ghc-6.6/package.conf by adding "-L/usr/local/lib" to ldOptions. What do I set in order to have ldOptions set properly at the conclusion of make;make install? See this bug: http://hackage.haskell.org/trac/ghc/ticket/957 Hopefully it should be fixed for 6.6.1. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] Google summer of code
David House wrote: On 06/03/07, Malcolm Wallace <[EMAIL PROTECTED]> wrote: Well, our wiki to gather ideas is now up-and-running again: http://hackage.haskell.org/trac/summer-of-code We should probably remove projects that were succeessfully completed last year, along with the lists of interested students on every project. I did some general tidying up in the Trac yesterday, including closing some of the projects that were done last year. I'd urge others to go and take a look too; I didn't do a complete sweep. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] TVars & throw
Stefan O'Rear wrote: > On Thu, Mar 08, 2007 at 12:25:15PM +1100, Thomas Conway wrote: >> Hi All, >> >> Consider the following: >> >> foo = do >>v <- newTVar "hi there!" >>throwDyn v >> >> main = do >>catchDyn (atomically foo) \v -> do >>x <- atomically (readTVar v) >>putStr x >> >> >> I.e. throw information that gets rolled back from inside a >> transaction, catch it and use it. >> >> This looks like bad. I assume it actually works, but should it? > > Read the paper! > > it is quite explicitly documented that exceptions can take data out of > a failing transaction, spj thought it preferable to simply erasing all > error data. > > Stefan And one can always use unsafeIOToSTM to exchange data as well, which is what I used to implement MonadAdvSTM. This lets you queue IO actions to perform if there is a retry and queue IO actions to perform if there is a commit. http://haskell.org/haskellwiki/New_monads/MonadAdvSTM ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A different Maybe maybe
It's not wasted time at all. Discovering things is fun and interesting; it doen't matter if someone else has discovered it first. On Mar 8, 2007, at 02:51 , Dan Weston wrote: Congratulations! You've just reinvented Church encoding. Do not let the multiple responses of how you apparently wasted your time reinventing (or do they mean stealing?) something Church did long ago dampen your enthusiasm to learn exciting things and then share them. I for one am always eager to hear them, and am now reading up on Church encoding so that I can sound as in the know as everybody else on this list. The Nobel-prize-winning Richard Feinmann loved to rederive previously discovered things. On occasion, he even managed to invent new physical theories by finding flaw in them. I suspect he might well have replied to you with somewhat more encouraging words than others have seen fit to offer. Dan ___ 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
