On Sun, 26 Aug 2012 08:22:01 +0200, Michael Haberler wrote: > Am 26.08.2012 um 07:24 schrieb Kent A. Reed: > >> On 8/26/2012 1:11 AM, Michael Haberler wrote: >>> Am 26.08.2012 um 06:32 schrieb Michael Haberler: >>> >>>> Am 26.08.2012 um 01:11 schrieb Chris Morley: >>>> >>>>> >>>>>> 3. ALL guis, not just Axis, need to eventually learn how to >>>>>> start a POSTGUI_HALFILE if there is any chance itself or a >>>>>> subprocess creates additional HAL objects. To do so, they need to >>>>>> understand that they are the primary UI component. This suggests a >>>>>> per-ui command line flag like '--primary-ui'. >>>>> >>>>> AXIS, TOUCHY and The future Gscreen all understand POST_GUI. >>>>> TOUCHY requires a touchy.hal file though. >>>>> It would be nice if linuxcncTK could be retrofitted with POSTGUI >>>>> and at least PYVCP panels. >>>>> but TCL is not my bag.... >>>> I think by now the whole POSTGUI_HALFILE thing was a kludge. The >>>> linuxcnc.in assumption is: shutdown happens when the UI program >>>> exits, so just block on the UI program, and run cleanup thereafter. >>>> >>>> It would be much easier and uniform if: >>>> 1. linuxcnc.in just starts the UI in the background and records >>>> its pid >>>> 2. linuxcnc.in waits for the UI to be fully set up (all HAL >>>> comps/pins created and ready) >>>> 3. linuxcnc.in runs any POSTGUI type jobs. >>>> 4. when done, it explicitly waits for the UI pid. >>>> >>>> 1,3,4: easy >>>> 2: I'm taking suggestions - one cant tell in advance which >>>> halcomps are set up behind the UI, so you cant test for them being >>>> ready easily; also halcmd is less than helpful wrt exit status: say >>>> 'halcmd show comp axis' always reports exit status 0 even if comp >>>> axis doesnt exist. >>>> >>>> Maybe somebody has a simple idea in his bag of shell tricks how a >>>> process can notify the parent shell that some step is complete. >>> Well, stackoverflow.com came to the rescue, see >>> http://serverfault.com/questions/37796/how-to-export-vars-from-a-subshell-to-a-parent-shell/373307#373307 >>> >>> this could work as follows: >>> >>> - linuxcnc.in exports a, say "NOTIFY" environment variable which >>> the UI can access with getenv("NOTIFY"). Contents are irrelevant. >>> - linuxcnc.in starts the UI in the background and records its pid. >>> - if the UI sees the NOTIFY env variable, it shall: >>> -- create a fifo in the current directory with 'mknod >>> notifiy.${pid} p' in the current directory >>> -- when done with HAL setup, run a subshell like so 'echo DONE' > >>> notfiy.${pid} &' which wont block, or 'FAIL' or something if it >>> failed to start properly. >>> - linuxcnc.in tests for a while if notifiy.${pid-of-UI} appears in >>> the current directory. >>> - if doesnt after say 5 seconds, and the UI process still runs, >>> this means the UI doesnt support this notification convention, so say >>> so and continue. >>> - if the UI process vanished, say so and shut down. >>> - if the pipe appeared, read it with: RESULT=`cat >>> notifiy.${pid-of-UI}` >>> -- if RESULT=='DONE', go ahead and run any POSTGUI type jobs. >>> -- if RESULT== 'FAIL', say so and shutdown. >>> -- reading will make the 'echo DONE > notfiy.${pid} &' process >>> (started by the UI) terminate >>> -- the fifo can be unlinked after reading. >>> >>> this needs a bit of modification to each UI, but it's simple and >>> the per-UI POSTGUI handling code can head for deprecation. I think >>> it's more general, too; a UI being healthy and ready is more >>> interesting as status report than teaching it some POSTGUI_HALFILE >>> execution trick. >>> >>> for regularity, really there should be a section [POSTGUI_HAL] >>> which works exactly like the HAL section, just run after the UI is >>> ready. >>> >>> this is a change which will affect documentation and ini files. >>> Opinions? >>> >>> - Michael >>> >> >> That's a clever way to pass a message. >> >> I would think the big questions for many would be >> >> 1) does this break existing configurations? (Maybe not, but it's too >> late at night for me to be sure) >> >> and if so >> >> 2) can we automate the configuration-upgrade process to easy >> people's >> pain/anxiety about changing something that is working for them. > > The logic is a bit tricky, but I think it can be done. I assume the > UI's wont all be upgraded in one go, and linuxcnc.in gets upgraded > first, then the UI's in a piecemeal fashion. > > We have the following cases: > > - the UI takes a POSTGUI_HALFILE option, but has not been upgraded to > speak the notification protocol. Detectable in linuxcnc.in by looking > for [HAL]POSTGUI_HALFILE as well as the DISPLAY= command name > contents > (contains axis, gladevcp, touchy..). > - the UI supports the notification protocol outlined above. The UI > can detect whether it is running an old-style config file by looking > for [HAL]POSTGUI_HALFILE and suggest to the user to upgrade the > config > file. linuxcnc.in can detect that by searching for the fifo for a > while. > - the config file is 'old style', i.e. has [HAL]POSTGUI_HALFILE= > lines. > - the config file is 'new style', i.e. has [POSTGUI]HALFILE= lines. > > 'Upgrading a config file' means to move all [HAL]POSTGUI_HALFILE > lines into [POSTGUI]HALFILE= lines. This can be automated. > 'Using the notification protocol' should be tried only if the config > file is 'new style' for less collateral damage. In the latter case, > one could assume the user has read up on the manual, and/or ran the > ini upgrade script. > > So we have: > > 'old style' config with [HAL]POSTGUI_HALFILE= options: > - follow existing style - just start the UI and wait for it to > finish. if the UI supports the notification protocol and finds an old > style config is used, it will suggest upgrading the config file by > running the upgrade script; there's no point in creating the fifo and > writing to it though. > > 'old style' config without any [HAL]POSTGUI_HALFILE= options: > - safe to run as above as well. Since upgrading the ini file will be > a noop, there's no point in telling the user to do so. > > 'new style' config with [POSTGUI]HALFILE= lines: > - if the UI supports notification, the fifo will appear and reading > the fifo in the parent will eventually succeed, so all is fine - > linuxcnc.in runs the [HAL]POSTGUI_HALFILE= section when it got the > 'DONE'. > > - if the UI hasnt been upgraded to support notification, the fifo > will NOT appear, so the loop testing for the fifo in linuxcnc.in will > fail. The linuxcnc.in script should tell the user she tried to use a > new-style config file with a UI which doesnt support it yet. > > I hope this covers it (does it?)
I think that covers most of it, but now you have just introduced a lot of convoluted logic. Wouldn't it be better to survey the users, collect all the 'old style' config's people are interested in, and then offer to help tweak the configs than to add all the convoluted logic for backwards compatibility? I hate to say it, but sometimes it is better to really start clean and either write an upgrade script that will automate most of the configuration changes or to manually update the old configs/code... Just sayin... EBo -- ------------------------------------------------------------------------------ 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
