Back
[07:14:12] <jepler> seb_kuzminsky: works fine, thanks
[07:23:55] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15lair82 opened issue #99: After Update to 2.7.4 error warning when using "Run From Line" in Gmoccapy 02
https://github.com/LinuxCNC/linuxcnc/issues/99
[07:29:33] <lair82> Good Morning Gents, jepler, that add in that Norbert mentioned to fix the 0600 permission problems, can I hand edit that hal_sourceview.py file and see if that fixes the problem?
[07:55:42] <jepler> lair82: never change files installed by a debian package. build a RIP or build a package if you want to test any changes.
[07:57:16] <lair82> Ok, no problem, would norberts fix hopefully be in a 2.7.5 update?
[07:58:45] <lair82> I will probably build an RIP for now, at least until the 2 bugs are fixed that I found.
[07:59:21] <jepler> I haven't tracked the status of that bug. if it's in the 2.7 branch of our git, then yes that will be in the next 2.7.x. If not, then who can say.
[08:00:16] <lair82> Ok, cool, I will just wait and see
[08:02:33] <lair82> Will that fix the problem though, inserting the "os.chmod (filename,0664)" line after line 260 in the hal_sourceview.py file, and then building an RIP?
[08:03:22] <cradek> I don't see any related fix in 2.7
[08:11:09] <jepler> that will probably do what you need. it is not the ideal solution to the problem, because it still does not respect umask. the ideal solution would change the way the temporary file is created, so that it respects umask
[08:11:32] <jepler> but my plan is to let norbert fix it in whatever way he sees fit, because I am not a gmoccapy user or developer
[08:14:59] <lair82> Totally understandable,
[08:15:52] <jepler> if do you make and verify a fix that works for you, follow our procedure for contributors and create a pull request for it on github with the fix.
[08:16:00] <jepler> afk
[09:36:54] <lair82_> I am trying to modify andy's carousel component, after I did a git pull, it erased my change to the comp, and I can't remember what to change it to, I need the following parameter " param r bit homing = 0" outputted so I can get it into classicladder, and make a comparison against it.
[09:38:31] <lair82_> I thought I changed it to "pin out bit homing = 0" but that apparently wasn't it.
[09:39:43] <lair82_> He showed me what to change it to, but that was a year ago, and I didn't make a copy of the file for myself, after I made the change.
[10:01:22] <lair82> Disregard the above, just found our conversation,
[11:19:56] <lair82_> seb_kuzminsky, jepler, I inserted this "os.chmod(filename, 0664)" after line 260 in hal_sourceview.py, and it works now, it saved the file like this, "-rw-rw-r-- 1 greenmill greenmill 251970 Jun 30 11:59 RICK-TEST.ngc"
[11:24:34] <seb_kuzminsky> nice
[11:29:27] <seb_kuzminsky> i agree with jepler above that the correct fix should honor the user's umask
[11:29:44] <seb_kuzminsky> (and that it's norbert's choice how to fix it properly)
[11:29:53] <seb_kuzminsky> my suggestion for a PR to norbert is this:
[11:29:56] <seb_kuzminsky> (untested)
[11:30:15] <seb_kuzminsky> orig_umask = os.umask(0)
[11:30:25] <seb_kuzminsky> os.umask(orig_umask)
[11:30:50] <seb_kuzminsky> os.chmod(filename, (0666 & ~orig_umask))
[11:31:05] <seb_kuzminsky> that will preserve the umask, and honor it when creating the file
[11:34:43] <jepler> there is NO REASON to create the temporary file with the API that doesn't respect umask in the first place!
[11:35:10] <jepler> if you just stop using that API, there's no need to chmod at all!
[11:35:15] <seb_kuzminsky> hmm, yeah
[11:36:20] <jepler> i.e., just generate a temporary filename in whatever way you like and use open().
[11:38:25] <jepler> .. open with mode wx to get O_EXCL|O_CREAT behavior
[11:40:31] <jepler> ('x' in an fopen mode string is an extension to POSIX supported on linux and freebsd and properly passed through by Python, I just checked)
[11:40:38] <jepler> (either that or it's parsed and emulated by Python)
[11:41:04] <jepler> and proposed for a future C standard
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1339.pdf
[11:43:01] <jepler> actually it appears to be in C11
http://www.open-std.org/jtc1/sc22/wg14/www/standards.html http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
[11:52:36] <jepler> though I see that code deals in file descriptors, so you want os.open(..., O_CREAT_O_EXCL, 0666)
[12:10:45] <lair82_> I have finished up my build from source, and it is running 2.7.4, how can I make it run 2.7.3?
[12:12:19] <jepler> Are you asking how to build a specific released version from source?
[12:12:21] <seb_kuzminsky> lair82_: did you check out the 2.7 branch, make some changes, build it for run-in-place, and now when you run it it says it's 2.7.4?
[12:12:39] <seb_kuzminsky> because it so, that's our build system lying to you :-/
[12:16:17] <lair82_> I did run "git branch --track 2.7_branch" then I ran, "git checkout 2.7", then compiled from there. It is running 2.7.4, I want 2.7.3
[12:16:51] <lair82_> And yes I modified a few files, and built a RIP
[12:17:45] <seb_kuzminsky> lair82_: the version number it announces is whatever was in the /VERSION file when you built
[12:17:55] <jepler> like most projects that use git, we have a tag associated with each release
[12:17:56] <seb_kuzminsky> when we make a release, we update the version in that file
[12:18:01] <jepler> to build a specific release, you would check out a tag instead of a branch
[12:18:33] <jepler> in this case, the tag would be v2.7.3
[12:18:49] <seb_kuzminsky> we have a script that updates that file when we build interim versions between the official releases, but the build system doesn't run it for you automatically
[12:18:52] <lair82_> I didn't want to get into the whole JA conversion, so I went back to 2.7, in 2.7.4 somethings up with the carousel component, so I was going to try 2.7.3 to see if the problem went away
[12:18:53] <jepler> the internet will of course have a lot more help about git tags in general, as will git --help tag, etc
[12:19:14] <seb_kuzminsky> so that's why it says you're on 2.7.4 even though you're obviously ahead of that release
[12:19:37] <seb_kuzminsky> but what you really want is what jepler's saying
[12:20:06] <lair82_> I think I remember, "git checkout v2.7.3"
[12:20:14] <seb_kuzminsky> that's it
[12:20:39] <lair82_> One of these days, it will all come together for me.
[12:20:41] <seb_kuzminsky> if you have made commits in your 2.7 branch, they'll not be in your working dir any more after you switch to the 2.7.3 commit, of course
[12:20:52] <jepler> since v2.7.3 (actually since v2.7.4) there is one change to the carousel component.
[12:20:55] <jepler> $ git log --oneline v2.7.3..origin/2.7 src/hal/components/carousel.comp
[12:20:57] <seb_kuzminsky> you'll get your commits back when you switch back to your local 2.7 branch
[12:20:58] <jepler> 72cb686 carousel.comp: Fix a bad initialisation in index mode
[12:22:01] <lair82_> while in 2.7, " git stash save"," git checkout v2.7.3", " git stash apply" ?????
[12:24:37] <jepler> if you have made modifications and not committed them with "git commit" then that may be an appropriate sequence of commands.
[12:24:45] <jepler> that will carry over uncommitted changes
[12:25:48] <lair82_> Ok, I will give it a try, I have never wandered any farther than changing branches with git, so this is virgin territory for me.
[12:26:40] <jepler> there is a very active #git channel on irc. they may be more experienced at helping people who are relatively new to git than we are.
https://git-scm.com/community
[12:27:55] <seb_kuzminsky> linuxcnc-specific git questions are welcome here of course
[12:40:54] <lair82_> I guess I will have to ask Andy directly what he changed, my tool changer carousel isn't working properly now in v2.7.4. After I reverted back to v2.7.3 it is working as intended.
[12:42:46] <cradek> there are no differences between 2.7.3 and 2.7.4 in carousel.comp
[12:43:13] <jepler> there are changes in 2.7 (the branch) since v2.7.4 (the tag / the release)
[12:43:17] <cradek> % git log v2.7.3..v2.7.4 -- src/hal/components/carousel.comp
[12:43:18] <cradek> [nothing]
[12:43:59] <cradek> yep one line is changed since v2.7.4
[12:44:21] <cradek> % git log -u v2.7.4..2.7 -- src/hal/components/carousel.comp
[14:00:54] <cradek> yep you can fix that error by just removing the error. someone added it on purpose, but it must've been for no reason, yeah.
[14:01:23] <cradek> (real answer is you at least need to enqueue it, since cutter comp has to read ahead in many cases, possibly far ahead)
[14:03:02] <cradek> even after you do that, the user will sometimes be surprised by where the IO changes, since one move when compensated can turn into 2 (or I think 3?) moves (when going around corners etc)
[14:06:47] <cradek> guess I should probably say that in the thread
[16:43:16] <seb_kuzminsky> i wonder if gene's surprise machine motion experience was due to #96, or some other fallout of the JA merge
[16:43:56] <seb_kuzminsky> i'm thinking now we should have made a 2.8.0~pre2 release just before the merge, so it'd be easy for folks to go back to a relatively stable version while we shake out the new bugs
[16:44:13] <jepler> you (well, the RM) can tag that ref after the fact
[16:44:30] <seb_kuzminsky> true dat
[16:46:35] <seb_kuzminsky> mozmck: how about we tag 44c5fb919801bdeef83035bebfd4a488c7278d0e as v2.8.0-pre2? that would help folks avoid JA until we fix it more
[17:54:02] <mozmck> Hmm, I thought that looked strange. Showed that everyone left with a net split and only me, hm_buildslave, and the_wench were in the channel
[17:54:13] <mozmck> restarted my client and that fixed it.
[17:54:34] <mozmck> zlog
[18:49:16] <PCW_> Someone complained that mesaflash corrupted configs when run on a 64 bit system
[18:49:17] <PCW_> but I cannot duplicate this
[18:55:49] <jepler> I have also run it on 64-bit systems
[18:58:35] <PCW_> I'll have to ask what version and OS (heck might be Winders)
[19:01:56] <jepler> this issue was reported with a linux-looking commandline:
https://github.com/micges/mesaflash/issues/4
[19:05:50] <jepler> but I assume the report you mention today is a fresh one?
[19:07:15] <PCW_> yes just fetched source and built
[19:07:47] <PCW_> sorry error report is today
[19:08:20] <PCW_> I fetched the source and built on mint 64B and had no issues
[19:12:37] <jepler> hostmot2.c:325:5: warning: field precision specifier ‘.*’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Wformat=]
[19:12:40] <jepler> printf(" Board Name: %.*s\n", sizeof(hm2->config_name), hm2->idrom.board_name);
[19:12:43] <jepler> ^
[19:14:19] <jepler> there are some warnings of this type, I haven't spotted anything else that appears likely to be a 64-bit-specific bug
[19:18:16] <PCW_> yeah I saw those warnings also but none seemed related to the firmware image
[19:30:52] <jepler> what fpga card is this user reporting a problem about? is it 5i25 again?
[19:35:42] <jepler> hm, maybe I am seeing the behavior?
[19:35:43] <jepler> http://paste.debian.net/772674/
[19:35:48] <PCW_> 5I24
[19:37:49] <PCW_> Ahh I tried Ethernet, maybe its PCI related
[19:39:45] <PCW_> And dont break the other 5I24 config
[19:42:34] <jepler> it may have already pooched the boot block, not sure
[19:42:47] <PCW_> the way to avoid breaking the other config this is to move the EEPROM select jumper,
[19:42:49] <PCW_> --reload from the working EEPROM and then move the jumper back
[19:43:25] <PCW_> (this only works with a bare motherboard so you can get at the card)
[19:47:02] <jepler> ah I think I have an answer...
[19:47:21] <jepler> it's a problem we first had in 2013 in linuxcnc
[19:47:26] <jepler> memcpy() vs PCI access
[19:47:54] <PCW_> I remember that
[19:57:38] <jepler> https://github.com/micges/mesaflash/pull/12 (N/C)
[20:03:27] <jepler> I also filed
https://github.com/micges/mesaflash/issues/13 because the prospect of having a buggy mesaflash make my board totally unbootable without asking extra hard for it is bad
[20:13:34] <PCW_> yeah there should maybe be a --confirm option and it should bail if the bootsector is invalid unless --confirm is set
[20:15:04] <PCW_> (I do use mesaflash all the time with blank EEPROMs so its valuable to write to bad/corrupted flash if you have to)
[20:52:01] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15TurBoss opened issue #100: Error compiling taskintf 02
https://github.com/LinuxCNC/linuxcnc/issues/100
[22:08:42] <jepler> ding ding ding .. is there a prize for issue #100? oh, no, sorry.
[22:14:53] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky commented on issue #100: Looks like a conflict in the definition of isnan() between the standard C++ header file "cmath" and boost.... 02
https://github.com/LinuxCNC/linuxcnc/issues/100#issuecomment-229841471
[22:14:56] <KGB-linuxcnc> 03Jeff Epler 05master f4eb375 06linuxcnc 10src/emc/task/taskintf.cc taskintf: fix compile error reported on on Ubuntu 16.04 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f4eb375
[22:15:09] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15cradek closed issue #100: Error compiling taskintf 02
https://github.com/LinuxCNC/linuxcnc/issues/100
[22:16:19] <seb_kuzminsky> heh, our comments crossed paths, and yours is way better
[22:16:36] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #100: Looks like we regressed, this was fixed once before at commit 9d6a5bc0. If the patch isn't adequate, please re-open this issue with the next compile error if it looks like it's also about `isnan`, or open a new issue if it looks like something else. 02
https://github.com/LinuxCNC/linuxcnc/issues/100#issuecomment-229841645
[22:17:12] <jepler> afk and goodnight
[22:22:46] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master be3ffa7 06linuxcnc 10VERSION drop "ja" from version number * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=be3ffa7
[22:25:08] <seb_kuzminsky> zlog:
[22:43:53] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15TurBoss commented on issue #100: it has passed the but still compiling fine... 02
https://github.com/LinuxCNC/linuxcnc/issues/100#issuecomment-229844557
[22:44:03] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15TurBoss commented on issue #100: it has passed the but still compiling fine... 02
https://github.com/LinuxCNC/linuxcnc/issues/100#issuecomment-229844557
[22:45:28] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15TurBoss commented on issue #100: it has passed the taskintf, but still compiling fine... 02
https://github.com/LinuxCNC/linuxcnc/issues/100#issuecomment-229844557
[22:47:34] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15TurBoss commented on issue #100: now I'm getting this... 02
https://github.com/LinuxCNC/linuxcnc/issues/100#issuecomment-229844942
[23:24:49] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15TurBoss commented on issue #100: sry can't reopen so I'm goin to create a new one 02
https://github.com/LinuxCNC/linuxcnc/issues/100#issuecomment-229848526
[23:26:26] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15TurBoss opened issue #101: isnan error while compiling 02
https://github.com/LinuxCNC/linuxcnc/issues/101