make Coreen understand Maven projects, but this sort of setup will be always
necessary for projects that use a totally custom build.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2941 6335cc39-0255-0410-8fd6-9bcaacd3b74c
the specified class.
Yeah.
I've had this laying around for a long time, almost embarrassed by it.
But I keep running into places where it'd be handy, and now I'm
going for it.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2940 6335cc39-0255-0410-8fd6-9bcaacd3b74c
version numbers and then puzzle over why things don't work when we try to use
new plugin features and forget to check what version number said feature was
introduced into the plugin and be sure that we're using that version. Yay!
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2925 6335cc39-0255-0410-8fd6-9bcaacd3b74c
so that we're 100% external dependency free no matter how you build us. This is
the path to righteousness that all of our libraries must eventually go down to
save us from the dependency frying pan and put us into the dependency fire.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2924 6335cc39-0255-0410-8fd6-9bcaacd3b74c
clearly more awesome. This is about to precipitate an upgrade from a 10 year
old hacked version of Velocity to a zero year old hacked version of Velocity
which is not going to be pleasant, but is roundabout ten years overdue.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2922 6335cc39-0255-0410-8fd6-9bcaacd3b74c
took a Function for computing weight. That would be more useful to me, usually.
The Map version could be reimplemented fairly easily with that...
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2921 6335cc39-0255-0410-8fd6-9bcaacd3b74c
of pick().
- Iterates once.
- Checks each weight for validity.
- Only generates one random number.
On that last point: huh! I don't think there's anything wrong
with what I've done, and passing a Map with all the values as 1 is
identical to calling the other form of pick on the keySet iterator.
So: maybe I can change the Iterator-based picking and plucking
to only use one random double, like this. In fact, it would make
those methods more optimal in another way: we could stop iteration
as soon as we see the Nth element, where N is (1 / random).
Deprecated getWeighted().
RFC.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2915 6335cc39-0255-0410-8fd6-9bcaacd3b74c
Maybe mdb is using a newer compiler that is behaving correctly,
but my 1.6 freaks out without these.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2910 6335cc39-0255-0410-8fd6-9bcaacd3b74c
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
samskivert