[zypp-devel] sat solver enhancements and questions
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
* Duncan Mac-Vicar Prett
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
Cool ! Thanks ! And a nice API. A couple of extensions/enhancements here and there and its going to be beautiful ;-)
q = Queue.new puts q.empty? r = pool.select_solvable(s, 'gnome-desktop')
What does 'select' mean ? This looks more like a 'find' or 'get' to me. [...]
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)
Since in 99.9% of all cases, one operates with a single pool (its just a collection of repos anyway), the pool should be made implicit.
- 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.
Just go ahead and do the fixes, I'd say !
- 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?
+1 vote from me !
- 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
[...]
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?
Go ahead ! I added autocrap just because it was easy (for me) and my cmake experience is next to zero. Klaus -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
ok I just commited everything, and I got the solver results iterators working: solv.solve(q) solv.each_to_install do |i| puts "to install #{i}" end solv.each_to_remove do |i| puts "to remove #{i}" end Michael (matz), with your sugestion about the queue api? how should it look like? Do you mean replace: q.push(SOLVER_INSTALL_SOLVABLE) q.push(r) with q.push_install(r), or q.push(r, :install) or? Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
* Duncan Mac-Vicar Prett
ok I just commited everything, and I got the solver results iterators working:
solv.solve(q)
solv.each_to_install do |i| puts "to install #{i}" end
solv.each_to_remove do |i| puts "to remove #{i}" end
I wonder if the transaction (input), the result (output) and the solver (function) shouldn't be separate. Something like result = solver.solve( transaction ) and then result.each ... result.install.each ... result.update.each ... result.remove.each ...
Michael (matz), with your sugestion about the queue api? how should it look like? Do you mean replace:
q.push(SOLVER_INSTALL_SOLVABLE) q.push(r)
with q.push_install(r), or q.push(r, :install) or?
I'd prefer to hide the queue from the API and have a 'transaction' object with named transactional methods: transaction.install( r ) transaction.install_name( "foo" ) transaction.require( "libfoo.so" ) Bottom line: The API should represent the solver semantics, not its implementation. Klaus -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Hi Duncan, On Fri, 26 Oct 2007, Duncan Mac-Vicar Prett wrote: That's nice :-)
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)
I would add an interface taking a (command,argument) pair, instead of exposing the command queue as real queue.
pool.prepare pool.promoteepoch = true
And I think pool.prepare should just be done implicitely by either constructing a solver, or as part of calling .solve(). I.e. it can use even some more API beatification :)
- I had some trouble wth the bool stuff (typedef _Bool bool) and swig
Which ones? Does swig perhaps not support the C99 _Bool type?
For the cmake part:
Blaeh :-)
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?
I don't see why not. Ciao, Michael. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
participants (3)
-
Duncan Mac-Vicar Prett
-
Klaus Kaempf
-
Michael Matz