#linuxcnc-devel Logs

Nov 27 2023

12:08 AM linuxcnc-build2: Build [#1163](http://buildbot2.highlab.com/buildbot/#builders/2/builds/1163) of `50-deb-uspace.debian-12-bookworm-amd64` 8completed with warnings.
12:36 AM linuxcnc-build: build #10439 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/10439 blamelist: CMorley <chrisinnanaimo@hotmail.com>
01:41 AM pere: Did c-morley break the master build? <URL: https://github.com/LinuxCNC/linuxcnc/commits/master >?
01:49 AM rigid: i'm just leaving this here: https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow
01:51 AM rigid: pere: seems the test failed for some apt-get failure
01:51 AM rigid: and wtf is it using http:// and not https://
01:53 AM pere: because apt have cryptosigned chains, so https only add privacy, not security.
01:54 AM rigid: i know. but i thought it's generally a good idea to block outgoing 80 requests from CI. But who knows what goes on internally at the microsoft farm.
01:58 AM pere: why would blocking port 80 be any better than blocking 443?
03:12 AM rigid: pere: the rationale behind it is that simple HTTP requests can be made by very simple means while a full https connections need more effort when exfiltrating the GITHUB_TOKEN
03:13 AM rigid: for example
03:13 AM rigid: sounds dubious
03:14 AM linuxcnc-build2: Build [#1165](http://buildbot2.highlab.com/buildbot/#builders/2/builds/1165) of `50-deb-uspace.debian-12-bookworm-amd64` 4failed.
03:16 AM pere: rigid: is the idea that calling curl is a lot of effort?
03:18 AM rigid: yeah, I guess that applies to some limited sandbox scenario where you got no curl available
03:19 AM rigid: but much more importantly: why is interp_list using NML messages although not using the NML API? :)
03:19 AM pere: historical reasons, perhaps? :)
03:20 AM rigid: and do we care about code formatting? I got a ton of pull requests but they don't follow the current formatting.
03:21 AM rigid: pere: yeah, but why did someone remove the API calls but kept the NMLmsg class
03:23 AM rmu: rigid: thanks for PR re. clang-format
03:23 AM rmu: rigid: interp_list: IIRC some of the messages that the interpreter is sending can also originate elsewhere, e.g. the GUI
03:26 AM rigid: ah, that'd make sense.
03:27 AM rigid: which comes back to that I think there should be an API to stop every component from constructing their own NML messages
03:30 AM rmu: i think there are three "APIs" that are used, the python emcmodule in the axis dir, shcom.hh/cc and the tcl shell.
03:30 AM rmu: IMO it would make sense to unify that
03:31 AM rigid: tcl shell? I saw that tcl uses shcom somewhere
03:32 AM rigid: and there's external GUIs who also do their own NML, right?
03:34 AM rigid: I guess a transition away from NML would be easier if they'd could just do C/bindings library calls that does the nasty stuff behind the scenes and doing it uniformly like shcom and emcmodule
03:36 AM rigid: i'm currently working on a faster pi driver and need to do some OpenPNP stuff but after that i would try to come up with something
03:37 AM rigid: (btw. if anyone is interested, https://github.com/joan2937/pigpio is blazing fast (~1MHz) for read and write operations)
04:53 AM linuxcnc-build2: Build [#1166](http://buildbot2.highlab.com/buildbot/#builders/2/builds/1166) of `50-deb-uspace.debian-12-bookworm-amd64` 8completed with warnings.
06:50 AM linuxcnc-build: build #7543 of 1902.clang-wheezy-rtai-i386 is complete: Failure [4failed garbage-collect git repo] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1902.clang-wheezy-rtai-i386/builds/7543 blamelist: andypugh <andy@bodgesoc.org>, dps.lwk <dps.lwk@gmail.com>
08:19 AM linuxcnc-build: build #10440 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/10440 blamelist: andypugh <andy@bodgesoc.org>, dps.lwk <dps.lwk@gmail.com>
10:24 AM mrec: andypugh_: is there a problem with reloading at the moment?
10:25 AM mrec: I'm using the latest git version, and the log says xyz is the same file when reloading.
10:26 AM mrec: Exception in Tkinter callback
10:26 AM mrec: Traceback (most recent call last):
10:26 AM mrec: File "/usr/lib/python3.7/tkinter/__init__.py", line 1705, in __call__
10:26 AM mrec: return self.func(*args)
10:26 AM mrec: File "/home/sundtek/devel/linuxcnc/bin/axis", line 2796, in touch_off_system
10:26 AM mrec: reload_file(False)
10:26 AM mrec: File "/home/sundtek/devel/linuxcnc/bin/axis", line 1911, in reload_file
10:26 AM mrec: shutil.copyfile(loaded_file, tempfile)
10:26 AM mrec: File "/usr/lib/python3.7/shutil.py", line 104, in copyfile
10:26 AM mrec: raise SameFileError("{!r} and {!r} are the same file".format(src, dst))
10:26 AM mrec: shutil.SameFileError: '/tmp/tmp3d2pd26j/sidewall.nc' and '/tmp/tmp3d2pd26j/sidewall.nc' are the same file
10:38 AM mrec: ----
10:38 AM mrec: open_file_guts(): /home/sundtek/final/feeder/5/sidewall.nc
10:38 AM mrec: loaded file: /home/sundtek/final/feeder/5/sidewall.nc tempfile: /tmp/tmpiuv_sj7q/sidewall.nc
10:38 AM mrec: open_file_guts(): /tmp/tmpiuv_sj7q/sidewall.nc
10:40 AM pcw-home: I've certainly seen that...
10:40 AM pcw-home: (in 2.10)
10:40 AM mrec: it is a big issue... eg. if I change the g-code and reload it won't be active
10:41 AM mrec: especially if some toolchanging is inside.. it crashed a tool here
10:42 AM mrec: the workaround is to open the file again via open dialog so that was okay today
10:42 AM mrec: but I want my reload back :-)
10:43 AM pcw-home: is it broken on 2.9?
10:43 AM mrec: it's the latest git version
10:43 AM mrec: main
10:44 AM rmu: mrec: it is an old known issue
10:44 AM mrec: err / master
10:44 AM mrec: what's the idea behind copying the file?
10:44 AM rmu: https://github.com/LinuxCNC/linuxcnc/issues/2490
10:45 AM rmu: issue has all info
10:45 AM rmu: that change that copies the file needs to be backed out
10:46 AM rmu: you can get the file running if you single block one instruction and then use continue
10:47 AM mrec: that function looked different in the past
10:47 AM mrec: if refilter or not get_filter(loaded_file):
10:47 AM mrec: open_file_guts(loaded_file, False, False)
10:47 AM mrec: else:
10:47 AM mrec: tempfile = os.path.join(tempdir, os.path.basename(loaded_file))
10:48 AM mrec: open_file_guts(tempfile, True, False)
10:48 AM mrec: if line:
10:48 AM mrec: o.set_highlight_line(line)
10:48 AM mrec: that certainly worked
10:58 AM rmu: this has to be backed out or modified https://github.com/LinuxCNC/linuxcnc/commit/3db35073cab2d054724ea2d4f26f7cc440a3ef59
10:59 AM rmu: the idea of the author was to prevent interpreter executing something different than shown in the gui (e.g. if you rewrite the file but don't "reload" in the gui)
11:06 AM mrec: well why not backup loaded_file and write it back once the file is opened?
11:06 AM mrec: def reload_file(refilter=True): global loaded_file
11:06 AM mrec: orig_loaded_file = loaded_file
11:07 AM mrec: .. after the if/else statement
11:07 AM mrec: loaded_file = orig_loaded_file
11:17 AM rmu: why not watch the file for changes?
11:18 AM rmu: qtpyvcp is doing that AFAIK, with the additional bug that it tries to reload the file even if it is running a program, leading to an error
11:18 AM rmu: (and aborting the run)
11:23 AM mrec: I might add several lines of g-code and save it in between, personally I'd prefer a manual reload
11:24 AM mrec: I only reload when things are idle .. not sure what axis would do while its processing the previous program
11:25 AM mrec: https://github.com/LinuxCNC/linuxcnc/pull/2762
11:27 AM rmu: the interpreter always re-opens the file when starting, so if you write the file and don't reload, axis won't show what will be executed if you start the program
11:28 AM mrec: so basically that patch will just disable the new workaround