Bug? Crash when running stock Gecko configs with gmoccapy
- Bats
- Topic Author
- Offline
- Senior Member
Less
More
- Posts: 55
- Thank you received: 7
31 Oct 2019 23:18 #149318
by Bats
Bug? Crash when running stock Gecko configs with gmoccapy was created by Bats
Just a quick (quickish?) bug report. This isn't anything I need resolved - it's just something I stumbled across by accident that Rodw mentioned might be of interest over here (although the actual bug turned out to be far narrower than it initially looked, and I'm not sure how much is gmoccapy's problem).
I was playing with some of the stock configs on 2.9 (2.9.0-pre0.770.0.ga48d613fb, to be painfully specific) and discovered that - as the title may have hinted - taking the stock by_interface->parport->gecko->Gecko_540B4 (or *B3) config into stepconf and switching it from axis to gmoccapy while "Include custom PyVCP GUI panel", "Spindle speed display", and "Include connections to HAL" are selected (with no other changes) will crash with the following error (full report attached) when linuxcnc tries to start up:
Going back into stepconf and toggling the GUI from gmoccapy back to axis will again allow it to start as expected.
I tried to check whether it would happen with other stock configs, but found that - at least under by_interface->parport - most of the others either wouldn't run at all (for various reasons), or wouldn't produce .stepconf files to modify. So I don't know whether the problem is systemic, a fluke of the Gecko setup, symptomatic of something broken in this particular build, or just because I was clicking a combination of buttons that were never meant to be combined in the first place.
If there's anything else I be of help on, just ask - but, again, this isn't anything I actually have any need for.
-Bats
I was playing with some of the stock configs on 2.9 (2.9.0-pre0.770.0.ga48d613fb, to be painfully specific) and discovered that - as the title may have hinted - taking the stock by_interface->parport->gecko->Gecko_540B4 (or *B3) config into stepconf and switching it from axis to gmoccapy while "Include custom PyVCP GUI panel", "Spindle speed display", and "Include connections to HAL" are selected (with no other changes) will crash with the following error (full report attached) when linuxcnc tries to start up:
Note: Using POSIX realtime
/usr/bin/gmoccapy:325: GtkWarning: Invalid icon size 48
self.widgets.window1.show()
(gmoccapy:18207): GtkSourceView-CRITICAL **: gtk_source_language_manager_set_search_path: assertion 'lm->priv->ids == NULL' failed
pyvcp_options.hal:8: Pin 'pyvcp.spindle-speed' does not exist
18175
18203
Stopping realtime threads
Unloading hal components
Note: Using POSIX realtime
Going back into stepconf and toggling the GUI from gmoccapy back to axis will again allow it to start as expected.
I tried to check whether it would happen with other stock configs, but found that - at least under by_interface->parport - most of the others either wouldn't run at all (for various reasons), or wouldn't produce .stepconf files to modify. So I don't know whether the problem is systemic, a fluke of the Gecko setup, symptomatic of something broken in this particular build, or just because I was clicking a combination of buttons that were never meant to be combined in the first place.
If there's anything else I be of help on, just ask - but, again, this isn't anything I actually have any need for.
-Bats
Please Log in or Create an account to join the conversation.
- pl7i92
- Offline
- Platinum Member
Less
More
- Posts: 1890
- Thank you received: 356
01 Nov 2019 07:54 #149336
by pl7i92
Replied by pl7i92 on topic Bug? Crash when running stock Gecko configs with gmoccapy
hi
open up your
custom_postgui.hal
in the mashine Folder with a editor
there is a line
net xxxxxxxxxxxxxxxxxxxx pyvcp.spindle-speed
make it
# net xxxxxxxxxxxxxxxxxxxx pyvcp.spindle-speed
in the INI
[DISPLAY]
look if there is
PYVCP =
DELETE IT
and you are fine
GMOCCAPY DOES NOT ALLOW EXTERNAL SIDE Panels
open up your
custom_postgui.hal
in the mashine Folder with a editor
there is a line
net xxxxxxxxxxxxxxxxxxxx pyvcp.spindle-speed
make it
# net xxxxxxxxxxxxxxxxxxxx pyvcp.spindle-speed
in the INI
[DISPLAY]
look if there is
PYVCP =
DELETE IT
and you are fine
GMOCCAPY DOES NOT ALLOW EXTERNAL SIDE Panels
Please Log in or Create an account to join the conversation.
- newbynobi
- Offline
- Moderator
Less
More
- Posts: 2075
- Thank you received: 406
01 Nov 2019 10:17 #149343
by newbynobi
That is not exactly correct!
gmoccapy does allow side panels as well as user pannels etc, but not pyVCP panel! please use gladeVCP panel for your needs.
The mentioned pyVCP panel is not needed with gmoccaps, as the GUI brings the requiered elements from stock.
Norbert
Replied by newbynobi on topic Bug? Crash when running stock Gecko configs with gmoccapy
GMOCCAPY DOES NOT ALLOW EXTERNAL SIDE Panels
That is not exactly correct!
gmoccapy does allow side panels as well as user pannels etc, but not pyVCP panel! please use gladeVCP panel for your needs.
The mentioned pyVCP panel is not needed with gmoccaps, as the GUI brings the requiered elements from stock.
Norbert
Please Log in or Create an account to join the conversation.
- cmorley
- Offline
- Moderator
Less
More
- Posts: 7773
- Thank you received: 2055
01 Nov 2019 21:42 #149392
by cmorley
Replied by cmorley on topic Bug? Crash when running stock Gecko configs with gmoccapy
Some of the problem here (IIRC) is stepconf will check to see if there is a XML file already - if there is it doesn't overwrite it - I thought it would ask you but maybe that's pncconf.
The reason is if someone adds custom HAL code then reruns stepconf, we don't want them to lose their code.
We could add a hash code check to see if they emitted it, I suppose....
The reason is if someone adds custom HAL code then reruns stepconf, we don't want them to lose their code.
We could add a hash code check to see if they emitted it, I suppose....
Please Log in or Create an account to join the conversation.
- Bats
- Topic Author
- Offline
- Senior Member
Less
More
- Posts: 55
- Thank you received: 7
01 Nov 2019 21:56 #149394
by Bats
Sounds like something that probably should've been blocked by stepconf in the first place. But I guess some bugs never need to be fixed because there's just no one stupid enough to ever actually trigger them... (until now! *dramatic chord*)
-Bats
Because better foolproofing requires a better fool!
Replied by Bats on topic Bug? Crash when running stock Gecko configs with gmoccapy
So that would fall solidly under "buttons nature never intended to be clicked together".gmoccapy does allow side panels as well as user pannels etc, but not pyVCP panel! please use gladeVCP panel for your needs.
The mentioned pyVCP panel is not needed with gmoccaps, as the GUI brings the requiered elements from stock.
Sounds like something that probably should've been blocked by stepconf in the first place. But I guess some bugs never need to be fixed because there's just no one stupid enough to ever actually trigger them... (until now! *dramatic chord*)
-Bats
Because better foolproofing requires a better fool!
Please Log in or Create an account to join the conversation.
- cmorley
- Offline
- Moderator
Less
More
- Posts: 7773
- Thank you received: 2055
01 Nov 2019 22:02 #149395
by cmorley
Replied by cmorley on topic Bug? Crash when running stock Gecko configs with gmoccapy
Naaw - it's just configuration programs don;t get a lot of testing until users use them.
Developers tend not to use the programs.
Chris
Developers tend not to use the programs.
Chris
Please Log in or Create an account to join the conversation.
- tommylight
- Away
- Moderator
Less
More
- Posts: 19410
- Thank you received: 6507
01 Nov 2019 22:44 #149396
by tommylight
I do remember another one i read somewhere:
Nothing is fool proof to a talented fool!
Replied by tommylight on topic Bug? Crash when running stock Gecko configs with gmoccapy
LOL-Bats
Because better foolproofing requires a better fool!
I do remember another one i read somewhere:
Nothing is fool proof to a talented fool!
Please Log in or Create an account to join the conversation.
- Bats
- Topic Author
- Offline
- Senior Member
Less
More
- Posts: 55
- Thank you received: 7
01 Nov 2019 22:46 #149397
by Bats
My initial thinking (which is, of course, where many of my best mistakes get their start) was that checking "Use Gmoccapy Screen" could just disable the "Include custom PyVCP Gui panel" checkbox & all its suboptions - which would solve my accidental use case and keep people from breaking a stock config by adding new panels known to be incompatible, but wouldn't do anything for the (presumably significant?) number of people working from less stock-y configs.
Unfortunately I don't think I understand enough of any of the nuts & bolts to suggest a more generalized solution.
-Bats
(ok, to be fair, I may not understand enough of the basics either)
Replied by Bats on topic Bug? Crash when running stock Gecko configs with gmoccapy
It looks like it does ask, at least under some circumstances (unless I'm looking at a different operation). Selecting "Blank program" when modifying a config with the spindle speed panel already present from a prior run gives an "Ok to replace existing custom pyvcp panel file?" popup (which then renames it to custompanel_backup.xml).Some of the problem here (IIRC) is stepconf will check to see if there is a XML file already - if there is it doesn't overwrite it - I thought it would ask you but maybe that's pncconf.
...which would probably increase the number of obscenities howled at a cold and uncaring sky by a non-trivial amount - although the various "If you make changes to this file, they will be overwritten when you run stepconf again" warnings have left me afraid to run it on anything I've manually modified anyhow.The reason is if someone adds custom HAL code then reruns stepconf, we don't want them to lose their code.
My initial thinking (which is, of course, where many of my best mistakes get their start) was that checking "Use Gmoccapy Screen" could just disable the "Include custom PyVCP Gui panel" checkbox & all its suboptions - which would solve my accidental use case and keep people from breaking a stock config by adding new panels known to be incompatible, but wouldn't do anything for the (presumably significant?) number of people working from less stock-y configs.
Unfortunately I don't think I understand enough of any of the nuts & bolts to suggest a more generalized solution.
-Bats
(ok, to be fair, I may not understand enough of the basics either)
Please Log in or Create an account to join the conversation.
Moderators: newbynobi, HansU
Time to create page: 0.067 seconds