#linuxcnc-devel Logs

Jul 03 2019

05:20 AM Tom_itx is now known as Tom_L
08:28 AM -!- #linuxcnc-devel mode set to +v by ChanServ
08:28 AM -!- #linuxcnc-devel mode set to +v by ChanServ
12:35 PM CaptHindsight: looks like this is what they will release for official Debian 10 Buster this weekend https://lists.debian.org/debian-devel-announce/2019/07/msg00001.html
02:46 PM andypugh: seb_kuzminsky: cradek jepler Is there a script for creating the Packages file in www.linuxcnc.org/dists ?
03:16 PM seb_kuzminsky: andypugh: yes, hold on i'll dig it up
03:17 PM seb_kuzminsky: https://github.com/LinuxCNC/infrastructure
03:17 PM seb_kuzminsky: when i update the deb archive, i follow this process:
03:18 PM seb_kuzminsky: 1. make/refresh a local copy of the current deb archive, `sync --progress --max-delete=0 -av -e "ssh -C -i $HOME/.ssh/id_dsa" "$@" emcboard@linuxcnc.org:www.linuxcnc.org/dists/ dists`
03:19 PM seb_kuzminsky: 2. add the new packages to the correct directories of my local copy. It's important to add source packages (.dsc etc) for any binary packages (.deb) that you add
03:21 PM seb_kuzminsky: 3. update the deb archive metadata using a script that isn't in infrastructure.git but should be (hold on and i'll add it...)
03:23 PM seb_kuzminsky: 4. rsync your local deb archive back to wlo, OVERWRITING whatever was there before, `rsync -av -e "ssh -C -i $HOME/.ssh/id_dsa" dists emcboard@linuxcnc.org:www.linuxcnc.org/`
03:23 PM seb_kuzminsky: at that point the new packages will be visible and accessible to people running "apt update" and similar
03:24 PM andypugh: OK, so you run the metadata script locally? The online advice seemed to be to run it on the server
03:24 PM andypugh: (Which I imagine might make a better job of “Maintainer” etc
03:28 PM andypugh: Did you mean “rsync” ?
03:33 PM seb_kuzminsky: i just pushed a couple of scripts to the linuxcnc infrastructure repo which are what i've been using to maintain the deb archive
03:33 PM andypugh: Looking at them now
03:33 PM seb_kuzminsky: yes, i do all my work locally, and use rsync to synchronize with the real deb archive at wlo
03:34 PM seb_kuzminsky: (1) above is the `rsync-from-wlo` script
03:34 PM seb_kuzminsky: 2 is manual
03:34 PM seb_kuzminsky: 3 is the `update-deb-archive` script
03:34 PM seb_kuzminsky: 4 is the `rsync-to-wlo` script
03:34 PM andypugh: your sync command, when changed to “rsync” asks for a password rather than using mu ssh key.
03:35 PM seb_kuzminsky: oh, yeah, (1) should be rsync, or just call the rsync-from-wlo script
03:35 PM seb_kuzminsky: these are the scripts i personally used, they may need tweaking to work right for you (in which case let's make them work for both of us somehow)
03:36 PM seb_kuzminsky: as you can see, the rsync (both to and from wlo) use `ssh -C -i $HOME/.ssh/id_dsa`, so if that's not the correct ssh key for you we'll have to change it
03:37 PM seb_kuzminsky: oh, i should also mention this... i actually used a slightly different workflow than the 4-step thing i typed above
03:37 PM andypugh: id_rsa …
03:38 PM seb_kuzminsky: i have a local long-lived copy of the wlo deb archive, which i've checked into git, much to the amusement of cradek
03:38 PM seb_kuzminsky: thus step 1.5 above is to "git diff" what i have locally with what i just rsynced from wlo, and committing any new packages and Contents/Release/Release.gpg files i just rsynced
03:39 PM seb_kuzminsky: then as step 2.5 i can `git diff` and see what i'm about to add
03:39 PM seb_kuzminsky: and as step 3.5 i can `git diff` again to sanity-check myself before rsyncing to wlo
03:39 PM andypugh: Sounds like something to try when I get more familiar with the process.
03:39 PM andypugh: At the moment I am flying-by-google
03:39 PM seb_kuzminsky: (and as step 4.5 i `git commit` my new deb archive state, to keep in synch with wlo)
03:40 PM seb_kuzminsky: you do you :-)
03:40 PM seb_kuzminsky: so maybe we should change the two rsync scripts to take the ssh key as an argument, or look for both my old one and your new one, or something... i'm open to suggestions there
03:41 PM andypugh: I may be making something of a mistake doing all this on the machine that I anticipate wiping to test .iso files…
03:42 PM andypugh: Make it 4 scripts? One for dsa one for rsa?
03:42 PM andypugh: rsync is now as far as dapper/emc2.3
03:43 PM andypugh: I wonder if we should consider pruning the dists…
03:56 PM seb_kuzminsky: i should probably update my wlo ssh key to the modern id_rsa, then we don't have to solve this problem until later
03:56 PM seb_kuzminsky: about pruning the dists, i think that's probably a good idea... i bet nobody uses breezy or dapper these days
03:57 PM seb_kuzminsky: there may still be some people on hardy, but we haven't supported hardy since 2.5 so we can probably archive that too
03:58 PM seb_kuzminsky: according to http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MinimumSoftwareVersions we still support 2.7 on lucid
03:58 PM seb_kuzminsky: 2.8 supposedly supports precise and newer
03:58 PM Tom_L: lucid was the one before wheezy wasn't it?
04:01 PM andypugh: It might be interesting to try building 2.8 on Hardy.
04:01 PM andypugh: It might even work.
04:02 PM seb_kuzminsky: i updated the rsync scripts to use id_rsa instead of id_dsa
04:02 PM seb_kuzminsky: i think it would be much more useful to try to get 2.7 to run on buster, rather than on old distros
04:03 PM seb_kuzminsky: i turned off the hardy buildslaves when we stopped supporting hardy, fwiw
04:11 PM andypugh: I am rather expecting that 2.8 would be on a Buster LiveCD
04:13 PM andypugh: Are you on the Live-Build mailing list
04:13 PM andypugh: ?
04:24 PM seb_kuzminsky: i'm not on the Live-Build mailing list
04:30 PM andypugh: It was sent an invitation last week to try the Buster ISO files on release day
04:30 PM andypugh: (and there was a request for folk to try bere metal installs on things like MIPS and PowerPC.
04:32 PM andypugh: I used to have a MIPS machine, but I doin’t think it would work, and it had no optical drive: https://en.wikipedia.org/wiki/Whitechapel_Computer_Works (I had a Whitechape Hitec-20. It is now with a friend as an interesting pieve of computer history)
04:33 PM seb_kuzminsky: how's the new memfrob rtai kernel working? have you tried running runtests in a loop?
04:34 PM andypugh: I ran runtests last night and failed 7.
04:34 PM andypugh: I _think_ this was an artefact of changing -RTAI to -rtai in the kernel version as you can’t make debs with caps.
04:35 PM andypugh: Prior to that I booted and ran LinuxCNC and ran the latency test.
04:36 PM andypugh: Today I started from scratch to avoid that tangle
04:38 PM pcw_mesa: I have a MIPS machine running our local DNS, but I dont think buster will work on a R2000...
04:38 PM andypugh: How about this one? https://www.ebay.co.uk/itm/WHITECHAPEL-MG-1-Computer-Milliard-Gargantubrain-Hitchhikers-Guide-Galaxy/223054856191?hash=item33ef1affff:g:D74AAOSw9N1VuL~P
04:38 PM andypugh: I think it might be over-riced
04:39 PM pcw_mesa: probably not many around
04:39 PM memfrob: what is runtests and what does it do?
04:41 PM seb_kuzminsky: memfrob: runtests runs the linuxcnc test suite
04:41 PM seb_kuzminsky: back when i was trying to get the rtai.org rtai to run, it would sometimes lock up while unloading the rtai modules after a runtests run
04:41 PM memfrob: ok, if any are failing it's due to the changes in the 4.14 kernel
04:41 PM memfrob: rtai.org is a lost cause
04:42 PM seb_kuzminsky: i could trigger the problem reliably by running runtests in a big loop and coming back an hour later
04:42 PM pcw_mesa: Wow the WhiteChapel is a NatSemi 32016 machine...
04:42 PM memfrob: how quickly does linuxcnc load and unload modules?
04:42 PM memfrob: (during runtests)
04:43 PM seb_kuzminsky: it loads the modules right when you start each test, then unloads the modules when the test finishes
04:43 PM seb_kuzminsky: different tests take different amounts of time between start/load and finish/unload
04:43 PM memfrob: lcnc@lcnc:~/linuxcnc$ runtests Running test: /home/lcnc/linuxcnc/tests/abort/feed-rate *** /home/lcnc/linuxcnc/tests/abort/feed-rate: FAIL: test run exited with 255
04:43 PM memfrob: the first test failed for me lol
04:46 PM memfrob: system just crashed. linuxcnc needs to fully recognize the 4.14 kernel first before running those
04:46 PM memfrob: linuxcnc with preempt_rt vs. linuxcnc with rtai compiles differently and how the drivers get built
04:47 PM memfrob: linuxcnc never ran on an RTAI kernel this new and needs updated API changes to fit the new kernel
04:47 PM seb_kuzminsky: how different is your rtai from rtai.org's 5.0? i updated linuxcnc to run on rtai 5.0 but nothing since then
04:48 PM memfrob: it's 5.2 with a lot of tweaks for linuxcnc and countless kernel bug fixes from myself and xenomai
04:48 PM andypugh: memfrob: I did a lot better.
04:48 PM andypugh: I failed 7 out of 255
04:48 PM memfrob: I also don't think it's very good that i'm getting this many compiling warnings when building linuxcnc: http://dpaste.com/0P1E452
04:49 PM memfrob: GCC 8.3.0
04:49 PM memfrob: what's your gcc version, andypugh ?
04:49 PM andypugh: Something odd there, it builds cleam for me
04:49 PM memfrob: (this is sid)
04:49 PM andypugh: gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
04:49 PM memfrob: ah
04:50 PM seb_kuzminsky: our gcc versions are listed here: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MinimumSoftwareVersions
04:50 PM seb_kuzminsky: newer versions of gcc tend to do a better job of pointing out sketchy bits of code, so it's not surprising that building with a newer gcc warns a lot
04:51 PM seb_kuzminsky: i don't think it's indicative of errors in the code base, generally
04:51 PM seb_kuzminsky: buster has gcc 8.3 too, btw
04:51 PM memfrob: different versions of gcc have different optimization passes and internal changes which can affect generated code
04:52 PM seb_kuzminsky: i agree
04:52 PM memfrob: those warnings aren't anything to worry about?
04:52 PM seb_kuzminsky: i didn't mean to say they're nothing to worry about
04:53 PM memfrob: ok after rebooting the machine, runtests iss fine
04:53 PM seb_kuzminsky: i just mean, they don't necessarily mean the code will build "wrong"
04:53 PM memfrob: oh i see
04:53 PM memfrob: *is
04:54 PM memfrob: before i hacked at rtai 5.2, i was getting overruns and incredibly bonkers latency test scores
04:55 PM memfrob: so in about an hour, it should crash? andypugh did it crash for you? or just fail 7?
04:57 PM seb_kuzminsky: that was my experience with rtai.org's 5.0(ish), yes
04:57 PM seb_kuzminsky: and by "crash" i mean, the rmmod would hang, but the rest of the system would stay up
04:58 PM memfrob: while true ; do runtests ; done ?
04:59 PM seb_kuzminsky: yep!
04:59 PM memfrob: how will i know when rmmod hangs? will it output to the term?
04:59 PM seb_kuzminsky: the runtests script will stop making progress
05:00 PM seb_kuzminsky: then in another terminal i would see with pstree that runtests was waiting on an rmmod process that was not making progress
05:00 PM memfrob: and dmesg is now filled with RTAI spam lol
05:00 PM seb_kuzminsky: mmm, spam
05:01 PM seb_kuzminsky: one of the trendy ramen retaurants in my town offers a spam ramen, i haven't tried it yet
05:01 PM memfrob: i think on x86, compiling the kernel without printk doesn't even boot
05:03 PM memfrob: so stretch and buster both have gcc 6, but buster doesn't have that python library you were talking about yesterday?
05:03 PM memfrob: python-gtksourceview2
05:04 PM seb_kuzminsky: no, stretch has gcc 6.3 but buster has gcc 8.3
05:04 PM seb_kuzminsky: and yes, buster does not have python-gtksourceview2
05:06 PM memfrob: ah buster has 8.3 and you got linuxcnc going with that really well so the compiler is good
05:07 PM seb_kuzminsky: yeah, exactly
05:07 PM seb_kuzminsky: i run linuxcnc in sim on my buster laptop all day long
05:08 PM seb_kuzminsky: i haven't tried to run real hardware with linuxcnc rt-preempt on buster, but i'd expect it to work just fine
05:08 PM memfrob: there was talk about someone having issues with controlling hardware but the sim itself was fine?
05:08 PM seb_kuzminsky: i don't know anything about that
05:08 PM seb_kuzminsky: part of my awol-ness is not paying attention to bug reports and conversations on the -users mailing list any more :-/
05:10 PM memfrob: only 5 pages of bugs isn't bad, and more than half of those have a fix or workaround in the comments
05:12 PM memfrob: with preempt_rt does linuxcnc still build the parport drivers and such?
05:12 PM seb_kuzminsky: yes
05:12 PM memfrob: ok, are any drivers rtai specific?
05:12 PM seb_kuzminsky: no, not that i know of
05:13 PM memfrob: ok thanks!
05:13 PM memfrob: a question andypugh had was about math support, why does linuxcnc when built for rtai need an rtai math module?
05:14 PM seb_kuzminsky: some of our realtime drivers need to do math
05:14 PM memfrob: but with preempt_rt they don't?
05:14 PM seb_kuzminsky: with preempt-rt they do math in userspace, the normal way
05:15 PM seb_kuzminsky: the linux kernel doesn't have a math library in it, but of course userland does
05:15 PM memfrob: what prevents linuxcnc from using rtai with userspace normal math?
05:16 PM memfrob: how RTAI works in my linuxcnc branch is that it links rtai_math.ko to integrated musl c library
05:16 PM memfrob: but if a system has musl or glibc, it seems redundant
05:16 PM seb_kuzminsky: our rtai build uses the kernel-mode rtai "processes", so userspace isn't accessible
05:17 PM memfrob: doesn't the preempt build still use kbuild though?
05:17 PM seb_kuzminsky: no, it doesn't
05:17 PM memfrob: ohh
05:18 PM seb_kuzminsky: our realtime stuff under rtpreempt runs as realtime userspace processes
05:18 PM memfrob: that's why the 8255 driver had a compiling error with rtai but not preempt_rt
05:18 PM memfrob: got it, now it all makes sense
05:18 PM memfrob: you need math in kernel space and that's what rtai_math is for, but you only use kernel space with rtai
05:19 PM andypugh: I thought the 8255 driver was a READ WRITE macro clash?
05:19 PM memfrob: well yes but that was related to kernel code
05:19 PM memfrob: the clash doesn't exist in userspace
05:19 PM andypugh: Odd
05:19 PM andypugh: Easy fix though, even I could fix it :-)
05:20 PM memfrob: well if in the kernel, you define READ and WRITE, but in glibc, you don't, you won't get the problem in userspace
05:20 PM memfrob: that's what you told me, is that there was a clash with the kernel code.
05:20 PM andypugh: rtapi_math also limits you to known-threadsafe functions. As I understand it.
05:21 PM memfrob: and it uses very little of what rtai_math provides..
05:23 PM memfrob: no complex numbers
05:24 PM memfrob: could there be an instance where linuxcnc would need more math functions that it already has?
05:24 PM memfrob: because one way i could silence a lot of those undefined symbols is removing the unused ones in rtai_math
05:25 PM memfrob: (the harmless annoying warnings during build)
05:26 PM seb_kuzminsky: we have a test called tests/realtime-math that exercises the realtime math functions that we claim to support
05:27 PM memfrob: i'll check that out, btw Runtest: 227 tests run, 227 successful, 0 failed + 0 expected
05:27 PM memfrob: there was this btw Running test: /home/lcnc/linuxcnc/tests/module-loading/rtapi-app-main-fails loadrt found the test component, and it failed to load
05:27 PM andypugh: Yes, I thought that my problems were just a kernel name string thing
05:28 PM seb_kuzminsky: that module-loading message is correct and expected (but maybe misguided in existing in the first place)
05:29 PM memfrob: tests/realtime-math's readme file should say how to run it..
05:31 PM memfrob: halcompile: command not found but i'm in rip-environment
05:31 PM seb_kuzminsky: all the tests run the same way, via runtests
05:31 PM memfrob: oh!
05:32 PM memfrob: well it passed
05:35 PM andypugh: I am a bit stuck making the RTAI package as the machine is still in the middle of rsync-ing every LinuxCNC .deb ever, so I can’t reboot into the RTAI kernel.
05:35 PM seb_kuzminsky: one of the great things with rsync is you can ^C it in the middle and next time you run it it'll pick up where it left off
05:36 PM memfrob: would there be a theoretical reason as to how in the future that linuxcnc would eventually depend on complex numbers or other math functions?
05:36 PM andypugh: OK, then perhaps I should do that
05:36 PM andypugh: memfrob: Not that I can think of. And if it did, you could always fake it.
05:37 PM andypugh: It’s not hard to write your own complex maths functions.
05:39 PM CaptHindsight: just don't try to write functions for un-real numbers
05:39 PM andypugh: We already have a Park-Clarke transform component that doesn’t use external complex maths. And if anything was going to, it would be that.
05:40 PM andypugh: I wrote the bldc component without needing them (or, in fact, using Park-Clarke which many would consider mandatory, but in fact is unnecessary)
05:42 PM andypugh: complex numbers are just a cunning way to have a 2-dimensional number line. You can go 3D with quaternions. But it’s all just mathermatical shorthand to avoid drowning in Sin and Cos functions.
05:48 PM memfrob: https://github.com/NTULINUX/RTAI/commit/bae529bbed658450e1d89b859a84c31328676342
05:48 PM memfrob: looks good?
05:51 PM andypugh: probably, but I just built my debs!
05:51 PM memfrob: sorry!!
05:53 PM memfrob: linuxcnc might use signbit which i removed but it didn't complain
05:53 PM memfrob: src/rtapi/rtapi_math.h:#define signbit(x) __builtin_signbit((x))
05:54 PM memfrob: actually how is that working?
05:54 PM andypugh: Is this a kernel patch change or just an RTAI change?
05:54 PM memfrob: RTAI change only, but i might have made a mistake
05:55 PM andypugh: No worries, RTAI build is still not startted, I only just booted in to the right kernel
05:56 PM memfrob: linuxcnc built against with no problems but i removed EXPORT_SYMBOL(__signbit);
05:57 PM memfrob: latency-test works too
05:59 PM memfrob: EXPORT_SYMBOL(nan); is also gone, but in rtapi_math.h -> #define nan(x) __builtin_nan((x))
06:10 PM memfrob: andypugh, how did you get such a good background in math?
06:11 PM andypugh: I did physics at college
06:12 PM andypugh: (and during my PhD I came across the “Reciprocal effective mass Tensor” but could happily ignore and never use it.
06:19 PM andypugh: memfrob: Finished for the moment?
06:19 PM memfrob: well i dont know if i should revert that last commit or not
06:19 PM memfrob: does __builtin_nan((x)) mean not use rtai_math.ko?
06:20 PM andypugh: I really have no idea
06:20 PM memfrob: i'll revert it then
06:20 PM memfrob: ok, done
06:23 PM memfrob: __builtin usually means "grab this from a GCC built-in"
06:24 PM memfrob: but i don't want to risk it for your debs
06:32 PM andypugh: I doubt these are the final build, I am really just trying to work out how to do this
06:33 PM memfrob: it's mostly copypaste+delete from seb's stuff
06:34 PM memfrob: he made it easy for you!
06:37 PM andypugh: well, in theory. In practice I am confused
06:39 PM andypugh: https://paste.ubuntu.com/p/Wk2xPbVBGK/
06:39 PM memfrob: are you in the rtai directory?
06:40 PM andypugh: Yes
06:40 PM andypugh: (one below debian)
06:42 PM andypugh: Though, looking, it isn’t wrong….
06:42 PM andypugh: I will grab sebs stuff again, looks like I lost some files
06:45 PM memfrob: heh!
06:45 PM memfrob: that'll do it
06:53 PM memfrob: Once you get this going, I'll add the debian folder into the git tree
07:01 PM memfrob: I was right about the __builtin functions: GCC provides fpclassify, isfinite, isinf_sign, isnormal and signbit built-ins used with __builtin_ prefixed. The isinf and isnan built-in functions appear both with and without the __builtin_ prefix.
07:02 PM memfrob: so when linuxcnc calls nan, it uses gcc's nan, not anything to do rtai_math or embedded musl
07:02 PM memfrob: so that commit was actually fine
07:02 PM memfrob: https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
07:02 PM memfrob: the final debs should have that math commit in there so it doesn't pollute the terminal as much with useless warnings
07:03 PM memfrob: these aren't the final ones so nothing to worry about
07:03 PM memfrob: wait, why not just do that for all of them?
07:05 PM memfrob: you could just drop rtai_math entirely if you just #define <all your math here> as __builtin_<said math function here>
07:06 PM memfrob: Using kbuild and building things in kernel space doesn't take away from GCC's built-in functions
07:07 PM andypugh: I really do not know enough to anwer that question.
07:07 PM andypugh: Jepler is your man for that, I think.
07:08 PM memfrob: i thought jepler was long gone, he's in the channel? what??
07:09 PM memfrob: i didn't even realize
07:14 PM memfrob: well i found really good example code: https://github.com/numworks/epsilon/blob/master/liba/include/math.h
07:19 PM memfrob: Ok, I have no idea what i'm doing I guess: WARNING: "sincos" [/home/lcnc/linuxcnc/src/5axiskins.ko] undefined!
07:24 PM andypugh: memfrob: PM…
07:27 PM memfrob: so as long as I don't patch sin or cos, it seems to be fine
07:31 PM memfrob: http://dpaste.com/1MDX6RA
07:33 PM memfrob: fmin and fmax need to be there because they aren't GCC built ins
07:34 PM andypugh: That might be a really good idea, but I really feel unqualified to opinionate.
07:34 PM memfrob: Well the GCC docs say they are, but the example code doesn't define fmin and fmax that way
07:35 PM memfrob: andypugh, I'm unqualified too, I'm just guessing that this is a better approach, because well.. who doesn't trust GCC to handle math?
07:36 PM andypugh: I will email jepler, see what he thinks.
07:39 PM memfrob: ok so using this for reference now: https://android.googlesource.com/platform/bionic/+/master/libm/builtins.cpp fmin and fmax can be built-ins too
07:40 PM memfrob: so that just leaves linuxcnc with it's own sin and cos
07:41 PM andypugh: theres a magic “sincos” somewhere. Don’t know where, don’t know what, but I have seen it.
07:42 PM memfrob: git grep "sincos"
07:43 PM memfrob: and it's only a problem if sin and cos are from GCC
07:43 PM memfrob: And for some reason, not sure if this by mistake, but every single math function has x before y, except atan2
07:44 PM memfrob: no, not a mistake: https://en.wikipedia.org/wiki/Atan2
07:48 PM memfrob: ok here we go: http://dpaste.com/3ER2XX6
07:52 PM andypugh: push it, I will pull, let us see how it gies
07:53 PM andypugh: (goes)
07:54 PM memfrob: push the removal of all the symbols that linuxcnc doesn't need to RTAI?
07:54 PM memfrob: are we factoring in my usage of GCC built-ins in linuxcnc or no?
08:00 PM memfrob: ok my fmin and fmax lines are wrong
08:03 PM andypugh: No rushm 2am here, I have run out of steam.
08:04 PM memfrob: I just don't know what you want me to push
08:04 PM andypugh: No, neither do I.
08:04 PM andypugh: :-)
08:04 PM memfrob: hahaha!
08:05 PM memfrob: good night andypugh, always a fun time
08:06 PM andypugh: I am currently unsure how to build the debs from the sebkuzinsky repo. Configure worked, but …
08:22 PM memfrob: I GOT IT!
08:24 PM memfrob: How to use fmin and fmax built-ins: http://dpaste.com/0NNDHGH
08:25 PM memfrob: static inline because extern __inline has those undefined symbols
08:26 PM memfrob: So now the only thing left really is sin and cos (sincos, magic)
08:27 PM memfrob: I'm pretty sure that patch is right, but #define fmax and #define fmin then double fmax just seems odd to me
08:27 PM memfrob: (and double fmin too)
08:27 PM andypugh: I would love to have an opinion, but…
08:28 PM memfrob: I know, same here
08:53 PM memfrob: where are the logs stored so i can come back to this?
08:53 PM memfrob: ah
08:54 PM Tom_L: or index
08:56 PM norias: hi
08:57 PM memfrob: welcome back norias!
08:57 PM norias: thanks
08:57 PM norias: i'm studing how CNC controllers work
08:58 PM norias: where can I get the linuxcnc source to read through?
09:00 PM Tom_L: github
09:01 PM Tom_L: https://github.com/LinuxCNC/linuxcnc
09:01 PM norias: oh, great, thanks
09:01 PM norias: i got a book, too
09:02 PM norias: so, this should be fun
09:02 PM hazzy-m: Tom_L: can you hear me?
09:02 PM norias: "Theory and Design of CNC Systems"
09:02 PM Tom_L: git clone if you're using git already
09:02 PM Tom_L: hazzy-m` no but i see you type
09:03 PM hazzy-m: lol, ok thanks. I just had to re identify
09:05 PM norias: oh man, so much code
09:14 PM CaptHindsight: https://buildbotics.com/