Back
    [01:23:34] <jmkasunich> jarl is rugdallur isn't he? 
    
[01:23:39] <jmkasunich> he's been very busy testing 
    
[01:23:58] <cradek> yes 
    
[01:24:43] <jmkasunich> you fixed the machine off spindle stays on problem? 
    
[01:24:58] <cradek> yes, I had hoped to ask him to try it, but I missed him today 
    
[01:25:28] <jmkasunich> you should go into the tracker and set the state to pending, fixed, and leave a comment asking him to test it 
    
[01:25:40] <jmkasunich> that will give him a couple weeks to test, then automatically close the bug 
    
[01:26:08] <cradek> good idea 
    
[01:26:15] <cradek> I don't like that it deletes it, instead of closing it 
    
[01:26:23] <jmkasunich> deletes? 
    
[01:26:52] <jmkasunich> oh, it does... 
    
[01:26:56] <jmkasunich> I didn't realise that 
    
[01:27:01] <jmkasunich> thats dumb 
    
[01:27:09] <cradek> yep 
    
[01:27:44] <jmkasunich> crap - I've done pending on a couple these last few days 
    
[01:28:10] <jmkasunich> although on my case, its "this isn't a bug", so deleted might be appropriate 
    
[01:28:13] <cradek> I looked to see if I could change that behavior, but I can't 
    
[01:28:29] <cradek> I also wanted to add "not a bug" as a resolution, but I can't do that either 
    
[01:28:54] <jmkasunich> SF is so cool! 
    
[01:29:00] <cradek> * cradek sighs 
    
[01:29:09] <cradek> it's worth at least as much as I pay for it, so I don't complain 
    
[01:29:20] <jmkasunich> I don't complain (much) either 
    
[01:29:27] <jmkasunich> I just wax sarcastic at times 
    
[01:29:34] <cradek> I had typed a complaint, but then I deleted it :-) 
    
[01:30:57] <jmkasunich> in my messings around with the xilinx bitfiles, I found out that it will be easy to add both "capabiltiies" and "user preferences" fields to the bitfile 
    
[01:31:08] <jmkasunich> their format is quite extendable 
    
[01:31:57] <jmkasunich> a bunch of chunks, each with a 1 byte tag, 2 or 4 byte length (depends on tag value) and then length bytes of data 
    
[01:32:04] <jmkasunich> followed by another chunk, or eof 
    
[01:32:12] <jmkasunich> they use tags a thru e 
    
[01:32:53] <jmkasunich> I'm gonna use w for "write this to the FPGA RAM after loading the config", for the user preferences (the driver reads from the ram to export HAL stuff) 
    
[01:33:25] <jmkasunich> and something else (dunno what) to convey capabilities to whatever user space config tool the user uses to customize the config 
    
[01:34:01] <jmkasunich> neatly solves some of the security stuff... the user can do the customization on a completely differnt machine if he wants 
    
[01:34:33] <jmkasunich> read the bitfile, use the capabiltiies section to prompt the user, then rewrite it with a new 'w' section containing the responses 
    
[01:35:15] <jmkasunich> no privs at all needed for that 
    
[03:32:10] <steves_logging> steves_logging is now known as steve_stallings 
    
[03:38:17] <cradek> * cradek fixes a bug by removing code... 
    
[03:42:03] <jmkasunich> heh 
    
[03:42:11] <jmkasunich> thats always nice 
    
[03:44:01] <cradek> well I'm a little sad to take it out, but it'll do for now 
    
[03:44:21] <jmkasunich> oh, it was an optimization...  
    
[03:44:31] <jmkasunich> I thought you meant you removed some complexity or something 
    
[03:44:32] <cradek> can you run the release from a shell and see if you get a traceback when typing - and + into the MDI? 
    
[03:44:44] <cradek> in axis I mean 
    
[03:44:56] <cradek> (I get that in trunk but cannot run 2.1 here) 
    
[03:45:10] <jmkasunich> I think I can do that...  
    
[03:45:14] <cradek> thanks 
    
[03:45:19] <jmkasunich> just run the installed version, sim/axis config? 
    
[03:45:22] <cradek> yes 
    
[03:45:52] <jmkasunich> thrash thrash... 
    
[03:46:23] <jmkasunich> thrash thrash... 
    
[03:46:26] <cradek> haha 
    
[03:46:35] <cradek> someone needs some more ram 
    
[03:47:02] <jmkasunich> thrash thrash... 
    
[03:47:07] <cradek> oops I missed bedtime again 
    
[03:47:50] <jmkasunich> it doesn't seem to be hitting the disk that terribly hard... its just nasty slow 
    
[03:48:01] <jmkasunich> I think RT and VMs don't get along 
    
[03:48:04] <jmkasunich> hey! axis is up! 
    
[03:48:28] <jmkasunich> ok, out of estop, machine on 
    
[03:48:40] <jmkasunich> mdi tab active 
    
[03:48:50] <jmkasunich> what do I do, just enter '-' in the line and hit go? 
    
[03:49:49] <jmkasunich> hey cradek ! did I spend 5 mins waiting for axis to start, just so you could go get some beauty sleep? 
    
[03:51:02] <jmkasunich> bah.... 
    
[03:51:09] <jmkasunich> * jmkasunich goes back to what he was doing 
    
[03:51:30] <cradek> heh, sorry 
    
[03:51:42] <jmkasunich> ok, what do I do? 
    
[03:51:50] <cradek> I was getting it whenever (as soon as) I typed - 
    
[03:53:50] <jmkasunich> arg... very not responsive 
    
