Glade Tooltable widget destroys tooltable in a particular case about linuxcnc HOT 39 CLOSED

I can confirm this behavior. Any G-code file can be used for recall, not just an empty G-code file.

In place for tool information is used as a decimal point and a dot. It is also in the Czech localization.

It looks wierd.

from linuxcnc.

Possible workarounds are:

1. Click on reload tool table before adding a tool

2. Use reload tool on start in the settings:

from linuxcnc.

The problem does not appear on Debian Bullseye / Python 3.9.2

from linuxcnc.

I was able to encircle the error. The problem is that the locale setting gets destroyed when showing the main box.

Good to see with these debug prints:
hansu@0fe0482

Output:

--- INIT:352, locale:  ('de_DE', 'UTF-8')
--- INIT:356, locale:  (None, None)

If I set the locale again after this with
locale.setlocale(locale.LC_ALL, '')
all works fine.
But this does't sound like a clean solution.

@c-morley any idea on this?

from linuxcnc.

Just for information to avoid double work - my working branch: https://github.com/hansu/linuxcnc/tree/2966-gmoccapy-destroys-tooltable

from linuxcnc.

Hello,

I tested your branche.
Backup file is working. It is fine.
Would it be possible to add "create backup file" to the official 2.9 branch already? Although this is not a solution to the problem, it would help a lot. Setting corrections for 10 instruments and then losing them is annoying.

BUT, I have different results from your test:
branche hansu/2966-gmoccapy-destroys-tooltable
--- INIT:352, locale: ('cs_CZ', 'UTF-8')
--- INIT:356, locale: ('cs_CZ', 'UTF-8')

branche linuxcnc/master (I added "print ...." commands to source code)
--- INIT:352, locale: ('cs_CZ', 'UTF-8')
--- INIT:356, locale: ('cs_CZ', 'UTF-8')

I use RIP installation. Debian 12. Physical PC

zdenek@cnc:~$ uname -a
Linux cnc 6.1.0-22-rt-amd64 #1 SMP PREEMPT_RT Debian 6.1.94-1 (2024-06-21) x86_64 GNU/Linux

from linuxcnc.

I tried change localization and result is same:
--- INIT:352, locale: ('de_DE', 'UTF-8')
--- INIT:356, locale: ('de_DE', 'UTF-8')

commands for set localization:
localectl set-locale LANG=cs_CZ.UTF-8

localectl set-locale LANG=de_DE.UTF-8

localectl set-locale LANG=en_US.UTF-8

localectl

source: https://www.server-world.info/en/note?os=Debian_12&p=locale

from linuxcnc.

Propably the locale setting get lost at another position on your system if you still encounter the tooltable bug.
You can set the debug print on other lines to figure out when it happens. Maybe begin with placing it at the end of the gmoccapy init function.

from linuxcnc.

I don't understand why you are looking for bugs in the init function.

I added the command "print ..." twice to the on_btn_new_clicked function:

gmoccapy.py:

    # make a new file
    def on_btn_new_clicked(self, widget, data=None):
        tempfilename = os.path.join(_TEMPDIR, "temp.ngc")
        content = self.get_ini_info.get_RS274_start_code()
        content += "\n\n\n\nM2"
        print("on_btn_new_clicked-1", locale.getlocale(locale.LC_NUMERIC))
        gcodefile = open(tempfilename, "w")
        gcodefile.write(content)
        gcodefile.close()
        if self.widgets.lbl_program.get_label() == tempfilename:
            self.widgets.hal_action_reload.emit("activate")
        else:
            self.widgets.hal_action_open.load_file(tempfilename)
            # self.command.program_open(tempfilename)
        self.widgets.gcode_view.grab_focus()
        self.widgets.btn_save.set_sensitive(False)
        print("on_btn_new_clicked-2", locale.getlocale(locale.LC_NUMERIC))

To execute this function, you must press this button:

Result after the first press:
on_btn_new_clicked-1 ('cs_CZ', 'UTF-8')
on_btn_new_clicked-2 ('cs_CZ', 'UTF-8')

