ChanServ changed the topic of #mlpack to: "mlpack: a fast, flexible machine learning library :: We don't always respond instantly, but we will respond; please be patient :: Logs at http://www.mlpack.org/irc/
Hackarp has joined #mlpack
< Hackarp>
To whoever it is concerned, I am a sophomore CSE student from IIT Kanpur looking forward to work under mlpack. I am a newbie in this field of ML and looking for some newcomer friendly bugs/ relevant document. Any kind of help would be appreciated.
< rcurtin>
Hackarp: hi there, have you tried taking a look at the mlpack website to try and find the information you are looking for?
< rcurtin>
jeffin143: ah, I see, the issue is that the boolean parameters are handled a little differently
< rcurtin>
specifically, there are two functions that are used throughout the code: CLI::GetParam<type>() and CLI::HasParam()
< rcurtin>
now HasParam() just specifies whether or not the option was passed at all,
< rcurtin>
but for a boolean option, at least from the command-line, there is no way to specify a boolean parameter as false... you would either pass --save or you wouldn't
< rcurtin>
so, a lot of the code that exists currently treats HasParam(<boolean option>) == true as meaning that the option is true
< rcurtin>
that's likely a little bit ugly and a refactoring might be useful, since in other languages you *can* specify a boolean parameter as false
< rcurtin>
now, back to your code, try removing line 86; then, "save" should be false when mlpackMain() is called
< rcurtin>
sreenik[m]: sorry to hear about the bootloader fun... it has been a long time since I fought with that :)
< rcurtin>
in fact the last time I really fought with it was before EFI or UEFI became a thing, so every time I'm dealing with bootloaders now I'm out of my depth ...
< rcurtin>
all I know is MBRs :)
< rcurtin>
that error message is an awful mouthful for #1987... let me try for a few minutes to see if I can figure some patch out
< rcurtin>
for #1985, yeah, the build errors seem unrelated. AppVeyor just had a timeout, and I think the travis build did too. I restarted the travis job to see if it does any better this time
< rcurtin>
I guess otherwise #1985 is ready though?
< rcurtin>
sreenik[m]: uh-oh, I can't reproduce the failure with gcc 8.3.0... let me try some different versions and see what happens...
< rcurtin>
oh, nevermind... it turns out there is a big difference between 'git checkout -b' and 'git checkout'... so I had just been building the master branch
< jenkins-mlpack2>
* Ryan Curtin: Deploy all of gcc including stdlib on new versions.
< jenkins-mlpack2>
* Ryan Curtin: Fix syntax?
< jenkins-mlpack2>
* Ryan Curtin: Oops, print the captured version.
< rcurtin>
sreenik[m]: got it figured out, see the comment I just left on #1987. :) if you can handle the other bits we can get it merged and we will be very close to a 3.2.0 release :)
Hackarp has quit [Quit: Ping timeout (120 seconds)]
< sreenik[m]>
rcurtin: Thanks for the comments. I pushed a few changes but forgot to 'delete' the objects in the test. I'll fix it today after I return from college and we will be ready I guess!
< akhandait[m]>
rcurtin: I'm facing some issues with building mlpack locally. Files in core/data/ seem to be causing the errors. Has anybody faced this or do you think something might be wrong in my system?
jeffin143 has joined #mlpack
< jeffin143>
rcurtin : that doesn't work either
< jeffin143>
For some reasons c++ is behaving weirdly
< jeffin143>
The above line 125 was added just to check what happens, and weirdlyfor CLI the above mlpackmain() is compiled and for the python binding below mlpackmain() is compiled
< jeffin143>
for python binding the above mlpackmain() is not compiling, I don't know why
< jeffin143>
If you take a look , then we can see that for CLI, it works smoothly but for Python the below mlpackmain() ( The else part) since i have added a radom error msg, and it is displayed
< rcurtin>
jeffin143: it all seems reasonable to me... for python you aren't specifying the width/height/channel parameters in the call to load_save_image()
< jeffin143>
If you check the else part , I have added a statment if (!CLI::HasParam("input")) throw error
< jeffin143>
just a sec I will show you for cli the same command
< jeffin143>
for python and cli 2 different error msg are comming, The reason is two different mlpackmain() programs in load_save_image_main.cpp
< rcurtin>
okay, I see, so it looks like HAS_STB is not being set for the Python bindings, do you agree with that diagnosis?
< rcurtin>
I can tell you what you'll need to do to get that enabled for Python bindings but it will be a little bit tedious:
< jeffin143>
Yes thats what I have concluded
< jeffin143>
Umm ok let me know whenever you are free, We can discuss that
< rcurtin>
1) modify the main CMakeLists.txt so that some variable called STB_AVAILABLE or something like that is set when STB is found (like 'set(STB_AVAILABLE 1)' or something)
< rcurtin>
2) modify src/mlpack/bindings/python/setup.py.in so that it knows when to add '-DHAS_STB' to the compile definitions: you can use the CMake configuration variable ${STB_AVAILABLE} to check
< rcurtin>
to be more specific, CMake calls configure_file() on setup.py.in to produce the configured setup.py, and it is at this point that we want to be sure to add the extra flag -DHAS_STB to the compilation
< rcurtin>
I *think* that you could do this before or after the line 'if not '${OpenMP_CXX_FLAGS}'':
< rcurtin>
if '${STB_AVAILABLE}':
< rcurtin>
extra_args = ['-DHAS_STB']
< rcurtin>
and then you'll have to modify where extra_args is set a little later down to make sure it accounts for the existing values in extra_args
< rcurtin>
I hope that's helpful... that's a very basic overview, maybe not a good one, but hopefully enough to get you started :)
< jeffin143>
Ok , so i need to google and understand how to write CMAke :)
< jeffin143>
Thanks for the information
< jeffin143>
I will ping you after trying :)
< rcurtin>
yeah, CMake is a strange language but it's not *too* hard
< rcurtin>
debugging is not too hard with this trick: you can add 'message(STATUS "variable is ${variable}")' to check the values of variables
< rcurtin>
at least, that's what I do a lot to figure out why things aren't set correctly...
< jeffin143>
:) thanks, also can you help me debug the above error too, message at 13:40, I don't understand why do same code behave differently in two different areas !!!!
< rcurtin>
right, exactly, this is the same thing
< rcurtin>
the reason the programs are behaving differently is that HAS_STB is defined when the command-line programs are compiled, but not when the Python bindings are compiled
< rcurtin>
so the idea of the guidelines I wrote above is to make sure that HAS_STB is *also* set when building Python bindings, by modifying the CMake configuration in the right way
< jeffin143>
but load_save_image_main_test.cpp is for CLI write, how would python binding effect them ?
< rcurtin>
okay, I definitely don't understand what you are referring to then. can you re-explain what the question is?
jeffin143 has quit [Ping timeout: 260 seconds]
ImQ009 has joined #mlpack
< akhandait[m]>
zoq:
jenkins-mlpack2 has quit []
coatless has joined #mlpack
< coatless>
@zoq are you folks planning a new release on Ensmallen any time soon? Or would it be safe to send out the compatibility fixes to CRAN?
< coatless>
@rcurtin ^^
jeffin143 has joined #mlpack
< jeffin143>
Hi rcurtin , You are a hero, That resolved the issue :) Thanks
< jeffin143>
Now there is a small problem -> if you could help me with that too :)
< jeffin143>
For some reasons c++ is behaving weirdly
< jeffin143>
Both the code line 70 to 90 and 97 to 117 have Same code but the latter one failed !
< jeffin143>
But couldn't get to*
< jeffin143>
I am sure, this is something to do with the implementation of the CLI, since I have tried everything possible.
< jeffin143>
If you could tell me how to clear the setInputParma("",""); after setting those , like i have to set new values, and i have to delte the old setinputparams,how to do it ?
< rcurtin>
coatless: I think that we should get #135 fixed and merged and do a patch release
< rcurtin>
jeffin143: awesome, glad that you got it resolved; I don't have a chance to look at the second thing now but I will try and look shortly
< rcurtin>
coatless: I can't say how long that will take though; maybe a few days? in either case, I'm not sure what sending fixes to CRAN entails, so I don't know if it's a big effort or small
< coatless>
Small effort with a freeze of about 4-5 days.
jeffin143 has quit [Ping timeout: 260 seconds]
< rcurtin>
coatless: ok, I see, in this case, let's wait on 2.10.2; I think we can get #135 merged soon
coatless has quit [Remote host closed the connection]
travis-ci has joined #mlpack
< travis-ci>
mlpack/mlpack#8030 (master - 72d7e54 : Ryan Curtin): The build has errored.
< zoq>
akhandait[m]: Was that with a clean build? Also I guess you are trying to build the master branch?
< zoq>
coatless: Do you see the same issue as described in #132?
< rcurtin>
jeffin143: ok, I believe I understand the problem now
< rcurtin>
thanks for the explanation
< rcurtin>
in your tests, the issue is that, if you uncomment lines 95 through 117, the test fails, because the *second* call to mlpackMain() still has "save" set to true
< rcurtin>
when I look through the code, CleanMemory() only cleans memory---it doesn't change the values of any parameters
< rcurtin>
further, the definition of SetInputParam() in test_helper.hpp just calls CLI::GetParam() to set the value of the parameter and also calls CLI::SetPassed() to mark the parameter as passed (so that HasParam() returns true)
< rcurtin>
now, the test fixture (lines 26 through 41) force *all* the parameters to be reset for every test by calling CleanMemory(), then ClearSettings(), then RestoreSettings()
< rcurtin>
so, the easiest option (but I don't know if it is valid) is to put each call to mlpackMain() in a separate test
< rcurtin>
the second easiest option (but it is a little ugly) is to call CleanMemory(), ClearSettings(), and RestoreSettings() at line 105
< rcurtin>
the third option is to add a CLI::UnsetPassed() function to cli.hpp, then add something to test_helper.hpp like 'UnsetInputParam("name")' that just unsets the parameter, then use that at line 105
< rcurtin>
I hope all of that makes sense, let me know if I can clarify anything :)
< zoq>
rcurtin: Are you working on jenkins?
< rcurtin>
zoq: no... or, at least, I wasn't before you asked the question :)
< rcurtin>
I did think it was strange that jenkins-mlpack2 left
< rcurtin>
let's see what's happening...
< rcurtin>
I didn't see any useful log messages; it seems like the process just terminated for some reason
< rcurtin>
anyway, it's coming back up now
jenkins-mlpack2 has joined #mlpack
< zoq>
rcurtin: okay, at least the server is still running :)