> On Sat, 09 Jun 2012, Skipper Seabold wrote:
>> > What are the plans with charlton statsmodels integration?
>> I'd like to merge formula-integration in ASAP.
> sorry guys -- what has happened with the release plans? is any one
> coming?
I had a short window to do this, and it didn't happen. I'm more or
less available again, but I don't know the status of master /
maintenance anymore. What do things look like?
On Sat, Jun 9, 2012 at 12:50 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
> On Sat, Jun 9, 2012 at 12:41 PM, Yaroslav Halchenko
> <yarikop...@gmail.com> wrote:
>> On Sat, 09 Jun 2012, Skipper Seabold wrote:
>>> > What are the plans with charlton statsmodels integration?
>>> I'd like to merge formula-integration in ASAP.
>> sorry guys -- what has happened with the release plans? is any one
>> coming?
> I had a short window to do this, and it didn't happen. I'm more or
> less available again, but I don't know the status of master /
> maintenance anymore. What do things look like?
I have 3 open bugfix PRs and 1 move/cleanup PR, issue #320 should get
a solution.
(I have a few more branches, Stata, R helper files, and maybe some minor stuff,
new gof_again needs a bit more work)
I have no clue for the remaining Debian errors, and cannot reproduce
them in my setup.
I started to update the CHANGES but not committed yet.
let me know when/what treeish should I check and then I would make sure
you could reproduce any remaining issue ;)
Thanks in advance!
On Sat, 09 Jun 2012, josef.p...@gmail.com wrote:
> > I had a short window to do this, and it didn't happen. I'm more or
> > less available again, but I don't know the status of master /
> > maintenance anymore. What do things look like?
> I have 3 open bugfix PRs and 1 move/cleanup PR, issue #320 should get
> a solution.
> (I have a few more branches, Stata, R helper files, and maybe some minor stuff,
> new gof_again needs a bit more work)
> I have no clue for the remaining Debian errors, and cannot reproduce
> them in my setup.
> I started to update the CHANGES but not committed yet.
> Josef
> > Skipper
-- Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
> On Sat, 09 Jun 2012, josef.p...@gmail.com wrote:
>> > I had a short window to do this, and it didn't happen. I'm more or
>> > less available again, but I don't know the status of master /
>> > maintenance anymore. What do things look like?
>> I have 3 open bugfix PRs and 1 move/cleanup PR, issue #320 should get
>> a solution.
>> (I have a few more branches, Stata, R helper files, and maybe some minor stuff,
>> new gof_again needs a bit more work)
>> I have no clue for the remaining Debian errors, and cannot reproduce
>> them in my setup.
>> I started to update the CHANGES but not committed yet.
>> Josef
>> > Skipper
> --
> Yaroslav O. Halchenko
> Postdoctoral Fellow, Department of Psychological and Brain Sciences
> Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
> Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
> WWW: http://www.linkedin.com/in/yarik
On Sun, Jun 10, 2012 at 10:53 PM, <josef.p...@gmail.com> wrote:
> On Sun, Jun 10, 2012 at 10:46 PM, Yaroslav Halchenko
> <yarikop...@gmail.com> wrote:
>> let me know when/what treeish should I check and then I would make sure
>> you could reproduce any remaining issue ;)
>> Thanks in advance!
> I think I will do some merging tomorrow.
> scipy weekend is over, our network is getting busier and is asking for
> review, so better get 0.4.1 out of the way.
Let me know. I'd like to do this asap as well. I have code I'm ready
to get back into master (mainly for the pyschological burden of
knowing "finished," tested code is out in a cold, lonely branch) but
now that we don't currently have separation between maintenance and
development I have to wait :).
On Tue, Jun 12, 2012 at 9:20 AM, Skipper Seabold <jsseab...@gmail.com> wrote:
> On Sun, Jun 10, 2012 at 10:53 PM, <josef.p...@gmail.com> wrote:
>> On Sun, Jun 10, 2012 at 10:46 PM, Yaroslav Halchenko
>> <yarikop...@gmail.com> wrote:
>>> let me know when/what treeish should I check and then I would make sure
>>> you could reproduce any remaining issue ;)
>>> Thanks in advance!
>> I think I will do some merging tomorrow.
One day late.
I merged 7 branches, master tests clean on my (medium old) working
setup, but I didn't run the compatibility tests yet.
rebase - force push - green button is fun
(as long as there are no merge conflicts or newly found test failures)
>> scipy weekend is over, our network is getting busier and is asking for
>> review, so better get 0.4.1 out of the way.
> Let me know. I'd like to do this asap as well. I have code I'm ready
> to get back into master (mainly for the pyschological burden of
> knowing "finished," tested code is out in a cold, lonely branch) but
> now that we don't currently have separation between maintenance and
> development I have to wait :).
I don't see any pull requests. :)
The only PR waiting for 0.4.1 to get out of the way that I see, is
lowess in cython.
On Tue, Jun 12, 2012 at 1:18 PM, <josef.p...@gmail.com> wrote:
> On Tue, Jun 12, 2012 at 9:20 AM, Skipper Seabold <jsseab...@gmail.com> wrote:
>> On Sun, Jun 10, 2012 at 10:53 PM, <josef.p...@gmail.com> wrote:
>>> On Sun, Jun 10, 2012 at 10:46 PM, Yaroslav Halchenko
>>> <yarikop...@gmail.com> wrote:
>>>> let me know when/what treeish should I check and then I would make sure
>>>> you could reproduce any remaining issue ;)
>>>> Thanks in advance!
>>> I think I will do some merging tomorrow.
> One day late.
> I merged 7 branches, master tests clean on my (medium old) working
> setup, but I didn't run the compatibility tests yet.
> rebase - force push - green button is fun
> (as long as there are no merge conflicts or newly found test failures)
>>> scipy weekend is over, our network is getting busier and is asking for
>>> review, so better get 0.4.1 out of the way.
>> Let me know. I'd like to do this asap as well. I have code I'm ready
>> to get back into master (mainly for the pyschological burden of
>> knowing "finished," tested code is out in a cold, lonely branch) but
>> now that we don't currently have separation between maintenance and
>> development I have to wait :).
> I don't see any pull requests. :)
Branches are sitting in my fork. These probably aren't appropriate for
a minor revision release and might require some discussion. Don't want
to hold things up.
> The only PR waiting for 0.4.1 to get out of the way that I see, is
> lowess in cython.
Does this need a look? I'm not that familiar with this code yet.
On Tue, 12 Jun 2012, Skipper Seabold wrote:
> > The only PR waiting for 0.4.1 to get out of the way that I see, is
> > lowess in cython.
> Does this need a look? I'm not that familiar with this code yet.
am I reading it right that current master is ready for the final
spin before the release? ;)
-- Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
On Tue, Jun 12, 2012 at 1:30 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
> On Tue, Jun 12, 2012 at 1:18 PM, <josef.p...@gmail.com> wrote:
>> On Tue, Jun 12, 2012 at 9:20 AM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>> On Sun, Jun 10, 2012 at 10:53 PM, <josef.p...@gmail.com> wrote:
>>>> On Sun, Jun 10, 2012 at 10:46 PM, Yaroslav Halchenko
>>>> <yarikop...@gmail.com> wrote:
>>>>> let me know when/what treeish should I check and then I would make sure
>>>>> you could reproduce any remaining issue ;)
>>>>> Thanks in advance!
>>>> I think I will do some merging tomorrow.
>> One day late.
>> I merged 7 branches, master tests clean on my (medium old) working
>> setup, but I didn't run the compatibility tests yet.
>> rebase - force push - green button is fun
>> (as long as there are no merge conflicts or newly found test failures)
>>>> scipy weekend is over, our network is getting busier and is asking for
>>>> review, so better get 0.4.1 out of the way.
>>> Let me know. I'd like to do this asap as well. I have code I'm ready
>>> to get back into master (mainly for the pyschological burden of
>>> knowing "finished," tested code is out in a cold, lonely branch) but
>>> now that we don't currently have separation between maintenance and
>>> development I have to wait :).
>> I don't see any pull requests. :)
> Branches are sitting in my fork. These probably aren't appropriate for
> a minor revision release and might require some discussion. Don't want
> to hold things up.
You can always open a PR so it's easier to keep track what's on the
waiting list.
I thought it will be the main changes for 0.5
>> The only PR waiting for 0.4.1 to get out of the way that I see, is
>> lowess in cython.
> Does this need a look? I'm not that familiar with this code yet.
Also for 0.5, not quite backwards compatible and might need exposure
through an rc to make sure the cython doesn't create problems on one
of the platforms/versions.
test coverage is good, but it needs the infrastructure to be build
inside statsmodels, as your cython code.
Your help for this would be good, because you know this part.
>> > The only PR waiting for 0.4.1 to get out of the way that I see, is
>> > lowess in cython.
>> Does this need a look? I'm not that familiar with this code yet.
> am I reading it right that current master is ready for the final
> spin before the release? ;)
about ready, one small bugfix in categorical is missing.
If you want to possibly save some work, then you could wait until I
have checked from python 2.5 to python 3.2, currently I know it's
clean only for one version.
On Tue, Jun 12, 2012 at 1:38 PM, <josef.p...@gmail.com> wrote:
> On Tue, Jun 12, 2012 at 1:30 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>> On Tue, Jun 12, 2012 at 1:18 PM, <josef.p...@gmail.com> wrote:
>>> On Tue, Jun 12, 2012 at 9:20 AM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>> On Sun, Jun 10, 2012 at 10:53 PM, <josef.p...@gmail.com> wrote:
>>>>> On Sun, Jun 10, 2012 at 10:46 PM, Yaroslav Halchenko
>>>>> <yarikop...@gmail.com> wrote:
>>>>>> let me know when/what treeish should I check and then I would make sure
>>>>>> you could reproduce any remaining issue ;)
>>>>>> Thanks in advance!
>>>>> I think I will do some merging tomorrow.
>>> One day late.
>>> I merged 7 branches, master tests clean on my (medium old) working
>>> setup, but I didn't run the compatibility tests yet.
>>> rebase - force push - green button is fun
>>> (as long as there are no merge conflicts or newly found test failures)
>>>>> scipy weekend is over, our network is getting busier and is asking for
>>>>> review, so better get 0.4.1 out of the way.
>>>> Let me know. I'd like to do this asap as well. I have code I'm ready
>>>> to get back into master (mainly for the pyschological burden of
>>>> knowing "finished," tested code is out in a cold, lonely branch) but
>>>> now that we don't currently have separation between maintenance and
>>>> development I have to wait :).
>>> I don't see any pull requests. :)
>> Branches are sitting in my fork. These probably aren't appropriate for
>> a minor revision release and might require some discussion. Don't want
>> to hold things up.
> You can always open a PR so it's easier to keep track what's on the
> waiting list.
> I thought it will be the main changes for 0.5
>>> The only PR waiting for 0.4.1 to get out of the way that I see, is
>>> lowess in cython.
>> Does this need a look? I'm not that familiar with this code yet.
> Also for 0.5, not quite backwards compatible and might need exposure
> through an rc to make sure the cython doesn't create problems on one
> of the platforms/versions.
> test coverage is good, but it needs the infrastructure to be build
> inside statsmodels, as your cython code.
> Your help for this would be good, because you know this part.
On Tue, Jun 12, 2012 at 1:58 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
> On Tue, Jun 12, 2012 at 1:38 PM, <josef.p...@gmail.com> wrote:
>> On Tue, Jun 12, 2012 at 1:30 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>> On Tue, Jun 12, 2012 at 1:18 PM, <josef.p...@gmail.com> wrote:
>>>> On Tue, Jun 12, 2012 at 9:20 AM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>>> On Sun, Jun 10, 2012 at 10:53 PM, <josef.p...@gmail.com> wrote:
>>>>>> On Sun, Jun 10, 2012 at 10:46 PM, Yaroslav Halchenko
>>>>>> <yarikop...@gmail.com> wrote:
>>>>>>> let me know when/what treeish should I check and then I would make sure
>>>>>>> you could reproduce any remaining issue ;)
>>>>>>> Thanks in advance!
>>>>>> I think I will do some merging tomorrow.
>>>> One day late.
>>>> I merged 7 branches, master tests clean on my (medium old) working
>>>> setup, but I didn't run the compatibility tests yet.
>>>> rebase - force push - green button is fun
>>>> (as long as there are no merge conflicts or newly found test failures)
>>>>>> scipy weekend is over, our network is getting busier and is asking for
>>>>>> review, so better get 0.4.1 out of the way.
>>>>> Let me know. I'd like to do this asap as well. I have code I'm ready
>>>>> to get back into master (mainly for the pyschological burden of
>>>>> knowing "finished," tested code is out in a cold, lonely branch) but
>>>>> now that we don't currently have separation between maintenance and
>>>>> development I have to wait :).
>>>> I don't see any pull requests. :)
>>> Branches are sitting in my fork. These probably aren't appropriate for
>>> a minor revision release and might require some discussion. Don't want
>>> to hold things up.
>> You can always open a PR so it's easier to keep track what's on the
>> waiting list.
>> I thought it will be the main changes for 0.5
>>>> The only PR waiting for 0.4.1 to get out of the way that I see, is
>>>> lowess in cython.
>>> Does this need a look? I'm not that familiar with this code yet.
>> Also for 0.5, not quite backwards compatible and might need exposure
>> through an rc to make sure the cython doesn't create problems on one
>> of the platforms/versions.
>> test coverage is good, but it needs the infrastructure to be build
>> inside statsmodels, as your cython code.
>> Your help for this would be good, because you know this part.
On Tue, Jun 12, 2012 at 2:14 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
> On Tue, Jun 12, 2012 at 1:58 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>> On Tue, Jun 12, 2012 at 1:38 PM, <josef.p...@gmail.com> wrote:
>>> On Tue, Jun 12, 2012 at 1:30 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>> On Tue, Jun 12, 2012 at 1:18 PM, <josef.p...@gmail.com> wrote:
>>>>> On Tue, Jun 12, 2012 at 9:20 AM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>>>> On Sun, Jun 10, 2012 at 10:53 PM, <josef.p...@gmail.com> wrote:
>>>>>>> On Sun, Jun 10, 2012 at 10:46 PM, Yaroslav Halchenko
>>>>>>> <yarikop...@gmail.com> wrote:
>>>>>>>> let me know when/what treeish should I check and then I would make sure
>>>>>>>> you could reproduce any remaining issue ;)
>>>>>>>> Thanks in advance!
>>>>>>> I think I will do some merging tomorrow.
>>>>> One day late.
>>>>> I merged 7 branches, master tests clean on my (medium old) working
>>>>> setup, but I didn't run the compatibility tests yet.
>>>>> a doc bug that I saw yesterday is missing,
>>>>> https://github.com/statsmodels/statsmodels/issues/305,
>>>>> and the release related stuff.
>>>>> I will update CHANGES, but might not have time until tonight.
>>>>> rebase - force push - green button is fun
>>>>> (as long as there are no merge conflicts or newly found test failures)
>>>>>>> scipy weekend is over, our network is getting busier and is asking for
>>>>>>> review, so better get 0.4.1 out of the way.
>>>>>> Let me know. I'd like to do this asap as well. I have code I'm ready
>>>>>> to get back into master (mainly for the pyschological burden of
>>>>>> knowing "finished," tested code is out in a cold, lonely branch) but
>>>>>> now that we don't currently have separation between maintenance and
>>>>>> development I have to wait :).
>>>>> I don't see any pull requests. :)
>>>> Branches are sitting in my fork. These probably aren't appropriate for
>>>> a minor revision release and might require some discussion. Don't want
>>>> to hold things up.
>>> You can always open a PR so it's easier to keep track what's on the
>>> waiting list.
>>> I thought it will be the main changes for 0.5
>>>>> The only PR waiting for 0.4.1 to get out of the way that I see, is
>>>>> lowess in cython.
>>>> Does this need a look? I'm not that familiar with this code yet.
>>> Also for 0.5, not quite backwards compatible and might need exposure
>>> through an rc to make sure the cython doesn't create problems on one
>>> of the platforms/versions.
>>> test coverage is good, but it needs the infrastructure to be build
>>> inside statsmodels, as your cython code.
>>> Your help for this would be good, because you know this part.
On Tue, Jun 12, 2012 at 2:21 PM, <josef.p...@gmail.com> wrote:
> On Tue, Jun 12, 2012 at 2:14 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>> On Tue, Jun 12, 2012 at 1:58 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>> On Tue, Jun 12, 2012 at 1:38 PM, <josef.p...@gmail.com> wrote:
>>>> On Tue, Jun 12, 2012 at 1:30 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>>> On Tue, Jun 12, 2012 at 1:18 PM, <josef.p...@gmail.com> wrote:
>>>>>> On Tue, Jun 12, 2012 at 9:20 AM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>>>>> On Sun, Jun 10, 2012 at 10:53 PM, <josef.p...@gmail.com> wrote:
>>>>>>>> On Sun, Jun 10, 2012 at 10:46 PM, Yaroslav Halchenko
>>>>>>>> <yarikop...@gmail.com> wrote:
>>>>>>>>> let me know when/what treeish should I check and then I would make sure
>>>>>>>>> you could reproduce any remaining issue ;)
>>>>>>>>> Thanks in advance!
>>>>>>>> I think I will do some merging tomorrow.
>>>>>> One day late.
>>>>>> I merged 7 branches, master tests clean on my (medium old) working
>>>>>> setup, but I didn't run the compatibility tests yet.
> I'll check tonight, since it's about strings there is some chance that
> python 3.2 complains.
> Otherwise, I extra failure on python 2.5 numpy 1.4, most likely too
> high precision in test.
> clean on py 2.6, 2.7, and 3.2
I fixed this one, but the last two merges don't look good, I guess the
categorical fix
these two show up in all versions. dtype mismatch i8 versus i4
(my python 2.5 2.6 2.7 are 32bit, python 3.2 is 64bit)
======================================================================
FAIL: statsmodels.tools.tests.test_tools.test_rec_issue302
----------------------------------------------------------------------
Traceback (most recent call last):
File "E:\Josef\testing\tox\py27a\lib\site-packages\nose\case.py",
line 197, in runTest
self.test(*self.arg)
File "E:\Josef\testing\tox\py27a\lib\site-packages\statsmodels\tools\tests\test_ tools.py",
line 314, in test_rec_issue302
assert_array_equal(actual, expected)
File "E:\Josef\testing\tox\py27a\lib\site-packages\numpy\testing\utils.py",
line 707, in assert_array_equal
verbose=verbose, header='Arrays are not equal')
File "E:\Josef\testing\tox\py27a\lib\site-packages\numpy\testing\utils.py",
line 636, in assert_array_compare
raise AssertionError(msg)
AssertionError:
Arrays are not equal
======================================================================
FAIL: statsmodels.tools.tests.test_tools.test_issue302
----------------------------------------------------------------------
Traceback (most recent call last):
File "E:\Josef\testing\tox\py27a\lib\site-packages\nose\case.py",
line 197, in runTest
self.test(*self.arg)
File "E:\Josef\testing\tox\py27a\lib\site-packages\statsmodels\tools\tests\test_ tools.py",
line 322, in test_issue302
assert_array_equal(actual, expected)
File "E:\Josef\testing\tox\py27a\lib\site-packages\numpy\testing\utils.py",
line 707, in assert_array_equal
verbose=verbose, header='Arrays are not equal')
File "E:\Josef\testing\tox\py27a\lib\site-packages\numpy\testing\utils.py",
line 636, in assert_array_compare
raise AssertionError(msg)
AssertionError:
Arrays are not equal
this one, I think, shows up every once in a while, only python 2.7
======================================================================
FAIL: statsmodels.tsa.tests.test_ar.TestARMLEConstant.test_predict
----------------------------------------------------------------------
Traceback (most recent call last):
File "E:\Josef\testing\tox\py27a\lib\site-packages\nose\case.py",
line 197, in runTest
self.test(*self.arg)
File "E:\Josef\testing\tox\py27a\lib\site-packages\statsmodels\tsa\tests\test_ar .py",
line 126, in
test_predict
DECIMAL_4)
File "E:\Josef\testing\tox\py27a\lib\site-packages\numpy\testing\utils.py",
line 452, in assert_almost_equal
return assert_array_almost_equal(actual, desired, decimal, err_msg)
File "E:\Josef\testing\tox\py27a\lib\site-packages\numpy\testing\utils.py",
line 800, in assert_array_almost_equal
header=('Arrays are not almost equal to %d decimals' % decimal))
File "E:\Josef\testing\tox\py27a\lib\site-packages\numpy\testing\utils.py",
line 636, in assert_array_compare
raise AssertionError(msg)
AssertionError:
Arrays are not almost equal to 4 decimals
----------------------------------------------------------------------
Ran 1470 tests in 97.341s
FAILED (SKIP=24, failures=3)
on python 3.2 I get 12 errors like this, my guess is string versus bytes issue
======================================================================
ERROR: Failure: ValueError (field named race_black not found.)
----------------------------------------------------------------------
Traceback (most recent call last):
File "E:\Josef\testing\tox\py32a\lib\site-packages\nose-1.1.2-py3.2.egg\nose\fai lure.py",
line 37,
in runTest
raise self.exc_class(self.exc_val).with_traceback(self.tb)
File "E:\Josef\testing\tox\py32a\lib\site-packages\nose-1.1.2-py3.2.egg\nose\loa der.py",
line 495,
in makeTest
return self._makeTest(obj, parent)
File "E:\Josef\testing\tox\py32a\lib\site-packages\nose-1.1.2-py3.2.egg\nose\loa der.py",
line 554,
in _makeTest
return MethodTestCase(obj)
File "E:\Josef\testing\tox\py32a\lib\site-packages\nose-1.1.2-py3.2.egg\nose\cas e.py",
line 346, in __init__
self.inst = self.cls()
File "E:\Josef\testing\tox\py32a\lib\site-packages\statsmodels\genmod\tests\test _glm.py",
line 238, in __init__
self.res2 = Lbw()
File "E:\Josef\testing\tox\py32a\lib\site-packages\statsmodels\genmod\tests\resu lts\results_glm.py",
line 691, in __init__
data['race_black'], data['race_other'], data['smoke'],
File "E:\Josef\testing\tox\py32a\lib\site-packages\numpy\core\records.py",
line 457, in __getitem__
obj = ndarray.__getitem__(self, indx)
ValueError: field named race_black not found.
>>>>>> a doc bug that I saw yesterday is missing,
>>>>>> https://github.com/statsmodels/statsmodels/issues/305,
>>>>>> and the release related stuff.
>>>>>> I will update CHANGES, but might not have time until tonight.
>>>>>> rebase - force push - green button is fun
>>>>>> (as long as there are no merge conflicts or newly found test failures)
>>>>>>>> scipy weekend is over, our network is getting busier and is asking for
>>>>>>>> review, so better get 0.4.1 out of the way.
>>>>>>> Let me know. I'd like to do this asap as well. I have code I'm ready
>>>>>>> to get back into master (mainly for the pyschological burden of
>>>>>>> knowing "finished," tested code is out in a cold, lonely branch) but
>>>>>>> now that we don't currently have separation between maintenance and
>>>>>>> development I have to wait :).
>>>>>> I don't see any pull requests. :)
>>>>> Branches are sitting in my fork. These probably aren't appropriate for
>>>>> a minor revision release and might require some discussion. Don't want
>>>>> to hold things up.
>>>> You can always open a PR so it's easier to keep track what's on the
>>>> waiting list.
>>>> I thought it will be the main changes for 0.5
>>>>>> The only PR waiting for 0.4.1 to get out of the way that I see, is
>>>>>> lowess in cython.
>>>>> Does this need a look? I'm not that familiar with this code yet.
>>>> Also for 0.5, not quite backwards compatible and might need exposure
>>>> through an rc to make sure the cython doesn't create problems on one
>>>> of the platforms/versions.
>>>> test coverage is good, but it needs the infrastructure to be build
>>>> inside statsmodels, as your cython code.
>>>> Your help for this would be good, because you know this part.
On Tue, Jun 12, 2012 at 8:53 PM, <josef.p...@gmail.com> wrote:
> On Tue, Jun 12, 2012 at 2:21 PM, <josef.p...@gmail.com> wrote:
>> On Tue, Jun 12, 2012 at 2:14 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>> On Tue, Jun 12, 2012 at 1:58 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>> On Tue, Jun 12, 2012 at 1:38 PM, <josef.p...@gmail.com> wrote:
>>>>> On Tue, Jun 12, 2012 at 1:30 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>>>> On Tue, Jun 12, 2012 at 1:18 PM, <josef.p...@gmail.com> wrote:
>>>>>>> On Tue, Jun 12, 2012 at 9:20 AM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>>>>>> On Sun, Jun 10, 2012 at 10:53 PM, <josef.p...@gmail.com> wrote:
>>>>>>>>> On Sun, Jun 10, 2012 at 10:46 PM, Yaroslav Halchenko
>>>>>>>>> <yarikop...@gmail.com> wrote:
>>>>>>>>>> let me know when/what treeish should I check and then I would make sure
>>>>>>>>>> you could reproduce any remaining issue ;)
>>>>>>>>>> Thanks in advance!
>>>>>>>>> I think I will do some merging tomorrow.
>>>>>>> One day late.
>>>>>>> I merged 7 branches, master tests clean on my (medium old) working
>>>>>>> setup, but I didn't run the compatibility tests yet.
> ======================================================================
> FAIL: statsmodels.tsa.tests.test_ar.TestARMLEConstant.test_predict
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "E:\Josef\testing\tox\py27a\lib\site-packages\nose\case.py",
> line 197, in runTest
> self.test(*self.arg)
> File "E:\Josef\testing\tox\py27a\lib\site-packages\statsmodels\tsa\tests\test_ar .py",
> line 126, in
> test_predict
> DECIMAL_4)
> File "E:\Josef\testing\tox\py27a\lib\site-packages\numpy\testing\utils.py",
> line 452, in assert_almost_equal
> return assert_array_almost_equal(actual, desired, decimal, err_msg)
> File "E:\Josef\testing\tox\py27a\lib\site-packages\numpy\testing\utils.py",
> line 800, in assert_array_almost_equal
> header=('Arrays are not almost equal to %d decimals' % decimal))
> File "E:\Josef\testing\tox\py27a\lib\site-packages\numpy\testing\utils.py",
> line 636, in assert_array_compare
> raise AssertionError(msg)
> AssertionError:
> Arrays are not almost equal to 4 decimals
On Tue, Jun 12, 2012 at 9:02 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
> On Tue, Jun 12, 2012 at 8:53 PM, <josef.p...@gmail.com> wrote:
>> On Tue, Jun 12, 2012 at 2:21 PM, <josef.p...@gmail.com> wrote:
>>> On Tue, Jun 12, 2012 at 2:14 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>> On Tue, Jun 12, 2012 at 1:58 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>>> On Tue, Jun 12, 2012 at 1:38 PM, <josef.p...@gmail.com> wrote:
>>>>>> On Tue, Jun 12, 2012 at 1:30 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>>>>> On Tue, Jun 12, 2012 at 1:18 PM, <josef.p...@gmail.com> wrote:
>>>>>>>> On Tue, Jun 12, 2012 at 9:20 AM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>>>>>>> On Sun, Jun 10, 2012 at 10:53 PM, <josef.p...@gmail.com> wrote:
>>>>>>>>>> On Sun, Jun 10, 2012 at 10:46 PM, Yaroslav Halchenko
>>>>>>>>>> <yarikop...@gmail.com> wrote:
>>>>>>>>>>> let me know when/what treeish should I check and then I would make sure
>>>>>>>>>>> you could reproduce any remaining issue ;)
>>>>>>>>>>> Thanks in advance!
>>>>>>>>>> I think I will do some merging tomorrow.
>>>>>>>> One day late.
>>>>>>>> I merged 7 branches, master tests clean on my (medium old) working
>>>>>>>> setup, but I didn't run the compatibility tests yet.
>> this one, I think, shows up every once in a while, only python 2.7
> Odd. Just lower precision to 3 I guess.
>> ======================================================================
>> FAIL: statsmodels.tsa.tests.test_ar.TestARMLEConstant.test_predict
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>> File "E:\Josef\testing\tox\py27a\lib\site-packages\nose\case.py",
>> line 197, in runTest
>> self.test(*self.arg)
>> File "E:\Josef\testing\tox\py27a\lib\site-packages\statsmodels\tsa\tests\test_ar .py",
>> line 126, in
>> test_predict
>> DECIMAL_4)
>> File "E:\Josef\testing\tox\py27a\lib\site-packages\numpy\testing\utils.py",
>> line 452, in assert_almost_equal
>> return assert_array_almost_equal(actual, desired, decimal, err_msg)
>> File "E:\Josef\testing\tox\py27a\lib\site-packages\numpy\testing\utils.py",
>> line 800, in assert_array_almost_equal
>> header=('Arrays are not almost equal to %d decimals' % decimal))
>> File "E:\Josef\testing\tox\py27a\lib\site-packages\numpy\testing\utils.py",
>> line 636, in assert_array_compare
>> raise AssertionError(msg)
>> AssertionError:
>> Arrays are not almost equal to 4 decimals
>> ----------------------------------------------------------------------
>> Ran 1470 tests in 97.341s
>> FAILED (SKIP=24, failures=3)
>> on python 3.2 I get 12 errors like this, my guess is string versus bytes issue
>> ======================================================================
>> ERROR: Failure: ValueError (field named race_black not found.)
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>> File "E:\Josef\testing\tox\py32a\lib\site-packages\nose-1.1.2-py3.2.egg\nose\fai lure.py",
>> line 37,
>> in runTest
>> raise self.exc_class(self.exc_val).with_traceback(self.tb)
>> File "E:\Josef\testing\tox\py32a\lib\site-packages\nose-1.1.2-py3.2.egg\nose\loa der.py",
>> line 495,
>> in makeTest
>> return self._makeTest(obj, parent)
>> File "E:\Josef\testing\tox\py32a\lib\site-packages\nose-1.1.2-py3.2.egg\nose\loa der.py",
>> line 554,
>> in _makeTest
>> return MethodTestCase(obj)
>> File "E:\Josef\testing\tox\py32a\lib\site-packages\nose-1.1.2-py3.2.egg\nose\cas e.py",
>> line 346, in __init__
>> self.inst = self.cls()
>> File "E:\Josef\testing\tox\py32a\lib\site-packages\statsmodels\genmod\tests\test _glm.py",
>> line 238, in __init__
>> self.res2 = Lbw()
>> File "E:\Josef\testing\tox\py32a\lib\site-packages\statsmodels\genmod\tests\resu lts\results_glm.py",
>> line 691, in __init__
>> data['race_black'], data['race_other'], data['smoke'],
>> File "E:\Josef\testing\tox\py32a\lib\site-packages\numpy\core\records.py",
>> line 457, in __getitem__
>> obj = ndarray.__getitem__(self, indx)
>> ValueError: field named race_black not found.
> Just installed Python 3.2. Will have a look. This has never showed up
> before? That's not a new test.
I'm looking at this now, it's a consequence of the str call in
categorical I guess.
I'm in 3.2 and try to figure out if it's supposed to be string,
unicode (encoding of string) or bytes.
On Tue, Jun 12, 2012 at 9:07 PM, <josef.p...@gmail.com> wrote:
> On Tue, Jun 12, 2012 at 9:02 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>> On Tue, Jun 12, 2012 at 8:53 PM, <josef.p...@gmail.com> wrote:
>>> On Tue, Jun 12, 2012 at 2:21 PM, <josef.p...@gmail.com> wrote:
>>>> On Tue, Jun 12, 2012 at 2:14 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>>> On Tue, Jun 12, 2012 at 1:58 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>>>> On Tue, Jun 12, 2012 at 1:38 PM, <josef.p...@gmail.com> wrote:
>>>>>>> On Tue, Jun 12, 2012 at 1:30 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>>>>>> On Tue, Jun 12, 2012 at 1:18 PM, <josef.p...@gmail.com> wrote:
>>>>>>>>> On Tue, Jun 12, 2012 at 9:20 AM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>>>>>>>> On Sun, Jun 10, 2012 at 10:53 PM, <josef.p...@gmail.com> wrote:
>>>>>>>>>>> On Sun, Jun 10, 2012 at 10:46 PM, Yaroslav Halchenko
>>>>>>>>>>> <yarikop...@gmail.com> wrote:
>>>>>>>>>>>> let me know when/what treeish should I check and then I would make sure
>>>>>>>>>>>> you could reproduce any remaining issue ;)
>>>>>>>>>>>> Thanks in advance!
>>>>>>>>>>> I think I will do some merging tomorrow.
>>>>>>>>> One day late.
>>>>>>>>> I merged 7 branches, master tests clean on my (medium old) working
>>>>>>>>> setup, but I didn't run the compatibility tests yet.
>>>> I'll check tonight, since it's about strings there is some chance that
>>>> python 3.2 complains.
>>>> Otherwise, I extra failure on python 2.5 numpy 1.4, most likely too
>>>> high precision in test.
>>>> clean on py 2.6, 2.7, and 3.2
>>> I fixed this one, but the last two merges don't look good, I guess the
>>> categorical fix
>>> these two show up in all versions. dtype mismatch i8 versus i4
>>> (my python 2.5 2.6 2.7 are 32bit, python 3.2 is 64bit)
>> Can you try replacing 'i8' with int?
> the test specifies '<i8' as correct answer, Is that what you get on
> your version combination.
> For my versions it looks like it should just be '<i4'
It's 32-bit for 64-bit I'm pretty sure. Just using int should fix it.
>>> this one, I think, shows up every once in a while, only python 2.7
>> Odd. Just lower precision to 3 I guess.
>>> ======================================================================
>>> FAIL: statsmodels.tsa.tests.test_ar.TestARMLEConstant.test_predict
>>> ----------------------------------------------------------------------
>>> Traceback (most recent call last):
>>> File "E:\Josef\testing\tox\py27a\lib\site-packages\nose\case.py",
>>> line 197, in runTest
>>> self.test(*self.arg)
>>> File "E:\Josef\testing\tox\py27a\lib\site-packages\statsmodels\tsa\tests\test_ar .py",
>>> line 126, in
>>> test_predict
>>> DECIMAL_4)
>>> File "E:\Josef\testing\tox\py27a\lib\site-packages\numpy\testing\utils.py",
>>> line 452, in assert_almost_equal
>>> return assert_array_almost_equal(actual, desired, decimal, err_msg)
>>> File "E:\Josef\testing\tox\py27a\lib\site-packages\numpy\testing\utils.py",
>>> line 800, in assert_array_almost_equal
>>> header=('Arrays are not almost equal to %d decimals' % decimal))
>>> File "E:\Josef\testing\tox\py27a\lib\site-packages\numpy\testing\utils.py",
>>> line 636, in assert_array_compare
>>> raise AssertionError(msg)
>>> AssertionError:
>>> Arrays are not almost equal to 4 decimals
>>> ----------------------------------------------------------------------
>>> Ran 1470 tests in 97.341s
>>> FAILED (SKIP=24, failures=3)
>>> on python 3.2 I get 12 errors like this, my guess is string versus bytes issue
>>> ======================================================================
>>> ERROR: Failure: ValueError (field named race_black not found.)
>>> ----------------------------------------------------------------------
>>> Traceback (most recent call last):
>>> File "E:\Josef\testing\tox\py32a\lib\site-packages\nose-1.1.2-py3.2.egg\nose\fai lure.py",
>>> line 37,
>>> in runTest
>>> raise self.exc_class(self.exc_val).with_traceback(self.tb)
>>> File "E:\Josef\testing\tox\py32a\lib\site-packages\nose-1.1.2-py3.2.egg\nose\loa der.py",
>>> line 495,
>>> in makeTest
>>> return self._makeTest(obj, parent)
>>> File "E:\Josef\testing\tox\py32a\lib\site-packages\nose-1.1.2-py3.2.egg\nose\loa der.py",
>>> line 554,
>>> in _makeTest
>>> return MethodTestCase(obj)
>>> File "E:\Josef\testing\tox\py32a\lib\site-packages\nose-1.1.2-py3.2.egg\nose\cas e.py",
>>> line 346, in __init__
>>> self.inst = self.cls()
>>> File "E:\Josef\testing\tox\py32a\lib\site-packages\statsmodels\genmod\tests\test _glm.py",
>>> line 238, in __init__
>>> self.res2 = Lbw()
>>> File "E:\Josef\testing\tox\py32a\lib\site-packages\statsmodels\genmod\tests\resu lts\results_glm.py",
>>> line 691, in __init__
>>> data['race_black'], data['race_other'], data['smoke'],
>>> File "E:\Josef\testing\tox\py32a\lib\site-packages\numpy\core\records.py",
>>> line 457, in __getitem__
>>> obj = ndarray.__getitem__(self, indx)
>>> ValueError: field named race_black not found.
>> Just installed Python 3.2. Will have a look. This has never showed up
>> before? That's not a new test.
> I'm looking at this now, it's a consequence of the str call in
> categorical I guess.
> I'm in 3.2 and try to figure out if it's supposed to be string,
> unicode (encoding of string) or bytes.
On Tue, Jun 12, 2012 at 9:10 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
> On Tue, Jun 12, 2012 at 9:07 PM, <josef.p...@gmail.com> wrote:
>> On Tue, Jun 12, 2012 at 9:02 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>> On Tue, Jun 12, 2012 at 8:53 PM, <josef.p...@gmail.com> wrote:
>>>> On Tue, Jun 12, 2012 at 2:21 PM, <josef.p...@gmail.com> wrote:
>>>>> On Tue, Jun 12, 2012 at 2:14 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>>>> On Tue, Jun 12, 2012 at 1:58 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>>>>> On Tue, Jun 12, 2012 at 1:38 PM, <josef.p...@gmail.com> wrote:
>>>>>>>> On Tue, Jun 12, 2012 at 1:30 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>>>>>>> On Tue, Jun 12, 2012 at 1:18 PM, <josef.p...@gmail.com> wrote:
>>>>>>>>>> On Tue, Jun 12, 2012 at 9:20 AM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>>>>>>>>> On Sun, Jun 10, 2012 at 10:53 PM, <josef.p...@gmail.com> wrote:
>>>>>>>>>>>> On Sun, Jun 10, 2012 at 10:46 PM, Yaroslav Halchenko
>>>>>>>>>>>> <yarikop...@gmail.com> wrote:
>>>>>>>>>>>>> let me know when/what treeish should I check and then I would make sure
>>>>>>>>>>>>> you could reproduce any remaining issue ;)
>>>>>>>>>>>>> Thanks in advance!
>>>>>>>>>>>> I think I will do some merging tomorrow.
>>>>>>>>>> One day late.
>>>>>>>>>> I merged 7 branches, master tests clean on my (medium old) working
>>>>>>>>>> setup, but I didn't run the compatibility tests yet.
>>>>> I'll check tonight, since it's about strings there is some chance that
>>>>> python 3.2 complains.
>>>>> Otherwise, I extra failure on python 2.5 numpy 1.4, most likely too
>>>>> high precision in test.
>>>>> clean on py 2.6, 2.7, and 3.2
>>>> I fixed this one, but the last two merges don't look good, I guess the
>>>> categorical fix
>>>> these two show up in all versions. dtype mismatch i8 versus i4
>>>> (my python 2.5 2.6 2.7 are 32bit, python 3.2 is 64bit)
>>> Can you try replacing 'i8' with int?
>> the test specifies '<i8' as correct answer, Is that what you get on
>> your version combination.
>> For my versions it looks like it should just be '<i4'
> It's 32-bit for 64-bit I'm pretty sure. Just using int should fix it.
but then it's also platform or compiler dependent, I get also '<i4' on
64 bit python 3.2 (gohlke binaries)
I will try the int
>>>> this one, I think, shows up every once in a while, only python 2.7
>>> Odd. Just lower precision to 3 I guess.
>>>> ======================================================================
>>>> FAIL: statsmodels.tsa.tests.test_ar.TestARMLEConstant.test_predict
>>>> ----------------------------------------------------------------------
>>>> Traceback (most recent call last):
>>>> File "E:\Josef\testing\tox\py27a\lib\site-packages\nose\case.py",
>>>> line 197, in runTest
>>>> self.test(*self.arg)
>>>> File "E:\Josef\testing\tox\py27a\lib\site-packages\statsmodels\tsa\tests\test_ar .py",
>>>> line 126, in
>>>> test_predict
>>>> DECIMAL_4)
>>>> File "E:\Josef\testing\tox\py27a\lib\site-packages\numpy\testing\utils.py",
>>>> line 452, in assert_almost_equal
>>>> return assert_array_almost_equal(actual, desired, decimal, err_msg)
>>>> File "E:\Josef\testing\tox\py27a\lib\site-packages\numpy\testing\utils.py",
>>>> line 800, in assert_array_almost_equal
>>>> header=('Arrays are not almost equal to %d decimals' % decimal))
>>>> File "E:\Josef\testing\tox\py27a\lib\site-packages\numpy\testing\utils.py",
>>>> line 636, in assert_array_compare
>>>> raise AssertionError(msg)
>>>> AssertionError:
>>>> Arrays are not almost equal to 4 decimals
>>>> ----------------------------------------------------------------------
>>>> Ran 1470 tests in 97.341s
>>>> FAILED (SKIP=24, failures=3)
>>>> on python 3.2 I get 12 errors like this, my guess is string versus bytes issue
>>>> ======================================================================
>>>> ERROR: Failure: ValueError (field named race_black not found.)
>>>> ----------------------------------------------------------------------
>>>> Traceback (most recent call last):
>>>> File "E:\Josef\testing\tox\py32a\lib\site-packages\nose-1.1.2-py3.2.egg\nose\fai lure.py",
>>>> line 37,
>>>> in runTest
>>>> raise self.exc_class(self.exc_val).with_traceback(self.tb)
>>>> File "E:\Josef\testing\tox\py32a\lib\site-packages\nose-1.1.2-py3.2.egg\nose\loa der.py",
>>>> line 495,
>>>> in makeTest
>>>> return self._makeTest(obj, parent)
>>>> File "E:\Josef\testing\tox\py32a\lib\site-packages\nose-1.1.2-py3.2.egg\nose\loa der.py",
>>>> line 554,
>>>> in _makeTest
>>>> return MethodTestCase(obj)
>>>> File "E:\Josef\testing\tox\py32a\lib\site-packages\nose-1.1.2-py3.2.egg\nose\cas e.py",
>>>> line 346, in __init__
>>>> self.inst = self.cls()
>>>> File "E:\Josef\testing\tox\py32a\lib\site-packages\statsmodels\genmod\tests\test _glm.py",
>>>> line 238, in __init__
>>>> self.res2 = Lbw()
>>>> File "E:\Josef\testing\tox\py32a\lib\site-packages\statsmodels\genmod\tests\resu lts\results_glm.py",
>>>> line 691, in __init__
>>>> data['race_black'], data['race_other'], data['smoke'],
>>>> File "E:\Josef\testing\tox\py32a\lib\site-packages\numpy\core\records.py",
>>>> line 457, in __getitem__
>>>> obj = ndarray.__getitem__(self, indx)
>>>> ValueError: field named race_black not found.
>>> Just installed Python 3.2. Will have a look. This has never showed up
>>> before? That's not a new test.
>> I'm looking at this now, it's a consequence of the str call in
>> categorical I guess.
>> I'm in 3.2 and try to figure out if it's supposed to be string,
>> unicode (encoding of string) or bytes.
On Tue, Jun 12, 2012 at 9:16 PM, <josef.p...@gmail.com> wrote:
> On Tue, Jun 12, 2012 at 9:10 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>> On Tue, Jun 12, 2012 at 9:07 PM, <josef.p...@gmail.com> wrote:
>>> On Tue, Jun 12, 2012 at 9:02 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>> On Tue, Jun 12, 2012 at 8:53 PM, <josef.p...@gmail.com> wrote:
>>>>> On Tue, Jun 12, 2012 at 2:21 PM, <josef.p...@gmail.com> wrote:
>>>>>> On Tue, Jun 12, 2012 at 2:14 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>>>>> On Tue, Jun 12, 2012 at 1:58 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>>>>>> On Tue, Jun 12, 2012 at 1:38 PM, <josef.p...@gmail.com> wrote:
>>>>>>>>> On Tue, Jun 12, 2012 at 1:30 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>>>>>>>> On Tue, Jun 12, 2012 at 1:18 PM, <josef.p...@gmail.com> wrote:
>>>>>>>>>>> On Tue, Jun 12, 2012 at 9:20 AM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>>>>>>>>>> On Sun, Jun 10, 2012 at 10:53 PM, <josef.p...@gmail.com> wrote:
>>>>>>>>>>>>> On Sun, Jun 10, 2012 at 10:46 PM, Yaroslav Halchenko
>>>>>>>>>>>>> <yarikop...@gmail.com> wrote:
>>>>>>>>>>>>>> let me know when/what treeish should I check and then I would make sure
>>>>>>>>>>>>>> you could reproduce any remaining issue ;)
>>>>>>>>>>>>>> Thanks in advance!
>>>>>>>>>>>>> I think I will do some merging tomorrow.
>>>>>>>>>>> One day late.
>>>>>>>>>>> I merged 7 branches, master tests clean on my (medium old) working
>>>>>>>>>>> setup, but I didn't run the compatibility tests yet.
>>>>>> I'll check tonight, since it's about strings there is some chance that
>>>>>> python 3.2 complains.
>>>>>> Otherwise, I extra failure on python 2.5 numpy 1.4, most likely too
>>>>>> high precision in test.
>>>>>> clean on py 2.6, 2.7, and 3.2
>>>>> I fixed this one, but the last two merges don't look good, I guess the
>>>>> categorical fix
>>>>> these two show up in all versions. dtype mismatch i8 versus i4
>>>>> (my python 2.5 2.6 2.7 are 32bit, python 3.2 is 64bit)
>>>> Can you try replacing 'i8' with int?
>>> the test specifies '<i8' as correct answer, Is that what you get on
>>> your version combination.
>>> For my versions it looks like it should just be '<i4'
>> It's 32-bit for 64-bit I'm pretty sure. Just using int should fix it.
> but then it's also platform or compiler dependent, I get also '<i4' on
> 64 bit python 3.2 (gohlke binaries)
> I will try the int
> Josef
>>> I will run the tests again after looking at the 3.2 issue
>>>>> ======================================================================
>>>>> FAIL: statsmodels.tools.tests.test_tools.test_rec_issue302
>>>>> ----------------------------------------------------------------------
>>>>> Traceback (most recent call last):
>>>>> File "E:\Josef\testing\tox\py27a\lib\site-packages\nose\case.py",
>>>>> line 197, in runTest
>>>>> self.test(*self.arg)
>>>>> File "E:\Josef\testing\tox\py27a\lib\site-packages\statsmodels\tools\tests\test_ tools.py",
>>>>> line 314, in test_rec_issue302
>>>>> assert_array_equal(actual, expected)
>>>>> File "E:\Josef\testing\tox\py27a\lib\site-packages\numpy\testing\utils.py",
>>>>> line 707, in assert_array_equal
>>>>> verbose=verbose, header='Arrays are not equal')
>>>>> File "E:\Josef\testing\tox\py27a\lib\site-packages\numpy\testing\utils.py",
>>>>> line 636, in assert_array_compare
>>>>> raise AssertionError(msg)
>>>>> AssertionError:
>>>>> Arrays are not equal
>>>>> this one, I think, shows up every once in a while, only python 2.7
>>>> Odd. Just lower precision to 3 I guess.
>>>>> ======================================================================
>>>>> FAIL: statsmodels.tsa.tests.test_ar.TestARMLEConstant.test_predict
>>>>> ----------------------------------------------------------------------
>>>>> Traceback (most recent call last):
>>>>> File "E:\Josef\testing\tox\py27a\lib\site-packages\nose\case.py",
>>>>> line 197, in runTest
>>>>> self.test(*self.arg)
>>>>> File "E:\Josef\testing\tox\py27a\lib\site-packages\statsmodels\tsa\tests\test_ar .py",
>>>>> line 126, in
>>>>> test_predict
>>>>> DECIMAL_4)
>>>>> File "E:\Josef\testing\tox\py27a\lib\site-packages\numpy\testing\utils.py",
>>>>> line 452, in assert_almost_equal
>>>>> return assert_array_almost_equal(actual, desired, decimal, err_msg)
>>>>> File "E:\Josef\testing\tox\py27a\lib\site-packages\numpy\testing\utils.py",
>>>>> line 800, in assert_array_almost_equal
>>>>> header=('Arrays are not almost equal to %d decimals' % decimal))
>>>>> File "E:\Josef\testing\tox\py27a\lib\site-packages\numpy\testing\utils.py",
>>>>> line 636, in assert_array_compare
>>>>> raise AssertionError(msg)
>>>>> AssertionError:
>>>>> Arrays are not almost equal to 4 decimals
>>>>> ----------------------------------------------------------------------
>>>>> Ran 1470 tests in 97.341s
>>>>> FAILED (SKIP=24, failures=3)
>>>>> on python 3.2 I get 12 errors like this, my guess is string versus bytes issue
>>>>> ======================================================================
>>>>> ERROR: Failure: ValueError (field named race_black not found.)
>>>>> ----------------------------------------------------------------------
>>>>> Traceback (most recent call last):
>>>>> File "E:\Josef\testing\tox\py32a\lib\site-packages\nose-1.1.2-py3.2.egg\nose\fai lure.py",
>>>>> line 37,
>>>>> in runTest
>>>>> raise self.exc_class(self.exc_val).with_traceback(self.tb)
>>>>> File "E:\Josef\testing\tox\py32a\lib\site-packages\nose-1.1.2-py3.2.egg\nose\loa der.py",
>>>>> line 495,
>>>>> in makeTest
>>>>> return self._makeTest(obj, parent)
>>>>> File "E:\Josef\testing\tox\py32a\lib\site-packages\nose-1.1.2-py3.2.egg\nose\loa der.py",
>>>>> line 554,
>>>>> in _makeTest
>>>>> return MethodTestCase(obj)
>>>>> File "E:\Josef\testing\tox\py32a\lib\site-packages\nose-1.1.2-py3.2.egg\nose\cas e.py",
>>>>> line 346, in __init__
>>>>> self.inst = self.cls()
>>>>> File "E:\Josef\testing\tox\py32a\lib\site-packages\statsmodels\genmod\tests\test _glm.py",
>>>>> line 238, in __init__
>>>>> self.res2 = Lbw()
>>>>> File "E:\Josef\testing\tox\py32a\lib\site-packages\statsmodels\genmod\tests\resu lts\results_glm.py",
>>>>> line 691, in __init__
>>>>> data['race_black'], data['race_other'], data['smoke'],
>>>>> File "E:\Josef\testing\tox\py32a\lib\site-packages\numpy\core\records.py",
>>>>> line 457, in __getitem__
>>>>> obj = ndarray.__getitem__(self, indx)
>>>>> ValueError: field named race_black not found.
>>>> Just installed Python 3.2. Will have a look. This has never showed up
>>>> before? That's not a new test.
>>> I'm looking at this now, it's a consequence of the str call in
>>> categorical I guess.
>>> I'm in 3.2 and try to figure out if it's supposed to be string,
>>> unicode (encoding of string) or bytes.
I found the source of the problem, but not yet the solution
On Tue, Jun 12, 2012 at 9:37 PM, <josef.p...@gmail.com> wrote:
> On Tue, Jun 12, 2012 at 9:16 PM, <josef.p...@gmail.com> wrote:
>> On Tue, Jun 12, 2012 at 9:10 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>> On Tue, Jun 12, 2012 at 9:07 PM, <josef.p...@gmail.com> wrote:
>>>> On Tue, Jun 12, 2012 at 9:02 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>>> On Tue, Jun 12, 2012 at 8:53 PM, <josef.p...@gmail.com> wrote:
>>>>>> On Tue, Jun 12, 2012 at 2:21 PM, <josef.p...@gmail.com> wrote:
>>>>>>> On Tue, Jun 12, 2012 at 2:14 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>>>>>> On Tue, Jun 12, 2012 at 1:58 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>>>>>>> On Tue, Jun 12, 2012 at 1:38 PM, <josef.p...@gmail.com> wrote:
>>>>>>>>>> On Tue, Jun 12, 2012 at 1:30 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>>>>>>>>> On Tue, Jun 12, 2012 at 1:18 PM, <josef.p...@gmail.com> wrote:
>>>>>>>>>>>> On Tue, Jun 12, 2012 at 9:20 AM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>>>>>>>>>>>> On Sun, Jun 10, 2012 at 10:53 PM, <josef.p...@gmail.com> wrote:
>>>>>>>>>>>>>> On Sun, Jun 10, 2012 at 10:46 PM, Yaroslav Halchenko
>>>>>>>>>>>>>> <yarikop...@gmail.com> wrote:
>>>>>>>>>>>>>>> let me know when/what treeish should I check and then I would make sure
>>>>>>>>>>>>>>> you could reproduce any remaining issue ;)
>>>>>>>>>>>>>>> Thanks in advance!
>>>>>>>>>>>>>> I think I will do some merging tomorrow.
>>>>>>>>>>>> One day late.
>>>>>>>>>>>> I merged 7 branches, master tests clean on my (medium old) working
>>>>>>>>>>>> setup, but I didn't run the compatibility tests yet.
>>>>>>> I'll check tonight, since it's about strings there is some chance that
>>>>>>> python 3.2 complains.
>>>>>>> Otherwise, I extra failure on python 2.5 numpy 1.4, most likely too
>>>>>>> high precision in test.
>>>>>>> clean on py 2.6, 2.7, and 3.2
>>>>>> I fixed this one, but the last two merges don't look good, I guess the
>>>>>> categorical fix
>>>>>> these two show up in all versions. dtype mismatch i8 versus i4
>>>>>> (my python 2.5 2.6 2.7 are 32bit, python 3.2 is 64bit)
>>>>> Can you try replacing 'i8' with int?
>>>> the test specifies '<i8' as correct answer, Is that what you get on
>>>> your version combination.
>>>> For my versions it looks like it should just be '<i4'
>>> It's 32-bit for 64-bit I'm pretty sure. Just using int should fix it.
>> but then it's also platform or compiler dependent, I get also '<i4' on
>> 64 bit python 3.2 (gohlke binaries)
>> I will try the int
>> Josef
>>>> I will run the tests again after looking at the 3.2 issue
>>>>>> ======================================================================
>>>>>> FAIL: statsmodels.tools.tests.test_tools.test_rec_issue302
>>>>>> ----------------------------------------------------------------------
>>>>>> Traceback (most recent call last):
>>>>>> File "E:\Josef\testing\tox\py27a\lib\site-packages\nose\case.py",
>>>>>> line 197, in runTest
>>>>>> self.test(*self.arg)
>>>>>> File "E:\Josef\testing\tox\py27a\lib\site-packages\statsmodels\tools\tests\test_ tools.py",
>>>>>> line 314, in test_rec_issue302
>>>>>> assert_array_equal(actual, expected)
>>>>>> File "E:\Josef\testing\tox\py27a\lib\site-packages\numpy\testing\utils.py",
>>>>>> line 707, in assert_array_equal
>>>>>> verbose=verbose, header='Arrays are not equal')
>>>>>> File "E:\Josef\testing\tox\py27a\lib\site-packages\numpy\testing\utils.py",
>>>>>> line 636, in assert_array_compare
>>>>>> raise AssertionError(msg)
>>>>>> AssertionError:
>>>>>> Arrays are not equal
>>>>>> this one, I think, shows up every once in a while, only python 2.7
>>>>> Odd. Just lower precision to 3 I guess.
>>>>>> ======================================================================
>>>>>> FAIL: statsmodels.tsa.tests.test_ar.TestARMLEConstant.test_predict
>>>>>> ----------------------------------------------------------------------
>>>>>> Traceback (most recent call last):
>>>>>> File "E:\Josef\testing\tox\py27a\lib\site-packages\nose\case.py",
>>>>>> line 197, in runTest
>>>>>> self.test(*self.arg)
>>>>>> File "E:\Josef\testing\tox\py27a\lib\site-packages\statsmodels\tsa\tests\test_ar .py",
>>>>>> line 126, in
>>>>>> test_predict
>>>>>> DECIMAL_4)
>>>>>> File "E:\Josef\testing\tox\py27a\lib\site-packages\numpy\testing\utils.py",
>>>>>> line 452, in assert_almost_equal
>>>>>> return assert_array_almost_equal(actual, desired, decimal, err_msg)
>>>>>> File "E:\Josef\testing\tox\py27a\lib\site-packages\numpy\testing\utils.py",
>>>>>> line 800, in assert_array_almost_equal
>>>>>> header=('Arrays are not almost equal to %d decimals' % decimal))
>>>>>> File "E:\Josef\testing\tox\py27a\lib\site-packages\numpy\testing\utils.py",
>>>>>> line 636, in assert_array_compare
>>>>>> raise AssertionError(msg)
>>>>>> AssertionError:
>>>>>> Arrays are not almost equal to 4 decimals
>>>>>> ----------------------------------------------------------------------
>>>>>> Ran 1470 tests in 97.341s
>>>>>> FAILED (SKIP=24, failures=3)
>>>>>> on python 3.2 I get 12 errors like this, my guess is string versus bytes issue
>>>>>> ======================================================================
>>>>>> ERROR: Failure: ValueError (field named race_black not found.)
>>>>>> ----------------------------------------------------------------------
>>>>>> Traceback (most recent call last):
>>>>>> File "E:\Josef\testing\tox\py32a\lib\site-packages\nose-1.1.2-py3.2.egg\nose\fai lure.py",
>>>>>> line 37,
>>>>>> in runTest
>>>>>> raise self.exc_class(self.exc_val).with_traceback(self.tb)
>>>>>> File "E:\Josef\testing\tox\py32a\lib\site-packages\nose-1.1.2-py3.2.egg\nose\loa der.py",
>>>>>> line 495,
>>>>>> in makeTest
>>>>>> return self._makeTest(obj, parent)
>>>>>> File "E:\Josef\testing\tox\py32a\lib\site-packages\nose-1.1.2-py3.2.egg\nose\loa der.py",
>>>>>> line 554,
>>>>>> in _makeTest
>>>>>> return MethodTestCase(obj)
>>>>>> File "E:\Josef\testing\tox\py32a\lib\site-packages\nose-1.1.2-py3.2.egg\nose\cas e.py",
>>>>>> line 346, in __init__
>>>>>> self.inst = self.cls()
>>>>>> File "E:\Josef\testing\tox\py32a\lib\site-packages\statsmodels\genmod\tests\test _glm.py",
>>>>>> line 238, in __init__
>>>>>> self.res2 = Lbw()
>>>>>> File "E:\Josef\testing\tox\py32a\lib\site-packages\statsmodels\genmod\tests\resu lts\results_glm.py",
>>>>>> line 691, in __init__
>>>>>> data['race_black'], data['race_other'], data['smoke'],
>>>>>> File "E:\Josef\testing\tox\py32a\lib\site-packages\numpy\core\records.py",
>>>>>> line 457, in __getitem__
>>>>>> obj = ndarray.__getitem__(self, indx)
>>>>>> ValueError: field named race_black not found.
>>>>> Just installed Python 3.2. Will have a look. This has never showed up
>>>>> before? That's not a new test.
>>>> I'm looking at this now, it's a consequence of the str call in
>>>> categorical I guess.
>>>> I'm in 3.2 and try to figure out if it's supposed to be string,
>>>> unicode (encoding of string)
On Tue, Jun 12, 2012 at 9:59 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
> On Tue, Jun 12, 2012 at 9:58 PM, <josef.p...@gmail.com> wrote:
>> numpy provided conversion function
>>>>> [asstr(ii) for ii in np.unique(data['race'])]
>> ['black', 'other', 'white']
the copy of numpy's asstr doesn't convert numbers to strings, so I
adjusted it as asstr2.
master runs without errors and failures in all my tox environments,
minimum still python 2.5, numpy 1.4.1, scipy 0.7.
I don't have any more changes to the code planned (unless we find some
bugs of course)
docs build with a few warnings, but would benefit from manual
checking. (I never see rst errors, because they run off the screen)
Skipper, can you update the documentation on the web tonight?
One or two days of adding release related stuff (changes, notes), and
some checking of the docs and 0.4.1 could be out before the end of the
week. (I haven't run my 0.4.0 backwards compatibility tests yet, but
don't expect any problems there.)
On Tue, Jun 12, 2012 at 11:55 PM, <josef.p...@gmail.com> wrote:
> On Tue, Jun 12, 2012 at 9:59 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>> On Tue, Jun 12, 2012 at 9:58 PM, <josef.p...@gmail.com> wrote:
>>> numpy provided conversion function
>>>>>> [asstr(ii) for ii in np.unique(data['race'])]
>>> ['black', 'other', 'white']
> the copy of numpy's asstr doesn't convert numbers to strings, so I
> adjusted it as asstr2.
> master runs without errors and failures in all my tox environments,
> minimum still python 2.5, numpy 1.4.1, scipy 0.7.
> I don't have any more changes to the code planned (unless we find some
> bugs of course)
> docs build with a few warnings, but would benefit from manual
> checking. (I never see rst errors, because they run off the screen)
> Skipper, can you update the documentation on the web tonight?
Will do.
> One or two days of adding release related stuff (changes, notes), and
> some checking of the docs and 0.4.1 could be out before the end of the
> week. (I haven't run my 0.4.0 backwards compatibility tests yet, but
> don't expect any problems there.)
Ok. Let me know when you want the binaries built. I can do this
today/tonight or it will have to be Monday.
On Thu, Jun 14, 2012 at 8:41 AM, Skipper Seabold <jsseab...@gmail.com> wrote:
> On Tue, Jun 12, 2012 at 11:55 PM, <josef.p...@gmail.com> wrote:
>> On Tue, Jun 12, 2012 at 9:59 PM, Skipper Seabold <jsseab...@gmail.com> wrote:
>>> On Tue, Jun 12, 2012 at 9:58 PM, <josef.p...@gmail.com> wrote:
>>>> numpy provided conversion function
>>>>>>> [asstr(ii) for ii in np.unique(data['race'])]
>>>> ['black', 'other', 'white']
>> the copy of numpy's asstr doesn't convert numbers to strings, so I
>> adjusted it as asstr2.
>> master runs without errors and failures in all my tox environments,
>> minimum still python 2.5, numpy 1.4.1, scipy 0.7.
>> I don't have any more changes to the code planned (unless we find some
>> bugs of course)
>> docs build with a few warnings, but would benefit from manual
>> checking. (I never see rst errors, because they run off the screen)
>> Skipper, can you update the documentation on the web tonight?
> Will do.
>> One or two days of adding release related stuff (changes, notes), and
>> some checking of the docs and 0.4.1 could be out before the end of the
>> week. (I haven't run my 0.4.0 backwards compatibility tests yet, but
>> don't expect any problems there.)
> Ok. Let me know when you want the binaries built. I can do this
> today/tonight or it will have to be Monday.
Monday, then.
I'd like to give Yaroslav a chance to test them on Debian/Ubuntu
before releasing.
And, I found one more bug in an untested code path of a test.
On Thu, 14 Jun 2012, josef.p...@gmail.com wrote:
> Monday, then.
> I'd like to give Yaroslav a chance to test them on Debian/Ubuntu
> before releasing.
> And, I found one more bug in an untested code path of a test.
FWIW -- seems to build fine BUT the same old issue I have mentioned
before on ubuntu 11.10 amd64:
reading sources... [ 24%] generated/statsmodels.genmod.generalized_linear_model.GLMResults.t_test
reading sources... [ 24%] generated/statsmodels.graphics.boxplots.beanplot
/usr/lib/pymodules/python2.7/matplotlib/sphinxext/plot_directive.py:322: PlotWarning: Exception running plot plots/graphics_boxplot_beanplot.py
Traceback (most recent call last):
File "/usr/lib/pymodules/python2.7/matplotlib/sphinxext/plot_directive.py", line 319, in render_figures
run_code(plot_path, function_name, plot_code, context=context)
File "/usr/lib/pymodules/python2.7/matplotlib/sphinxext/plot_directive.py", line 225, in run_code
os.chdir(path)
OSError: [Errno 2] No such file or directory: 'plots'
warnings.warn(s, PlotWarning)
Exception occurred:
File "/usr/lib/pymodules/python2.7/docutils/statemachine.py", line 233, in run
context, state, transitions)
File "/usr/lib/pymodules/python2.7/docutils/statemachine.py", line 454, in check_line
return method(match, context, next_state)
File "/usr/lib/pymodules/python2.7/docutils/parsers/rst/states.py", line 2281, in explicit_markup
nodelist, blank_finish = self.explicit_construct(match)
File "/usr/lib/pymodules/python2.7/docutils/parsers/rst/states.py", line 2293, in explicit_construct
return method(self, expmatch)
File "/usr/lib/pymodules/python2.7/docutils/parsers/rst/states.py", line 2035, in directive
directive_class, match, type_name, option_presets)
File "/usr/lib/pymodules/python2.7/docutils/parsers/rst/states.py", line 2086, in run_directive
result = directive_instance.run()
File "/usr/lib/pymodules/python2.7/docutils/parsers/rst/__init__.py", line 370, in run
self.state, self.state_machine)
File "/usr/lib/pymodules/python2.7/matplotlib/sphinxext/plot_directive.py", line 483, in plot_directive
options, state_machine)
File "/usr/lib/pymodules/python2.7/matplotlib/sphinxext/plot_directive.py", line 400, in _plot_directive
shutil.copyfile(plot_path, os.path.join(destdir, fname))
File "/usr/lib/python2.7/shutil.py", line 81, in copyfile
with open(src, 'rb') as fsrc:
IOError: [Errno 2] No such file or directory: u'plots/graphics_boxplot_beanplot.py'
The full traceback has been saved in /tmp/sphinx-err-7QpCeB.log, if you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error message can be provided next time.
Either send bugs to the mailing list at <http://groups.google.com/group/sphinx-dev/>,
or report them in the tracker at <http://bitbucket.org/birkenfeld/sphinx/issues/>. Thanks!
make[1]: *** [html] Error 1
make[1]: Leaving directory `/tmp/buildd/statsmodels-0.4.0+git1162-g602ec99/docs'
make: *** [doc-stamp] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
E: Failed autobuilding of package
if I find a moment I will try to figure it out...
full logs are at
http://neuro.debian.net/_files/_buildlogs/statsmodels/0.4.0+git1162-g... disregard those FAILED on older ubuntus (due to missing recent
numpy/scipy's) and I guess I forgotten to fix requirement of python >=2.6 so it
fails on debian stable while trying to test against 2.5 (will fix and retest)
: # Run unittests here against installed statsmodels
cd build/ && \
PYTHONPATH=`/bin/ls -d /tmp/buildd/statsmodels-0.4.0+git1162-g602ec99/debian/python-statsmodels/us r/lib/python2.5/*/` \
MPLCONFIGDIR=/tmp/buildd/statsmodels-0.4.0+git1162-g602ec99/build \
python2.5 /usr/bin/nosetests -s -v statsmodels
Traceback (most recent call last):
File "/usr/bin/nosetests", line 8, in <module>
load_entry_point('nose==0.11.1', 'console_scripts', 'nosetests')()
File "/usr/lib/pymodules/python2.5/nose/core.py", line 113, in __init__
argv=argv, testRunner=testRunner, testLoader=testLoader)
File "/usr/lib/python2.5/unittest.py", line 767, in __init__
self.parseArgs(argv)
File "/usr/lib/pymodules/python2.5/nose/core.py", line 164, in parseArgs
self.createTests()
File "/usr/lib/pymodules/python2.5/nose/core.py", line 178, in createTests
self.test = self.testLoader.loadTestsFromNames(self.testNames)
File "/usr/lib/pymodules/python2.5/nose/loader.py", line 442, in loadTestsFromNames
return unittest.TestLoader.loadTestsFromNames(self, names, module)
File "/usr/lib/python2.5/unittest.py", line 565, in loadTestsFromNames
suites = [self.loadTestsFromName(name, module) for name in names]
File "/usr/lib/pymodules/python2.5/nose/loader.py", line 394, in loadTestsFromName
discovered=discovered)
File "/usr/lib/pymodules/python2.5/nose/loader.py", line 316, in loadTestsFromModule
tests.extend(self.loadTestsFromDir(module_path))
File "/usr/lib/pymodules/python2.5/nose/loader.py", line 165, in loadTestsFromDir
entry_path, discovered=True)
File "/usr/lib/pymodules/python2.5/nose/loader.py", line 394, in loadTestsFromName
discovered=discovered)
File "/usr/lib/pymodules/python2.5/nose/loader.py", line 316, in loadTestsFromModule
tests.extend(self.loadTestsFromDir(module_path))
File "/usr/lib/pymodules/python2.5/nose/loader.py", line 165, in loadTestsFromDir
entry_path, discovered=True)
File "/usr/lib/pymodules/python2.5/nose/loader.py", line 394, in loadTestsFromName
discovered=discovered)
File "/usr/lib/pymodules/python2.5/nose/loader.py", line 316, in loadTestsFromModule
tests.extend(self.loadTestsFromDir(module_path))
File "/usr/lib/pymodules/python2.5/nose/loader.py", line 157, in loadTestsFromDir
entry_path, discovered=True)
File "/usr/lib/pymodules/python2.5/nose/loader.py", line 394, in loadTestsFromName
discovered=discovered)
File "/usr/lib/pymodules/python2.5/nose/loader.py", line 305, in loadTestsFromModule
test_classes + test_funcs)
File "/usr/lib/pymodules/python2.5/nose/loader.py", line 304, in <lambda>
tests = map(lambda t: self.makeTest(t, parent=module),
File "/usr/lib/pymodules/python2.5/nose/loader.py", line 511, in makeTest
return self.loadTestsFromTestClass(obj)
File "/usr/lib/pymodules/python2.5/nose/loader.py", line 475, in loadTestsFromTestClass
for case in filter(wanted, dir(cls))]
File "/usr/lib/pymodules/python2.5/nose/loader.py", line 521, in makeTest
return MethodTestCase(obj)
File "/usr/lib/pymodules/python2.5/nose/case.py", line 328, in __init__
self.inst = self.cls()
File "/usr/lib/python2.5/site-packages/statsmodels/genmod/tests/test_glm.py", line 238, in __init__
File "/usr/lib/python2.5/site-packages/statsmodels/genmod/tests/results/results_ glm.py", line 693, in __init__
File "/usr/lib/python2.5/site-packages/statsmodels/tools/tools.py", line 301, in add_constant
TypeError
make[1]: *** [python-test2.5] Error 1
make[1]: Leaving directory `/tmp/buildd/statsmodels-0.4.0+git1162-g602ec99'
make: *** [binary-arch] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
-- Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