Result after the second press:
on_btn_new_clicked-1 (None, None)
on_btn_new_clicked-2 (None, None)

Something delocalizate it, but I don't know what happens after loading some *.ngc file. Could it be a gremlin? I couldn't get Gmoccapy to run without Gremlin.

from linuxcnc.

If I comment this line:
self.widgets.hal_action_open.load_file(tempfilename)

Gmoccapy is not delocalizitied after on_btn_new_clicked

from linuxcnc.

I don't understand why you are looking for bugs in the init function.

Because I wanted to figure out when the locale gets lost. But does not seem to happen at a specific position.

from linuxcnc.

If I comment this line: self.widgets.hal_action_open.load_file(tempfilename)

Gmoccapy is not delocalizitied after on_btn_new_clicked

This does not really resolves it.

from linuxcnc.

If I comment this line: self.widgets.hal_action_open.load_file(tempfilename)
Gmoccapy is not delocalizitied after on_btn_new_clicked

This does not really resolves it.

1. I agree that this is not a solution to the main problem. Please consider my posts as an attempt to help you.This line here in the code does something. I don't know exactly what. It would be stupid to just delete it.

2. I found out that the main problem occurs when the LCNC is in the state:
   (None, None)
   You solved it with this:
   locale.setlocale(locale.LC_ALL, '') in tooledit_widget.py

3. Command self.widgets.hal_action_open.load_file causes something that delocalizes LCNC:
   ('cs_CZ', 'UTF-8') => (None, None)
   Unfortunately, my skills are not good enough to get deeper into the problem.
   If someone could explain to me what the self.widgets.hal_action_open.load_file command does and where its code is located, that would help.
   Have you tried deleting this line and checking the localization on your computer?
   Maybe we have a race-condition again and the problem is not in self.widgets.hal_action_open.load_file. I wonder how it behaves on another PC.

4. It's good that you fixed the main problem, but it would be good to find the cause. Writing "everywhere" locale.setlocale(locale.LC_ALL, '') is not a long-term solution.

from linuxcnc.

Ok I did some more investigation and the reason why the localisation gets lost for me during the initialisation is because I have chosen to load a file on startup in the preferences.

I did some more investigations and found out that hal_action_open.load_file() is not directly the problem.
But it happens in conjunction with that.
If you add debug prints just after calls to this functions, the locale is still valid.
It happens when you go back after creating a file or switch to another mode after loading a file,
so in on_ntb_button_switch_page() (or somewhere in between).
So basically when switching the context. But only when a file is loaded.
I have no idea why self.linuxcnc.program_open(filename) causes that when switching tabs.

If someone could explain to me what the self.widgets.hal_action_open.load_file command does and where its code is located, that would help.

lib/python/gladevcp/hal_filechooser.py:111

from linuxcnc.

It happens when you go back after creating a file or switch to another mode after loading a file, ...

I dont agree with you. It must be something that happens automatically.

I made modification of cooling button in gmoccapy.py for better testing:

# =========================================================
# Coolant an mist coolant button
    def on_tbtn_flood_toggled(self, widget, data=None):
        print("on_tbtn_flood_toggled-1", locale.getlocale(locale.LC_NUMERIC))
        self.widgets.hal_action_open.load_file("../nc_files/3D_Chips.ngc")
        print("on_tbtn_flood_toggled-2", locale.getlocale(locale.LC_NUMERIC))

and deactivate function _update_coolant

    def _update_coolant(self):
        a=5

Result after first click:

on_tbtn_flood_toggled-1 ('cs_CZ', 'UTF-8')
on_tbtn_flood_toggled-2 ('cs_CZ', 'UTF-8')

Result after second click:

on_tbtn_flood_toggled-1 (None, None)
on_tbtn_flood_toggled-2 (None, None)

from linuxcnc.

Yes when some context changes or some containers are being reloaded does this happen. Initiated manually or not does not really seem to make a difference here.

