Prev: Data folder
Next: convert selected to uppercase
From: John H Meyers on 11 Nov 2009 04:38
On Wed, 11 Nov 2009 01:55:04 -0600, Jim Higgins wrote:

> It is only with SIGNED integers that subtracting 1 from zero gives a
> negative number. With unsigned integers subtracting 1 from zero
> results in the largest possible 32-bit value.

Subtracting 1 from zero gives the _identical_ value in either case
(a 32-bit word where every bit is "1")

What I concluded last time was that, in the end,
trying to guess how the "junk scorer" _interprets_ the result
is moot -- we know that this point is where things go wrong,
and we know that if we want to correct the observed "going wrong,"
we need to change a recognizably "wrong counter" to a value
where many of the leading bits are again "0"

> you could try seeing what happens when a piece of junk
> is DRAGGED out of Junk to another mailbox.

I just tried this, and nothing happened -- neither "dragging out from"
nor "dragging into" the Junk mailbox changed any counters,
which does not support telling someone
that this is the cause of his problem,
or will prevent its recurrence in the future.

> blindly spewing URLs to old messages relating to
> pre-6.2.0 versions, when the OP is using the latest 7.1.0.9,
> is not the best thing to do.

We don't even know whether it can ever happen,
if no other version is ever used.

Those messages are also the only ones I can find
which identify that the "total counts line"
is where things go wrong, how to recognize it, and how to fix it,
so they are the only references I can credit,
to give credit where due, to those who have already
found the problem in the past, as well as who may have
recovered from it by doing what they had said.

JHM:
>> Perhaps one might profit by now and then
>> replacing that file with one's own "UserJunkDB.txt" file,
>> while it is still working well :)

> I couldn't even guess.

I will take full credit for guessing,
that if the complete logic of calculating a "junk score"
in any way blends the two files (the "StaticJunkDB.txt"
which comes installed with the programs, plus the
"UserJunkDB.txt" which changes upon user's "Junk/Not_Junk" actions),
then I think it may improve reliance on one's own training,
plus assist recovery of any corruption to one's own "UserJunkDB.txt"
to have a previous version of it saved as "StaticJunkDB.txt,"
thus "promoting the good health of two birds with one feeder" :)

> [I got] incredibly few errors of either type after the first week.
> My numbers are low, which one would think runs greater risk
> of the first one going below zero and that hasn't happened.

Does this point to possible prior use of an older Eudora version
by the OP as a suspect? "Only the OP knows for sure" :)

> Bottom line to my part of this discussion (to including earlier
> messages on the junk mail problem) being that I think very little of
> this esoteric business about integers or signed integers was helpful
> to the OP.

Then why keep harping upon it?

If we agree that when something subtracts 1 from 0,
then it goes into "bad territory, counter-wise,"
or even if we attribute the bad value to a haunting
by an evil spirit, then it's still necessary to both
recognize the symptom of a "bad counter"
and know what sort of value a "good counter" should have,
if we are to put it back into "good" state again,
although unnecessary if we prefer
to instead just junk the training file itself.

> He needs to edit his file to stop the problem

Good, so he has to know what sort of edit makes it "good" again.

> and he needs to handle the manual junking
> and manual unjunking of messages properly to avoid recurrence.

This we do not know. We have no evidence that version 7.1.0.9
(or even 6.2.3.4) subtracts from any counter at any time,
based on the very few experiments I have just done,
but we do have the past testimony
of some whom I would call expert,
saying that some past version certainly did that,
in response to _normal_ junking!

There are also other possibilities as to how it might go wrong,
internally -- for example, if a 16-bit counter,
while being _interpreted_ as signed, exceeds 32,767
and is then copied to a 32-bit counter, again being
interpreted as signed, but then is written as a decimal value
to the file, by a function which interprets it as unsigned!

We don't know what goes on, but one thing I just saw,
from an experiment, is that dragging messages to or from Junk
seemed to be of no influence at all.

> Whether additional steps are needed to prevent
> recurrence is unproven at this time.

Then why give the unproven advice above,
particularly when applying the _normal_ advice too often (that is,
applying normal "Junk/Not_Junk" actions to too many messages)
was declared by those who have researched this before
as the actual precipitator of the problem!

If I can keep my eyes from glazing over,
I'll ask Katrina whether she has any more direct knowledge about this,
and with what versions, etc. (she may also have had contact with developers,
one might suspect, from some knowledge of internals which would otherwise
seem hard to obtain).

Thank you, and good night.

--
From: st.luck on 11 Nov 2009 07:29
> !MessageCount = 500, 11638

Two days ago I have modified UserJunkDB.txt file and I have written
"!MessageCount = 500, 11638". I now can tell you I have solved my
problem. Eudora now works very very fine.
Thanks for your suggestions.
From: Jim Higgins on 11 Nov 2009 09:53
On Wed, 11 Nov 2009 03:38:53 -0600, "John H Meyers"
<jhmeyers(a)nomail.invalid> wrote:

