Back
    [00:00:27] <jepler> seb_kuzminsky: I'm not sure what would set a limit lower than "unlimited" for scripts run from init.. 
    
[00:00:52] <seb_kuzminsky> buildbot runs from init, and it has a memlock limit of 32k 
    
[00:02:01] <jepler> seb_kuzminsky: there's an /etc/init.d/buildbot that's run as root by init? 
    
[00:02:07] <jepler> I'd try putting a ulimit-setting directive in that script 
    
[00:02:07] <seb_kuzminsky> yes 
    
[00:02:24] <jepler> I would expect this to work if running as root:  ulimit -l unlimited 
    
[00:02:49] <jepler> or 20480 or whatever 
    
[00:03:08] <jepler> jepler@platte:~$ sudo -s 
    
[00:03:08] <jepler> root@platte:~# ulimit -l 
    
[00:03:08] <jepler> 32 
    
[00:03:08] <jepler> root@platte:~# ulimit -l 20480; ulimit -l 
    
[00:03:08] <jepler> 20480 
    
[00:04:59] <seb_kuzminsky> yep 
    
[00:06:22] <seb_kuzminsky> i put it in /etc/default/buildbot 
    
[00:07:49] <seb_kuzminsky> building now, we'll see what it does 
    
[00:11:10] <seb_kuzminsky> that looks good 
    
[00:11:16] <seb_kuzminsky> yay it passed 
    
[00:11:17] <seb_kuzminsky> :-) 
    
[00:11:55] <jmkasunich> interesting "saga" 
    
[00:12:23] <jmkasunich> my farm would not have that issue (not sure if that is good or bad) 
    
[00:12:40] <jmkasunich> I log into the VM as a normal user, open a shell, and start the farm script 
    
[00:13:01] <seb_kuzminsky> i just wanted it more automatic 
    
[00:13:16] <seb_kuzminsky> it start the buildslave at boot time without human intervention 
    
[00:13:39] <jmkasunich> I should probably do something like that here too, but I'm lazy 
    
[00:14:16] <jmkasunich> and what I have is convenient - I start it with "./run_farm &", then do a "tail -f farm_log", so all I need to do is glance at the shell to see what is happening 
    
[00:17:51] <seb_kuzminsky> ok i just updated the hardy and dapper buildslaves to run with "ulimit -l unlimited" 
    
[00:18:07] <seb_kuzminsky> and kicked off a rebuild of the top-of-tree (TRUNK and v2_2_branch) 
    
[00:18:13] <seb_kuzminsky> i think it will be all green 
    
[00:18:23] <seb_kuzminsky> bbl folks 
    
[01:21:21] <seb_kuzminsky> yay buildbot's all green :-) 
    
[01:29:34] <jmkasunich> I bet I can fix that 
    
[01:33:11] <SWPadnos> heh - not a problem on this end either : 
    
[01:33:13] <SWPadnos> :) 
    
[01:54:44] <seb_kuzminsky> tomorrow i will clean the corner of the garage that i use as a workshop 
    
[01:54:46] <seb_kuzminsky> :-) 
    
[01:55:57] <seb_kuzminsky> i'm gonna install mailman on emc2-buildbot and make a list for build status 
    
[01:56:17] <seb_kuzminsky> like jmk suggested: start sending mails when it start failing, stop after it start working again 
    
[01:57:06] <seb_kuzminsky> but now i'm gonna go read bedtime books for the kids 
    
[01:57:45] <SWPadnos> see dick and jane sleep 
    
[03:37:53] <jepler> seb_kuzminsky: thanks for committing that rtai_malloc fixaround 
    
[03:38:18] <seb_kuzminsky> sure 
    
[03:38:29] <seb_kuzminsky> i wasnt sure from your comment if you thought it was a good idea or not 
    
[03:39:40] <cradek> hi guys 
    
[03:39:52] <jepler> seb_kuzminsky: in an ideal world we'd build the fixed rtai packages instead of working around it, since we supply both to our users 
    
[03:39:57] <jepler> but .. that's no fun 
    
[03:40:22] <seb_kuzminsky> hi chris 
    
[03:40:49] <seb_kuzminsky> i'll work with the rtai guys to get it fixed, then when the bug is dead & buried in like a decade we can remove our workaround 
    
[03:41:33] <jepler> heh 
    
[03:46:00] <jepler> 'night guys 
    