from linuxcnc.

I found source of problem:

If I deactivate function load in gremlin.py

=>

    def load(self,filename = None):
        print("gremlin_load-1")

LCNC is not delocalizated

from linuxcnc.

Not sure if this is the source of the problem. Have you tried Gscreen? That GUI uses the same tooltable widget and seem to not have this problem...

from linuxcnc.

Gscreen has the same problem with delocation after self.widgets.hal_action_open.load_file(). I made same test with modification Flood button in The Gscreen. Gremlin.py has no "import locale", so in Gremlin.py doesnt work locale.getlocale(locale.LC_NUMERIC), so I cant find wrong line.

from linuxcnc.

Did you manage to crash the tool table in Gscreen in the same way?

from linuxcnc.

No, I am interesting only about delocation now:
('cs_CZ', 'UTF-8')
=>
(None, None)

from linuxcnc.

I added to gremlin.py:

# localization
import locale
BASE = os.path.abspath(os.path.join(os.path.dirname(sys.argv[0]), ".."))
LOCALEDIR = os.path.join(BASE, "share", "locale")
locale.setlocale(locale.LC_ALL, '')

I added the "print" commands to the "load" function:

    def load(self,filename = None):
        print("gremlin_load-1", locale.getlocale(locale.LC_NUMERIC))
        s = self.stat
        s.poll()
        if not filename and s.file:
            filename = s.file
        elif not filename and not s.file:
            return

        td = tempfile.mkdtemp()
        self._current_file = filename
        print("gremlin_load-2", locale.getlocale(locale.LC_NUMERIC))
        try:
            random = int(self.inifile.find("EMCIO", "RANDOM_TOOLCHANGER") or 0)
            canon = StatCanon(self.colors, self.get_geometry(),self.lathe_option, s, random)
            parameter = self.inifile.find("RS274NGC", "PARAMETER_FILE")
            temp_parameter = os.path.join(td, os.path.basename(parameter or "linuxcnc.var"))
            if parameter:
                shutil.copy(parameter, temp_parameter)
            canon.parameter_file = temp_parameter
            print("gremlin_load-3", locale.getlocale(locale.LC_NUMERIC))
            unitcode = "G%d" % (20 + (s.linear_units == 1))
            print("gremlin_load-4", locale.getlocale(locale.LC_NUMERIC))
            initcode = self.inifile.find("RS274NGC", "RS274NGC_STARTUP_CODE") or ""
            print("gremlin_load-5", locale.getlocale(locale.LC_NUMERIC))
            result, seq = self.load_preview(filename, canon, unitcode, initcode)
            print("gremlin_load-6", locale.getlocale(locale.LC_NUMERIC))
            if result > gcode.MIN_ERROR:
                self.report_gcode_error(result, seq, filename)
            self.calculate_gcode_properties(canon)
            print("gremlin_load-7", locale.getlocale(locale.LC_NUMERIC))
        except Exception as e:
            print (e)
            self.gcode_properties = None
        finally:
            shutil.rmtree(td)

        self.set_current_view()

Result:

gremlin_load-1 ('cs_CZ', 'UTF-8')
gremlin_load-2 ('cs_CZ', 'UTF-8')
gremlin_load-3 ('cs_CZ', 'UTF-8')
gremlin_load-4 ('cs_CZ', 'UTF-8')
gremlin_load-5 ('cs_CZ', 'UTF-8')
gremlin_load-6 (None, None)
gremlin_load-7 (None, None)

This implies that the problem is here:

Here is the edited file:
gremlin.py.zip

from linuxcnc.

gremlin_load-6 (None, None)
gremlin_load-7 (None, None)

You still get this when you add the import locale ... to gremlin?

from linuxcnc.

It continue to glcanon.py

I added:

import sys

# localization
import locale
BASE = os.path.abspath(os.path.join(os.path.dirname(sys.argv[0]), ".."))
LOCALEDIR = os.path.join(BASE, "share", "locale")
locale.setlocale(locale.LC_ALL, '')

