Hey guys - I just checked coveralls -- appears to be online on 94% coverage so
all seems fine there - I still have access to it from setting it up back when
haha
So we're 'all-covered'
Hope you guys are well!
Jaques
> On 28 Jul 2016, at 5:25 PM, Andreas Mueller wrote:
>
> Hey all.
> So I t
Hi guys,
I am sorry to bother you. But I have a question about using
scikit-learn in ubuntu.
I installed scikit using:
sudo apt-get install build-essential python-dev python-numpy
python-numpy-dev python-scipy libatlas-dev g++ python-matplotlib ipython
sudo pip install -U sciki
On 07/28/2016 05:48 PM, Gael Varoquaux wrote:
On Thu, Jul 28, 2016 at 11:25:28AM -0400, Andreas Mueller wrote:
I gave permissions back to the CI services, but they are not all linked to
my account.
Olivier, can you check for coveralls and circleci? I think you have these
accounts.
Appveyor and
On Thu, Jul 28, 2016 at 11:25:28AM -0400, Andreas Mueller wrote:
> I gave permissions back to the CI services, but they are not all linked to
> my account.
> Olivier, can you check for coveralls and circleci? I think you have these
> accounts.
> Appveyor and travis are working again.
Hum, Olivier
Agreed that it sounded great on podcast.__init__ and I specifically thought
it would be helpful for sklearn as someone who is not a developer but has
been digging into the codebase. If anyone on the list wants an overview of
MyPy I highly recommend listening to that episode:
http://podcastinit.podb
On 07/28/2016 03:30 PM, federico vaggi wrote:
My main issue with the upgrade is that if there was a slightly newer
version of numpy/scipy it would try to upgrade my numpy/scipy linked
against MKL/blas to a vanilla version downloaded from the cheese
shop. It was a huge pain.
You mean with b
On Thu, Jul 28, 2016 at 8:30 PM, federico vaggi
wrote:
> My main issue with the upgrade is that if there was a slightly newer version
> of numpy/scipy it would try to upgrade my numpy/scipy linked against
> MKL/blas to a vanilla version downloaded from the cheese shop. It was a
> huge pain.
The
My main issue with the upgrade is that if there was a slightly newer
version of numpy/scipy it would try to upgrade my numpy/scipy linked
against MKL/blas to a vanilla version downloaded from the cheese shop. It
was a huge pain.
On Thu, 28 Jul 2016 at 21:17 Matthew Brett wrote:
> On Thu, Jul 28
On Thu, Jul 28, 2016 at 8:10 PM, Andreas Mueller wrote:
>
>
> On 07/28/2016 03:04 PM, Matthew Brett wrote:
>>
>> On Thu, Jul 28, 2016 at 7:55 PM, Sebastian Raschka
>> wrote:
>>>
>>> I think that should work fine for the `pip install scikit-learn`,
>>> however, I think the problem was with upgradi
On 07/28/2016 03:04 PM, Matthew Brett wrote:
On Thu, Jul 28, 2016 at 7:55 PM, Sebastian Raschka
wrote:
I think that should work fine for the `pip install scikit-learn`, however, I
think the problem was with upgrading, right?
E.g., if you run
pip install scikit-learn --upgrade
it would try
On 07/28/2016 02:55 PM, Sebastian Raschka wrote:
I think that should work fine for the `pip install scikit-learn`, however, I
think the problem was with upgrading, right?
Well so far the compiling was more the issue.
E.g., if you run
pip install scikit-learn --upgrade
it would try to upgra
On Thu, Jul 28, 2016 at 7:55 PM, Sebastian Raschka
wrote:
> I think that should work fine for the `pip install scikit-learn`, however, I
> think the problem was with upgrading, right?
> E.g., if you run
>
> pip install scikit-learn --upgrade
>
> it would try to upgrade numpy and scipy as well, wh
I think that should work fine for the `pip install scikit-learn`, however, I
think the problem was with upgrading, right?
E.g., if you run
pip install scikit-learn --upgrade
it would try to upgrade numpy and scipy as well, which may not be desired. I
think the only workaround would be to run
I am not a core dev but just wanted to say that I like the idea of adding
static type checking a lot, Daniel. Coincidentally, I just listened to the
Podcast.__init__ episode on mypy a few weeks ago and was planning to use it in
my personal + research projects as well.
I think the “normal” scik
Hi all.
I think since the pipy ecosystem improved a lot, we should properly
declare the scipy
and numpy dependencies, so that ``pip install scikit-learn`` works properly.
The argument why we did not do this previously was that this would try
to download
and build numpy and scipy, which are pre
On 07/28/2016 12:43 PM, Gael Varoquaux wrote:
On Thu, Jul 28, 2016 at 12:04:48PM -0400, Andreas Mueller wrote:
If you find some bugs with the annotations and mypy, that would probably
prove its value to some degree [and if you don't, I might be inclined to
argue it's not working well ;]
Joel,
On Thu, Jul 28, 2016 at 12:04:48PM -0400, Andreas Mueller wrote:
> If you find some bugs with the annotations and mypy, that would probably
> prove its value to some degree [and if you don't, I might be inclined to
> argue it's not working well ;]
> Joel, Olivier, Gael, anyone else?: opinions?
Th
On Thu, Jul 28, 2016 at 12:10:03PM -0400, Andreas Mueller wrote:
> >Given numpy has dropped support for 2.6, maybe it would be reasonable
> >for scikit-learn to do the same, to make this process easier?
> How would it change the process?
> We have been discussing this. My stance is that we should
On Thu, Jul 28, 2016 at 5:10 PM, Andreas Mueller wrote:
>
>
> On 07/28/2016 12:03 PM, Matthew Brett wrote:
>>
>> Hi,
>>
>> On Wed, Jul 27, 2016 at 10:08 PM, Andreas Mueller
>> wrote:
>>>
>>> Hi Daniel.
>>> This hasn't been brought up before so there is no "official position".
>>> I am generally i
On Thu, Jul 28, 2016 at 5:04 PM, Andreas Mueller wrote:
>
>
> On 07/28/2016 11:55 AM, Daniel Moisset wrote:
>
>>
>>
>> Given that there's interest (or at least no opposition) on this I feel
>> inclined to create a fork and start adding annotations (the comment-based
>> ones) into the code (which
Hi,
On Wed, Jul 27, 2016 at 10:08 PM, Andreas Mueller wrote:
> Hi Daniel.
> This hasn't been brought up before so there is no "official position".
> I am generally in favor, though I'm not sure how doable it is.
> We are generally pretty generous in accepting all kinds of inputs, and many
> of ou
On 07/28/2016 11:55 AM, Daniel Moisset wrote:
Given that there's interest (or at least no opposition) on this I feel
inclined to create a fork and start adding annotations (the
comment-based ones) into the code (which is better suited for this
scenario than creating external type stubs). W
On 07/28/2016 12:03 PM, Matthew Brett wrote:
Hi,
On Wed, Jul 27, 2016 at 10:08 PM, Andreas Mueller wrote:
Hi Daniel.
This hasn't been brought up before so there is no "official position".
I am generally in favor, though I'm not sure how doable it is.
We are generally pretty generous in accep
Hi Andreas, thanks for the reply,
I think many arguments may end up with open specs, but even specifying
"Union[None, int, float, string, np.ndarray]" might be useful. I actually
expect to be able to provide stricter types using generics (you can say
things like "this a list of floats" or "this is
Hey all.
So I think I messed with the CI a bit too much yesterday.
After looking into the organization permissions a bit more, I saw that
any app that is authorized on github by any of the devs
will automatically be authorized for the organization.
That seems pretty bad.
So I change that defaul
25 matches
Mail list logo
