#linuxcnc-devel | Logs for 2016-07-12

Back
[00:08:29] <linuxcnc-build> build #3492 of 4008.deb-precise-amd64 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4008.deb-precise-amd64/builds/3492 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[00:18:07] -!- terminal has quit [Remote host closed the connection]
[00:23:05] <skunkworks> jepler, great work!
[00:40:20] -!- kalxas has quit [Quit: Goodbye]
[00:54:48] <linuxcnc-build> build #2060 of 4016.deb-wheezy-i386 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4016.deb-wheezy-i386/builds/2060 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[00:55:31] <linuxcnc-build> build #2064 of 4017.deb-wheezy-amd64 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-amd64/builds/2064 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[00:55:59] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8200:7a40:d0d5:13c1:9dae:52c] has joined #linuxcnc-devel
[01:08:58] <linuxcnc-build> build #1345 of 4014.deb-wheezy-rtpreempt-i386 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4014.deb-wheezy-rtpreempt-i386/builds/1345 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[01:20:49] <jepler> skunkworks: oops I missed that you asked me a question earlier. it is the userspace API of xenomai, specifically their "posix skin".
[01:21:41] <skunkworks> is the LXRT better supported for more kernels than rtai?
[01:21:46] <skunkworks> (userspace)
[01:21:53] <skunkworks> jepler, thanks
[01:22:20] <skunkworks> (I may be asking the wrong question..)
[01:23:40] <linuxcnc-build> build #1380 of 4015.deb-wheezy-rtpreempt-amd64 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4015.deb-wheezy-rtpreempt-amd64/builds/1380 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[01:25:47] <jepler> skunkworks: lxrt is the name of the userspace API of rtai. I think it is optional, so not all rtai kernels may have it.
[01:26:05] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8200:7a40:d0d5:13c1:9dae:52c] has parted #linuxcnc-devel
[01:26:45] <skunkworks> ah.. so it is on top of rtai?
[01:29:39] <jepler> right. with this branch, the same build of uspace can work in 4 different ways: no specific kernel (simulator mode), any preempt-rt kernel, any properly-configured xenomai kernel, and any properly-configured rtai kernel
[01:30:06] <jepler> in the case of xenomai and rtai it is not tied to a single kernel version number, it's a matter of that kernel providing an ABI to userspace programs (posix-skin or lxrt respectively)
[01:30:54] <skunkworks> neat
[01:31:54] <Tom_itx> latency vary between versions?
[01:33:05] <jepler> Tom_itx: yes, each different kernel has different latency performance.
[01:33:41] <Tom_itx> so as before any certain hardware may like one over another
[01:34:11] <jepler> right
[01:35:12] <Tom_itx> sounds pretty neat
[01:35:12] <jepler> but the ability to support any of those with the same build of linuxcnc should be a big improvement
[01:35:19] <Tom_itx> yeah
[01:35:28] <linuxcnc-build> build #729 of 4022.deb-jessie-amd64 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4022.deb-jessie-amd64/builds/729 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[01:35:42] <jepler> to be fair, the machinekit people had the same idea first, what with wanting to support different ARM computers all with different kernels
[01:35:44] <linuxcnc-build> build #1752 of 4018.deb-wheezy-rtai-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4018.deb-wheezy-rtai-i386/builds/1752 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[01:36:45] <linuxcnc-build> build #645 of 4019.deb-jessie-rtpreempt-i386 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4019.deb-jessie-rtpreempt-i386/builds/645 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[01:39:11] <linuxcnc-build> build #731 of 4021.deb-jessie-i386 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4021.deb-jessie-i386/builds/731 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[01:40:30] <linuxcnc-build> build #644 of 4020.deb-jessie-rtpreempt-amd64 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4020.deb-jessie-rtpreempt-amd64/builds/644 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[01:50:03] -!- PCW_ has quit [Ping timeout: 276 seconds]
[01:58:23] <jepler> it's nice that the congratulations can begin at the point where I've broken *ALL* the package builds (on a branch, but still)
[02:03:59] <skunkworks> but still ;)
[02:04:11] <skunkworks> You have always figured it out
[02:06:10] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus a792bba 06linuxcnc 10(7 files in 3 dirs) uspace: add uspace+rtai realtime * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a792bba
[02:06:10] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus e14fc74 06linuxcnc 10(6 files in 2 dirs) uspace: add uspace+xenomai realtime * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e14fc74
[02:06:10] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus ebac00b 06linuxcnc 10(8 files) packaging: rtai, xenomai are sub-packages of uspace * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ebac00b
[02:06:12] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus fa8d52c 06linuxcnc 10docs/src/code/building-linuxcnc.txt docs: document new RTOS support * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fa8d52c
[02:15:10] <jepler> this is what, castle #18? the last one got blown to bits by sappers from the kingdom of lintian...
[02:39:07] -!- ktchk [ktchk!~eddie6929@n219079250015.netvigator.com] has joined #linuxcnc-devel
[02:41:33] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #108: getting close to building on all platforms in our buildbot, though because of technical limitations that doesn't include rtai support now. 02https://github.com/LinuxCNC/linuxcnc/pull/108#issuecomment-231922744
[02:43:22] <linuxcnc-build> build #2695 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/2695 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[02:43:22] <linuxcnc-build> build #4350 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4350 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[02:44:44] -!- ktchk [ktchk!~eddie6929@n219079250015.netvigator.com] has parted #linuxcnc-devel
[02:55:57] <jepler> > command timed out: 1200 seconds without output, attempting to kill
[02:55:58] <jepler> argh
[02:56:08] <jepler> [20427.404021] INFO: rcu_preempt detected stall on CPU 1 (t=15001 jiffies)
[02:56:11] <jepler> more of this
[02:57:49] <jepler> seb_kuzminsky: I fear you'll have to bounce that machine again. but before you do, can you see if there are spinning processes (rtapi_apps maybe)?
[02:58:11] <seb_kuzminsky> checking...
[03:00:02] <seb_kuzminsky> "top" just sits at the terminal, doesn't redraw the screen
[03:00:13] <seb_kuzminsky> actually it locked the console up
[03:00:18] <jepler> too bad
[03:00:27] <seb_kuzminsky> Alt-F2 switched consoles though...
[03:00:41] <jepler> this a new failure mode right?
[03:00:45] <seb_kuzminsky> new to me, yeah
[03:00:55] <seb_kuzminsky> i've seen similar things while debugging rtai
[03:01:00] <seb_kuzminsky> including the rcu stall
[03:01:15] <seb_kuzminsky> i can log in on the other console and ps gives some output before hanging
[03:01:23] <seb_kuzminsky> does not get back to the shell prompt
[03:02:35] * seb_kuzminsky pulls the plug
[03:03:00] <seb_kuzminsky> you know...
[03:03:15] <seb_kuzminsky> both failures today were on wheezy-rtpreempt-amd64
[03:03:23] <seb_kuzminsky> none on wheezy-rtpreempt-i386
[03:03:56] <seb_kuzminsky> well no, they both have just 1 cpu
[03:04:25] <seb_kuzminsky> i got different baffling results on rtai when running with more CPUs, i'm going to try bumping wheezy-rtpreempt-amd64 to 2 vcpus
[03:04:43] <jepler> the main difference that affects preempt-rt (and vanilla for that matter) is this new system of sending rtapi_print messages out through this lockfree queue
[03:05:07] <jepler> hm my wheezy test system has 12 threads :-P
[03:05:45] <jepler> but that new thread doesn't run with elevated priority of any kind
[03:06:20] <seb_kuzminsky> the 19th one got infested with alligators
[03:07:44] <seb_kuzminsky> i just rebuild the rtai kernel with all lock debugging options turned on
[03:07:48] -!- ve7it has quit [Remote host closed the connection]
[03:07:55] <jepler> linuxcnc-build: force build --branch=jepler/master/uspace-plus 0000-checkin
[03:07:56] <linuxcnc-build> no such builder '0000-checkin'
[03:08:10] <jepler> linuxcnc-build: force build --branch=jepler/master/uspace-plus 0000.checkin
[03:08:11] <linuxcnc-build> build forced [ETA 1h36m29s]
[03:08:12] <linuxcnc-build> I'll give a shout when the build finishes
[03:09:21] <jepler> that builder looks like it had two (v)CPUs already
[03:09:26] <jepler> [21328.024081] Pid: 7497, comm: rtapi_app Not tainted 3.2.0-4-rt-amd64 #1 Debian 3.2.81-1 Bochs Bochs
[03:09:47] <jepler> [20967.776304] Pid: 3, comm: ksoftirqd/0 Not tainted 3.2.0-4-rt-amd64 #1 Debian 3.2.81-1 Bochs Bochs
[03:09:51] <jepler> [21147.900379] Pid: 0, comm: swapper/0 Not tainted 3.2.0-4-rt-amd64 #1 Debian 3.2.81-1 Bochs Bochs
[03:09:59] <jepler> mostly, comm is rtapi_app
[03:10:27] <seb_kuzminsky> hmm, yes
[03:10:33] <seb_kuzminsky> http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/2695/steps/environment-report/logs/stdio
[03:11:03] <seb_kuzminsky> it disturbs me that nproc in the guest disagrees with libvirt's theory of the guest's cpu count
[03:11:27] <jepler> I wonder if the message-printing task shold simply wait long between polling
[03:11:35] <jepler> it is going every 10us which is actually frightfully often
[03:11:44] <jepler> is that right?
[03:11:58] <jepler> + struct timespec ts = {0, 10000};
[03:11:58] <jepler> + rtapi_clock_nanosleep(CLOCK_MONOTONIC, 0, &ts, NULL, NULL);
[03:12:19] <seb_kuzminsky> 10,000 nanoseconds, yep
[03:14:22] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus 36fe278 06linuxcnc 10src/rtapi/uspace_common.h 10src/rtapi/uspace_rtapi_app.cc 10src/rtapi/uspace_ulapi.c uspace: Introduce lockfree queue for rtapi_print_msg * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=36fe278
[03:14:22] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus ffd7a41 06linuxcnc 10src/rtapi/rtapi_uspace.hh 10src/rtapi/uspace_common.h 10src/rtapi/uspace_rtapi_app.cc 10src/rtapi/uspace_ulapi.c uspace: rtapi_delay will need a different implementation for rtai * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ffd7a41
[03:14:22] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus 98ee7f1 06linuxcnc 10src/configure.in configure: fall back to uspace realtime if rtai not found * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=98ee7f1
[03:14:25] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus ec63b08 06linuxcnc 10src/module_helper/module_helper.c module_helper: Allow loading modules associated with running kernel * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ec63b08
[03:14:29] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus c4b87c7 06linuxcnc 10src/module_helper/module_helper.c module_helper: always allow .ko objects * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c4b87c7
[03:14:33] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus be528b7 06linuxcnc 10scripts/realtime.in realtime: Load modules even for uspace, if requested by rtapi.conf * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=be528b7
[03:14:37] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus ff3fbb3 06linuxcnc 10src/Makefile build: even on uspace, make linuxcnc_module_helper setuid * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ff3fbb3
[03:14:41] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus 30df045 06linuxcnc 10src/Makefile build: install additional programs as setuid in uspace * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=30df045
[03:14:45] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus 05a0efa 06linuxcnc 10debian/configure packaging: drop special treatment of linuxcnc_module_helper * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=05a0efa
[03:14:49] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus 25a055c 06linuxcnc 10src/rtapi/uspace_rtapi_app.cc uspace: ensure a more orderly shutdown * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=25a055c
[03:14:53] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus f66f0ee 06linuxcnc 10(7 files in 3 dirs) uspace: add uspace+rtai realtime * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f66f0ee
[03:14:57] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus c3ce4ec 06linuxcnc 10(6 files in 2 dirs) uspace: add uspace+xenomai realtime * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c3ce4ec
[03:15:01] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus ccc4512 06linuxcnc 10(8 files) packaging: rtai, xenomai are sub-packages of uspace * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ccc4512
[03:15:05] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus 5b0e05e 06linuxcnc 10docs/src/code/building-linuxcnc.txt docs: document new RTOS support * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5b0e05e
[03:15:39] <jepler> it disturbs me if simply trying to run a *non-rt* task even at 100kHz even in a VM could make something go wonky
[03:16:08] <jepler> but it's not yet clear whether that's the right theory anyway
[03:16:35] <seb_kuzminsky> it's extra disturbing if a single thread on a multi-cpu VM can make it crash
[03:16:40] -!- Miner_48er has quit [Quit: Leaving]
[03:18:55] <jepler> what's the virtualization software, qemu with kvm support?
[03:19:13] <jepler> I see those messages say "bochs" but that's seriously old stuff
[03:21:32] <jepler> 'night, its late here
[03:23:14] <seb_kuzminsky> yeah, qemu/kvm
[03:23:22] <seb_kuzminsky> the wheezy VMs are running on a jessie hypervisor
[03:44:40] <seb_kuzminsky> i guess it's running the bochs bios
[04:14:42] <KGB-linuxcnc> 03Dewey Garrett 05master d95374e 06linuxcnc 10src/emc/motion/control.c control.c teleop wheel jog: no feed override JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d95374e
[04:14:42] <KGB-linuxcnc> 03Dewey Garrett 05master 263c646 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis.py: allow feedoverride adjust always JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=263c646
[04:20:16] <KimK> From the "Uh-Oh" department? (via Distrowatch): "Lately we have been seeing more Linux distributions dropping support for 32-bit x86 architectures. ..."--Distrowatch news item "...making a case for phasing [out] our 32-bit support slowly over the next two and a half years. ..."--Dimtri John Ledkov, Ubuntu developer Distrowatch news item: http://distrowatch.com/weekly.php?issue=20160711#news Ubuntu dev thread:
[04:20:16] <KimK> https://lists.ubuntu.com/archives/ubuntu-devel/2016-June/039420.html
[04:20:20] <KimK> Oops
[04:25:36] <KimK> Flood, sorry. I thought HexChat would have had a character-counter by now. (I'm in the process of upgrading from 10.04 to Mint 18). I had a character-counter script running on Xchat/10.04 but probably won't bother on HexChat/Mint 18.
[04:26:23] <seb_kuzminsky> KimK: come over to debian stable, the water is fine!
[04:36:48] <KimK> I like Debian on our CNC ISOs, and support the choice of Debian there. Keep things simple, great for a CNC machine or small PC where you don't need to do a lot of work. But Debian can be hard to live with for a long stay on the main desktop. I don't like Mint's "complicated parentage", and can see why you guys would prefer not to support it as developers (too many cooks?), but it sure is easy to live with on a long-term
[04:36:48] <KimK> basis. I like the way it works.
[04:36:51] <KimK> Bah!
[04:38:44] <KimK> Maybe I do need a character-counter, lol.
[04:40:06] <KimK> No, it's a new screen, I'll get used to it.
[05:31:42] -!- kwallace [kwallace!~kwallace@162.222.30.254] has parted #linuxcnc-devel
[06:57:05] -!- mk0 [mk0!~Orr@fiztech.basnet.by] has joined #linuxcnc-devel
[07:00:01] -!- Mathnerd314 has quit [Ping timeout: 252 seconds]
[07:00:53] -!- mk0 has quit [Read error: Connection reset by peer]
[07:03:23] -!- teepee_ [teepee_!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[07:05:24] -!- teepee has quit [Ping timeout: 272 seconds]
[07:05:24] teepee_ is now known as teepee
[07:11:19] -!- Miner_48er has quit [Ping timeout: 258 seconds]
[10:31:33] -!- skunkworks has quit [Ping timeout: 260 seconds]
[11:34:29] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[11:34:52] <skunkworks> zlog
[11:34:52] <zlog> skunkworks: Log stored at http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2016-07-12.html
[11:44:51] -!- ktchk [ktchk!~eddie6929@n219079250015.netvigator.com] has joined #linuxcnc-devel
[12:05:43] <jepler> seb_kuzminsky: this time, jessie-rtpreempt-amd64 fell off the face of the planet, but differently than what wheezy did
[12:06:02] <jepler> [Failure instance: Traceback (failure with no frames): <class 'twisted.internet.error.ConnectionLost'>: Connection to the other side was lost in a non-clean fashion.
[12:06:05] <jepler> ]
[12:08:17] <jepler> my real wheezy amd64 vanilla system ran tests/and-or-not-mux.0 successfully 125k+ times overnight and of course my real jessie preempt amd64 system ran 25k+ yesterday so once again it smells like something that happens in vms, not real machines :-/
[13:08:13] -!- tinkerer [tinkerer!~tinkerer@mail.play-pla.net] has joined #linuxcnc-devel
[13:10:08] <tinkerer> jepler: which kind of vms are you using?
[13:12:38] <jepler> tinkerer: seb_kuzminsky said last night, qemu/kvm
[13:14:04] <tinkerer> ok, then it's unlikely that it is this issue: http://serverfault.com/a/608441
[13:16:01] <jepler> most of the problems in the past 2 days have been "rcu_preempt detected stall"
[13:16:09] <jepler> this last one is different
[13:16:17] <jepler> afk
[13:18:49] <tinkerer> ipv6 issues?
[13:37:35] -!- RobyRemzy has quit [Remote host closed the connection]
[13:51:31] <seb_kuzminsky> jepler: black console, totally unresponsive, bounced it
[13:52:07] <seb_kuzminsky> tinkerer: no ipv6 is used in the buildbot
[14:05:11] <tinkerer> and configured?
[14:09:57] <tinkerer> sudo modprobe -c | grep ipv6
[14:13:51] <linuxcnc-build> build #2092 of 3003.dsc-wheezy is complete: Failure [4failed making debian source package] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/3003.dsc-wheezy/builds/2092
[14:14:39] <linuxcnc-build> build #2218 of 3301.dsc-wheezy-rtpreempt is complete: Failure [4failed making debian source package] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/3301.dsc-wheezy-rtpreempt/builds/2218
[14:14:45] -!- pcw_home_ [pcw_home_!~chatzilla@c-50-143-148-115.hsd1.ca.comcast.net] has joined #linuxcnc-devel
[14:14:54] <linuxcnc-build> build #763 of 3004.dsc-jessie is complete: Failure [4failed making debian source package] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/3004.dsc-jessie/builds/763
[14:15:06] <linuxcnc-build> build #762 of 3302.dsc-jessie-rtpreempt is complete: Failure [4failed making debian source package] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/3302.dsc-jessie-rtpreempt/builds/762
[14:15:42] -!- pcw_home has quit [Ping timeout: 246 seconds]
[14:15:54] pcw_home_ is now known as pcw_home
[14:15:57] <linuxcnc-build> build #3514 of 3002.dsc-precise is complete: Failure [4failed making debian source package] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/3002.dsc-precise/builds/3514
[14:21:27] <linuxcnc-build> build #4351 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4351
[14:25:03] <jepler> sigh one of these days I'll get the debian stuff right
[14:34:34] -!- Taski has quit [Ping timeout: 250 seconds]
[14:51:25] -!- kwallace [kwallace!~kwallace@162.222.30.254] has joined #linuxcnc-devel
[15:29:24] -!- Daerist has quit [Quit: Leaving]
[15:32:48] -!- Mathnerd314 [Mathnerd314!~quassel@supertux/Mathnerd314] has joined #linuxcnc-devel
[15:34:30] -!- ivansanchez has quit []
[15:39:27] <skunkworks> http://www.machsupport.com/forum/index.php/topic,32854.0.html
[15:39:33] <skunkworks> http://www.machsupport.com/forum/index.php/topic,32854.0.html
[15:39:59] <skunkworks> sorry - meant
[15:40:00] <skunkworks> http://www.machsupport.com/forum/index.php/topic,32833.0.html
[15:40:06] * skunkworks hugs linuxcnc
[15:40:15] -!- sel [sel!~sel@net77-43-27-64.mclink.it] has joined #linuxcnc-devel
[15:40:27] <seb_kuzminsky> group hug!
[15:40:36] <skunkworks> Mmmmmm
[15:41:18] -!- sel has quit [Client Quit]
[15:41:25] <skunkworks> sorry - I lingered
[15:41:44] -!- sel [sel!~sel@net77-43-27-64.mclink.it] has joined #linuxcnc-devel
[15:42:10] -!- sel has quit [Client Quit]
[15:46:23] <cradek> I suppose like threading, every external device has to implement probing
[15:47:35] <seb_kuzminsky> has anyone made an arm box with linuxcnc to sell to the mach people yet?
[15:47:57] <cradek> I thought alex made a cute self-contained thing
[16:04:23] -!- ktchk has quit [Quit: ktchk]
[16:08:45] <jepler> yes I think he did
[16:09:16] <jepler> seb_kuzminsky: this again! [Failure instance: Traceback (failure with no frames): <class 'twisted.internet.error.ConnectionLost'>: Connection to the other side was lost in a non-clean fashion.
[16:09:24] <jepler> http://buildbot.linuxcnc.org/buildbot/builders/1530.rip-jessie-rtpreempt-amd64/builds/967/steps/runtests
[16:10:41] <jepler> coincidence? it was during the flipflop.0 test both times
[16:14:29] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus a2ab3ae 06linuxcnc 10(8 files) packaging: rtai, xenomai are sub-packages of uspace * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a2ab3ae
[16:14:29] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus bdc41c5 06linuxcnc 10docs/src/code/building-linuxcnc.txt docs: document new RTOS support * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bdc41c5
[16:16:44] <jepler> struct timespec ts = {0, 10000000};
[16:16:45] <jepler> rtapi_clock_nanosleep(CLOCK_MONOTONIC, 0, &ts, NULL, NULL);
[16:16:58] <jepler> that last failure is unfortunately after I changed the message-printing thread to have a much larger sleep
[16:17:06] <jepler> so it blows that theory out of the water
[16:21:18] -!- skunkworks_ [skunkworks_!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[16:22:16] <skunkworks> http://electronicsam.com/images/matsuura/DSC_7726.jpg
[16:26:32] <jepler> what did you do, double-sided-tape the LCD to the old control?
[16:30:33] <seb_kuzminsky> skunkworks: does it have a standard vesa mount on the back?
[16:30:57] <skunkworks> yes
[16:31:08] <skunkworks> 4 holes
[16:31:12] <seb_kuzminsky> nice
[16:31:30] <seb_kuzminsky> i'm been (cough) meaning to do something similar on my bridgeport, for oh about the past 5 years now
[16:32:02] <jepler> seb_kuzminsky: ^^^ I keep breaking buildbot
[16:32:08] <seb_kuzminsky> jepler: same symptoms, black console, unresponsive to the keyboard
[16:32:37] <seb_kuzminsky> pid 26238 is the stalled one, in case that helps any
[16:32:55] <seb_kuzminsky> it unblanked when i hit the power button, but it doesnt seem to be shutting down
[16:32:57] <jepler> umm not sure how a pid would help
[16:33:10] <seb_kuzminsky> if it got logged somewhere, somehow
[16:33:15] <seb_kuzminsky> imma power cycle it
[16:35:18] <jepler> maybe I should reboot my jessie machine with maxcpus=2 or =1 and see if that lets me produce a problem
[16:36:29] <jepler> of course it could also be kernel-dependent
[16:37:01] <jepler> seb_kuzminsky: which kernel is on the jessie builder?
[16:37:38] <seb_kuzminsky> it's 4.1.0-0.bpo.1-rt-amd64
[16:37:40] <seb_kuzminsky> http://buildbot.linuxcnc.org/buildbot/builders/1530.rip-jessie-rtpreempt-amd64/builds/967/steps/environment-report/logs/stdio
[16:38:00] <seb_kuzminsky> i should probably upgrade it
[16:38:16] <seb_kuzminsky> would that mess up your testing?
[16:39:25] <jepler> if you upgrade it and the problem goes away that's dandy
[16:39:29] <jepler> you'd put that current 4.6 kernel in?
[16:39:40] <jepler> .. but wasn't 4.1 the one we were talking about standardizing on?
[16:39:48] <seb_kuzminsky> how about if i upgrade it and it changes everything so you get different errors? :-P
[16:40:01] <jepler> I've been testing with 4.4 but I'll reboot with 4.1 and see how it goes
[16:45:06] <jepler> 700+ iterations of flipflop.0 with Linux rat 4.1.0-0.bpo.2-rt-amd64 #1 SMP PREEMPT RT Debian 4.1.6-1~bpo8+1 (2015-09-09) x86_64 GNU/Linux
[16:45:18] <jepler> on bare metal with 8 CPUs
[16:45:44] <seb_kuzminsky> i should try that kernel on the buildbot
[16:47:19] <jepler> I wish it wasn't such a PITA to get packages from snapshot.debian.org!@
[16:48:49] <jepler> hmm we should move hm2_test into its test, and make sure a new hostmot2 hardware driver can be built just with exported headers (they can't be right now)
[16:49:24] <jepler> huh this is bizarre
[16:50:14] <jepler> "1" is missing from the font that xfce uses for most of its user interface
[16:50:34] <seb_kuzminsky> you can get by with just "0"
[16:50:36] <seb_kuzminsky> and inc
[16:50:40] <jepler> so e.g., the clock reads " :50: 9 20 6-07- 2" (11:50:19 2016-07-12)
[16:52:06] <jepler> it's fixed if I change the defult font from "sans 0" (er "sans 10") to "sans 9"!
[16:52:49] <jepler> or turn off subpixel fonts or change hinting to "slight" or "none"
[16:53:20] <mozmck> That sounds really odd. Seems like something that major would have been noticed and fixed?
[16:53:39] <jepler> It must not happen all the time, I would have noticed it before now
[16:55:12] <seb_kuzminsky> Linux jessie-rtpreempt-i386 4.1.0-2-rt-686-pae #1 SMP PREEMPT RT Debian 4.1.6-1 (2015-08-23) i686 GNU/Linux
[16:55:16] <linuxcnc-build> build #2093 of 3003.dsc-wheezy is complete: Failure [4failed making debian source package] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/3003.dsc-wheezy/builds/2093 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[16:55:29] <seb_kuzminsky> both jessie preempt-rt machines will soon be running the latest 4.1-rt kernel from snapshots
[16:55:45] <seb_kuzminsky> linux-image-4.1.0-2-rt-amd64_4.1.6-1_amd64.deb
[16:55:52] <linuxcnc-build> build #2219 of 3301.dsc-wheezy-rtpreempt is complete: Failure [4failed making debian source package] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/3301.dsc-wheezy-rtpreempt/builds/2219 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[16:56:00] <jepler> I rebooted into this kernel with kexec, I bet I am hitting this and it makes the graphics stack behave a bit weirdly: https://bugs.freedesktop.org/show_bug.cgi?id=95023
[16:56:12] <linuxcnc-build> build #764 of 3004.dsc-jessie is complete: Failure [4failed making debian source package] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/3004.dsc-jessie/builds/764 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[16:56:24] <linuxcnc-build> build #763 of 3302.dsc-jessie-rtpreempt is complete: Failure [4failed apt-get-update install-missing-build-dependencies making debian source package] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/3302.dsc-jessie-rtpreempt/builds/763 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[16:57:01] <seb_kuzminsky> jepler: nice find
[16:57:18] <seb_kuzminsky> what's the branch with the freebsd build fixes?
[16:57:19] <linuxcnc-build> build #3515 of 3002.dsc-precise is complete: Failure [4failed making debian source package] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/3002.dsc-precise/builds/3515 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[16:57:41] <jepler> seb_kuzminsky: some stuff is in master, for the rest look at github PRs
[16:57:56] <seb_kuzminsky> ok
[16:58:12] <jepler> I know trasz has some more that look cherry-pick-able, and then I have a couple of "see if this works for you" type PRs that I would like his feedback on
[17:02:07] <jepler> linuxcnc-build: dance
[17:02:08] <linuxcnc-build> <(^.^<)
[17:02:09] <linuxcnc-build> <(^.^)>
[17:02:10] <linuxcnc-build> (>^.^)>
[17:02:11] <linuxcnc-build> (7^.^)7
[17:02:12] <linuxcnc-build> (>^.^<)
[17:03:46] <jepler> ugh so bored waiting for these long running mdi tests
[17:04:03] <linuxcnc-build> build #4352 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4352 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[17:04:06] <seb_kuzminsky> jepler: ok, both jessie-rtpreempt buildslaves are running the latest 4.1-rt kernel now
[17:10:48] <jepler> the vm hangs / crashes make me worry there's something subtly broken about uspace
[17:10:56] <jepler> I wish someone smart would look at it
[17:11:19] <mozmck> So is 4.1 best of the newer kernels? I know PCW had some problems with 4.something on one board anyhow.
[17:12:08] <jepler> mozmck: 4.1 seemed to have the best compatibility, but PCW has a least one board where 4.6 (I think) is better. Overall our guess is that 4.1 had better compatibility, though.
[17:15:50] -!- radish has quit [Ping timeout: 258 seconds]
[17:32:34] -!- teepee has quit [Ping timeout: 244 seconds]
[17:32:41] -!- teepee [teepee!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[17:39:40] -!- Daerist has quit [Quit: Leaving]
[17:39:57] -!- ve7it [ve7it!~LawrenceG@S010648f8b3c3bc3b.pk.shawcable.net] has joined #linuxcnc-devel
[17:43:39] <jepler> yay(?) reproduced the hang on bare metal with maxcpus=2
[17:43:45] <seb_kuzminsky> yay
[17:43:51] <cradek> oh good
[17:43:51] <seb_kuzminsky> definily
[17:43:58] <cradek> buildbot can live to see another minute or two
[17:45:28] <jepler> I assume bisect is going to point me at the commit that changed how messages are exfiltrated from realtime, but maybe the answer will surprise me..
[17:45:54] <jepler> at origin/mster survived 800+ iterations, while uspace-plus was blowing up well under 100.
[17:47:04] <jepler> [ 225.330287] rtapi_app[12940]: segfault at 0 ip 000000000040d78c sp 00007febc6ae5eb8 error 4 in rtapi_app[400000+18000]
[17:47:19] <seb_kuzminsky> that's different
[17:47:28] <jepler> yeah it is
[17:54:10] <jepler> OK I understand this crash, it's a bug I've introduced and then (hopefully!) fixed in my tree
[17:55:13] <jepler> at 669dca9d I arranged to destroy the App object and set the app pointer to NULL
[17:55:32] <jepler> but it wasn't until 25a055cd that I ensured all tasks were stopped before doing that
[17:55:49] <jepler> the second commit that bisect gave me, 36fe2786, is in between those two
[17:56:10] <jepler> 669dca9 uspace: arrange to destroy the RtapiApp at shutdown
[17:56:18] <jepler> 36fe278 uspace: Introduce lockfree queue for rtapi_print_msg
[17:56:21] <jepler> 25a055c uspace: ensure a more orderly shutdown
[17:57:14] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 5e19f08 06linuxcnc 10src/configure.in configure: fix a typo in a hep message * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5e19f08
[18:13:19] <jepler> hm, no, bisect is bad before the commit I suspected..
[18:17:48] <jepler> uspace: stop threads and then destroy the RtapiApp at shutdown
[18:17:54] <jepler> .. is the first bad commit
[18:18:04] <jepler> that's the combination of 669dca9 and 25a055c from above
[18:19:44] -!- kalxas has quit [Read error: Connection reset by peer]
[18:29:46] -!- skunkworks_ has quit [Ping timeout: 276 seconds]
[18:40:00] -!- kalxas has quit [Changing host]
[18:46:01] -!- skunkworks_ [skunkworks_!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[18:48:08] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler opened issue #109: figure out why trying to clean up tasks crashes uspace posix with maxcpus=2 02https://github.com/LinuxCNC/linuxcnc/issues/109
[19:06:38] -!- Mathnerd314 has quit [Ping timeout: 244 seconds]
[19:10:42] -!- skunkworks_ has quit [Ping timeout: 276 seconds]
[19:19:23] <jepler> hmph
[19:19:39] <jepler> with maxcpus=2, xenomai fails about 1 time in 50 running this script with halrun:
[19:19:43] <jepler> loadrt threads name1=fast period1=1000000
[19:19:44] <jepler> dmesg says
[19:19:44] <jepler> Jul 12 14:19:04 rat kernel: [ 1507.004904] Xenomai: watchdog triggered -- signaling runaway thread 'rtapi_app'
[19:19:48] <jepler> start
[19:19:50] <jepler> loadusr -w sleep .1
[19:27:41] -!- skunkworks has quit [Read error: Connection reset by peer]
[19:44:01] <kwallace> Yay, the laptop stork left a package on the doorstep. It came with the hard drive door (but no caddy) and a power supply. It booted right up, with Windows 7, whatever that is.
[19:44:16] -!- asheppard has quit [Quit: Ex-Chat]
[19:50:33] -!- skunkworks [skunkworks!~skunkwork@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[19:51:39] -!- skunkworks has quit [Client Quit]
[19:51:51] -!- skunkworks [skunkworks!~skunkwork@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[19:52:28] -!- asheppard has quit [Quit: Ex-Chat]
[19:54:09] <skunkworks> zlog
[19:54:09] <zlog> skunkworks: Log stored at http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2016-07-12.html
[19:55:19] <jepler> kwallace: as long as you can whip up something that keeps the drive snug and doesn't add too much thermal insulation, you'll be fine. I've resorted to carefully positioned rubber bands in my life.
[19:55:48] -!- andypugh [andypugh!~andypugh@cpc14-basl11-2-0-cust1010.20-1.cable.virginm.net] has joined #linuxcnc-devel
[19:57:00] <andypugh> “You guys suck because my pathological INI file breaks the conversion script”
[19:59:13] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus 88be437 06linuxcnc 10src/rtapi/rtapi_uspace.hh 10src/rtapi/uspace_common.h 10src/rtapi/uspace_rtapi_app.cc 10src/rtapi/uspace_ulapi.c uspace: rtapi_get_time will need a different implementation for rtai * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=88be437
[19:59:13] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus 8dbccfb 06linuxcnc 10(40 files in 7 dirs) build: include a copy of boost lockfree for heritage platforms * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8dbccfb
[19:59:13] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus f0ae455 06linuxcnc 10src/rtapi/uspace_common.h 10src/rtapi/uspace_rtapi_app.cc 10src/rtapi/uspace_ulapi.c uspace: Introduce lockfree queue for rtapi_print_msg * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f0ae455
[19:59:17] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus 3c0e6ea 06linuxcnc 10src/rtapi/rtapi_uspace.hh 10src/rtapi/uspace_common.h 10src/rtapi/uspace_rtapi_app.cc 10src/rtapi/uspace_ulapi.c uspace: rtapi_delay will need a different implementation for rtai * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3c0e6ea
[19:59:22] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus 4841a94 06linuxcnc 10src/configure.in configure: fall back to uspace realtime if rtai not found * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4841a94
[19:59:26] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus 6e4ad10 06linuxcnc 10src/module_helper/module_helper.c module_helper: Allow loading modules associated with running kernel * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6e4ad10
[19:59:30] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus 7a809ac 06linuxcnc 10src/module_helper/module_helper.c module_helper: always allow .ko objects * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7a809ac
[19:59:34] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus 14e582d 06linuxcnc 10scripts/realtime.in realtime: Load modules even for uspace, if requested by rtapi.conf * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=14e582d
[19:59:38] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus 443bbd1 06linuxcnc 10src/Makefile build: even on uspace, make linuxcnc_module_helper setuid * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=443bbd1
[19:59:40] <skunkworks> andypugh, you can't please anyone.
[19:59:42] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus b67d1f4 06linuxcnc 10src/Makefile build: install additional programs as setuid in uspace * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b67d1f4
[19:59:46] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus ab4ade8 06linuxcnc 10debian/configure packaging: drop special treatment of linuxcnc_module_helper * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ab4ade8
[19:59:50] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus 81b6744 06linuxcnc 10(7 files in 3 dirs) uspace: add uspace+rtai realtime * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=81b6744
[19:59:54] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus 4b46b5d 06linuxcnc 10(6 files in 2 dirs) uspace: add uspace+xenomai realtime * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4b46b5d
[19:59:58] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus 013facf 06linuxcnc 10(8 files) packaging: rtai, xenomai are sub-packages of uspace * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=013facf
[20:00:02] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus 434c782 06linuxcnc 10docs/src/code/building-linuxcnc.txt docs: document new RTOS support * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=434c782
[20:00:08] <andypugh> Why did he comment-out the [HEADER] part?
[20:00:22] <kwallace> jepler, I think I know somebody that can make something on a CNC that will fit.
[20:00:45] <skunkworks> andypugh, the carousel component is working great - I have not had a chance to look at the jogging issue.
[20:12:49] -!- asheppard has quit [Quit: Ex-Chat]
[20:51:05] -!- kwallace1 [kwallace1!~kwallace@162.222.30.254] has joined #linuxcnc-devel
[20:51:05] -!- kwallace has quit [Read error: Connection reset by peer]
[21:02:12] <linuxcnc-build> build #484 of 4017.5.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4017.5.deb-wheezy-armhf/builds/484 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[21:04:13] <jepler> seb_kuzminsky: have you noticed that the deb builders for build N can be going at the same time as the RIP builders for build N+1? feature or bug?
[21:21:42] -!- jepler has quit [Read error: Connection reset by peer]
[21:22:01] -!- cradek has quit [Read error: Connection reset by peer]
[21:22:08] -!- cradek [cradek!~chris@outpost.timeguy.com] has joined #linuxcnc-devel
[21:24:50] -!- teepee has quit [Ping timeout: 272 seconds]
[21:24:50] -!- amiri has quit [Ping timeout: 272 seconds]
[21:28:07] -!- jepler [jepler!~jepler@emc/developer/pdpc.professional.jepler] has joined #linuxcnc-devel
[21:28:29] -!- teepee [teepee!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[21:32:37] <seb_kuzminsky> jepler: intentional
[21:32:42] <seb_kuzminsky> though maybe misguided
[21:33:06] <seb_kuzminsky> the thinking was, as long as only one thread runs runtests, it's just system load and that should be ok
[21:33:33] <seb_kuzminsky> but you know, i've been wrong before
[21:33:35] <seb_kuzminsky> once
[21:33:47] <seb_kuzminsky> and that was when i thought i was wrong about something, but actually i was right
[21:40:39] -!- trasz [trasz!~trasz@freebsd/developer/trasz] has joined #linuxcnc-devel
[21:40:49] <trasz> seb_kuzminsky: thanks for the fixes :-)
[21:40:58] <seb_kuzminsky> sure :-)
[21:41:08] <trasz> seb_kuzminsky: they are better than mine, but if you're doing some more work, you might want to wait a day or two.
[21:41:25] <trasz> seb_kuzminsky: i basically have all this building and working; it's just that i need to clean things up and push upstream.
[21:41:26] <seb_kuzminsky> i'll wait
[21:41:34] <seb_kuzminsky> oh that's great to hear
[21:42:10] <trasz> seb_kuzminsky: plan for now is to get the port committed to the ports collection - it was waiting for tkimg update, which finally happened today.
[21:42:28] <trasz> seb_kuzminsky: then i'll go back to submitting fixes to linuxcnc.
[21:42:47] <seb_kuzminsky> is something wrong with the libimg port?
[21:42:57] <seb_kuzminsky> or, was
[21:42:59] <trasz> seb_kuzminsky: there was; it didn't work correctly with libpng.
[21:43:19] <trasz> seb_kuzminsky: which made axis crash at startup.
[21:43:24] <seb_kuzminsky> heh yikes
[21:43:47] <seb_kuzminsky> my freebsd 10 vm is about set up, when you push your stuff i'll be able to test it
[21:44:11] <seb_kuzminsky> have you run the latency tests? i'm curious how a stock freebsd kernel does
[21:44:48] <trasz> seb_kuzminsky: it does horribly, but it still doesn't use the proper scheduling.
[21:45:06] <trasz> seb_kuzminsky: i've tried enabling it and it hang; didn't have time to track this down yet.
[21:45:23] <trasz> seb_kuzminsky: i'm wondering myself; in theory freebsd should do well.
[21:45:33] <trasz> seb_kuzminsky: due to interrupt threads, priority lending etc.
[21:45:33] <seb_kuzminsky> does freebsd have anything better than posix 1003.1?
[21:45:56] <trasz> seb_kuzminsky: no, but the plain SCHED_RR didn't work for some reason.
[21:46:05] <trasz> seb_kuzminsky: but it should; there must be a bug somewhere.
[21:46:20] <seb_kuzminsky> right
[21:47:35] <trasz> seb_kuzminsky: ah, that reminds me.
[21:47:49] <trasz> seb_kuzminsky: can you tell me which parts of linuxcnc use readline?
[21:48:07] <trasz> seb_kuzminsky: another thing i need to sort out is to try to link it against libedit, which provides readline-compatible API.
[21:48:19] <trasz> seb_kuzminsky: this would fix the licensing conflict, allowing to distribute binary packages.
[21:48:43] <seb_kuzminsky> i dont know the list of readline users off the top of my head, i'd have to go digging in the build system
[21:49:15] <trasz> seb_kuzminsky: ok, never mind then; i'll need to go through this anyway.
[21:50:14] <seb_kuzminsky> looks like halcmd, sai, and gladevcp, at first glance
[21:52:57] <trasz> thanks
[21:53:08] <trasz> ok, but that's for tomorrow.
[21:53:18] <trasz> :-)
[21:53:48] <seb_kuzminsky> sounds good
[21:59:11] -!- tinkerer has quit [Quit: Leaving]
[21:59:45] <jepler> trasz: hi, sorry i've been neglecting your most recent pr. other stuff has been foremost on my mind...
[22:01:04] <jepler> I hope my uspace work for multiple linux rtoses doesn't make too many conflicts
[22:04:08] <jepler> gladevcp surprises me as a possible readline user.
[22:09:09] <seb_kuzminsky> oh, i think i'm confused about gladevcp, i think it just calls python's file-object readlines() method
[22:09:22] * seb_kuzminsky crawls back into his sewer pipe
[22:10:39] -!- PCW_ [PCW_!~chatzilla@99.88.10.65] has joined #linuxcnc-devel
[22:19:33] -!- asheppard has quit [Ping timeout: 240 seconds]
[22:28:00] <andypugh> Testing this comversion script is really tedious. I have to keep re-setting the config to non-JA. I suppose there is probably a cunnign way to set a restore point with git to make it less tedious.
[22:35:33] -!- zeeshan|2 has quit [Ping timeout: 240 seconds]
[22:47:45] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8200:7a40:d0d5:13c1:9dae:52c] has joined #linuxcnc-devel
[22:47:52] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8200:7a40:d0d5:13c1:9dae:52c] has parted #linuxcnc-devel
[22:59:51] -!- PCW_ has quit [Remote host closed the connection]
[23:03:52] -!- Miner_48er has quit [Quit: Leaving]
[23:06:58] -!- k-man has quit [Ping timeout: 258 seconds]
[23:28:56] <seb_kuzminsky> andypugh: using git for that is absolutely a good way to do it
[23:29:30] <JT-Shop> can you say git reset --hard
[23:29:37] <seb_kuzminsky> 'git commit' all the configs you want to test, run your converter on all of them and check the results, then run 'git reset --hard' to restore the files to their pre-converted state
[23:29:51] <seb_kuzminsky> and 'git clean -fdx .' to get rid of all the generated, untracked files
[23:29:53] <seb_kuzminsky> JT-Shop: +1
[23:30:11] <JT-Shop> a new one for me git glean -fdx
[23:30:15] <JT-Shop> what is -fdx
[23:30:28] <seb_kuzminsky> force, remove dirs, and i forget
[23:30:43] <JT-Shop> which one is i forget?
[23:30:50] <JT-Shop> just kidding
[23:30:51] <seb_kuzminsky> oh yeah, even remove files that are ignored by .gitignore
[23:31:55] <JT-Shop> and added to my git-secrets.txt file
[23:32:54] <seb_kuzminsky> i hope it says The Secret Life of Gits
[23:33:27] <JT-Shop> yep
[23:35:03] <seb_kuzminsky> back when i was working at the university i taught a short class called Habits of Highly Effective Unix
[23:36:15] <JT-Shop> I used to like the show secret life of machines