Re: Let's do 0.1

[Isabel Drost]

On Friday 23 January 2009, Grant Ingersoll wrote:
> On Jan 20, 2009, at 5:06 PM, Sean Owen wrote:
> > "0.1" does not need to be nearly perfect; I think we're definitely
> > past the 0.1 state. Whatever we have, just pack it up and release it.
> > It's OK if the structure changes later.

+1 from me as well


-- 
Fill what's empty, empty what's full, scratch where it itches.  -- 
Alice 
Roosevelt Longworth
  |\  _,,,---,,_   Web:   
  /,`.-'`'-.  ;-;;,_
 |,4-  ) )-,_..;\ (  `'-'
'---''(_/--'  `-'\_) (fL)  IM:  


signature.asc
Description: This is a digitally signed message part.

RE: RE: RE: [jira] Commented: (MAHOUT-19) Hierarchial clusterer

[Goel, Ankur]

Thanks Sean, I will try this one out on my dataset and keep the list
posted on how well it worked.

Regards
-Ankur

-Original Message-
From: Sean Owen [mailto:sro...@gmail.com] 
Sent: Friday, January 23, 2009 5:55 AM
To: mahout-dev@lucene.apache.org
Subject: Re: RE: RE: [jira] Commented: (MAHOUT-19) Hierarchial clusterer

Here's a DataModel you could try out for your purposes; the rest
should be as I described earlier.


package org.apache.mahout.cf.taste.example;

import org.apache.mahout.cf.taste.impl.model.file.FileDataModel;
import org.apache.mahout.cf.taste.impl.model.GenericPreference;
import org.apache.mahout.cf.taste.impl.model.BooleanPrefUser;
import org.apache.mahout.cf.taste.impl.common.FastSet;
import org.apache.mahout.cf.taste.model.Preference;
import org.apache.mahout.cf.taste.model.Item;
import org.apache.mahout.cf.taste.model.User;

import java.io.File;
import java.io.IOException;
import java.util.List;
import java.util.Map;
import java.util.ArrayList;

public final class AnkursDataModel extends FileDataModel {

  public AnkursDataModel(File ratingsFile) throws IOException {
super(ratingsFile);
  }

  @Override
  protected void processLine(String line, Map> data, Map itemCache) {
String[] tokens = line.split("\t");
String userID = tokens[0];
List prefs = new ArrayList(tokens.length -
1);
for (int tokenNum = 1; tokenNum < tokens.length; tokenNum++) {
  String itemID = tokens[tokenNum];
  Item item = itemCache.get(itemID);
  if (item == null) {
item = buildItem(itemID);
itemCache.put(itemID, item);
  }
  prefs.add(new GenericPreference(null, item, 1.0));
  // this is a little ugly but makes it easy to reuse
FileDataModel -- pref values are tossed below
}
data.put(userID, prefs);
  }

  @Override
  protected User buildUser(String id, List prefs) {
FastSet itemIDs = new FastSet();
for (Preference pref : prefs) {
  itemIDs.add(pref.getItem().getID());
}
return new BooleanPrefUser(id, itemIDs);
  }
}



On Wed, Jan 21, 2009 at 7:57 AM, Goel, Ankur 
wrote:
> The input data format is typically
> User-id \t item-id \t (other information)
>
> From here it can transformed into either of the formats as they are
just
> 1 map-red away. After transformation the input data set will contain
> lines only in 1 format and not both. The data format that I use has
each
> line of the form
>
> User-id \t (Item-id1:other_info) \t ((Item-id1:other_info))...
>
> As for co-occurrence counting the way Ted mentioned, I implemented a
> map-red implementation for the same and I have found it to be pretty
> efficient, simple and effective too.
>
> Couple of tricks like only keeping top-X co-occurred items for an item
> by count and emitting only those item pairs that match a certain
> criteria have worked very well.
>
> I would like to contribute it to Mahout and filed a JIRA for the same
> https://issues.apache.org/jira/browse/MAHOUT-103
>
> I will have a patch coming soon.
>
> What I am looking for is a complimentary technique that does not
depend
> so much on co-occurrences and tries to do some sort of latent variable
> analysis to answer my query.
>
> Thanks
> -Ankur

Re: Re : @Override annotations

[Grant Ingersoll]

The Hadoop version we use requires 1.6.


On Jan 22, 2009, at 4:05 AM, Ted Dunning wrote:


I think mahout should compile with both 1.5 and 1.6.

On Wed, Jan 21, 2009 at 11:23 PM, deneche abdelhakim >wrote:


Last time I tried to compile the Mahout trunk, I got a similar  
problem. In
my case, I'm using Eclipse and the errors were caused by the JDK  
Compliance
Level (in the project properties). In short, I was using JVM 1.6  
JRE but

with 5.0 compliance level (forgot to change it !).

I found the answer in the following link:

http://dev.eclipse.org/newslists/news.eclipse.newcomer/msg19329.html


--- En date de : Jeu 22.1.09, Jeff Eastman > a

écrit :


De: Jeff Eastman 
Objet: @Override annotations
À: mahout-dev@lucene.apache.org
Date: Jeudi 22 Janvier 2009, 6h07
I'm trying to compile the latest Mahout trunk on my
MacBook using the JVM 1.6.0 JRE and the @Override
annotations are causing a lot of errors. There must be a
simple solution to this problem but I cannot recall it. Can
somebody help?

Jeff








--
Ted Dunning, CTO
DeepDyve
4600 Bohannon Drive, Suite 220
Menlo Park, CA 94025
www.deepdyve.com
650-324-0110, ext. 738
858-414-0013 (m)


--
Grant Ingersoll

Lucene Helpful Hints:
http://wiki.apache.org/lucene-java/BasicsOfPerformance
http://wiki.apache.org/lucene-java/LuceneFAQ

Re: Let's do 0.1

[Grant Ingersoll]

+1

On Jan 20, 2009, at 5:06 PM, Sean Owen wrote:


There's been talk of releasing 0.1 for a long time. As far as I can
tell the only task anyone is thinking of completing before 0.1 is a
migration to Maven. Might I suggest that we either decide to do that
this week, or decide to do it later, so that either way we can finally
get out a first release at the start of next week?

(I am neutral on Maven -- not against it, not for it -- don't mind if
someone else wants to do it.)

"0.1" does not need to be nearly perfect; I think we're definitely
past the 0.1 state. Whatever we have, just pack it up and release it.
It's OK if the structure changes later.

I want to push on this a little since I haven't put out a real release
of the CF code since last April or so, and people are still using the
old code since it's the last released version, and asking about bugs
or performance problems that were long since fixed in Mahout, or that
need features in Mahout. I can tell them to check SVN but this is a
turn-off for some people that just want a .jar. So it would sure be of
benefit to me to cut a release.

I am going to hold off on any significant changes this second to focus
on releasing 0.1. After that I want to update some dependencies and
get going on a few non-trivial changes in my neck of the code.
Thoughts?

Sean

Re: RE: RE: [jira] Commented: (MAHOUT-19) Hierarchial clusterer

[Sean Owen]

Here's a DataModel you could try out for your purposes; the rest
should be as I described earlier.


package org.apache.mahout.cf.taste.example;

import org.apache.mahout.cf.taste.impl.model.file.FileDataModel;
import org.apache.mahout.cf.taste.impl.model.GenericPreference;
import org.apache.mahout.cf.taste.impl.model.BooleanPrefUser;
import org.apache.mahout.cf.taste.impl.common.FastSet;
import org.apache.mahout.cf.taste.model.Preference;
import org.apache.mahout.cf.taste.model.Item;
import org.apache.mahout.cf.taste.model.User;

import java.io.File;
import java.io.IOException;
import java.util.List;
import java.util.Map;
import java.util.ArrayList;

public final class AnkursDataModel extends FileDataModel {

  public AnkursDataModel(File ratingsFile) throws IOException {
super(ratingsFile);
  }

  @Override
  protected void processLine(String line, Map> data, Map itemCache) {
String[] tokens = line.split("\t");
String userID = tokens[0];
List prefs = new ArrayList(tokens.length - 1);
for (int tokenNum = 1; tokenNum < tokens.length; tokenNum++) {
  String itemID = tokens[tokenNum];
  Item item = itemCache.get(itemID);
  if (item == null) {
item = buildItem(itemID);
itemCache.put(itemID, item);
  }
  prefs.add(new GenericPreference(null, item, 1.0));
  // this is a little ugly but makes it easy to reuse
FileDataModel -- pref values are tossed below
}
data.put(userID, prefs);
  }

  @Override
  protected User buildUser(String id, List prefs) {
FastSet itemIDs = new FastSet();
for (Preference pref : prefs) {
  itemIDs.add(pref.getItem().getID());
}
return new BooleanPrefUser(id, itemIDs);
  }
}



On Wed, Jan 21, 2009 at 7:57 AM, Goel, Ankur  wrote:
> The input data format is typically
> User-id \t item-id \t (other information)
>
> From here it can transformed into either of the formats as they are just
> 1 map-red away. After transformation the input data set will contain
> lines only in 1 format and not both. The data format that I use has each
> line of the form
>
> User-id \t (Item-id1:other_info) \t ((Item-id1:other_info))...
>
> As for co-occurrence counting the way Ted mentioned, I implemented a
> map-red implementation for the same and I have found it to be pretty
> efficient, simple and effective too.
>
> Couple of tricks like only keeping top-X co-occurred items for an item
> by count and emitting only those item pairs that match a certain
> criteria have worked very well.
>
> I would like to contribute it to Mahout and filed a JIRA for the same
> https://issues.apache.org/jira/browse/MAHOUT-103
>
> I will have a patch coming soon.
>
> What I am looking for is a complimentary technique that does not depend
> so much on co-occurrences and tries to do some sort of latent variable
> analysis to answer my query.
>
> Thanks
> -Ankur

Re: Taste: throwing NoSuchElementException

[Ted Dunning]

What you choose to present on the absence of history is a very similar  
problem as what you present when you have just a little information.  
The best case is when the recs engine always gives you the best it can  
as well as giving you some indication of how much it knows. Then the  
presentation layer can make decisions about what to show.


One way to look at recommendations is as a form of inference from the  
behavior of the mass of users and the possibly limited information  
about the user.


Regarding the best recommendation with empty history, no I don't think  
that the most popular items are a good choice. You do much better to  
consider the value of eliciting interesting information from the user  
by giving a variety of items. The most popular items tend to be much  
too homogeneous to be a good recommendation. If they don't like the  
first they won't like the rest. Better to just show one item.


On Jan 22, 2009, at 11:26, Sean Owen  wrote:


Interesting indeed... I suppose I had thought of that as something a
bit separate from recommendation. You're really just giving, what, the
top-rated items or something? perhaps something more appropriate given
the domain. Either way it feels like something the caller can come up
with outside the context of a recommendation engine. I had thought it
less surprising for the engine to say nothing when it can't actually
recommend something meaningfully.

I suppose DataModel could expose getTopRatedItems or something?

On Thu, Jan 22, 2009 at 7:23 PM, Ted Dunning   
wrote:

ANother option is to actually recommend something for new users.

Re: Taste: throwing NoSuchElementException

[Otis Gospodnetic]

I agree with Sean, and that's exactly what my plan was.  Once I get null (or 
the new exception - thanks Sean), we fall back on some other data source and 
return that to users who would otherwise not get any recommendations.


Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch



