After a long time without write here I like to reactivate it, but not for good news. After a long time trying to focus and speed up the synchrotron project, we had a "Drop of water that spills the glass".
https://sites.google.com/site/comitedempresacells/
This is not because of the salary cut, this is because of the management of the synchrotron how doesn't like to negotiate the progression of this cut. They said a "proposal" or a 5% cut equal for all. They said, my proposal or my (worst) second proposal, without accept any type of negotiation.
The issue is not the cut, the issue is the attitude of the management against the workers.
2008/11/25
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.
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.
2008/11/13
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.
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.
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
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:Ok, then what can be done is:
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)
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
2008/11/12
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!
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!
2008/09/19
Extremophile
After the land of the Phoenix in the Mars arctic, with the first results of the high salinity of the ground, I read some articles about the water is not the only one restriction to allow life.
In out planet we have places where the life exist under extreme conditions. This type of life we call it Extremophile. Working in a synchrotron I am curioused, specifically with the life that is able to be in extreme radiological conditions. I don't know how a bacteria can protect and repair what the radiation breaks, but what about the parasitoid wasp? Wikipedia says this complex life can support a hundred times more of radiation than the humans.
A few a go I read about the survivance in space conditions of the Tardigrade. It's impressive how this lifes can survive to the void with high radiation doses.
In out planet we have places where the life exist under extreme conditions. This type of life we call it Extremophile. Working in a synchrotron I am curioused, specifically with the life that is able to be in extreme radiological conditions. I don't know how a bacteria can protect and repair what the radiation breaks, but what about the parasitoid wasp? Wikipedia says this complex life can support a hundred times more of radiation than the humans.
A few a go I read about the survivance in space conditions of the Tardigrade. It's impressive how this lifes can survive to the void with high radiation doses.
2008/09/13
how (software) patents can bother your development
Yesterday, I receive an answer from Jivson (the author of the 'ECC in OpenPGP' internet draft) from a couple of mails discussing something about how to play with the standard to made easy some future improvements.
I'm working in an improvement of the eccGnuPG project to add the feature to reset the cryptosystem using isogeny stars like Er Rostovtsev, Anton Stolbunov propouse.
To create this isogeny stars can be usefull that they have a cofactor 2 (or at most 4, like the standards recomend) in order to have easier ways to compute a path in the stars. My surprice arribes when Jivson draws me the attention on the point that cofactor division is under a patent.
I trust on it, but I cannot find this yet. Maybe this idea with I'm working now, will be patented by someone else some day. And I can be obligated again to drop some work because an stupid patent. This is the third time that patents bother my work on elliptic curves.
This is incredible, simply unacceptable.
I'm working in an improvement of the eccGnuPG project to add the feature to reset the cryptosystem using isogeny stars like Er Rostovtsev, Anton Stolbunov propouse.
To create this isogeny stars can be usefull that they have a cofactor 2 (or at most 4, like the standards recomend) in order to have easier ways to compute a path in the stars. My surprice arribes when Jivson draws me the attention on the point that cofactor division is under a patent.
I trust on it, but I cannot find this yet. Maybe this idea with I'm working now, will be patented by someone else some day. And I can be obligated again to drop some work because an stupid patent. This is the third time that patents bother my work on elliptic curves.
This is incredible, simply unacceptable.
Subscribe to:
Posts (Atom)
