Ted Dunning
2012-01-01, 01:07
Grant Ingersoll
2012-01-06, 14:59
Ted Dunning
2012-01-06, 15:50
Grant Ingersoll
2011-12-08, 13:20
Grant Ingersoll
2011-12-08, 19:35
Jeff Eastman
2011-12-28, 03:34
Grant Ingersoll
2011-12-28, 12:33
Sean Owen
2011-12-28, 04:53
Jeff Eastman
2011-12-28, 05:30
Gavin McDonald
2011-12-28, 06:06
Dmitriy Lyubimov
2011-12-28, 06:06
Ted Dunning
2011-12-28, 06:37
Ted Dunning
2011-12-28, 06:49
Dmitriy Lyubimov
2011-12-28, 07:15
Grant Ingersoll
2011-12-28, 23:21
Ted Dunning
2011-12-28, 23:30
Grant Ingersoll
2011-12-28, 23:45
Ted Dunning
2011-12-29, 00:15
Grant Ingersoll
2011-12-29, 02:33
Ted Dunning
2011-12-29, 05:01
Dmitriy Lyubimov
2011-12-29, 07:44
Dmitriy Lyubimov
2011-12-29, 07:49
Dmitriy Lyubimov
2011-12-29, 07:56
Dmitriy Lyubimov
2011-12-29, 08:13
Dmitriy Lyubimov
2011-12-29, 08:31
Dmitriy Lyubimov
2011-12-29, 08:42
Dawid Weiss
2011-12-29, 08:49
Dmitriy Lyubimov
2011-12-29, 08:49
Ted Dunning
2011-12-29, 08:52
Dmitriy Lyubimov
2011-12-29, 08:57
Dmitriy Lyubimov
2011-12-29, 08:58
Lance Norskog
2011-12-30, 01:19
Grant Ingersoll
2011-12-31, 22:25
Grant Ingersoll
2011-12-28, 23:44
Lance Norskog
2012-01-10, 03:33
-
Re: Build failed in Jenkins: mahout-nightly #737Ted Dunning 2012-01-01, 01:07
I have replicated this and applied this patch but the test still fails.
I will take a longer look when I get a chance.
On Sat, Dec 31, 2011 at 3:57 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
> I just took a look and found several files not closed issues as Dmitriy
> mentioned. There might be a buffering difference on Linux versus make.
>
> I have a patch to fix this and will test right now on EC2 if I have enough
> time.
>
>
> On Sat, Dec 31, 2011 at 2:25 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
>
>> Any progress on this? Seems like it is a show stopper for code freeze.
>> On Dec 29, 2011, at 3:58 AM, Dmitriy Lyubimov wrote:
>>
>> > note identical md5 for u200 and u400.
>> >
>> > On Thu, Dec 29, 2011 at 12:57 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>> wrote:
>> >> MD5 sums
>> >>
>> >> b8217318a29ef69c58b921013eb019e5
>> /tmp/matrix8554072597307396201/A-000000000
>> >> 41db088ff74c5efd5b766dba253efc03
>> /tmp/matrix8554072597307396201/A-000000200
>> >> b8217318a29ef69c58b921013eb019e5
>> /tmp/matrix8554072597307396201/A-000000400
>> >> 41db088ff74c5efd5b766dba253efc03
>> /tmp/matrix8554072597307396201/A-000000600
>> >> c8dc2a7df82065b5c1e8284ff23aecc6
>> /tmp/matrix8554072597307396201/A-000000800
>> >> 83bccdd2fa191e01d34646e2030f0e77
>> /tmp/matrix8554072597307396201/B-000000000
>> >> 9d6878fb789d61d5453b994ea1a5c6db
>> /tmp/matrix8554072597307396201/B-000000210
>> >> cbdf720b17ce25feb686effd1aa0ebef
>> /tmp/matrix8554072597307396201/B-000000420
>> >> 2f71d6ba6891b242575b5cc6ba1c4358
>> /tmp/matrix8554072597307396201/B-000000630
>> >> f50b76bb48c8f6a791a6d8206d980492
>> /tmp/matrix8554072597307396201/B-000000840
>> >> 6bb29ca304889a6c8effff6e5c062dc8 /tmp/matrix8554072597307396201/U-0
>> >> 019c881c1d7c5748a1cacb3e0b3e5899 /tmp/matrix8554072597307396201/U-200
>> >> 019c881c1d7c5748a1cacb3e0b3e5899 /tmp/matrix8554072597307396201/U-400
>> >> b84e4b01ffb9d691c87b496f8b4d84ec /tmp/matrix8554072597307396201/U-600
>> >> 6bb29ca304889a6c8effff6e5c062dc8 /tmp/matrix8554072597307396201/U-770
>> >>
>> >>
>> >> On Thu, Dec 29, 2011 at 12:52 AM, Ted Dunning <[EMAIL PROTECTED]>
>> wrote:
>> >>> Thanks. Good hints.
>> >>>
>> >>> I will take a look on a linux machine in the next few days.
>> >>>
>> >>> On Thu, Dec 29, 2011 at 12:42 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]
>> >wrote:
>> >>>
>> >>>> yes. i would venture to say that U computation (or restoration) is
>> >>>> somehow corrupted starting with 2nd block. at least it looks this
>> way.
>> >>>>
>> >>>> On Thu, Dec 29, 2011 at 12:31 AM, Dmitriy Lyubimov <
>> [EMAIL PROTECTED]>
>> >>>> wrote:
>> >>>>> A-reconstructed difference looks good up to row 399 but starting at
>> >>>>> row 400 differences do not add up to 0 anymore (although both inputs
>> >>>>> are not 0).
>> >>>>>
>> >>>>> So it doesn't look like trivial case of something is not initialized
>> >>>>> on top of it. It does seem something to do with blocking mechanism
>> >>>>> though since apparently 400th row is a boundary of some blocking
>> >>>>> somewhere, but it is hard for me to see where it fails at this
>> point.
>> >>>>>
>> >>>>> On Thu, Dec 29, 2011 at 12:13 AM, Dmitriy Lyubimov <
>> [EMAIL PROTECTED]>
>> >>>> wrote:
>> >>>>>> oh. it's because the synthetic input has only 4 singular values.
>> >>>>>>
>> >>>>>> On Wed, Dec 28, 2011 at 11:56 PM, Dmitriy Lyubimov <
>> [EMAIL PROTECTED]>
>> >>>> wrote:
>> >>>>>>> But it is not a problem reading U or V files, that's indeed what
>> U and
>> >>>>>>> V contain.
>> >>>>>>>
>> >>>>>>> On Wed, Dec 28, 2011 at 11:49 PM, Dmitriy Lyubimov <
>> [EMAIL PROTECTED]>
>> >>>> wrote:
>> >>>>>>>> U and V look suspect, degenerate (only 4 first columns are
>> nonzero,
>> >>>>>>>> the rest of matrices are zeros.
>> >>>>>>>>
>> >>>>>>>> On Wed, Dec 28, 2011 at 11:44 PM, Dmitriy Lyubimov <
>> [EMAIL PROTECTED]>
>> >>>> wrote:
>> >>>>>>>>> Yeah, fails for me on ubuntu without any special environment
>> issues.
>> >>>>>>>>> Which makes it easier, i can step thru.
I will take a longer look when I get a chance.
On Sat, Dec 31, 2011 at 3:57 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
> I just took a look and found several files not closed issues as Dmitriy
> mentioned. There might be a buffering difference on Linux versus make.
>
> I have a patch to fix this and will test right now on EC2 if I have enough
> time.
>
>
> On Sat, Dec 31, 2011 at 2:25 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
>
>> Any progress on this? Seems like it is a show stopper for code freeze.
>> On Dec 29, 2011, at 3:58 AM, Dmitriy Lyubimov wrote:
>>
>> > note identical md5 for u200 and u400.
>> >
>> > On Thu, Dec 29, 2011 at 12:57 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>> wrote:
>> >> MD5 sums
>> >>
>> >> b8217318a29ef69c58b921013eb019e5
>> /tmp/matrix8554072597307396201/A-000000000
>> >> 41db088ff74c5efd5b766dba253efc03
>> /tmp/matrix8554072597307396201/A-000000200
>> >> b8217318a29ef69c58b921013eb019e5
>> /tmp/matrix8554072597307396201/A-000000400
>> >> 41db088ff74c5efd5b766dba253efc03
>> /tmp/matrix8554072597307396201/A-000000600
>> >> c8dc2a7df82065b5c1e8284ff23aecc6
>> /tmp/matrix8554072597307396201/A-000000800
>> >> 83bccdd2fa191e01d34646e2030f0e77
>> /tmp/matrix8554072597307396201/B-000000000
>> >> 9d6878fb789d61d5453b994ea1a5c6db
>> /tmp/matrix8554072597307396201/B-000000210
>> >> cbdf720b17ce25feb686effd1aa0ebef
>> /tmp/matrix8554072597307396201/B-000000420
>> >> 2f71d6ba6891b242575b5cc6ba1c4358
>> /tmp/matrix8554072597307396201/B-000000630
>> >> f50b76bb48c8f6a791a6d8206d980492
>> /tmp/matrix8554072597307396201/B-000000840
>> >> 6bb29ca304889a6c8effff6e5c062dc8 /tmp/matrix8554072597307396201/U-0
>> >> 019c881c1d7c5748a1cacb3e0b3e5899 /tmp/matrix8554072597307396201/U-200
>> >> 019c881c1d7c5748a1cacb3e0b3e5899 /tmp/matrix8554072597307396201/U-400
>> >> b84e4b01ffb9d691c87b496f8b4d84ec /tmp/matrix8554072597307396201/U-600
>> >> 6bb29ca304889a6c8effff6e5c062dc8 /tmp/matrix8554072597307396201/U-770
>> >>
>> >>
>> >> On Thu, Dec 29, 2011 at 12:52 AM, Ted Dunning <[EMAIL PROTECTED]>
>> wrote:
>> >>> Thanks. Good hints.
>> >>>
>> >>> I will take a look on a linux machine in the next few days.
>> >>>
>> >>> On Thu, Dec 29, 2011 at 12:42 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]
>> >wrote:
>> >>>
>> >>>> yes. i would venture to say that U computation (or restoration) is
>> >>>> somehow corrupted starting with 2nd block. at least it looks this
>> way.
>> >>>>
>> >>>> On Thu, Dec 29, 2011 at 12:31 AM, Dmitriy Lyubimov <
>> [EMAIL PROTECTED]>
>> >>>> wrote:
>> >>>>> A-reconstructed difference looks good up to row 399 but starting at
>> >>>>> row 400 differences do not add up to 0 anymore (although both inputs
>> >>>>> are not 0).
>> >>>>>
>> >>>>> So it doesn't look like trivial case of something is not initialized
>> >>>>> on top of it. It does seem something to do with blocking mechanism
>> >>>>> though since apparently 400th row is a boundary of some blocking
>> >>>>> somewhere, but it is hard for me to see where it fails at this
>> point.
>> >>>>>
>> >>>>> On Thu, Dec 29, 2011 at 12:13 AM, Dmitriy Lyubimov <
>> [EMAIL PROTECTED]>
>> >>>> wrote:
>> >>>>>> oh. it's because the synthetic input has only 4 singular values.
>> >>>>>>
>> >>>>>> On Wed, Dec 28, 2011 at 11:56 PM, Dmitriy Lyubimov <
>> [EMAIL PROTECTED]>
>> >>>> wrote:
>> >>>>>>> But it is not a problem reading U or V files, that's indeed what
>> U and
>> >>>>>>> V contain.
>> >>>>>>>
>> >>>>>>> On Wed, Dec 28, 2011 at 11:49 PM, Dmitriy Lyubimov <
>> [EMAIL PROTECTED]>
>> >>>> wrote:
>> >>>>>>>> U and V look suspect, degenerate (only 4 first columns are
>> nonzero,
>> >>>>>>>> the rest of matrices are zeros.
>> >>>>>>>>
>> >>>>>>>> On Wed, Dec 28, 2011 at 11:44 PM, Dmitriy Lyubimov <
>> [EMAIL PROTECTED]>
>> >>>> wrote:
>> >>>>>>>>> Yeah, fails for me on ubuntu without any special environment
>> issues.
>> >>>>>>>>> Which makes it easier, i can step thru.
+
Ted Dunning 2012-01-01, 01:07
-
Re: Build failed in Jenkins: mahout-nightly #737Grant Ingersoll 2012-01-06, 14:59
Any luck on this, as it is still failing for me on Ubuntu?
We are slowing whittling down the 0.6 issues, but this one seems critical.
On Dec 31, 2011, at 8:07 PM, Ted Dunning wrote:
> I have replicated this and applied this patch but the test still fails.
>
> I will take a longer look when I get a chance.
>
> On Sat, Dec 31, 2011 at 3:57 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>
>> I just took a look and found several files not closed issues as Dmitriy
>> mentioned. There might be a buffering difference on Linux versus make.
>>
>> I have a patch to fix this and will test right now on EC2 if I have enough
>> time.
>>
>>
>> On Sat, Dec 31, 2011 at 2:25 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
>>
>>> Any progress on this? Seems like it is a show stopper for code freeze.
>>> On Dec 29, 2011, at 3:58 AM, Dmitriy Lyubimov wrote:
>>>
>>>> note identical md5 for u200 and u400.
>>>>
>>>> On Thu, Dec 29, 2011 at 12:57 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>> wrote:
>>>>> MD5 sums
>>>>>
>>>>> b8217318a29ef69c58b921013eb019e5
>>> /tmp/matrix8554072597307396201/A-000000000
>>>>> 41db088ff74c5efd5b766dba253efc03
>>> /tmp/matrix8554072597307396201/A-000000200
>>>>> b8217318a29ef69c58b921013eb019e5
>>> /tmp/matrix8554072597307396201/A-000000400
>>>>> 41db088ff74c5efd5b766dba253efc03
>>> /tmp/matrix8554072597307396201/A-000000600
>>>>> c8dc2a7df82065b5c1e8284ff23aecc6
>>> /tmp/matrix8554072597307396201/A-000000800
>>>>> 83bccdd2fa191e01d34646e2030f0e77
>>> /tmp/matrix8554072597307396201/B-000000000
>>>>> 9d6878fb789d61d5453b994ea1a5c6db
>>> /tmp/matrix8554072597307396201/B-000000210
>>>>> cbdf720b17ce25feb686effd1aa0ebef
>>> /tmp/matrix8554072597307396201/B-000000420
>>>>> 2f71d6ba6891b242575b5cc6ba1c4358
>>> /tmp/matrix8554072597307396201/B-000000630
>>>>> f50b76bb48c8f6a791a6d8206d980492
>>> /tmp/matrix8554072597307396201/B-000000840
>>>>> 6bb29ca304889a6c8effff6e5c062dc8 /tmp/matrix8554072597307396201/U-0
>>>>> 019c881c1d7c5748a1cacb3e0b3e5899 /tmp/matrix8554072597307396201/U-200
>>>>> 019c881c1d7c5748a1cacb3e0b3e5899 /tmp/matrix8554072597307396201/U-400
>>>>> b84e4b01ffb9d691c87b496f8b4d84ec /tmp/matrix8554072597307396201/U-600
>>>>> 6bb29ca304889a6c8effff6e5c062dc8 /tmp/matrix8554072597307396201/U-770
>>>>>
>>>>>
>>>>> On Thu, Dec 29, 2011 at 12:52 AM, Ted Dunning <[EMAIL PROTECTED]>
>>> wrote:
>>>>>> Thanks. Good hints.
>>>>>>
>>>>>> I will take a look on a linux machine in the next few days.
>>>>>>
>>>>>> On Thu, Dec 29, 2011 at 12:42 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]
>>>> wrote:
>>>>>>
>>>>>>> yes. i would venture to say that U computation (or restoration) is
>>>>>>> somehow corrupted starting with 2nd block. at least it looks this
>>> way.
>>>>>>>
>>>>>>> On Thu, Dec 29, 2011 at 12:31 AM, Dmitriy Lyubimov <
>>> [EMAIL PROTECTED]>
>>>>>>> wrote:
>>>>>>>> A-reconstructed difference looks good up to row 399 but starting at
>>>>>>>> row 400 differences do not add up to 0 anymore (although both inputs
>>>>>>>> are not 0).
>>>>>>>>
>>>>>>>> So it doesn't look like trivial case of something is not initialized
>>>>>>>> on top of it. It does seem something to do with blocking mechanism
>>>>>>>> though since apparently 400th row is a boundary of some blocking
>>>>>>>> somewhere, but it is hard for me to see where it fails at this
>>> point.
>>>>>>>>
>>>>>>>> On Thu, Dec 29, 2011 at 12:13 AM, Dmitriy Lyubimov <
>>> [EMAIL PROTECTED]>
>>>>>>> wrote:
>>>>>>>>> oh. it's because the synthetic input has only 4 singular values.
>>>>>>>>>
>>>>>>>>> On Wed, Dec 28, 2011 at 11:56 PM, Dmitriy Lyubimov <
>>> [EMAIL PROTECTED]>
>>>>>>> wrote:
>>>>>>>>>> But it is not a problem reading U or V files, that's indeed what
>>> U and
>>>>>>>>>> V contain.
>>>>>>>>>>
>>>>>>>>>> On Wed, Dec 28, 2011 at 11:49 PM, Dmitriy Lyubimov <
>>> [EMAIL PROTECTED]>
>>>>>>> wrote:
>>>>>>>>>>> U and V look suspect, degenerate (only 4 first columns are
>>> nonzero,
>>>>>>>>>>> the rest of matrices are zeros.
>>>>>>>>>>>
Grant Ingersoll
http://www.lucidimagination.com
We are slowing whittling down the 0.6 issues, but this one seems critical.
On Dec 31, 2011, at 8:07 PM, Ted Dunning wrote:
> I have replicated this and applied this patch but the test still fails.
>
> I will take a longer look when I get a chance.
>
> On Sat, Dec 31, 2011 at 3:57 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>
>> I just took a look and found several files not closed issues as Dmitriy
>> mentioned. There might be a buffering difference on Linux versus make.
>>
>> I have a patch to fix this and will test right now on EC2 if I have enough
>> time.
>>
>>
>> On Sat, Dec 31, 2011 at 2:25 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
>>
>>> Any progress on this? Seems like it is a show stopper for code freeze.
>>> On Dec 29, 2011, at 3:58 AM, Dmitriy Lyubimov wrote:
>>>
>>>> note identical md5 for u200 and u400.
>>>>
>>>> On Thu, Dec 29, 2011 at 12:57 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>> wrote:
>>>>> MD5 sums
>>>>>
>>>>> b8217318a29ef69c58b921013eb019e5
>>> /tmp/matrix8554072597307396201/A-000000000
>>>>> 41db088ff74c5efd5b766dba253efc03
>>> /tmp/matrix8554072597307396201/A-000000200
>>>>> b8217318a29ef69c58b921013eb019e5
>>> /tmp/matrix8554072597307396201/A-000000400
>>>>> 41db088ff74c5efd5b766dba253efc03
>>> /tmp/matrix8554072597307396201/A-000000600
>>>>> c8dc2a7df82065b5c1e8284ff23aecc6
>>> /tmp/matrix8554072597307396201/A-000000800
>>>>> 83bccdd2fa191e01d34646e2030f0e77
>>> /tmp/matrix8554072597307396201/B-000000000
>>>>> 9d6878fb789d61d5453b994ea1a5c6db
>>> /tmp/matrix8554072597307396201/B-000000210
>>>>> cbdf720b17ce25feb686effd1aa0ebef
>>> /tmp/matrix8554072597307396201/B-000000420
>>>>> 2f71d6ba6891b242575b5cc6ba1c4358
>>> /tmp/matrix8554072597307396201/B-000000630
>>>>> f50b76bb48c8f6a791a6d8206d980492
>>> /tmp/matrix8554072597307396201/B-000000840
>>>>> 6bb29ca304889a6c8effff6e5c062dc8 /tmp/matrix8554072597307396201/U-0
>>>>> 019c881c1d7c5748a1cacb3e0b3e5899 /tmp/matrix8554072597307396201/U-200
>>>>> 019c881c1d7c5748a1cacb3e0b3e5899 /tmp/matrix8554072597307396201/U-400
>>>>> b84e4b01ffb9d691c87b496f8b4d84ec /tmp/matrix8554072597307396201/U-600
>>>>> 6bb29ca304889a6c8effff6e5c062dc8 /tmp/matrix8554072597307396201/U-770
>>>>>
>>>>>
>>>>> On Thu, Dec 29, 2011 at 12:52 AM, Ted Dunning <[EMAIL PROTECTED]>
>>> wrote:
>>>>>> Thanks. Good hints.
>>>>>>
>>>>>> I will take a look on a linux machine in the next few days.
>>>>>>
>>>>>> On Thu, Dec 29, 2011 at 12:42 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]
>>>> wrote:
>>>>>>
>>>>>>> yes. i would venture to say that U computation (or restoration) is
>>>>>>> somehow corrupted starting with 2nd block. at least it looks this
>>> way.
>>>>>>>
>>>>>>> On Thu, Dec 29, 2011 at 12:31 AM, Dmitriy Lyubimov <
>>> [EMAIL PROTECTED]>
>>>>>>> wrote:
>>>>>>>> A-reconstructed difference looks good up to row 399 but starting at
>>>>>>>> row 400 differences do not add up to 0 anymore (although both inputs
>>>>>>>> are not 0).
>>>>>>>>
>>>>>>>> So it doesn't look like trivial case of something is not initialized
>>>>>>>> on top of it. It does seem something to do with blocking mechanism
>>>>>>>> though since apparently 400th row is a boundary of some blocking
>>>>>>>> somewhere, but it is hard for me to see where it fails at this
>>> point.
>>>>>>>>
>>>>>>>> On Thu, Dec 29, 2011 at 12:13 AM, Dmitriy Lyubimov <
>>> [EMAIL PROTECTED]>
>>>>>>> wrote:
>>>>>>>>> oh. it's because the synthetic input has only 4 singular values.
>>>>>>>>>
>>>>>>>>> On Wed, Dec 28, 2011 at 11:56 PM, Dmitriy Lyubimov <
>>> [EMAIL PROTECTED]>
>>>>>>> wrote:
>>>>>>>>>> But it is not a problem reading U or V files, that's indeed what
>>> U and
>>>>>>>>>> V contain.
>>>>>>>>>>
>>>>>>>>>> On Wed, Dec 28, 2011 at 11:49 PM, Dmitriy Lyubimov <
>>> [EMAIL PROTECTED]>
>>>>>>> wrote:
>>>>>>>>>>> U and V look suspect, degenerate (only 4 first columns are
>>> nonzero,
>>>>>>>>>>> the rest of matrices are zeros.
>>>>>>>>>>>
Grant Ingersoll
http://www.lucidimagination.com
+
Grant Ingersoll 2012-01-06, 14:59
-
Re: Build failed in Jenkins: mahout-nightly #737Ted Dunning 2012-01-06, 15:50
No Joy (no time) yet.
On Fri, Jan 6, 2012 at 6:59 AM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
> Any luck on this, as it is still failing for me on Ubuntu?
>
> We are slowing whittling down the 0.6 issues, but this one seems critical.
>
>
> On Dec 31, 2011, at 8:07 PM, Ted Dunning wrote:
>
> > I have replicated this and applied this patch but the test still fails.
> >
> > I will take a longer look when I get a chance.
> >
> > On Sat, Dec 31, 2011 at 3:57 PM, Ted Dunning <[EMAIL PROTECTED]>
> wrote:
> >
> >> I just took a look and found several files not closed issues as Dmitriy
> >> mentioned. There might be a buffering difference on Linux versus make.
> >>
> >> I have a patch to fix this and will test right now on EC2 if I have
> enough
> >> time.
> >>
> >>
> >> On Sat, Dec 31, 2011 at 2:25 PM, Grant Ingersoll <[EMAIL PROTECTED]
> >wrote:
> >>
> >>> Any progress on this? Seems like it is a show stopper for code freeze.
> >>> On Dec 29, 2011, at 3:58 AM, Dmitriy Lyubimov wrote:
> >>>
> >>>> note identical md5 for u200 and u400.
> >>>>
> >>>> On Thu, Dec 29, 2011 at 12:57 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]
> >
> >>> wrote:
> >>>>> MD5 sums
> >>>>>
> >>>>> b8217318a29ef69c58b921013eb019e5
> >>> /tmp/matrix8554072597307396201/A-000000000
> >>>>> 41db088ff74c5efd5b766dba253efc03
> >>> /tmp/matrix8554072597307396201/A-000000200
> >>>>> b8217318a29ef69c58b921013eb019e5
> >>> /tmp/matrix8554072597307396201/A-000000400
> >>>>> 41db088ff74c5efd5b766dba253efc03
> >>> /tmp/matrix8554072597307396201/A-000000600
> >>>>> c8dc2a7df82065b5c1e8284ff23aecc6
> >>> /tmp/matrix8554072597307396201/A-000000800
> >>>>> 83bccdd2fa191e01d34646e2030f0e77
> >>> /tmp/matrix8554072597307396201/B-000000000
> >>>>> 9d6878fb789d61d5453b994ea1a5c6db
> >>> /tmp/matrix8554072597307396201/B-000000210
> >>>>> cbdf720b17ce25feb686effd1aa0ebef
> >>> /tmp/matrix8554072597307396201/B-000000420
> >>>>> 2f71d6ba6891b242575b5cc6ba1c4358
> >>> /tmp/matrix8554072597307396201/B-000000630
> >>>>> f50b76bb48c8f6a791a6d8206d980492
> >>> /tmp/matrix8554072597307396201/B-000000840
> >>>>> 6bb29ca304889a6c8effff6e5c062dc8 /tmp/matrix8554072597307396201/U-0
> >>>>> 019c881c1d7c5748a1cacb3e0b3e5899
> /tmp/matrix8554072597307396201/U-200
> >>>>> 019c881c1d7c5748a1cacb3e0b3e5899
> /tmp/matrix8554072597307396201/U-400
> >>>>> b84e4b01ffb9d691c87b496f8b4d84ec
> /tmp/matrix8554072597307396201/U-600
> >>>>> 6bb29ca304889a6c8effff6e5c062dc8
> /tmp/matrix8554072597307396201/U-770
> >>>>>
> >>>>>
> >>>>> On Thu, Dec 29, 2011 at 12:52 AM, Ted Dunning <[EMAIL PROTECTED]
> >
> >>> wrote:
> >>>>>> Thanks. Good hints.
> >>>>>>
> >>>>>> I will take a look on a linux machine in the next few days.
> >>>>>>
> >>>>>> On Thu, Dec 29, 2011 at 12:42 AM, Dmitriy Lyubimov <
> [EMAIL PROTECTED]
> >>>> wrote:
> >>>>>>
> >>>>>>> yes. i would venture to say that U computation (or restoration) is
> >>>>>>> somehow corrupted starting with 2nd block. at least it looks this
> >>> way.
> >>>>>>>
> >>>>>>> On Thu, Dec 29, 2011 at 12:31 AM, Dmitriy Lyubimov <
> >>> [EMAIL PROTECTED]>
> >>>>>>> wrote:
> >>>>>>>> A-reconstructed difference looks good up to row 399 but starting
> at
> >>>>>>>> row 400 differences do not add up to 0 anymore (although both
> inputs
> >>>>>>>> are not 0).
> >>>>>>>>
> >>>>>>>> So it doesn't look like trivial case of something is not
> initialized
> >>>>>>>> on top of it. It does seem something to do with blocking mechanism
> >>>>>>>> though since apparently 400th row is a boundary of some blocking
> >>>>>>>> somewhere, but it is hard for me to see where it fails at this
> >>> point.
> >>>>>>>>
> >>>>>>>> On Thu, Dec 29, 2011 at 12:13 AM, Dmitriy Lyubimov <
> >>> [EMAIL PROTECTED]>
> >>>>>>> wrote:
> >>>>>>>>> oh. it's because the synthetic input has only 4 singular values.
> >>>>>>>>>
> >>>>>>>>> On Wed, Dec 28, 2011 at 11:56 PM, Dmitriy Lyubimov <
> >>> [EMAIL PROTECTED]>
> >>>>>>> wrote:
> >>>>>>>>>> But it is not a problem reading U or V files, that's indeed what
On Fri, Jan 6, 2012 at 6:59 AM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
> Any luck on this, as it is still failing for me on Ubuntu?
>
> We are slowing whittling down the 0.6 issues, but this one seems critical.
>
>
> On Dec 31, 2011, at 8:07 PM, Ted Dunning wrote:
>
> > I have replicated this and applied this patch but the test still fails.
> >
> > I will take a longer look when I get a chance.
> >
> > On Sat, Dec 31, 2011 at 3:57 PM, Ted Dunning <[EMAIL PROTECTED]>
> wrote:
> >
> >> I just took a look and found several files not closed issues as Dmitriy
> >> mentioned. There might be a buffering difference on Linux versus make.
> >>
> >> I have a patch to fix this and will test right now on EC2 if I have
> enough
> >> time.
> >>
> >>
> >> On Sat, Dec 31, 2011 at 2:25 PM, Grant Ingersoll <[EMAIL PROTECTED]
> >wrote:
> >>
> >>> Any progress on this? Seems like it is a show stopper for code freeze.
> >>> On Dec 29, 2011, at 3:58 AM, Dmitriy Lyubimov wrote:
> >>>
> >>>> note identical md5 for u200 and u400.
> >>>>
> >>>> On Thu, Dec 29, 2011 at 12:57 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]
> >
> >>> wrote:
> >>>>> MD5 sums
> >>>>>
> >>>>> b8217318a29ef69c58b921013eb019e5
> >>> /tmp/matrix8554072597307396201/A-000000000
> >>>>> 41db088ff74c5efd5b766dba253efc03
> >>> /tmp/matrix8554072597307396201/A-000000200
> >>>>> b8217318a29ef69c58b921013eb019e5
> >>> /tmp/matrix8554072597307396201/A-000000400
> >>>>> 41db088ff74c5efd5b766dba253efc03
> >>> /tmp/matrix8554072597307396201/A-000000600
> >>>>> c8dc2a7df82065b5c1e8284ff23aecc6
> >>> /tmp/matrix8554072597307396201/A-000000800
> >>>>> 83bccdd2fa191e01d34646e2030f0e77
> >>> /tmp/matrix8554072597307396201/B-000000000
> >>>>> 9d6878fb789d61d5453b994ea1a5c6db
> >>> /tmp/matrix8554072597307396201/B-000000210
> >>>>> cbdf720b17ce25feb686effd1aa0ebef
> >>> /tmp/matrix8554072597307396201/B-000000420
> >>>>> 2f71d6ba6891b242575b5cc6ba1c4358
> >>> /tmp/matrix8554072597307396201/B-000000630
> >>>>> f50b76bb48c8f6a791a6d8206d980492
> >>> /tmp/matrix8554072597307396201/B-000000840
> >>>>> 6bb29ca304889a6c8effff6e5c062dc8 /tmp/matrix8554072597307396201/U-0
> >>>>> 019c881c1d7c5748a1cacb3e0b3e5899
> /tmp/matrix8554072597307396201/U-200
> >>>>> 019c881c1d7c5748a1cacb3e0b3e5899
> /tmp/matrix8554072597307396201/U-400
> >>>>> b84e4b01ffb9d691c87b496f8b4d84ec
> /tmp/matrix8554072597307396201/U-600
> >>>>> 6bb29ca304889a6c8effff6e5c062dc8
> /tmp/matrix8554072597307396201/U-770
> >>>>>
> >>>>>
> >>>>> On Thu, Dec 29, 2011 at 12:52 AM, Ted Dunning <[EMAIL PROTECTED]
> >
> >>> wrote:
> >>>>>> Thanks. Good hints.
> >>>>>>
> >>>>>> I will take a look on a linux machine in the next few days.
> >>>>>>
> >>>>>> On Thu, Dec 29, 2011 at 12:42 AM, Dmitriy Lyubimov <
> [EMAIL PROTECTED]
> >>>> wrote:
> >>>>>>
> >>>>>>> yes. i would venture to say that U computation (or restoration) is
> >>>>>>> somehow corrupted starting with 2nd block. at least it looks this
> >>> way.
> >>>>>>>
> >>>>>>> On Thu, Dec 29, 2011 at 12:31 AM, Dmitriy Lyubimov <
> >>> [EMAIL PROTECTED]>
> >>>>>>> wrote:
> >>>>>>>> A-reconstructed difference looks good up to row 399 but starting
> at
> >>>>>>>> row 400 differences do not add up to 0 anymore (although both
> inputs
> >>>>>>>> are not 0).
> >>>>>>>>
> >>>>>>>> So it doesn't look like trivial case of something is not
> initialized
> >>>>>>>> on top of it. It does seem something to do with blocking mechanism
> >>>>>>>> though since apparently 400th row is a boundary of some blocking
> >>>>>>>> somewhere, but it is hard for me to see where it fails at this
> >>> point.
> >>>>>>>>
> >>>>>>>> On Thu, Dec 29, 2011 at 12:13 AM, Dmitriy Lyubimov <
> >>> [EMAIL PROTECTED]>
> >>>>>>> wrote:
> >>>>>>>>> oh. it's because the synthetic input has only 4 singular values.
> >>>>>>>>>
> >>>>>>>>> On Wed, Dec 28, 2011 at 11:56 PM, Dmitriy Lyubimov <
> >>> [EMAIL PROTECTED]>
> >>>>>>> wrote:
> >>>>>>>>>> But it is not a problem reading U or V files, that's indeed what
+
Ted Dunning 2012-01-06, 15:50
-
Re: Build failed in Jenkins: Mahout-Quality #1237Grant Ingersoll 2011-12-08, 13:20
Looking into it...
On Dec 8, 2011, at 7:37 AM, Apache Jenkins Server wrote:
> See <https://builds.apache.org/job/Mahout-Quality/1237/changes>
>
> Changes:
>
> [gsingers] MAHOUT-688: fix dropping of maxDFPercent
>
> [gsingers] MAHOUT-837: make ASF examples HDFS aware
>
> ------------------------------------------
> [...truncated 32831 lines...]
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.489 sec
> Running org.apache.mahout.cf.taste.common.CommonTest
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
> Running org.apache.mahout.cf.taste.hadoop.item.ToUserVectorsReducerTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec
> Running org.apache.mahout.cf.taste.hadoop.item.RecommenderJobTest
> Tests run: 21, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 229.761 sec
> Running org.apache.mahout.cf.taste.hadoop.similarity.item.ItemSimilarityJobTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 98.343 sec
> Running org.apache.mahout.cf.taste.hadoop.als.ParallelALSFactorizationJobTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 122.754 sec
> Running org.apache.mahout.cf.taste.impl.common.RefreshHelperTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
> Running org.apache.mahout.cf.taste.impl.common.InvertedRunningAverageTest
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
> Running org.apache.mahout.cf.taste.impl.common.CacheTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.7 sec
> Running org.apache.mahout.cf.taste.impl.common.RunningAverageTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
> Running org.apache.mahout.cf.taste.impl.common.FastMapTest
> Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.314 sec
> Running org.apache.mahout.cf.taste.impl.common.BitSetTest
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
> Running org.apache.mahout.cf.taste.impl.common.FastByIDMapTest
> Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.287 sec
> Running org.apache.mahout.cf.taste.impl.common.LongPrimitiveArrayIteratorTest
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
> Running org.apache.mahout.cf.taste.impl.common.WeightedRunningAverageTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
> Running org.apache.mahout.cf.taste.impl.common.RunningAverageAndStdDevTest
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 sec
> Running org.apache.mahout.cf.taste.impl.common.FastIDSetTest
> Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.303 sec
> Running org.apache.mahout.cf.taste.impl.common.SamplingLongPrimitiveIteratorTest
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
> Running org.apache.mahout.cf.taste.impl.model.BooleanUserPreferenceArrayTest
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
> Running org.apache.mahout.cf.taste.impl.model.BooleanItemPreferenceArrayTest
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
> Running org.apache.mahout.cf.taste.impl.model.GenericDataModelTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec
> Running org.apache.mahout.cf.taste.impl.model.GenericUserPreferenceArrayTest
> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
> Running org.apache.mahout.cf.taste.impl.model.MemoryIDMigratorTest
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
> Running org.apache.mahout.cf.taste.impl.model.GenericItemPreferenceArrayTest
> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
> Running org.apache.mahout.cf.taste.impl.model.file.FileDataModelTest
> Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.056 sec
> Running org.apache.mahout.cf.taste.impl.model.file.FileIDMigratorTest
Grant Ingersoll
http://www.lucidimagination.com
On Dec 8, 2011, at 7:37 AM, Apache Jenkins Server wrote:
> See <https://builds.apache.org/job/Mahout-Quality/1237/changes>
>
> Changes:
>
> [gsingers] MAHOUT-688: fix dropping of maxDFPercent
>
> [gsingers] MAHOUT-837: make ASF examples HDFS aware
>
> ------------------------------------------
> [...truncated 32831 lines...]
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.489 sec
> Running org.apache.mahout.cf.taste.common.CommonTest
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
> Running org.apache.mahout.cf.taste.hadoop.item.ToUserVectorsReducerTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec
> Running org.apache.mahout.cf.taste.hadoop.item.RecommenderJobTest
> Tests run: 21, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 229.761 sec
> Running org.apache.mahout.cf.taste.hadoop.similarity.item.ItemSimilarityJobTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 98.343 sec
> Running org.apache.mahout.cf.taste.hadoop.als.ParallelALSFactorizationJobTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 122.754 sec
> Running org.apache.mahout.cf.taste.impl.common.RefreshHelperTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
> Running org.apache.mahout.cf.taste.impl.common.InvertedRunningAverageTest
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
> Running org.apache.mahout.cf.taste.impl.common.CacheTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.7 sec
> Running org.apache.mahout.cf.taste.impl.common.RunningAverageTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
> Running org.apache.mahout.cf.taste.impl.common.FastMapTest
> Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.314 sec
> Running org.apache.mahout.cf.taste.impl.common.BitSetTest
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
> Running org.apache.mahout.cf.taste.impl.common.FastByIDMapTest
> Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.287 sec
> Running org.apache.mahout.cf.taste.impl.common.LongPrimitiveArrayIteratorTest
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
> Running org.apache.mahout.cf.taste.impl.common.WeightedRunningAverageTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
> Running org.apache.mahout.cf.taste.impl.common.RunningAverageAndStdDevTest
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 sec
> Running org.apache.mahout.cf.taste.impl.common.FastIDSetTest
> Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.303 sec
> Running org.apache.mahout.cf.taste.impl.common.SamplingLongPrimitiveIteratorTest
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
> Running org.apache.mahout.cf.taste.impl.model.BooleanUserPreferenceArrayTest
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
> Running org.apache.mahout.cf.taste.impl.model.BooleanItemPreferenceArrayTest
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
> Running org.apache.mahout.cf.taste.impl.model.GenericDataModelTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec
> Running org.apache.mahout.cf.taste.impl.model.GenericUserPreferenceArrayTest
> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
> Running org.apache.mahout.cf.taste.impl.model.MemoryIDMigratorTest
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
> Running org.apache.mahout.cf.taste.impl.model.GenericItemPreferenceArrayTest
> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
> Running org.apache.mahout.cf.taste.impl.model.file.FileDataModelTest
> Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.056 sec
> Running org.apache.mahout.cf.taste.impl.model.file.FileIDMigratorTest
Grant Ingersoll
http://www.lucidimagination.com
+
Grant Ingersoll 2011-12-08, 13:20
-
Re: Build failed in Jenkins: Mahout-Quality #1237Grant Ingersoll 2011-12-08, 19:35
Should be fixed. Just when you think a change is isolated so you skip the full tests...
On Dec 8, 2011, at 8:20 AM, Grant Ingersoll wrote:
> Looking into it...
>
> On Dec 8, 2011, at 7:37 AM, Apache Jenkins Server wrote:
>
>> See <https://builds.apache.org/job/Mahout-Quality/1237/changes>
>>
>> Changes:
>>
>> [gsingers] MAHOUT-688: fix dropping of maxDFPercent
>>
>> [gsingers] MAHOUT-837: make ASF examples HDFS aware
>>
>> ------------------------------------------
>> [...truncated 32831 lines...]
>> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.489 sec
>> Running org.apache.mahout.cf.taste.common.CommonTest
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
>> Running org.apache.mahout.cf.taste.hadoop.item.ToUserVectorsReducerTest
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec
>> Running org.apache.mahout.cf.taste.hadoop.item.RecommenderJobTest
>> Tests run: 21, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 229.761 sec
>> Running org.apache.mahout.cf.taste.hadoop.similarity.item.ItemSimilarityJobTest
>> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 98.343 sec
>> Running org.apache.mahout.cf.taste.hadoop.als.ParallelALSFactorizationJobTest
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 122.754 sec
>> Running org.apache.mahout.cf.taste.impl.common.RefreshHelperTest
>> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
>> Running org.apache.mahout.cf.taste.impl.common.InvertedRunningAverageTest
>> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
>> Running org.apache.mahout.cf.taste.impl.common.CacheTest
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.7 sec
>> Running org.apache.mahout.cf.taste.impl.common.RunningAverageTest
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
>> Running org.apache.mahout.cf.taste.impl.common.FastMapTest
>> Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.314 sec
>> Running org.apache.mahout.cf.taste.impl.common.BitSetTest
>> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
>> Running org.apache.mahout.cf.taste.impl.common.FastByIDMapTest
>> Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.287 sec
>> Running org.apache.mahout.cf.taste.impl.common.LongPrimitiveArrayIteratorTest
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
>> Running org.apache.mahout.cf.taste.impl.common.WeightedRunningAverageTest
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
>> Running org.apache.mahout.cf.taste.impl.common.RunningAverageAndStdDevTest
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 sec
>> Running org.apache.mahout.cf.taste.impl.common.FastIDSetTest
>> Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.303 sec
>> Running org.apache.mahout.cf.taste.impl.common.SamplingLongPrimitiveIteratorTest
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
>> Running org.apache.mahout.cf.taste.impl.model.BooleanUserPreferenceArrayTest
>> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
>> Running org.apache.mahout.cf.taste.impl.model.BooleanItemPreferenceArrayTest
>> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
>> Running org.apache.mahout.cf.taste.impl.model.GenericDataModelTest
>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec
>> Running org.apache.mahout.cf.taste.impl.model.GenericUserPreferenceArrayTest
>> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
>> Running org.apache.mahout.cf.taste.impl.model.MemoryIDMigratorTest
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
>> Running org.apache.mahout.cf.taste.impl.model.GenericItemPreferenceArrayTest
>> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
Grant Ingersoll
http://www.lucidimagination.com
On Dec 8, 2011, at 8:20 AM, Grant Ingersoll wrote:
> Looking into it...
>
> On Dec 8, 2011, at 7:37 AM, Apache Jenkins Server wrote:
>
>> See <https://builds.apache.org/job/Mahout-Quality/1237/changes>
>>
>> Changes:
>>
>> [gsingers] MAHOUT-688: fix dropping of maxDFPercent
>>
>> [gsingers] MAHOUT-837: make ASF examples HDFS aware
>>
>> ------------------------------------------
>> [...truncated 32831 lines...]
>> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.489 sec
>> Running org.apache.mahout.cf.taste.common.CommonTest
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
>> Running org.apache.mahout.cf.taste.hadoop.item.ToUserVectorsReducerTest
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec
>> Running org.apache.mahout.cf.taste.hadoop.item.RecommenderJobTest
>> Tests run: 21, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 229.761 sec
>> Running org.apache.mahout.cf.taste.hadoop.similarity.item.ItemSimilarityJobTest
>> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 98.343 sec
>> Running org.apache.mahout.cf.taste.hadoop.als.ParallelALSFactorizationJobTest
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 122.754 sec
>> Running org.apache.mahout.cf.taste.impl.common.RefreshHelperTest
>> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
>> Running org.apache.mahout.cf.taste.impl.common.InvertedRunningAverageTest
>> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
>> Running org.apache.mahout.cf.taste.impl.common.CacheTest
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.7 sec
>> Running org.apache.mahout.cf.taste.impl.common.RunningAverageTest
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
>> Running org.apache.mahout.cf.taste.impl.common.FastMapTest
>> Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.314 sec
>> Running org.apache.mahout.cf.taste.impl.common.BitSetTest
>> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
>> Running org.apache.mahout.cf.taste.impl.common.FastByIDMapTest
>> Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.287 sec
>> Running org.apache.mahout.cf.taste.impl.common.LongPrimitiveArrayIteratorTest
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
>> Running org.apache.mahout.cf.taste.impl.common.WeightedRunningAverageTest
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
>> Running org.apache.mahout.cf.taste.impl.common.RunningAverageAndStdDevTest
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 sec
>> Running org.apache.mahout.cf.taste.impl.common.FastIDSetTest
>> Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.303 sec
>> Running org.apache.mahout.cf.taste.impl.common.SamplingLongPrimitiveIteratorTest
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
>> Running org.apache.mahout.cf.taste.impl.model.BooleanUserPreferenceArrayTest
>> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
>> Running org.apache.mahout.cf.taste.impl.model.BooleanItemPreferenceArrayTest
>> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
>> Running org.apache.mahout.cf.taste.impl.model.GenericDataModelTest
>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec
>> Running org.apache.mahout.cf.taste.impl.model.GenericUserPreferenceArrayTest
>> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
>> Running org.apache.mahout.cf.taste.impl.model.MemoryIDMigratorTest
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
>> Running org.apache.mahout.cf.taste.impl.model.GenericItemPreferenceArrayTest
>> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
Grant Ingersoll
http://www.lucidimagination.com
+
Grant Ingersoll 2011-12-08, 19:35
-
Re: Build failed in Jenkins: mahout-nightly #737Jeff Eastman 2011-12-28, 03:34
I'm getting a lot of these emails yet all the tests run locally for me.
Does anybody have an idea what the problem is? This close to a release
it would be really nice to have Jenkins on our side.
Jeff
On 12/27/11 4:54 PM, Apache Jenkins Server wrote:
> See<https://builds.apache.org/job/mahout-nightly/737/>
>
> ------------------------------------------
> [...truncated 2536 lines...]
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec
> Running org.apache.mahout.classifier.naivebayes.training.IndexInstancesMapperTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
> Running org.apache.mahout.classifier.naivebayes.training.ThetaMapperTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec
> Running org.apache.mahout.classifier.naivebayes.training.WeightsMapperTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec
> Running org.apache.mahout.classifier.bayes.BayesFeatureMapperTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.064 sec
> Running org.apache.mahout.classifier.bayes.BayesClassifierSelfTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 85.86 sec
> Running org.apache.mahout.classifier.bayes.BayesFeatureMapReduceTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.11 sec
> Running org.apache.mahout.classifier.bayes.BayesFileFormatterTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec
> Running org.apache.mahout.classifier.bayes.BayesClassifierTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
> Running org.apache.mahout.classifier.bayes.CBayesClassifierTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
> Running org.apache.mahout.classifier.evaluation.AucTest
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.185 sec
> Running org.apache.mahout.classifier.discriminative.WinnowTrainerTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
> Running org.apache.mahout.classifier.discriminative.PerceptronTrainerTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
> Running org.apache.mahout.classifier.discriminative.LinearModelTest
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
> Running org.apache.mahout.clustering.kmeans.TestKmeansClustering
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 244.039 sec
> Running org.apache.mahout.clustering.kmeans.TestRandomSeedGenerator
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec
> Running org.apache.mahout.clustering.TestClusterInterface
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
> Running org.apache.mahout.clustering.TestClusterClassifier
> Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.077 sec
> Running org.apache.mahout.clustering.lda.TestLDAInference
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.166 sec
> Running org.apache.mahout.clustering.lda.TestMapReduce
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0.059 sec
> Running org.apache.mahout.clustering.lda.cvb.TestCVBModelTrainer
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 233.081 sec
> Running org.apache.mahout.clustering.TestGaussianAccumulators
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.912 sec
> Running org.apache.mahout.clustering.spectral.common.TestAffinityMatrixInputJob
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
> Running org.apache.mahout.clustering.spectral.common.TestVectorCache
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 sec
> Running org.apache.mahout.clustering.spectral.common.TestUnitVectorizerJob
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec
> Running org.apache.mahout.clustering.spectral.common.TestMatrixDiagonalizeJob
Does anybody have an idea what the problem is? This close to a release
it would be really nice to have Jenkins on our side.
Jeff
On 12/27/11 4:54 PM, Apache Jenkins Server wrote:
> See<https://builds.apache.org/job/mahout-nightly/737/>
>
> ------------------------------------------
> [...truncated 2536 lines...]
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec
> Running org.apache.mahout.classifier.naivebayes.training.IndexInstancesMapperTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
> Running org.apache.mahout.classifier.naivebayes.training.ThetaMapperTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec
> Running org.apache.mahout.classifier.naivebayes.training.WeightsMapperTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec
> Running org.apache.mahout.classifier.bayes.BayesFeatureMapperTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.064 sec
> Running org.apache.mahout.classifier.bayes.BayesClassifierSelfTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 85.86 sec
> Running org.apache.mahout.classifier.bayes.BayesFeatureMapReduceTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.11 sec
> Running org.apache.mahout.classifier.bayes.BayesFileFormatterTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec
> Running org.apache.mahout.classifier.bayes.BayesClassifierTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
> Running org.apache.mahout.classifier.bayes.CBayesClassifierTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
> Running org.apache.mahout.classifier.evaluation.AucTest
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.185 sec
> Running org.apache.mahout.classifier.discriminative.WinnowTrainerTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
> Running org.apache.mahout.classifier.discriminative.PerceptronTrainerTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
> Running org.apache.mahout.classifier.discriminative.LinearModelTest
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
> Running org.apache.mahout.clustering.kmeans.TestKmeansClustering
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 244.039 sec
> Running org.apache.mahout.clustering.kmeans.TestRandomSeedGenerator
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec
> Running org.apache.mahout.clustering.TestClusterInterface
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
> Running org.apache.mahout.clustering.TestClusterClassifier
> Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.077 sec
> Running org.apache.mahout.clustering.lda.TestLDAInference
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.166 sec
> Running org.apache.mahout.clustering.lda.TestMapReduce
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0.059 sec
> Running org.apache.mahout.clustering.lda.cvb.TestCVBModelTrainer
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 233.081 sec
> Running org.apache.mahout.clustering.TestGaussianAccumulators
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.912 sec
> Running org.apache.mahout.clustering.spectral.common.TestAffinityMatrixInputJob
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
> Running org.apache.mahout.clustering.spectral.common.TestVectorCache
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 sec
> Running org.apache.mahout.clustering.spectral.common.TestUnitVectorizerJob
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec
> Running org.apache.mahout.clustering.spectral.common.TestMatrixDiagonalizeJob
+
Jeff Eastman 2011-12-28, 03:34
-
Re: Build failed in Jenkins: mahout-nightly #737Grant Ingersoll 2011-12-28, 12:33
I'm seeing this pretty consistently on my Jenkins locally, but then when I run on my Mac, it passes.
On Dec 27, 2011, at 10:34 PM, Jeff Eastman wrote:
> I'm getting a lot of these emails yet all the tests run locally for me. Does anybody have an idea what the problem is? This close to a release it would be really nice to have Jenkins on our side.
> Jeff
>
>
> On 12/27/11 4:54 PM, Apache Jenkins Server wrote:
>> See<https://builds.apache.org/job/mahout-nightly/737/>
>>
>> ------------------------------------------
>> [...truncated 2536 lines...]
>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec
>> Running org.apache.mahout.classifier.naivebayes.training.IndexInstancesMapperTest
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
>> Running org.apache.mahout.classifier.naivebayes.training.ThetaMapperTest
>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec
>> Running org.apache.mahout.classifier.naivebayes.training.WeightsMapperTest
>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec
>> Running org.apache.mahout.classifier.bayes.BayesFeatureMapperTest
>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.064 sec
>> Running org.apache.mahout.classifier.bayes.BayesClassifierSelfTest
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 85.86 sec
>> Running org.apache.mahout.classifier.bayes.BayesFeatureMapReduceTest
>> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.11 sec
>> Running org.apache.mahout.classifier.bayes.BayesFileFormatterTest
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec
>> Running org.apache.mahout.classifier.bayes.BayesClassifierTest
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
>> Running org.apache.mahout.classifier.bayes.CBayesClassifierTest
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
>> Running org.apache.mahout.classifier.evaluation.AucTest
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.185 sec
>> Running org.apache.mahout.classifier.discriminative.WinnowTrainerTest
>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
>> Running org.apache.mahout.classifier.discriminative.PerceptronTrainerTest
>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
>> Running org.apache.mahout.classifier.discriminative.LinearModelTest
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
>> Running org.apache.mahout.clustering.kmeans.TestKmeansClustering
>> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 244.039 sec
>> Running org.apache.mahout.clustering.kmeans.TestRandomSeedGenerator
>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec
>> Running org.apache.mahout.clustering.TestClusterInterface
>> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
>> Running org.apache.mahout.clustering.TestClusterClassifier
>> Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.077 sec
>> Running org.apache.mahout.clustering.lda.TestLDAInference
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.166 sec
>> Running org.apache.mahout.clustering.lda.TestMapReduce
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0.059 sec
>> Running org.apache.mahout.clustering.lda.cvb.TestCVBModelTrainer
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 233.081 sec
>> Running org.apache.mahout.clustering.TestGaussianAccumulators
>> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.912 sec
>> Running org.apache.mahout.clustering.spectral.common.TestAffinityMatrixInputJob
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
>> Running org.apache.mahout.clustering.spectral.common.TestVectorCache
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 sec
Grant Ingersoll
http://www.lucidimagination.com
On Dec 27, 2011, at 10:34 PM, Jeff Eastman wrote:
> I'm getting a lot of these emails yet all the tests run locally for me. Does anybody have an idea what the problem is? This close to a release it would be really nice to have Jenkins on our side.
> Jeff
>
>
> On 12/27/11 4:54 PM, Apache Jenkins Server wrote:
>> See<https://builds.apache.org/job/mahout-nightly/737/>
>>
>> ------------------------------------------
>> [...truncated 2536 lines...]
>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec
>> Running org.apache.mahout.classifier.naivebayes.training.IndexInstancesMapperTest
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
>> Running org.apache.mahout.classifier.naivebayes.training.ThetaMapperTest
>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec
>> Running org.apache.mahout.classifier.naivebayes.training.WeightsMapperTest
>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec
>> Running org.apache.mahout.classifier.bayes.BayesFeatureMapperTest
>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.064 sec
>> Running org.apache.mahout.classifier.bayes.BayesClassifierSelfTest
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 85.86 sec
>> Running org.apache.mahout.classifier.bayes.BayesFeatureMapReduceTest
>> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.11 sec
>> Running org.apache.mahout.classifier.bayes.BayesFileFormatterTest
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec
>> Running org.apache.mahout.classifier.bayes.BayesClassifierTest
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
>> Running org.apache.mahout.classifier.bayes.CBayesClassifierTest
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
>> Running org.apache.mahout.classifier.evaluation.AucTest
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.185 sec
>> Running org.apache.mahout.classifier.discriminative.WinnowTrainerTest
>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
>> Running org.apache.mahout.classifier.discriminative.PerceptronTrainerTest
>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
>> Running org.apache.mahout.classifier.discriminative.LinearModelTest
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
>> Running org.apache.mahout.clustering.kmeans.TestKmeansClustering
>> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 244.039 sec
>> Running org.apache.mahout.clustering.kmeans.TestRandomSeedGenerator
>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec
>> Running org.apache.mahout.clustering.TestClusterInterface
>> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
>> Running org.apache.mahout.clustering.TestClusterClassifier
>> Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.077 sec
>> Running org.apache.mahout.clustering.lda.TestLDAInference
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.166 sec
>> Running org.apache.mahout.clustering.lda.TestMapReduce
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0.059 sec
>> Running org.apache.mahout.clustering.lda.cvb.TestCVBModelTrainer
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 233.081 sec
>> Running org.apache.mahout.clustering.TestGaussianAccumulators
>> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.912 sec
>> Running org.apache.mahout.clustering.spectral.common.TestAffinityMatrixInputJob
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
>> Running org.apache.mahout.clustering.spectral.common.TestVectorCache
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 sec
Grant Ingersoll
http://www.lucidimagination.com
+
Grant Ingersoll 2011-12-28, 12:33
-
Re: Build failed in Jenkins: mahout-nightly #737Sean Owen 2011-12-28, 04:53
It's all errors in the Apache infrastructure, rather than a real test
failure. At least, stuff passes for me locally, and that's what's
important.
So I'm ignoring these.
On Tue, Dec 27, 2011 at 9:34 PM, Jeff Eastman
<[EMAIL PROTECTED]> wrote:
> I'm getting a lot of these emails yet all the tests run locally for me. Does
> anybody have an idea what the problem is? This close to a release it would
> be really nice to have Jenkins on our side.
> Jeff
>
failure. At least, stuff passes for me locally, and that's what's
important.
So I'm ignoring these.
On Tue, Dec 27, 2011 at 9:34 PM, Jeff Eastman
<[EMAIL PROTECTED]> wrote:
> I'm getting a lot of these emails yet all the tests run locally for me. Does
> anybody have an idea what the problem is? This close to a release it would
> be really nice to have Jenkins on our side.
> Jeff
>
+
Sean Owen 2011-12-28, 04:53
-
Re: Build failed in Jenkins: mahout-nightly #737Jeff Eastman 2011-12-28, 05:30
+infra@
Well, yes, I guess everybody is ignoring them. But that kinda begs the
question of why we even bother to have Jenkins if we are going to always
ignore its warnings? I'm a big fan of continuous integration and I've
managed its administration before so I understand the challenges. But
this seems kinda goofy to me.
On 12/27/11 9:53 PM, Sean Owen wrote:
> It's all errors in the Apache infrastructure, rather than a real test
> failure. At least, stuff passes for me locally, and that's what's
> important.
> So I'm ignoring these.
>
> On Tue, Dec 27, 2011 at 9:34 PM, Jeff Eastman
> <[EMAIL PROTECTED]> wrote:
>> I'm getting a lot of these emails yet all the tests run locally for me. Does
>> anybody have an idea what the problem is? This close to a release it would
>> be really nice to have Jenkins on our side.
>> Jeff
>>
>
Well, yes, I guess everybody is ignoring them. But that kinda begs the
question of why we even bother to have Jenkins if we are going to always
ignore its warnings? I'm a big fan of continuous integration and I've
managed its administration before so I understand the challenges. But
this seems kinda goofy to me.
On 12/27/11 9:53 PM, Sean Owen wrote:
> It's all errors in the Apache infrastructure, rather than a real test
> failure. At least, stuff passes for me locally, and that's what's
> important.
> So I'm ignoring these.
>
> On Tue, Dec 27, 2011 at 9:34 PM, Jeff Eastman
> <[EMAIL PROTECTED]> wrote:
>> I'm getting a lot of these emails yet all the tests run locally for me. Does
>> anybody have an idea what the problem is? This close to a release it would
>> be really nice to have Jenkins on our side.
>> Jeff
>>
>
+
Jeff Eastman 2011-12-28, 05:30
-
RE: Build failed in Jenkins: mahout-nightly #737Gavin McDonald 2011-12-28, 06:06
> -----Original Message-----
> From: Jeff Eastman [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, 28 December 2011 3:31 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Build failed in Jenkins: mahout-nightly #737
>
> +infra@
All build related questions should go to the [EMAIL PROTECTED] list.
>
> Well, yes, I guess everybody is ignoring them. But that kinda begs the
> question of why we even bother to have Jenkins if we are going to always
> ignore its warnings? I'm a big fan of continuous integration and I've managed
> its administration before so I understand the challenges. But this seems
> kinda goofy to me.
It is not up to infra to check projects failed builds! It is up to the project.
It is also up to the project to configure their Jenkins configs.
Now, if the project needs any pre-reqs installed on any slaves to help make the
build pass, by all means ask the builds@ list, otherwise what are we infra expected to
do?
If Jenkins isn’t working out for you, maybe try Buildbot or Continuum , see
ci.apache.org for more.
Gav...
>
>
> On 12/27/11 9:53 PM, Sean Owen wrote:
> > It's all errors in the Apache infrastructure, rather than a real test
> > failure. At least, stuff passes for me locally, and that's what's
> > important.
> > So I'm ignoring these.
> >
> > On Tue, Dec 27, 2011 at 9:34 PM, Jeff Eastman
> > <[EMAIL PROTECTED]> wrote:
> >> I'm getting a lot of these emails yet all the tests run locally for
> >> me. Does anybody have an idea what the problem is? This close to a
> >> release it would be really nice to have Jenkins on our side.
> >> Jeff
> >>
> >
+
Gavin McDonald 2011-12-28, 06:06
-
Re: Build failed in Jenkins: mahout-nightly #737Dmitriy Lyubimov 2011-12-28, 06:06
Ted,
do you have an idea why this test may be failing? I think this test comes
with M-792 commit.
I can take a look at it, I suspect something in the environment can be
tripping it.
On Dec 27, 2011 8:54 PM, "Sean Owen" <[EMAIL PROTECTED]> wrote:
> It's all errors in the Apache infrastructure, rather than a real test
> failure. At least, stuff passes for me locally, and that's what's
> important.
> So I'm ignoring these.
>
> On Tue, Dec 27, 2011 at 9:34 PM, Jeff Eastman
> <[EMAIL PROTECTED]> wrote:
> > I'm getting a lot of these emails yet all the tests run locally for me.
> Does
> > anybody have an idea what the problem is? This close to a release it
> would
> > be really nice to have Jenkins on our side.
> > Jeff
> >
>
do you have an idea why this test may be failing? I think this test comes
with M-792 commit.
I can take a look at it, I suspect something in the environment can be
tripping it.
On Dec 27, 2011 8:54 PM, "Sean Owen" <[EMAIL PROTECTED]> wrote:
> It's all errors in the Apache infrastructure, rather than a real test
> failure. At least, stuff passes for me locally, and that's what's
> important.
> So I'm ignoring these.
>
> On Tue, Dec 27, 2011 at 9:34 PM, Jeff Eastman
> <[EMAIL PROTECTED]> wrote:
> > I'm getting a lot of these emails yet all the tests run locally for me.
> Does
> > anybody have an idea what the problem is? This close to a release it
> would
> > be really nice to have Jenkins on our side.
> > Jeff
> >
>
+
Dmitriy Lyubimov 2011-12-28, 06:06
-
Re: Build failed in Jenkins: mahout-nightly #737Ted Dunning 2011-12-28, 06:37
Indeed it does. Thanks for pointing that out.
This error is very strange.
On Tue, Dec 27, 2011 at 10:06 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>wrote:
> Ted,
>
> do you have an idea why this test may be failing? I think this test comes
> with M-792 commit.
>
> I can take a look at it, I suspect something in the environment can be
> tripping it.
> On Dec 27, 2011 8:54 PM, "Sean Owen" <[EMAIL PROTECTED]> wrote:
>
> > It's all errors in the Apache infrastructure, rather than a real test
> > failure. At least, stuff passes for me locally, and that's what's
> > important.
> > So I'm ignoring these.
> >
> > On Tue, Dec 27, 2011 at 9:34 PM, Jeff Eastman
> > <[EMAIL PROTECTED]> wrote:
> > > I'm getting a lot of these emails yet all the tests run locally for me.
> > Does
> > > anybody have an idea what the problem is? This close to a release it
> > would
> > > be really nice to have Jenkins on our side.
> > > Jeff
> > >
> >
>
This error is very strange.
On Tue, Dec 27, 2011 at 10:06 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>wrote:
> Ted,
>
> do you have an idea why this test may be failing? I think this test comes
> with M-792 commit.
>
> I can take a look at it, I suspect something in the environment can be
> tripping it.
> On Dec 27, 2011 8:54 PM, "Sean Owen" <[EMAIL PROTECTED]> wrote:
>
> > It's all errors in the Apache infrastructure, rather than a real test
> > failure. At least, stuff passes for me locally, and that's what's
> > important.
> > So I'm ignoring these.
> >
> > On Tue, Dec 27, 2011 at 9:34 PM, Jeff Eastman
> > <[EMAIL PROTECTED]> wrote:
> > > I'm getting a lot of these emails yet all the tests run locally for me.
> > Does
> > > anybody have an idea what the problem is? This close to a release it
> > would
> > > be really nice to have Jenkins on our side.
> > > Jeff
> > >
> >
>
+
Ted Dunning 2011-12-28, 06:37
-
Re: Build failed in Jenkins: mahout-nightly #737Ted Dunning 2011-12-28, 06:49
So I am like everybody else. The test works for me.
My suspicion is that there is something going on with the temporary
directory that I am trying to use and that the environment that Jenkins is
using is somehow strange.
The only slightly surprising idiom I am using is to create a temporary
file, delete it and recreate it as a directory. I even check the return
values from the delete and the mkdir.
I will keep looking.
On Tue, Dec 27, 2011 at 10:37 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
> Indeed it does. Thanks for pointing that out.
>
> This error is very strange.
>
>
> On Tue, Dec 27, 2011 at 10:06 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>wrote:
>
>> Ted,
>>
>> do you have an idea why this test may be failing? I think this test comes
>> with M-792 commit.
>>
>> I can take a look at it, I suspect something in the environment can be
>> tripping it.
>> On Dec 27, 2011 8:54 PM, "Sean Owen" <[EMAIL PROTECTED]> wrote:
>>
>> > It's all errors in the Apache infrastructure, rather than a real test
>> > failure. At least, stuff passes for me locally, and that's what's
>> > important.
>> > So I'm ignoring these.
>> >
>> > On Tue, Dec 27, 2011 at 9:34 PM, Jeff Eastman
>> > <[EMAIL PROTECTED]> wrote:
>> > > I'm getting a lot of these emails yet all the tests run locally for
>> me.
>> > Does
>> > > anybody have an idea what the problem is? This close to a release it
>> > would
>> > > be really nice to have Jenkins on our side.
>> > > Jeff
>> > >
>> >
>>
>
>
My suspicion is that there is something going on with the temporary
directory that I am trying to use and that the environment that Jenkins is
using is somehow strange.
The only slightly surprising idiom I am using is to create a temporary
file, delete it and recreate it as a directory. I even check the return
values from the delete and the mkdir.
I will keep looking.
On Tue, Dec 27, 2011 at 10:37 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
> Indeed it does. Thanks for pointing that out.
>
> This error is very strange.
>
>
> On Tue, Dec 27, 2011 at 10:06 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>wrote:
>
>> Ted,
>>
>> do you have an idea why this test may be failing? I think this test comes
>> with M-792 commit.
>>
>> I can take a look at it, I suspect something in the environment can be
>> tripping it.
>> On Dec 27, 2011 8:54 PM, "Sean Owen" <[EMAIL PROTECTED]> wrote:
>>
>> > It's all errors in the Apache infrastructure, rather than a real test
>> > failure. At least, stuff passes for me locally, and that's what's
>> > important.
>> > So I'm ignoring these.
>> >
>> > On Tue, Dec 27, 2011 at 9:34 PM, Jeff Eastman
>> > <[EMAIL PROTECTED]> wrote:
>> > > I'm getting a lot of these emails yet all the tests run locally for
>> me.
>> > Does
>> > > anybody have an idea what the problem is? This close to a release it
>> > would
>> > > be really nice to have Jenkins on our side.
>> > > Jeff
>> > >
>> >
>>
>
>
+
Ted Dunning 2011-12-28, 06:49
-
Re: Build failed in Jenkins: mahout-nightly #737Dmitriy Lyubimov 2011-12-28, 07:15
I vaguely remember Jenkins had problems with creating stuff in Java tmp
dir. E.g. I remember that was creating problems for Mr tasks in local mr
mode legitimately using boxed task temporary space.
OK I'll try to scan for the problem tomorrow.
On Dec 27, 2011 10:50 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
> So I am like everybody else. The test works for me.
>
> My suspicion is that there is something going on with the temporary
> directory that I am trying to use and that the environment that Jenkins is
> using is somehow strange.
>
> The only slightly surprising idiom I am using is to create a temporary
> file, delete it and recreate it as a directory. I even check the return
> values from the delete and the mkdir.
>
> I will keep looking.
>
> On Tue, Dec 27, 2011 at 10:37 PM, Ted Dunning <[EMAIL PROTECTED]>
> wrote:
>
> > Indeed it does. Thanks for pointing that out.
> >
> > This error is very strange.
> >
> >
> > On Tue, Dec 27, 2011 at 10:06 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]
> >wrote:
> >
> >> Ted,
> >>
> >> do you have an idea why this test may be failing? I think this test
> comes
> >> with M-792 commit.
> >>
> >> I can take a look at it, I suspect something in the environment can be
> >> tripping it.
> >> On Dec 27, 2011 8:54 PM, "Sean Owen" <[EMAIL PROTECTED]> wrote:
> >>
> >> > It's all errors in the Apache infrastructure, rather than a real test
> >> > failure. At least, stuff passes for me locally, and that's what's
> >> > important.
> >> > So I'm ignoring these.
> >> >
> >> > On Tue, Dec 27, 2011 at 9:34 PM, Jeff Eastman
> >> > <[EMAIL PROTECTED]> wrote:
> >> > > I'm getting a lot of these emails yet all the tests run locally for
> >> me.
> >> > Does
> >> > > anybody have an idea what the problem is? This close to a release it
> >> > would
> >> > > be really nice to have Jenkins on our side.
> >> > > Jeff
> >> > >
> >> >
> >>
> >
> >
>
dir. E.g. I remember that was creating problems for Mr tasks in local mr
mode legitimately using boxed task temporary space.
OK I'll try to scan for the problem tomorrow.
On Dec 27, 2011 10:50 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
> So I am like everybody else. The test works for me.
>
> My suspicion is that there is something going on with the temporary
> directory that I am trying to use and that the environment that Jenkins is
> using is somehow strange.
>
> The only slightly surprising idiom I am using is to create a temporary
> file, delete it and recreate it as a directory. I even check the return
> values from the delete and the mkdir.
>
> I will keep looking.
>
> On Tue, Dec 27, 2011 at 10:37 PM, Ted Dunning <[EMAIL PROTECTED]>
> wrote:
>
> > Indeed it does. Thanks for pointing that out.
> >
> > This error is very strange.
> >
> >
> > On Tue, Dec 27, 2011 at 10:06 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]
> >wrote:
> >
> >> Ted,
> >>
> >> do you have an idea why this test may be failing? I think this test
> comes
> >> with M-792 commit.
> >>
> >> I can take a look at it, I suspect something in the environment can be
> >> tripping it.
> >> On Dec 27, 2011 8:54 PM, "Sean Owen" <[EMAIL PROTECTED]> wrote:
> >>
> >> > It's all errors in the Apache infrastructure, rather than a real test
> >> > failure. At least, stuff passes for me locally, and that's what's
> >> > important.
> >> > So I'm ignoring these.
> >> >
> >> > On Tue, Dec 27, 2011 at 9:34 PM, Jeff Eastman
> >> > <[EMAIL PROTECTED]> wrote:
> >> > > I'm getting a lot of these emails yet all the tests run locally for
> >> me.
> >> > Does
> >> > > anybody have an idea what the problem is? This close to a release it
> >> > would
> >> > > be really nice to have Jenkins on our side.
> >> > > Jeff
> >> > >
> >> >
> >>
> >
> >
>
+
Dmitriy Lyubimov 2011-12-28, 07:15
-
Re: Build failed in Jenkins: mahout-nightly #737Grant Ingersoll 2011-12-28, 23:21
I can reproduce outside of Jenkins. It really seems odd that the answer is off by so much.
On Dec 28, 2011, at 2:15 AM, Dmitriy Lyubimov wrote:
> I vaguely remember Jenkins had problems with creating stuff in Java tmp
> dir. E.g. I remember that was creating problems for Mr tasks in local mr
> mode legitimately using boxed task temporary space.
>
> OK I'll try to scan for the problem tomorrow.
> On Dec 27, 2011 10:50 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
>
>> So I am like everybody else. The test works for me.
>>
>> My suspicion is that there is something going on with the temporary
>> directory that I am trying to use and that the environment that Jenkins is
>> using is somehow strange.
>>
>> The only slightly surprising idiom I am using is to create a temporary
>> file, delete it and recreate it as a directory. I even check the return
>> values from the delete and the mkdir.
>>
>> I will keep looking.
>>
>> On Tue, Dec 27, 2011 at 10:37 PM, Ted Dunning <[EMAIL PROTECTED]>
>> wrote:
>>
>>> Indeed it does. Thanks for pointing that out.
>>>
>>> This error is very strange.
>>>
>>>
>>> On Tue, Dec 27, 2011 at 10:06 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]
>>> wrote:
>>>
>>>> Ted,
>>>>
>>>> do you have an idea why this test may be failing? I think this test
>> comes
>>>> with M-792 commit.
>>>>
>>>> I can take a look at it, I suspect something in the environment can be
>>>> tripping it.
>>>> On Dec 27, 2011 8:54 PM, "Sean Owen" <[EMAIL PROTECTED]> wrote:
>>>>
>>>>> It's all errors in the Apache infrastructure, rather than a real test
>>>>> failure. At least, stuff passes for me locally, and that's what's
>>>>> important.
>>>>> So I'm ignoring these.
>>>>>
>>>>> On Tue, Dec 27, 2011 at 9:34 PM, Jeff Eastman
>>>>> <[EMAIL PROTECTED]> wrote:
>>>>>> I'm getting a lot of these emails yet all the tests run locally for
>>>> me.
>>>>> Does
>>>>>> anybody have an idea what the problem is? This close to a release it
>>>>> would
>>>>>> be really nice to have Jenkins on our side.
>>>>>> Jeff
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
--------------------------------------------
Grant Ingersoll
http://www.lucidimagination.com
On Dec 28, 2011, at 2:15 AM, Dmitriy Lyubimov wrote:
> I vaguely remember Jenkins had problems with creating stuff in Java tmp
> dir. E.g. I remember that was creating problems for Mr tasks in local mr
> mode legitimately using boxed task temporary space.
>
> OK I'll try to scan for the problem tomorrow.
> On Dec 27, 2011 10:50 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
>
>> So I am like everybody else. The test works for me.
>>
>> My suspicion is that there is something going on with the temporary
>> directory that I am trying to use and that the environment that Jenkins is
>> using is somehow strange.
>>
>> The only slightly surprising idiom I am using is to create a temporary
>> file, delete it and recreate it as a directory. I even check the return
>> values from the delete and the mkdir.
>>
>> I will keep looking.
>>
>> On Tue, Dec 27, 2011 at 10:37 PM, Ted Dunning <[EMAIL PROTECTED]>
>> wrote:
>>
>>> Indeed it does. Thanks for pointing that out.
>>>
>>> This error is very strange.
>>>
>>>
>>> On Tue, Dec 27, 2011 at 10:06 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]
>>> wrote:
>>>
>>>> Ted,
>>>>
>>>> do you have an idea why this test may be failing? I think this test
>> comes
>>>> with M-792 commit.
>>>>
>>>> I can take a look at it, I suspect something in the environment can be
>>>> tripping it.
>>>> On Dec 27, 2011 8:54 PM, "Sean Owen" <[EMAIL PROTECTED]> wrote:
>>>>
>>>>> It's all errors in the Apache infrastructure, rather than a real test
>>>>> failure. At least, stuff passes for me locally, and that's what's
>>>>> important.
>>>>> So I'm ignoring these.
>>>>>
>>>>> On Tue, Dec 27, 2011 at 9:34 PM, Jeff Eastman
>>>>> <[EMAIL PROTECTED]> wrote:
>>>>>> I'm getting a lot of these emails yet all the tests run locally for
>>>> me.
>>>>> Does
>>>>>> anybody have an idea what the problem is? This close to a release it
>>>>> would
>>>>>> be really nice to have Jenkins on our side.
>>>>>> Jeff
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
--------------------------------------------
Grant Ingersoll
http://www.lucidimagination.com
+
Grant Ingersoll 2011-12-28, 23:21
-
Re: Build failed in Jenkins: mahout-nightly #737Ted Dunning 2011-12-28, 23:30
I think that the answer is 0 because the model is not being read and we are
swallowing an exception somewhere. This is what an uninitialized matrix
would give as a result.
On Wed, Dec 28, 2011 at 3:21 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
> I can reproduce outside of Jenkins. It really seems odd that the answer
> is off by so much.
>
> On Dec 28, 2011, at 2:15 AM, Dmitriy Lyubimov wrote:
>
> > I vaguely remember Jenkins had problems with creating stuff in Java tmp
> > dir. E.g. I remember that was creating problems for Mr tasks in local mr
> > mode legitimately using boxed task temporary space.
> >
> > OK I'll try to scan for the problem tomorrow.
> > On Dec 27, 2011 10:50 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
> >
> >> So I am like everybody else. The test works for me.
> >>
> >> My suspicion is that there is something going on with the temporary
> >> directory that I am trying to use and that the environment that Jenkins
> is
> >> using is somehow strange.
> >>
> >> The only slightly surprising idiom I am using is to create a temporary
> >> file, delete it and recreate it as a directory. I even check the return
> >> values from the delete and the mkdir.
> >>
> >> I will keep looking.
> >>
> >> On Tue, Dec 27, 2011 at 10:37 PM, Ted Dunning <[EMAIL PROTECTED]>
> >> wrote:
> >>
> >>> Indeed it does. Thanks for pointing that out.
> >>>
> >>> This error is very strange.
> >>>
> >>>
> >>> On Tue, Dec 27, 2011 at 10:06 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]
> >>> wrote:
> >>>
> >>>> Ted,
> >>>>
> >>>> do you have an idea why this test may be failing? I think this test
> >> comes
> >>>> with M-792 commit.
> >>>>
> >>>> I can take a look at it, I suspect something in the environment can be
> >>>> tripping it.
> >>>> On Dec 27, 2011 8:54 PM, "Sean Owen" <[EMAIL PROTECTED]> wrote:
> >>>>
> >>>>> It's all errors in the Apache infrastructure, rather than a real test
> >>>>> failure. At least, stuff passes for me locally, and that's what's
> >>>>> important.
> >>>>> So I'm ignoring these.
> >>>>>
> >>>>> On Tue, Dec 27, 2011 at 9:34 PM, Jeff Eastman
> >>>>> <[EMAIL PROTECTED]> wrote:
> >>>>>> I'm getting a lot of these emails yet all the tests run locally for
> >>>> me.
> >>>>> Does
> >>>>>> anybody have an idea what the problem is? This close to a release it
> >>>>> would
> >>>>>> be really nice to have Jenkins on our side.
> >>>>>> Jeff
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>
>
> --------------------------------------------
> Grant Ingersoll
> http://www.lucidimagination.com
>
>
>
>
swallowing an exception somewhere. This is what an uninitialized matrix
would give as a result.
On Wed, Dec 28, 2011 at 3:21 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
> I can reproduce outside of Jenkins. It really seems odd that the answer
> is off by so much.
>
> On Dec 28, 2011, at 2:15 AM, Dmitriy Lyubimov wrote:
>
> > I vaguely remember Jenkins had problems with creating stuff in Java tmp
> > dir. E.g. I remember that was creating problems for Mr tasks in local mr
> > mode legitimately using boxed task temporary space.
> >
> > OK I'll try to scan for the problem tomorrow.
> > On Dec 27, 2011 10:50 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
> >
> >> So I am like everybody else. The test works for me.
> >>
> >> My suspicion is that there is something going on with the temporary
> >> directory that I am trying to use and that the environment that Jenkins
> is
> >> using is somehow strange.
> >>
> >> The only slightly surprising idiom I am using is to create a temporary
> >> file, delete it and recreate it as a directory. I even check the return
> >> values from the delete and the mkdir.
> >>
> >> I will keep looking.
> >>
> >> On Tue, Dec 27, 2011 at 10:37 PM, Ted Dunning <[EMAIL PROTECTED]>
> >> wrote:
> >>
> >>> Indeed it does. Thanks for pointing that out.
> >>>
> >>> This error is very strange.
> >>>
> >>>
> >>> On Tue, Dec 27, 2011 at 10:06 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]
> >>> wrote:
> >>>
> >>>> Ted,
> >>>>
> >>>> do you have an idea why this test may be failing? I think this test
> >> comes
> >>>> with M-792 commit.
> >>>>
> >>>> I can take a look at it, I suspect something in the environment can be
> >>>> tripping it.
> >>>> On Dec 27, 2011 8:54 PM, "Sean Owen" <[EMAIL PROTECTED]> wrote:
> >>>>
> >>>>> It's all errors in the Apache infrastructure, rather than a real test
> >>>>> failure. At least, stuff passes for me locally, and that's what's
> >>>>> important.
> >>>>> So I'm ignoring these.
> >>>>>
> >>>>> On Tue, Dec 27, 2011 at 9:34 PM, Jeff Eastman
> >>>>> <[EMAIL PROTECTED]> wrote:
> >>>>>> I'm getting a lot of these emails yet all the tests run locally for
> >>>> me.
> >>>>> Does
> >>>>>> anybody have an idea what the problem is? This close to a release it
> >>>>> would
> >>>>>> be really nice to have Jenkins on our side.
> >>>>>> Jeff
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>
>
> --------------------------------------------
> Grant Ingersoll
> http://www.lucidimagination.com
>
>
>
>
+
Ted Dunning 2011-12-28, 23:30
-
Re: Build failed in Jenkins: mahout-nightly #737Grant Ingersoll 2011-12-28, 23:45
It's expecting the answer to be 0, but it's some really large value.
testSingularValues(org.apache.mahout.math.ssvd.SequentialOutOfCoreSvdTest): expected:<0.0> but was:<4131200.0000000037>
On Dec 28, 2011, at 6:30 PM, Ted Dunning wrote:
> I think that the answer is 0 because the model is not being read and we are
> swallowing an exception somewhere. This is what an uninitialized matrix
> would give as a result.
>
> On Wed, Dec 28, 2011 at 3:21 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
>
>> I can reproduce outside of Jenkins. It really seems odd that the answer
>> is off by so much.
>>
>> On Dec 28, 2011, at 2:15 AM, Dmitriy Lyubimov wrote:
>>
>>> I vaguely remember Jenkins had problems with creating stuff in Java tmp
>>> dir. E.g. I remember that was creating problems for Mr tasks in local mr
>>> mode legitimately using boxed task temporary space.
>>>
>>> OK I'll try to scan for the problem tomorrow.
>>> On Dec 27, 2011 10:50 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
>>>
>>>> So I am like everybody else. The test works for me.
>>>>
>>>> My suspicion is that there is something going on with the temporary
>>>> directory that I am trying to use and that the environment that Jenkins
>> is
>>>> using is somehow strange.
>>>>
>>>> The only slightly surprising idiom I am using is to create a temporary
>>>> file, delete it and recreate it as a directory. I even check the return
>>>> values from the delete and the mkdir.
>>>>
>>>> I will keep looking.
>>>>
>>>> On Tue, Dec 27, 2011 at 10:37 PM, Ted Dunning <[EMAIL PROTECTED]>
>>>> wrote:
>>>>
>>>>> Indeed it does. Thanks for pointing that out.
>>>>>
>>>>> This error is very strange.
>>>>>
>>>>>
>>>>> On Tue, Dec 27, 2011 at 10:06 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]
>>>>> wrote:
>>>>>
>>>>>> Ted,
>>>>>>
>>>>>> do you have an idea why this test may be failing? I think this test
>>>> comes
>>>>>> with M-792 commit.
>>>>>>
>>>>>> I can take a look at it, I suspect something in the environment can be
>>>>>> tripping it.
>>>>>> On Dec 27, 2011 8:54 PM, "Sean Owen" <[EMAIL PROTECTED]> wrote:
>>>>>>
>>>>>>> It's all errors in the Apache infrastructure, rather than a real test
>>>>>>> failure. At least, stuff passes for me locally, and that's what's
>>>>>>> important.
>>>>>>> So I'm ignoring these.
>>>>>>>
>>>>>>> On Tue, Dec 27, 2011 at 9:34 PM, Jeff Eastman
>>>>>>> <[EMAIL PROTECTED]> wrote:
>>>>>>>> I'm getting a lot of these emails yet all the tests run locally for
>>>>>> me.
>>>>>>> Does
>>>>>>>> anybody have an idea what the problem is? This close to a release it
>>>>>>> would
>>>>>>>> be really nice to have Jenkins on our side.
>>>>>>>> Jeff
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>
>> --------------------------------------------
>> Grant Ingersoll
>> http://www.lucidimagination.com
>>
>>
>>
>>
--------------------------------------------
Grant Ingersoll
http://www.lucidimagination.com
testSingularValues(org.apache.mahout.math.ssvd.SequentialOutOfCoreSvdTest): expected:<0.0> but was:<4131200.0000000037>
On Dec 28, 2011, at 6:30 PM, Ted Dunning wrote:
> I think that the answer is 0 because the model is not being read and we are
> swallowing an exception somewhere. This is what an uninitialized matrix
> would give as a result.
>
> On Wed, Dec 28, 2011 at 3:21 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
>
>> I can reproduce outside of Jenkins. It really seems odd that the answer
>> is off by so much.
>>
>> On Dec 28, 2011, at 2:15 AM, Dmitriy Lyubimov wrote:
>>
>>> I vaguely remember Jenkins had problems with creating stuff in Java tmp
>>> dir. E.g. I remember that was creating problems for Mr tasks in local mr
>>> mode legitimately using boxed task temporary space.
>>>
>>> OK I'll try to scan for the problem tomorrow.
>>> On Dec 27, 2011 10:50 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
>>>
>>>> So I am like everybody else. The test works for me.
>>>>
>>>> My suspicion is that there is something going on with the temporary
>>>> directory that I am trying to use and that the environment that Jenkins
>> is
>>>> using is somehow strange.
>>>>
>>>> The only slightly surprising idiom I am using is to create a temporary
>>>> file, delete it and recreate it as a directory. I even check the return
>>>> values from the delete and the mkdir.
>>>>
>>>> I will keep looking.
>>>>
>>>> On Tue, Dec 27, 2011 at 10:37 PM, Ted Dunning <[EMAIL PROTECTED]>
>>>> wrote:
>>>>
>>>>> Indeed it does. Thanks for pointing that out.
>>>>>
>>>>> This error is very strange.
>>>>>
>>>>>
>>>>> On Tue, Dec 27, 2011 at 10:06 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]
>>>>> wrote:
>>>>>
>>>>>> Ted,
>>>>>>
>>>>>> do you have an idea why this test may be failing? I think this test
>>>> comes
>>>>>> with M-792 commit.
>>>>>>
>>>>>> I can take a look at it, I suspect something in the environment can be
>>>>>> tripping it.
>>>>>> On Dec 27, 2011 8:54 PM, "Sean Owen" <[EMAIL PROTECTED]> wrote:
>>>>>>
>>>>>>> It's all errors in the Apache infrastructure, rather than a real test
>>>>>>> failure. At least, stuff passes for me locally, and that's what's
>>>>>>> important.
>>>>>>> So I'm ignoring these.
>>>>>>>
>>>>>>> On Tue, Dec 27, 2011 at 9:34 PM, Jeff Eastman
>>>>>>> <[EMAIL PROTECTED]> wrote:
>>>>>>>> I'm getting a lot of these emails yet all the tests run locally for
>>>>>> me.
>>>>>>> Does
>>>>>>>> anybody have an idea what the problem is? This close to a release it
>>>>>>> would
>>>>>>>> be really nice to have Jenkins on our side.
>>>>>>>> Jeff
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>
>> --------------------------------------------
>> Grant Ingersoll
>> http://www.lucidimagination.com
>>
>>
>>
>>
--------------------------------------------
Grant Ingersoll
http://www.lucidimagination.com
+
Grant Ingersoll 2011-12-28, 23:45
-
Re: Build failed in Jenkins: mahout-nightly #737Ted Dunning 2011-12-29, 00:15
Yeah.. but this is a difference from the correct answer. I am moderately
sure that this is a problem writing to the temp directory.
On Wed, Dec 28, 2011 at 3:45 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
> It's expecting the answer to be 0, but it's some really large value.
> testSingularValues(org.apache.mahout.math.ssvd.SequentialOutOfCoreSvdTest):
> expected:<0.0> but was:<4131200.0000000037>
>
>
> On Dec 28, 2011, at 6:30 PM, Ted Dunning wrote:
>
> > I think that the answer is 0 because the model is not being read and we
> are
> > swallowing an exception somewhere. This is what an uninitialized matrix
> > would give as a result.
> >
> > On Wed, Dec 28, 2011 at 3:21 PM, Grant Ingersoll <[EMAIL PROTECTED]
> >wrote:
> >
> >> I can reproduce outside of Jenkins. It really seems odd that the answer
> >> is off by so much.
> >>
> >> On Dec 28, 2011, at 2:15 AM, Dmitriy Lyubimov wrote:
> >>
> >>> I vaguely remember Jenkins had problems with creating stuff in Java tmp
> >>> dir. E.g. I remember that was creating problems for Mr tasks in local
> mr
> >>> mode legitimately using boxed task temporary space.
> >>>
> >>> OK I'll try to scan for the problem tomorrow.
> >>> On Dec 27, 2011 10:50 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
> >>>
> >>>> So I am like everybody else. The test works for me.
> >>>>
> >>>> My suspicion is that there is something going on with the temporary
> >>>> directory that I am trying to use and that the environment that
> Jenkins
> >> is
> >>>> using is somehow strange.
> >>>>
> >>>> The only slightly surprising idiom I am using is to create a temporary
> >>>> file, delete it and recreate it as a directory. I even check the
> return
> >>>> values from the delete and the mkdir.
> >>>>
> >>>> I will keep looking.
> >>>>
> >>>> On Tue, Dec 27, 2011 at 10:37 PM, Ted Dunning <[EMAIL PROTECTED]>
> >>>> wrote:
> >>>>
> >>>>> Indeed it does. Thanks for pointing that out.
> >>>>>
> >>>>> This error is very strange.
> >>>>>
> >>>>>
> >>>>> On Tue, Dec 27, 2011 at 10:06 PM, Dmitriy Lyubimov <
> [EMAIL PROTECTED]
> >>>>> wrote:
> >>>>>
> >>>>>> Ted,
> >>>>>>
> >>>>>> do you have an idea why this test may be failing? I think this test
> >>>> comes
> >>>>>> with M-792 commit.
> >>>>>>
> >>>>>> I can take a look at it, I suspect something in the environment can
> be
> >>>>>> tripping it.
> >>>>>> On Dec 27, 2011 8:54 PM, "Sean Owen" <[EMAIL PROTECTED]> wrote:
> >>>>>>
> >>>>>>> It's all errors in the Apache infrastructure, rather than a real
> test
> >>>>>>> failure. At least, stuff passes for me locally, and that's what's
> >>>>>>> important.
> >>>>>>> So I'm ignoring these.
> >>>>>>>
> >>>>>>> On Tue, Dec 27, 2011 at 9:34 PM, Jeff Eastman
> >>>>>>> <[EMAIL PROTECTED]> wrote:
> >>>>>>>> I'm getting a lot of these emails yet all the tests run locally
> for
> >>>>>> me.
> >>>>>>> Does
> >>>>>>>> anybody have an idea what the problem is? This close to a release
> it
> >>>>>>> would
> >>>>>>>> be really nice to have Jenkins on our side.
> >>>>>>>> Jeff
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>
> >> --------------------------------------------
> >> Grant Ingersoll
> >> http://www.lucidimagination.com
> >>
> >>
> >>
> >>
>
> --------------------------------------------
> Grant Ingersoll
> http://www.lucidimagination.com
>
>
>
>
sure that this is a problem writing to the temp directory.
On Wed, Dec 28, 2011 at 3:45 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
> It's expecting the answer to be 0, but it's some really large value.
> testSingularValues(org.apache.mahout.math.ssvd.SequentialOutOfCoreSvdTest):
> expected:<0.0> but was:<4131200.0000000037>
>
>
> On Dec 28, 2011, at 6:30 PM, Ted Dunning wrote:
>
> > I think that the answer is 0 because the model is not being read and we
> are
> > swallowing an exception somewhere. This is what an uninitialized matrix
> > would give as a result.
> >
> > On Wed, Dec 28, 2011 at 3:21 PM, Grant Ingersoll <[EMAIL PROTECTED]
> >wrote:
> >
> >> I can reproduce outside of Jenkins. It really seems odd that the answer
> >> is off by so much.
> >>
> >> On Dec 28, 2011, at 2:15 AM, Dmitriy Lyubimov wrote:
> >>
> >>> I vaguely remember Jenkins had problems with creating stuff in Java tmp
> >>> dir. E.g. I remember that was creating problems for Mr tasks in local
> mr
> >>> mode legitimately using boxed task temporary space.
> >>>
> >>> OK I'll try to scan for the problem tomorrow.
> >>> On Dec 27, 2011 10:50 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
> >>>
> >>>> So I am like everybody else. The test works for me.
> >>>>
> >>>> My suspicion is that there is something going on with the temporary
> >>>> directory that I am trying to use and that the environment that
> Jenkins
> >> is
> >>>> using is somehow strange.
> >>>>
> >>>> The only slightly surprising idiom I am using is to create a temporary
> >>>> file, delete it and recreate it as a directory. I even check the
> return
> >>>> values from the delete and the mkdir.
> >>>>
> >>>> I will keep looking.
> >>>>
> >>>> On Tue, Dec 27, 2011 at 10:37 PM, Ted Dunning <[EMAIL PROTECTED]>
> >>>> wrote:
> >>>>
> >>>>> Indeed it does. Thanks for pointing that out.
> >>>>>
> >>>>> This error is very strange.
> >>>>>
> >>>>>
> >>>>> On Tue, Dec 27, 2011 at 10:06 PM, Dmitriy Lyubimov <
> [EMAIL PROTECTED]
> >>>>> wrote:
> >>>>>
> >>>>>> Ted,
> >>>>>>
> >>>>>> do you have an idea why this test may be failing? I think this test
> >>>> comes
> >>>>>> with M-792 commit.
> >>>>>>
> >>>>>> I can take a look at it, I suspect something in the environment can
> be
> >>>>>> tripping it.
> >>>>>> On Dec 27, 2011 8:54 PM, "Sean Owen" <[EMAIL PROTECTED]> wrote:
> >>>>>>
> >>>>>>> It's all errors in the Apache infrastructure, rather than a real
> test
> >>>>>>> failure. At least, stuff passes for me locally, and that's what's
> >>>>>>> important.
> >>>>>>> So I'm ignoring these.
> >>>>>>>
> >>>>>>> On Tue, Dec 27, 2011 at 9:34 PM, Jeff Eastman
> >>>>>>> <[EMAIL PROTECTED]> wrote:
> >>>>>>>> I'm getting a lot of these emails yet all the tests run locally
> for
> >>>>>> me.
> >>>>>>> Does
> >>>>>>>> anybody have an idea what the problem is? This close to a release
> it
> >>>>>>> would
> >>>>>>>> be really nice to have Jenkins on our side.
> >>>>>>>> Jeff
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>
> >> --------------------------------------------
> >> Grant Ingersoll
> >> http://www.lucidimagination.com
> >>
> >>
> >>
> >>
>
> --------------------------------------------
> Grant Ingersoll
> http://www.lucidimagination.com
>
>
>
>
+
Ted Dunning 2011-12-29, 00:15
-
Re: Build failed in Jenkins: mahout-nightly #737Grant Ingersoll 2011-12-29, 02:33
I commented out the deletion of the dir in the tearDown. Not sure if that looks reasonable or not, but on the surface they look equivalent.
Here's the contents of the dir on Ubuntu:
-rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
-rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
-rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
-rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000600
-rw-rw-r-- 1 XXXXXX XXXXXX 1387722 2011-12-28 21:17 A-000000800
-rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000000
-rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000210
-rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000420
-rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000630
-rw-rw-r-- 1 XXXXXX XXXXXX 144312 2011-12-28 21:17 B-000000840
-rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-0
-rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-200
-rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-400
-rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-600
-rw-rw-r-- 1 XXXXXX XXXXXX 136352 2011-12-28 21:17 U-800
-rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-0
-rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-1
-rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-2
-rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-3
-rw-rw-r-- 1 XXXXXX XXXXXX 144372 2011-12-28 21:17 V-4
Here's what my Mac looks like:
total 20296
-rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000000
-rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000200
-rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000400
-rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000600
-rw-r--r-- 1 XXXXXX staff 1.3M Dec 28 21:28 A-000000800
-rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000000
-rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000210
-rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000420
-rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000630
-rw-r--r-- 1 XXXXXX staff 141K Dec 28 21:28 B-000000840
-rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-0
-rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-200
-rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-400
-rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-600
-rw-r--r-- 1 XXXXXX staff 133K Dec 28 21:28 U-800
-rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-0
-rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-1
-rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-2
-rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-3
-rw-r--r-- 1 XXXXXX staff 141K Dec 28 21:28 V-4
On Dec 28, 2011, at 7:15 PM, Ted Dunning wrote:
> Yeah.. but this is a difference from the correct answer. I am moderately
> sure that this is a problem writing to the temp directory.
>
> On Wed, Dec 28, 2011 at 3:45 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
>
>> It's expecting the answer to be 0, but it's some really large value.
>> testSingularValues(org.apache.mahout.math.ssvd.SequentialOutOfCoreSvdTest):
>> expected:<0.0> but was:<4131200.0000000037>
>>
>>
>> On Dec 28, 2011, at 6:30 PM, Ted Dunning wrote:
>>
>>> I think that the answer is 0 because the model is not being read and we
>> are
>>> swallowing an exception somewhere. This is what an uninitialized matrix
>>> would give as a result.
>>>
>>> On Wed, Dec 28, 2011 at 3:21 PM, Grant Ingersoll <[EMAIL PROTECTED]
>>> wrote:
>>>
>>>> I can reproduce outside of Jenkins. It really seems odd that the answer
>>>> is off by so much.
>>>>
>>>> On Dec 28, 2011, at 2:15 AM, Dmitriy Lyubimov wrote:
>>>>
>>>>> I vaguely remember Jenkins had problems with creating stuff in Java tmp
>>>>> dir. E.g. I remember that was creating problems for Mr tasks in local
>> mr
>>>>> mode legitimately using boxed task temporary space.
>>>>>
>>>>> OK I'll try to scan for the problem tomorrow.
>>>>> On Dec 27, 2011 10:50 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>>> So I am like everybody else. The test works for me.
>>>>>>
>>>>>> My suspicion is that there is something going on with the temporary
Grant Ingersoll
http://www.lucidimagination.com
Here's the contents of the dir on Ubuntu:
-rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
-rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
-rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
-rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000600
-rw-rw-r-- 1 XXXXXX XXXXXX 1387722 2011-12-28 21:17 A-000000800
-rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000000
-rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000210
-rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000420
-rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000630
-rw-rw-r-- 1 XXXXXX XXXXXX 144312 2011-12-28 21:17 B-000000840
-rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-0
-rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-200
-rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-400
-rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-600
-rw-rw-r-- 1 XXXXXX XXXXXX 136352 2011-12-28 21:17 U-800
-rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-0
-rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-1
-rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-2
-rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-3
-rw-rw-r-- 1 XXXXXX XXXXXX 144372 2011-12-28 21:17 V-4
Here's what my Mac looks like:
total 20296
-rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000000
-rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000200
-rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000400
-rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000600
-rw-r--r-- 1 XXXXXX staff 1.3M Dec 28 21:28 A-000000800
-rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000000
-rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000210
-rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000420
-rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000630
-rw-r--r-- 1 XXXXXX staff 141K Dec 28 21:28 B-000000840
-rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-0
-rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-200
-rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-400
-rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-600
-rw-r--r-- 1 XXXXXX staff 133K Dec 28 21:28 U-800
-rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-0
-rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-1
-rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-2
-rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-3
-rw-r--r-- 1 XXXXXX staff 141K Dec 28 21:28 V-4
On Dec 28, 2011, at 7:15 PM, Ted Dunning wrote:
> Yeah.. but this is a difference from the correct answer. I am moderately
> sure that this is a problem writing to the temp directory.
>
> On Wed, Dec 28, 2011 at 3:45 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
>
>> It's expecting the answer to be 0, but it's some really large value.
>> testSingularValues(org.apache.mahout.math.ssvd.SequentialOutOfCoreSvdTest):
>> expected:<0.0> but was:<4131200.0000000037>
>>
>>
>> On Dec 28, 2011, at 6:30 PM, Ted Dunning wrote:
>>
>>> I think that the answer is 0 because the model is not being read and we
>> are
>>> swallowing an exception somewhere. This is what an uninitialized matrix
>>> would give as a result.
>>>
>>> On Wed, Dec 28, 2011 at 3:21 PM, Grant Ingersoll <[EMAIL PROTECTED]
>>> wrote:
>>>
>>>> I can reproduce outside of Jenkins. It really seems odd that the answer
>>>> is off by so much.
>>>>
>>>> On Dec 28, 2011, at 2:15 AM, Dmitriy Lyubimov wrote:
>>>>
>>>>> I vaguely remember Jenkins had problems with creating stuff in Java tmp
>>>>> dir. E.g. I remember that was creating problems for Mr tasks in local
>> mr
>>>>> mode legitimately using boxed task temporary space.
>>>>>
>>>>> OK I'll try to scan for the problem tomorrow.
>>>>> On Dec 27, 2011 10:50 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>>> So I am like everybody else. The test works for me.
>>>>>>
>>>>>> My suspicion is that there is something going on with the temporary
Grant Ingersoll
http://www.lucidimagination.com
+
Grant Ingersoll 2011-12-29, 02:33
-
Re: Build failed in Jenkins: mahout-nightly #737Ted Dunning 2011-12-29, 05:01
What do checksums look like?
On Wed, Dec 28, 2011 at 6:33 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
> I commented out the deletion of the dir in the tearDown. Not sure if that
> looks reasonable or not, but on the surface they look equivalent.
>
> Here's the contents of the dir on Ubuntu:
> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000600
> -rw-rw-r-- 1 XXXXXX XXXXXX 1387722 2011-12-28 21:17 A-000000800
> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000000
> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000210
> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000420
> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000630
> -rw-rw-r-- 1 XXXXXX XXXXXX 144312 2011-12-28 21:17 B-000000840
> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-0
> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-200
> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-400
> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-600
> -rw-rw-r-- 1 XXXXXX XXXXXX 136352 2011-12-28 21:17 U-800
> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-0
> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-1
> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-2
> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-3
> -rw-rw-r-- 1 XXXXXX XXXXXX 144372 2011-12-28 21:17 V-4
>
> Here's what my Mac looks like:
> total 20296
> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000000
> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000200
> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000400
> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000600
> -rw-r--r-- 1 XXXXXX staff 1.3M Dec 28 21:28 A-000000800
> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000000
> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000210
> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000420
> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000630
> -rw-r--r-- 1 XXXXXX staff 141K Dec 28 21:28 B-000000840
> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-0
> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-200
> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-400
> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-600
> -rw-r--r-- 1 XXXXXX staff 133K Dec 28 21:28 U-800
> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-0
> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-1
> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-2
> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-3
> -rw-r--r-- 1 XXXXXX staff 141K Dec 28 21:28 V-4
>
> On Dec 28, 2011, at 7:15 PM, Ted Dunning wrote:
>
> > Yeah.. but this is a difference from the correct answer. I am moderately
> > sure that this is a problem writing to the temp directory.
> >
> > On Wed, Dec 28, 2011 at 3:45 PM, Grant Ingersoll <[EMAIL PROTECTED]
> >wrote:
> >
> >> It's expecting the answer to be 0, but it's some really large value.
> >>
> testSingularValues(org.apache.mahout.math.ssvd.SequentialOutOfCoreSvdTest):
> >> expected:<0.0> but was:<4131200.0000000037>
> >>
> >>
> >> On Dec 28, 2011, at 6:30 PM, Ted Dunning wrote:
> >>
> >>> I think that the answer is 0 because the model is not being read and we
> >> are
> >>> swallowing an exception somewhere. This is what an uninitialized
> matrix
> >>> would give as a result.
> >>>
> >>> On Wed, Dec 28, 2011 at 3:21 PM, Grant Ingersoll <[EMAIL PROTECTED]
> >>> wrote:
> >>>
> >>>> I can reproduce outside of Jenkins. It really seems odd that the
> answer
> >>>> is off by so much.
> >>>>
> >>>> On Dec 28, 2011, at 2:15 AM, Dmitriy Lyubimov wrote:
> >>>>
> >>>>> I vaguely remember Jenkins had problems with creating stuff in Java
> tmp
> >>>>> dir. E.g. I remember that was creating problems for Mr tasks in local
> >> mr
> >>>>> mode legitimately using boxed task temporary space.
On Wed, Dec 28, 2011 at 6:33 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
> I commented out the deletion of the dir in the tearDown. Not sure if that
> looks reasonable or not, but on the surface they look equivalent.
>
> Here's the contents of the dir on Ubuntu:
> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000600
> -rw-rw-r-- 1 XXXXXX XXXXXX 1387722 2011-12-28 21:17 A-000000800
> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000000
> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000210
> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000420
> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000630
> -rw-rw-r-- 1 XXXXXX XXXXXX 144312 2011-12-28 21:17 B-000000840
> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-0
> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-200
> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-400
> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-600
> -rw-rw-r-- 1 XXXXXX XXXXXX 136352 2011-12-28 21:17 U-800
> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-0
> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-1
> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-2
> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-3
> -rw-rw-r-- 1 XXXXXX XXXXXX 144372 2011-12-28 21:17 V-4
>
> Here's what my Mac looks like:
> total 20296
> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000000
> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000200
> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000400
> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000600
> -rw-r--r-- 1 XXXXXX staff 1.3M Dec 28 21:28 A-000000800
> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000000
> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000210
> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000420
> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000630
> -rw-r--r-- 1 XXXXXX staff 141K Dec 28 21:28 B-000000840
> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-0
> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-200
> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-400
> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-600
> -rw-r--r-- 1 XXXXXX staff 133K Dec 28 21:28 U-800
> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-0
> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-1
> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-2
> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-3
> -rw-r--r-- 1 XXXXXX staff 141K Dec 28 21:28 V-4
>
> On Dec 28, 2011, at 7:15 PM, Ted Dunning wrote:
>
> > Yeah.. but this is a difference from the correct answer. I am moderately
> > sure that this is a problem writing to the temp directory.
> >
> > On Wed, Dec 28, 2011 at 3:45 PM, Grant Ingersoll <[EMAIL PROTECTED]
> >wrote:
> >
> >> It's expecting the answer to be 0, but it's some really large value.
> >>
> testSingularValues(org.apache.mahout.math.ssvd.SequentialOutOfCoreSvdTest):
> >> expected:<0.0> but was:<4131200.0000000037>
> >>
> >>
> >> On Dec 28, 2011, at 6:30 PM, Ted Dunning wrote:
> >>
> >>> I think that the answer is 0 because the model is not being read and we
> >> are
> >>> swallowing an exception somewhere. This is what an uninitialized
> matrix
> >>> would give as a result.
> >>>
> >>> On Wed, Dec 28, 2011 at 3:21 PM, Grant Ingersoll <[EMAIL PROTECTED]
> >>> wrote:
> >>>
> >>>> I can reproduce outside of Jenkins. It really seems odd that the
> answer
> >>>> is off by so much.
> >>>>
> >>>> On Dec 28, 2011, at 2:15 AM, Dmitriy Lyubimov wrote:
> >>>>
> >>>>> I vaguely remember Jenkins had problems with creating stuff in Java
> tmp
> >>>>> dir. E.g. I remember that was creating problems for Mr tasks in local
> >> mr
> >>>>> mode legitimately using boxed task temporary space.
+
Ted Dunning 2011-12-29, 05:01
-
Re: Build failed in Jenkins: mahout-nightly #737Dmitriy Lyubimov 2011-12-29, 07:44
Yeah, fails for me on ubuntu without any special environment issues.
Which makes it easier, i can step thru.
On Wed, Dec 28, 2011 at 9:01 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
> What do checksums look like?
>
> On Wed, Dec 28, 2011 at 6:33 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
>
>> I commented out the deletion of the dir in the tearDown. Not sure if that
>> looks reasonable or not, but on the surface they look equivalent.
>>
>> Here's the contents of the dir on Ubuntu:
>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000600
>> -rw-rw-r-- 1 XXXXXX XXXXXX 1387722 2011-12-28 21:17 A-000000800
>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000000
>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000210
>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000420
>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000630
>> -rw-rw-r-- 1 XXXXXX XXXXXX 144312 2011-12-28 21:17 B-000000840
>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-0
>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-200
>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-400
>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-600
>> -rw-rw-r-- 1 XXXXXX XXXXXX 136352 2011-12-28 21:17 U-800
>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-0
>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-1
>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-2
>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-3
>> -rw-rw-r-- 1 XXXXXX XXXXXX 144372 2011-12-28 21:17 V-4
>>
>> Here's what my Mac looks like:
>> total 20296
>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000000
>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000200
>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000400
>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000600
>> -rw-r--r-- 1 XXXXXX staff 1.3M Dec 28 21:28 A-000000800
>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000000
>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000210
>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000420
>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000630
>> -rw-r--r-- 1 XXXXXX staff 141K Dec 28 21:28 B-000000840
>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-0
>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-200
>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-400
>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-600
>> -rw-r--r-- 1 XXXXXX staff 133K Dec 28 21:28 U-800
>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-0
>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-1
>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-2
>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-3
>> -rw-r--r-- 1 XXXXXX staff 141K Dec 28 21:28 V-4
>>
>> On Dec 28, 2011, at 7:15 PM, Ted Dunning wrote:
>>
>> > Yeah.. but this is a difference from the correct answer. I am moderately
>> > sure that this is a problem writing to the temp directory.
>> >
>> > On Wed, Dec 28, 2011 at 3:45 PM, Grant Ingersoll <[EMAIL PROTECTED]
>> >wrote:
>> >
>> >> It's expecting the answer to be 0, but it's some really large value.
>> >>
>> testSingularValues(org.apache.mahout.math.ssvd.SequentialOutOfCoreSvdTest):
>> >> expected:<0.0> but was:<4131200.0000000037>
>> >>
>> >>
>> >> On Dec 28, 2011, at 6:30 PM, Ted Dunning wrote:
>> >>
>> >>> I think that the answer is 0 because the model is not being read and we
>> >> are
>> >>> swallowing an exception somewhere. This is what an uninitialized
>> matrix
>> >>> would give as a result.
>> >>>
>> >>> On Wed, Dec 28, 2011 at 3:21 PM, Grant Ingersoll <[EMAIL PROTECTED]
>> >>> wrote:
>> >>>
>> >>>> I can reproduce outside of Jenkins. It really seems odd that the
>> answer
>> >>>> is off by so much.
Which makes it easier, i can step thru.
On Wed, Dec 28, 2011 at 9:01 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
> What do checksums look like?
>
> On Wed, Dec 28, 2011 at 6:33 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
>
>> I commented out the deletion of the dir in the tearDown. Not sure if that
>> looks reasonable or not, but on the surface they look equivalent.
>>
>> Here's the contents of the dir on Ubuntu:
>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000600
>> -rw-rw-r-- 1 XXXXXX XXXXXX 1387722 2011-12-28 21:17 A-000000800
>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000000
>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000210
>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000420
>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000630
>> -rw-rw-r-- 1 XXXXXX XXXXXX 144312 2011-12-28 21:17 B-000000840
>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-0
>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-200
>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-400
>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-600
>> -rw-rw-r-- 1 XXXXXX XXXXXX 136352 2011-12-28 21:17 U-800
>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-0
>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-1
>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-2
>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-3
>> -rw-rw-r-- 1 XXXXXX XXXXXX 144372 2011-12-28 21:17 V-4
>>
>> Here's what my Mac looks like:
>> total 20296
>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000000
>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000200
>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000400
>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000600
>> -rw-r--r-- 1 XXXXXX staff 1.3M Dec 28 21:28 A-000000800
>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000000
>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000210
>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000420
>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000630
>> -rw-r--r-- 1 XXXXXX staff 141K Dec 28 21:28 B-000000840
>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-0
>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-200
>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-400
>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-600
>> -rw-r--r-- 1 XXXXXX staff 133K Dec 28 21:28 U-800
>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-0
>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-1
>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-2
>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-3
>> -rw-r--r-- 1 XXXXXX staff 141K Dec 28 21:28 V-4
>>
>> On Dec 28, 2011, at 7:15 PM, Ted Dunning wrote:
>>
>> > Yeah.. but this is a difference from the correct answer. I am moderately
>> > sure that this is a problem writing to the temp directory.
>> >
>> > On Wed, Dec 28, 2011 at 3:45 PM, Grant Ingersoll <[EMAIL PROTECTED]
>> >wrote:
>> >
>> >> It's expecting the answer to be 0, but it's some really large value.
>> >>
>> testSingularValues(org.apache.mahout.math.ssvd.SequentialOutOfCoreSvdTest):
>> >> expected:<0.0> but was:<4131200.0000000037>
>> >>
>> >>
>> >> On Dec 28, 2011, at 6:30 PM, Ted Dunning wrote:
>> >>
>> >>> I think that the answer is 0 because the model is not being read and we
>> >> are
>> >>> swallowing an exception somewhere. This is what an uninitialized
>> matrix
>> >>> would give as a result.
>> >>>
>> >>> On Wed, Dec 28, 2011 at 3:21 PM, Grant Ingersoll <[EMAIL PROTECTED]
>> >>> wrote:
>> >>>
>> >>>> I can reproduce outside of Jenkins. It really seems odd that the
>> answer
>> >>>> is off by so much.
+
Dmitriy Lyubimov 2011-12-29, 07:44
-
Re: Build failed in Jenkins: mahout-nightly #737Dmitriy Lyubimov 2011-12-29, 07:49
U and V look suspect, degenerate (only 4 first columns are nonzero,
the rest of matrices are zeros.
On Wed, Dec 28, 2011 at 11:44 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
> Yeah, fails for me on ubuntu without any special environment issues.
> Which makes it easier, i can step thru.
>
> On Wed, Dec 28, 2011 at 9:01 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>> What do checksums look like?
>>
>> On Wed, Dec 28, 2011 at 6:33 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
>>
>>> I commented out the deletion of the dir in the tearDown. Not sure if that
>>> looks reasonable or not, but on the surface they look equivalent.
>>>
>>> Here's the contents of the dir on Ubuntu:
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000600
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1387722 2011-12-28 21:17 A-000000800
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000000
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000210
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000420
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000630
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144312 2011-12-28 21:17 B-000000840
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-0
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-200
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-400
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-600
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 136352 2011-12-28 21:17 U-800
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-0
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-1
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-2
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-3
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144372 2011-12-28 21:17 V-4
>>>
>>> Here's what my Mac looks like:
>>> total 20296
>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000000
>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000200
>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000400
>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000600
>>> -rw-r--r-- 1 XXXXXX staff 1.3M Dec 28 21:28 A-000000800
>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000000
>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000210
>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000420
>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000630
>>> -rw-r--r-- 1 XXXXXX staff 141K Dec 28 21:28 B-000000840
>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-0
>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-200
>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-400
>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-600
>>> -rw-r--r-- 1 XXXXXX staff 133K Dec 28 21:28 U-800
>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-0
>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-1
>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-2
>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-3
>>> -rw-r--r-- 1 XXXXXX staff 141K Dec 28 21:28 V-4
>>>
>>> On Dec 28, 2011, at 7:15 PM, Ted Dunning wrote:
>>>
>>> > Yeah.. but this is a difference from the correct answer. I am moderately
>>> > sure that this is a problem writing to the temp directory.
>>> >
>>> > On Wed, Dec 28, 2011 at 3:45 PM, Grant Ingersoll <[EMAIL PROTECTED]
>>> >wrote:
>>> >
>>> >> It's expecting the answer to be 0, but it's some really large value.
>>> >>
>>> testSingularValues(org.apache.mahout.math.ssvd.SequentialOutOfCoreSvdTest):
>>> >> expected:<0.0> but was:<4131200.0000000037>
>>> >>
>>> >>
>>> >> On Dec 28, 2011, at 6:30 PM, Ted Dunning wrote:
>>> >>
>>> >>> I think that the answer is 0 because the model is not being read and we
>>> >> are
>>> >>> swallowing an exception somewhere. This is what an uninitialized
the rest of matrices are zeros.
On Wed, Dec 28, 2011 at 11:44 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
> Yeah, fails for me on ubuntu without any special environment issues.
> Which makes it easier, i can step thru.
>
> On Wed, Dec 28, 2011 at 9:01 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>> What do checksums look like?
>>
>> On Wed, Dec 28, 2011 at 6:33 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
>>
>>> I commented out the deletion of the dir in the tearDown. Not sure if that
>>> looks reasonable or not, but on the surface they look equivalent.
>>>
>>> Here's the contents of the dir on Ubuntu:
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000600
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1387722 2011-12-28 21:17 A-000000800
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000000
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000210
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000420
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000630
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144312 2011-12-28 21:17 B-000000840
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-0
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-200
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-400
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-600
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 136352 2011-12-28 21:17 U-800
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-0
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-1
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-2
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-3
>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144372 2011-12-28 21:17 V-4
>>>
>>> Here's what my Mac looks like:
>>> total 20296
>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000000
>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000200
>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000400
>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000600
>>> -rw-r--r-- 1 XXXXXX staff 1.3M Dec 28 21:28 A-000000800
>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000000
>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000210
>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000420
>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000630
>>> -rw-r--r-- 1 XXXXXX staff 141K Dec 28 21:28 B-000000840
>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-0
>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-200
>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-400
>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-600
>>> -rw-r--r-- 1 XXXXXX staff 133K Dec 28 21:28 U-800
>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-0
>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-1
>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-2
>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-3
>>> -rw-r--r-- 1 XXXXXX staff 141K Dec 28 21:28 V-4
>>>
>>> On Dec 28, 2011, at 7:15 PM, Ted Dunning wrote:
>>>
>>> > Yeah.. but this is a difference from the correct answer. I am moderately
>>> > sure that this is a problem writing to the temp directory.
>>> >
>>> > On Wed, Dec 28, 2011 at 3:45 PM, Grant Ingersoll <[EMAIL PROTECTED]
>>> >wrote:
>>> >
>>> >> It's expecting the answer to be 0, but it's some really large value.
>>> >>
>>> testSingularValues(org.apache.mahout.math.ssvd.SequentialOutOfCoreSvdTest):
>>> >> expected:<0.0> but was:<4131200.0000000037>
>>> >>
>>> >>
>>> >> On Dec 28, 2011, at 6:30 PM, Ted Dunning wrote:
>>> >>
>>> >>> I think that the answer is 0 because the model is not being read and we
>>> >> are
>>> >>> swallowing an exception somewhere. This is what an uninitialized
+
Dmitriy Lyubimov 2011-12-29, 07:49
-
Re: Build failed in Jenkins: mahout-nightly #737Dmitriy Lyubimov 2011-12-29, 07:56
But it is not a problem reading U or V files, that's indeed what U and
V contain.
On Wed, Dec 28, 2011 at 11:49 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
> U and V look suspect, degenerate (only 4 first columns are nonzero,
> the rest of matrices are zeros.
>
> On Wed, Dec 28, 2011 at 11:44 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>> Yeah, fails for me on ubuntu without any special environment issues.
>> Which makes it easier, i can step thru.
>>
>> On Wed, Dec 28, 2011 at 9:01 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>>> What do checksums look like?
>>>
>>> On Wed, Dec 28, 2011 at 6:33 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
>>>
>>>> I commented out the deletion of the dir in the tearDown. Not sure if that
>>>> looks reasonable or not, but on the surface they look equivalent.
>>>>
>>>> Here's the contents of the dir on Ubuntu:
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000600
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1387722 2011-12-28 21:17 A-000000800
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000000
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000210
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000420
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000630
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144312 2011-12-28 21:17 B-000000840
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-0
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-200
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-400
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-600
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 136352 2011-12-28 21:17 U-800
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-0
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-1
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-2
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-3
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144372 2011-12-28 21:17 V-4
>>>>
>>>> Here's what my Mac looks like:
>>>> total 20296
>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000000
>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000200
>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000400
>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000600
>>>> -rw-r--r-- 1 XXXXXX staff 1.3M Dec 28 21:28 A-000000800
>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000000
>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000210
>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000420
>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000630
>>>> -rw-r--r-- 1 XXXXXX staff 141K Dec 28 21:28 B-000000840
>>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-0
>>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-200
>>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-400
>>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-600
>>>> -rw-r--r-- 1 XXXXXX staff 133K Dec 28 21:28 U-800
>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-0
>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-1
>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-2
>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-3
>>>> -rw-r--r-- 1 XXXXXX staff 141K Dec 28 21:28 V-4
>>>>
>>>> On Dec 28, 2011, at 7:15 PM, Ted Dunning wrote:
>>>>
>>>> > Yeah.. but this is a difference from the correct answer. I am moderately
>>>> > sure that this is a problem writing to the temp directory.
>>>> >
>>>> > On Wed, Dec 28, 2011 at 3:45 PM, Grant Ingersoll <[EMAIL PROTECTED]
>>>> >wrote:
>>>> >
>>>> >> It's expecting the answer to be 0, but it's some really large value.
>>>> >>
>>>> testSingularValues(org.apache.mahout.math.ssvd.SequentialOutOfCoreSvdTest):
>>>> >> expected:<0.0> but was:<4131200.0000000037>
>>>>
V contain.
On Wed, Dec 28, 2011 at 11:49 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
> U and V look suspect, degenerate (only 4 first columns are nonzero,
> the rest of matrices are zeros.
>
> On Wed, Dec 28, 2011 at 11:44 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>> Yeah, fails for me on ubuntu without any special environment issues.
>> Which makes it easier, i can step thru.
>>
>> On Wed, Dec 28, 2011 at 9:01 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>>> What do checksums look like?
>>>
>>> On Wed, Dec 28, 2011 at 6:33 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
>>>
>>>> I commented out the deletion of the dir in the tearDown. Not sure if that
>>>> looks reasonable or not, but on the surface they look equivalent.
>>>>
>>>> Here's the contents of the dir on Ubuntu:
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000600
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1387722 2011-12-28 21:17 A-000000800
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000000
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000210
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000420
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000630
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144312 2011-12-28 21:17 B-000000840
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-0
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-200
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-400
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-600
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 136352 2011-12-28 21:17 U-800
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-0
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-1
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-2
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-3
>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144372 2011-12-28 21:17 V-4
>>>>
>>>> Here's what my Mac looks like:
>>>> total 20296
>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000000
>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000200
>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000400
>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000600
>>>> -rw-r--r-- 1 XXXXXX staff 1.3M Dec 28 21:28 A-000000800
>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000000
>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000210
>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000420
>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000630
>>>> -rw-r--r-- 1 XXXXXX staff 141K Dec 28 21:28 B-000000840
>>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-0
>>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-200
>>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-400
>>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-600
>>>> -rw-r--r-- 1 XXXXXX staff 133K Dec 28 21:28 U-800
>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-0
>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-1
>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-2
>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-3
>>>> -rw-r--r-- 1 XXXXXX staff 141K Dec 28 21:28 V-4
>>>>
>>>> On Dec 28, 2011, at 7:15 PM, Ted Dunning wrote:
>>>>
>>>> > Yeah.. but this is a difference from the correct answer. I am moderately
>>>> > sure that this is a problem writing to the temp directory.
>>>> >
>>>> > On Wed, Dec 28, 2011 at 3:45 PM, Grant Ingersoll <[EMAIL PROTECTED]
>>>> >wrote:
>>>> >
>>>> >> It's expecting the answer to be 0, but it's some really large value.
>>>> >>
>>>> testSingularValues(org.apache.mahout.math.ssvd.SequentialOutOfCoreSvdTest):
>>>> >> expected:<0.0> but was:<4131200.0000000037>
>>>>
+
Dmitriy Lyubimov 2011-12-29, 07:56
-
Re: Build failed in Jenkins: mahout-nightly #737Dmitriy Lyubimov 2011-12-29, 08:13
oh. it's because the synthetic input has only 4 singular values.
On Wed, Dec 28, 2011 at 11:56 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
> But it is not a problem reading U or V files, that's indeed what U and
> V contain.
>
> On Wed, Dec 28, 2011 at 11:49 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>> U and V look suspect, degenerate (only 4 first columns are nonzero,
>> the rest of matrices are zeros.
>>
>> On Wed, Dec 28, 2011 at 11:44 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>>> Yeah, fails for me on ubuntu without any special environment issues.
>>> Which makes it easier, i can step thru.
>>>
>>> On Wed, Dec 28, 2011 at 9:01 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>>>> What do checksums look like?
>>>>
>>>> On Wed, Dec 28, 2011 at 6:33 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
>>>>
>>>>> I commented out the deletion of the dir in the tearDown. Not sure if that
>>>>> looks reasonable or not, but on the surface they look equivalent.
>>>>>
>>>>> Here's the contents of the dir on Ubuntu:
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000600
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1387722 2011-12-28 21:17 A-000000800
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000000
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000210
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000420
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000630
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144312 2011-12-28 21:17 B-000000840
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-0
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-200
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-400
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-600
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 136352 2011-12-28 21:17 U-800
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-0
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-1
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-2
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-3
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144372 2011-12-28 21:17 V-4
>>>>>
>>>>> Here's what my Mac looks like:
>>>>> total 20296
>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000000
>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000200
>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000400
>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000600
>>>>> -rw-r--r-- 1 XXXXXX staff 1.3M Dec 28 21:28 A-000000800
>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000000
>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000210
>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000420
>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000630
>>>>> -rw-r--r-- 1 XXXXXX staff 141K Dec 28 21:28 B-000000840
>>>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-0
>>>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-200
>>>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-400
>>>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-600
>>>>> -rw-r--r-- 1 XXXXXX staff 133K Dec 28 21:28 U-800
>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-0
>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-1
>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-2
>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-3
>>>>> -rw-r--r-- 1 XXXXXX staff 141K Dec 28 21:28 V-4
>>>>>
>>>>> On Dec 28, 2011, at 7:15 PM, Ted Dunning wrote:
>>>>>
>>>>> > Yeah.. but this is a difference from the correct answer. I am moderately
>>>>> > sure that this is a problem writing to the temp directory.
>>>>> >
>>>>> > On Wed, Dec 28, 2011 at 3:45 PM, Grant Ingersoll <[EMAIL PROTECTED]
>>>>> >wrote:
>>>>> >
>>>>
On Wed, Dec 28, 2011 at 11:56 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
> But it is not a problem reading U or V files, that's indeed what U and
> V contain.
>
> On Wed, Dec 28, 2011 at 11:49 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>> U and V look suspect, degenerate (only 4 first columns are nonzero,
>> the rest of matrices are zeros.
>>
>> On Wed, Dec 28, 2011 at 11:44 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>>> Yeah, fails for me on ubuntu without any special environment issues.
>>> Which makes it easier, i can step thru.
>>>
>>> On Wed, Dec 28, 2011 at 9:01 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>>>> What do checksums look like?
>>>>
>>>> On Wed, Dec 28, 2011 at 6:33 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
>>>>
>>>>> I commented out the deletion of the dir in the tearDown. Not sure if that
>>>>> looks reasonable or not, but on the surface they look equivalent.
>>>>>
>>>>> Here's the contents of the dir on Ubuntu:
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000600
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1387722 2011-12-28 21:17 A-000000800
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000000
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000210
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000420
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000630
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144312 2011-12-28 21:17 B-000000840
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-0
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-200
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-400
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-600
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 136352 2011-12-28 21:17 U-800
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-0
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-1
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-2
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-3
>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144372 2011-12-28 21:17 V-4
>>>>>
>>>>> Here's what my Mac looks like:
>>>>> total 20296
>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000000
>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000200
>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000400
>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000600
>>>>> -rw-r--r-- 1 XXXXXX staff 1.3M Dec 28 21:28 A-000000800
>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000000
>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000210
>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000420
>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000630
>>>>> -rw-r--r-- 1 XXXXXX staff 141K Dec 28 21:28 B-000000840
>>>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-0
>>>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-200
>>>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-400
>>>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-600
>>>>> -rw-r--r-- 1 XXXXXX staff 133K Dec 28 21:28 U-800
>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-0
>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-1
>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-2
>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-3
>>>>> -rw-r--r-- 1 XXXXXX staff 141K Dec 28 21:28 V-4
>>>>>
>>>>> On Dec 28, 2011, at 7:15 PM, Ted Dunning wrote:
>>>>>
>>>>> > Yeah.. but this is a difference from the correct answer. I am moderately
>>>>> > sure that this is a problem writing to the temp directory.
>>>>> >
>>>>> > On Wed, Dec 28, 2011 at 3:45 PM, Grant Ingersoll <[EMAIL PROTECTED]
>>>>> >wrote:
>>>>> >
>>>>
+
Dmitriy Lyubimov 2011-12-29, 08:13
-
Re: Build failed in Jenkins: mahout-nightly #737Dmitriy Lyubimov 2011-12-29, 08:31
A-reconstructed difference looks good up to row 399 but starting at
row 400 differences do not add up to 0 anymore (although both inputs
are not 0).
So it doesn't look like trivial case of something is not initialized
on top of it. It does seem something to do with blocking mechanism
though since apparently 400th row is a boundary of some blocking
somewhere, but it is hard for me to see where it fails at this point.
On Thu, Dec 29, 2011 at 12:13 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
> oh. it's because the synthetic input has only 4 singular values.
>
> On Wed, Dec 28, 2011 at 11:56 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>> But it is not a problem reading U or V files, that's indeed what U and
>> V contain.
>>
>> On Wed, Dec 28, 2011 at 11:49 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>>> U and V look suspect, degenerate (only 4 first columns are nonzero,
>>> the rest of matrices are zeros.
>>>
>>> On Wed, Dec 28, 2011 at 11:44 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>>>> Yeah, fails for me on ubuntu without any special environment issues.
>>>> Which makes it easier, i can step thru.
>>>>
>>>> On Wed, Dec 28, 2011 at 9:01 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>>>>> What do checksums look like?
>>>>>
>>>>> On Wed, Dec 28, 2011 at 6:33 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
>>>>>
>>>>>> I commented out the deletion of the dir in the tearDown. Not sure if that
>>>>>> looks reasonable or not, but on the surface they look equivalent.
>>>>>>
>>>>>> Here's the contents of the dir on Ubuntu:
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000600
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1387722 2011-12-28 21:17 A-000000800
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000000
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000210
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000420
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000630
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144312 2011-12-28 21:17 B-000000840
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-0
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-200
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-400
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-600
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 136352 2011-12-28 21:17 U-800
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-0
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-1
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-2
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-3
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144372 2011-12-28 21:17 V-4
>>>>>>
>>>>>> Here's what my Mac looks like:
>>>>>> total 20296
>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000000
>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000200
>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000400
>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000600
>>>>>> -rw-r--r-- 1 XXXXXX staff 1.3M Dec 28 21:28 A-000000800
>>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000000
>>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000210
>>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000420
>>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000630
>>>>>> -rw-r--r-- 1 XXXXXX staff 141K Dec 28 21:28 B-000000840
>>>>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-0
>>>>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-200
>>>>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-400
>>>>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-600
>>>>>> -rw-r--r-- 1 XXXXXX staff 133K Dec 28 21:28 U-800
>>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-0
row 400 differences do not add up to 0 anymore (although both inputs
are not 0).
So it doesn't look like trivial case of something is not initialized
on top of it. It does seem something to do with blocking mechanism
though since apparently 400th row is a boundary of some blocking
somewhere, but it is hard for me to see where it fails at this point.
On Thu, Dec 29, 2011 at 12:13 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
> oh. it's because the synthetic input has only 4 singular values.
>
> On Wed, Dec 28, 2011 at 11:56 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>> But it is not a problem reading U or V files, that's indeed what U and
>> V contain.
>>
>> On Wed, Dec 28, 2011 at 11:49 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>>> U and V look suspect, degenerate (only 4 first columns are nonzero,
>>> the rest of matrices are zeros.
>>>
>>> On Wed, Dec 28, 2011 at 11:44 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>>>> Yeah, fails for me on ubuntu without any special environment issues.
>>>> Which makes it easier, i can step thru.
>>>>
>>>> On Wed, Dec 28, 2011 at 9:01 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>>>>> What do checksums look like?
>>>>>
>>>>> On Wed, Dec 28, 2011 at 6:33 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
>>>>>
>>>>>> I commented out the deletion of the dir in the tearDown. Not sure if that
>>>>>> looks reasonable or not, but on the surface they look equivalent.
>>>>>>
>>>>>> Here's the contents of the dir on Ubuntu:
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000600
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1387722 2011-12-28 21:17 A-000000800
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000000
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000210
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000420
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000630
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144312 2011-12-28 21:17 B-000000840
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-0
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-200
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-400
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-600
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 136352 2011-12-28 21:17 U-800
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-0
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-1
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-2
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-3
>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144372 2011-12-28 21:17 V-4
>>>>>>
>>>>>> Here's what my Mac looks like:
>>>>>> total 20296
>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000000
>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000200
>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000400
>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000600
>>>>>> -rw-r--r-- 1 XXXXXX staff 1.3M Dec 28 21:28 A-000000800
>>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000000
>>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000210
>>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000420
>>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000630
>>>>>> -rw-r--r-- 1 XXXXXX staff 141K Dec 28 21:28 B-000000840
>>>>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-0
>>>>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-200
>>>>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-400
>>>>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-600
>>>>>> -rw-r--r-- 1 XXXXXX staff 133K Dec 28 21:28 U-800
>>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 V-0
+
Dmitriy Lyubimov 2011-12-29, 08:31
-
Re: Build failed in Jenkins: mahout-nightly #737Dmitriy Lyubimov 2011-12-29, 08:42
yes. i would venture to say that U computation (or restoration) is
somehow corrupted starting with 2nd block. at least it looks this way.
On Thu, Dec 29, 2011 at 12:31 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
> A-reconstructed difference looks good up to row 399 but starting at
> row 400 differences do not add up to 0 anymore (although both inputs
> are not 0).
>
> So it doesn't look like trivial case of something is not initialized
> on top of it. It does seem something to do with blocking mechanism
> though since apparently 400th row is a boundary of some blocking
> somewhere, but it is hard for me to see where it fails at this point.
>
> On Thu, Dec 29, 2011 at 12:13 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>> oh. it's because the synthetic input has only 4 singular values.
>>
>> On Wed, Dec 28, 2011 at 11:56 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>>> But it is not a problem reading U or V files, that's indeed what U and
>>> V contain.
>>>
>>> On Wed, Dec 28, 2011 at 11:49 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>>>> U and V look suspect, degenerate (only 4 first columns are nonzero,
>>>> the rest of matrices are zeros.
>>>>
>>>> On Wed, Dec 28, 2011 at 11:44 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>>>>> Yeah, fails for me on ubuntu without any special environment issues.
>>>>> Which makes it easier, i can step thru.
>>>>>
>>>>> On Wed, Dec 28, 2011 at 9:01 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>>>>>> What do checksums look like?
>>>>>>
>>>>>> On Wed, Dec 28, 2011 at 6:33 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
>>>>>>
>>>>>>> I commented out the deletion of the dir in the tearDown. Not sure if that
>>>>>>> looks reasonable or not, but on the surface they look equivalent.
>>>>>>>
>>>>>>> Here's the contents of the dir on Ubuntu:
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000600
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1387722 2011-12-28 21:17 A-000000800
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000000
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000210
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000420
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000630
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144312 2011-12-28 21:17 B-000000840
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-0
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-200
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-400
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-600
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 136352 2011-12-28 21:17 U-800
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-0
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-1
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-2
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-3
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144372 2011-12-28 21:17 V-4
>>>>>>>
>>>>>>> Here's what my Mac looks like:
>>>>>>> total 20296
>>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000000
>>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000200
>>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000400
>>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000600
>>>>>>> -rw-r--r-- 1 XXXXXX staff 1.3M Dec 28 21:28 A-000000800
>>>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000000
>>>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000210
>>>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000420
>>>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000630
>>>>>>> -rw-r--r-- 1 XXXXXX staff 141K Dec 28 21:28 B-000000840
>>>>>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-0
>>>>>>
somehow corrupted starting with 2nd block. at least it looks this way.
On Thu, Dec 29, 2011 at 12:31 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
> A-reconstructed difference looks good up to row 399 but starting at
> row 400 differences do not add up to 0 anymore (although both inputs
> are not 0).
>
> So it doesn't look like trivial case of something is not initialized
> on top of it. It does seem something to do with blocking mechanism
> though since apparently 400th row is a boundary of some blocking
> somewhere, but it is hard for me to see where it fails at this point.
>
> On Thu, Dec 29, 2011 at 12:13 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>> oh. it's because the synthetic input has only 4 singular values.
>>
>> On Wed, Dec 28, 2011 at 11:56 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>>> But it is not a problem reading U or V files, that's indeed what U and
>>> V contain.
>>>
>>> On Wed, Dec 28, 2011 at 11:49 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>>>> U and V look suspect, degenerate (only 4 first columns are nonzero,
>>>> the rest of matrices are zeros.
>>>>
>>>> On Wed, Dec 28, 2011 at 11:44 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>>>>> Yeah, fails for me on ubuntu without any special environment issues.
>>>>> Which makes it easier, i can step thru.
>>>>>
>>>>> On Wed, Dec 28, 2011 at 9:01 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>>>>>> What do checksums look like?
>>>>>>
>>>>>> On Wed, Dec 28, 2011 at 6:33 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
>>>>>>
>>>>>>> I commented out the deletion of the dir in the tearDown. Not sure if that
>>>>>>> looks reasonable or not, but on the surface they look equivalent.
>>>>>>>
>>>>>>> Here's the contents of the dir on Ubuntu:
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000600
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1387722 2011-12-28 21:17 A-000000800
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000000
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000210
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000420
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000630
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144312 2011-12-28 21:17 B-000000840
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-0
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-200
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-400
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-600
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 136352 2011-12-28 21:17 U-800
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-0
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-1
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-2
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-3
>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144372 2011-12-28 21:17 V-4
>>>>>>>
>>>>>>> Here's what my Mac looks like:
>>>>>>> total 20296
>>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000000
>>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000200
>>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000400
>>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000600
>>>>>>> -rw-r--r-- 1 XXXXXX staff 1.3M Dec 28 21:28 A-000000800
>>>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000000
>>>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000210
>>>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000420
>>>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000630
>>>>>>> -rw-r--r-- 1 XXXXXX staff 141K Dec 28 21:28 B-000000840
>>>>>>> -rw-r--r-- 1 XXXXXX staff 157K Dec 28 21:28 U-0
>>>>>>
+
Dmitriy Lyubimov 2011-12-29, 08:42
-
Re: Build failed in Jenkins: mahout-nightly #737Dawid Weiss 2011-12-29, 08:49
Does the same problem occur with another JVM, Dmitriy? JRockit or
IBM's J9? Or even a different version of HotSpot? I remember we were
once trying to figure out a similar bug (lots of computations,
different result) in our code and it turned out that the problem was
due to different native floating point precision roundings and code
JITting at different points in time (this was a very hard stuff to
debug).
The result in our case did not propagate to such large differences,
but I would still try to reproduce with a different JVM just to see if
this makes any difference.
My next step would then be to instrument the code with AspectJ
(statically) and run on a machine (jvm) where the test passes and on
the one where it fails and dump, dump, dump execution progress (all
method entry/exit points, with arguments). These are usually very
large files, but you can easily diff them against each other and see
where _exactly_ the execution started to diverge. If you add
-XX:PrintCompilation to hotspot you may even be able to tell if this
is a JIT problem or something else.
Shooting at the dark here, but maybe you'll find it helpful. I can
help you with aspectj instrumentation if you find this interesting.
Dawid
On Thu, Dec 29, 2011 at 9:42 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
> yes. i would venture to say that U computation (or restoration) is
> somehow corrupted starting with 2nd block. at least it looks this way.
>
> On Thu, Dec 29, 2011 at 12:31 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>> A-reconstructed difference looks good up to row 399 but starting at
>> row 400 differences do not add up to 0 anymore (although both inputs
>> are not 0).
>>
>> So it doesn't look like trivial case of something is not initialized
>> on top of it. It does seem something to do with blocking mechanism
>> though since apparently 400th row is a boundary of some blocking
>> somewhere, but it is hard for me to see where it fails at this point.
>>
>> On Thu, Dec 29, 2011 at 12:13 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>>> oh. it's because the synthetic input has only 4 singular values.
>>>
>>> On Wed, Dec 28, 2011 at 11:56 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>>>> But it is not a problem reading U or V files, that's indeed what U and
>>>> V contain.
>>>>
>>>> On Wed, Dec 28, 2011 at 11:49 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>>>>> U and V look suspect, degenerate (only 4 first columns are nonzero,
>>>>> the rest of matrices are zeros.
>>>>>
>>>>> On Wed, Dec 28, 2011 at 11:44 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>>>>>> Yeah, fails for me on ubuntu without any special environment issues.
>>>>>> Which makes it easier, i can step thru.
>>>>>>
>>>>>> On Wed, Dec 28, 2011 at 9:01 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>>>>>>> What do checksums look like?
>>>>>>>
>>>>>>> On Wed, Dec 28, 2011 at 6:33 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
>>>>>>>
>>>>>>>> I commented out the deletion of the dir in the tearDown. Not sure if that
>>>>>>>> looks reasonable or not, but on the surface they look equivalent.
>>>>>>>>
>>>>>>>> Here's the contents of the dir on Ubuntu:
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000600
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1387722 2011-12-28 21:17 A-000000800
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000000
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000210
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000420
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000630
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144312 2011-12-28 21:17 B-000000840
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-0
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-200
IBM's J9? Or even a different version of HotSpot? I remember we were
once trying to figure out a similar bug (lots of computations,
different result) in our code and it turned out that the problem was
due to different native floating point precision roundings and code
JITting at different points in time (this was a very hard stuff to
debug).
The result in our case did not propagate to such large differences,
but I would still try to reproduce with a different JVM just to see if
this makes any difference.
My next step would then be to instrument the code with AspectJ
(statically) and run on a machine (jvm) where the test passes and on
the one where it fails and dump, dump, dump execution progress (all
method entry/exit points, with arguments). These are usually very
large files, but you can easily diff them against each other and see
where _exactly_ the execution started to diverge. If you add
-XX:PrintCompilation to hotspot you may even be able to tell if this
is a JIT problem or something else.
Shooting at the dark here, but maybe you'll find it helpful. I can
help you with aspectj instrumentation if you find this interesting.
Dawid
On Thu, Dec 29, 2011 at 9:42 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
> yes. i would venture to say that U computation (or restoration) is
> somehow corrupted starting with 2nd block. at least it looks this way.
>
> On Thu, Dec 29, 2011 at 12:31 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>> A-reconstructed difference looks good up to row 399 but starting at
>> row 400 differences do not add up to 0 anymore (although both inputs
>> are not 0).
>>
>> So it doesn't look like trivial case of something is not initialized
>> on top of it. It does seem something to do with blocking mechanism
>> though since apparently 400th row is a boundary of some blocking
>> somewhere, but it is hard for me to see where it fails at this point.
>>
>> On Thu, Dec 29, 2011 at 12:13 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>>> oh. it's because the synthetic input has only 4 singular values.
>>>
>>> On Wed, Dec 28, 2011 at 11:56 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>>>> But it is not a problem reading U or V files, that's indeed what U and
>>>> V contain.
>>>>
>>>> On Wed, Dec 28, 2011 at 11:49 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>>>>> U and V look suspect, degenerate (only 4 first columns are nonzero,
>>>>> the rest of matrices are zeros.
>>>>>
>>>>> On Wed, Dec 28, 2011 at 11:44 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>>>>>> Yeah, fails for me on ubuntu without any special environment issues.
>>>>>> Which makes it easier, i can step thru.
>>>>>>
>>>>>> On Wed, Dec 28, 2011 at 9:01 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>>>>>>> What do checksums look like?
>>>>>>>
>>>>>>> On Wed, Dec 28, 2011 at 6:33 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
>>>>>>>
>>>>>>>> I commented out the deletion of the dir in the tearDown. Not sure if that
>>>>>>>> looks reasonable or not, but on the surface they look equivalent.
>>>>>>>>
>>>>>>>> Here's the contents of the dir on Ubuntu:
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000600
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1387722 2011-12-28 21:17 A-000000800
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000000
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000210
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000420
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000630
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144312 2011-12-28 21:17 B-000000840
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-0
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-200
+
Dawid Weiss 2011-12-29, 08:49
-
Re: Build failed in Jenkins: mahout-nightly #737Dmitriy Lyubimov 2011-12-29, 08:49
I see unclosed/unflushed streams in computeV, computeU, but that
doesn't seem to be the reason.
On Thu, Dec 29, 2011 at 12:42 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
> yes. i would venture to say that U computation (or restoration) is
> somehow corrupted starting with 2nd block. at least it looks this way.
>
> On Thu, Dec 29, 2011 at 12:31 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>> A-reconstructed difference looks good up to row 399 but starting at
>> row 400 differences do not add up to 0 anymore (although both inputs
>> are not 0).
>>
>> So it doesn't look like trivial case of something is not initialized
>> on top of it. It does seem something to do with blocking mechanism
>> though since apparently 400th row is a boundary of some blocking
>> somewhere, but it is hard for me to see where it fails at this point.
>>
>> On Thu, Dec 29, 2011 at 12:13 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>>> oh. it's because the synthetic input has only 4 singular values.
>>>
>>> On Wed, Dec 28, 2011 at 11:56 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>>>> But it is not a problem reading U or V files, that's indeed what U and
>>>> V contain.
>>>>
>>>> On Wed, Dec 28, 2011 at 11:49 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>>>>> U and V look suspect, degenerate (only 4 first columns are nonzero,
>>>>> the rest of matrices are zeros.
>>>>>
>>>>> On Wed, Dec 28, 2011 at 11:44 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>>>>>> Yeah, fails for me on ubuntu without any special environment issues.
>>>>>> Which makes it easier, i can step thru.
>>>>>>
>>>>>> On Wed, Dec 28, 2011 at 9:01 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>>>>>>> What do checksums look like?
>>>>>>>
>>>>>>> On Wed, Dec 28, 2011 at 6:33 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
>>>>>>>
>>>>>>>> I commented out the deletion of the dir in the tearDown. Not sure if that
>>>>>>>> looks reasonable or not, but on the surface they look equivalent.
>>>>>>>>
>>>>>>>> Here's the contents of the dir on Ubuntu:
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000600
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1387722 2011-12-28 21:17 A-000000800
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000000
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000210
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000420
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000630
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144312 2011-12-28 21:17 B-000000840
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-0
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-200
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-400
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-600
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 136352 2011-12-28 21:17 U-800
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-0
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-1
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-2
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-3
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144372 2011-12-28 21:17 V-4
>>>>>>>>
>>>>>>>> Here's what my Mac looks like:
>>>>>>>> total 20296
>>>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000000
>>>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000200
>>>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000400
>>>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000600
>>>>>>>> -rw-r--r-- 1 XXXXXX staff 1.3M Dec 28 21:28 A-000000800
>>>>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000000
>>>>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000210
>>>>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000420
doesn't seem to be the reason.
On Thu, Dec 29, 2011 at 12:42 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
> yes. i would venture to say that U computation (or restoration) is
> somehow corrupted starting with 2nd block. at least it looks this way.
>
> On Thu, Dec 29, 2011 at 12:31 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>> A-reconstructed difference looks good up to row 399 but starting at
>> row 400 differences do not add up to 0 anymore (although both inputs
>> are not 0).
>>
>> So it doesn't look like trivial case of something is not initialized
>> on top of it. It does seem something to do with blocking mechanism
>> though since apparently 400th row is a boundary of some blocking
>> somewhere, but it is hard for me to see where it fails at this point.
>>
>> On Thu, Dec 29, 2011 at 12:13 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>>> oh. it's because the synthetic input has only 4 singular values.
>>>
>>> On Wed, Dec 28, 2011 at 11:56 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>>>> But it is not a problem reading U or V files, that's indeed what U and
>>>> V contain.
>>>>
>>>> On Wed, Dec 28, 2011 at 11:49 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>>>>> U and V look suspect, degenerate (only 4 first columns are nonzero,
>>>>> the rest of matrices are zeros.
>>>>>
>>>>> On Wed, Dec 28, 2011 at 11:44 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>>>>>> Yeah, fails for me on ubuntu without any special environment issues.
>>>>>> Which makes it easier, i can step thru.
>>>>>>
>>>>>> On Wed, Dec 28, 2011 at 9:01 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>>>>>>> What do checksums look like?
>>>>>>>
>>>>>>> On Wed, Dec 28, 2011 at 6:33 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
>>>>>>>
>>>>>>>> I commented out the deletion of the dir in the tearDown. Not sure if that
>>>>>>>> looks reasonable or not, but on the surface they look equivalent.
>>>>>>>>
>>>>>>>> Here's the contents of the dir on Ubuntu:
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000600
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1387722 2011-12-28 21:17 A-000000800
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000000
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000210
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000420
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000630
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144312 2011-12-28 21:17 B-000000840
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-0
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-200
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-400
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-600
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 136352 2011-12-28 21:17 U-800
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-0
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-1
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-2
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-3
>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144372 2011-12-28 21:17 V-4
>>>>>>>>
>>>>>>>> Here's what my Mac looks like:
>>>>>>>> total 20296
>>>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000000
>>>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000200
>>>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000400
>>>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000600
>>>>>>>> -rw-r--r-- 1 XXXXXX staff 1.3M Dec 28 21:28 A-000000800
>>>>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000000
>>>>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000210
>>>>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000420
+
Dmitriy Lyubimov 2011-12-29, 08:49
-
Re: Build failed in Jenkins: mahout-nightly #737Ted Dunning 2011-12-29, 08:52
Thanks. Good hints.
I will take a look on a linux machine in the next few days.
On Thu, Dec 29, 2011 at 12:42 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>wrote:
> yes. i would venture to say that U computation (or restoration) is
> somehow corrupted starting with 2nd block. at least it looks this way.
>
> On Thu, Dec 29, 2011 at 12:31 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
> wrote:
> > A-reconstructed difference looks good up to row 399 but starting at
> > row 400 differences do not add up to 0 anymore (although both inputs
> > are not 0).
> >
> > So it doesn't look like trivial case of something is not initialized
> > on top of it. It does seem something to do with blocking mechanism
> > though since apparently 400th row is a boundary of some blocking
> > somewhere, but it is hard for me to see where it fails at this point.
> >
> > On Thu, Dec 29, 2011 at 12:13 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
> wrote:
> >> oh. it's because the synthetic input has only 4 singular values.
> >>
> >> On Wed, Dec 28, 2011 at 11:56 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
> wrote:
> >>> But it is not a problem reading U or V files, that's indeed what U and
> >>> V contain.
> >>>
> >>> On Wed, Dec 28, 2011 at 11:49 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
> wrote:
> >>>> U and V look suspect, degenerate (only 4 first columns are nonzero,
> >>>> the rest of matrices are zeros.
> >>>>
> >>>> On Wed, Dec 28, 2011 at 11:44 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
> wrote:
> >>>>> Yeah, fails for me on ubuntu without any special environment issues.
> >>>>> Which makes it easier, i can step thru.
> >>>>>
> >>>>> On Wed, Dec 28, 2011 at 9:01 PM, Ted Dunning <[EMAIL PROTECTED]>
> wrote:
> >>>>>> What do checksums look like?
> >>>>>>
> >>>>>> On Wed, Dec 28, 2011 at 6:33 PM, Grant Ingersoll <
> [EMAIL PROTECTED]>wrote:
> >>>>>>
> >>>>>>> I commented out the deletion of the dir in the tearDown. Not sure
> if that
> >>>>>>> looks reasonable or not, but on the surface they look equivalent.
> >>>>>>>
> >>>>>>> Here's the contents of the dir on Ubuntu:
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000600
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1387722 2011-12-28 21:17 A-000000800
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000000
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000210
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000420
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000630
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144312 2011-12-28 21:17 B-000000840
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-0
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-200
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-400
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-600
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 136352 2011-12-28 21:17 U-800
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-0
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-1
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-2
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-3
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144372 2011-12-28 21:17 V-4
> >>>>>>>
> >>>>>>> Here's what my Mac looks like:
> >>>>>>> total 20296
> >>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000000
> >>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000200
> >>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000400
> >>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000600
> >>>>>>> -rw-r--r-- 1 XXXXXX staff 1.3M Dec 28 21:28 A-000000800
> >>>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000000
> >>>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000210
I will take a look on a linux machine in the next few days.
On Thu, Dec 29, 2011 at 12:42 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>wrote:
> yes. i would venture to say that U computation (or restoration) is
> somehow corrupted starting with 2nd block. at least it looks this way.
>
> On Thu, Dec 29, 2011 at 12:31 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
> wrote:
> > A-reconstructed difference looks good up to row 399 but starting at
> > row 400 differences do not add up to 0 anymore (although both inputs
> > are not 0).
> >
> > So it doesn't look like trivial case of something is not initialized
> > on top of it. It does seem something to do with blocking mechanism
> > though since apparently 400th row is a boundary of some blocking
> > somewhere, but it is hard for me to see where it fails at this point.
> >
> > On Thu, Dec 29, 2011 at 12:13 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
> wrote:
> >> oh. it's because the synthetic input has only 4 singular values.
> >>
> >> On Wed, Dec 28, 2011 at 11:56 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
> wrote:
> >>> But it is not a problem reading U or V files, that's indeed what U and
> >>> V contain.
> >>>
> >>> On Wed, Dec 28, 2011 at 11:49 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
> wrote:
> >>>> U and V look suspect, degenerate (only 4 first columns are nonzero,
> >>>> the rest of matrices are zeros.
> >>>>
> >>>> On Wed, Dec 28, 2011 at 11:44 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
> wrote:
> >>>>> Yeah, fails for me on ubuntu without any special environment issues.
> >>>>> Which makes it easier, i can step thru.
> >>>>>
> >>>>> On Wed, Dec 28, 2011 at 9:01 PM, Ted Dunning <[EMAIL PROTECTED]>
> wrote:
> >>>>>> What do checksums look like?
> >>>>>>
> >>>>>> On Wed, Dec 28, 2011 at 6:33 PM, Grant Ingersoll <
> [EMAIL PROTECTED]>wrote:
> >>>>>>
> >>>>>>> I commented out the deletion of the dir in the tearDown. Not sure
> if that
> >>>>>>> looks reasonable or not, but on the surface they look equivalent.
> >>>>>>>
> >>>>>>> Here's the contents of the dir on Ubuntu:
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000600
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1387722 2011-12-28 21:17 A-000000800
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000000
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000210
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000420
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000630
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144312 2011-12-28 21:17 B-000000840
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-0
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-200
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-400
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 160412 2011-12-28 21:17 U-600
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 136352 2011-12-28 21:17 U-800
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-0
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-1
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-2
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168432 2011-12-28 21:17 V-3
> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 144372 2011-12-28 21:17 V-4
> >>>>>>>
> >>>>>>> Here's what my Mac looks like:
> >>>>>>> total 20296
> >>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000000
> >>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000200
> >>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000400
> >>>>>>> -rw-r--r-- 1 XXXXXX staff 1.6M Dec 28 21:28 A-000000600
> >>>>>>> -rw-r--r-- 1 XXXXXX staff 1.3M Dec 28 21:28 A-000000800
> >>>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000000
> >>>>>>> -rw-r--r-- 1 XXXXXX staff 164K Dec 28 21:28 B-000000210
+
Ted Dunning 2011-12-29, 08:52
-
Re: Build failed in Jenkins: mahout-nightly #737Dmitriy Lyubimov 2011-12-29, 08:57
MD5 sums
b8217318a29ef69c58b921013eb019e5 /tmp/matrix8554072597307396201/A-000000000
41db088ff74c5efd5b766dba253efc03 /tmp/matrix8554072597307396201/A-000000200
b8217318a29ef69c58b921013eb019e5 /tmp/matrix8554072597307396201/A-000000400
41db088ff74c5efd5b766dba253efc03 /tmp/matrix8554072597307396201/A-000000600
c8dc2a7df82065b5c1e8284ff23aecc6 /tmp/matrix8554072597307396201/A-000000800
83bccdd2fa191e01d34646e2030f0e77 /tmp/matrix8554072597307396201/B-000000000
9d6878fb789d61d5453b994ea1a5c6db /tmp/matrix8554072597307396201/B-000000210
cbdf720b17ce25feb686effd1aa0ebef /tmp/matrix8554072597307396201/B-000000420
2f71d6ba6891b242575b5cc6ba1c4358 /tmp/matrix8554072597307396201/B-000000630
f50b76bb48c8f6a791a6d8206d980492 /tmp/matrix8554072597307396201/B-000000840
6bb29ca304889a6c8effff6e5c062dc8 /tmp/matrix8554072597307396201/U-0
019c881c1d7c5748a1cacb3e0b3e5899 /tmp/matrix8554072597307396201/U-200
019c881c1d7c5748a1cacb3e0b3e5899 /tmp/matrix8554072597307396201/U-400
b84e4b01ffb9d691c87b496f8b4d84ec /tmp/matrix8554072597307396201/U-600
6bb29ca304889a6c8effff6e5c062dc8 /tmp/matrix8554072597307396201/U-770
On Thu, Dec 29, 2011 at 12:52 AM, Ted Dunning <[EMAIL PROTECTED]> wrote:
> Thanks. Good hints.
>
> I will take a look on a linux machine in the next few days.
>
> On Thu, Dec 29, 2011 at 12:42 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>wrote:
>
>> yes. i would venture to say that U computation (or restoration) is
>> somehow corrupted starting with 2nd block. at least it looks this way.
>>
>> On Thu, Dec 29, 2011 at 12:31 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>> wrote:
>> > A-reconstructed difference looks good up to row 399 but starting at
>> > row 400 differences do not add up to 0 anymore (although both inputs
>> > are not 0).
>> >
>> > So it doesn't look like trivial case of something is not initialized
>> > on top of it. It does seem something to do with blocking mechanism
>> > though since apparently 400th row is a boundary of some blocking
>> > somewhere, but it is hard for me to see where it fails at this point.
>> >
>> > On Thu, Dec 29, 2011 at 12:13 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>> wrote:
>> >> oh. it's because the synthetic input has only 4 singular values.
>> >>
>> >> On Wed, Dec 28, 2011 at 11:56 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>> wrote:
>> >>> But it is not a problem reading U or V files, that's indeed what U and
>> >>> V contain.
>> >>>
>> >>> On Wed, Dec 28, 2011 at 11:49 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>> wrote:
>> >>>> U and V look suspect, degenerate (only 4 first columns are nonzero,
>> >>>> the rest of matrices are zeros.
>> >>>>
>> >>>> On Wed, Dec 28, 2011 at 11:44 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>> wrote:
>> >>>>> Yeah, fails for me on ubuntu without any special environment issues.
>> >>>>> Which makes it easier, i can step thru.
>> >>>>>
>> >>>>> On Wed, Dec 28, 2011 at 9:01 PM, Ted Dunning <[EMAIL PROTECTED]>
>> wrote:
>> >>>>>> What do checksums look like?
>> >>>>>>
>> >>>>>> On Wed, Dec 28, 2011 at 6:33 PM, Grant Ingersoll <
>> [EMAIL PROTECTED]>wrote:
>> >>>>>>
>> >>>>>>> I commented out the deletion of the dir in the tearDown. Not sure
>> if that
>> >>>>>>> looks reasonable or not, but on the surface they look equivalent.
>> >>>>>>>
>> >>>>>>> Here's the contents of the dir on Ubuntu:
>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000600
>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1387722 2011-12-28 21:17 A-000000800
>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000000
>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000210
>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000420
>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000630
b8217318a29ef69c58b921013eb019e5 /tmp/matrix8554072597307396201/A-000000000
41db088ff74c5efd5b766dba253efc03 /tmp/matrix8554072597307396201/A-000000200
b8217318a29ef69c58b921013eb019e5 /tmp/matrix8554072597307396201/A-000000400
41db088ff74c5efd5b766dba253efc03 /tmp/matrix8554072597307396201/A-000000600
c8dc2a7df82065b5c1e8284ff23aecc6 /tmp/matrix8554072597307396201/A-000000800
83bccdd2fa191e01d34646e2030f0e77 /tmp/matrix8554072597307396201/B-000000000
9d6878fb789d61d5453b994ea1a5c6db /tmp/matrix8554072597307396201/B-000000210
cbdf720b17ce25feb686effd1aa0ebef /tmp/matrix8554072597307396201/B-000000420
2f71d6ba6891b242575b5cc6ba1c4358 /tmp/matrix8554072597307396201/B-000000630
f50b76bb48c8f6a791a6d8206d980492 /tmp/matrix8554072597307396201/B-000000840
6bb29ca304889a6c8effff6e5c062dc8 /tmp/matrix8554072597307396201/U-0
019c881c1d7c5748a1cacb3e0b3e5899 /tmp/matrix8554072597307396201/U-200
019c881c1d7c5748a1cacb3e0b3e5899 /tmp/matrix8554072597307396201/U-400
b84e4b01ffb9d691c87b496f8b4d84ec /tmp/matrix8554072597307396201/U-600
6bb29ca304889a6c8effff6e5c062dc8 /tmp/matrix8554072597307396201/U-770
On Thu, Dec 29, 2011 at 12:52 AM, Ted Dunning <[EMAIL PROTECTED]> wrote:
> Thanks. Good hints.
>
> I will take a look on a linux machine in the next few days.
>
> On Thu, Dec 29, 2011 at 12:42 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>wrote:
>
>> yes. i would venture to say that U computation (or restoration) is
>> somehow corrupted starting with 2nd block. at least it looks this way.
>>
>> On Thu, Dec 29, 2011 at 12:31 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>> wrote:
>> > A-reconstructed difference looks good up to row 399 but starting at
>> > row 400 differences do not add up to 0 anymore (although both inputs
>> > are not 0).
>> >
>> > So it doesn't look like trivial case of something is not initialized
>> > on top of it. It does seem something to do with blocking mechanism
>> > though since apparently 400th row is a boundary of some blocking
>> > somewhere, but it is hard for me to see where it fails at this point.
>> >
>> > On Thu, Dec 29, 2011 at 12:13 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>> wrote:
>> >> oh. it's because the synthetic input has only 4 singular values.
>> >>
>> >> On Wed, Dec 28, 2011 at 11:56 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>> wrote:
>> >>> But it is not a problem reading U or V files, that's indeed what U and
>> >>> V contain.
>> >>>
>> >>> On Wed, Dec 28, 2011 at 11:49 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>> wrote:
>> >>>> U and V look suspect, degenerate (only 4 first columns are nonzero,
>> >>>> the rest of matrices are zeros.
>> >>>>
>> >>>> On Wed, Dec 28, 2011 at 11:44 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>> wrote:
>> >>>>> Yeah, fails for me on ubuntu without any special environment issues.
>> >>>>> Which makes it easier, i can step thru.
>> >>>>>
>> >>>>> On Wed, Dec 28, 2011 at 9:01 PM, Ted Dunning <[EMAIL PROTECTED]>
>> wrote:
>> >>>>>> What do checksums look like?
>> >>>>>>
>> >>>>>> On Wed, Dec 28, 2011 at 6:33 PM, Grant Ingersoll <
>> [EMAIL PROTECTED]>wrote:
>> >>>>>>
>> >>>>>>> I commented out the deletion of the dir in the tearDown. Not sure
>> if that
>> >>>>>>> looks reasonable or not, but on the surface they look equivalent.
>> >>>>>>>
>> >>>>>>> Here's the contents of the dir on Ubuntu:
>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000600
>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1387722 2011-12-28 21:17 A-000000800
>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000000
>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000210
>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000420
>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000630
+
Dmitriy Lyubimov 2011-12-29, 08:57
-
Re: Build failed in Jenkins: mahout-nightly #737Dmitriy Lyubimov 2011-12-29, 08:58
note identical md5 for u200 and u400.
On Thu, Dec 29, 2011 at 12:57 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
> MD5 sums
>
> b8217318a29ef69c58b921013eb019e5 /tmp/matrix8554072597307396201/A-000000000
> 41db088ff74c5efd5b766dba253efc03 /tmp/matrix8554072597307396201/A-000000200
> b8217318a29ef69c58b921013eb019e5 /tmp/matrix8554072597307396201/A-000000400
> 41db088ff74c5efd5b766dba253efc03 /tmp/matrix8554072597307396201/A-000000600
> c8dc2a7df82065b5c1e8284ff23aecc6 /tmp/matrix8554072597307396201/A-000000800
> 83bccdd2fa191e01d34646e2030f0e77 /tmp/matrix8554072597307396201/B-000000000
> 9d6878fb789d61d5453b994ea1a5c6db /tmp/matrix8554072597307396201/B-000000210
> cbdf720b17ce25feb686effd1aa0ebef /tmp/matrix8554072597307396201/B-000000420
> 2f71d6ba6891b242575b5cc6ba1c4358 /tmp/matrix8554072597307396201/B-000000630
> f50b76bb48c8f6a791a6d8206d980492 /tmp/matrix8554072597307396201/B-000000840
> 6bb29ca304889a6c8effff6e5c062dc8 /tmp/matrix8554072597307396201/U-0
> 019c881c1d7c5748a1cacb3e0b3e5899 /tmp/matrix8554072597307396201/U-200
> 019c881c1d7c5748a1cacb3e0b3e5899 /tmp/matrix8554072597307396201/U-400
> b84e4b01ffb9d691c87b496f8b4d84ec /tmp/matrix8554072597307396201/U-600
> 6bb29ca304889a6c8effff6e5c062dc8 /tmp/matrix8554072597307396201/U-770
>
>
> On Thu, Dec 29, 2011 at 12:52 AM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>> Thanks. Good hints.
>>
>> I will take a look on a linux machine in the next few days.
>>
>> On Thu, Dec 29, 2011 at 12:42 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>wrote:
>>
>>> yes. i would venture to say that U computation (or restoration) is
>>> somehow corrupted starting with 2nd block. at least it looks this way.
>>>
>>> On Thu, Dec 29, 2011 at 12:31 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>> wrote:
>>> > A-reconstructed difference looks good up to row 399 but starting at
>>> > row 400 differences do not add up to 0 anymore (although both inputs
>>> > are not 0).
>>> >
>>> > So it doesn't look like trivial case of something is not initialized
>>> > on top of it. It does seem something to do with blocking mechanism
>>> > though since apparently 400th row is a boundary of some blocking
>>> > somewhere, but it is hard for me to see where it fails at this point.
>>> >
>>> > On Thu, Dec 29, 2011 at 12:13 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>> wrote:
>>> >> oh. it's because the synthetic input has only 4 singular values.
>>> >>
>>> >> On Wed, Dec 28, 2011 at 11:56 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>> wrote:
>>> >>> But it is not a problem reading U or V files, that's indeed what U and
>>> >>> V contain.
>>> >>>
>>> >>> On Wed, Dec 28, 2011 at 11:49 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>> wrote:
>>> >>>> U and V look suspect, degenerate (only 4 first columns are nonzero,
>>> >>>> the rest of matrices are zeros.
>>> >>>>
>>> >>>> On Wed, Dec 28, 2011 at 11:44 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>> wrote:
>>> >>>>> Yeah, fails for me on ubuntu without any special environment issues.
>>> >>>>> Which makes it easier, i can step thru.
>>> >>>>>
>>> >>>>> On Wed, Dec 28, 2011 at 9:01 PM, Ted Dunning <[EMAIL PROTECTED]>
>>> wrote:
>>> >>>>>> What do checksums look like?
>>> >>>>>>
>>> >>>>>> On Wed, Dec 28, 2011 at 6:33 PM, Grant Ingersoll <
>>> [EMAIL PROTECTED]>wrote:
>>> >>>>>>
>>> >>>>>>> I commented out the deletion of the dir in the tearDown. Not sure
>>> if that
>>> >>>>>>> looks reasonable or not, but on the surface they look equivalent.
>>> >>>>>>>
>>> >>>>>>> Here's the contents of the dir on Ubuntu:
>>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
>>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
>>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
>>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000600
>>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1387722 2011-12-28 21:17 A-000000800
>>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000000
>>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000210
On Thu, Dec 29, 2011 at 12:57 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
> MD5 sums
>
> b8217318a29ef69c58b921013eb019e5 /tmp/matrix8554072597307396201/A-000000000
> 41db088ff74c5efd5b766dba253efc03 /tmp/matrix8554072597307396201/A-000000200
> b8217318a29ef69c58b921013eb019e5 /tmp/matrix8554072597307396201/A-000000400
> 41db088ff74c5efd5b766dba253efc03 /tmp/matrix8554072597307396201/A-000000600
> c8dc2a7df82065b5c1e8284ff23aecc6 /tmp/matrix8554072597307396201/A-000000800
> 83bccdd2fa191e01d34646e2030f0e77 /tmp/matrix8554072597307396201/B-000000000
> 9d6878fb789d61d5453b994ea1a5c6db /tmp/matrix8554072597307396201/B-000000210
> cbdf720b17ce25feb686effd1aa0ebef /tmp/matrix8554072597307396201/B-000000420
> 2f71d6ba6891b242575b5cc6ba1c4358 /tmp/matrix8554072597307396201/B-000000630
> f50b76bb48c8f6a791a6d8206d980492 /tmp/matrix8554072597307396201/B-000000840
> 6bb29ca304889a6c8effff6e5c062dc8 /tmp/matrix8554072597307396201/U-0
> 019c881c1d7c5748a1cacb3e0b3e5899 /tmp/matrix8554072597307396201/U-200
> 019c881c1d7c5748a1cacb3e0b3e5899 /tmp/matrix8554072597307396201/U-400
> b84e4b01ffb9d691c87b496f8b4d84ec /tmp/matrix8554072597307396201/U-600
> 6bb29ca304889a6c8effff6e5c062dc8 /tmp/matrix8554072597307396201/U-770
>
>
> On Thu, Dec 29, 2011 at 12:52 AM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>> Thanks. Good hints.
>>
>> I will take a look on a linux machine in the next few days.
>>
>> On Thu, Dec 29, 2011 at 12:42 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>wrote:
>>
>>> yes. i would venture to say that U computation (or restoration) is
>>> somehow corrupted starting with 2nd block. at least it looks this way.
>>>
>>> On Thu, Dec 29, 2011 at 12:31 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>> wrote:
>>> > A-reconstructed difference looks good up to row 399 but starting at
>>> > row 400 differences do not add up to 0 anymore (although both inputs
>>> > are not 0).
>>> >
>>> > So it doesn't look like trivial case of something is not initialized
>>> > on top of it. It does seem something to do with blocking mechanism
>>> > though since apparently 400th row is a boundary of some blocking
>>> > somewhere, but it is hard for me to see where it fails at this point.
>>> >
>>> > On Thu, Dec 29, 2011 at 12:13 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>> wrote:
>>> >> oh. it's because the synthetic input has only 4 singular values.
>>> >>
>>> >> On Wed, Dec 28, 2011 at 11:56 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>> wrote:
>>> >>> But it is not a problem reading U or V files, that's indeed what U and
>>> >>> V contain.
>>> >>>
>>> >>> On Wed, Dec 28, 2011 at 11:49 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>> wrote:
>>> >>>> U and V look suspect, degenerate (only 4 first columns are nonzero,
>>> >>>> the rest of matrices are zeros.
>>> >>>>
>>> >>>> On Wed, Dec 28, 2011 at 11:44 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>> wrote:
>>> >>>>> Yeah, fails for me on ubuntu without any special environment issues.
>>> >>>>> Which makes it easier, i can step thru.
>>> >>>>>
>>> >>>>> On Wed, Dec 28, 2011 at 9:01 PM, Ted Dunning <[EMAIL PROTECTED]>
>>> wrote:
>>> >>>>>> What do checksums look like?
>>> >>>>>>
>>> >>>>>> On Wed, Dec 28, 2011 at 6:33 PM, Grant Ingersoll <
>>> [EMAIL PROTECTED]>wrote:
>>> >>>>>>
>>> >>>>>>> I commented out the deletion of the dir in the tearDown. Not sure
>>> if that
>>> >>>>>>> looks reasonable or not, but on the surface they look equivalent.
>>> >>>>>>>
>>> >>>>>>> Here's the contents of the dir on Ubuntu:
>>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
>>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
>>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
>>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000600
>>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1387722 2011-12-28 21:17 A-000000800
>>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000000
>>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 168312 2011-12-28 21:17 B-000000210
+
Dmitriy Lyubimov 2011-12-29, 08:58
-
Re: Build failed in Jenkins: mahout-nightly #737Lance Norskog 2011-12-30, 01:19
A-0 and A-400 match, and A-200 and A-600 match.
Bs are all unique.
U-200 matches U-400
On Thu, Dec 29, 2011 at 12:58 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
> note identical md5 for u200 and u400.
>
> On Thu, Dec 29, 2011 at 12:57 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>> MD5 sums
>>
>> b8217318a29ef69c58b921013eb019e5 /tmp/matrix8554072597307396201/A-000000000
>> 41db088ff74c5efd5b766dba253efc03 /tmp/matrix8554072597307396201/A-000000200
>> b8217318a29ef69c58b921013eb019e5 /tmp/matrix8554072597307396201/A-000000400
>> 41db088ff74c5efd5b766dba253efc03 /tmp/matrix8554072597307396201/A-000000600
>> c8dc2a7df82065b5c1e8284ff23aecc6 /tmp/matrix8554072597307396201/A-000000800
>> 83bccdd2fa191e01d34646e2030f0e77 /tmp/matrix8554072597307396201/B-000000000
>> 9d6878fb789d61d5453b994ea1a5c6db /tmp/matrix8554072597307396201/B-000000210
>> cbdf720b17ce25feb686effd1aa0ebef /tmp/matrix8554072597307396201/B-000000420
>> 2f71d6ba6891b242575b5cc6ba1c4358 /tmp/matrix8554072597307396201/B-000000630
>> f50b76bb48c8f6a791a6d8206d980492 /tmp/matrix8554072597307396201/B-000000840
>> 6bb29ca304889a6c8effff6e5c062dc8 /tmp/matrix8554072597307396201/U-0
>> 019c881c1d7c5748a1cacb3e0b3e5899 /tmp/matrix8554072597307396201/U-200
>> 019c881c1d7c5748a1cacb3e0b3e5899 /tmp/matrix8554072597307396201/U-400
>> b84e4b01ffb9d691c87b496f8b4d84ec /tmp/matrix8554072597307396201/U-600
>> 6bb29ca304889a6c8effff6e5c062dc8 /tmp/matrix8554072597307396201/U-770
>>
>>
>> On Thu, Dec 29, 2011 at 12:52 AM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>>> Thanks. Good hints.
>>>
>>> I will take a look on a linux machine in the next few days.
>>>
>>> On Thu, Dec 29, 2011 at 12:42 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>wrote:
>>>
>>>> yes. i would venture to say that U computation (or restoration) is
>>>> somehow corrupted starting with 2nd block. at least it looks this way.
>>>>
>>>> On Thu, Dec 29, 2011 at 12:31 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>>> wrote:
>>>> > A-reconstructed difference looks good up to row 399 but starting at
>>>> > row 400 differences do not add up to 0 anymore (although both inputs
>>>> > are not 0).
>>>> >
>>>> > So it doesn't look like trivial case of something is not initialized
>>>> > on top of it. It does seem something to do with blocking mechanism
>>>> > though since apparently 400th row is a boundary of some blocking
>>>> > somewhere, but it is hard for me to see where it fails at this point.
>>>> >
>>>> > On Thu, Dec 29, 2011 at 12:13 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>>> wrote:
>>>> >> oh. it's because the synthetic input has only 4 singular values.
>>>> >>
>>>> >> On Wed, Dec 28, 2011 at 11:56 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>>> wrote:
>>>> >>> But it is not a problem reading U or V files, that's indeed what U and
>>>> >>> V contain.
>>>> >>>
>>>> >>> On Wed, Dec 28, 2011 at 11:49 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>>> wrote:
>>>> >>>> U and V look suspect, degenerate (only 4 first columns are nonzero,
>>>> >>>> the rest of matrices are zeros.
>>>> >>>>
>>>> >>>> On Wed, Dec 28, 2011 at 11:44 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>>> wrote:
>>>> >>>>> Yeah, fails for me on ubuntu without any special environment issues.
>>>> >>>>> Which makes it easier, i can step thru.
>>>> >>>>>
>>>> >>>>> On Wed, Dec 28, 2011 at 9:01 PM, Ted Dunning <[EMAIL PROTECTED]>
>>>> wrote:
>>>> >>>>>> What do checksums look like?
>>>> >>>>>>
>>>> >>>>>> On Wed, Dec 28, 2011 at 6:33 PM, Grant Ingersoll <
>>>> [EMAIL PROTECTED]>wrote:
>>>> >>>>>>
>>>> >>>>>>> I commented out the deletion of the dir in the tearDown. Not sure
>>>> if that
>>>> >>>>>>> looks reasonable or not, but on the surface they look equivalent.
>>>> >>>>>>>
>>>> >>>>>>> Here's the contents of the dir on Ubuntu:
>>>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
>>>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
>>>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
Lance Norskog
[EMAIL PROTECTED]
Bs are all unique.
U-200 matches U-400
On Thu, Dec 29, 2011 at 12:58 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
> note identical md5 for u200 and u400.
>
> On Thu, Dec 29, 2011 at 12:57 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>> MD5 sums
>>
>> b8217318a29ef69c58b921013eb019e5 /tmp/matrix8554072597307396201/A-000000000
>> 41db088ff74c5efd5b766dba253efc03 /tmp/matrix8554072597307396201/A-000000200
>> b8217318a29ef69c58b921013eb019e5 /tmp/matrix8554072597307396201/A-000000400
>> 41db088ff74c5efd5b766dba253efc03 /tmp/matrix8554072597307396201/A-000000600
>> c8dc2a7df82065b5c1e8284ff23aecc6 /tmp/matrix8554072597307396201/A-000000800
>> 83bccdd2fa191e01d34646e2030f0e77 /tmp/matrix8554072597307396201/B-000000000
>> 9d6878fb789d61d5453b994ea1a5c6db /tmp/matrix8554072597307396201/B-000000210
>> cbdf720b17ce25feb686effd1aa0ebef /tmp/matrix8554072597307396201/B-000000420
>> 2f71d6ba6891b242575b5cc6ba1c4358 /tmp/matrix8554072597307396201/B-000000630
>> f50b76bb48c8f6a791a6d8206d980492 /tmp/matrix8554072597307396201/B-000000840
>> 6bb29ca304889a6c8effff6e5c062dc8 /tmp/matrix8554072597307396201/U-0
>> 019c881c1d7c5748a1cacb3e0b3e5899 /tmp/matrix8554072597307396201/U-200
>> 019c881c1d7c5748a1cacb3e0b3e5899 /tmp/matrix8554072597307396201/U-400
>> b84e4b01ffb9d691c87b496f8b4d84ec /tmp/matrix8554072597307396201/U-600
>> 6bb29ca304889a6c8effff6e5c062dc8 /tmp/matrix8554072597307396201/U-770
>>
>>
>> On Thu, Dec 29, 2011 at 12:52 AM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>>> Thanks. Good hints.
>>>
>>> I will take a look on a linux machine in the next few days.
>>>
>>> On Thu, Dec 29, 2011 at 12:42 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>wrote:
>>>
>>>> yes. i would venture to say that U computation (or restoration) is
>>>> somehow corrupted starting with 2nd block. at least it looks this way.
>>>>
>>>> On Thu, Dec 29, 2011 at 12:31 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>>> wrote:
>>>> > A-reconstructed difference looks good up to row 399 but starting at
>>>> > row 400 differences do not add up to 0 anymore (although both inputs
>>>> > are not 0).
>>>> >
>>>> > So it doesn't look like trivial case of something is not initialized
>>>> > on top of it. It does seem something to do with blocking mechanism
>>>> > though since apparently 400th row is a boundary of some blocking
>>>> > somewhere, but it is hard for me to see where it fails at this point.
>>>> >
>>>> > On Thu, Dec 29, 2011 at 12:13 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>>> wrote:
>>>> >> oh. it's because the synthetic input has only 4 singular values.
>>>> >>
>>>> >> On Wed, Dec 28, 2011 at 11:56 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>>> wrote:
>>>> >>> But it is not a problem reading U or V files, that's indeed what U and
>>>> >>> V contain.
>>>> >>>
>>>> >>> On Wed, Dec 28, 2011 at 11:49 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>>> wrote:
>>>> >>>> U and V look suspect, degenerate (only 4 first columns are nonzero,
>>>> >>>> the rest of matrices are zeros.
>>>> >>>>
>>>> >>>> On Wed, Dec 28, 2011 at 11:44 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>>> wrote:
>>>> >>>>> Yeah, fails for me on ubuntu without any special environment issues.
>>>> >>>>> Which makes it easier, i can step thru.
>>>> >>>>>
>>>> >>>>> On Wed, Dec 28, 2011 at 9:01 PM, Ted Dunning <[EMAIL PROTECTED]>
>>>> wrote:
>>>> >>>>>> What do checksums look like?
>>>> >>>>>>
>>>> >>>>>> On Wed, Dec 28, 2011 at 6:33 PM, Grant Ingersoll <
>>>> [EMAIL PROTECTED]>wrote:
>>>> >>>>>>
>>>> >>>>>>> I commented out the deletion of the dir in the tearDown. Not sure
>>>> if that
>>>> >>>>>>> looks reasonable or not, but on the surface they look equivalent.
>>>> >>>>>>>
>>>> >>>>>>> Here's the contents of the dir on Ubuntu:
>>>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
>>>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
>>>> >>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
Lance Norskog
[EMAIL PROTECTED]
+
Lance Norskog 2011-12-30, 01:19
-
Re: Build failed in Jenkins: mahout-nightly #737Grant Ingersoll 2011-12-31, 22:25
Any progress on this? Seems like it is a show stopper for code freeze.
On Dec 29, 2011, at 3:58 AM, Dmitriy Lyubimov wrote:
> note identical md5 for u200 and u400.
>
> On Thu, Dec 29, 2011 at 12:57 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>> MD5 sums
>>
>> b8217318a29ef69c58b921013eb019e5 /tmp/matrix8554072597307396201/A-000000000
>> 41db088ff74c5efd5b766dba253efc03 /tmp/matrix8554072597307396201/A-000000200
>> b8217318a29ef69c58b921013eb019e5 /tmp/matrix8554072597307396201/A-000000400
>> 41db088ff74c5efd5b766dba253efc03 /tmp/matrix8554072597307396201/A-000000600
>> c8dc2a7df82065b5c1e8284ff23aecc6 /tmp/matrix8554072597307396201/A-000000800
>> 83bccdd2fa191e01d34646e2030f0e77 /tmp/matrix8554072597307396201/B-000000000
>> 9d6878fb789d61d5453b994ea1a5c6db /tmp/matrix8554072597307396201/B-000000210
>> cbdf720b17ce25feb686effd1aa0ebef /tmp/matrix8554072597307396201/B-000000420
>> 2f71d6ba6891b242575b5cc6ba1c4358 /tmp/matrix8554072597307396201/B-000000630
>> f50b76bb48c8f6a791a6d8206d980492 /tmp/matrix8554072597307396201/B-000000840
>> 6bb29ca304889a6c8effff6e5c062dc8 /tmp/matrix8554072597307396201/U-0
>> 019c881c1d7c5748a1cacb3e0b3e5899 /tmp/matrix8554072597307396201/U-200
>> 019c881c1d7c5748a1cacb3e0b3e5899 /tmp/matrix8554072597307396201/U-400
>> b84e4b01ffb9d691c87b496f8b4d84ec /tmp/matrix8554072597307396201/U-600
>> 6bb29ca304889a6c8effff6e5c062dc8 /tmp/matrix8554072597307396201/U-770
>>
>>
>> On Thu, Dec 29, 2011 at 12:52 AM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>>> Thanks. Good hints.
>>>
>>> I will take a look on a linux machine in the next few days.
>>>
>>> On Thu, Dec 29, 2011 at 12:42 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>wrote:
>>>
>>>> yes. i would venture to say that U computation (or restoration) is
>>>> somehow corrupted starting with 2nd block. at least it looks this way.
>>>>
>>>> On Thu, Dec 29, 2011 at 12:31 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>>> wrote:
>>>>> A-reconstructed difference looks good up to row 399 but starting at
>>>>> row 400 differences do not add up to 0 anymore (although both inputs
>>>>> are not 0).
>>>>>
>>>>> So it doesn't look like trivial case of something is not initialized
>>>>> on top of it. It does seem something to do with blocking mechanism
>>>>> though since apparently 400th row is a boundary of some blocking
>>>>> somewhere, but it is hard for me to see where it fails at this point.
>>>>>
>>>>> On Thu, Dec 29, 2011 at 12:13 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>>> wrote:
>>>>>> oh. it's because the synthetic input has only 4 singular values.
>>>>>>
>>>>>> On Wed, Dec 28, 2011 at 11:56 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>>> wrote:
>>>>>>> But it is not a problem reading U or V files, that's indeed what U and
>>>>>>> V contain.
>>>>>>>
>>>>>>> On Wed, Dec 28, 2011 at 11:49 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>>> wrote:
>>>>>>>> U and V look suspect, degenerate (only 4 first columns are nonzero,
>>>>>>>> the rest of matrices are zeros.
>>>>>>>>
>>>>>>>> On Wed, Dec 28, 2011 at 11:44 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>>> wrote:
>>>>>>>>> Yeah, fails for me on ubuntu without any special environment issues.
>>>>>>>>> Which makes it easier, i can step thru.
>>>>>>>>>
>>>>>>>>> On Wed, Dec 28, 2011 at 9:01 PM, Ted Dunning <[EMAIL PROTECTED]>
>>>> wrote:
>>>>>>>>>> What do checksums look like?
>>>>>>>>>>
>>>>>>>>>> On Wed, Dec 28, 2011 at 6:33 PM, Grant Ingersoll <
>>>> [EMAIL PROTECTED]>wrote:
>>>>>>>>>>
>>>>>>>>>>> I commented out the deletion of the dir in the tearDown. Not sure
>>>> if that
>>>>>>>>>>> looks reasonable or not, but on the surface they look equivalent.
>>>>>>>>>>>
>>>>>>>>>>> Here's the contents of the dir on Ubuntu:
>>>>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
>>>>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
>>>>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
>>>>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000600
Grant Ingersoll
http://www.lucidimagination.com
On Dec 29, 2011, at 3:58 AM, Dmitriy Lyubimov wrote:
> note identical md5 for u200 and u400.
>
> On Thu, Dec 29, 2011 at 12:57 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]> wrote:
>> MD5 sums
>>
>> b8217318a29ef69c58b921013eb019e5 /tmp/matrix8554072597307396201/A-000000000
>> 41db088ff74c5efd5b766dba253efc03 /tmp/matrix8554072597307396201/A-000000200
>> b8217318a29ef69c58b921013eb019e5 /tmp/matrix8554072597307396201/A-000000400
>> 41db088ff74c5efd5b766dba253efc03 /tmp/matrix8554072597307396201/A-000000600
>> c8dc2a7df82065b5c1e8284ff23aecc6 /tmp/matrix8554072597307396201/A-000000800
>> 83bccdd2fa191e01d34646e2030f0e77 /tmp/matrix8554072597307396201/B-000000000
>> 9d6878fb789d61d5453b994ea1a5c6db /tmp/matrix8554072597307396201/B-000000210
>> cbdf720b17ce25feb686effd1aa0ebef /tmp/matrix8554072597307396201/B-000000420
>> 2f71d6ba6891b242575b5cc6ba1c4358 /tmp/matrix8554072597307396201/B-000000630
>> f50b76bb48c8f6a791a6d8206d980492 /tmp/matrix8554072597307396201/B-000000840
>> 6bb29ca304889a6c8effff6e5c062dc8 /tmp/matrix8554072597307396201/U-0
>> 019c881c1d7c5748a1cacb3e0b3e5899 /tmp/matrix8554072597307396201/U-200
>> 019c881c1d7c5748a1cacb3e0b3e5899 /tmp/matrix8554072597307396201/U-400
>> b84e4b01ffb9d691c87b496f8b4d84ec /tmp/matrix8554072597307396201/U-600
>> 6bb29ca304889a6c8effff6e5c062dc8 /tmp/matrix8554072597307396201/U-770
>>
>>
>> On Thu, Dec 29, 2011 at 12:52 AM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>>> Thanks. Good hints.
>>>
>>> I will take a look on a linux machine in the next few days.
>>>
>>> On Thu, Dec 29, 2011 at 12:42 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>wrote:
>>>
>>>> yes. i would venture to say that U computation (or restoration) is
>>>> somehow corrupted starting with 2nd block. at least it looks this way.
>>>>
>>>> On Thu, Dec 29, 2011 at 12:31 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>>> wrote:
>>>>> A-reconstructed difference looks good up to row 399 but starting at
>>>>> row 400 differences do not add up to 0 anymore (although both inputs
>>>>> are not 0).
>>>>>
>>>>> So it doesn't look like trivial case of something is not initialized
>>>>> on top of it. It does seem something to do with blocking mechanism
>>>>> though since apparently 400th row is a boundary of some blocking
>>>>> somewhere, but it is hard for me to see where it fails at this point.
>>>>>
>>>>> On Thu, Dec 29, 2011 at 12:13 AM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>>> wrote:
>>>>>> oh. it's because the synthetic input has only 4 singular values.
>>>>>>
>>>>>> On Wed, Dec 28, 2011 at 11:56 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>>> wrote:
>>>>>>> But it is not a problem reading U or V files, that's indeed what U and
>>>>>>> V contain.
>>>>>>>
>>>>>>> On Wed, Dec 28, 2011 at 11:49 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>>> wrote:
>>>>>>>> U and V look suspect, degenerate (only 4 first columns are nonzero,
>>>>>>>> the rest of matrices are zeros.
>>>>>>>>
>>>>>>>> On Wed, Dec 28, 2011 at 11:44 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]>
>>>> wrote:
>>>>>>>>> Yeah, fails for me on ubuntu without any special environment issues.
>>>>>>>>> Which makes it easier, i can step thru.
>>>>>>>>>
>>>>>>>>> On Wed, Dec 28, 2011 at 9:01 PM, Ted Dunning <[EMAIL PROTECTED]>
>>>> wrote:
>>>>>>>>>> What do checksums look like?
>>>>>>>>>>
>>>>>>>>>> On Wed, Dec 28, 2011 at 6:33 PM, Grant Ingersoll <
>>>> [EMAIL PROTECTED]>wrote:
>>>>>>>>>>
>>>>>>>>>>> I commented out the deletion of the dir in the tearDown. Not sure
>>>> if that
>>>>>>>>>>> looks reasonable or not, but on the surface they look equivalent.
>>>>>>>>>>>
>>>>>>>>>>> Here's the contents of the dir on Ubuntu:
>>>>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000000
>>>>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000200
>>>>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000400
>>>>>>>>>>> -rw-rw-r-- 1 XXXXXX XXXXXX 1632612 2011-12-28 21:17 A-000000600
Grant Ingersoll
http://www.lucidimagination.com
+
Grant Ingersoll 2011-12-31, 22:25
-
Re: Build failed in Jenkins: mahout-nightly #737Grant Ingersoll 2011-12-28, 23:44
Fails on Ubuntu, but passes on my Mac.
On Dec 28, 2011, at 6:21 PM, Grant Ingersoll wrote:
> I can reproduce outside of Jenkins. It really seems odd that the answer is off by so much.
>
> On Dec 28, 2011, at 2:15 AM, Dmitriy Lyubimov wrote:
>
>> I vaguely remember Jenkins had problems with creating stuff in Java tmp
>> dir. E.g. I remember that was creating problems for Mr tasks in local mr
>> mode legitimately using boxed task temporary space.
>>
>> OK I'll try to scan for the problem tomorrow.
>> On Dec 27, 2011 10:50 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
>>
>>> So I am like everybody else. The test works for me.
>>>
>>> My suspicion is that there is something going on with the temporary
>>> directory that I am trying to use and that the environment that Jenkins is
>>> using is somehow strange.
>>>
>>> The only slightly surprising idiom I am using is to create a temporary
>>> file, delete it and recreate it as a directory. I even check the return
>>> values from the delete and the mkdir.
>>>
>>> I will keep looking.
>>>
>>> On Tue, Dec 27, 2011 at 10:37 PM, Ted Dunning <[EMAIL PROTECTED]>
>>> wrote:
>>>
>>>> Indeed it does. Thanks for pointing that out.
>>>>
>>>> This error is very strange.
>>>>
>>>>
>>>> On Tue, Dec 27, 2011 at 10:06 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]
>>>> wrote:
>>>>
>>>>> Ted,
>>>>>
>>>>> do you have an idea why this test may be failing? I think this test
>>> comes
>>>>> with M-792 commit.
>>>>>
>>>>> I can take a look at it, I suspect something in the environment can be
>>>>> tripping it.
>>>>> On Dec 27, 2011 8:54 PM, "Sean Owen" <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>>> It's all errors in the Apache infrastructure, rather than a real test
>>>>>> failure. At least, stuff passes for me locally, and that's what's
>>>>>> important.
>>>>>> So I'm ignoring these.
>>>>>>
>>>>>> On Tue, Dec 27, 2011 at 9:34 PM, Jeff Eastman
>>>>>> <[EMAIL PROTECTED]> wrote:
>>>>>>> I'm getting a lot of these emails yet all the tests run locally for
>>>>> me.
>>>>>> Does
>>>>>>> anybody have an idea what the problem is? This close to a release it
>>>>>> would
>>>>>>> be really nice to have Jenkins on our side.
>>>>>>> Jeff
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>
> --------------------------------------------
> Grant Ingersoll
> http://www.lucidimagination.com
>
>
>
--------------------------------------------
Grant Ingersoll
http://www.lucidimagination.com
On Dec 28, 2011, at 6:21 PM, Grant Ingersoll wrote:
> I can reproduce outside of Jenkins. It really seems odd that the answer is off by so much.
>
> On Dec 28, 2011, at 2:15 AM, Dmitriy Lyubimov wrote:
>
>> I vaguely remember Jenkins had problems with creating stuff in Java tmp
>> dir. E.g. I remember that was creating problems for Mr tasks in local mr
>> mode legitimately using boxed task temporary space.
>>
>> OK I'll try to scan for the problem tomorrow.
>> On Dec 27, 2011 10:50 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
>>
>>> So I am like everybody else. The test works for me.
>>>
>>> My suspicion is that there is something going on with the temporary
>>> directory that I am trying to use and that the environment that Jenkins is
>>> using is somehow strange.
>>>
>>> The only slightly surprising idiom I am using is to create a temporary
>>> file, delete it and recreate it as a directory. I even check the return
>>> values from the delete and the mkdir.
>>>
>>> I will keep looking.
>>>
>>> On Tue, Dec 27, 2011 at 10:37 PM, Ted Dunning <[EMAIL PROTECTED]>
>>> wrote:
>>>
>>>> Indeed it does. Thanks for pointing that out.
>>>>
>>>> This error is very strange.
>>>>
>>>>
>>>> On Tue, Dec 27, 2011 at 10:06 PM, Dmitriy Lyubimov <[EMAIL PROTECTED]
>>>> wrote:
>>>>
>>>>> Ted,
>>>>>
>>>>> do you have an idea why this test may be failing? I think this test
>>> comes
>>>>> with M-792 commit.
>>>>>
>>>>> I can take a look at it, I suspect something in the environment can be
>>>>> tripping it.
>>>>> On Dec 27, 2011 8:54 PM, "Sean Owen" <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>>> It's all errors in the Apache infrastructure, rather than a real test
>>>>>> failure. At least, stuff passes for me locally, and that's what's
>>>>>> important.
>>>>>> So I'm ignoring these.
>>>>>>
>>>>>> On Tue, Dec 27, 2011 at 9:34 PM, Jeff Eastman
>>>>>> <[EMAIL PROTECTED]> wrote:
>>>>>>> I'm getting a lot of these emails yet all the tests run locally for
>>>>> me.
>>>>>> Does
>>>>>>> anybody have an idea what the problem is? This close to a release it
>>>>>> would
>>>>>>> be really nice to have Jenkins on our side.
>>>>>>> Jeff
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>
> --------------------------------------------
> Grant Ingersoll
> http://www.lucidimagination.com
>
>
>
--------------------------------------------
Grant Ingersoll
http://www.lucidimagination.com
+
Grant Ingersoll 2011-12-28, 23:44
-
Re: Build failed in Jenkins: Mahout-Examples-Cluster-Reuters-II #6Lance Norskog 2012-01-10, 03:33
Seems like this should be easy to fix:
Exception in thread "main"
org.apache.hadoop.mapred.FileAlreadyExistsException: Output directory
/tmp/mahout-work-hudson/reuters-minhash already exists
at org.apache.hadoop.mapreduce.lib.output.FileOutputFormat.checkOutputSpecs(FileOutputFormat.java:134)
----------------------------------------------------------------------
12/01/09 19:12:29 WARN driver.MahoutDriver: No
org.apache.mahout.clustering.minhash.MinHashDriver.props found on
classpath, will use command-line arguments only
12/01/09 19:12:30 INFO common.AbstractJob: Command line arguments:
{--endPhase=2147483647, --hashType=murmur,
--input=/tmp/mahout-work-hudson/reuters-out-seqdir-sparse-minhash/tfidf-vectors,
--keyGroups=2, --minClusterSize=10, --minVectorSize=5,
--numHashFunctions=10, --numReducers=2,
--output=/tmp/mahout-work-hudson/reuters-minhash, --startPhase=0,
--tempDir=temp}
12/01/09 19:12:31 INFO mapred.JobClient: Cleaning up the staging area
file:/tmp/hadoop-hudson/mapred/staging/hudson916254904/.staging/job_local_0001
Exception in thread "main"
org.apache.hadoop.mapred.FileAlreadyExistsException: Output directory
/tmp/mahout-work-hudson/reuters-minhash already exists
at org.apache.hadoop.mapreduce.lib.output.FileOutputFormat.checkOutputSpecs(FileOutputFormat.java:134)
at org.apache.hadoop.mapred.JobClient$2.run(JobClient.java:846)
at org.apache.hadoop.mapred.JobClient$2.run(JobClient.java:807)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:396)
at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1059)
at org.apache.hadoop.mapred.JobClient.submitJobInternal(JobClient.java:807)
at org.apache.hadoop.mapreduce.Job.submit(Job.java:465)
at org.apache.hadoop.mapreduce.Job.waitForCompletion(Job.java:495)
at org.apache.mahout.clustering.minhash.MinHashDriver.runJob(MinHashDriver.java:86)
at org.apache.mahout.clustering.minhash.MinHashDriver.run(MinHashDriver.java:115)
at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:65)
at org.apache.mahout.clustering.minhash.MinHashDriver.main(MinHashDriver.java:41)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.hadoop.util.ProgramDriver$ProgramDescription.invoke(ProgramDriver.java:68)
at org.apache.hadoop.util.ProgramDriver.driver(ProgramDriver.java:139)
at org.apache.mahout.driver.MahoutDriver.main(MahoutDriver.java:188)
Build step 'Execute shell' marked build as failure
----------------------------------------------------------------------------------
On Mon, Jan 9, 2012 at 11:13 AM, Apache Jenkins Server
<[EMAIL PROTECTED]> wrote:
> See <https://builds.apache.org/job/Mahout-Examples-Cluster-Reuters-II/6/changes>
>
> Changes:
>
> [srowen] More of my suggested refinements
>
> [gsingers] MAHOUT-899: Add some more cluster dumping options like sampling, coloring
>
> ------------------------------------------
> [...truncated 7306 lines...]
> 12/01/09 19:11:52 INFO mapred.Merger: Down to the last merge-pass, with 0 segments left of total size: 0 bytes
> 12/01/09 19:11:52 INFO mapred.LocalJobRunner:
> 12/01/09 19:11:52 INFO mapred.JobClient: map 100% reduce 0%
> 12/01/09 19:11:52 INFO mapred.Task: Task:attempt_local_0003_r_000000_0 is done. And is in the process of commiting
> 12/01/09 19:11:52 INFO mapred.LocalJobRunner:
> 12/01/09 19:11:52 INFO mapred.Task: Task attempt_local_0003_r_000000_0 is allowed to commit now
> 12/01/09 19:11:52 INFO output.FileOutputCommitter: Saved output of task 'attempt_local_0003_r_000000_0' to /tmp/mahout-work-hudson/reuters-out-seqdir-sparse-minhash/partial-vectors-0
Lance Norskog
[EMAIL PROTECTED]
Exception in thread "main"
org.apache.hadoop.mapred.FileAlreadyExistsException: Output directory
/tmp/mahout-work-hudson/reuters-minhash already exists
at org.apache.hadoop.mapreduce.lib.output.FileOutputFormat.checkOutputSpecs(FileOutputFormat.java:134)
----------------------------------------------------------------------
12/01/09 19:12:29 WARN driver.MahoutDriver: No
org.apache.mahout.clustering.minhash.MinHashDriver.props found on
classpath, will use command-line arguments only
12/01/09 19:12:30 INFO common.AbstractJob: Command line arguments:
{--endPhase=2147483647, --hashType=murmur,
--input=/tmp/mahout-work-hudson/reuters-out-seqdir-sparse-minhash/tfidf-vectors,
--keyGroups=2, --minClusterSize=10, --minVectorSize=5,
--numHashFunctions=10, --numReducers=2,
--output=/tmp/mahout-work-hudson/reuters-minhash, --startPhase=0,
--tempDir=temp}
12/01/09 19:12:31 INFO mapred.JobClient: Cleaning up the staging area
file:/tmp/hadoop-hudson/mapred/staging/hudson916254904/.staging/job_local_0001
Exception in thread "main"
org.apache.hadoop.mapred.FileAlreadyExistsException: Output directory
/tmp/mahout-work-hudson/reuters-minhash already exists
at org.apache.hadoop.mapreduce.lib.output.FileOutputFormat.checkOutputSpecs(FileOutputFormat.java:134)
at org.apache.hadoop.mapred.JobClient$2.run(JobClient.java:846)
at org.apache.hadoop.mapred.JobClient$2.run(JobClient.java:807)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:396)
at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1059)
at org.apache.hadoop.mapred.JobClient.submitJobInternal(JobClient.java:807)
at org.apache.hadoop.mapreduce.Job.submit(Job.java:465)
at org.apache.hadoop.mapreduce.Job.waitForCompletion(Job.java:495)
at org.apache.mahout.clustering.minhash.MinHashDriver.runJob(MinHashDriver.java:86)
at org.apache.mahout.clustering.minhash.MinHashDriver.run(MinHashDriver.java:115)
at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:65)
at org.apache.mahout.clustering.minhash.MinHashDriver.main(MinHashDriver.java:41)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.hadoop.util.ProgramDriver$ProgramDescription.invoke(ProgramDriver.java:68)
at org.apache.hadoop.util.ProgramDriver.driver(ProgramDriver.java:139)
at org.apache.mahout.driver.MahoutDriver.main(MahoutDriver.java:188)
Build step 'Execute shell' marked build as failure
----------------------------------------------------------------------------------
On Mon, Jan 9, 2012 at 11:13 AM, Apache Jenkins Server
<[EMAIL PROTECTED]> wrote:
> See <https://builds.apache.org/job/Mahout-Examples-Cluster-Reuters-II/6/changes>
>
> Changes:
>
> [srowen] More of my suggested refinements
>
> [gsingers] MAHOUT-899: Add some more cluster dumping options like sampling, coloring
>
> ------------------------------------------
> [...truncated 7306 lines...]
> 12/01/09 19:11:52 INFO mapred.Merger: Down to the last merge-pass, with 0 segments left of total size: 0 bytes
> 12/01/09 19:11:52 INFO mapred.LocalJobRunner:
> 12/01/09 19:11:52 INFO mapred.JobClient: map 100% reduce 0%
> 12/01/09 19:11:52 INFO mapred.Task: Task:attempt_local_0003_r_000000_0 is done. And is in the process of commiting
> 12/01/09 19:11:52 INFO mapred.LocalJobRunner:
> 12/01/09 19:11:52 INFO mapred.Task: Task attempt_local_0003_r_000000_0 is allowed to commit now
> 12/01/09 19:11:52 INFO output.FileOutputCommitter: Saved output of task 'attempt_local_0003_r_000000_0' to /tmp/mahout-work-hudson/reuters-out-seqdir-sparse-minhash/partial-vectors-0
Lance Norskog
[EMAIL PROTECTED]
+
Lance Norskog 2012-01-10, 03:33
