#emc-devel | Logs for 2011-09-24

Back
[00:03:51] -!- theorbtwo has quit [Ping timeout: 256 seconds]
[00:03:56] theorb is now known as theorbtwo
[00:09:09] -!- jimlay has quit [Ping timeout: 255 seconds]
[00:12:13] -!- Loetmichel has quit [Ping timeout: 260 seconds]
[00:14:45] <SWPadnos> not unforgivably lazy, but you should realize that HAL shared memory is a more contrained resource than generic kernel memory
[00:15:02] <SWPadnos> it's so constrained, there isn't room for the "s"!
[00:26:16] -!- dgarr [dgarr!~dgarrett@adsl-76-230-239-49.dsl.pltn13.sbcglobal.net] has joined #emc-devel
[00:27:40] <andypugh> I am thinking in terms of 8 floats
[00:28:43] <andypugh> Actually, that's not quite true, it could be an arbitrary number of floats, but who needs a 20+ order polynomial?
[00:29:45] <andypugh> I am working on an arbitrary-order polynomial function (based on a request for thermistor / thermocouple linearisation)
[00:30:35] <andypugh> Oh, and while you are talking, any thoughts on my idea of making HAL blind to the difference between _ and - ?
[00:42:30] -!- dgarr1 [dgarr1!~dgarrett@adsl-76-230-236-170.dsl.pltn13.sbcglobal.net] has joined #emc-devel
[00:42:55] -!- dgarr has quit [Ping timeout: 248 seconds]
[00:52:54] <SWPadnos> andypugh, what part(s) of HAL?
[00:53:29] <andypugh> find_pin_by_name
[00:53:45] <SWPadnos> nope
[00:53:47] <andypugh> (I explained in a dv mailing list post)
[00:53:50] <SWPadnos> ah
[00:54:48] <andypugh> The canonical pin naming spec states that underscores are bad, and will be removed. But doing that breaks existing configs.
[00:55:21] <SWPadnos> breaking existing configs is acceptable for a .x release (ie, 2.4 to 2.5)
[00:55:24] <SWPadnos> not that it's desirable
[00:55:33] <andypugh> My thinking is that there are no pins where treating - and _ as matching leads to ambiguity
[00:55:46] <SWPadnos> it should be possible to use some sed-foo to update many HAL configs
[00:56:13] <andypugh> I am thinking in terms of live configs out in the wild
[00:56:27] <SWPadnos> another question: should one or the other character be disallowed (or converted) from the command line?
[00:56:45] <SWPadnos> well, the user should expect to need to update configs when moving between point releases
[00:57:26] <SWPadnos> and we (by that I mean you :) ) can write a sed script to semi-automate the process, and stick it on the wiki or in the 2.5 packages
[00:57:35] <andypugh> I just wrote a hal_strcmp where pin-out == pin_out. To be honest I see no drawbacks, and it would have saved me a fair bit of head scratching
[00:58:25] <SWPadnos> halcmd loadrt and2 names=bob_in,bob_out
[00:58:32] <SWPadnos> what happens there?
[00:59:07] <SWPadnos> it should be confusing for someone to use that line, and then connect bob-in.in1 to something (vs. bob_in.in1)
[01:00:25] <andypugh> Well, at the moment I am only suggesting it for pins, not functions, and it could be limited to oldname anyway.
[01:00:57] <SWPadnos> all pins created from bob_in would have bob_in in their names, so by definition bob-in would also work
[01:01:14] <SWPadnos> that's not necessarily a bad thing, but as Chris M said, it oculd lead to more confusion down the road
[01:01:18] <SWPadnos> could
[01:01:44] <andypugh> And I doubt that your scenario causes any more confusion than I have felt not noticing a _- error.
[01:01:56] <SWPadnos> err, Jon E said that I guess
[01:02:01] <SWPadnos> heh
[01:02:18] <andypugh> making labels case-insensitive is fairly common (and we could do that too)
[01:02:39] <SWPadnos> that kind of change is often not good
[01:02:51] <SWPadnos> it trades some problems for others
[01:03:38] <SWPadnos> there's a big difference between "Therapist" and "TheRapist" :)
[01:04:53] <andypugh> Are you suggesting that there are HAL configs out there in Userland where the only difference between pin names is a _ and a -? That would involve someone a) making a custom component (because there aren no such ambiguities in the base code) and b) being very stupid :-)
[01:05:31] <andypugh> Maybe I should ask this quesrtion on expertsexchange.com?
[01:05:32] <SWPadnos> remember, it's not just pin names, or shouldn't be at least
[01:05:58] <SWPadnos> it would be confusing to have some words automatically changed, but not others
[01:06:22] <SWPadnos> so it should be any hal name: pin, param, component, function, thread ...
[01:06:52] <andypugh> Nothing actually changes, the pin names stay the same. But net this_pin finds this-pin too.
[01:07:09] <SWPadnos> oh yeah, nets
[01:07:16] <SWPadnos> /signals
[01:07:31] <SWPadnos> I understand. my point is that it should be consistent
[01:07:44] <SWPadnos> or it will get even more confusing
[01:08:30] <SWPadnos> I understand the frustration of having a typo like that cause problems - I don't know how many times I have stared at a few lines of code, just to find some * where there should be a / or whatever
[01:08:54] <SWPadnos> but I *really* don't want to trade that for another kind of confusing situation
[01:09:25] <andypugh> You can make an argument for not doing it for aliased names, because users should be able to have this_pin and this-pin unambiguous, but is somebody types encoder.0.index_enable then they are almost definitely wanting encoder.0.index-enable
[01:09:40] <SWPadnos> it sure would make it harder to help people. someone pastebins their HAL file, and now I need a regex to find some pin
[01:10:10] <andypugh> I think, however, we have strayed from the point.
[01:10:14] <SWPadnos> sure, and the error message should tell them which line to look at to find their error
[01:10:33] -!- dgarr1 has quit [Ping timeout: 260 seconds]
[01:10:34] <SWPadnos> incidentally, does the code snippet you posted work? I don't think it should
[01:10:45] <andypugh> Works for me...
[01:11:02] <SWPadnos> oh, right. it works but is non-optimal
[01:11:25] <SWPadnos> the second strchr should use c as its input string, since everything leading up to that point has already been scanned
[01:11:28] <andypugh> I wasn't sure about it, and I asked for "elegantisation".
[01:12:06] <SWPadnos> but it does work, since you replace the character being looked for with something else, so the next call scans past c anyway
[01:14:02] <SWPadnos> on another note, do you know anyone with an apartment for rent that's somewhere near the O2 dome (or easily accessible to there by tube)?
[01:14:24] <andypugh> My proposal is not actually to make HAL not care about _ and -, it is that if we want to change to consistent pin naming convention then adding agnosticism to HAL will avoid breaking existing configs (and I remain unconvinced that it will lead to any actual problems if limited to pin names)
[01:15:21] <andypugh> I can ask about the aprtment. How long for?
[01:15:52] <SWPadnos> you may be right. I just have the feeling that someone who can't find their typo (when it's pointed out by a halcmd error message), will make other errors anyway, but in places where it's not as easy to spot (like o or O instead of a zero ...)
[01:15:53] <andypugh> I am far more likely to be able to find a spare room than an apartment.
[01:16:00] <SWPadnos> well, maybe 3 months or so
[01:16:25] <SWPadnos> a couple of those would work too, but I'm not much of a couch surfer (too old for that :) )
[01:16:49] <andypugh> How many people?
[01:17:02] <SWPadnos> 2, 3, or 4 - don't know yet
[01:17:04] <SWPadnos> no couples
[01:17:08] -!- PCW has quit [Quit: ChatZilla 0.9.87 [Firefox 3.6.13/20101203075014]]
[01:17:13] <SWPadnos> ... that I know of
[01:18:01] <andypugh> And this change isn't about typos. It is about allowing us to change pin names to the canonical spec without machines breaking all over the world..
[01:18:12] <SWPadnos> ok
[01:18:25] <SWPadnos> it will be about typos some time in the future, I'm guessing
[01:18:51] <andypugh> Fixing my typos is just a happy side effect :-)
[01:18:55] <SWPadnos> wasn't the original question about using _ because that's what the label on the board says?
[01:18:58] <SWPadnos> heh
[01:19:19] <SWPadnos> so it's more about syncing the HAL name with the name on the silkscreen
[01:20:34] <Jymmm> Nothing a sharpie cant fix
[01:21:12] <andypugh> No, what brought it up was ChrisM pointing out that my pin names were odd, then somebody (you?) finding the canonical spec, and then when I changed all the pin names in 7i64, Chris noticing that they now didn't match the hostmot2 gpio pins
[01:21:22] <SWPadnos> not me, not me!
[01:22:04] <Jymmm> Bogie Man ?
[01:22:19] <andypugh> So, now 7i64 pins have in-not, but FPGA board pins have in_not.
[01:22:23] <SWPadnos> the canonical spec would be much more useful if we had things like macros in halcmd
[01:23:01] <Jymmm> I use underscores as replacement for space
[01:23:02] <SWPadnos> so you could do something like setup_gpio(comp.pin.base-name, out, 1)
[01:23:14] <andypugh> If we change the FPGA board pins to match the canonical spec, there will be wailing and gnashing of teeth throughout the world.
[01:23:18] <Jymmm> SWPadnos: dot notation?
[01:23:28] <SWPadnos> and the macro would know that the xxx-dir sets the direction, and xxx.in-not is the inverted input ...
[01:24:04] <SWPadnos> Jymmm, we have that, but it's kind of reserved for denoting hierarchy
[01:24:34] <Jymmm> SWPadnos: so its a matter of dash vs underscore? I'd go underscore
[01:24:37] <SWPadnos> so things like card.0 and card.1 can be put into a nice tree display
[01:24:47] <Jymmm> SWPadnos: Yeah, that's fine.
[01:25:02] <SWPadnos> hyphens are nice in HAL names, but they can't be used in the variable names of course
[01:25:08] <SWPadnos> since that would imply subtraction
[01:25:20] <Jymmm> dashes are bad
[01:25:26] <Jymmm> underscoes are good
[01:26:00] <SWPadnos> parport.0.pin.7.in-not makes as much sense to me as parport.0.pin.7.in_not
[01:26:11] <andypugh> Given a free choice, I would go underscore too, but a document exists that states that all underscores in HAL pin names will be replaced by hyphens in the future (where "future" == EMC2 v 2.2)
[01:26:24] <SWPadnos> heh
[01:26:30] <SWPadnos> a bit delayed, huh?
[01:26:33] <Jymmm> andypugh: who said that, and why?
[01:27:01] <SWPadnos> I'm not so concerned about breaking configs, because I think it should be reasonably easy to make a script that can fix them (for us and anyone else)
[01:27:10] <SWPadnos> it's in the docs somewhere, I think
[01:27:15] <Jymmm> SWPadnos: souldn't have to imo
[01:27:19] <Jymmm> shouldn't
[01:27:35] <SWPadnos> don't have to, but it's nice
[01:27:51] <Jymmm> underscore is a standard nomenclature as replacement for whitespace, hyphen is not.
[01:28:09] <SWPadnos> ie, if we do convert all those underscores to dashes in our components, it would be nice if we made it easy for people to update their configs to accomodate that change
[01:28:45] <andypugh> http://linuxcnc.org/docs/html/hal_general_ref.html#cha:Canonical-Device-Interfaces (especially the footnotes)
[01:28:46] <SWPadnos> yeah. I don't remember the conversation very well, but we decided that it seemed like a good idea at that time (around 3 or 4 years ago)
[01:28:55] <Jymmm> I wouldn't fuck with functional symbols (* / - + % ^)
[01:28:58] <SWPadnos> not an important decision, obviously :)
[01:29:08] <SWPadnos> _ is a function too :)
[01:29:15] <Jymmm> name it?
[01:29:35] <SWPadnos> in internationalization, it's what converts an english message to the current language
[01:30:04] <Jymmm> SWPadnos: functional math symbols, hell with em not being able to translate engwish ;)
[01:30:07] <SWPadnos> printf("%s\n", _("This is a message"))
[01:30:11] <SWPadnos> heh
[01:30:28] <Jymmm> SWPadnos: Hey, no regex here
[01:30:34] <Jymmm> SWPadnos: no c/C++ either
[01:30:43] <SWPadnos> don't be a poopy-head
[01:31:14] <Jymmm> SWPadnos: Hey, this means soemthing --> ++++++---++-++<<<>><<>>
[01:31:23] <SWPadnos> brainf*ck
[01:31:29] <Jymmm> SWPadnos: so, dont give me no chit! =)
[01:31:37] <Jymmm> SWPadnos: yep, and c too
[01:32:11] <Jymmm> SWPadnos: For the record BF is actually easy to write and kinda fun too
[01:32:25] <SWPadnos> I'll have to listen to that record later
[01:33:25] <Jymmm> record?
[01:33:27] <andypugh> If it was my choice it would be all underscores in HAL (INI already is). It would give comp an easier time, and the corresponding variables in the code can't use hyphens
[01:33:35] <SWPadnos> for the record ...
[01:34:19] <Jymmm> heh
[01:35:11] <andypugh> But, if the spec says that I should use hyphens, and I am writing a component, should I follow the spec, should I be consistent with the higher level driver, or should I just use CamelCase as a quiet revenge?
[01:35:52] <SWPadnos> LPSTRHungarian_Notation
[01:35:57] <SWPadnos> or something like that ;)
[01:36:22] <Jymmm> andypugh: Who/what wrote the spec?
[01:36:45] <SWPadnos> a bunch of us discussed it at an EMC fest several years ago
[01:38:03] <Jymmm> SWPadnos: why was dash choosen?
[01:38:12] <SWPadnos> I don't remember
[01:38:34] <SWPadnos> maybe because you don't need to use the shift key to access it :)
[01:39:04] <Jymmm> While I understand the lazy aspect, but that's a poor reason imp
[01:39:10] <Jymmm> imo
[01:39:19] <SWPadnos> hyphens make sense in english, they're used for splitting or combining words. underscores are much rarer in the non-computer world
[01:39:52] <Jymmm> But we're talking the computer world, nobody is going to SPEAK these
[01:40:28] <Jymmm> and liek you said, a minus is gonna screw up things.
[01:41:00] -!- Valen has quit [Quit: Leaving.]
[01:41:01] <SWPadnos> users aren't always heavily into the computer world ...
[01:41:06] <Jymmm> Just like ! == NOT
[01:41:28] <SWPadnos> but again, I don't recall the reason we chose it. I'm just thinking of some off the top of my head
[01:41:32] <SWPadnos> where the hair used to be
[01:41:43] <Jymmm> in.!
[01:41:53] <Jymmm> in_!
[01:41:58] <Jymmm> both work
[01:43:11] <andypugh> EMC2 already strips spaces and case when looking for parameters and subs
[01:43:29] <andypugh> (in G-code, I mean)
[01:43:29] <SWPadnos> ?
[01:43:55] <SWPadnos> that's a very different animal, and one we weren't able to define
[01:44:24] <andypugh> True, but we accept it
[01:45:40] <SWPadnos> case and space insensitivity are a part of the RS274NGC language, we don't have much choice about accepting that if we want to be compatible
[01:46:00] <SWPadnos> adding things is different, so we can extend, but not fundamentally modify, the language
[01:46:04] <SWPadnos> we have control over HAL
[01:46:55] <SWPadnos> in any case, I don't think it's a huge issue. my personal take is that the change you propose would solve some short-term problems, but may end up creating other long-term problems
[01:47:21] <Jymmm> Delimiter-separated words
[01:47:21] <Jymmm> One approach is to delimit separate words with a nonalphanumeric character. The two characters commonly used for this purpose are the hyphen ('-') and the underscore ('_'), (e.g., the two-word name "two words" would be represented as "two-words" or "two_words"). The hyphen is used by nearly all programmers writing COBOL and Lisp; it is also common for selector names in Cascading Style Sheets. Most other languages (e.g., languages in the C
[01:47:21] <Jymmm> and Pascal families) reserve the hyphen for use as the subtraction infix operator, so it is not available for use in identifiers and underscores are therefore used instead.
[01:47:25] <andypugh> Anyway, so far I have found no fans for my idea. The objection seems to be a hypothetical ambiguity for which I can find no concrete examples. However I think that without it the cost/benefit analysis of rationalising pin names comes down on the "don't bother" side.
[01:47:48] <SWPadnos> as a matter of principle, I (personally) don't like the idea of the computer trying to figure out what the user intended. if there's ambiguity in the input, there should be an error or ambiguity in the output
[01:49:51] <SWPadnos> I agree, it's it's probably 50/50 or 60/40 as to whether to do it or not, so it's probably not worth the effort we have put into discussing it :)
[01:49:56] <andypugh> It isn't about guessing what the user intended, it is about allowing us to rationalise pin names in the declared intent way without frustrating the user base during the transition period.
[01:50:45] <SWPadnos> it's very easy (I think) to make a program that will take a text file as input, and which has a list of words that should be replaced with other words if they're found
[01:50:53] <SWPadnos> so the transition period isn't an issue IMO
[01:51:20] <andypugh> You propose editing peoples config files for them?
[01:51:27] <chester88> Why don't we do it temporarily in master till they are all changed over a period of months?
[01:51:49] <chester88> then any one using master won't be broken for months
[01:52:47] <SWPadnos> because anyone who creates a config in that time may make their own typos, and they will then be surprised when their configs suddenly stop working
[01:52:59] <SWPadnos> once it's in, I think it has to stay in
[01:53:35] <chester88> Well if we give notice ... and anyone using master should expect things to change from time to time.
[01:53:36] <SWPadnos> we can't (easily) automate the fixing of typos, but we can easily automate the replacement of known words with other known words
[01:54:04] <chester88> can we do the total change in a very short time ? 2 weeks say?
[01:54:12] <SWPadnos> we always give notice (and warn that configs may need to change between minor revisions such as 2.4 and 2.5), which we can also do when changing pin names ...
[01:54:22] <andypugh> But do we have the right to edit peoples configs for them?
[01:54:36] <SWPadnos> in the list of things you need to think about when upgrading your configs
[01:54:43] <chester88> we problem i see is only the time it takes to make the change.
[01:55:15] <SWPadnos> "if you have a Mesa 7i48, note that the GPIO pin names have changed from e.g. blahblah_doodad to blahblah-doodad"
[01:55:21] <chester88> in that time peoples configs could constantly have to be changed depending how many components they use.
[01:55:58] <andypugh> Or are you proposing only changing the sample configs? I don't think we can do that, a fair proportion of users have never looked at their HAL file, it was made by stepconf and that is their interface.
[01:56:13] <SWPadnos> that's the kind of feature that we don't want to change during a minor release cycle (ie, 2.5.0 to 2.5.1), since it could break configs
[01:56:48] <chester88> do we care if we annoy people using master?
[01:56:48] <SWPadnos> any config that was made by stepconf should be able to be loaded by stepconf and re-generated with the correct names
[01:57:04] <andypugh> In my opinion, it's not worth it.
[01:57:10] <SWPadnos> any custom or customized config should be relatively easy to update with sed
[01:57:28] <SWPadnos> chester88, it's not about master, it's about releases to the public
[01:57:55] <SWPadnos> I think that's what Andy was talking about, anyway - all those people who have configs that might break, and how to make it easier for them
[01:57:58] <chester88> yes but If you fix master then the next major release it is fixed
[01:58:26] <chester88> then only people using master in the mean time are annoyed
[01:59:45] <SWPadnos> sure, and that
[01:59:50] <SWPadnos> that's not an issue IMO :)
[01:59:53] <andypugh> An increase in elegance from the dev point of view is not worth any hassle imposed on the User in my opinion (OK, so I am an Apple user). Either we make it so that existing machines continue to work, or we give up on rational pin names. There is no benefit to the average user in rational pin names, after all, as they hardly see them.
[02:00:37] <chester88> it's annoying as hell
[02:01:10] <chester88> but i see your point (or better said the users)
[02:01:16] <andypugh> chester88: You are here on IRC, you are not an average user.
[02:01:40] <SWPadnos> the average user can't easily update from 2.4 to 2.5
[02:01:46] <SWPadnos> that's not automatic, you have to want it
[02:01:54] <chester88> well don't forget that users can forget which components use _ or -
[02:02:08] <SWPadnos> andypugh, do you know if there's a way to use the GUI in MacOS to set actimeo on an NFS share?
[02:02:10] <chester88> in mesa now we use both
[02:02:15] <SWPadnos> (speaking of Apple)
[02:02:44] <andypugh> I don't even know what actimeo is.
[02:03:18] <SWPadnos> heh
[02:03:22] <SWPadnos> so much for Apple ;)
[02:03:46] <SWPadnos> it's a timeout value, in seconds, after which it assumes that network data is stale and should be refreshed
[02:04:03] <SWPadnos> it defaults to ... something ..., and I haven't found a way to specify it from the GUI
[02:04:14] <SWPadnos> it works fine if I do a mount from a terminal
[02:05:00] <andypugh> I still don't see any concrete cases where making hal -_ agnostic will actually cause a problem. I accept thatn from the point of view of ingrained programmer caution it sounds like a bad idea, bit in the limited case of HAL pin names, and all future conceivable hal pin names, I think it is in practical terms zero-risk.
[02:06:02] <chester88> i think we should fix the naming for 2.6 and i like your idea on a temporary bases in master till it is done.
[02:06:08] <andypugh> There is quite a lot in OSX which actually isn't accessible from the GUI.
[02:06:28] <SWPadnos> and which apparently varies from version to version or machine to machine
[02:06:38] <chester88> how do i change my name on here?
[02:06:44] <andypugh> it will be in a plist somewhere
[02:06:45] <SWPadnos> in an non-discoverable and non-changeable way
[02:06:55] <SWPadnos> chester88, /nick MyNewName
[02:07:13] chester88 is now known as Cmorley
[02:07:22] <Cmorley> testing...
[02:07:28] <Cmorley> thanks
[02:07:30] <SWPadnos> you might want to register that one too, if it isn't already
[02:07:32] <SWPadnos> sure
[02:07:56] <SWPadnos> andypugh, it helps *some* users *some* times to make HAL ignore their errors
[02:08:06] <Cmorley> how do I do that :) I don't use IRC much
[02:08:30] <SWPadnos> it may make *other* users more confused
[02:09:34] <andypugh> How many times do I have to repeat that it isn't about users making errors in HAL files?
[02:09:59] <SWPadnos> the average joe, who doesn't look at HAL names at all, doesn't care, since they rely on tools that we provide, and which should be able to grnerate corrected configs from the same input that created their existing configs
[02:10:10] <andypugh> It is about allowing us to change the pin names without breaking machines.
[02:10:45] <SWPadnos> there is aliasing ...
[02:10:58] <SWPadnos> (not a good suggestion, I know :) )
[02:11:15] <andypugh> Arguably, HAL itself is a configuration tool, and that is what this change does. It allows either format to work
[02:12:02] <andypugh> If someone has been given a HAL file by Sherline (as an example) then they don't have a configuration tool to re-run.
[02:12:08] <Cmorley> your thinking to ignore the name difference untill we have them all fixed then remove it so HAL cares again? is that right Andy?
[02:12:19] <andypugh> Largely.
[02:12:39] <SWPadnos> well no, because the premise is that we are trying to not break *existing* user configurations
[02:12:51] <andypugh> To be honest I don't see why you would remove it, but in principle you could
[02:13:09] <SWPadnos> which is impossible, unless you leave the ability to accept either name format in HAL forever. it doesn't eliminate the problem, it only delays it
[02:13:57] <SWPadnos> I'm also being selfish, because when I do support, it will make it harder for me to find certain classes of error
[02:14:07] <andypugh> We only need to delay it until the Singularity (or the Zombie Apocolaypse) so that might be enough.
[02:14:29] <SWPadnos> ie, someone has a spindle speed problem, and they post their HAL files. I look for spindle-at-speed, but they spelled it spindle-at_speed in their file
[02:14:41] <Cmorley> it also makes it so we only break configs once and in a short time . otherwise we break them for the time it takes us to chaange them all which could be a while.
[02:14:53] <SWPadnos> that isn't the problem, but it makes it harder to find something else that might be
[02:15:12] <SWPadnos> or I have to use regex to find the pins I'm looking for (spindle[-_]at[-_]speed)
[02:15:48] <andypugh> SWPadnos: But you, as in informed EMC dude, will know that they are equivalent, in the same way as you know that some parts of URLs are (and some aren't)
[02:16:10] <SWPadnos> sure, but it still makes it harder to help people out
[02:16:36] <SWPadnos> Cmorley, the obvious choice is to change some pin names and the configs that use them in the same git push
[02:17:01] <SWPadnos> if we change some mesa names, then change the mesa configs at the same time, so there's never a version in git that won't work
[02:17:09] <Cmorley> but is that going to happen ? isn't there a lot of them and kinda hard to find.
[02:17:25] <SWPadnos> if we change spindle-out, then all sample configs need that change, but it's a sed, not a lot of manual editing
[02:17:28] <Cmorley> other then existing users
[02:18:28] <SWPadnos> find . -name "*.hal" | xargs grep -l "the-pin-I-changed" | xargs sed 's/the-pin-I-changed/the-new-name/g'
[02:18:32] <andypugh> Consider the idea abandoned then. But I also resist any changes to pin names in the drivers, because there is no benefit to the users, and potential cost. (in many cases significant financial cost if we break a production machine)
[02:19:34] <SWPadnos> do that (or something like it that's spelled right and double-checked) in the configs dir, and it should change all instances of "the-pin-I-changed" to "the-new-name"
[02:19:50] <SWPadnos> in hal files only, not inis or whatever
[02:20:09] <andypugh> Maybe that is why we have such different perspectives? I think we should avoid costing anyone actual cash at any cost, so all working machines have to continue working.
[02:20:46] <SWPadnos> that's not always possible, and the time to break them is when the user has to explicitly do something to upgrade their software
[02:21:08] <SWPadnos> I agree with you fully that any automatic (or automatically detected) update (not upgrade) shouldn't break anything
[02:21:37] <SWPadnos> but if there might be any change needed, which has happened for every 2.x release, they should all happen at once
[02:21:40] <Cmorley> I assume people use master on production machines too. right or wrong.
[02:21:48] <andypugh> But in this case, there is no argument for breaking them in either case.
[02:21:49] <SWPadnos> so the user can make the change, fix their configs, and move on
[02:22:04] <SWPadnos> are there no other config changes?
[02:22:16] <SWPadnos> (I've been out of touch, I don't actually know the answer to that question)
[02:22:24] <SWPadnos> they probably do
[02:22:54] <SWPadnos> a number of sed lines like the one above could be put into a script, which would be able to fix anyone's configs
[02:23:09] <andypugh> I spend a lot of time on the forums. Many folk don't even know they have config files. And I actually think that they shouldn't need to (Mac perspective again).
[02:23:19] <SWPadnos> no no no.
[02:23:34] <SWPadnos> machines can kill or maim people, we can't hide everything
[02:23:53] <andypugh> But if they go to the website, find a new liveCD and install it, then they could reasonably expect the old config to work.
[02:24:08] <SWPadnos> no, they can't
[02:24:12] <SWPadnos> we make that clear
[02:24:24] <SWPadnos> we should make that clearer if it's not clear
[02:24:30] <andypugh> And yoiu would have to be very patient to be killed by a Sherline.
[02:25:07] <SWPadnos> it's got fangs
[02:26:07] <SWPadnos> look at the wiki pages on "UpdatingTo2.1" (and 2.2, 2.3, 2.4)
[02:26:28] <SWPadnos> they describe the differences between old and new config files, and what has to be done to upgrade to the new version
[02:27:02] <Cmorley> hey we should make one for 2.5 soon ...
[02:27:10] <SWPadnos> it would be pretty hard to make some of those changes transparent to the users
[02:27:14] <andypugh> Anyway, I don't think we should change pin names if we can't make it transparent for all users, because it only really makes things easier for developers, and that's not where the balance should be.
[02:27:52] <SWPadnos> we don't want to automatically load components and make connections, which is what would be needed to keep all changes hidden from the user
[02:28:00] <SWPadnos> that's fine
[02:28:20] <SWPadnos> were the pin changes in question from the board names to the "canonical HAL" names?
[02:28:32] <SWPadnos> board names = names silkscreened on the board
[02:28:39] <andypugh> No, neither.
[02:29:05] <andypugh> I had made up names that I thought made sense
[02:29:10] <SWPadnos> ah
[02:29:25] <Cmorley> hostmot2 uses some names with _ some with -
[02:29:45] <andypugh> It was pointed out to me that they didnt match canonical spec. So I changed them.
[02:29:52] <SWPadnos> ok
[02:31:20] <andypugh> So, now, the 7i64 pins match canonical spec. But they are the only Hostmot2 pins which do, so they are inconsistent with the rest of hostmot2. I can change them again to be consistently wrong, I suppose...
[02:32:25] <Cmorley> using the phrase 'GPIO' on 7i64 is miss leading (MHO). I like your naming now better.
[02:32:42] <andypugh> Sorry, but I am a pedant. If you show me a spec, I am going to stick to it, and to hell with the consequences.
[02:33:08] <SWPadnos> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UPDATING
[02:33:14] <Cmorley> it was just the different delimiters that was annoying.
[02:33:19] <SWPadnos> there are a few changes there that are cosmetic only
[02:33:48] <SWPadnos> such as motion.motion-inpos being changed to motion.in-position
[02:33:54] <Cmorley> but as you said maybe better to leave it now
[02:34:04] <SWPadnos> and some hostmot2 changes too
[02:35:28] <andypugh> So, now I am sat here smugly happy that _my_ pins have the right names, and it is somebody else's problem to figure out the inconsistency. (Well, not quite, I found and coded a solution, but it has been pretty much universally reviled apart from by Chris, who has the problem of handling the complexity in pncconf)
[02:35:32] <Cmorley> In my mind i have no problem making a incompatible change on major releases (that's the only way to get new features) It just breaking configs in a long drawn out way (the making changes in master as we find the pins)
[02:35:56] <SWPadnos> making -_ ambiguous is a pretty small issue. I think in a greater sense, there will be times when we have to break configs, and there is no reasonable way of handling an arbitrary number of configuration "versions", which is what you end up with later, if you refuse to let anyone's configs break
[02:36:45] <SWPadnos> imagine if we had taken what you call the "Apple approach" for all those changes in the UPDATING document
[02:37:57] <andypugh> I actually think that some should have been. The NML file issue was something that could have been trapped and fixed.
[02:38:02] <SWPadnos> we would now have to somehow figure out (programmatically) what version the user was writing to (possible by adding a mandatory and non-changeable ID of some sort to the file), and then making some decisions about what that might mean in the context of a new system, where their config is now invalid
[02:38:24] <SWPadnos> there are ways to automate the changes to users configs, which is what I'm advocating
[02:40:13] <SWPadnos> which NML file issue?
[02:40:26] <SWPadnos> there are two changes on that wiki page
[02:40:27] <andypugh> My enthusiasm for this whole issue is tending towards zero
[02:40:32] <SWPadnos> heh
[02:40:40] <Cmorley> well i'm off - good discussion night
[02:40:51] <SWPadnos> sorry to be a downer. your efforts are appreciated by me at least
[02:40:58] <SWPadnos> night
[02:43:18] -!- adb has quit [Ping timeout: 260 seconds]
[02:43:43] <andypugh> 1.1 emc.nml. Some users (I saw about half a dozen on the forum) found that their machine failed to boot until they removed an nml file reference from the ini file. (one that they personally might not have inserted). How many had the same problem and didn't find the forum/mailing list/wiki? We can never know.
[02:44:36] <SWPadnos> should be very few, but let's examine that case, if you have a minute
[02:45:11] <andypugh> Well, it is 0344 here, but I can hang around a bit.
[02:45:37] <SWPadnos> should be few because the user always has to explicitly change their apt sources to be able to upgrade, and anyone who gets the new version for the first time has no configs to update
[02:46:06] <SWPadnos> so the machine can't suddenly break unexpectedly, it has to be done by the user :)
[02:46:26] <SWPadnos> so, the NML file thing. "make it work automatically"
[02:46:58] <SWPadnos> how would one do that? The ini file has a reference to an NML file, so emc has to decide whether it's real or default
[02:47:16] <SWPadnos> the name isn't useful for determining that, since everybody uses "emc.nml"
[02:47:51] <SWPadnos> the file contents could be examined, by maybe having an old version in the package and doing a diff somehow - if the files match, it's a default file and the new defaults can be used instead
[02:48:06] <SWPadnos> (new default file, that is)
[02:48:31] <SWPadnos> but what if someone did something like add a note at the top "#DO NOT CHANGE THIS FILE EVER!!!"
[02:48:46] <SWPadnos> diff comes up false, and it looks like a custom NML file
[02:48:56] <andypugh> For the upgrade effort, true, but I know other software where you have to try/pay to upgrade and it carries on working. Microsoft charge you hundreds of pounds for a new version of office, which you then install, but you keep your spreadheets.
[02:49:19] <SWPadnos> that's the equivalent of keeping your G-code
[02:50:03] <SWPadnos> this is more like copying your old XP registry and expecting Win7 to keep on working the same
[02:50:32] <SWPadnos> what they do is provide tools to automatically make the changes they think need to be made to your configuration
[02:50:39] <andypugh> Well, yes and I have a horrible worry about my Excel macro at work now that they are offering office 2010. This is an Excel macro with a 200 page manual...
[02:50:39] <SWPadnos> which sometimes work and sometimes don't
[02:51:06] <SWPadnos> I can't stand Word or Excel 2010, thanks for reminding me ;)
[02:51:47] <SWPadnos> like the fact that F3 no longer goes to the next found search term ...
[02:52:08] <SWPadnos> and there was something that's no longer possible with the keyboard - you have to use the mouse
[02:52:22] <SWPadnos> can't remember that one, probably blocked due to excessive emotional trauma
[02:52:41] <SWPadnos> anyway, we're talking about things like the registry, not a bunch of documents
[02:53:35] <andypugh> But, I disagree about the scope of the change. To us an EMC2 upgrade might be equivalent to an OS upgrade (and on a dedicated machine is probably is) but users probably see it as a simple software update
[02:53:41] <SWPadnos> and when you install Word 2010, your configuration of Word itself is unlikely to survive either - color preferences, styles maybe, custom key commands maybe not ...
[02:54:32] <SWPadnos> it's kind of a cross between OS level stuff and application level stuff
[02:54:52] <andypugh> Yes, but, when you click the Word icon, you still get Word. Not a "crash"
[02:54:53] <SWPadnos> but in either case, I expect to be able to use the files I created (or used) before, but I don't expect all my settings to carry over
[02:54:55] <SWPadnos> and HAL is settings
[02:55:13] <SWPadnos> probably, but not the same Word - ie, not configured the same
[02:55:55] <SWPadnos> with Word, if I have to go through preferences and change key commands or how (and whether) it hilights grammatical errors, that's just an annoyance
[02:56:05] <andypugh> (and that is how they report it, not "what does this message mean" , it is always "Emc2 crashes on startup (Waaah)"
[02:56:15] <SWPadnos> with EMC, if there's something about how the machine works that changes, it could be dangerous
[02:56:20] <SWPadnos> yeah, I know
[02:57:56] <andypugh> To rewind for context, making - and _ equivalent is _really_ unlikely to kill anyone.
[02:58:04] <SWPadnos> heh
[03:01:14] <SWPadnos> I guess my reaction is that it's the kind of thing that one does to insure that users can be as ignorant of their tools as possible, and that's not something that makes me happy. Additionally, it's a slippery slope. The next change could be to something more important, but we would have precedent for making EMC capable of using configs from any version for some later version.
[03:01:16] <andypugh> But I can accept that this is a debate I have lost, I didn't spend long on the code. I still favour the idea, but accept that, in reality, nothing is going to change now on pin names.
[03:01:32] <SWPadnos> that's an impossible goal, because there are some changes that just can't be automated.
[03:04:18] <SWPadnos> anyway - good night. sorry this hasn't turned out to be easy for you (so far)
[03:05:05] <andypugh> It's a pity that my pins don't match Seb's pins, but mine match the spec, it's up to others to change the others and handle the consequences their way.
[03:05:20] <SWPadnos> yes, that's true
[03:05:31] <SWPadnos> both points
[03:06:25] <andypugh> I would have done it my way, but I refuse to break existing configs unless there is a user benefit.
[03:07:00] <andypugh> I have plenty of other things to be doing. Heck, I could even do stuff in the workshop!
[03:07:03] -!- jimlay_ has quit [*.net *.split]
[03:07:03] -!- ve7it has quit [*.net *.split]
[03:07:04] -!- nots has quit [*.net *.split]
[03:07:04] -!- Tom_itx has quit [*.net *.split]
[03:07:04] -!- DaViruz has quit [*.net *.split]
[03:07:16] <SWPadnos> you could sleep!
[03:07:56] <andypugh> That's one thing I am truly hopeless at. I just lie in bed and get bored, mainly
[03:08:18] <Jymmm> andypugh: sex?
[03:08:27] <Jymmm> andypugh: casino?
[03:08:33] <SWPadnos> heh. well, I'll go get bored in bed myself then. night
[03:08:43] <andypugh> Night all.
[03:08:47] <Jymmm> SWPadnos: Wifey gone huh?
[03:08:56] -!- andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust1037.basl.cable.virginmedia.com] has parted #emc-devel
[03:08:58] <SWPadnos> no, she's here but already asleep (so boring)
[03:09:16] <Jymmm> SWPadnos: Well, bring her a rose or sumtin
[03:09:26] <SWPadnos> no sense, she's asleep :)
[03:09:27] <Jymmm> SWPadnos: Jello pudding?
[03:09:37] <Jymmm> bucket of ice?
[03:09:45] <SWPadnos> hmmmmmm
[03:09:49] <SWPadnos> let me think about that one
[03:09:55] <Jymmm> ti's only midnight and a friday
[03:10:08] <Jymmm> err 2300
[03:10:42] <Jymmm> SWPadnos: Well, g'night then =)
[03:10:51] <SWPadnos> aye
[03:19:47] -!- ve7it [ve7it!~LawrenceG@S0106001c10b7770f.pk.shawcable.net] has joined #emc-devel
[03:44:57] -!- mozmck has quit [Quit: Leaving.]
[04:13:14] -!- Tom_itx has quit []
[04:14:01] -!- isssy has quit [Quit: Visitor from www.linuxcnc.org]
[05:08:16] -!- factor has quit [Read error: Connection reset by peer]
[05:17:32] -!- FinboySlick has quit [Quit: Leaving.]
[06:13:18] -!- pcw_home has quit [Ping timeout: 256 seconds]
[06:24:00] -!- ve7it has quit [Remote host closed the connection]
[06:59:51] -!- MarkusBec has quit [Ping timeout: 252 seconds]
[07:00:15] -!- lilalinux has quit [Ping timeout: 260 seconds]
[07:27:18] -!- capricorn_one has quit [Remote host closed the connection]
[07:46:35] -!- theos has quit [Read error: Connection reset by peer]
[07:50:50] -!- lilalinux has quit [Excess Flood]
[09:46:56] -!- factor has quit [Ping timeout: 256 seconds]
[09:58:40] -!- Calyp has quit [Ping timeout: 255 seconds]
[10:39:43] -!- Poincare has quit [Quit: changing servers]
[10:41:53] -!- jthornton [jthornton!~chatzilla@216-41-156-49.semo.net] has joined #emc-devel
[11:44:05] <CIA-83> EMC: 03jthornton 07v2.4_branch * r5b6bf7bfeaf3 10/src/hal/components/thc.comp: try and clear up the description and license.
[11:47:48] -!- MOGLI has quit [Quit: Visitor from www.linuxcnc.org]
[13:03:18] -!- mozmck [mozmck!~moses@client-173.225.233.241.dfwtx.partnershipbroadband.com] has joined #emc-devel
[13:22:09] -!- Valen has quit [Client Quit]
[13:24:57] -!- micges [micges!~x@addc47.neoplus.adsl.tpnet.pl] has joined #emc-devel
[14:42:37] -!- pjm has quit [Read error: Connection reset by peer]
[14:59:46] -!- Calyp has quit [Ping timeout: 245 seconds]
[15:49:46] -!- automata has quit [Ping timeout: 245 seconds]
[15:51:00] -!- micges has quit [Quit: Ex-Chat]
[15:57:42] -!- isssy has quit [Quit: Visitor from www.linuxcnc.org]
[16:46:37] -!- micges [micges!~x@addc47.neoplus.adsl.tpnet.pl] has joined #emc-devel
[16:55:50] -!- micges has quit [Quit: Ex-Chat]
[17:06:36] -!- kljsdfhklj has quit [Quit: kljsdfhklj]
[17:24:10] -!- Calyp has quit [Ping timeout: 255 seconds]
[17:32:53] -!- isssy has quit [Ping timeout: 260 seconds]
[17:34:19] -!- factor has quit [Read error: Connection reset by peer]
[18:29:51] -!- elmo40 has quit [Ping timeout: 258 seconds]
[18:33:06] -!- elmo401 has quit [Ping timeout: 245 seconds]
[18:36:28] -!- Fox_Muldr has quit [Ping timeout: 260 seconds]
[18:46:39] -!- odiug has quit [Ping timeout: 248 seconds]
[19:23:08] -!- rooks has quit [Quit: So long, and thanks for all the fish.]
[19:24:10] -!- isssy has quit [Quit: Visitor from www.linuxcnc.org]
[19:56:17] -!- andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust1037.basl.cable.virginmedia.com] has joined #emc-devel
[20:12:42] -!- micges [micges!~x@addc47.neoplus.adsl.tpnet.pl] has joined #emc-devel
[20:46:33] -!- automata_ has quit [Ping timeout: 260 seconds]
[21:08:26] -!- nullie has quit [Ping timeout: 276 seconds]
[21:11:59] -!- ve7it [ve7it!~LawrenceG@S0106001c10b7770f.pk.shawcable.net] has joined #emc-devel
[21:33:24] -!- micges has quit [Quit: Ex-Chat]
[21:53:34] -!- servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[22:01:11] -!- maximilian_h [maximilian_h!~bonsai@f052209155.adsl.alicedsl.de] has joined #emc-devel
[22:01:14] -!- maximilian_h has quit [Client Quit]
[22:34:11] -!- odiug has quit [Ping timeout: 256 seconds]
[22:41:13] -!- Calyp has quit [Quit: Leaving]
[23:21:33] -!- nullie has quit [Quit: Ex-Chat]