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