>On Wed, 11 Nov 2009 01:55:04 -0600, Jim Higgins wrote:
>
>> It is only with SIGNED integers that subtracting 1 from zero gives a
>> negative number. With unsigned integers subtracting 1 from zero
>> results in the largest possible 32-bit value.
>
>Subtracting 1 from zero gives the _identical_ value in either case
>(a 32-bit word where every bit is "1")
>
>What I concluded last time was that, in the end,
>trying to guess how the "junk scorer" _interprets_ the result
>is moot -- we know that this point is where things go wrong,
>and we know that if we want to correct the observed "going wrong,"
>we need to change a recognizably "wrong counter" to a value
>where many of the leading bits are again "0"
>
>> you could try seeing what happens when a piece of junk
>> is DRAGGED out of Junk to another mailbox.
>
>I just tried this, and nothing happened -- neither "dragging out from"
>nor "dragging into" the Junk mailbox changed any counters,
>which does not support telling someone
>that this is the cause of his problem,
>or will prevent its recurrence in the future.


On the contrary... observation that the first value getting smaller
until it passes thru zero and becoming negative is the cause of the
problem, one should properly unjunk messages so as to increment this
counter as (I assume) was intended when mail is unjunked. If you
don't, then whatever condition decrements that value is more able to
cause the problem. Obviously I'm rejecting the notion that so much
mail is unjunked or other action occurs that increments the first
value, that it increases over 2Gigs to become negative (signed 32-bit
integer assumed).


>> blindly spewing URLs to old messages relating to
>> pre-6.2.0 versions, when the OP is using the latest 7.1.0.9,
>> is not the best thing to do.
>
>We don't even know whether it can ever happen,
>if no other version is ever used.
>
>Those messages are also the only ones I can find
>which identify that the "total counts line"
>is where things go wrong, how to recognize it, and how to fix it,
>so they are the only references I can credit,
>to give credit where due, to those who have already
>found the problem in the past, as well as who may have
>recovered from it by doing what they had said.


Read those messages from top to bottom. As I recall 2 out of 3 just
rattle on and on without providing a clear solution.


>JHM:
>>> Perhaps one might profit by now and then
>>> replacing that file with one's own "UserJunkDB.txt" file,
>>> while it is still working well :)
>
>> I couldn't even guess.
>
>I will take full credit for guessing,
>that if the complete logic of calculating a "junk score"
>in any way blends the two files (the "StaticJunkDB.txt"
>which comes installed with the programs, plus the
>"UserJunkDB.txt" which changes upon user's "Junk/Not_Junk" actions),
>then I think it may improve reliance on one's own training,
>plus assist recovery of any corruption to one's own "UserJunkDB.txt"
>to have a previous version of it saved as "StaticJunkDB.txt,"
>thus "promoting the good health of two birds with one feeder" :)
>
>> [I got] incredibly few errors of either type after the first week.
>> My numbers are low, which one would think runs greater risk
>> of the first one going below zero and that hasn't happened.
>
>Does this point to possible prior use of an older Eudora version
>by the OP as a suspect? "Only the OP knows for sure" :)


A VERY GOOD POINT! This is perhaps why spewing references to old
messages, some of which predate version 6.?, is perhaps not such a
good idea without first asking. "Too much help" offered when the
problem isn't fully defined can become a "problem."


>> Bottom line to my part of this discussion (to including earlier
>> messages on the junk mail problem) being that I think very little of
>> this esoteric business about integers or signed integers was helpful
>> to the OP.
>
>Then why keep harping upon it?


Because the value of any help offered is proportional to the ability
to understand it and to see it as sensible, it makes no sense to
describe a value as a 32-bit integer and go on in references about the
vague relationship between big numbers and really big numbers being
the problem without accurately describing the integer being discussed
as 32-bit UNSIGNED... and for that matter without describing big vs
really big. There is a difference between information and usable
information.


>If we agree that when something subtracts 1 from 0,
>then it goes into "bad territory, counter-wise,"
>or even if we attribute the bad value to a haunting
>by an evil spirit, then it's still necessary to both
>recognize the symptom of a "bad counter"
>and know what sort of value a "good counter" should have,
>if we are to put it back into "good" state again,
>although unnecessary if we prefer
>to instead just junk the training file itself.


Agreed. But vague descriptions of good vs bad with big being OK, but
really big being bad, and then talking about positive vs negative
values - which don't clearly map to big vs really big doesn't seem
like it would help the average person.


>> He needs to edit his file to stop the problem
>
>Good, so he has to know what sort of edit makes it "good" again.


That's why I told him... without running him around to old messages, 2
out of 3 of which described the problem, but didn't clearly address a
solution.


>> and he needs to handle the manual junking
>> and manual unjunking of messages properly to avoid recurrence.


>This we do not know.


We do know he has the problem and we "know" he has been unjunking by
dragging. He said so.

