Back
[02:44:39] <CIA-2> EMC: 03jthornton 07master * r0dfaff951502 10/docs/src/ladder/ (images/extra-pulse-reject.png ladder_examples.lyx): add example of rejecting extra pulses in ladder
[12:11:59] <christel> [Global Notice] Hi all, In preparation for the weekend's ircd migration we will need to take some servers out of production for upgrades, I am about to do a spot of rehubbing to continue the upgrades now. This may raise the number of splits for the next day, more information as and when will be available via wallops. Thank you for using freenode and have a great day.
[12:26:54] <CIA-2> EMC: 03jthornton 07master * re3cfb40af183 10/docs/src/motion/pid_theory.lyx: add a bit more info on Ziegler Nichols method
[13:09:52] <jepler> jthornton: looks like install/installing_emc2.lyx and install/compiling_emc2 are in need of some love ..
[13:10:43] <jthornton> LOL ok thanks for spotting that
[13:14:04] <jepler> I was trying to figure out what directions Ian might have found that were diffent from the wiki instructions
[13:17:35] <jthornton> jepler: is this page current?
[13:17:38] <jthornton> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Installing_EMC2
[13:19:19] <jthornton> except that 2.4 will be for 10.something right?
[13:19:29] <jepler> let me scan it real quick
[13:19:34] <jthornton> ok
[13:22:19] <jepler> still reading .. I tried to reword a bit at the end of 2.1.1 because then you have to go on 2.1.2 but I'm not sure how best to say it.
[13:23:40] <jepler> ah I bet Ian found '2.4. Pre-requisites for Ubuntu 9.10'
[13:27:33] <jepler> well, one difference I can't put on that page yet is that when talking about 2.4 only the --enable-run-in-place switch is now implied by default
[13:27:50] <jepler> so './configure' gives you a RIP system, and it takes './configure --prefix=...' to get a run-installed system
[13:27:59] <jepler> but 2.3 is different
[13:28:21] <SWPadnos> jepler, have you seen this:
http://www.myhdl.org/doku.php
[13:28:46] <jepler> SWPadnos: it rings a bell, but I never actually tried to use it
[13:28:52] <SWPadnos> ok
[13:29:04] <SWPadnos> it was mentioned in the opencores.org newsletter I just got
[13:32:28] <jepler> jthornton: most of what that page says for generalities and for ubuntu systems looks right to me. I can't evaluate the stuff it says about other systems, and there's a lot of stuff that you can skip if you are only talking about 2.4
[13:33:15] <jepler> jthornton: maybe you can find a way find a way to say as little as possible in the .lyx docs and toss in a link to the wiki which will generally be more up to date?
[13:33:28] <jepler> bbl, heading to the office
[13:50:05] <CIA-2> EMC: 03alex_joni 07master * r3c212db3ba0b 10/src/emc/kinematics/ (genserkins.c genserkins.h): fix a bug spotted by seb
[13:50:06] <CIA-2> EMC: 03alex_joni 07master * rcf8ea0c40742 10/docs/src/motion/pid_theory.lyx: Merge branch 'master' of ssh://alex_joni@git.linuxcnc.org/git/emc2
[13:52:10] <jthornton> jepler: that is kinda what I was thinking say as little as possible about non standard installs and point them to the wiki site
[14:08:47] <CIA-2> EMC: 03jthornton 07master * r867adafe91b9 10/docs/src/hal/pyvcp.lyx: remove note about 6.06
[14:08:57] <CIA-2> EMC: 03jthornton 07master * r3a298b80d58c 10/docs/src/gui/axis.lyx: clear up Axis typical procedures
[14:15:12] <jepler> jthornton: as always thanks for working on that stuff
[14:18:54] <jepler> zEOF in file:/usr/local/jepler/src/emc2/nc_files/fuh.ngc seeking o-word: o<q> from line: -2147483632
[14:19:07] <jepler> s/^z//
[15:33:14] <aystarik> hi, I've updated emc ru.po, where should I send it?
[15:33:58] <jepler> aystarik: email it to the developers list as a patch (git format-patch)
[15:38:19] <aystarik> jepler: done
[15:38:39] <cradek> thanks for working on it!
[15:39:07] <aystarik> ups... too big, will be held, bla-bla-bla...
[15:52:11] <aystarik> does "list moderator review" of long messages happen or should I send somehow else?
[15:58:00] <cradek> strangely it hasn't notified me yet
[16:35:31] <jepler> argh, some days I hate the sf mailing lists.
[16:35:45] <jepler> if you like you can mail it directly to me (jepler@unpythonic.net) instead.
[17:37:22] <jepler> can I get someone to test this (preferably on 8.04):
http://emergent.unpy.net/files/sandbox/0001-make-install-menus-puts-RIP-in-the-Applications-menu.patch
[17:40:51] <jepler> or at any rate, something post-6.06 which is all I have hady
[17:40:52] <jepler> handy
[18:03:07] <jepler> oh, and you need this to make latency-test RIP work from the menu:
http://emergent.unpy.net/files/sandbox/0001-make-latency-test-run-without-emc-environment.patch
[18:05:19] <SWPadnos> is emc-environment present on installed versions?
[18:05:25] <jepler> no
[18:05:39] <SWPadnos> so that test could be added to the runscript, couldn't it
[18:06:02] <jepler> the emc script already has the "doesn't need emc-environment" exception
[18:06:14] <jepler> the latency-test script did not, but needs it to work from a .desktop file
[18:06:15] <SWPadnos> ?
[18:06:47] <SWPadnos> I didn't think that the runscript would source emc-environment - is that what you said?
[18:06:56] <jepler> maybe I don't know what you mean when you say "runscript"
[18:07:04] <SWPadnos> the script named "emc"
[18:07:34] <jepler> you're already allowed to run "emc" without ". emc-environment" first; that has been the case for a very long time
[18:08:03] <SWPadnos> but it doesn't work well on RIP versions, especially where there's an installed version as well
[18:08:07] <SWPadnos> (last I knew)
[18:08:27] <SWPadnos> it seems that people still need to source emc-environment manually
[18:08:52] <jepler> can you point me at a description of the problem?
[18:09:09] <jepler> the situation you describe is intended to work properly
[18:09:12] <SWPadnos> uh. there isn't a problem. this would be an improvement IMO
[18:09:19] <SWPadnos> ok, maybe it does now
[18:09:23] <jepler> argh, we're talking past each other.
[18:09:41] <SWPadnos> maybe I've misunderstood the patch to latency-test
[18:10:19] <SWPadnos> my understanding is that it checks to see if there's an emc-environment script that "goes with" the executed latency test, and sources it if there's no EMC2_HOME variable set
[18:10:37] <jepler> yes, I think you accurately described the change
[18:10:41] <SWPadnos> ok
[18:11:12] <jepler> (there would be EMC2_HOME if the user already did a . emc-environment; that's a way to avoid the warning that emc-environment prints when you source it more than once)
[18:11:55] <SWPadnos> as far as I know, the emc script, when run from within a RIP directory, requires the user to have previously sourced emc-environment to prevent issues with installed emc2 versions
[18:12:44] <jepler> just because scripts/emc doesn't . emc-environment, you shouldn't infer that it requires it.
[18:13:10] <SWPadnos> it seems to eliminate some problems with the wrong modules getting loaded
[18:13:15] <SWPadnos> and that kind of thing
[18:14:08] <SWPadnos> out of curiosity, in what circumstances would you suggest not sourcing emc-environment in a RIP?
[18:14:30] <SWPadnos> (I can't think of any, unless I'm testing how RIP interacts with installed ...)
[18:14:33] <jepler> I suggest that when using a terminal you should always . emc-environment
[18:15:07] <SWPadnos> I agree, as that reduces confusion when e.g. you run emc in one terminal, and halcmd in another
[18:15:35] <jepler> but, if only in my mind, scripts/emc has always been exempt from this rule, the reason being that before I introduced emc-environment it wasn't required for RIP before running emc
[18:15:54] <jepler> and now I am taking advantage of that exemption to make .desktop files that work for RIP
[18:16:06] <jepler> and that's why if you believe it doesn't work I want to hear how to reproduce the problem so I can fix it
[18:16:48] <SWPadnos> ok. I don't have specifics, but I do recall helping tom3p (I think) recently, and I still suggest emc-environment before doing anything else
[18:16:57] <SWPadnos> I don't remember clearly whether that's the solution any more though :)
[18:17:15] <jepler> emc-environment exports EMC2_HOME EMC2VERSION EMC2_EMCSH PATH LD_LIBRARY_PATH MANPATH
[18:17:28] <jepler> on further inspection of the emc script, it appears it may not export LD_LIBRARY_PATH
[18:17:40] <jepler> so you may be right and the script needs fixed
[18:18:30] <SWPadnos> ah, ok. that would explain it, since the question I'm usually answering is why there's some shmem ID conflict, or some (new) module can't be found
[18:20:47] <jepler> bbl, it's lunchtime here
[19:07:01] <skunkworks_> logger_dev: bookmark
[19:07:01] <skunkworks_> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-01-27.txt
[20:10:48] <seb_kuzminsky> emc2-buildmaster: remember to copy the debs to the archive this time, kthx
[20:17:41] <alex_joni> SWPadnos: I never run the source for just launching emc from rip
[20:17:56] <alex_joni> usually I have a terminal for compiling running, and another one for interacting
[20:18:00] <alex_joni> cd src
[20:18:01] <alex_joni> make
[20:18:05] <alex_joni> ../scripts/emc
[20:18:19] <SWPadnos> do you have an installed version as well?
[20:18:24] <alex_joni> sure
[20:18:50] <alex_joni> on the other terminal where I need to interact using halcmd I use the source
[20:19:02] <alex_joni> cause it's more convenient to type halcmd instead of bin/halcmd
[20:19:11] <alex_joni> but it would work nonetheless
[20:19:15] <SWPadnos> ok
[20:20:01] <SWPadnos> I don't remember the exact circumstances where it seems necessary. it could be when people are writing new comp modules or the like
[20:20:11] <SWPadnos> and it may be necessary for comp, not emc itself
[20:20:51] <alex_joni> actually it's necessary for people who aren't versate with many emc2 versions
[20:20:59] <alex_joni> if you do the source, surely no bad things can happen ;)
[20:21:08] <alex_joni> if you don't, you're on your own
[20:21:16] <alex_joni> (at least that's how I remember it.. ;)
[20:21:47] <SWPadnos> heh. could be
[20:52:02] <micges> if I write addf parport.0.read base-thread 1
[20:52:11] <micges> and the n addf parport.1.read base-thread 1
[20:52:30] <micges> what will be order of execution?
[20:52:44] <SWPadnos> parport.1 then parport.0
[20:52:50] <cradek> I think 'halcmd show funct' will show the order
[20:53:06] <SWPadnos> parport.1 will be inserted as the first item in the thread (I believe it's 1-based, not 0-based)
[20:53:27] <micges> in halcmd order of function is meaning something?
[20:53:37] <SWPadnos> yes, that does show the order of execution
[20:53:39] <cradek> yes I think it prints them in order
[20:53:50] <micges> thanks
[20:54:56] <micges> are there could be other numbers instead of -2 -1 and 1?
[20:55:58] <micges> imo that could be helpfull to order execution
[20:56:07] <SWPadnos> yes
[20:56:09] <cradek> hm, man halcmd doesn't show this syntax
[20:56:15] <SWPadnos> hmmm
[20:56:20] <SWPadnos> halcmd help addf should
[20:56:34] <SWPadnos> when you specify a number, the function gets put in that position in the execution order
[20:56:40] <cradek> true it does
[20:56:43] <SWPadnos> using negative numbers start from the end
[20:57:11] <SWPadnos> so "addf blahblah servo-thread -2" would put blahblah second from the end
[20:57:11] <micges> I think -3 isn't accepted
[20:57:27] <SWPadnos> not unless there are already 3 items in the thread (possibly)
[20:57:55] <micges> oh I see
[20:58:18] <micges> thanks again guys
[21:56:28] <seb_kuzminsky> http://imagebin.ca/view/8G8SzQ.html
[21:56:35] <seb_kuzminsky> http://emc2-buildbot.colorado.edu/~buildmaster/
[21:56:59] <alex_joni> cool.. never got qemu that usable ;)
[21:57:10] <seb_kuzminsky> when there's a commit, the buildbot builds & tests, and if all the tests pass it makes debs & uploads them to its deb archive
[21:57:28] <seb_kuzminsky> separate deb components for sim & rt, since the source packages collide otherwise
[21:57:32] <seb_kuzminsky> only hardy-i386 for now
[21:57:41] <cradek> seb_kuzminsky: wow...
[21:58:12] <alex_joni> cool stuff
[21:58:55] <seb_kuzminsky> once the runtests are fixed from the tlo merge, the buildbot will start building packages for us :-)
[22:00:59] <cradek> oh hm, I bet they're afu because of the tool tables
[22:03:15] <seb_kuzminsky> my poor vm server is getting all overloaded, the non-realtime hardy-i386 host is running super slow
[22:09:51] <cradek> yeah rs274 (the sai) doesn't parse the new tool table at all
[22:10:03] <cradek> so lame that this code is in two places :-(
[22:13:04] <seb_kuzminsky> yeah that's a bummer
[22:15:54] <cradek> bbl
[22:26:49] <seb_kuzminsky> oh oh, the sim packages are done!
[22:27:52] <alex_joni> ding! something smells burned in here
[22:34:06] <seb_kuzminsky> yay the sim packages work too :-)
[22:39:10] <seb_kuzminsky> the versions of the buildbot-built packages will be all messed up until we come up with a better way to set the version numbers
[22:39:29] <seb_kuzminsky> currently it's "the version number from the changelog, followed by the output from git-describe"
[22:39:54] <seb_kuzminsky> so we're subject to the vagaries of tag names
[22:40:20] <alex_joni> maybe number from changelog + unix time?
[22:40:28] <alex_joni> so that it's at least sorted?
[22:40:34] <seb_kuzminsky> yeah
[22:40:50] <alex_joni> changelog+unixtime+output from git-describe
[22:40:57] <seb_kuzminsky> or time time of the commit we're building
[22:41:01] <seb_kuzminsky> it's already pretty long...
[22:41:15] <alex_joni> time of the commit by itself should be enough maybe
[22:41:24] <seb_kuzminsky> emc2_2.4.0~pre+cvs-import-761-g61325cb_i386.deb
[22:41:41] <alex_joni> yuck
[22:42:25] <seb_kuzminsky> if the tag were the same as the version from the changelog, it would look nice, something like 2.4.0~pre-761-g1234abcd
[22:44:55] <alex_joni> seb_kuzminsky: btw, here's the scripts I used for hardy repos
http://git.linuxcnc.org/gitweb?p=infrastructure.git;a=tree;f=repositories/hardy;hb=HEAD
[23:03:29] <cradek> seb_kuzminsky: did you fix the tests? I don't see a commit...
[23:04:42] <seb_kuzminsky> no, i rebuilt an old commit from before the tlo merge
[23:05:26] <alex_joni> the package name should be obvious
[23:05:28] <alex_joni> ROFL
[23:06:18] <cradek> they will be sorted anyway, won't they?
[23:06:33] <seb_kuzminsky> they will be sorted, but maybe not the way we want...
[23:06:33] <cradek> does the previous one disappear when there is a new one?
[23:06:49] <cradek> oh right - when the tag changes, it'll mess up
[23:06:50] <seb_kuzminsky> currently it keeps all the debs around, and you can select which version you want to install
[23:07:07] <seb_kuzminsky> i'm going to add a cronjob to remove packages older than a month or so
[23:10:30] <cradek> I recommend "remove all but the last N" instead
[23:10:49] <SWPadnos> with N pretty small, like 3 or less
[23:10:50] <cradek> otherwise you may remove all of them, or remove not enough
[23:11:36] <SWPadnos> is there a log of the packages that have been built?
[23:19:07] <seb_kuzminsky> "keep N most recent" is better
[23:19:40] <seb_kuzminsky> SWPadnos: not really, but here's a restricted waterfall showing just the deb builders:
http://emc2-buildbot.colorado.edu/buildbot/waterfall?branch=&builder=deb-hardy-sim-binary-i386&builder=deb-hardy-rt-binary-i386
[23:20:09] <seb_kuzminsky> not really what you wanter...
[23:20:35] <SWPadnos> it's probably not necessary actually, since the person can get the git revision with dpkg
[23:21:12] <SWPadnos> I was thinking about making sure that a developer can get an identical (ish) version of emc if there's a problem, even if the packages have been cleaned off the web
[23:21:20] <seb_kuzminsky> the git revision is also in the changelog that the package installs (/usr/share/doc/emc2/changelog)
[23:21:37] <seb_kuzminsky> oh, right, "send me the output of dpkg -s emc2"
[23:22:09] <SWPadnos> something like that
[23:22:11] <seb_kuzminsky> the version number contains the git-describe, which identifies the commit it was built from
[23:47:29] <seb_kuzminsky> later