Back
[01:01:27] <jmkasunich> strange - ./configure is missing
[01:01:38] <jepler> jmkasunich: run ./autogen.sh
[01:01:55] <jepler> jmkasunich: sometime after 2.3 I removed configure and config.h from revision control, because they're generated files
[01:02:13] <jmkasunich> ah
[01:02:40] <jmkasunich> I think maybe I'll edit docs/INSTALL to note that, so I can do a commit (it's been ages)
[01:02:48] <jepler> you might have to install the package "autoconf"
[01:03:07] <jmkasunich> already had that
[01:03:10] <jepler> OK
[01:03:42] <jmkasunich> checking for /usr/src/linux-headers-2.6.17-rtai3.5/include/linux/version.h... noconfigure: error: version.h not found - Is the kernel headers package installed ?
[01:04:20] <jmkasunich> duh, this box doesn't have RTAI, I gotta tell it to do sim
[01:04:44] <jepler> aystarik: there were three main concerns I had about your proposed changes. First, the unrelated stuff mixed in (like removal of linecode); second, the indentation could better match the surrounding code; third, my version doesn't radically change the API so that no user of the gcode module could get unprocessed arcs.
[01:05:08] <jepler> aystarik: I think I incorporated all of your algorithmic suggestions, and I was glad to have your code and explanations while working on it!
[01:09:34] <jmkasunich> jepler: noticing some oddness
[01:10:00] <jmkasunich> ./configure --enable-run-in-place --enable-simulator <--- seems to work OK
[01:10:08] <jmkasunich> make clean <--- seems to work
[01:10:17] <jmkasunich> make clean (yes, again) result in:
[01:10:30] <jmkasunich> jmkasunich@mahan:~/emcdev/emc2head/src$ make clean
[01:10:30] <jmkasunich> make: Entering directory `/home/jmkasunich/emcdev/emc2head/src'
[01:10:31] <jmkasunich> make: *** No rule to make target `config.status', needed by `Makefile.inc'. Stop.
[01:10:33] <jmkasunich> make: Leaving directory `/home/jmkasunich/emcdev/emc2head/src'
[01:11:53] <aystarik> jepler: there is more clean up to arcs, please take a look at patch.
[01:12:00] <jepler> jmkasunich: hm, that may be caused by 1a48491976d6c56d3ebe5f099a90f18fbc2d58d2
[01:12:22] <jepler> aystarik: can you be more specific?
[01:12:25] <jmkasunich> caused by "string of random characters that means nothing to me"
[01:12:51] <jepler> jmkasunich: oh, sorry, that's a git commit. you can see it with: git show 1a484919
[01:13:08] <aystarik> do you see patch in emc-devel, I just sent it?
[01:14:36] <jepler> aystarik: I see that you silenced the warning about 'plane' unitialized. do you see a code path where it actually could be uninitialized, or are you just making the compiler happy?
[01:14:49] <jepler> I think rotate/unrotate better shows intent
[01:15:16] <aystarik> add comment?
[01:15:53] <aystarik> rad, tx and ty need not to be calculated.
[01:18:47] <jepler> any performance comparisons?
[01:19:02] <aystarik> at noise level.
[01:19:52] <jmkasunich> jepler: I'm seeing things in the makefile that look wrong, but I'm too out of the loop to be sure - let me know if/when you have a few mins to discuss
[01:22:08] <jepler> jmkasunich: go ahead
[01:22:46] <jmkasunich> I'm getting an error message about "no rule to make config.status", but there is a rule in the makefile
[01:23:06] <jmkasunich> line 204 of my makefile
[01:23:36] <jmkasunich> I noticed that rule invokes configure with "--enable-run-in-place", but not with "--enable-simulator", even tho I'm using sim
[01:25:26] <jepler> jmkasunich: hm, my intentions were good
[01:25:52] <jepler> jmkasunich: if you ran configure in the past (and not 'make clean', I guess) then you have config.status. that rule would run when the configure script is updated
[01:26:31] <jepler> but I was trying to be smart, and run it with some default options if configure has never been run, or config.status has been removed (e.g., 'make clean')
[01:27:10] <jepler> so probably the rule should say something more like 'if [ -f config.status ]; then ./config.status --recheck; else echo "Run ./configure with sensible arguments"; exit 1; fi'
[01:27:25] <jmkasunich> that rule should also run if config.status has been removed (by make clean, or whatever)
[01:28:01] <jepler> jmkasunich: but if config.status is removed, then nothing records the desired ./configure arguments
[01:28:26] <jmkasunich> ok, this gets to the root of my problem - what is config.status for anyway?
[01:28:34] <aystarik> cradek, I've sent out the patch to add panes to AXIS, it is almost usable...
[01:28:48] <aystarik> bbl
[01:28:49] <jmkasunich> and if it is needed during a make, why is make clean removing it?
[01:28:56] <jepler> jmkasunich: it's a file that configure creates
[01:29:08] <jmkasunich> gathered that much, what info does it store?
[01:29:11] <jepler> jmkasunich: seb made clean remove it because it made dpkg happy
[01:29:37] <jepler> jmkasunich: it stores the result of every configure test and the code to regenerate each xxx file from xxx.in
[01:30:07] <jmkasunich> what is that used for? to speed up subsequent runs of configure or something>?
[01:31:12] <jepler> jmkasunich: consider scripts/emc. It's made at ./configure time from scripts/emc.in. It can also be made by config.status: ./config.status --file=../scripts/emc.in
[01:31:26] <jepler> jmkasunich: so there's a makefile rule to invoke config.status when an xxx file needs to be rebuilt from xxx.in
[01:31:38] <jepler> in the far past it was necessary to rerun configure each time you changed emc.in and that was undesirable
[01:31:47] <jmkasunich> ok, got that
[01:32:08] <jmkasunich> so, either Seb made a mistake, or the intended use of make clean is not what I thought it was
[01:32:24] <seb_kuzminsky> i may well have messed up there
[01:32:29] <jmkasunich> I thought you could run configure, then make, make clean, make, make clean, etc, as often as wanted
[01:32:46] <jmkasunich> but it sounds like make clean is making things _really_ clean, as in you must re-run configure
[01:32:47] <jepler> seb_kuzminsky: would it make sense to put the removal of those specific files in debian/rules clean?
[01:33:05] <jepler> or in a new target? some projects use 'distclean' for that purpose
[01:33:36] <seb_kuzminsky> debian/rules sounds fine to me
[01:34:02] <seb_kuzminsky> i'll fix it
[01:35:39] <jepler> seb_kuzminsky: I think that you'll want to do that on v2.4_branch since that's where you introduced the change
[01:35:46] <seb_kuzminsky> i agree
[01:35:55] <jmkasunich> the first issue we just talked about happened if I ran make clean twice
[01:36:06] <skunkworks> jmkasunich: got the packages - they work great.
[01:36:25] <jmkasunich> I also got warnings (which might have been errors, but didn't stop the build) if I ran make clean once, then ran make
[01:36:45] <jmkasunich> I suspect both issues might be manifestations of the same thing...
[01:37:03] <jmkasunich> skunkworks: great
[01:39:35] <jepler> jmkasunich: yeah it does similar baffling things here
[01:40:44] <jmkasunich> am I correct that you should be able to run make clean followed by make as many times as you want, without re-running configure?
[01:41:32] <jepler> I'm pretty sure it used to work that way
[01:41:43] <jepler> I seldom run "clean" myself
[01:41:54] <jmkasunich> I know it did - my question is whether that is the intended behavior
[01:42:13] <seb_kuzminsky> jmkasunich: that seems like a reasonable way for it to work
[01:42:15] <jmkasunich> I ran clean just now because it's been ages since I did anything, and I wanted to de-cruft
[01:42:19] <jepler> I don't know of any good reason to take away that behavior
[01:42:47] <jmkasunich> ok, so consider this conversation a bug report (and it sounds like Seb is already fixing the bug)
[01:42:54] <jmkasunich> at least I can still test things ;-)
[01:43:22] <seb_kuzminsky> that's not bad, i'm mostly good at breaking things
[01:44:13] <jmkasunich> * jmkasunich curses git
[01:44:59] <jmkasunich> more accurately: jmkasunich curses anything that makes him learn new ways of working
[01:45:52] <jepler> :)
[01:48:00] <jmkasunich> what is this "origin" thing?
[01:48:30] <jmkasunich> looking at
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Git
[01:48:36] <jepler> "origin" is the name of the location you cloned from
[01:48:42] <seb_kuzminsky> origin is the remote repository you originally cloned from, probably git.linuxcnc.org
[01:48:51] <seb_kuzminsky> what he said ^^^
[01:49:58] <jmkasunich> I need some intrpretation of that wiki page, specifically section 6
[01:50:19] <jmkasunich> the fourth set of commands says "to work on the 2.4 branch...."
[01:50:28] <jmkasunich> then shows a branch command followed by a checkout command
[01:50:55] <jmkasunich> the next section shows switching between branch and master by using only checkout commands
[01:51:14] <seb_kuzminsky> the branch command is only needed once. It makes a "local branch" tracking the remote branch on origin
[01:51:56] <JT-Hardinge> I'm with you jmkasunich on learning things like git'
[01:52:03] <jmkasunich> I think a light is starting to turn on
[01:52:17] <jepler> git is a distributed system, so it has a distinction between a "local branch" and a "remote branch". origin/v2.4_branch is a remote branch; it is changed when you use commands like pull and push
[01:52:30] <jmkasunich> git forces you to duplicate a bunch of stuff locally that you never had to worry about before
[01:52:32] <jepler> you want to create "v2.4_branch" which you can change by commands like commit
[01:52:56] <jmkasunich> exactly - stuff is duplicated
[01:53:11] <seb_kuzminsky> jmkasunich: that's right
[01:53:23] <jmkasunich> and everything takes two steps instead of one
[01:53:29] <seb_kuzminsky> jmkasunich: yes
[01:53:36] <seb_kuzminsky> and those are both good things :-)
[01:53:41] <jmkasunich> sez you
[01:53:54] <seb_kuzminsky> sez me :-)
[01:54:10] <seb_kuzminsky> i was in the middle of a big hack when you made the bug report above
[01:54:23] <seb_kuzminsky> i was working on my local master, which is tracking "origin/master"
[01:54:57] <seb_kuzminsky> so i committed (locally), made a new branch from that point called "doc-hack", reset my master to origin/master, and switched focus to the bug fix
[01:55:12] <seb_kuzminsky> so i saved state without polluting the main repo
[01:55:17] <seb_kuzminsky> very handy, sez me ;-)
[01:55:40] <jepler> * jepler now wonders what seb_kuzminsky is doing with the docs
[01:55:47] <seb_kuzminsky> i'm experimenting
[01:56:18] <jmkasunich> my initial curse at git was because I couldn't figure out the equivalent of "cvs diff -u"
[01:56:21] <jmkasunich> I still can't
[01:56:44] <seb_kuzminsky> i split emc2.deb into three debs, to get the big pdfs out to their own packages (emc2-doc-en and emc2-doc-fr)
[01:57:06] <seb_kuzminsky> if you *dont* want the pdfs, this brings your download from 15 MB to 3 MB
[01:57:19] <seb_kuzminsky> and the installed size from 28 MB to 14MB
[01:57:36] <jepler> jmkasunich: "git diff" doesn't do what you want?
[01:57:42] <seb_kuzminsky> i fully intended to run this by the bowers that pee before pushing anything ;-)
[01:58:11] <seb_kuzminsky> oh man i love git diff, especially after i set color.diff=true in my git config :-)
[01:58:27] <seb_kuzminsky> * seb_kuzminsky refrains from suggesting "git gui" to jmkasunich
[01:58:31] <jmkasunich> jepler: well, now that there are two stages, and multiple local branches, I'm no longer 100% sure what I want
[01:59:10] <seb_kuzminsky> may i recommend "gitk"? you give it a list of branches you're interested in on the command-line, and it shows you the histories of those branches in relation to each other
[01:59:25] <jmkasunich> my old workflow was: 1) do stuff, 2) test it 3) cvs diff -u to preview the commit 4) cvs commit -m "pithy comment"
[01:59:26] <seb_kuzminsky> frex, "gitk master origin/master"
[01:59:36] <jepler> or just "gitk" (no args)
[01:59:55] <seb_kuzminsky> jmkasunich: i think that would still be fine, if you replace "cvs" with "git", and append 5) git push
[02:00:22] <seb_kuzminsky> oh, and drop -u from the diff, unified diffs are default in git
[02:01:26] <jmkasunich> the wiki implies that I should pull and resolve conflicts after my local commit and before the push
[02:01:54] <jmkasunich> and also mentions--rebase, which I haven't read about yet
[02:02:04] <seb_kuzminsky> dont worry about rebase yet
[02:02:29] <seb_kuzminsky> it's always a good idea to do your work close to the tip of the central repo, just like with cvs or anything else
[02:02:46] <jmkasunich> and rebase puts me there?
[02:02:56] <seb_kuzminsky> pull does
[02:03:13] <jmkasunich> ok, I did a pull an hour or so ago
[02:03:51] <seb_kuzminsky> pull means "fetch everything new from origin to my local copy of origin, then try to merge the local branch that i'm in with origin's branch that i'm trackign"
[02:04:36] <JT-Hardinge> hmmm on 2.4 max velocity of any axis caps the rest is that expected?
[02:06:13] <jmkasunich> do you really have to do "git add <file>" for every changed file that you want to commit?
[02:06:30] <seb_kuzminsky> either that, or say "git commit -a" to commit everything that's changed
[02:07:00] <seb_kuzminsky> "git commit -a" duplicates the "cvs commit" behavior that way
[02:07:17] <jmkasunich> see - it's never as simple as "replace cvs with git" ;-)
[02:07:21] <seb_kuzminsky> and yes, git is full of little goofy command line flags like that, and it ain't pretty
[02:07:41] <seb_kuzminsky> * seb_kuzminsky again does not tell jmkasunich about git gui
[02:07:50] <CIA-2> EMC: 03jmkasunich 07master * ra89e2cae5fc9 10/docs/INSTALL: configure isn't present on a fresh checkout, add info on how to generate it
[02:07:58] <seb_kuzminsky> wohoo!
[02:08:56] <jmkasunich> it is disconcerting when my commit changed one file, but my push says "counting objects: 7" and later "compressing objects 4/4", and "total: 4 (delta 3)", etc
[02:09:15] <jmkasunich> made me think I accidentally changed something else, even tho git diff and the commit indicated I didn't
[02:09:37] <jepler> :)
[02:09:41] <seb_kuzminsky> yeah that's a bit weird too - objects in this case includes directories up to the repo root
[02:09:48] <CIA-2> EMC: 03seb 07v2.4_branch * r68db5f71e65d 10/ (debian/rules.in src/Makefile): don't remote config.status on "make clean"
[02:10:11] <seb_kuzminsky> urg, i blame all this talk of "remote" repos on my typo in that commit message...
[02:11:39] <jmkasunich> ok, now for git 102 - the change I just made should probably be in the 2.4 branch since configure isn't part of a checkout in that branch
[02:12:59] <seb_kuzminsky> what i would do is make a local branch named v2.4_branch frmo origin/v2.4_branch, check out the new local branch, cherry pick your commit (using gitk), and push the result to origin
[02:13:23] <jmkasunich> I figured out the first two steps from the wiki, doing that now
[02:13:51] <jepler> by the way, I like to reassure myself that "push" will do what I wanted.. here's how I do that:
[02:13:55] <jepler> git push --dry-run
[02:13:57] <jepler> To git.linuxcnc.org:/git/emc2.git
[02:13:59] <jepler> then gitk a89e2ca..7b9c31f
[02:14:02] <jepler> a89e2ca..7b9c31f master -> master
[02:14:11] <jepler> that'll show all of the commits that would be pushed
[02:14:16] <seb_kuzminsky> nice
[02:16:43] <seb_kuzminsky> jepler: i just tried merging 2.4 into master, and it conflicted on JT's classicladder commits
[02:16:50] <seb_kuzminsky> just a heads up...
[02:17:34] <CIA-2> EMC: 03seb 07master * ra7914b238bcd 10/ (debian/rules.in src/Makefile): don't remote config.status on "make clean"
[02:17:39] <seb_kuzminsky> and rather than do the civic thing and fix it, i just cherrypicked the commit i care about... :-(
[02:17:52] <jepler> seb_kuzminsky: OK, I'll look into it
[02:18:11] <cradek> hey a commit from a new developer - John somebody or other
[02:18:42] <jmkasunich> seb_kuzminsky:ok, I've got a local branch. when I run gitk, I can't see my commit (since it is in master, and gitk is looking at 2.4)
[02:19:13] <jmkasunich> if I checkout master, then gitk sees my commit, and I can right-click and select cherry-pick, but it wants to reapply the change to master
[02:19:21] <jepler> "gitk master" while in v2.4_branch
[02:19:29] <jmkasunich> ah, thanks
[02:21:01] <jmkasunich> ok, more error messages
[02:21:15] <jmkasunich> and it seems that gitk errors can't be copy/pasted
[02:21:42] <jmkasunich> "finished one cherry-pick" <-- sounds good
[02:22:04] <jepler> yes, that is a success message
[02:22:13] <jmkasunich> "on branch v2.4_branch" "your branch is ahead of origin/v2.4_branch by 1 commit" <-- also promising
[02:23:00] <jmkasunich> "untracked files:" "share/desktop-directories/cnc.directory" "nothing added to commit but untracked files present (use git add to track)"
[02:23:10] <jmkasunich> "child process exited abnormally"
[02:23:20] <jmkasunich> ^^^ not so much of a success message
[02:23:23] <seb_kuzminsky> that untracked file should be git-ignored
[02:23:34] <seb_kuzminsky> but other than that it all sounds good
[02:23:46] <jmkasunich> even the "exited abnormally" part?
[02:24:02] <seb_kuzminsky> try "git push --dry-run" and "gitk $START..$END" like jeff suggested
[02:24:08] <seb_kuzminsky> well... abnormal is relative
[02:24:22] <jmkasunich> do you have any relatives that are abnormal?
[02:25:13] <jmkasunich> oh, go straight to push, without a commit? I guess cherry-pick already committed the change, that's why git diff didn't show anything...
[02:25:34] <jmkasunich> I expected cherry-pick to make the changes to the files
[02:25:47] <jepler> cherry-pick did everything, it even created the commit
[02:25:54] <seb_kuzminsky> yes, if there's no merge conflict cherry-pick commits
[02:25:58] <jmkasunich> the commit should come after I make sure the changes don't break the branch (in this case that isn't an issue...)
[02:26:04] <jepler> this is just a file created by build that should be listed in a gitignore but isn't: "share/desktop-directories/cnc.directory"
[02:26:29] <jmkasunich> so my tester hat is getting a good workout today ;-)
[02:27:38] <jmkasunich> jmkasunich@mahan:~/emcdev/emc2head$ git push --dry-run
[02:27:38] <jmkasunich> To ssh://jmkasunich@git.linuxcnc.org/git/emc2.git
[02:27:38] <jmkasunich> 68db5f7..c5c6c8a v2.4_branch -> v2.4_branch
[02:27:38] <jmkasunich> ! [rejected] master -> master (non-fast forward)
[02:27:38] <jmkasunich> error: failed to push some refs to 'ssh://jmkasunich@git.linuxcnc.org/git/emc2.git'
[02:27:53] <seb_kuzminsky> because i pushed something
[02:27:57] <seb_kuzminsky> git pull first
[02:28:09] <seb_kuzminsky> jepler: is now the time to tell jmkasunich about rebase?
[02:28:29] <seb_kuzminsky> jmkasunich: try git pull --rebase
[02:29:09] <jmkasunich> will do - I already tried a plain pull, didn't fix anything
[02:29:32] <jepler> jmkasunich: which version of git do you have? git --version
[02:29:35] <jmkasunich> nor did the rebase attempt
[02:29:42] <jmkasunich> 1.6.1.2
[02:30:30] <jepler> OK
[02:30:37] <jepler> this is a git annoyance that they fixed sometime after that version
[02:30:55] <jepler> it is trying to push *all* branches to origin by default, not just the branch you're on.
[02:32:12] <jepler> but you can't push "master", because there's a commit to master on git.linuxcnc.org that you don't have in your own history
[02:32:25] <jepler> you may want to specify what branch to push: git push --dry-run origin v2.4_branch
[02:32:54] <jepler> that'll skip trying to push master, which you don't want to push anyway
[02:33:49] <jmkasunich> I tried another approach: git checkout master, pull, git checkout v2.4_branch, git push --dry-run
[02:33:50] <jmkasunich> worked
[02:34:04] <jepler> yes, that'll work too
[02:34:15] <jepler> because then your master and git.linuxcnc.org's master will be the same
[02:34:27] <jmkasunich> your approach makes more sense tho
[02:34:43] <jepler> if you had a newer git, you could git 'config --global push.default current' and the thing I suggest would be the default
[02:34:51] <jmkasunich> there might be 5 branches with un-pulled changes, there is no reason for me to pull them all, I should just push the one branch I'm working on
[02:35:38] <jmkasunich> this git is the current rev for dapper, I think
[02:36:00] <jmkasunich> which means I won't have newer git until I have newer ubuntu (I don't feel like messing around with unpackaged versions, etc)
[02:36:38] <jepler> which ubuntu are you on? you can try these packages; I use them on a couple of my hardy systems
https://launchpad.net/~git-core/+archive/ppa
[02:36:41] <CIA-2> EMC: 03jmkasunich 07v2.4_branch * rc5c6c8a0655d 10/docs/INSTALL: configure isn't present on a fresh checkout, add info on how to generate it
[02:36:47] <jmkasunich> dapper
[02:37:39] <jmkasunich> personally, I'd just as soon stay with the dapper versions, and update the wiki with whatever quirks I find, so others on dapper won't suffer the same aggravations
[02:39:32] <jepler> you know dapper is officially not supported for 2.4 and beyond, right?
[02:39:55] <jepler> at the moment it still seems to work, and I even develop there sometimes, but in the long run...
[02:40:03] <jmkasunich> I was gonna ask about that, I remember hearing that dapper was going on end-of-life, but didn't recall exactly when
[02:40:16] <jepler> though if you put off switching until 10.04 gets usable then you win by avoiding one step on the upgrade treadmill
[02:40:38] <JT-Hardinge> * JT-Hardinge can't wait for 10.04 :)
[02:40:40] <jepler> it ended desktop support from ubuntu/canonical in 6/09 and as far as the emc project goes we have said we won't support it past 2.3.x.
[02:40:52] <jmkasunich> I just hope the shoptask computer doesn't have troubles with 10.04
[02:41:13] <jmkasunich> ubuntu is bloating almost as fast as windows - at least it seems that way at times
[02:41:50] <jmkasunich> I have plans to upgrade this computer too, but there are several steps in that process
[02:42:03] <jmkasunich> gotta move all the stuff that currently runs on it to my newest computer
[02:42:18] <jmkasunich> webserver, etc
[02:43:36] <jepler> yeah, I know how you feel -- and I more readily buy new PCs to run the new versions
[02:43:48] <JT-Hardinge> I had all kind of good upgrading plans for the Hardinge but they all went to hell in a hand basket
[02:44:00] <jmkasunich> right now I have two computers running constantly, which is just a waste of electricity
[02:44:28] <jmkasunich> this one, server, and the new one in the family room, media box
[02:44:58] <jmkasunich> I think I want to move the server stuff over to the media box, and only turn on this one when I need it
[02:52:00] <jmkasunich> jepler: seb's fix lets make clean work as expected, but there is still a minor time-bomb lurking
[02:52:32] <jmkasunich> line 205 of the makefile invokes configure with predefined args, you said earlier that it should probably error out and tell the user to invoke configure
[02:58:42] <jepler> yeah
[02:58:58] <jepler> I'll give that a whirl before I call it a night
[02:59:02] <jepler> one must respect the time change
[03:04:19] <seb_kuzminsky> mozmck!
[03:04:32] <mozmck> hey seb!
[03:07:52] <seb_kuzminsky> jepler: have you tried the RNG-but-no-ioport firmware after that fix?
[03:14:36] <jepler> seb_kuzminsky: no, I haven't.
[03:16:38] <seb_kuzminsky> what do you think about splitting our 14 MB of docs out to their own packages?
[03:17:00] <jepler> seb_kuzminsky: it prints out a bunch of these
[03:17:00] <jepler> [1391689.673688] hm2/hm2_5i20.0: hm2_set_pin_source: invalid pin number 0
[03:17:09] <jepler> but then succeeds and creates a lot of GPIO pins
[03:17:14] <seb_kuzminsky> hm, bummer
[03:17:38] <jepler> seb_kuzminsky: if it doesn't crash and leave hostmot2 not-unloadable then it's an improvement!
[03:17:48] <seb_kuzminsky> figures there was more hickups - that's a pretty pervasive assumption i made
[03:18:00] <seb_kuzminsky> an AnyIO board with no IO? who's heard of such a thing!
[03:19:49] <CIA-2> EMC: 03jepler 07v2.4_branch * r27653900f648 10/src/Makefile: don't auto-run configure with bogus arguments
[03:23:40] <CIA-2> EMC: 03jepler 07master * r898a45d23c1a 10/docs/src/ladder/classic_ladder.lyx: change double dash font to typewriter font
[03:23:41] <CIA-2> EMC: 03jepler 07master * ra242646d8b85 10/src/libnml/inifile/inifile.cc: Fix a bug when one tag is a prefix of another
[03:23:42] <CIA-2> EMC: 03jepler 07master * r68db5f71e65d 10/ (debian/rules.in src/Makefile): don't remote config.status on "make clean"
[03:23:43] <CIA-2> EMC: 03jepler 07master * rc5c6c8a0655d 10/docs/INSTALL: configure isn't present on a fresh checkout, add info on how to generate it
[03:23:44] <CIA-2> EMC: 03jepler 07master * r27653900f648 10/src/Makefile: don't auto-run configure with bogus arguments
[03:23:46] <CIA-2> EMC: 03jepler 07master * r3b6a928ec7dd 10/ (3 files in 3 dirs): Merge commit 'origin/v2.4_branch'
[03:35:08] <jmkasunich> jepler: I already pushed the INSTALL doc fix to both 2.4 and master, it looks like you did it again
[03:35:33] <jmkasunich> however, it also looks like git was smart enough to not add the new line twice
[03:36:52] <seb_kuzminsky> this is part of git's awesome sauce
[03:37:40] <jmkasunich> what? posting the same commit to the same branch is awesome? I agree that it is good that it didn't actually apply the patch twice, but it did post it twice on the list
[11:55:07] <jepler> jmkasunich: git represents history as a DAG, and a merge as a commit with two parents. That's why it's inevitable that the commit you made on v2.4_branch became part of the history of master when I merged it, even though a textually-identical change was already made on the other side of the merge.
[12:50:11] <jepler> huh. contrary to the age-old optimization advice I've never bothered to internalize, gcc generates the exact same code for both these functions:
[12:50:14] <jepler> void f() { for(int i=0; i<K; i++) e(); }
[12:50:17] <jepler> void g() { for(int i=0; i<K; ++i) e(); }
[12:55:22] <SWPadnos> what if i is passed to e?
[12:57:13] <jepler> they're still the same
[12:57:35] <SWPadnos> ok. I guess the gcc guys got smart then :)
[14:36:59] <jepler> here's my take on the paned/resizable program area:
http://emergent.unpy.net/files/sandbox/0001-make-the-program-text-resizeable.patch
[14:37:44] <cradek> that sure looks simple
[14:37:46] <cradek> does it work?
[14:37:53] <jepler> seems to here
[14:38:31] <jepler> I thought about saving the position to prefs, but I decided it was a bad idea.
[14:38:44] <jepler> position is saved basically by saving the height of the top area
[14:39:00] <alex_joni> so if you resize AXIS .. ?
[14:39:13] <jepler> if you maximized the window, then moved the sash to the bottom, then quit, then restarted, the sash would be at the very bottom, or maybe even offscreen
[14:39:29] <jepler> as I am still reluctant to make axis save/load its own geometry, I don't think I can save the sash position either
[14:39:59] <alex_joni> * alex_joni votes for the size it's always been
[14:40:14] <SWPadnos> you could check it for "sanity" - have a minimum of say 3 rows of text and 100 pixels for the preview or something
[14:40:16] <alex_joni> then the user can drag it to his best likings
[14:40:28] <jepler> alex_joni: yeah, and that's what it does now
[14:40:37] <alex_joni> does tk have those "smartish" panes where you can click on it to remove it completely?
[14:41:27] <jepler> alex_joni: no
[14:42:41] <alex_joni> too bad ;)
[14:43:52] <cradek> your patch does exactly what I wanted
[14:44:20] <cradek> it would be nice if it would keep the highlighted gcode line visible when resizing - is that easy?
[14:44:20] <jepler> that hardly ever happens
[14:44:36] <jepler> ugh
[14:44:40] <SWPadnos> heh
[14:45:03] <cradek> hmm, something goes weird about the entire window's resizability
[14:45:56] <cradek> enlarge window vertically - drag sash just a tiny bit - now try to reduce window vertically
[14:46:27] <jepler> are you talking about the "twitch"?
[14:47:13] <cradek> no - after you do what I describe, it won't let you reduce it vertically at all
[14:48:10] <jepler> (bizarre: the twitch goes away when I remove the menu from the widget; I notice the amount of the twitch seems to be about the height of the menu)
[14:48:25] <cradek> I didn't see any twitch
[14:48:39] <jepler> OK, I can get your behavior too
[14:49:38] <jepler> I get the twitch by trying to make the window shorter any time
[16:42:10] <jepler> cradek: try applying this change on top of the last one and see if it fixes the resizing problem you saw:
http://emergent.unpy.net/files/sandbox/0002-don-t-prevent-window-from-being-shrunk.patch
[17:47:48] <SWPadnos> hmmm. I guess today is the last day for discounted CNC workshop registration, isn't it?
[18:02:46] <mshaver> really? crap...
[18:03:24] <mshaver> all work & no money makes Matt a sad boy...
[18:03:54] <SWPadnos> heh
[18:04:31] <SWPadnos> I could forqard you this email I just got. It looks like FedEx is waiting to deliver $1.5 million to someone
[18:04:36] <SWPadnos> forward
[18:08:03] <mshaver> you? Great! Can I borrow the cnc workshop fee? I can pay you back around 2025...
[18:09:29] <cradek> has anyone figured out how to register?
[18:10:43] <SWPadnos> call the phone number in the post on bbs.somemachiningwebsite.com
[18:10:58] <cradek> whut
[18:10:59] <SWPadnos> http://bbs.homeshopmachinist.net/showthread.php?t=36635
[18:11:14] <SWPadnos> For reservations, please call Village Press at: 800-447-7367
[18:13:43] <cradek> ok but how do you really do it? that's obviously instructions for someone else
[18:14:35] <SWPadnos> ... because we expect to be able to do it online?
[18:16:29] <cradek> now I'm really faced with wanting to see and work with you guys vs. not really caring about any of the stuff at cnc workshop.
[18:16:47] <SWPadnos> heh. ambivalence seems to be common this year
[18:17:10] <SWPadnos> I'm having a hard time getting excited about it myself
[18:18:14] <skunkworks_> same here...
[18:19:15] <cradek> it'd be fun to hack on emc together like usual, but nothing about the venue attracts me - we could do it anywhere
[18:19:52] <mshaver> me too, but I'm looking forward to seeing you guys again.
[18:19:56] <SWPadnos> yeah, it kind of drives home the difference between EMC "Programmers fest" and EMC evangelism
[18:21:00] <mshaver> I think we can escape the need to constantly answer the question, "Whut ya' got there"? Maybe a room where we can close the door.
[18:22:26] <SWPadnos> I guess the really interesting part of CNC workshop was having access to a large machine to mess with, plus the fact that it was more of a get-together than a formal show
[18:22:52] <cradek> we can have that at stuart's (hell we can have that at my shop)
[18:22:59] <SWPadnos> this one will have vendors showing their stuff, which we might have available to mess with from time to time, and not much outside that
[18:23:09] <SWPadnos> at least that's my gut feeling about it this time
[18:23:18] <SWPadnos> yeah, Stuart's is a great place
[18:23:31] <SWPadnos> or my place. maybe I could finally get my machines converted :)
[18:30:19] <skunkworks_> hey - I have dibs.
[18:30:23] <skunkworks_> ;)
[18:36:54] <cradek> skunkworks's would be a very interesting project
[18:37:11] <SWPadnos> :P
[18:37:26] <cradek> possibly dual feedback, random toolchanger, maybe barcode tool scanning
[18:37:46] <SWPadnos> yeah yeah. I know another Bridgeport and another HNC aren't that exciting
[18:37:49] <cradek> locking/indexing rotary table
[18:37:59] <cradek> pallet change maybe?
[18:38:25] <cradek> seb and I could do your bridgeport in 11 hours - what would we do the rest of the week?
[18:38:44] <alex_joni> don't forget the puma for part loading/unloading
[18:39:07] <SWPadnos> there are nice restaurants here
[18:39:08] <cradek> don't forget that WI is about a zillion miles closer than ME
[18:39:10] <SWPadnos> and mountains
[18:39:20] <alex_joni> cradek: driving obviously
[18:39:21] <SWPadnos> ME is too far
[18:39:42] <cradek> are you in ME? I forget
[18:39:46] <SWPadnos> VT
[18:39:49] <cradek> ah
[18:39:55] <SWPadnos> a couple hundred miles shy of ME
[18:41:39] <alex_joni> well.. to be fair, VT is nearer than WI from here
[18:41:51] <SWPadnos> see! I knew it was a good idea
[18:42:11] <SWPadnos> oh yay. I can go pick up my new motherboards now
[18:42:34] <SWPadnos> it's kind of cool that a major internet supplier of embedded computers is like 5 miles from me
[18:42:34] <alex_joni> I think it's WY .. right?
[18:42:46] <alex_joni> SWPadnos: which one?
[18:42:51] <cradek> what's in WY?
[18:42:55] <SWPadnos> I don't think anyone lives in Wyoming
[18:43:16] <SWPadnos> http://www.logicsupply.com/
[18:43:16] <alex_joni> WI is wisconsin?
[18:43:26] <cradek> yes
[18:43:33] <alex_joni> oic
[18:44:03] <alex_joni> SWPadnos: cool stuff
[18:44:16] <SWPadnos> yep, nice folks too
[18:44:45] <SWPadnos> hmmm. it occurs to me that I was supposed to go there some time a few years ago and demonstrate to them how to do latency testing on their systems
[18:44:47] <alex_joni> humm.. decided seamonkey doesn't quite cut it for me :/
[18:45:49] <SWPadnos> bummer
[18:45:53] <SWPadnos> bbl
[18:46:02] <alex_joni> SWPadnos: yeah.. too bad
[18:46:11] <alex_joni> * alex_joni tries TB once more
[18:50:02] <cradek> alex_joni: you already use irssi, so one of these days you will come to your senses and use mutt
[18:50:16] <alex_joni> cradek: well.. if it were only me
[18:50:22] <cradek> BTW, TB is a disease
[18:50:32] <cradek> mostly eradicated in these modern times, though
[18:50:39] <alex_joni> maybe that's why I didn't like it :P
[18:51:20] <alex_joni> I meant thunderbird
[18:51:41] <alex_joni> cradek: I use alpine sometimes, and it's ok for ssh access to emails
[18:57:48] <cradek> so now that I've aired my laundry, wonder if I should try to use the telephone to sign up
[18:59:14] <cradek> jepler: I can't find anything weird after applying your second patch - looks neat
[18:59:43] <cradek> (although I'd still like the highlighted line to stay visible when I resize)
[19:02:27] <skunkworks_> so - does it seem cludgy to send a scaled commanded spindle speed to ladder - do the math - scale it back down within emc? (using ladder to pick the correct gear and sending back the spindle motor speed)
[19:03:39] <skunkworks_> I was excited for 2 seconds when I saw ladder took floats - but then read that it converted them to s32 ;)
[19:04:25] <skunkworks_> I can scale the spindle by 100000 - then the returned values should be more than acurate enough ;)
[19:10:37] <jepler> sure, why not?
[19:11:04] <skunkworks_> so if the commanded spindle speed is 200 - that is 6th gear with a ratio of .0901584. so I would send 20000000 to ladder - ladder would pick the 6th gear and divide it by 9016 and send back to emc the spindle motor rpm of 2218.
[19:13:22] <skunkworks_> cool
[20:14:43] <alex_joni> skunkworks_: nothing that works can be wrong
[20:16:20] <seb_kuzminsky> wait, was there closure on the cnc workshop question? Are we meeting at Chris's shop or Stuart's shop or what? Or both?
[20:20:08] <cradek> no, I guess I'm just stirring unrest
[20:20:16] <seb_kuzminsky> the only draw of the cnc workshop for is hanging out with y'all and hacking
[20:20:24] <cradek> me too
[20:20:42] <seb_kuzminsky> i could care less about how to install mach 3 on windows vista
[20:20:46] <cradek> I thought you couldn't make it anyway?
[20:21:12] <seb_kuzminsky> things just changed here - the big camping trip got pushed back a week because a bunch of other folks couldnt make it that week
[20:21:17] <seb_kuzminsky> so now i'm free to go :-)
[20:21:35] <seb_kuzminsky> but if i'm gonna go i want to buy the cheaper registration today
[20:21:37] <cradek> well that's pretty cool
[20:21:50] <seb_kuzminsky> i guess their schedule conflict was more important than mine ;-)
[20:22:40] <seb_kuzminsky> actually there's another draw in ann arbor - that's where smithy is and i think it'd be neat to see their place
[20:22:54] <cradek> I'd like to see dale's tech shop place
[20:27:35] <cradek> yeah I guess I want to go
[20:29:00] <seb_kuzminsky> sounds like the biggest emc2 crowd planned so far this year
[20:30:32] <cradek> yeah I think so
[20:34:58] <seb_kuzminsky> i just called & signed up, i asked about a discount for the emc2 group but the lady said there wasn't one...
[20:36:38] <cradek> I'm still uncomfortable and unsure how this "telephone" thing works - can you talk me through it?
[20:36:46] <cradek> for example, what URL do I use to start?
[20:37:09] <seb_kuzminsky> it's pots://800.477.7367
[20:37:39] <cradek> uh-oh, I must be missing a plugin or something
[20:37:52] <seb_kuzminsky> try it in skype instead of firefox
[20:38:18] <seb_kuzminsky> the real challenging interface comes after the connection's set up
[20:39:30] <seb_kuzminsky> hey look at that, a maker faire in ann arbor just before the cnc workshop
[20:39:37] <seb_kuzminsky> http://blog.makezine.com/archive/2010/03/ann_arbor_mini_maker_faire_request.html
[20:40:12] <seb_kuzminsky> see you guys there
[20:40:13] <seb_kuzminsky> bbl
[20:50:35] <cradek> I signed up, too
[20:50:49] <cradek> I agree about the challenging interface comment
[20:52:34] <jepler> me three
[20:52:46] <jepler> worst on-hold music I've heard in awhile
[20:54:01] <cradek> ha, you had to wait while she was figuring out that my zip code wasn't in PA
[22:02:19] <ries_> ries_ is now known as ries