- Original Message 
> From: Sean Owen 
> To: mahout-dev@lucene.apache.org
> Sent: Thursday, January 22, 2009 2:26:18 PM
> Subject: Re: Taste: throwing NoSuchElementException
> 
> Interesting indeed... I suppose I had thought of that as something a
> bit separate from recommendation. You're really just giving, what, the
> top-rated items or something? perhaps something more appropriate given
> the domain. Either way it feels like something the caller can come up
> with outside the context of a recommendation engine. I had thought it
> less surprising for the engine to say nothing when it can't actually
> recommend something meaningfully.
> 
> I suppose DataModel could expose getTopRatedItems or something?
> 
> On Thu, Jan 22, 2009 at 7:23 PM, Ted Dunning wrote:
> > ANother option is to actually recommend something for new users.

Re: Taste: throwing NoSuchElementException

[Sean Owen]

Interesting indeed... I suppose I had thought of that as something a
bit separate from recommendation. You're really just giving, what, the
top-rated items or something? perhaps something more appropriate given
the domain. Either way it feels like something the caller can come up
with outside the context of a recommendation engine. I had thought it
less surprising for the engine to say nothing when it can't actually
recommend something meaningfully.

I suppose DataModel could expose getTopRatedItems or something?

On Thu, Jan 22, 2009 at 7:23 PM, Ted Dunning  wrote:
> ANother option is to actually recommend something for new users.