Modify:

    def load_preview(self, f, canon, *args):
        print("glcanon_load_preview-1", locale.getlocale(locale.LC_NUMERIC))
        self.set_canon(canon)
        print("glcanon_load_preview-2", locale.getlocale(locale.LC_NUMERIC))
        result, seq = gcode.parse(f, canon, *args)
        print("glcanon_load_preview-3", locale.getlocale(locale.LC_NUMERIC))
        if result <= gcode.MIN_ERROR:
            self.canon.progress.nextphase(1)
            canon.calc_extents()
            self.stale_dlist('program_rapids')
            self.stale_dlist('program_norapids')
            self.stale_dlist('select_rapids')
            self.stale_dlist('select_norapids')
        print("glcanon_load_preview-4", locale.getlocale(locale.LC_NUMERIC))
        return result, seq

Result:

glcanon_load_preview-1 ('cs_CZ', 'UTF-8')
glcanon_load_preview-2 ('cs_CZ', 'UTF-8')
glcanon_load_preview-3 (None, None)
glcanon_load_preview-4 (None, None)

This implies that the problem is here:

Here is the edited file:
glcanon.py.zip

gremlin_load-6 (None, None)
gremlin_load-7 (None, None)

You still get this when you add the import locale ... to gremlin?

Yes

from linuxcnc.

In glcanon.py is
import gcode

Where is source?
I found only linuxcnc-2.9/lib/python/gcode.so

from linuxcnc.

Hi Hans,

I assume the file linuxcnc-2.9/lib/python/gcode.so comes from source code written in 'C' language.

I did research about "locale + Python language + C language". I found these two resources:
Here's a guy who has a similar problem and also didn't find any nice solution:
https://stackoverflow.com/questions/140295/using-locale-setlocale-in-embedded-python-without-breaking-file-parsing-in-c -thr
Here is the locale documentation:
https://docs.python.org/3/library/locale.html

My conclusions:

1. setlocale() is not thread-safe

In documentation:

setlocale() is not thread-safe on most systems. Applications typically start with a call of

import locale
locale.setlocale(locale.LC_ALL, '')

This sets the locale for all categories to the user’s default setting (typically specified in the LANG environment variable). If the locale is not changed thereafter, using multithreading should not cause problems.

LinuxCNC is a multithreading project, so using the locale library is inappropriate for LinuxCNC. On the other hand, there is probably no better solution.
Therefore, I suppose we will forever be fighting localization and delocalization.

2. I assume that without drastic changes, it will not be possible to simply switch localizations. Therefore, a simple rule will apply:
   locale settings LCNC = default locale settings OS

If my assumption that we will always be at war with localization and delocalization is correct, then we should:

• point to it in the source codes.
• remove the delocalization problem at the lowest level. At the same time, assume that delocalization can also occur at a higher level of code.

In this case, I fixed the problem as low as possible in this PR:
#3036

On the other hand, your PR should also be merged:
#3026
Because we don't know if some other delocalization problem will arise in the future.

I have some comments on your commit

c5a4ea4

• No one knows why locale.setlocale(locale.LC_ALL, '') is used here.
  I would add a comment: "For the correct functionality of the following code, it is necessary to have a correctly set localization"
• Even better would be to check if:
  locale.getdefaultlocale == locale.getlocale
  Only after this check use locale.setlocale(locale.LC_ALL, '')
  At the same time add Debug message: [glacanon.py] LCNC delocalization occurred and now localization occurred

from linuxcnc.

Fixed by #3041

from linuxcnc.

Can I ask you for #2966 (comment) ?

It is necessary to locale Offset Z +Vcc.

I don't know if this bug is related to the locale library.

from linuxcnc.

Do you mean the offset is still with a dot instead of a comma?

from linuxcnc.

Yes, the same problem has label Vcc.

from linuxcnc.

Ah ok you mean Vc - because Vcc is something completely different ;-)

from linuxcnc.

Sorry - Vc.

from linuxcnc.