Re: [Haskell-cafe] Ideas
Hi > - Blogging software. (Because there isn't enough of it in the world yet.) Hope (google: Haskell Hope) > - A wiki program. (Ditto.) Flippi (google: Haskell Flippi) > - A general CMS. Hope > - An interactive function plotter. (GNUplot is nice, but it can't plot > recursive functions...) None that I know of. > - A "graphical programming tool". (You add boxes and put in lines, it > constructs a "program" that you can run.) You mean a programming tool with a horrible syntax and user interface? If you want to remove the joy from programming, just use Ada. Alternatively, use PureData, which can be extended with Haskell, and gives boxes and lines. http://haskell.org/haskellwiki/AngloHaskell/2007#Abstracts Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
Neil Mitchell wrote: - A wiki program. (Ditto.) Flippi (google: Haskell Flippi) ...and yet haskell.org uses WikiMedia? (Which is written in something bizzare like Perl...) - A general CMS. Hope Woo! I'll have to go play with this for a while... - An interactive function plotter. (GNUplot is nice, but it can't plot recursive functions...) None that I know of. Mmm, OK. I would have thought it would be a nice project for somebody... - A "graphical programming tool". (You add boxes and put in lines, it constructs a "program" that you can run.) You mean a programming tool with a horrible syntax and user interface? LOL! That's not entirely what I meant... ;-) Have you ever played with KLogic? You draw boxes and lines, and it makes some logic. (As in the digital electronics sense of "logic".) I have some (very expensive) software called Reaktor. You draw boxes and lines, it does DSP algorithms. You build synthesizers and effects boxes with it. You get the idea. (The trouble with KLogic is its utter buggyness... I'd love to have a tool like it that actually works properly!) If you want to remove the joy from programming, just use Ada. Or Perl. Or Java. Or C. Or C++. Or VB. Or... Alternatively, use PureData, which can be extended with Haskell, and gives boxes and lines. http://haskell.org/haskellwiki/AngloHaskell/2007#Abstracts OK, I'll take a cool. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
Hi > > Flippi (google: Haskell Flippi) > > ...and yet haskell.org uses WikiMedia? (Which is written in something > bizzare like Perl...) Yes, but WikiMedia is a result of years of work, Flippi is a lot less. Wikipedia uses WikiMedia - its a tried and proven solution. > >> - A "graphical programming tool". (You add boxes and put in lines, it > >> constructs a "program" that you can run.) > > Have you ever played with KLogic? You draw boxes and lines, and it makes > some logic. (As in the digital electronics sense of "logic".) > > I have some (very expensive) software called Reaktor. You draw boxes and > lines, it does DSP algorithms. You build synthesizers and effects boxes > with it. That sounds exactly like PureData - you can also do graphics as well with PureData, the demo I saw was very cool. Of course, PureData is written in C with Haskell as an extension language. The last two ideas you mentioned require a graphical user interface, which is an area of Haskell which is comparatively weak, compared to the rest of Haskell. Thanks Neil PS: Apologies to Andrew for 2 copies of this message. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
On Sat, 25 Aug 2007, Andrew Coppin wrote: > Neil Mitchell wrote: > > > > > - A wiki program. (Ditto.) > > > > > > > Flippi (google: Haskell Flippi) > > > > ...and yet haskell.org uses WikiMedia? (Which is written in something > bizzare like Perl...) > Flippi is... rather minimalistic. And fugly. You can tell it was written by someone who has trouble getting things done! I get the impression it did a certain amount of good as a proof of concept and a reminder that doing things the old-fashioned way still works though. > > > - A general CMS. > > > > > > > Hope > > > > Woo! I'll have to go play with this for a while... > While I haven't looked at it much, Hope's seeing a lot more actual use. -- [EMAIL PROTECTED] Society does not owe people jobs. Society owes it to itself to find people jobs. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
On Sat, 25 Aug 2007, Neil Mitchell wrote: > Hi > > > > Flippi (google: Haskell Flippi) > > > > ...and yet haskell.org uses WikiMedia? (Which is written in something > > bizzare like Perl...) > > Yes, but WikiMedia is a result of years of work, Flippi is a lot less. The original version was the result of a certain amount of thinking, an overnight hack and a few tweaks :-) > > Have you ever played with KLogic? You draw boxes and lines, and it makes > > some logic. (As in the digital electronics sense of "logic".) > > > > I have some (very expensive) software called Reaktor. You draw boxes and > > lines, it does DSP algorithms. You build synthesizers and effects boxes > > with it. > > That sounds exactly like PureData - you can also do graphics as well > with PureData, the demo I saw was very cool. Of course, PureData is > written in C with Haskell as an extension language. > Reaktor is rather nicer to use than PureData though, in that it's designed to work with mainstream sequencers (or any VST - I work with trackers myself) and be used by non-hackers. Also, I'm not entirely sure it's fair to say that it has Haskell as an extension language as such - but Claude's slides'll give a better explanation than I can. > The last two ideas you mentioned require a graphical user interface, > which is an area of Haskell which is comparatively weak, compared to > the rest of Haskell. > Yep. It would be nice to have a library for doing that kind of stuff though, I suspect there're many nifty projects that would be easy to implement once that was done - Haskell's good at manipulating the underlying structures. -- [EMAIL PROTECTED] "The reason for this is simple yet profound. Equations of the form x = x are completely useless. All interesting equations are of the form x = y." -- John C. Baez ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
> - A "graphical programming tool". (You add boxes and put in lines, it > constructs a "program" that you can run.) I'm not entirely exactly sure what you mean by this. If you mean one can create programs by creating them visually then perhaps you could consider Vital: http://www.cs.kent.ac.uk/projects/vital/ It's a document-centered implementation of Haskell. Allowing one to display and directly manipulate Haskell data structures in real-time. Chris. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Ideas
>> - A "graphical programming tool". (You add boxes and put in lines, it >> constructs a "program" that you can run.) > You mean a programming tool with a horrible syntax and user interface? > If you want to remove the joy from programming, just use Ada. For programmers or scientists, I agree. For designers/artists who want to make cool stuff without learning a textual programming language, I totally disagree. Look at Apple Shake, SideFX Houdini, Werkzeug, Shader FX, Unreal 3, or even National Instruments Labview, and more... They all have a (albeit very limited) visual programming language. People get real "procedural" work done with these tools. Almost every 3D movie uses at least one of tools I mentioned. Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
Bertram Felgenhauer wrote: Hi, You wrote: - An interactive function plotter. (GNUplot is nice, but it can't plot recursive functions...) Actually you can express a lot of those with the ?: operator. Ooo... interesting. I don't recall seeing *that* in the manual! gnuplot> f(x) = x < 1 ? 0 : f(x/2) + 1 gnuplot> plot f(x) works just as expected. Mutually recursive functions defined that way work, too. Still, support could be a lot better here. OK... so how do I plot a graph of the Fibonacci numbers? Similarly, how do I plot (what Haskell calls) interate f 0? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
Neil Mitchell wrote: HI Flippi (google: Haskell Flippi) ...and yet haskell.org uses WikiMedia? (Which is written in something bizzare like Perl...) Yes, but WikiMedia is a result of years of work, Flippi is a lot less. Wikipedia uses WikiMedia - its a tried and proven solution. Well, I guess... I just thought, you know, the Tcl wiki is written in Tcl, why isn't the Haskell wiki written in Haskell? Hey, aren't we trying to tell people is a *useful* language that people should learn and use? ;-) - A "graphical programming tool". (You add boxes and put in lines, it constructs a "program" that you can run.) Have you ever played with KLogic? You draw boxes and lines, and it makes some logic. (As in the digital electronics sense of "logic".) I have some (very expensive) software called Reaktor. You draw boxes and lines, it does DSP algorithms. You build synthesizers and effects boxes with it. That sounds exactly like PureData - you can also do graphics as well with PureData, the demo I saw was very cool. Of course, PureData is written in C with Haskell as an extension language. Oh. Ah well.. The last two ideas you mentioned require a graphical user interface, which is an area of Haskell which is comparatively weak, compared to the rest of Haskell. Yeah, I noticed. Though actually Gtk2hs isn't too bad. (There's a few corners that require bit-flipping and other low-level strangeness...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
Philippa Cowderoy wrote: Flippi is... rather minimalistic. And fugly. You can tell it was written by someone who has trouble getting things done! I get the impression it did a certain amount of good as a proof of concept and a reminder that doing things the old-fashioned way still works though. Ah yes, nothing like a good proof-of-concept implementation. Except that you usually can't do any "real" stuff with it. ;-) Some of you may remember a few years back, it seemed that Java was a programming language invented for implementing Tic-Tac-Toe programs... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
Philippa Cowderoy wrote: I have some (very expensive) software called Reaktor. You draw boxes and lines, it does DSP algorithms. You build synthesizers and effects boxes with it. That sounds exactly like PureData - you can also do graphics as well with PureData, the demo I saw was very cool. Of course, PureData is written in C with Haskell as an extension language. Reaktor is rather nicer to use than PureData though, in that it's designed to work with mainstream sequencers (or any VST - I work with trackers myself) and be used by non-hackers. Also, I'm not entirely sure it's fair to say that it has Haskell as an extension language as such - but Claude's slides'll give a better explanation than I can. Reaktor has a few limitations though. 1. It's virtually impossible to debug the thing! (I.e., if your synth doesn't work... good luck working out why.) 2. It lacks looping capabilities. For example, you cannot build a variable-size convolution block - only a fixed-size one. (If you want to draw *a lot* of wires!) If you look through the standard library, you'll find no end of instruments that use a "hack" of using voice polyphony to crudely simulate looping... but it's not too hot. Would be nice if I could build something in Haskell that overcomes these. OTOH, does Haskell have any way to talk to the audio hardware? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
On Aug 25, 2007, at 14:43 , Andrew Coppin wrote: Neil Mitchell wrote: HI Flippi (google: Haskell Flippi) ...and yet haskell.org uses WikiMedia? (Which is written in something bizzare like Perl...) Yes, but WikiMedia is a result of years of work, Flippi is a lot less. Wikipedia uses WikiMedia - its a tried and proven solution. Well, I guess... I just thought, you know, the Tcl wiki is written in Tcl, why isn't the Haskell wiki written in Haskell? Hey, aren't we trying to tell people is a *useful* language that people should learn and use? ;-) Are you volunteering to take the time to write and test it? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [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] Ideas
C.M.Brown wrote: - A "graphical programming tool". (You add boxes and put in lines, it constructs a "program" that you can run.) I'm not entirely exactly sure what you mean by this. I wasn't especially specific about it, that's true enough. I actually had several different things in mind... If you mean one can create programs by creating them visually then perhaps you could consider Vital: http://www.cs.kent.ac.uk/projects/vital/ It's a document-centered implementation of Haskell. Allowing one to display and directly manipulate Haskell data structures in real-time. Looks very interesting... and very low-tech visuals. :-/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
Brandon S. Allbery KF8NH wrote: On Aug 25, 2007, at 14:43 , Andrew Coppin wrote: Yes, but WikiMedia is a result of years of work, Flippi is a lot less. Wikipedia uses WikiMedia - its a tried and proven solution. Well, I guess... I just thought, you know, the Tcl wiki is written in Tcl, why isn't the Haskell wiki written in Haskell? Hey, aren't we trying to tell people is a *useful* language that people should learn and use? ;-) Are you volunteering to take the time to write and test it? Are you offering to pay me? :-D Oh, wait, "volunteer"... Well, let's put it this way: If I ever get round to making something and it turns out to be any good, you're free to use it... Don't hold your breath... ;-) PS. Do paid Haskell jobs really exist? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
> - Blogging software. (Because there isn't enough of it in the world yet.) In addition (because a little competition can't help ;), I'm going to be experimenting with writing a blog engine for my final year project at Uni next year - 2007/08. Hopefully some good will come of it, i.e. something that people (I) can actually use. It'll probably be more blog less CMS than Hope. At the minute I'm looking at using HAppS for most of it. Should be fun! Iain ps. Sorry for the spam Andrew. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
Iain Lane wrote: - Blogging software. (Because there isn't enough of it in the world yet.) In addition (because a little competition can't help ;), I'm going to be experimenting with writing a blog engine for my final year project at Uni next year - 2007/08. Hopefully some good will come of it, i.e. something that people (I) can actually use. It'll probably be more blog less CMS than Hope. At the minute I'm looking at using HAppS for most of it. Should be fun! Good luck with that - should be enjoyable at least. ;-) I'm going to have a go at it myself as well. My current blog uses something called "word press", and I don't like it especially much. (It *insists* on chewing up all my carefully applied formatting. And the people providing it have locked it down so there's loads I can't change...) So I'm hoping to write something nice to replace it with. But we'll see... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
On Sat, Aug 25, 2007 at 07:43:30PM +0100, Andrew Coppin wrote: > Neil Mitchell wrote: >> HI >> >> Flippi (google: Haskell Flippi) >>> ...and yet haskell.org uses WikiMedia? (Which is written in something >>> bizzare like Perl...) >>> >> >> Yes, but WikiMedia is a result of years of work, Flippi is a lot less. >> Wikipedia uses WikiMedia - its a tried and proven solution. >> > > Well, I guess... > > I just thought, you know, the Tcl wiki is written in Tcl, why isn't the > Haskell wiki written in Haskell? Hey, aren't we trying to tell people is a > *useful* language that people should learn and use? ;-) Actually, we aren't. You might not have been able to tell, but a core goal of our community is to stay small and avoid success at all costs; our language is not practical, not designed to be practical, and if it ever becomes practical, it will have done so only by a terrible streak of bad luck. Remember, success breeds inertia, and inertia would ruin our fundamental goal of being an agile research language. :) Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
Stefan O'Rear wrote: On Sat, Aug 25, 2007 at 07:43:30PM +0100, Andrew Coppin wrote: Hey, aren't we trying to tell people is a *useful* language that people should learn and use? ;-) Actually, we aren't. You might not have been able to tell, but a core goal of our community is to stay small and avoid success at all costs; our language is not practical, not designed to be practical, and if it ever becomes practical, it will have done so only by a terrible streak of bad luck. Remember, success breeds inertia, and inertia would ruin our fundamental goal of being an agile research language. Heh. Well, that told me... o_O Maybe *this* is why everybody else thinks I'm an idiot for using Haskell... :-( PS. Wasn't one of the explicit design goals "to design a standardised language for teaching FP"? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
Andrew Coppin wrote: C.M.Brown wrote: If you mean one can create programs by creating them visually then perhaps you could consider Vital: http://www.cs.kent.ac.uk/projects/vital/ It's a document-centered implementation of Haskell. Allowing one to display and directly manipulate Haskell data structures in real-time. Looks very interesting... and very low-tech visuals. :-/ Hang on a minute... it's written in Java... and it can run Haskell code...? o_O Now that's interesting! (Re. the other thread about "we should have an automatic expression reducing program"...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Ideas
>> *useful* language that people should learn and use? ;-) >Actually, we aren't. You might not have been able to tell, >but a core goal of our community is to stay small and avoid >success at all costs; our language is not practical, >not designed to be practical, and if it ever becomes practical, >it will have done so only by a terrible streak of bad luck. >Remember, success breeds inertia, and inertia would ruin >our fundamental goal of being an agile research language. Well, IMHO the only reasons why Haskell is not a language for the masses are: - No marketing. If a company as big as Microsoft would decide that Haskell is to become the standard language, then it would be so. - Ancient IDEs. When someone comes from Eclipse or Visual Studio it feels one is teleported back to the stone ages. Although Visual Haskell looks promising, it seems to be in the pre-beta stage. - Although the documentation is very good, it is rather bulky, which can scare away newbies. - As Haskell is currently used a lot by people with an average IQ of 160, the available packages and programming approaches are not easily absorbed for the average software engineer with an IQ of 120 ;-) However, once you take your time to dig deep into the matter, one often sees the beauty behind it. But many newbies just feel really stupid when they look at Haskell code :) I certainly did and still do, but fortunately I know I'm not very clever, so that's okay ;) - I haven't looked at the debuggers, but I've heared Haskell is really hard to debug. Anyway, although my IQ is far below 160, I find Haskell the most exciting language I have ever learned (and I've only scratched the bare surface of the language) Cheers, Peter Verswyvelen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Ideas
I tried vital, and at first sight it is very nice, but they only support a very limited subset of Haskell, perform no type checking at all, don't support the indent rule, etc... Anyway it is an amazing piece of work. Regarding your question about visual programming, GEM Cutter from the Open Quark Framework is also nice. http://labs.businessobjects.com/cal. But they also wrote their own Haskell98 (with some Hugs extension) compiler in... Java. Cheers, Peter Verswyvelen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Coppin Sent: Saturday, August 25, 2007 9:37 PM To: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Ideas Andrew Coppin wrote: > C.M.Brown wrote: >> If you mean one can >> create programs by creating them visually then perhaps you could >> consider >> Vital: >> >> http://www.cs.kent.ac.uk/projects/vital/ >> >> It's a document-centered implementation of Haskell. Allowing one to >> display and directly manipulate Haskell data structures in real-time. >> > > Looks very interesting... and very low-tech visuals. :-/ Hang on a minute... it's written in Java... and it can run Haskell code...? o_O Now that's interesting! (Re. the other thread about "we should have an automatic expression reducing program"...) ___ 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] Ideas
Peter Verswyvelen wrote: I tried vital, and at first sight it is very nice, but they only support a very limited subset of Haskell, perform no type checking at all, don't support the indent rule, etc... Anyway it is an amazing piece of work. Regarding your question about visual programming, GEM Cutter from the Open Quark Framework is also nice. http://labs.businessobjects.com/cal. But they also wrote their own Haskell98 (with some Hugs extension) compiler in... Java. Cheers, Peter Verswyvelen Vital seems to have a really damn nice concept behind it. The visuals don't look quite so hot though... ;-) If I could figure out how to do the whole "drag boxes around, draw lines" stuff with Gtk2hs, I might have a go at bettering this myself... but that's unlikely. GEM Cutter also falls into the category of "hey, that's interesting, I should go find out about this stuff..." ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
> Reaktor has a few limitations though. > > 1. It's virtually impossible to debug the thing! (I.e., if your synth > doesn't work... good luck working out why.) > > 2. It lacks looping capabilities. For example, you cannot build a > variable-size convolution block - only a fixed-size one. (If you want to > draw *a lot* of wires!) If you look through the standard library, you'll > find no end of instruments that use a "hack" of using voice polyphony to > crudely simulate looping... but it's not too hot. > > Would be nice if I could build something in Haskell that overcomes > these. OTOH, does Haskell have any way to talk to the audio hardware? Nyquist is a music language from a whlie back that I liked (in theory, not so much in practice). It has a functional model in that "instruments" are just functions that return sample streams, so there's no difference between signal processing and signal generating functions (or orchestra and score, for the csounders out there). This was made efficient by lazily evaluating the streams and some custom hackery where it would e.g. notice that one signal going into (+) had ended and simply unlink the entire operation from the call graph, and some gc hackery to reclaim sound blocks quickly. The other interesting feature was "behaviours" which were just dynamically scoped variables that would propagate down to the nearest function that cared to interpret them, e.g. (transpose 5 (seq (melody 1) (melody 2))) would transpose the tones generated by (melody) by setting a dynamic variable that would later be read by the underlying oscillators or whatever that melody used. "seq" used the mechanism to shift or scale the beginnings end endings of notes. It was also more powerful than e.g. csound, supecollider, or reaktor style languages because in the former you have to compile a static call graph (the "orchestra") and then "play" it with signals dynamically (the "score"), whereas in nyquist there's no orchestra and score division. The disadvantage is that the immutable signals made it hard to implement real-time synthesis. The practical problem was that it was implemented in a hacked up XLisp which was primitive and hard to debug. Added to that, you had to be careful to wrap signals in functions or macros so the eager interpreter wouldn't evaluate the whole signal and kill performance. To get this back to haskell, at the time I wondered if a more natural implementation might be possible in haskell, seeing as it was more naturally lazy. Not sure how to implement the behaviours though (which were simply macros around a let of *dynamic-something*). I'm sure people have done plenty of signal processing, and there's always haskore... but what about a sound generation language like csound or clm or nyquist? It could fit in nicely below haskore. Also, as another reaktor user I agree it would have been so much nicer were it simply a real language. Drawing those boxes and lines and the complete lack of abstraction (beyond copy and paste) is a real pain. Supercollider is more promising in that way, but less polished of course. It also has that two-level imperative model though where you create and modify your signal graph with imperative techniques, then run it, rather than your program *being* the signal graph. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
Peter Verswyvelen wrote: Well, IMHO the only reasons why Haskell is not a language for the masses are: - No marketing. If a company as big as Microsoft would decide that Haskell is to become the standard language, then it would be so. See, for example, Java... - Ancient IDEs. Can't comment. Every IDE I've used recently sucked anyway. ;-) - As Haskell is currently used a lot by people with an average IQ of 160, the available packages and programming approaches are not easily absorbed for the average software engineer with an IQ of 120 ;-) However, once you take your time to dig deep into the matter, one often sees the beauty behind it. But many newbies just feel really stupid when they look at Haskell code :) I certainly did and still do, but fortunately I know I'm not very clever, so that's okay ;) I have an IQ of 103. Apparently. (This makes me officially the most stupid person on the povray.off-topic newsgroup...) - I haven't looked at the debuggers, but I've heared Haskell is really hard to debug. OTOH, Haskell requires less debugging in the first place. ;-) Anyway, although my IQ is far below 160, I find Haskell the most exciting language I have ever learned (and I've only scratched the bare surface of the language) Indeed. Personally, I don't *want* Haskell to be a research language. I want Haskell to be The Next Big Thing. I want to see newspapers full of people trying to recruit Haskell programmers rather than all this C / C++ / Java stuff. ;-) Still, it will never happen... Would be nice if I could convince people that Haskell isn't just for idiots though. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
Evan Laforge wrote: To get this back to haskell, at the time I wondered if a more natural implementation might be possible in haskell, seeing as it was more naturally lazy. Not sure how to implement the behaviours though (which were simply macros around a let of *dynamic-something*). I'm sure people have done plenty of signal processing, and there's always haskore... but what about a sound generation language like csound or clm or nyquist? It could fit in nicely below haskore. Indeed, you can write certain DSP algorithms beautifully in Haskell. Now, if only it could talk to the audio hardware... (Or just use common file formats even.) Also, as another reaktor user I agree it would have been so much nicer were it simply a real language. Drawing those boxes and lines and the complete lack of abstraction (beyond copy and paste) is a real pain. Supercollider is more promising in that way, but less polished of course. It also has that two-level imperative model though where you create and modify your signal graph with imperative techniques, then run it, rather than your program *being* the signal graph. Reaktor has abstraction. You can build a gizmo that does something useful, call it a macro, and then use it whereever you want. If you want to build a gizmo that takes a siganl "x" and computes "8*x*x*x - 8*x*x + 1" (i.e., the 4th Chebyshev polynomial), you've going to have to draw *a lot* of wires! It would be nice if there was some feature for quickly building complicated chunks of pure algebra like that. It would also be nice if there were some way to *programmatically* construct the graph... but never mind. (Maybe in Reaktor 6?) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
> Indeed, you can write certain DSP algorithms beautifully in Haskell. > Now, if only it could talk to the audio hardware... (Or just use common > file formats even.) Oh, that's easy. I wrote an FFI interface to portaudio a while back to write a delay-looping type utility in haskell. It was pretty trivial. You could do the same for libsndfile or whatever. The only thing I'm uncertain about is whether it would have good enough time and space performance. All the real work is writing yet another set of basic envelope, oscillator, and fft primitives. You *should* be able to go all the way down to the samples in pure haskell though, which would be more elegant than those other languages :) > Reaktor has abstraction. You can build a gizmo that does something > useful, call it a macro, and then use it whereever you want. Well, except that if you then change your macro you have re-copy it into every instrument or ensemble or other macro that uses it. So I consider the macros basically a copy and paste mechanism. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Ideas
> I tried vital, and at first sight it is very nice, but they only support a > very limited subset of Haskell, perform no type checking at all, don't > support the indent rule, etc... Anyway it is an amazing piece of work. I believe that type-sensitive manipulation was certainly being investigated; however, I can't confirm as to how far it *was* investigated. What intriged me mostly was how it can display infinite data structures lazily. I think it's certainly a great tool for teaching some aspects of functional programming: helping newbies to understand and define data structures, say. Chris. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
Evan Laforge writes: Indeed, you can write certain DSP algorithms beautifully in Haskell. Now, if only it could talk to the audio hardware... (Or just use common file formats even.) Oh, that's easy. I wrote an FFI interface to portaudio a while back to write a delay-looping type utility in haskell. It was pretty trivial. You could do the same for libsndfile or whatever. The only thing I'm uncertain about is whether it would have good enough time and space performance. All the real work is writing yet another set of basic envelope, oscillator, and fft primitives. You *should* be able to go all the way down to the samples in pure haskell though, which would be more elegant than those other languages :) == Well, if you want to see what you can do with a lazy functional language, not necessarily Haskell, but Clean (sorry for advertizing a competitor on this list...), perhaps have a look on my PADL paper http://users.info.unicaen.fr/~karczma/arpap/cleasyn.pdf I generated .wav files as output, from lazy streams, so the sound was off-line. My ambition was to code in a very, very compact way some musical instruments, with looping replaced by co-recursion. It cannot be extremely efficient, but it seems quite elegant and powerful. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
On Sat, 25 Aug 2007, Andrew Coppin wrote: > Would be nice if I could build something in Haskell that overcomes these. > OTOH, does Haskell have any way to talk to the audio hardware? > It would definitely be nice if someone wrote a binding to the VST SDK or a wrapper for it. Unfortunately I suspect it's too windows-specific for most of those on the list, and there isn't a sufficiently good portable and widely-used/available alternative. -- [EMAIL PROTECTED] "The reason for this is simple yet profound. Equations of the form x = x are completely useless. All interesting equations are of the form x = y." -- John C. Baez ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Ideas
> What intriged me mostly was how it can display infinite data structures > lazily. I think it's certainly a great tool for teaching some aspects of > functional programming: helping newbies to understand and define data > Structures, say. Definitely! It's really cool stuff. But something like that for real Haskell (e.g. GHC) would be even better :) I could be an offline downloadable application. It would be a very nice tool: create postscript (or PDF, or LaTex, whatever rich text format) documents with Haskell "boxes" inside. Real literate programming... Oh well ;) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Ideas
> Definitely! It's really cool stuff. But something like that for real Haskell > (e.g. GHC) would be even better :) I could be an offline downloadable > application. It would be a very nice tool: create postscript (or PDF, or > LaTex, whatever rich text format) documents with Haskell "boxes" inside. > Real literate programming... Oh well ;) I would personally say Haskell 98 is "real" Haskell (well, until Haskell Prime comes out). It becomes difficult for tool developers to cater for non-standard languages; Haskell is quite complicated enough without having to cater for all the little nuances and idiomatic extensions that are constantly added with each release of a compiler. I believe it does work as an offline downloadable tool... http://www.cs.kent.ac.uk/projects/vital/install/index.html Chris. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
On Sat, 2007-08-25 at 22:51 +0100, Philippa Cowderoy wrote: > On Sat, 25 Aug 2007, Andrew Coppin wrote: > > > Would be nice if I could build something in Haskell that overcomes these. > > OTOH, does Haskell have any way to talk to the audio hardware? > > > > It would definitely be nice if someone wrote a binding to the VST SDK or a > wrapper for it. Unfortunately I suspect it's too windows-specific for most > of those on the list, and there isn't a sufficiently good portable and > widely-used/available alternative. > I recently wrote a binding to LADSPA. I just need to finish packaging it and upload it to Hackage. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
On Sat, 2007-08-25 at 23:36 +0200, [EMAIL PROTECTED] wrote: > Evan Laforge writes: > > >> Indeed, you can write certain DSP algorithms beautifully in Haskell. > >> Now, if only it could talk to the audio hardware... (Or just use common > >> file formats even.) > > > > Oh, that's easy. I wrote an FFI interface to portaudio a while back > > to write a delay-looping type utility in haskell. It was pretty > > trivial. You could do the same for libsndfile or whatever. > > > > The only thing I'm uncertain about is whether it would have good > > enough time and space performance. All the real work is writing yet > > another set of basic envelope, oscillator, and fft primitives. You > > *should* be able to go all the way down to the samples in pure haskell > > though, which would be more elegant than those other languages :) > > == > > Well, if you want to see what you can do with a lazy functional language, > not necessarily Haskell, but Clean (sorry for advertizing a competitor > on this list...), perhaps have a look on my PADL paper > > http://users.info.unicaen.fr/~karczma/arpap/cleasyn.pdf > > I generated .wav files as output, from lazy streams, so the sound was > off-line. > My ambition was to code in a very, very compact way some musical > instruments, with looping replaced by co-recursion. It cannot be extremely > efficient, but it seems quite elegant and powerful. Last week I did exactly that. Using lazy streams and a quickly hacked up .wav file output, I played with some of the extended Karplus-Strong plucked string/drum synthesis algorithms. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
Evan Laforge wrote: Indeed, you can write certain DSP algorithms beautifully in Haskell. Now, if only it could talk to the audio hardware... (Or just use common file formats even.) Oh, that's easy. I wrote an FFI interface to portaudio a while back to write a delay-looping type utility in haskell. It was pretty trivial. You could do the same for libsndfile or whatever. Well, since I can't do C... (What I typically end up doing in these situations is to write a small server program in some language that *does* have the feature I want, and then talk to it over TCP from the language that *doesn't* have the feature. But it's typically quite a lot of typing... and the only language I know of that supports sound (other than C) is Java. And it's *very* complicated...) The only thing I'm uncertain about is whether it would have good enough time and space performance. All the real work is writing yet another set of basic envelope, oscillator, and fft primitives. You *should* be able to go all the way down to the samples in pure haskell though, which would be more elegant than those other languages :) Heh. FFT is tricky. But I got it to work one time... ;-) Reaktor has abstraction. You can build a gizmo that does something useful, call it a macro, and then use it whereever you want. Well, except that if you then change your macro you have re-copy it into every instrument or ensemble or other macro that uses it. So I consider the macros basically a copy and paste mechanism. True, true... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Ideas
Chris wrote: > I would personally say Haskell 98 is "real" Haskell (well, until Haskell... > I believe it does work as an offline downloadable tool... > http://www.cs.kent.ac.uk/projects/vital/install/index.html With "real Haskell" I ment strong type checking and indentation for determining scope; without the former, it becomes a different experience IMO. Avoiding runtime errors because types don't match is one the main advantages of Haskell; without this, I'm afraid it is difficult to get a good feeling of the Haskell programming language, be it Haskell98 Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
Evan Laforge wrote: The only thing I'm uncertain about is whether it would have good enough time and space performance. All the real work is writing yet another set of basic envelope, oscillator, and fft primitives. You *should* be able to go all the way down to the samples in pure haskell though, which would be more elegant than those other languages :) I've been playing with using Arrows as stream processors for audio, and the dataflow syntax of arrows is quite nice for sample manipulation: -- low pass filter (1-zero) lop i = proc (x, f) -> do sr <- readState -< SampleRate let c = clip (2 * pi * f / sr) 0 1 rec y <- delay i -< o let o = x * c + (1 - c) * y returnA -< o lop :: (ArrowCircuit a, ArrowReader b a, Floating b, Ord b) => b -> a (b, b) b Unfortunately it's *very* slow - to render a 5s sine oscillator sweep from 20Hz to 2Hz through a low pass filter at 44100Hz sampling rate takes around 17s. Admittedly 40% of the time is spent outputting the numbers to a text file, but it's still far far from realtime, and churns through 7GB of memory in the process (the total memory usage at any one time is constant and small, however). Claude -- http://claudiusmaximus.goto10.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
On Sat, 25 Aug 2007, Andrew Coppin wrote: Would be nice if I could build something in Haskell that overcomes these. OTOH, does Haskell have any way to talk to the audio hardware? Maybe a JACK interface? http://haskell.org/haskellwiki/Applications_and_libraries/Music_and_sound ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
On Sat, 25 Aug 2007, Evan Laforge wrote: Reaktor has a few limitations though. 1. It's virtually impossible to debug the thing! (I.e., if your synth doesn't work... good luck working out why.) 2. It lacks looping capabilities. For example, you cannot build a variable-size convolution block - only a fixed-size one. (If you want to draw *a lot* of wires!) If you look through the standard library, you'll find no end of instruments that use a "hack" of using voice polyphony to crudely simulate looping... but it's not too hot. Would be nice if I could build something in Haskell that overcomes these. OTOH, does Haskell have any way to talk to the audio hardware? ... To get this back to haskell, at the time I wondered if a more natural implementation might be possible in haskell, seeing as it was more naturally lazy. Not sure how to implement the behaviours though (which were simply macros around a let of *dynamic-something*). I'm sure people have done plenty of signal processing, and there's always haskore... but what about a sound generation language like csound or clm or nyquist? It could fit in nicely below haskore. I'm playing around with Haskore controlling signal synthesis implemented in pure Haskell for some time now: http://darcs.haskell.org/synthesizer/src/Haskore/Interface/Signal/ It works, but it's still slow and hard to install. This discussion is certainly also of interest for the haskell-art mailing list. http://lists.lurk.org/mailman/listinfo/haskell-art ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
On Sat, 25 Aug 2007, Andrew Coppin wrote: How easy would it be to make / would anybody care / has somebody already made ... in Haskell? - An interactive function plotter. (GNUplot is nice, but it can't plot recursive functions...) I'm be interested to use such a library. - A "graphical programming tool". (You add boxes and put in lines, it constructs a "program" that you can run.) Would be nice for editing signal processing that is coded in Haskell. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
On Sun, 26 Aug 2007, Andrew Coppin wrote: The only thing I'm uncertain about is whether it would have good enough time and space performance. All the real work is writing yet another set of basic envelope, oscillator, and fft primitives. You *should* be able to go all the way down to the samples in pure haskell though, which would be more elegant than those other languages :) Heh. FFT is tricky. But I got it to work one time... ;-) There's already an extensive FFT implementation in Haskell by Matt Donadio: http://haskelldsp.sourceforge.net/ (I'm working on some clean up at http://darcs.haskell.org/dsp/Numeric/Transform/Fourier/ ) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
John MacFarlane wrote: > > +++ Andrew Coppin [Aug 25 07 12:50 ]: > > > I wrote a simple wiki using HAppS and pandoc. See demonstration #15 > on the pandoc web page: > > http://sophos.berkeley.edu/macfarlane/pandoc/examples.html > > o Hey ! that s exactly whatI had in mind.. cool indeed, I am toying with the idea to - produce book, nicely (automatically) typeset with Latex or docbook - out of a wiki as interface ( as wikibook for instance) - with either free and informal text , - or formally ( automatically produced) sets or reference or docs ( a bit like literate programming embed code into the text), but these table would be more and more refined set of requirement.. This last point was with a software ingeniering backgroud in mind, ie to produce the requirement, and specification of software, , imagine a lot of reference and cross reference to manage, and to establish tracability..( if you heard about Cleanroom, just to examplify ) may i ask you what did you had in mind as an application when you started that ? -- View this message in context: http://www.nabble.com/Ideas-tf4327747.html#a12337130 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
All went finally fine. wiki is live. thanks for your help. great example. this helped me progressing my understanding of happs. This should conveniently go on the happs tutorial wiki., or at least be referred to . (I have seen alex is doing some tutorial on a wiki in the latest head release, so definitively this is the topic of the day !!) fyi, the cabal run (runghc) could not find the Diff file ( in the same directory anyway) o_o but ghc --make PanDocwiki.hs had it ok.) John MacFarlane wrote: > > lcs can be found at http://urchin.earth.li/darcs/igloo/lcs/ > > +++ Luc TAESCH [Aug 26 07 23:45 ]: >> when building , i cannot find the lcs mentionned in the cabal file not >> on hasckage nor on goggle. >> could you help? > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- View this message in context: http://www.nabble.com/Ideas-tf4327747.html#a12344039 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
On 8/26/07, Stefan O'Rear <[EMAIL PROTECTED]> wrote: > Actually, we aren't. You might not have been able to tell, but a core > goal of our community is to stay small and avoid success at all costs; > our language is not practical, not designed to be practical, and if it > ever becomes practical, it will have done so only by a terrible streak > of bad luck. Remember, success breeds inertia, and inertia would ruin > our fundamental goal of being an agile research language. Yes! We agree :-) Can someone please do something about the horrible paragraph at the end of this page here: http://www.haskell.org/complex/why_does_haskell_matter.html , which is what inspired my rather passive/agressive attitude to the Haskell community ;-) "Another reaso for the lack of Haskell, and other functional languages, in mainstream use is that programming languages are rarely thought of as tools (even though they are). To most people their favorite programming language is much more like religion - it just seems unlikely that any other language exists that can get the job done better and faster. There is a paper by Paul Graham called Beating the Averages describing his experience using Lisp, another functional language, for an upstart company. In it he uses an analogy which he calls "The Blub Paradox". It goes a little something like this: If a programmer's favorite language is Blub, which is positioned somewhere in the middle of the "power spectrum", he can most often only identify languages that are lower down in the spectrum. He can look at COBOL and say "How can anyone get anything done in that language, it doesn't have feature x", x being a feature in Blub. However, this Blub programmer has a harder time looking the other way in the spectrum. If he examines languages that are higher up in the power spectrum, they will just seem "weird" because the Blub programmer is "thinking in Blub" and can not possibly see the uses for various features of more powerful languages. It goes without saying that this inductively leads to the conclusion that to be able to compare all languages you'll need to position yourself at the top of the power spectrum. It is my belief that functional languages, almost by definition, are closer to the top of the power spectrum than imperative ones. So languages can actually limit a programmers frame of thought. If all you've ever programmed is Blub, you may not see the limitations of Blub - you may only do that by switching to another level which is more powerful." The author of this paragraph fails to realize that the Blub Paradox cut both ways ;-) Anyway, there I've said it, so that's out of the way perhaps :-D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
Oooo... just noticed that the page is not anonymous errr :-D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
On 8/27/07, Hugh Perkins <[EMAIL PROTECTED]> wrote: > Oooo... just noticed that the page is not anonymous errr :-D > FWIW, the rest of the page is awesome. Good work. It was one of the pages that inspired me to look at Haskell. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
Hi, Am Samstag, den 25.08.2007, 12:50 +0100 schrieb Andrew Coppin: > How easy would it be to make / would anybody care / has somebody already > made ... in Haskell? > > - A wiki program. (Ditto.) I wrote a wiki in haskell, but it focuses on full-sized LaTeX-Documents, so the “regular” wiki party is rather limited. But of course it can be extended... (It’s based on subversion, and the small CGI-part is written in python). Wiki (self-hosting): http://latexki.nomeata.de/ Application: http://mitschriebwiki.nomeata.de/ Greetings, Joachim -- Joachim "nomeata" Breitner mail: [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Key: 4743206C JID: [EMAIL PROTECTED] | http://www.joachim-breitner.de/ Debian Developer: [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas
On Saturday 25 August 2007 20:49, Andrew Coppin wrote: > [...] Would be nice if I could build something in Haskell that overcomes > these. OTOH, does Haskell have any way to talk to the audio hardware? Depending on what you are exactly trying to do, the OpenAL/ALUT packages might be of interest. Slighty dated online docs are here: http://haskell.org/HOpenGL/newAPI/OpenAL/Sound-OpenAL.html http://haskell.org/HOpenGL/newAPI/ALUT/Sound-ALUT.html Cheers, S. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas on a fast and tidy CSV library
Justin Paston-Cooper writes: > Dear All, > > Recently I have been doing a lot of CSV processing. I initially tried to > use the Data.Csv (cassava) library provided on Hackage, but I found this to > still be too slow for my needs. In the meantime I have reverted to hacking > something together in C, but I have been left wondering whether a tidy > solution might be possible to implement in Haskell. > Have you tried profiling your cassava implementation? In my experience I've found it's quite quick. If you have an example of a slow path I'm sure Johan (cc'd) would like to know about it. > I would like to build a library that satisfies the following: > > 1) Run a function < ... -> a_n -> m (Maybe (b_1, ..., b_n))>>, > with <> some monad and the <>s and <>s being input and output. > > 2) Be able to specify a maximum record string length and output record > string length, so that the string buffers used for reading and outputting > lines can be reused, preventing the need for allocating new strings for > each record. > > 3) Allocate only once, the memory where the parsed input values, and output > values are put. > Ultimately this could be rather tricky to enforce. Haskell code generally does a lot of allocation and the RTS is well optimized to handle this. I've often found that trying to shoehorn a non-idiomatic "optimal" imperative approach into Haskell produces worse performance than the more readable, idiomatic approach. I understand this leaves many of your questions unanswered, but I'd give the idiomatic approach a bit more time before trying to coerce C into Haskell. Profile, see where the hotspots are and optimize appropriately. If the profile has you flummoxed, the lists and #haskell are always willing to help given the time. Cheers, - Ben pgpp3Fd9RzpaG.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas on a fast and tidy CSV library
On Tue, Jul 23, 2013 at 5:45 PM, Ben Gamari wrote: > Justin Paston-Cooper writes: > >> Dear All, >> >> Recently I have been doing a lot of CSV processing. I initially tried to >> use the Data.Csv (cassava) library provided on Hackage, but I found this to >> still be too slow for my needs. In the meantime I have reverted to hacking >> something together in C, but I have been left wondering whether a tidy >> solution might be possible to implement in Haskell. >> > Have you tried profiling your cassava implementation? In my experience > I've found it's quite quick. If you have an example of a slow path I'm > sure Johan (cc'd) would like to know about it. I'm always interested in examples of code that is not running fast enough. Send me a reproducible example (preferably as a bug on the GitHub bug tracker) and I'll take a look. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas on a fast and tidy CSV library
I hadn't yet tried profiling the programme. I actually deleted it a few days ago. I'm going to try to get something new running, and I will report back. On a slightly less related track: Is there any way to use cassava so that I can have pure state and also yield CSV lines while my computation is running instead of everything at the end as would be with the State monad? On 23 July 2013 22:13, Johan Tibell wrote: > On Tue, Jul 23, 2013 at 5:45 PM, Ben Gamari > wrote: > > Justin Paston-Cooper writes: > > > >> Dear All, > >> > >> Recently I have been doing a lot of CSV processing. I initially tried to > >> use the Data.Csv (cassava) library provided on Hackage, but I found > this to > >> still be too slow for my needs. In the meantime I have reverted to > hacking > >> something together in C, but I have been left wondering whether a tidy > >> solution might be possible to implement in Haskell. > >> > > Have you tried profiling your cassava implementation? In my experience > > I've found it's quite quick. If you have an example of a slow path I'm > > sure Johan (cc'd) would like to know about it. > > I'm always interested in examples of code that is not running fast > enough. Send me a reproducible example (preferably as a bug on the > GitHub bug tracker) and I'll take a look. > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas on a fast and tidy CSV library
You can use the Incremental or Streaming modules to get more fine grained control over when new parsed records are produced. On Thu, Jul 25, 2013 at 11:02 AM, Justin Paston-Cooper wrote: > I hadn't yet tried profiling the programme. I actually deleted it a few days > ago. I'm going to try to get something new running, and I will report back. > On a slightly less related track: Is there any way to use cassava so that I > can have pure state and also yield CSV lines while my computation is running > instead of everything at the end as would be with the State monad? > > > On 23 July 2013 22:13, Johan Tibell wrote: >> >> On Tue, Jul 23, 2013 at 5:45 PM, Ben Gamari >> wrote: >> > Justin Paston-Cooper writes: >> > >> >> Dear All, >> >> >> >> Recently I have been doing a lot of CSV processing. I initially tried >> >> to >> >> use the Data.Csv (cassava) library provided on Hackage, but I found >> >> this to >> >> still be too slow for my needs. In the meantime I have reverted to >> >> hacking >> >> something together in C, but I have been left wondering whether a tidy >> >> solution might be possible to implement in Haskell. >> >> >> > Have you tried profiling your cassava implementation? In my experience >> > I've found it's quite quick. If you have an example of a slow path I'm >> > sure Johan (cc'd) would like to know about it. >> >> I'm always interested in examples of code that is not running fast >> enough. Send me a reproducible example (preferably as a bug on the >> GitHub bug tracker) and I'll take a look. > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas on a fast and tidy CSV library
Dear All, I now have some example code. I have put it on: http://pastebin.com/D9MPmyVd. vectorBinner is simply of type Vector Int -> Int. I am inputting a 1.5GB CSV on stdin, and would like vectorBinner to run over every single record, outputting results as computed, thus running in constant memory. My programme instead quickly approaches full memory use. Is there any way to work around this? Justin On 25 July 2013 17:53, Johan Tibell wrote: > You can use the Incremental or Streaming modules to get more fine > grained control over when new parsed records are produced. > > On Thu, Jul 25, 2013 at 11:02 AM, Justin Paston-Cooper > wrote: > > I hadn't yet tried profiling the programme. I actually deleted it a few > days > > ago. I'm going to try to get something new running, and I will report > back. > > On a slightly less related track: Is there any way to use cassava so > that I > > can have pure state and also yield CSV lines while my computation is > running > > instead of everything at the end as would be with the State monad? > > > > > > On 23 July 2013 22:13, Johan Tibell wrote: > >> > >> On Tue, Jul 23, 2013 at 5:45 PM, Ben Gamari > >> wrote: > >> > Justin Paston-Cooper writes: > >> > > >> >> Dear All, > >> >> > >> >> Recently I have been doing a lot of CSV processing. I initially tried > >> >> to > >> >> use the Data.Csv (cassava) library provided on Hackage, but I found > >> >> this to > >> >> still be too slow for my needs. In the meantime I have reverted to > >> >> hacking > >> >> something together in C, but I have been left wondering whether a > tidy > >> >> solution might be possible to implement in Haskell. > >> >> > >> > Have you tried profiling your cassava implementation? In my experience > >> > I've found it's quite quick. If you have an example of a slow path I'm > >> > sure Johan (cc'd) would like to know about it. > >> > >> I'm always interested in examples of code that is not running fast > >> enough. Send me a reproducible example (preferably as a bug on the > >> GitHub bug tracker) and I'll take a look. > > > > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas on a fast and tidy CSV library
As I mentioned, you want to use the Streaming (or Incremental) module. As the program now stands the call to `decode` causes 1.5 GB of CSV data to be read as a `Vector (Vector Int)` before any encoding starts. -- Johan On Wed, Aug 21, 2013 at 1:09 PM, Justin Paston-Cooper wrote: > Dear All, > > I now have some example code. I have put it on: http://pastebin.com/D9MPmyVd > . > > vectorBinner is simply of type Vector Int -> Int. I am inputting a 1.5GB CSV > on stdin, and would like vectorBinner to run over every single record, > outputting results as computed, thus running in constant memory. My > programme instead quickly approaches full memory use. Is there any way to > work around this? > > Justin > > > On 25 July 2013 17:53, Johan Tibell wrote: >> >> You can use the Incremental or Streaming modules to get more fine >> grained control over when new parsed records are produced. >> >> On Thu, Jul 25, 2013 at 11:02 AM, Justin Paston-Cooper >> wrote: >> > I hadn't yet tried profiling the programme. I actually deleted it a few >> > days >> > ago. I'm going to try to get something new running, and I will report >> > back. >> > On a slightly less related track: Is there any way to use cassava so >> > that I >> > can have pure state and also yield CSV lines while my computation is >> > running >> > instead of everything at the end as would be with the State monad? >> > >> > >> > On 23 July 2013 22:13, Johan Tibell wrote: >> >> >> >> On Tue, Jul 23, 2013 at 5:45 PM, Ben Gamari >> >> wrote: >> >> > Justin Paston-Cooper writes: >> >> > >> >> >> Dear All, >> >> >> >> >> >> Recently I have been doing a lot of CSV processing. I initially >> >> >> tried >> >> >> to >> >> >> use the Data.Csv (cassava) library provided on Hackage, but I found >> >> >> this to >> >> >> still be too slow for my needs. In the meantime I have reverted to >> >> >> hacking >> >> >> something together in C, but I have been left wondering whether a >> >> >> tidy >> >> >> solution might be possible to implement in Haskell. >> >> >> >> >> > Have you tried profiling your cassava implementation? In my >> >> > experience >> >> > I've found it's quite quick. If you have an example of a slow path >> >> > I'm >> >> > sure Johan (cc'd) would like to know about it. >> >> >> >> I'm always interested in examples of code that is not running fast >> >> enough. Send me a reproducible example (preferably as a bug on the >> >> GitHub bug tracker) and I'll take a look. >> > >> > > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ideas for a phd in the area of paralleism?
On Wed, Jan 07, 2009 at 10:35:25AM +0100, Michael Lesniak wrote: > Hello, > > currently I'm searching for a topic for my phd-thesis or at least for > a workshop-paper (as a starting point, to get my feet wet...). My > academic group has specialized itself on (practical, i.e. not too > theoretical stuff like verification, etc...) parallel programming and > related topics, so my future thesis has to be in this area, but as > long as its related I'm free to choose whatever I want. GPU programming seems to be hot: http://www.cse.unsw.edu.au/~chak/papers/gpugen.pdf http://www.cs.chalmers.se/Cs/Education/Courses/svh/Slides/may-15-Obsidian-short.pdf Regards, Frederik ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ideas for a phd in the area of paralleism?
Frederik Deweerdt wrote: On Wed, Jan 07, 2009 at 10:35:25AM +0100, Michael Lesniak wrote: Hello, currently I'm searching for a topic for my phd-thesis or at least for a workshop-paper (as a starting point, to get my feet wet...). My academic group has specialized itself on (practical, i.e. not too theoretical stuff like verification, etc...) parallel programming and related topics, so my future thesis has to be in this area, but as long as its related I'm free to choose whatever I want. GPU programming seems to be hot: http://www.cse.unsw.edu.au/~chak/papers/gpugen.pdf http://www.cs.chalmers.se/Cs/Education/Courses/svh/Slides/may-15-Obsidian-short.pdf Make OpenCL bindings please, please ... pretty please. Martin Regards, Frederik ___ 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] ideas for a phd in the area of paralleism?
Hi, check http://www.intellasys.net/index.php?option=com_content&task=view&id=35 http://groups.google.com.tw/group/seaforth That's a FORTH cpu I ever took a look one year ago when my professor introduced it. It has some very promising features as the above links claims.The most impressive one for me is its mechanism of inter-core commuication. Unfortunately(FORTH advocators may disagree), it seems to require native FORTH programming and manual parallelism among the processor arrary. I wonder whether it's possible to implement a compiler with parallelism capability(coordinate those cores) on it, especially for functional languages. Regards, Mura ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
