PyPI

[StrikerRUS]

I think it's time to increment the version, create new release on GitHub and register rgf_python on PyPI to make it more popular and easy-to-install.

[StrikerRUS]

I see that you've already incremented version but the badge shows previous one. Bug? 😞

[fukatani]

I re-updated version, but it doesn't work.

[fukatani]

Thank you for your suggestion for registering pip.

rgf_python can be installed by

pip install git+git://github.com/fukatani/rgf_python@master

so we don't have to hurry. I will do in the future.

By the way, can we build C ++ just by pip?

[StrikerRUS]

I re-updated version, but it doesn't work.

OK, forget about it. After registering PyPI we will replace this buggy badge with this one which will sync with PyPI:

rgf_python can be installed by
pip install git+git://github.com/fukatani/rgf_python@master

Yeah, but pip install rgf_python looks more pleasing 😄 . I want to give a link to this repo to Russian data-science community with the aim of testing and popularization. That's why I asked you to register PyPI account. By the way, we will be able to add this badge too 😃

By the way, can we build C ++ just by pip?

Interesting idea! 👍 I'll google it in a few days.

[fukatani]

Yeah, but pip install rgf_python looks more pleasing 😄 . I want to give a link to this repo to Russian data- science community with the aim of testing and popularization. That's why I asked you to register PyPI account.

Cool! OK, I'll register to PYPI definitely.
I'm trying it, but pypi server is down now.

Interesting idea! 👍 I'll google it in a few days.

Thanks! User benefit of this is big.

[StrikerRUS]

Thanks! Don't hurry, +/- several days don't matter, I think.

I've found that it's possible to build C++ source code on-the-fly using pip.
At first sight, it looks like an ocean of a headache for us. But even if we implement it, we will restrict users in possible compilers. I mean, our pip install rgf_python will assume specific compiler for each platform, and user will not be able to use their favorite compiler. So, if compiler is not in the PATH the WHOLE installation will be aborted. Now we allowing users to use any compiler and installation through pip never crashes. I think that it's better to ask users compile by themselves.
Please take a look to setup.py where compiling on-the-fly is used:
LightGBM, XGBoost. So many restrictions...

We are on PyPI now. For stable version, please install using pip:
pip install xgboost
Since this package contains C++ source code, pip needs a C++ compiler from the system to compile the source code on-the-fly. Please follow the following instruction for each supported platform.
Note for Mac OS X users: please install gcc from brew by brew tap homebrew/versions; brew install gcc --without-multilib firstly.
Note for Linux users: please install gcc by sudo apt-get install build-essential firstly or using the corresponding package manager of the system.
Note for windows users: this pip installation may not work on some windows environment, and it may cause unexpected errors. pip installation on windows is currently disabled for further investigation, please install from github.

What do you think?

[StrikerRUS]

Offtop: Maybe after a while all our work will not be needed link.

[fukatani]

I completed to register PYPI.

And thank you for your research about on-the-fly compile. It seems difficult for us.
It may be better to quit.

Offtop: Maybe after a while all our work will not be needed link.

If LightGBM supports RGF earnestly, it is great benefit for users.
I think that what we are doing is meaningful in spreading RGF.
Of course, there is the possibility that lightgbm will give up to support RGF.

[StrikerRUS]

I completed to register PYPI.

Super! Thanks!

I'll search more about on-the-fly compiling. Maybe there is an opportunity to create two versions of installation: with and without compiling binaries, it'll be the perfect variant. I'll keep you informed about my finds.

[StrikerRUS]

Of course, there is the possibility that lightgbm will give up to support RGF.

It seems that you were right.

About on-the-fly compiling: I found the way to implement option-dependent installation. Working on it link.

[fukatani]

About on-the-fly compiling: I found the way to implement option-dependent installation. Working on it link.

Wonderful! This must make rgf_python more popular!

[StrikerRUS]

I'm having some troubles with building exe file from Visual Studio .sln file. On my machine I overcame problem somehow, but remotely (appveyor) didn't: even if file is compiled it's broken (always return code isn't 0).

Which OS do you use? Or better question: do you have access to Windows machine? 😄

[fukatani]

I use rgf_python on,

Windows 7 (32bit) 
Visual Studio 2010 C++

To compile RGF, I needed to edit .sln file and to compile 32bit version.
I think version of Visual Studio is also important.

However, if we can on-the-fly compile only on Ubuntu, it is big progress for rgf_python.

[StrikerRUS]

Yeah, according to logs of Appveyor, MSBuild can automatically detect the platform: x64 or x86.

The problem is in PlatformToolset. By default it was Windows7.1SDK. Locally I can specify installed on my machine toolset (v120) and everything works fine. But remotely after compiling with toolset which is differ from Windows7.1SDK (for example, v110 for Visual Studio 2010) compiled file is corrupted and everytime returns error.

Maybe you know how properly change PlatformToolset or maybe it's needed to specify more parameters except PlatformToolset.

PROJECT -> PROPERTIES:

And the corresponding code.

UPD: Please say what PlatformToolset displays when you open solution file from branch compile.

UPD2: How many warnings you got after compiling Win32 solution (it'll be great to see your building logs)?

[StrikerRUS]

Last news: I still don't know how to change PlatformToolset by MSBuild properly and there are ~100 warnings on 32-bit machines about type casting.
Other use cases seem to be OK. I created special branch for it and you may see Travis and Appveyor success.

[fukatani]

Thank you for your report!
It'll be pretty nice if we can merge this branch.

I am going to look at the build report on 32bit PC.

[StrikerRUS]

Yeah, I think we are almost ready to bring on-the-fly compiling to rgf_python.

Thanks for your participation in testing. I mean, I want to see your building logs of original VS solution. On my 64-bit machine even this one is compiled with warnings. I think, I'll write to author with the question about it...
And please don't forget to notice PlatformToolset which is shown in settings.

[StrikerRUS]

I came up to the conclusion that specifying some PlatformToolset (PT) versions produces corrupted executable file just because of Appveyor has many installed versions of VS and they interfere paths. That's only the objective reason that came in my mind. Fortunately, I learned how to detect such files and drop them while iterating through different PTs. So, these PTs are not dangerous but they increase the possibility not to made users install additional software.

Also, I've written to the author of rgf1.2 and asked him about the safety of typecasting from Azint8 to size_t.

[StrikerRUS]

Rie Johnson, one of the author of RGF, answered the following about the question about typecasting from AZint8 to size_t warnings:

I think in theory it should work on 32-bit machines too, with a limitation on file sizes (see below).  But I cannot guarantee it since I cannot test it -- I have no access to 32-bit machines.  
 
AZint8 (8-byte integer) was introduced mainly for handling files larger than 2GB (which typical 32-bit systems cannot handle).  The typecasting from AZint8 to size_t indicates that with your compiler, C library functions for file I/O can only handle files smaller than 2GB.  Those typecast warnings themselves are not a problem.  The thing is, with rgf compiled for 32-bit systems, you can not handle files larger than 2GB; for example, if you try to make a very large model so that a model file size goes over 2GB, then the code would either die or return some error.  

__ AZ_MSDN__ is for using the 64-bit version of fseek etc. on Windows, and so in this case, you can remove it.