- Libraries - Haskell.org

Re: New bug tracker: Trac
by Jean-Philippe Bernardy 16 Jan '06

16 Jan '06

Hello, I'd wish to use Trac to manage my work on the libraries, though I can't find a subproject or something dedicated to the base package. Are there plans/policies regarding usage of Trac for libraries ? Cheers, JP. On 12/6/05, Simon Marlow <simonmar(a)microsoft.com> wrote: > Hi Folks, > > We've been meaning to switch bug trackers for some time, and yesterday I > finally got annoyed enough with SourceForge to do something about it. > I've imported all our SourceForge tracker data into a new Trac > installation: > > http://cvs.haskell.org/trac/ghc > > Not only do we get a faster and more flexible bug tracker, but we also > get online browsing of the darcs repository (well, for some reason it > isn't working right now, but I hope to get it fixed). Also the Trac > wiki will be a good place to put the User Guide annotations that we've > been talking about. > > The bug tracker is set up to mail glasgow-haskell-bugs(a)haskell.org with > any and all ticket modifications at the moment; if you're on that list, > there will probably be an increased volume of mail as we'll be making > more use of the bug tracker than before. My feeling is that we don't > need to create a new mailing list for this, but by all means speak up if > you disagree. > > The wiki is currently closed because I don't want to have to deal with > spam. Use HaWiki for now. > > Developers with an account on cvs.haskell.org: please add yourselves as > users on the Trac, so I can give out permissions to edit tickets. You > create a user like this: > > - log in to cvs.haskell.org > - htpasswd /srv/trac/ghc/trac.htpasswd <username> > - type your password when prompted > - let me know when you've done this > > Cheers, > Simon > _______________________________________________ > Cvs-ghc mailing list > Cvs-ghc(a)haskell.org > http://www.haskell.org/mailman/listinfo/cvs-ghc >

2 1

Idea to allow people to comment on Haskell docs
by Duncan Coutts 16 Jan '06

16 Jan '06

All, People were taking recently about how to make it easier for people to contribute to the official documentation. Well here's a suggestion: We have the Haddock-generated pages link to a wiki. Each module would link to one page of a wiki. On that wiki page people could add their extended documentation, notes, example code snippets, pitfalls etc. The PHP online docs have a similar (albeit more integrated) solution where each module has user-contributed notes at the end of each page. For example here's the documentation for the PHP array module: http://www.php.net/manual/en/ref.array.php Actually having a wiki might be better than the PHP solution where they have a series of attributed contributions since with a wiki an 'editor' can re-arrange the notes to improve the organisation. The nice thing about most wikis is that if you link to a page that doesn't yet exist then it can be created. So the wiki does not even need to be prepared before the docs get pointed at it. The first person to add notes for a module will just create the corresponding wiki page. So we'd want to patch haddock to generate the links (controlled by an extra flag I guess). So I expect that there should be at least a top level link to the corresponding wiki page. How about links for each documented entity (eg functions)? That could generate links with anchors #functionName. If there were no such anchor then the browser just defaults to the top of the page which is ok. How would we put the wiki links in for each documented entity? How about a little [wiki] icon (with a suitable mouse-over descriptive text) in the right margin of the name. eg: rawSystem :: String -> [String] -> IO ExitCode [wiki] The computation ... Other suggestions? Just use a top level per-module wiki link? Duncan

4 4

Map for FGL
by Christian Maeder 16 Jan '06

16 Jan '06

Hi, I wonder how well http://www.haskell.org/ghc/docs/latest/html/libraries/fgl/Data-Graph-Induct… performs wrt. other Map implementations. It may be worth replacing this implementation, too. Cheers Christian

2 5

What's the current bug report procedure?
by Seth Kurtzberg 16 Jan '06

16 Jan '06

All, I have a (minor) but to report in the networking (Network and Network.Socket) libraries. If the /etc/protocols file is missing, an error message is printed saying that a service could not be found. This occurs even when no service is involved (the port number is specified explicitly using the constructor PortNumber). I'm aware that the procedure changed; can you point me at the right place to report this and/or the right people/bug tracker/whatever? Thanks, Seth Kurtzberg

1 0

