Back
[00:45:29] <jepler> hm, here's an idea. we could have a kernel-rtai metapackage on all our supported platforms, and then have the emc2 package build-depend on it. that would get us closer to having a single emc2 source packages for all supported platforms.
http://raphaelhertzog.com/2010/09/27/different-dependencies-between-debian-and-ubuntu-but-common-source-package/#comment-3628
[01:15:17] <KimK> Sorry to be a VMware noob, but how do I DL a VMware Player appliance (like this one, Ubuntu 8.04.2:
http://lb.vmplanet.net/node/81 ) from vmplanet.net ? It just keeps running me around the webpages, the download/torrent/whatever doesn't begin. What am I missing? Or is there a better place to DL VMware appliances from? Thanks.
[01:17:44] <KimK> (Hope this is not thought off-topic, trying to get Ubuntu 8.04 running in VMware under 10.04 for docs. Don't care about real-time, sim, etc. Just LyX. )
[01:19:24] <KimK> BTW, 10.04 LyX has some kind of "save-as-earlier-version", would that be OK to use? (No, I won't start using it unless approved.)
[01:19:57] <jepler> no idea. I haven't used vmware in years, but I've more recently used virtualbox OSE and qemu, which are both open source products. virtualbox ose will offer a graphical way to create a new virtual machine, and then you can select an 8.04 cdrom image to boot and install from. qemu will work if you are comfortable at the commandline.
[01:21:31] <jepler> besides saving in a format that 8.04 can read and produce pdf documentation from, it's important that small textual changes not make thousands of lines of changes according to "diff", because that makes it hard to see that the actual change is small. You can test the 10.04 "save as earlier version" feature, use "git diff" to see whether the changes after a small textual change are exactly what you changed, or whether it's lots of
[01:24:14] <jepler> (where is "save-as-earlier-version"? is it in the menu?)
[01:24:19] <KimK> OK, that's a good idea about testing the 10.04 LyX. I was only trying VMware because I could never find a way to satisfy the dependency of Xen on xen-tools, which seemed to be "unavailable(?) when I tried it last. But I'm happy to give up on VMware and try virtualbox OSE and/or qemu, if they can be easily installed and used.
[01:24:26] <KimK> Yes, I think it was.
[01:25:08] <KimK> Or maybe it's not necessary if the save-as-earlier-version works.
[01:30:15] <KimK> All I really want is 8.04 conveniently available without rebooting (leaving 10.04), I don't care how I get it, lol. Thanks for your suggestion, and if you think of anything else, please post it, I'm sure it'll be helpful.
[01:36:13] <jepler> looks like qemu has some GUI front ends now available as packages .. qemulator, qemu-launcher, qtemu
[01:38:26] <KimK> OK, sorry, it wasn't really LyX save-as-earlier-version, it was File/Export then a long pick list including LyX 1.3.x, LyX 1.4.x, LyX 1.5.x. But it is on the menu. I'll try your diff test when I get back. Thanks for looking into qemu, I'll try that too. Back in a while.
[01:38:57] <jepler> I'll bbl too
[01:40:06] <jepler> looks like qmeulator isn't bad, I'm already booting the 8.04 live cd
[01:40:10] <KimK> * KimK doesn't want to miss "Monday Night Taco Madness", all you can eat tacos 75c each. Tasty!
[01:40:43] <jepler> (though my past qemu experience probably helps me understand some things that are not immediately apparent to someone who's never used it before)
[01:40:47] <jepler> mmm enjoy
[01:56:04] <ries_> ries_ is now known as ries
[05:47:46] <psha> May someone tell me if i'm wrong or not
[05:48:14] <psha> src/emc/task/emctaskmain.cc use interp_list queue for received commands
[05:48:43] <psha> but it is defined in src/nml_intf/interpl.{hh,cc}
[05:49:11] <psha> It seem that this var is 'local' to milltask
[05:49:43] <psha> So (in some limits) I may do everything I want with it
[05:49:52] <psha> E.g. reschedule tasks by appending them back to interp_list
[08:46:06] <psha> jepler: are you nearby?
[08:48:59] <psha> jepler: i think i have patch for your problem with subsequent MDI commands
[09:32:00] <alex_joni> psha: he's in the US, so still asleep most likely
[09:34:55] <psha> hope his client will notify him that some messages were sent...
[09:36:32] <psha> he was complaining about subsequent mdi commands not working so i've created a patch on top of previous patch-set to fix it
[10:11:43] <alex_joni> psha: cool, surely he reads the backlog
[10:16:29] <jthornton> whats the link to the bug and feature request at sourceforge? I can't seem to find it...
[10:21:06] <jthornton> nm I googled it out of space
[13:12:35] <psha> may someone help me with halui pins?
[13:13:27] <psha> week ago micges said that halui has 100ms delay between processing pins
[13:13:55] <psha> it seem to be 'fixable' at a first glance
[15:29:18] <alex_joni> psha: fixable?
[15:36:22] <psha> when you route one signal to several halui pins it will catch only one
[15:36:45] <psha> if it's not held too long in 'high' state
[15:36:49] <psha> like button press
[15:37:16] <psha> for example 'home all' button
[15:37:27] <psha> which is routed to halui.joint.*.home pins
[15:45:00] <psha> possible workaround is to route it first to oneshot.X.in and then route .out to desired halui pins
[15:45:20] <psha> but maybe it's better to fix bug in halui so others won't need to do it :)
[15:47:47] <cpresser> if could be done quite simple by copying the halui_data-struct and checking on the copy
[15:49:16] <cpresser> but that would not be elegant. and changes to the real halui_data would not get processed
[15:59:52] <psha> cpresser: changes will be processed on next iteration
[16:00:18] <psha> it seem more correct then to loose data while processing part of halui_data
[16:01:01] <psha> as for elegance maybe it's better to put something like std::map with string keys?
[16:02:04] <cpresser> so be honest, I dont know a thing about the shared memory-stuff behind halui_data
[16:02:50] <cpresser> but using dynamic allocation would make that struct obsolete.
[16:03:24] <cpresser> then one would not havt to resort to something like #define MDI_MAX 64
[16:12:51] <psha> MDI_MAX is only soft limit, hal pins are allocated dynamically
[16:13:04] <psha> halui_data is only struct of pointer to shmem
[16:13:33] <psha> dynamic allocation with string keys have one more benefit
[16:13:48] <psha> all pins may be described in one place and then loaded on halui module start
[16:14:16] <psha> only non-ovbious point i see is halui.join.* pins
[16:28:39] <psha> cpresser: if you are willing to review patch I'll try to replace structs with std::map
[16:32:49] <cpresser> psha: I will take a look, and test its functionality
[16:33:43] <cpresser> I have a good understanding of computer programming, however, I lack some knowledge with pointers concepts :)
[16:35:28] <psha> so let's stash jepler's patch and rewrite halui a bit...
[16:37:46] <cpresser> could yo try to include my changes/ideas as well?
http://ca.rstenpresser.de/~cpresser/tmp/emc2.5pre_lenny/patches/halui.cc.multi-named-mdi-command.diff
[16:40:17] <psha> ok
[16:40:31] <psha> i'll apply first your patch and then rewrite to std::map
[16:43:55] <psha> May I add your's signed-off to this patch?
[16:44:05] <psha> I've only cleared trailing whitespaces
[17:16:41] <cpresser> yes, please add it
[17:44:39] <psha> cpresser: things happens to be more diffucult then i hope... (
[17:44:50] <psha> std::map don't provide compile-time checks for types
[17:47:07] <psha> other way to go is some macros magic but it's not suitable here (
[18:40:51] <alex_joni> psha: halui as written is mostly disguised C code
[18:41:10] <alex_joni> feel free to rewrite the heck of it, if you think it'll get better
[18:43:40] <psha> alex_joni: unfortunately it's not so simple :(
[18:43:49] <psha> huge structs provide compile-time safety
[18:44:41] <psha> but maybe i may drop local_halui_data and replace it with copy of halui_data
[18:45:00] <psha> i'm still thinking )
[19:04:26] <psha> jepler: ping
[19:16:44] <psha> jepler: please look at the patch
http://pastebin.com/fXcpQSn1 now subsequent probe & G0 commands work fine
[19:17:35] <psha> jepler: i'll send it to mailing list too
[19:24:22] <alex_joni> psha: even better
[19:24:28] <alex_joni> (sending it to the mailing list)
[19:25:32] <psha> already formatting...
[19:33:58] <psha> sent
[19:34:15] <psha> hope halui will be my last victim :)
[19:37:55] <psha> bb
[20:30:23] <ries_> ries_ is now known as ries
[21:34:26] <andypugh> Rather a noob question here
[21:35:11] <andypugh> Does C allow you to allocate a pointer to something of a type that you won't know the nature of until run-time?
[21:35:29] <alex_joni> void * foo
[21:36:54] <andypugh> And then I can malloc that in a switch such that foo[1]->thingy1.value and foo[2]->different_thingy.value is valid?
[21:37:51] <andypugh> Or does hal_malloc only know the total size of the memory space, not the internal layout?
[21:38:17] <andypugh> Maybe I need to be more specific.
[21:38:20] <alex_joni> malloc functions only alloc a certain size
[21:38:29] <alex_joni> they don't care what goes there
[21:38:39] <alex_joni> you usually cast the result
[21:38:54] <alex_joni> char_ptr = (char *) malloc (size_of(whatever))
[21:39:16] <andypugh> Which means that C has no way to know where to look in that memory for specific datatypes?
[21:39:29] <alex_joni> right
[21:39:58] <andypugh> Hmm.
[21:40:57] <andypugh> I guess that means that each of the sserial objects needs to declare space for each of the several things it can be, and waste the unused ones?
[21:44:28] <alex_joni> why not alloc when you know what you need?
[21:45:17] <andypugh> The situation: The smart-serial Hostmot2 object (of which there can be 8 or more on a single FPGA card) can be plugged in to three (currently) different types of daughter-module. At initialisation the code will poll them all to see what they are, and needs to create pins accordingly. The pins of an 8i20 are not at all the same as a 7i37 so I was anticipating defining a struct for each, and a pointer to the correct type
[21:45:17] <andypugh> the sserial "master" struct.
[21:46:46] <andypugh> (I mean 7i64 I think)
[21:48:35] <andypugh> In VBA (which I have enormously more experience in) I would have a late-bound object in the sserial object and that could then become anything it wanted to be as required.
[21:49:37] <andypugh> I have a VBA application which does almost exactly this, interfacing to two totally different types of hardware through the APIs of two totally different software packages to a common database.
[21:50:16] <andypugh> I guess this is why they made C++ ?
[21:57:47] <andypugh> Thinking about it, I guess I need to look at what the hostmot2 driver itself does, as that copes with a variable number of things of various types. I should be able to copy that, with arrays of of as little as zero objects of each type that need to be supported.
[21:57:59] <andypugh> Perhaps I am making this more difficult than it needs to be.
[21:58:17] <alex_joni> sure sounds complicated ;)
[21:59:04] <andypugh> I think it is fundamentally compicated. I am far from sure that I am the right man for the job.
[22:08:07] <alex_joni> andypugh: it would probably be best to ask seb
[22:08:52] <andypugh> I think I am starting to get my head round it
[22:11:19] <andypugh> seb defined pointers to all the possible types of thing that could be in there, then mallocs the space for as many of them as there are at init. I guess we can live with wasting a few pointers that will never point to anything.
[22:14:37] <alex_joni> that sounds ok
[22:16:01] <andypugh> I was concerned about wasting shared memory, but that is actually allocated at a much later stage, pin by pin.
[22:18:21] <andypugh> 8i20 isn't a valid variable name is it? In fact there is some risk it might be taken to be a complex number!
[23:25:27] <ries_> ries_ is now known as ries