[Haskell] Streams 0.1.7 library announce
Hello haskell, I'm glad to present Streams library version 0.1.7. If you don't yet know, Streams is a fast extensible I/O and serialization library ( http://haskell.org/haskellwiki/Library/Streams ). Main changes against previous version: * true support for GHC 6.6 * support of files larger than 4 gb on windows (see FD5gb.hs example) * files are now open in shared mode on all systems The most dramatic change, though, is that Pupeno <[EMAIL PROTECTED]> has taken a work of polishing, unix testing, packaging and distributing the library, so now it contains: * haddock'ized internal docs * ready to be included in any unix packaging system * semi-automatic self-testing system ;) To get Streams 0.1.7, you can download one of http://pupeno.com/software/streams/Streams-0.1.7.tar.bz2 http://pupeno.com/software/streams/Streams-0.1.7.tar.gz or you can get it from its repository by running: darcs get --tag=0.1.7 http://software.pupeno.com/Streams-0.1 Streams-0.1.7 You can also download and keep track of the 0.1 branch, which is supposed to remain stable and only get bug-fixes by running darcs get http://software.pupeno.com/Streams-0.1/ and then run 'darcs pull' inside it to get further changes. To get the latest unstable and fluctuating version, the development version, run: darcs get http://software.pupeno.com/Streams/ Note: as of this moment, while the project is being darcsified you are not going to find anything useful there, but we expect that to change. Preferably, you should send patches to code to [EMAIL PROTECTED] and to other parts of library to [EMAIL PROTECTED] . Documentation may be edited right at the project homepage, which remains http://haskell.org/haskellwiki/Library/Streams -- Best regards, Bulat mailto:[EMAIL PROTECTED] ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: [Haskell-cafe] SimonPJ and Tim Harris explain STM - video
I would just love to have some Haskell video casts. That would be awesome! Cheers, Johan On 11/23/06, Bayley, Alistair wrote: http://channel9.msdn.com/Showpost.aspx?postid=231495 The links to the video are a couple of yellow buttons at the bottom of the article: "Watch" or "Download". I haven't watched this yet (it's nearly an hour long, I think). Found via reddit (http://reddit.com). Haskeller's on TV (sort of...) woot woot! Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: [Haskell-cafe] SimonPJ and Tim Harris explain STM - video
On Thu, Nov 23, 2006 at 12:56:00PM -, Bayley, Alistair wrote: > http://channel9.msdn.com/Showpost.aspx?postid=231495 > > The links to the video are a couple of yellow buttons at the bottom of > the article: "Watch" or "Download". > > I haven't watched this yet (it's nearly an hour long, I think). Found > via reddit (http://reddit.com). > > Haskeller's on TV (sort of...) woot woot! Does anybody know how to watch this on Linux? I would prefer to simply download the movie file and use MPlayer on that, but I failed. .. or on Mac OS X (haven't tried yet) Best regards Tomasz ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: [Haskell-cafe] SimonPJ and Tim Harris explain STM - video
On 11/24/06, Tomasz Zielonka <[EMAIL PROTECTED]> wrote: On Thu, Nov 23, 2006 at 12:56:00PM -, Bayley, Alistair wrote: > http://channel9.msdn.com/Showpost.aspx?postid=231495 > > The links to the video are a couple of yellow buttons at the bottom of > the article: "Watch" or "Download". > > I haven't watched this yet (it's nearly an hour long, I think). Found > via reddit (http://reddit.com). > > Haskeller's on TV (sort of...) woot woot! Does anybody know how to watch this on Linux? I would prefer to simply download the movie file and use MPlayer on that, but I failed. .. or on Mac OS X (haven't tried yet) Worked for me with mplayer+w32codecs. -- Cheers, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: [Haskell-cafe] SimonPJ and Tim Harris explain STM - video
On Fri, Nov 24, 2006 at 10:31:27AM +0100, Lemmih wrote: > Worked for me with mplayer+w32codecs. Oops! I missed the "Download" link and tried to download through "Watch" ;-) Thanks! Best regards Tomasz ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: base libraries
Simon PJ and I spent some time thinking about this today, and wrote a wiki page. There are several interconnected issues, which makes this hard to discuss on a mailing list. I hope this can evolve into a concrete design for a reorganisation of the packages. Please feel free to edit the wiki, or continue to discuss (individual points one at a time, preferably!) on the list. http://hackage.haskell.org/trac/ghc/wiki/PackageReorg Cheers, Simon ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Library versioning policy
Hello haskell, We all know what is a "DLL hell" - if some program written against version 2.0 of library, then using version 1.0 or 3.0 of the same library when program compiled may call all sorts of devil there is a great solution of this problem - Eternal Compatibility Theory. unfortunately, it's so great that seldom used on practice because it requires significant efforts from library developer i propose another solution for this problem which don't require to write anything and just impose some policies both for library developer and user library developer should just explicitly declare and obey some policy of incrementing library versions which will allow library user to select proper range of versions which are guaranteed to work with his code. i propose the following as standard policy: * major version change (2.2->3.0) means total incompatibility. all sorts of changes may come * middle version change (2.1.3->2.2) means addition of new facilities (functions, constructors, classes...). in most cases, such semi-compatible version can be used if that's done with caution * minor change (2.1.1->2.1.2) means only internal changes and bugfixes other policies may be used as well, library developer should just declare his policy at the library birth and use it consistently this will allow library users to declare in their cabal files range of library versions they are accepted and be sure that this range will include latest bugfixes but don't include any incompatible changes. then Cabal (which now can handle many versions of the same lib) should select latest acceptable version of library requested and make it available for compilation say, if i wrote my program using Streams 1.2.1, i can specify Build-Depends: Streams 1.2.* or, if i brave/accurate enough: Build-Depends: Streams 1.* and Cabal should select the best library available at build time -- Best regards, Bulat mailto:[EMAIL PROTECTED] ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: QuickCheck 2 development version
This is just a quick announcement that the development version of QuickCheck 2 is now available in a public darcs repository. Some highlights: - Shrinks failing test cases. - Supports testing monadic code. - Handles exceptions gracefully. - coarbitrary has moved to a separate class, to make it easier to write simple instances of Arbitrary. - Type-level modifiers for changing test data generation (e.g. NonNegative). - Magic function table printing. - User-defined actions when properties fail. You can get it with: darcs get http://www.cs.chalmers.se/~bringert/darcs/QuickCheck/ This is a development version, and the API is not necessarily stable yet. It uses the same module names as QuickCheck 1, Test.QuickCheck.*, but it breaks backwards compatibility in many cases. Use explicit package versioning if you need to use it alongside QuickCheck 1. You can build the code and API documentation with Cabal, see README for instructions. Happy hacking! Koen & Björn ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re[2]: base libraries
Hello Simon, Friday, November 24, 2006, 1:58:36 PM, you wrote: > There are several interconnected issues, which makes this hard to discuss > on > a mailing list. i hardly imagine how it can be discussed on wiki :) >http://hackage.haskell.org/trac/ghc/wiki/PackageReorg thanks, it's much closer to my POV. still some problems exists. first, this proposal don't realize problems with upgrading libraries used by Cabal itself. is it possible to have, say, base 2.0 and 2.1 installed side-by-side and make Cabal import just base 2.0 against which it was written? second, rules for ghc-specific libs pops up as some modification of initial rules, it will be better to include them in general rules themselves. third, this don't split core libs into the pre-installed and installed by package manager. so, my updated proposal: Now Haskell standard libraries (as specified in H98 Report) are very small and old-fashioned, it's impossible to develop real programs using this API. In order to facilitate Haskell-based development, we need a much wider, not-fixed set of libs which are guaranteed to be available with every Haskell compiler. libraries should be split into 4 rings: frozen, core, base and the rest * frozen libs are installed with haskell compiler and cannot be upgraded using Cabal. it includes Cabal itself and libraries required by Cabal, currently it's the Base library. compiler may provide its own ways to upgrade these libs * core libs are tied closely to specific compiler and version. therefore, these are also preinstalled but can be upgraded with Cabal. in order to make upgrading not-a-headache, version of such library must include compiler version, i.e. TH 6.6.0. for ghc these currently includes TH and STM libs * base libs are *guaranteed* to be shipped with any haskell compiler (compliant with this proposal). these libs are installed using Cabal or OS package manager, only on poor Windows-like systems these should be included in monolithic compiler distro. the reason is to allow user to got latest, bug-fixed versions of these libraries for the installation moment these libs should include rich set of functionality. criteria of inclusion library in this set are: widely used, small and portable. Portability: these libs should work on windows and major unix branches, on ghc/hugs/nhc and other proposal-compliant compilers, otherwise we can't guarantee availability everywhere. It should be easy for porters to prepare such lib for their systems Widely used: this should include data structures, general data processing, other things that facilitates development in general as opposite to solve some particular problem. plus basic OS interfaces. haskell98, readline, unix/Win32, QuickCheck, fgl, haskell-src, html, mtl, network, parsec, time, xhtml, ByteString, regex-*, Edison, Filepath, MissingH, NewBinary, arrows, HUnit, QuickCheck, monads it should be great also to strip down size of HaXml lib and include it here. now it don't conform only to size criterion * there are also other great libs that are either too fat or os/compiler specific, such as gui and database ones. these can be included in some distros or downloaded and installed separately using Cabal infrastructure there are also a number of Cabal-specific problems we should solve: 1) libraries required by setup scripts (Setup.hs) should be specified as dependencies in .cabal file: Build-Depends: FilePath this way, the library will be installed just before running Setup script. of course, all the Build-Depends libs should be made available for setup script 2) cabal, cabal-get and other package management tools should use only libraries from frozen set. any extra functionality required (networking, file management...) should be *copied* into these packages. this just means handmade instead of automatic dependencies tracking, but we can't rely on automatic management for tools that implement this management! (this proposal don't include some topics, like testing and Hugs, where i can't say anything new compared to Simon's page) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: [Haskell-cafe] SimonPJ and Tim Harris explain STM - video
On Fri, Nov 24, 2006 at 10:26:38AM +0100, Tomasz Zielonka wrote: > Does anybody know how to watch this on Linux? I would prefer to simply > download the movie file and use MPlayer on that, but I failed. > > . or on Mac OS X (haven't tried yet) The latest mplayer works for me on FreeBSD/amd64 (1.0rc1, iirc). ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: [Haskell-cafe] SimonPJ and Tim Harris explain STM - video
Hi, I got this working on Mac OS X. I had to download media player 9: http://www.microsoft.com/windows/windowsmedia/software/Macintosh/osx/default.aspx This contains the WMV3 codec. Cheers, Chris. On Fri, 24 Nov 2006, James William Pye wrote: > On Fri, Nov 24, 2006 at 10:26:38AM +0100, Tomasz Zielonka wrote: > > Does anybody know how to watch this on Linux? I would prefer to simply > > download the movie file and use MPlayer on that, but I failed. > > > > . or on Mac OS X (haven't tried yet) > > The latest mplayer works for me on FreeBSD/amd64 (1.0rc1, iirc). > ___ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re[2]: base libraries
Am Freitag, 24. November 2006 15:42 schrieb Bulat Ziganshin: > [...] > libraries should be split into 4 rings: frozen, core, base and the rest That's one possibility, but not the only one. Especially I don't see the need to distinguish between "frozen" and "core". > [...] > these libs should include rich set of functionality. criteria of > inclusion library in this set are: widely used, small and portable. While "portable" (in the sense of: "runs on a gives set of Haskell implementations/platforms") is a good criterion, the other ones might need some discussion: How can somebody determine if a package is "widely used"? If there was a reliable way to figure this out, I would probably keep it for myself and make millions of dollars in the marketing industry... And "small" is not a criterion at all. Is Boost small? No. Is java.io.* or java.util.* small? No. Etc. etc. > [...] > haskell98, readline, unix/Win32, QuickCheck, fgl, haskell-src, html, > mtl, network, parsec, time, xhtml, > ByteString, regex-*, Edison, Filepath, MissingH, NewBinary, arrows, > HUnit, QuickCheck, monads This is a completely random selection of packages based on personal preferences. I could give my personal favourites, which would not have a large intersection with the set above, but this would lead us nowhere. So the meta-question is: How will we determine which packages are worty enough to be "base" packages? > [...] > 2) cabal, cabal-get and other package management tools should use only > libraries from frozen set. any extra functionality required > (networking, file management...) should be *copied* into these > packages. this just means handmade instead of automatic dependencies > tracking, but we can't rely on automatic management for tools that > implement this management! Uh, oh, copying... :-P Redundancy is the source of all evil! If we step back a little bit, we can see that there is no intrinsic need that those tools are even written in Haskell, even less need that libraries needed to build those tools are available on non-developer installations. If e.g. cabal-get is a statically linked application, nobody is forced to install any networking/crypto/... packages. The situation here is quite similar to the (mostly) statically linked commands in /bin on most *nices. Cheers, S. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re[2]: base libraries
On Fri, 2006-11-24 at 17:42 +0300, Bulat Ziganshin wrote: > libraries should be split into 4 rings: frozen, core, base and the rest > > * frozen libs are installed with haskell compiler and cannot be > upgraded using Cabal. it includes Cabal itself and libraries required > by Cabal, currently it's the Base library. compiler may provide its > own ways to upgrade these libs Cabal can be upgraded using Cabal. This is important. Unlike well specified libraries like ByteString, Cabal tackles an ill-specified problem and we're still learning how best to solve it, so the api and features change much more frequently. Duncan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: QuickCheck 2 development version
在 Nov 24, 2006 9:29 PM 時，Björn Bringert 寫到： This is just a quick announcement that the development version of QuickCheck 2 is now available in a public darcs repository. Some highlights: - Shrinks failing test cases. - Supports testing monadic code. Wonderful. Many thanks for QC2! :-) By the way, since Positive is a type synonym, the StrictlyMonotonicFunction instance should perhaps be: instance Arbitrary StrictlyMonotonicFunction where arbitrary = StrictlyMonotonic `fmap` arbMonotonicFunction (\ (NonZero (NonNegative x)) -> x) instead of: instance Arbitrary StrictlyMonotonicFunction where arbitrary = StrictlyMonotonic `fmap` arbMonotonicFunction (\ (Positive x) -> x) Thanks, Audrey___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: QuickCheck 2 development version
On 24 nov 2006, at 22.04, Audrey Tang wrote: 在 Nov 24, 2006 9:29 PM 時，Björn Bringert 寫到： This is just a quick announcement that the development version of QuickCheck 2 is now available in a public darcs repository. Some highlights: - Shrinks failing test cases. - Supports testing monadic code. Wonderful. Many thanks for QC2! :-) Thank Koen. By the way, since Positive is a type synonym, the StrictlyMonotonicFunction instance should perhaps be: instance Arbitrary StrictlyMonotonicFunction where arbitrary = StrictlyMonotonic `fmap` arbMonotonicFunction (\ (NonZero (NonNegative x)) -> x) instead of: instance Arbitrary StrictlyMonotonicFunction where arbitrary = StrictlyMonotonic `fmap` arbMonotonicFunction (\ (Positive x) -> x) Oops, thanks. How did I manage to push the change to Positive without building? Now let's move any discussion about my silly mistakes off this list. /Björn___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