[03:47:57] <cradek> bye 
    
[03:52:20] <seb_kuzminsky> seeya jepler  
    
[04:02:06] <CIA-38> EMC: 03seb 07TRUNK * 10emc2/docs/man/man9/hm2_7i43.9: add a note to load probe_parport before hm2_7i43 
    
[04:04:18] <cradek> I would not have thought of that... 
    
[04:04:36] <cradek> not at first anyway. 
    
[04:11:43] <seb_kuzminsky> well that might not be it 
    
[04:11:50] <seb_kuzminsky> epp man, what a drag 
    
[04:11:52] <seb_kuzminsky> gimme pci any day 
    
[04:12:03] <cradek> yeah I wasn't going to say that, but I was thinking it 
    
[04:12:42] <seb_kuzminsky> we all were... 
    
[04:12:48] <cradek> parport makes me think of all the cheap consumer devices of the late 90s (pre-usb) 
    
[04:13:21] <cradek> when scanners (and tape drives, and quick cams, and card readers) were too cheap to be scsi, but there was no usb 
    
[04:13:31] <seb_kuzminsky> back in the bad old days 
    
[04:13:38] <cradek> that stuff was always just a big pain 
    
[04:13:51] <seb_kuzminsky> remember zip drives? 
    
[04:14:00] <cradek> sure 
    
[04:14:10] <cradek> I bet the external ones were parport 
    
[04:14:29] <cradek> I never did use them.  they were just 'big floppies' and I already had networking. 
    
[04:15:24] <seb_kuzminsky> the network pretty much saved all our bacon 
    
[04:15:43] <seb_kuzminsky> grr, eric still got problems 
    
[04:16:44] <cradek> has he sent a full dmesg? 
    
[04:16:51] <seb_kuzminsky> no 
    
[04:16:53] <cradek> would be nice to see it with probe_parport etc 
    
[04:17:07] <seb_kuzminsky> when will they learn we're not clairvoyant? 
    
[04:17:19] <cradek> never 
    
[04:17:28] <cradek> it's so irritating 
    
[05:34:59] <CIA-38> EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/ (5 files): Changes to allow the user to select what variables MODBUS is mapped to. read coils,inputs and write coils done. TODO registers 
    
[07:02:22] <CIA-38> EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/protocol_modbus_master.h: Fix transposed constant 
    
[14:34:11] <seb_kuzminsky> the rtai guys say the funny return value from rtai_malloc is a feature, not a bug... 
    
[14:38:46] <cradek> but that seems so unlikely to be true 
    
[14:39:07] <cradek> (does he go on to say why he thinks that?) 
    
[14:54:27] <Guest198> feature by design.. 
    
[14:54:34] <Guest198> Guest198 is now known as skunkworks_ 
    
[15:00:16] <skunkworks_> alex is on the move. 
    
[15:00:50] <alex_mobile> Hi 
    
[15:01:18] <alex_mobile> Actually waiting for someone in my car. 
    
[15:02:47] <alex_mobile> What's up? 
    
[15:03:25] <skunkworks_> heh - nothing.  all I know so far is that the funny return value from rtai_malloc is a feature according to the rtai people. 
    
[15:03:59] <alex_mobile> Yeah, I read that too. 
    
[15:04:14] <skunkworks_> :) 
    
[15:04:43] <alex_mobile> Paolo is strange sometimes... 
    
[15:04:54] <skunkworks_> and there is a 4 day weekend coming up. 
    
[15:05:10] <alex_mobile> How come? 
    
[15:06:19] <alex_mobile> Thanksgiving? 
    
[15:08:52] <skunkworks_> yes 
    
[15:08:59] <skunkworks_> turkey day 
    
[15:09:17] <skunkworks_> we actually are going to have wild turkey this time. 
    
[15:09:50] <alex_mobile> Wild as in crazy? 
    
[15:10:06] <alex_mobile> :P 
    
[15:10:19] <skunkworks_> :)  
    
[15:10:47] <skunkworks_> should be interesting. 
    
[15:11:33] <cradek> wow, look at classicladder/arrays.c:204 (in a good unix editor) 
    
[15:11:37] <cradek> I wonder how that's compiled 
    
[15:12:05] <Lerman_____> Lerman_____ is now known as Lerman 
    
