requirement 安装 protobuf, 经测试2.6版本的可以,3.0暂时还没有正式版。 可以修改project/pom.xml里面的protobuf.version 由2.5.0改成2.6.0, 于3.0暂时还没有正式版, 所以暂时还不行, 会报错protoc version is ‘libprotoc 3.0.0’, expected version is ‘2.5.0’ mvn package -Pdist -Ptar -Pdocs -skipTests
1 2 3 4 5 6 7
cd hadoop-mapreduce-project export Platform=x64 mvn clean installassembly:assembly -Pnative ## Issue the following command instead (while still being in the hadoop-mapreduce-project folder: mvn package -Pdist,native -DskipTests=true -Dtar cd .. # move back to top-level folder mvn package -Pdist,native -DskipTests=true -Dtar
PECS (short for"Producer extends and Consumer super") can be explained by : GetandPutPrinciple GetAndPutPrinciple (FromJavaGenericsandCollections)
It states,
use an extends wildcard when you only get values outof a structure use a super wildcard when you only put values into a structure and don’t use a wildcard when you both get and put.
Since, count() method uses super, all of the following calls are legal: The last two calls would not be legal if super was not used.
EXCEPTION : you cannot get anything outfrom a type declared with a super wildcard—exceptfor a value oftypeObject, which is a supertype of every reference type:
Whenever you both put values into and get values outof the same structure, you should not use a wildcard.
public static double sumCount(Collection<Number> nums, int n) { count(nums, n); return sum(nums); }
“PECS” is from the collection’s point of view. If you are only pulling items from a generic collection, it is a producer and you should use extends; if you are only stuffing items in, it is a consumer and you should use super. If you do both with the same collection, you shouldn’t use either extends or super.
Suppose you have a method that takes as its parameter a collection of things, but you want it to be more flexible than just accepting a Collection.
Case 1: You want to go through the collection and do things with each item. Then the list is a producer, so you should use a Collection<? extends Thing>.
The reasoning is that a Collection<? extends Thing> could hold any subtype of Thing, and thus each element will behave as a Thing when you perform your operation. (You actually cannot add anything to a Collection<? extends Thing>, because you cannot know at runtime which specific subtype of Thing the collection holds.)
Case 2: You want to add things to the collection. Then the list is a consumer, so you should use a Collection<? super Thing>.
The reasoning here is that unlike Collection<? extends Thing>, Collection<? super Thing> can always hold a Thing no matter what the actual parameterized type is. Here you don’t care what is already in the list as long as it will allow a Thing to be added; this is what ? super Thing guarantees.
I’m always trying to think about it this way: A producer is allowed to produce something more specific, hence extends, a consumer is allowed to accept something more general, hence super. – Feuermurmel May 7 ‘13 at 13:11
Another way to remember the producer/consumer distinction is to think of a method signature. If you have a method doSomethingWithList(List list), you are consuming the list and so will need covariance / extends (or an invariant List). On the other hand if your method is List doSomethingProvidingList, then you are producing the List and will need contravariance / super (or an invariant List). – Raman Jan 24 ‘14 at 19:20
gtk3agg: no [Requires pygobject to be installed.] gtk3cairo: no [Requires cairocffi or pycairo to be installed.] gtkagg: no [Requires pygtk] tkagg: no [The C/C++ header for Tk (tk.h) could not be found. You may need to install the development package.] wxagg: no [requires wxPython] gtk: no [Requires pygtk] agg: yes [installing] cairo: no [cairocffi or pycairo not found] windowing: yes [installing, installing]
OPTIONAL LATEX DEPENDENCIES dvipng: no ghostscript: no latex: no pdftops: no
OPTIONAL PACKAGE DATA dlls: no [skipping due to configuration]