Back
[00:41:08] <jmkasunich> you sent in the money?
[00:43:23] <cradek> yep
[00:43:30] <cradek> well paypal actually
[00:44:00] <cradek> looks like you need to remove the depends in those trees you moved
[00:44:16] <jmkasunich> dang
[00:44:57] <jepler> cradek: do you think we need to have a toggle for "Show extents"?
[00:45:22] <jmkasunich> thats actually rather strange - shouldn't a make clean remove the depends?
[00:46:00] <cradek> jepler: it's nice to have one for everything
[00:46:06] <cradek> jmkasunich: I thought it did
[00:46:27] <jepler> is the hack to not load the depends when doing "make clean" not working?
[00:46:39] <jmkasunich> I dunno whats not working
[00:47:24] <jmkasunich> I changed the "emc2testing" farm checkouts to the v2_0_branch, and when they rebuilt, they failed on 3 of 5 systems
[00:47:37] <cradek> jepler: -include $(RTDEPS) isn't wrapped the same way
[00:47:43] <jepler> cradek: aha
[00:50:01] <cradek> jmkasunich: don't do anything, let me try to fix it
[00:50:05] <jmkasunich> ok
[00:50:16] <jmkasunich> I'm trying to figure out why the failure messages didn't go to the commit list
[00:50:26] <cradek> I saw some of them
[00:50:35] <jmkasunich> on IRC yes, but on the mailing list?
[00:50:41] <cradek> oh, rtfs, sorry
[00:52:17] <jepler> when we wanted to send to the sf lists from cvs.linuxcnc.org, it wouldn't accept the messages because sf tries to connect to the mail server for the sending domain. Could that be going on here?
[00:52:38] <cradek> yes, but I thought we had that solved
[00:53:06] <jmkasunich> the log seems to indicate that the mail was accepted
[00:53:09] <cradek> no, jmk changed it to use dreamhost
[00:53:15] <cradek> hmm
[00:53:22] <jmkasunich> I tested several days ago sending mail to my users.sourceforge.acct
[00:54:07] <jmkasunich> the dreamhost account isn't subscribed to the list, but that just means the messages should have been held for approval
[00:54:14] <jmkasunich> I just checked, nothing held
[00:57:09] <jmkasunich> <emc-commit@lists.sourceforge.net>: host mail.sourceforge.net[66.35.250.206]
[00:57:09] <jmkasunich> said: 550-Postmaster verification failed while checking
[00:57:09] <jmkasunich> <jmkasunich@linuxcnc.org> 550-Called: 208.97.132.31 550-Sent: RCPT
[00:57:09] <jmkasunich> TO:<postmaster@linuxcnc.org> 550-Response: 550 <postmaster@linuxcnc.org>:
[00:57:09] <jmkasunich> Recipient address rejected: User unknown in virtual alias table 550-Several
[00:57:10] <jmkasunich> RFCs state that you are required to have a postmaster 550-mailbox for each
[00:57:12] <jmkasunich> mail domain. This host does not accept mail 550-from domains whose servers
[00:57:14] <jmkasunich> reject the postmaster address. 550 Sender verify failed (in reply to RCPT
[00:57:16] <jmkasunich> TO command)
[00:57:44] <jmkasunich> grrrrrr
[00:58:21] <cradek> use @cvs.linuxcnc.org, a properly-configured mail server
[00:58:56] <jmkasunich> hard to believe dreamhost isn't
[00:58:59] <cradek> (sometimes it seems like the sf mail guy is a big wanker)
[00:59:14] <jmkasunich> maybe the problem is using the linuxcnc.org alias?
[00:59:44] <jmkasunich> it does seem that way sometimes
[01:00:00] <jmkasunich> but dreamhost isn't a buncha amateurs, I certainly hope they have a postmaster account
[01:02:04] <cradek> #554 <jmkasunich@linuxcnc.org>: Relay access denied
[01:02:14] <cradek> I don't think you can get mail at linuxcnc.org at all
[01:02:17] <jepler> I think that message says that 208.97.132.31 wouldn't accept <postmaster@linuxcnc.org> which would be relaying
[01:02:27] <jmkasunich> I can get it just fine
[01:02:45] <jmkasunich> in fact, since I just subscribed that addy to the commit list, I got the last commit message (yours)
[01:02:45] <jepler> which makes sense -- there's no reason for a dreamhost MX to accept messages for linuxcnc.org.
[01:02:59] <jepler> (or do they, since they host the domain?)
[01:03:32] <jmkasunich> they host the domain, and they give SWP the option of setting up email accounts like foo@linuxcnc.org
[01:03:41] <jmkasunich> (he has a limit of 12000 accounts ;-)
[01:04:01] <cradek> RCPT TO:jmkasunich@linuxcnc.org
[01:04:01] <cradek> 250 Ok
[01:04:01] <cradek> RCPT TO:postmaster@linuxcnc.org
[01:04:01] <cradek> 550 <postmaster@linuxcnc.org>: Recipient address rejected: User unknown in virtual alias table
[01:04:08] <cradek> ok I was on drugs, it works fine
[01:05:08] <jmkasunich> I just sent a message to the users list using the webmail interface as jmkasunich@linuxcnc.org
[01:05:20] <jmkasunich> it was accepted, and I got a response "your message awaits moderation"
[01:05:40] <cradek> yeah, it's fine, maybe swp can set up a postmaster alias
[01:06:25] <jmkasunich> but why did they accept that one from jmkasunich@linuxcnc.org and not accept the one generated by the farm, which came from the exact same address, and was relayed from the farm thru the exact same server?
[01:09:12] <cradek> I sure don't know
[01:10:14] <SWPadnos> hi guys
[01:10:20] <SWPadnos> should I add a postmaster account?
[01:10:21] <cradek> hi
[01:10:24] <jmkasunich> hi
[01:10:31] <cradek> can you just make a mail alias instead?
[01:10:36] <SWPadnos> yup
[01:10:46] <SWPadnos> there should already be one - I'll look at it
[01:11:07] <cradek> there isn't...
[01:11:14] <jmkasunich> something is fishy beyond the postmaster thing
[01:12:06] <jmkasunich> why would SF accept a msg from jmkasunich@linuxcnc.org sent using the dreamhost webmail interface, but not one from me sent by using esmtp to send it do the dreamhost server for forwarding (relaying)?
[01:12:27] <cradek> because the former is not relaying
[01:13:12] <jmkasunich> and SF figured out that it was relayed, and applied a more stringent postmaster test because of that?
[01:13:50] <cradek> coming from their webmail interface, it may have had an envelope-from @dreamhost
[01:14:37] <jmkasunich> I can see the headers on the one they accepted (its at the moderation screen)
[01:14:45] <jmkasunich> there are several received from headers
[01:15:16] <jmkasunich> bottom two use linuxcnc.org
[01:15:18] <cradek> you typically can't see the envelope-from in the headers
[01:15:32] <jmkasunich> above that are ones that mentiondreamhost
[01:17:05] <cradek> we must be getting branch builds now, since it's takinga while
[01:17:42] <jmkasunich> slot 2 is uploading branch result now
[01:17:52] <jmkasunich> 3 & 5 are building branch
[01:17:58] <jmkasunich> 4 is building head
[01:18:36] <cradek> we got the first success, so I guess I fixed it
[01:18:46] <jmkasunich> yeah
[01:19:46] <jmkasunich> i dunno about these irc messages
[01:19:57] <jmkasunich> think maybe they're a little too much?
[01:20:02] <cradek> sure are a lot of them
[01:20:21] <cradek> maybe the url is too much
[01:20:28] <cradek> if they were a simple one line message, it would be better
[01:20:46] <cradek> maybe the url only on failure?
[01:20:51] <jmkasunich> I was thinking that
[01:21:02] <SWPadnos> just point to the compile farm page, unless there's a failure
[01:21:23] <jmkasunich> SWP: any url will make it a two line message
[01:21:39] <SWPadnos> not on my monitor ;)
[01:21:39] <jmkasunich> I can do several things:
[01:21:45] <jmkasunich> 1) no url on pass
[01:21:51] <jmkasunich> 2) no message on pass
[01:22:00] <jepler> you can omit the (kernel version) part
[01:22:10] <jepler> and change it to just 'farm' instead of 'compile-farm'?
[01:22:29] <jepler> but taking out the URL sounds good too
[01:22:31] <jmkasunich> 3) (a little harder but not much) no message unless new result is different than previous result
[01:22:41] <jmkasunich> 4) shorten the message the way jepler suggested
[01:22:54] <jepler> I don't know if my changes make enough of a difference to help
[01:23:01] <SWPadnos> message on fail is best, I think
[01:23:05] <jepler> I'm like swp, my monitor is pretty wide and my letters are small
[01:23:26] <jmkasunich> 2 & 3 reduce the number of messages
[01:23:28] <cradek> my irc is usually 80 columns with quite a few taken up by timestamp and name
[01:23:34] <jmkasunich> 1 & 4 only reduce the length
[01:23:39] <SWPadnos> only 3 of those lines wrapped for me
[01:24:06] <cradek> I say take off everything starting at the ; if it passes
[01:24:13] <SWPadnos> by the way - the logs should be date/time stamped, and you can upload them and bzip or gzip them - they compress down to about 8-10k each
[01:24:25] <SWPadnos> and we can keep them all that way
[01:24:35] <cradek> is there any value in that?
[01:24:36] <jmkasunich> thats a lot of logs
[01:24:51] <cradek> I can't imagine ever wanting to look through them
[01:24:52] <SWPadnos> yes - you can look at differences in the logs
[01:25:14] <cradek> I agree you could
[01:25:23] <SWPadnos> ie, what's different between compiler X and compiler Y
[01:25:54] <SWPadnos> note that when a build fails, the previous successful build log is lost
[01:27:06] <cradek> I also agree that's true
[01:27:24] <jmkasunich> if we decided to do that, the zipped and stamped logs would be in addition to the plaintext "most recent" one
[01:27:27] <cradek> I guess that has never bothered me, since I haven't noticed
[01:28:02] <cradek> man, 8:30 and it feels like bedtime already
[01:28:13] <jmkasunich> you go to bed early
[01:28:31] <cradek> not during the week, which is why I feel like this at the end of the week
[01:28:57] <jmkasunich> I'm an hour ahead of you, yet you always disappear just about when I'm getting warmed up
[01:32:57] <SWPadnos> the postmaster account is set up now, forwarded to me. I'm not sure if it even needs to be deliverable.
[01:33:44] <cradek> I think it just has to say Ok to RCPT TO:
[01:33:50] <SWPadnos> right
[01:35:53] <jmkasunich> I just send another message to emc-users, this time from a farm slot using esmtp
[01:36:05] <jmkasunich> and it went thru (to the moderation page, I didn't let it go to the list)
[01:36:10] <cradek> yay
[01:36:12] <jmkasunich> so I think its fixed
[01:36:51] <SWPadnos> cool
[01:37:29] <SWPadnos> does make look for axis/ under emc2/src, or under emc2 ?
[01:37:35] <jmkasunich> now, the "spamming the channel issue..."
[01:38:33] <jmkasunich> no message on pass would have the biggest effect on reducing spam
[01:38:49] <jmkasunich> but sometimes (just after you committed a fix) you want to _know_ that it passed
[01:38:53] <cradek> I say take off everything starting at the ; if it passes
[01:39:09] <cradek> I kind of like the reassurance
[01:39:21] <SWPadnos> too bad you can't use html markup, and make the word PASSED or FAILED a link to the log
[01:39:32] <jepler> If the previous build failed, it would be nice to see the success
[01:39:42] <jmkasunich> jepler: I was thinking about that
[01:39:49] <jepler> and maybe the success for the "primary" architecture should always be shown
[01:39:53] <jmkasunich> if fail, or if pass and previous failed, send to IRC
[01:40:04] <SWPadnos> so maybe you send the message for all failures, and the furst success after a failure
[01:40:09] <SWPadnos> right
[01:40:58] <cradek> that sounds a little complex
[01:41:27] <jmkasunich> its not to bad, remember there is a history_log file
[01:42:10] <jmkasunich> "tail -n 2 history_log | head -n 1 | grep PASS" will tell me the previous result
[01:42:18] <SWPadnos> you can also have a one-word (or empty, for that matter) "semaphore file"
[01:42:48] <jmkasunich> actually that doesn't work so well
[01:42:55] <jmkasunich> I broke it into independent scripts
[01:43:15] <jmkasunich> the build one appends to the history log (and would write the most recent result to the semaphore)
[01:43:34] <jmkasunich> then afterwards, the results scripts would look and see the new result, not the previous one
[01:44:41] <SWPadnos> script 1: export PREVIOUS_STATE=`cat $STATE_FILE`
[01:44:51] <SWPadnos> rm $STATE_FILE
[01:44:55] <SWPadnos> etc
[01:45:07] <SWPadnos> after message decision, export PREVIOUS_STATE=
[01:45:13] <SWPadnos> (or unset it)
[01:46:35] <jmkasunich> I think I prefer using the existing history file
[01:47:00] <jmkasunich> leave decisions about (and support for) reporting in the reporting script
[01:47:09] <jmkasunich> and let the build script focus on the build
[01:47:11] <SWPadnos> that works, too
[01:47:24] <SWPadnos> do you have "prep" script?
[01:47:29] <SWPadnos> have a ...
[01:47:43] <jmkasunich> I have 6 scripts, plus the top level one
[01:47:56] <jmkasunich> one checks for _any_ commit, using a quick wget
[01:48:12] <jmkasunich> the next one does cvs up on a specific checkout and sees if anything changed
[01:48:16] <jmkasunich> the next one builds
[01:48:20] <jmkasunich> then three do reporting
[01:48:31] <jmkasunich> one updates the webpage, one the commit list, and on cia
[01:49:20] <SWPadnos> how does the "see if anything changed" part work in #2?
[01:49:33] <jmkasunich> top level: echo " <log>build ${RESULT}ED ; see
http://linuxcnc.org/compile_farm/${BUILD_NAME}_slot${SLOT}_log.txt</log>" >>cia.msg
[01:49:43] <jmkasunich> cvs up, scan output for "P" or "U"
[01:50:22] <jmkasunich> oops, bad paste
[01:50:36] <jmkasunich> top level script:
http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/infrastructure/farm-scripts/run_farm?rev=1.6
[01:51:03] <SWPadnos> I was just thinking about checking out the infrastructure stuff so I could - um - check it out ;)
[01:51:34] <jmkasunich> you can browse it with webcvs, easier unless you really want to get into it
[01:51:50] <SWPadnos> I'm a fan of local copies
[01:51:54] <jmkasunich> heh
[01:52:09] <SWPadnos> that way, I can fiddle with it if I like
[01:52:13] <cradek> so if I change a file and a 30 minute build starts, then one minute later, change another file, what happens?
[01:52:17] <jmkasunich> enjoy
[01:52:36] <jmkasunich> another build later
[01:52:40] <jmkasunich> depending on the timing
[01:53:04] <cradek> ok so I get two 30 minute builds, that's fine
[01:53:22] <jmkasunich> since the farm checks for commits every 5 mins, your second commit might get picked up by the first build
[01:53:56] <SWPadnos> it may make sense to check out on the check after a change is detected
[01:54:03] <jmkasunich> I believe its "race proofed" to the extent that you'll never miss a change, but you may get more builds than you want
[01:54:11] <SWPadnos> ie, give it a few minutes to allow more commits to come in
[01:54:13] <cradek> that's exactly what I was asking
[01:54:46] <jmkasunich> SWP: "check out on the check after a change" you lost me ;-)
[01:54:53] <SWPadnos> heh
[01:55:13] <SWPadnos> checking cvs for possible checkouts so the compile farm can check for breakage ;)
[01:55:36] <SWPadnos> what I meant was, wait a few minutes after a CVS change is detected before doing the checkout and compile
[01:55:47] <jmkasunich> thats a tradeoff
[01:55:55] <jmkasunich> I do wait something between 0 and 5 mins
[01:56:04] <SWPadnos> yep - speed of reporting vs. number of builds
[01:56:07] <jmkasunich> I'm trying to deliver results as fast as possible tho
[01:56:18] <jmkasunich> so adding an additional delay seems not so good
[01:56:46] <SWPadnos> well, the technical reason to wait is so that multiple changes in different directories are all in the repository
[01:57:18] <jmkasunich> worst case is if you are unlucky enough to commit a change to one directory just before it checks, then not commit the rest of the changes for a couple mins, so the build starts
[01:57:22] <SWPadnos> for example, a change to an NML message would touch traj/task, interp, and nml
[01:57:31] <jmkasunich> that build might fail
[01:57:35] <SWPadnos> right - you'll get bogus fails
[01:58:19] <cradek> meh
[01:58:33] <jmkasunich> so, how long should I wait?
[01:58:37] <jmkasunich> 1 min?
[01:58:40] <jmkasunich> 5?
[01:59:05] <jmkasunich> if a person does cvs up from the top level dir, everything shows up in cvs pretty quickly
[01:59:23] <cradek> I think you should leave it
[01:59:24] <SWPadnos> it's the checkins that would be the problem
[01:59:44] <cradek> multi-dir checkins happen in a few seconds
[01:59:51] <jmkasunich> I suppose a 30 second wait after check_commit sees something wouldn't delay the results much, and would ensure that I get all dirs
[02:00:31] <SWPadnos> if the developer checks in all changes in one commit, then it's quick (and that's the ideal case, so it's probably fine the way it is)
[02:01:46] <SWPadnos> heh - here's the race condition - do the farm slots check out the infrastructure module before running? ;)
[02:03:34] <SWPadnos> hmmm - I wonder if I should sign up for the Usenix conference
[02:04:34] <jmkasunich> no
[02:04:51] <jmkasunich> updating the farm scripts themselves is done manually by me
[02:05:08] <SWPadnos> ah
[02:07:33] <jmkasunich> it would actually be pretty simple to get the previous result in run_farm, just before invoking the build script
[02:07:57] <SWPadnos> yeah - tail -1 build_log > old_state
[02:08:31] <SWPadnos> you echo success or failure to the log, right?
[02:08:39] <jmkasunich> $OLD_STATE=`tail -1 history_log`
[02:09:09] <jmkasunich> yes, but not neccessarily the very last line
[02:09:14] <jmkasunich> history_log is better
[02:09:31] <SWPadnos> wouldn't you need only the last word, or is it all one-word lines? (in history_log)
[02:09:53] <jmkasunich> http://linuxcnc.org/compile_farm/emc2head_slot2_history.txt
[02:10:30] <SWPadnos> right - so you'd want to cut -3 or something
[02:11:15] <jmkasunich> or store the whole line in $PREV, then later do if `echo $PREV | grep PASSED`
[02:11:20] <jmkasunich> lotta ways to do it
[02:11:23] <SWPadnos> cut -f 3, I think
[02:12:25] <jepler> case $PREV in *PASSED*) ... ;; *) ...; esac
[02:13:39] <jmkasunich> cut -d " " -f 3
[02:13:47] <jmkasunich> default delimiter is tab
[02:14:24] <SWPadnos> right
[02:15:06] <jmkasunich> for now I think I'm not gonna screw with it
[02:15:18] <SWPadnos> that sounds reasonable :)
[02:15:20] <jmkasunich> getting the messages lets me know the farm is still working ;-)
[02:15:30] <SWPadnos> there is that
[02:15:55] <SWPadnos> it also gives a good indication of the coverage a particular compile gets, once more people are set up with farm slots
[02:16:05] <jmkasunich> yes
[02:16:15] <jmkasunich> I'd like to have a BDI-4.recent slot
[02:16:34] <jmkasunich> but I'm not willing to try to set it up on one of the actual slots
[02:16:43] <SWPadnos> 4.30 and / or 4.40 or so would be good
[02:16:52] <SWPadnos> (if 4.40 is out)
[02:17:15] <jmkasunich> it took a laying on of hands by Paul to get 4.20 to install on those things, because they default to a graphical login
[02:17:23] <jmkasunich> doing a non-X install was a pain
[02:17:28] <SWPadnos> I can imagine
[02:18:00] <jmkasunich> for the same reason, I didn't even try to install ubuntu on one of those
[02:18:14] <jmkasunich> I know the server install would work, but I just didn't want to spend the time
[02:18:22] <jmkasunich> I'm using this box for the ubuntu slot
[02:18:30] <jmkasunich> the only problem is when I shut it down
[02:18:37] <SWPadnos> well, if you bring the farm to fest, maybe we can get that done
[02:18:58] <jmkasunich> actually I wasn't planning to bring it this time
[02:19:14] <jmkasunich> its fscking heavy, and a pain to connect/disconnect
[02:19:23] <SWPadnos> that should inprove gas mileage
[02:19:40] <jmkasunich> well, it will be offset by all the other crap I'm bringing
[02:19:57] <SWPadnos> hmm - BDI 4.42 is on cncgear, along with src-1 and src-2 ISOs
[02:20:11] <jmkasunich> that's new
[02:20:44] <SWPadnos> yep. apparently there's still a problem with the text mode installer, but the partitioning / non-bootable hard drive problems of 4.40 are gone
[02:21:59] <jmkasunich> now that RT patched kernels can be distributed as packages independent of the distro, I dunno why Paul doesn't just have people install stock debian and then apt-get <stuff for emc>
[02:22:32] <SWPadnos> you're assuming a net-connected machine, and a fairly fast internet connection
[02:22:34] <jmkasunich> although I guess stock debian's installer isn't very friendly?
[02:23:01] <jmkasunich> I guess there is something to be said for having a working emc on a cd
[02:23:02] <SWPadnos> it's not great, especially for graphical workstation installs
[02:23:16] <SWPadnos> yep - the "one stop shop" is a good thing
[02:23:41] <SWPadnos> I'm not sure if you can even hand out a CD with the emc2 .debs on it, and have it be easy to install
[02:23:59] <jmkasunich> hand out an ubuntu cd and one with the debs
[02:24:08] <SWPadnos> if you right-click on a .deb in ubuntu, does it give you an "install" option?
[02:24:18] <jmkasunich> dunno
[02:24:34] <jmkasunich> you might have to put "cdrom" in your apt/sources.list file
[02:24:38] <SWPadnos> if not, then you have to use apt-cdrom add, then apt-get install <whatever>
[02:24:54] <jmkasunich> yeah
[02:25:04] <SWPadnos> but then the packages come from the CDROM, I'm not sure how updates are handled
[02:25:30] <jmkasunich> well, if you assume a box thats not net connected, frankly, updates aren't handled at all
[02:25:51] <jmkasunich> personally I can't imagine a machine that isn't net connected
[02:25:55] <jmkasunich> <shudders>
[02:26:03] <SWPadnos> normally , I wouldn't worry about needing an internet connection, but I had a kinda strange conversation with a (CNC-using) friend a few days ago
[02:26:10] <SWPadnos> heh - yeah
[02:26:19] <SWPadnos> or even worse - dial-up
[02:26:25] <SWPadnos> you think you're connected, but noooooooo
[02:26:42] <jmkasunich> cradek: you still around?
[02:27:20] <jmkasunich> on the topic of "installing emc2 from cdrom", we're probably gonna have a few folks who show up a the workshop with boxes that they want to install emc on
[02:27:38] <jmkasunich> and others who would like to walk away with CDs and install when they get home
[02:27:43] <jmkasunich> esp dialup folks
[02:27:46] <SWPadnos> yep
[02:28:15] <jmkasunich> I'll make sure I have an ubuntu iso, a burner, and a stack of blank CDs
[02:28:25] <jmkasunich> but what about emc2 itself?
[02:28:30] <SWPadnos> maybe I should bring my control box, and we can have a workshop on wiring up controls for use with EMC :)
[02:28:56] <SWPadnos> my empty control box ;)
[02:29:06] <jmkasunich> sure
[02:29:13] <jmkasunich> thats what the workshop is all about
[02:29:20] <SWPadnos> I can bring the small box and VFD as well
[02:29:28] <SWPadnos> but no mill
[02:29:51] <jmkasunich> I have some specific things I want to do on the mazak, and there is talk about an EDM, but I hope that we won't be so deep into a single huge project as we were last time
[02:30:06] <jmkasunich> I want to be able to help individuals with stuff, answer questions, etc
[02:30:09] <SWPadnos> I don't want to be, that's for sure
[02:30:13] <SWPadnos> yep
[02:30:39] <SWPadnos> it's Fest as well, so there can't really be that big a project, I think
[02:31:14] <jmkasunich> before we get there I want to have the "canonical encoder interface" worked out
[02:31:31] <jmkasunich> while there (where there is a motenc card) I want to update the motenc driver to that interface
[02:31:39] <jmkasunich> and test it by homing to index pulses
[02:31:43] <SWPadnos> that's a specification for the interface that any "encoder class" device will present?
[02:31:46] <jmkasunich> (right now the mazak homes to the switches)
[02:31:48] <jmkasunich> yes
[02:32:04] <jmkasunich> at present the software based encoder is the canonical interface
[02:32:12] <jmkasunich> but homing needs to be modified to work with it
[02:32:13] <SWPadnos> everything should have a "class" like that, but then you also get into capabilities reporting and the like
[02:32:33] <jmkasunich> well the idea with the encoder is to have only one
[02:32:38] <jmkasunich> so nothing to report
[02:32:52] <SWPadnos> right, but is it for rotary / incremental, or absolute, or either?
[02:32:59] <SWPadnos> linear?
[02:33:24] <jmkasunich> incremental, doesn't matter whether its linear or rotary
[02:34:17] <SWPadnos> what's missing from e.g. the usc encoder interface?
[02:34:31] <SWPadnos> reset on index is missing
[02:34:35] <jmkasunich> it seems like no two hal drivers handle index the same way
[02:34:39] <jmkasunich> yes
[02:34:59] <SWPadnos> there are sometimes hardware issues with index
[02:35:11] <SWPadnos> doesn't motenc or STG reset the counter on an index pulse?
[02:35:11] <jmkasunich> actually its worse than that - Jon noticed a week or so ago that he has had reset on index wrong in the FPGA forever
[02:35:17] <SWPadnos> heh
[02:35:25] <SWPadnos> I saw that mail
[02:35:35] <SWPadnos> maybe I'll install the Xilinx tools on my laptop ;)
[02:35:47] <jmkasunich> for the mesa card?
[02:35:56] <SWPadnos> either mesa or USC
[02:35:58] <jmkasunich> I _really_ want to look into that\
[02:36:16] <jmkasunich> the mesa card seems like a really cool idea, I wish I had more time
[02:36:33] <jmkasunich> I have this vision of building a spindle drive using the PC to do the hard work
[02:36:42] <jmkasunich> I have some 3kW three-phase power modules here
[02:36:43] <SWPadnos> I need to reinstall here, but I did manage to import the design files into Altium, and I got as far as place and route before the Xilinx software refused to go any further
[02:36:56] <jmkasunich> IGBT, DC bus, isolated gate drivers, isolated current sense
[02:37:03] <SWPadnos> cool
[02:37:38] <jmkasunich> all I need on an interface board is 3 ADCs, 3 PWM generators, and hardware IOC protection (instantenous overcurrent - never trust software)
[02:37:44] <SWPadnos> I think the current config uses about 40% of the FPGA on the mesa card
[02:39:09] <jmkasunich> the mesa has 72 IO, right?
[02:39:15] <SWPadnos> yep
[02:39:40] <jmkasunich> so a 12 bit parallel bus to multiple DACs and/or ADCs with a few chip selects still leaves a lot
[02:39:49] <jmkasunich> or use serial ADC/DACs
[02:39:50] <SWPadnos> yep
[02:39:50] <jmkasunich> I
[02:40:08] <jmkasunich> I've used some serial ones that have four channels in one chip for about $5
[02:40:20] <jmkasunich> build the serializer into the fpga
[02:40:24] <SWPadnos> Burr-Brown has some, as well as AD
[02:40:28] <SWPadnos> right
[02:40:33] <jmkasunich> I used AD
[02:40:50] <jmkasunich> AD7886 or something like that maybe
[02:41:28] <SWPadnos> Burr-Brown DAC7615P - quad 12-bit
[02:42:04] <jepler> I toyed with an tlv5604 once. quad 10-bit. It's pretty slow, though, 100k samples/second, and I think it's 1/4 that if you want to drive all 4 channels.
[02:42:05] <SWPadnos> more expensive though
[02:42:39] <jmkasunich> I can do motor control with 3-4 channels at 5KYz
[02:42:53] <jepler> "Yz"?
[02:42:59] <jmkasunich> Hz
[02:44:23] <jepler> maybe 100k samples/second isn't so slow in the context of running servos -- I was interested in running an XY display from it, which leaves only around 800 dots at 60fps.
[02:44:52] <jepler> is 12 bits of resolution important?
[02:44:54] <jmkasunich> yeah, thats a totally different speed class
[02:45:14] <SWPadnos> holy crap - 500MHz update rate:
http://www.digikey.com/scripts/DkSearch/dksus.dll?Detail?Ref=438079&Row=73903&Site=US
[02:45:31] <jmkasunich> 12 is what I consider the norm for industrial stuff
[02:45:32] <SWPadnos> at 16 bits
[02:45:47] <jmkasunich> 8 is too low, 16 is overkill
[02:45:52] <SWPadnos> 12 bits is fine for feedback systems. it's possibly a little low for open loop
[02:47:11] <jmkasunich> for us, 12 bits means sub 1/4V resolution on a 800V dc bus, and sub 1A resolution on a 1200A rms output drive (IOC at 3200A or so)
[02:47:43] <jepler> you play with the big toys
[02:47:45] <jmkasunich> since the analog accuracy is at best 0.1%, and usually more like 0.2-0.3%, much finer doesn't buy us anything
[02:48:17] <jepler> isn't 0.1% about the same as 10 bits?
[02:48:20] <jmkasunich> yes
[02:48:21] <SWPadnos> yeah - it's the old 10x rule though - 4096 steps gives you ~400 steps of "good control"
[02:48:35] <jepler> 'night all
[02:48:37] <SWPadnos> which isn't that great when you're talking about a 20000A power supply ;)
[02:48:47] <jmkasunich> night jeff
[02:48:49] <jepler> you need floating-point
[02:48:52] <SWPadnos> night jepler
[02:48:59] <SWPadnos> heh - yeah, in the little AVR ;)
[02:49:04] <jmkasunich> heh
[02:49:13] <jmkasunich> I wish we had floating point in our drives
[02:49:26] <jmkasunich> they use 32 bit processors, so fixed point usually works
[02:49:50] <jmkasunich> except that 90% of the control software was written by folks who never run anything bigger than 50HP
[02:49:50] <SWPadnos> 32 bit fixed can be better than 32-bit FP for this kind of application
[02:49:57] <SWPadnos> it's the derivatives that get you though
[02:49:58] <jmkasunich> we've found a few scaling problems
[02:50:20] <SWPadnos> ah yes - overflows they never thought of
[02:50:23] <jmkasunich> yep
[02:50:35] <SWPadnos> sounds like Ariane 5
[02:50:56] <jmkasunich> they do a lot of divides by multiplying by reciprocals
[02:51:18] <jmkasunich> X/Y = X*(K/Y)/K where K = some power of 2
[02:51:31] <SWPadnos> damn - went straight from a cold / runny nose to a nosebleed. bbiab
[02:51:34] <jmkasunich> often Y is ~1
[02:51:52] <jmkasunich> so K is large, and the intermediate result gets big
[02:51:59] <SWPadnos> right - multiply then take only the low (word size) portion
[02:59:51] <jmkasunich> 11pm....
[03:00:01] <SWPadnos> and all's more or less well
[03:00:06] <jmkasunich> you know, I might just do something differnet and go to bed
[03:00:16] <SWPadnos> I'm sorry - I didn't understand that
[03:00:29] <SWPadnos> http://ubuntuforums.org/showthread.php?t=2854
[03:00:37] <jmkasunich> I haven't gone to bed before midnight in a long time
[03:00:54] <jmkasunich> was up to 4am sunday night working on farm stuff
[03:01:17] <SWPadnos> nighty night then ;)
[03:02:59] <jmkasunich> interesting thread
[03:03:16] <jmkasunich> at least in our case we know the dependencies
[03:03:49] <jmkasunich> it would be interesting to un-iso an ubuntu iso, add our debs to their debs, then mkisofs it back up again
[03:04:01] <SWPadnos> just mount -o loop
[03:04:04] <jmkasunich> (delete some rarely used packages if needed to make space)
[03:04:10] <cradek> ugh, why?
[03:04:30] <jmkasunich> so we can hand out cds at fest that will install emc2 without an internet connection
[03:04:33] <SWPadnos> for the case of non-net-connected machines, or multiple installs without multiple downloads
[03:04:37] <jmkasunich> (or at least without a broadband one)
[03:04:47] <cradek> then we should make a second CD with the emc2 repository
[03:04:57] <SWPadnos> that's the other possibility
[03:05:01] <cradek> I refuse to get into the bdi business
[03:05:12] <SWPadnos> how would that work with other debian-based distros?
[03:05:18] <SWPadnos> (the emc2 repository CD)
[03:05:40] <cradek> might work fine, it's untested
[03:05:43] <jmkasunich> I can understand not getting into the bdi business
[03:05:44] <SWPadnos> heh
[03:05:57] <jmkasunich> but twice as many cds to burn and hand out also sucks
[03:06:15] <jmkasunich> if we could get a batch of official ubuntu cds that would be cool
[03:06:17] <cradek> not if you order a stack of nice screen-printed CDs from ubuntu
[03:06:22] <SWPadnos> maybe we should order a bunch of CDs from Ubuntu.com?
[03:06:28] <cradek> I have 15-20 of them that I intend to bring
[03:06:29] <jmkasunich> but I've yet to hear of anyone getting their disks from them
[03:06:36] <jmkasunich> oh, so they did arrive?
[03:06:42] <cradek> I got mine after 3-4 weeks
[03:07:08] <jmkasunich> hmm, maybe I shold order a bunch
[03:07:13] <jmkasunich> might get here in time, might now
[03:07:14] <cradek> they came from france, I don't know why
[03:07:14] <jmkasunich> not
[03:07:29] <SWPadnos> they aren't shipping any more until they release Dapper Drake
[03:07:36] <jmkasunich> poop
[03:07:39] <SWPadnos> yep
[03:07:42] <cradek> that was not the case last I checked, even though someone else told me the same thing
[03:07:46] <SWPadnos> * SWPadnos just checked
[03:07:54] <cradek> darn.
[03:08:01] <jmkasunich> DD is due this month isn't it?
[03:08:10] <SWPadnos> was, but now it's early next
[03:08:31] <SWPadnos> we can burn our own CDs - they're cheap
[03:08:34] <cradek> yep
[03:08:35] <jmkasunich> are the disks you got from them burned or pressed?
[03:09:02] <cradek> how do I tell?
[03:09:19] <SWPadnos> if they're blue-ish, they're burned
[03:09:21] <cradek> they look nice, they come in an envelope with install CD and live CD
[03:09:27] <jmkasunich> compare them to a music cd?
[03:09:29] <SWPadnos> if they're silver, they're pressed
[03:09:30] <cradek> no they're silver like factory music CDs
[03:09:44] <jmkasunich> the reason I asked, I tend to have miserable luck with burned cds
[03:09:53] <jmkasunich> I manage to ruin them
[03:10:03] <cradek> I have pretty good luck I guess
[03:10:14] <cradek> I have a duplicator at work - I could run a bunch if you think we'll need them
[03:10:18] <SWPadnos> they have a terrible shelf life
[03:10:21] <cradek> but I doubt we'll need that many...?
[03:10:36] <jmkasunich> last year BDI-4.20 was the current version
[03:10:45] <jmkasunich> we probably gave away 20-30?
[03:11:27] <jmkasunich> it would definitely be good if you could burn some with the emc2 repository
[03:11:53] <jmkasunich> if you have 15 ubuntu, burn 15-20 repository disks, so we can give a complete set
[03:11:54] <cradek> I haven't tried it, but I assume it's the same structure as the ftp site, and you use apt-cdrom somehow to add it
[03:12:05] <cradek> wonder if anyone will have a burner there
[03:12:17] <jmkasunich> my box has a burner
[03:12:21] <jmkasunich> most do these days
[03:12:25] <cradek> I was going to put one in the machine I was bringing, but I think now I'm just bringing my laptop
[03:13:59] <SWPadnos> damn - laptop DVD +/-RW drives are $70 now
[03:14:08] <jmkasunich> I don't know how much interest there will be, but I suspect there will be a certain number of folks that want an "install fest"
[03:14:28] <SWPadnos> how many people do you expect to bring their computeers?
[03:14:33] <jmkasunich> especially if there are suitable computers available for cheap at the swap tables
[03:14:35] <SWPadnos> conputers also
[03:14:39] <SWPadnos> argh
[03:15:05] <jmkasunich> cpomuetrs
[03:15:13] <SWPadnos> yeah - those
[03:15:14] <cradek> helping people install is trivial
[03:15:26] <cradek> helping people set up emc2 for their oddball software: not so trivial
[03:15:36] <jmkasunich> oddball software?
[03:15:41] <jmkasunich> do you mean hardware?
[03:15:45] <cradek> hardware
[03:16:21] <jmkasunich> well, I intend to be "Mr. HAL" to some extent
[03:17:32] <jmkasunich> being able to type on their keyboard, read their screen, and if needed apply my (real) scope in addition to halscope beats the pants off of trying to help them on IRC and/or mail
[03:17:43] <jmkasunich> speaking of which...
[03:17:45] <SWPadnos> yep indeed
[03:17:49] <jmkasunich> I seem to keep missing chinamill
[03:18:07] <jmkasunich> when I read back in the evening he's asking questions about hal modules and stuff
[03:18:15] <cradek> true, maybe it will be easy for us to help set up someone's basic machine.
[03:18:51] <jmkasunich> I think one or two of the classes ray has planned are on using hal
[03:19:14] <jmkasunich> and I think roland told me yesterday he might have a projector (the kind that lets you project your screen output)
[03:19:32] <jmkasunich> so we could walk people thru copying a sample config and customizing it
[03:20:09] <jmkasunich> unfortunately none of those projectors have made it into the dumpster yet....
[03:20:51] <cradek> crap, that reminds me I better email fred
[03:22:23] <jmkasunich> looks like the 6.4 release has slipped _two_ months
[03:22:24] <jmkasunich> Ubuntu 6.06, due to be released on June 1st, 2006, will mark a new milestone for Ubuntu. Aimed at organisations with long-term and large-scale free software deployments, Ubuntu 6.06 is a robust and reliable platform that will be actively supported with security updates and high-impact bug fixes for a period of 3 years on the desktop and 5 years on the server.
[03:22:31] <jmkasunich> but the long term support is interesting
[03:22:44] <SWPadnos> yeah, plus the gnome updates, and a bunch of other stuff
[03:22:54] <SWPadnos> (like XGL and compiz packages)
[03:23:15] <cradek> good, it's a distraction I don't want yet.
[03:23:39] <cradek> I hope they don't do something dumb like go to xgl-only
[03:23:53] <SWPadnos> no way - it's just a package in the dapper repositories now
[03:23:53] <jmkasunich> whats XGL?
[03:24:03] <cradek> "jellovision"
[03:24:06] <SWPadnos> super-duper 3D window manager stuff
[03:24:12] <cradek> there's a video out there, let me see if I can find it
[03:24:21] <cradek> it's eyecandy like vista might have some day if it's released
[03:24:27] <jmkasunich> dunno if I'm set up to watch video here
[03:24:38] <jmkasunich> and I don't like eye candy, so don't bother ;-)
[03:24:50] <SWPadnos> http://www.linuxedge.org/?q=node/58
[03:25:26] <jmkasunich> 3D objects on the desktop and animated backgrounds.
[03:25:32] <cradek> requires nvidia hardware and the closed-source driver that nukes rtai
[03:25:33] <SWPadnos> the cool thing is that it actually uses the GPU hardware for rendering the desktop
[03:25:38] <jmkasunich> ooohhhh, I'm just drooling all over the keyboard
[03:25:39] <jmkasunich> NOT!
[03:25:47] <cradek> in a few years, if that's all that's available, we might be screwed.
[03:25:51] <SWPadnos> it also runs on ATI hardware
[03:26:27] <cradek> fwiw, I think they have a few good ideas, but the jello would have to go
[03:26:34] <cradek> I tried using it, I lasted about 5 minutes
[03:26:47] <SWPadnos> I've been trying to boot the kororaa XGL liveCD on my big amchine, but it doesn't seem to like the SATA DVD drive
[03:27:10] <SWPadnos> I think it would perform fine on a dual Opteron with a 7800GT
[03:27:42] <jmkasunich> I want stuff that performs fine on older hardware than my main box
[03:27:50] <jmkasunich> not stuff that demands newer than my main box
[03:27:56] <SWPadnos> both have their place
[03:28:11] <jmkasunich> bah humbug
[03:28:19] <SWPadnos> fubar to yubar
[03:28:22] <cradek> I'm glad we won't have this distraction at the workshop.
[03:29:16] <jmkasunich> anything that _needs_ a dual opteron had damn well be resequencing DNA or rendering POVray or something else that actually _needs_ performance, rather than just eye candy that robs performance
[03:29:44] <SWPadnos> sure - the desktop is just in POVRAY (mmmm - terminal / nano in POVRAY ... ;) )
[03:29:44] <jmkasunich> this distraction = 6.06?
[03:29:50] <cradek> yes
[03:30:09] <SWPadnos> well - if it's at all possible, I think we should be handing out 6.06
[03:30:23] <cradek> jmkasunich: people (who are not like us) really like things like jiggling windows
[03:30:37] <cradek> SWPadnos: how would that be possible in 6.05?
[03:30:39] <jmkasunich> people (who are not like us) are idiots
[03:30:40] <SWPadnos> it just "looks bad" to be giving away 8-month-old software as the "latest and greatest"
[03:30:53] <SWPadnos> as I said - if possible ;)
[03:31:15] <cradek> I guess I don't care about that
[03:31:28] <cradek> emc2 is the latest and greatest
[03:31:32] <jmkasunich> 8 month old software is not old
[03:31:35] <cradek> ubuntu 5.10 is a proven stable platform to run it on
[03:31:53] <jmkasunich> which will be officially supported by ubuntu for another 18 months
[03:32:08] <jmkasunich> oops, 10 months
[03:32:09] <cradek> "looks bad" is handing out stuff that doesn't work because you haven't even had time to try it yet
[03:33:10] <SWPadnos> that's also rue
[03:33:12] <SWPadnos> true
[03:33:13] <jmkasunich> if DD was out today, I'd consider it for fest
[03:33:19] <jmkasunich> we could install and play with it
[03:33:22] <cradek> I might consider it
[03:33:35] <jmkasunich> but if it comes out a week before fest, thats just insane
[03:33:36] <cradek> it might be a lot of work (for me), I may or may not choose to do it right away
[03:33:48] <jmkasunich> right, I forgot about the kernel
[03:34:27] <cradek> these releases probably overlap by a year for this reason
[03:34:36] <cradek> ... it takes time to switch
[03:34:42] <SWPadnos> can you put kernel patching notes/instructions into the infrastructure repository?
[03:35:01] <jmkasunich> the nice thing about DD is the three year support period they're talking about
[03:35:10] <cradek> those should go in the wiki probably
[03:35:17] <jmkasunich> apparently the next version after DD is going to be more bleeding edge
[03:35:25] <jmkasunich> why not infrastructure?
[03:35:40] <SWPadnos> maybe both
[03:36:04] <cradek> I guess I don't think of compile instructions as infrastructure
[03:36:13] <SWPadnos> there is an RTAI kernel for ubuntu in Universe
[03:36:25] <SWPadnos> I'm not sure if it would work
[03:36:49] <cradek> I looked at an rtai build that someone had done, it was very screwy
[03:37:04] <cradek> not sure if it's the same one
[03:37:09] <SWPadnos> on ubuntu, which compiler did you end up using?
[03:37:13] <SWPadnos> it could be
[03:37:22] <cradek> 3.4
[03:37:39] <SWPadnos> for the kernel/RTAI as well?
[03:37:53] <cradek> yes all kernels are built with 3.x on ubuntu
[03:38:11] <SWPadnos> good deal
[03:38:24] <SWPadnos> that was another issue with BDI - mixed compilers
[03:38:33] <SWPadnos> 2.9x and 3.3, IIRC
[03:38:42] <cradek> last I saw, bdi was still using 2.95, I don't know why
[03:38:56] <cradek> I couldn't get anything to build right with it (and it's pre-c99)
[03:39:12] <SWPadnos> some incompatibility with some RTAI or ADEOS version
[03:39:19] <cradek> * cradek shrugs
[03:39:25] <jmkasunich> rtai has had issues with new compilers, but I think that is history now
[03:39:28] <cradek> 3.4 worked fine for me
[03:39:49] <cradek> maybe there's still superstition around, difficult problems in the past can cause that
[03:39:53] <SWPadnos> I was going to roll my own again on my Gentoo install, but the ADEOS stuff changed to ipipe, and it was too strange for me to bother figuring out
[03:40:19] <jmkasunich> I see that 4.20 still used 2.95
[03:40:46] <jmkasunich> its probably superstition at this point
[03:40:50] <cradek> yeah.
[03:40:57] <cradek> clearly 3.x works fine
[03:41:16] <jmkasunich> https://wiki.ubuntu.com/WhatWindowsUsersWant
[03:41:23] <cradek> btw 4.x does NOT work fine
[03:41:36] <jmkasunich> #1: chat #2: peer to peer
[03:41:59] <jmkasunich> buncha music copying chatty teenagers
[03:42:11] <cradek> 3. software to help you consume more
[03:42:14] <cradek> 4. worthless eyecandy
[03:42:21] <cradek> 5. same as 3
[03:42:45] <jmkasunich> you must not be reading the same list
[03:42:53] <cradek> conclusions/key findings
[03:42:54] <jmkasunich> 3 is spyware cleaner ;-)
[03:43:05] <jmkasunich> 4 is compression, ok, thats usefull
[03:43:08] <cradek> oh, I was further up
[03:43:09] <jmkasunich> 5 media player
[03:43:17] <jmkasunich> 6 downloading
[03:43:27] <jmkasunich> 7 desktop customization
[03:43:30] <jmkasunich> (eye candy)
[03:43:48] <cradek> I'm glad this is not my problem
[03:44:05] <jmkasunich> yep
[03:44:10] <cradek> I don't give two ... about most of that
[03:44:46] <cradek> man
[03:44:53] <cradek> the whole list is chat and consume
[03:44:57] <jmkasunich> I find it amusing (and depressing) when I see a website that is all about how good some distro is, and their evidence is.....
[03:45:04] <cradek> don't these people actually DO anything?
[03:45:13] <jmkasunich> an page with fifty screenshots of customized desktops
[03:45:19] <jmkasunich> each weirder than the next
[03:45:43] <cradek> ok I need to go to bed before I read any more of this
[03:45:47] <cradek> goodnight guys
[03:45:57] <jmkasunich> transparent xterms with light gray text scrolling on a background of some video game monster's fa ce
[03:46:00] <jmkasunich> goodnight
[03:46:29] <SWPadnos> nighto
[04:49:46] <SWPadnos> SWPadnos is now known as SWP_Away
[10:46:36] <rayh> another msgcat question -- msgcat::mc "can't save %s
[10:47:14] <rayh> If msgcat does phrase matching it will never find that phrase.
[10:54:02] <rayh> Ah I see it. %s is generic and the actual value is assigned following the lookup.
[10:54:06] <rayh> sorry.
[12:34:05] <rayh> cradek, I was reading something about yet another change to configuration. Could you describe that to me?
[12:46:37] <jepler> do you mean hal/ini changes? I haven't seen anything lately that needs hal/ini changes.
[13:04:14] <rayh> I'm not certain what it was about. Let me read back on the logger and see if I can understand what was being said.
[13:13:05] <rayh> something to do with "identical files should have identical names." Doesn't affect my ini work though. Thanks jepler
[13:27:48] <SWP_Away> SWP_Away is now known as SWPadnos
[13:28:36] <SWPadnos> rayh, were you referring to the short discussion jmk and I had last night re: wholepair's .nml and .tbl files?
[13:39:27] <rayh> Right.
[13:40:53] <rayh> I was wondering if it would affect halconfig but it doesnt.
[13:41:29] <SWPadnos> I'm not sure what caused us to rename all the .tbl, .nml and .var files in the first place
[13:44:17] <rayh> Nor do I except that someone could find any old var and edit by hand and think he was getting the one that was run with a specific setup.
[13:44:38] <rayh> Some of us tend to do those sorts of dumb things.
[13:45:02] <SWPadnos> I've only done it twice. once to use a remote ui via NML, and once to change it back ;)
[17:31:46] <rayh> this is the output of one parameter "05 u8 -W 1 (01) stepgen.2.steplen
[17:31:47] <rayh> "
[17:32:09] <rayh> why are there two numbers in the value space 1 and (01)
[18:33:08] <cradek> they're probably decimal and hex
[19:00:56] <rayh> Okay. I did try changing the first and it changes the second. Didn't think of that.
[19:01:55] <cradek> if you want to be sure, have a look at the source
[19:04:59] <cradek> sorry, I guess that was stating the obvious
[20:03:01] <SWPadnos> it is decimal and hex. you only get the decimal if you use the -s option to halcmd (unless there's a bug there)
[20:03:58] <rayh> Ah okay.
[20:04:03] <rayh> Thanks
[20:04:35] <SWPadnos> err - I should have said, you get only decimal (no hex) with -s
[20:06:14] <rayh> okay. got that.
[20:06:42] <SWPadnos> I figured it would just jog your memory, but it doesn't hurt to be clear :)
[20:08:46] <rayh> No clear is good for most things. Beer bottles in the sun might be an exception.
[20:08:53] <SWPadnos> heh
[23:34:57] <jmkasunich> hi all
[23:35:26] <jmkasunich> or should that be hay y'awl
[23:48:27] <cradek> hi john
[23:49:12] <jmkasunich> I see the subject of naming .nml, .var, etc came up (very briefly)
[23:49:29] <cradek> yeah, I didn't see the original conversation, just ray asking about it later
[23:50:55] <jmkasunich> the idea of stepper.var, sim.var, stg.var, this.var, that.var just seems wrong
[23:51:03] <jmkasunich> since they all start out exactly the same
[23:51:22] <cradek> I think I remember arguing that some time ago
[23:51:39] <cradek> but it's too late, so I think we shouldn't worry about it
[23:52:03] <jmkasunich> its never too late ;-)
[23:52:30] <cradek> it's WAY too late for the release, but I won't argue if someone wants to change it in HEAD
[23:53:17] <jmkasunich> I was afraid you'd say that
[23:53:34] <jmkasunich> changing it in head and not the release just means more pain later
[23:53:47] <cradek> then we shouldn't change it
[23:53:52] <cradek> it doesn't hurt a single thing
[23:54:18] <jmkasunich> it caused some confusion last night with wholepair
[23:54:27] <jmkasunich> but I think the real problem was the wiki page he followed
[23:54:43] <jmkasunich> it said "copy sim to your directory and edit to suit your needs"
[23:54:47] <cradek> I didn't read back far enough I guess
[23:54:58] <jmkasunich> except he was trying to set up a stepper machine
[23:55:05] <jmkasunich> so he should have copied stepper
[23:55:26] <cradek> hmm yeah this sounds like a tangent then
[23:55:27] <jmkasunich> we tried just moving a couple files around, thats when the naming thing made a mess
[23:55:41] <jmkasunich> in the end we said fsck it and had him copy stepper
[23:56:16] <jmkasunich> I changed the wiki page today, telling them to pick the most appropriate sample to copy, instead of just telling them to copy sim
[23:56:36] <cradek> cool