>We have no evidence that version 7.1.0.9
>(or even 6.2.3.4) subtracts from any counter at any time,
>based on the very few experiments I have just done,
>but we do have the past testimony
>of some whom I would call expert,
>saying that some past version certainly did that,
>in response to _normal_ junking!


For the sake of discussion I'll stipulate that a past version
decremented the counter under some condition. So how is the problem
happening in ver 7.1.0.9 if it isn't still being decremented under
some condition? Do you hold the notion that it was incremented over 2
giga-times to make a 32-bit signed negative value to cause the
problem? That seems really unlikely.


>There are also other possibilities as to how it might go wrong,
>internally -- for example, if a 16-bit counter,
>while being _interpreted_ as signed, exceeds 32,767
>and is then copied to a 32-bit counter, again being
>interpreted as signed, but then is written as a decimal value
>to the file, by a function which interprets it as unsigned!
>
>We don't know what goes on, but one thing I just saw,
> from an experiment, is that dragging messages to or from Junk
>seemed to be of no influence at all.


I didn't see that. I saw proper unjunking incrementing the first
value while improper unjunking didn't. So... if we run with that
assumption that in an earlier version this value was decremented under
certain conditions, it seems that proper unjunking helps to prevent
the problem of this value falling below zero. Thus proper unjunking
is at least a factor in PREVENTING the problem.


>> Whether additional steps are needed to prevent
>> recurrence is unproven at this time.
>
>Then why give the unproven advice above,
>particularly when applying the _normal_ advice too often (that is,
>applying normal "Junk/Not_Junk" actions to too many messages)
>was declared by those who have researched this before
>as the actual precipitator of the problem!



>
>If I can keep my eyes from glazing over,
>I'll ask Katrina whether she has any more direct knowledge about this,
>and with what versions, etc. (she may also have had contact with developers,
>one might suspect, from some knowledge of internals which would otherwise
>seem hard to obtain).


Please don't do so on my account because my eyes are glazing over too
and I'm straying from the real point. My point isn't the technical
details per se. My point is that a lot of technical details don't
necessarily constitute help.


>Thank you, and good night.

Likewise.

--
Please don't be a "Help Vampire"
http://slash7.com/pages/vampires
From: Jim Higgins on 11 Nov 2009 09:55
On Wed, 11 Nov 2009 13:29:37 +0100, st.luck(a)NOSPAMkatamail.com wrote:

>> !MessageCount = 500, 11638
>
>Two days ago I have modified UserJunkDB.txt file and I have written
>"!MessageCount = 500, 11638". I now can tell you I have solved my
>problem. Eudora now works very very fine.
>Thanks for your suggestions.


That's good news! I'm glad to have been able to help.
--
Please don't be a "Help Vampire"
http://slash7.com/pages/vampires
From: Jim Higgins on 12 Nov 2009 11:08
On Wed, 11 Nov 2009 03:38:53 -0600, "John H Meyers"
<jhmeyers(a)nomail.invalid> wrote:

>On Wed, 11 Nov 2009 01:55:04 -0600, Jim Higgins wrote:
>>
>> and he needs to handle the manual junking
>> and manual unjunking of messages properly to avoid recurrence.
>
>
>This we do not know. We have no evidence that version 7.1.0.9
>(or even 6.2.3.4) subtracts from any counter at any time,
>based on the very few experiments I have just done,
>but we do have the past testimony of some whom I would
>call expert, saying that some past version certainly did that,
>in response to _normal_ junking!


I was going to leave this topic alone, but based on my own limited
testing this morning, Eudora 7.1.0.9 (registered) will decrement the
first !MessageCount counter in the UserJunkDB.txt file.

This morning I un-junked two messages with no change seen to the
UserJunkDB.txt file !MessageCount values UNTIL EUDORA WAS SHUT DOWN.
After shutdown it could be seen that the first count had been
incremented by 2, no change to the second count.

Now these same two messages were junked with no change seen to the
file until Eudora was again closed. After shutdown it could be seen
that the first count was DECREMENTED by two and the second count was
incremented by two.

It appears that Eudora only updates the UserJunkDB.txt file at
shutdown, or at least at longer intervals than my testing lasted. Any
testing that doesn't include shutting down Eudora before checking for
changes to the UserJunkDB.txt file is potentially flawed.

So, here's the case showing that Eudora does decrement the first
counter.

Also, here's the case for properly un-junking good mail rather than
dragging it out of junk as the OP initially indicated he had been
doing... because doing so increments the first counter, making it
less likely to fall below zero and become negative, which causes the
problem of all incoming mail being junked automatically.

I'm assuming/accepting that the counter is a 32-bit signed integer
when I say it becomes negative. Perhaps the problem comes about
because the first value is greater than or "huge" vs the second value.
I haven't tested either possibility and don't plan to.

I don't know if it's important, but my settings apply a junk value of
zero to a manually unjunked message and a value of 100 to a manually
junked message.
--
Please don't be a "Help Vampire"
http://slash7.com/pages/vampires
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Data folder
Next: convert selected to uppercase