Back
[00:01:24] <jepler> jmkasunich: in a simple block like 'ddt' is it typical to store that data inside the block returned by hal_malloc?
[00:49:00] <dan_falck> jepler: what are you using for the opengl portion of Axis? I'm just now learning a little about pyopengl
[01:11:59] <jepler> dan_falck: I started with pyopengl, but I ended up writing my own module. It's called 'minigl' (because it supports only the opengl calls needed by axis)
[01:12:17] <jepler> I use 'Togl' to put the opengl widget into a Tkinter application
[01:14:29] <jepler> when I used pyopengl, there were 3 main problems: availability. bugs in Togl. bugs in opengl "vertex arrays". there wasn't a packaged version for redhat, which I used at the time. If you didn't tweak the compile, the Togl module didn't work. And there was a bad memory leak in the pyopengl implementation of the opengl calls axis uses to draw the backplot.
[01:14:34] <jepler> these may all be fixed now...
[01:15:14] <jepler> the source for the 'minigl' module:
http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/emc/usr_intf/axis/extensions/minigl.c?rev=1.4;content-type=text%2Fx-cvsweb-markup
[01:16:01] <jepler> axis's private copy of the Togl module is also in the 'extensions' directory
[01:59:35] <dan_falck> thanks
[02:00:40] <jmkasunich> jepler: yes
[02:00:48] <jepler> jmkasunich: oh you're back
[02:00:49] <jepler> just in time
[02:00:50] <jepler> [583330.900483] ddt: Unknown symbol __subsf3
[02:00:52] <jmkasunich> unless you need a lot of data, its simpler
[02:00:53] <jepler> any idea what this means?
[02:01:06] <jepler> wrong cflags when compiling the module?
[02:01:08] <jmkasunich> missing floating point libs?
[02:01:23] <jepler> rtai_math is loaded
[02:01:36] <jmkasunich> this is new code?
[02:01:42] <jmkasunich> or something that used to work?
[02:01:54] <jepler> this is the first fp-using module I tried to compile outside the source tree
[02:02:16] <jmkasunich> there is a lot of weird shit for FP in kernel space
[02:02:35] <jmkasunich> various people have worked on it, I really no longer understand it
[02:02:46] <jmkasunich> I just know the build system works
[02:02:56] <jepler> adding -mhard-math "fixed" it
[02:03:45] <jmkasunich> what are you cooking up outside the source tree?
[02:04:03] <jepler> just another example -- ddt
[02:04:12] <jepler> it's the simplest thing that stores some extra data
[02:04:54] <jmkasunich> re storing data - using the hal memory is the simplest, as long as you don't need much
[02:05:09] <jmkasunich> kmalloc has pretty heavy overhead (I think it might allocate 4K pages)
[02:19:06] <jepler> did you see that I put a first release of the preprocessor up?
http://axis.unpy.net/01157339338
[02:19:27] <jmkasunich> yeah
[02:19:42] <jmkasunich> oh, now I see what you are working on...
[02:19:54] <jmkasunich> need a "storage" item, to go along with pin, function, etc
[02:20:20] <jepler> yep
[02:20:32] <jepler> and now it works
[02:20:34] <jmkasunich> and "param" too (or is that done already
[02:20:45] <jepler> http://emergent.unpy.net/files/sandbox/ddt.comp
[02:20:57] <jepler> param is done -- there's an 'invert' param in the maj3 sample component
[02:21:21] <jmkasunich> maj3? majority voting?
[02:21:40] <jepler> yeah. Its output is 0 if at least 2 inputs are 0, 1 if at least 2 inputs are 1.
[02:21:46] <jmkasunich> neat
[02:21:54] <jmkasunich> just noticed something tho
[02:21:57] <jepler> what's that?
[02:22:06] <jmkasunich> it looks like the tool makes single components
[02:22:22] <jmkasunich> can you do something like blocks that contains lots of little things?
[02:22:59] <jepler> no, not really
[02:23:11] <jmkasunich> I wonder what the tradeoffs are
[02:23:23] <jepler> more modules loaded?
[02:23:49] <jmkasunich> its probably more convenient and natural to do "loadrt ddt num=3" than "loadrt blocks ddt=3"
[02:24:26] <jmkasunich> I don't think hal itself has any hard limits
[02:24:40] <jepler> maybe there's some limit to the number of loaded modules, but it's probably big
[02:24:45] <jmkasunich> but rtapi was done first, and it not as sophisticated, it has some internal data in arrays'
[02:26:02] <jmkasunich> start emc (or just some HAL stuff) and then do cat /proc/rtapi/*
[02:26:31] <jmkasunich> at first glance it seems like modules are _not_ limited
[02:26:36] <jmkasunich> shmem blocks and tasks are
[02:29:32] <jmkasunich> I guess blocks doesn't really have any savings over one module per function
[02:29:45] <jmkasunich> there is little or no actual reused code, just tons of recopied code
[02:30:04] <jepler> text data bss dec hexfilename
[02:30:04] <jepler> 14301 3200 88 17589 44b5../rtlib/blocks.ko
[02:30:04] <jepler> 448 644 4 1096 448../rtlib/ddt.ko
[02:30:17] <jmkasunich> oh, I know that
[02:31:36] <jmkasunich> I was wondering how loading _all_ the blocks individually would compare to loading blocks.ko
[02:31:45] <jmkasunich> and I think I've convinced myself the penalty isn't large
[02:32:10] <jmkasunich> and since few if any configs use _all_ the blocks, individual is probably better, not worse
[02:32:39] <jepler> that may be true
[02:32:51] <jmkasunich> hmm, what exactly is the syntax for the storage?
[02:32:57] <jmkasunich> option <name> <type>?
[02:33:04] <jepler> option data <type>
[02:33:17] <jmkasunich> what if you need more than one variable?
[02:33:18] <jepler> <type> can be a scalar like 'float' or something that is typedef'd after the ;;
[02:34:15] <jmkasunich> so you'd use "in = data->var1 * out" in the function?
[02:34:45] <jepler> data.var1, yes
[02:35:02] <jmkasunich> ah
[02:35:13] <jmkasunich> I use . so rarely I forget about it sometimes
[02:35:47] <jmkasunich> this would handle probably 80% of the components we have
[02:35:55] <jmkasunich> all of the ones in blocks probably, plus many others
[02:36:19] <jmkasunich> some are more complex - stepgen and freqgen for example, with multiple functions (or do you support that too?)
[02:36:49] <jepler> multiple functions are (should be) supported
[02:37:19] <jmkasunich> insmod command line args are not I suppose
[02:37:30] <jmkasunich> (which is a good thing, it would be nice to not have those)
[02:37:47] <jmkasunich> although I'm writing a component right now that does
[02:37:51] <jepler> you can write them after the ;;
[02:37:55] <jepler> and one is used by default: count
[02:38:25] <jmkasunich> pretty complete then
[02:38:47] <jmkasunich> only things that vary their pin/param list at insmod time aren't covered
[02:39:02] <jmkasunich> like drivers that discover how much I/O is installed, then export pins for it
[02:39:04] <jepler> yes
[02:39:18] <jepler> and I'm not sure how driver detection would fit into this anyway
[02:39:32] <jmkasunich> could get messy fast
[02:39:42] <jmkasunich> better to keep this clean like it is now
[02:40:03] <jmkasunich> hmm, just thought of one other caveat
[02:40:03] <jepler> yep
[02:40:13] <jepler> what's that?
[02:40:25] <jmkasunich> blocks contains a lot of stuff today, and we can use any name we want for each thing in there
[02:40:38] <jmkasunich> if each is a module, those names have to live in the kernel module namespace
[02:41:01] <jmkasunich> just like we had to use hal_parport to avoid conflict with linux's parport module
[02:41:21] <jmkasunich> if linux has a ddt, or and2, or mux2, etc module, we have a problem
[02:41:28] <jmkasunich> not likely, but needs to be checked
[02:41:54] <jepler> I could add a separate 'prefix' option
[02:42:01] <jepler> component hal_ddt; option prefix ddt; ...
[02:42:14] <jmkasunich> ?
[02:42:20] <jmkasunich> isn't that prefix hal_ ?
[02:42:49] <jepler> I had in mind that if prefix was specified, all pins, parameters, and functions would have that prefix
[02:43:02] <jepler> so you'd get hal_ddt.ko but pin ddt.0.in
[02:43:03] <jmkasunich> those aren't the issue
[02:43:11] <jmkasunich> oh, ok
[02:43:17] <jmkasunich> not a prefix to be added to the name
[02:43:26] <jmkasunich> but a prefix that replaces the name in identifiers
[02:43:26] <jepler> a prefix to be used instead of the component name
[02:43:36] <jepler> in pin, parameter, and function names
[02:44:03] <jmkasunich> I was thinking more like: component ddt; option prefix hal_; and its used only for the .ko name
[02:44:34] <jmkasunich> anyway, I'd rather avoid it completely
[02:45:17] <jmkasunich> cause you _know_ we're gonna find ourselves telling people "load a ddt block", and they'll come back and say "loadrt ddt" doesn't work
[02:45:35] <jmkasunich> then you start having to remember which ones have hal_ on the front and which don't
[02:46:24] <jmkasunich> for me the holy grail is being able to load one ddt now, and another later, getting rid of the count parameter
[02:46:51] <jepler> yeah that would be nice
[02:47:34] <jmkasunich> problem is, init_module is the only convenient hook we have for executing the "export stuff" code in kernel space
[02:48:11] <jmkasunich> hmm
[02:48:30] <jmkasunich> when I started, everything got loaded with insmod and removed with rmmod
[02:48:35] <jmkasunich> that was before loadrt
[02:48:43] <jmkasunich> what if loadrt got smarter
[02:49:04] <jmkasunich> load a module, say ddt
[02:49:09] <jmkasunich> it doesn't export any hal pins
[02:49:17] <jmkasunich> it does export a function that can export a ddt
[02:49:23] <jmkasunich> (not a hal function, something new)
[02:49:51] <jmkasunich> then when you want to instantiate a ddt, you load a module called say, "newblk"
[02:50:05] <jmkasunich> its init_module calls the function in ddt.ko that exports a ddt
[02:50:17] <jmkasunich> and then it exits
[02:50:44] <jmkasunich> I dunno whether you'd have newblk return an error to linux so it gets unloaded, or have loadrt turn around and unload it
[02:50:56] <jmkasunich> quite a hack now that I think about it...
[02:51:04] <jmkasunich> * jmkasunich stops rambling
[02:51:48] <jepler> that's better than the hack I thought of: addf ddt.new special-creating-thread
[02:52:04] <jmkasunich> ;-)
[02:52:15] <jmkasunich> the only difference is my way hides the hack
[02:52:18] <jmkasunich> invisible threads
[02:52:34] <jepler> the other item that needs to be tackled is names: if I 'newblk ddt', what ddt.N is it?
[02:52:57] <jmkasunich> previous N + 1, I suppose
[02:53:03] <jepler> ugh
[02:53:18] <jmkasunich> the other approach is to let you actually name the block
[02:53:29] <jmkasunich> newblk ddt vel_differentiator
[02:53:43] <jmkasunich> crappy choice of name, but you get the point
[02:53:46] <jepler> I think that's desirable
[02:54:12] <jepler> because then you have a lot more freedom to cut and paste, not worry about renumbering 'ddt's when one of them came from somewhere else
[02:54:35] <jmkasunich> the nicest implementation of newblk would go out and find what kernel module contains ddt, load that module, then somehow invoke the "exporter" function
[02:54:47] <jmkasunich> the second time around it would just invoke the exporter
[02:54:52] <jepler> yeah
[02:54:56] <jmkasunich> you'd also have delblk
[02:55:04] <jmkasunich> and the final delblk would rmmod the module
[02:55:23] <jepler> things written with 'comp' would be in a pretty good position to be adapted to this new way, whenever it's created
[02:55:27] <jepler> since all that is in the generated code
[02:55:34] <jmkasunich> yeah
[02:55:40] <jmkasunich> that would make the transition _much_ easier
[02:56:17] <jmkasunich> anyway, newblk and delblk (and newthread) are things I've been putting off until the hypothetical "hal refactor" thats been on hold for about 2 years now
[02:56:23] <jepler> yeah
[02:56:29] <jepler> if we want 2.1.0 this fall it's still the wrong time to do it
[02:56:35] <jmkasunich> the threads block was a step in the right direction for newthread
[02:56:48] <jmkasunich> agreed about 2.1
[02:56:59] <jepler> time for me to feed the cats and hit the sack
[02:57:05] <jmkasunich> what do you think about comp as a 2.1 thing?
[02:57:25] <jmkasunich> it will involve a one time change to everybody's hal files
[02:57:37] <jmkasunich> (at least those that use blocks or other modules that get moved)
[02:57:57] <jmkasunich> newblock if it ever happens will be another hal file change
[02:58:47] <jepler> even if we put 'comp' in emc2 that doesn't mean we have to get rid of 'blocks'
[02:58:57] <jmkasunich> true
[02:59:11] <jmkasunich> but not long after comp appears, I'm gonna want to redo blocks to use it
[02:59:26] <jmkasunich> its just so much cleaner
[02:59:45] <jmkasunich> blocks.c is 2400 lines
[02:59:50] <jepler> except that it creates an unneeded incompatability
[03:00:08] <jmkasunich> true
[03:00:17] <jmkasunich> maybe use it for new blocks only
[03:00:30] <jmkasunich> then when (hopefully) we get newblk, we take the big step
[03:00:31] <jepler> yeah. the other option is 2.1: provide blocks.c and a bunch of .comps, document that blocks is deprecated. 2.2: remove blocks
[03:01:02] <jepler> it's duplicated code but there's not much work to be done on blocks. anything new would go in a .comp.
[03:01:14] <jmkasunich> yeah
[03:01:53] <jmkasunich> I fear the day when somebody finds a bug in blocks.c and fixes that copy but not the .comp one, or vice versa
[03:02:03] <jmkasunich> but blocks.c is pretty stable
[03:02:14] <jepler> another issue is whether 2.0.x users would benefit from comp
[03:02:43] <jmkasunich> I'm not planning on adding any new components to 2.0.x
[03:02:54] <jmkasunich> (using comp, or writing them out the old way)
[03:03:03] <jepler> yeah, but people may want custom ones for their 2.0.x systems
[03:03:19] <jepler> (which is easy with 2.1's Makefile.modinc, but should be possible in 2.0.x too)
[03:03:31] <jmkasunich> let them upgrade
[03:03:55] <jepler> that's my gut feeling too
[03:04:04] <jepler> anyway .. goodnight
[03:04:08] <jmkasunich> goodnight
[03:04:11] <jmkasunich> and thanks!
[03:04:13] <jepler> I'm glad you like 'comp' so far
[03:04:38] <jepler> I'll put "0.2" online tomorrow with the improvements I made today
[03:04:55] <jmkasunich> anything that eliminates 3/4 or more of blocks.c and keeps the stuff that matters is a good thing
[03:05:12] <jmkasunich> I hate boilerplate code (and I generate a lot if it)
[03:06:19] <jmkasunich> next step is to have the makefile do "for comp in *.comp do make the module ; done"
[03:06:32] <jmkasunich> do you don't even have to edit the makefile when you do a new .comp
[08:57:26] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[19:29:24] <jepler> jmkasunich: any thoughts on if/when I should check 'comp' into CVS?
[19:29:44] <jepler> has anybody else looked at it yet?
[19:29:51] <jmkasunich> not that I know of
[19:30:05] <cradek> I looked at it briefly
[19:30:08] <jmkasunich> I've been to busy - the conversations we've had are the extent of my looking at it
[19:30:48] <jepler> I understand
[19:45:27] <jepler> is SEQUENTIAL_SUPPORT disabled? I don't see anything that would enable it.
[19:48:33] <alex_joni> jepler: just go ahead :)
[19:48:41] <alex_joni> best way to add it afterall