Hi guys, I have been playing with the sat solver motivated by being able to use it from ruby scripts or rails apps, and also to familiarize myself with the internals I have in my local git a patch that adds the following: (~dmacvicar/sat-ruby-cmake.diff) - beatiful ruby bindings (and 99% of the stuff needed to have perl, python, java, etc) - cmake build support The bindings look like this right now: require 'satsolver' include Satsolver pool = Pool.new f = File.open('../../testsuite/data.libzypp/basic-exercises/exercise-20-packages.solv', 'r') s = pool.add_source_solv(f, 'foo') f = File.open('../../testsuite/data.libzypp/basic-exercises/exercise-20-system.solv', 'r') installed = pool.add_source_solv(f, 'system') pool.each_source do |repo| puts repo.name end s.each_solvable do |r| puts "#{r.name}" end q = Queue.new puts q.empty? r = pool.select_solvable(s, 'gnome-desktop') puts r.name # push one command and one resolvable to the queue q.push(SOLVER_INSTALL_SOLVABLE) q.push(r) pool.prepare pool.promoteepoch = true solv = Solver.new(pool, installed) solv.fixsystem = 0 solv.updatesystem = 0 solv.allowdowngrade = 0 solv.allowuninstall = 0 solv.noupdateprovide = 0 # solve the queue solv.solve(q) solv.print_decisions As you can see, lot of the not-nice-things of the current API are hidden, so humans can use it. For example: - Queue push automatically knows if you are passing a command or a solvable, and does that offset calculation by itself - iterations of pool solvables or pool sources made easy with ruby each - Convertion of ruby File to C FILE* What is missing in the bindings part: - translation of attributes like name from Id to string in a transparent way (the fact that the conversion function needs a pool is my limiting factor right now) - fixing of attributes names to follow ruby conventions. What can be enhanced in the C api: - choose conventions. Come on, this is not something technical, just some discipline that helps people. I dont think having one method called pool_something and then other called queuesomething makes sense except to annoy.. The convention class_action( class*, args ) is pretty standard in C OO code. Use it, but don't mix or you make people have to read the code to guess method names. - Source name. It was very difficult to standarze the name in libzypp, product management and other products to repositories. Calling it Source is going back to 10.2 and introduce more confusion. The official word is repo now, why not use it? - there is a bug when you add a empty system repo to the solver, it segfaults. - I had some trouble wth the bool stuff (typedef _Bool bool) and swig For the cmake part: - It supports out of source tree build by definition, and this is nice if you are using git - it does everything, except if I am missing some coolo's requirement needed to run the testsuite. - it supports packaging, and check svn if there are uncommited stuff before packaging - the ruby bindings require the cmake build. It took me 5 minutes to do everything wth cmake, but 20 minutes looking for autocrap swig macros. - I havent tested building the package and spec, but it is there. I have no problem to maintain the cmake part (even in paralell), unless everyone loves it and it can be made the default. it is ok to commit it? Cheers Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org