[03:53:51] <jmkasunich>  23:53:32 up 31 days,  1:19,  8 users,  load average: 13.14, 11.87, 9.15 
    
[04:28:44] <steve_stallings> steve_stallings is now known as steves_logging 
    
[12:18:53] <cradek_> cradek_ is now known as cradek 
    
[14:29:43] <cradek> wow, a lot of activity on the lists lately 
    
[16:07:19] <jepler> I think the hal_parport.c,1.28,1.29 change is wrong -- in 'x' mode, those pins are OC and so either side is permitted to drive them low 
    
[16:08:43] <cradek> when I said the same thing, jmk said it's confusing and not very useful to have that, but to change it back if I want 
    
[16:08:53] <cradek> (big paraphrase) 
    
[18:18:18] <cradek> * cradek grumbles 
    
[18:18:37] <cradek> * cradek goes looking for coffee 
    
[18:20:04] <skunkworks> that can't be good 
    
[18:57:11] <cradek> just the thread on emc-users 
    
[18:57:17] <alex_joni> * alex_joni sighs 
    
[18:57:27] <cradek> hi alex 
    
[18:57:33] <alex_joni> hi 
    
[18:58:09] <cradek> after 8 emails I'm no closer to knowing whether there's a bug or not 
    
[18:59:14] <cradek> well actually I know there's a bug - I can see it in his debug output - but it sounds like it's in his local tweaks that he didn't mention until about message #6 
    
[19:38:47] <skunkworks> so why would he think that it isn't his changes? 
    
[19:39:05] <cradek> I still don't know if it is 
    
[19:39:27] <cradek> if he's just issuing MDI commands programatically, it's doubtful his changes are the problem 
    
[19:39:39] <cradek> because that's all AXIS does when you type the command in 
    
[19:40:10] <skunkworks> ah 
    
[19:41:36] <cradek> but ken is right - if it's not their code, they should be able to reproduce it in an unmodified version, and they should have done that before asking for help 
    
[20:50:47] <skunkworks> cradek: nice sluthing 
    
[20:51:05] <cradek> think I found it? 
    
[20:51:14] <skunkworks> sounds like it - doesn't it? 
    
[20:51:40] <skunkworks> job for alex_joni? :) 
    
[20:52:14] <cradek> yeah, poor alex 
    
[20:52:32] <alex_joni> what is? 
    
[20:53:01] <cradek> I found a bug that might be what Tomasz/Michal were reporting 
    
[20:53:20] <alex_joni> eek 
    
[20:53:24] <alex_joni> just read it 
    
[20:53:44] <alex_joni> I'll sleep it over.. 
    
[20:53:49] <cradek> ok :-) 
    
[20:54:02] <alex_joni> not sure that we have the current pos in canon 
    
[20:54:04] <cradek> I tried sprinkling GET_EXTERNAL_POSITION() calls around, but it didn't help 
    
[20:54:07] <alex_joni> where this is calc'ed 
    
[20:54:20] <cradek> well we can get it with GET_EXTERNAL_POSITION 
    
[20:54:50] <alex_joni> * alex_joni looks 
    
[20:54:54] <cradek> but when using run from line, it seems to do the calcs/gets for the previous lines even though they are skipped 
    
[20:55:06] <cradek> so obviously I don't know how 'run from line' works 
    
[20:55:28] <cradek> but since it's in task, I assigned it to you :-) 
    
[20:55:54] <cradek> does it help if I say I think you're very smart and brave because you fix our task bugs? 
    
[20:57:56] <alex_joni> haha 
    
[20:58:14] <alex_joni> are you sure it's in task? 
    
[20:58:35] <cradek> pretty sure, that's where all the skipping and stuff happens 
    
[20:58:54] <alex_joni> interp_list.clear(); 
    
[20:59:01] <alex_joni> that's all that happens in task :D 
    
[20:59:13] <alex_joni> while     if (programStartLine < 0 || 
    
[20:59:13] <alex_joni> emcStatus->task.readLine < 
    
[20:59:13] <alex_joni> programStartLine) { 
    
[20:59:20] <cradek> I have to run ... 4:00 
    
[20:59:26] <alex_joni> ok, see you 
    
[20:59:29] <cradek> goodnight if I don't see you later 
    
[20:59:41] <alex_joni> I don't think it's a task issue.. 
    
[20:59:49] <alex_joni> it's a concept issue 
    
[20:59:52] <alex_joni> which is worse :( 
    
[21:00:05] <cradek> eek 
    
[21:00:17] <cradek> run from line is so problematic, I'm not too surprised 
    
[21:00:28] <cradek> however I bet we can fix *this*  
    
[21:00:29] <alex_joni> it simply skips over existing lines 
    
[21:00:42] <alex_joni> but canon has no idea that it skiped vs. executed 
    
[21:01:04] <cradek> well not really - it seems like it actually calls STRAIGHT_TRAVERSE for line 2, when I "run from" line 3 
    
[21:01:07] <cradek> that's what screws it up 
    
[21:01:15] <cradek> somehow, that line 2 causes no motion though 
    
[21:01:38] <cradek> like I said, I don't know how the skipping works 
    
[21:02:18] <alex_joni> well.. it runs teh interp 
    
[21:02:22] <alex_joni> which calls the canon calls 
    
[21:02:28] <cradek> have to go!  :-) 
    
[21:02:28] <alex_joni> but then task discards the stuff 
    
[21:02:33] <alex_joni> ok.. talk to you later 
    
[21:02:35] <cradek> we'll look tomorrow