Back
[00:00:12] -!- logger[mah] has quit [Read error: Connection reset by peer]
[00:00:20] -!- logger[mah] [logger[mah]!~loggermah@ns2.mah.priv.at] has joined #linuxcnc-devel
[00:04:57] -!- rob_h has quit [Ping timeout: 256 seconds]
[00:05:33] -!- the_wench has quit [Ping timeout: 246 seconds]
[00:05:40] -!- archivist has quit [Ping timeout: 246 seconds]
[00:07:53] -!- zzolo has quit [Quit: zzolo]
[00:25:54] -!- andypugh has quit [Quit: andypugh]
[00:29:37] -!- jthornton has quit [Read error: Connection reset by peer]
[00:29:47] -!- jthornton [jthornton!~john@184.63.140.99] has joined #linuxcnc-devel
[00:41:24] -!- skunkworks__ [skunkworks__!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[00:41:47] -!- skunkworks_ has quit [Ping timeout: 256 seconds]
[00:52:00] zz_satyag is now known as satyag
[01:06:21] -!- micges has quit [Ping timeout: 244 seconds]
[01:06:21] -!- asdfasd has quit [Ping timeout: 252 seconds]
[01:07:42] -!- toastydeath has quit [Read error: No route to host]
[01:08:11] -!- mackerski has quit [Quit: mackerski]
[01:08:19] -!- micges [micges!~micges@adcy92.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[01:12:13] -!- mhaberler has quit [Quit: mhaberler]
[01:23:42] -!- servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[01:26:22] satyag is now known as zz_satyag
[01:31:23] -!- PCW has quit [Ping timeout: 245 seconds]
[01:31:29] PCW_ is now known as PCW
[01:38:41] -!- adb has quit [Ping timeout: 255 seconds]
[01:42:12] -!- r00t4rd3d has quit [Ping timeout: 250 seconds]
[01:47:18] -!- micges has quit [Quit: Leaving]
[01:55:08] -!- ve7it has quit [Remote host closed the connection]
[02:13:13] -!- ZinovaS has quit [Ping timeout: 265 seconds]
[02:42:21] -!- PCW has quit [Remote host closed the connection]
[02:54:31] -!- r00t4rd3d has quit [Changing host]
[02:55:18] -!- ZinovaS has quit [Read error: Operation timed out]
[03:07:19] -!- theos has quit [Ping timeout: 246 seconds]
[03:25:51] -!- r00t4rd3d has quit [Quit: Leaving]
[03:50:01] -!- sumpfralle has quit [Ping timeout: 246 seconds]
[04:01:08] -!- Keknom has quit [Quit: Leaving.]
[04:22:12] -!- Loetmichel has quit [Ping timeout: 248 seconds]
[04:23:46] -!- zzolo has quit [Quit: zzolo]
[04:31:47] <seb_kuzminsky> buildbot.linuxcnc.org:80 92.62.49.67 - - [29/Nov/2012:21:18:44 -0700] "GET /dists/$DIST/scratch-rt/binary-i386/Packages.bz2 HTTP/1.1" 404 319 "-" "Debian APT-HTTP/1.3 (0.8.10.3)"
[04:31:52] <seb_kuzminsky> sigh...
[05:18:08] -!- pfred1 has quit [Quit: Lost terminal]
[05:23:19] -!- mattions has quit [Ping timeout: 260 seconds]
[05:45:20] -!- tjb1 has quit [Quit: tjb1]
[05:47:51] -!- tjb1 has quit [Read error: Connection reset by peer]
[05:48:01] -!- mk0 has quit [Quit: Leaving]
[05:53:06] -!- kwallace [kwallace!~kwallace@tmb-227.sonnet.com] has parted #linuxcnc-devel
[06:01:49] -!- Fox_Muldr has quit [Ping timeout: 260 seconds]
[06:02:12] zz_satyag is now known as satyag
[06:02:57] -!- FinboySlick has quit [Quit: Leaving.]
[06:13:15] -!- art_ has quit [Quit: Page closed]
[06:17:51] satyag is now known as zz_satyag
[06:19:35] -!- automata has quit [Ping timeout: 260 seconds]
[06:23:36] zz_satyag is now known as satyag
[06:35:34] -!- jthornton has quit [Ping timeout: 246 seconds]
[06:35:47] -!- JT-Shop has quit [Ping timeout: 260 seconds]
[06:42:53] satyag is now known as zz_satyag
[06:43:16] -!- yuvipanda has quit [Ping timeout: 246 seconds]
[06:49:25] -!- dhoovie has quit [Ping timeout: 246 seconds]
[06:49:39] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[06:51:40] -!- Cylly has quit [Read error: Connection reset by peer]
[06:53:30] -!- yuvipanda has quit [Read error: Connection reset by peer]
[06:55:32] <seb_kuzminsky> screen -Dr
[06:55:44] <seb_kuzminsky> oops
[06:56:06] zz_satyag is now known as satyag
[06:56:27] -!- psha[work] [psha[work]!~psha@195.135.238.205] has joined #linuxcnc-devel
[06:57:58] satyag is now known as zz_satyag
[06:58:18] -!- yuvipanda has quit [Read error: Connection reset by peer]
[07:16:24] -!- cmorley1 [cmorley1!~chris@S010600c09fc019c2.no.shawcable.net] has joined #linuxcnc-devel
[07:19:11] -!- cmorley has quit [Ping timeout: 256 seconds]
[07:22:22] -!- yuvipanda has quit [Ping timeout: 250 seconds]
[07:27:26] -!- theorb_ has quit [Quit: Lost terminal]
[07:27:44] -!- yuvipanda has quit [Read error: Connection reset by peer]
[07:44:18] -!- capricorn_one has quit [Read error: Connection reset by peer]
[07:44:19] -!- theorb has quit [Read error: Connection reset by peer]
[07:44:23] -!- Aero-Tec has quit [Ping timeout: 260 seconds]
[07:44:23] -!- Vq has quit [Ping timeout: 260 seconds]
[07:44:37] Aero-Tec_ is now known as Aero-Tec
[07:44:51] -!- Farthen has quit [Ping timeout: 260 seconds]
[07:47:11] -!- yuvipanda has quit [Ping timeout: 260 seconds]
[07:51:31] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[07:53:05] -!- factor has quit [Read error: Connection reset by peer]
[07:54:24] -!- Tugge has quit [Ping timeout: 260 seconds]
[08:11:28] -!- the_wench has quit [Ping timeout: 246 seconds]
[08:12:17] -!- archivist has quit [Ping timeout: 256 seconds]
[08:20:33] -!- bmwyss has quit [Read error: Connection reset by peer]
[08:20:33] bmwyss_ is now known as bmwyss
[08:32:43] Jymmm is now known as Jymmmmmmmmm
[08:37:08] Jymmmmmmmmm is now known as Jymmm
[08:39:38] -!- cmorley [cmorley!~chris@S010600c09fc019c2.no.shawcable.net] has joined #linuxcnc-devel
[08:41:23] -!- cmorley2 [cmorley2!~chris@S010600c09fc019c2.no.shawcable.net] has joined #linuxcnc-devel
[08:42:28] -!- cmorley1 has quit [Ping timeout: 248 seconds]
[08:44:05] -!- cmorley has quit [Ping timeout: 255 seconds]
[08:47:04] -!- karavanjoW has quit [Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/]
[08:51:25] -!- emel has quit [Excess Flood]
[08:57:07] -!- rob_h [rob_h!~rob_h@027c009b.bb.sky.com] has joined #linuxcnc-devel
[09:01:42] -!- racycle has quit [Quit: racycle]
[09:48:58] -!- dhoovie|2 has quit [Ping timeout: 246 seconds]
[09:57:56] -!- yuvipanda has quit [Quit: yuvipanda]
[10:16:37] -!- dhoovie has quit [Ping timeout: 246 seconds]
[10:21:12] -!- jthornton [jthornton!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[10:21:20] -!- JT-Shop [JT-Shop!~John@184.63.140.99] has joined #linuxcnc-devel
[10:51:50] -!- yuvipanda has quit [Ping timeout: 246 seconds]
[10:52:41] -!- Farthen has quit [Excess Flood]
[11:09:49] -!- dhoovie has quit [Ping timeout: 246 seconds]
[11:17:52] -!- Oo_BIGeye has quit [Ping timeout: 246 seconds]
[11:32:33] -!- tayy has quit [Remote host closed the connection]
[11:39:55] -!- dhoovie has quit [Ping timeout: 246 seconds]
[12:01:28] -!- Poincare has quit [Ping timeout: 246 seconds]
[12:02:07] -!- jst has quit [Ping timeout: 246 seconds]
[12:06:52] _Poincare is now known as Poincare
[12:10:27] -!- maximilian_h [maximilian_h!~bonsai@p549DF622.dip.t-dialin.net] has joined #linuxcnc-devel
[12:10:31] -!- maximilian_h has quit [Client Quit]
[12:15:12] -!- dhoovie|2 has quit [Read error: Connection reset by peer]
[12:20:36] <KGB-linuxcnc> 03jthornton 05v2.5_branch c92eccc 06emc2 10docs/src/common/python-interface.txt * Docs: correct mode names
[12:24:56] -!- r00t4rd3d has quit [Quit: Leaving]
[12:38:54] -!- cncbasher [cncbasher!~quassel@cpc15-hart9-2-0-cust101.11-3.cable.virginmedia.com] has joined #linuxcnc-devel
[12:42:26] -!- toastydeath has quit [Read error: Connection reset by peer]
[13:03:48] -!- sumpfralle has quit [Ping timeout: 264 seconds]
[13:04:18] -!- djheinzNO has quit [Ping timeout: 264 seconds]
[13:09:15] -!- alpha1125 has quit [Quit: Computer has gone to sleep.]
[13:40:07] -!- cncbasher has quit [Ping timeout: 246 seconds]
[13:40:54] -!- mattions has quit [Ping timeout: 260 seconds]
[13:53:39] -!- yuvipanda has quit [Quit: yuvipanda]
[13:56:52] -!- yuvipanda has quit [Client Quit]
[14:03:49] zz_satyag is now known as satyag
[14:07:36] -!- mozmck has quit [Quit: Leaving.]
[14:07:57] -!- abetusk has quit [Quit: Leaving]
[14:09:02] -!- mozmck [mozmck!~moses@client-204.235.45.161.wcfltx.partnershipbroadband.com] has joined #linuxcnc-devel
[14:15:45] -!- psha[work] has quit [Quit: Lost terminal]
[14:19:50] -!- automata has quit [Ping timeout: 255 seconds]
[14:20:34] -!- Simooon has quit [Remote host closed the connection]
[14:39:27] <seb_kuzminsky> linuxcnc-build: notify on failure
[14:39:27] <linuxcnc-build> The following events are being notified: ['failure']
[14:58:22] -!- mk0 has quit [Quit: Looking for access to www.icdd.com bases.]
[15:01:14] <cradek> !!
[15:01:36] <cradek> jmk's buildbot used to do that - it was great.
[15:09:23] -!- morfic has quit [Ping timeout: 246 seconds]
[15:09:43] <seb_kuzminsky> there's a bunch of things you can have it talk about
[15:09:57] <seb_kuzminsky> msg it "commands" for a list, if you care ;-)
[15:10:32] -!- jthornton has quit [Read error: Connection reset by peer]
[15:10:35] -!- jthornton_ [jthornton_!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[15:10:37] -!- JT-Shop has quit [Read error: Connection reset by peer]
[15:10:56] -!- JT-Shop [JT-Shop!~John@184.63.140.99] has joined #linuxcnc-devel
[15:11:45] <cradek> cool
[15:12:24] <seb_kuzminsky> i'm having trouble with linuxcncrsh
[15:12:36] <seb_kuzminsky> i love the idea, but the implementation leaves some to be desired
[15:12:59] <seb_kuzminsky> any other suggestions for how to drive linuxcnc via a script that simulates a gui?
[15:14:39] <cradek> just twiddle halui with halcmd?
[15:15:20] <seb_kuzminsky> i thought about that, but i'd give up the ability to have the script generate the mdi commands
[15:15:29] <seb_kuzminsky> halui requires you to pre-define the mdi commands in the .ini file
[15:15:42] <cradek> oh yeah, guess so.
[15:15:54] <seb_kuzminsky> is there a python gui library?
[15:16:49] <cradek> sure, axis has a python abstraction
[15:17:48] <cradek> http://emergent.unpythonic.net/01167419757
[15:20:09] <seb_kuzminsky> thanks
[15:20:34] <seb_kuzminsky> that may be better than what i'm doing now, which is a lot of fighting with linuxcncrsh
[15:21:22] <cradek> yeah, bet so
[15:30:30] -!- SWPadnos_ [SWPadnos_!~Me@74-92-8-208-NewEngland.hfc.comcastbusiness.net] has joined #linuxcnc-devel
[15:31:00] -!- asdfasd has quit [Ping timeout: 248 seconds]
[15:33:18] -!- SWPadnos has quit [Ping timeout: 246 seconds]
[15:33:19] SWPadnos_ is now known as SWPadnos
[15:33:23] asdfas is now known as asdfasd
[15:40:43] -!- cradek has quit [Remote host closed the connection]
[15:40:44] -!- KGB-linuxcnc has quit [Quit: KGB-linuxcnc]
[15:45:52] -!- KGB-linuxcnc [KGB-linuxcnc!~kgb-linux@git.linuxcnc.org] has joined #linuxcnc-devel
[15:45:56] -!- cradek [cradek!~chris@outpost.timeguy.com] has joined #linuxcnc-devel
[15:46:11] -!- cradek has quit [Changing host]
[15:46:12] -!- cradek [cradek!~chris@emc/board-of-directors/cradek] has joined #linuxcnc-devel
[15:46:12] -!- mode/#linuxcnc-devel [+v cradek] by ChanServ
[15:48:27] satyag is now known as zz_satyag
[15:50:59] zz_satyag is now known as satyag
[15:55:10] -!- elmo40 has quit [Quit: Leaving.]
[16:08:43] <KGB-linuxcnc> 03seb 05v2.5_branch 52f83e5 06emc2 10tests/ 10linuxcncrsh/expected-gcode-output 10linuxcncrsh/lots-of-gcode 10linuxcncrsh/test.sh * improve the linuxcncrsh big-blob test
[16:08:43] <KGB-linuxcnc> 03seb 05v2.5_branch 24f0768 06emc2 10src/emc/usr_intf/emcrsh.cc * fix a 'lost message' bug in linuxcncrsh
[16:09:10] * seb_kuzminsky throws up in his mouth a little
[16:11:18] <skunkworks> that bad?
[16:15:10] <cradek> emcrsh.cc has all the worst smells of C stirred together into one file
[16:16:08] <skunkworks> heh
[16:18:42] -!- kwallace [kwallace!~kwallace@smb-61.sonnet.com] has joined #linuxcnc-devel
[16:27:08] -!- psha [psha!~psha@213.208.162.92] has joined #linuxcnc-devel
[16:29:00] -!- bmwyss has quit [Ping timeout: 264 seconds]
[16:29:29] -!- bmwyss_ has quit [Ping timeout: 260 seconds]
[16:37:46] -!- Tecan has quit [Quit: live long and phosphor]
[16:41:32] -!- factor has quit [Read error: Connection reset by peer]
[16:42:04] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 16.0.2/20121025205401]]
[16:54:01] -!- SWPadnos has quit [Read error: Connection reset by peer]
[16:54:42] -!- SWPadnos [SWPadnos!~Me@74-92-8-208-NewEngland.hfc.comcastbusiness.net] has joined #linuxcnc-devel
[17:02:18] -!- steves_logging has quit [Ping timeout: 256 seconds]
[17:03:33] -!- steves_logging [steves_logging!~Steve@wsip-70-168-134-18.dc.dc.cox.net] has joined #linuxcnc-devel
[17:05:42] -!- SWPadnos_ [SWPadnos_!~Me@74-92-8-208-NewEngland.hfc.comcastbusiness.net] has joined #linuxcnc-devel
[17:08:00] -!- SWPadnos has quit [Ping timeout: 246 seconds]
[17:08:01] -!- Thetawaves has quit [Ping timeout: 246 seconds]
[17:08:14] SWPadnos_ is now known as SWPadnos
[17:14:25] -!- Simon2 has quit [Read error: Connection reset by peer]
[17:15:44] satyag is now known as zz_satyag
[17:22:22] -!- cevad has quit [Quit: Leaving]
[17:22:22] -!- andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust639.basl.cable.virginmedia.com] has joined #linuxcnc-devel
[17:36:17] -!- ve7it [ve7it!~LawrenceG@S0106001c10b7770f.pk.shawcable.net] has joined #linuxcnc-devel
[18:05:54] -!- automata has quit [Ping timeout: 255 seconds]
[18:06:57] -!- ve7it has quit [Remote host closed the connection]
[18:12:12] -!- capricorn_one has quit [Ping timeout: 264 seconds]
[18:41:38] -!- kmiyashiro has quit [Quit: kmiyashiro]
[18:47:17] -!- crib has quit [Read error: Operation timed out]
[18:48:59] -!- tjb1 has quit [Quit: tjb1]
[18:52:33] -!- adb [adb!~IonMoldom@178-211-235-11.dhcp.voenergies.net] has joined #linuxcnc-devel
[18:55:31] -!- adb has quit [Client Quit]
[18:55:39] -!- adb [adb!~IonMoldom@178-211-235-11.dhcp.voenergies.net] has joined #linuxcnc-devel
[18:56:23] -!- adb_ [adb_!~IonMoldom@178-211-235-11.dhcp.voenergies.net] has joined #linuxcnc-devel
[18:56:24] -!- IchGuckLive has quit [*.net *.split]
[18:56:24] -!- the_wench has quit [*.net *.split]
[18:56:24] -!- jst has quit [*.net *.split]
[18:56:24] -!- RyanS has quit [*.net *.split]
[18:56:25] -!- hewball has quit [*.net *.split]
[18:56:46] -!- gambakufu has quit [Ping timeout: 256 seconds]
[18:57:21] -!- adb_ has quit [Client Quit]
[18:57:22] -!- JT-Shop-2 [JT-Shop-2!~John@184.63.140.99] has joined #linuxcnc-devel
[18:57:26] -!- adb has quit [Client Quit]
[18:57:34] -!- adb [adb!~IonMoldom@178-211-235-11.dhcp.voenergies.net] has joined #linuxcnc-devel
[18:58:53] -!- adb_ [adb_!~IonMoldom@178-211-235-11.dhcp.voenergies.net] has joined #linuxcnc-devel
[18:59:35] -!- adb_ has quit [Client Quit]
[19:05:43] -!- JT-Shop has quit [Write error: Connection reset by peer]
[19:07:44] -!- tronwizard has quit [Ping timeout: 241 seconds]
[19:08:48] <mhaberler> I think the whole gamut of halcmd, halrmt, emcsh, emcrsh and friends should be replaced by Python once the core has an API definition worth speaking of (esp HAL), and it better be remote capable
[19:09:09] <mhaberler> there is no reason whatsoever to have huge C clunkers for that kind of purpose
[19:13:13] <andypugh> <Devil's advocate> There is no need to have the overhead of Python on such time-critical paths.
[19:13:36] <andypugh> Might as well just use VBA :-)
[19:18:21] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 16.0.2/20121025205401]]
[19:21:01] -!- theorbtwo has quit [Remote host closed the connection]
[19:23:46] * skunkworks still uses vba
[19:23:49] <andypugh> This chap:
http://www.linuxcnc.org/index.php/forum/38-general-linuxcnc-questions/25865-linux-cnc-going-commercial?start=18&lang=english#27106
[19:24:11] <andypugh> Says that there is no radius compensation in the Y-Z plane. Is that correct?
[19:24:47] <andypugh> I use VBA a great deal at work. I almost like it.
[19:26:17] <seb_kuzminsky> mhaberler: i prefer small C interface libraries. it's easy enough to wrap them in python if you want to later, but the lowest level interface should be C accessible
[19:27:06] <mhaberler> I did not say otherwise.
[19:27:21] <seb_kuzminsky> oh good
[19:28:38] <mhaberler> The API must be C of course, but it better be a messaging type API, not library calls - we need to get out of this 'everything has to run on a single CPU' thing
[19:30:37] <mhaberler> If you do it with the right tool, you get language bindings for free - e.g. protobufs for marshalling and zmq as middleware: every language worth considering has a binding for both
[19:32:02] <mhaberler> let me reword that: the API must be C accessible; with these tools it might not make sense to have one if you have the abstract representation compiled into language bindings anyway, that would be just a duplication
[19:33:28] <mhaberler> if you're interested I can dig out an example (not licensing compliant :-/) but you get the idea how the bits feel between the toes
[19:35:54] <seb_kuzminsky> i've never used protobufs, but i know trustworthy people who like them
[19:36:12] <seb_kuzminsky> i've used asn.1, which does a similar thing, and i wasnt too impressed
[19:36:55] <seb_kuzminsky> whatever communication mechanism we use, we should be careful about how we add external dependencies...
[19:37:29] <seb_kuzminsky> i really don't like forking other projects into our code, i'd much rather fit in to the existing software ecosystem (which currently means debian/ubuntu)
[19:37:57] <mhaberler> one has nothing to do with the other. Where is the forking?
[19:38:19] <seb_kuzminsky> we forked a2 in order to support asciidoc docs
[19:38:23] <seb_kuzminsky> i mean a2x
[19:38:27] <seb_kuzminsky> we have a copy of yapps
[19:38:29] <seb_kuzminsky> redis
[19:38:42] <mhaberler> right. Well, that is a homegrown problem I would say
[19:39:01] <seb_kuzminsky> i dont know what you mean by that
[19:39:26] <mhaberler> there's nobody you can blame for using 10.04 which is about to fall off the support cliff
[19:39:49] <mhaberler> the a2x issue is gone afaict in precise, isnt it?
[19:40:04] -!- Nick001 has quit [Ping timeout: 248 seconds]
[19:40:38] <seb_kuzminsky> yes, and jepler fixed it for the older distros too, by backporting the debs
[19:40:48] <mhaberler> redis: same thing; all this wouldnt be necessary if we could fastforward the distro
[19:40:57] <seb_kuzminsky> but we can't
[19:41:19] <mhaberler> why exactly - does precise not work decently with the current RTAI kernel? I never tried
[19:41:51] <seb_kuzminsky> i've tried it, and in the 30 minutes i played with it, it worked fine
[19:42:01] <mhaberler> so why cant we then?
[19:42:25] <mhaberler> problems with ubuntu updates?
[19:42:33] <seb_kuzminsky> http://thread.gmane.org/gmane.linux.distributions.emc.user/34836
[19:42:41] <seb_kuzminsky> we could, but there is a cost
[19:43:14] <seb_kuzminsky> by deviating from tested and known good software combinations, we introduce uncertainty
[19:43:29] <seb_kuzminsky> the support burden for these new systems fall heavier on us
[19:43:50] <seb_kuzminsky> not all our users are as good at debugging platform problems as you are ;-)
[19:43:54] <mhaberler> now you see why I'm putting so much effort into alternatives;)
[19:44:04] <seb_kuzminsky> oh i know why you're doing it
[19:44:16] <mhaberler> ?
[19:44:32] <seb_kuzminsky> and i agree with your reasons, and i think it's great that you're doing it
[19:45:06] <seb_kuzminsky> all i'm saying is, let's, whenever possible, not break the old ones, or fork a bunch of stuff when existing alternatives would suffice
[19:45:14] <mhaberler> unfortunately even if we have xenomai 3+ and rtpreempt 3+ that doesnt give us a newer RTAI kernel yet
[19:45:24] <seb_kuzminsky> agreed
[19:45:50] <mhaberler> personally I have never experienced a serious issue running various kernels under lucid or precise, I change all the time for testing
[19:45:54] <seb_kuzminsky> and maybe we won't need a new rtai kernel, if we can integrate xenomai/preempt-rt/rtai all inside rtapi
[19:46:32] <seb_kuzminsky> so we can support lucid with rtai, and newer distros with these other realtime solutions
[19:46:35] <mhaberler> I'm not sure cutting out the RTAI option altogether is a good idea
[19:46:46] <seb_kuzminsky> i very much don't want to drop rtai
[19:46:56] <mhaberler> I see; well that is entirely possible
[19:47:25] <seb_kuzminsky> the immense amount of testing and experience we have with rtai is very valuable and not to be discarded lightly
[19:47:43] <mhaberler> one possible option is with L3 to take the risk of an old RTAI kernel under newer distros anyway, I dont see the risk actually
[19:47:45] <seb_kuzminsky> and this is the same reason i don't want to drop support for lucid
[19:47:48] <mhaberler> yes, definitely
[19:48:14] <seb_kuzminsky> L3?
[19:48:19] <seb_kuzminsky> oh, you mean linuxcnc version 3
[19:48:21] <mhaberler> yes
[19:48:48] <mhaberler> and leave the LinuxCNC classic at lucid until Paolo comes up with something
[19:49:16] <andypugh> Does Paolo have any other customers?
[19:49:23] <seb_kuzminsky> i offered our users the lucid kernel on the precise userspace back in spring, and i dont think anyone cared
[19:49:31] <seb_kuzminsky> i certainly have not heard any reports from folks who have tried it
[19:49:35] <andypugh> I can see how motivation might be low if we are the only project using RTAI.
[19:49:38] <seb_kuzminsky> i think that means almost no one cares
[19:49:43] <mhaberler> I dont know; I think he's in some research shop
[19:49:56] -!- psha has quit [Quit: Lost terminal]
[19:50:01] <seb_kuzminsky> andypugh: there's some traffic on the rtai mailing lists, and most of it is from other users of rtai
[19:50:45] <seb_kuzminsky> rtai has been great for us, but it seems to be in decline, i'm very happy that mhaberler has done all the heavy lifting to try newer, more actively maintained realtime solutions
[19:50:46] <mhaberler> well maybe we should crank out a precise/rtai 2.6.32-122 'alternate' LiveCD and see what the fallout is
[19:50:48] <andypugh> OK, so that isn't the problem then.
[19:51:23] <seb_kuzminsky> mhaberler: i'd be ok with that, if we marked it as **EXPERIMENTAL** ;-)
[19:51:31] <mhaberler> well yes
[19:51:42] <seb_kuzminsky> one of our big strengths is a user perception that linuxcnc is very stable
[19:51:45] <mhaberler> we need to state intent with it
[19:51:52] <seb_kuzminsky> yes
[19:52:29] <mhaberler> there are some startup issues like AppArmor shouting I think; I dont even know what that is but it works fine
[19:53:10] <seb_kuzminsky> and then when people come and say "i was running precise on my computer and it was fine, then i installed the precise version of linuxcnc and now it (won't boot|doesn't see the wifi|crashes all the time)"
[19:53:24] <seb_kuzminsky> then we have to tell them, "sorry, we can't support your hardware on that kernel"
[19:53:58] <seb_kuzminsky> unless we want to get into the business of maintaining a kernel fork, with drivers etc from linux 3.x backported to 2.6.32 ;-)
[19:53:59] <mhaberler> oh I see. Well it would have to be the current driver set; that is a potential morass,yes
[19:54:18] <seb_kuzminsky> is mozmck around? if not i volunteer him for that effort ;-)
[19:54:44] <seb_kuzminsky> so what i'm saying is this:
[19:54:47] <mhaberler> well whatever happens, I think there needs to be some contingency planning in case nothing comes forward on the RTAI front
[19:54:49] <seb_kuzminsky> 1. yay for new realtime options!
[19:55:01] <seb_kuzminsky> 2. yay for the old, well-tested, well-understood realtime option of RTAI
[19:55:13] <seb_kuzminsky> 3. let's develop the new stuff while not breaking the old stuff
[19:55:21] <mhaberler> no contest
[19:55:46] <seb_kuzminsky> cool, yeah i think we're largely on the same page
[19:55:53] <mhaberler> yes
[19:55:53] <seb_kuzminsky> i mean we're largely in agreement
[19:56:05] <mhaberler> except them API flavors;)
[19:56:09] <mhaberler> but really, what do we do if RTAI gets stuck where it is?
[19:56:32] <mhaberler> I once heard somebody say 'we violently agree' ;)
[19:56:46] <seb_kuzminsky> i don't feel violent ;-)
[19:57:13] <seb_kuzminsky> if rtai keeps being stuck, we maintain it as long as we realistically can, while developing and testing the alternatives
[19:57:39] <mhaberler> that means 10.04 freeze in WindowsXP state so to speak in 4 moths
[19:57:54] <seb_kuzminsky> ideally there should be a year or two of overlap, at least, whiel we support rtai for our slower-moving users and we encourage our braver users to try the new options and report back
[19:58:09] <seb_kuzminsky> yes i know 10.04 is falling off the maintenance cliff soon
[19:58:31] <andypugh> I like the phrase "vehemently agreeing".
[19:58:39] <seb_kuzminsky> 8.04 stopped years ago, but it's still a viable option for conservative/risk-adverse/stuck-in-their-ways users
[19:59:04] <mhaberler> ok, maybe retrospection helps - any reminiscence of a showstopper Ubuntu bug which was resolved by an apt-get upgrade?
[19:59:25] <andypugh> The Dynos at work run realtime-patched Windows2000. Some were running on PDP-11s until 2 years ago.
[19:59:30] <pcw_home> 8,04 also has better latency on some hardware
[19:59:43] <seb_kuzminsky> pcw_home: that's right, i had forgotten that
[20:00:07] <seb_kuzminsky> mhaberler: are you asking, do i remember any bugs that bit users that were fixed by upgrading the underlying ubuntu distro?
[20:00:17] <mhaberler> yes
[20:00:25] <seb_kuzminsky> oh, sure, lots!
[20:00:36] <seb_kuzminsky> lucid was pretty flaky the first year or so
[20:00:43] <mhaberler> right
[20:00:43] <seb_kuzminsky> lots of bugs were fixed by Canonical
[20:00:48] <cradek> it had trouble ... booting right
[20:01:00] <mhaberler> but I guess it tapered off
[20:01:12] <cradek> yeah, it seems solid enough now
[20:01:14] <seb_kuzminsky> yeah, it's amazing what a coupld of years of stabilization work can do ;-)
[20:01:26] <seb_kuzminsky> (same reason our 2.5 branch is so stable, btw)
[20:01:37] <mhaberler> well that isnt going to change, except for the hardware underneath
[20:02:12] <mhaberler> I mean Halted Specialities in Sunnyvale is a great supplier for compatible stuff;)
[20:02:32] <seb_kuzminsky> i miss that place - i used to live just up the street, on fair oaks
[20:02:57] <mhaberler> I spent lots of time there - a museal shop
[20:03:11] <mhaberler> you lived down there?
[20:03:14] <cradek> I predict that I could run my mill using current-to-slightly-old-today hardware for the next ~15 years on linuxcnc 2.5 on lucid without any trouble
[20:03:19] <pcw_home> 10.04 runs on most current motherboards
[20:03:51] <mhaberler> I'm just trying to gauge the impact of the update freeze on remaining life and user happiness
[20:03:52] <cradek> yeah, possibly newer hardware, but I wouldn't count on it (uefi)
[20:03:53] <seb_kuzminsky> mhaberler: i lived in sunnyvale for 5 years. moved to boulder, colorado in 200...3?
[20:04:07] <mhaberler> fleeing the valley?
[20:04:17] <mhaberler> why would you.. raising kids?
[20:04:19] <seb_kuzminsky> missed the mountains ;-) i gre up here
[20:04:27] <mhaberler> ah. good reason.
[20:04:39] <seb_kuzminsky> and yes, we were planning to have kids and didn't want them to grow up there
[20:04:47] <seb_kuzminsky> they're much happier here i think :-)
[20:04:55] <seb_kuzminsky> you live in the south bay?
[20:05:01] <mhaberler> not a flatlandian myself. yeah, the kids argument makes sense
[20:05:19] <mhaberler> yes, I had a postdoc fellowship at Stanford for a few years
[20:05:43] <seb_kuzminsky> cool! i go out there for work once or twice a year, we should grab a beer next time!
[20:06:20] <mhaberler> I'm baaack in Austria, but I need to sniff valley air pretty soon I think
[20:06:32] <seb_kuzminsky> ah
[20:06:47] <andypugh> I much prefer Austrian Valley air.
[20:06:49] <mhaberler> btw I almost wound up in Denver.. company bought out by a certain, uh, 'Qwest'
[20:08:28] <mhaberler> andy: you dont get to Halted Specialities in Austria. You need to go there. And bring a container and a truck;)
[20:08:29] <andypugh> I haven't been to Austria for far too long. Since my skiing chums had kids all the trips have been to the French Alps.
[20:09:05] <mhaberler> http://www.halted.com
[20:09:56] <andypugh> I don't need more junk!
[20:10:25] <mhaberler> I'm sorry, what attitude it this
[20:10:41] <mhaberler> "he who dies with the most junk, wins!"
[20:11:05] <andypugh> I am hoping to skip the dying part.
[20:11:20] <mhaberler> but you shouldnt skip the junk part.
[20:11:21] <andypugh> 7% of people have never died. Not terrible odds.
[20:11:44] <mhaberler> xenomai front: today I got the fourth report of it working on the beaglebone, so we'll have that shortly - its more a matter of extorting patches from these guys
[20:13:19] <mhaberler> I made halcomp for debugging programs on the AM335x coprocessors - single step, break, dump, continue - without that its a bit fire and forget; the TI 'tool' is a 3.5GB eclipse boatanchor which needs a JTAG
[20:13:41] <mhaberler> now, all in gladevcp
[20:17:08] <mhaberler> John Morris has done a great job on RTAPI cleanup; no more duplicated code; and Charles is making headway with the userland PCI shim
[20:17:47] <mhaberler> seb: we need to start talking buildbot seriously pretty soon, latest early next year I think
[20:18:51] <seb_kuzminsky> sounds good
[20:19:11] <mhaberler> right now, all this is forked off 2.5; I though it would be better to have that option for 2.5 as well, but it implies merging into 2.5 then
[20:19:42] <seb_kuzminsky> i'm pretty reluctant to merge such a deep change into 2.5 at this point
[20:20:01] <seb_kuzminsky> i'd prefer master, and let's get it stabilized there
[20:20:23] <andypugh> When does code go into header files, and when not?
[20:20:27] <mhaberler> sure. But you then dont get the option, meaning 2.5 is going to stay wedded to RTAI
[20:20:37] <mhaberler> 'never'
[20:21:00] <seb_kuzminsky> i'll add some buildslaves with the new realtime kernels, we'll teach the various build scripts to do the right thing on whatever platform they find themselves on, and we should be good
[20:21:02] <mhaberler> except static inline which is a glorified macro
[20:21:25] <seb_kuzminsky> yeah, i think 2.5 will stay rtai-only
[20:21:34] <andypugh> As I don't know what a static inline is, and therefore would never use one, I think I have a nice easy rule to follow.
[20:21:37] <seb_kuzminsky> but i'm just one guy, and that's just my opinion
[20:22:09] <mhaberler> a macro has no typechecking exccept for the code it emits
[20:22:35] <mhaberler> a static inline is expanded into inline code with ful type checking of args/return values
[20:23:00] <mhaberler> so whenever you feel a need for style, use a static inline function
[20:24:06] -!- yuvipanda has quit [Quit: yuvipanda]
[20:24:42] <andypugh> I will bear that in mind when I feel I understand enough to worry about style.
[20:25:33] <mhaberler> seb: I dont think that decision is helpful for the transition period if we do substantial changes in R3 - this means a hole where you have 2.5/RTAI, current master which needs to be supported with the new kernels, and development with the new kernels - that spreads resources very thin
[20:26:26] <mhaberler> There are no effective changes in RTAPI support for RTAI - for this very reason
[20:26:54] <mhaberler> the only change we did is split and reshuffle to reduce duplication, but not changes
[20:27:05] <seb_kuzminsky> i haven't looked at the changes yet, so i should keep my mouth shut
[20:27:45] <mhaberler> well it isnt time for reviewing just yet, but I hope to provide some boring Xmas reading;)
[20:28:19] <seb_kuzminsky> i'm planning to spend my christmas break nights on the hostmot2 buildbot
[20:28:43] <mhaberler> what is special there, fpga code build?
[20:28:59] <cradek> that sounds like dreary work but I would really love to see it going
[20:29:26] <seb_kuzminsky> yeah, auto-building fpga bitfiles from hostmot2 vhdl code
[20:29:45] <seb_kuzminsky> it's a big hole in our infrastructure currently
[20:29:50] <andypugh> Talking of style. I have made a macro HM2WRITE which expands to hm2->llio->write(hm2->llio, . I guess I shouldn't use that in new code in old modules as mix-and match is untidy. And changing working code for brevity is deprecated?
[20:29:54] <mhaberler> aja, so you get to integrate those vendor tools
[20:29:55] <cradek> deb packages of bitfiles
[20:30:08] JT-Shop-2 is now known as JT-Shop
[20:30:10] <mhaberler> hey, seb is forking _again_! stop all that forking
[20:30:15] <seb_kuzminsky> cradek: right
[20:30:19] <seb_kuzminsky> heh
[20:31:13] <andypugh> seb_kuzminsky: Web-interface! Bitfiles on-demand! (On the face of it, a stepconf front end to make the main vhdl file looks almost easy)
[20:31:23] <mhaberler> bbl
[20:31:26] <seb_kuzminsky> i've talked with pcw, and I think we've agreed that he's going to do his firmware development in our git repo, or at least regularly send me patches for me to commit to our git repo
[20:31:35] <seb_kuzminsky> so no forking :-P
[20:31:41] <mhaberler> hm hm hm
[20:31:46] <andypugh> Sounds good.
[20:32:23] <seb_kuzminsky> andypugh: maybe... i see how it would be convenient, but it's also inconvenient in another way
[20:32:30] <mhaberler> you mean proprietary binaries on the buildbot.. how can you..
[20:32:50] <seb_kuzminsky> if i make a custom firmware, i won't get automatic bugfixes when the modules i use are updated
[20:32:57] <seb_kuzminsky> mhaberler: yeah :-/
[20:33:11] <seb_kuzminsky> if there was a viable alternative i'd be all about it
[20:33:25] <seb_kuzminsky> let's all stop work for 5 years and write an open-source vhdl compiler!
[20:33:32] <mhaberler> RMS would not approve
[20:33:34] <mhaberler> yeah right
[20:33:35] <seb_kuzminsky> oh wait, no lets not
[20:33:36] <cradek> I think the need for individually customized bitfiles is extremely rare, and the practice is somewhat harmful
[20:33:49] <seb_kuzminsky> cradek: i agree
[20:34:07] <mhaberler> I would see value in an automatic build chain end to end
[20:34:12] <andypugh> I disagree. As I use one.
[20:34:22] <cradek> which part do you disagree with?
[20:34:30] <seb_kuzminsky> i bet most people can have their needs met with a double handful of "official" firmware images
[20:34:43] <cradek> yes, very vast majority
[20:34:45] <seb_kuzminsky> and if we find one that's missing, i'd rather add it to the repo and have it become an official image
[20:34:46] <mhaberler> just reminding you of the fact that since we dont have that for the RTAI kernel, and the repo is lost ...
[20:34:49] <andypugh> Not my 7i44 / 7i49 / 7i39 combo...
[20:35:03] <seb_kuzminsky> mhaberler: yes, that's a big bumemr
[20:35:10] <seb_kuzminsky> burrmmurr
[20:35:15] <seb_kuzminsky> brummur
[20:35:16] <cradek> but we have corresponding source packages...
[20:36:12] <andypugh> Well, the 7i44 / 7i49 / 7i39 could be an official firmware. The previous one which had UART and Smart-Serial couldn't as those disagree about an instance stride.
[20:36:33] <andypugh> (had to recompile the LinuxCNC driver with a check taken out)
[20:36:47] <seb_kuzminsky> oh hey, look at that:
http://www.linuxcnc.org/dists/lucid/base/source/
[20:37:00] <seb_kuzminsky> andypugh: that sounds like a bug ;-)
[20:37:16] <andypugh> But I think I am arguing that I should be allowed custom firmwares, not that we should make them easy for anyone who fancies a neter ribbon cable routing.
[20:37:34] <seb_kuzminsky> hten i think we agree
[20:37:34] <cradek> nobody is disagreeing with "allowed"
[20:37:54] <seb_kuzminsky> and i'm planning to add the 'scratch' feature form the linuxcnc buildbot to the hm2 one
[20:38:21] <seb_kuzminsky> so it'll be easy for folks to build their own branch of the hm2 source, without polluting the "official" branches or deb archives
[20:39:52] -!- cherry_lin has quit [Ping timeout: 246 seconds]
[20:42:58] <pcw_home> Actually I cant think of an actual problem with custom firmware, really all that is custom is a pinout/module set
[20:43:39] <seb_kuzminsky> pcw_home: the problem i'm worried about is getting a bug report and having a hard time figuring out what version of the source the user is using
[20:43:40] <cradek> pcw_home: how can you push out a bugfix?
[20:44:05] <seb_kuzminsky> and that
[20:44:08] <pcw_home> Each module have a version
[20:44:29] <pcw_home> module have bugs, not configs
[20:44:37] <pcw_home> modules
[20:46:42] <cradek> if there's a bug in a module, and you push a fix to the git, and buildbot rebuilds all the "blessed" configs and makes new debs, the users get that fixed code when they run their usual updates.
[20:47:18] <cradek> that is where we should try to be, just like for the linuxcnc code
[20:48:02] -!- alpha1125 has quit [Quit: Computer has gone to sleep.]
[20:48:02] <pcw_home> and the driver gets updated to bellyache about the buggy module, so a user with a custom bitfile is informed
[20:48:10] <cradek> if a user has a problem you can see the corresponding source code, because it's tagged with the version number of the deb
[20:48:46] <cradek> ok, informed, and then their system is broken until they get new individualized firmwares using whatever separate process
[20:51:40] <pcw_home> well you could just add them to the buildbot list (at the end)
[20:51:59] <andypugh> If it's just a warning, and they enter into the custom bitfile situation voluntarily, and the firmware still works at least as well as it did, is there a real problem?
[20:52:59] <cradek> pcw_home: sure, if there's a useful config that is not well served, we could bless and package it
[20:53:06] <pcw_home> And (well other than embedded processor code) how may firmware bug have there actually been (5?)
[20:53:56] <cradek> I don't know - I think I have the one with broken velocities for some encoders on my mill, and it hasn't bitten me yet
[20:54:47] <pcw_home> stepgen, muxed encoder velocities, a couple bad pinouts
[20:55:22] <pcw_home> 36 sserial revs :-)
[20:56:46] <pcw_home> plus a top level bug in the PLX interface code that only affects windows drivers
[20:58:00] <pcw_home> There is one flaw in the current IDROM format that needs fixing (Andy's stride problem)
[20:59:06] <cradek> if you have a fix that requires driver and firmware updates simultaneously, you can set dependencies on the packages and the routine updates will get them installed together
[20:59:34] <cradek> there are so many benefits for the user and also for us
[21:00:33] <cradek> like hostmot2 version 20 requires linuxcnc >= 2.5.1
[21:01:01] <pcw_home> I think the format thing has been fixed buy getting along with any revision (V2,V3 IDROM and now V4)
[21:05:36] <andypugh> pcw_home: Is the instance stride at location 5 of a local read the same as the stride in the module descriptor?
[21:06:10] <andypugh> My guess is "no" but I thought I should check
[21:07:56] <pcw_home> No, thats something I want to change for V4
[21:07:57] <pcw_home> the nibble in the module decriptor is just a selector of the 2 possible strides
[21:09:06] <pcw_home> i want to chne this so the module descriptor nibbles are the strides themselves (well log2 of the strides)
[21:09:13] <pcw_home> change
[21:10:15] <pcw_home> so each module has its own instance and register strides
[21:12:17] <seb_kuzminsky> the buildbot framework is designed to work on specific version of source code that it gets from a revision control system
[21:12:37] <seb_kuzminsky> adding a "design your own firmware on a webpage" feature is beyond the scope of my christmas break ;-)
[21:13:25] <andypugh> Change religion to stretch it a bit?
[21:13:37] -!- kwallace has quit [Ping timeout: 255 seconds]
[21:16:31] -!- wboykinm has quit [Remote host closed the connection]
[21:17:33] <seb_kuzminsky> what's that religion that feeds my kids and puts them through college, again? i keep forgetting
[21:26:12] -!- acdha has quit [Quit: Leaving...]
[21:37:53] -!- mattions has quit [Ping timeout: 246 seconds]
[21:43:56] -!- motioncontrol has quit [Quit: Sto andando via]
[21:45:52] <andypugh> Pastafarianism.
[21:51:10] -!- micges has quit [Ping timeout: 260 seconds]
[21:52:17] toudi_ is now known as micges
[22:22:18] -!- DJ9DJ has quit [Quit: bye]
[22:23:25] -!- FinboySlick has quit [Quit: Leaving.]
[22:27:35] -!- bmwyss has quit [Quit: bmwyss]
[22:31:08] <seb_kuzminsky> pcw_home: plx interface bug that affects windows drivers, is that the waitstate thing you helped me with a year and a half ago?
[22:32:54] -!- vladimirek has quit [Remote host closed the connection]
[22:40:38] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[23:02:39] -!- bmwyss has quit [Quit: bmwyss]
[23:03:58] -!- mattions has quit [Ping timeout: 246 seconds]
[23:06:40] -!- automata has quit [Ping timeout: 256 seconds]
[23:07:41] -!- PCW [PCW!~chatzilla@99.88.10.65] has joined #linuxcnc-devel
[23:08:38] <PCW> seb_kuzminsky: yep thats it
[23:12:45] <PCW> the PLX driver has it fingers into the bridge chip, and they changed something that caused the hangs
[23:12:47] <PCW> I disabled wait states to work around this when you had the trouble, but I found a better way and
[23:12:49] <PCW> fixed the firmware to be more robust relative to driver meddling
[23:27:51] -!- r00t4rd3d has quit [Quit: Leaving]
[23:34:18] -!- asdfasd has quit [Ping timeout: 264 seconds]
[23:35:15] -!- pjm has quit [Read error: Connection reset by peer]
[23:39:14] -!- racycle has quit [Quit: racycle]
[23:45:17] asdfas is now known as asdfasd
[23:46:48] -!- asdfasd has quit []
[23:52:25] <seb_kuzminsky> very cool
[23:53:47] <PCW> We had another windows customer that ran into the problem (I think it may be be PLX driver version dependent)
[23:54:23] <PCW> (they had a config with 36 encoder inputs!)
[23:54:35] <andypugh> That's rather a lot
[23:54:54] <PCW> some kind of cardboard box folding machine
[23:56:12] <PCW> we actually made the 7I53 (12 channel encoder input daughtercard) for them
[23:56:18] <andypugh> I am thinking about punting a car-emulator to Ford. We would need 200 pins on a USB connector (think car on the desktop plugged into the PCM, linked to Excel/VBA/USB)
[23:57:39] <andypugh> We already do it, we have half a dozen D-space boxes which are a completely accurate simulacrum of the vehicle environment of the PCM. I was thinking of something a lot more basic.
[23:58:38] <andypugh> The sensors all either talk CAN, LIN or (because it is cheap, not because it makes any sense) PWM.
[23:59:13] <andypugh> I have no idea how much effort the PCM wastes measuring input PWM.