verne.freenode.net changed the topic of #mlpack to: http://www.mlpack.org/ -- We don't respond instantly... but we will respond. Give it a few minutes. Or hours. -- Channel logs: http://www.mlpack.org/irc/
zoq has quit [Read error: Connection reset by peer]
zoq has joined #mlpack
trapz has quit [Quit: trapz]
KTL has joined #mlpack
govg has quit [Ping timeout: 264 seconds]
govg has joined #mlpack
govg has quit [Ping timeout: 252 seconds]
govg has joined #mlpack
vedhu63w has joined #mlpack
govg has quit [Ping timeout: 246 seconds]
govg has joined #mlpack
govg has quit [Ping timeout: 252 seconds]
KTL has quit [Ping timeout: 264 seconds]
govg has joined #mlpack
KTL has joined #mlpack
govg has quit [Ping timeout: 252 seconds]
govg has joined #mlpack
govg is now known as Guest83620
Guest83620 has quit [Ping timeout: 264 seconds]
vedhu63w has quit [Ping timeout: 272 seconds]
govg_ has joined #mlpack
govg_ has quit [Ping timeout: 256 seconds]
govg_ has joined #mlpack
KTL has quit [Ping timeout: 252 seconds]
govg_ has quit [Ping timeout: 272 seconds]
govg has joined #mlpack
govg has quit [Quit: leaving]
govg has joined #mlpack
KTL has joined #mlpack
trapz has joined #mlpack
< naywhayare>
okay, thought of the day:
< naywhayare>
if I compile mlpack without debugging symbols, there are no bounds checks or anything like this, and it's fast
< naywhayare>
but if the user builds a program that does something invalid (like, say, calling an out of bounds element in a DiscreteDistribution), they'll get segfaults and other weirdness
< naywhayare>
so to figure out what went wrong, they have to rebuild libmlpack.so with debugging symbols, which is tedious, and then rebuild their program against that
< naywhayare>
after some discussion with some friends, we thought the best idea was to build libmlpack.so and also libmlpack_debug.so and distribute both
< naywhayare>
so, if your program is segfaulting, you relink with -lmlpack_debug and then you get more useful (but slower) output
< naywhayare>
thoughts?
< naywhayare>
I'll have to run this by Dirk Eddelbeutel too, who packages mlpack for Debian, to see if this would be some giant packaging disaster and violates Debian guidelines or something
< zoq>
naywhayare: hm, if we build mlpack with and without debug symbols how does this affect the build time?
< naywhayare>
the build of libmlpack_debug.so will take about as long as the build of libmlpack.so, but there's no need to build mlpack_test or any other executable twice, so, if I type 'make', it'll probably take about 1.2-1.3x as long (just a guess), but not 2x
< zoq>
I think it should be possible to build mlpack with debug symbols only (default is without and with debug symbols)?
< zoq>
So for all who usually build mlpack with debug symbols only there is no downside
< syrius>
naywhayare: package manager aside, but strictly per naming convention, i just had an input on the debug name
< syrius>
libmlpackd.so
< syrius>
instead of _debug
< naywhayare>
syrius: ah, yeah, I would agree with that
< syrius>
but i do think it's a good idea for people using the package distribution
< syrius>
that won't require them to recompile themselves
< naywhayare>
zoq: ah, okay, so maybe some CMake option "BUILD_SEPARATE_DEBUG" or something like this, which, when enabled, builds libmlpackd.so ?
< naywhayare>
(and then the distributions can distribute both libmlpack.so and libmlpackd.so)
< zoq>
naywhayare: yeah, right
< syrius>
hmm
< syrius>
naywhayare: hmm, another possibility w/ the package management situation
< syrius>
since i assume most people wanting mlpack from the repo might not be developers
< syrius>
since it's just a dependency, would it make more sense to include libmlpackd.so in mlpack-dev package instead of mlpack package?
< syrius>
maybe it's just bad practice period to include an so in a -dev package though
< naywhayare>
syrius: yeah, I agree with that idea, but that's up to the packagers in the end
< naywhayare>
although I guess I am the Fedora packager, so I get to make the decision for Fedora...
< naywhayare>
hmm, I suppose it is possible that someone downstream might want to distribute something linked against libmlpackd.so, so they can get better error output in whatever application they're writing
< naywhayare>
in which case libmlpackd.so should be in the libmlpack package (or whatever it is called by the distribution)
< syrius>
just brainstorming, since quite often regular apps that have mlpack as a dependency won't need the debug library
< syrius>
i feel it's kind of a stretch that someone would distribute a machine learning app linked against mlpack debug
< syrius>
wouldn't that somewhat be too performance prohibitive?
< naywhayare>
yeah, I would certainly think so
< naywhayare>
things compiled in debug mode will still run, but they may take anywhere between (ballpark) 3x-20x to run
< syrius>
i can only see the debug mlpack being used by developers during testing
< syrius>
yeah
< naywhayare>
(at least, that's what my empirical work with debug mode has seemed to indicate)
< syrius>
having the debug lib as a dependency in a repo would be crazy
< naywhayare>
libmlpackd.so is 14M too, so that is compelling reason to leave it out of the mlpack package
< syrius>
well absolutely.. it's not nearly as helpful if you're compiling with debug symbols and also optimization
< naywhayare>
yeah
< syrius>
i would personally laugh at an app that linked against a debug version of a lib for 'production' use
< syrius>
or question their confidence in their implementation of said dependency :)
< syrius>
well, here's another thing too.. no one is going to be debugging someone elses app already linked against mlpack release
< syrius>
well, not no one
< syrius>
but the main app would have to be open source, and they'd have to relink
< syrius>
that's the simplistic case.. i don't forsee a ton of people doing that
< naywhayare>
yeah; I don't aim to make debugging for things five levels downstream easier (because that's going to be a nightmare anyway if the bug is in mlpack or a way upstream dependency)
< syrius>
secondly, if they're going to be debugging through mlpack specifically, chances are they're going to have to be familiar with mlpack, aka they have the source
< syrius>
and if they're familiar enough with the mlpack source, they can probably easily build it themselves
< syrius>
though, i do see the utility in having it available period for developers
< syrius>
do you have a lot of requests for prebuilt debug binaries?
< naywhayare>
not really, but I do get a lot of people who say "it just segfaulted", and the reason becomes clear when linking against a debug version where you get things like out of bounds checks and stuff like that
< naywhayare>
and the first thing I want to say is "show me what it does when you compile with debugging symbols", but then for them this entails reconfiguring mlpack
< naywhayare>
and if they just installed libmlpack-dev on Debian or whatever, this is now a difficult task which involves downloading and compiling mlpack by hand
< naywhayare>
or, if they had already compiled it, they need to either reconfigure CMake or make a new build directory and compile again
< syrius>
naywhayare: sure, that makes sense. i suppose you're already maintaining these binaries for various platforms to begin with
< naywhayare>
I only do the Fedora/RHEL packaging; others do it for Debian/Ubuntu/Mint/other derivatives and Arch Linux
< naywhayare>
I think someone does it for Gentoo and FreeBSD too, but my email contact with them ended years ago with an un-followed-up-reply from them that said "Hey! Great to hear from you! I have a lot of questions to ask, I'll get back to you soon..."
< naywhayare>
I guess people are packaging it for Homebrew too; not sure of the status of the OS X package managers
< syrius>
yeah, homebrew and macports are the two main ones
< syrius>
on osx
< zoq>
Maybe saketkc has given up ... not sure, I'll wait a couple of days, if nothing happens, I'll go and make a pull request to get mlpack into homebrew science.
< naywhayare>
I think I may have been a little short to saketkc in the bug tracker when he kept opening new bugs and giving very little useful information for debugging, and maybe I scared him off. I'll be more careful in the future...