Closed scabug closed 13 years ago
scabug
commented
16 years ago Imported From: https://issues.scala-lang.org/browse/SI-1170?orig=1 Reporter: @DRMacIver Attachments:
scabug
commented
16 years ago @DRMacIver said: Err. What an embarrassing mangling of a sentence. "Trunk appears to currently be broken, so I decided to submit these with an astonishingly long compile error message" should of course be "Trunk appears to currently be broken with an astonishingly long compile error message". I tried building without these in the source tree and the error message was still there.
scabug
commented
16 years ago @DRMacIver said: Sorry, I had to make a change to merge it into the source tree and forgot to include that in the files I attached. Here's a corrected version.
scabug
commented
16 years ago Geoffrey Alan Washburn (washburn) said: Can you elaborate on "trunk" being completely broken? Most everything seems to be working for us at the moment.
scabug
commented
16 years ago @DRMacIver said: Sure. See attached log.
scabug
commented
16 years ago Geoffrey Alan Washburn (washburn) said: Okay, I'm not seeing that, and we aren't seeing that in the nightly or commit builds either. Are you sure you're starting from a clean checkout and/or did a complete cleanup ("ant all.clean")? If so, let us know more about your configuration.
scabug
commented
16 years ago @DRMacIver said: Hm. I swear I did a clean when I got it the first time (I definitely didn't before the build log I sent you earlier), but given that cleaning seems to have fixed it I guess I probably didn't. Sorry for the false alarm!
scabug
commented
16 years ago Geoffrey Alan Washburn (washburn) said: I've added these in r15695.
I would like partest to be able to handle tests written in scalacheck (see #609), but there is the issue that it would be adding additional dependencies into trunk. But we should really do something in this area for improving the test coverage of the libraries.
scabug
commented
16 years ago @DRMacIver said: Thanks very much. Hope they prove to be a useful addition. :-)
If you want me to submit some tests for this I can, but they're not going to be as extensive as the test suite I actually run because the idea of trying to port all those tests from ScalaCheck and getting even half as good coverage fills me with dread.
As discussed with Martin, I'm attaching a bunch of additional collections implementations for inclusion in the standard library. Trunk appears to currently be broken, so I decided to submit these with an astonishingly long compile error message, so I'm just submitting these as a bunch of files.
IntMap is a specialised immutable map for integer keys. It's based on "Fast Mergeable Integer Maps" Okasaki and Gill. It stores things in unsigned order and does substantially better than the standard tree map (though doesn't do as well as the hash implementations on individual operations).
LongMap is the same as IntMap but for Long keys.
TreeHashMap is an alternative implementation of immutable hash maps. It has better sharing properties than the standard immutable hash map and isn't synchronised. Its performance seems very dependent on the computer it's running on - on my home desktop it's about a factor of two slower on reads and writes compared to the standard immutable hash map, but does a lot better on bulk operations. On some computers it has been observed being faster than the standard one. I think this is to do with cache sizes and number of cores
ArrayStack is an alternative implementation of a mutable stack, based on an index into a growable array. It should be much faster than the one currently in the standard library.
There was going to be an additional one: a mutable Map implementation based on open hashing, but I discovered some bugs this evening and decided this left me insufficiently confident in the implementation to submit it for this release. I'll try to get it working, tested and ready and submit it as an additional patch at some point, but it won't be in time for 2.7.2.
I have pretty extensive tests for these things, but I'm not really sure how to integrate them into the standard test suite. In particular appropriateness of dependencies, etc. (I use both scalax and scalacheck in my tests, because it's massively convenient to do so, but I don't think you want those as test dependencies?). Let me know what I should do about that.