found an annoynance, not sure if its a bug
halscope invokes sysrem("halcmd loadrt scope_rt") to load its RT part (if not already loaded)
I'm running in place, but the system call is invoking /usr/bin/halmcd, not emc2/bin/halcmd
/usr/bin/halcmd is looking in /usr/rtlib for the RT part of scope, but its actually in emc2/rtlib
run in place is important and very usefull, but tricky
jmkasunich: In scripts/emc, PATH is set, so it's correct to use a bare "halcmd". If halscope is intended to be invoked other than from scripts/emc it should be changed to use something it gets from config.h or Makefile
I wrote the "halcmd loadrt" so I'll look at fixing it
er, 'I wrote *that" "halcmd loadrt"'
halscope is a general purpose utility, it is intended to be invoked without emc
jmkasunich: you checked in a change to scope_files.c earlier?
something's weird. I dropped Chris a note. That file is now dated in the future.
-rw-r--r-- 1 jepler jepler 16992 2006-04-05 00:46 scope_files.c
I think that might happen if the clock on the CVS server is not set right
looks like UTC
yeah, its 01:22 UTC now, I did the commit about 40 mins ago
yeah, but that timestamp is displayed in my local (US Central) time, making it hours in the future.
I bet its timezone related tho
wowee it sure is fast having the CVS server in my house
on the system call thing
although halscope can be used outside of emc, it can't be used unless you've run "scripts/realtime start"
dunno if that might help, perhaps the realtime script can set a path?
I don't think that will help -- If you run a program from the shell, that program can't change the shell's PATH. It can only change its own PATH.
I can make halscope use the full path to halcmd though
compile it in?
kinda yucky, but...
well we do it in other places (halcmd has a full path to emc_module_helper for many of the same reasons)
there are only two choices: require the user to set the PATH when starting something *not* through scripts/emc, or encode the full path
the second is doable, and it will help under some circumstances
encode the full path works for me
before you dive into that...
the server is in your basement after all, can you go down there and to "time" and see what it says?
I don't have a regular shell login .. but maybe the messge is shown on the console.
the timestamp shown on a log message would be correct if it's GMT but I suspect it's showing local (US Central) time---confirming it's a wrong clock on that machine.
something for cradek to fix
I wonder how hard we're hitting your connection?
(I'm starting to bring the compile farm back up, three checkouts (emc, rcslib, and emc2) on each of 4 boxes
oh it'll probably hurt for a little while
use a high -z number when checking out, -z5 or higher
Here's my traffic graph: http://unpy.net/mrtg/dsl.html
IMO it shows a bit more traffic than usual, but nothing that will affect my normal usage or my other websites
I was using z3, I'll do z5 for the rest
I think that with the slow connection (40KB/s) the higher -z numbers will really help, and I think even a fairly old system can compress 40KB/s of data with gzip.
I put that poorly but maybe you understand what I mean
fast line, slow cpu, use lo or no z, slow line and fast cpu, use hi z
whats it mean when a filename is bracked with # in the dir listing? #Hal_Introduction.lyx#
I know foo~ means its a backup
is #foo# a unix convention, or something lyx must have done?
Different programs have different conventions for their backup files
for example, CVS sometimes creates backup files of the pattern .#*#
Maybe lyx creates the kind of backup file you just spotted.
jmkasunich: done with the checkouts on the "farm" yet?
did slot 2 first, now I'm getting all the loose ends tied up
when its working I'll do the other 3
(I'm also moving the results to Dreamhost, and other twiddling)
do you think theres any benefit to using -z on a routine cvs up?
(the farm does cvs up on three trees once per hour)
yeah, I think it will still give a benefit
yay, I got an email out of it, now I just have to put in the contents I want
I just realized I have some stuff still in SF cvs
I stuck the farm scripts into the old emc2_hal module
do you want a new module?
I did not copy over those modules I thought were dead
I'm glad you didn't
I dunno if the farm is worthy of such a thing, but otoh, perhaps a combination of farm, and other various admin stuff is worth keeping in cvs
call the module misc perhaps, farm stuff goes in misc/farm_scripts
ok I'll get to it in a bit
maybe later we have misc/server_setup with notes about setting up the server, and any custom config files that are needed, etc
or maybe that goes on the wiki
that reminds me, I should change my pseudo-farm to use the new cvs
any scripts or other code that is used by the server should be in cvs, far easier to extract than from the wiki
code, sure. notes? wiki might be a better choice, depending on the exact situation.
it looks like cvs.linuxcnc.org is working correctly
out of curiosity, has anyone tried compiling / running emc on a non-x86 CPU?
doubt it (at least not emc2)
the original emc (long long ago) was run on sparcs and stuff
without realtime of course
I saw a nice looking 400MHz PPC board today, and the devel kit comes with Linux/RTAI
the only thing missing in the *very* cool case I saw was a parallel port, but I think there are digital I/Os internal to the unit
jepler: I managed to put a couple spikes on your load graph
all done now
do you think it would be good to move the mailing lists over to DreamHost?
we haven't really had too many problems with the lists
compile farm results are now being sent to Dreamhost
cool - that's working OK?
slot 2 is done, slots 3,4,5 are crunching away
yep, they're checking out of the new cvs and sending results to the new website
one of these days I want to do something to reduce the latency
some commit-message-based thing would be good
and possibly send results to either the commit list or CIA
or even a UDP thing from the CVS server, since Chris controls that
its gonna be hard for the cvs server to "push" anything at the farm
the farm is behind a NAT firewall
even if I did port forwarding, it would go to a single slot
is it aqn embedded box, or a Linux box?
not if it were different ports
(there are actually 2)
a linksys box at the border of the house
and a linux box (farm slot) serving the farm's subnet
(overkill, I know, but at the Smithy fest, the farm router routed (and served DHCP) for our entire fest net
I already set up port forwarding thru both routers for ports 22 and 80, so that eventually a farm slot can become a backup cvs server if needed
well, you may be able to have a rule that distributes certain packets to all farm slots
shame there isn't a "last commit was at XX:XX" field on the cvsweb page
I could wget it every 10 mins or so and check the field
initiate a farm run if it changes
cradek: you there?
perhaps I should have said: cradek: you mind a distraction?
you said a while back that you got it to send a message
is that by a script inside the chroot jail? outside the jail?
it's inside, but it sends the mail to the outside sendmail
I had a strange idea of having the script modify that two line "homepage"
sockets don't get chrooted, right?
but that lives outside the jail
I could wget that two line page every 10 mins without causing much load
jmkasunich: that would be easy
actually, even better than modifying the index.html page would be writing a completely different one
no modify needed, just do something like "date >last_commit.txt"
with last_commit.txt in the same dir as index.html, so I can fetch it with wget cvs.linux.org/last_commit.txt"
that's easy, don't let me forget to do it
how often should I remind you?
* jmkasunich sets up a cron job ;-)
once a day until it's done
well, I found out how to put the makefiles into an infinite loop
give one source file a date in the future
see you guys later
Apr 4 22:51:23 cvs sm-mta: k353pIfr027391: to=<firstname.lastname@example.org>, delay=00:00:04, xdelay=00:00:04, mailer=esmtp, pri=30628, relay=externalmx-1.sourceforge.net. [220.127.116.11], dsn=4.3.0, stat=Deferred: 451-could not connect to cvs.linuxcnc.org [18.104.22.168]: Connection refused
well, I have commit emails working, but sf is being clever and refusing them for some unclear reason
are you subscribed to the commit list?
no, but that should put it into the queue that admins can allow
this is deferring the message itself
it must be an anti-spam thing
ISTR some anti spam stuff that SF does
there is a challenge response thing
oh do you know about it?
I have some notes from when they were fighting with my ISP
let me look for them
it would be great if you could find that for me
basically it boils down to they won't accept mail from anyone they can't send mail back to
so if you don't have something on that box to accept incoming mail, you are gonna have problems
alex_jon1 is now known as alex_joni
cradek: If necessary I'll reconfigure my mail machine so that it will accept messges from cvs.linuxcnc.org for lists.sourceforge.net.
but that restriction seems like a stupid one.
jmkasunich: Different 'make' versions behave differently with files from the future. make 3.80 (ubuntu) notes that a file is from the future, but finishes.
jepler_: either that, or let the smtp port through, it's up to you
I think that bald.unpythonic.net will already act as a relay for you, because you're in my internal subnet.
try that first.
jepler_ is now known as jepler
skunkworks_wrk is now known as SkunkWorks
cradek: think you can add udiff in the commit message?
alex_joni: probably, but there are some concerns, and I want to do cia first
ok, no problem
it's just that I got used to reading diffs while away from my devel box
alex_joni: trimming diffs that are too long, and binary files
alex_joni: don't you have a web browser? there's a link to the diff
cradek: that depends, sometimes (very rarely I have e-mail access only)
but I noticed the links, and will use those
alex_joni: I think I'd like the diffs there too, I will get to it a little later
ok, no hurry