Back
[00:05:21] -!- Nick001-Shop has quit [Remote host closed the connection]
[00:19:51] -!- rob__H has quit [Ping timeout: 260 seconds]
[00:22:46] -!- skorasaurus has quit [Read error: Connection reset by peer]
[00:34:28] _BJFreeman is now known as BJfreeman
[00:41:47] -!- jfire has quit [Ping timeout: 260 seconds]
[01:01:07] -!- CaptHindsight has quit [Ping timeout: 246 seconds]
[01:04:18] -!- CaptHindsight [CaptHindsight!~2020@unaffiliated/capthindsight] has joined #linuxcnc-devel
[01:21:39] -!- MrFahrenheit has quit [Read error: Operation timed out]
[01:21:46] -!- c-bob| has quit [Ping timeout: 246 seconds]
[01:24:42] -!- CaptHindsight has quit [Quit: gone]
[01:47:19] -!- CaptHindsight [CaptHindsight!~2020@unaffiliated/capthindsight] has joined #linuxcnc-devel
[02:05:47] -!- qrp has quit [Ping timeout: 250 seconds]
[02:16:21] -!- Servos4ever has quit [Ping timeout: 264 seconds]
[02:16:33] Servos4ever_ is now known as Servos4ever
[02:24:33] <cradek> I'm not working on fixing that bug 315, I only made the test to help mhaberler
[02:25:16] <cradek> I asked him to share his insights on -devel about which change caused the regression, if he doesn't want to work on it himself.
[02:28:37] -!- Tom_itx has quit [Ping timeout: 246 seconds]
[02:31:39] -!- Servos4ever has quit [Remote host closed the connection]
[02:37:13] -!- zlog has quit [Ping timeout: 256 seconds]
[02:38:31] -!- Tom_itx [Tom_itx!~Tl@unaffiliated/toml/x-013812] has joined #linuxcnc-devel
[02:40:30] -!- zlog [zlog!~zlog@ip68-102-196-238.ks.ok.cox.net] has joined #linuxcnc-devel
[02:41:22] <KGB-linuxcnc> 03jepler 05master f980aa4 06linuxcnc 10lib/python/gladevcp/hal_gremlin_plus.py * gladevcp: only 32-bit signed integers are OK here
[02:50:32] <seb_kuzminsky> cradek: ok, that makes sense
[03:04:20] -!- BJfreeman has quit [Quit: had a good time]
[03:05:21] -!- Loetmichel has quit [Ping timeout: 241 seconds]
[03:05:30] -!- |1li has quit [Quit: Leaving]
[03:07:31] -!- CaptHindsight has quit [Quit: gone]
[03:18:08] -!- Valen has quit [Quit: Leaving.]
[03:24:07] <linuxcnc-build> build #1150 of precise-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim/builds/1150 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:24:53] <linuxcnc-build> build #1151 of hardy-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1151 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:25:13] <linuxcnc-build> build #1148 of precise-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-sim/builds/1148 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:26:28] -!- CaptHindsight [CaptHindsight!~2020@unaffiliated/capthindsight] has joined #linuxcnc-devel
[03:26:49] <linuxcnc-build> build #1148 of lucid-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1148 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:28:11] <linuxcnc-build> build #1146 of lucid-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1146 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:29:06] <linuxcnc-build> build #1147 of hardy-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1147 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:29:45] <linuxcnc-build> build #1149 of hardy-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1149 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:29:56] <KGB-linuxcnc> 03jepler 05master 55fec86 06linuxcnc 10src/emc/usr_intf/touchy/listing.py * touchy: allow optional counts argument to scroll operations
[03:29:56] <KGB-linuxcnc> 03jepler 05master 9bf54b3 06linuxcnc 10src/emc/ 10usr_intf/touchy/touchy.glade 10usr_intf/touchy/touchy.py * touchy: allow wheel scrolling of program start point
[03:30:00] <KGB-linuxcnc> 03jepler 05master e8cd18f 06linuxcnc 10src/emc/usr_intf/touchy/touchy.py * Merge branch 'touchy-mpg-scrolling'
[03:30:30] <linuxcnc-build> build #348 of precise-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/348 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:32:12] <linuxcnc-build> build #1147 of lucid-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1147 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:32:12] <linuxcnc-build> build #1145 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1145 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:34:37] -!- CaptHindsight has quit [Quit: gone]
[03:34:43] -!- Nick001 has quit [Ping timeout: 264 seconds]
[03:48:16] -!- CaptHindsight [CaptHindsight!~2020@unaffiliated/capthindsight] has joined #linuxcnc-devel
[03:48:18] -!- CaptHindsight has quit [Read error: Connection reset by peer]
[03:53:49] -!- CaptHindsight [CaptHindsight!~2020@unaffiliated/capthindsight] has joined #linuxcnc-devel
[04:02:47] -!- skorasaurus has quit [Ping timeout: 256 seconds]
[04:08:20] <KGB-linuxcnc> 03elson 05v2.5_branch 069894e 06linuxcnc 10docs/src/drivers/pico_ppmc.txt
[04:08:20] <KGB-linuxcnc> 23:08:49 up 15 days, 0 min, 4 users, load average: 0.02, 0.08, 0.09
[04:08:21] <KGB-linuxcnc> USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
[04:08:21] <KGB-linuxcnc> elson :-3 - 23Jun13 ?xdm? 4:29m 0.96s /usr/bin/gnome-
[04:08:22] <KGB-linuxcnc> elson pts/1 :0.0 24Jun13 0.00s 55:28 0.29s git commit pico
[04:08:25] <KGB-linuxcnc> elson pts/2 :0.0 26Jun13 22.00s 0.86s 0.03s info vi
[04:08:27] <KGB-linuxcnc> elson pts/3 :0.0 Sun19 25:30m 0.07s 0.07s bash
[04:08:30] <KGB-linuxcnc> Please enter the commit message for your changes. Lines starting
[04:13:53] <linuxcnc-build> build #1151 of precise-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim/builds/1151 blamelist: Jeff Epler <jepler@unpythonic.net>
[04:16:09] <linuxcnc-build> build #1149 of precise-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-sim/builds/1149 blamelist: Jeff Epler <jepler@unpythonic.net>
[04:16:46] <linuxcnc-build> build #1152 of hardy-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1152 blamelist: Jeff Epler <jepler@unpythonic.net>
[04:17:45] <linuxcnc-build> build #349 of precise-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/349 blamelist: Jeff Epler <jepler@unpythonic.net>
[04:19:41] <linuxcnc-build> build #1148 of lucid-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1148 blamelist: Jeff Epler <jepler@unpythonic.net>
[04:19:44] <linuxcnc-build> build #1147 of lucid-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1147 blamelist: Jeff Epler <jepler@unpythonic.net>
[04:20:08] <linuxcnc-build> build #1149 of lucid-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1149 blamelist: Jeff Epler <jepler@unpythonic.net>
[04:21:22] <linuxcnc-build> build #1150 of hardy-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1150 blamelist: Jeff Epler <jepler@unpythonic.net>
[04:21:58] <linuxcnc-build> build #1148 of hardy-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1148 blamelist: Jeff Epler <jepler@unpythonic.net>
[04:21:59] <linuxcnc-build> build #1146 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1146 blamelist: Jeff Epler <jepler@unpythonic.net>
[04:26:53] <KGB-linuxcnc> 03elson 05master 01efc2d 06linuxcnc 10docs/src/drivers/pico_ppmc.txt * describe command line options
[04:36:21] -!- CaptHindsight has quit [Quit: gone]
[04:38:41] -!- CaptHindsight [CaptHindsight!~2020@unaffiliated/capthindsight] has joined #linuxcnc-devel
[04:44:27] -!- AR_ has quit [Ping timeout: 260 seconds]
[04:45:59] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[04:53:43] <seb_kuzminsky> yowser
[04:53:53] -!- Laremere has quit [Ping timeout: 240 seconds]
[05:02:17] -!- Fox_Muldr has quit [Ping timeout: 256 seconds]
[05:02:57] -!- CaptHindsight has quit [Remote host closed the connection]
[05:04:49] -!- CaptHindsight [CaptHindsight!~2020@unaffiliated/capthindsight] has joined #linuxcnc-devel
[05:15:45] -!- _1SheYode has quit [Ping timeout: 240 seconds]
[05:22:51] -!- vladimirek has quit [Remote host closed the connection]
[05:43:35] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[05:55:54] -!- ve7it has quit [Remote host closed the connection]
[06:05:11] -!- kwallace1 [kwallace1!~kwallace@smb-5.sonnet.com] has joined #linuxcnc-devel
[06:05:46] -!- kwallace2 has quit [Ping timeout: 240 seconds]
[06:06:34] -!- mourner has quit [Quit: mourner]
[06:23:11] <linuxcnc-build> build #351 of precise-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/351 blamelist: Jon Elson <elson@jeuser.pico-systems.com>
[06:31:36] <linuxcnc-build> build #1151 of precise-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-sim/builds/1151 blamelist: Jon Elson <elson@jeuser.pico-systems.com>
[06:31:44] -!- psha[work] [psha[work]!~psha@195.135.238.205] has joined #linuxcnc-devel
[06:34:51] <linuxcnc-build> build #1149 of lucid-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1149 blamelist: Jon Elson <elson@jeuser.pico-systems.com>
[06:36:16] <linuxcnc-build> build #1153 of precise-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim/builds/1153 blamelist: Jon Elson <elson@jeuser.pico-systems.com>
[06:40:01] -!- WalterN has quit [Ping timeout: 248 seconds]
[06:48:09] <linuxcnc-build> build #1154 of hardy-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1154 blamelist: Jon Elson <elson@jeuser.pico-systems.com>
[06:50:21] -!- stsydow has quit [Remote host closed the connection]
[06:54:51] <linuxcnc-build> build #1152 of hardy-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1152 blamelist: Jon Elson <elson@jeuser.pico-systems.com>
[06:56:17] <linuxcnc-build> build #1150 of hardy-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1150 blamelist: Jon Elson <elson@jeuser.pico-systems.com>
[06:56:26] <linuxcnc-build> build #1151 of lucid-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1151 blamelist: Jon Elson <elson@jeuser.pico-systems.com>
[07:03:16] <linuxcnc-build> build #1150 of lucid-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1150 blamelist: Jon Elson <elson@jeuser.pico-systems.com>
[07:03:16] <linuxcnc-build> build #1148 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1148 blamelist: Jon Elson <elson@jeuser.pico-systems.com>
[07:05:53] -!- kwallace1 [kwallace1!~kwallace@smb-5.sonnet.com] has parted #linuxcnc-devel
[07:07:46] -!- jfire has quit [Quit: Leaving.]
[07:19:22] -!- cpresser has quit [Quit: Lost terminal]
[07:29:04] -!- rob_h [rob_h!~rob_h@94.8.134.245] has joined #linuxcnc-devel
[08:02:06] <KGB-linuxcnc> 03git 05bug315-fix 13273aa 06linuxcnc 10src/emc/rs274ngc/interp_o_word.cc * bug315: terminate skipping state on endsub only, not on return
[08:22:50] -!- stsy has quit [Remote host closed the connection]
[08:27:44] -!- odogono has quit [Read error: Connection reset by peer]
[08:30:06] <mhaberler> jepler: fp detect - what kernel was that? rt-preempt?
[08:41:53] _BJFreeman is now known as BJfreeman
[08:47:04] -!- md-2 has quit [Remote host closed the connection]
[08:55:05] <KGB-linuxcnc> 03git 05bug315-2-fix f27301c 06linuxcnc 10src/emc/rs274ngc/interp_read.cc * interp/params: do not require a named param to be defined when parsing a sub
[09:06:40] -!- putnik_ has quit [Changing host]
[09:12:01] -!- doobeh has quit [*.net *.split]
[09:12:01] -!- krusty_ar has quit [*.net *.split]
[09:12:01] -!- fatpandas has quit [*.net *.split]
[09:12:01] -!- jepler has quit [*.net *.split]
[09:12:01] -!- knownasilya has quit [*.net *.split]
[09:12:02] -!- `Nerobro has quit [*.net *.split]
[09:12:02] -!- MarkusBec has quit [*.net *.split]
[09:12:02] -!- putnik has quit [*.net *.split]
[09:12:02] -!- bsilvereagle has quit [*.net *.split]
[09:12:03] -!- zultron has quit [*.net *.split]
[09:12:03] -!- l0ggy_ has quit [*.net *.split]
[09:12:03] -!- rob_h has quit [*.net *.split]
[09:12:04] -!- c-bob| has quit [*.net *.split]
[09:12:04] -!- fbx90 has quit [*.net *.split]
[09:12:05] -!- mourner has quit [*.net *.split]
[09:12:06] -!- Kup has quit [*.net *.split]
[09:12:07] -!- JaggedNZ has quit [*.net *.split]
[09:12:08] -!- the_wench has quit [*.net *.split]
[09:12:08] -!- aude has quit [*.net *.split]
[09:12:08] -!- shanker has quit [*.net *.split]
[09:12:09] -!- mrsun_ has quit [*.net *.split]
[09:12:09] -!- oddover_ has quit [*.net *.split]
[09:12:09] -!- donkey has quit [*.net *.split]
[09:12:09] -!- BJfreeman has quit [*.net *.split]
[09:12:09] -!- xxoxx has quit [*.net *.split]
[09:12:11] -!- uwe_mobile has quit [*.net *.split]
[09:12:11] -!- nots has quit [*.net *.split]
[09:12:11] -!- Poincare has quit [*.net *.split]
[09:12:11] -!- awallin has quit [*.net *.split]
[09:12:12] -!- Spida has quit [*.net *.split]
[09:12:12] -!- roycroft has quit [*.net *.split]
[09:12:13] -!- phillipadsmith_ has quit [*.net *.split]
[09:12:13] -!- Tecan has quit [*.net *.split]
[09:12:14] -!- bob1123 has quit [*.net *.split]
[09:12:14] -!- hm2-buildmaster has quit [*.net *.split]
[09:12:14] -!- t12 has quit [*.net *.split]
[09:13:49] -!- awallin [awallin!awallin@lakka.kapsi.fi] has joined #linuxcnc-devel
[09:15:18] -!- zultron_ [zultron_!~zultron@99-190-134-148.lightspeed.austtx.sbcglobal.net] has joined #linuxcnc-devel
[09:15:18] -!- jepler [jepler!~jepler@206.222.212.217] has joined #linuxcnc-devel
[09:15:18] -!- rob_h [rob_h!~rob_h@94.8.134.245] has joined #linuxcnc-devel
[09:15:18] -!- hm2-buildmaster [hm2-buildmaster!~hm2-build@174-29-12-164.hlrn.qwest.net] has joined #linuxcnc-devel
[09:15:18] -!- the_wench [the_wench!~the_wench@host81-149-189-98.in-addr.btopenworld.com] has joined #linuxcnc-devel
[09:19:07] -!- bob1123 has quit [Ping timeout: 248 seconds]
[09:25:05] -!- crazyraven has quit [Quit: Leaving.]
[09:29:21] -!- b_b has quit [Changing host]
[10:17:02] -!- skunkworks has quit [Remote host closed the connection]
[10:17:37] -!- rzqrs has quit [Ping timeout: 250 seconds]
[10:35:49] -!- FrEaKmAn_ has quit [Read error: Connection reset by peer]
[10:50:53] -!- odogono has quit [Read error: Connection reset by peer]
[10:55:50] -!- BJfreeman has quit [Quit: had a good time]
[10:56:50] -!- Simooon_z has quit [Quit: Leaving]
[10:57:11] -!- putnik_ has quit [Read error: Connection reset by peer]
[10:57:33] -!- putnik has quit [Changing host]
[10:59:01] -!- FrEaKmAn_ has quit [Quit: Leaving]
[11:06:56] <jthornton> http://gnipsel.com/files/0001-increase-stepgen-to-16.patch
[11:07:20] <jthornton> I seem to be missing something the most I can get is 10 stepgens
[11:07:29] <jthornton> it builds ok
[11:16:14] -!- DJ9DJ has quit [Remote host closed the connection]
[11:16:57] DJ9DJ_ is now known as DJ9DJ
[11:17:30] -!- archivist has quit [Ping timeout: 264 seconds]
[11:18:09] -!- syyl_ has quit [Ping timeout: 264 seconds]
[11:20:39] -!- DJ9DJ has quit [Client Quit]
[11:22:46] <jthornton> I wonder if there is something else besides MAX_CYCLE and MAX_CHAN that limits it to 10 stepgens
[11:37:12] -!- md-2 has quit [Remote host closed the connection]
[11:56:31] <cradek> mhaberler: thanks! I will look at it soon.
[11:56:51] <cradek> I wonder how elson does that...
[12:00:05] <jthornton> I thought I was the only one to break things...
[12:00:55] -!- archivist [archivist!~archivist@host81-149-189-98.in-addr.btopenworld.com] has joined #linuxcnc-devel
[12:03:02] -!- stsydow has quit [Remote host closed the connection]
[12:03:48] <jepler> mhaberler: fp detect is in good old sim (master branch)
[12:04:16] <jepler> mhaberler: I don't plan to merge it right now but I should throw it up on a branch somewhere
[12:10:15] -!- mourner has quit [Quit: mourner]
[12:10:47] <KGB-linuxcnc> 03jepler 05jepler/detect-x87 09a280f 06linuxcnc 10src/rtapi/sim_rtapi.c * sim: detect use of x87 instructions in nofp thread
[12:38:12] -!- dhoovie has quit [Read error: Connection reset by peer]
[12:40:05] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[12:52:02] -!- xxoxx has quit [Read error: Operation timed out]
[12:59:16] knownasilya2 is now known as knownasilya
[13:36:40] -!- b_b has quit [Changing host]
[13:46:14] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[13:55:52] -!- mk0 has quit [Quit: Leaving]
[13:55:57] <zultron_> Hey seb_kuzminsky, nice idea about pushing commits to the base of your branch for pushing to master, I like it.
[13:57:44] <zultron_> Here's another one for you: we've agreed that each commit needs to build so cradek can bisect without frustration. Does that extend to unit tests, too?
[13:58:47] <cradek> fwiw, I think it's ok to commit failing tests and then the fix
[13:59:09] <cradek> if you were searching for breakage using a test, you'd run only the interesting test
[13:59:37] <zultron_> I think so too, and we've seen that happen. So the line can be drawn there, good.
[14:00:01] <cradek> "it builds" is really a very low bar
[14:00:57] <cradek> I bet I haven't thought this all through as much as seb - I should listen more than I talk
[14:05:39] <zultron_> Ha ha! Well, I recall examples such as Seb's commit of a unit test before there was a fix to the regression some months back, so obviously the "it tests" bar can't be strictly required.
[14:06:13] <zultron_> There could be commits that break *all* tests, though, even though they clear the "it builds" bar.
[14:07:08] <zultron_> I'm sure I've got commits like that in my tree, since there's a lot of change going on in there.
[14:07:17] <cradek> I suppose that's true - and you could use auto-bisect with any or all tests to find that problem commit
[14:08:09] <cradek> with our continuous testing, we don't break tests and not notice them -- so I don't think we'd ever want to use bisect to find a test-breaker commit
[14:12:01] <zultron_> Maybe I'm imagining an exotic scenario, but if I found a regression and wanted to figure out where it was introduced, I could write a unit test, use git rebase to stick it way back in the history, and then do the bisect.
[14:12:25] <cradek> that'd be awesome
[14:12:51] -!- karavanjoW has quit [Ping timeout: 256 seconds]
[14:13:55] <cradek> or without rebase, you could just copy your test in and try it at every bisect point
[14:14:06] <zultron_> Oh yeah, duh. :)
[14:14:11] -!- Valen has quit [Quit: Leaving.]
[14:15:01] <zultron_> Anyway, you get the idea: if *all* tests are broken, you'll run into the same type of frustration from yesterday when you came across commits that don't build.
[14:15:06] <cradek> I guess bug 315 would have been like that, if we had a cleaner history through that time
[14:15:32] <cradek> yeah and if anything about the test infrastructure changes, etc, you'll have to change your test at the right time
[14:15:59] <cradek> but if ONE commit breaks all the tests and the next one fixes it, and you're unlucky enough to hit that one, you can just use bisect skip and get the next one
[14:16:29] <cradek> it's pretty normal to have to skip testing a commit here and there
[14:17:19] <cradek> my situation recently was that many in a row didn't build and that's pretty obnoxious
[14:17:30] <zultron_> So what ended up happening with your bisect yesterday? I imagine if you skipped enough, you'd have landed on one that compiled.
[14:17:39] zultron_ is now known as zultron
[14:17:45] <cradek> I just gave up after a couple hours of getting nowhere
[14:17:59] <zultron> That sucks.
[14:18:13] -!- renihs has quit [Read error: Connection reset by peer]
[14:18:22] <cradek> and I was pretty sure it was in the remap changes because they were the only major changes, so I asked mhaberler to look at it and made a test program and runtest to help him
[14:18:51] <cradek> eh it's ok, but it makes me think more along the lines of seb being right when he wants our history to be pretty clean
[14:19:17] <zultron> Yep, that's a strong argument, and I personally like it that way, too.
[14:20:40] <cradek> for a while I thought he might be caring too much, but I think the more experience you have with source control, the more you care about things like that (my peeve is whitespace-only changes that break merges for no reason other than someone's aesthetic preferences)
[14:20:46] <zultron> The other argument that Seb hit on is I like to make it look like my development style is super organized and deliberate, even at the expense of being a history revisionist. ;)
[14:21:04] <cradek> haha yeah I like to look smarter than I am too
[14:21:54] <cradek> one time I made a big series of changes that included new files, and then at the end I remembered to add license statements to my new files. before sharing that work, I used rebase to put those in at the beginning instead, for future history's sake.
[14:23:49] <zultron> I don't have enough experience with git collaboration to have seen problems like your whitespace pet-peeve. I'm ambivalent about those kinds of commits.
[14:24:17] <zultron> Yeah, sounds like the perfect application of git rebase -i.
[14:24:25] <zultron> The license statements, that is.
[14:25:43] <cradek> I think after a while, catering to the source control is a primary task, and you make your changes with that in mind (not making merges hard, making future bisects work well, etc)
[14:26:22] <cradek> just like you try to write code that makes the compiler work right (it builds)
[14:26:31] <cradek> I'm not sure if that's a bug or feature of source control systems
[14:26:56] <zultron> Like I say, I'm still learning, but you're preaching to the choir here. :)
[14:27:04] <cradek> I think diff/patch works surprisingly well on source code, but something smarter would sure be better
[14:27:40] <cradek> now I'm philosophizing or something, sorry
[14:28:37] <cradek> like how changing whitespace is a problem ONLY because it makes diff/patch not work on the source code anymore. there's nothing wrong with whitespace changes otherwise.
[14:30:10] -!- kwallace [kwallace!~kwallace@tmb-250.sonnet.com] has joined #linuxcnc-devel
[14:31:04] <zultron> Yes, there're a number of problems there. All kinds of things can make 'git blame' work incorrectly, as I found while trying to survey how much Paul C code needed to be dealt with for the relicense.
[14:32:28] <zultron> There were a few instances like his 1600-line patch where he ran a bunch of files through a source code reflow tool.
[14:32:30] <cradek> yep, he was a big whitespacer, you're right that blame is another way the line-by-line-changes assumptions are bad
[14:32:56] <cradek> yes he should've been shot at that time.
[14:33:19] <zultron> You couldn't tell whether the commit was a no-op, or whether there were actual changes in there. And his commit messages are rarely informative.
[14:33:32] <cradek> now I'm the choir!
[14:34:30] <cradek> the worst change is one that makes a change of substance AND changes whitespace everywhere else. the change is really well hidden then, and you break pretty much every feature of source control all at once.
[14:34:45] <zultron> Well, I don't care too much about whitespace commits, if they're isolated (no real changes) and labeled as no-op. I don't like extra whitespace, either.
[14:35:30] <cradek> that's sure the best way to do it if you must, but you still break blame and usually all future merges that cross that commit
[14:35:34] <zultron> Maybe that defines when I'm ok with them....
[14:36:06] <cradek> and any manual diff old..new across it is noisy
[14:36:08] <zultron> Git blame is broken anyway. :P git mv breaks git blame.
[14:36:42] <cradek> did not know that. I'm still trained to avoid mv because of my cvs days training.
[14:37:07] <zultron> Yeah, that's got problems too. There is 'git diff -w' or whatever that helps with the noise.
[14:38:12] <zultron> For the relicensing work, I was thinking about writing a git plugin that runs code through a reflow tool before taking a diff.
[14:38:19] <cradek> yes for some kinds of reformatting (that doesn't flow lines) that can help
[14:38:42] <zultron> That would help with the whitespace/reflow problems.
[14:39:02] <zultron> It would help with some other things that I've now forgotten....
[14:39:21] -!- bithin has quit [Ping timeout: 250 seconds]
[14:39:36] <cradek> I'd be interested to hear whether that works - I think indent is not idempotent - not sure if there's a smarter one
[14:41:34] <zultron> Another idea was, within a commit, to check whether - lines to one file match + lines in another file. That would help with file renames and general code reorganization.
[14:41:46] <zultron> Anyway, that's a topic for another time.
[14:45:09] -!- morfic- has quit [Ping timeout: 264 seconds]
[14:57:49] -!- kwallace2 [kwallace2!~kwallace@smb-180.sonnet.com] has joined #linuxcnc-devel
[14:59:00] -!- kwallace has quit [Ping timeout: 246 seconds]
[15:03:42] -!- Logxen has quit [Ping timeout: 264 seconds]
[15:10:19] -!- psha[work] has quit [Quit: Lost terminal]
[15:16:49] -!- Kup has quit [Read error: Connection reset by peer]
[15:30:27] <seb_kuzminsky> i'd like to join y'all's choir
[15:35:10] -!- capricorn_one has quit [Quit: Konversation terminated!]
[15:37:53] -!- odogono has quit [Ping timeout: 240 seconds]
[15:38:11] -!- gregory has quit [Ping timeout: 268 seconds]
[15:38:54] -!- Laremere has quit [Ping timeout: 246 seconds]
[15:44:33] <cradek> the more the merrier. but can any of us sing?
[15:45:34] <jepler> cradek: I happen to know you can
[15:51:08] -!- mrsun_ has quit [Ping timeout: 268 seconds]
[15:52:00] -!- psha [psha!~psha@213.208.162.67] has joined #linuxcnc-devel
[15:54:57] <mhaberler> jepler: fp.. gnu threads can have non-fp threads?
[15:55:23] <mhaberler> in xeno-user there's an fp flag for thread creation, but its always fp - so ignored
[15:55:35] <jepler> mhaberler: as far as I could discern, the gnu pth thread switching code saved the fp registers regardless
[15:55:54] <jepler> mhaberler: the goal is to learn about accidental use of fp in functions declared nofp
[15:56:09] <mhaberler> right, I get that
[15:56:29] <mhaberler> where was that patch again?
[15:56:38] <jepler> I pushed it to a branch in git.l.o
[15:57:14] <jepler> branch name is jepler/detect-x87
[15:57:52] <zultron> I'll sing under light interrogation.
[15:58:05] <zultron> seb_kuzminsky, any opinion on the unit test question?
[15:59:09] <jepler> zultron: can you re-state the unit test question?
[15:59:21] steve_stallings is now known as steves_logging
[15:59:24] <jepler> it's nice to have the tests passing at every commit, just like it's nice to have it building
[15:59:32] <zultron> (Maybe it was cleared up by "with our continuous testing, we don't break tests and not notice them -- so I don't think we'd ever want to use bisect to find a test-breaker commit")
[15:59:36] <jepler> when a test is checked in before its fix, you can drop a turd in its directory to mark it as "expected to fail"
[16:00:19] <jepler> of course at some point we should drop our homegrown 'runtests' script and switch to something real.
[16:00:41] <jepler> what we have now was written by a demented NIH-monkey (me) who didn't really even investigate alternatives
[16:00:42] <cradek> I didn't think about the expect-to-fail flag
[16:01:31] <seb_kuzminsky> zultron: i've in the past committed the test first, and the fix second (and i also didn't think about expected-to-fail)
[16:01:58] <seb_kuzminsky> i like doing it that way because then you can run the test without the fix and see that it's a real problem, then hop forward to the fix and see that it really does make the test pass
[16:02:37] <seb_kuzminsky> it does create a window in history where runtests will not pass, which might be confusing or frustrating or harmful when spelunking later?
[16:02:59] <seb_kuzminsky> i've never been bit by that particular problem, so i haven't worried about it
[16:04:18] <seb_kuzminsky> i think i noted in the commit message when adding the expceted-to-fail test that the fix was coming in the next few commits, so a history-spelunker who *did* get bit would have a fighting chance of un-confusing themselves (though the frustration might linger)
[16:04:35] Cylly is now known as Loetmichel
[16:05:01] <cradek> I also have not been bitten by this
[16:05:26] <cradek> if someone told me I oughta use expected-to-fail I guess I might listen or might not...
[16:06:08] <seb_kuzminsky> 49ee157e63c61e267a8d4a37bffff8b1516b7b39
[16:06:54] -!- jfire has quit [Quit: Leaving.]
[16:07:21] <jepler> in the future we'll be able to conduct virtually all conversations merely by sharing the cryptographic hash of the conversation we wish to hold
[16:07:41] <seb_kuzminsky> maybe the best would be to first add the test with xfail, then add the fix and remove xfail in a later commit?
[16:07:44] <cradek> I think adding a new (failing) test that honestly represents an existing bug makes the whole of the tree better
[16:07:57] <seb_kuzminsky> +1
[16:08:04] <jepler> if there's a non-expected fail, I think buildbot won't give packages
[16:08:12] <seb_kuzminsky> yes that's right
[16:08:14] <jepler> .. but it also doesn't squawk publically about expected fails
[16:08:15] <cradek> I am pretty sure this doesn't bother me one bit
[16:08:30] <jepler> I would be happy if there was urgency to test failures; that's why they exist
[16:08:46] <cradek> there is, if only to stop that incessant squawking
[16:09:03] <seb_kuzminsky> "no packages without a clean runtests" is a feature
[16:09:27] <seb_kuzminsky> and yes, having the buildbot spam #linuxcnc-devel is a powerful motivator to get it to shut up :-)
[16:14:48] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[16:18:11] * jepler just ordered his rostock printer
[16:18:24] <jepler> too bad I may not have time to play with it until august
[16:18:26] <cradek> woo
[16:18:43] <jepler> (a week lead time, a week to ship, then I'm out of town, then it's august .. wth)
[16:19:33] <cradek> did you remember to order plenty of extra struts?
[16:20:24] <jepler> no
[16:20:28] <jepler> why so negative?
[16:20:56] <cradek> I have experience writing kinematics
[16:21:35] <cradek> did you get it with the drivers and controller and everything?
[16:21:45] <jepler> yes
[16:21:45] -!- mourner has quit [Quit: mourner]
[16:22:11] <jepler> by the time I'm working on linuxcnc kinematics I'll have printed some different attachment system like the magnetic one we've been talking about
[16:22:20] <cradek> cool
[16:23:09] -!- gregory has quit [Quit: Quitte]
[16:28:35] <seb_kuzminsky> very cool jepler
[16:29:29] <seb_kuzminsky> the guy i've been machining mendelmax parts for got all excited when i told him about running 3d printers with linuxcnc and is going to give me a printer on "permanent loan"
[16:29:37] <seb_kuzminsky> i wonder what month it will be when i have time to work on it...
[16:35:20] <cradek> are you doing the aluminum parts on
http://www.mendelmax.com/2012/12/27/announcing-the-new-mendelmax-2-0/2012-12-24-19-25/
[16:38:24] <seb_kuzminsky> just this part for now:
http://store.terawattindustries.com/27-universal-y-axis-plate-t6061-aluminum.html
[16:38:54] <seb_kuzminsky> we keep talking about other parts but nothing's materialized yet
[16:39:25] <cradek> cool
[16:39:31] <cradek> do you do the tapping?
[16:39:52] <ssi> seb_kuzminsky: I have a mendelmax
[16:40:14] <seb_kuzminsky> cradek: heh no
[16:40:24] <seb_kuzminsky> i mill & drill, and he does the tapping by hand
[16:40:38] <seb_kuzminsky> one of these years i should finish the spindle encoder i started...
[16:40:50] <cradek> hand tapping! sacrilege!
[16:40:52] <seb_kuzminsky> ssi: does it work well for you?
[16:40:57] <ssi> yeah, very well
[16:41:43] <seb_kuzminsky> oh good! which hot end?
[16:41:51] <ssi> couple weeks ago, I did a solidworks drawing of the ProTram cause pete wanths to clone it
[16:41:54] <ssi> and for giggles, I printed it:
[16:41:55] <ssi> https://pbs.twimg.com/media/BKUIYZ1CMAAlTz2.jpg
[16:42:02] <ssi> I have the budaschnozzle on my max
[16:42:07] <ssi> I have a J-head on my prusa
[16:43:16] <seb_kuzminsky> i've heard good things about the budaschnozzle (who makes these names up?)
[16:43:18] <cradek> making 3d models actually appear is pretty neat
[16:43:35] <seb_kuzminsky> not having to worry about work holding and tool selection really lowers the barrier to entry
[16:43:50] <ssi> yea
[16:43:56] <cradek> or coolant or chips in the carpet
[16:43:57] <ssi> it's cool stuff... I've even used them to build machine parts
[16:44:00] <seb_kuzminsky> hmm this looks like a good idea:
http://lists.freebsd.org/pipermail/freebsd-stable/2013-July/074157.html
[16:44:50] <cradek> I'm for that
[16:45:09] <ssi> seb_kuzminsky: I designed and printed this little guy:
http://www.youtube.com/watch?v=VsHNA3oLXC8
[16:45:46] <seb_kuzminsky> wow!
[16:46:25] <seb_kuzminsky> oh, i just now realized that you're ian mcmahon
[16:46:31] -!- PetefromTn has quit [Remote host closed the connection]
[16:46:32] <ssi> that's me :D
[16:46:56] <ssi> please don't follow that with "...you've been served"
[16:47:03] <seb_kuzminsky> i meant to ask you, there are some commits in rtos-master-v0 that claim to be written by "joe chipbreaker" or something, is that you too?
[16:47:32] <ssi> heh yeah... I was doing work on the linuxcnc beagle image, and I did the first couple commits before I realized that the git commit stuff was prepopulated :P
[16:47:39] <ssi> I told michael about it, and he shrugged :)
[16:47:44] <seb_kuzminsky> yeah
[16:48:10] <seb_kuzminsky> we don't have an official document that says "commit as yourself", afaik, but i think we should
[16:48:23] <ssi> oh believe me, I didn't intend for it to go in that way
[16:48:29] <ssi> would prefer it to be changed, but I don't know how
[16:48:31] <seb_kuzminsky> it'll mess up the *next* relicensing effort if we can't contact our contributors
[16:48:35] <seb_kuzminsky> heh
[16:48:38] <ssi> hahahah
[16:49:00] <seb_kuzminsky> ok, no problem, i'll fix it up when i merge it
[16:49:02] <ssi> cool
[16:49:10] <seb_kuzminsky> logger[psha]: link please
[16:49:16] <jepler> git has a concept of a "mailmap" which can fix this when it is in the distant past and only noticed later
http://stacktoheap.com/blog/2013/01/06/using-mailmap-to-fix-authors-list-in-git/
[16:49:20] <ssi> I have that hm2 driver underway that I asked you about
[16:49:21] syyl__ is now known as syyl
[16:50:35] <seb_kuzminsky> neat
[16:51:00] <ssi> I have to do a bunch of corresponding work to the hostmot firmware though, and I'm not sure how that's going to go yet
[16:51:09] <jepler> ssi: what are you cooking?
[16:51:37] <ssi> I have a beaglebone cape with an s3a 200k on it, and I want to make up a hostmot firmware that fits in it and can communicate over SPI
[16:51:44] <ssi> and I'm writing an hm2 driver to run it
[16:53:00] <jepler> ssi: that sounds like a great idea
[16:53:09] <jepler> SPI clocks comfortably fast enough for this?
[16:53:14] <ssi> 48mbit
[16:53:24] <ssi> might limit how much stuff I can run, but I think it's doable
[16:53:28] <ssi> if not, I'll look at using the GPMC driver
[16:53:39] <ssi> but I'll have to give up hdmi framer for that, so no onboard video
[16:53:52] <ssi> my goal is to do it with SPI, so the BBB + fpga can be a complete self contained linuxcnc machine
[16:54:00] <ssi> plug in hdmi monitor and keyboard/mouse and go
[16:54:22] <jepler> nah, epp (7i43) is 2MB/s on a good day, 48Mb/s (=6MB/s) is comfortably faster
[16:54:34] <ssi> ok excellent
[16:54:48] -!- tmcw has quit [Remote host closed the connection]
[16:55:03] <ssi> I'll have to write an SPI slave in vhdl for the firmware side
[16:55:06] <ssi> I haven't dug into that code yet
[16:55:20] <ssi> but fortunately I wrote an SPI slave in vhdl a cuople weeks ago for a bitcoin application
[16:55:22] <jepler> There must be SPI code already in there, but perhaps it's SPI master
[16:55:45] <ssi> I'm hoping I can get at least enough firmware to run a 7i77
[16:56:55] <jepler> surely it's easy to buy that much fpga real estate these days
[16:57:34] <ssi> well i'm working within what I have
[16:57:45] <ssi> this is a board that someone else designed
[16:57:54] <ssi> but if I have success, I'm going to do another board with an s6 lx9 on it
[16:57:59] <ssi> which is what the 5i25 has
[16:59:07] -!- zzolo has quit [Quit: zzolo]
[16:59:17] <jepler> 7i43_400 (3s400tq144) has an SV8 configuration, i20 (2s200pq208) has SV12.
[16:59:26] <jepler> and those are both several generations old
[16:59:54] <jepler> bbl
[17:01:54] <pcw_home> SmartSerial (uProc+RAM+ROM+UARTs) is pretty big as are stepgens and resolver interface
[17:02:32] <ssi> I don't need stepgens or resolvers
[17:02:57] <pcw_home> you have a SP3/200?
[17:03:02] <ssi> s3a 200
[17:03:10] <mhaberler> jepler: I'm delighted to hear you consider alternatives to runtests - interested to hear what you find appropriate
[17:03:33] <pcw_home> pretty sure what a 7I77 needs would fit
[17:03:44] <ssi> yeah that'd be enough for this iteration
[17:03:49] <ssi> next board will have the s6 lx9 on it
[17:03:54] <ssi> which I know for sure will fit :)
[17:04:23] <pcw_home> SP6 is noticeably faster and cheaper/LUT
[17:04:33] <ssi> yeah
[17:04:39] <ssi> I just have these already
[17:04:46] <ssi> I want to POC it before I spin another board
[17:04:54] -!- mrsun_ has quit [Ping timeout: 264 seconds]
[17:05:21] <pcw_home> no problem running the sserial UARTs and uProc at 100 MHz in SP6
[17:06:50] <pcw_home> If you lay out a new card with SPI interface, make sure you use a GCLK for the SPI clock so you dont have to oversample if you dont want to
[17:07:45] -!- md-2 has quit [Remote host closed the connection]
[17:09:33] <pcw_home> In that case SPI slave interface SR runs in its own local clock domain
[17:09:34] <pcw_home> with only doubleword rate parallel data crossing into the hm2 interface clock domain
[17:13:28] <ssi> I'll have to digest that a bit :)
[17:13:42] <ssi> I'm still pretty green at HDL
[17:14:09] <ssi> when I did the last SPI slave, I used a 3 bit shift register to cross clock domain, as per some stuff I read on fpga4fun.com
[17:14:17] <ssi> and I did have trouble with it until I oversampled 5x
[17:27:19] <ssi> pcw_home: so I'm looking at the schem for the existing board I have, and SPI_SCLK is brought in on a pin labeled IO_L12N_CCLK
[17:27:32] -!- bdiu has quit [Remote host closed the connection]
[17:27:32] <ssi> is that what you meant? (or the s3a equivalent maybe)?
[17:29:59] -!- stsy has quit [Remote host closed the connection]
[17:29:59] <pcw_home> No thats the config clock
[17:30:29] <ssi> oh I see the GCLK pins
[17:32:04] <pcw_home> they probably have it wired that way so they can load the FPGA via the SPI interface
[17:32:26] <pcw_home> "serial slave mode"
[17:32:32] -!- stsydow has quit [Remote host closed the connection]
[17:35:10] <pcw_home> SP6 will probably meet timing for a 250 MHz overclock but for Cubie for instance I need to support a 100 MHz SPI clk
[17:35:11] <pcw_home> so I pretty much have to use a GCLK
[17:49:05] <ssi> you think I can do a 48MHz sclk without a gclk?
[17:51:46] -!- mrsun has quit [Ping timeout: 240 seconds]
[17:55:29] -!- alpha1125 has quit [Read error: Connection reset by peer]
[18:02:00] <jepler> mhaberler: I haven't investigated / am not investigating alternatives at the moment
[18:02:57] <mhaberler> thats ok - if it eventually happens, I'd be delighted
[18:03:01] <pcw_home> Possibly by making a HF clock (200 or 250 MHz) and oversampling
[18:03:39] <pcw_home> (in SP6, probably more difficult in SP3)
[18:04:52] <ssi> I guess I'm unclear about the purpose of the glck... I thought they were just buffers for distributing the clock to lots of different logic without much slew
[18:05:07] <ssi> if it's only driving the one spi receiver, which is a relatively small amount of logic, what does the gclk buy you
[18:05:31] <mhaberler> afaict a non-fp thread being really non-fp is a problem limited to kthreads
[18:07:10] <jepler> mhaberler: with more people using user threads models it will be even more important to catch this kind of error
[18:07:35] <jepler> maybe someday we can deprecate the flag but until we do I would like to have a way to find violations
[18:07:48] -!- CaptHindsight has quit [Quit: gone]
[18:08:12] <mhaberler> that I dont understand.. why is it becoming more important? some performance reason?
[18:08:45] <jepler> because we will have more developers running systems where they can accidentally write fp-using code in a nofp context and not see problems
[18:08:57] <mhaberler> I see
[18:09:06] <jepler> i.e., bob q. programmer writes on rt-preempt and then we don't see the problem until someone with rtai/kthreads runs it
[18:09:18] <mhaberler> right
[18:09:52] <jepler> I am not 100% sure but in kernel threads I think the problem may appear as corruption of userspace FP regs
[18:10:00] <mhaberler> right
[18:10:20] <jepler> not fun to diagnose in the last
[18:10:22] <jepler> in the least
[18:10:31] <mhaberler> maybe there is a way to investigate statically by looking at the object files
[18:11:21] -!- CaptHindsight [CaptHindsight!~2020@unaffiliated/capthindsight] has joined #linuxcnc-devel
[18:13:28] <pcw_home> If you have a high speed clock routed to multiple LUTS (like your input slave SPI SR) you probably want to use a clock spine
[18:14:17] -!- mackerski has quit [Quit: mackerski]
[18:16:12] <pcw_home> (clock skew is especially bad for hold time in your SRs)
[18:16:41] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 20.0/20130329043827]]
[18:17:53] -!- odogono has quit [Ping timeout: 240 seconds]
[18:18:36] -!- andypugh [andypugh!~andy2@cpc16-basl9-2-0-cust685.20-1.cable.virginmedia.com] has joined #linuxcnc-devel
[18:21:34] <skunkworks> emco lathe will do 40ipm
[18:22:53] <cradek> that's probably enough for threading
[18:23:03] <skunkworks> yes
[18:23:35] <skunkworks> that is about the limit...
[18:24:04] <seb_kuzminsky> that's great :-)
[18:29:38] -!- CaptHindsight has quit [Quit: gone]
[18:34:36] -!- CaptHindsight [CaptHindsight!~2020@unaffiliated/capthindsight] has joined #linuxcnc-devel
[18:38:48] -!- enty has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
[18:39:20] -!- MattyMatt has quit [Ping timeout: 245 seconds]