[15:13:27] <alex_mobile> No unix editor on my cellphone :( 
    
[15:15:05] <cradek> // comment ^M  if (condition)  
    
[15:15:06] <cradek> { 
    
[15:15:07] <cradek> ... 
    
[15:15:33] <alex_mobile> Ouch 
    
[15:15:39] <seb_kuzminsky> about a quarter of our coverity issues are in classicladder 
    
[15:15:39] <cradek> yeah no kidding 
    
[15:15:50] <seb_kuzminsky> (another quarter is in libnml) 
    
[15:15:50] <cradek> seb_kuzminsky: hmm. 
    
[15:16:30] <alex_mobile> So half in the actual emc2 code 
    
[15:16:53] <seb_kuzminsky> lol @ arrays.c 
    
[15:17:20] <seb_kuzminsky> see you guys later 
    
[15:17:47] <alex_mobile> Later seb 
    
[15:21:48] <alex_mobile> * alex_mobile needs a BT keyboard 
    
[15:55:10] <jepler> oh god, I hope it turns out there's not any audio of RMS signing this tune:  
    
[15:55:11] <jepler> http://web.cecs.pdx.edu/~trent/gnu/bull/04/bull4.html#SEC11 
    [15:55:53] <cradek> ack 
    
[16:15:18] <cradek> AskFrame[ FrameSize++ ] = Value-((Value>>8)*256); 
    
[16:38:15] <jepler> ?? 
    
[16:49:57] <skunkworks_> jepler: nice email 
    
[16:50:39] <jepler> skunkworks_: thanks, I tried very hard to be civil and factual. 
    
[16:50:41] <jepler> it becomes a struggle. 
    
[16:50:51] <CIA-38> EMC: 03cradek 07TRUNK * 10emc2/src/hal/classicladder/arrays.c: remove ^M from this file to fix a very shady situation: // comment ^M if(condition) n { ... 
    
[16:51:37] <CIA-38> EMC: 03cradek 07TRUNK * 10emc2/src/hal/classicladder/config_gtk.c: fix overruns due to undersized arrays 
    
[16:52:13] <skunkworks_> jepler: you did good :) 
    
[16:55:17] <CIA-38> EMC: 03cradek 07TRUNK * 10emc2/src/hal/classicladder/protocol_modbus_master.c: remove dos line endings 
    
[17:02:01] <jepler> cradek: there's a lot more where that came from.  
http://emergent.unpy.net/files/sandbox/dos-contaminated.txt 
    [17:02:16] <jepler> (assuming my program's right, anyway) 
    
[17:02:29] <cradek> I'm only fixing the ones I also want to make a substantive change to 
    
[17:02:36] <jepler> ok 
    
[17:02:48] <cradek> in fact, I'm done crapping around in classicladder 
    
[17:02:54] <cradek> which makes me happy 
    
[17:06:20] <CIA-38> EMC: 03cradek 07TRUNK * 10emc2/src/hal/utils/meter.c: this does not have to be global, because it's passed to refresh_value 
    
[17:07:55] <CIA-38> EMC: 03cradek 07TRUNK * 10emc2/src/rtapi/sim_rtapi.c: this result covered the other result - no bug, just silly 
    
[17:12:11] <cradek> interesting that CIA nuked the \ in my message 
    
[17:12:30] <cradek> I figured it was my fault, but I don't think so, since it's in the email 
    
[17:14:45] <BigJohnT> * BigJohnT kicks cia-38 
    
[17:14:45] <CIA-38> ow 
    
[17:14:53] <BigJohnT> maybe that fixed it 
    
[17:15:06] <cradek> can't hurt. 
    
[17:15:28] <jepler> sounds like it hurt 
    
[17:26:07] <jepler> Did you mean: "mt dew" segmentation fault   
    
[17:26:11] <jepler> gee thanks google 
    
[17:26:13] <jepler> no, I didn't. 
    
[17:27:24] <seb_kuzminsky> mt dew is implicated in 69.8% of my segfaults 
    
[17:27:41] <jepler> in this case, I'm trying to figure out why 'mt rew' segfaults on this machine 
    
[17:28:03] <cradek> it's still doing it? 
    
[17:29:37] <jepler> cradek: yes 
    
[17:29:45] <jepler> today I discovered that 'mt rewi' doesn't 
    
[17:29:53] <cradek> uh 
    
[17:30:11] <jepler> ikirst@nori:~$ ltrace mt rew 
    
[17:30:15] <jepler> ... 
    
[17:30:15] <jepler> strncmp("rewoffl", "rew", 3)                                      = 0 
    
[17:30:16] <jepler> strlen("rewoffl")                                                 = 7 
    
[17:30:23] <jepler> ikirst@nori:~$ ltrace mt rewind 
    
[17:30:35] <cradek> ohh 
    
[17:30:37] <jepler> er, I guess I spelled it out all the way 
    
[17:30:39] <cradek> different command 
    
[17:30:48] <jepler> yeah, looks that way 
    
[17:31:10] <jepler> actually, I *think* that it may be trying to produce the message to tell me I typed an ambiguous command.. 
    
[17:31:56] <cradek> how could mt have broken?  is there a lot of development going on in there? 
    
[17:32:11] <jepler> beats me 
    
[17:32:11] <cradek> someone probably decided to i18nize it 
    
[17:32:22] <jepler> setlocale(6, "")                                                  = "en_US.UTF-8" 
    
[17:32:25] <jepler> bindtextdomain("cpio", "/usr/share/locale")                       = "/usr/share/locale" 
    
[17:32:28] <jepler> textdomain("cpio")                                                = "cpio" 
    
[17:32:30] <jepler> of course 
    
[17:33:01] <cradek> if only there was a way to tell what changed between dapster and harny 
    
[17:33:42] <SWPadnos> cvs diff -rdapper -rhardy > bigfile 
    
[17:33:46] <SWPadnos> :) 
    
[19:48:04] <alex_joni> hi guys 
    
[19:48:17] <jepler> afternoon alex_joni  
    
[19:48:29] <alex_joni> what's up? 
    
[19:54:08] <jepler> oh, nothing worth talking about 
    
[19:54:40] <alex_joni> haha, read that 
    
[19:55:13] <SWPadnos> that's never stopped us before 
    
[19:55:53] <alex_joni> crap.. think I caught a cold 
    
[19:56:38] <jepler> :( 
    
[19:56:40] <jepler> don't do that 
    
[19:56:54] <SWPadnos> yeah, toss it back 
    
[20:06:49] <SWPadnos> jepler, do you remember why stepconf only outputs 0.95* (vel based on ideal_period) for max_vel? 
    
[20:07:24] <jepler> SWPadnos: I think it was the easiest way to add stepgen headroom 
    
[20:08:44] <SWPadnos> ok, looking at it, it seems that the ideal_period() function doesn't use the user-supplied velocity value 
    
[20:08:54] <SWPadnos> oh wait, of course it does 
    
[20:09:09] <SWPadnos> ok, so that's the confusion 
    
[20:09:38] <SWPadnos> the guy on CNCZone who hasn't been able to make his G540 work has mentioned that the velocity is only 95% of what he entered 
    
[20:09:54] <SWPadnos> which makes sense, since I see that calculation right there in stepconf :) 
    
[20:11:17] <SWPadnos> but it's a bit confusing that his machine moves at 21.8IPM instead pf the 24 he entered.  it seems that the hz value should be calculated using (1/0.95)*maxvel, so that the actual velocity limit will match user input if the machine can do it 
    
[20:31:44] <jepler> like I said, I think it was the easiest way I saw to add stepgen headroom 
    
[20:31:48] <jepler> I agree it's not ideal 
    
[20:32:08] <SWPadnos> oh, it works but it's suprising for some users :) 
    
[20:33:07] <SWPadnos> I could swear that I added code to account for the needed encoder counting rate when calculating min_period 
    
[20:33:12] <SWPadnos> but I can't find it 
    
[20:33:16] <jepler> hah! 
    
[20:35:56] <SWPadnos> maybe I just thought about it, but someone convinced me it was too hard :) 
    
[23:39:51] <seb_kuzminsky> http://www.linuxdevices.com/news/NS7876661673.html 
    [23:40:21] <seb_kuzminsky> commercial robot arm controlled by Linxu & Xenomai & open-source software  
    
[23:41:27] <SWPadnos> cool.  looks like 6 joints plus the grip (unless that's also a positionable servo joint) 
    
[23:41:44] <SWPadnos> but it does mean that there's a working RT kernel on PPC 
    
[23:41:47] <SWPadnos> which is nice 
    
[23:58:26] <CIA-42> EMC: 03jepler 07TRUNK * 10emc2/src/Makefile: fix additional -O2 instances