Back
[00:56:19] <CIA-67> EMC: 03jepler 07v2_3_branch * 10emc2/VERSION: prepare for release
[00:56:22] <CIA-67> EMC: 03jepler 07v2_3_branch * 10emc2/debian/changelog: prepare for release
[00:56:22] <CIA-67> EMC: 03jepler 07v2_3_branch * 10emc2/src/configure: prepare for release
[00:58:43] <CIA-67> EMC: 03jepler 07v2_3_branch * 10emc2/VERSION: bump version number after release
[00:58:47] <CIA-67> EMC: 03jepler 07v2_3_branch * 10emc2/debian/changelog: bump version number after release
[00:58:49] <CIA-67> EMC: 03jepler 07v2_3_branch * 10emc2/src/configure: bump version number after release
[01:35:55] <cradek> woo
[01:39:45] <jepler> yeah, now we just wait for me to upload them at 24kB/second
[02:34:05] <jepler> doh, I forgot I was going to backport the increased hal size to this release :(
[02:34:15] <jepler> oops
[02:35:01] <SWPadnos> 2.3.1.1 :)
[04:28:53] <tfmacz> join #emc
[04:30:16] <tfmacz> Has anyone compiled emc-sim on 9.04?
[08:07:32] <alex_joni> tfmacz: any issues?
[08:07:44] <alex_joni> I think SWPadnos runs -rt on 9.04
[08:55:58] <SWPadnos> alex_joni, tfmacz I have compiled RTAI packages on 9.04, and run the available -rt flavor, but neither was stable
[08:56:41] <alex_joni> SWPadnos: how many RTAI kernels did you go through?
[08:56:46] <SWPadnos> one :)
[08:56:55] <alex_joni> there might be the culprit ;)
[08:57:35] <SWPadnos> considering that the stock -rt kernel also died within a day or two every time, I don't feel so bad
[08:57:47] <alex_joni> oh, definately don't feel bad ;)
[08:57:51] <alex_joni> what kernel is it?
[08:57:55] <alex_joni> 2.6.28 ?
[08:58:34] <alex_joni> I think I read there are serious stability problems with 2.6.27 and IPIPE, and also with 2.6.28
[08:58:38] <alex_joni> 2.6.29 should be better
[08:59:42] <SWPadnos> hmmmdunno, can't check. got a plane to catch
[08:59:44] <SWPadnos> see you later
[09:50:09] <alex_joni> safe trip
[14:42:37] <CIA-48> EMC: 03jepler 07v2_3_branch * 10emc2/debian/changelog: bump hal shared memory area
[14:42:37] <CIA-48> EMC: 03jepler 07v2_3_branch * 10emc2/src/hal/hal_priv.h: bump hal shared memory area
[18:15:05] <cradek> cradek has changed the topic to: EMC2 development --
http://linuxcnc.org/ | Current version: 2.3.1 | channel logged by logger_dev
[18:15:42] <cradek> cradek has changed the topic to: EMC2 development --
http://linuxcnc.org/ | Latest release: EMC 2.3.1 | channel logged by logger_dev
[19:34:50] <BigJohnT_> BigJohnT_ is now known as BigJohnT
[22:41:05] <SWPLinux> so, I wrote a component that converts a u32 into up to 32 bits
[22:41:14] <SWPLinux> any preferences as to what it should be called?
[22:41:36] <SWPLinux> hmmm. looks like 31 bits is the limit - have to fix that
[22:49:41] <SWPLinux> hmmm again. I guess it does go up to 32, but you have to specify personality=31 to get it
[22:50:05] <SWPLinux> I guess I'll change the docs to say that personality is the highest numbered bit you want :)
[22:52:06] <jepler> hm is there a fencepost error in the way comp specifies variable arrays? or are you putting in -1s or +1s yourself?
[22:52:18] <SWPLinux> I had to add a +1 to get to 32
[22:52:45] <SWPLinux> I would have tried ((personality-1)&0x1F)+1, but 0 would be problematic there
[22:53:19] <SWPLinux> there are a couple of problems with personality though (or how I'm using it)
[22:53:29] <SWPLinux> one, I didn't see a way to set a default value
[22:54:02] <SWPLinux> so you must specify personality, or you get no output bits (actually one now, since I have the +1 in the index calculation, so that may be OK)
[22:54:33] <SWPLinux> it's the same for logic - don't specify personality, get no inputs (or outputs)
[22:55:29] <SWPLinux> I scanned through comp.g looking for information on personality, and I saw a lot of places where the number 16 is used
[22:55:34] <alex_joni> good night all
[22:55:47] <SWPLinux> it doesn't seem to be a limit on the number of pins though, as I thought it might be
[22:55:50] <SWPLinux> see you alex_joni
[22:57:07] <jepler> 16 is the size of the array that accepts personality values
[22:57:18] <SWPLinux> ah, ok
[22:57:31] <SWPLinux> 16 instances of the component
[22:57:35] <SWPLinux> data
[22:57:57] <SWPLinux> ah, I see
[22:58:17] <SWPLinux> logic uses personality&0xFF, so you can specify 16 and it fits
[22:58:31] <SWPLinux> I got tricky and used 0x1F, so 32 doesn't fit
[23:00:53] <jepler> there's a bug with EXTRA_SETUP and personality, but this is how I wish it could be solved:
http://pastebin.ca/1425910
[23:00:56] <jepler> it gives a compile error instead
[23:01:32] <SWPLinux> oh, EXTRA_SETUP. duh
[23:03:45] <SWPLinux> hmmm, yeah. EXTRA_SETUP doesn't have the variant with the extra personality argument
[23:04:08] <SWPLinux> that's instance-specific, can't it be part of the instance data?
[23:04:21] <SWPLinux> (IIRC, it was a separate pointer)
[23:04:30] <jepler> right, that's the problem
[23:05:05] <jepler> you can try this:
http://emergent.unpy.net/files/sandbox/fix-personality-with-extra-setup.patch
[23:05:08] <jepler> I have to bbl
[23:05:14] <SWPLinux> oki
[23:05:15] <SWPLinux> -i
[23:05:47] <jepler> you could also try writing out-##[personality?32:personality]; I don't know how much of C is permitted in there, or how that'll parse since there are multiple colons
[23:05:51] <jepler> bbl
[23:07:02] <SWPLinux> I tried a ?: and got errors