On 03/01/2013 03:09 PM, Sebastian Kuzminsky wrote: > This message is for anyone who cares one way or another if redis is > included in the linuxcnc git repo. > > The redis database was recently forked and a copy placed into the > linuxcnc master branch. This is wrong from fundamental principles, and > also causes practical problems (the build system has been broken from > the beginning). Redis is currently not used by any code in linuxcnc. > > The proper way to integrate redis with linuxcnc is to supply it through > an external package, backporting redis to older linuxcnc platforms if > needed. (We've done this with a couple of external packages already, > the process works well.) > > In a recent discussion between me, Chris Radek, and Michael Haberler on > #linuxcnc-devel we agreed to remove it from our repo. > > To this end, i am planning to remove redis from the linuxcnc repo soon. > Does anyone mind? Does anyone have any input before I go ahead with > this? I will act early next week unless i hear opposition. > >
Will a linuxcnc/redis still be available after this? I was hoping to use the tool change / tool information aspects. This announcement does not explain what redis was for, and so does not touch on what is being lost. Is there a proposed replacement for these features? mha explained purpose/intent of redis """ let me clarifiy what I intend to use redis for, and where it fits in the overall picture IMV; also with the intent to avoid disappointment: I plan to use it as a name space for state which are to be shared between different parts/processes of LinuxCNC. What is currently lacking in communication between different components is: - there is a lot of state in task and the interpreter which does not fit into the current HAL and NML framework, and there is no way to access it in an extensible fashion - some areas of LinuxCNC are severly limited in options by not having a way to access/modify this state while still retaining the option of running UI's on a different machine than the RT control part - which I think is a good design decision and should be retained, even if not used much now - the state seen/exported by task and interpreter is currently fixed at compile time, despite the fact that we have now an embedded Python capability which makes access to internal state very easy, and HAL does not help here much either. - a good example for the type of problem the redis integration will help with is tool information handling. Currently tool information is quite limited and not extensible with new properties (think of wear information, arbitrary changer arrangements etc). This kind of state is not realtime in nature, but should be extensible, by the user/integrator. - the way this information typically will be handled is event-driven: some part of LinuxCNC change some part of state *when it's relevant*, but the redis DB doesnt necessarily track state in other components like HAL immediately shares variables between userland components and kernel modules. However, redis would work over TCP just alike; even if one extended HAL that wouldnt help with networked configurations. While redis is very fast, keep in mind it isnt shared memory. - Michael """ regards TomP tjtr33 ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