Re: Taste: throwing NoSuchElementException

[Ted Dunning]

ANother option is to actually recommend something for new users.

On Thu, Jan 22, 2009 at 11:14 AM, Sean Owen  wrote:

> Got it, you make a good point. Yeah I imagine the unknown-user case is
> more common that I had supposed. OK, disregard the comment about
> DataModel knowing about all users. It's not always going to be the
> case nor I suppose is it necessarily desirable.
>
> So let's see, the code does handle this situation. I suppose the
> remaining question is whether the method should return null or throw
> an exception? I still imagine the overhead of exceptions is virtually
> nil and I mildly prefer exceptions to null.
>
> So yeah it boils down to throwing a different exception? Sure, how
> about I invent a NoSuchUserException as a subclass of TasteException?
> Can-do.
>
> Sean
>
> On Wed, Jan 21, 2009 at 10:06 PM, Otis Gospodnetic
>  wrote:
> > Hello,
> >
> >
> > - Original Message 
> >> From: Sean Owen 
> >>
> >> Yeah let's see, to boil it down: either way there has to be a way to
> >> signal the user isn't known, and either way the caller has to handle
> >> it. I've always preferred exceptions to null, all else being equal. I
> >> don't mind the idea of exceptions being used for control flow; they
> >> aren't that expensive. (In a performance-critical block, OK, I'd use
> >> null instead, but here, this case is rare enough that I don't think
> >> performance is a factor.)
> >
> > I think this last bit is an assumption.  I'm working with a setup where
> 80% of recommendation requests will be for unknown users.
> > Imagine a web site that is not super sticky.  New users pass through all
> the time.  Most users are irregular visitors.  The system gets their ID from
> a cookie, but doesn't know much else about that user.
> >
> >> Catching an exception needs a bit more code than handling null. You
> >> can't force a caller to handle null, but you can force a caller to
> >> handle an exception -- but here I'm using an unchecked exception so
> >> that doesn't matter anyway. You have a point about catching this maybe
> >> masking another exception.
> >>
> >> I could be talked into changing this, but here, I think the right
> >> behavior for a DataModel is to know about all users that exist, not
> >> just ones with preferences. That is this user should be known in your
> >> situation.
> >
> > I think there'll always be unknown users in my case.  The reason I have
> such a high % of unknown users is because in addition to what I described
> above, I furthermore skip "noisy users" and don't have the FileDataModel
> read them.  I skip users who don't have much history - users for whom I
> don't have enough data to make good recommendations.  If I keep them, they
> consume my precious JVM heap and recommendation computation is slower.  If I
> skip them, I see noticeable improvement in performance (and I haven't
> noticed degradation in quality so far... should I have?)
> >
> >> But are you using FileDataModel or something similar? because this
> >> condition isn't really fulfilled by this implementation. It only knows
> >> about users that have expressed a preference, by its nature. That can
> >> be addressed so that you can express users, without expressing a
> >> preference.
> >
> > I think the above explains my particular situation.
> >
> >> If this is the issue -- let me attack that issue directly to solve
> >> this, and punt on the exception vs. null discussion. Am I right?
> >
> > I'm doing okay performance-wise after I skip my noisy users, so this is
> not a huge problem for me.  Perhaps just changing the exception to a
> specific checked exception would be an improvement if handling null is too
> much of a pain.
> >
> > Otis
>