please send your cabal bug reports, wishlist, and patches!
by Isaac Jones 16 Jan '06

16 Jan '06

Greetings, I'm trying hard to get a better hold on the Cabal[1] project, and a more clear idea of all the outstanding work that needs to be done. I've gone through my mailbox to dig up stuff like this, but no doubt some has slipped between the cracks. I started a bug tracker / wiki a few weeks ago, and would like your help to make sure that it reflects _all_ of the work that needs to be done in Cabal. If you've sent me a feature request or bug report that hasn't been added to Cabal, can you please check if it is on the wiki, and if not, create a "ticket" (bug report) for it: Cabal Wiki & Bug Tracker: http://hackage.haskell.org/trac/hackage/ If you're not sure, or don't want to use the bug tracker, just email me. This bug tracker is a great place to make more complex feature requests, as it has full wiki markup. See this ticket for a nice example: http://hackage.haskell.org/trac/hackage/ticket/27 Also, if you've sent me any patches that are not yet applied, please re-send them to me. peace, isaac [1] http://www.haskell.org/cabal

1 0

simplifying user hooks (non-backward-compatible)
by Isaac Jones 16 Jan '06

16 Jan '06

Andres Loeh proposed simplifying the hooks interface now that they've grown to include not only pre-and-post hooks, but also er, "during" hooks too. That is, all of the actions are hooks now (preConf, confHooks, postConf). http://hackage.haskell.org/cgi-bin/trac/trac.cgi/ticket/23 So we could now get rid of the pre and post hooks, as long as the user could call to the default hooks thusly: myHooks = defaultUserHooks { confHook = myConf } myConf pd cf = do myPreConf lbi <- confHook defaultUserHooks myPostConf pd cf lbi (for suitable myPreConf and myPostConf functions) This would greatly simplify the Distribution.Simple.UserHooks structure bringing it from 34 fields to 14 fields, or so. Downsides: Making pre and post hooks would now be slightly harder, and it would break existing hooks-using code. I like it. What are your feelings? peace, isaac

2 6

using cabal? add your package to the list!
by Isaac Jones 15 Jan '06

15 Jan '06

I started a list of packages using cabal (including those uplaoded to Hackage). Please either upload your packages to hackage, or add it here. I want this list so that I can try to figure out things like how much a given modification to Cabal will break stuff: http://hackage.haskell.org/trac/hackage/wiki/CabalPackages To add your package to the list, hit "Edit Page" at the bottom of the page. Feel free to make the page into a table, add links for the packages already there, reorganize, etc. peace, isaac

1 0

Cabal compatibility redeux
by Robert Dockins 09 Jan '06

09 Jan '06

I'd just like to reseruct the conversation from here (http://www.haskell.org//pipermail/libraries/2005-December/004692.html) for a quick moment if I might. At the time I wrote: >>>> This would greatly simplify the Distribution.Simple.UserHooks >>>> structure bringing it from 34 fields to 14 fields, or so. >>>> >>>> Downsides: Making pre and post hooks would now be slightly harder, and >>>> it would break existing hooks-using code. >>> >>> I just want to mention that these kind of changes represent represent a >>> VERY big problem. I discussed that issue at some length in an email I >>> intended to send to this list very recently, but it seems to have gotten >>> lost. >> >> Are you sure they represent a very big problem in practice and not >> just in theory? > > [snip] > > Well, obviously it isn't a practical problem yet. If it was we'd have > people screaming about it on the lists. I would now like to add to the theoretical arguments I made then the evidence that the HSQL driver package for MySQL uses the user hooks of Cabal and I have just experienced a case of Cabal version skew breaking a build system, because this package will not build for me using Cabal 1.1.3. I am unsure at the moment if this is because my Cabal is too new or too old, and I now face the prospect of 1) hacking on the build system to match my cabal, 2) trying random cabal upgrades/downgrades or 3) pinging the package maintainers to figure out how to build this package. Rob Dockins

2 1

Re: Left-bias and non-structural equality.
by Jean-Philippe Bernardy 08 Jan '06

08 Jan '06

