# Your branch is behind 'origin/master' by 11647 commits, and can be fast-forwarded.
boy, you don't pay attention to linux kernel development for a few months, and look what happens!
cradek_ is now known as cradek
9677 files changed, 849009 insertions(+), 467919 deletions(-)
psha: what's up?
[19:30:40] <psha> http://psha.org.ru/cgit/psha/emc2.git/commit/?h=gladevcp-axis&id=5c6d9f60993c82f2b71c4f11cc94f1296f7e57ad
this allows usage of gladevcp panels just where pyvcp one is living
in proper layer so it's under error messages and not over them :)
psha: if the user specifies both panels in inifile it'll load both and display just one
or did I Miss something?
i think it'll load both and display both
have to test though
no, they're both gridded at the same location
if vcp and gladevcp: complain loudly
# ^^^ because this is a stupid configuration that we don't want to try to support
it's a vlaid ppoint:
jepler: correct, but it may be easily fixed with replacing column=4 to column=5 in gladevcp
psha: quite liekyl
ow my typing
sorry, had some keyboard issues
how it's better to notify user about both pyvcp/gladevcp?
die with error message to console or something else?
Anything would be better than the current pyvcp behaviour, where it just dies with no hint what the problem is.
when does it die?
i think if something is bad in .xml file
psha: I'm trying to decide whether it's better to allow both, even though I think no sensible user would ever uave both
jepler: i see at least one use case - migration
andypugh: not even a python traceback when starting emc on the terminal?
Yes, anything bad in the XML file and emc quits without clue. After a while you learn that quits without an error message are xml problems, so there is a clue-by-omission there.
jepler: If I recall correctly, no. I might be misremebering, it's been a while.
psha: fine, unless it makes a miscolored 1-pixel strip or something else that we identify as a problem, grid the gladevcp in the next column and call it good
andypugh: ugh, I didn't realize that. somebody should figure out and do something (looks like I did at least once, back at 4c1c10)
[19:54:36] <psha> http://psha.org.ru/cgit/psha/emc2.git/commit/?h=gladevcp-axis&id=de9df2a905541ea4a20f26f6eb42be30f46f21ca
It might already be fixed then, or perhaps at the time I wasn't adept enough at checking error logs.
i think no extra pixel line is added
as i may see
but even if it's there it's impossible to see it - panels have 4px padding ;)
Let me see what is involved in making a deliberately broken test.
psha: hmmm this makes me realize something
we only loaded a gladevcp if hal_preset == 1
if hal_present (which I think originates from the environment) is false, axis isn't supposed to do anything hal-related
correct, i've lost it
i think then all dynamic tab blocks has to be wrapped?
you'll tell me: no, a camview tab doesn't do anything hal-related
i think it's ok not to load dynamic tabs whe hal is not present
what are use cases of no-HAL axis?
psha: two reasons. first, the mythical use of NML over the network so that AXIS runs on a different system than the realtime software. second, for development so that you can start axis multiple times within a single emc session
i think then it's better to wait for tabs only when hal_present=1
if not present - no waiting
non hal tabs will work, hal - wont
the point in waiting is to run the postgui halfile, but that shouldn't be run in the case of !hal_present
yes, and postgui is executed after waiting
so no waiting - no postgui halfile
I see that postgui_halfile was run regardless of hal_present
yes, i've missed that point
no, I mean before any of your changes
[20:07:11] <psha> http://psha.org.ru/cgit/psha/emc2.git/commit/?h=gladevcp-axis&id=882d51336824e331949f2f3ecd9fa86566dbbaf3
something like this
wait for childs _and_ execute postgui only when hal_present=1
[20:09:25] <psha> http://psha.org.ru/cgit/psha/emc2.git/commit/?h=gladevcp-axis&id=2f18e6
this one is better - it deiconifies axis window if hal not present )
I withdraw my statement about pyvcp quitting without an error message. Either it has been fixed, or I was just wrong.
psha: better all the time
andypugh: thanks for checking that!
jepler: man pages are added by hand?
psha: except for .comp files, manpages are written by hand
psha: if that doesn't answer the question you were asking, please try asking a slightly different question
i've just merged mhaberler's manpage for gladevcp and just was curious if it's correct way :)
so it's anwsered my question
i think i'm ready for merge now
running last tests to ensure i've not broke something on merge ;)
andypugh: I took a look at the code for gearchange.comp (your message dated 2 Dec 2010) and I don't spot any glaring errors. You think it's ready for incorporation in master? Is there a later version?
The version on my drive was last edited on the 3rd.
I wonder what changed?
the 2 Dec mail was about the comp bug with parameters with personality that you discovered
I would not be surprised if you were just looking for a workaround for it?
The one that got fixed elsewhere?
yes, it was a bug in comp and I fixed it.
There is a very subtle change, I changed the line-wrap on the pin desciriptions to honour the 80 column width
There were no functional changes
send me that version, then? firstname.lastname@example.org
jepler: take a look at 'gladevcp' branch when you have a minute
i think it's ready
axis integration and some persistence cleanups
I wonder if there is a way to make hal components polymorphic? It would be very nice if the mux2, mux4 components could adapt to the attached signals.
I doubt it could be done in a way whch would let you run them in a base thread, though.
andypugh: i guess it's hard since pins are created before they are connected
you either need to create many pins or create many components - mux2b, mux2f, ...
You can create pins on-demand depending on the declaration modparam, but you are right that it is too late once you start wiring the signals.
There are some curious quirks, such as mux2 being float and sample_hold being s32. (you can use mux2 as a float sample-hold, but not vice-versa)
andypugh: I just use the logic comp - (needed a 3 input and gate) and after figuring out the incantation - it worked great!
jepler: i have to go now, so if you think 'gladevcp' branch is fine - please merge it
i'll check in the morning
if something is not ok - just write here, i'll check logs
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-12-20.txt
at least now logger is up :)
andypugh: a non-'comp' component could take the type of pins to create as a module parameter..
Not allowing duplicate names is a comp thing not a hal thing, isn't it?
And default pehaviour could remain the same.
I ought to make this 8i20 driver stop bricking the drives first though.
EMC: 03jepler 07master * r2edf1a912721 10/ (lib/python/gladevcp/xembed.py src/hal/user_comps/gladevcp.py): gladevcp: Reorder initialization/cleanup code
andypugh: not allowing a pin and a parameter to have the same name is a comp thing
EMC: 03jepler 07master * r954d9488b6ea 10/ (3 files in 3 dirs): gladevcp: Keyboard events forwardind (axis)
EMC: 03jepler 07master * r2ce59e65125f 10/src/emc/usr_intf/axis/scripts/axis.py: axis: Execute POSTGUI_HALFILE after all child processes
EMC: 03jepler 07master * r90624f8d6d96 10/lib/python/gladevcp/persistence.py: gladevcp: persistence.py simplified
EMC: 03jepler 07master * rb851c0e7f8c7 10/configs/gladevcp/ (7 files in 4 dirs): gladevcp: Move configs to simplified presistence
EMC: 03jepler 07master * r2f18e6930067 10/src/emc/usr_intf/axis/scripts/axis.py: gladevcp: Use gladevcp in same place where PyVCP live
not allowing two pins or two parameters to have the same name is a hal thing
EMC: 03jepler 07master * rcdac8820809e 10/ (9 files in 6 dirs): Merge branch 'gladevcp-axis', remote branch 'void/gladevcp-persistence-simplified2' into gladevcp
EMC: 03jepler 07master * r40a18779d76f 10/docs/man/man1/gladevcp.1: gladevcp: add man page
EMC: 03jepler 07master * rfb748fed714c 10/lib/python/gladevcp/xembed.py: gladevcp: Change XEmbed order
psha, mhaberler: thanks, I didn't spot any problems.
psha is off for today. I gave it a spin as well and didnt see anything suspicious.
jepler: I fear we have missed the python-configobj dependency in debian/control.in
sorry about that