-- 
Ted Dunning, CTO
DeepDyve
4600 Bohannon Drive, Suite 220
Menlo Park, CA 94025
www.deepdyve.com
650-324-0110, ext. 738
858-414-0013 (m)

Re: Taste: throwing NoSuchElementException

[Sean Owen]

Got it, you make a good point. Yeah I imagine the unknown-user case is
more common that I had supposed. OK, disregard the comment about
DataModel knowing about all users. It's not always going to be the
case nor I suppose is it necessarily desirable.

So let's see, the code does handle this situation. I suppose the
remaining question is whether the method should return null or throw
an exception? I still imagine the overhead of exceptions is virtually
nil and I mildly prefer exceptions to null.

So yeah it boils down to throwing a different exception? Sure, how
about I invent a NoSuchUserException as a subclass of TasteException?
Can-do.

Sean

On Wed, Jan 21, 2009 at 10:06 PM, Otis Gospodnetic
 wrote:
> Hello,
>
>
> - Original Message 
>> From: Sean Owen 
>>
>> Yeah let's see, to boil it down: either way there has to be a way to
>> signal the user isn't known, and either way the caller has to handle
>> it. I've always preferred exceptions to null, all else being equal. I
>> don't mind the idea of exceptions being used for control flow; they
>> aren't that expensive. (In a performance-critical block, OK, I'd use
>> null instead, but here, this case is rare enough that I don't think
>> performance is a factor.)
>
> I think this last bit is an assumption.  I'm working with a setup where 80% 
> of recommendation requests will be for unknown users.
> Imagine a web site that is not super sticky.  New users pass through all the 
> time.  Most users are irregular visitors.  The system gets their ID from a 
> cookie, but doesn't know much else about that user.
>
>> Catching an exception needs a bit more code than handling null. You
>> can't force a caller to handle null, but you can force a caller to
>> handle an exception -- but here I'm using an unchecked exception so
>> that doesn't matter anyway. You have a point about catching this maybe
>> masking another exception.
>>
>> I could be talked into changing this, but here, I think the right
>> behavior for a DataModel is to know about all users that exist, not
>> just ones with preferences. That is this user should be known in your
>> situation.
>
> I think there'll always be unknown users in my case.  The reason I have such 
> a high % of unknown users is because in addition to what I described above, I 
> furthermore skip "noisy users" and don't have the FileDataModel read them.  I 
> skip users who don't have much history - users for whom I don't have enough 
> data to make good recommendations.  If I keep them, they consume my precious 
> JVM heap and recommendation computation is slower.  If I skip them, I see 
> noticeable improvement in performance (and I haven't noticed degradation in 
> quality so far... should I have?)
>
>> But are you using FileDataModel or something similar? because this
>> condition isn't really fulfilled by this implementation. It only knows
>> about users that have expressed a preference, by its nature. That can
>> be addressed so that you can express users, without expressing a
>> preference.
>
> I think the above explains my particular situation.
>
>> If this is the issue -- let me attack that issue directly to solve
>> this, and punt on the exception vs. null discussion. Am I right?
>
> I'm doing okay performance-wise after I skip my noisy users, so this is not a 
> huge problem for me.  Perhaps just changing the exception to a specific 
> checked exception would be an improvement if handling null is too much of a 
> pain.
>
> Otis

