#emc | Logs for 2006-02-11

[00:00:14] <SWPadnos> nor cradek, that's why he wrote the new one ;)
[00:00:19] <SWPadnos> (or so I gather)
[00:00:41] <les_w> chris decided to start from scratch since it was so convoluted...hence simpletp
[00:01:36] <les_w> Just have dinner with Fred...then you will understand
[00:01:47] <les_w> He's too smart
[00:01:54] <SWPadnos> I did, but he wouldn't talk about the TP :)
[00:02:03] <Jymmm> les_w titebond II != gorilla ?
[00:02:04] <SWPadnos> he didn't remember it, I think
[00:02:37] <les_w> convolutes things to the point that it does not bore him....which results in impossible code
[00:02:42] <les_w> oh he remembers
[00:04:19] <SWPadnos> during Fest, we discussed this a bit, and he did say that it could all be wrong, and possibly should be thrown out
[00:04:49] <SWPadnos> or so I think I remember
[00:05:18] <k4ts> hello
[00:05:30] <les_w> jymmm titebond II/III is a water based cross-linking PVA....gorilla is a solvent based moisture cure urethane
[00:05:50] <les_w> swp fred told me that it flat should be thrown out period
[00:06:01] <les_w> hi k4ts!!
[00:06:14] <k4ts> ehilaaa les_w
[00:07:13] <les_w> IIRC Fred said it was "junk code"
[00:08:49] <fenn> chips and fries
[00:10:06] <les_w> well, fred can visualize very complex interactions. If something is simple and doesn't require it...he puts it in anyway to not be bored.
[00:10:14] <SWPadnos> heh
[00:10:57] <les_w> He is smart...too smart. I thought I was smart but feel like an ameoba next to him.
[00:11:20] <les_w> now I know that isn't spelled right...
[00:11:30] <fenn> amoeba
[00:11:34] <les_w> ty
[00:19:13] <les_w> Fred should stop writing code and ponder superstring theory in 11 dimensions or a cure for cancer or something
[00:21:41] <Jymmm> Well, the exploit I discovered has been added to my AV signatures by the vendor. I'm nost sure if that's a good or bad thing.
[00:21:50] <Jymmm> s/nost/not/
[00:22:11] <les_w> huh?
[00:23:32] <Jymmm> I had found a javascript exploit that can infect you with a virus.
[00:23:40] <les_w> oh jymmm...I may have told you...I am giving a wood finishing classfor a group of about 30 at the local high school industrial arts area.
[00:23:46] <les_w> get your ticket!
[00:24:31] <Jymmm> les_w Mailman already came today... wehn did you mail my FIRST CLASS ticket?
[00:24:35] <les_w> java can be a trojan for a virus?
[00:24:43] <giacus> uhmm
[00:24:56] <giacus> i doubt it
[00:24:57] <Jymmm> les_w Yes... noth Java AND now Javascript.
[00:25:03] <Jymmm> les_w Yes... both Java AND now Javascript.
[00:25:10] <les_w> first class...of course...can't have you in the back with the riff-raff
[00:25:11] <Jymmm> fuck I can't type today.
[00:25:38] <Jymmm> les_w I'm 6'4"... I aint gonna be a sardine for a two+ hour flight
[00:26:23] <les_w> I am short...but I hate 12 hrs in economy a lot....
[00:26:24] <Jymmm> The Javascript exploit was really nasty... took a while to find, then to analize is a safe manner.
[00:27:09] <Jymmm> You dont even have to click on a link, just visitng an infected website was enough.
[00:27:35] <Jymmm> It was very creative, that's for sure.
[00:27:40] <les_w> possibly like the one that hijacked my site a few weeks ago
[00:27:57] <les_w> I think they got in with non secure ftp
[00:27:58] <Jymmm> Sorta like that, yes.
[00:28:12] <Jymmm> then your website becomes the carrier
[00:28:18] <les_w> yep
[00:28:24] <Jymmm> and everyone that vistis gets infected
[00:28:38] <Jymmm> This one originated from Russia/Ukrane
[00:28:44] <les_w> I refreshed the html and changed the password...no problems so far
[00:29:43] <Jymmm> cool. I'm only using sftp now.
[00:29:54] <Jymmm> just for safe measures
[00:30:25] <les_w> my hit count took a nose dive those few days...and anyone that visited then will never return
[00:31:00] <Jymmm> at least not with JS enabled
[00:31:08] <les_w> yeah
[00:31:22] <Jymmm> I can instantly turn java/js on/off
[00:31:25] <les_w> I expect 99% have JS enabled
[00:31:48] <Jymmm> I never run with JAVA enabled, but JS I do
[00:32:36] <les_w> I have to put up a new web site for this wood finishing class thing
[00:32:44] <Jymmm> And with another project I'm working on... I haven't even written a line of code yet becasue I'm planning out all the security crap!
[00:34:48] <Jymmm> I was gonna write a simple captcha, but not after the website I found.
[00:35:51] <les_w> I don't know much about that stuff... I just make websites and ftp em up with commercial software
[00:35:58] <wb9mjn> Hey Les !
[00:35:59] <les_w> hi wb9
[00:36:17] <wb9mjn> Welp, I took delivery on a Prius on Wednesday in Skunktown...
[00:36:23] <les_w> will be up your way soon
[00:36:27] <wb9mjn> where skunkworks lives...
[00:36:30] <Jymmm> les : [CAPTCHA] Completely Automated Public Turing test to tell Computers and Humans Apart (see: http://www.zend.com/zend/tut/tutorial-mehmet1.php), also http://en.wikipedia.org/wiki/Captcha and http://www.ocr-research.org.ua/list.html
[00:36:47] <les_w> tell me about the prius
[00:36:55] <wb9mjn> 42.8 mpg at 70 mph for 284 miles back here...!
[00:37:08] <les_w> looks cool
[00:37:12] <wb9mjn> It was the first HSD (Hybrid Synergy Drive) that Toyota did...
[00:37:16] <les_w> good reliability
[00:37:41] <wb9mjn> They have the planetary gear set between the motors and the engine and axle...
[00:37:56] <wb9mjn> I m hoping for very good mechanical reliability...
[00:38:09] <les_w> I still have not bought a travel car...and ITW is bugging me to get up there
[00:38:28] <Jymmm> les_w Ask them to buy you one
[00:38:28] <les_w> I'll live at the extended stayamerica on 53 I guess
[00:38:37] <wb9mjn> The Lexus LS is next for the HSD treatment after the Camry which roles out in June...
[00:38:53] <wb9mjn> I mean GS ...
[00:39:14] <les_w> yeah GS is on the short list for me
[00:39:37] <wb9mjn> In two days bact to work, including a bunch of lunch time block rounders, this tank of gas is getting 43.5 mpg ...
[00:39:41] <wb9mjn> so far...
[00:39:46] <wb9mjn> Yep...I remeber that...
[00:39:49] <les_w> neat
[00:39:57] <Jymmm> how big is the tank?
[00:39:59] <les_w> where is work?
[00:40:07] <wb9mjn> Wood Dale...about 25 miles...
[00:40:25] <wb9mjn> Its 11.9 gallons...hand .3 of a tank when I pulled in here from skunktown...
[00:40:40] <les_w> ah...I lived in elmhurst before medinah....close by
[00:40:44] <Jymmm> Why is it that a tankfull is ALWAYS ~300 miles?!
[00:41:11] <wb9mjn> Started out at 15 degrees outside temp and it was snowing and 32 when I pulled into town here...no snow except for in town here the whole
[00:41:13] <wb9mjn> trip...
[00:41:50] <wb9mjn> People at work really like it, including the president of the company and the lead sales guy...sales guy wants to do Ft Wayne and back on
[00:41:56] <les_w> Fond memories of moving to evanston from florida
[00:41:57] <wb9mjn> one tank...which I think he can..
[00:42:01] <les_w> I had no idea
[00:42:08] <les_w> had no car either
[00:42:35] <les_w> bought a new plymouth and tried to learn how to drive on the icy side streets
[00:43:00] <les_w> it was better than freezing on L platforms
[00:43:14] <wb9mjn> If you work out that mileage lymm, its 405.7 miles on the tank that day I drove the car back...
[00:43:24] <wb9mjn> That s 284/(1-.3) ...
[00:44:00] <Jymmm> that's not too shabby... I'd prefer 500miles/tank
[00:44:21] <les_w> the neat thing is that you get lots of off the line torque from the electrics even with a small gas engine
[00:44:23] <wb9mjn> They are supposed to be selling a $72K HSD sportscar in Germany this year....0-60 in 4.0 sec, 30 mpg...
[00:44:30] <les_w> pundits say it will never fly
[00:44:35] <wb9mjn> Sure do, he he...
[00:44:36] <les_w> but I am not so sure
[00:44:52] <wb9mjn> Its already flying....this is why GM is freaked out....
[00:45:01] <les_w> yeah
[00:45:28] <wb9mjn> LA is Priuscrazy...Leonardo DeCaprio has 4 of em ...
[00:45:37] <les_w> ha
[00:46:17] <les_w> what battery does it use? Lithium hydride?
[00:46:34] <wb9mjn> In Florida and California they get 500 m/tank on many occaisions...but not at 15 degrees F outside, hi..
[00:46:36] <fenn> here is an interesting technology i'd never heard about before.. http://vri.etec.wwu.edu/pdf files/v29paper.pdf
[00:46:54] <fenn> thermophotovoltaics
[00:47:22] <wb9mjn> It NiMH,,but just this year the LI batteries have become practical for the application...Sanyo and MIT invented nano-engineered electrode
[00:48:05] <wb9mjn> technologies that give the LI battery quicker recharge time, and long charge retention capabilities...ideal for Hybrid Car...
[00:48:10] <les_w> what is the battery life?
[00:48:27] <wb9mjn> Its 100 K / 8 year garuntee....
[00:48:49] <les_w> wow
[00:49:00] <wb9mjn> Taxis have been running the Prius with 200 K life on many of the cars...Toyota says their design nominal was 150 K miles...
[00:49:35] <wb9mjn> They only let the battery discharge to 40 % or recharge to 80 % ...and its in the cabin...so when in use, its temp controlled...
[00:50:06] <wb9mjn> They had all sorts of developement problems when they hung them underneath the car, and the Thermal radiation off the pavement fried the
[00:50:08] <wb9mjn> batteries...
[00:50:27] <wb9mjn> So, now they have the batteries under the rear passenger seat...
[00:50:27] <les_w> well, I saw a prius today on the hiway. Looked good too.
[00:50:46] <wb9mjn> Best Cd on the market .... .26 ...
[00:51:02] <les_w> hmmm
[00:51:28] <wb9mjn> Cars have problems with drag....not like airplanes at .1 or so....
[00:51:43] <les_w> perhaps I ought to drive one...even though I am looking for a heavy cruising car
[00:51:57] <fenn> just put some more batteries in it les
[00:52:04] <les_w> haha
[00:52:20] <wb9mjn> Batteries usually survive the headons, so they are available salvage now ...
[00:52:31] <fenn> full electric one way trip
[00:52:36] <fenn> i bet its feasible
[00:52:42] <wb9mjn> Nope...really does not work like that....
[00:53:11] <wb9mjn> But some guys in CA are working on a "Plug-in" Prius...with big LI batteries, to get 30 miles range ...
[00:53:23] <les_w> I need an old man car. Total silence at 70 mph. Good handling, but I don't want to hear or feel the road very much anymore.
[00:53:26] <wb9mjn> They think they could cut down on gas usage by half....
[00:53:45] <les_w> I want to not be tired when I get to my meeting.
[00:53:57] <fenn> les_w: one word: chauffeur :)
[00:54:04] <les_w> haha
[00:54:11] <wb9mjn> You can feel the road a little...but it is quite quiet...only a 1.5 liter engine and hardly no wind noise ...
[00:54:16] <les_w> another word:
[00:54:20] <les_w> Lexus.
[00:54:32] <wb9mjn> Did not get a sore but till about 10 miles from home....
[00:54:57] <les_w> huh?
[00:55:05] <les_w> it gives you sores?
[00:55:10] <les_w> explain...
[00:55:12] <wb9mjn> No....
[00:55:42] <wb9mjn> Sitting in a car for 5 hours tends to make me give some tail-bone soreness...
[00:55:51] <les_w> yeah...
[00:56:12] <wb9mjn> But did not have any till about 4 hrs 50 minutes in this car...
[00:56:24] <les_w> ok that's not bad
[00:56:35] <wb9mjn> Nope...
[00:57:11] <wb9mjn> But, I m sure they will do a nice job on the GS too....
[00:58:05] <wb9mjn> Handling takes some getting used to...I m used to the cues of being able to see the corners when I turn...in the SL2 ...
[00:58:08] <les_w> Well I always blasted around in hard seated bmw and audi....hard seats are so you interact with the road
[00:58:13] <les_w> which I liked
[00:58:20] <wb9mjn> This car has a high seating position, and you have to dead reckon a little....
[00:58:33] <les_w> but now I want something a little more soft
[00:58:51] <wb9mjn> Yep...Had an Opel Manta and could tell anything the rear axle was doing in that car...
[00:59:10] <les_w> It's awful to get old.
[00:59:15] <wb9mjn> Yep....
[00:59:43] <les_w> old man car for me.
[01:00:03] <wb9mjn> This will be my old-man car probably...plan to keep it for 10 years....
[01:00:42] <wb9mjn> On the Z drive here...I got some servo-disk motors....
[01:00:58] <wb9mjn> Going to use the big one, as I can get a lower stall current with it....
[01:01:22] <wb9mjn> Then once that is working, will look into a counter balance air spring...
[01:03:09] <wb9mjn> probably will take me a couple of months...from-scratch motor mounting plate...
[01:03:47] <wb9mjn> big....10 by 6 with milled circular pockets and through bores....
[01:03:56] <wb9mjn> tapped holes....
[01:04:22] <wb9mjn> Have it kinda designed...have to get some workholding bits and pieces...
[01:05:27] <wb9mjn> Watching Olympics starting on other screen on the computer here...
[01:10:25] <les_w> sorry phone again
[01:10:33] <les_w> olympics on huh?
[01:11:08] <les_w> I just likre the ice skater girls.
[01:12:01] <wb9mjn> They are interviewing one now.....
[01:12:06] <wb9mjn> I think ...
[01:12:32] <les_w> think i'll go to the music room and check it out while we see if we get snowed in.....
[01:12:46] <wb9mjn> Need to tweak in my lathe tailstock....Ground a tang into a dead center last friday....came out nice....
[01:13:00] <wb9mjn> Yep...It was Michelle Kwan...
[01:13:21] <wb9mjn> Put in centers in head and tail stocks....could see how far it was off....
[01:13:26] <les_w> later wb9
[01:13:30] <wb9mjn> 73...
[01:14:55] <fenn> stupid ham people
[01:15:03] <fenn> you cant do anything cool on ham
[01:15:10] <fenn> bah
[01:19:31] <wb9mjn> Depends on what you feel is cool...
[02:00:53] <Jymmm> fenn: Sure you can... ATV, APRS, Packet,
[02:01:34] <fenn> Jymmm: you arent allowed to do any encryption or any traffic that includes obscenities
[02:01:57] <fenn> so for example lets say you downloaded an internet web page with an "obscenity" on it
[02:01:57] <Jymmm> fenn and your point is?
[02:02:52] <fenn> or if someone (me) /msgs you "FUCK" well there's your $11,000 fine
[02:04:11] <Jymmm> Only if you made a habbit of it and it only be a pinkslip anyway
[02:04:34] <fenn> i just dont get it
[02:05:13] <Jymmm> Well, if you remove the old-fart aspect from ham radio, it's not too shabby at what you can do/accomplish.
[02:06:15] <Jymmm> I am a ham, but that's about the only thing I'm not too fond of.
[02:06:57] <Jymmm> old-fart doesn't necessarily refer to age, as much as attitude.
[02:07:58] <Jymmm> I enjoy T-Hunt
[02:14:52] <Jymmm> fenn: If it matters much to you, having your ticket also gives you the right to experiment too. Where do yu think cell phones originated from?
[02:15:42] <fenn> i think radio band licensing, satellite orbit licensing, property ownership in general is a crock
[02:17:44] <Jymmm> what, you want anyone to be able to tranmit anywhere they please?
[02:18:06] <fenn> well, that's how it is no matter what you do
[02:18:07] <Jymmm> I mean, look at 11m (CB radio).
[02:18:29] <fenn> sorry i cant see in radio (yet)
[02:18:32] <Jymmm> fenn Right... I dont hear jammers on my FM radio in the car
[02:18:59] <Jymmm> or pirate tv
[02:19:07] <fenn> and it's a damn shame
[02:19:42] <Jymmm> There are a bunch of unlicensed bands, are you usng any of them?
[02:19:59] <fenn> only 802.11
[02:20:16] <Jymmm> then wha cha bitchin bout?!
[02:21:06] <fenn> even 802.11 is regulated
[02:21:32] <fenn> cant even get any decent open source drivers for my roomie's laptop because of the bs
[02:21:44] <Jymmm> lol
[02:21:48] <fenn> someone "might turn up the power on their wireless card if we release the specs"
[02:22:02] <Jymmm> fenn and you will too
[02:22:23] <Jymmm> BUSTED!
[02:22:32] <fenn> i'd set it to whatever works best
[02:22:38] <fenn> what's wrong with that?
[02:22:41] <Jymmm> Uh huh... highest
[02:23:12] <Jymmm> hey, how bout I add an external waveguide to my microwave overn so it can cook faster!
[02:23:43] <fenn> look, i'm just saying the regs don't reflect reality
[02:24:17] <fenn> and are generally un-american
[02:24:19] <Jymmm> it's also due to safety
[02:24:22] <fenn> * fenn never thought he'd say that
[02:26:54] <SWPadnos> being unrealistic is very american these days
[02:26:59] <giacus> goooood niiiiiight
[02:27:02] <giacus> :P
[03:44:15] <CIA-8> 03jepler * 10emc2/src/Makefile: first pass at making the new build system work with bdi-live rc46 -- it builds but I haven't tested it yet
[03:46:50] <jepler> .. in fact I think I'll be done for the night after I verify it hasn't broken building on ubuntu
[03:51:04] <lerman_> lerman_ is now known as lerman
[03:58:34] <jepler> emc2 still builds and runs on ubuntu breezy .. builds but is untested on bdi-live .. built and ran earlier on bdi-4.30
[03:58:38] <jepler> goodnight all
[03:58:50] <cradek> goodnight
[03:58:58] <cradek> thanks for all the good work
[04:00:58] <SWPadnos> night, thanks
[04:50:36] <CIA-8> 03cradek * 10emc2/src/emc/rs274ngc/ (4 files): fix warnings
[04:52:45] <SWPadnos> SWPadnos is now known as SWP_Away
[05:59:56] <jmkasunich> jmkasunich is now known as jmk_away
[06:46:46] <LawrenceG> cradek: have you fallen asleep yet?
[06:54:07] <LawrenceG> cradek: your changes to the kernel now work on this old P200. I can run cds.ngc with default stepper.ini settings
[06:54:55] <LawrenceG> interface is slow and the cpu is showing pretty close to 100% (93-99%) during the run.
[06:56:07] <LawrenceG> cradek: I have some piezio buzzers on the step pins and the pulse trains sound ok.
[07:01:35] <LawrenceG> cradek: I could not get the sim-axis setup to run.... I get the spash screen, the sizeof info on the console window and the axis display window...I can f1,f2,4, get the file open window up (but blank) and it never gets as far as letting me open a gcode file. CPU is maxed out at 99% even after an all night wait.
[07:02:28] <LawrenceG> cradek: rats... lost part of my post...
[07:03:43] <LawrenceG> cradek: axis sim does not work. gets as far as splash, painint axis screen and writing sizeof (now continue from above)
[07:05:11] <LawrenceG> logger_aj: bookmark
[07:05:11] <LawrenceG> See http://solaris.cs.utt.ro/irc/irc.freenode.net:6667/emc/2006-02-11#T07-05-11
[13:08:46] <robin_sz> meep
[13:11:37] <wb9mjn> Morning all...
[14:29:38] <jepler> my bdi-live-in-qemu is behaving oddly: scripts/emc2 seems to have a lot of 'sleep's to keep everything from happening at once .. but "sleep 5" takes at least minutes to exit. I finally killed it from top
[14:45:27] <jepler> after rebooting and increasing BASE_PERIOD, it works.
[14:45:27] <jepler> yay
[14:55:52] <alex_joni> hello
[14:56:09] <alex_joni> jepler: nice work
[15:22:30] <jepler> bdi2's X server won't work inside qemu
[15:22:33] <jepler> anybody know if there's a trick?
[15:24:57] <jepler> oh well, I don't think I'll worry about it right now
[15:25:30] <jepler> it's not likely to work, because the dependency step assumes there's a compiler that makes gcc3-style dependency information
[16:43:06] <CIA-8> 03jepler * 10emc2/src/hal/utils/Submakefile: build m5i20cfg
[17:00:59] <jepler> cradek: can I get the .config from your latest linux-image without installing the deb?
[17:01:34] <alex_joni> jepler: you can download it, and use gzip to unpack it
[17:01:41] <cradek> you could get it out of the deb, or I could send it to you
[17:01:45] <alex_joni> or maybe chris can send it..
[17:01:49] <cradek> haha
[17:02:12] <alex_joni> cradek: what's funny?
[17:02:22] <cradek> we gave the same answer
[17:03:12] <alex_joni> that's only expectable
[17:03:15] <alex_joni> :-P
[17:03:33] <alex_joni> you know.. the 'great minds think alike' ;)
[17:07:26] <alex_joni> now this is really funny.. http://www.microsoft.com/windowsvista/features/default.mspx
[17:07:34] <alex_joni> only "usefull" improvements
[17:10:32] <jepler> and they've made the "close" button bigger, because it was just too small before
[17:11:09] <jepler> and added a scrollbar to the start menu
[17:11:12] <alex_joni> jepler: that is one thing I am bitching about on ubuntu
[17:11:14] <jepler> man, give me a commandline
[17:11:31] <alex_joni> I am very used on doze not to look where the close button is
[17:11:50] <alex_joni> it's basicly on the top-right corner of the desktop, when the app is maximized
[17:11:55] <jepler> alex_joni: hit alt-f4!
[17:12:02] <jepler> use the keyboard God gave you
[17:12:13] <alex_joni> lol, but satan gave me a mouse ;)
[17:12:35] <jepler> hah. the screenshots show running as 'administrator'
[17:12:56] <alex_joni> that's default on doze, you can't do pretty much nothing as normal user
[17:13:01] <alex_joni> installing software & such :/
[17:13:05] <alex_joni> no sudo either
[17:13:10] <jepler> alex_joni: but vista will be different!!!!!!! and secure!!!!!!!
[17:13:17] <alex_joni> ROFLMAO
[17:13:20] <alex_joni> right..
[17:13:25] <jepler> alex_joni: windows has had 'switch user' and 'run as' at least since XP and I think since 2000...
[17:13:38] <alex_joni> 98 too
[17:13:40] <jepler> it's easy to run an installer as administrator if you have to
[17:13:45] <alex_joni> but no-one uses that
[17:13:49] <alex_joni> :)
[17:14:04] <alex_joni> jepler: it will be different : "Windows Vista Aero provides spectacular visual effects such as glass-like interface elements that you can see through."
[17:14:17] <alex_joni> now that I call USEFULL
[17:15:07] <jepler> "Often malware is hidden in programs that appeal to children. To help protect your computer, you can create standard user accounts for your children. When your child tries to install a piece of software, the system will ask for an administrator account's password. Your children cannot install new programs by themselves."
[17:15:26] <alex_joni> ohh.. scary
[17:15:32] <cradek> s/children/users/
[17:15:42] <alex_joni> my children can't install software anymore? who's gonna administer my pc? :(
[17:15:51] <cradek> s/children/parents/
[17:16:04] <jepler> oh, yeah, I believe you. It's your *kid* who installed all the malware. It didn't come in "huge-t**s.exe"
[17:16:18] <alex_joni> lol
[17:16:37] <alex_joni> yeah, it did, but it was my *kid* who got it
[19:16:42] <jepler> cradek: I rebuilt a kernel with your new settings, but turned back on my APIC-related items. After that, the latest rtai and emc2 debs installed just fine and look like they work
[19:16:50] <jepler> cradek: I didn't need 'lapic' on the kernel commandline
[19:17:00] <jepler> cradek: s/APIC-related/ACPI-related/
[19:17:25] <jepler> bbl
[20:06:25] <jmk_away> jmk_away is now known as jmkasunich
[20:49:00] <cradek> jepler: that's great
[20:58:09] <alex_joni> I wonder what feedrate les is usually running on his machine
[21:00:46] <alex_joni> here's a emc2 user running F9000
[21:01:01] <A-L-P-H-A> ??
[21:01:12] <alex_joni> mm, not inch
[21:01:21] <alex_joni> but still pretty much
[21:01:38] <alex_joni> G0 is 18000 mm/min
[21:02:04] <alex_joni> http://www.zanner.sbg.at/DSCN2548.jpg
[21:14:59] <fenn> that guy's definitely a vampire
[22:05:36] <Jymmm> Jymmm is now known as Jymmmm
[22:19:47] <CIA-8> 03alex_joni * 10emc2/src/Makefile: added message for sudo make setuid
[22:40:18] <CIA-8> 03jepler * 10emc2/src/ (4 files in 4 dirs):
[22:40:18] <CIA-8> Refinements to makefiles
[22:40:18] <CIA-8> Makefile: Use .PHONY. Use $(LIB_DIR). Use $(KERNELDIR).
[22:40:18] <CIA-8> Submakefiles: create ../lib before trying to put a lib there.
[22:48:35] <CIA-8> 03alex_joni * 10emc2/bin/emc-config.in: added first version, configure needs to be fixed for this to work
[23:16:34] <CIA-8> 03alex_joni * 10emc2/bin/emc-config.in: updated the proper param
[23:23:15] <CIA-8> 03alex_joni * 10emc2/ (src/configure.in src/configure scripts/emc.in): configure now takes care of directories and supplies values to changed files (scripts/emc, scripts/realtime, bin/emc-config)
[23:29:33] <SWP_Away> SWP_Away is now known as SWPadnos
[23:34:49] <CIA-8> 03alex_joni * 10emc2/docs/INSTALL: updated latest info
[23:37:14] <CIA-8> 03alex_joni * 10emc2/docs/NEWS: updated NEWS, with jeff's changes to the buildsystem
[23:38:54] <CIA-8> 03alex_joni * 10emc2/debian/changelog: changes to the buildsystem
[23:57:49] <robin_sz> meep?
[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