On 8/15/2012 7:13 PM, Michael Haberler wrote: > Am 16.08.2012 um 00:12 schrieb Daniel Rogge: > >> >Michael, >> > >> >I appreciate your analysis. I hadn't given much thought to the potential >> >race condition between the interpreter and the parameters, nor had I really >> >considered preventing access to parameters that didn't make much sense to >> >access (e.g. #5399). I worked on this in the hope of using parameters in a >> >currently unused range (>5600) to store persistent machine settings similar >> >to the preferences.py implementation used by Chris in Touchy. I had not >> >considered, for instance, using this to display all the G5x work offsets on >> >one screen as suggested by Chris on IRC earlier today. The contents of >> >that patch work for my current need, but if people feel that the code >> >should prevent access to nonsensical or interpreter-sensitive parameters >> >then I'm happy to put in the extra effort to make something useful for the >> >community. >> > >>> >>As for persistent parameters (stored in emc.var) I think the eventual >>> >>solution is to have the persistent parameters in a Redis store and make >>> >>the >interpreter query/set it as needed; this store then can be >>> >>queried/set by other processes as well. single location, no consistency >>> >>issues. >> > >> >I'm all for it. > ok, let me restate the use case: > > - there shall be a class of persistent parameters which serve interaction > with UI's (not necessarily limited to numbered params) > - these params shall be accessible by arbitrary processes > - setting a parameter updates the interpreter's current view of the param > - getting a parameter retrieves the params current view > > is that it? (btw I think it is useful). > is this for master? > > If so, I have an alternative proposal. I would like to take the opportunity > to solve this through redis, with the intent of warming up folks to the > actual use of redis instead of me just musing about it. > > this will involve a new package dependency (redis-server) and the hiredis and > redis-py C and Python bindings, and a bit of configure support so we have a > conditional dependency on redis etc availability. > > -- > > It will also mean that if redis is used, emc.var contents will live in the > redis store (a file), a redis shell client is available. > > I'm happy to work with you on that, but I would hesitate to merge this patch > - it's going down the wrong lane (just look at the contortions you needed to > do to get a*single* remote procedure call done, and we're not moving any > closer to clean distributed state management; not your fault, NML is next to > useless for the job). > > to get an idea how this could pan out, have a look > athttp://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/redis-iocontrol > - I created this as a simple example to store the current tool table in > redis, and show how UI's could work with it (read only). And to sell jepler > on the idea;) The relevant part is the patch to iocontrol-v2. > > -Michael >
<I deleted the earlier exchanges> Michael: I think your alternative proposal is great. I hope you proceed irrespective of any decision about the proposed extension to emcmodule.cc. When you introduced the idea of redis "or something like it" last fall I was too wrapped up in my wife's ongoing difficulties to pay attention, but looking back on your messages now I think it would make a great addition to LinuxCNC. I'd be carrying coals to Newcastle to tell you how convenient it is to be able, at run time, to define, stash, and retrieve data in such an accessible container. In the past you've alluded to the fact that LinuxCNC would actually need to use little of the growing redis API. My first thought was, we (that's the editorial "we", meaning someone very much like you) could implement the few needed capabilities. They aren't much different from what we were doing in a pub/sub project I was working on in the early part of this century. Then I got real. Why spend any time/effort at all to reimplement and test what is already available under a *very* liberal open-source license. We've got other problems to solve. Given the terms of the redis license, we could use either of the schemes you outlined (Ubuntu package manager or git) unless/until either the redis project dies or its further development is taken under wraps by VMware, at which time we could simply distribute the last publicly available source package as part of our source distribution (with proper attribution, of course). Since the Ubuntu package manager currently offers "redis 2:1.2" and early versions of its language bindings, I downloaded the redis 2.4.6 server/client software directly from the project site this afternoon to play with (my testcase is a simplified bit of the pub/sub project I mentioned). Compared to the LinuxCNC distribution, it took no time at all to build on my machine. I'll try your tool-table example later. Regards, Kent PS - I know it doesn't matter in the great scheme of things, but it would be nice if we could wean ourselves from automatically naming the parameter file "emc.var". ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
