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