constants up from the logger impl and back down, so we'll just use Object and
do the casting manually.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2905 6335cc39-0255-0410-8fd6-9bcaacd3b74c
- Instead of duplicating every method twice, once allowing you to specify
your own Random object, there is a static thread-safe sharable instance
that anyone can use, and a factory method to create your own instance
with a supplied Random.
- The goofy methods for picking an element from a collection but skipping
a particular value, or picking from an iterator but providing a count,
are gone.
- Instead there are two methods: pick and pluck, for picking an element
or picking and removing an element. For Iterator, only pick is available.
Optimized code paths are provided for Lists and Collections, but the API
is kept simple.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2901 6335cc39-0255-0410-8fd6-9bcaacd3b74c
adding a function type to samskivert because everyone and their mother has a
function type. This is hopefully innocuous enough and allows you to obtain
generality at the expense of verbosity:
Folds.foldLeft(new Folds.R<Integer>() {
public Integer apply (Integer zero, Integer elem) {
return Math.max(zero, elem);
}
}, 0, values);
Folds.foldLeft(new Folds.R<String>() {
public String apply (String zero, String elem) {
return zero + elem;
}
}, "", strings);
Maybe by Java 8 or 9 we'll have closures and this can become:
Folds.foldLeft((Integer b, Integer a) => Math.max(b, a))
Folds.foldLeft((String b, String a) => b + a)
or maybe:
Folds.foldLeft(#(Integer b, Integer a) { return Math.max(b, a); })
Folds.foldLeft(#(String b, String a) { return b + a; })
who knows where the syntax bike shed arguments will end up. Of course, that'll
probably hit the shelves around 2015 or so at the rate Oracle seems to be
proceeding.
If you really want to get jiggy with the functional programming, you can check
out Functional Java, which goes the whole nine yards, but sort of ignores Java's
standard collections in the process which kind of sucks:
http://functionaljava.org/
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2896 6335cc39-0255-0410-8fd6-9bcaacd3b74c
so wants to be using Scala. For example, in Java:
Folds.sum(0, values)
where values must implement Iterable and all you get is sum. In Scala:
scala> Array(1, 2, 3).getClass // a real array
res1: java.lang.Class[_] = class [I
scala> Array(1, 2, 3).sum
res2: Int = 6
scala> Vector(1, 2, 3).sum // more like ArrayList
res3: Int = 6
scala> Map(1 -> 2, 3 -> 4).keysIterator.sum // even works on Iterator
res4: Int = 4
and you can do arbitrary folds just as easily:
scala> Array(1, 2, 3).reduceLeft(math.max)
res5: Int = 3
scala> Array(2, 3, 4).reduceLeft(_*_)
res6: Int = 24
Want to specify the type of the result? Can do:
scala> Array(1, 2, 3).foldLeft(0L)(_+_)
res7: Long = 6
Have a list of maps you need to merge? No problem:
scala> List(Map(1 -> 2), Map(2 -> 3), Map(3 -> 4)).reduceLeft(_++_)
res8: scala.collection.immutable.Map[Int,Int] = Map((1,2), (2,3), (3,4))
Functional programming truly does start with fun!
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2895 6335cc39-0255-0410-8fd6-9bcaacd3b74c
abstraction, and inlining of LogBuilder code into doLog() so that odd trailing
log arguments can be included without borking our ability to also include a
Throwable as the final argument.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2894 6335cc39-0255-0410-8fd6-9bcaacd3b74c
The Loggers don't strip out the Exception if it's the last
element, so they actually *depend* on this ignoring the last odd element.
Revert my last change until I figure some reasonable compromise out.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2892 6335cc39-0255-0410-8fd6-9bcaacd3b74c
into the starter collection using addAll. Certain Collections, like
guava's Multiset have optimized addAll() methods that recognize
other Multisets.
There is also a putAll() equivalent for Maps.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2891 6335cc39-0255-0410-8fd6-9bcaacd3b74c
And SVN is being super pokey so I'm swimming against molasses and
that wasn't showing yet. Argh.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2889 6335cc39-0255-0410-8fd6-9bcaacd3b74c
If someone wants to use StringUtil.toString(), let them get
the openBox/closeBox/separators they were expected.
Gee, I hope r2885 didn't beak any Log parsing code...
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2886 6335cc39-0255-0410-8fd6-9bcaacd3b74c
This is an incomplete fix and brings up a larger issue that I'll explain
below. Also, this breaks the customization of openBox/closeBox/separator
Strings.
First off, I know of no Collection that doesn't have a decent toString()
implementation. The java.util.Abstract* classes all do something
reasonable and most Collections are built from those.
Guava's Multiset has a defined way of representing itself as a String.
An example would be "[value1, value2 x 100]". This fix is mainly
addressed at fixing that, as this class would do the very dumb thing
if provided with a Multiset.
Do we really customize the openBox/closeBox/separator values? Should we?
The second issue comes from the way Log uses StringUtil to evaluate
the var-args it is passed. Check out the following code.
Iterator<Thing> it = Iterables.concat(_staticThings, newThings).iterator();
log.debug("About to iterate", "user", user, "request", req, "iterator", it);
while (it.hasNext()) {
...
If the logging level is above debug, this works fine. However if one day
you lower your logging level, the message will be logged and the Iterator
will be passed to String.toString(), which will suck all the elements out of it.
That's a problem.
Actually, perhaps the right thing to do is simply to change the Log class
to avoid using this, and instead just call String.valueOf() on all objects
except arrays, which can instead be String'd with the methods added to
java.util.Arrays in 1.5.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2884 6335cc39-0255-0410-8fd6-9bcaacd3b74c
things, which ended up being infeasible. But I'll leave this test machinery
here as it may be useful in the future if we want to add more
com.samskivert.jdcb unit tests.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2880 6335cc39-0255-0410-8fd6-9bcaacd3b74c
line count of the build.xml file, but I suppose that's just because XML is
absurdly verbose (and Maven annoyingly chose to do things like
<quiet>true</quiet> instead of a quiet="true" attribute). I wonder if there's a
Maven plugin that allows you to specify your pom.xml in YAML or some less
verbose format and which automatically converts it to XML. That'd probably cut
the line count by 2/3.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2853 6335cc39-0255-0410-8fd6-9bcaacd3b74c
standard Maven layout.
I'm not a huge fan of that separation, particularly now that it's de rigueur to
ship your sources with your class files. In such circumstances, one could
imagine just copying the entire contents of src/main/java into target/classes
and being done with it. Class files, XML files, propert files, etc. are all
packaged up together into one happy jar file of goodness. Then you don't have
extra files off in src/main/resources being demure and hard to notice.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2849 6335cc39-0255-0410-8fd6-9bcaacd3b74c
our tests pass even when we haven't run them before. We were relying on
sub.sub3 having been set and persisted from a previous test invocation.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2848 6335cc39-0255-0410-8fd6-9bcaacd3b74c
to put your source and test source code for Java projects. I'm going to toe the
line here because I want to use SBT to publish samskivert to the centralized
Maven repositories.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2807 6335cc39-0255-0410-8fd6-9bcaacd3b74c
room to spare, per the spec.
- Document that we do not support null elements.
- Increment modCount in our modifying methods, to take advantage of
fail-fast iterators.
- A few small comments.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2805 6335cc39-0255-0410-8fd6-9bcaacd3b74c
the memory benefits of ArrayIntSet and better performance than a
HashSet<Integer> (presumably because of less boxing and better spatial
locality). The downside is that you need to pick a sentinel value that can't
be stored in the set, but that's not a problem in any application for which
I've ever used an IntSet. In some (admittedly simplistic) Google Caliper
testing, HashIntSet was 22% faster than ArrayIntSet and 73% faster than
HashSet for arrays of size N=10, 100% faster than ArrayIntSet and 69% faster
than HashSet for N=100, and 357% faster than ArrayIntSet and 74% faster than
HashSet for N=1000.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2801 6335cc39-0255-0410-8fd6-9bcaacd3b74c
I haven't deprecated our version in CollectionUtil because it
copes with being passed a null array...
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2799 6335cc39-0255-0410-8fd6-9bcaacd3b74c
karma@deadmoose.com