Back
[01:05:06] <memleak> zultron, why not use LTS kernels?
[01:05:16] <memleak> (w/ RTAI)
[07:53:55] <mhaberler> I have no idea how we are supposed to 'test against RTAI 3.5.7' - I do not see any downloadable package for it
[07:59:08] <KGB-linuxcnc> 03git 05unified-build-candidate-0 66ababb 06linuxcnc 10src/rtapi/rtapi_proc.h * rtapi_proc: add /proc/rtapi/instance
[07:59:09] <KGB-linuxcnc> 03git 05unified-build-candidate-0 9a7ddcb 06linuxcnc 10src/ 10rtapi/rtapi.h 10rtapi/rtapi_compat.c * rtapi_compat.c: add kernel_instance_id() method
[07:59:12] <KGB-linuxcnc> 03git 05unified-build-candidate-0 23b8ec3 06linuxcnc 10src/rtapi/rtapi_msgd.c * rtapi_msgd: reorganize startup sequence
[07:59:18] <KGB-linuxcnc> 03git 05unified-build-candidate-0 312b3d1 06linuxcnc 10scripts/realtime.in * scripts/realtime: simplify startup by shifting checks to rtapi_msgd
[07:59:25] <KGB-linuxcnc> 03git 05unified-build-candidate-0 978da4a 06linuxcnc 10scripts/realtime.in * scripts/realtime: enable passing options to shmdrv through SHMDRV_OPTS
[08:04:54] <linuxcnc-build> build #1221 of hardy-i386-realtime-rip is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1221 blamelist: Michael Haberler <git@mah.priv.at>
[08:05:11] <linuxcnc-build> build #1225 of hardy-amd64-sim is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1225 blamelist: Michael Haberler <git@mah.priv.at>
[08:05:47] <linuxcnc-build> build #1223 of hardy-i386-sim is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1223 blamelist: Michael Haberler <git@mah.priv.at>
[09:02:36] <linuxcnc-build> build #422 of precise-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/422 blamelist: Michael Haberler <git@mah.priv.at>
[09:02:37] <linuxcnc-build> build #1219 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1219 blamelist: Michael Haberler <git@mah.priv.at>
[10:46:05] <seb_kuzminsky> mhaberler:
http://highlab.com/~seb/linuxcnc/rtai-for-3.5-prerelease/
[10:46:32] <mhaberler> is this apt-gettable or dpkg -i?
[10:46:46] <seb_kuzminsky> dpkg
[10:46:49] <mhaberler> ok
[10:47:09] <mhaberler> thanks, will try that on the atom too
[10:47:21] <seb_kuzminsky> that's based on paolo's magma, but i'll be switching to avalanche soon i think
[10:47:27] <zultron> seb_kuzminsky, last I remember there were problems with 64-bit. Is that why no amd64 pkgs, or just because those weren't built?
[10:47:59] <seb_kuzminsky> yes paolo's magma doesn't do 64-bit rtai correctly
[10:48:10] <zultron> Got it.
[10:48:11] <seb_kuzminsky> or at least it didn't in... april, when i tried it last
[10:48:59] <mhaberler> do you run this on your machine, or is this for bb only?
[10:50:14] <seb_kuzminsky> both
[10:51:59] <zultron> Which VM technology do you use on the bb? I'm going to try running these under Xen, but I'm skeptical whether it'll work.
[10:52:52] <seb_kuzminsky> i use kvm via libvirt
[10:53:14] <zultron> Noted, thanks
[10:53:27] <seb_kuzminsky> my vm host is an old lucid server
[10:54:00] <seb_kuzminsky> i keep meaning to upgrade it to precise or something, but... it currently works and there's always been higher-priority things to do
[11:05:26] <mhaberler> Seb: whats's tge difference in the two modules packages?
[11:05:38] <mhaberler> I have a 10.04lts livecd base
[11:05:50] <mhaberler> I assume the 'ubuntu' flavor then?
[11:06:52] <seb_kuzminsky> i think they're two similar but different versions of the same thing, use the one with the larger version number
[11:11:58] <mhaberler> did you uninstall the 2.6 kernel before installing this one?
[11:12:08] <seb_kuzminsky> i've never installed this kernel on lucid (which ships with the 2.6 kernel)
[11:12:19] <seb_kuzminsky> i installed precise 32-bit, and added this package
[11:17:21] <zultron> ssi, you attending the #linuxcnc-meet?
[11:34:31] <memleak> zultron, i'm working on the 64-bit code in RTAI, should be fixed in about a week or so.
[11:35:21] <seb_kuzminsky> memleak: join us in #linuxcnc-meet!
[11:35:28] <memleak> seb_kuzminsky, avalanche only supports 2.6 kernels but 64-bit should work fine.
[11:35:32] <memleak> uh... ok :)
[11:38:17] <memleak> direct vectoring of interrupts doesn't work though in avalanche in 64-bit, I'm working on that in master for 64-bit but that means 3.x+ only
[11:44:16] <memleak> seb_kuzminsky, have you worked at all on the 64-bit build problem for linuxcnc?
[11:44:32] <memleak> the SSE sincos error we talked about a few days ago.
[12:09:30] <mhaberler> great, so here is my carry - over issue from meet:
[12:09:41] <mhaberler> Let me say this - I am a bit angry, but - compatible with the Wichita takeaway that we would cooperate in good faith - I try to make my point in a professional way:
[12:09:43] <mhaberler> We did received encouragement - if not to say pressure - to move ahead with the unified build branch and bring it into shape for merging.
[12:09:44] <mhaberler> We have arrived at this point - a first candidate is available. This is what we need from you now:
[12:09:46] <mhaberler> We need active and constructive work - not just on our side, but by the core developers who express interest. This is what I am requesting you to do - please to read through the - admittedly at this point fragmentary - documentation link I posted, build this branch on your own machines, and report back, ideally via the tracker so issues are not lost. I have already received lots of constructive feedback from many non-core developer
[12:09:47] <mhaberler> We routinely test on several platforms (me on 5 different ones), and I do push stuff which I found to at least pass runtests. It is very clear the fundamental changes which this work brings about will also require changes to the build environment, some to the better. We need these to happen, and we cannot effect them since this is not in our control. It is - as things stand - a hopeless cause if the stance is 'you guys push this
[12:09:48] <mhaberler> through the buildbot and we go from there' - this effort will not succeed without a more proactive attitude.
[12:09:49] <mhaberler> I hope to continue in the Wichita spirit!
[12:10:05] <jthornton> be back in a bit
[12:11:13] <seb_kuzminsky> i have been building your branch and providing feedback and patches, and will continue to do so
[12:12:08] <zultron> (I'm sticking around for a few minutes for this)
[12:12:20] <seb_kuzminsky> i can only stick around a few minutes too
[12:12:26] <mhaberler> great. I understand it is a rocky transition, and a bit too learn, but we cannot do it all alone and particularly appreciate anybody actively engaging
[12:12:51] <seb_kuzminsky> i think you would get much better feedback if your branch was in a state where it could be more easily understood
[12:13:26] <seb_kuzminsky> we have talked about this before, i gave you my suggestion on how to make it more digestible by others (rebase & organize, basically), and you agreed to do it, but never did the work
[12:14:08] <seb_kuzminsky> as is, it's 1200 commits long and full of false starts and broken commits, which really increases the work for everyone else, now during the merge review and later after the merge
[12:14:09] <zultron> We had a discussion about that in Stuart's 2nd shop's office.
[12:14:43] <zultron> There wasn't a conclusive plan, but I remember the two main ideas were:
[12:14:47] <mhaberler> rebasing is utterly unrealistic at this stage, and the history is what it is, but it does not prevent anybody from forming an opinion and contributing.
[12:15:04] <seb_kuzminsky> yes, you and charles and i agreed on a piecemeal merge, but then michael objected vehemently and asked for 1-2 more weeks to finish up more work
[12:15:13] <zultron> 1. Go back and break everything up into more digestible chunks
[12:15:37] <zultron> 2. Evaluate the top-level commit tree as it is
[12:16:09] <cradek> mhaberler: it makes us rely on the documentation you have added saying what changed (which I appreciate) instead of understanding the changes, which is fairly impossible (which I would prefer)
[12:16:32] <mhaberler> seb: basically what I am asking you is this: the bb fails on say rtai 3.5.7 . please build that tree on your machine and find out what the problem is if we cannot rpeoduce it locally
[12:16:35] <zultron> I don't think I agreed on a piecemeal merge. That's an enormous amount of work to go back and do that, since everything is so intertwined.
[12:17:17] <seb_kuzminsky> your branch makes a large number of unrelated changes, and i wish we could consider each on its own merits, instead of "this is the end result, take it or leave it"
[12:17:31] <seb_kuzminsky> this is what i've been asking for all along, and what i thought we agreed to, multiple times
[12:17:39] <mhaberler> cradek: I continually work on the document - it clearly leaves to be desired, but it will eveolve
[12:17:59] <seb_kuzminsky> some of the things in the ub branch need to come out, or be drastically changed, for example emcweb
[12:18:07] <cradek> SOME of the history MUST be rewritten for a merge, especially fixing some bogus authorships, and renaming emcweb
[12:18:30] <cradek> those things are undisputable
[12:18:42] <zultron> Yes, you've been asking for it repeatedly, and I understand why you want it. I'd also like to give you that if I had the energy to replay the last 8 months' work.
[12:19:07] <zultron> I think we might find another way to do it though, just looking at the tree as it is today.
[12:19:23] <mhaberler> my last count of the string 'emc' in the linxucnc tree was beyond 75.000. We can easily rename a directory, the build is already optional, but I am usnure about the rationale.
[12:19:40] <zultron> It's still modular, even though it looks like a giant blob from 10k feet.
[12:19:45] <mhaberler> I am talking about emcweb being enabled by --enable-emcweb
[12:20:02] <zultron> What if we isolated parts of it to review, and did those one at a time?
[12:20:41] <mhaberler> so what is left, renaming the directory?
[12:21:16] <zultron> Can we agree that emcweb will be renamed, and move on?
[12:21:17] <seb_kuzminsky> "what is left" is reviewing this branch and understanding what it does, identifying the problems, and fixing them
[12:21:32] <mhaberler> fine, propose a name, let us move on.
[12:21:34] <zultron> I agree with that statement.
[12:21:55] <zultron> But I disagree that sifting through the history is the best way to do it.
[12:22:12] <seb_kuzminsky> sifting through the history is impossible at this time, there's too much and it's too chaotic
[12:22:41] <zultron> Ah, if you agree with that, I feel a lot better.
[12:23:30] <zultron> I believe Michael's document does a reasonable job of pointing out the changes from a high level.
[12:23:33] <cradek> for what it's worth, I'd feel a lot better if we would all commit to avoiding that situation in future work
[12:23:43] <seb_kuzminsky> this collaboration model of forking for 8 months and then saying "merge this" is bad for this reason - it makes the merge super awkward
[12:24:07] <seb_kuzminsky> it makes all the different changes impossible to understand on their own
[12:24:20] <zultron> I agree. I hope we don't have to dig up why that happened again, though.
[12:24:33] <zultron> I absolutely want to avoid this again.
[12:24:38] <seb_kuzminsky> me too
[12:24:47] <cradek> me too
[12:24:51] <mhaberler> at the core is the rtapi directory, which is all that is do it
[12:25:04] <zultron> Actually, I don't mind talking about why it happened again, but I don't have time today.
[12:25:19] <seb_kuzminsky> i dont have time right now either
[12:25:34] <seb_kuzminsky> i do want to merge the good parts of your work
[12:25:39] <seb_kuzminsky> but i dont know how to do it
[12:25:50] <seb_kuzminsky> it's not going to be quick or easy
[12:26:26] <mhaberler> fine - all I request at this point is: you build it on your machines, please help systematically with the tracker, help it through the buildbot.
[12:26:43] <zultron> Ok, so we're going to have to find some way to make the job manageable, meaning break it up into smaller pieces.
[12:27:26] <zultron> mhaberler is right, you guys should build & run on your machines so that we have the common infrastructure to discuss.
[12:27:32] <seb_kuzminsky> i'm doing that
[12:27:51] <seb_kuzminsky> if you guys aren't going to do the rebase, i guess i'll have to do it
[12:27:55] <zultron> Great! I don't mean to say you're not, sorry.
[12:27:55] <mhaberler> I am happy to hold hands at it, but I cant do it for all of you
[12:28:21] <zultron> What's 'the rebase'?
[12:28:31] <seb_kuzminsky> i'm currently rebasing ja4 for the exact same reason (to make it managable and understandable), i'll rebase your branch when i'm done with ja4
[12:28:36] <mhaberler> Seb: I will point you to a range of commits which I tried to squash and reword, I failed how to do it - not enough git fu
[12:28:44] <mhaberler> I would apprciate help on that one
[12:28:50] <seb_kuzminsky> zultron: rebasing is a way of re-writing history in git
[12:29:03] <seb_kuzminsky> it lets you change what commit a branch is based on, how commits are ordered
[12:29:11] <zultron> I know what rebasing is, but what rebase do you want us to do that we aren't doing?
[12:29:14] <seb_kuzminsky> it lets you "squash" two commits together, or split a commit apart
[12:29:16] <seb_kuzminsky> oh
[12:29:37] <seb_kuzminsky> my goal is to make your changes understandable, meaning:
[12:29:51] <seb_kuzminsky> all the commits that change one thing are together, and separate from all the commits that change other things
[12:30:10] <seb_kuzminsky> commits that are broken (bad merge commits, incorrect author emails, etc) are fixed or removed
[12:30:26] <seb_kuzminsky> false starts taken out
[12:30:34] <seb_kuzminsky> better commit messages (no "wip")
[12:30:54] <mhaberler> yes, I heard that before, and I did request help above
[12:31:22] <mhaberler> what we can do is throw away the history, and create a new one per file in rtapi - this will not help with bisecting though.
[12:31:24] <zultron> So I'm looking at the top-level goal, 'to make [our] changes understandable'.
[12:31:35] <seb_kuzminsky> mhaberler: i can help you with git if you like
[12:31:51] <mhaberler> fine - I will mail you that range, thanks
[12:31:58] <seb_kuzminsky> one commit per file is not helpful, what we should be going for is "each commit makes sense on its own and in the history"
[12:31:58] <zultron> Why is sifting through the history like that the only way to make these changes understandable?
[12:32:27] <seb_kuzminsky> 0 11:17:46 seb@steel /home/seb/linuxcnc.git> git diff --stat origin/master..origin/unified-build-candidate-0 | tail -1 620 files changed, 83310 insertions(+), 11750 deletions(-)
[12:32:40] <seb_kuzminsky> i think it's be easier than understanding a 100,000 line diff
[12:32:43] <zultron> What if we were to point out the various high-level changes and discuss those pieces?
[12:33:12] <mhaberler> that is likely a merge commit, which happens all the time in rolling forward
[12:33:14] <seb_kuzminsky> also, rebasing is the only way to fix some of the issues, like committers with bogus names/emails
[12:34:29] <zultron> fixing bogus names/emails with a rebase is trivial compared to what you're suggesting with the 'understandable' goal.
[12:34:33] <cradek> zultron: I bet the conceptual ideas you'd convey when pointing out high level changes are exactly what seb would need to group the corresponding source changes together
[12:34:47] <cradek> and that could make everyone happy
[12:34:58] <mhaberler> meaning exactly what?
[12:35:36] <jmk-mcfaul_> is it possible to eat the elephant one bite at a time? if fixing the author problem is a trivial rebase, then do it? is there some reason that rebase and the "other" rebase that seb is talking about are inter-related?
[12:35:43] <mhaberler> just trying to understand what you just said?
[12:35:56] <seb_kuzminsky> zultron: the rebase is going to be non-trivial no matter what, because of all the merges in your history
[12:36:17] <mhaberler> that is a side issue, and can be done, just like the contentions 'wip' commits which are less than 2% at last count
[12:37:11] <cradek> yes fixing those authors is not hard (if we have the information) - kind of a side issue
[12:37:12] <jmk-mcfaul_> if it is a managable side issue, and can be done, and doesn't relate to the rest of the problem, then why not just do it and get it off the table?
[12:37:29] <mhaberler> that is why I asked help above, since I already tried
[12:37:42] <seb_kuzminsky> cradek: we have that info, Joe Chipper is Ian McMahon and he's agreed to us re-writing the Joe commits to be him
[12:37:44] <zultron> Of course we can change the authors, yes, let's just do that & forget it.
[12:37:59] <mhaberler> so we can consider this off the list even if not yet done, I hope
[12:38:02] <cradek> for that question, I think you just use commit --amend --author=... etc
[12:38:03] <seb_kuzminsky> i dont remember if there were other commits by unknown authors
[12:38:14] <seb_kuzminsky> it's not going to be that easy
[12:38:14] <cradek> seb_kuzminsky: ok, cool
[12:38:21] <seb_kuzminsky> the rebase is going to suck because of all the merges
[12:38:33] <zultron> As for the merges, I'm actually not aware of the merges, but what's the issue with them? Is it the merges themselves, or the merge concept in general?
[12:38:36] <mhaberler> there were a few which a escaped Charles from the bb image as 'Joe Chipcutter'
[12:38:54] <seb_kuzminsky> zultron: both, imo
[12:38:59] <cradek> I don't have any experience with big rebase cleanups
[12:39:18] <seb_kuzminsky> several of the merges in your history introduce merge conflict markers into the tree, and then later commits come back and take them out
[12:39:24] <mhaberler> well it is standard procedure with master I understand, so I dont understand that point either, which is why I worked on that assumptions
[12:39:29] <seb_kuzminsky> that break bisect, among other problems
[12:39:46] <seb_kuzminsky> non-fast-forward merges in master are quite rare
[12:39:53] <seb_kuzminsky> and that's a good thing
[12:39:57] <mhaberler> great, than please point them out to me so we can get them out
[12:40:01] <cradek> oh are there more of those conflict markers in this branch?
[12:40:25] <cradek> (the ones that bit me a while back were already in our master and it's too late to fix them)
[12:40:41] <mhaberler> note I have been aiming at a buildable branch because you guys are interested in having something, which necessarily postpones cleanup - so please be rational in what you ask for
[12:41:00] <mhaberler> both at same instance cant be done
[12:41:06] <seb_kuzminsky> i dont feel like i'm being irrational
[12:41:20] <zultron> Hmm, I don't know enough to discuss this, but what you're saying about breaking bisects doesn't agree with other things I've read. I'll research more.
[12:41:38] <zultron> What's the issue with the merge conflict markers?
[12:41:42] <seb_kuzminsky> what breaks bisect isn't merge commits per se
[12:42:03] <seb_kuzminsky> what breaks bisect is having commits that don't build, such as merge commits that introduct merge conflict markers into source code
[12:42:08] <mhaberler> all I am saying is: I gave priority to a buildable branch, which is why I now ask you to verify it is buildable; if that is resolved, we turn to the cosmetic aspects
[12:42:09] <jmk-mcfaul_> code containing those markers won't compile
[12:42:38] <zultron> Oh, are you talking about ====== and <<<<<<<?
[12:42:43] <zultron> That's bad.
[12:42:45] <seb_kuzminsky> yes
[12:42:53] <mhaberler> if you find such a commit - please add it to the tracker here so it is not forgotten:
https://github.com/zultron/linuxcnc/issues?state=open
[12:43:01] <zultron> I thought you meant the merge conflict log message.
[12:43:25] <seb_kuzminsky> ah, no, log messages are much less important
[12:43:26] <zultron> Ok, so let's be sure to remove anything like that.
[12:43:35] <cradek> ok, yes there are quite a few of them, I used git log -S'<<<<<' master..unified-build-candidate-0
[12:44:00] <seb_kuzminsky> removing it means rewriting history, which means rebasing, and i think you'll find, because of how the branch has been developed, that the rebase will be very difficult
[12:44:27] <seb_kuzminsky> keeping the feature branch clean is really an ongoing process during development, not a cosmetic finishing touch at the end
[12:44:28] <zultron> I know I've done that kind of thing before unintentionally, but wouldn't intentionally leave it behind.
[12:44:42] <mhaberler> great, filed:
https://github.com/zultron/linuxcnc/issues/40
[12:44:45] <jmk-mcfaul_> does it mean one big rebase, or a bunch of little ones?
[12:45:00] <zultron> Sure. I'm happy to deal with that issue, and the author renames.
[12:45:18] <seb_kuzminsky> jmk-mcfaul_: the first rebase will be big and difficult, after that additional ones will be small and easy
[12:45:21] <mhaberler> (btw the github tracker is years ahead of the sourceforge one, worth a try just for that)
[12:45:28] <seb_kuzminsky> wow zultron, thanks a ton!!
[12:45:51] <seb_kuzminsky> i'll be happy to help in any way i can, unfortunately the actual work of rebasing is not really parallelizable
[12:46:08] <seb_kuzminsky> moral support, tech support, air-drops of coffee... let me know what i can do
[12:46:25] <zultron> I thought of both of those as small issues compared to what I thought you were asking for:
[12:46:30] <jmk-mcfaul_> seb_kuzminsky, my git knowledge is pathetic, but I was thinking that the introduction of merge markers and their removal wouldn;t be that far apart, and that each set could be handled by a rebase that spans only a few commits
[12:47:09] <zultron> rewriting history into chunks where each of the dozen or so major features needs to be incrementally appliable and buildable for review.
[12:47:16] <mhaberler> I do not commit to a rebase being possible and I note there was no such codified rule, which is why it is questionable to demand that at this stage - merge forward has been the documented rule, and that was that
[12:47:25] <seb_kuzminsky> jmk-mcfaul_: in git, each commit contains a pointer to its parent, so when you rebase you have to rebase from some point all the way to the head of the branch
[12:47:57] <seb_kuzminsky> zultron: that would be ideal, and i think after you do the first rebase the rest will be easy in comparison
[12:48:49] <zultron> I don't think so at all, because the history is very long and complicated.
[12:48:55] <seb_kuzminsky> mhaberler: there's no written rule, that's true, but what you're asking for (merge these 1200 commits that add 12 new features and sometimes dont build) is very far from the normal way to collaborate
[12:49:40] <mhaberler> sure. I just do not like to be measured against rules which are not codified, and I am sure you understand this because you would not either.
[12:50:21] <jmk-mcfaul_> who said anybody was being measured against anything?
[12:50:37] <mhaberler> rebase vs merge forward, see above
[12:50:54] <seb_kuzminsky> zultron: if you do the rebase to rename emcweb and fix the authors and squash out the merge conflict markers in the source code, you'll have done by far the most difficult part of the work, i believe
[12:51:04] <zultron> Feature X is added, there's a merge with upstream master, Feature Y is added & Feature X undergoes lots of changes to accommodate it, then do that again with many more features.
[12:51:46] <mhaberler> as for the 'far from normal' I do note that this work has raised the core devs attention only recently, and that is clearly one reason (among many others) why it is a long series of commits
[12:51:49] <zultron> If Feature X is reviewed at that point, it's not really separated in its final state, as I read you want from above.
[12:52:02] <seb_kuzminsky> if X is merged into master already, then the branch that adds Y should do the changes to X down at the bottom (at the point where it branches from master)
[12:52:28] <seb_kuzminsky> if X is not merged into master, then the changes to X demanded by Y should be squashed into the commits that add X
[12:52:30] <zultron> Yes, but that can be very difficult because everything is so intertwined.
[12:52:48] <zultron> Our changes are mostly in rtapi.
[12:52:48] <seb_kuzminsky> so that the X that gets reviewed is the final X you want in master, not some intermediate one
[12:53:14] <seb_kuzminsky> yes it's difficult now because everything is interwined, i totally get that
[12:53:41] <cradek> is it true that there are some things that aren't intertwined at all? like pru, emcweb? can those commits be grouped?
[12:53:47] <zultron> Yeah, that really won't work. To request that makes me think that everything we've done is essentially one big feature, and X and Y are sub-features.
[12:54:17] <jmk-mcfaul_> what exactly are the features (for someone like me who hasn't been observing)
[12:54:18] <zultron> Michael will have to step in to answer that.
[12:54:24] <jmk-mcfaul_> unified build is a big one
[12:54:32] <seb_kuzminsky> cradek: it does seem like some things are separate from the rtos support and the unified build
[12:54:38] <jmk-mcfaul_> emcweb seems completely independent of that (for example)
[12:54:52] <seb_kuzminsky> jmk-mcfaul_: i think that's true, but michael is probably the guy to answer
[12:55:05] <cradek> it's tempting to list a few big features, and squash the hell out of the 1200 commits and make just a few, one per big interdependent feature
[12:55:21] <mhaberler> I have laid it out on the dev list, I received no tangible feedback, I went ahead.
[12:55:23] <cradek> then at least we have working bisect
[12:55:44] <seb_kuzminsky> it would have been simpler to review the rtos changes is the emcweb code (for example) had been merged into some other integration branch
[12:56:02] <mhaberler> gentlemen, Iwe have a circle here. I have said clearly I have prioritized - on your request btw - a buildable branch over cleaned history, and now I understand it is all so diffcult to build because the cleaned history is not in place. I have never said I will not do it, but I cannot take on arbitrary ex-post rules, and I can do only one thing at a time.
[12:56:53] <mhaberler> which is the reason why I requested as above. Once we have that ticked, next item, cosmetics.
[12:57:08] <seb_kuzminsky> that's not true michael, you and i talked months ago and you agreed twice to making the rtos branch history clean and reviewable
[12:58:01] <seb_kuzminsky> i gotta go, but i want to continue this conversation
[12:58:13] <mhaberler> the merge candidate pressure was _not mine_, Seb. As for cleaning, I spelled out the priorities.
[12:58:23] <seb_kuzminsky> i want some of the awesome features you guys ahve worked so hard to develop
[12:58:30] <seb_kuzminsky> and i'm willing to work to make it happen
[12:58:35] <zultron> jmk-mcfaul_, check this doc:
http://static.mah.priv.at/public/UnifiedBuild.html
[12:58:47] <mhaberler> so it is not fair to say 'I deny that'. I do request you help _at this stage_.
[12:59:07] <jmk-mcfaul_> zultron, wow
[12:59:29] <jmk-mcfaul_> tl;dr at this point - keep in mind that I am not an active dev and have not been for several years
[12:59:43] <jmk-mcfaul_> I do think unified build is very important
[13:00:11] <jmk-mcfaul_> and I somewhat understand what mhaberler mentioned earlier - he made proposals and got little feedback
[13:00:38] <CaptHindsight> How about if someone else is available to perform the cleanup and refactors it all for an understandable merge?
[13:01:15] <seb_kuzminsky> i'm going offline for several hours
[13:01:32] <seb_kuzminsky> i'm not angry or anything, and i welcome continued collaboration on this difficult issue
[13:01:41] <seb_kuzminsky> bye for now, friends!
[13:01:47] <jmk-mcfaul_> bye seb
[13:02:17] <mhaberler> cu
[13:02:20] <jmk-mcfaul_> mhaberler, zultron: long ago when I first proposed hal, I wrote a long email explaining what I thought was this cool idea
[13:02:26] <jmk-mcfaul_> the silence was deafening
[13:03:18] <zultron> Sorry, phone call
[13:03:26] <jmk-mcfaul_> I think that is inevitable - few people are deeply involved in the details of anything, and almost by definition, nobody is going to be as excited by or interested in your new feature as you are
[13:03:40] <zultron> Well it's lucky you weren't discouraged by the deafening silence.
[13:03:42] <mhaberler> that is why I went ahead
[13:04:16] <jmk-mcfaul_> I was discouraged, somebody (I don't recall who, maybe cradek?) said something to the effect of "built it and they will come"
[13:04:21] <jmk-mcfaul_> much like you guys did
[13:04:34] <mhaberler> but then there can be no surprise this comes out a bit different than the average fix
[13:04:45] <jmk-mcfaul_> I don't remember how much pain, if any, was involved in merging it
[13:05:09] <zultron> Wasn't there someone in particular who was very opposed to it?
[13:05:10] <jmk-mcfaul_> less than this time around I think, probably because rtapi and hal were self contained, and not mixed in with any other features
[13:05:30] <jmk-mcfaul_> yes, one person
[13:06:01] <zultron> Anyway, at that point you weren't a newcomer, I assume.
[13:06:04] <jmk-mcfaul_> when hal was first proposed, it was indeed just a hardware abstraction layer. no components, just driver management
[13:06:04] <cradek> but nobody is opposed to these changes, just overwhelmed by the complexity
[13:06:10] <jmk-mcfaul_> actually, I was
[13:06:52] <mhaberler> cradek: me to, and I had no idea at the beginning what it would turn into - eg the ub idea bit us when, February? March?
[13:06:59] <zultron> I'm sorry cradek, I didn't mean to imply that we're facing the same thing in any way, other than that there were discouraging social elements.
[13:07:06] <jmk-mcfaul_> prior to rtapi and hal, all I had done was a couple of those ancient code structure drawings, trying to understand things
[13:07:07] <mhaberler> that was a serious structural turn
[13:08:02] <mhaberler> cradek: I have an idea: you build it, and we give you a walkthrough what actually happens - seriously
[13:08:39] <jmk-mcfaul_> cradek, do you remember how we actually merged hal and rtapi? I have a hunch we didn't really "merge" it at all. We started this new thing called emc2 ;-/
[13:08:45] <mhaberler> I think such an IRC log would actually be helpful to edit later into a document
[13:08:45] <cradek> actually I just built it successfully, and am puzzling over whether I need anything setuid and why
[13:09:08] <zultron> jmk-mcfaul_, you all started a new CVS/SVN repo for emc2. :)
[13:09:08] <cradek> I am hoping to run the equivalent of just simulator, how do I do that?
[13:09:26] <mhaberler> export FLAVOR=posix
[13:09:30] <mhaberler> realtime start
[13:09:36] <cradek> jmk-mcfaul_: yeah and that's exactly what we don't want in this case...
[13:09:46] <mhaberler> halcmd -f -k
[13:09:49] <mhaberler> or just do
[13:09:58] <mhaberler> FLAVOR=posix linuxcnc
[13:10:16] <mhaberler> you might have to do a make setuid
[13:10:40] <cradek> I did not, and sim/axis/axis does start for me
[13:10:43] <zultron> Right. Or if you want a simulator-only build, try "./configure --with-posix && make"; that will build only posix threads.
[13:11:04] <cradek> aha that's what I was looking for
[13:11:10] <jmk-mcfaul_> cradek, so, in my case, when I made some wholesale changes that really were impossible to merge incrementally, we "solved" the problem (more like ignored it) by making a new repositiory
[13:11:11] <cradek> I only checked --enable-* but not --with-*
[13:11:30] <jmk-mcfaul_> it seems like mhaberler and zultron are being given a much higher hurdle to leap
[13:11:35] <zultron> Ok, I really do need to run. Thanks for the discussion. I feel progress.
[13:11:43] <cradek> zultron: thanks to you too
[13:11:44] <mhaberler> please set up logging as in the document, this is important
[13:11:56] <mhaberler> zultron: have phun, and greetings to your wife!
[13:12:16] <cradek> yeah, congrats on N years
[13:12:16] <jmk-mcfaul_> zultron, enjoy!
[13:12:40] <cradek> mhaberler: for my sim, I'd like to get all my logging to stderr instead of syslog. can I?
[13:12:59] <mhaberler> yes you can, that is an example in the document, let me see:
[13:13:33] <cradek> oh I see it now
[13:13:58] <cradek> er, it says "as well" - can I get only?
[13:13:59] <mhaberler> for instance: DEBUG=5 MSGD_OPTS="--stderr" realtime start # will get you a detailed session log on stderr (only that session, including RT and user logs)
[13:14:50] <mhaberler> the --stderr flag enables LOG_STDERR on syslog, so logs still got to syslog too
[13:16:21] <cradek> ok, I'm seeing the rtapi debug stuff now
[13:16:55] <cradek> "task issue" debug level works (that's the one I often use)
[13:18:41] <cradek> what are the new columns in halcmd show pin?
[13:19:11] <mhaberler> (sorry, spillover from development code, an ifdef left in)
[13:19:18] <cradek> oh ok
[13:19:45] <jmk-mcfaul_> that pesky cosmetic stuff :-)
[13:20:00] <mhaberler> what they are are properties which come into play when automatically reporting changes from hal: a float epsilon value, and an attribute mask
[13:21:05] <mhaberler> I understand you concern this being quite complex; I still think a walkthrough is a good idea. I will start a section on that in the document, and maybe interested folks can join in on announced IRC session.
[13:22:22] <mhaberler> note the current logging gives you something which we did not have: precise temporal ordering of log entries regardless where they come from (RT, which thread, userland, whatever) - this will help the people chasing race conditions
[13:23:06] <mhaberler> because klog and stderr had no exact mutual temporal ordering
[13:24:56] <cradek> I see there's little going to syslog by default - that's good
[13:25:24] <mhaberler> crank up DEBUG and there will lots (5 max)
[13:25:39] <cradek> yeah I saw that - just checking the default now
[13:26:01] <cradek> (syslog writes are synchronous so it's very painful on some systems if you flood syslog)
[13:27:07] <mhaberler> btw I really appreciate you are exploring this
[13:27:54] <cradek> would probably be more useful if I tried it on hardware
[13:28:39] <mhaberler> is this a VM?
[13:28:58] <cradek> no, a real laptop, but no hardware hooked to it
[13:29:06] <mhaberler> ah
[13:29:27] <cradek> heh "hardware" is pretty ambiguous in this situation
[13:30:02] <cradek> I meant get some steps out a parport, or read some encoders with hm2, etc
[13:30:31] <cradek> do you use linuxcnc on any real hardware?
[13:30:48] <cradek> I remember jmk didn't for many years, kinda funny.
[13:31:03] <mhaberler> yes, a 5i20 config driving a lathe and a mill, but not used much recently
[13:31:20] <cradek> aha
[13:31:33] <mhaberler> I guess I need to do the 'eat your own dogfood' stunt soon for cred ;)
[13:31:57] <cradek> yeah never hurts
[13:32:21] <jmk-mcfaul_> I never used emc1 on hardware
[13:33:00] <cradek> I used emc1 on hardware for a while to avoid the complexity of hal :-)
[13:33:04] <jmk-mcfaul_> I built a test jig containing a xylotex drive, 3 steppers, and a jogwhee, hooked to parport, for the initial testing of hal
[13:33:37] <jmk-mcfaul_> I didn't have an actual machine running emc2 until 2007 (I got involved in 2003, hal was semi-functional by 2004)
[13:34:39] <cradek> I have to run, too
[13:34:41] <cradek> thanks all
[13:34:51] <mhaberler> cu!
[14:12:34] <jthornton> seb_kuzminsky, even if the German and Polish pdf docs are used somehow when you set your language to German or Polish they are still built from the English docs so the de and pl files are only there to make submakefile happy.
[23:01:14] <KGB-linuxcnc> 03seb 05master 933f465 06linuxcnc 10docs/src/hal/rtcomps.txt * docs: fix some typos in rtcomps.txt
[23:01:14] <KGB-linuxcnc> 03seb 05master 7fcda0f 06linuxcnc 10debian/control.in * make all docs packages Provide linuxcnc-doc
[23:01:16] <KGB-linuxcnc> 03seb 05master 50d382a 06linuxcnc 10docs/src/Submakefile * docs: split out doc source files by language
[23:01:23] <KGB-linuxcnc> 03seb 05master d05dbea 06linuxcnc 10docs/src/Submakefile * docs: split out pdf targets by language
[23:01:29] <KGB-linuxcnc> 03seb 05master 3eb2112 06linuxcnc 10debian/ 10configure 10control.in 04linuxcnc-doc-de.files.in * deb: dont build german docs package
[23:01:36] <KGB-linuxcnc> 03seb 05master 868d1ab 06linuxcnc 10docs/ 10(92 files in 13 dirs) * docs: remove german docs
[23:45:10] <linuxcnc-build> build #423 of precise-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/423 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[23:48:33] <linuxcnc-build> build #1220 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1220 blamelist: Sebastian Kuzminsky <seb@highlab.com>