Back
[02:50:20] <nojepler> 15:16:39 <mozmck> what do the d's on the end mean?
[02:50:48] <nojepler> that's a C++ "mangled symbol". It includes information about the type of each argument. "d" is an a double-type argument, I think.
[02:51:22] <nojepler> the dpkg-shilibdeps warnings are just noise, I've never taken the time to figure out how to silence them.
[07:30:50] <KGB-linuxcnc> 03John Thornton 052.7 91e1574 06linuxcnc 10docs/src/getting-started/pncconf.txt 10docs/src/getting-started/stepconf.txt 10docs/src/gui/axis.txt 10docs/src/ladder/classic_ladder.txt Docs: change see x manual to a link to the section or chapter * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=91e1574
[07:30:50] <KGB-linuxcnc> 03John Thornton 052.7 5c3ab91 06linuxcnc 10docs/src/gui/gladevcp.txt Docs: change see x manual to a link to the section or chapter * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5c3ab91
[07:30:50] <KGB-linuxcnc> 03John Thornton 052.7 cc8dbce 06linuxcnc 10docs/src/hal/basic_hal.txt 10docs/src/hal/components.txt 10docs/src/hal/pyvcp.txt 10docs/src/hal/tutorial.txt Docs: change see x manual to a link to the section or chapter * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cc8dbce
[10:13:59] <KGB-linuxcnc> 03John Thornton 052.7 5e0bbfc 06linuxcnc 10docs/src/examples/spindle.txt 10docs/src/lathe/lathe-user.txt Docs: change see x manual to a link to the section or chapter * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5e0bbfc
[10:13:59] <KGB-linuxcnc> 03John Thornton 052.7 393b930 06linuxcnc 10(97 files in 6 dirs) Docs: move pyvcp to gui subdirectory along with the rest of the gui like things * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=393b930
[10:13:59] <KGB-linuxcnc> 03John Thornton 052.7 460fa4d 06linuxcnc 10docs/src/getting-started/stepconf.txt Docs: fix build warning :missing section: * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=460fa4d
[11:07:34] <cradek> jthornton: in 2.7 sim it seems like deleting a rung works fine
[11:07:43] <cradek> jthornton: I wonder if I'm doing something different
[11:08:09] <cradek> did you have to use his clp? I just ran demo-sim-cl or however it's spelled, added a rung, put some stuff on it, deleted it
[11:11:59] <JT-Shop> I did the same as you, using wheezy and 2.7 and I crashed
[11:12:40] <cradek> I expected to see CL crash in sim
[11:12:58] <cradek> I'm not itching to try it in rt but I guess I will (hard to debug a hard lock)
[11:13:36] <cradek> I bet nojepler would run something under valgrind and find it right away
[11:13:39] <cradek> I wonder how to do that
[11:15:24] <JT-Shop> news flash, it has to be the last rung
[11:15:44] <cradek> hmmmmm!
[11:15:46] <JT-Shop> any rung before the last one can be deleted
[11:16:01] <JT-Shop> that's where I went when I just tried it again
[11:16:32] <cradek> you just mean the bottom one on the screen?
[11:16:54] <JT-Shop> yes, add one after the bottom one put something in then delete it
[11:17:22] <JT-Shop> put something in , say ok then reselect it then delete
[11:17:24] <cradek> so you use "add" not insert?
[11:17:34] <JT-Shop> yea
[11:17:47] <cradek> delete the whole rung, right?
[11:18:20] <JT-Shop> yea
[11:18:27] <cradek> thanks, I'll try again
[11:21:46] <archivist> valgrind takes a little to get used to but does find the odd sillyness
[12:29:16] <cradek> #0 0xb6fa2f1c in RefreshRung (Rung=0xb6f91f8c, JumpTo=0xb70a929c) at hal/classicladder/calc.c:666
[12:29:19] <cradek> #1 0xb6fa2e6a in RefreshASection (pSection=0xb6f956ac) at hal/classicladder/calc.c:763
[12:29:22] <cradek> #2 0xb6fa31cb in ClassicLadder_RefreshAllSections () at hal/classicladder/calc.c:810
[12:29:25] <cradek> #3 0xb6fa0beb in hal_task (arg=0x0, period=1000000) at hal/classicladder/module_hal.c:156
[12:41:20] <cradek> (gdb) p RungArray
[12:41:20] <cradek> $27 = (StrRung *) 0xb6f92380
[12:41:42] <cradek> heh I bet -1 is not a valid index of RungArray...
[12:42:08] <seb_kuzminsky> somebody returned an error and the caller thought it was an index?
[12:42:28] <seb_kuzminsky> btw hi i'm back
[12:42:41] <seb_kuzminsky> y'all have been busy this weekend!
[12:42:45] <cradek> well for some reason each entry in RungArray[] has a "next" index
[12:42:51] <cradek> this is all very inscrutable
[12:42:57] <cradek> welcome back :-)
[12:44:26] <cradek> so ... it's a linked list, the elements of which are stored in a (fixed size?) array
[12:46:25] <seb_kuzminsky> why use one data structure when two will do?
[12:48:49] <cradek> welp before I make it all crashy, I see two rungs on the screen. Rung[0] has used 1, prev 0, next 2; Rung[1] has used 1, prev 1, next -1; Rung[2] has used 0, prev 0, next 0
[12:49:49] <cradek> the "comments" in Rung[0] and Rung[1] look like the two comments I see on the screen
[12:50:10] <cradek> when I click the top one it says "Rung 1" and when I click the bottom one that label disappears
[12:51:46] <cradek> it's hard to know what design to try to fix
[13:05:07] <cradek> well I think this is too deep for me today
[13:05:10] <cradek> I'm going to go do the laundry
[13:12:02] <nojepler> linked-list-in-array lets you have bounded memory usage and atomic delete/insert
[13:12:06] <nojepler> and it must also be a bear to get right
[13:17:37] <cradek> now I'm not even sure that's the data structure
[13:18:02] <cradek> there are jump coils, -(J)-, that somehow make it jump to a rung other than the one below
[13:18:18] <cradek> the "next" seems to have something to do with that
[13:26:47] <nojepler> ah hm
[13:49:28] <nojepler> (if we ever adapt a newer version of CL to linuxcnc we should upstream it and thereafter just package upstream CL on wlo)
[14:34:41] <KGB-linuxcnc> 03John Thornton 052.7 b1c09e0 06linuxcnc 10docs/asciidoc-markup.txt Docs: add info to markup doc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b1c09e0
[14:34:42] <KGB-linuxcnc> 03John Thornton 052.7 cf03f6f 06linuxcnc 10docs/src/getting-started/stepconf.txt 10docs/src/gui/gmoccapy.txt Docs: fix build errors and minor markup fixes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cf03f6f
[15:03:48] <linuxcnc-build> build #1378 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/1378 blamelist: John Thornton <bjt128@gmail.com>
[15:12:22] <linuxcnc-build> build #3200 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3200 blamelist: John Thornton <bjt128@gmail.com>
[17:22:38] <seb_kuzminsky> jthornton: the buildbot is set up to do lots of builds on different platforms, the 0000.checkin one is just the top-level thing that triggers all the real work
[17:23:18] <seb_kuzminsky> the failure before 0000.checkin was 1405.rip-wheezy-armhf, which does a run-in-place build & runtests on wheezy, on an armhf machine (an odroid u3 currently)
[17:23:32] <seb_kuzminsky> that's the failure that caused 0000.checkin to report an error
[17:24:09] <seb_kuzminsky> it looks like a test failure that's happened intermittently for many months, that no one has bothered to track down yet
[17:24:30] <seb_kuzminsky> search for "limit3" on this page to see it:
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/1378
[17:24:49] <seb_kuzminsky> i'm going to tell the buildbot to try again, and it'll probably work
[17:25:02] <seb_kuzminsky> linuxcnc-build: force build --branch=2.7 0000.checkin
[17:25:03] <linuxcnc-build> build forced [ETA 51m58s]
[17:25:03] <linuxcnc-build> I'll give a shout when the build finishes
[18:13:09] <linuxcnc-build> Hey! build 0000.checkin #3201 is complete: Success [3build successful]
[18:13:09] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3201