Re: No javadocs?
OK, done. Will take some time to propagate through the mirrors. Note, now we need to add package level docs, etc. ;-) -Grant On Apr 14, 2009, at 5:18 PM, Grant Ingersoll wrote: On Apr 14, 2009, at 5:04 PM, Otis Gospodnetic wrote: Hello, I just noticed there are no Javadocs on the site. I generated them locally with mvn javadoc:javadoc. I'll add a JIRA issue. I think Sean put them up, but they may not be linked from the site just yet. I know they do exist on people.a.o. Sean?
Re: [ANNOUNCE] Apache Mahout 0.1 Released
Yes, you missed the "publish" part of it: See step 8 of http://cwiki.apache.org/MAHOUT/howtoupdatethewebsite.html I'll take care of it. On Apr 14, 2009, at 5:11 PM, Sean Owen wrote: Javadoc is here brah - I think I updated the Resources page but perhaps did not properly publish the link? -- Forwarded message -- From: "Grant Ingersoll" Date: Apr 10, 2009 8:31 PM Subject: Re: [ANNOUNCE] Apache Mahout 0.1 Released To: On Apr 10, 2009, at 3:10 PM, Sean Owen wrote: > OK copied everything to .../mahout/javadoc/core --... Once it propagates, it will be at http://lucene.apache.org/mahout/javadoc/core/ So, I think all that is needed at this point is a pointer to them from the Resource section of the site.
Re: [ANNOUNCE] Apache Mahout 0.1 Released
I'll check. On Apr 14, 2009, at 5:11 PM, Sean Owen wrote: Javadoc is here brah - I think I updated the Resources page but perhaps did not properly publish the link? -- Forwarded message -- From: "Grant Ingersoll" Date: Apr 10, 2009 8:31 PM Subject: Re: [ANNOUNCE] Apache Mahout 0.1 Released To: On Apr 10, 2009, at 3:10 PM, Sean Owen wrote: > OK copied everything to .../mahout/javadoc/core --... Once it propagates, it will be at http://lucene.apache.org/mahout/javadoc/core/ So, I think all that is needed at this point is a pointer to them from the Resource section of the site.
Re: No javadocs?
On Apr 14, 2009, at 5:04 PM, Otis Gospodnetic wrote: Hello, I just noticed there are no Javadocs on the site. I generated them locally with mvn javadoc:javadoc. I'll add a JIRA issue. I think Sean put them up, but they may not be linked from the site just yet. I know they do exist on people.a.o. Sean?
Re: Shutting down RefreshHelper or Recommender
Ah yes sorry I mean 'refresh(null)'. Seriously I am terrible at tracking my
own changes.
This should reload everything. If you want to change params - yeah rebuild
everything. Here again I am open to building better solutions to accommodate
your real use case should it prove painful to rebuild the recommender.
On Apr 14, 2009 9:59 PM, "Otis Gospodnetic"
wrote:
Hi,
> Should be even simpler: > > Recommender r = ...; > ... > r.refresh();
Is that really so? I don't see refresh() in any Recommenders in trunk:
o...@lesina:~/workspace/asf-mahout/core$ grep -ic refresh\(\)
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/*Recommender.java
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/AbstractRecommender.java:0
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/BooleanUserGenericUserBasedRecommender.java:0
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/CachingRecommender.java:0
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/GenericItemBasedRecommender.java:0
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/GenericUserBasedRecommender.java:0
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/ItemAverageRecommender.java:0
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/ItemUserAverageRecommender.java:0
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/TreeClusteringRecommender.java:0
I do see the alternative method that takes in a Collection of Refreshables,
as in the code snippet I sent:
o...@lesina:~/workspace/asf-mahout/core$ grep -i refresh\(Coll
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/*Recommender.java
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/BooleanUserGenericUserBasedRecommender.java:
public void refresh(Collection alreadyRefreshed) {
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/CachingRecommender.java:
public void refresh(Collection alreadyRefreshed) {
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/GenericItemBasedRecommender.java:
public void refresh(Collection alreadyRefreshed) {
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/GenericUserBasedRecommender.java:
public void refresh(Collection alreadyRefreshed) {
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/ItemAverageRecommender.java:
public void refresh(Collection alreadyRefreshed) {
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/ItemUserAverageRecommender.java:
public void refresh(Collection alreadyRefreshed) {
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/TreeClusteringRecommender.java:
public void refresh(Collection alreadyRefreshed) {
Is refresh() really in there somewhere?
> The RefreshHelper business is supposed to take care of the details. >
Dependent components, all o...
Well, that's one part, yes. In particular, one thing that I want to do is
explicitly force the reload of the underlying input data (FileDataModel).
The other thing that I would like to be able to do is set new parameters for
the Recommender, or rather, classes that go into the recommender, such as
the neighbourhood size, minimal similarity, and a few parameters of my own
that I pass to my custom DataModel loader (it extends
BooleanPrefUserFileDataModel and takes several parameters in its ctor that
tell it which users/items not to load). I *think* that because of this and
for this piece I still need to make a completely new instance of the
Recommender... because I don't want to just do a refresh, I want to refresh,
but with a different set of parameters.
> As to the other question, I don't know of any reason it would behave >
differently on Java 5 vers...
I like this idea. As a matter of fact, I've thought along the same "diff
lines" while working on this recommender stuff.
> It is a good idea but the fact that other files in the same directory have
> an effect too has al...
I don't think that's it - I have only one "re-input.txt" file, which is my
(user,item,pref) file. I create it elsewhere in the system and them just
"mv" it to the right place. Before 0.1 Taste would see something changed
and reload the file (but, again, not on all systems) :)
I'll try explicit refresh now (with refresh(Collection Otherwise, hmm, would have to dig in with you and debug. > > On Apr 14,
2009 4:20 PM, "Otis Gosp...
> wrote: > > > OK, cool, so with refresh() this can become a push that looks
like: > > Rec...
> CollectionrefreshableDM = new ArrayList();
> refreshableDM.add(dm); > r.refresh(refreshableDM); // this seems to be
needed according...
> > To: mahout-dev@lucene.apache.org > > > Sent: Tuesday, April 14, 2009
9:57:34 AM > Subject: Re: ...
Fwd: Re: [ANNOUNCE] Apache Mahout 0.1 Released
Javadoc is here brah - I think I updated the Resources page but perhaps did not properly publish the link? -- Forwarded message -- From: "Grant Ingersoll" Date: Apr 10, 2009 8:31 PM Subject: Re: [ANNOUNCE] Apache Mahout 0.1 Released To: On Apr 10, 2009, at 3:10 PM, Sean Owen wrote: > OK copied everything to .../mahout/javadoc/core --... Once it propagates, it will be at http://lucene.apache.org/mahout/javadoc/core/ So, I think all that is needed at this point is a pointer to them from the Resource section of the site.
[jira] Created: (MAHOUT-117) Add Javadocs to site
Add Javadocs to site Key: MAHOUT-117 URL: https://issues.apache.org/jira/browse/MAHOUT-117 Project: Mahout Issue Type: Improvement Reporter: Otis Gospodnetic There are no Javadocs on http://lucene.apache.org/mahout . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
No javadocs?
Hello, I just noticed there are no Javadocs on the site. I generated them locally with mvn javadoc:javadoc. I'll add a JIRA issue. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
Re: Shutting down RefreshHelper or Recommender
Hi,
> Should be even simpler:
>
> Recommender r = ...;
> ...
> r.refresh();
Is that really so? I don't see refresh() in any Recommenders in trunk:
o...@lesina:~/workspace/asf-mahout/core$ grep -ic refresh\(\)
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/*Recommender.java
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/AbstractRecommender.java:0
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/BooleanUserGenericUserBasedRecommender.java:0
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/CachingRecommender.java:0
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/GenericItemBasedRecommender.java:0
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/GenericUserBasedRecommender.java:0
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/ItemAverageRecommender.java:0
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/ItemUserAverageRecommender.java:0
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/TreeClusteringRecommender.java:0
I do see the alternative method that takes in a Collection of Refreshables, as
in the code snippet I sent:
o...@lesina:~/workspace/asf-mahout/core$ grep -i refresh\(Coll
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/*Recommender.java
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/BooleanUserGenericUserBasedRecommender.java:
public void refresh(Collection alreadyRefreshed) {
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/CachingRecommender.java:
public void refresh(Collection alreadyRefreshed) {
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/GenericItemBasedRecommender.java:
public void refresh(Collection alreadyRefreshed) {
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/GenericUserBasedRecommender.java:
public void refresh(Collection alreadyRefreshed) {
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/ItemAverageRecommender.java:
public void refresh(Collection alreadyRefreshed) {
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/ItemUserAverageRecommender.java:
public void refresh(Collection alreadyRefreshed) {
./src/main/java/org/apache/mahout/cf/taste/impl/recommender/TreeClusteringRecommender.java:
public void refresh(Collection alreadyRefreshed) {
Is refresh() really in there somewhere?
> The RefreshHelper business is supposed to take care of the details.
> Dependent components, all of them, will be refreshed first, in order, and
> exactly once. Or am I missing something you want to do?
Well, that's one part, yes. In particular, one thing that I want to do is
explicitly force the reload of the underlying input data (FileDataModel).
The other thing that I would like to be able to do is set new parameters for
the Recommender, or rather, classes that go into the recommender, such as the
neighbourhood size, minimal similarity, and a few parameters of my own that I
pass to my custom DataModel loader (it extends BooleanPrefUserFileDataModel and
takes several parameters in its ctor that tell it which users/items not to
load). I *think* that because of this and for this piece I still need to make a
completely new instance of the Recommender... because I don't want to just do a
refresh, I want to refresh, but with a different set of parameters.
> As to the other question, I don't know of any reason it would behave
> differently on Java 5 versus 6. It is supposed to completely reload all
> data.
>
> I have a guess at the problem. I built in a 'feature' which lets you supply
> 'update' files, named with a prefix like your main data file, which override
> and update the main data file. The idea is it is a way to push updates to a
> file without pushing the whole massive data file.
I like this idea. As a matter of fact, I've thought along the same "diff
lines" while working on this recommender stuff.
> It is a good idea but the fact that other files in the same directory have
> an effect too has already surprised even me - it created a test bug that a
> kind user had to figure out for me. Is this possibly a factor? It might
> explain why it behaves differently on a different machine.
I don't think that's it - I have only one "re-input.txt" file, which is my
(user,item,pref) file. I create it elsewhere in the system and them just "mv"
it to the right place. Before 0.1 Taste would see something changed and reload
the file (but, again, not on all systems) :)
I'll try explicit refresh now (with refresh(Collection Otherwise, hmm, would have to dig in with you and debug.
>
> On Apr 14, 2009 4:20 PM, "Otis Gospodnetic"
> wrote:
>
>
> OK, cool, so with refresh() this can become a push that looks like:
>
>Recommender r
>
>public void init() {
> r = new SomeRecommender(...);
> DataModel dm = recommender.getDataModel(); // make DataModel
> refreshable
> CollectionrefreshableDM = new ArrayList();
> refreshableDM.add(dm);
> r.r
[jira] Commented: (MAHOUT-116) Decode matrix methods
[ https://issues.apache.org/jira/browse/MAHOUT-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12698916#action_12698916 ] Jeff Eastman commented on MAHOUT-116: - We have been living with the ad-hoc asFormatString methods since the beginning days of Vectors and Matrices. In MAHOUT-30, I introduced Google's Gson implementation of Json for storing and retrieving models and states, and this works pretty well IMHO. We have also discussed the use of alternative serialization/deserialization methods in other threads and at other times. I'd rather we converge on a single mechanism with broad generality rather than keep inventing more ad-hoc serialization code. The current format strings really break down once we decide to implement e.g. MAHOUT-65 Element Labels. Could you take a look at Gson and see if it would fill the bill? > Decode matrix methods > - > > Key: MAHOUT-116 > URL: https://issues.apache.org/jira/browse/MAHOUT-116 > Project: Mahout > Issue Type: Improvement > Components: Matrix >Reporter: Daniel Nee > Attachments: MAHOUT-116.patch > > > Currently in the matrix package we have asFormatString() methods to serialize > matrices, however there are no corresponding methods to decode the serialized > matrices. At the moment I do not think any of the code base uses the matrix > asFormatString() methods, however for the Gaussian Mixture Model(GMM) code I > am working on I will need to serialize/deserialize covariance matrices. > The following matrix classes will require decoding methods: > 1. DenseMatrix > 2. SparseMatrix > 3. SparseColumnMatrix > 4. SparseRowMatrix > 5. MatrixView -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MAHOUT-116) Decode matrix methods
[ https://issues.apache.org/jira/browse/MAHOUT-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Nee updated MAHOUT-116: -- Attachment: MAHOUT-116.patch Patch to implement the decoding methods for the five classes listed above, plus updates to their respective unit tests. In order to make the decoding easier I made some changes to what asFormatString() produces for the matrix classes. The string representing the actual data in the matrix is prefixed by a two-character code indicating the matrix type and the string '(N,M)' where N is number of rows and M is the number of columns. For instance in TestSparseMatrix the 3x2 sparse matrix produces the output from asFormatString: sm(3,2)[ [s2, 0:1.1, 1:2.2, ] [s2, 0:3.3, 1:4.4, ] [s2, 0:5.5, 1:6.6, ] ] As much as possible I have tried to keep the way in which matrices are decoded similar to the way in which vectors are currently decoded. Thus to decode a matrix you would call the static method decodeMatrix in AbstractMatrix, which would in turn call the respective decodeFormat method in the appropriate matrix class. In order to decode the rows of the matrix I have used the decodeVector method. Couple of things I am currently not happy with: SparseColumnMatrix does not output a sparse representation, as the asFormatString method of SparseVector will produce a row wise representation of the vector. At the moment it will basically output the same as a DenseMatrix representation. Arguably we could output the transpose of the matrix as series of sparse rows and just ensure when the matrix is decoded we obtain correct matrix. Fair amount of shared code between the decodeFormat methods implemented in each of the five classes. Potentially some it it could be moved into the AbstractMatrix method. Your thoughts and suggestions would be welcome. > Decode matrix methods > - > > Key: MAHOUT-116 > URL: https://issues.apache.org/jira/browse/MAHOUT-116 > Project: Mahout > Issue Type: Improvement > Components: Matrix >Reporter: Daniel Nee > Attachments: MAHOUT-116.patch > > > Currently in the matrix package we have asFormatString() methods to serialize > matrices, however there are no corresponding methods to decode the serialized > matrices. At the moment I do not think any of the code base uses the matrix > asFormatString() methods, however for the Gaussian Mixture Model(GMM) code I > am working on I will need to serialize/deserialize covariance matrices. > The following matrix classes will require decoding methods: > 1. DenseMatrix > 2. SparseMatrix > 3. SparseColumnMatrix > 4. SparseRowMatrix > 5. MatrixView -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MAHOUT-116) Decode matrix methods
Decode matrix methods - Key: MAHOUT-116 URL: https://issues.apache.org/jira/browse/MAHOUT-116 Project: Mahout Issue Type: Improvement Components: Matrix Reporter: Daniel Nee Currently in the matrix package we have asFormatString() methods to serialize matrices, however there are no corresponding methods to decode the serialized matrices. At the moment I do not think any of the code base uses the matrix asFormatString() methods, however for the Gaussian Mixture Model(GMM) code I am working on I will need to serialize/deserialize covariance matrices. The following matrix classes will require decoding methods: 1. DenseMatrix 2. SparseMatrix 3. SparseColumnMatrix 4. SparseRowMatrix 5. MatrixView -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Shutting down RefreshHelper or Recommender
Should be even simpler:
Recommender r = ...;
...
r.refresh();
The RefreshHelper business is supposed to take care of the details.
Dependent components, all of them, will be refreshed first, in order, and
exactly once. Or am I missing something you want to do?
As to the other question, I don't know of any reason it would behave
differently on Java 5 versus 6. It is supposed to completely reload all
data.
I have a guess at the problem. I built in a 'feature' which lets you supply
'update' files, named with a prefix like your main data file, which override
and update the main data file. The idea is it is a way to push updates to a
file without pushing the whole massive data file.
It is a good idea but the fact that other files in the same directory have
an effect too has already surprised even me - it created a test bug that a
kind user had to figure out for me. Is this possibly a factor? It might
explain why it behaves differently on a different machine.
Otherwise, hmm, would have to dig in with you and debug.
On Apr 14, 2009 4:20 PM, "Otis Gospodnetic"
wrote:
OK, cool, so with refresh() this can become a push that looks like:
Recommender r
public void init() {
r = new SomeRecommender(...);
DataModel dm = recommender.getDataModel(); // make DataModel
refreshable
Collection refreshableDM = new ArrayList();
refreshableDM.add(dm);
r.refresh(refreshableDM); // this seems to be needed according to
Refreshable javadoc?
}
// force DataModel refresh
public void forceRefresh() {
r.refresh(refreshableDM);
}
?
One more Q regarding refreshing:
Is this meant to completely reload the data (even if it has new users and
new items and new preferences)? The reason I'm asking is because I'm seeing
a mixed behaviour depending on which system I run my recommender app on. On
one system I can get the refresh to reload the data and "see" any new
users/items. This system runs with Java 1.6 and the data lives on the local
disk. On another system I can't get the changes to the data model file to
be visible to the recommender. This system runs Java 1.5 and the data file
lives on the mounted NAS disk. I *do* see "INFO: Reading file info...", but
the recommender still doesn't see, say, new users, and thus gives 0
recommendations for them. Both systems run slightly pre-0.1 code.
Thanks, Otis - Original Message > From: Sean Owen
> To: mahout-dev@lucene.apache.org
> Sent: Tuesday, April 14, 2009 9:57:34 AM > Subject: Re: Shutting down
RefreshHelper or Recommender...
> Yes the change is in 0.1. No you can always have everything
reload/recompute > with the refresh() ...
> wrote: > > > Ah, I didn't even realize you took it out ... so it's not in
0.1? (I'm > behind on ...
> - Original Message > From: Sean Owen > To:
> mahout-...@lucene.apache > > > wrote: > > > > Hello, > > > > Here is a
quick Taste thing that...
Re: Shutting down RefreshHelper or Recommender
OK, cool, so with refresh() this can become a push that looks like:
Recommender r
public void init() {
r = new SomeRecommender(...);
DataModel dm = recommender.getDataModel(); // make DataModel refreshable
Collection refreshableDM = new ArrayList();
refreshableDM.add(dm);
r.refresh(refreshableDM); // this seems to be needed according to
Refreshable javadoc?
}
// force DataModel refresh
public void forceRefresh() {
r.refresh(refreshableDM);
}
?
One more Q regarding refreshing:
Is this meant to completely reload the data (even if it has new users and new
items and new preferences)? The reason I'm asking is because I'm seeing a
mixed behaviour depending on which system I run my recommender app on. On one
system I can get the refresh to reload the data and "see" any new users/items.
This system runs with Java 1.6 and the data lives on the local disk. On
another system I can't get the changes to the data model file to be visible to
the recommender. This system runs Java 1.5 and the data file lives on the
mounted NAS disk. I *do* see "INFO: Reading file info...", but the recommender
still doesn't see, say, new users, and thus gives 0 recommendations for them.
Both systems run slightly pre-0.1 code.
Thanks,
Otis
- Original Message
> From: Sean Owen
> To: mahout-dev@lucene.apache.org
> Sent: Tuesday, April 14, 2009 9:57:34 AM
> Subject: Re: Shutting down RefreshHelper or Recommender
>
> Yes the change is in 0.1. No you can always have everything reload/recompute
> with the refresh() method. The idea is to call that on Recommender and let
> it manage the update of all dependencies, including the model.
>
> I think you rightly noted earlier that the refresh mechanism would be better
> if rewritten as a 'push' rather than 'pull' system. If this is causing
> trouble we can get on redesigning it.
>
> On Apr 14, 2009 2:15 PM, "Otis Gospodnetic"
> wrote:
>
>
> Ah, I didn't even realize you took it out ... so it's not in 0.1? (I'm
> behind on email, etc.).
> So reloading the data model now means creating a new instance of the
> recommender?
>
>
> Thanks,
> Otis
>
> - Original Message > From: Sean Owen > To:
> mahout-...@lucene.apache
>
> > wrote: > > > > Hello, > > > > Here is a quick Taste thing that looks like
> it could be a "bug". Qu...
Re: Shutting down RefreshHelper or Recommender
Yes the change is in 0.1. No you can always have everything reload/recompute with the refresh() method. The idea is to call that on Recommender and let it manage the update of all dependencies, including the model. I think you rightly noted earlier that the refresh mechanism would be better if rewritten as a 'push' rather than 'pull' system. If this is causing trouble we can get on redesigning it. On Apr 14, 2009 2:15 PM, "Otis Gospodnetic" wrote: Ah, I didn't even realize you took it out ... so it's not in 0.1? (I'm behind on email, etc.). So reloading the data model now means creating a new instance of the recommender? Thanks, Otis - Original Message > From: Sean Owen > To: mahout-...@lucene.apache > wrote: > > > > Hello, > > > > Here is a quick Taste thing that looks like it could be a "bug". Qu...
Re: Shutting down RefreshHelper or Recommender
Ah, I didn't even realize you took it out ... so it's not in 0.1? (I'm behind on email, etc.). So reloading the data model now means creating a new instance of the recommender? Thanks, Otis - Original Message > From: Sean Owen > To: mahout-dev@lucene.apache.org > Sent: Tuesday, April 14, 2009 12:46:37 AM > Subject: Re: Shutting down RefreshHelper or Recommender > > Yeah that's part of the reason I just took this out -- there is no > longer an automatic reload. Can you update and/or just remove this > part of the code in your branch as well? > > I took a second look and didn't see anything else, like a static > reference somewhere, that would prevent a Recommender from being > GC'ed. > > > > On Tue, Apr 14, 2009 at 12:38 AM, Otis Gospodnetic > wrote: > > > > Hello, > > > > Here is a quick Taste thing that looks like it could be a "bug". Quotes > because it doesn't really break much, but... > > > > So Taste has the handy RefreshHelper thing that monitors the input file and > reloads it if it changes. I wanted to be able to explicitly reload my > recommender, because I want to create a new one with new parameters. So I > thought I'd just create a new recommender instance and let the other one get > GCed. Then I started seeing a bunch of these: > > INFO: Reading file info... > > INFO: Reading file info... > > INFO: Reading file info... > > > > At which point I realized that the old recommender that I was "swapping", > > was > still alive and its thread for reloading of the input file was still alive. > Ouch. A quick scan of the code doesn't reveal a method that lets one "shut > down" the recommender or at least this background thread, but perhaps it is > in > there somewhere and I'm just not seeing it? > > > > Thanks, > > Otis > >
Re: Welcome Sean Owen and Ted Dunning to the Lucene PMC
Congrats Ted and Sean! Great work! :-D On Tue, Apr 14, 2009 at 4:28 PM, Shalin Shekhar Mangar wrote: > On Tue, Apr 14, 2009 at 6:26 AM, Grant Ingersoll wrote: > >> I am pleased to announce the addition of Sean Owen and Ted Dunning to the >> Lucene PMC. Both Sean and Ted have played instrumental roles in helping get >> the Mahout project off the ground. I personally am looking forward to their >> continued contribution and hope you all will join me in congratulations. >> >> > Congratulations Sean and Ted! Thank you for all the hard work you guys have > been putting in Mahout. > > -- > Regards, > Shalin Shekhar Mangar. >
Re: Welcome Sean Owen and Ted Dunning to the Lucene PMC
On Tue, Apr 14, 2009 at 6:26 AM, Grant Ingersoll wrote: > I am pleased to announce the addition of Sean Owen and Ted Dunning to the > Lucene PMC. Both Sean and Ted have played instrumental roles in helping get > the Mahout project off the ground. I personally am looking forward to their > continued contribution and hope you all will join me in congratulations. > > Congratulations Sean and Ted! Thank you for all the hard work you guys have been putting in Mahout. -- Regards, Shalin Shekhar Mangar.
Re: Welcome Sean Owen and Ted Dunning to the Lucene PMC
Hi, On Tue, Apr 14, 2009 at 2:56 AM, Grant Ingersoll wrote: > I am pleased to announce the addition of Sean Owen and Ted Dunning to the > Lucene PMC. Both Sean and Ted have played instrumental roles in helping get > the Mahout project off the ground. I personally am looking forward to their > continued contribution and hope you all will join me in congratulations. +1 Congratulations, and keep up the good work! BR, Jukka Zitting
