EMC: 03jthornton 07master * r0dfaff951502 10/docs/src/ladder/ (images/extra-pulse-reject.png ladder_examples.lyx): add example of rejecting extra pulses in ladder
[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.
EMC: 03jthornton 07master * re3cfb40af183 10/docs/src/motion/pid_theory.lyx: add a bit more info on Ziegler Nichols method
jthornton: looks like install/installing_emc2.lyx and install/compiling_emc2 are in need of some love ..
LOL ok thanks for spotting that
I was trying to figure out what directions Ian might have found that were diffent from the wiki instructions
jepler: is this page current?
[13:17:38] <jthornton> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Installing_EMC2
except that 2.4 will be for 10.something right?
let me scan it real quick
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.
ah I bet Ian found '2.4. Pre-requisites for Ubuntu 9.10'
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
so './configure' gives you a RIP system, and it takes './configure --prefix=...' to get a run-installed system
but 2.3 is different
jepler, have you seen this: http://www.myhdl.org/doku.php
SWPadnos: it rings a bell, but I never actually tried to use it
it was mentioned in the opencores.org newsletter I just got
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
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?
bbl, heading to the office
EMC: 03alex_joni 07master * r3c212db3ba0b 10/src/emc/kinematics/ (genserkins.c genserkins.h): fix a bug spotted by seb
EMC: 03alex_joni 07master * rcf8ea0c40742 10/docs/src/motion/pid_theory.lyx: Merge branch 'master' of ssh://email@example.com/git/emc2
jepler: that is kinda what I was thinking say as little as possible about non standard installs and point them to the wiki site
EMC: 03jthornton 07master * r867adafe91b9 10/docs/src/hal/pyvcp.lyx: remove note about 6.06
EMC: 03jthornton 07master * r3a298b80d58c 10/docs/src/gui/axis.lyx: clear up Axis typical procedures
jthornton: as always thanks for working on that stuff
zEOF in file:/usr/local/jepler/src/emc2/nc_files/fuh.ngc seeking o-word: o<q> from line: -2147483632
hi, I've updated emc ru.po, where should I send it?
aystarik: email it to the developers list as a patch (git format-patch)
thanks for working on it!
ups... too big, will be held, bla-bla-bla...
does "list moderator review" of long messages happen or should I send somehow else?
strangely it hasn't notified me yet
argh, some days I hate the sf mailing lists.
if you like you can mail it directly to me (firstname.lastname@example.org) instead.
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
or at any rate, something post-6.06 which is all I have hady
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
is emc-environment present on installed versions?
so that test could be added to the runscript, couldn't it
the emc script already has the "doesn't need emc-environment" exception
the latency-test script did not, but needs it to work from a .desktop file
I didn't think that the runscript would source emc-environment - is that what you said?
maybe I don't know what you mean when you say "runscript"
the script named "emc"
you're already allowed to run "emc" without ". emc-environment" first; that has been the case for a very long time
but it doesn't work well on RIP versions, especially where there's an installed version as well
(last I knew)
it seems that people still need to source emc-environment manually
can you point me at a description of the problem?
the situation you describe is intended to work properly
uh. there isn't a problem. this would be an improvement IMO
ok, maybe it does now
argh, we're talking past each other.
maybe I've misunderstood the patch to latency-test
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
yes, I think you accurately described the change
(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)
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
just because scripts/emc doesn't . emc-environment, you shouldn't infer that it requires it.
it seems to eliminate some problems with the wrong modules getting loaded
and that kind of thing
out of curiosity, in what circumstances would you suggest not sourcing emc-environment in a RIP?
(I can't think of any, unless I'm testing how RIP interacts with installed ...)
I suggest that when using a terminal you should always . emc-environment
I agree, as that reduces confusion when e.g. you run emc in one terminal, and halcmd in another
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
and now I am taking advantage of that exemption to make .desktop files that work for RIP
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
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
I don't remember clearly whether that's the solution any more though :)
emc-environment exports EMC2_HOME EMC2VERSION EMC2_EMCSH PATH LD_LIBRARY_PATH MANPATH
on further inspection of the emc script, it appears it may not export LD_LIBRARY_PATH
so you may be right and the script needs fixed
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
bbl, it's lunchtime here
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-01-27.txt
emc2-buildmaster: remember to copy the debs to the archive this time, kthx
SWPadnos: I never run the source for just launching emc from rip
usually I have a terminal for compiling running, and another one for interacting
do you have an installed version as well?
on the other terminal where I need to interact using halcmd I use the source
cause it's more convenient to type halcmd instead of bin/halcmd
but it would work nonetheless
I don't remember the exact circumstances where it seems necessary. it could be when people are writing new comp modules or the like
and it may be necessary for comp, not emc itself
actually it's necessary for people who aren't versate with many emc2 versions
if you do the source, surely no bad things can happen ;)
if you don't, you're on your own
(at least that's how I remember it.. ;)
heh. could be
if I write addf parport.0.read base-thread 1
and the n addf parport.1.read base-thread 1
what will be order of execution?
parport.1 then parport.0
I think 'halcmd show funct' will show the order
parport.1 will be inserted as the first item in the thread (I believe it's 1-based, not 0-based)
in halcmd order of function is meaning something?
yes, that does show the order of execution
yes I think it prints them in order
are there could be other numbers instead of -2 -1 and 1?
imo that could be helpfull to order execution
hm, man halcmd doesn't show this syntax
halcmd help addf should
when you specify a number, the function gets put in that position in the execution order
true it does
using negative numbers start from the end
so "addf blahblah servo-thread -2" would put blahblah second from the end
I think -3 isn't accepted
not unless there are already 3 items in the thread (possibly)
oh I see
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/
cool.. never got qemu that usable ;)
when there's a commit, the buildbot builds & tests, and if all the tests pass it makes debs & uploads them to its deb archive
separate deb components for sim & rt, since the source packages collide otherwise
only hardy-i386 for now
once the runtests are fixed from the tlo merge, the buildbot will start building packages for us :-)
oh hm, I bet they're afu because of the tool tables
my poor vm server is getting all overloaded, the non-realtime hardy-i386 host is running super slow
yeah rs274 (the sai) doesn't parse the new tool table at all
so lame that this code is in two places :-(
yeah that's a bummer
oh oh, the sim packages are done!
ding! something smells burned in here
yay the sim packages work too :-)
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
currently it's "the version number from the changelog, followed by the output from git-describe"
so we're subject to the vagaries of tag names
maybe number from changelog + unix time?
so that it's at least sorted?
changelog+unixtime+output from git-describe
or time time of the commit we're building
it's already pretty long...
time of the commit by itself should be enough maybe
if the tag were the same as the version from the changelog, it would look nice, something like 2.4.0~pre-761-g1234abcd
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
seb_kuzminsky: did you fix the tests? I don't see a commit...
no, i rebuilt an old commit from before the tlo merge
the package name should be obvious
they will be sorted anyway, won't they?
they will be sorted, but maybe not the way we want...
does the previous one disappear when there is a new one?
oh right - when the tag changes, it'll mess up
currently it keeps all the debs around, and you can select which version you want to install
i'm going to add a cronjob to remove packages older than a month or so
I recommend "remove all but the last N" instead
with N pretty small, like 3 or less
otherwise you may remove all of them, or remove not enough
is there a log of the packages that have been built?
"keep N most recent" is better
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
not really what you wanter...
it's probably not necessary actually, since the person can get the git revision with dpkg
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
the git revision is also in the changelog that the package installs (/usr/share/doc/emc2/changelog)
oh, right, "send me the output of dpkg -s emc2"
something like that
the version number contains the git-describe, which identifies the commit it was built from