You can mod confluence themes. We do it as CXF. I can look into how.
for a website redesign? I'm kind of thinking we do like OFBiz
and have a nice landing page, and then everything else is driven off
Confluence. Thoughts?
-Grant
On Tue, Apr 13, 2010 at 5:16 AM, Benson Margulies
bimargul...@gmail.com
wrote:
Here's a practical matter
Yup, same scheme at CXF.
On Wed, Apr 21, 2010 at 8:31 AM, Grant Ingersoll gsing...@apache.orgwrote:
On Apr 21, 2010, at 7:55 AM, Benson Margulies wrote:
Confluence?
Yeah, that's pretty much it. I'm thinking we have a static front page and
then backed by some pages on Confluence. Check
I thought it would be a bit less confusing if the current toplevel moved
directly to REPO/mahout/mahout instead of moving to REPO/mahout.
On Wed, Apr 21, 2010 at 5:43 PM, Grant Ingersoll gsing...@apache.orgwrote:
On Apr 21, 2010, at 5:01 PM, Drew Farris wrote:
On Wed, Apr 21, 2010 at 6:04
The results are lots and lots of +1, and nothing else.
Grant, it looks to me like the job construction scripting in maven/build.xml
would look neater as an application of the maven-shade-plugin. Do you (or
anyone else) have an opinion about this, before I try to cook up a patch?
I just had to set up a Bloom filter. I found a seemingly cogent
implementation by one Bruno Martins, but it has a design decision that I
found difficult to swallow.
To get the multiple hashes, he:
1: used Rabin fingerprints to get an hash.
2: rehashed that hash with varying seeds to get the
It's the conceptual model I'd like to understand here. In my
'understanding', bloom filters work because each hash function grabs a
different picture of the total information content of the original key.
A good hash does this if you have different seeds.
What bothered me about the
I'll be on vacation at the 72-hour mark, so I won't mop this all up until
Sunday or Monday.
[
https://issues.apache.org/jira/browse/MAHOUT-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12856704#action_12856704
]
Benson Margulies commented on MAHOUT-364:
-
GPL3 is NOT ASL compatible.
[GSOC
[
https://issues.apache.org/jira/browse/MAHOUT-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12855921#action_12855921
]
Benson Margulies commented on MAHOUT-377:
-
Thanks. I was really just tying a JIRA
Unlike the last one, you don't have to take this one on trust, not
that I'm complaining. It is possible to download source, but, and run
unit tests in the more or less usual way if anyone is so inclined.
On Mon, Apr 12, 2010 at 5:14 AM, Sean Owen sro...@gmail.com wrote:
Sure +1 for same reason.
, Grant Ingersoll gsing...@apache.org wrote:
On Apr 11, 2010, at 9:53 PM, Benson Margulies wrote:
You can get dependency by running 'mvn' in the collections directory,
which will build a snapshot and put it in your local repository, or by
adding the Apache snapshot repository to your environment
Robin asked me to pay attention to this mentoring question. I have
assumed that, to be an effective mentor here, I'd have to be capable
of at least keeping up with the mentee on the math behind whatever
algorithm is in play. Thus, absent a proposal to work on maven
configurations or collections,
OK, sign me up.
On Mon, Apr 12, 2010 at 11:05 AM, Grant Ingersoll gsing...@apache.org wrote:
On Apr 12, 2010, at 10:01 AM, Benson Margulies wrote:
Robin asked me to pay attention to this mentoring question. I have
assumed that, to be an effective mentor here, I'd have to be capable
Apache Policy/Folklore:
When voting for a release, you are supposed to download the source,
build it, and verify that it is more or less as advertised. In this
case, observing that typing 'mvn' at the downloaded source builds and
passes unit tests is about as good as it's going to get.
On Mon,
Here's a practical matter:
svn layout.
starting at the root we get, I propose:
- sandboxes
- mahout(/trunk,tag,branches)
- collections(/trunk/tag/branches)
sandboxes gives us a home for experimental branches; mahout will
contain the core product modules, collections the codegen and
Clean up javadoc errors in collections
--
Key: MAHOUT-377
URL: https://issues.apache.org/jira/browse/MAHOUT-377
Project: Mahout
Issue Type: Bug
Affects Versions: 0.4
Reporter: Benson
[
https://issues.apache.org/jira/browse/MAHOUT-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies updated MAHOUT-377:
Affects Version/s: collections-1.0
(was: 0.4
I have prepared an independent release of the Mahout collections
library. This differs from the 0.3 release only insofar as it removes
the unwanted slf4j dependency.
The release pieces, including non-Maven tarballs and zips, can be found at:
CANCEL THIS. I just noticed that the not-very-maven artifacts are missing.
On Sun, Apr 11, 2010 at 9:26 PM, Benson Margulies bimargul...@gmail.com wrote:
I have prepared an independent release of the Mahout collections
library. This differs from the 0.3 release only insofar as it removes
https://repository.apache.org/content/repositories/orgapachemahout-015/
contains (this time for sure) all the artifacts for release 1.0 of the
mahout-collections component. This is the first independent release of
collections from the rest of mahout; it differs from the version
released with
Fellow Mahout developers and Mahout users who check out from svn:
We are in the middle of loosening the connection between
mahout-collections and the rest of mahout, in order to make it easier
for folks to use collections by itself and to allow collections to
develop its own release rhythm.
For
early, release often.
-Grant
On Apr 6, 2010, at 5:12 PM, Benson Margulies wrote:
Indeed. Off I go.
On Tue, Apr 6, 2010 at 4:23 PM, Ted Dunning ted.dunn...@gmail.com
wrote:
Very cool. Very exciting.
Benson, that sounds like consensus to me.
On Tue, Apr 6, 2010 at 1:02 PM, Jake
Looks like we have 72 hours and the right sort of votes.
On Thu, Apr 8, 2010 at 1:47 AM, deneche abdelhakim adene...@gmail.com wrote:
+1
On Thu, Apr 8, 2010 at 2:57 AM, Drew Farris drew.far...@gmail.com wrote:
+1
On Tue, Apr 6, 2010 at 9:08 PM, Benson Margulies bimargul...@gmail.com
wrote
.
Is there a way for me to test this component? Is there any testing needed
beyond checking existence?
On Tue, Apr 6, 2010 at 7:13 PM, Benson Margulies bimargul...@gmail.com
wrote:
On Tue, Apr 6, 2010 at 9:40 PM, Ted Dunning ted.dunn...@gmail.com
wrote:
Is that possible here instead
robin.a...@gmail.com wrote:
I will take your word for it :) Just giving a soln to Teds concern.
+1 from me.
Robin
On Wed, Apr 7, 2010 at 4:50 PM, Benson Margulies bimargul...@gmail.comwrote:
You have two choices: 1) take my word (or diff) about the zero code
changes :-), or
2) I can set up
Hearing no other remarks, I will proceed to disconnect and make the
version 1.0-SNAPSHOT, and call a release vote RSN.
On Sun, Apr 4, 2010 at 7:58 PM, Benson Margulies bimargul...@gmail.com wrote:
Last question: What's the first version going to be? I propose '1.0'.
0.4 would get mighty
, 2010 at 1:44 PM, Sean Owen sro...@gmail.com wrote:
This still lives in Mahout, just has a different version number?
what's the substance of the change in the short-term; I think I missed
that step.
On Tue, Apr 6, 2010 at 6:41 PM, Benson Margulies bimargul...@gmail.com
wrote:
Hearing
than the core mahout project if only because the needs they
fulfill
are better understood. That makes the 1.0 version for collections match
the
0.4 upcoming version for Mahout.
On Tue, Apr 6, 2010 at 11:17 AM, Benson Margulies bimargul...@gmail.com
wrote:
Substance:
1: remove
Where are we on the consensus process?
Jake, have Ted and I satisfied you? Does this call for a VOTE to be
sure that we're on the same page?
On Tue, Apr 6, 2010 at 3:33 PM, Benson Margulies bimargul...@gmail.com wrote:
On Tue, Apr 6, 2010 at 3:10 PM, Ted Dunning ted.dunn...@gmail.com wrote:
I
Indeed. Off I go.
On Tue, Apr 6, 2010 at 4:23 PM, Ted Dunning ted.dunn...@gmail.com wrote:
Very cool. Very exciting.
Benson, that sounds like consensus to me.
On Tue, Apr 6, 2010 at 1:02 PM, Jake Mannix jake.man...@gmail.com wrote:
... I'm in favor, I guess, of:
1: remove
In order to decouple the mahout-collections library from the rest of
Mahout, to allow more frequent releases and other good things, we
propose to release the code generator for the collections library as a
separate Maven artifact. (Followed, in short order, by the collections
library proper.) This
://repository.apache.org/content/repositories/orgapachemahout-006/
It should work better now.
On Tue, Apr 6, 2010 at 6:08 PM, Benson Margulies bimargul...@gmail.comwrote:
In order to decouple the mahout-collections library from the rest of
Mahout, to allow more frequent releases and other good
Last question: What's the first version going to be? I propose '1.0'.
0.4 would get mighty confusion. I really don't see the harm in calling
it 1.0.
On Sat, Apr 3, 2010 at 6:00 PM, Grant Ingersoll gsing...@apache.org wrote:
On Apr 3, 2010, at 2:22 PM, Benson Margulies wrote:
On Sat, Apr 3
Commons-collections turns out to be a very specific thing which this
is not. I have an intemediate proposal that I'll put in a separate
thread.
On Sat, Apr 3, 2010 at 7:06 AM, Dawid Weiss dawid.we...@gmail.com wrote:
I'm neutral... maybe let it marinate longer in Mahout, prove it's used
and
I propose to disconnect collections from the aggregate project and put
it on its own release cycle.
This was originally someone else's idea when we started on it.
Collections is useful in its own right, and I'd like to make fixes to
it available without having the whole rest of Mahout reach a
On Sat, Apr 3, 2010 at 2:07 PM, Sean Owen sro...@gmail.com wrote:
On Sat, Apr 3, 2010 at 6:47 PM, Benson Margulies bimargul...@gmail.com
wrote:
I confess that the slf4j dependency in collections is a very strong
local motivation to me, but it also seems right in principle.
I just killed
[
https://issues.apache.org/jira/browse/MAHOUT-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies reassigned MAHOUT-361:
---
Assignee: Benson Margulies
SLF4J dependency structure leads to unpleasant surproses
: Clustering
Affects Versions: 0.3
Reporter: Benson Margulies
Our poms declare a dependency on the slf4j core, but not on any of the
implementation modules. Thus, if an unsuspecting user adds a dependency on our
stuff, and runs, they get a exception from slf4j complaining
There's a Trove feature I didn't address in the 0.3 version of collections:
control of the hash function for Object types. In Trove, you construct over
a 'strategy' object if you want something like the JDK IdentityHashMap. COLT
didn't do that. A user can get this currently via subclassing, though
On Fri, Apr 2, 2010 at 7:01 AM, Sean Owen sro...@gmail.com wrote:
What's the use case for needing to vary the hash function? It's one of
those things where I assume there are incorrect ways to do it, and
correct ways, and among the correct ways fairly clear arguments about
which function will
[
https://issues.apache.org/jira/browse/MAHOUT-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12852793#action_12852793
]
Benson Margulies commented on MAHOUT-361:
-
It's a little worse than 'override
I'm going to code subclasses in my code to get something done before we get
to the next Mahout release, and that will give me some practical experience
with the whole business.
Meanwhile, consider the case of IdentityHashMap. If nothing else, the
strategy approach means adding One class to the
Dawid,
Now I recall why I stopped working on features of Mahout collections :-)
HPPC.
We'll see who gets where first.
--benson
On Fri, Apr 2, 2010 at 10:06 AM, Dawid Weiss dawid.we...@gmail.com wrote:
What's the use case for needing to vary the hash function? It's one of
those things
[
https://issues.apache.org/jira/browse/MAHOUT-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12852971#action_12852971
]
Benson Margulies commented on MAHOUT-361:
-
Well, OK, but if assembling a typical
[
https://issues.apache.org/jira/browse/MAHOUT-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12853018#action_12853018
]
Benson Margulies commented on MAHOUT-361:
-
That lone collections business is pretty
[
https://issues.apache.org/jira/browse/MAHOUT-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12853017#action_12853017
]
Benson Margulies commented on MAHOUT-361:
-
Ceki, noop would be not as nice as j.u.l
I need a brave eclipse user to try out the following, and then I have
some questions for others.
1) Remove all .project and .classpath files from your tree.
2) cd to 'eclipse'.
3) Pick a new pathname for an eclipse workspace (call it WORKSPACE) in
the following.
4) mvn -Psetup-eclipse-workspace
-server arch: i386 Family: unix
On Mon, Mar 22, 2010 at 9:35 AM, Benson Margulies bimargul...@gmail.com
wrote:
I need a brave eclipse user to try out the following, and then I have
some questions for others.
1) Remove all .project and .classpath files from your tree.
2) cd to 'eclipse'.
3
If you want convenience with Eclipse, here's the process:
1) run eclipse:configure-workspace to set M2_REPO in the workspace.
2) Copy several files into the workspace: checkstyle setting, PMD
settings, Eclipse code format settings, Eclipse cleanup settings.
3) create and augment several Eclipse
...@...
• Isabel Drost (isa...@...)
• Ted Dunning (tdunn...@...)
• Jeff Eastman (jeast...@...)
• Drew Farris (d...@...)
• Grant Ingersoll (gsing...@...)
• Benson Margulies (bimargul...@...)
• Sean Owen (sro...@...)
• Robin Anil (robina
to be binding.
-Grant
On Mar 19, 2010, at 11:05 AM, Benson Margulies wrote:
My nonbinding vote is +1.
On Fri, Mar 19, 2010 at 10:50 AM, Grant Ingersoll gsing...@apache.org
wrote:
Per the earlier discussions, I'm calling a vote to submit the following
resolution [1] to the Lucene PMC
dodges the problem that we have a lurking
version conflict here so I'd rather not 'fix' it this way. But at
least I can work again for now.
On Wed, Mar 17, 2010 at 10:04 PM, Benson Margulies
bimargul...@gmail.com wrote:
Some use of 'excludes' is called for here. I'll have a look.
On Wed, Mar
Ingersoll (gsing...@...)
• Benson Margulies (bimargul...@...)
• Sean Owen (sro...@...)
• Robin Anil (robina...@...)
• Jake Mannix (jman...@...)
RESOLVED, that the Apache Mahout Project be and hereby
is tasked with the migration and rationalization of the Apache
[
https://issues.apache.org/jira/browse/MAHOUT-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12847192#action_12847192
]
Benson Margulies commented on MAHOUT-338:
-
revisions: 925070, 925071
Simplify
[
https://issues.apache.org/jira/browse/MAHOUT-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12847197#action_12847197
]
Benson Margulies commented on MAHOUT-338:
-
revision 925075.
Simplify maven
[
https://issues.apache.org/jira/browse/MAHOUT-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12847198#action_12847198
]
Benson Margulies commented on MAHOUT-338:
-
Progress: there is a distribution dir
Some use of 'excludes' is called for here. I'll have a look.
On Wed, Mar 17, 2010 at 11:00 AM, Sean Owen sro...@gmail.com wrote:
Two postscripts:
Velocity 1.6.3 (latest) depends on 2.4, but isn't in Maven.
The issue is using some methods on MutableLong/Double etc. in lang
that aren't in
[
https://issues.apache.org/jira/browse/MAHOUT-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies reassigned MAHOUT-338:
---
Assignee: Benson Margulies
Simplify maven structure
Hmm. Not a bad idea. I think of maven as done, but that's not right.
I'll deal with this in the evening.
On Tue, Mar 16, 2010 at 11:33 AM, Robin Anil robin.a...@gmail.com wrote:
http://www.apache.org/dist/lucene/mahout/
I dont see it here yet. Isnt that required of a release?
Robin
to edit the release notes in the meantime.
Robin
On Mon, Mar 15, 2010 at 8:54 PM, Robin Anil robin.a...@gmail.com wrote:
Yeah the site src edit doesnt mean it will go live. It will go live only if
the site is generated.
On Mon, Mar 15, 2010 at 8:50 PM, Benson Margulies
bimargul
Whoops, let's check this count.
Are Drew and Sean Lucene PMC members? If not, we're a few bricks short
of a load.
On Mon, Mar 15, 2010 at 11:56 AM, Robin Anil robin.a...@gmail.com wrote:
On Mon, Mar 15, 2010 at 9:23 PM, Benson Margulies
bimargul...@gmail.comwrote:
I've just come up
Sorry, I thought Sean tucked one away into his message where the wired
build problems went away.
On Mon, Mar 15, 2010 at 12:05 PM, Grant Ingersoll gsing...@apache.org wrote:
On Mar 15, 2010, at 11:59 AM, Benson Margulies wrote:
Whoops, let's check this count.
Are Drew and Sean Lucene PMC
There's a bug in maven such that the Apache nexus thing refuses to let
me promote our release. I have to wait for a guy with a pointy hat. He
should be along presently.
I recommend maven 2.1.x. I can't explain the error from
eclipse:eclipse, I use it constantly.
On Mon, Mar 15, 2010 at 7:13 PM, Jeff Eastman
j...@windwardsolutions.com wrote:
After deleting my .m2 repository and rebuilding Mahout I now had an Eclipse
classpath full of obsolete references to
It turns out that the concept of voting for a RM is a quirk of the WS
PMC that I mistakenly thought was Foundation policy.
-tempore of Mahout Release!
+1
On Thu, Mar 11, 2010 at 6:19 PM, Ted Dunning ted.dunn...@gmail.com
wrote:
Should we vote Benson in?
On Thu, Mar 11, 2010 at 5:04 PM, Benson Margulies
bimargul...@gmail.com
wrote:
1) Vote someone as release manager
Sean's problems aside, we're not exactly drowning in +1 votes for the
release here ...
Personally I think we should have a Owl perched on the trunk of an elephant.
Ma-Hoot.
On Fri, Mar 12, 2010 at 5:11 PM, Ted Dunning ted.dunn...@gmail.com wrote:
I am always interested in seeing what ideas people come up with. If they
are good ideas, then we should try them on. If they fit,
Somehow, your release build is refusing to find and use the collection code
generator plugin -- that it just built.
Is the module/ for it somehow disabled in the release profile?
On Thu, Mar 11, 2010 at 7:05 AM, Sean Owen sro...@gmail.com wrote:
Ah just the mvn -Prelease,mahout_release
Or the version didn't get set to non-SNAPSHOT in the plugin's pom?
On Thu, Mar 11, 2010 at 7:05 AM, Sean Owen sro...@gmail.com wrote:
Ah just the mvn -Prelease,mahout_release release:prepare business
On Thu, Mar 11, 2010 at 12:02 PM, Grant Ingersoll gsing...@apache.org
wrote:
What were you
Guys,
Here's now to diagnose this.
release:prepare:
a) runs an ordinary build which should succeed.
b) edits the poms to remove the -SNAPSHOTS.
c) checks them in.
d) makes a tag.
e) puts the new snapshots in the poms.
f) checks them in.
I don't see a tag. So I don't understand how you got to
docs on what we do:
http://cwiki.apache.org/confluence/display/MAHOUT/How+to+release
I'd surely appreciate it if you can have a look Benson as I think you
know more than I do about how this works.
On Thu, Mar 11, 2010 at 1:33 PM, Benson Margulies bimargul...@gmail.com
wrote:
Guys,
Here's
I have problems before you have problems. I can't build mahout-utils at
all. I'm looking into it. This is with no funny profiles.
[INFO] Building Mahout Utilities
[INFO]task-segment: [install]
[INFO]
Downloading:
OK, I see something. I'm trying to use -Dmaven.test.skip=true to speed
things up, but that stops the creation of the test jar. Unfortunately, since
I get random test failures, this is a problem.
I think that we need to replace the test-jar trick with an extra project,
since it's really preferably
The release pieces for Mahout are available at the nexus staging repository
for Mahout:
https://repository.apache.org/service/local/staging/deploy/maven2/
This vote will be open for 72 hours.
Note that I am not a legally designated release manager, but perhaps the PMC
would care to take that
So, I got the release process to go. I would like to propose a slight
rearrangement to match patterns I've seen elsewhere.
a) Make a new directory, distribution. Put the assembly executions and such
in there.
b) get rid of the maven directory. Move the contents of that pom into the
toplevel pom.
Yes. Sorry, I meant to send a status report first. Coming right up.
On Thu, Mar 11, 2010 at 7:55 PM, Grant Ingersoll gsing...@apache.orgwrote:
Shall we assume by your vote call that this was fixed?
On Mar 11, 2010, at 5:28 PM, Benson Margulies wrote:
OK, I see something. I'm trying to use
I confess that I never quite reproduced srowen's strange behavior. Instead,
I applied a few bandaids to the poms to get more predictable behavior:
1) I made collections depend on collections-codegen, in addition to using
it, to ensure that the reactor would process the former before the later.
2)
:
What was the question ?
On Tue, Mar 9, 2010 at 13:13, Benson Margulies bimargul...@gmail.com
wrote:
Options:
1. Email to their private@ list.
2. Email to members@ seeking assistance.
3. Sleuthing their archive to see who was the release manager for this
and
try to persuade them
Options:
1. Email to their private@ list.
2. Email to members@ seeking assistance.
3. Sleuthing their archive to see who was the release manager for this and
try to persuade them.
Opinions?
I just got email from Doug Cutting. He is going to take care of it for us.
On Tue, Mar 9, 2010 at 9:17 AM, Grant Ingersoll gsing...@apache.org wrote:
On Mar 9, 2010, at 7:13 AM, Benson Margulies wrote:
Options:
1. Email to their private@ list.
2. Email to members@ seeking assistance
On Mar 9, 2010, at 2:25 PM, Benson Margulies wrote:
I just got email from Doug Cutting. He is going to take care of it for
us.
On Tue, Mar 9, 2010 at 9:17 AM, Grant Ingersoll gsing...@apache.org
wrote:
On Mar 9, 2010, at 7:13 AM, Benson Margulies wrote:
Options:
1. Email
at 5:10 PM, Benson Margulies bimargul...@gmail.comwrote:
And I'm following up to see if there isn't a patch I could make that would
make this easier for them.
On Tue, Mar 9, 2010 at 5:01 PM, Grant Ingersoll gsing...@apache.orgwrote:
Very cool. Given they use the repository.apache.org
it to create and push these. If you have experience working with
ant/ivy/maven, your review of this issue would help us commit it to
0.20.3 and speed future releases. Thanks -C
On Tue, Mar 9, 2010 at 2:09 PM, Benson Margulies bimargul...@gmail.com
wrote:
Now that I'm not pecking at an iPod, I think
Could I be stupid for a moment? Our fellow Apache project, Hadoop, makes
releases but doesn't bother to stick them into the Apache repo where they
will replicate to central?
Are we proposing to just do their work for them, or to publish them under a
Mahout-specific Maven triple? If the later, I
Coming Right Up.
On Fri, Mar 5, 2010 at 9:32 AM, Grant Ingersoll gsing...@apache.org wrote:
Has anyone filed a JIRA with them to do so?
The Extremely Esteemed PMC Chair (aka Paper Pusher Extraordinaire),
Grant
On Mar 5, 2010, at 7:28 AM, Benson Margulies wrote:
Could I be stupid
https://issues.apache.org/jira/browse/HADOOP-6617
On Fri, Mar 5, 2010 at 9:32 AM, Grant Ingersoll gsing...@apache.org wrote:
Has anyone filed a JIRA with them to do so?
The Extremely Esteemed PMC Chair (aka Paper Pusher Extraordinaire),
Grant
On Mar 5, 2010, at 7:28 AM, Benson Margulies
[
https://issues.apache.org/jira/browse/MAHOUT-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12839529#action_12839529
]
Benson Margulies commented on MAHOUT-307:
-
This one looks good to me.
Move
To answer a question of Robin's:
Some months ago, I started to make arrangements to include cs in our
build. However, I discovered an aspect of 'Lucene style' that was, at
the time, 100%-incompatible with cs. There was no option to cs to
align it.
So, the first step here is to agree to a style
[
https://issues.apache.org/jira/browse/MAHOUT-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12833879#action_12833879
]
Benson Margulies commented on MAHOUT-291:
-
Robin's going to have to pick through
on segmentation. Thanks for the pointer.
--benson
On Sat, Feb 13, 2010 at 11:18 PM, Ted Dunning ted.dunn...@gmail.com wrote:
Benson,
Are you using techniques related to this:
http://www.it.usyd.edu.au/~james/pubs/pdf/dlp07perc.pdf ?
On Sat, Feb 13, 2010 at 9:38 AM, Benson Margulies
bimargul
On Sun, Feb 14, 2010 at 4:47 PM, Ted Dunning ted.dunn...@gmail.com wrote:
Benson,
One more thing. I forget the actual reference, but the best Chinese
segmenter that I have seen in practice (whose name I forget) was able to get
away with a simple unweighted lexicon and 2-3 word look-ahead +
I don't object to good style. I object to sweeping changes that break a lot
of patches. Maybe not the case here, but it will be in the future and unless
the whole thing is automated as part of committing (as Hadoop does), the code
will always have formatting issues causing this exact
to me that you can depth bound your beam
search and turn it into an exhaustive search. The lesson of their success
is that garden path sentences (with regard to segmentation) are rare in
Chinese.
On Sun, Feb 14, 2010 at 10:29 AM, Benson Margulies
bimargul...@gmail.comwrote:
Ted, thanks very
Folks,
Here's one of my occasional questions in which I am, in essence,
bartering my code wrangling efforts for expertise on hard stuff.
Consider a sequence problem addressed with a perceptron model with an
ordinary Viterbi decoder. There's a standard confidence estimation
technique borrowed
The ongoing admin is really no big deal. The PMC has to report to the
board once a month. As Grant noted, the initial work is mostly a gift
from infra.
I don't see any harm in getting 0.3 out first if that makes folks more
comfortable.
On Sat, Feb 13, 2010 at 2:42 PM, Drew Farris
I'm not very fond of a plague of finals. Here's why.
Consider
final int[] x = new int[10];
That doesn't, sadly, prevent
x[2] = 1;
So, to me, final is too weak to be useful. I put them in code when
required due to the rules about anonymous functions capturing locals,
but never otherwise.
You meant immutable? I wouldn't disagree. I appreciate what it does, I
just don't much like it :-)
On Sat, Feb 13, 2010 at 4:07 PM, Robin Anil robin.a...@gmail.com wrote:
final doesnt necessarily mean mutable right?
On Sun, Feb 14, 2010 at 2:35 AM, Benson Margulies
bimargul
1 - 100 of 451 matches
Mail list logo