On 1/8/06, Adrian Hey <ahey(a)iee.org> wrote: > On thing that occurred to me was that calling the AVL tree based sets > "Set" might be the wrong thing to do anyway. If we want to allow for > future implementations to be based on other data structures then we > probably shouldn't usurp the name "Set", but rather call it SetAVL or > something. (To allow a consistent naming scheme to be used if someone > ever produces SetRedBlack say). Both SetAVL and SetRedBlack would > be instances of the "Set" type constructor class (presumably). > > So maybe the thing to do would be to keep Data.Set (with biasing specified) > for the present, but just put a pointer there in the Haddock to a new > module Data.SetAVL (which does not specify biasing). This scheme would > also allow the current Set implementation to be retained if it turns > out to have some advantages over AVL (seems a bit rash to discard it > completely anyway), but it would be called Data.SetAdams (or something..) As I was writing to Adrian this morning, that's exactly what I am proposing. :) To clarify things, I've put up some more explanations on the wiki: http://haskell.org/hawiki/StandardCollectionLibraries Cheers, JP.

2 1

Left-bias and non-structural equality.
by Jean-Philippe Bernardy 08 Jan '06

08 Jan '06

On 1/2/06, Adrian Hey <ahey(a)iee.org> wrote: > On Sunday 01 Jan 2006 3:28 pm, Jean-Philippe Bernardy wrote: > > Yes, union suffers from the same problem; both in Set and Map as well. > > The testing code can now detect problems of left-biasing in presence > > of non-structural equality. (That's what I wanted to implement before > > applying the fix). > > Actually I was wondering whether or not the term "left-biasing" was > particularly useful. It could be misleading for some functions. > > For example.. > -- | /O(n*log n)/. Create a set from a list of elements. > fromList :: Ord a => [a] -> Set a > fromList xs = foldlStrict ins empty xs > where ins t x = insert x t > > My interpretation of left biasing would be that if the input list contains > multiple occurences of "equal" values then the first occurence is the one > which is inserted in the Set and the rest are discarded. But AFAICS the > this is not the case with the current Data.Set implementation (or with the > clone I just produced). Both are right biased (at least according to my > intuitive understanding of the term). There is a "definition" of left-bias here: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Set.html -- Note that the implementation is /left-biased/ -- the elements of a -- first argument are always perferred to the second, for example in -- 'union' or 'insert'. Of course, left-biasing can only be observed -- when equality is an equivalence relation instead of structural -- equality. ...which says nothing about biasing inside a list. > BTW, I think I would prefer the default behaviour of insert > to be to retain existing elements because this allows the > optimisation of not updating the data structure representing > the set at all (which should help keep heap burn rate down). > But I guess this is in effect assuming equality implies > structural equality so others may not like it. Sigh... The biggest problem with this is that Map.insert changes the value corresponding to the inserted key inside the map, and since it is observable even with structural equality, you can be certain that quite some people rely on that behaviour. Making Set do the opposite is rather counter-intuitive. In summary, left-biasing is important even in with well-behaved equality, in the case of Maps. > <whine> > I really wish this whole issue of how to properly deal with "things > that are equal but may still be different somehow" would just go > away :-) It's hard to be precise about what choice you've made, and > whatever choice you do make usually seems arbitrary. Even when > it doesn't make any semantic difference, the choice you make may > well have an observable effect on space and time behavior. > </whine> I really wish it too. BTW, the fact that Map and Sets had many problems with non-structural equality and biasing is quite revealing that this is not such a big problem in practice. (For the record I had to fix union and intersection in Set, and union*, intersection*, differenceWith* and insertWith* in Map) Non structural equality seemed not to have many proponents the last time I discussed it. (See http://www.haskell.org//pipermail/libraries/2004-March/001833.html and following messages) Yet, since haskell doesn't rule it out, I guess we have to provide a consitent behaviour, if only to minimize the user's suprise. On the other hand, I wish to deprecate all functions that implicitly promote non-structural Equality, in order not to lead the unsuspecting user to a dangerous path. Interestingly enough, this brings us back to the origin of this thread, namely insertWithKey. Changing it to follow the left-bias rule, it now doesn't depend on the keys present in the map; and hence becomes deprecated, for the reason David mentioned. Cheers, JP.

6 20