Chris raised an important question privately, and I asked if I could reply publically.
> Hi Michael > > I have been toying with the idea of converting gladeVCP to GTK3. > but after reading your plans I wonder if building a new style that uses > messaging would be better time spent. > I am a little worried it's above my pay grade but I could say that about > everything I have done so far in linuxcnc. :) > > Since HAL doesn't have messaging capability yet, what about a two program > system one realtime with HAL pins and one userlevel with GTK3 ? > hmm I guess this is how it will work anyways... > > What messaging system are you thinking of at this time? I can't remeber the > name.. > Any other comments / ideas? > > I'm just thinking the idea at the moment. > > Chris M let me summarize the question as 'how does this newfangled HAL messaging stuff impact my current work with GladeVCP and HAL access'? That is very valid point. HAL-based UI's assume shared memory between UI and the realtime layer. We drop the shared memory paradigm - so where does that leave those UI's? do we have to rewrite all those UI's do deal with Haberler's messaging fad? I hope not, and this is how I envisage it to work out (I am concentrating on GladeVCP and HAL widgets for the moment; Action widgets are fairly similar to deal with, and motion commands too). I will do a small excursion to HAL widget intestines and 'come back up the stack' to actually answer the question. --- How do HAL widgets retrieve and set pin values, and get notifications - like the hal-pin-changed signal - in the current code? Like everything in HAL, it works by polling HAL values, and it is all encapsulated in 176 lines of Python, in lib/python/hal_glib.py, thanks to Pavel's great design skills. The relevant method is 'update()' in the GPin object (and in GStat for Action support). It is currently called 10 times per second, I think. So let's assume we yank the Python hal component as it stands now, and replace it by HAL messaging (I dont exclude messaging can be included in the hal Python component, I'm just not assuming that for now to make the point): What changes is: 1. how a HAL component is created - check if comp exists, yell if it does etc. 2. how a pin is created - checking if the name exists, tell HAL to create a pin of a certain type and direction. 3. how the current pin value is is read 4. how a pin value is set 5. how notification of pin value change is processed. Now going through the list in turn: 1,2 and 4 are going to be a HAL messsaging RPC (remote procedure call) operation into machinekit. 3 could be the same, but see below. 5 could be based on 3. So instead of accessing methods in Python 'hal', it will ask machinekit for operations which look like a function call at the using level. See footnote how such an RPC could look in Python _in principle_. The lowest level machinekit API will look rather similar. So 'all that is to be done' is replacing one function call by another, and if we're lucky it is all contained in hal_glib.py. That code could actually autodetect or ask for configuration information if running 'locally' (shared memory access) or remote (HAL messaging). Is that going to work? Yes. Is it going to work fast? Not yet. The update network traffic of constant polling for changed values will be considerable, and given the above, will scale linearly with the number of HAL widgets. This can be fixed with a slight twist in the API - by replacing polling through change notifications. Instead of constantly polling for the current value just to detect a change, the HAL messaging API will provide a way to express 'please notify me if the value of pin X changes'. The machinekit server will do that change detection for all clients, and all pins with expressed update interest. It will notify the client by a message if a pin changes. This message will hook into the GPin update method, and cause a UI display update. In essence the clients declare interest in a certain object, and the server will notify of updates. That is exactly what the publish/subscribe interaction model is about, regardless whether it'd be HAL pins or stock quotes. So we need a messaging layer which supports RPC and publish/subscribe. This removes the network traffic of constantly polling for changed values; so in effect we have network traffic only when setting a pin from the GUI, or when a pin we declared interest in changes value. Note that the change detection code in the machinekit backend is completely generic - it need not be aware of any specific machine configuration, just of the list of 'interesting pins', and the clients will declare that interest in the startup phase. The only client-specific parameters I could conceive are: a) an epsilon value for HAL float change detection, b) a change detect timer value, but that's conceptually not different from the local case. ---- coming back up the stack to actually answer the question: I dont think it is necessary, or desirable, to change the UI programming paradigm at all as far as HAL/GladeVCP goes. In fact I think the changes can be contained to a single Python file, and they can be made such that the using code sees no difference whether shared memory mode or messaging mode is used. I still hope I can drag Pavel into advising us on this, but it seems he's currently busy with family enlargement work;) - Michael --- [1] a 'hello world' example for a remote procedure call, which uses zeromq and protocol buffers behind the scenes - I hope this makes the point for reusing existing code: http://code.google.com/p/rpcz/source/browse/examples/python/example_client.py Behind the scenes, message contents are described like so: http://code.google.com/p/rpcz/source/browse/examples/common/search.proto - note that at the using level you will _not_ have to deal with these message descriptions. ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
