Back
[00:05:03] -!- andypugh has quit [Quit: andypugh]
[00:12:36] -!- logger[psha] [logger[psha]!~loggerpsh@195.135.238.205] has joined #linuxcnc-devel
[00:22:41] -!- pjm_ has quit [Read error: Connection reset by peer]
[00:22:56] -!- L84Supper has quit [Quit: <puff of smoke>]
[00:48:00] sliptonic_away is now known as sliptonic
[00:48:02] sliptonic is now known as sliptonic_away
[00:48:04] sliptonic_away is now known as sliptonic
[01:01:05] -!- crank has quit [Ping timeout: 255 seconds]
[01:09:42] -!- GammaX-Laptop has quit [Ping timeout: 272 seconds]
[01:26:02] <KGB-linuxcnc> 03chrisinnanaimo 05master 689928f 06linuxcnc 10lib/python/gladevcp/drowidget.py * gladevcp -add diameter mode to dro_widget
[01:37:37] -!- L84Supper [L84Supper!~Larch@unaffiliated/l84supper] has joined #linuxcnc-devel
[01:59:55] -!- dgarr [dgarr!~dgarrett@71-209-213-245.phnx.qwest.net] has joined #linuxcnc-devel
[02:19:16] -!- phantoneD has quit []
[02:38:48] -!- skorasaurus has quit [Quit: left the building.]
[02:41:06] -!- Tecan has quit [Quit: Live Long And Phosphor!]
[02:55:29] -!- servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[02:58:10] -!- Keknom has quit [Quit: Leaving.]
[03:27:58] -!- dgarr has quit [Quit: Leaving.]
[03:41:15] -!- Felix29 has quit []
[04:01:34] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[04:09:37] -!- Tecan has quit [Changing host]
[04:23:21] -!- ProxDem has quit [Ping timeout: 245 seconds]
[04:31:20] -!- FinboySlick has quit [Quit: Leaving.]
[04:52:38] -!- Valen has quit [Quit: Leaving.]
[05:12:12] -!- tjb1 has quit [Quit: tjb1]
[05:27:36] -!- automata [automata!~automata@122.169.56.44] has joined #linuxcnc-devel
[05:59:55] <KGB-linuxcnc> 03nieson 05master 229839d 06linuxcnc 10configs/ 10(11 files in 2 dirs)
[05:59:56] <KGB-linuxcnc> gmoccapy_0_9_1 - reworked the complete settings page and added a lot of new features
[06:02:26] -!- a_l_e has quit [Ping timeout: 252 seconds]
[06:28:15] -!- brian|lfs has quit [Remote host closed the connection]
[06:39:18] -!- jfire has quit [Quit: Leaving.]
[06:54:52] -!- GammaX-Laptop has quit [Ping timeout: 272 seconds]
[06:55:24] -!- Loetmichel has quit [Ping timeout: 264 seconds]
[06:58:44] -!- maximilian_h [maximilian_h!~bonsai@130.255.104.21] has joined #linuxcnc-devel
[07:17:43] -!- Tom_itx has quit [Ping timeout: 260 seconds]
[07:18:53] -!- SWPadnos has quit [Ping timeout: 245 seconds]
[07:21:34] -!- mhaberler has quit [Quit: mhaberler]
[07:22:17] -!- mle has quit [Excess Flood]
[07:29:36] -!- SWPadnos [SWPadnos!~Me@74-92-8-208-NewEngland.hfc.comcastbusiness.net] has joined #linuxcnc-devel
[07:34:03] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[07:40:22] -!- gambakufu has quit [Read error: Connection reset by peer]
[07:42:15] -!- stsydow has quit [Remote host closed the connection]
[08:04:58] -!- thesisb_ has quit [Quit: Leaving...]
[08:21:57] -!- stsydow has quit [Quit: Leaving]
[08:23:04] -!- rob_h [rob_h!~rob_h@94.2.180.164] has joined #linuxcnc-devel
[08:25:05] -!- maximilian_h [maximilian_h!~bonsai@130.255.104.21] has parted #linuxcnc-devel
[08:33:36] -!- mhaberler has quit [Quit: mhaberler]
[08:54:46] Tom_garage is now known as Tom_itx
[09:11:40] -!- tandoori has quit [Ping timeout: 272 seconds]
[09:17:36] -!- psha[work] [psha[work]!~psha@195.135.238.205] has joined #linuxcnc-devel
[09:22:47] -!- p0st4L has quit [Ping timeout: 260 seconds]
[09:31:58] -!- gommo has quit [Remote host closed the connection]
[09:40:18] -!- b_b has quit [Changing host]
[10:15:13] -!- b_b has quit [Changing host]
[10:18:32] -!- largecheesepuff has quit [Read error: Operation timed out]
[10:33:34] Cylly is now known as Loetmichel
[10:55:01] -!- skunkworks has quit [Remote host closed the connection]
[11:24:39] -!- gonzo_ has quit [Quit: Leaving]
[11:27:25] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[11:30:18] -!- dhoovie has quit [Read error: Connection reset by peer]
[11:47:27] -!- bla_ has quit [Client Quit]
[11:49:44] -!- Felix29 [Felix29!Felix@c-71-193-105-131.hsd1.in.comcast.net] has joined #linuxcnc-devel
[11:58:04] Bojangle1 is now known as Bojangles
[12:11:27] -!- largecheesepuff has quit [Read error: Operation timed out]
[12:15:11] -!- juxta has quit [Ping timeout: 255 seconds]
[12:22:28] -!- juxta has quit [Ping timeout: 260 seconds]
[12:23:51] -!- adb [adb!~IonMoldom@178.211.237.94] has joined #linuxcnc-devel
[12:26:57] -!- ravenlock has quit [Remote host closed the connection]
[12:30:21] -!- PetefromTn has quit [Remote host closed the connection]
[12:47:23] -!- psha[work] has quit [Quit: Lost terminal]
[12:53:04] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[13:00:41] -!- Felix29 has quit []
[13:00:43] -!- maximilian_h [maximilian_h!~bonsai@f052191189.adsl.alicedsl.de] has joined #linuxcnc-devel
[13:06:14] -!- riz_ [riz_!62dd7d6e@gateway/web/freenode/ip.98.221.125.110] has joined #linuxcnc-devel
[13:06:43] -!- b_b has quit [Changing host]
[13:07:28] <riz_> In rs274ngc_pre.cc, I see some code about lazy closing of files. Does anyone knwo exactly what this is?
[13:07:45] <riz_> It is in Interp::open
[13:08:37] -!- stsydow has quit [Remote host closed the connection]
[13:25:14] -!- syyl__ has quit [Ping timeout: 256 seconds]
[13:25:20] -!- syyl_ws has quit [Ping timeout: 246 seconds]
[13:25:50] -!- aFeijo has quit [Ping timeout: 255 seconds]
[13:29:02] -!- danilow has quit [Quit: Page closed]
[13:32:12] -!- L84Supper has quit [Quit: <puff of smoke>]
[13:32:53] <mhaberler> yes: it means - dont touch it
[13:33:31] <mhaberler> for some reason there's an assumption the interp needs to have a file open, and if it doesnt, weird things happen
[13:35:30] <mhaberler> that is one of the areas where interp needs work, this file I/O nonsense should go away and only string input should be left, any number of lines; in case of an actual ngc file, mmap() it before
[13:36:29] <mhaberler> you're plowing through all the intestines, it seems?
[13:36:49] <riz_> Every bit of it haha
[13:36:53] <riz_> It's interesting
[13:37:02] <mhaberler> welcome to the Dark Corner section ;)
[13:37:03] <riz_> I just dont understand the intention or logic of some of it
[13:37:11] <mhaberler> you are not alone
[13:37:55] <mhaberler> what you see is 'layered improvements', which tends to hide the original intent or design (assuming there was one ;)
[13:38:11] <riz_> So you are saying to get rid of files with regard to the interpreter?
[13:38:27] <riz_> yeah, i noticed that
[13:38:28] <mhaberler> well it goes a bit further than that but yes
[13:39:21] <riz_> I might want to work on this. It seems easy enough. Any specific approach or idea on how it should be done?
[13:39:58] <mhaberler> I dont see any fundamental difference between MDI and Auto mode as far as the interp goes; however, that useless mode differentiation (which has all sorts of side effects - cant do this in this mode, cant do that in that mode) is represented in interp in the way input is passed: MDI - a string; auto- a file
[13:40:36] <mhaberler> actually there would be more than one work item here, while you are at it..
[13:41:07] <mhaberler> the way the interpreter is hooked into task is fundamentally broken, and this is why
[13:41:33] <mhaberler> what happens is that the interp is called as a subroutine by task: read - eval - generate canon commands
[13:41:58] <mhaberler> that was a great idea before control structures were conceived because a 'program' was just a sequence
[13:42:01] -!- davec has quit [Quit: Leaving]
[13:42:34] <mhaberler> what control structs brought was all sorts of contortions to call or not call the interp depending whether a block is finished or not
[13:42:52] <mhaberler> that really shows if you do 'o<proc> call' in mdi
[13:43:13] <mhaberler> the MDI processing in task and interp is beyond repair IMO
[13:43:38] <riz_> that doesnt sound good..
[13:44:11] <mhaberler> what could be done to simplify dramatically is to make the interp a process / thread proper (interp _always_ knows when it is done; instead we have task guessing she _might_ be done, which is silly)
[13:44:55] <mhaberler> that interp process is fed a string to execute, and need IMO not know what 'MDI' or 'auto' actually means, except for an option maybe
[13:45:23] <riz_> I see
[13:45:26] <mhaberler> and the actual read-eval-generate canon loop would be all inside interp and not littered above several parts
[13:45:53] -!- mozmck [mozmck!~moses@client-67.210.159.199.dfwtx.partnershipbroadband.com] has joined #linuxcnc-devel
[13:46:09] <riz_> This will take much more than anticipated. The code is so intertwined that it would take a lot of parsing
[13:46:24] <mhaberler> yes, that is the case unfortunately
[13:46:59] <mhaberler> what would be needed is:
[13:47:08] <mhaberler> thread-safing the interp list (easy)
[13:47:31] <mhaberler> adding an interp command queue which passes input strings to interp, driven by task
[13:47:54] <mhaberler> callback of interp into task to do a sync() operation
[13:48:12] <mhaberler> then get rid of the MDI processing nonsense in task
[13:49:17] -!- L84Supper [L84Supper!~Larch@unaffiliated/l84supper] has joined #linuxcnc-devel
[13:49:33] <mhaberler> interp running into an error or finishing could be handled by new 'canon' commands, basically just to tell task 'done' or 'blew it'
[13:50:08] <mhaberler> well there is an upside: lots of incomprehensible code can go
[13:50:23] -!- holst has quit [Quit: Leaving]
[13:50:39] <mhaberler> and an actually readable structure
[13:51:22] <riz_> I'll have to take a deeper look into it. I havent looked at interp with such depth
[13:52:03] <mhaberler> actually interps are loadable from .so files at run time and can be replaces; it isnt used really atm
[13:52:40] <mhaberler> well let me know if you decide to give it a stab, so we can map out a plan and steps
[13:53:46] <riz_> What is your timeframe. I am doing this on the side and it might take me a bit to study
[13:53:50] -!- psha [psha!~psha@213.208.162.67] has joined #linuxcnc-devel
[13:53:54] <mhaberler> would be nice to be able to plug in a really useful interp at runtime, like python
[13:54:35] <mhaberler> I have no timeframe because it isnt on my top priorities; I'm busy at the HAL/RTAPI/RTOS layer atm
[13:54:51] <mhaberler> but I think it should be done, and it might not be that wild after all
[13:55:35] <riz_> OK. I will definitely leyt you know if I am crazy enough to give it a shot in the future
[13:55:43] <mhaberler> I do think however it interferes a bit with my plans to wipe NML (just a wee bit)
[13:56:02] <pcw_home> Isn't simplifying the connection of interp to real time needed for MachinKit like hardware partitioning anyway
[13:56:09] <pcw_home> ?
[13:56:10] <mhaberler> amen, yes
[13:56:29] <mhaberler> what that means is that the interplist and canon should be made agnostic of NML and use zeroMQ to start with
[13:57:31] <riz_> Im sorry, what is zeromq?
[13:57:32] <mhaberler> pcw_home: the first step would be to make the task/motion and HAL/task interfaces remote capable so as to be able to cut rt off from non-rt
[13:57:36] <mhaberler> interp is firmly non-rt so it isnt an issue
[13:58:00] <mhaberler> a queueing middleware which we'll use to dump NML, see zeromq.org
[13:59:20] <mhaberler> but neverthelesse while cleaning up NML, making the task/interp interaction zmq like the rest is the obvious way to go, instead of layering yet another bandaid over NML
[14:00:18] <riz_> I dont understand why we need any of these things such as NML or zmq? Why not just do away with all of that
[14:00:32] <mhaberler> and replace it by what?
[14:00:47] <riz_> Well, what is the underlying purpose of it
[14:00:55] <riz_> I was thinking just write and read from shared memory
[14:01:09] <riz_> dont we just want to communicate messages
[14:01:19] <mhaberler> that aint a solution, it is the problem right now
[14:01:39] <riz_> Why is that a problem?
[14:01:43] <mhaberler> everything is forced onto a single memory space, hence every bit of it has to run on an RTOS
[14:02:47] <mhaberler> _everything_ starting from UI to wiggling bits in the machine has to be on one memory space - and it better be realtime
[14:03:37] <riz_> I am just ocnfused. Why can;t you have real time and non-real time separated and communicate through a buffer?
[14:04:06] <mhaberler> as soon as you use queues in shared memory only, both non-RT and RT have to be on one machine
[14:04:20] <mhaberler> you need networked queues to make the cut
[14:05:20] <mhaberler> separating non-rt and rt with shm queues is in place anyway
[14:05:43] <riz_> Because running the non-RT stuff in the RT memory space will effect the performance???
[14:06:34] <mhaberler> well think of this: glue an ipad to you mill, or any other non-linux, non-vnc UI, or maybe windows. What runs where?
[14:06:45] <riz_> Wouldn't you ideally want the system running on one machine as long as you can keep the real time performance?
[14:06:49] <mhaberler> right now all you can do is vnc, which is a dog
[14:07:02] <riz_> Oh, i see what you are getting at
[14:07:31] <mhaberler> separate rt from non-rt to enable postwar UI's..
[14:07:41] <mhaberler> or a web ui
[14:07:58] <mhaberler> note there is one, and guess what: it doesnt support HAL. Duh. Why?
[14:08:28] <mhaberler> well HAL is shared memory _only_ atm and it doesnt have say a websockets/JSON service as of now
[14:10:27] <mhaberler> note also that splitting rt from non rt enables moving rt to a specialized platform like an fpga/soc or say a beaglebone
[14:10:38] <mhaberler> cant do that in the current 'architecture'
[14:10:47] <riz_> hmm
[14:11:03] <mhaberler> note the inital design from nist was fully distributed but restrictions crept in over time
[14:11:31] <riz_> yeah
[14:11:36] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[14:12:29] <mhaberler> which leaves you with the hope to find a PC-style motherboard which runs RT reasonably on RTAI, and has less-than-broken graphics drivers; note this is a breed heading for extinction
[14:12:29] <riz_> What restrictions are you referring to?
[14:12:45] <mhaberler> NML is in principle remote-capable
[14:12:48] <mhaberler> HAL is not
[14:13:02] <riz_> right
[14:13:05] <mhaberler> which is why you get the common subset: NML features on a single machine
[14:22:53] -!- erictheise has quit [Quit: erictheise]
[14:27:12] -!- netxshare has quit [Ping timeout: 264 seconds]
[14:28:14] <seb_kuzminsky> hi mhaberler, any progress on the rebase of the new rtos branches?
[14:28:24] <mhaberler> why?
[14:28:36] <mhaberler> I am still trying to compile on the bb
[14:28:44] <mhaberler> and fail and fail and fail and fail
[14:29:05] <seb_kuzminsky> why? because that's the next step towards merging it
[14:29:12] <seb_kuzminsky> what buildbot problems are you having?
[14:29:43] <mhaberler> please look at the fail logs, they still hiccup with package installs and askpass
[14:29:50] <mhaberler> I'll push so you'll see it
[14:30:17] <seb_kuzminsky> ok, i'll watch
[14:30:20] <mhaberler> I think getting a build to complete is a step before merging, dont you think so too?
[14:30:30] <seb_kuzminsky> i thought it was building
[14:30:44] <seb_kuzminsky> and yes, of course i agree, it should build before getting merged
[14:31:34] <mhaberler> http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-amd64/builds/7/steps/shell/logs/stdio
[14:31:58] <mhaberler> http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-xenomai-binary-amd64/builds/7/steps/shell/logs/stdio
[14:32:27] <mhaberler> http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-xenomai-binary-x86/builds/7/steps/apt-get-update/logs/stdio
[14:32:55] <mhaberler> no point in pushing I think
[14:34:10] <seb_kuzminsky> that was from 10 days ago, i think it's been fixed
[14:34:17] <mhaberler> ok
[14:34:37] <mhaberler> do I need to push a change or can I trigger a build on a branch?
[14:34:41] <seb_kuzminsky> and anyway, the deb builders wont succeed, because it's looking for the realtime kernels on linuxcnc.org, and they're not there yet
[14:35:03] <seb_kuzminsky> linuxcnc-build: force build --branch=rtos-integration-preview3 checkin
[14:35:04] <linuxcnc-build> build forced [ETA 1h14m12s]
[14:35:04] <linuxcnc-build> I'll give a shout when the build finishes
[14:35:05] <mhaberler> then why dont you just pull them from my repo until then
[14:35:23] <seb_kuzminsky> it doesnt make sense to
[14:35:43] <seb_kuzminsky> this project of yours is in the integration phase now, let's do it right
[14:36:07] <seb_kuzminsky> this means getting the kernels onto linuxcnc.org (which i'm working on with zultron) and getting the branch ready to review and merge (which you'd said you would do)
[14:36:31] <seb_kuzminsky> do you still agree with this plan? we've decided on it twice now ;-)
[14:36:41] <mhaberler> yes, and I want to see it build first, and try out actual packages
[14:36:54] <mhaberler> I dont understand this tit-for-tat
[14:37:24] <seb_kuzminsky> there's no tit foar tat michael, i'm just trying to get this branch merged
[14:38:34] <mhaberler> Seb - I know your preferences, and again: _this_ branch (rtos-integration-preview3 etc) will not be merged because it is absolutely pointless by now to do this step, and I dont see why one should put effort into useless work
[14:38:43] -!- vladimirek has quit [Remote host closed the connection]
[14:38:59] <mhaberler> whatever the result is, the build chain needs to work, and it doesnt yet
[14:39:19] <seb_kuzminsky> we talked about this
[14:39:32] <mhaberler> I think we're moving in circles here
[14:39:38] <seb_kuzminsky> yes i think so too
[14:39:46] <seb_kuzminsky> ok, never mind
[14:39:50] <seb_kuzminsky> laters
[14:47:53] <jepler> mhaberler: to answer your question from this weekend, there are parts of rtapi-more-headers that I am not comfortable asking cradek to accept for v2.5_branch.
[14:48:08] <mhaberler> I see
[14:48:31] <mhaberler> did you see the errors I got?
[14:48:32] <jepler> mhaberler: for instance, even if we believe there are no users of pre-2.6.24 kernels I would not argue we should accept a patch that will absolutely break any such users in the "stable" branch
[14:48:41] <mhaberler> right
[14:48:44] <mhaberler> makes sense
[14:49:22] <jepler> mhaberler: yes I saw that you got errors. I haven't done anything about them yet
[14:49:28] krusty_ar is now known as soy_marta
[14:49:35] <mhaberler> fair enough
[14:49:52] -!- alex_joni has quit [Ping timeout: 272 seconds]
[14:50:13] -!- Tugge has quit [Read error: Operation timed out]
[14:50:41] <jepler> mhaberler: for pm_message_t, it looks like I could just drop suspend* / resume* / shutdown from the userspace rtapi_pci_driver structure. what do you think?
[14:51:15] <mhaberler> oh definitely, I dont think any of this will be ever activated except by accident
[14:52:16] -!- alex_joni [alex_joni!~alex_joni@emc/board-of-directors/alexjoni] has joined #linuxcnc-devel
[14:52:16] -!- mode/#linuxcnc-devel [+v alex_joni] by ChanServ
[14:52:24] <jepler> rtapi_pci_dev vs rtapi_pcidev -- I am confused here. There are two rather different structure definitions, too
[14:52:51] <jepler> but in the kernel API I don't see that part
[14:52:57] <jepler> is rtapi_pcidev supposed to be something internal to the implementation?
[14:53:40] <jepler> I need to go back and look at the original from before I adapted it, I guess
[14:53:43] <mhaberler> let me look at it again, I am in the middle of something else right now
[14:53:47] <jepler> that's fine
[14:53:50] <jepler> I should be doing $DAY_JOB too
[14:53:54] <mhaberler> ah ;)
[14:54:04] <mhaberler> tax season here :-/
[14:54:29] <jepler> that's possibly even less fun than what I'm doing (trying to figure something about how multiple monitors work on ms windows)
[14:55:29] <mhaberler> you lucky guy
[14:56:41] <jepler> apparently users with multiple monitors don't like it when the main application comes up evenly split between the two monitors
[14:56:45] <jepler> picky picky
[14:58:34] -!- joe9 has quit [Remote host closed the connection]
[15:01:51] <mhaberler> does it make a difference to a windows user?
[15:02:17] <mhaberler> or let me put it this way: do they actually notice?
[15:04:31] <cradek> who would you say is the good default assignee for pyvcp bugs and requests?
[15:08:30] -!- tjtr33 has quit [Quit: Leaving]
[15:09:48] <mhaberler> it's a bit like with much of the TCL stuff - I think the way to deal with it is to mark it for deprecation if nobody can be identified
[15:23:48] -!- L84Supper has quit [Quit: <puff of smoke>]
[15:24:32] -!- L84Supper [L84Supper!~Larch@unaffiliated/l84supper] has joined #linuxcnc-devel
[15:28:12] -!- Bojangles has quit [Ping timeout: 260 seconds]
[15:35:07] -!- automata has quit [Ping timeout: 256 seconds]
[15:42:50] <linuxcnc-build> build #77 of precise-x86-rtpreempt-rip is complete: Failure [4failed apt-get-update runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-x86-rtpreempt-rip/builds/77
[15:43:17] <linuxcnc-build> build #61 of precise-amd64-rtpreempt-rip is complete: Failure [4failed apt-get-update runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-rtpreempt-rip/builds/61
[15:43:46] <linuxcnc-build> build #980 of precise-amd64-sim is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim/builds/980
[15:44:32] <linuxcnc-build> build #978 of precise-i386-sim is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-sim/builds/978
[15:45:41] <linuxcnc-build> build #976 of lucid-i386-sim is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/976
[15:46:21] <linuxcnc-build> build #178 of precise-i386-realtime-rip is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/178
[15:47:26] <linuxcnc-build> build #61 of precise-amd64-xenomai-rip is complete: Failure [4failed apt-get-update runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-xenomai-rip/builds/61
[15:49:25] -!- sumpfralle has quit [Ping timeout: 248 seconds]
[15:49:44] <linuxcnc-build> build #980 of hardy-amd64-sim is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/980
[15:49:49] -!- mhaberler has quit [Quit: mhaberler]
[15:51:34] -!- capricorn_1 has quit [Quit: Konversation terminated!]
[15:52:38] <linuxcnc-build> build #87 of precise-x86-xenomai-rip is complete: Failure [4failed apt-get-update runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-x86-xenomai-rip/builds/87
[15:53:13] <linuxcnc-build> build #978 of lucid-amd64-sim is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/978
[15:53:22] <linuxcnc-build> build #977 of hardy-i386-realtime-rip is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/977
[15:53:48] <linuxcnc-build> build #979 of hardy-i386-sim is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/979
[15:54:40] <linuxcnc-build> build #977 of lucid-i386-realtime-rip is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/977
[15:54:40] <linuxcnc-build> build #975 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/975
[16:01:25] <seb_kuzminsky> the failures i spot-checked are all because of the linuxcncrsh hang, these tests have all been disabled in 2.5 and master pending a fix
[16:04:05] -!- mozmck has quit [Read error: Operation timed out]
[16:06:01] -!- jfire has quit [Quit: Leaving.]
[16:13:28] -!- mozmck [mozmck!~moses@client-204.235.45.161.wcfltx.partnershipbroadband.com] has joined #linuxcnc-devel
[16:21:24] -!- thesisb has quit [Remote host closed the connection]
[16:22:25] <seb_kuzminsky> it's interesting that the linuxcncrsh tests fail so much more often in the rtos branch than in the mainline branches
[16:22:33] <seb_kuzminsky> something to chase
[16:23:16] <seb_kuzminsky> i've been running those tests on my laptop for days and days (once directly on the laptop, and simultaneously in a lucid-amd64 vm running on the laptop)
[16:23:22] <seb_kuzminsky> 0 failures so far :-/
[16:24:38] -!- riz_ has quit [Ping timeout: 245 seconds]
[16:26:38] -!- syyl has quit [Ping timeout: 246 seconds]
[16:27:04] -!- psha has quit [Read error: No route to host]
[16:27:19] -!- psha [psha!~psha@213.208.162.67] has joined #linuxcnc-devel
[16:28:42] -!- stsydow has quit [Remote host closed the connection]
[16:31:34] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[16:34:02] -!- V0idExp has quit [Quit: Leaving.]
[16:36:52] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[16:38:13] -!- GammaX-Laptop has quit [Ping timeout: 240 seconds]
[16:38:35] <seb_kuzminsky> mhaberler: those failures are because of the linuxcncrsh tests, which have been disabled in the mainline branches.
[16:38:51] <mhaberler> ok
[16:38:53] <seb_kuzminsky> when/if you rebase, that problem will go away
[16:46:08] -!- tmcw has quit [Remote host closed the connection]
[16:46:50] <KGB-linuxcnc> 03jepler 05rtos-integration-preview3 0cc034c 06linuxcnc 10scripts/runtests * runtests: Don't start if linuxcnc or hal is already running
[16:46:51] <KGB-linuxcnc> 03jepler 05rtos-integration-preview3 c7c1bf0 06linuxcnc 03tests/linuxcncrsh/skip * tests/linuxcncrsh: skip this test until we know what's up
[16:46:54] <KGB-linuxcnc> 03seb 05rtos-integration-preview3 4c403fa 06linuxcnc 10scripts/runtests * Revert "runtests: Don't start if linuxcnc or hal is already running"
[16:47:02] <KGB-linuxcnc> 03seb 05rtos-integration-preview3 7ec4ae1 06linuxcnc 10docs/src/config/ini_config.txt * docs: add subsections for servos & steppers
[16:47:08] <KGB-linuxcnc> 03seb 05rtos-integration-preview3 cca131d 06linuxcnc 10tests/ 10(7 files in 7 dirs) * skip all the tests that use linuxcncrsh
[16:47:14] <KGB-linuxcnc> 03seb 05rtos-integration-preview3 eeb0ee6 06linuxcnc 10tests/ 10motion/g0/test.sh 10toolchanger/toolno-pocket-differ/shared-test.sh * run nc correctly
[16:47:21] <KGB-linuxcnc> 03git 05rtos-integration-preview3 8b9ff03 06linuxcnc * Merge remote-tracking branch 'origin/v2.5_branch' into rtos-integration-preview3
[16:47:28] <KGB-linuxcnc> 03micges 05rtos-integration-preview3 60ad92d 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2.c * hostmot2: fix compilation warning
[16:47:35] <KGB-linuxcnc> 03git 05rtos-integration-preview3 bb71cbd 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2.c * Merge remote-tracking branch 'origin/v2.5_branch' into rtos-integration-preview3
[17:01:27] -!- PetefromTn has quit [Remote host closed the connection]
[17:05:37] -!- r00t4rd3d has quit [Read error: Connection reset by peer]
[17:08:46] -!- karavanjoW has quit [Ping timeout: 245 seconds]
[17:17:35] -!- hdokes has quit [Quit: Easy as 3.14159265358979323846...]
[17:22:31] -!- dway has quit [Quit: NOOOOOOooooooooo……]
[17:23:53] <linuxcnc-build> build #78 of precise-x86-rtpreempt-rip is complete: Failure [4failed apt-get-update runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-x86-rtpreempt-rip/builds/78 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, Michael Haberler <git@mah.priv.at>, Michael Geszkiewicz
[17:23:53] <linuxcnc-build> <micges@wp.pl>
[17:24:56] -!- mhaberler has quit [Quit: mhaberler]
[17:26:47] <linuxcnc-build> build #62 of precise-amd64-rtpreempt-rip is complete: Failure [4failed apt-get-update runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-rtpreempt-rip/builds/62 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, Michael Haberler <git@mah.priv.at>, Michael Geszkiewicz
[17:26:48] <linuxcnc-build> <micges@wp.pl>
[17:27:07] -!- automata [automata!~automata@42.104.176.179] has joined #linuxcnc-devel
[17:28:55] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[17:29:05] <linuxcnc-build> build #979 of precise-i386-sim is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-sim/builds/979 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, Michael Haberler <git@mah.priv.at>, Michael Geszkiewicz <micges@wp.pl>
[17:30:20] <linuxcnc-build> build #981 of precise-amd64-sim is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim/builds/981 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, Michael Haberler <git@mah.priv.at>, Michael Geszkiewicz <micges@wp.pl>
[17:30:32] <linuxcnc-build> build #977 of lucid-i386-sim is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/977 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, Michael Haberler <git@mah.priv.at>, Michael Geszkiewicz <micges@wp.pl>
[17:30:44] <linuxcnc-build> build #179 of precise-i386-realtime-rip is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/179 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, Michael Haberler <git@mah.priv.at>, Michael Geszkiewicz <micges@wp.pl>
[17:31:47] <linuxcnc-build> build #62 of precise-amd64-xenomai-rip is complete: Failure [4failed apt-get-update runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-xenomai-rip/builds/62 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, Michael Haberler <git@mah.priv.at>, Michael Geszkiewicz
[17:31:47] <linuxcnc-build> <micges@wp.pl>
[17:32:42] -!- sumpfralle has quit [Ping timeout: 252 seconds]
[17:34:12] <linuxcnc-build> build #88 of precise-x86-xenomai-rip is complete: Failure [4failed apt-get-update runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-x86-xenomai-rip/builds/88 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, Michael Haberler <git@mah.priv.at>, Michael Geszkiewicz <micges@wp.pl>
[17:36:11] <linuxcnc-build> build #978 of hardy-i386-realtime-rip is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/978 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, Michael Haberler <git@mah.priv.at>, Michael Geszkiewicz <micges@wp.pl>
[17:38:01] <linuxcnc-build> build #981 of hardy-amd64-sim is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/981 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, Michael Haberler <git@mah.priv.at>, Michael Geszkiewicz <micges@wp.pl>
[17:38:23] -!- [1]hdokes has quit [Quit: HydraIRC -> http://www.hydrairc.com <- Wibbly Wobbly IRC]
[17:38:44] <linuxcnc-build> build #980 of hardy-i386-sim is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/980 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, Michael Haberler <git@mah.priv.at>, Michael Geszkiewicz <micges@wp.pl>
[17:38:52] <linuxcnc-build> build #979 of lucid-amd64-sim is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/979 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, Michael Haberler <git@mah.priv.at>, Michael Geszkiewicz <micges@wp.pl>
[17:39:01] <linuxcnc-build> build #978 of lucid-i386-realtime-rip is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/978 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, Michael Haberler <git@mah.priv.at>, Michael Geszkiewicz <micges@wp.pl>
[17:39:02] <linuxcnc-build> build #976 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/976 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, Michael Haberler <git@mah.priv.at>, Michael Geszkiewicz <micges@wp.pl>
[17:39:09] -!- [1]hdokes has quit [Client Quit]
[17:44:19] -!- gimpswork has quit [Ping timeout: 264 seconds]
[17:47:30] -!- IchGuckLive [IchGuckLive!~chatzilla@95-89-97-224-dynip.superkabel.de] has joined #linuxcnc-devel
[17:47:52] <IchGuckLive> hi it may find a way to the examples pattern a sub
http://pastebin.com/uCRsXYTC
[17:59:03] -!- andypugh [andypugh!~andy2@cpc16-basl9-2-0-cust685.20-1.cable.virginmedia.com] has joined #linuxcnc-devel
[17:59:28] -!- pcw_home has quit [Ping timeout: 258 seconds]
[17:59:54] -!- pcw_home [pcw_home!~chatzilla@ip-66-80-167-54.sjc.megapath.net] has joined #linuxcnc-devel
[18:00:12] <seb_kuzminsky> those failures are all left-behind realtime environments fmor the linuxcncrsh tests that failed on the run before
[18:02:21] -!- danilow has quit [Quit: Page closed]
[18:04:58] -!- ler_hydra has quit [Remote host closed the connection]
[18:05:21] <seb_kuzminsky> linuxcnc-build: force build --branch=rtos-integration-preview3 checkin
[18:05:22] <linuxcnc-build> build forced [ETA 1h14m12s]
[18:05:22] <linuxcnc-build> I'll give a shout when the build finishes
[18:05:38] <jepler> mhaberler: re multi-instance: cool
[18:07:32] <mhaberler> some rough edges remain - I cant yet automatically attach a namespace in a remote usercomp (with api change - easy; test in main loop); and sending a signal is, well, not my preferred method of IPC
[18:08:59] -!- c0ldfront has quit [Ping timeout: 252 seconds]
[18:09:07] <IchGuckLive> Question why is my joypad loosing the complete halcomp after 30min of work no input pins
[18:09:39] <mhaberler> look at syslog - usb disconnect?
[18:09:59] <mhaberler> using an usb hub?
[18:10:05] <mhaberler> get rid of it if so
[18:10:12] <IchGuckLive> no direct via 10m activ cable
[18:10:34] <mhaberler> 10m.. and that is within spec?
[18:10:36] <IchGuckLive> worked fine on hypertherm but at the china plasma it goes off
[18:10:52] <mhaberler> it..off?
[18:11:06] <IchGuckLive> there are simply no pins anymore
[18:11:12] <IchGuckLive> in halmeter
[18:11:24] <mhaberler> well read the syslog for usb events
[18:11:31] <IchGuckLive> ok
[18:11:48] <jepler> the component will exit if the device disappears. if this problem occurs when you turn on plasma, it's probably not a software bug.
[18:11:53] <andypugh> My USB joypad disappears too.
[18:12:11] <andypugh> Normally I have finished with my setup by then.
[18:12:34] <IchGuckLive> i also but at the end is good to drive also
[18:13:22] -!- gonzo07 has quit [Remote host closed the connection]
[18:21:37] -!- IchGuckLive [IchGuckLive!~chatzilla@95-89-97-224-dynip.superkabel.de] has parted #linuxcnc-devel
[18:24:28] <jepler> andypugh: have you looked whether there are usb disconnect messages in dmesg when that occurs?
[18:24:45] <jepler> since our other problem reporter didn't care to answer
[18:25:02] <andypugh> To be honest, no. In fact I have never got further than a muffled curse and a switch to the keyboard :-)
[18:25:23] <jepler> hah groan
[18:25:27] <andypugh> I will try to remember to have a look next time.
[18:29:42] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 20.0/20130329043827]]
[18:30:00] <pcw_home> Do USB devices re-enumerate if they have too many CRC errors?
[18:30:26] <pcw_home> seems like they would try to re-connect
[18:30:52] <jepler> they probably re-enumerate, but hal_input was not written to handle this type of thing
[18:31:06] <pcw_home> Yeah
[18:32:14] -!- jfire has quit [Quit: Leaving.]
[18:33:17] <andypugh> Did anyone pick up on my wierd lathe cutter comp issue yesterday?
[18:33:19] -!- thesisb has quit [Quit: Leaving...]
[18:33:58] <cradek> I didn't see it
[18:34:05] <jepler> andypugh: I didn't know enough to comment
[18:35:13] <andypugh> Axis was drawing in a line under the centre of the tip circle, and the normal little cross was absent. (or hidden in the ,middle of the tool image). More strange still, a traverse at X = 20 was showing 20.8 on the DRO one direction, and 19.2 in the other direction!
[18:36:06] <andypugh> ie, G0 X20, G1 X0, G1 Z20 was displaying different X values during the two Z moves. Which isn't normal, I don't think.
[18:36:25] <andypugh> Sorry, G0 X20, G1 Z0, G1 Z20.
[18:36:51] <KimK> andypugh: I don't know enough to comment either, but if you think you are on the trail of a bug, I hope you are able to stick with it to the end. Good hunting!
[18:36:52] <cradek> can you make a little program that you think does a wrong thing?
[18:37:19] <cradek> I don't really see what you're talking about from just that
[18:37:22] <andypugh> I switched to an orientation 2 tool, and that worked normally, then back to the orientation 6, and the cross reappeared, the axis preview returned to normal, and both moves showed 20 on the DRO....
[18:38:00] <andypugh> cradek: I tried to, but the problem disappeared :-/
[18:38:41] <cradek> are you talking about doing mdi commands?
[18:38:51] <andypugh> No, G-code program.
[18:39:19] <jepler> did your program apply tool length offsets or use cutter compensation?
[18:39:37] <jepler> those are both things that will make DRO numbers not read the same as part program numbers
[18:39:44] -!- mhaberler has quit [Quit: mhaberler]
[18:39:53] <andypugh> G42, orientation 6 tool. A move at X = 7 was displaying as X = 7.8 on the DRO. And produced a 7.8mm part too.
[18:40:29] <andypugh> 0.8 radius tool.
[18:41:36] <andypugh> After a switch to a different tool and back, the DRO readout was 7, and the parts were the correct size.
[18:41:51] <cradek> I hope you can find a way to reproduce it
[18:42:24] <andypugh> As far as I can tell neither tool length or tool geometry normally change the DRO display value?
[18:42:49] <andypugh> cradek: Yes, I do too, as it is properly wrong, I reckon.
[18:43:13] <cradek> if the dro is in relative mode tlo shouldn't make the dro and the gcode command disagree
[18:43:28] <cradek> cutter comp will definitely make the dro and gcode command disagree
[18:43:54] <andypugh> On an agled move, yes. Not on a Z-traverse?
[18:43:56] <cradek> and the tool geometry will affect the particular ways they disagree in that case
[18:44:43] <andypugh> Playing around in a sim, A Z move displays the programmed X, even with cutter comp.
[18:44:44] <cradek> Z-only moves and G0 (I assume that's what you mean by traverse) are not special cases, so depending on your settings, sure
[18:45:07] <andypugh> I meant "traverse" in the lathe sense
[18:45:14] <cradek> I don't know what you mean
[18:45:28] <andypugh> The longitudinal slide
[18:45:49] <cradek> I know which way Z is, but I don't know what you mean in terms of gcode
[18:46:06] <andypugh> G0 X 7 G1 Z20
[18:46:20] <andypugh> ie, a straight move, only in Z
[18:46:37] <andypugh> Nothing to compensate in that case with an orientation 6 tool.
[18:46:42] <cradek> splitting that into two lines, yes the second move is Z only
[18:47:08] <andypugh> And in a sim, the displayed X will be 7.
[18:47:47] <cradek> if in g40 or g42, but not in g41
[18:47:50] <andypugh> (To be clearer, a G42 move towards the headstock normally displays the programmed X position)
[18:48:00] <cradek> if I have my handedness right in my head
[18:49:13] <cradek> if in g41 X will be decreased by the tool dia during that move
[18:50:12] <andypugh> I am not entirely clear still whether you use tip radius or tip diameter in the lathe tool table.
[18:51:13] <andypugh> But yes, I would expect to see the G41 move change, and not the G42. And this is exactly what I see in a SIM. But yesterday both were offset from the non-compensated move.
[18:51:37] <cradek> the docs say D=diameter
[18:52:05] <cradek> docs could probably spell out explicitly that for lathe tools it's STILL diameter
[18:52:25] <cradek> especially since there's already a lathe-specific tool table paragraph
[18:52:38] <cradek> http://www.linuxcnc.org/docs/html/lathe/lathe-user.html#_lathe_tool_table_a_id_sec_lathe_tool_table_a
[18:52:56] <andypugh> You should be able to just specify the insert code :-)
[18:53:04] -!- holgi has quit [Quit: ChatZilla 0.9.90 [Firefox 20.0/20130329043827]]
[18:53:20] <cradek> andypugh: that sounds wrong if you were in orientation 6, again I hope you can reproduce it
[18:54:05] <andypugh> Unfortunately I very rarely use cutter-comp, as I very rarely do any profiles.
[18:54:15] <cradek> I suspect your active orientation wasn't what you expected, for some reason or other
[18:54:15] <jepler> so it's probably not a very good contribution to the discussion, but
http://emergent.unpythonic.net/files/sandbox/lcap.ngc
[18:54:20] <andypugh> This was an exception, I was making a batch of pull-studs.
[18:55:10] <jepler> probably I misunderstood what andypugh was describing, but this program (understandably to me) goes inside the specified X when going RTL and outside it when going LTR, so as to keep that X=20 line always on the left by .8mm.
[18:55:39] <jepler> orientation 6 vs 9 didn't seem to make a difference to my result
[18:55:47] <andypugh> cradek: You may have hit the nail on th head there, I wonder if I was using orientation 6 frontangle and backangle, but the "6" in the orioentation column hadn't taken? That's an easy test to make.
[18:56:12] -!- markvandenborre has quit [Changing host]
[18:56:27] <andypugh> So, is R radius there, or diameter?
[18:57:00] <cradek> in G10L1? R is radius
[18:57:07] <cradek> docs say so
[18:59:21] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[18:59:42] <linuxcnc-build> build #8 of deb-precise-xenomai-binary-x86 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-xenomai-binary-x86/builds/8
[18:59:50] <linuxcnc-build> build #8 of deb-precise-xenomai-binary-amd64 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-xenomai-binary-amd64/builds/8
[18:59:53] <cradek> that R.8 does put 0.06299 in my tool table
[18:59:56] <linuxcnc-build> build #8 of deb-precise-rtpreempt-binary-x86 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-x86/builds/8
[19:00:09] <linuxcnc-build> build #8 of deb-precise-rtpreempt-binary-amd64 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-amd64/builds/8
[19:00:21] -!- automata has quit [Ping timeout: 252 seconds]
[19:00:37] <cradek> andypugh: what version were you on?
[19:01:52] <andypugh> Good question :-). I think that machine is on a buildbot .deb
[19:08:32] <andypugh> Aha! What I was seeing exactly matches the orientation-9 behaviour, though the onscreen display was like 6 (on 2.5.2 sim the orientation 9 tool is a circle)
[19:09:08] <jepler> you can comment one line and uncomment the other to see the difference (if any) the tool orientation makes
[19:09:29] <cradek> ah, then maybe you should be trying terrible combinations of editing/loading/not loading/G10L1ing the tool table
[19:10:19] <cradek> I bet you can get AXIS to show the wrong (out of date) tool shape, but doubt you can make the motion be wrong, hopefully anyway
[19:10:39] <jepler> cradek: except that andypugh said the piece measured other than was desired if I understand correctly
[19:11:19] <cradek> but possibly he was deceived by something on-screen and had the gcode and/or tool table wrong (or not loaded)?
[19:11:23] <andypugh> This is my test file, which shows the radius-compensation nicely (if zoomed in far enough).
http://pastebin.com/MJCxkDwv though does require tool table editing to see the effects.
[19:11:35] -!- syyl_ws has quit [Remote host closed the connection]
[19:12:16] <andypugh> No, part dimensions matched onscreen display. After the problem went away (which did involve a G43) the part dimensions were correct.
[19:12:50] <andypugh> (For values of "correct" modulated by the quality of my lathe, anyway)
[19:18:09] -!- psha has quit [Quit: Lost terminal]
[19:21:24] <linuxcnc-build> Hey! build checkin #977 is complete: Success [3build successful]
[19:21:24] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/977
[19:31:54] -!- morfic has quit [Ping timeout: 264 seconds]
[19:33:14] -!- FinboySlick has quit [Quit: Leaving.]
[19:36:40] <cradek> wooo
[19:44:30] -!- soy_marta has quit [Ping timeout: 258 seconds]
[19:45:40] <jepler> that's new rtos on buildbot?
[19:45:41] <jepler> whee
[19:50:39] -!- kizer has quit [Quit: Lost terminal]
[19:52:38] <mhaberler> not sure how that's supposed to work if some package fetches fail
[19:53:57] <mhaberler> obviously there must have been something on that vm leftover, but unsure what: eg:
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-xenomai-rip/builds/63/steps/apt-get-update/logs/stdio
[19:55:56] <mhaberler> it could mean it built with whatever was in the ubuntu stream for xenomai userland support, and that is way out of date
[19:57:46] -!- skunkworks has quit [Read error: Connection reset by peer]
[20:00:42] -!- Kup has quit [Remote host closed the connection]
[20:09:58] <cradek> that's expected, because there are no packages yet
[20:10:36] <mhaberler> there _are_ packages for exactly that
[20:11:06] <seb_kuzminsky> the rtpreempt vm has wheezy's rtpreempt kernel installed
[20:11:10] <mhaberler> they are on deb.machinkit.net, we did them for that purpose, and all that is needed is installing zultron's keyring
[20:11:28] <seb_kuzminsky> the xenomai vms have zultron's xenomai kernels installed
[20:11:56] <seb_kuzminsky> the next step forwards is to get the kernels onto linuxcnc.org's deb archive, i dont want to be pulling them from anywhere else
[20:12:04] <mhaberler> I was talking the userland support package - where does it come from?
[20:12:06] <mhaberler> http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-xenomai-rip/builds/63/steps/apt-get-update/logs/stdio
[20:12:35] <mhaberler> it didnt install from deb.machinekit.net which is why I assume it pulled old crap from the ubuntu stream
[20:13:00] <seb_kuzminsky> oh oops, machinekit shouldnt be in the list
[20:13:06] <seb_kuzminsky> it's not installing anything, as you can see
[20:13:13] <mhaberler> then you _force_ it to use old crap
[20:13:18] <seb_kuzminsky> it's using the debs i already installed (from machinekit)
[20:13:20] <seb_kuzminsky> yes
[20:13:31] <seb_kuzminsky> the next step forwards is to push integration of this stuff into linuxcnc
[20:13:48] <seb_kuzminsky> there's no point in pulling kernels & other debs from random places on the internet
[20:14:18] <mhaberler> ok, my machine isnt anymore random than yours, but I dont mind - as long as it happens eventually
[20:14:29] <seb_kuzminsky> that's what i want too michael....
[20:14:48] <seb_kuzminsky> just waiting to review now
[20:15:09] <mhaberler> please.. can we put that to rest.
[20:15:45] <zultron> Hey seb_kuzminsky, let me know if I can help with anything. My automatic script is missing a thing or two, like creating a debian pkg archive. Would that help?
[20:20:28] -!- Tecan has quit [Quit: Live Long And Phosphor!]
[20:24:22] <seb_kuzminsky> zultron: yeah, hugely!
[20:24:52] <seb_kuzminsky> my issues from last time we looked at it are:
[20:25:13] <seb_kuzminsky> 1: it fetches xenomai debs frmo elsewhere, instead of using the ones it just built
[20:25:22] <zultron> Ok. I should have that process worked out, but it's always a bit of work to put stuff into a Makefile
[20:25:31] <seb_kuzminsky> 2: doesn't build the rtl 8168 module
[20:25:41] <zultron> Yeah, #1 is a problem for sure.
[20:26:06] <seb_kuzminsky> 3: we need to review the git repos it fetches all the stuff from
[20:26:11] <seb_kuzminsky> that's all i had
[20:26:29] <zultron> And fixing #1 also gives us debian archives that the buildbot could use.
[20:26:36] <seb_kuzminsky> that system is sweet, i'm super excited to have such good repeatable kernel building, so thank you
[20:26:45] <seb_kuzminsky> perfect
[20:27:08] -!- Herschi has quit [Client Quit]
[20:27:12] <zultron> #2 is important for users wanting to install packages. It's not needed by the buildbots, though, correct?
[20:27:26] <seb_kuzminsky> once we're building the debs correctly we'll put them in the One True Debian Archive on linuxcnc.org where all other official packages live
[20:27:31] -!- carper64_lb has quit [Ping timeout: 245 seconds]
[20:27:42] <zultron> #3: It's all my stuff, so someone else needs to do the review. :)
[20:27:56] <seb_kuzminsky> yeah that's right, 2 is only for users, the buildslaves dont care
[20:28:00] <mhaberler> Seb - while you are at it, please set up a VM which has all RTOS userland support installed (xenomai and RTAI); kernel dont matter; we will need that for the unified binary
[20:28:26] <seb_kuzminsky> and yeah i agree on #3, it's not your task, that one's on me and whoever else wants to pitch in
[20:28:51] <seb_kuzminsky> mhaberler: no
[20:29:29] <zultron> Why come? I want a buildbot like that too.
[20:29:50] <seb_kuzminsky> sure, when it's time, but now's not the time
[20:30:09] <seb_kuzminsky> let's get one thing merged before we build other stuff on top of it, it just makes sense
[20:30:23] <mhaberler> we had half a year of 'time', and those requirements changed since then
[20:31:34] <seb_kuzminsky> no, nothing's changed
[20:31:41] <seb_kuzminsky> development happens one step at a time
[20:37:22] <cradek> mhaberler: can you summarize what's in the way of cleanup/review/merging the new-rtos support? seems like you guys have agreed over and over on how to do it but it never happens. it would be awesome to get it reviewed and merged before fest.
[20:39:28] <mhaberler> I think it need to be built first, and not the stuff we had 6 months ago, but the stuff which is maturing now - because there is absolutely no point to rock the boat twice, and the upside is that the unified binary will simplify logistics big time.
[20:40:09] <cradek> what is currently not built?
[20:40:09] <mhaberler> meaning: I would appreciate to have some say what is to be merged, as I know the differences and the upside
[20:40:27] <mhaberler> the unified binary branch which we've been talking about for months
[20:40:31] <cradek> I thought people were actually running linuxcnc on these new platforms
[20:40:34] <mhaberler> that is the one to go for
[20:40:42] <mhaberler> yes,, from git builds
[20:41:21] <cradek> why can't we clean/review/merge that work? are you throwing it away?
[20:41:22] <mhaberler> what you have with the old rtos branches is a ton of variants, one per rtos
[20:41:37] <mhaberler> it is not thrown away since the ub is based on rtos3
[20:42:16] <cradek> so are you saying cleanup of rtos3 is a necessary step anyway, you just disagree about the order of that vs. continuing new work on top of it?
[20:42:21] <mhaberler> with the ub you get a _single_ package and a collection of module trees, and you are done for _all_ rtos platforms, period
[20:42:56] <mhaberler> yes, when the ub branch based on rtos builds and the kinks are worked out, cleaning history makes sense
[20:43:15] <mhaberler> it makes zero sense to merge rtos3 now and get everybody through the learning curve
[20:43:28] <mhaberler> one month more or less dont matter anymore, really
[20:43:53] <mhaberler> I'd rather have all those Q&A sessions once, not twice
[20:44:19] -!- DJ9DJ has quit [Quit: bye]
[20:44:29] <cradek> well I see the same disagreements over and over, and I'm trying to understand that
[20:44:35] <mhaberler> which is why I suggested we have a build VM which can do it
[20:44:59] <cradek> several times now I've seen you agree to clean up the existing work for review and merge, but then decide not to, and continue making new changes instead
[20:45:13] <mhaberler> no, that is not the case
[20:45:37] <mhaberler> what I said is I will clean the branch which will be merged, which will include the rtos3 history below it
[20:45:46] <mhaberler> but from that it doesnt follow I want rtos3 merged
[20:46:14] <mhaberler> for the reasons outlined above
[20:47:13] <cradek> in that case, I would be happy if we could start reviewing the parts that you will keep under your new work.
[20:47:39] <cradek> as a favor to those of us who want to review, could you clean up and share that part before continuing? it seems useful anyway, as people are using it already.
[20:48:11] <mhaberler> the way I work isnt piecemeal here and there, but rather like so
[20:48:13] <cradek> I'm sure you know reviews can get really unwieldy if you have too many things mixed together
[20:49:13] <cradek> I understand preferring to work a certain way, but when collaborating with others sometimes compromises can help lube the interactions. Would you consider doing that?
[20:49:31] <mhaberler> I do not want to be pressed into working on pieces here and there piecemeal
[20:50:38] <cradek> perhaps someone else could do the cleanup step for you, then? would you work with someone else to accomplish that?
[20:50:40] <mhaberler> I dont think I had any problems with interactions with the folks which worked with me on it, so thats a bit theoretical - I actually _do_ work with other people, contrary to many other
[20:51:41] <mhaberler> look Chris - I dont understand this sudden itch - for months we had roundabout zero support and suddenly it has to go a certain way - I would appreciate if I had a say in it
[20:52:14] <mhaberler> nobody is hindered from using things from git to start with
[20:52:27] <mhaberler> as for the new ub branch, I want this done as follows:
[20:52:56] <cradek> don't get angry with me, I'm not trying to start a fight. I just see a lot more arguing than progress lately and would like to understand and possibly help.
[20:53:13] <mhaberler> I'm not angry - just explaining how I want it done
[20:54:01] <mhaberler> I do want a working build infra before focusing on the task, and if I do so I will focus on it continuously until its done. If I dont have that, I could as well work with a bunch of PC's and boards here - which I partially have and is a bloody nuisance
[20:54:08] <mhaberler> thats really all that is to it
[20:54:57] <mhaberler> I cant nail two targets at once
[20:55:59] <mhaberler> and the reason why I want to do it in one wash is because it is more effective for me - if I do a bit now and a bit then, I loose context and need to relearn it
[20:56:52] <cradek> how much work (say, number of hours) do you think is involved in the cleanup work seb wants you to do, that would allow us to review the work that is done so far?
[20:57:03] <mhaberler> there is no mean scheme, I just dont want to waste time on this which is used ineffective IMO
[20:57:40] <mhaberler> you are thinking in terms of cleanup work, which is beside the point for the ub
[20:57:45] <cradek> I mean the parts that will be kept under your new UB work
[20:57:54] <mhaberler> that is at the core of the misunderstanding
[20:58:02] <cradek> then please explain
[20:58:12] <mhaberler> the rtos3 stuff is stable
[20:58:30] <cradek> are you building on top of it or not?
[20:58:36] <mhaberler> yes
[20:58:48] <mhaberler> ub is a linear rebase on rtos3
[20:58:54] <mhaberler> no magic here
[20:58:58] <cradek> but this basis work is not in final shape, right?
[20:59:13] <mhaberler> the ub stuff works, but the build integration (modules for all flavors) needs to be done, and worked out on all platforms
[20:59:21] -!- tmcw has quit [Remote host closed the connection]
[20:59:57] <cradek> ah, that part may require help from others (the buildy folks)
[21:00:31] <mhaberler> well I'm working right now with John on it, and Jeff's changes have been very helpful, so it will happen anyway
[21:00:38] <cradek> great
[21:00:48] <mhaberler> simple matter of time ;)
[21:01:05] <mhaberler> I suggest to have that bit of patience until this is done
[21:01:14] <mhaberler> note there are no _functional_ changes really
[21:02:20] <mhaberler> between rtos3 and ub (except multi-instance but thats on the HAL level only and would need a round of work to be made available - which I dont want to because NML needs fixing and that will be history before I get there ;)
[21:02:31] <cradek> I don't have any impatience and I don't see where you are reading that. my only concern is that isolated small sets of changes are easier to review. I think that's seb's concern too, if I'm reading it right.
[21:03:17] <cradek> certainly NML replacement is a separate project!?
[21:03:32] <mhaberler> well there will be a clear cut in the history where you see where the ub work starts, and that really correlates to the current rtos3 tip except for swaushing and rewriting some commits)
[21:03:39] <mhaberler> definitely, not before end of year
[21:04:05] <cradek> yes, ideally after the other stuff is merged into master and people use it enough for it to stabilize
[21:04:24] <mhaberler> oh sure, I have no intent of coming forward with any of that early
[21:04:48] <mhaberler> no point
[21:05:13] <cradek> but to be clear you're unwilling to clean the stuff before that clear cut before continuing on the work after it? it seems like that is all seb is asking you to do and I would also appreciate it so we can get to reviewing.
[21:05:30] <mhaberler> _no_
[21:05:58] <mhaberler> what I said is: I want to do this in one go. and it would help if I had the bb support needed before I start
[21:06:22] <mhaberler> yes, I will take out the occasional random commit message before rtos3 too when I am at it
[21:06:30] <mhaberler> like FIXME etc
[21:07:24] <mhaberler> to repeat: once I am at it, I will clean the whole history back to v2.5branch back then
[21:08:04] <cradek> cool, that sounds like exactly what seb is asking you to do
[21:08:33] <mhaberler> you missed the bb support part
[21:09:28] <mhaberler> to build a ub, you need a VM which has all libs (xenomai, rtai, etc on it) regardless of kernel, otherwise it can build only a subset
[21:09:29] <mhaberler> which misses the whole point
[21:09:40] <cradek> well I can't influence that - hope it is not an impasse for you two
[21:10:55] <cradek> thanks for the explanations, I have a better feel for what's up now.
[21:14:36] <mhaberler> actually thinking of it, those might be doable through debian/control and not require a separate VM
[21:14:55] <mhaberler> or wherever the prerequisites are
[21:16:11] <zultron> I was thinking that too, but the buildbot builds the raw git tree first, not in a pbuilder, so all the runtime libs & kernels would still need to be on the buildbot.
[21:17:20] <mhaberler> so we do
[21:20:42] -!- frallzor has quit []
[21:20:42] <jepler> it looks like even when doing a non-package build, the buildbot uses the debian/configure+debian/control method to install packages required at build time
[21:21:00] <jepler> this is not a package builder but it does configure-debian-control and install-missing-build-dependencies steps
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/982
[21:24:00] <zultron> Ah, so if the right debian archives were configured in /etc/apt/sources, it would pull dependent packages.
[21:24:09] <mhaberler> well it's worth an experiment, still we cant work with the xenomai userland stuff in the ubuntu stream so we need either the package from machinekit or a local replica
[21:24:54] <zultron> Then that must be what Seb was talking about: the dependent packages aren't in the Ubuntu or LinuxCNC debian archives.
[21:25:18] <zultron> It's not a matter of manually installing them on the buildbot.
[21:26:05] -!- zlog has quit [Remote host closed the connection]
[21:26:34] <zultron> Hmm, but actually those *should* be manually installed. If the package pulls e.g. the Xenomai kernel, it'll configure itself in grub as the default, if I understand .deb kernel packages well enough.
[21:27:20] <zultron> If that's allowed to happen, the rt-preempt buildbot may come up with a xeno kernel at next rebot.
[21:27:28] <zultron> reboot
[21:27:33] -!- chillly has quit [Quit: Leaving]
[21:27:53] -!- wboykinm has quit [Remote host closed the connection]
[21:29:57] <jepler> this looks like passwordless sudo isn't properly configured for the buildslave user:
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-xenomai-binary-amd64/builds/8/steps/shell_2/logs/stdio
[21:30:14] <cradek> usually the kernel package named -headers is the build dependency, and that would not cause the problem you describe. are you talking about a build-dep?
[21:33:00] <jepler> mhaberler: you mentioned the ubuntu packages being too old(?) to work properly -- can you use debian package version numbers so that we get an error (in dpkg-checkbuilddeps) that simply states the problem? For instance, libxenomai-dev (>= 1.0.0) if 1.0.0 is good but 0.9.9 isn't good enough (totally a for instance; I don't even know what the package names are)
[21:33:02] <zultron> Is that addressed to me? If the -headers pkg doesn't depend on the kernel package itself, that wouldn't be a problem.
[21:33:18] <zultron> Sounds right, that is. :)
[21:33:35] <cradek> Provides: linux-headers, linux-headers-2.6
[21:33:36] <cradek> Depends: coreutils | fileutils (>= 4.0), linux-headers-2.6.32-38, libc6 (>= 2.8)
[21:33:39] <mhaberler> I think that'd be an option, except I dont see where the newer one would come yet
[21:33:42] <mhaberler> from
[21:33:51] <cradek> it doesn't on this one...?
[21:34:09] <jepler> yes I think linux-headers don't depend on linux-image
[21:34:38] <zultron> Great! I can stop worrying. :)
[21:34:42] <cradek> yay
[21:35:56] <mhaberler> that is one of the culprits, here from wheezy:
http://hastebin.com/necusahivo.avrasm
[21:37:33] <mhaberler> this is the custom set: libxenomai-dev libxenomai1 xenomai-doc xenomai-runtime
[21:38:40] <jepler> huh, can't resolve hastebin.com over here
[21:40:25] <mhaberler> used nameservers for sale here!
[21:41:11] <jepler> oh ours is running on a perfectly reasonable FreeBSD 6.2-RELEASE box
[21:41:13] -!- skorasaurus has quit [Quit: left the building.]
[21:42:13] <jepler> well now it resolves
[21:42:20] <jepler> I guess the dns packets were slow
[21:44:16] -!- motioncontrol has quit [Quit: Sto andando via]
[21:44:48] -!- micges [micges!~toudi@dho47.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[21:46:14] <jepler> mhaberler: if that's the oldest xenomai version it's reasonable to support, then you'd arrange to have debian/configure write something like 'xenomai-runtime (>= 2.6.0-2)' to the Build-Depends or Depends lines of debian/control
[21:47:53] -!- odogono has quit [Ping timeout: 252 seconds]
[21:48:15] <jepler> mhaberler: I'm out for now. please ping me if I don't push an update of that rtapi branch by thursday.
[21:48:26] <mhaberler> ok well we are at libxenomai-dev_2.6.2.1-3_amd64.deb for example in the machinekit repo
[21:48:37] <mhaberler> fair enough, will do
[21:48:43] <jepler> as far as I recall, it was just the pm thing and the pcidev vs pci_dev thing, and I wasn't sure I understood what was going on with the latter..
[21:49:28] <mhaberler> afaict you used v2.5_branch as a base, but that wouldnt use the userland code ?
[21:49:41] <mhaberler> maybe linked into rtapi
[21:49:51] <jepler> right .. unfortunately, the way I did it I wasn't actually testing the userspace part at all
[21:49:55] <jepler> which is why it didn't work when you went to try it
[21:50:00] <mhaberler> ah ok
[21:50:47] <mhaberler> well the oldest v2.5 based applicable branch would be rtos-integration-preview3 and that would compile it for any userland threads flavor
[21:50:58] <jepler> yes
[21:51:19] <jepler> I would need to merge the two branches and that was not an instant process
[21:52:06] <jepler> bye
[21:52:11] <mhaberler> cu & thanks!
[22:06:02] -!- thesisb has quit [Ping timeout: 255 seconds]
[22:17:35] -!- mhaberler has quit [Ping timeout: 252 seconds]
[22:19:14] -!- largecheesepuff has quit [Ping timeout: 252 seconds]
[22:35:27] -!- gonzo_ has quit [Ping timeout: 276 seconds]
[22:39:44] -!- hdokes has quit [Read error: Connection reset by peer]
[22:43:58] -!- Simooon has quit [Quit: Leaving]
[22:44:36] -!- morfic has quit [Ping timeout: 245 seconds]
[22:50:34] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[23:00:36] -!- zzolo has quit [Quit: zzolo]
[23:06:24] -!- Tecan has quit [Quit: Live Long And Phosphor!]
[23:10:35] -!- Felix29 [Felix29!Felix@c-71-193-105-131.hsd1.in.comcast.net] has joined #linuxcnc-devel
[23:16:32] -!- morfic has quit [Ping timeout: 256 seconds]
[23:22:55] -!- asdfasd has quit []
[23:25:58] -!- tmcw has quit [Remote host closed the connection]
[23:27:25] -!- amefad has quit [Quit: Page closed]
[23:33:14] -!- jfire has quit [Read error: Connection reset by peer]
[23:35:19] -!- micges1 [micges1!~toudi@acwd67.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[23:35:51] -!- rob_h has quit [Ping timeout: 245 seconds]
[23:38:07] -!- asdfasd has quit [Ping timeout: 268 seconds]
[23:38:14] shdhdfghd is now known as asdfasd
[23:38:22] -!- micges has quit [Ping timeout: 256 seconds]
[23:39:27] micges1 is now known as micges
[23:39:58] -!- adb has quit [Ping timeout: 268 seconds]
[23:41:00] -!- morfic has quit [Ping timeout: 264 seconds]
[23:53:32] -!- jfire1 has quit [Read error: Connection reset by peer]
[23:56:11] -!- Patang has quit [Ping timeout: 240 seconds]