Re: Re : @Override annotations

[Ted Dunning]

Ahh... that is a different kettle.

On Thu, Jan 22, 2009 at 6:31 AM, Kay Kay  wrote:

> I thought we are using Java 6 because of the dependency on Hadoop ?
>
>
>
> Jeff Eastman wrote:
>
>> I was able to get past the compiler problems by switching the compliance
>> level to Java 6, thanks Deneche. IIRC,  With Java 6.0, @Override *can* also
>> be used if your method implements a method in a base interface. If this is
>> the only 6.0 feature we are using it is a shame to preclude Java 5
>> compilation for this alone.
>>
>>

Re: Re : @Override annotations

[Sean Owen]

Yep that was the real reason, as I understand it. It is not merely to
use @Override on interface methods.

On Thu, Jan 22, 2009 at 2:31 PM, Kay Kay  wrote:
> I thought we are using Java 6 because of the dependency on Hadoop ?

Re: Re : @Override annotations

[Kay Kay]

I thought we are using Java 6 because of the dependency on Hadoop ?


Jeff Eastman wrote:
I was able to get past the compiler problems by switching the 
compliance level to Java 6, thanks Deneche. IIRC,  With Java 6.0, 
@Override *can* also be used if your method implements a method in a 
base interface. If this is the only 6.0 feature we are using it is a 
shame to preclude Java 5 compilation for this alone.


