Back
[00:00:32] <fenn> hm forgot classicladder
[00:00:37] <fenn> 396
[00:00:50] <alex_joni> hmm.. this is odd, some are double in the /var/lib/dpkg/status
[00:04:22] <alex_joni> fenn: build a package, install it, and see if apt breaks
[00:04:26] <cradek> what's wrong?
[00:04:44] <alex_joni> cradek: I get too many config files in the emc2 package, which breaks apt
[00:05:04] <cradek> huh
[00:05:25] <alex_joni> it seems apt only handles 32k of tagfiles (whatever those are)
[00:05:43] <alex_joni> our configfiles + MD5SUMs are bigger than 32k for TRUNK
[00:06:26] <cradek> by how much?
[00:06:31] <alex_joni> 20k
[00:06:35] <cradek> ouch
[00:06:47] <alex_joni> I'm rebuilding TRUNK atm, to make sure
[00:06:49] <cradek> some of those configs are crap, but I doubt half are
[00:07:00] <alex_joni> somehow things end up twice in the list I got
[00:07:36] <alex_joni> cradek:
http://pastebin.ca/1337495
[00:08:06] <jmkasunich> last summer I added configs/vismach with a few in it
[00:08:42] <alex_joni> jmkasunich: it's 697 vs. 286
[00:08:55] <alex_joni> but 697 does sound like a bogus number
[00:09:06] <jmkasunich> I know my additions didn't cause the problem, but they contributed to it
[00:09:49] <alex_joni> it's not a big issue to move things to /usr/share/emc2/sample-configs/
[00:17:26] <alex_joni> oh, this isn't helpfull.. when an older config doesn't exist in the new package, it gets added to the list of configs, but marked obsolete
[00:18:29] <jmkasunich> I think I just found a bug in the docs
[00:18:46] <alex_joni> juve@dapper-vm:~$ less emc2_2.3.0~alpha1.configlist | wc -l
[00:18:46] <alex_joni> 405
[00:18:52] <jmkasunich> manual for parport says: The address for a PCI card is usally shown in “lspci -v” in an “I/O ports” line, or in the kernel message log after executing “sudo modprobe -a parport_pc”.
[00:19:26] <jmkasunich> but we've got parport_pc aliased or replaced or something, with "/bin/true"
[00:19:40] <alex_joni> yup, that won't ever work
[00:20:00] <alex_joni> but insmod /path/to/parport_pc would
[00:21:48] <jmk-robot> hmm, I have three parport_pc modules, for three of the four installed kernels - but not for the rtaismp kernel
[00:22:11] <alex_joni> http://eneas.juve.ro/~juve/emc/emc2_2.3.0~alpha1.configlist <- grep "emc2/sample-configs" from /var/lib/dpkg/status after installing emc2-2.3.0~alpha1 (RT version)
[00:22:52] <alex_joni> jmk-robot: probably didn't mark the module as M when building that kernel ;)
[00:23:17] <jmk-robot> joy
[00:23:26] <alex_joni> reboot might be fastest
[00:23:27] <jmk-robot> lspci doesn't provide enlightenment
[00:23:47] <alex_joni> not even lspci -vv ?
[00:23:49] <alex_joni> pastebin it
[00:25:54] <jmk-robot> http://pastebin.ca/1337552
[00:27:56] <alex_joni> try sudo lspci -vv
[00:28:15] <alex_joni> but I don't see a PCI parport board
[00:29:34] <jmk-robot> it is an onboard parport
[00:29:42] <alex_joni> then you won't find it with lspci
[00:29:51] <alex_joni> 02:17 < jmkasunich> manual for parport says: The address for a PCI card is usally shown
[00:30:22] <jmk-robot> I assumed (incorrectly I guess) that the onboard I/O was on the PCI bus
[00:30:48] <alex_joni> try BIOS, or the obvious 0x378, 0x278, 0x3bc
[00:31:33] <alex_joni> it is.. but it's inside one of the big chips
[00:31:46] <alex_joni> maybe hostbridge, not sure
[00:32:55] <alex_joni> aha.. it's part of 00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01)
[00:33:11] <alex_joni> "The LPC Bridge provides a data and control path to the Super I/O (the normal attachment for the keyboard, mouse, parallel port, serial port, IR port, and floppy controller)"
[00:34:31] <jmk-robot> which doesn't list any I/O regions
[00:34:53] <alex_joni> yup .. "nice" isn't it..
[00:35:17] <jmk-robot> I found mention of the parport in lshal, but no addresses
[00:35:39] <alex_joni> tried one of the default values?
[00:35:51] <alex_joni> along with hal_parport
[00:35:57] <jmk-robot> doing that now
[00:36:21] <alex_joni> I don't think I've seen a machine that doesn't use 0x378 in the last 2 years
[00:36:32] <jmk-robot> 0x0378 worked
[00:36:44] <alex_joni> you're beeing too thorough :P
[00:36:53] <alex_joni> http://eneas.juve.ro/~juve/emc/emc2-sim_2.3.0~alpha1_i386.configlist <- from the emc2-sim package
[00:37:00] <jmk-robot> I actually tried hal_parport with no cfg string first - I thought it used to default to 0x0378
[00:37:12] <jmk-robot> the manual says there is no default now
[00:37:34] <alex_joni> which manual?
[00:37:41] <alex_joni> mobo? emc2?
[00:37:43] <jmk-robot> emc2 manual, parport section
[00:37:58] <alex_joni> * alex_joni looks towards BigJohnT
[00:38:24] <jmk-robot> I thought 'loadrt hal_parport' was the same as 'loadrt hal_parport cfg="0x378" '
[00:38:51] <jmk-robot> so when I tried hal_parport by itself and it didn't work, I started looking for the address elsewhere
[00:39:03] <alex_joni> ah.. right
[00:39:08] <jmk-robot> I think the manual is correct - it says you have to specify an address
[00:39:13] <alex_joni> "There is no default address; if <config-string> does not contain at least one address, it is an error."
[00:39:30] <alex_joni> can I hijack the conversation back to configs ?
[00:39:30] <jmk-robot> its unfortunate that such errors are invisible
[00:39:35] <jmk-robot> sure
[00:39:46] <jmk-robot> I'm the hijacker, sorry
[00:39:48] <alex_joni> it seems the config list is around 31-32k
[00:40:00] <alex_joni> (for both emc2 and emc2-sim built from TRUNK)
[00:40:27] <alex_joni> we can probably squeeze that to work, by removing some cruft/unused examples from the configs
[00:40:35] <alex_joni> but I don't think it's a long-run solution
[00:40:38] <jmk-robot> yeah, but we'll be on the edge
[00:40:43] <alex_joni> yes
[00:41:17] <alex_joni> for example configs/classicladder/cl-estop/*
[00:41:31] <alex_joni> that's a folder that isn't going to be understood by the config picker
[00:41:44] <jmk-robot> too deep?
[00:41:48] <alex_joni> yup
[00:42:19] <alex_joni> and the config is generated by stepconf, not really usefull imo
[00:42:31] <jmk-robot> I'm afraid I was too busy with robot stuff to pay much attention to the problem
[00:43:01] <alex_joni> then there's demo-sim-cl and demo-step-cl and so on
[00:43:02] <jmk-robot> the base issue is that apt and dpkg treat all the sample configs as "configuration data" for the package, and they can't handle that much data
[00:43:07] <jmk-robot> right?
[00:43:11] <alex_joni> dpkg can
[00:43:13] <alex_joni> apt can't
[00:43:26] <alex_joni> but for regular users dpkg is not existing
[00:43:33] <jmk-robot> ok
[00:43:44] <alex_joni> they will only see that once they installed an emc2 package nothing else will ever work again
[00:43:51] <alex_joni> no more updates, no synaptics, etc
[00:43:56] <jmk-robot> something tells me that other packages don't deliver a large number of sample configs
[00:44:05] <jepler> I'm back
[00:44:07] <alex_joni> not this large ;)
[00:44:14] <jepler> etc is not for "sample configurations" it's for actual configurations
[00:44:20] <jmk-robot> thats where I was going
[00:44:24] <jepler> we put the files in the wrong place according to the debian way of doing things
[00:45:15] <alex_joni> jepler: I think we're fine for 2.2.x though
[00:45:32] <jepler> by the skin of our teeth
[00:45:45] <alex_joni> about 10k
[00:45:53] <alex_joni> 22k vs. 33k
[00:46:42] <alex_joni> ok, so the idea is to move the sample configs from /etc/emc2/sample-configs to somewhere else
[00:46:58] <alex_joni> that can be /usr/share/emc/sample-configs
[00:47:07] <alex_joni> or /usr/share/emc2/sample-configs
[00:47:11] <alex_joni> or ..
[00:47:13] <jepler> right. under /usr/share/emc (a directory our package already creates) or under /usr/share/docs/emc2 (another directory our package already creates) seem like two likely places
[00:47:41] <jmk-robot> the docs one seems like a better choice to me
[00:47:56] <jepler> many packages put example in /usr/share/doc/<packagename>/examples
[00:47:59] <alex_joni> think users go there more often?
[00:48:13] <jepler> users drool on pickconfig
[00:48:28] <jmk-robot> if pickconfig can find them users will be happy
[00:48:37] <alex_joni> well, it will ;)
[01:05:10] <jmkasunich> arrrrrgh
[01:05:19] <jmkasunich> slip of the meter probe and another blown fuse
[01:05:42] <jmkasunich> I need a fuseholder (the fuse is currently soldered in, and buried inside)
[01:18:07] <alex_joni> argh
[01:18:33] <alex_joni> putting configs in /usr/share/doc/emc2/sample-configs causes some of the textfile to get compressed with gzip by default
[01:30:45] <jepler> alex_joni: comment out dh_compress in debian/rules
[01:34:48] <alex_joni> I added the relevant exceptions
[01:34:55] <alex_joni> (for example odg's can be compressed)
[01:35:36] <alex_joni> pdf, txt, hal, ini, clp, var, nml, tbl, xml
[01:40:17] <jepler> that works too
[01:41:56] <alex_joni> it seems to build ok, and run from the built package
[01:42:01] <alex_joni> testing run-in-place noce
[01:42:03] <alex_joni> now
[01:44:49] <alex_joni> ok, RIP works too
[01:44:57] <alex_joni> jepler: want me to commit this?
[01:51:24] <alex_joni> guess we can always revert ;)
[01:51:39] <CIA-2> EMC: 03alex_joni 07TRUNK * 10emc2/debian/ (emc2.files.in rules.in): move install location for the sample-configs from /etc/emc2/sample-configs to /usr/share/doc/emc2/sample-configs - should be transparent for the regular user, fixes a problem with apt (too many config files break apt)
[01:51:40] <CIA-2> EMC: 03alex_joni 07TRUNK * 10emc2/src/ (Makefile configure configure.in): move install location for the sample-configs from /etc/emc2/sample-configs to /usr/share/doc/emc2/sample-configs - should be transparent for the regular user, fixes a problem with apt (too many config files break apt)
[01:56:59] <jepler> alex_joni: I'm getting good at reverting :-P
[01:57:21] <jepler> but really, thanks for learning about the problem and then working on it
[01:58:21] <jepler> cradek: should I file an sf item about the "cutter comp not turned off after error" behavior?
[03:00:48] <cradek> um, I haven't been watching
[03:01:07] <cradek> I don't think ngc says what state the interp is in after an error
[03:01:47] <cradek> also I haven't figured out the system for erroring - seems like some errors cause an abort and no AXIS preview, some show the aborted preview
[03:01:58] <cradek> I bet this is related to that difference
[03:15:44] <jepler> cradek: cradek this was along the lines of "after one bad run, emc says 'can't change units in cutter comp mode -- oh well, I guess I have to restart emc"
[03:15:51] <jepler> (I think it's one of those things that m2 fixes)
[03:16:17] <jepler> it's sure a gotcha, though if m2 fixes it, all you have to do is teach each user of comp to remember to do it every time
[03:17:00] <SWPadnos> how much state is available for troubleshooting after an error, which would be destroyed by automatically doing M2 after an error?
[03:17:33] <SWPadnos> (ie, is there a downside to just doing all the stuff you do for M2 when an erorr occurs)
[03:27:43] <cradek> currently you get an error displayed but the machine keeps going, and when it gets to the error spot, it simply stops, leaving everything unchanged
[03:28:08] <cradek> I'm pretty sure other (?) kinds of errors cause an abort when the bogus line is interpreted
[03:28:41] <SWPadnos> hmmm. I guess some things like offsets might get unapplied with M2, which could make you wonder where the machine thought it was
[03:28:49] <cradek> I'd prefer that abort behavior for emc's interpreter, but the run-blissfully-on-as-long-as-possible for AXIS's interpreter
[03:29:15] <SWPadnos> oh - I didn't read back too far, so I probably don't understand the problem
[03:30:14] <cradek> maybe jepler is talking about 2.2, since you CAN change units with comp on
[03:31:44] <cradek> making the sample config files NOT apt "config" files might bite us
[03:32:09] <cradek> if a user changes a sample config and runs it from there, apt will now overwrite his changes without asking
[03:32:33] <SWPadnos> don't users have to work to be able to write to those files?
[03:32:52] <cradek> users are surprisingly resourceful when screwing stuff up
[03:32:57] <SWPadnos> well, that is truw
[03:32:59] <cradek> but, yeah
[03:33:00] <SWPadnos> e
[03:34:59] <jmk-robot> does feature freeze mean I can't commit a new hal comp?
[03:35:23] <cradek> what is it?
[03:35:50] <jmk-robot> it takes a 2D vector (pins x-in and y-in) and rotates it by some angle, to give x-out and y-out
[03:37:04] <cradek> jepler gets to make the final decision but I bet it would be ok if you want it to be in 2.3
[03:37:16] <SWPadnos> does it also take an offset as input? (so you can rotate about a point that's not the origin)
[03:37:17] <cradek> "gets to"
[03:37:23] <SWPadnos> heh
[03:37:27] <SWPadnos> s/gets/has/ ;)
[03:37:38] <jmk-robot> SWPadnos: no
[03:37:53] <jmk-robot> you can always subtract using sum blocks
[03:38:03] <fenn> affine-transformation.comp
[03:38:09] <SWPadnos> he
[03:38:11] <SWPadnos> h
[03:38:17] <cradek> I think alex is already testing packaging - this probably would affect his tests a bit.
[03:38:37] <jmk-robot> I can just do it on this box and not commit it
[03:39:02] <jmk-robot> committing is mostly for my convenience - makes it easy to get the comp onto any other box
[03:39:16] <jmk-robot> but I really shouldn't need to do that anyway
[03:39:18] <cradek> maybe you should do it after the 2.3 branch then
[03:39:36] <jmk-robot> ok
[04:23:57] <seb_kuzminsky> i use local branches all the time to move not-ready-to-share software between machines (a couple of VMs and a couple of real machines)
[04:30:02] <jmkasunich> does cvs have local branches?
[04:30:37] <SWPadnos> yes, if you don't commit ;)
[04:32:27] <jmk-robot> but if you don't commit, you can't fetch it from another system
[04:32:50] <SWPadnos> "local" implies to me that you don't transfer it to the repo
[04:33:26] <SWPadnos> SVN is a bit different from CVS in that it appears to have all the branches locally
[04:33:43] <SWPadnos> there's a pivot command of some sort that lets you change to a particular revision locally
[04:37:06] <seb_kuzminsky> cvs and svn don't have local branches; i use bzr
[04:38:08] <seb_kuzminsky> git and hg (and others) also have local branches
[04:38:45] <SWPadnos> I guess with SVN you'd also have to not commit
[04:39:00] <SWPadnos> can't you create a branch and then "stash" it though?
[04:39:35] <seb_kuzminsky> in svn anyone with commit access can make new branches (svn cp trunk branches/my-branch)
[04:39:47] <seb_kuzminsky> but to share it to another computer you have to upload it to the central repo
[04:40:19] <SWPadnos> right
[04:40:21] <seb_kuzminsky> this is pretty quick with svn, a cp is like a copy-on-write symlink
[04:40:54] <SWPadnos> I thought there was also some support for swapping between branches (locally)
[04:41:08] <SWPadnos> I guess cd../other-branch might do it ;)
[04:41:23] <seb_kuzminsky> that's it
[04:42:39] <seb_kuzminsky> git has a notion of "switching" which branch is "visible" in a checkout
[04:42:48] <seb_kuzminsky> strikes me as a bit weird
[04:43:03] <SWPadnos> that's also where "stash" comes from
[04:43:27] <SWPadnos> work on stuff, then stash those changes away so you can look at some other stuff on the unmodified branch
[04:43:36] <SWPadnos> then get the stashed stuff back later
[04:46:11] <seb_kuzminsky> bzr calls that "shelve"
[04:46:20] <SWPadnos> ah
[04:46:53] <seb_kuzminsky> there's also "loom", which is even cooler... the stashed patches-in-progress stack on each other, and you can move up and down the patch stack, modifying patches as you go
[04:47:00] <seb_kuzminsky> with full commit/log/diff/revert on each patch
[04:47:11] <SWPadnos> cool
[04:47:25] <SWPadnos> the bzr equivalent(or superset) of quilt?
[04:47:29] <seb_kuzminsky> right
[04:47:47] <seb_kuzminsky> built into the revision control system, instead of on top of it
[04:47:52] <SWPadnos> cool
[04:47:59] <seb_kuzminsky> it's more like mercurial 'queues' in that way, than quilt
[04:48:23] <SWPadnos> damn. the gas height adjuster on my chair seems to be stuck in the "adjust" Position
[04:48:35] <SWPadnos> so I sink to the bottom all the time, a kind of hard stop
[04:49:01] <seb_kuzminsky> retrofit with ballscrew, preloaded ballnuts, and servo
[04:49:08] <SWPadnos> hmmm
[04:49:12] <seb_kuzminsky> you know you want to
[04:49:16] <SWPadnos> considering that it's still under warrantee, I may pass ;)
[04:49:22] <seb_kuzminsky> heh
[05:13:10] <jmk-robot> I'm very confused - PID is being weird
[05:13:29] <jmk-robot> it seems like the sign of error is inverted
[05:14:15] <SWPadnos> getting positive feedback?
[05:14:20] <jmk-robot> yeah
[05:14:24] <SWPadnos> weird
[05:14:36] <jmk-robot> (right now I just have the default gains: P = 1, others = 0
[05:16:01] <SWPadnos> you're not using at_pid are you?
[05:16:11] <SWPadnos> (not that I see anything in it)
[05:16:37] <jmk-robot> no
[05:16:41] <jmk-robot> I think I found the problem
[05:16:47] <SWPadnos> ah
[05:16:47] <jmk-robot> bkac
[05:17:12] <jmk-robot> I'm summing the output of two PIDs - one to steer, one to control speed
[05:17:24] <SWPadnos> heh
[05:17:24] <jmk-robot> I forgot about the 2nd one, and had the summer gains set wrong
[05:17:34] <SWPadnos> phew!
[05:17:47] <SWPadnos> I figured ssomeone would have noticed 100% runaways by now
[10:40:48] <alex_joni> cradek: the other choice would have been to keep configs in /etc/emc2/ and really be carefull what to include there (strip half of the stuff from emc2/configs)
[10:41:07] <alex_joni> I don't think that's a better idea than biting users who mess around where they shouldn't
[10:41:28] <alex_joni> we'll put a big warning in the manual, and that should be it
[14:06:40] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/drivers/hostmot2.lyx: add more info
[14:18:07] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gui/axis.lyx: some clean up
[14:24:56] <jepler> are the mailing lists broken, or is there a problem on my end? The last I have from any emc list is over 12 hours ago, [Emc-commit] TRUNK emc2/src Makefile, 1.281, 1.282 configure, 1.153, 1.154 configure.in, 1.156, 1.157
[14:29:15] <jepler> oh hey -- I ask, they arrive
[14:33:12] <BigJohnT> it's magic
[15:20:12] <BigJohnT> rut row, test this axis is broken in 2.3
http://imagebin.ca/view/aNT3Nr.html
[15:20:23] <BigJohnT> stepconf wizard
[15:22:16] <jepler> BigJohnT: I won't have a chance to look into that for a week, so please file it on sf so it's not forgotten
[15:22:49] <BigJohnT> ok will do
[15:22:58] <BigJohnT> have a good trip
[15:23:26] <jepler> thanks, I plan to
[16:29:40] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/config/images/ (5 files): update images
[17:19:05] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/config/ (5 files): some clean up and image updates
[17:24:34] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/install/installing_emc2.lyx: some minor clean up
[17:29:30] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/drivers/hostmot2.lyx: more updates
[17:31:09] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/common/Linux_FAQ.lyx: clean up layout
[18:20:13] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/drivers/hostmot2.lyx: more info added
[19:56:03] <BigJohnT_> BigJohnT_ is now known as BigJohnT
[20:37:34] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/drivers/hostmot2.lyx: a few more edits
[20:59:34] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/config/images/ (4 files): move images
[21:47:06] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/config/ (6 files): moved to images directory
[21:57:43] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/config/ini_config.lyx: minor edit