Lerneaen_Hydra is now known as Lerneaen_Hydra_s
Lerneaen_Hydra_s is now known as LH_school
* alex_joni prods jmkasunich
what do you want
make it quick, I'm sweaty and need a shower ;-)
(mowing grass, pulling weeds, etc)
I'm having easier days at work the next few..
can work on changing the HAL stuff.. just need a small direction
you mean that rd/wr stuff
and return values
and maybe changing the hal_pin_bit_new to newf
retvals is probably the messier of the two
hal_rd and wr is the simplest I think
it can _almost_ be done with sed
ok.. I'll have a go at that
for a pin_new call, change HAL_RD to HAL_IN, HAL_WR to HAL_OUT, and HAL_RD_WR to HAL_IO
for a param new call, change HAL_RD to HAL_RO, and both HAL_WR and HAL_RD_WR to HAL_RW
the idea of a write only param is silly, the user can _always_ read them
I think params are silly overall
the WR indicated that _only_ the user would write it, the component would only read, but I think that distinction isn't important anymore
the only advantage of params is that you can do setp
and I kind of agree
a bit more easily than newsig & sets
we would have to redefine setp as "set pin", and have it work for pins that aren't connected to anything
adding a signal for every "parameter" type pin would be insane
that's not that hard
I agree about the signal :)
hmm, there are cases where its not insane
suppose you have identical blocks handling several signals (like x, y, z)
how about creating a constant signal when you issue setp ?
that way it gets set like a parameter and stays that way
if the params were pins, you could connect them all together and then sets them to the same value with one command
prevents changes which are unintentional
no - I don't want all those signals
and I don't want "constant" signals
when created, a pin is connected to a dummy "signal", a memory location that is part of the pin structure
then probably just setp to set the value and that is
setp on an unconnected pin would just change that dummy
right, and if later there is a signal connected and you change the dummy it won't matter
as far as unintended changes, we already have a lock mechanism, but nobody uses it
or maybe we should even error out
setp on a pin that is connected would be an error
if its connected, you use sets
* alex_joni remembers vaguely coding something like that :D
sets if the signal doesn't have a writer
and name the signal that its connected to - to make it clear that you are changing everything connected to the signal, not just that one pin
I like this..
if it does have a writer, then any change sets made would be overwritten by the writer in a few mS anyway
its a big change
probably for the better, but it affects a lot of stuff
halscope and meter, halcmd, plus the internals
but as it is.. 2.0.x is not compatible with 2.1.x
.hal files would still work with this change ;-)
I think scope and meter are the least of the problem
not the ones using setp
because setp foo 3 would have the same effect if foo was a param before and an unconnected pin after
or.. actually they would
thats the beauty of the change - hal files unaffected
anyways.. just wanted to let you guys know
if you ever see a starting up emc that complains about not beeing able to set axis_backlash
given this disciussion - don't start changing HAL_RD, etc, at least not for parameters
it's because motion is not added to a thread (2.0.x does it, pre 2.0. didn't need to)
I'll change all the pins only
2.0.x and 2.1/CVS work the same though?
I think so
had to convert some older configs to 2.0.3
anybody with pre 2.0 will get "asked" to upgrade to a released version ;-)
and I spent quite some while till I figured out what the problem was
of 2.0.1 and 2.0.3 are different that is something to worry about....
but pre 2.0, I no longer want to support
I know.. but this was for puppy :)
which was _some_ TESTING version at one point
anyways.. it's probably best to say it's rip for now :(
ok, time for that shower
the hound has been put to sleep :D
then going out this evening - probably won't talk to you until tomorrow
I'm off to bed soon anyways :)
and it is tomorrow for me .. (just about)
check the board channel before you go
I have no prob with cradek handling it
maybe.. write something?
it's easier to leave proof behind .. for cradek who seems to mind his job for now :D
jmkasunich: then we'll talk tomorrow about param morphing
jepler: this might make the comp easier
do you know by any chance if there's a mult in 2.0.x ?
yep, eliminates one whole class of objects
loadrt blocks mult=1 ?
I was trying to help a user get a positive spindle-speed value
even for reverse operation
ahh, need an abs block
so I suggested * -1
is there an abs ?
in CVS there is mult
there is a sum, that multiplies its inputs by gains and then adds them
so using a wcomp, a mux, and a mult you can do the trick
leave one input unconnected, and you can multiply by a constant (param) gain
probably a regular comp?
param is no good.. I need a pin
sig speed goes to mux input 0, and sum input 0
mult with +1 while forward, mult with -1 while back
sum gain 0 set to -1
sum output goes to mux input 1
select = 1 when speed < 0
ok, didn't figure out how to use a comp to do the <0
that's why I chose a wcomp
comp is just like an analog comparator
you need a dummy signal and a setp on the other input
right - typo
but it only checks for equal
not for greater or less
or am I missing the obvious ?
its a comparator
LM311, LM339, etc
if +in > -in, output hi
if +in < -in, output low
I see.. thanks
I dunno what it does if the two inputs are _exactly_ equal
in this case
as the 2 signals in the mux are equal
* jmkasunich is off to the shower
k, thanks for the tip
I keep seeing a lot of changes to the configs.
And the ones I've modified stop running.'
rayh: we have to break compatibility at one point to allow improvement :(
I know it's a problem and a mess..
if you guys want to change lots of stuff about how hal works, I think we need to branch 2.1 first.
I was wondering, and only wondering if we may want to change the nature of config
so that config lists the intent rather than the specific.
cradek: not lots
basicly we were talking about dropping params and replacing them with pins
this change will probably go unnoticed in the configs
but it will add lots of flexibility
I agree with that.
Although we do set some params now from the ini file.
Those hal lines will need to be changed.
not at all
the setp command will just mean 'set pin' not 'set parameter'
Does that mean we can set any pin?
we will be able to if we make the change
and if the pin is not connected
and if the pin is an input
I'm also uneasy about such a big change if we want to release 2.1.0 soon
jepler: anything specific.. or just the idea itself?
big changes have unexpected consequences
we'll end up releasing 2.1 later than we want to, or with more bugs than if we didn't make this change
I see your point
I think we need to look at changes as "who will it affect" and "can we lump things together, so they only see one change instead of two (or more)"
for example, eliminating params will _not_ require changes to hal files
except for one or two very rare cases
(if you invoke a halmeter in your halfile for example: "halmeter param foo" would become "halmeter pin foo" or perhaps just "halmeter foo"
but few people do that - none of the sample configs do it
the change from "loadrt blocks ddt=3 sum2=4" to "loadrt ddt count=3 ; loadrt sum2 count=4" _will_ affect people
I agree that the time for big changes is _not_ right before a release
eliminating params can wait for 2.2, _especially_ since it doesn't require changing configs
people who adopt at 2.1 won't have to change later
otoh, if there are changes that will require config editing, I'd rather do them sooner than later, if we have confidence in them
because the longer we wait, the more people will have the "old" config and have to fixup when the change comes thru
* jmkasunich drops a pin
but there are source-level incompatabilities, especially if (as I hope) 2.1 encourages people to build components outside the source tree
so you want to defer building outside the tree until 2.2?
clarify: what change introduces source level incompatibilities?
introducing comp? the HAL_WR thing? or changing params to pins?
getting rid of parameters
I was thinking while mowing, and again in the shower...
how bout this:
revise the setp command for 2.1
setp first looks for a param of the specified name
if it finds one it set is
if not, it looks for a pin
it it finds one, and its not connected to anything, it sets it
and encourage people to use pins for everything
at that point, a component can export a pin or a param and it works the same to the user
comp would never support params
and the .h files would encourage people writing comps from scratch to use pins only
by 2.2 we would have removed params completely
but 2.1 works both ways
for 2.2, all traces of parameter would be removed, and setp would _only_ look for unconnected pins
having a transition period eases changes like this
the only thing needed to start using pins only on all new components are the setp changes, and a change to halcmd save
how *does* halcmd save know what to save?
I had only considered the "documentation" value of parameters but that's another issue
(right now, it outputs a setp for every user writable param - it would also need to output a setp for every unconnected input pin, and a sets for every signal with no writer
once params go away, it would only output the last two items
btw, the last version, signals with no writers, is a trick sometimes used today, and the value of those signals does _not_ currently get saved
anyway, I'd like to implement the setp and save changes for 2.1
I can't see a way in which they hurt the existing stuff (but a few more days thought wouldn't hurt)
a plan for transition, and a smaller number of changes in 2.1, make me feel better
_after_ we branch 2.1, we can start actually eliminating params in existing components
and if it turns out to be a mistake, we back out the changes, and when 2.2 comes around, nobody even notices
I was thinking something similar for blocks
If possible, I'd like 2.1 to include comp, and standalone versions of all the stuff in blocks
but it would _also_ include blocks
halcmd loadrt would have a hack added - if you do "loadrt blocks" it would print a warning that blocks is deprecated and recommend switching to the individual components, but it would go ahead and load blocks as requested
for 2.2, blocks (and the halcmd hack) would be removed
it seems like the docs take a long time to build but it's still only 3 minutes real on this laptop
to build everything, not just the docs
not too bad
as long as the docs don't change that often
speaking of docs, I should do a man page, and lyx stuff, for streamer
not tonight tho - going out
one thing before I check in 'comp'
# Yapps 2 - yet another python parser system
# Copyright 1999-2003 by Amit J. Patel <email@example.com>
# This version of Yapps 2 can be distributed under the
# terms of the MIT open source license, either found in the LICENSE file
# included with the Yapps distribution
^^ this is the license of Yapps2
but what does it actually say?
any concerns? or are you just pointing out that its not GPL?
well not really
if it's the X11 license, then gnu.org says it's compatible
in any case, the yapps license doesn't apply to the generated code does it?
well, in the emc2-dev package we'll include the 'comp' program which will use (import) part of yapps, yapps.runtime
so it may matter
we did agree that requiring the installation of yapps and yapps-runtime packages was the thing to do, right?
not include a copy?
runtime in this case is when comp is running, to create a .c file?
ie. build time for emc?
yes, runtime is when turning a .comp into a .c file
I don't see the issue then
at worst, it affects the license you apply to comp, not the licensing of emc/hal
you could release comp under the MIT license if you want, as long as its present when you build emc
I'll let you decide how to deal with that - gotta leave now
I'm going to check this in .. it'll break the whole farm
Yapps 2 is more flexible than Yapps 1 but it requires Python 1.5'
but python 1.5 is so old it might even be the version on bdi2
nah it doesn't have python at all (!?)
bdi-tng and newer have python
yeah, install these: python-1.5.2-43.62.i386.rpm openssl-0.9.5a-33.i386.rpm
* danex is away: Away at the moment