Back
[09:27:34] <jthornton> I get this error when I close Axis with a small GladeVCP panel. /usr/bin/gladevcp:292: GtkWarning: GdkWindow 0x4a00003 unexpectedly destroyed gtk.main() **** GLADE VCP ERROR: X Protocol Error: 3 Shutting down and cleaning up LinuxCNC...
[09:27:44] <jthornton> is that normal?
[09:29:50] <pcw_home> sounds like you shut the door before turning off the lights
[09:30:31] <jthornton> yea, I just need to find the light switch
[09:31:06] <archivist> did your xml brackets match up
[09:38:13] <JT-Shop> xml brackets?
[09:43:32] <archivist> Im thinking of these
http://www.linuxcnc.org/docs/2.4/html/hal_pyvcp.html too many guis error :)
[09:43:56] <pcw_home> just guessing, sounds like you need to close the VCP panel last
[09:45:06] <pcw_home> that is for example if you have halscope running and close axis, halscope is closed last
[09:45:30] <pcw_home> (I have _no_ idea how this works)
[09:48:27] <andypugh> I think someone else was talking about this problem.
[09:49:10] <andypugh> Ah yes, here it is.
http://www.linuxcnc.org/hardy/index.php/english/forum/48-gladevcp/28760-properly-exiting-a-gladevcp-panel-embedded-in-axis?start=10#55274
[10:03:27] <JT-Shop> ah yes that is it andypugh
[10:05:11] <JT-Shop> just wish I could follow his train of thought
[10:11:00] <JT-Shop> from the manual Due to the way a GladeVCP panel interacts with Axis if a panel is embedded within Axis, window1 will not receive destroy events properly.
[10:20:21] <KGB-linuxcnc> 03Dewey Garrett 052.7 86617a3 06linuxcnc 10configs/sim/axis/moveoff/6_zretract.ini 10configs/sim/axis/moveoff/6_zretract.txt moveoff: expand help txt for 6_zretract demo * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=86617a3
[10:20:21] <KGB-linuxcnc> 03Dewey Garrett 052.7 dd0a661 06linuxcnc Merge branch 'dgarr/histo' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=dd0a661
[10:21:17] <andypugh> JT-Shop: Ah, yes, you need to put your on_destroy handler in something inside Window1 not Window1.
[10:21:46] <andypugh> This is mentioned in the section of the gladevdp docs that describes saving persistent state
[10:21:59] <KGB-linuxcnc> 05dgarr/histo 8e62cdc 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8e62cdc
[10:56:25] <kwallace2> andypugh, thank you for posting the on_destroy note.
[10:57:43] <cradek> is it really true that motion.spindle-speed-in is rps while motion.spindle-speed-out is rpm?
[10:59:00] <cradek> that's how sim/lathe has it, and also the docs say so
[10:59:41] <cradek> I'm in that situation where I want to make a part and not stop and look for bugs (fpr in master sure seems wrong)
[10:59:44] <cradek> trying 2.6
[11:01:52] <cradek> yeah fpr in 2.6's sim/lathe looks a lot more right
[11:03:30] <cradek> http://timeguy.com/cradek-files/emc/end.ngc
[11:03:46] <cradek> runs in about 30 seconds in 2.6.7 and moves very slowly in master
[11:33:00] <cradek> wait wait wait
[11:33:09] <cradek> 2.7.0~pre4 looks right
[11:33:24] <cradek> maybe my master was old and busted and I'm an idiot
[11:33:40] <seb_kuzminsky> whew!
[11:33:58] <seb_kuzminsky> this was your sunday morning heart attach, sponsored by cradek!
[11:34:07] <cradek> haha heart attach
[11:34:14] <seb_kuzminsky> err
[11:34:15] <seb_kuzminsky> heh
[11:34:19] <seb_kuzminsky> what part are you making?
[11:34:20] <cradek> I do that to folks sometimes
[11:34:35] <cradek> a glass lens grinding fixture
[11:34:42] <seb_kuzminsky> ooh, cool
[11:35:16] <cradek> yeah a new master is right, yay
[11:35:21] <cradek> good grief
[11:35:21] <seb_kuzminsky> oh good
[11:35:43] <seb_kuzminsky> yeah, the new tp was kinda broken in some corner cases for a while, but seems much better now
[11:35:54] <seb_kuzminsky> thanks to sam and all the other testers, and to rob/tormach of course
[11:35:59] <cradek> heh "running on a lathe" is a corner case
[11:36:17] <cradek> yeah, everyone involved is awesome
[11:36:50] <seb_kuzminsky> i wonder if tormach is running the new TP on their lathe? and if so, why they didn't notice or fix this bug until sam pointed it out
[11:37:12] <cradek> did sam test lathe stuff?
[11:37:44] <seb_kuzminsky> i think he did not, and i think he tested the new TP on a machine with fast X & Y and slow Z, which triggered the same bug apparently?
[11:37:51] <kwallace2> I can run a lathe sim here, what should I look for?
[11:38:02] <seb_kuzminsky> kwallace2: nothing, it was a false alarm :-)
[11:39:49] <seb_kuzminsky> has anyone heard of the problem Ageraluon reported? that you can only test one axis in stepconf, due to it doing amp-enable wrong?
https://sourceforge.net/p/emc/bugs/416/
[11:41:10] <cradek> basic playing around with of g95/g96/g43 vs m3/m4 shows no unexpected things in master
[11:45:06] <cradek> kwallace2: not that you shouldn't also try them :-)
[11:46:06] <kwallace2> Indeed.
[11:46:45] <cradek> I don't know what motion.spindle-speed-cmd-rps is supposed to be for - it's not in the motion manpage - and it shows a surprising number when in css mode
[11:47:12] <seb_kuzminsky> i think c_morley added it because he wanted rps as well as rpm?
[11:47:22] <seb_kuzminsky> are you on master or 2.7?
[11:47:31] <cradek> master now
[11:47:43] <cradek> we already had speed-out and speed-out-rps and speed-out-rps-abs
[11:47:48] <seb_kuzminsky> ok (they're really close)
[11:47:49] <cradek> now we also have speed-cmd-rps
[11:48:39] <cradek> I can't believe -in and -out have different units
[11:48:48] <seb_kuzminsky> is spindle-speed-out the actual (feedback) spindle speed and -cmd is the commanded (for driving vfds & gearboxes and things?
[11:49:17] <cradek> no, motion.*-out are a command from motion
[11:49:26] <cradek> -in is the feedback from the spindle
[11:50:00] <seb_kuzminsky> huh
[11:50:18] <seb_kuzminsky> i'd have to read the code (or ask c_morley) what's going on there
[11:51:19] <cradek> a1c66d494
[11:51:22] <cradek> ok it's a feature
[11:52:01] <cradek> just a doc bug
[11:52:15] <seb_kuzminsky> probably in 2.7 too
[11:52:44] <cradek> well there are docs, you simply find them using git grep, then git blame, then git log
[11:54:31] <seb_kuzminsky> cradek: do i understand you correctly, you are reporting that motion.spindle-speed-cmd-rps is not in the motion manpage, is that right?
[11:54:47] <cradek> heh yes
[11:55:04] <seb_kuzminsky> ok
[11:55:19] <cradek> I also recall a "motion's interface to hal" link in the top index of the docs, but I couldn't find it today
[11:55:32] <cradek> it must have gone in something else
[11:55:42] <cradek> that's where I expected to find the docs for those pins
[11:56:05] <seb_kuzminsky> hmm
[11:56:39] <cradek> ah "core hal components"
[11:56:54] <seb_kuzminsky> do you mean at linuxcnc.org/docs? there's only the motion manpage in 2.5 and later, no other link has "motion" in the name
[11:56:58] <seb_kuzminsky> aha
[11:57:07] <cradek> this list also doesn't have that pin
[11:57:39] <seb_kuzminsky> it confuses me that we have two copies of many of our docs, the manpage and the non-manpage docs like that
[11:57:43] <cradek> yes
[11:57:50] <seb_kuzminsky> they invariably drift apart :-/
[11:57:56] <cradek> yes
[11:59:59] <seb_kuzminsky> i opened
https://sourceforge.net/p/emc/bugs/418/ for this
[12:00:15] <cradek> thanks for doing my work for me
[12:09:29] <seb_kuzminsky> someone should write a docs lint program that finds all the pins & params & functions, and makes sure they're mentioned in the manpage
[12:11:13] <archivist> do many still use the manpages
[12:11:32] <archivist> I hate multiple docs too
[12:12:06] <seb_kuzminsky> i use the manpages almost exclusively
[12:13:13] <archivist> I use the html, but sometimes end up on overly terse manpages when googling
[12:15:48] <seb_kuzminsky> i like that the html/pdf docs can have pictures, it makes some things much clearer
[12:16:14] <archivist> I have no time at all for the pdf stuff
[12:16:28] <seb_kuzminsky> we just make those for gene, so he can print them out
[12:24:08] <JT-Shop> aww Andy is gone
[12:25:43] <seb_kuzminsky> JT-Shop: ?
[12:25:58] <seb_kuzminsky> i interpreted his email to mean he gave up trying to get anyone to care about his tool handling patch
[12:27:16] <archivist> I think it just needs his bit to be in userspace and just send the detail needed for the current gcode
[12:28:35] <archivist> how the table gets sent in the message needs a fix, change to a tool as needed
[12:28:49] <seb_kuzminsky> there's a couple of ways to get more tools supported
[12:29:09] <seb_kuzminsky> currently interp expectes to know about all tools without having to send a request anywhere and wait for a response
[12:29:53] <seb_kuzminsky> changing that code pattern to a request/reply one would have repercussions on a lot of Task
[12:30:10] <seb_kuzminsky> or at least a lot of the interpreter
[12:30:56] <seb_kuzminsky> i'd prefer to keep having all tools known to interp, but to change how the tools get there to be better
[12:31:18] <seb_kuzminsky> either by increasing the size of the message that carries the tools, so that more tools can fit in the message
[12:31:19] <archivist> as long as tool x is sent prior to need then the interp will know about it
[12:31:21] <JT-Shop> I was going to thank him for the tip on when the gtk window gets destroyed
[12:31:49] <seb_kuzminsky> or by changing how the protocol works so we can send multiple messages with tools in them
[12:32:13] <seb_kuzminsky> archivist: agreed, i think we want to pre-load tools into interp, not fetch them on demand
[12:32:18] <archivist> all tools in one hit is a basic mistake I think
[12:32:18] <seb_kuzminsky> JT-Shop: ah, got it
[12:32:31] <seb_kuzminsky> meh, it's served us well for a long time
[12:32:46] <archivist> nah it has cause a limit :)
[12:32:47] <seb_kuzminsky> maybe it's time to change it up now though
[12:32:52] <seb_kuzminsky> heh
[12:33:08] <seb_kuzminsky> bbl, time to go burn some metal salts with my daugher for her science fair project :-)
[12:36:56] <Tom_itx> don't burn the house down
[12:40:07] <jthornton> well adding an on destroy event to a sub object didn't work I still get /usr/bin/gladevcp:292: GtkWarning: GdkWindow 0x4600003 unexpectedly destroyed gtk.main()**** GLADE VCP ERROR: X Protocol Error: 3
[12:40:22] <jthornton> when I close Axis with a GladeVCP tab
[12:40:56] <jthornton> well I guess I have to save the glade file before trying :(
[12:41:44] <jthornton> nope still get the error, lets see if the on destroy is getting called
[12:48:23] <jthornton> Andy if you read back, if I put gtk.main_quit() in a sub object (not window1) then when it's destroy event is fired gtk is not there anymore. This does seem to be an error in how GladeVCP closes the window I think.
[12:49:38] <jthornton> I assume I could do other pythonic things in the destroy event like micges suggests like saving some variable as my print function worked.
[12:49:51] <jthornton> bbl
[13:22:22] <skunkworks> lathe testing was light. But was tested on real hardware.
[13:38:48] <micges> skunkworks: you have lathe with lcnc?
[13:39:09] <skunkworks> just a little emco
[13:40:02] <micges> cool
[13:43:27] <skunkworks> http://electronicsam.com/images/KandT/testing/TOP.JPG
[14:24:47] * seb_kuzminsky has lathe-envy of skunkworks
[14:28:20] <seb_kuzminsky> ok, time to go play with the little robot arm for an hour or two :-)
[14:33:37] <jthornton> well crumb, using the python interface to load a program in Axis only updates the title bar but not Axis
[14:59:30] <andypugh> You mean it doesn’t re-paint the preview?
[15:02:58] <JT-Shop> yes, and Axis thinks the previous file is still loaded, so when you hit refresh it reloads the old file
[15:04:02] <JT-Shop> also the G code in the G code window at the bottom is still the old G code
[15:05:23] <JT-Shop> http://linuxcnc.org/index.php/english/forum/20-g-code/28692-lathe-g-code-generator#56223
[15:06:14] <JT-Shop> you can see in that screenshot the file loaded via the python interface shows up on the title bar but the G code is the splash g-code
[15:09:12] <andypugh> I hate to suggest this, but you might have to shell out to the OS and use axis_remote:
http://linuxcnc.org/docs/html/man/man1/axis-remote.1.html
[15:11:52] <JT-Shop> yea, looks like I'm back to having the program live outside of Axis and opened by Axis so the output goes to Axis
[15:12:56] <JT-Shop> I wonder how I could run axis-remote from python?
[15:18:55] * JT-Shop can't even figure out how to use axis-remote
[15:21:30] <JT-Shop> well I got a mdi command to show up in Axis
[15:22:14] <KGB-linuxcnc> 03andypugh 05andypugh/tooltable 666a1cd 06linuxcnc 10(11 files in 2 dirs) Tool database as a database * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=666a1cd
[15:22:14] <KGB-linuxcnc> 03andypugh 05andypugh/tooltable f59be17 06linuxcnc 10(21 files in 5 dirs) starting to play with interp-convert * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f59be17
[15:22:14] <KGB-linuxcnc> 03andypugh 05andypugh/tooltable 5bfeef0 06linuxcnc 10(10 files in 6 dirs) First working version * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5bfeef0
[15:22:15] <KGB-linuxcnc> 03andypugh 05andypugh/tooltable 9e09adb 06linuxcnc 03lib/python/toolstore/test.py 03lib/python/toolstore/tool_db 03share/sql/classic.sql Add some missed files * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9e09adb
[15:22:19] <KGB-linuxcnc> 03Sebastian Kuzminsky 05andypugh/tooltable 03680f7 06linuxcnc 10(10 files) docs: rebrand manpages * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=03680f7
[15:22:23] <KGB-linuxcnc> 03Andy Pugh 05andypugh/tooltable 30272e2 06linuxcnc Merge branch 'master' of ssh://git.linuxcnc.org/git/linuxcnc into tooltable * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=30272e2
[15:23:17] <linuxcnc-build> build #1194 of 1405.rip-wheezy-armhf is complete: Failure [4failed configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/1194 blamelist: Sebastian Kuzminsky <seb@highlab.com>, andypugh <andy@bodgesoc.org>, Andy Pugh <andy@bodgesoc.org>
[15:23:31] <linuxcnc-build> build #1355 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed install-missing-build-dependencies configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/1355 blamelist: Sebastian Kuzminsky <seb@highlab.com>, andypugh <andy@bodgesoc.org>, Andy Pugh <andy@bodgesoc.org>
[15:24:15] <linuxcnc-build> build #1164 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/1164 blamelist: Sebastian Kuzminsky <seb@highlab.com>, andypugh <andy@bodgesoc.org>, Andy Pugh <andy@bodgesoc.org>
[15:24:31] <JT-Shop> I did figure out the syntax finally for axis-remote
[15:25:06] <linuxcnc-build> build #675 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed install-missing-build-dependencies configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/675 blamelist: Sebastian Kuzminsky <seb@highlab.com>, andypugh <andy@bodgesoc.org>, Andy Pugh <andy@bodgesoc.org>
[15:25:13] <JT-Shop> axis-remote -p doens't seem to do anything
[15:25:47] <kwallace2> JT-Shop, are you trying to feed MDI commands or create a set of commands to complete a conversational routine?
[15:26:15] <linuxcnc-build> build #823 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/823 blamelist: Sebastian Kuzminsky <seb@highlab.com>, andypugh <andy@bodgesoc.org>, Andy Pugh <andy@bodgesoc.org>
[15:26:44] <linuxcnc-build> build #1164 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/1164 blamelist: Sebastian Kuzminsky <seb@highlab.com>, andypugh <andy@bodgesoc.org>, Andy Pugh <andy@bodgesoc.org>
[15:26:54] <JT-Shop> ha axis-remote is a python script
[15:27:15] <JT-Shop> kwallace2, I'm trying to open a file created by a python program
[15:27:39] <linuxcnc-build> build #3006 of 1300.rip-precise-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/3006 blamelist: Sebastian Kuzminsky <seb@highlab.com>, andypugh <andy@bodgesoc.org>, Andy Pugh <andy@bodgesoc.org>
[15:27:48] <linuxcnc-build> build #3007 of 1200.rip-lucid-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/3007 blamelist: Sebastian Kuzminsky <seb@highlab.com>, andypugh <andy@bodgesoc.org>, Andy Pugh <andy@bodgesoc.org>
[15:27:57] <linuxcnc-build> build #3008 of 1306.rip-precise-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/3008 blamelist: Sebastian Kuzminsky <seb@highlab.com>, andypugh <andy@bodgesoc.org>, Andy Pugh <andy@bodgesoc.org>
[15:28:04] <linuxcnc-build> build #2208 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/2208 blamelist: Sebastian Kuzminsky <seb@highlab.com>, andypugh <andy@bodgesoc.org>, Andy Pugh <andy@bodgesoc.org>
[15:28:05] <linuxcnc-build> build #159 of 1903.clang-wheezy-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1903.clang-wheezy-amd64/builds/159 blamelist: Sebastian Kuzminsky <seb@highlab.com>, andypugh <andy@bodgesoc.org>, Andy Pugh <andy@bodgesoc.org>
[15:28:34] <linuxcnc-build> build #3007 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/3007 blamelist: Sebastian Kuzminsky <seb@highlab.com>, andypugh <andy@bodgesoc.org>, Andy Pugh <andy@bodgesoc.org>
[15:29:41] <linuxcnc-build> build #3007 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/3007 blamelist: Sebastian Kuzminsky <seb@highlab.com>, andypugh <andy@bodgesoc.org>, Andy Pugh <andy@bodgesoc.org>
[15:29:43] <kwallace2> JT-Shop, okay you are ahead of me. That is something I need to figure out.
[15:30:06] <linuxcnc-build> build #798 of 1102.rip-hardy-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1102.rip-hardy-amd64/builds/798 blamelist: Sebastian Kuzminsky <seb@highlab.com>, andypugh <andy@bodgesoc.org>, Andy Pugh <andy@bodgesoc.org>
[15:30:30] <JT-Shop> I can send output to axis from a program that is opened by Axis
[15:30:31] <linuxcnc-build> build #3013 of 1101.rip-hardy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1101.rip-hardy-rtai-i386/builds/3013 blamelist: Sebastian Kuzminsky <seb@highlab.com>, andypugh <andy@bodgesoc.org>, Andy Pugh <andy@bodgesoc.org>
[15:31:00] <linuxcnc-build> build #3008 of 1100.rip-hardy-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1100.rip-hardy-i386/builds/3008 blamelist: Sebastian Kuzminsky <seb@highlab.com>, andypugh <andy@bodgesoc.org>, Andy Pugh <andy@bodgesoc.org>
[15:32:42] <andypugh> Err… What have I done?
[15:33:58] <JT-Shop> you pointed me in a direction that works
[15:34:00] <JT-Shop> os.system('axis-remote -m g0x3')
[15:34:22] <linuxcnc-build> build #159 of 1902.clang-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1902.clang-wheezy-rtai-i386/builds/159 blamelist: Sebastian Kuzminsky <seb@highlab.com>, andypugh <andy@bodgesoc.org>, Andy Pugh <andy@bodgesoc.org>
[15:34:23] <linuxcnc-build> build #3017 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3017 blamelist: Sebastian Kuzminsky <seb@highlab.com>, andypugh <andy@bodgesoc.org>, Andy Pugh <andy@bodgesoc.org>
[15:34:45] <andypugh> No, mean I seem to have wrecked the buildbot
[15:34:58] <JT-Shop> yes, I see that too
[15:35:13] * skunksleep thinks andy tripped over a wire
[16:09:40] <JT-Remote> J/ #linuxcnc
[16:10:11] <JT-Remote> j/ #linuxcnc
[16:12:24] <andypugh> Ah, well, it seems that the tooltable branch won’t compile for me either. “No rule to make target `emc/rs274ngc/interp_execute.cc’”
[16:12:42] <andypugh> I don’t know if I even touched that file.
[16:20:12] <seb_kuzminsky> just met a guy who wants to help us build rt-preempt kernels for arm
[16:20:46] <andypugh> I thought they already existed?
[16:20:59] <seb_kuzminsky> sort of
[16:21:17] <seb_kuzminsky> the rt-preempt patch works on arm
[16:21:35] <seb_kuzminsky> but i dont know of a good set of pre-built debian packages for it
[16:21:46] <andypugh> Ah, right.
[16:21:57] <andypugh> I build Xenomai kernels for Udoo
[16:22:05] <andypugh> That was a hassle
[16:22:12] <seb_kuzminsky> yeah, i bet
[16:22:20] <seb_kuzminsky> i built rtai kernels for x86, that was a hassle too ;-)
[16:22:47] <seb_kuzminsky> thanks for pushing the tooltable branch, i promise to look at it this time ;-)
[16:22:50] <seb_kuzminsky> bbl
[16:24:20] <andypugh> seb_kuzminsky: Any idea what’s wrong with it?
[16:24:35] <andypugh> “No rule to make target” ?
[16:36:14] <andypugh> Well, for some reason the file has disappeared from my branch. That would explain it, I guess.
[16:55:57] <KGB-linuxcnc> 03andy pugh 05andypugh/tooltable acb168b 06linuxcnc 03src/emc/rs274ngc/interp_execute.cc Putting back a file deleted by accident * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=acb168b
[16:56:49] <linuxcnc-build> build #1195 of 1405.rip-wheezy-armhf is complete: Failure [4failed configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/1195 blamelist: andy pugh <andy@bodgesoc.org>
[16:57:16] <linuxcnc-build> build #1356 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed install-missing-build-dependencies configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/1356 blamelist: andy pugh <andy@bodgesoc.org>
[16:57:57] <linuxcnc-build> build #676 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed install-missing-build-dependencies configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/676 blamelist: andy pugh <andy@bodgesoc.org>
[17:00:08] <andypugh> Darn it to heck!
[17:45:19] <linuxcnc-build> build #1165 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/1165 blamelist: andy pugh <andy@bodgesoc.org>
[17:45:32] <linuxcnc-build> build #1165 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/1165 blamelist: andy pugh <andy@bodgesoc.org>
[17:46:23] <seb_kuzminsky> andypugh: try rebasing your branch onto master
[17:46:45] <seb_kuzminsky> the "master" commit that you merged in was an ancient 2013 commit
[17:47:54] <linuxcnc-build> build #824 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/824 blamelist: andy pugh <andy@bodgesoc.org>
[17:48:19] <seb_kuzminsky> how did it ever work if you removed interp_execute.cc?
[17:56:21] <linuxcnc-build> build #3007 of 1300.rip-precise-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/3007 blamelist: andy pugh <andy@bodgesoc.org>
[17:56:48] <linuxcnc-build> build #3009 of 1306.rip-precise-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/3009 blamelist: andy pugh <andy@bodgesoc.org>
[17:58:32] <linuxcnc-build> build #2209 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/2209 blamelist: andy pugh <andy@bodgesoc.org>
[17:59:21] <linuxcnc-build> build #3008 of 1200.rip-lucid-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/3008 blamelist: andy pugh <andy@bodgesoc.org>
[18:00:13] <linuxcnc-build> build #3008 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/3008 blamelist: andy pugh <andy@bodgesoc.org>
[18:01:03] <linuxcnc-build> build #799 of 1102.rip-hardy-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1102.rip-hardy-amd64/builds/799 blamelist: andy pugh <andy@bodgesoc.org>
[18:01:59] <linuxcnc-build> build #3008 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/3008 blamelist: andy pugh <andy@bodgesoc.org>
[18:02:17] <linuxcnc-build> build #3014 of 1101.rip-hardy-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1101.rip-hardy-rtai-i386/builds/3014 blamelist: andy pugh <andy@bodgesoc.org>
[18:03:36] <linuxcnc-build> build #3009 of 1100.rip-hardy-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1100.rip-hardy-i386/builds/3009 blamelist: andy pugh <andy@bodgesoc.org>
[18:03:36] <linuxcnc-build> build #3018 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3018 blamelist: andy pugh <andy@bodgesoc.org>
[18:10:20] <andypugh> I didn’t want to rebase it as I didn’t know what I would end up with
[18:11:03] <andypugh> I (naively) thought that if it compiled OK then it would compile OK now.
[18:24:04] <andypugh> And rebase won’t work without conflicts.
[18:53:44] <seb_kuzminsky> andypugh: eventually you'll have to resolve those conflicts, whether through a merge or a rebase
[18:54:05] <seb_kuzminsky> if you do a rebase now, what we review will be more like what would eventually get merged into master
[18:54:37] <seb_kuzminsky> and it would let you move 03680f779a3df17331e39a15d56ee632dc7f6090 to the beginning of the branch so it can be merged independently, since it has nothing to do with tool tables
