[Haskell-cafe] Re: ANNOUNCE: A Levenberg-Marquardt implementation
> Our binding consists of three packages: > > * http://hackage.haskell.org/package/bindings-levmar-0.1 Which were the changes you needed to do to the library code? I believe this is going to cause you two problems: maintenance (as you can't always be sure the patched version didn't introduce a bug) and license (as levmar is GPL. You can't distribute it linked to non GPL code). > * http://hackage.haskell.org/package/levmar-0.1 Cool. Don't you think the type level natural numbers deserve their own package? > Unfortunately the documentation of these libraries is not > available from hackage because bindings-levmar won't configure > because of a missing dependency (lapack) on the hackage server. I'll try to write you a patch to solve that after I study better your code. Best, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANNOUNCE: A Levenberg-Marquardt implementation
> The C library prints error messages to stderr. (...) > Attached is the patch to the C levmar library. Thanks for the file. > The license issue is indeed a problem. Either your (linked + > distributed) code must be GPL or you must acquire a different > (commercial) license from the author of the C library. I don't think the GPL is itself a problem, I just meant that by packaging levmar with your bindings-levmar you probably have to GPL bindings-levmar itself. Although, since you used BSD, I don't think anyone will waste time bothering you about that. > Lapack has to be installed on the hackage server in order for > the package to build. Another option is to temporarily remove > the dependency on lapack from the cabal file. (...). But the > downside is that someone won't be able to cabal install it > without first modifying the .cabal file. That is unacceptable in > my opinion. Yes, this is difficult to solve... I've even asked that some nice, trusted C libraries could be installed on hackage so that we could bind to them. Maybe this can be accepted in the future if the idea of having many good quality bindings-* packages grow up. In the mean time, we have a two-sided problem: if we release a package with linking options removed we have to edit cabal file, which is unacceptable in my opinion too; and if we do not, all bindings-*, as well as all packages built on them, will be marked with "Build failure" on hackage and lack documentation, which is also unnaceptable... The good thing is that this problem can be isolated on bindings-* packages. If it is solved, it is solved once and for all. So far, my solution has been this: * to leave a 'pkg-config' line in bindings-* cabal file. This way, your package can be used properly as long as your installed library has pkg-config configuration, and this is easy to add (even for your favorite distribution library package) if it doesn't. * to comment that pkg-config line, so that hackage will build your package. Users can just add something like 'pkgconfig-depends: levmar' to their own packages. Though I have no reason to claim this is the best solution. Also: bindings-common has some macros that could easy your job. You could have used, for instance: #bindings_frac LM_INIT_MU #bindings_frac LM_STOP_THRESH #bindings_frac LM_DIFF_DELTA Although this would add a dependency, so I don't know if it's worth. Best, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANNOUNCE: A Levenberg-Marquardt implementation
>> Unless you think that extra-libraries is a good long term >> solution, I'll still investigate on how to add pkg-config >> generation to configuration scripts and try to send a sugestion >> with a patch to maintainers of libraries wrapped in bindings-*. > It is not practical to use pkg-config for such libraries. After > you persuade the reference code[1] of lapack to use pkg-config, > are you going to make ATLAS[2] do it also? And what about > Intel's mkl[3]? Or even lapack bindings provided by Nvidia's > CUDA[4]? Sure. But only for packages we have direct Haskell bindings to. You only need pkg-config available for the libraries you directly need for a cabal package. For complicated dependencies, just rely on your OS distribution (or Haskell Platform etc.). > I know it's hard to include every possibilities. But I prefer > some configuration switch that I can tune when building the > library. The idea is just to provide a default, working configuration. Anyway, I imagine this tunning should be done in a way that is transparent to a cabal package. > That's been said, it is still your package. And people can > always change the build scripts for their own needs. Not actually! I didn't work on bindings-levmar. I'm just the guy who started the idea of having low level bindings packages as basis for higher level bindings (so that this kind of problem can be solved at the same time for many, say, levmar high level bindings). That's why I would like to help acchieving good general guides for easy building. Wrapping of levmar is entirely van Dijk brothers' work. http://hackage.haskell.org/package/bindings-common Best, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANNOUNCE: A Levenberg-Marquardt implementation
Yes. It works this way. Tested in debian and old fedora Thank you for testing. I have just released bindings-levmar-0.1.0.1 on hackage. It simply replaces pkgconfig-depends with extra-libraries. I hope this solves the installation problems. Debian maintainer was willing to add pkg-config to lapack package: http://lists.alioth.debian.org/pipermail/pkg-scicomp-devel/2009-September/004508.html However, he and also Tollef (pkg-config maintainer) believe it's a better idea to add it to upstream package: http://article.gmane.org/gmane.comp.package-management.pkg-config/346 Unless you think that extra-libraries is a good long term solution, I'll still investigate on how to add pkg-config generation to configuration scripts and try to send a sugestion with a patch to maintainers of libraries wrapped in bindings-*. Although I don't know exactly how that patch should exactly be... Best, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: A Levenberg-Marquardt implementation
>> * http://hackage.haskell.org/package/bindings-levmar-0.1 > > Which were the changes you needed to do to the library code? I > believe this is going to cause you two problems: maintenance (as > you can't always be sure the patched version didn't introduce a > bug) and license (as levmar is GPL. You can't distribute it linked > to non GPL code). The C library prints error messages to stderr. We can check some things before calling the C functions to ensure that some erroneous conditions do not occur, but we can't prevent all cases. Since the functions already returned a generic error code we disabled all printing to stderr and created an enumeration of error codes. In Haskell we wrap this error code in a nice data type so if something goes wrong you'll know why. We have send a patch with these changes to the author and we are waiting for a reply. The license issue is indeed a problem. Either your (linked + distributed) code must be GPL or you must acquire a different (commercial) license from the author of the C library. The benefits of the library we have chosen for this binding is that it is small, just a few .c files, and it has almost no dependencies. If anyone knows of any other implementations of Levenberg-Marquardt that are also easy to bind then we would certainly like to hear it. If the feature set is not to different we might be able to provide a common interface. >> * http://hackage.haskell.org/package/levmar-0.1 > > Cool. > > Don't you think the type level natural numbers deserve their own > package? Perhaps in the future. For this release we just focused on levmar. We might also use another package for type level programming if it suits our needs. >> Unfortunately the documentation of these libraries is not >> available from hackage because bindings-levmar won't configure >> because of a missing dependency (lapack) on the hackage server. > > I'll try to write you a patch to solve that after I study better > your code. Lapack has to be installed on the hackage server in order for the package to build. Another option is to temporarily remove the dependency on lapack from the cabal file. The package would probably build, you just wouldn't be able to link against it. But the downside is that someone won't be able to cabal install it without first modifying the .cabal file. That is unacceptable in my opinion. Roel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: A Levenberg-Marquardt implementation
Maurício CA writes: >>> Yes. It works this way. Tested in debian and old fedora > >> Thank you for testing. I have just released bindings-levmar-0.1.0.1 on >> hackage. It simply replaces pkgconfig-depends with extra-libraries. I >> hope this solves the installation problems. > > Debian maintainer was willing to add pkg-config to lapack package: > > http://lists.alioth.debian.org/pipermail/pkg-scicomp-devel/2009-September/004508.html > > However, he and also Tollef (pkg-config maintainer) believe it's a > better idea to add it to upstream package: > > http://article.gmane.org/gmane.comp.package-management.pkg-config/346 > > Unless you think that extra-libraries is a good long term > solution, I'll still investigate on how to add pkg-config > generation to configuration scripts and try to send a sugestion > with a patch to maintainers of libraries wrapped in bindings-*. > Although I don't know exactly how that patch should exactly be... > It is not practical to use pkg-config for such libraries. After you persuade the reference code[1] of lapack to use pkg-config, are you going to make ATLAS[2] do it also? And what about Intel's mkl[3]? Or even lapack bindings provided by Nvidia's CUDA[4]? [1] http://www.netlib.org/lapack/ [2] http://math-atlas.sourceforge.net/ [3] http://software.intel.com/en-us/intel-mkl/ [4] http://www.nvidia.com/object/cuda_home.html One can install them side by side, but for performance's sake, one really wants to link a particular library/binary to the most useful one. I know it's hard to include every possibilities. But I prefer some configuration switch that I can tune when building the library. That's been said, it is still your package. And people can always change the build scripts for their own needs. Best, Xiao-Yong -- c/*__o/* <\ * (__ */\ < ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: A Levenberg-Marquardt implementation
Maurício CA writes: >> That's been said, it is still your package. And people can >> always change the build scripts for their own needs. > > Not actually! I didn't work on bindings-levmar. I'm just the guy > who started the idea of having low level bindings packages as > basis for higher level bindings (so that this kind of problem > can be solved at the same time for many, say, levmar high level > bindings). That's why I would like to help acchieving good general > guides for easy building. Wrapping of levmar is entirely van Dijk > brothers' work. Sorry, I didn't mean that. I was just trying to say that it might be wiser to put in a configure script like most of the open source software do. It does not need to be very complicated, because usually people know what they are doing when they want to link against different optimized libraries. The one[1] provided by hmatrix[2] is sufficient and easy to use for most of the purposes. [1] http://perception.inf.um.es/cgi-bin/darcsweb.cgi?r=hmatrix;a=headblob;f=/configure.hs [2] http://www.hmatrix.googlepages.com/ In the case of hmatrix, it is good that you only need to run $ cabal install hmatrix -fmkl to build it against Intel mkl instead of the default BLAS/LAPACK. And you can also add other shared libraries to link against as a command line switch when you run `cabal install'. I just don't see the problem with bindings-levmar. Because compared with bindings-levmar, hmatrix actually needs GSL, BLAS and LAPACK, but it builds fine on hackage and the documents[3] are very well built. [3] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hmatrix Just my 2 cents. Xiao-Yong -- c/*__o/* <\ * (__ */\ < ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
