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