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?)
- Michael
---
While we are housecleaning: lintini needs a makeover:
lintini gladevcp+hal.ini
Traceback (most recent call last):
File "/home/mah/emc2-test/bin/lintini", line 41, in <module>
period = get_int("EMCMOT", "BASE_PERIOD")
File "/home/mah/emc2-test/bin/lintini", line 37, in get_int
return int(ini.find(section, key).split()[0])
AttributeError: 'NoneType' object has no attribute 'split'
NB: EMCMOT isnt used anymore.
> Regards,
> Kent
>
>
> ------------------------------------------------------------------------------
> 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
------------------------------------------------------------------------------
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
