[mythtv-users] ticket 10504 and php-5.4.8-1.fc17.x86_64

[Michael T. Dean]

On 12/12/2012 11:40 AM, Udo van den Heuvel wrote:
> On 2012-12-12 17:26, Michael T. Dean wrote:
>>>> The logic is fine.
>>> I doubt that.
>>> Silently interpreting a default string as empty if not logical in any
>>> way.
>>> A default name could be interpreted as an unconfigured system, so yell
>>> about that instead.
>> That "default" LocalHostName ("my-unique-identifier-goes-here") is /not/
>> a default.
> [root at recorder mythtv]# rpm -qf  /etc/mythtv/config.xml
> mythtv-common-0.26.0-0.1.git.1.fc17.x86_64
> [root at recorder mythtv]# grep LocalHostName /etc/mythtv/config.xml
>    <LocalHostName>my-unique-identifier-goes-here</LocalHostName>
>
> QED.
> (and no, I use the config.xml in mythtv's home directory)

Isn't your "proof" supposed to be definitive before you say, "Q.E.D."?

I said, "That 'default' LocalHostName ('my-unique-identifier-goes-here') 
is /not/ a default."

I then said more (which you've decided to ignore before you said you've 
proven me wrong), and what more I said explains that it's not a default 
because it's a sentinel value.  So I'm guessing you're missing out on 
the meaning of one or more words:  definitive, default, and/or sentinel.

>>   It is a sentinel value that specifically means, "no
>> specified value".  It is the one and only disallowed value for the
>> LocalHostName profile identifier.
> You can argue all you want.
> Discarding it and treating it as it is now does not help in any way.

We do not discard it--that would imply that it /could/ be used.  We use 
that as a flag to say, "The user did not provide a host name (profile 
identifier) override, so we will fall back to using the *default* value, 
which is the system's host name".

The profile identifier is used as a key to find the profile (settings 
and configuration) for a specific system.  It's just a name we use to 
look up the configuration.  If it's wrong, you get the wrong configuration.

> Please dedicate a specific message to the case of finding this string as
> it is a default.

If it's a default, it would be /used/.  It's not used.  It's a sentinal 
that tells us to use the *default* value, which is the system's host name.

Note, also, that there's *no* reason for a user to set this value.  It 
only needs to be set if, for some reason, the user does not want to use 
the system's host name for the profile identifier.  If it's not set (or 
if it has the sentinel value), we use the system's host name for the 
profile identifier (and the user will likely recognize that host name 
and associate it with the proper system, so it seems a reasonable thing 
to do).

> The logic is fatally flawed and this is just an example.
> Or do you need an updated graph of growing VSZ&  RSS values for a
> certain backend process?
>
> My box is running once again.
> So I do not need the fix right away.
> But think about how many others you might help with just a small change
> in the code.

What should the message say?

"You did not provide a local host name override, so we are going to use 
the *default* value, which is the system's host name."

"Since you did not override the local host name with a different profile 
identifier, we are going to use the *default* value, which is the 
system's host name."

"You did not configure a value--which shouldn't be configured on any 
system, unless there's some reason you want to specifically override the 
profile identifier or you just prefer to control things that don't need 
controlling--so we are going to use the *default* value, which is the 
system's host name."

"No LocalHostName override specified, so we'll use the *default* value, 
which is the system's host name."

Or, just say, "Empty LocalHostName." at the *notice* level (not an 
error, nor even a warning, therefore, just information) and then carry 
on and use the *default* value, which is the system's host name.

Seems reasonable to me.  Especially since /just/ after that we say what 
host name we're using:

>> 2012-12-06 15:59:48.122585 I  Using localhost value of recorder.hierzo 

I really don't even know what you're complaining about.  As far as I can 
see, what happened was:

a) Your system didn't work after upgrade because of a problem in your 
config.xml that prevented it from picking up the proper settings.
b) You posted about the problem and were told your config.xml is broken, 
so your programs don't know which settings to use/which host is which ( 
http://www.gossamer-threads.com/lists/mythtv/users/534434#534434 )
c) You posted about a problem and were told your config.xml is broken 
(starting somewhere around 
http://www.gossamer-threads.com/lists/mythtv/users/534735#534735 --and, 
yes, in the 
off-list-because-your-mail-client-sent-a-message-directly-to-me-instead-of-through-the-list-so-I-didn't-know-I-was-replying-off-list 
messages, I told you that the problem is the same one--that you have a 
broken environment/config.xml problem so it doesn't know which settings 
to use/which host is which)
d) Because of your belligerent attitude, some may have held off 
providing simple instructions/descriptions of the problem because they 
didn't want to deal with the abuse (for, example, by providing small 
comments that, with a little thought and possible effort searching the 
archives on your part, would have led you to find the simple 
instructions/descriptions of the problem).
e) You feel you must find someone else to blame for the problems you had 
when you upgraded (because, obviously, you couldn't have ever done 
anything wrong at any point), so you've latched on to saying the 
message, "Empty LocalHostName.", is causing problems for some reason.  
In fact, the root of the problem is that your system changed--to the 
point of changing the value returned by the hostname program (i.e. you 
have a different host name or something) or you previously specified a 
LocalHostName override, but weren't specifying it in the updated 
config.xml).
f) You upset me to the point I'm being mean to you on the list.

Mike


(I've heard repetition is the key to learning...  Seems a good time to 
test this theory.  So, one more time, if the user does not override the 
LocalHostName (profile identifier), we use the *default* value, which is 
the system's host name.)