Back
[01:40:02] <SWPadnos> hiya jmk
[01:40:20] <jmkasunich> hi
[01:41:02] <jmkasunich> * jmkasunich is tired
[01:41:07] <jmkasunich> TGIF
[01:41:12] <SWPadnos> still got the cold?
[01:41:16] <jmkasunich> recovering
[01:41:33] <jmkasunich> I stayed at work until after 8 today
[01:41:37] <SWPadnos> that generally sucks
[01:41:40] <jmkasunich> (not working per se tho)
[01:41:40] <SWPadnos> bummer
[01:41:57] <jmkasunich> national engineers week is coming up, and the company has some competitions
[01:42:10] <jmkasunich> they are actually fun, but we spend long hours building stuff
[01:42:21] <SWPadnos> ah - I remember all the E-Week stuff
[01:42:34] <SWPadnos> egg drops, rube goldberg competitions, etc.
[01:42:48] <jmkasunich> we're building a machine to "go bowling"
[01:42:56] <SWPadnos> uh-oh ;)
[01:43:09] <jmkasunich> there will be a ball and a bunch of pins set up in the lobby (about a 30' x 60' area)
[01:43:22] <jmkasunich> we need to grab the ball and knock down the pins
[01:43:38] <jmkasunich> to make it interesting, the pins that are worth the most points aren't on the floor
[01:43:48] <SWPadnos> do you have to release the ball?
[01:43:51] <jmkasunich> no
[01:43:54] <SWPadnos> heh
[01:44:11] <SWPadnos> pins on tables / chairs / mantles?
[01:44:14] <jmkasunich> one pin (worth 30 points) will be on a 16" high pedestal
[01:44:30] <SWPadnos> does it count if you destroy the pedestal?
[01:44:39] <jmkasunich> 10 at 2 pts each will be in the traditional triangle setup on a 4" hi platform
[01:44:53] <jmkasunich> pedestal is a pretty sturdy stack of cinderblocks
[01:44:54] <SWPadnos> I think a cannon is the best bet ;)
[01:45:06] <SWPadnos> as long as the ball can handle it
[01:45:11] <jmkasunich> no explosives, flame, or fuels allowed
[01:45:19] <SWPadnos> high pressure gas?
[01:45:27] <jmkasunich> inert or air
[01:45:35] <jmkasunich> an additional twist
[01:45:40] <SWPadnos> compressor to push the ball, rubber seal that'll give way when the pressure is high enough
[01:45:43] <jmkasunich> the pedestal is on the far side of the lobby
[01:45:47] <SWPadnos> of course
[01:45:53] <jmkasunich> ball (and start line) on the near side
[01:45:56] <SWPadnos> and you have to aim
[01:46:04] <SWPadnos> presumably they can move one or the other
[01:46:06] <jmkasunich> between the two is a low wall (which we're not allowed to go over)
[01:46:16] <jmkasunich> with an 18" wide x 15" high tunnel in it
[01:46:23] <SWPadnos> that does put a wrinkle into my plans
[01:46:43] <jmkasunich> so we have to fit thru a 15" high hole, then knock a pin of a 16" high pedestal
[01:47:05] <SWPadnos> does the ball get to break apart?
[01:47:11] <jmkasunich> the rule is that you don't have to actually hit the pin(s) with the ball
[01:47:12] <jmkasunich> no
[01:47:23] <SWPadnos> as long as they fall - that's good
[01:47:38] <SWPadnos> is this a bowling ball, or a baseball?
[01:47:40] <jmkasunich> but you must be carrying the ball if you wish to use part of your vehicle to knock pins
[01:47:44] <jmkasunich> bowling
[01:47:46] <jmkasunich> 12 lbs
[01:47:48] <SWPadnos> ok
[01:47:59] <SWPadnos> oh - you get to ride it - that's nice
[01:48:05] <jmkasunich> the easy way is to push the ball around
[01:48:12] <SWPadnos> as long as you're less than 15" tall ;)
[01:48:32] <jmkasunich> there are 10 pins at 1 pt in the usual setup about 10 feet in front of the initial ball position, those are easy
[01:48:55] <jmkasunich> 8 more (4 on each side of the wall, far apart) worth 3 points, also on the floor, so easy for someone who is just pushing the ball
[01:49:00] <jmkasunich> the rest are harder
[01:49:15] <jmkasunich> 10 on a 4" high platform (with a ramp)
[01:49:17] <SWPadnos> sounds fun
[01:49:22] <jmkasunich> and 1 on the 16" pedestal
[01:49:44] <jmkasunich> should be
[01:49:58] <jmkasunich> we are going with the "2 wheels and a caster" method
[01:50:09] <jmkasunich> we have the wheel/motor part built up
[01:50:12] <jmkasunich> working on the chassis
[01:50:17] <jmkasunich> then the part to capture the ball
[01:50:40] <jmkasunich> and finally a long "tail" that we can lower for the tunnel and raise to knock things off the pedestal
[01:51:01] <SWPadnos> scorpion-bot
[01:51:05] <jmkasunich> we're allowed to use wired remote control
[01:51:28] <SWPadnos> ok, so not a lot of spinning around or going around things
[01:51:28] <jmkasunich> I'm so tempted to put a laptop running HAL on the vehicle tho
[01:51:32] <SWPadnos> yep
[01:51:43] <SWPadnos> ethernet and remote X for a wired remote ;)
[01:52:00] <jmkasunich> we're gonna have a 6-8 foot cord, we can walk around behind it, just not allowed to touch it
[01:52:06] <SWPadnos> ah
[01:52:34] <jmkasunich> if I could pull off the laptop thing I'd want to use wireless ethernet ;-)
[01:52:39] <SWPadnos> in that case, a small monitor and a game controller (like the Nostromo - a USB keypad for the most part)
[01:53:22] <jmkasunich> thing is my beater laptop (my only laptop) doesn't even have ethernet, let along all the other new fangled stuff
[01:53:34] <jmkasunich> s/along/alone/
[01:53:42] <SWPadnos> bummer
[01:53:59] <jmkasunich> were probably gonna use an analog PWM generator
[01:54:07] <jmkasunich> I built up one for last years event
[01:54:22] <jmkasunich> that was RC controlled - they gave us a little RC car to work with
[01:54:29] <jmkasunich> really underpowered for the contest
[01:54:52] <SWPadnos> just a joystick and analog PWM
[01:54:59] <jmkasunich> so we gutted it, kept the radio, and took the signals from the radio, massaged them into PWM to drive two motors and made a more powerfull vehicle
[01:55:15] <jmkasunich> this year we're gonna reuse the power stage and part of the PWM generator
[01:55:27] <jmkasunich> replace the RC car interface with pots/joystick
[01:55:50] <jmkasunich> what really makes me want to use the PC is that the motors we're using have encoders on them
[01:56:03] <SWPadnos> G-Rex
[01:56:14] <jmkasunich> they came from an old tape library that I dumpster picked
[01:56:21] <jmkasunich> 64ppr encoders
[01:56:29] <SWPadnos> do you still have the tape drives? :)
[01:56:30] <jmkasunich> and 45:1 worm gears to drive the wheels
[01:56:34] <SWPadnos> damn
[01:56:41] <jmkasunich> tore the tape drives apart
[01:56:46] <SWPadnos> that'll get you some torque
[01:56:55] <SWPadnos> bummer
[01:57:00] <jmkasunich> the motors are small, 2" long x 1.4" dia
[01:57:09] <jmkasunich> why? who wants SCSI tape drives?
[01:57:13] <SWPadnos> me
[01:57:18] <SWPadnos> high capacity though
[01:57:34] <jmkasunich> I dunno exactly what kind these were
[01:57:36] <SWPadnos> I'm still trying to get my old dual Pentium Pro to work as a server
[01:57:41] <jmkasunich> there were two drives in each box
[01:57:57] <SWPadnos> I have a tape drive (off eBay) - 50/100G AIT-2
[01:57:58] <jmkasunich> size of a full height 5-1/4 disk drive
[01:58:06] <SWPadnos> an - DLT probably
[01:58:16] <SWPadnos> or 8MM
[01:58:16] <jmkasunich> the tape cartridge apparently only has one reel
[01:58:21] <SWPadnos> those were pretty huge
[01:58:35] <SWPadnos> feeds into the center as it pulls off the outside?
[01:58:52] <jmkasunich> it grabs the tape and winds it onto an internal reel (pulling it past the head) then when done winds it back into the cartridge
[01:59:01] <SWPadnos> ah, strange
[01:59:23] <jmkasunich> two reel motors, one mates to the cartridges reel, the other is connected to the internal reel
[01:59:47] <jmkasunich> no capstan drive, there is an idler roller with a high cpr encoer that is used to measure tape speed
[02:00:03] <jmkasunich> I'm guessing late 90's technology
[02:00:12] <jmkasunich> I wanted it for the tape handling stuff
[02:00:19] <SWPadnos> that must be a PITA To get the thing threaded onto the inner reel each time (unless there's a nub or bobbin on the tape)
[02:00:33] <jmkasunich> all automagic
[02:00:41] <SWPadnos> "magnetic" ;)
[02:01:12] <jmkasunich> there is a leader-ish thing inside the drive that apparently connects to a hole or something on the end of the tape
[02:02:18] <SWPadnos> ok - a hole in the tape and a hook (retractable) on the spindle wouldd o it
[02:02:26] <jmkasunich> not on the spindle
[02:02:52] <jmkasunich> there is a 12" or so long piece of thin steel (feeler gage thin, 0.002 or so) that acts as a leader
[02:03:09] <jmkasunich> that is attached to the spindle at one end, and is prethreaded thru the head mechanism
[02:03:18] <SWPadnos> ok - also as a tape protector, I imagine
[02:03:26] <jmkasunich> the other end sits where the cartridge is gonna go, and somehow hooks the end of the tape
[02:03:39] <jmkasunich> (I suspect there is a leader of some sort in the cartridge too)
[02:06:09] <jmkasunich> IF they were a drive type you could have used, and IF I knew, I would have saved them
[02:06:19] <jmkasunich> I really wanted the rest of the tape handling stuff
[02:06:19] <SWPadnos> heh - thanks
[02:06:28] <SWPadnos> if I had known, I would have asked earlier ;)
[02:06:35] <jmkasunich> there were two main units (two tape drives each) and one adder unit
[02:06:45] <jmkasunich> the main units held about 10 cartriges, the adder about 15
[02:06:55] <SWPadnos> cool. some of the libraries are pretty cool, robotically speaking
[02:07:07] <jmkasunich> there were screws and motors and all kinda stuff to move tapes from storage to drive and back
[02:07:12] <SWPadnos> the ADIC upright TB or more libraries really get moving
[02:07:14] <SWPadnos> yep
[02:07:27] <jmkasunich> the expander even had an elevator to take tapes up to the main unit mounted above it in the rack
[02:07:33] <jmkasunich> I got 10 of those little servo motors
[02:07:48] <SWPadnos> yep. have you seen the automated pill dispensers at some pharmacies?
[02:08:02] <SWPadnos> they're pretty similar to the libraries
[02:08:07] <jmkasunich> three 20"+ long, high pitch/multi-start screws and nuts, three worm gears and worms, etc
[02:08:14] <jmkasunich> nope
[02:08:16] <SWPadnos> cool
[02:08:32] <jmkasunich> bunch of little timing belt pulleys and stuff
[02:08:55] <jmkasunich> I collect stuff like that even tho I'll probably only use 2% of it
[02:09:03] <jmkasunich> its a disease
[02:09:42] <jmkasunich> I just scrounged a PC today
[02:09:51] <jmkasunich> dual P3 667MHz
[02:10:17] <jmkasunich> rambus memory - talk about a dead end, that never did take off did it?
[02:14:19] <SWPadnos> not really
[02:14:40] <jmkasunich> the box I grabbed was at one time a high end developers workstation
[02:14:44] <jmkasunich> HP Kayak system
[02:14:45] <SWPadnos> that's better than my dual PPro-overdrive-333
[02:15:03] <SWPadnos> with a whopping 256M (some of which seems to not be working at the moment)
[02:15:18] <SWPadnos> and the dead CMOS battery - you remember the old VARTA blue cylindrical batteries?
[02:15:27] <jmkasunich> ohh, old
[02:15:30] <SWPadnos> heh
[02:15:48] <SWPadnos> yep - it has an i960 chip on it, and 8 PCI slots
[02:16:01] <jmkasunich> what was the 960 for?
[02:16:10] <SWPadnos> IO processor
[02:16:12] <jmkasunich> I've seen them in RAID controllers
[02:16:25] <SWPadnos> yep - this has I2O on the motherboard
[02:16:35] <SWPadnos> another technology that didn't really go anywhere
[02:17:09] <jmkasunich> heh... the "mundane" machines in the dumpster are all pretty mainstream
[02:17:26] <jmkasunich> but the ones that were high end when purchased, were bleeding edge
[02:17:31] <jmkasunich> some bled more than others
[02:17:34] <SWPadnos> I'd love to put this server stuff into another machien, but I'd also love to not spend much on it
[02:17:39] <SWPadnos> yep
[02:17:52] <jmkasunich> what server stuff?
[02:18:19] <SWPadnos> I actually have a SCSI drive array in a hot-swap cage, CD-ROM, ZIP-100 drive, and U160 controllers
[02:18:25] <SWPadnos> and the tape drive, of course
[02:18:45] <jmkasunich> and a case that holds it all?
[02:18:48] <SWPadnos> then again, I can have 3x the storage, in RAID1 SATA for $200
[02:18:50] <SWPadnos> yes
[02:18:58] <jmkasunich> (you got the drive array from me, right?)
[02:19:04] <SWPadnos> 19 drive bays, triple redundant 900W supply
[02:19:07] <SWPadnos> nope
[02:19:37] <jmkasunich> ok, I recall giving someone a 3 bay hot plug scsi cage and drives at NIST EMCfest
[02:19:38] <SWPadnos> I bought the machine new (in 1995 or so), most of the other stuff is eBay
[02:19:43] <jmkasunich> must have been someone else
[02:19:56] <SWPadnos> I think I had asked about them, but maybe Paul or JonE got them
[02:20:14] <jmkasunich> so what do you need for that server? you have all the storage, the case, and the PS
[02:20:21] <jmkasunich> just need a mobo?
[02:20:31] <SWPadnos> a battery, and the ability to install Linux from CD-ROM
[02:20:42] <SWPadnos> the motherboard works (though the supply is AT, not ATX)
[02:21:10] <jmkasunich> does it have a spare IDE channel for the cdrom drive?
[02:21:13] <SWPadnos> I've booted of ffloppies, tries syslinux and smartboot, and I can't get the damned thing to install a new version of Linux
[02:21:18] <jmkasunich> oh, I bet it can't boot from CD
[02:21:22] <SWPadnos> I could go that route, probably
[02:21:44] <SWPadnos> this machine came out when CD-boot was new, and there's a BIOS option for it, but it doesn't seem to work
[02:21:58] <SWPadnos> it's attached to an Adapted 2940UW at the moment
[02:22:01] <SWPadnos> Adaptec
[02:22:04] <jmkasunich> what about a new mobo?
[02:22:13] <SWPadnos> AT only, in that case
[02:22:18] <jmkasunich> ah
[02:22:30] <SWPadnos> the supply is really big, since it's triple hot-swap
[02:22:34] <jmkasunich> get out the drill?
[02:22:45] <SWPadnos> nice case - Antec KS-011B
[02:22:51] <jmkasunich> course the PS would be a prob anyway
[02:22:58] <SWPadnos> I've done that already, and the hacksaw and files ;)
[02:23:44] <jmkasunich> if you were just looking for a system (and didn't already have the case and everything...
[02:23:45] <SWPadnos> that's my dilemma - I have 11 SCSI hard drives, a tape drive, several CD-Roms and the ZIP drive (plus a few controllers)
[02:23:51] <jmkasunich> I have an HP LPr server
[02:23:58] <SWPadnos> but I can replace that al with a $299 wal-mart IDE special
[02:24:08] <jmkasunich> dual 600MHz P3, two bay hot-plug SCSI, CD-ROM
[02:24:16] <jmkasunich> all in 3.5" high rack mount
[02:24:22] <SWPadnos> nice
[02:24:28] <SWPadnos> did you have tha twith you at Fest?
[02:24:36] <jmkasunich> I think I brought it
[02:24:40] <jmkasunich> never did anything with it tho
[02:24:41] <SWPadnos> ok - I think so too.
[02:24:48] <jmkasunich> BDI and SCSI didn't get along back then
[02:24:55] <jmkasunich> still might not
[02:25:00] <SWPadnos> ubuntu
[02:25:06] <SWPadnos> great hardware detection
[02:25:19] <jmkasunich> yeah, but I've heard that SCSI does bad things to RT latency
[02:25:24] <jmkasunich> not a factor for a server tho
[02:25:34] <SWPadnos> DMA does, but you should be able to disable it
[02:25:42] <SWPadnos> though I'm not sure for SCSI
[02:25:48] <jmkasunich> sometimes I think I would like to set the LPr up as a server of some kind
[02:25:55] <jmkasunich> other times it just seems silly
[02:26:10] <SWPadnos> yep
[02:26:32] <SWPadnos> less noise, better performance, less power, less space, and all that for only $150 :)
[02:26:40] <SWPadnos> or so
[02:26:43] <jmkasunich> it would be nice to have a RAID array for my /home directory, so I'd never loose anything even as I evolve thru different main computers
[02:26:57] <jmkasunich> but not nice enough to be worth the hassle
[02:27:08] <jmkasunich> the raid array is 2x18G drives
[02:27:15] <jmkasunich> my drive on this box is 80G
[02:27:21] <SWPadnos> that's part of my idea - I have a static IP, I'd like to have CVS access to projects when I'm away from home
[02:27:32] <SWPadnos> IMAP for email
[02:27:52] <jmkasunich> if I had static IP, then it would be a different story - serve webpages, host emc stuff, etc
[02:27:55] <SWPadnos> and backups / redundancy for business projects
[02:28:16] <SWPadnos> actually, the static IP costs me 1/3 of the hosting fees at DreamHost
[02:28:37] <jmkasunich> well, if you ever think you could put that LPr to good use, let me know
[02:28:37] <SWPadnos> I'm way better off with the extra $16/month for the offsite hosting
[02:28:43] <SWPadnos> OK - will do. thanks
[02:28:57] <jmkasunich> course you'd need a 19" rack
[02:29:10] <jmkasunich> then you'd have a rack with 3.5" filled, and lots of empty space
[02:29:24] <jmkasunich> which you would eventually fill ;-)
[02:29:25] <SWPadnos> I have a short rack with a power supply on it right behind me
[02:29:35] <jmkasunich> how deep?
[02:29:40] <jmkasunich> this thing is 20" plus
[02:29:51] <SWPadnos> 18 deep
[02:29:53] <jmkasunich> maybe 24" plus
[02:30:04] <SWPadnos> the supply is around 20 as well
[02:30:41] <SWPadnos> I have a server closet actually, so it's not really an issue
[02:30:51] <SWPadnos> I just don't have a running server in the closet ATM
[02:31:16] <SWPadnos> On a separate note, is this your comment (in tp.c)?
[02:31:17] <SWPadnos> /* what the hell does this do? It is one of the key functions in
[02:31:19] <SWPadnos> the whole planner, and it doesn't have any overall comments :-(
[02:31:20] <SWPadnos> */
[02:31:27] <SWPadnos> (just above tpRunCycle)
[02:31:28] <jmkasunich> yeah ;-)
[02:31:36] <SWPadnos> heh - well I agree
[02:31:54] <SWPadnos> I fixed the 3dChips problem by reintroducing the high speed blending problems
[02:32:03] <SWPadnos> (apparently)
[02:33:13] <jmkasunich> dunno if that is good or bad
[02:33:21] <SWPadnos> me either
[02:33:48] <SWPadnos> apparently the code inside the OLD_CODE ifdefs was an attempt to smooth out blending for machines like Les'
[02:34:02] <SWPadnos> but it screwed up this other stuff, as we now know
[02:34:05] <jmkasunich> smoothed it a little too much
[02:34:13] <SWPadnos> heh - sort of
[02:34:48] <jmkasunich> http://cgi.ebay.ca/ws/eBayISAPI.dll?ViewItem&item=5865618500
[02:34:52] <SWPadnos> the runcycle - do you know how many segments there should be in the queue?
[02:34:56] <jmkasunich> that is something like the LPr box
[02:35:04] <jmkasunich> I've never dug into that code
[02:35:06] <SWPadnos> h - OK
[02:35:10] <SWPadnos> ok (on both)
[02:35:20] <jmkasunich> you and cradek quickly got deeper than my knowledge last night
[02:35:29] <SWPadnos> heh
[02:35:34] <SWPadnos> mine too ;)
[02:35:58] <SWPadnos> I should just scrap that big box - it doesn't even have 64/66 PCI
[02:36:13] <SWPadnos> 64 or 66, let alone both
[02:36:25] <jmkasunich> don't you just hate it when that happens
[02:36:37] <jmkasunich> something that was once top-of-the-line
[02:36:38] <SWPadnos> yes, especially when I bought the thing for $5000 or so
[02:36:45] <jmkasunich> ouch!
[02:36:48] <SWPadnos> plus upgrades after the fact
[02:36:52] <SWPadnos> yeah
[02:36:58] <jmkasunich> I've never bought such stuff, I dumpster dive it
[02:37:05] <SWPadnos> the SuperMicro motherboard was around $1000 alone
[02:37:24] <jmkasunich> and it still hurts when I realize that it's dumb to keep it because it can be replaced (better) for a few hundred bucks
[02:37:50] <SWPadnos> now I have a SuperMicro dual Opteron, and the MB cost $350 (and the whole computer was < $2500 + monitors)
[02:37:54] <SWPadnos> yep
[02:38:33] <jmkasunich> that one I grabbed today... I had this nagging voice in my head that said "you'll never actually use this, leave it in the dumpster"
[02:38:44] <SWPadnos> heh - that's so hard to do
[02:39:21] <jmkasunich> if the mechanicals were more normal I'd just grab the mobo, CPUs and memory
[02:39:40] <SWPadnos> it's a full size AT board - I'm not sure there's a case made today that it'll fit in
[02:39:43] <jmkasunich> but they are slot1 CPUs, with a special fan and ducting to cool them
[02:39:50] <SWPadnos> ah - yours
[02:39:54] <jmkasunich> yeah
[02:39:54] <SWPadnos> same deal, I bet
[02:40:07] <jmkasunich> on yours, the mobo is probalby the most obsolete part
[02:40:19] <jmkasunich> (except for that pesky AT vs ATX thing)
[02:41:03] <SWPadnos> yeah - I can always use the SCSI drives and controllers
[02:41:13] <SWPadnos> the AHA-39160 is still a good card
[02:41:21] <jmkasunich> you said 333MHz? even the mundane ones in the dumpster are better than that ;-)
[02:41:24] <jmkasunich> (not SMP tho)
[02:41:41] <SWPadnos> DUAL 333 MHz!
[02:41:54] <jmkasunich> I paid $100 for the mobo and CPU in this box (on sale, Sempron 2800)
[02:42:09] <SWPadnos> plus a Matrox Millennium II video card, and an actual soundblaster (with extra SIMM ram on it!)
[02:42:19] <jmkasunich> lol
[02:43:03] <SWPadnos> yeah - I just looked at a board for a friend - $225 for an A64 3000 (socket 939), and a board with both AGP and PCIe (both of which perform well), integrated GigE, up to 4G RAM, ...
[02:43:46] <jmkasunich> boggles the mind
[02:43:48] <SWPadnos> well - I may just build myself up an Opteron server, and a single opteron workstation - I think I need to replace the cpus in the duallie anyway
[02:43:51] <SWPadnos> yes
[02:44:17] <jmkasunich> "the dualie" that the 333Mhz one, or your new screamer?
[02:44:23] <SWPadnos> e new screamer
[02:44:25] <SWPadnos> the
[02:44:36] <jmkasunich> why do you need to replace the CPUs?
[02:44:57] <SWPadnos> unfortunately, I bought it about 6 hours before they released the new processor stepping - the one that lets VMWare emulate a 64-bit CPU
[02:45:04] <SWPadnos> plus the SSE3 instructions
[02:45:14] <SWPadnos> and a die shrink + HT speed increase ...
[02:45:16] <jmkasunich> the perils of living on the bleeing edge
[02:45:22] <jmkasunich> bleeding even
[02:45:30] <SWPadnos> yes - and I didn't even buy fast opterons - they're 244s
[02:45:39] <jmkasunich> I'll take the old ones off your hands ;-)
[02:45:46] <jmkasunich> (how fast are they?)
[02:45:51] <SWPadnos> well ...
[02:45:55] <SWPadnos> 1.8 GHz
[02:46:03] <SWPadnos> maybe they're 246s
[02:46:12] <jmkasunich> I dunno what those numbers mean
[02:46:42] <SWPadnos> well - they start at [1,2,8]40, and go up to [1,2,8]54 right now
[02:46:52] <SWPadnos> each 2 in the last position is .2 GHz
[02:47:07] <SWPadnos> the first digit is the tpye of system they're for - 1, 2, or 8-way systems
[02:47:10] <SWPadnos> type
[02:47:18] <jmkasunich> so x54 = 5.4GHz?
[02:47:22] <jmkasunich> seems too fast
[02:47:52] <SWPadnos> no - they start at 1.2 or 1.4 GHz, and go up in steps of 0.2, so a 240 is 1.4GHz, and a 242 is 1.4 + 0.2 = 1.6 GHz
[02:48:00] <jmkasunich> oh
[02:48:39] <jmkasunich> so if the number is XYY
[02:48:52] <SWPadnos> ok - I have 244s, which are 1.8 GHz
[02:48:58] <jmkasunich> freq is YY/10 - 2.6 GHZ
[02:49:09] <SWPadnos> nope
[02:49:16] <jmkasunich> 44/10 = 4.4
[02:49:27] <jmkasunich> 4.4 - 2.6 = 1.8
[02:49:46] <SWPadnos> freq is 1.4 + ((YY-40) / 10) GHz
[02:49:53] <SWPadnos> ok - sure
[02:49:54] <jmkasunich> same thing
[02:50:09] <SWPadnos> I read the - as a dash, not a minus sign ;)
[02:50:35] <SWPadnos> unles YY is 60 or over
[02:50:51] <SWPadnos> in which case it's a dual-core, and the model numbers go up by 5
[02:51:01] <SWPadnos> for each 0.2 GHz increase in speed (I think)
[02:51:11] <jmkasunich> so on raw clock they are only marginally faster than my sempron 2800 (I think it is 1.6G)
[02:51:16] <SWPadnos> yes
[02:51:27] <SWPadnos> but they have 1M of full core speed cache
[02:51:31] <jmkasunich> right
[02:51:33] <SWPadnos> per core
[02:51:42] <jmkasunich> and the architecture is faster probably
[02:51:43] <SWPadnos> and a dual-port RAM bus
[02:51:52] <SWPadnos> dual challen, I mean
[02:51:55] <SWPadnos> cahnnel
[02:51:57] <SWPadnos> channel
[02:51:59] <jmkasunich> lol
[02:52:00] <SWPadnos> woohoo!
[02:52:20] <SWPadnos> I type like bush speaks
[02:52:21] <jmkasunich> well shit, here it is almost 10pm and I still haven't looked into the compile farm problem
[02:52:26] <SWPadnos> heh
[02:52:34] <jmkasunich> you can tell how much I'm looking forward to that
[02:52:44] <SWPadnos> sorry - I'll go make tea, you look at the compile farm :)
[02:52:56] <jmkasunich> do I have to?
[02:53:09] <SWPadnos> can you subscribe the farm controller to the commit messages, and have it set a flag that way
[02:53:19] <SWPadnos> then have the individual cards do a clean checkout
[02:53:21] <jmkasunich> no mail on the farm
[02:53:28] <SWPadnos> ok
[02:53:34] <jmkasunich> and I don't want to try to set up mail on 4 different distros
[02:53:42] <SWPadnos> no - only on the supervisor
[02:53:54] <jmkasunich> there is no supervisor
[02:54:04] <SWPadnos> ah - only to get the cards booted?
[02:54:11] <jmkasunich> ?
[02:54:32] <SWPadnos> I thought there weas a "controller" card that took care of getting the individual cards booted
[02:54:36] <SWPadnos> rebooting them, etc
[02:54:41] <jmkasunich> each card is a PC, there is a built in KVM that also "muxes" a floppy drive, and the power and reset switches
[02:54:51] <SWPadnos> oh - OK
[02:54:57] <jmkasunich> but the controller is dedicated HW, not a PC
[02:55:03] <SWPadnos> got it
[02:55:38] <jmkasunich> if I was willing to do a fresh checkout every time I could figure out some way to make it work
[02:55:43] <jmkasunich> but gawd that sucks
[02:55:49] <SWPadnos> can you check the cvs error return, or is that the same no matter what the error is?
[02:55:52] <jmkasunich> and it shouldn't be needed
[02:56:05] <jmkasunich> cvs apparently returns a failure
[02:56:21] <jmkasunich> I might be able to parse the log and say "oh, its _that_ failure, ignore it"
[02:56:27] <jmkasunich> but that sucks too
[02:56:51] <SWPadnos> do you have a copy of the actual error returned (is that on the farm status page)?
[02:56:55] <jmkasunich> the scripts are in cvs - the emc-HAL module
[02:57:10] <jmkasunich> not on the status page
[02:57:12] <jmkasunich> stand by
[02:58:42] <jmkasunich2> farming
[02:58:51] <SWPadnos> howdy there, stranger
[02:59:01] <jmkasunich2> unforch, this box is text only
[02:59:18] <SWPadnos> ok - the failure is anything that doesn't get a CVS_SUCCESS in the log
[02:59:31] <jmkasunich2> looking at the scripts?
[02:59:33] <SWPadnos> yep
[02:59:54] <jmkasunich2> lemme alt-F2 and read the cvs-fail log
[02:59:57] <SWPadnos> did you have locally created/modified cvsignore files?
[03:00:52] <jmkasunich2> no, not on the farm
[03:01:41] <SWPadnos> ok - I thought that was the origin of the problem
[03:02:02] <jmkasunich2> when it happened on my main box I assumed that was the source
[03:02:31] <jmkasunich2> I should probably reboot that box back to the BDI-4.27 and see if it has the same problem
[03:03:09] <SWPadnos> I see that the latest build of emc2 is from 1/24
[03:03:13] <jmkasunich2> right
[03:03:28] <jmkasunich2> ever since then the cvs up has been failing
[03:03:41] <jmkasunich2> didn't even notice till two days ago
[03:03:55] <jmkasunich2> sometimes I wonder if I should bother with the farm
[03:04:23] <SWPadnos> it's good for forensic work, but it does seem to be underutilized these days
[03:04:33] <SWPadnos> it'll be critical for releases though
[03:04:44] <jmkasunich> I'm gonna reboot this box
[03:06:32] <jmkasunich2> I bet when I get it working again several compiles will fail
[03:06:43] <SWPadnos> we'll see :)
[03:06:52] <jmkasunich2> (well, with the jepler changes that is a sure bet, but even before then...
[03:07:06] <jmkasunich2> there were a lot of changes since 1/24
[03:07:13] <SWPadnos> here's what he wrote in this channel, a bit before you arrived:
[03:07:20] <SWPadnos> jeplerin case this reassures anyone of my good intentions, I'm installing bdi-live in qemu right now and will work this weekend to get emc2 compiling on it again
[03:07:22] <jmkasunich2> mostly by folks with no idea if they work on older systems
[03:07:46] <jmkasunich2> ok - but I was already reassured by his email to the list
[03:07:53] <SWPadnos> I'm not sure what would cause cvs to fail though - that shouldn't have anything to do with the content of the changes
[03:08:16] <jmkasunich2> no, the cvs failures are definitely the .cvsignore
[03:08:37] <jmkasunich2> but once they are fixed, there are gonna be compile errors or warnings because of other changes
[03:08:51] <SWPadnos> sure - that's what we need to see
[03:08:58] <SWPadnos> well -cradek and jepler at least ;)
[03:09:15] <jmkasunich2> like a change to rtapi, the type of an arg passed to some RTAI function was changed from int to long or vice-versa
[03:09:21] <jmkasunich2> (don't remember which)
[03:09:35] <jmkasunich2> it fixes a warning on new systems, causes one on old systems
[03:09:42] <SWPadnos> that was quite a while ago, I think
[03:09:57] <jmkasunich2> that was done once before, then reverted, but it was done again in the last couple weeks
[03:10:02] <SWPadnos> ah
[03:10:18] <SWPadnos> that brings up a point similar to the one raised by "Mark"
[03:10:24] <jmkasunich2> back to the other box
[03:10:58] <SWPadnos> maybe RTAPI should be linked to the kernel (in terms of source), and that's the compatibility layer for HAL / emc
[03:11:36] <SWPadnos> linked in a logical, source-control way, not like the last step in making an executable
[03:12:26] <jmkasunich> I've thought about RTAPI as a separate package/project/tree/whatever
[03:13:12] <jmkasunich> its only connection to sw like emc that uses it is a kernel module, a lib, and a .h file
[03:13:37] <SWPadnos> it would be nice to be able to layer the system better - kernel / RT / RTAPI / HAL / emc (motion) / interpreter / UI
[03:14:01] <SWPadnos> without a lot of hooks that bypass layers (and a clear interface definition)
[03:14:26] <SWPadnos> but it's probably not worth the time
[03:14:48] <jmkasunich> I would like HAL (or its successor) to be separate from EMC
[03:15:11] <jmkasunich> I'd be tempted to merge RTAPI into HAL
[03:15:12] <SWPadnos> yep - emc would have a HAL component or two, but otherwise separate
[03:15:26] <jmkasunich> thats what I intended to do with BLOCS
[03:15:52] <SWPadnos> right
[03:16:05] <jmkasunich> ok, on this box, my old checkouts get the .cvsignore error every time I do an up
[03:16:11] <jmkasunich> a new checkout doesn't
[03:16:19] <jmkasunich> time for diff I think ;-)
[03:16:21] <SWPadnos> what is the error?
[03:16:38] <jmkasunich> cvs update: move away `include/.cvsignore'; it is in the way
[03:16:38] <jmkasunich> C include/.cvsignore
[03:16:46] <jmkasunich> three places
[03:17:01] <jmkasunich> include, bin, and rtlib
[03:17:15] <SWPadnos> ok
[03:17:25] <jmkasunich> have you ever seen that?
[03:17:28] <jmkasunich> cradek did
[03:17:38] <SWPadnos> nope - not that I can remember
[03:21:53] <SWPadnos> maybe the thing to do (and this may be what you meant) is to use cvs diff in the TRY_CVS function
[03:22:32] <jmkasunich> not what I meant, I was diffing files in my checkout's CVS/ dir to see if the two checkouts differ
[03:22:42] <SWPadnos> if it's ok
[03:22:53] <jmkasunich> one checkout (made after the .cvsignore files were added, one made before)
[03:23:00] <jmkasunich> both just did cvs up -dP
[03:23:01] <SWPadnos> cvs diff returns success if there's no difference
[03:23:05] <jmkasunich> both should be the same
[03:23:10] <SWPadnos> should be ;)
[03:23:25] <jmkasunich> but one prints those messages, one doesn't
[03:23:32] <jmkasunich> I want to know why
[03:23:51] <SWPadnos> very odd
[03:24:22] <SWPadnos> only the first time, or every time you up?
[03:24:27] <jmkasunich> every time
[03:24:34] <jmkasunich> (pretty sure)
[03:24:35] <jmkasunich> * jmkasunich checks
[03:24:56] <jmkasunich> yep
[03:25:30] <jmkasunich> one thing bin/, include/, and rtlib/ have in common
[03:25:47] <SWPadnos> they start out empty
[03:25:47] <jmkasunich> they don't actually contain anything in the repository (I think)
[03:25:56] <jmkasunich> except the .cvsignore file
[03:26:03] <jmkasunich> ls
[03:26:04] <SWPadnos> started out empty
[03:26:04] <jmkasunich> oops
[03:26:12] <SWPadnos> ./
[03:26:13] <SWPadnos> ../
[03:26:24] <SWPadnos> (dunno what comes next ;) )
[03:28:32] <SWPadnos> the farm gets develper access, right? (not anonymous CVS)
[03:28:37] <SWPadnos> developer
[03:28:40] <jmkasunich> manually deleted the .cvsignore file in bin/
[03:28:51] <jmkasunich> next cvs up, it was happy (did a U .cvsignore)
[03:28:56] <jmkasunich> the following one complained again
[03:29:06] <jmkasunich> yes, dev access
[03:29:17] <jmkasunich> and I have the SSH keys loaded so it doesn't prompt for a password
[03:29:39] <SWPadnos> ok. I see the timeout is 60 seconds - I've been waiting as much as 15 seconds lately for the password prompt
[03:29:49] <SWPadnos> if the server is that slow, it could be aproblem
[03:29:56] <jmkasunich> these aren't timeouts
[03:30:15] <jmkasunich> the cvs log file has the same message I just pasted
[03:30:21] <jmkasunich> cvs update: move away `include/.cvsignore'; it is in the way
[03:30:21] <jmkasunich> C include/.cvsignore
[03:30:40] <SWPadnos> what's the date on the file?
[03:30:51] <jmkasunich> cvsignore?
[03:31:03] <SWPadnos> yes
[03:31:17] <jmkasunich> jan 30
[03:31:28] <SWPadnos> from an emc2 checkout?
[03:31:29] <jmkasunich> (it is at version 1.2, that was committed on 1/30)
[03:31:31] <jmkasunich> yes
[03:31:40] <SWPadnos> in the include dir?
[03:32:03] <jmkasunich> I'm looking in bin right now
[03:32:06] <jmkasunich> lemme check include
[03:32:19] <jmkasunich> 1/24
[03:32:21] <SWPadnos> ok - the include one I have is 1/24 at 16:45
[03:32:52] <jmkasunich> yep, same in both checkouts here
[03:32:52] <cradek> hi guys
[03:32:57] <SWPadnos> ok
[03:32:59] <SWPadnos> hi
[03:33:01] <jmkasunich> hi
[03:33:26] <jmkasunich> cradek: to fill you in
[03:33:34] <jmkasunich> I'm on my BDI box again
[03:33:53] <cradek> problems with ubuntu?
[03:33:53] <jmkasunich> I have two checkouts of emc2, one in ~/emcdev/emc2head, one in ~/emcdev/emc2old
[03:33:58] <jmkasunich> no
[03:34:22] <jmkasunich> the emc2old checkout was my main working one, it was checked out a year or more ago
[03:34:32] <jmkasunich> the other one was checked out after the .cvsignore was added
[03:34:39] <cradek> ok
[03:34:47] <cradek> still having problems with that?
[03:34:48] <jmkasunich> right now, both are up to date (I think), I ran cvs up -dP on both
[03:35:05] <jmkasunich> the old one complains about three .cvsignore files, the new one doesn't
[03:35:13] <jmkasunich> I can't figure out what is the difference
[03:35:43] <cradek> did you look in CVS/Entries?
[03:36:22] <jmkasunich> yes, sort of
[03:36:30] <jmkasunich> (there is one of those in every dir in the tree)
[03:36:51] <jmkasunich> the ones in that contain the files that its complaining about are exactly the same (diffed em)
[03:37:17] <cradek> well wtf
[03:37:37] <jmkasunich> dat's pretty much what I've been saying
[03:37:44] <jmkasunich> gonna do some more elaborate diffs
[03:38:31] <cradek> is this just academic or is there a reason you have to keep the old tree?
[03:38:57] <jmkasunich> I don't want to do new checkouts on all four farm slots
[03:39:24] <jmkasunich> and I want to get to the bottom of it, because if I do new checkouts and it recurrs when someone changes a .cvsignore, then I'll have to do it again
[03:39:35] <jmkasunich> if its a bug in CVS I want to report it
[03:39:41] <cradek> I understand
[03:39:45] <jmkasunich> if its something screwy about our repository I want to fix it
[03:39:46] <jmkasunich> etc
[03:40:03] <SWPadnos> well - I have a checkout that predates the cvsignore files, and it gives me no error
[03:40:04] <cradek> I dug through the info pages and there's not a lot of detail
[03:40:32] <SWPadnos> let me check another dir
[03:41:31] <jmkasunich> I find it interesting that the ones it complains about are in the dirs that are otherwise empty
[03:42:28] <SWPadnos> what version of CVS are you running? (though it's the same for both checkouts on that box, duh)
[03:42:52] <jmkasunich> 1.12.9
[03:43:14] <SWPadnos> ok - same here - the BDI 4.30 version
[03:45:38] <SWPadnos> are you the same user as the checkout was done under?
[03:45:43] <jmkasunich> yes
[03:49:03] <SWPadnos> well - you could have the farm scripts check the log for "^C", and rm -rf the tree, then do a clean checkout if it's found
[03:49:59] <jmkasunich> I'm not considering workarounds tonight
[03:50:10] <jmkasunich> maybe tomorrow, if I can't figure out what is going on
[03:50:12] <SWPadnos> that would be a pretty permanent solution
[03:50:35] <jmkasunich> its not that simple, I would also have to copy the build script down into the new tree, etc
[03:50:43] <jmkasunich> not insurmountable
[03:50:46] <jmkasunich> bit I'd rather not
[03:50:49] <SWPadnos> actually, any error that isn't a connection problem (not sure how to check that) can cause a re-checkout
[03:51:17] <jmkasunich> there shouldn't be any error except connection problems
[03:51:29] <SWPadnos> I agree - but in this case, there is
[03:51:29] <cradek> unfortunately I don't know how to trigger this so I can work on it
[03:51:41] <jmkasunich> * jmkasunich is stubborn
[03:51:47] <jmkasunich> come back with workarounds tomorrow
[03:51:47] <SWPadnos> ther emay be other cases as well, so working around them may be a sane approach
[03:52:06] <jmkasunich> farms been running for a couple years now, this is the first problem
[03:52:14] <SWPadnos> I can't get it to hapeen here either - BDI 4.30, checkouts from before or after the files were added
[03:52:34] <SWPadnos> does the farm do a make clean before or after the test build?
[03:52:41] <jmkasunich> make clean before
[03:52:47] <SWPadnos> ok
[03:52:53] <jmkasunich> it does the whole thing, ./configure, make clean, make
[03:53:47] <SWPadnos> but you're not doing that in your testing right now
[03:53:53] <SWPadnos> ?
[03:53:54] <jmkasunich> nope
[03:53:58] <jmkasunich> just cvs up -dP
[03:55:18] <SWPadnos> what are the contents of the CVS/Entries files under those 3 dirs?
[03:55:48] <cradek> I do not have this bug in ubuntu's cvs version 1.12.9
[03:55:56] <cradek> here's what I did
[03:56:07] <cradek> cvs -d:.... co -D2005/12/01 emc2
[03:56:11] <jmkasunich> John@main:~/emcdev/emc2old/bin$ cat CVS/*
[03:56:14] <jmkasunich> /.cvsignore/1.2/Mon Jan 30 16:51:33 2006//
[03:56:14] <jmkasunich> D
[03:56:14] <jmkasunich> emc2/bin
[03:56:15] <jmkasunich> :ext:jmkasunich@cvs.sourceforge.net:/cvsroot/emc
[03:56:28] <cradek> cd emc2; touch .cvsignore; cvs up -A
[03:56:34] <cradek> I get the error
[03:56:45] <cradek> I remove .cvsignore, cvs up again, no error
[03:57:07] <jmkasunich> the first time after I remove it I get no error (because it isn't there)
[03:57:19] <jmkasunich> the 2nd (and subsequent) time I get the error again
[03:57:30] <jmkasunich> what is -A
[03:57:32] <cradek> I did several, I never get the error again
[03:57:44] <cradek> -A = remove that previous date specification
[03:58:26] <SWPadnos> what's the date on your machine?
[03:58:42] <SWPadnos> and time
[03:58:44] <cradek> me? it's right
[03:58:48] <jmkasunich> Fri Feb 10 22:58:36 EST 2006
[03:59:00] <SWPadnos> ok - close enough ;)
[03:59:02] <jmkasunich> set by ntp on boot
[03:59:13] <SWPadnos> ok
[04:01:44] <cradek> did you try cvs up -C
[04:01:49] <jmkasunich> not yet
[04:01:53] <jmkasunich> I'm testing a theory
[04:02:17] <jmkasunich> heh, caught jepler in a commit
[04:03:42] <jmkasunich> ok, I only get the error when I do cvs up -d
[04:03:48] <cradek> me too...?
[04:03:51] <jmkasunich> -P is ok
[04:03:57] <jmkasunich> as is cvs up <nothing>
[04:04:03] <cradek> aha
[04:04:12] <cradek> I don't typically use -d
[04:04:28] <jmkasunich> this has got to be related to the fact that those dirs are empty (except for .cvsignore)
[04:05:09] <jmkasunich> -d is the only way to make sure you get any newly added directories
[04:05:13] <jmkasunich> critical for the farm
[04:05:24] <jmkasunich> darned usefull for normal developers too
[04:05:25] <cradek> yeah
[04:05:29] <cradek> seems like a cvs bug then?
[04:05:46] <jmkasunich> could be
[04:05:57] <jmkasunich> wish I had a scratch repository to test things in
[04:06:09] <jmkasunich> I wonder if it is because .cvsignore is a hidden file
[04:07:11] <cradek> so if you do cvs up without -d, is it fixed, or is -d broken forever?
[04:07:32] <jmkasunich> if I do cvs up <no -d> I get a normal cvs up
[04:07:47] <jmkasunich> if I later do one with -d, I get the error
[04:07:57] <jmkasunich> later yet, no -d, no error
[04:08:09] <cradek> so you can never use -d again?
[04:08:12] <cradek> wtf?
[04:08:20] <cradek> I don't have that behavior
[04:08:30] <jmkasunich> fresh or old checkout?
[04:08:41] <jmkasunich> because on my fresh checkout -dP works fine
[04:08:58] <jmkasunich> damned if I can see any difference between the two checkouts
[04:09:13] <cradek> I don't think state is stored anywhere except in CVS/
[04:09:20] <jmkasunich> agreed
[04:09:23] <jmkasunich> and they match
[04:09:27] <jmkasunich> at least in those three dirs
[04:09:36] <jmkasunich> lemme check the top dir
[04:09:45] <SWPadnos> what are the timestamps of the .cvsignore files?
[04:10:22] <jmkasunich> -rw-r--r-- 1 John John 179 2006-01-30 11:51 ./emc2old/bin/.cvsignore
[04:10:22] <jmkasunich> -rw-r--r-- 1 John John 4 2006-01-31 16:15 ./emc2old/.cvsignore
[04:10:23] <jmkasunich> -rw-r--r-- 1 John John 9 2006-01-24 16:45 ./emc2old/include/.cvsignore
[04:10:23] <jmkasunich> -rw-r--r-- 1 John John 14 2006-01-24 16:56 ./emc2old/rtlib/.cvsignore
[04:10:29] <SWPadnos> both from the CVA/Entries file, and ls
[04:10:35] <SWPadnos> CVS ...
[04:10:38] <jmkasunich> -rw-r--r-- 1 John John 179 2006-02-10 22:27 ./emc2head/bin/.cvsignore
[04:10:38] <jmkasunich> -rw-r--r-- 1 John John 4 2006-01-31 16:15 ./emc2head/.cvsignore
[04:10:38] <jmkasunich> -rw-r--r-- 1 John John 9 2006-01-24 16:45 ./emc2head/include/.cvsignore
[04:10:39] <jmkasunich> -rw-r--r-- 1 John John 14 2006-01-24 16:56 ./emc2head/rtlib/.cvsignore
[04:10:59] <jmkasunich> entries coming up
[04:11:18] <cradek> jmkasunich: I can't reproduce it on ubuntu. I made my conflicting include/.cvsignore but deleting it once (when it says to) solves the problem
[04:11:33] <jmkasunich> John@main:~/emcdev$ cat emc2old/bin/CVS/Entries
[04:11:36] <jmkasunich> /.cvsignore/1.2/Mon Jan 30 16:51:33 2006//
[04:11:36] <jmkasunich> D
[04:11:36] <jmkasunich> John@main:~/emcdev$ cat emc2head/bin/CVS/Entries
[04:11:37] <jmkasunich> /.cvsignore/1.2/Sat Feb 11 03:27:27 2006//
[04:11:37] <jmkasunich> D
[04:12:10] <SWPadnos> and it's the emc2head dir that fails?
[04:12:14] <jmkasunich> no, old
[04:12:29] <SWPadnos> well - that's backwards
[04:13:08] <SWPadnos> oh wait - I went the wrong way on the times
[04:13:21] <jmkasunich> for head, the one in Entries is newer than the one on disk
[04:13:31] <SWPadnos> Entries is in UTC
[04:13:44] <SWPadnos> so it should be +5 from ls
[04:13:54] <SWPadnos> assuming you're in EST5EDT
[04:14:10] <jmkasunich> yeah
[04:14:27] <jmkasunich> so they both are +5
[04:14:39] <jmkasunich> but one date is the commit date for the file
[04:14:43] <jmkasunich> the other is the checkout date
[04:15:42] <SWPadnos> yes
[04:15:57] <SWPadnos> http://lists.gnu.org/archive/html/info-cvs/2001-03/msg00163.html
[04:16:06] <SWPadnos> that's what made me mention it
[04:19:04] <jmkasunich> I'm gonna try deleting the bin/ directory and doing an up
[04:19:28] <SWPadnos> http://www.monkey.org/openbsd/archive/misc/0004/msg00534.html
[04:19:41] <SWPadnos> that message implies that it's a problem best solved with rm -rf
[04:19:58] <SWPadnos> though you did that, and the issue came back the second time
[04:20:19] <jmkasunich> I only removed the file
[04:20:29] <cradek> did you remove the line in Entries and the file at the same time?
[04:20:32] <jmkasunich> this time I removed the dir (which includes CVS/ and Entries
[04:20:34] <SWPadnos> right - the guy says remove the file ()or the entire directory)
[04:21:40] <jmkasunich> looks like that fixed it
[04:21:48] <jmkasunich> for the bin dir anyway
[04:22:17] <jmkasunich> for include/ I'm gonna try just removing Entries and see if it replaces it
[04:22:33] <cradek> yes I think you should remove from Entires the same time you delete the file
[04:22:51] <cradek> then you'll get a 'U .cvsignore' when you up
[04:23:02] <jmkasunich> I get the U anyway
[04:23:15] <jmkasunich> it says ".cvsignore was lost" then "U .cvsignore"
[04:23:39] <jmkasunich> I'm used to that one - if I hack on a file, then decide I don't like the changes, I rm it, and cvs up to get the original
[04:23:41] <cradek> it shouldn't say "was lost" I think
[04:23:51] <cradek> if you delete from Entries
[04:23:58] <jmkasunich> I also rm README on the farm to force a build (because the farm sees the U)
[04:24:00] <SWPadnos> if you delete the file, but not the Entry, it should
[04:24:17] <jmkasunich> I didn't delete FROM Entries, I DELETED Entries ;-)
[04:24:22] <SWPadnos> heh
[04:24:43] <jmkasunich> it said Entries not found, then U .cvsignore, and apparently rebuilt Entries
[04:25:14] <jmkasunich> that didn't fix it
[04:25:33] <jmkasunich> deleting the entire dir did (for bin/), deleting .cvsignore and CVS/Entries didn't (for include/)
[04:25:52] <jmkasunich> gonna try deleting CVS/* and .cvsignore
[04:26:43] <jmkasunich> nope...
[04:27:44] <jmkasunich> removing the entire directory fixes it
[04:27:51] <jmkasunich> and it seems to stay fixed
[04:28:11] <SWPadnos> I wonder if the dir timestamp is somehow screwing things up
[04:28:20] <jmkasunich> (I wonder if it will stay fixed thru a build - I think make clean empties out those three dirs)
[04:28:41] <SWPadnos> it doesn't rm -f any more, I think
[04:29:00] <cradek> no it does e.g. rm include/*
[04:29:02] <jmkasunich> cd ..
[04:29:14] <SWPadnos> you have moved up one directory level
[04:29:27] <SWPadnos> you see a small pile of stones, and a towel
[04:31:39] <jmkasunich> wow, jepler has been busy
[04:31:52] <jmkasunich> make looks different
[04:31:59] <SWPadnos> and it's a lot faster
[04:32:16] <jmkasunich> the --with-make-quiet is noiser
[04:32:23] <SWPadnos> went from 7:21 to 5:30 on my machine
[04:33:45] <jmkasunich> some warnings from the interp that I'm not used to seing
[04:33:47] <jmkasunich> seeing
[04:34:06] <SWPadnos> all those volatile things?
[04:34:18] <jmkasunich> and that type warning from arg 2 of rt_task_init_cpuid that I mentioned earlier
[04:34:48] <jmkasunich> the interp ones are unused variables
[04:34:59] <cradek> I don't understand why new interp warnings showed up
[04:35:10] <SWPadnos> ok - he may have turned on some warnings that had been off before
[04:35:18] <cradek> I had everything else cleaned up
[04:35:35] <cradek> I went warning-hunting a few nights ago
[04:35:44] <jmkasunich> Compiling emc/rs274ngc/interp_convert.cc -fPIC
[04:35:44] <jmkasunich> emc/rs274ngc/interp_convert.cc: In member function `int
[04:35:44] <jmkasunich> Interp::convert_comment(char*)':
[04:35:45] <jmkasunich> emc/rs274ngc/interp_convert.cc:795: warning: unused variable `int item'
[04:35:45] <jmkasunich> emc/rs274ngc/interp_convert.cc: In member function `int
[04:35:46] <jmkasunich> Interp::convert_m(block*, setup*)':
[04:35:47] <jmkasunich> emc/rs274ngc/interp_convert.cc:1652: warning: unused variable `int index'
[04:36:00] <jmkasunich> warning hunting is a noble thing - I try to do it every so often
[04:36:30] <jmkasunich> I'm proud of the fact that "my" parts of emc2 are warning free
[04:36:45] <cradek> I agree int index is unused...
[04:37:00] <jmkasunich> but I'm especially impressed when you hunt warnings in code that you aren't responsible for
[04:37:03] <jmkasunich> thanks!
[04:37:52] <cradek> welcome - none of it's "my" code
[04:38:01] <cradek> I screw up all areas equally
[04:38:11] <jmkasunich> several similar warnings in other files, interp_cycles.cc, etc
[04:38:17] <jmkasunich> do you get them?
[04:38:20] <cradek> yes
[04:38:34] <jmkasunich> ok
[04:38:43] <jmkasunich> that last one is different
[04:38:54] <cradek> I'm surprised there is no fallout from my latest configure change
[04:39:01] <jmkasunich> /home/John/emcdev/emc2old/src/rtapi/rtai_rtapi.c: In function `rtapi_task_new':
[04:39:02] <jmkasunich> /home/John/emcdev/emc2old/src/rtapi/rtai_rtapi.c:674: warning: passing arg 2 of `rt_task_init_cpuid' from incompatible pointer type
[04:39:10] <jmkasunich> this is familiar
[04:39:19] <cradek> I swear I fixed that
[04:39:32] <cradek> I think it's a function pointer
[04:39:33] <jmkasunich> I think magma may use a differnet type for that arg than older RTAI does
[04:39:41] <cradek> ohhhh
[04:39:46] <cradek> maybe it's fixed for just me then
[04:40:00] <jmkasunich> it's been "fixed" before, and reverted because it was wrong on other systems
[04:40:12] <jmkasunich> thats what the compile farm is supposed to catch
[04:40:52] <jmkasunich> speaking of which, now that I know how to fix the CVS prob, I'm gonna get it going again
[04:40:56] <cradek> great
[04:41:03] <cradek> we may really need it soon
[04:41:05] <jmkasunich2> /part
[04:52:41] <SWPadnos> ok - bedtime for me. good night guys
[04:52:45] <SWPadnos> SWPadnos is now known as SWP_Away
[04:52:48] <jmkasunich> builds on BDI-2 and -TNG failed rather quickly
[04:52:58] <cradek> jmkasunich: those are the non-kbuild?
[04:53:02] <jmkasunich> -Live and -4.20 are still going, thats a good sign
[04:53:14] <jmkasunich> yes, but Live is non-kbuild too
[04:53:19] <cradek> jmkasunich: are they 2.2?
[04:53:34] <jmkasunich> BDI-2 is, TNG is 2.4
[04:53:41] <cradek> so far, 2.2 is uncharted waters
[04:53:45] <jmkasunich> http://www.linuxcnc.org/compile_farm/
[04:54:00] <jmkasunich> not just 2.2, BDI-2 is also RTLinux instead of rtai
[04:54:07] <cradek> ok
[04:54:23] <SWP_Away> 2.18 reports failed, but the log says success
[04:54:41] <SWP_Away> oops - reload :)
[04:54:43] <jmkasunich> sez you??
[04:54:52] <jmkasunich> make clean failed ;-/
[04:54:56] <SWP_Away> that one was in cache ;)
[04:55:11] <SWP_Away> see - I told you I should go to sleep
[04:56:10] <jmkasunich> -TNG has a problem with some kind of depend file - I don't know what that is about
[04:56:51] <jmkasunich> maybe this weekend I can install ubuntu on a farm slot
[04:57:16] <jmkasunich> I've have a nagging feeling I should install BDI-4.30 or 4.38, but I don't really want to
[04:59:33] <jmkasunich> damn, midnight again
[04:59:41] <jmkasunich> at least the farm is running now
[04:59:44] <jmkasunich> bedtime for me
[05:01:28] <cradek> jmkasunich: how do I cause another farm run?
[05:01:45] <jmkasunich> wait an hour, or ask me to kick it off
[05:01:53] <cradek> ok
[05:03:02] <jmkasunich> the first two slots I already kicked off after you committed the warnings fix (but they failed)
[05:03:11] <jmkasunich> the other two are still running their first compile
[05:03:37] <jmkasunich> which is a good sign
[05:04:01] <cradek> can I log into these?
[05:04:06] <jmkasunich> no
[05:04:11] <cradek> darn
[05:04:22] <jmkasunich> they have no ssh or anything like that, and are firewalled out the wazoo
[05:05:10] <jmkasunich> I have considered having them monitor #emc, and when CIA sends out a commit notice they could start immediately
[05:05:46] <cradek> that would be nice
[05:05:57] <cradek> but probably it would be finicky to set up
[05:06:15] <jmkasunich> IRC works from those boxes, as long as they initiate things
[05:06:38] <cradek> irssi has simple to use perl scripting
[05:06:48] <jmkasunich> what is irssi?
[05:06:57] <cradek> irc client
[05:07:09] <cradek> doesn't require x
[05:07:18] <jmkasunich> good - these boxes are x-less
[05:08:21] <cradek> sometimes I think makefiles are write-only
[05:08:42] <jmkasunich> yeah
[05:08:56] <jmkasunich> I wonder if irssi can run blind (in the background)
[05:09:18] <cradek> you could run it in screen if you have to
[05:09:23] <jmkasunich> just print everything said in the channel to stdout
[05:10:29] <cradek> on bdi-tng what does gcc -v give you?
[05:11:17] <jmkasunich> 2.96
[05:11:21] <cradek> crap
[05:11:23] <cradek> I figured
[05:11:54] <cradek> is there a gcc-3.xx anywhere on it?
[05:12:02] <jmkasunich> doubt it
[05:12:26] <jmkasunich> ./config is supposed to figure out that the compiler version isn't good for RT and use egcs instead
[05:12:52] <jmkasunich> at least it did ages ago
[05:13:12] <jmkasunich> you know, it is good that jepler wants to try to support the older systems
[05:13:23] <jmkasunich> but I was serious when I said we should discuss it
[05:13:30] <cradek> the base of the problem is that gcc2 doesn't have the dependency-calculation scheme gcc3 has
[05:13:33] <jmkasunich> maybe the time has come to drop some of them
[05:14:35] <jmkasunich> Paul dropped support for TNG ages ago, RH did something to piss him off, he went to knoppix and then debian
[05:14:38] <cradek> maybe.
[05:15:57] <jmkasunich> the dependency system in the old build system didn't work right
[05:16:09] <cradek> yeah it was totally wrong
[05:16:12] <jmkasunich> I dunno if it ever did, but I know that a couple months ago it didn't
[05:16:27] <cradek> this one should be exactly right (and the depends are automatically maintained correctly)
[05:16:33] <jmkasunich> I could modify a .h file and the files that included it didn't get rebuilt
[05:16:44] <cradek> yeah, the make finished, but the program didn't run right
[05:16:49] <cradek> I dealt with that a lot
[05:16:54] <cradek> it bites
[05:17:32] <cradek> with the new build, if you change a file, depends for the file are recalculated (because you might have added an #include) and then it is compiled along with all necessary things
[05:17:41] <cradek> and no UNnecessary things are compiled
[05:18:03] <cradek> but as written, it requires an available gcc3
[05:18:33] <jmkasunich> I think we should seriously discuss dropping support for BDI-2.x and -TNG
[05:19:06] <cradek> we would probably not have a lot of complaints.
[05:19:27] <jmkasunich> BDI-Live compiled OK, BDI-4.20 did not
[05:19:28] <cradek> it's nice that -live, outdated as it is, works
[05:20:01] <cradek> 4.20 looks close...
[05:20:21] <jmkasunich> I'll restart -TNG so it will get your warning fixes
[05:20:38] <jmkasunich> do you think you might want to try anything for 4.20?
[05:20:44] <jmkasunich> if not, I'll restart it too
[05:20:56] <jmkasunich> if you want to try something, I'll wait
[05:21:03] <cradek> I don't see the error... just that ld failed with no error message
[05:21:47] <jmkasunich> yeah, kinda strange
[05:21:58] <cradek> I don't know what to try right now, so go ahead
[05:23:13] <jmkasunich> damn - I know what happened
[05:23:17] <jmkasunich> disk is full
[05:23:21] <cradek> ahhhh
[05:23:27] <cradek> I was going to suggest that, but thought "nah"
[05:23:31] <jmkasunich> gotta clean up a bit
[05:25:09] <jmkasunich> is there any convenient way to find out where the big files are?
[05:25:24] <cradek> I like to use xdu
[05:25:37] <jmkasunich> a recursive ls that lists only the total size of each directory contents or something
[05:25:37] <cradek> do you have remote X?
[05:25:44] <cradek> well there's du
[05:25:46] <jmkasunich> I don't have remote anything
[05:25:51] <jmkasunich> I walk over there and type
[05:26:12] <cradek> you'll have to get by with du I ugess
[05:26:13] <cradek> guess
[05:26:21] <jmkasunich> that should work
[05:26:39] <cradek> especially check /tmp and /var
[05:32:12] <jmkasunich> there's 300+ megs of .debs in /tmp
[05:32:21] <cradek> oh good
[05:32:28] <jmkasunich> I guess those can go away
[05:32:31] <cradek> a smoking gun is always nice
[05:32:46] <jmkasunich> I also had a many-meg farm log file
[05:33:07] <jmkasunich> the cvs error caused that to bloat by about a factor of 6
[05:33:38] <jmkasunich> is erasing debs gonna make apt get all confused?
[05:33:46] <cradek> not from /tmp
[05:33:47] <jmkasunich> or does it cache them somewhere else
[05:33:48] <jmkasunich> ok
[05:38:45] <jmkasunich> ok, freed up 380+ meg and started it again
[05:38:52] <jmkasunich> that slot only has a 2G disk
[05:38:58] <cradek> ok cool
[05:39:05] <cradek> darn I wanted to work on halcmd tonight, but didn't
[05:39:08] <cradek> tomorrow maybe
[05:39:18] <jmkasunich> yeah, its late
[05:39:22] <jmkasunich> what were you gonna do?
[05:39:26] <jmkasunich> oh, module-helper?
[05:39:29] <cradek> yeah
[05:39:35] <cradek> last piece of the puzzle
[05:39:55] <cradek> I set up run-in-place to use module_helper now too
[05:40:06] <cradek> so if halcmd does it, we can have ONLY module_helper setuid
[05:40:15] <jmkasunich> nice
[05:40:34] <jmkasunich> I saw something about having to tell ./configure if you want to do run-in-place
[05:40:43] <cradek> yes, we now have to decide at configure-time whether we are building for rip
[05:40:54] <jmkasunich> so if you enable rip, you disable install?
[05:41:04] <cradek> yes
[05:41:20] <cradek> you have to compile it one way or the other
[05:41:28] <jmkasunich> that is ok
[05:41:45] <jmkasunich> but the message at the end of configure should prominently identify which way it is set, and how to change it
[05:41:57] <cradek> the paths are hardcoded, there's nothing we can do (short of terrible hackery everywhere that guesses paths)
[05:42:16] <jmkasunich> don't want terrible hackery
[05:42:39] <jmkasunich> in fact, now that configure decides rip vs install, maybe that gawd awful mess in halcmd that tries to find the modules can go away
[05:42:49] <jmkasunich> HAL_RTMOD_DIR etc
[05:42:57] <cradek> yes it probably could
[05:43:53] <cradek> the same evilness is in the realtime script
[05:44:01] <cradek> maybe we should take a look at all of that together sometime
[05:44:05] <jmkasunich> yeah
[05:44:11] <jmkasunich> maybe this weekend?
[05:44:19] <cradek> sure
[05:45:15] <cradek> maybe we can even investigate throwing it all out and using depmod
[05:45:36] <jmkasunich> I don't like that
[05:45:45] <jmkasunich> maybe for the RTAI modules
[05:45:52] <jmkasunich> but HAL modules are NOT normal kernel modules
[05:46:10] <cradek> they are in that they depend on other things to be loaded first (have deps)
[05:46:19] <cradek> I think that's what depmod is for
[05:46:20] <jmkasunich> HAL just happens to use the kernel module mechanism to get loaded into memory
[05:46:39] <jmkasunich> but they don't become part of the kernel, they don't provide drivers or other services to the kernel
[05:46:40] <cradek> n.b. I haven't investigated this at all
[05:47:16] <jmkasunich> it is probably a matter of opinion
[05:47:26] <jmkasunich> I just have a strong opinion on the subject
[05:47:39] <jmkasunich> I want to keep them apart as much as possible from "normal" kernel modules
[05:47:41] <cradek> I don't, but I have a strong aversion to the current complexity
[05:47:58] <cradek> that's all
[05:48:04] <jmkasunich> HAL modules aren't complex, they depend only on hal and rtapi
[05:48:12] <jmkasunich> there is no inter-module dependency
[05:48:19] <jmkasunich> the complexity is the RTOS modules
[05:48:24] <cradek> I mean complexity of the parts like the realtime script
[05:48:27] <cradek> yeah
[05:48:28] <jmkasunich> and I'm not opposed to depmod there
[05:48:41] <cradek> ok we should investigate that scheme then
[05:48:42] <jmkasunich> I agree that realtime needs to be better
[05:49:02] <jmkasunich> but loadrt should not use depmod IMNSHO
[05:49:16] <cradek> are those always in exactly one dir?
[05:49:35] <cradek> if so, that's simple then, have the dir compiled in (like module_helper does)
[05:49:36] <jmkasunich> the hal ones? they should be
[05:49:53] <jmkasunich> for rip it is emc2/rtlib
[05:49:59] <jmkasunich> for installed, I'm not sure
[05:50:05] <cradek> it varies based on the system
[05:50:10] <cradek> but it's already figured out by configure
[05:50:13] <jmkasunich> right
[05:50:15] <cradek> (and compiled into module_helper)
[05:50:31] <cradek> so getting it into halcmd is virtually done
[05:50:54] <cradek> maybe we'll do that first
[05:51:08] <cradek> goodnight john, the screen is getting blurry
[05:51:23] <jmkasunich> goodnight
[05:51:34] <jmkasunich> I'm writing a list message, then I'm gone too
[05:52:00] <cradek> "you may not want to cvs up for a couple days" haha
[05:58:08] <jmkasunich> warnings are gone from BDI-Live build
[05:58:20] <jmkasunich> except that rt_task_init pointer type one
[05:58:36] <jmkasunich> maybe that needs an ifdef
[05:58:47] <jmkasunich> ifdef magma or something
[05:59:33] <jmkasunich> cool, BDI-4.20 succeeded too!
[05:59:39] <jmkasunich> bedtime
[05:59:56] <jmkasunich> jmkasunich is now known as jmk_away
[16:15:58] <rayh> * rayh needs some help
[16:17:02] <rayh> ubuntu sucks
[16:21:16] <rayh> gnome sucks
[16:23:19] <jepler> rayh: maybe I can help you
[16:23:26] <jepler> rayh: (I hate gnome too, fwiw)
[16:24:30] <rayh> How does a person make a copy of m5i20 and then find it to run.
[16:24:55] <rayh> Got a guy trying to run cradeks stuff now and it isn't going at all
[16:25:05] <jepler> what's m5i20?
[16:25:39] <jepler> there's an m5i20 directory under /etc/emc2
[16:26:16] <rayh> He can start the m5i20 from the first screen but when he makes a copy of it, and names it new, he can't find the new or find any way to run it.
[16:26:42] <rayh> He can't even navigate the file browser to / much less etc
[16:26:50] <jepler> Is he using that GUI thing to choose the configuration? I think it only lists the things from /etc
[16:27:13] <rayh> So how does he find and start his own?
[16:28:41] <jepler> If you run 'emc somedir' at the command prompt, it will use 'somedir' instead of anything under /etc/emc2
[16:29:20] <jepler> but I'm not sure how you create a working copy of m5i20 without using that window that pops up when you run 'emc' without an argument or from the icon
[16:29:32] <rayh> We tried that but didn't find the new directory he tried to make witht he setupconfig stuff.
[16:30:10] <rayh> Where does the setupconfig make a new configuration?
[16:30:14] <jepler> he couldn't find it, or he got an error?
[16:30:22] <jepler> I think setupconfig tries to create it in /etc/emc2 too
[16:30:32] <rayh> Got an error when entering emc pantec in a terminal
[16:30:46] <jepler> Error in startup script: can't create directory "asdf": permission denied
[16:30:46] <jepler> while executing
[16:30:46] <jepler> "file mkdir $new_config_name"
[16:30:48] <jepler> something like this?
[16:31:25] <rayh> So the icon does not have permission to make a new configuration?
[16:31:54] <jepler> Try this: sudo chown USERNAME /etc/emc2
[16:32:10] <jepler> Try this: sudo chown -R USERNAME /etc/emc2
[16:32:25] <jepler> until a new emc2 package is installed/upgraded, USERNAME should be able to edit the configs, copy them, etc
[16:34:34] <rayh> Okay trying that now.
[16:35:25] <jepler> by doing this, I was able to create a new config called 'mysim', based on 'sim'
[16:37:15] <jepler> trying to run m5i20 or a copy, I get an error, but I think it's just because I don't have the hardware
[16:37:21] <jepler> insmod: error inserting '/usr/realtime-2.6.12-magma/modules/emc2/hal_m5i20.ko': -1 Operation not permitted
[16:37:29] <jepler> but dmesg says [138465.493029] M5I20: **** No M5I20 card detected ****
[16:38:49] <rayh> We got a new config. Thanks.
[16:39:08] <rayh> Right You don't have one of those cards, yet.
[16:39:15] <jepler> "yet"?
[16:39:30] <rayh> Where would we find the installed version of the tickle stuff.
[16:39:51] <jepler> 'dpkg -L emc2' will show you all the files in the emc2 package
[16:39:57] <jepler> looks like it goes under /usr/share/emc
[16:41:17] <rayh> Thanks again.
[16:41:23] <jepler> I'm glad I can help
[16:41:39] <alex_joni> hello guys
[16:41:48] <rayh> Hi alex
[16:42:03] <rayh> phone trying to get a ubuntu guy running.
[16:42:11] <alex_joni> oh, coo
[16:42:16] <alex_joni> does he have any clue?
[16:43:48] <rayh> halconfig will not start up. can't find halcmd.
[16:45:39] <rayh> s**t. We lost another ubuntu user.
[16:46:56] <rayh> This guys just happens to be the "first" guy to apply a PC to motion.
[16:47:41] <rayh> It was his presentation at a conference that got FredP going on trajectory planning.
[16:47:45] <alex_joni> rayh: I think cradek said he would be happy to get feedback from new users
[16:48:03] <jepler> yeah, but it needs to be more useful than "this sucks, goodbye".
[16:48:05] <alex_joni> mostly from ones that can't use it
[16:48:19] <alex_joni> jepler: of course
[16:48:30] <rayh> Sorry. Thanks for trying jepp
[16:48:46] <rayh> jepler: Oh that's it.
[16:49:18] <rayh> Wow. What a different system that is.
[16:49:20] <jepler> that last bit was supposed to be sad/funny, maybe it didn't come out right.
[16:49:49] <rayh> I've tried gnome a couple of times but should not try to help with an emc with it.
[16:50:03] <rayh> np. Thanks a whole lot for your help.
[16:50:18] <rayh> Now I know where some of the installed files are.
[16:50:45] <rayh> We should put a list of locations on the wiki along with the way to make a copy of a config.
[16:50:58] <rayh> Where will configs be in a properly working system.
[16:53:12] <cradek> template/sample configs are in /etc/emc2; user configs are in /usr/local/etc/emc2
[16:53:27] <jepler> hi cradek
[16:53:36] <cradek> setupconfig doesn't do it right yet.
[16:53:39] <cradek> hi jepler
[16:54:57] <jepler> cradek: can I get the .config from your latest kernel without installing the linux-image deb?
[16:55:01] <cradek> because of the unfinished state of setupconfig, emc2 isn't ready for people who can't copy files/chown/etc
[16:55:20] <jepler> /usr/local/etc/emc2? Not ~/emc2 or something?
[16:56:13] <cradek> well it's an open question. the emc2 config is a mix of machine preferences (which go in a system folder such as /usr/local) and user preferences which go in a home directory
[16:56:33] <cradek> so I guess I'm not sure which we should pick.
[16:56:34] <alex_joni> cradek: maybe custom settings should go to ~/emc2
[16:56:44] <alex_joni> because they have been created by the user afterwards
[16:57:08] <alex_joni> I also favoured ~/nc_files as a default place for his NC files
[16:57:17] <alex_joni> but it's pretty much still open
[16:57:49] <rayh> If this machine was being used in a job shop, there will be several users, and a maintenence guy.
[16:57:57] <alex_joni> otoh, if you're thinking of a default machine & config, /etc/emc2 would be a good place
[16:58:11] <cradek> being an old unix user I'm always cognizant of systems being multiuser. seems the hardware attached to the machine is not a user preference, it's a system config.
[16:58:14] <alex_joni> rayh: right, so that means ~/emc2 is bad
[16:58:28] <alex_joni> cradek: you have a point there
[16:58:33] <rayh> yes for the basic configuration.
[16:58:48] <alex_joni> so basicly having /etc/emc2 for templates, and deb configs
[16:58:50] <cradek> but some of the things in our ini are definitely user prefs, like gui
[16:58:56] <alex_joni> and new ones go to /usr/local/..
[16:58:57] <cradek> units maybe
[16:59:10] <cradek> nc_files location
[16:59:19] <alex_joni> cradek: help file
[16:59:28] <cradek> yes help file/language
[16:59:44] <rayh> Wah! It really gets complex in a hurry.
[16:59:44] <cradek> well language, not necessarily help file
[16:59:50] <alex_joni> this reminds me (OT: we might want to have a LANG= in the ini)
[16:59:58] <jepler> alex_joni: Why?
[17:00:05] <cradek> rayh: maybe we need ini includes
[17:00:13] <cradek> alex_joni: no, no other app works that way
[17:00:16] <alex_joni> jepler: for users running from the menu, or does systemwide LANG work?
[17:00:31] <jepler> alex_joni: I think the normal system setting for language should be good enough
[17:00:33] <alex_joni> ok, I take it back
[17:00:53] <rayh> Sure. I can see that at Sherline in Vista. Some would use Spanish and some English.
[17:00:57] <alex_joni> I only tried LANG=foo emc, never tried to change systemwide configs
[17:01:07] <rayh> On the same puter.
[17:01:07] <alex_joni> Vista?
[17:01:27] <rayh> Near San Diego
[17:01:53] <rayh> Can each user select his own language preference?
[17:01:55] <alex_joni> oh, thought you meant somethign else..
[17:01:59] <alex_joni> rayh: sure
[17:02:12] <jepler> rayh: yes, the langauge is just part of the Unix environment
[17:02:40] <rayh> Then the user's language preference ought to be able to key tkemc?
[17:03:00] <alex_joni> and axis and mini(someday)
[17:03:31] <rayh> Okay.
[17:03:43] <alex_joni> rayh: thought you meant this:
http://www.microsoft.com/Windowsvista/
[17:03:43] <jepler> here's how I got emc to come up with german text on my ubuntu system: (unset LANGUAGE; export LANG=de; emc sim)
[17:03:51] <rayh> I've got a ubuntu disk on the way. Next day rush...
[17:04:02] <alex_joni> rayh: it'll blow your mind ;)
[17:04:06] <jepler> if a user preferred german text, the proper environment variables would already be set, and this would be unnecessary
[17:04:11] <alex_joni> I mean the new emc/ubuntu experience
[17:04:21] <rayh> I'll put another box on the net here.
[17:04:34] <alex_joni> jepler: I am sure there is a Sytem->configuration clickity way to do that
[17:04:56] <rayh> As folks around here say, alex_joni , I believe you but there's thousands that wouldn't"
[17:05:50] <rayh> I don't like gnome at all. Haven't since RedHat 5.0
[17:05:58] <alex_joni> I haven't either
[17:06:05] <alex_joni> but I only tried it way back
[17:06:20] <alex_joni> it doesn't look like any gnome I ever tried
[17:06:44] <rayh> Okay. I'll erase my prejudice...
[17:06:54] <rayh> and create a new one.
[17:07:11] <alex_joni> lol, basicly start with no prejudice
[17:07:26] <cradek> rayh: I hope you can come at all of this with an open mind. I know you've had problems with bdi packages, old gnome, etc., but I hope you can work with us to make this work right
[17:07:41] <rayh> That's hard for an old guy to do.
[17:08:00] <alex_joni> rayh: all your nagging only makes us do it better ;)
[17:08:09] <alex_joni> if you don't mind me saying that
[17:08:14] <rayh> Yep. We have to make it workable.
[17:08:14] <cradek> I think it's critical to the success of emc2 that we have an easy to install, easy to use system.
[17:08:54] <cradek> and that the packagers, board, developers, etc all work together and not at odds
[17:09:07] <cradek> we haven't had that for a while, now we can
[17:09:20] <rayh> I recognize that I'm trying to provide help for a system I know little about.
[17:09:45] <alex_joni> cradek: have we ever?
[17:09:53] <cradek> rayh: I'm always willing to help.
[17:10:02] <alex_joni> except the times when it was NIST's project
[17:10:33] <cradek> alex_joni: I don't know the whole history
[17:10:43] <cradek> alex_joni: but we haven't had it since I've been around.
[17:10:55] <alex_joni> ditto, although I'm newer
[17:11:47] <rayh> I think that we have come a long way with emc2 and ubuntu in the last six months.
[17:12:27] <alex_joni> I think more likely six weeks
[17:13:33] <rayh> It looks like the emc2 system that is in the apt was from the time when there were problems with how to run halconfig.
[17:13:54] <rayh> It wasn't under the tkemc scripts menu yet.
[17:14:08] <rayh> and it couldn't run from a terminal.
[17:14:16] <cradek> I'm sure it's in the tkemc menu
[17:14:32] <cradek> that's how I first ran it
[17:14:37] <alex_joni> it might be older
[17:14:37] <rayh> This was an apt from last night.
[17:14:43] <alex_joni> then it should be there
[17:14:50] <cradek> are you running sim? I ran sim
[17:15:00] <rayh> This wasn't my run.
[17:15:09] <alex_joni> was it tkemc for sure?
[17:15:13] <rayh> It was a m5i20 board
[17:15:48] <rayh> the only thing under scripts was the configuration gui.
[17:16:53] <cradek> my scripts menu has Set_Coordinates and HAL Config
[17:17:10] <cradek> HAL Config runs fine
[17:17:26] <cradek> this is emc2 2.0.0-alpha17
[17:17:47] <rayh> Gotta get out of here for a bit.
[17:17:49] <alex_joni> rayh: btw, how come the users jumped on the ubuntu train?
[17:18:13] <alex_joni> s/users/user/
[17:18:32] <rayh> These guys are wanting to test this board
[17:19:07] <alex_joni> I see
[17:19:08] <rayh> without having to compile.
[17:19:32] <cradek> it would be better if setupconfig was done.
[17:19:48] <alex_joni> cradek: and make install to make a new deb ;)
[17:19:53] <rayh> right. and halconfig as well.
[17:20:08] <cradek> alex_joni: probably today
[17:20:24] <rayh> bbl
[17:22:18] <jepler> cradek: are you saying you're going to fix 'make install'?
[17:22:25] <jepler> cradek: or that you expect me to do it today?
[17:22:51] <cradek> jepler: If you don't plan on doing it, I'll try to do it today
[17:23:01] <alex_joni> * alex_joni can help
[17:23:05] <cradek> jepler: I want the ability to make new debs soon
[17:23:19] <alex_joni> although looking at the Makefile my enthusiasm goes away :)
[17:23:24] <jepler> There shouldn't be anything subtle about 'make install'
[17:24:11] <jepler> alex_joni: What, you get put off by lines that read like this? TORTOBJS = $(foreach file,$($(patsubst %.o,%,$(1))-objs), objects/rt$(file))
[17:24:27] <alex_joni> no, those are fine
[17:24:43] <jepler> What bothers you, then?
[17:24:53] <alex_joni> hang on, pasting soon ;)
[17:25:09] <cradek> I admit make has an odd way of declaring functions
[17:26:07] <alex_joni> depends/%.d: %.c
[17:26:07] <alex_joni> @mkdir -p $(dir $@)
[17:26:07] <alex_joni> @echo Depending $<
[17:26:22] <alex_joni> kidding, that line you pasted makes a good example
[17:28:41] <jepler> To do the non-recursive Make you end up doing a lot more complicated things in the Makefile, it's true
[17:29:04] <alex_joni> jepler: I'm sure it's not that complicated, once you know how to read it
[17:29:32] <jepler> and also you shouldn't have to look at the complicated parts to write 'make install'
[17:29:42] <jepler> install: userspace modules; all the stuff make install used to say
[17:29:51] <alex_joni> how about using the make install that was there?
[17:30:00] <cradek> alex_joni: I use Quick Reference on the make info page a LOT
[17:30:16] <alex_joni> * alex_joni never has
[17:30:23] <alex_joni> probably I should do so too
[17:30:28] <cradek> it is a very nice summary
[17:30:56] <cradek> `$(patsubst PATTERN,REPLACEMENT,TEXT)'
[17:30:56] <cradek> Replace words matching PATTERN with REPLACEMENT in TEXT.
[17:31:31] <alex_joni> ok, guys I need to get back and finish my presentation
[17:31:37] <alex_joni> I'll be reading in here on and off
[17:32:39] <jepler> * jepler idles too
[17:33:09] <alex_joni> darn projects.. don't really want to do that now, but I'm leaving on monday, so I need to have it done by then
[17:35:58] <cradek> I also have other work to do today
[17:36:03] <cradek> but maybe in the evening I'll work on emc
[20:06:25] <jmk_away> jmk_away is now known as jmkasunich
[20:10:29] <alex_joni> hi john
[20:12:08] <jmkasunich> hi
[20:12:42] <jmkasunich> I was reading back - ray's comments make me feel like I'm standing in front of a bus trying to stop it
[20:13:05] <jmkasunich> (because someone is trying to drive it away while we have it up on jacks to change the tires)
[20:27:09] <alex_joni> heh
[20:28:47] <jmkasunich> my opinion of the present stage of development is this:
[20:29:06] <jmkasunich> If you are gonna go away in a huff as soon as things don't work, then the project isn't ready for you, come back later
[20:29:17] <alex_joni> fully agreed
[20:29:29] <jmkasunich> if you are gonna help test, find bugs, and give us good usable reports, then we'll do our best to help you in return
[20:29:41] <alex_joni> although last week might have been a bit more stable than today, but it'll get better
[20:30:11] <alex_joni> or you weren't literally refering to 'today' ?
[20:30:37] <jmkasunich> last month, this week, next week
[20:30:47] <alex_joni> ok
[20:30:47] <jmkasunich> basically, until we issue a release candadate
[20:30:58] <alex_joni> well, the deb's are still named alpha
[20:31:02] <alex_joni> and that usually means alpha
[20:31:25] <alex_joni> we're working towards a beta soon, (we might even be there)
[20:31:33] <jmkasunich> in a few days
[20:31:39] <alex_joni> but beta will be when setupconfig works ok, and halconfig works ok
[20:31:55] <jmkasunich> setupconfig was built and tested in rip mode, needs work yet for installed mode
[20:31:59] <alex_joni> setupconfig is limited usefull for installed versions
[20:32:02] <alex_joni> right
[20:32:35] <alex_joni> it's lacking the /usr/share/emc2/configs/ support
[20:32:36] <jmkasunich> I can't believe some generic user is out there using setupconfig in installed mode and then calling ray about it
[20:32:42] <jmkasunich> that's just insane
[20:33:00] <alex_joni> my bet it's the other way around
[20:33:12] <jmkasunich> huh?
[20:33:13] <alex_joni> they called ray and he suggested ubuntu/deb
[20:33:26] <alex_joni> for a quick starters on m5i20
[20:33:34] <alex_joni> without the need of recompiling
[20:33:40] <jmkasunich> so far he hasn't been all that enthusiastic about ubuntu
[20:33:55] <alex_joni> right, but otoh not many places to read about that either
[20:34:59] <jmkasunich> I'm kinda dissapointed at the deafening silence after my email about dropping support for BDI-2.x
[20:35:18] <jmkasunich> only reply was jepler saying he'll work on getting it to compile
[20:36:37] <alex_joni> seems most users are not participating at all in any conversation
[20:36:51] <alex_joni> I just looked at frappr.. there are 64 registered users there
[20:37:04] <alex_joni> that should be 2 digits off
[20:38:53] <jmkasunich> at least 1 digit, just based on the list subscribers
[20:39:09] <alex_joni> yeah, and based on sherline another digit
[20:39:44] <jmkasunich> yeah, but 99% of sherline users are completely unaware of the lists and anything else except the manual they got with the machine and Ray's phone number
[20:39:56] <jmkasunich> and they ignore the number too, unless they have a problem
[20:40:21] <jmkasunich> they don't even know about frapper, and even if they did they wouldn't bother joining it
[20:40:38] <jmkasunich> to them EMC is just another product, not a club to join
[20:40:52] <alex_joni> http://5128.rapidforum.com/topic=115676084706
[20:40:58] <alex_joni> heh, those guys are quick ;)
[20:41:19] <jmkasunich> I can't read german
[20:42:32] <alex_joni> it's just a translation
[20:42:38] <alex_joni> but dated on the same day
[20:42:51] <jmkasunich> translation of what?
[20:44:02] <alex_joni> of my news item at Sourceforge
[20:44:36] <alex_joni> Posted By: alex_joni
[20:44:36] <jmkasunich> I figured out why I'm so confused (after I babelfished it)
[20:44:36] <alex_joni> Date: 2006-02-05 02:37
[20:44:36] <alex_joni> Summary: emc2 approaching release
[20:44:36] <alex_joni> Lots of work has been done recently on emc2, and it is almost ready for an initial release.
[20:44:39] <alex_joni> Check again soon for notifications about a first beta release. Until then you can try emc2 by using a CVS checkout of the code.
[20:44:42] <alex_joni> If you still have requests please use the Feature Request section to let us know.
[20:44:48] <alex_joni> why are you so confused?
[20:44:49] <jmkasunich> the URL doesn't work for me, so I got a german error message
[20:45:05] <alex_joni> ahhh.. oops, forgot you need to be signed up on that forum
[20:45:11] <jmkasunich> lol
[20:46:20] <jmkasunich> I wonder where cradek is?
[20:46:36] <jmkasunich> * jmkasunich needs help to get setupconfig working in "installed mode"
[20:46:41] <alex_joni> he had some stuff to do
[20:46:45] <alex_joni> jmkasunich: I can help
[20:46:53] <alex_joni> at least with install specifics issues
[20:46:58] <jmkasunich> you may regret saying that ;-)
[20:46:59] <alex_joni> but I can't help with tcl
[20:47:01] <jmkasunich> but ok
[20:47:08] <alex_joni> yeah I know
[20:47:09] <alex_joni> :D
[20:47:21] <alex_joni> ok. let me start with the problems
[20:47:28] <jmkasunich> first problem is that the program needs to know whether it is rip or installed
[20:47:35] <jmkasunich> if rip, all configs are in subdirs of configs/
[20:47:39] <alex_joni> that's easier
[20:47:47] <jmkasunich> if installed, samples are in one place, user configs in another
[20:47:48] <alex_joni> it already does that
[20:48:04] <jmkasunich> and it should probably present the user with a list showing both
[20:48:08] <alex_joni> because it gets the config dir from teh runscript
[20:48:17] <alex_joni> so that works for both
[20:48:28] <jmkasunich> from the runscript? that sucks
[20:48:36] <jmkasunich> means it is broken when run alone
[20:48:42] <alex_joni> heh, you did that iirc
[20:49:07] <cradek> I'm here now
[20:49:09] <alex_joni> $SETUPCONFIG --configs-dir $EMC2_CONFIG_DIR --get-config $1)
[20:49:27] <alex_joni> jmkasunich: the main problem is that there is no default dir for the installed version
[20:49:36] <alex_joni> it's all configurable at ./configure time
[20:50:00] <cradek> darn, I shouldn't have said anything, this looks tough
[20:50:09] <alex_joni> cradek may want to place configs into /etc/emc2, I might want to place them in /usr/local/configs/emc2
[20:50:17] <jmkasunich> # --configs-dir <dir>
[20:50:17] <jmkasunich> #
[20:50:17] <jmkasunich> # Assume that <dir> is the configs/ directory, and that
[20:50:18] <jmkasunich> # subdirectories of <dir> contain individual configs.
[20:50:18] <jmkasunich> # If --configs-dir is not given, the script attempts to
[20:50:19] <jmkasunich> # find the directory itself, but that works only if the
[20:50:20] <jmkasunich> # environment variable EMC2_ORIG_CONFIGS_DIR is set, or
[20:50:22] <jmkasunich> # if the script was run from the configs dir, or one
[20:50:24] <jmkasunich> # directly above or below it.
[20:50:43] <jmkasunich> the "find the directory itself" part was based on rip only
[20:50:47] <jmkasunich> shortsighted I know
[20:50:52] <cradek> how about making --configs-dir take a PATH-like list
[20:50:54] <alex_joni> jmkasunich: I think the proper fix is to have setupconfig be touched by configure
[20:51:08] <alex_joni> so it KNOWS where stuff is
[20:51:25] <alex_joni> and doesn't need to worry about searching and guessing and assuming
[20:51:30] <cradek> alex_joni: maybe there's no need for that since emc.in can provide it on the commandline?
[20:51:44] <alex_joni> cradek: jmk was talking about running setupconfig independently
[20:51:47] <jmkasunich> assuming that emc.in is calling setupconfig
[20:51:49] <cradek> oh
[20:52:07] <alex_joni> that way setupconfig knows where emc is, so that part is fixed too
[20:52:09] <jmkasunich> I don't know if setupconfig needs to be able to run alone, but its nice
[20:52:18] <cradek> yeah then you have to process it with configure I guess
[20:52:28] <cradek> I'm hesitant to touch more than necessary with configure
[20:52:38] <cradek> because everything turns into this.in and that.in, which sucks
[20:52:44] <jmkasunich> a path type approach is kinda ok, but there should really be two seperate dirs (or paths)
[20:52:49] <alex_joni> well.. this.tcl.in
[20:52:59] <alex_joni> jmkasunich: or more than two
[20:53:07] <alex_joni> the PATH approach might allow that
[20:53:19] <jmkasunich> one for samples (which might be RO) one for user configs (which is RW, and the target for the "NEW" command)
[20:53:33] <alex_joni> setupconfig --with-config-dirs=/etc/emc2:/usr/share/emc/configs/:~/emc2/configs/
[20:53:40] <jmkasunich> I think Ray's owner got stung by the RO part
[20:53:52] <alex_joni> yeah, but jepler solved that one quickly
[20:53:57] <jmkasunich> how?
[20:54:01] <alex_joni> sudo chown -R USER /etc/emc2
[20:54:10] <jmkasunich> that doesn't solve it
[20:54:10] <cradek> ouch
[20:54:18] <jmkasunich> that made one guy happy (maybe)
[20:54:19] <cradek> it doesn't solve it right...
[20:54:29] <alex_joni> I didn't say it's right
[20:54:35] <alex_joni> I said it was quick
[20:54:37] <alex_joni> :-)
[20:54:44] <alex_joni> now we have the task to solve it for good
[20:54:46] <jmkasunich> you said it was solved ;-P
[20:54:55] <alex_joni> yeah, for ray's owner
[20:55:03] <cradek> who owns ray?
[20:55:08] <alex_joni> cradek: customers
[20:55:20] <jmkasunich> "a bug ain't solved until the solution is committed to CVS"
[20:55:31] <alex_joni> oh, CVS is still not solved
[20:55:32] <alex_joni> :)
[20:55:44] <alex_joni> ok, let's not worry semantics right now
[20:55:52] <alex_joni> we got 2 possible solutions
[20:56:08] <alex_joni> 1. have configure touch setupconfig.tcl.in and replace path's & co
[20:56:36] <alex_joni> 2. have setupconfig.tcl be run only from emc with a list of files supplied (or maybe even from the menu, with the same list supplied)
[20:56:41] <jmkasunich> we actually have two problems too:
[20:57:07] <jmkasunich> 1) modify setupconfig.tcl to deal with multiple places where config can be stored, some of which are RO
[20:57:17] <jmkasunich> 2) figure out how to tell it where those places are
[20:57:34] <alex_joni> --with-template-dir --with-config-out-dir ?
[20:57:38] <cradek> setupconfig can simply use stat to see if writing configs in a certain place is possible
[20:57:57] <jmkasunich> cradek: yes, that is one possible solution to problem 1
[20:57:58] <cradek> maybe I want to make a new template for my site in /usr/local/etc/emc2
[20:58:18] <jmkasunich> I like alex's - two dirs (or paths)
[20:58:45] <alex_joni> jmkasunich: we should allow more than one for the first path
[20:59:09] <jmkasunich> for problem 2, instead of setupconfig.tcl.in, how about emc_dirs.in
[20:59:23] <alex_joni> --with-template-dir=/etc/emc2:/usr/local/etc/emc2:~/emc2 --with-config-out-dir=~/emc2
[20:59:24] <jmkasunich> that would contain ONLY directories, paths, et
[20:59:27] <jmkasunich> etc
[20:59:40] <jmkasunich> other scripts (realtime, setupconfig, etc) could source it
[20:59:43] <alex_joni> you still get the problem where does emc_dirs.in go to
[20:59:49] <alex_joni> and how you find that
[21:00:05] <jmkasunich> it goes the same place the executables go
[21:00:06] <alex_joni> realtime goes to /etc/init.d/
[21:00:14] <alex_joni> executables go to /usr/bin
[21:00:15] <jmkasunich> oh...
[21:00:19] <jmkasunich> :-(
[21:00:25] <alex_joni> tcl stuff goes to /usr/share/emc/tcl
[21:00:30] <alex_joni> need I go on?
[21:00:33] <alex_joni> ;-)
[21:00:38] <jmkasunich> drat
[21:00:49] <jmkasunich> I like the idea of all this damned directory stuff in one place
[21:01:07] <alex_joni> yeah, the problem is where is that
[21:01:42] <jmkasunich> cradek: can you enlighten me on exactly how rip vs install are handled now?
[21:01:58] <jmkasunich> if you ./config for rip, what happens if you do "make install"
[21:02:11] <jmkasunich> if you ./config for install, what happens if you try to run it?
[21:02:13] <cradek> right now, it will install a non-working setup
[21:02:28] <cradek> you'll probably get errors when inserting modules
[21:02:28] <alex_joni> no, rght now it will barf because there is no make install
[21:02:34] <cradek> well that's true
[21:02:47] <jmkasunich> so both cases are messed up
[21:03:05] <jmkasunich> make install when built for rip should do nothing except an error message
[21:03:05] <cradek> yeah, you have to decide at configure time whether you are installing or not
[21:03:14] <cradek> I agree
[21:03:20] <alex_joni> we can do that
[21:03:27] <alex_joni> replace dirs with error messages
[21:03:51] <alex_joni> $bindir=nodir
[21:03:51] <cradek> alex_joni: we'll have to get $RUN_IN_PLACE into make (it's not written out to Makefile.inc right now) and then just test it
[21:04:01] <cradek> that will be the most explicit way to do it
[21:04:01] <alex_joni> yeah, that too
[21:04:14] <cradek> easy to solve
[21:04:17] <alex_joni> RUN_IN_PLACE=@RUN_IN_PLACE@
[21:04:24] <cradek> yeah
[21:04:25] <alex_joni> into Makefile.inc.in
[21:04:42] <cradek> we can have that in scripts/emc too if we want
[21:04:45] <alex_joni> do you guys mind if I leave for 20 minutes?
[21:04:46] <cradek> I didn't because it's not needed right now.
[21:04:53] <cradek> of course not
[21:04:58] <alex_joni> yeah, scripts/emc has a workaround
[21:05:01] <jmkasunich> alex: when you gotta go, you gotta go ;-)
[21:05:07] <alex_joni> my water is getting cold..
[21:05:17] <alex_joni> * alex_joni goes to relax in a nice hot tub
[21:05:25] <cradek> a nice lukewarm tub
[21:05:25] <alex_joni> at least I hope it's still hot :D
[21:05:56] <alex_joni> hp2emc
[21:05:57] <alex_joni> hp2emc ist ein Tool, das aus einer HPGL-Plotter Datei funktionsf�higen Code f�r die EMC erzeugt. Das ganze basiert auf dem Tool hp2xx, welches die plt in NC-Code umwandelt. Das hp2emc Programm f�gt noch Header und Footer f�r EMC hinzu und bietet weiter vielf�ltige Optionen.
[21:06:24] <alex_joni> hp2emc is a tool, that generates functional G-Code for EMC out of a HPGL-plotter file.
[21:06:28] <jmkasunich> hey, I can almost read that
[21:06:40] <alex_joni> http://www.go2web.net/dlr/linuxcnc/index.htm
[21:08:17] <alex_joni> * alex_joni will be back
[21:08:26] <cradek> jmkasunich: how can I help? or should I busy myself with make install?
[21:08:28] <jmkasunich> splish splash
[21:08:57] <jmkasunich> I can write the tcl (eww, I can't believe I said that) but I need someone to bounce ideas off of and decide how it should work
[21:09:08] <cradek> ok bounce away
[21:09:40] <jmkasunich> when we present a list of configs to run, they will come from multiple dirs
[21:09:58] <jmkasunich> same as when the list of templates when doing a "new"
[21:10:12] <jmkasunich> the destination of the "new" will now need to be specified somehow
[21:10:36] <jmkasunich> the backup and restore commands are also getting messy
[21:10:54] <jmkasunich> I was going to use configs/backup
[21:11:42] <jmkasunich> seems like we need to back up a little
[21:12:03] <cradek> backup/restore to/from home dir maybe?
[21:12:09] <jmkasunich> maybe
[21:12:20] <jmkasunich> only dir that the user has guaranteed write access to
[21:12:44] <cradek> or maybe ~/Desktop on ubuntu
[21:12:47] <jmkasunich> we have a high risk of getting into policy here
[21:12:59] <cradek> yeah
[21:13:10] <cradek> here's how I look at it
[21:13:16] <cradek> we kind of know what we're doing with unix
[21:13:22] <cradek> so we should provide sensible policy defaults.
[21:13:30] <jmkasunich> what is right for a one man shop like you or I isn't right for a real shop with a supervisor who makes/edits configs and operators who just run the machine
[21:13:41] <cradek> we should not unnecessarily restrict anybody's ability to change the policy.
[21:13:57] <jmkasunich> agreed
[21:14:06] <cradek> jmkasunich: we need sensible defaults + configurability
[21:14:21] <cradek> jmkasunich: configurability should come from unix in the normal way as much as possible (permissions, groups etc)
[21:14:27] <jmkasunich> right now setupconfig has a lot of policy embedded in it
[21:14:39] <cradek> that's why I'm rooting for a PATH-like specification
[21:14:40] <jmkasunich> if you can run emc, you can create a new config
[21:14:56] <cradek> and using stat to determine whether to allow creation/editing
[21:15:02] <jmkasunich> (or you can attempt to create a new config, then get a lot of cryptic error messages if you don't have rights)
[21:15:16] <jmkasunich> yeah, that makes sense
[21:15:30] <jmkasunich> I wonder how tcl's support for stat is?
[21:15:36] <cradek> so as an administrator, I can make emc-users and emc-administrators groups if I want
[21:16:02] <jmkasunich> yes
[21:16:25] <cradek> I can't find the tcl manpages... I bet there's [file writable ...] etc
[21:17:00] <jmkasunich> I have O'Reilly's "TCL/TK in a Nutshell", looking now
[21:17:34] <jmkasunich> file owned returns 1 if owned by current user, else 0.... might be usefull
[21:18:09] <jmkasunich> yes, "file writable" exists
[21:18:21] <jmkasunich> how does that work for creating a new file (or dir)
[21:18:30] <jmkasunich> you need write acces to the containing dir?
[21:18:35] <cradek> yes
[21:19:10] <jmkasunich> so on a "new" it could iterate down the path and select only the dirs that are writable
[21:19:24] <cradek> yes I think that's the right thing to do
[21:19:25] <jmkasunich> if only 1, cool, if not, present the list to the user and make 'em choose
[21:19:31] <cradek> yes
[21:19:57] <cradek> and the deb should install /etc/emc2 non-writable
[21:20:06] <cradek> (sensible default #1)
[21:20:18] <jmkasunich> an alternate approach would be a file picker dialog where we let them put the new config "anywhere" and name it anything
[21:20:28] <jmkasunich> less custom code
[21:20:37] <cradek> but then you have a problem finding it later.
[21:20:39] <jmkasunich> but setupconfig would be unable to find the new confis
[21:20:42] <jmkasunich> ;-)
[21:21:28] <jmkasunich> so one path, not two, and we use writability to decide where to stick new configs
[21:22:10] <cradek> that's my preference
[21:22:24] <cradek> ideally the path is expanded at runtime so you can put $HOME in it
[21:22:58] <cradek> that would allow for user-specific configs if someone wants them
[21:23:05] <jmkasunich> yeah
[21:23:18] <jmkasunich> I saw a conversation earlier that was a brain bender
[21:23:43] <jmkasunich> machine config is the same for all users in a shop, but some want differnt GUIs or languages
[21:23:52] <cradek> different languages is easy
[21:23:57] <jmkasunich> I gathered from the conversation that languages would take care of themselves
[21:23:58] <cradek> different guis is currently not possible
[21:24:04] <cradek> yes, that's automatic
[21:24:30] <cradek> it's my opinion that system config and user preferences are separate, but we have them together
[21:24:30] <jmkasunich> different guis
[21:24:40] <jmkasunich> yes, that is the fundamental problem
[21:25:00] <cradek> we could fix it in inifind
[21:25:06] <jmkasunich> choice of GUI is somewhere in the middle
[21:25:11] <jmkasunich> policy again
[21:25:16] <cradek> I think gui is a user preference
[21:25:28] <cradek> think of it as a "theme" in modern apps - definitely user pref
[21:25:31] <jmkasunich> a shop owner may want all his users to have the same GUI, so the forman can help the machine operator if he gets confused
[21:25:50] <jmkasunich> themes are less invasive
[21:26:03] <jmkasunich> changing from axis to mini is NOT just a theme change
[21:26:37] <cradek> let's not argue over details :-)
[21:26:43] <jmkasunich> yeah
[21:26:55] <cradek> I have some thoughts on a solution
[21:27:03] <jmkasunich> unless we figure out a way to separate out GUI choice, its irrelevant anyway
[21:27:08] <cradek> inifind could read the base ini and then ~/.emc2rc
[21:27:15] <cradek> things in ~/.emc2rc override the ini settings
[21:27:40] <cradek> so I can have everything the system config has, except I want a different gui
[21:27:51] <cradek> or my nc_files are in a different place
[21:27:53] <jmkasunich> interesting
[21:27:54] <cradek> or etc
[21:28:02] <jmkasunich> lots of apps work that way don't they
[21:28:04] <cradek> yes
[21:28:14] <jmkasunich> kind of a heirarchy of config files
[21:28:25] <cradek> yes, with the more personal overriding the more general
[21:28:50] <jmkasunich> but how far do you let that go? do you let the personal reconfigure the HAL?
[21:28:58] <jmkasunich> policy again
[21:29:14] <cradek> yeah none of that is clear, I am just thinking of the concept in general
[21:29:28] <jmkasunich> I like it, but I think its more of a 2.2 thing
[21:29:32] <cradek> possibly we could move some things into a [USER_PREFS] section
[21:29:42] <jmkasunich> oh, that sounds good
[21:29:43] <cradek> or something like that, and have .emc2rc override just those things
[21:30:10] <cradek> but then we have to decide what's a user pref and what's not!
[21:30:41] <jmkasunich> in halcmd setp, a plain number is a value
[21:30:53] <jmkasunich> $name fetches from environment
[21:31:01] <jmkasunich> and [name]name fetches from ini file
[21:31:19] <jmkasunich> could we use the [name]name syntax in the ini file to let any var be fetched from another section
[21:31:33] <jmkasunich> the other section could be USER_PREFS
[21:31:44] <jmkasunich> the base ini determines which things are hard coded and which are prefs
[21:31:52] <jmkasunich> the base ini is RO to the user
[21:32:24] <jmkasunich> the USER_PREF section of the base ini defines the default prefs, they can be overridden by the .emc2rc
[21:32:40] <cradek> I see what you're getting at
[21:32:44] <cradek> so the ini decides what is a user pref
[21:32:53] <cradek> sure I think we could do that
[21:33:03] <jmkasunich> that way we provide mechanism, and the choice of hard coded or indirect references defines policy
[21:33:26] <cradek> as my friend used to say "it's just a simple matter of programming" (he said that when something was really hard)
[21:33:32] <jmkasunich> heh
[21:33:42] <jmkasunich> it could get messy
[21:33:54] <jmkasunich> multiple levels of indirection, or worse, circular references
[21:33:57] <cradek> yeah.
[21:34:24] <cradek> should we go back to concentrating on what we need to do today? how can I help with that?
[21:34:34] <jmkasunich> setupconfig
[21:34:51] <cradek> right, ok, so there's a path
[21:35:19] <cradek> --configs-dir '/a:/b:$HOME/c'
[21:35:25] <jmkasunich> we decided that --configs-dir <dir> will be replaced by --configs-dirs <dir>[;dir][;dir]
[21:35:35] <cradek> :
[21:35:39] <jmkasunich> ok
[21:35:51] <jmkasunich> I wasn't sure what the convention was
[21:36:04] <jmkasunich> that can get turned into a tcl list easily
[21:36:15] <jmkasunich> ok, suppose nothing is passed
[21:36:34] <jmkasunich> (for instance if it's invoked directly)
[21:36:42] <jmkasunich> now, it tries to guess
[21:36:45] <cradek> here's the tricky part. We need to decide whether we want it invoked directly. I don't think we want that.
[21:36:45] <jmkasunich> worked for rip
[21:37:05] <cradek> why not get it by running emc, and then hit cancel instead of running? it works the same.
[21:37:31] <jmkasunich> its nice for development testing (and for the unix principle of standalone things working together)
[21:37:41] <jmkasunich> but for testing, I can pass --config-dirs
[21:37:46] <cradek> true
[21:38:00] <jmkasunich> so if no --config-dirs it will print a message and exit?
[21:38:06] <cradek> currently setupconfig isn't in the user's path
[21:38:19] <cradek> so the user will not run it standalone anyway (without hunting for it)
[21:38:40] <jmkasunich> yeah, but we still need to decide what it will do if invoked without that option
[21:38:49] <cradek> yeah I vote for an error message
[21:39:00] <jmkasunich> ok, error and exit
[21:39:05] <jmkasunich> just thought of another complication
[21:39:15] <jmkasunich> with only one dir, config names are unique
[21:39:31] <jmkasunich> with a path, you could have two configs both called "foo"
[21:39:36] <cradek> true
[21:39:48] <jmkasunich> so I guess the pick list needs to show the path, not just the name
[21:39:50] <jmkasunich> messy
[21:40:13] <cradek> yeah, ick
[21:40:27] <jmkasunich> how does unix do it
[21:40:29] <cradek> but it's likely I will want to copy the template "stepper" and make a local "stepper" with a few things changed
[21:40:32] <jmkasunich> runs the first match it finds
[21:40:45] <cradek> with PATH? yes
[21:41:08] <cradek> I'm not sure this is exactly like PATH
[21:41:26] <jmkasunich> not exactly
[21:41:43] <jmkasunich> similar tho - if I say "emc foo", I want to run the first "foo" in the path
[21:41:45] <cradek> PATH is not used to present you with choices
[21:41:51] <cradek> yeah, that's probably true
[21:42:00] <cradek> presentation in the gui is the things that's not typical
[21:42:04] <cradek> thing
[21:42:18] <jmkasunich> yeah
[21:42:33] <jmkasunich> well, if I say "emc foo", I don't expect to get the gui
[21:42:43] <jmkasunich> because I already made my choide
[21:42:47] <cradek> agreed
[21:43:08] <jmkasunich> so its PATH like when passing a config name to emc
[21:43:16] <cradek> ok, I'll buy that
[21:43:55] <jmkasunich> I wonder if were trying to use one program to do too many things
[21:44:33] <cradek> I honestly don't know that answer
[21:44:37] <jmkasunich> picking a config to run, and making a new config
[21:45:53] <jmkasunich> ok, lets consider a possiblity:
[21:46:03] <jmkasunich> a prog called "choose_config"
[21:46:07] <alex_joni> back..
[21:46:08] <jmkasunich> accepts the following:
[21:46:14] <alex_joni> * alex_joni had a great idea
[21:46:22] <alex_joni> tell me what you think..
[21:46:23] <jmkasunich> --config-path=dir[:dir]
[21:46:34] <jmkasunich> --config <name>
[21:46:37] <jmkasunich> --ini <name>
[21:47:00] <jmkasunich> requires --config-path
[21:47:03] <jmkasunich> the other two are optional
[21:47:14] <jmkasunich> if config is given, search path for it
[21:47:31] <jmkasunich> if config contains multiple ini files, use --ini to pick one
[21:47:35] <alex_joni> right now we are running tcl/bin/halconfig & setupconfig.tcl, right? How about we make those not executable (-x), but instead let make create 2 simple bash files in bin/ with the proper dirs in them? (e.g. bin/setupconfig and bin/halconfig)
[21:47:39] <jmkasunich> if --ini isn't given, GUI to choose
[21:47:45] <jmkasunich> if --config isn't given, GUI to choose
[21:48:29] <jmkasunich> alex: that solves the problem of getting --configs-path into the tcl without setupconfig.tcl.in
[21:48:41] <jmkasunich> back to the picker
[21:48:51] <jmkasunich> it ONLY picks a config to run
[21:48:54] <cradek> jmkasunich: this would remove the choose-a-config-to-run part from setupconfig?
[21:49:01] <jmkasunich> yes
[21:49:14] <jmkasunich> no "new" option, no backup or restore or edit
[21:49:51] <jmkasunich> those functions would be handled by something else (perhaps still called setupconfig, that name seems appropriate)
[21:50:32] <jmkasunich> of course, I don't know how you would invoke setupconfig
[21:50:42] <cradek> you think choose-a-config-to-run and manipulate-the-configs are two separate tasks
[21:50:52] <jmkasunich> kinda
[21:51:08] <jmkasunich> every machine operator in the shop will do the former every morning
[21:51:14] <cradek> jmkasunich: it'll go on the applications menu, of course
[21:51:24] <jmkasunich> only the integrator/foreman/owner will do the latter
[21:51:28] <jmkasunich> what applications menu?
[21:51:38] <jmkasunich> oh, you mean another icon at the OS level?
[21:51:40] <cradek> jmkasunich: the one emc is currently in
[21:51:55] <jmkasunich> "Run EMC" "Configure EMC"
[21:51:58] <cradek> sure
[21:52:25] <jmkasunich> in a way, thats what I had in mind for when someone directly invokes setupconfig.tc
[21:52:26] <cradek> and equivalent bins in the path: emc emc-configuration
[21:52:35] <alex_joni> right, and the configure EMC will call the small bash I talked about
[21:53:28] <alex_joni> jmkasunich: do you plan to rip the config-picker out?
[21:53:31] <alex_joni> into a new file?
[21:53:40] <jmkasunich> we're just discussing possibilities
[21:53:50] <alex_joni> seems better
[21:53:52] <jmkasunich> but I'd be willing to do it if we thought it was the right thing to do
[21:54:04] <alex_joni> and there"s one more thing
[21:54:23] <alex_joni> we really need to do the default config stuff
[21:54:25] <jmkasunich> probably wind up with three files, one with common code (present a list of configs and select one, used for run and for new (to pick the template) )
[21:54:52] <jmkasunich> what do you mean about default config stuff?
[21:55:02] <alex_joni> users runs the first time
[21:55:12] <alex_joni> selects a template, copies it, etc
[21:55:21] <jmkasunich> oh, remember the previous one
[21:55:31] <alex_joni> after he's happy, checks a button/checkbox (run-as -default)
[21:55:43] <alex_joni> next emc invocation will run with that
[21:56:00] <jmkasunich> question: once he's done that, how does it not run that one?
[21:56:05] <alex_joni> emc config
[21:56:09] <alex_joni> from the menu
[21:57:04] <cradek> this is another thing we shouldn't bother with because the desktop environment can do it just fine
[21:57:11] <alex_joni> that brings up setupconfig, with the current first page (but with radiobuttons to select the default config)
[21:57:19] <cradek> I can make an icon, or menu entry, or whatever - it runs "emc myconfig"
[21:57:23] <alex_joni> cradek: it can?
[21:57:29] <jmkasunich> IOW, create an icon that does "emc my_favorite-config"
[21:57:33] <alex_joni> yeah, but can the user?
[21:57:35] <cradek> yes
[21:57:37] <cradek> sure
[21:57:44] <cradek> the user can make shortcuts to whatever he wants
[21:57:45] <jmkasunich> cradek: depends on the user
[21:57:52] <alex_joni> no, aunt tillie can't
[21:57:56] <cradek> "can" = is permitted to by the system
[21:58:03] <alex_joni> ok, so he can't
[21:58:15] <jmkasunich> much of this stuff is for the aunt tillie who might not know how to do that even in doze, and uses Linux ONLY for emc
[21:58:18] <cradek> so have the "make default" button write an icon file to ~/Desktop?
[21:58:30] <cradek> I dunno
[21:58:40] <alex_joni> nah.. that doesn't seem right
[21:58:44] <jmkasunich> the make default button would be nice, but gets to be very distro dependent
[21:58:48] <cradek> yeah
[21:58:50] <alex_joni> because you will be platform dependent
[21:59:04] <jmkasunich> I guess we have two classes of users
[21:59:42] <jmkasunich> 1) dumbshits, who we try to lead by the hand and never expose to the complexity (and power) of the OS or the windowing system
[21:59:42] <cradek> jmkasunich: Tillie might be perfectly happy (reassured even) if she has to click the machine configuration every time.
[22:00:00] <jmkasunich> 2) normal people, who can set up icons and do other such things
[22:00:01] <cradek> jmkasunich: a more advanced user can make a shortcut.
[22:00:09] <alex_joni> * alex_joni gives up
[22:00:48] <jmkasunich> giving up on the default?
[22:01:02] <alex_joni> yup
[22:01:10] <jmkasunich> you do have a point tho
[22:01:25] <alex_joni> yes I do, but it adds a problem
[22:01:26] <jmkasunich> keep in mind, this isn't like an editor opening the last file edited by default
[22:01:35] <jmkasunich> most PCs will only control ONE machine
[22:01:35] <alex_joni> where/how do you keep that data
[22:01:56] <alex_joni> jmkasunich: that's exactly why I favour a default
[22:02:03] <jmkasunich> it seems kinda silly to make the user pick every time
[22:02:15] <jmkasunich> or build another menu entry/icon
[22:02:50] <jmkasunich> cradek: what would the "unix way" think of making a config (subdir) called default that is a symlink to the preferred one
[22:02:57] <jmkasunich> the "make default" button could do that
[22:03:18] <jmkasunich> and "emc" with no args would look for the "default" before invoking the picker
[22:04:15] <alex_joni> jmkasunich: yes that is a way, but there is another (at least GUI-wise), I like that more
[22:04:27] <alex_joni> on the config page, you have all setups/templates
[22:04:42] <alex_joni> have a radiobutton for each in a column called default config
[22:04:54] <alex_joni> and have a new line on top called 'None'
[22:05:13] <alex_joni> but I guess it's just a matter of taste
[22:05:21] <jmkasunich> I like that too
[22:05:26] <jmkasunich> that is the interface
[22:05:31] <jmkasunich> what is the mechanism?
[22:05:34] <alex_joni> yes, underneath it's the same
[22:05:37] <jmkasunich> perhaps the symlink is the mechanism
[22:05:44] <alex_joni> default symlink
[22:05:53] <jmkasunich> checking none deletes the symlink "default"
[22:05:57] <alex_joni> yup
[22:05:59] <jmkasunich> checking any other creates the symlink
[22:06:33] <jmkasunich> cradek is being very quiet
[22:06:58] <alex_joni> bet he's being busy
[22:07:00] <alex_joni> while we talk
[22:07:23] <cradek> I'm watching, it's just that I don't have strong opinions about it.
[22:07:26] <alex_joni> ok, how do you like the bin/setupconfig stuff?
[22:07:35] <alex_joni> I want to do that now
[22:08:05] <jmkasunich> don't call it bin/setupconfig
[22:08:12] <jmkasunich> call it bin/emc-config
[22:08:16] <jmkasunich> (IMO)
[22:08:17] <cradek> I agree
[22:08:33] <cradek> if we have multiple invocations in bin, they should be emc-* (with no extensions)
[22:08:35] <jmkasunich> and it comes from emc-config.in
[22:08:46] <alex_joni> ok, it will be generated by make, so it won't be in the repository (which means name can change)
[22:08:59] <jmkasunich> the .in will be in the repository
[22:09:01] <alex_joni> no need for .in
[22:09:17] <alex_joni> cat > $bindir/emc-config
[22:09:29] <jmkasunich> generated by make, not by configure?
[22:09:34] <alex_joni> yeah
[22:09:40] <alex_joni> make has all the knowledge
[22:09:55] <alex_joni> that way we keep configure touched files low
[22:09:56] <jmkasunich> and make can customize for rip or install
[22:10:02] <alex_joni> but either way is fine for me
[22:10:03] <cradek> seems to me like a job for configure
[22:10:28] <jmkasunich> cradek: tell me again why we need to decide rip vs. install at the configure stage
[22:10:37] <cradek> jmkasunich: so the module helper knows where the modules are/will be
[22:10:39] <alex_joni> well, configure writes Makefile.inc which we'll use
[22:10:51] <jmkasunich> what info gets compiled into which file that needs to be different?
[22:10:57] <jmkasunich> ok, the module_helper whitelist
[22:11:00] <cradek> right
[22:11:07] <cradek> the dir whitelist
[22:11:13] <jmkasunich> I can see why we don't want to handle that with wrapper scripts or something
[22:11:21] <jmkasunich> what else, or is that it?
[22:11:23] <cradek> right, it needs to be compiled in.
[22:11:27] <alex_joni> any way of handling that is insecure
[22:11:42] <cradek> right now, that's it, but knowing this may let us simplify other things.
[22:11:46] <cradek> I haven't dug too deeply.
[22:11:52] <jmkasunich> ok, here's a thought:
[22:12:01] <jmkasunich> compile module helper twice
[22:12:16] <jmkasunich> once has the install whitelist, and is installed setuid when you do make install
[22:12:37] <jmkasunich> the other has the rip whitelist, and sits in the local dir, and needs to be invoked with sudo
[22:12:45] <jmkasunich> (I assume we still require sudo for rip?)
[22:12:48] <cradek> no
[22:12:53] <alex_joni> if it's setuid no
[22:12:56] <cradek> we don't require sudo for anything
[22:13:16] <jmkasunich> oh, thats right, you do make setuid
[22:13:23] <cradek> jmkasunich: there's another thing: the path to the module helper itself
[22:13:31] <cradek> configure also has to set that
[22:13:44] <jmkasunich> set it where?
[22:13:45] <cradek> (in the realtime script)
[22:13:57] <jmkasunich> and eventually in halcmd
[22:14:00] <cradek> right
[22:14:04] <cradek> today, if I get to it
[22:14:21] <alex_joni> cradek: I can't figure this Makefile out
[22:14:30] <cradek> alex_joni: I can help
[22:14:34] <alex_joni> I wanted to add the message for sudo make setuid back
[22:14:42] <alex_joni> but I have no clue where that should go
[22:15:25] <cradek> add a rule at the end of default:
[22:15:54] <cradek> then add .PHONY: message
[22:16:02] <cradek> then add message: with echos after it
[22:16:14] <alex_joni> .PHONY anywhere?
[22:16:18] <alex_joni> or at the end?
[22:16:29] <jmkasunich> couldn't you just add the echos to the default:?
[22:16:37] <jmkasunich> default: userspace modules
[22:16:44] <jmkasunich> <tab> echo stuff
[22:16:57] <alex_joni> that might work too I guess
[22:17:15] <jmkasunich> I guess the message target means you can invoke the same message from more than one place tho
[22:18:06] <jmkasunich> there should already be a .PHONY line in the makefile, just add message to it
[22:18:16] <cradek> alex_joni: put it up with .SUFFIXES I guess
[22:18:21] <alex_joni> no PHONY as I can see
[22:18:26] <jmkasunich> ok
[22:18:29] <cradek> doesn't matter much
[22:18:29] <alex_joni> I added the echo and it works ok
[22:18:40] <alex_joni> without the message target
[22:18:44] <jmkasunich> I haven't looked a tht new makefiles
[22:18:52] <cradek> yeah you can put them right in default: I guess
[22:18:59] <jepler> .PHONY is defense against some joker creating a file called 'default', and breaking the makefiles
[22:19:00] <cradek> matter of taste
[22:19:04] <jmkasunich> something tells me when I do it will be "Toto, we're not in Kansas anymore"
[22:19:21] <jepler> I didn't write any .PHONYs
[22:19:30] <alex_joni> I wrote .PONY
[22:19:40] <alex_joni> does that count?
[22:19:43] <jmkasunich> lol
[22:20:02] <jepler> In the case of 'message', it would become a feature if you can 'touch message' and shut up the makefile
[22:20:27] <jmkasunich> jepler: you didn't do .PHONY because there are no phony targets, or because you just didn't get around to it yet?
[22:21:10] <jepler> jmkasunich: Because I didn't get around to it, I suppose
[22:21:11] <cradek> jmkasunich: if your PHONY targets aren't likely file names, .PHONY makes no difference
[22:21:23] <cradek> jmkasunich: so it's easy to overlook
[22:21:41] <alex_joni> so if I'm getting this right, if a user makes a file called 'default', make won't work anymore?
[22:21:56] <jmkasunich> I'm accustomed to seeing ".PHONY all clean etc, etc"
[22:21:59] <jmkasunich> right
[22:22:04] <jepler> yeah
[22:22:07] <alex_joni> jmkasunich: probably to not allow that
[22:22:13] <alex_joni> we'll worry lateron
[22:22:28] <jmkasunich> yeah, the .PHONY lines should be added, but not critical
[22:22:31] <jepler> it's easy enough to add
[22:23:29] <cradek> wow this builds fast now
[22:24:14] <jmkasunich> still 22 mins on the BDI-Live slot
[22:24:26] <jmkasunich> (that includes configure and make clean as well as make)
[22:24:39] <cradek> real0m53.316s
[22:24:49] <jepler> cradek: you may have the fastest machine of any of us
[22:24:49] <jmkasunich> 19 mins on the BDI-4.20 slot
[22:24:53] <cradek> 53s from clean with -j3 here
[22:25:09] <jepler> cradek: are you using ccache?
[22:25:12] <alex_joni> cradek: hwo did you time it?
[22:25:15] <jmkasunich> the compile farm machines are NOT fast ;-)
[22:25:40] <cradek> jepler: no, I don't think so
[22:25:50] <cradek> alex_joni: make clean; time make -j3 -s
[22:26:20] <alex_joni> deps already done I presume
[22:26:26] <cradek> yes
[22:26:33] <alex_joni> * alex_joni times it now
[22:26:41] <jmkasunich> does make clean undo the deps?
[22:26:44] <alex_joni> no
[22:26:48] <jepler> jmkasunich: no, 'depclean' removes the deps
[22:26:48] <jmkasunich> damn
[22:26:57] <alex_joni> why?
[22:27:02] <jmkasunich> ok, then I should change the compile farm to do depclean
[22:27:17] <cradek> I don't mind if clean also removes deps
[22:27:22] <jmkasunich> I want the farm to behave just like a compile by some newbie who has a fresh, virginal checkout
[22:27:31] <cradek> we do not need to routinely use clean anymore
[22:27:44] <alex_joni> real 1m27.701s
[22:27:56] <alex_joni> a bit slower
[22:28:20] <alex_joni> but this is my slower box :)
[22:28:52] <jmkasunich> is make depclean supposed to re-do the depends?
[22:29:06] <jmkasunich> because it is
[22:29:19] <jmkasunich> Makefile:63: depends/libnml/rcs/rcs_print.d: No such file or directory
[22:29:19] <jmkasunich> Makefile:63: depends/module_helper/module_helper.d: No such file or directory
[22:29:19] <jmkasunich> Makefile:63: depends/rtapi/rtai_ulapi.d: No such file or directory
[22:29:21] <jmkasunich> /bin/sh: line 1: cd: ../lib: No such file or directory
[22:29:21] <jmkasunich> Depending rtapi/rtai_ulapi.c
[22:29:21] <jmkasunich> Depending module_helper/module_helper.c
[22:29:22] <jmkasunich> Depending libnml/rcs/rcs_print.cc
[22:29:23] <jmkasunich> Depending libnml/rcs/rcs_exit.cc
[22:29:24] <cradek> if you run it twice, it will delete them, generate them, delete them
[22:29:39] <jmkasunich> I did cvs up, ./configure, make depclean
[22:29:47] <cradek> yeah, it will generate then delete them
[22:29:56] <jmkasunich> it deleted (or tried to, hence all the no such file), then it made them
[22:29:58] <alex_joni> huh
[22:30:18] <cradek> in order to run your command, the makefile has to include the dep files, so it creates them
[22:30:34] <jmkasunich> I wonder about that /bin/sh: line 1 error too
[22:30:46] <jepler> I'm not sure about that 'cd: ../lib' error either
[22:30:57] <cradek> jmkasunich: you don't have a lib directory, cvs up -d will create it
[22:31:00] <cradek> I had that problem too
[22:31:00] <jmkasunich> there is another one at the very end
[22:31:07] <jepler> RPATH := $(shell cd ../lib; /bin/pwd)
[22:31:09] <jmkasunich> Depending emc/ini/iniaux.cc
[22:31:09] <jmkasunich> Depending emc/canterp/canterp.cc
[22:31:10] <jepler> ah, it's from this line
[22:31:10] <jmkasunich> /bin/sh: line 1: cd: ../lib: No such file or directory
[22:31:24] <jepler> I wrote that to get the absolute path where the shared libraries are created for run-in-place
[22:31:25] <cradek> does something remove it?
[22:31:48] <alex_joni> cvs up -d removes empty dirs
[22:31:51] <cradek> that's now available as $(rip_moduledir)
[22:31:57] <jmkasunich> -dP removes empty
[22:32:02] <jmkasunich> (the P )
[22:32:05] <alex_joni> right
[22:32:10] <cradek> jepler: that's now available as $(rip_moduledir)
[22:32:11] <alex_joni> * alex_joni is tired :)
[22:32:15] <jmkasunich> I routinely do cvs up -dP
[22:32:44] <jmkasunich> because of the cvsignore files, include, bin, and rtlib don't get removed, but I guess lib does
[22:32:52] <jepler> I don't think the Makefile does a 'mkdir' on lib
[22:33:02] <jepler> so maybe it's broken for fresh checkouts
[22:33:24] <jmkasunich> try cvs up -dP
[22:33:32] <cradek> but lib is in cvs
[22:33:39] <jmkasunich> is it empty?
[22:33:45] <alex_joni> cradek: -P deletes empty dirs after checkout
[22:33:52] <cradek> oh
[22:33:59] <cradek> why do you use that then?
[22:34:12] <alex_joni> in order not to see empty dirs?
[22:34:16] <jepler> cradek: Because otherwise every directory that was ever populated will exist in a new checkout
[22:34:19] <jmkasunich> so if someone commits "got rid of a dir full of cruft" the dir goes away on my local copy
[22:34:25] <cradek> oh
[22:34:36] <cradek> hmm
[22:34:37] <jepler> cradek: CVS doesn't have any way to express "a directory exists", except by having a file in it
[22:34:39] <alex_joni> cradek: that's true even for dirs created on some other branch
[22:34:52] <alex_joni> they show up in HEAD too, but empty
[22:34:54] <alex_joni> iirc
[22:34:56] <jmkasunich> and I do -d so fi someone commits "added a dir full of wonderfull stuff" I get the dir
[22:35:00] <cradek> jepler: I think we should remove those target directories from cvs and create then with mkdir
[22:35:16] <alex_joni> I think install -d was used before
[22:35:16] <cradek> well I guess we can't have .cvsignores in them them
[22:35:53] <alex_joni> cradek: mind if we sort the directory mess out?
[22:35:53] <jmkasunich> can the top level .cvsignore tell CVS to ignore an entire dir?
[22:35:57] <cradek> * cradek leaves this to the experts
[22:36:09] <jepler> jmkasunich: I think so
[22:36:21] <alex_joni> now that configure knows rip vs installed, that hacking in emc.in is not needed anymore
[22:36:25] <jepler> (in fact it looks like 'lib' is in the toplevel cvsignore)
[22:36:26] <jmkasunich> then we can remove the created dirs (and their .cvsignores) from CVS
[22:36:40] <jepler> also, 'objects' and 'depends' are listed in src/.cvsignore
[22:36:52] <jmkasunich> and add "if ( !d <somedir> ) mkdir <somedir>" to the makefile
[22:38:46] <jmkasunich> changing the subject (back to an older one)
[22:39:21] <jmkasunich> how do we feel about splitting the run-picker and config-manager functions of setupconfig.tcl into two
[22:39:31] <jmkasunich> and invoking the latter with emc-config
[22:39:33] <cradek> jmkasunich: mkdir -p dir
[22:39:45] <cradek> jmkasunich: actually @mkdir -p dir
[22:39:49] <alex_joni> jmkasunich: very good actually
[22:39:50] <jmkasunich> whatever
[22:40:07] <alex_joni> jmkasunich: I feel very good about that
[22:40:13] <alex_joni> the emc-config is almost done
[22:40:21] <jmkasunich> alex: I hear you, what about the other guys
[22:41:37] <cradek> fine with me, I don't feel strongly about it either way
[22:42:32] <jmkasunich> I think I will do it then, the new picker (for run) will be called pickconfig.tcl (unless somebody has a better suggestion) and that will be called from emc (aka emc.in)
[22:43:18] <jmkasunich> setupconfig.tcl will be called from emc-config and emc-config.in (or is Alex getting rid of the .in versions and doing it all in makefiles?)
[22:43:56] <cradek> IMO substituting some stuff into files is the job of configure, not make
[22:44:16] <jmkasunich> ok, you guys hash that out, I'm starting on the tcl progs
[22:44:18] <alex_joni> ok, I already have the .in in place
[22:44:39] <alex_joni> but I want to redo the whole configure folder stuff
[22:44:49] <alex_joni> guess i'll just commit, and fix afterwards
[22:46:43] <jepler> alex_joni: I use that approach whenever I work on axis, and I've found it works nicely when applied to emc2 too.
[22:47:22] <cradek> haha
[22:47:38] <cradek> sometimes people, in their frustration, help you finish
[22:48:13] <cradek> brb
[22:48:24] <alex_joni> I might break this for a few minutes.. bear with me
[22:57:44] <jmkasunich> what is that place that fenn sometimes uses to post a few lines or pages of text?
[22:57:53] <alex_joni> pastebin
[22:57:58] <jmkasunich> thanks
[23:00:50] <jmkasunich> http://pastebin.com/550331
[23:01:09] <jmkasunich> this is what the new picker will do - can you folks spare a couple minutes to see if it makes sense?
[23:02:32] <cradek> is this going to manipulate the default symlinks?
[23:02:44] <jmkasunich> no, it only follows them
[23:02:48] <jmkasunich> it will be invoked by "emc"
[23:02:54] <jmkasunich> "emc-config" will manipulate
[23:03:02] <cradek> ok
[23:03:13] <alex_joni> why not call it always with default as param?
[23:03:31] <alex_joni> if it's not there, it displays the list
[23:03:34] <alex_joni> if it is, it runs
[23:03:50] <jmkasunich> IOW, no special code needed to hunt for defaults
[23:03:54] <jmkasunich> that is good
[23:04:01] <cradek> I agree
[23:05:09] <cradek> I still think multiple inis in a config is a bad idea
[23:05:31] <cradek> and the complexity caused by that bad decision is spreading to multiple places
[23:05:41] <alex_joni> cradek: probably so, but better than lots of dirs with the same config in it
[23:05:56] <jmkasunich> alex: debatable
[23:05:57] <cradek> alex_joni: I disagree
[23:06:05] <jmkasunich> but I don't want to have that debate today ;-/
[23:06:23] <jmkasunich> well, maybe a little debate:
[23:06:29] <cradek> haha
[23:06:43] <jmkasunich> lots of dirs with the saem stuff is a problem only for developers who need to maintain the copies
[23:07:00] <jmkasunich> multiple inis in one config is a problem (a decision to make) for users too
[23:07:42] <cradek> and it makes backup/restore less useful - the backup doesn't represent the entire machine configuration, you have to know something else too (which ini to use)
[23:08:00] <jmkasunich> good point, I didn't think about that one
[23:08:01] <cradek> I think a config should represent exactly the machine configuration
[23:08:10] <cradek> right now, it doesn't
[23:08:34] <jmkasunich> how about a compromize (might be the worst of both ways tho)
[23:08:34] <cradek> so it's also going to be a support problem
[23:08:52] <jmkasunich> sample configs can have more than one, but when you do "new" it makes you pick one and copies only that one
[23:09:20] <jmkasunich> worst of both worlds in that the run and pick code still needs to handle the case of multiple files
[23:09:38] <jmkasunich> but at least users will only have one so the ambiguity is gone
[23:09:38] <cradek> I think that's an improvement, but you're right, it's still unnecessarily complex.
[23:10:45] <cradek> but it fixes my main complaint
[23:11:42] <cradek> nobody is going to maintain the inis for both units in their custom config
[23:11:52] <cradek> there is no reason to do that
[23:12:01] <cradek> so we just don't copy them in there
[23:12:04] <cradek> that seems sane to me
[23:13:02] <cradek> that fixes the support problem but does not allow us to remove complexity from setupconfig and friends
[23:13:11] <jmkasunich> http://pastebin.com/550347
[23:13:28] <jmkasunich> revised, now you can specify --config default --ini default and it will do the right thing
[23:13:36] <cradek> great
[23:14:42] <jmkasunich> thanks alex that idea probably reduced the code by 20% or more
[23:15:15] <alex_joni> np, I'm about to commit too
[23:15:52] <jmkasunich> I'll try to get pickconfig implemented today
[23:16:19] <alex_joni> $bindir/emc-config should work ok soon
[23:16:20] <jmkasunich> its gonna go in emc2/tcl/bin, I don't know where it will get installed
[23:16:34] <jmkasunich> emc-config will simply invoke setupconfig?
[23:16:36] <alex_joni> jmkasunich: no need to worry where it will get
[23:16:58] <alex_joni> it already does, but it also supplies --configs-dir $EMC2_CONFIG_DIR
[23:17:13] <jmkasunich> how about --configs-path instead
[23:17:21] <jmkasunich> (it can be more than one directory)
[23:17:30] <alex_joni> when it will knwo that it's easy to change
[23:17:47] <jmkasunich> speaking of which, how will the user/installer set that path?
[23:18:00] <alex_joni> he won't, configure sets it
[23:18:21] <jmkasunich> we talked about things like /etc/emc:/usr/something/emc:~/emc
[23:18:33] <jmkasunich> but that is policy, the machine owner should set it
[23:18:33] <alex_joni> yup, we can still do that
[23:18:42] <cradek> other way: $HOME/emc2 /usr/local/etc/emc2 /etc/emc2
[23:18:44] <alex_joni> ok, then he needs to change something
[23:19:35] <jmkasunich> a one man shop would want $HOME, a large shop with multiple users would not
[23:19:57] <jmkasunich> so that needs to be chosen at ./configure time (or when installing the .deb, or something)
[23:22:02] <jmkasunich> package require msgcat
[23:22:02] <jmkasunich> if ([info exists env(LANG)]) {
[23:22:02] <jmkasunich> msgcat::mclocale $env(LANG)
[23:22:03] <jmkasunich> msgcat::mcload "../../src/po"
[23:22:03] <jmkasunich> }
[23:22:09] <jmkasunich> ../../src/po
[23:22:13] <alex_joni> yes, that is bad
[23:22:16] <jmkasunich> something tells me that won't work installed
[23:22:38] <alex_joni> something is right
[23:23:06] <alex_joni> I mean the 'something' that tells you it won't work installed, is right
[23:23:19] <jmkasunich> I understood ;-)
[23:23:39] <alex_joni> ok, now RIP which isn't configures as rip is completely busted
[23:24:07] <jmkasunich> RIP now equals "rest in peace"
[23:24:10] <alex_joni> so to run-in-place you have to ./configure --enable-run-in-place and you'll get the proper dirs in the scripts
[23:24:21] <alex_joni> no, it still works as it should
[23:24:23] <cradek> the default ./configure should make a system that works after make install, and it should be --prefix of /usr/local
[23:24:33] <alex_joni> cradek: it is
[23:24:36] <cradek> great
[23:24:56] <alex_joni> but maybe I missed a spot :)
[23:25:05] <alex_joni> let me know if it doesn't work as it should
[23:25:18] <jmkasunich> so only developers, or folks wanting to try out a new version without overwriting their old version would specify --enable-run-in-place
[23:25:27] <alex_joni> yup
[23:25:27] <cradek> right
[23:25:41] <jmkasunich> gonna have to publicize that option
[23:25:47] <jmkasunich> it should be in the INSTALL file
[23:25:54] <cradek> the normal behavior of './configure; make; make install' needs to work like every other program
[23:26:04] <alex_joni> sudo make install
[23:26:06] <cradek> right
[23:26:13] <alex_joni> and sudo make setuid ?
[23:26:21] <jmkasunich> that is only needed for RIP
[23:26:25] <alex_joni> or maybe make install should take care of it
[23:26:27] <cradek> no, make install should set permissions on everything appropriately
[23:26:33] <alex_joni> right
[23:26:35] <jmkasunich> (and should also be mentioned in INSTALL)
[23:26:54] <alex_joni> what's up with you and INSTALL?
[23:26:58] <alex_joni> j/k
[23:26:59] <cradek> it needs to use install -m ... -o ... etc, not our sloppy "cp bin/* ..."
[23:27:03] <jmkasunich> ok, then README
[23:27:10] <alex_joni> I read you all right
[23:27:19] <jmkasunich> :-P
[23:27:36] <alex_joni> jepler: still around?
[23:27:44] <alex_joni> * alex_joni has something to ask of you
[23:28:02] <jmkasunich> shouldn't have said that, now he's gonna hide
[23:28:13] <alex_joni> I trust he won't
[23:29:33] <SWP_Away> SWP_Away is now known as SWPadnos
[23:29:41] <SWPadnos> hi guys
[23:30:25] <cradek> hi
[23:30:31] <jmkasunich> hello
[23:31:00] <SWPadnos> You guys have been talking a lot today - my backscroll buffer is cut off as of 4:00 or so ;)
[23:31:22] <alex_joni> hello
[23:31:32] <alex_joni> we do talk a lot :)
[23:31:37] <jmkasunich> yeah, the brainsweat has been flowing
[23:31:47] <SWPadnos> heh
[23:32:06] <SWPadnos> the system/user config thing may have an easy (ish) solution
[23:32:35] <SWPadnos> the KDE config system uses a search path for ini files (called desktop files in KDE-land)
[23:33:02] <SWPadnos> the files are searched in order, and in any file, you can mark the whole file, a specific section, or a specific setting as "immutable"
[23:33:16] <jmkasunich> yes, I remember reading about that
[23:33:31] <jmkasunich> the immutable thing would require a change to our ini syntax
[23:33:35] <SWPadnos> anything immutable isn't changed as the search progresses, anything non-immutable is changed each time it's encountered
[23:33:55] <SWPadnos> you just add $i after the setting name, section name, or at the top of the file
[23:34:01] <jmkasunich> right, and it searches from most generic (system) to most specific (user)
[23:34:07] <SWPadnos> exactly
[23:34:09] <jmkasunich> opposite of something like PATH
[23:34:36] <SWPadnos> yes - so that immutable system settings are taken over user settings, but in all other cases user settings are honored
[23:34:52] <alex_joni> jmkasunich: happy now?
[23:34:56] <SWPadnos> I think you can also load a complete ini tree into a structure, and then read from that - not reload the file every time
[23:36:02] <jmkasunich> alex: yes, I'm happy, thank you ;-)
[23:36:13] <alex_joni> don't mention it :)
[23:38:15] <jmkasunich> translation should never be started until the code is released
[23:38:37] <jmkasunich> every time I change a message I think of the poor translators work that I just invalidated
[23:38:39] <alex_joni> probably so
[23:38:54] <alex_joni> oh, btw .. I just remembered
[23:38:59] <alex_joni> how about flo-h ?
[23:39:07] <alex_joni> I think we decided to add him
[23:39:13] <jmkasunich> oh, sure
[23:39:29] <alex_joni> * alex_joni looks if he has done that
[23:40:35] <alex_joni> jepler (&others): please update the changelogs (debian/changelog docs/NEWS) when adding new stuff to emc2, it's hard to keep track of it otherwise
[23:41:06] <cradek> I update my local debian/changelog when I make a new deb
[23:41:25] <cradek> that's just supposed to document what has changed since the last deb
[23:41:38] <cradek> I'm not sure exactly how to handle it
[23:41:45] <alex_joni> how so?
[23:41:52] <cradek> but my local one goes up to alpha17 right now
[23:42:20] <alex_joni> jmkasunich: I see that flo-h is added, ok
[23:43:21] <cradek> (and now I'm going to get a merge)
[23:44:59] <alex_joni> ouch
[23:45:13] <alex_joni> anyways.. I'm off to bed
[23:45:24] <alex_joni> pretty late over here
[23:45:45] <cradek> ok goodnight
[23:46:00] <cradek> in the morning maybe you can clean up after us :-)
[23:46:27] <alex_joni> sure will
[23:46:32] <alex_joni> I got a box of tissues
[23:46:34] <alex_joni> ROFL
[23:46:53] <cradek> ??
[23:47:16] <alex_joni> clean up?
[23:47:36] <cradek> not that kind of mess - the software kind
[23:47:51] <alex_joni> yeah I know.. was trying to be funny, but it's late :/
[23:48:01] <cradek> I know
[23:48:04] <cradek> goodnight...
[23:49:03] <alex_joni> goodnight
[23:50:53] <jmkasunich> how is it that cats can always figure out which book you're gonna need, and then lay down on it?
[23:55:22] <jmkasunich> --configs-path: should that accept dirs with . or .. in them, or only absolute paths?
[23:57:27] <cradek> I don't think you need to do any validation
[23:58:01] <jmkasunich> well right now, I pass the name to a normalize function that gets rid of . and .. and makes it absolute
[23:58:09] <cradek> why?
[23:58:28] <jmkasunich> so it doesnt get screwed up if I cd
[23:59:49] <jmkasunich> on a related note, I need to expand $HOME don't I
[23:59:52] <cradek> we cd to the config dir to run, don't we