#emc-devel | Logs for 2010-02-11

Back
[03:57:18] <cradek> I'm not sure either
[03:57:20] <cradek> oops
[06:13:21] <ries_> ries_ is now known as ries
[15:58:42] <cradek> g'morning seb
[15:59:52] <seb_kuzminsky> hi! i'm making headway in the garage! it's a long way to go still, but it's moving in the right direction :-)
[15:59:58] <seb_kuzminsky> can't wait to get that machine home :-)
[16:00:16] <cradek> yay! and I'm making progress buying replacements for the things you're taking :-)
[16:00:24] <seb_kuzminsky> every morning on my way to work i glance at that logo we milled on it and i smile, i feel like a little schoolboy in love
[16:00:32] <cradek> haha
[16:00:56] <cradek> it's a simple love... a little one-sided
[16:01:08] <seb_kuzminsky> like most of my school-boy loves then ;-)
[16:02:08] <seb_kuzminsky> jepler: did you see my email about tagging our tree? are you still opposed to it?
[16:02:13] <cradek> I'm getting stuff packed up - the tooling is in a big bucket and a big box
[16:02:29] <cradek> apparently you're getting about 5 gallons of tooling...
[16:02:29] <seb_kuzminsky> yum...
[16:02:43] <jepler> seb_kuzminsky: I blew it off, sorry
[16:03:04] <seb_kuzminsky> i havent decided yet whether i'll do the moving (with my bro & his big truck&trailer) or whether i'll hire a real rigger
[16:03:12] <seb_kuzminsky> jepler: no problem, it's not really urgent
[16:03:26] <seb_kuzminsky> it's just a small change that would make the buildbot debs a little prettier
[16:03:48] <jepler> hm and it looks like I failed a reading test in kim's message
[16:04:22] <seb_kuzminsky> off by 2
[16:04:32] <cradek> seb_kuzminsky: yeah it's hard to decide. depends on your trailer more than anything I think
[16:04:54] <jepler> seb_kuzminsky: you say it was an e-mail where you asked me to put tags? I can't find it..
[16:05:12] <cradek> I felt like I needed more truck hauling my lathe, and that was downhill and lighter than the bridgeport - you would have it worse
[16:06:02] <cradek> I was using a full size pickup but it was just a v6. I should have used our other truck but it wasn't feeling up to it at the moment.
[16:06:12] <seb_kuzminsky> cradek: his trailer is rated for 10k lbs, it's got brakes and a wood floor, and he says his truck's big enough for it
[16:06:48] <cradek> that sounds pretty easy then... 10k is a very big trailer.
[16:06:53] <seb_kuzminsky> jepler: it was (somewhat misguidedly) in reply to your "v2.4_branch created" email to emc-devel
[16:06:55] <seb_kuzminsky> brb
[16:08:34] <jepler> ah there it is
[16:37:01] <seb_kuzminsky> currently we're not really using tags, but i think that's "the way" to get git revnos to be legible to humans
[16:40:18] <jt-plasma> can you use the 7i48 with hostmot2 on a 5i20?
[16:41:38] <seb_kuzminsky> jt-plasma: no, it uses muxed encoders to the fpga, which is not supported in the hostmot2 driver yet
[16:42:25] <cradek> looks like you could use the dac part
[16:42:32] <jt-plasma> ok thanks
[16:43:47] <jepler> it looks like the PWM inputs are not on the same pins as they are on the other servo cards
[16:43:51] <jepler> er, PWM outputs
[16:44:02] <cradek> oh dang, don't listen to me
[16:44:20] <seb_kuzminsky> jt-plasma: yeah, so you'd have to email jeff and ask him to make a firmware with custom pinouts ;-)
[16:45:07] <micges> hi all
[16:47:20] <cradek> hi
[16:47:59] <micges> I have question: if I have driver +-10V connected to my dac boards (simmilar to mesanet) and it seems that servo stops when voltage is +0.1V. how can (could) I set offset for dac value?
[16:48:43] <micges> in our machines servo has that parameter, but what if other driver will not have this ?
[16:48:59] <cradek> usually there's a knob to adjust on the servo amp
[16:49:11] <cradek> also check your ground wiring carefully - 0.1v seems like a lot of offset
[16:50:22] <micges> I don't know exact values, I just wanted to know idea
[16:50:29] <jepler> I can build SV12IM_2X7I48_72 for 5i20
[16:51:25] <micges> cradek: thanks
[16:51:50] <jt-plasma> jepler: would that work with 2 7i37's and the 7i48?
[16:55:08] <jepler> jt-plasma: I think so (but remember, the quadrature counters won't work without hostmot2 driver work)
[16:56:10] <jt-plasma> ok, that would not be an advantage then, I was thinking of someone with 5 axis would only need one 7i48 and have two 7i37's for I/O
[17:07:26] <jepler> anyhow, I went ahead and built that firmware: http://emergent.unpy.net/files/sandbox/sv12im_2x7i48_72.bit http://emergent.unpy.net/files/sandbox/sv12im_2x7i48_72.pin
[17:14:24] <jt-plasma> dang that is fast as fast can be...
[17:16:20] <jepler> it's not a difficult process once the setup is done. and it's not like I tested that it works or anything like that
[17:30:06] <jt-plasma> now we just need Seb to doctor up hostmot2 :)
[17:30:25] <jt-plasma> * jt-plasma heads back to the other shop
[17:30:30] <jt-plasma> jepler: thanks
[17:34:35] <jepler> * jepler tries to decide about idromv3-for-2.3
[17:34:40] <jepler> to push or not to push...
[17:53:43] <CIA-81> EMC: 03jepler 07v2_3_branch * rfa31aa7ab048 10/src/hal/drivers/mesa-hostmot2/hostmot2.c: dont be so princess-y about the locations of things
[17:53:44] <CIA-81> EMC: 03jepler 07v2_3_branch * rd192ad936302 10/src/hal/drivers/mesa-hostmot2/hostmot2.c: accept IDROM Type 2 and Type 3
[17:53:44] <CIA-81> EMC: 03jepler 07v2_3_branch * r133b51da34e4 10/debian/changelog: note new feature
[18:02:13] <pcw_home> The 7I48 can be supported by the existing driver (If the IDROM lies about the hardware)
[18:02:15] <pcw_home> but I've wanted to avoid that, as the muxed encoder counter has different timing contraints
[19:33:34] <jepler> based on pcw saying that the registers are compatible between regular and muxed encoder, I've whipped this together: http://emergent.unpy.net/files/sandbox/0001-untested-support-for-muxed-encoders.patch
[19:33:54] <jepler> it'll load that sv12im_2x7148_72 bitfile and shows plausible things in dmesg and halcmd, but I can't test beyond that
[19:34:47] <jepler> seb_kuzminsky: so you think I should tag v2.5.0-pre at 68a3312b5a4418a4b14258fcfe8c4a34a45d2144 and v2.4.0-pre at 9e8f7c44f0c52850528b3f78da1dab501657674f ?
[19:35:17] <jepler> (git rejects ~ in tags, so I can't tag with ~pre; but we want the ~ in VERSION or at least debian/changelog so that the package name sorts before v2.5.0)
[20:14:55] <seb_kuzminsky> jepler: that sounds pretty good, and i'll switch out the first "-" for a "~" when i make the version number
[20:16:40] <seb_kuzminsky> it might be good to add a human-controlled number to the pre, ie tag it "2.5.0-pre0" instead of "2.5.0-pre". This way we can have somewhat controlled pre-releases as we go, might be nice (or it might be useless, i'm not sure)
[20:17:06] <seb_kuzminsky> oh, and the tag should ideally not have the leading "v". It should be as close as possible to the string we want as the version number
[20:18:37] <jepler> $ dpkg --compare-versions 2.5.0~pre eq 2.5.0~pre0 && echo true
[20:18:37] <jepler> true
[20:18:39] <jepler> that's weird
[20:18:54] <jepler> $ dpkg --compare-versions 2.5.0~pre lt 2.5.0~pre1 && echo true
[20:18:54] <jepler> true
[20:19:22] <seb_kuzminsky> weird
[20:19:34] <jepler> anyway, I think we can go up to ~pre1 later if we want
[20:20:23] <seb_kuzminsky> how about this: tag 8dc56... as "2.4.0-pre0", tag 68a33... as "2.5.0-pre0", and tag d0cc2... as "2.5.0-pre1"
[20:21:11] <seb_kuzminsky> once those tags as in i'll fix the debian/update-dch-frmo-git script to use this new convention
[20:21:44] <seb_kuzminsky> will you be using annotated tags or lightweight?
[20:22:18] <jepler> git tag -s (signed annotated)
[20:22:26] <jepler> that way you don't have to specify --tags to git describe
[20:22:30] <seb_kuzminsky> fancy
[20:22:35] <jepler> extremely
[20:23:40] <jepler> so you think I should put pre0 and pre1 in the git tag even if it's not in VERSION?
[20:23:47] <jepler> and why do you want two 2.5.0-pre* tags?
[20:25:11] <seb_kuzminsky> currently we have over 900 commits since the previous tag, and the "git log | dch" part of building the deb takes almost 10 minutes to run
[20:25:25] <seb_kuzminsky> by having multiple -pre's, we can keep that time down to something reasonable
[20:25:54] <jepler> I see
[20:26:17] <seb_kuzminsky> if it's too much hassle to make those -pre tags i can totally live withotu it
[20:26:25] <jepler> the asymmetry bothers me
[20:26:38] <seb_kuzminsky> what asymmetry?
[20:26:45] <seb_kuzminsky> oh between that and the VERSION
[20:26:49] <jepler> not that'v
[20:27:03] <seb_kuzminsky> you can put the v in and i'll strip it off
[20:27:05] <jepler> the tag v2.4.0-pre0 will be miles away from where v2.4.0 development started, but v2.5.0 will be right there
[20:27:31] <seb_kuzminsky> you could tag v2.4.0-pre0 as where trunk/master opened again after the 2.3 freeze
[20:28:00] <seb_kuzminsky> then make v2.4.0-pre1 where the v2.4_branch was made
[20:46:50] <jepler> OK, how about this? http://pastebin.com/m3e5416ad
[20:49:53] <seb_kuzminsky> that looks good, let me do a few more tests here
[20:50:11] <jepler> also we can make update-dch-from-git nice and fast
[20:53:26] <jepler> http://pastebin.com/m2d3af6b5
[20:54:56] <jepler> emc2 (1:1:1:1:1:1:2.5.0~pre) hardy; urgency=low
[20:54:59] <jepler> hm that's not quite right
[20:55:04] <cradek> ha
[20:55:26] <seb_kuzminsky> why are we using epochs in the version number at all?
[20:57:11] <jepler> we made a mistake in versioning once
[20:57:25] <jepler> $ grep '^emc2' debian/changelog
[20:58:44] <cradek> fortunately all my mistakes have been made in the past
[20:59:45] <jepler> er, I meant to have - in all those tags, not _
[20:59:52] <seb_kuzminsky> either one's fine by me
[21:00:00] <seb_kuzminsky> as long as it's not a v, ., or number ;-)
[21:02:11] <jepler> $ debian/update-dch-from-git ; head -1 debian/changelog
[21:02:12] <jepler> emc2 (1:2.5.0~pre0-52-g79c83be) hardy; urgency=low
[21:09:12] <seb_kuzminsky> i think the v2.5.0_pre1 tag in that pastebin is wrong, it should be v2.4.0_pre1
[21:09:58] <jepler> argh I'll never get it right at this rate
[21:09:59] <seb_kuzminsky> oh duh it is
[21:10:06] <seb_kuzminsky> no it's me that'll never get it
[21:10:09] <seb_kuzminsky> you did it right
[21:16:28] <jepler> is that version number a good one? It comes from stripping the leading "v" and turning -pre into ~pre
[21:16:52] <jepler> it seems to me that any ~pre will come before 2.5.0 in debian version numbering
[21:18:24] <seb_kuzminsky> agreed, the ~ character sorts last: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
[21:18:51] <jepler> I'm not sure what we will do if we want "alpha" or "beta", since ~alpha is older than ~pre
[21:18:52] <seb_kuzminsky> er, i meant "sorts first", ie, is a lesser version than anything else
[21:19:07] <seb_kuzminsky> let's just call then ~preX
[21:19:27] <cradek> ~~pre
[21:21:54] <jepler> hmmmm
[21:21:54] <jepler> $ dpkg --compare-versions v2.5.0~pre+cvs-import-833-g3378b86 gt v2.5.0~pre1 && echo true
[21:21:57] <jepler> true
[21:22:03] <seb_kuzminsky> yes that sucks
[21:22:27] <seb_kuzminsky> i'm planning to manually remove all *cvs-import* debs, and ask people to remove them by hand from their machines
[21:23:09] <jepler> hm
[21:24:07] <jepler> or we could use something else to make the new pre packages sort newer, ~.pre or ~+pre
[21:25:23] <jepler> bbiab
[21:29:51] <seb_kuzminsky> soemthing like ~+pre would make it seamless, but at the cost of adding some cruft
[21:30:35] <seb_kuzminsky> my preference would be to keep the version numbers as simple as we can, and if that means manual action for the folks running the buildbot debs, i'm ok with that
[21:34:49] <seb_kuzminsky> four distinct IPs have downloaded debs from the buildbot
[21:34:52] <seb_kuzminsky> two of them are me
[21:35:37] <seb_kuzminsky> the other two are 64.38.154.147 and 75.100.33.29
[21:38:42] <seb_kuzminsky> the 64. one is registered to isomedia, an isp in washington state
[21:38:47] <seb_kuzminsky> the 75. one is registered to tds.net, an isp in Wisconsin
[21:41:19] <seb_kuzminsky> so, meh, looks like only two people care about buildbot debs and we should probably not add cruft to keep those two people happy
[21:50:20] <jepler> OK
[21:50:47] <jepler> you want to test this new update-dch-from-git or should I just commit & push it?
[21:51:34] <jepler> .. I just pushed the tags
[21:59:18] <seb_kuzminsky> logger_dev: bookmark
[21:59:18] <seb_kuzminsky> Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-02-11.txt
[21:59:32] <jepler> and I went ahead with update-dch-from-git as well
[21:59:36] <CIA-81> EMC: 03jepler 07master * rdb9020a8af04 10/debian/update-dch-from-git: Merge branch 'improved-git-dch'
[21:59:37] <CIA-81> EMC: 03jepler 07v2.4_branch * rd83451d6d0b4 10/debian/update-dch-from-git: Merge branch 'improved-git-dch' into v2.4_branch
[21:59:41] <seb_kuzminsky> ah, ok
[21:59:42] <CIA-81> EMC: 03jepler 07master * r1acdfcadd463 10/debian/update-dch-from-git: improve changelog generation from git: faster, better version number
[21:59:54] <seb_kuzminsky> then i will abort my commit ;-)
[22:00:18] <jepler> oops, did I step on your toes?
[22:00:27] <seb_kuzminsky> nah its fine
[22:00:50] <seb_kuzminsky> your dch updater is way better than mine anyway
[22:01:26] <jepler> it's fast anyway
[22:07:31] <seb_kuzminsky> ooh, i didnt know the "bash is sed" syntax you used to change -pre to ~pre, nice
[22:08:30] <seb_kuzminsky> "git describe --abbrev=0" gives you just the tag, without having to sedify the raw describe output
[22:18:26] <seb_kuzminsky> bummer, i guess the git on my hardy vms is too old
[22:18:28] <seb_kuzminsky> brb
[22:23:15] <jepler> oops, what did I write that didn't work there?
[22:34:03] <seb_kuzminsky> installing git from the hardy ppa, will rebuild those in a few moments
[22:41:48] <jepler> seb_kuzminsky: what did I write that didn't work? incidentally, I have 1.6.6.1 from the git ppa..
[22:44:17] <seb_kuzminsky> the hardy git doesnt understand --match
[22:45:07] <jepler> oh
[22:45:14] <jepler> that's unfortunate
[22:45:32] <seb_kuzminsky> yeah, match is made of win
[22:46:28] <seb_kuzminsky> i installed 1.6.6.1 from the ppa on the buildslaves that care
[23:20:01] <seb_kuzminsky> that looks better
[23:22:23] <jepler> is there no log to view from master-checkin?
[23:25:15] <jepler> bbl
[23:39:11] <seb_kuzminsky> jepler: right, master-checkin only triggers other builders, so it has no log
[23:39:38] <seb_kuzminsky> and it's not just master, it's master or v2.4_branch
[23:41:59] <seb_kuzminsky> brb