Decentralized mirror multiple repositories

From a long a go I am try to find how to synchronize the contents of, at least two, code repositories. After some tries with software not design to do it, I was illuminated to one correct.

But after know the program who is able to do it, the other point is to know how to say to the program what you want to do. Now I know a little and I write an small howto for one of the usages I want.

One reason for this tool is when I have two repositories where I like to save the sources or when you like to develop for somewhere you only have read access.

In the second case, when you are developing something for a free software project who have a public repository, this repository is only read access for you. Then you should have your repository somewhere else. But a feature to synchronize with the updates on the main branch are need. It's like to have a branch in a different place and you like to have a merge possibility.

The other case is when we have an internal repository, a working copy, and at some point of the development you want to publish something in a public repository.

Many more things can be done with svk, I will check and if I can I will document it.

Dynamic multiple inheritance (II)

It works. We are using multiple inheritance and also we change dynamically on one macro, one of its inheritance to adapt to the concrete measurement.

More understandable code that A and B classes should be:

class _ltb:
····def __init__(self):
········print "__init__ 4 __ltb"
····def mesh(self):
········print "do a mesh scan"

class _energy(_ltb):
····def showResults(self):
········print "Energy results"

class _emittance(_ltb):
····def showResults(self):
········print "Emittance results"

class ltb_energy(_energy):
····def run(self):
········self.mesh()
········self.showResults()

class ltb_emittance(_emittance):
····def run(self):
········self.mesh()
········self.showResults()

class ltb_offline:
····def run(self,operation):
········if operation == "energy":
············self.__class__.__bases__ = (_energy,)
········elif operation == "emittance":
············self.__class__.__bases__ = (_emittance,)
········self.mesh()
········self.showResults()

In the implementation, there is also multi-inheritance because the ltb_{energy,emittance,offline} also inherit from Macro (a class of the MacroServer).

The sources of the Sardana project are in sourceforge. This macros are not already uploaded to the tango-ds svn. It needs a little bit more test, and probabli next week we will publish it.

Nota: in the implementation, the classes ltb_{energy,emittance,offline} has another primary inheritance from Macro. But the classes _energy and _emittance cannot inherite from Macro, because are not macros itself, but uses method of this superclass.

Dynamic multiple inheritance

I am having a little problem with the offline measurement on the linac. My task in the linac is to produce an application to measure the electron beam energy and emittance. A long a go, we start to document it on the Alba's site.

The idea of the offline measurement was on means of all, but not so clear because we did some offline with data from other synchrotrons. But now we like to repeat the measurements we already did with our linac. Always when a measurement had been launch we store the images. Then the offline is to reload the images and deceive the system like this is real.

Problems about we didn't take care before are, for example, the magnets doesn't move precisselly to the ordered position; there is a threshold on that. And when the fit will be repeated offline we have to use the old magnet values, not the dummy motors how we use to simulate that.

Then something specific has to be programed to do this. We had macros to do the online measurements and they are not usable to load data from an old session for the offline measurement. Ok, then we need a new macro:


But, the offline macro needs to be the same to simulate energy or emittance. Then the inheritance, apart to be multiple, has to be dynamically changed...

Why not an instance? Why not all the macros only inherit from 'Macro' and has an instance of __energy or __emittance? Because the three on top right uses methods from the 'Macro' class.

class A:
def method(self):
print "A"
def methodA(self):
print "AA"

class B:
def method(self):
print "B"
def methodB(self):
print "BB"

class C:
def setA(self):
self.__class__.__bases__ = (A,)
def setB(self):
self.__class__.__bases__ = (B,)
def setAB(self):
self.__class__.__bases__ = (A,B)
def setBA(self):
self.__class__.__bases__ = (B,A)

Ok, then what can be done is:
c = C()

c has 4 methods: {c.setA(),c.setB(),c.setAB(),c.setBA}

c.setA()
now has 2 methods more {c.setA(),c.setB(),c.setAB(),c.setBA,c.method(),c.methodA()}

with a call c.setB() the list of methods changes to {c.setA(),c.setB(),c.setAB(),c.setBA,c.method(),c.methodB()}

c.setAB()
now the list of methods is
{c.setA(),c.setB(),c.setAB(),c.setBA,c.method(),c.methodA(),c.methodB()}
and notice the call c.method() uses the one from A.

with c.setBA()
the list is the same, but now the c.method() uses the one from B.

Actualization: Be careful if you use multiple objects using this. If we have multiple instances, the modification affects all of them:
c1 = C()
c2 = C()
c1.setA()
c1.method()
A
c2.setB()
c2.method()
B
c1.method()
B

OpenMoko is moving

Finally I see some movement on Openmoko to say that is trying. I don't have the device but I have it running in qemu as I wrote a long ago.

Some (sub)communities starts movements creating contents with more proximity to the potential clients. Many of us are convinced to support Openmoko because we support free software on our bones, but the world is full of people who doesn't care about that and other techniques are need.

For example this case of an spanish community who are writing a wiki from a non technical point of view, more in a propagandistic way to be proximus to the final user.

Thanks the communities and feel free!