Jeff


Sean Owen wrote:

Yes I added them since we are officially requiring Java 6 -- right?
that was the conclusion on a recent thread.

On Thu, Jan 22, 2009 at 9:33 AM, deneche abdelhakim 
 wrote:
 
When you say 1.5, you mean the 1.5 JDK (or JRE in the case of 
Eclipse) ?


Because, I just tried to compile the Mahout trunk in Eclipse using 
JRE 1.5.0_11 (and 5.0 compliance level of course), and got 628 
errors in core/src (I didn't check core/test yet).


The first 100 errors are as follows:
. 98 errors related to the @Override, for example:





  

Re: Re : @Override annotations

[Jeff Eastman]

I was able to get past the compiler problems by switching the compliance 
level to Java 6, thanks Deneche. IIRC,  With Java 6.0, @Override *can* 
also be used if your method implements a method in a base interface. If 
this is the only 6.0 feature we are using it is a shame to preclude Java 
5 compilation for this alone.


Jeff


Sean Owen wrote:

Yes I added them since we are officially requiring Java 6 -- right?
that was the conclusion on a recent thread.

On Thu, Jan 22, 2009 at 9:33 AM, deneche abdelhakim  wrote:
  

When you say 1.5, you mean the 1.5 JDK (or JRE in the case of Eclipse) ?

Because, I just tried to compile the Mahout trunk in Eclipse using JRE 1.5.0_11 
(and 5.0 compliance level of course), and got 628 errors in core/src (I didn't 
check core/test yet).

The first 100 errors are as follows:
. 98 errors related to the @Override, for example:





  




PGP.sig
Description: PGP signature

Re: Re : @Override annotations

[Sean Owen]

Yes I added them since we are officially requiring Java 6 -- right?
that was the conclusion on a recent thread.

On Thu, Jan 22, 2009 at 9:33 AM, deneche abdelhakim  wrote:
> When you say 1.5, you mean the 1.5 JDK (or JRE in the case of Eclipse) ?
>
> Because, I just tried to compile the Mahout trunk in Eclipse using JRE 
> 1.5.0_11 (and 5.0 compliance level of course), and got 628 errors in core/src 
> (I didn't check core/test yet).
>
> The first 100 errors are as follows:
> . 98 errors related to the @Override, for example:
>

[jira] Commented: (MAHOUT-24) Skeletal LWLR implementation

[Alexander Hans (JIRA)]

[ 
https://issues.apache.org/jira/browse/MAHOUT-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666101#action_12666101
 ] 

Alexander Hans commented on MAHOUT-24:
--

> Alexander did you further pursue this issue?

Sorry for being so quiet on this one, the last couple of months have been 
somewhat stressful for me day job-wise, so I didn't find any time to work on 
this issue. I think things will become easier in a few weeks.

Ted, thanks for pointing out other methods for inverting a matrix. For a single 
LWLR prediction this has to be done only once by the reducer, so I think it 
would be ok to implement whatever method works for a first version and change 
it later to something better once the whole algorithm is functional.

> Skeletal LWLR implementation
> 
>
> Key: MAHOUT-24
> URL: https://issues.apache.org/jira/browse/MAHOUT-24
> Project: Mahout
>  Issue Type: New Feature
> Environment: n/a
>Reporter: Samee Zahur
> Attachments: LWLR.patch.tar.bz2
>
>
> This is a very skeletal but functional implementation for LWLR. It outputs n 
> lines where n is the number of dimensions. ith line = sum(x[i]*x[ind]) where 
> ind is the index of independant variable. So the actual gradient = 2nd 
> line/1st line for the classical 2D.
> Contains a single small test case for demonstration.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Re : @Override annotations

[deneche abdelhakim]

When you say 1.5, you mean the 1.5 JDK (or JRE in the case of Eclipse) ?

Because, I just tried to compile the Mahout trunk in Eclipse using JRE 1.5.0_11 
(and 5.0 compliance level of course), and got 628 errors in core/src (I didn't 
check core/test yet). 

The first 100 errors are as follows:
. 98 errors related to the @Override, for example:

The method accept(File) of type BayesFileFormatter.FileProcessor must override 
a superclass method  mahout-core/src/org/apache/mahout/classifier
BayesFileFormatter.java line 160

. 2 errors related to "Deque cannot be resolved" in
  . org.apache.mahout.classifier.bayes.BayesClassifier, and
  . org.apache.mahout.classifier.cbayes.CBayesClassifier

May be I'm wrong, but Deque is available only in 1.6, no ?

--- En date de : Jeu 22.1.09, Ted Dunning  a écrit :

> De: Ted Dunning 
> Objet: Re: Re : @Override annotations
> À: mahout-dev@lucene.apache.org
> Date: Jeudi 22 Janvier 2009, 10h05
> I think mahout should compile with both 1.5 and 1.6.
> 
> On Wed, Jan 21, 2009 at 11:23 PM, deneche abdelhakim
> wrote:
> 
> > Last time I tried to compile the Mahout trunk, I got a
> similar problem. In
> > my case, I'm using Eclipse and the errors were
> caused by the JDK Compliance
> > Level (in the project properties). In short, I was
> using JVM 1.6 JRE but
> > with 5.0 compliance level (forgot to change it !).
> >
> > I found the answer in the following link:
> >
> >
> http://dev.eclipse.org/newslists/news.eclipse.newcomer/msg19329.html
> >
> >
> > --- En date de : Jeu 22.1.09, Jeff Eastman
>  a
> > écrit :
> >
> > > De: Jeff Eastman
> 
> > > Objet: @Override annotations
> > > À: mahout-dev@lucene.apache.org
> > > Date: Jeudi 22 Janvier 2009, 6h07
> > > I'm trying to compile the latest Mahout trunk
> on my
> > > MacBook using the JVM 1.6.0 JRE and the @Override
> > > annotations are causing a lot of errors. There
> must be a
> > > simple solution to this problem but I cannot
> recall it. Can
> > > somebody help?
> > >
> > > Jeff
> >
> >
> >
> >
> 
> 
> -- 
> Ted Dunning, CTO
> DeepDyve
> 4600 Bohannon Drive, Suite 220
> Menlo Park, CA 94025
> www.deepdyve.com
> 650-324-0110, ext. 738
> 858-414-0013 (m)

Re: Re : @Override annotations

[Ted Dunning]

I think mahout should compile with both 1.5 and 1.6.

On Wed, Jan 21, 2009 at 11:23 PM, deneche abdelhakim wrote:

> Last time I tried to compile the Mahout trunk, I got a similar problem. In
> my case, I'm using Eclipse and the errors were caused by the JDK Compliance
> Level (in the project properties). In short, I was using JVM 1.6 JRE but
> with 5.0 compliance level (forgot to change it !).
>
> I found the answer in the following link:
>
> http://dev.eclipse.org/newslists/news.eclipse.newcomer/msg19329.html
>
>
> --- En date de : Jeu 22.1.09, Jeff Eastman  a
> écrit :
>
> > De: Jeff Eastman 
> > Objet: @Override annotations
> > À: mahout-dev@lucene.apache.org
> > Date: Jeudi 22 Janvier 2009, 6h07
> > I'm trying to compile the latest Mahout trunk on my
> > MacBook using the JVM 1.6.0 JRE and the @Override
> > annotations are causing a lot of errors. There must be a
> > simple solution to this problem but I cannot recall it. Can
> > somebody help?
> >
> > Jeff
>
>
>
>


-- 
Ted Dunning, CTO
DeepDyve
4600 Bohannon Drive, Suite 220
Menlo Park, CA 94025
www.deepdyve.com
650-324-0110, ext. 738
858-414-0013 (m)