On 10/18/2024 6:17 AM, Richard Damon wrote:The more interesting part is HHH simulating itself, specifically the
On 10/17/24 11:47 PM, olcott wrote:
On 10/17/2024 10:27 PM, Richard Damon wrote:
On 10/17/24 9:47 PM, olcott wrote:
On 10/17/2024 8:13 PM, Richard Damon wrote:
On 10/17/24 7:31 PM, olcott wrote:
When DDD is correctly emulated by HHH according to the semantics >>>>>>> of the x86 language DDD cannot possibly reach its own machine
address [00002183] no matter what HHH does.
[00002172]-->[00002173]-->[00002175]-->[0000217a]--+
Except that 0000217a doesn't go to 00002172, but to 000015d2
The Emulating HHH sees those addresses at its begining and then never
again.
Then the HHH that it is emulating will see those addresses, but not the
outer one that is doing that emulation of HHH.
And so on.
Which HHH do you think EVER gets back to 00002172?
What instruction do you think that it emulates that would tell it to do
so?
At best the trace is:OK great this is finally good progress.
00002172 00002173 00002175 0000217a conditional emulation of 00002172
conditional emulation of 00002173 conditional emulation of 00002175
conditional emulation of 0000217a CE of CE of 00002172 ...
He hasn't.and if HHH decides to abort its emulation, it also should know thatIf I understand his words correctly Mike has already disagreed with
every level of condition emulation it say will also do the same thing,
this.
Message-ID: <[email protected]>Of course. It needs to, in order to simulate it. Strictly speaking
On 3/1/2024 12:41 PM, Mike Terry wrote:
Obviously a simulator has access to the internal state (tape contents etc.) of the simulated machine. No problem there.This seems to indicate that the Turing machine UTM version of HHH can
somehow see each of the state transitions of the DDD resulting from
emulating its own Turing machine description emulating DDD.
*Joes can't seem to understand this*This is very simple to understand. Almost as simple as: even if only
Only the outer-most HHH meets its abort criteria first, thus unless it
aborts as soon as it meets this criteria none of them will ever abort.
--and thus the call HHH at 0000217a will be returned from, > and HHH has
no idea what will happen after that, so it KNOWS it is ignorant of the
answer.
On 10/18/2024 9:41 AM, joes wrote:What? That is part of HHH, not DDD.
Am Fri, 18 Oct 2024 09:10:04 -0500 schrieb olcott:That has nothing to do with any aspect of the emulation until HHH has correctly emulated itself emulating DDD.
On 10/18/2024 6:17 AM, Richard Damon wrote:The more interesting part is HHH simulating itself, specifically the
On 10/17/24 11:47 PM, olcott wrote:
On 10/17/2024 10:27 PM, Richard Damon wrote:
On 10/17/24 9:47 PM, olcott wrote:
On 10/17/2024 8:13 PM, Richard Damon wrote:
On 10/17/24 7:31 PM, olcott wrote:
When DDD is correctly emulated by HHH according to the semantics >>>>>>>>> of the x86 language DDD cannot possibly reach its own machine >>>>>>>>> address [00002183] no matter what HHH does.
[00002172]-->[00002173]-->[00002175]-->[0000217a]--+
Except that 0000217a doesn't go to 00002172, but to 000015d2
The Emulating HHH sees those addresses at its begining and then neverOK great this is finally good progress.
again.
Then the HHH that it is emulating will see those addresses, but not
the outer one that is doing that emulation of HHH.
And so on.
Which HHH do you think EVER gets back to 00002172?
What instruction do you think that it emulates that would tell it to
do so?
At best the trace is:
00002172 00002173 00002175 0000217a conditional emulation of 00002172
conditional emulation of 00002173 conditional emulation of 00002175
conditional emulation of 0000217a CE of CE of 00002172 ...
if(Root) check on line 502.
But it would.He hasn't.and if HHH decides to abort its emulation, it also should know thatIf I understand his words correctly Mike has already disagreed with
every level of condition emulation it say will also do the same
thing,
this.
From the concrete execution trace of DDD emulated by HHHMessage-ID: <[email protected]>Of course. It needs to, in order to simulate it. Strictly speaking it
On 3/1/2024 12:41 PM, Mike Terry wrote:
> Obviously a simulator has access to the internal state (tape
> contents etc.) of the simulated machine. No problem there.
This seems to indicate that the Turing machine UTM version of HHH can
somehow see each of the state transitions of the DDD resulting from
emulating its own Turing machine description emulating DDD.
has no idea of its simulation of a simulation two levels down, only of
the immediate simulation; the rest is just part of whatever program the
simulated simulator is simulating, which happens to be itself.
according to the semantics of the x86 language people with sufficient technical competence can see that the halt status criteria that
professor Sipser agreed to has been met.
If emulating termination analyzer HHH emulates its input DDD
until HHH determines that
its emulated DDD would never stop running unless aborted ...
Same as the outer HHH returning that the inner ones wouldn't.Yet that is based on the factually incorrect assumption that every*Joes can't seem to understand this*This is very simple to understand. Almost as simple as: even if only
Only the outer-most HHH meets its abort criteria first, thus unless it
aborts as soon as it meets this criteria none of them will ever abort.
the outermost HHH didn't abort, it would still halt,
instance of HHH does not use the exact same machine code.
--since it is simulating a halting program: the nested version will
abort.
and thus the call HHH at 0000217a will be returned from, > and HHH
has no idea what will happen after that, so it KNOWS it is ignorant
of the answer.
On 10/18/2024 12:00 PM, joes wrote:The existence of the check has an effect right from the start;
Am Fri, 18 Oct 2024 11:39:52 -0500 schrieb olcott:Until if (root) is true it has no effect on DDD emulated by HHH.
On 10/18/2024 9:41 AM, joes wrote:What? That is part of HHH, not DDD.
Am Fri, 18 Oct 2024 09:10:04 -0500 schrieb olcott:That has nothing to do with any aspect of the emulation until HHH has
On 10/18/2024 6:17 AM, Richard Damon wrote:The more interesting part is HHH simulating itself, specifically the
On 10/17/24 11:47 PM, olcott wrote:
On 10/17/2024 10:27 PM, Richard Damon wrote:
On 10/17/24 9:47 PM, olcott wrote:
On 10/17/2024 8:13 PM, Richard Damon wrote:
On 10/17/24 7:31 PM, olcott wrote:
When DDD is correctly emulated by HHH according to the
semantics of the x86 language DDD cannot possibly reach its >>>>>>>>>>> own machine address [00002183] no matter what HHH does.
[00002172]-->[00002173]-->[00002175]-->[0000217a]--+
Except that 0000217a doesn't go to 00002172, but to 000015d2
The Emulating HHH sees those addresses at its begining and then
never again.
Then the HHH that it is emulating will see those addresses, but not >>>>>> the outer one that is doing that emulation of HHH.
And so on.
Which HHH do you think EVER gets back to 00002172?
What instruction do you think that it emulates that would tell it
to do so?
At best the trace is:
00002172 00002173 00002175 0000217a conditional emulation of
00002172 conditional emulation of 00002173 conditional emulation of >>>>>> 00002175 conditional emulation of 0000217a CE of CE of 00002172 ... >>>>> OK great this is finally good progress.
if(Root) check on line 502.
correctly emulated itself emulating DDD.
But it would.From the concrete execution trace of DDD emulated by HHHMessage-ID: <[email protected]>Of course. It needs to, in order to simulate it. Strictly speaking it
On 3/1/2024 12:41 PM, Mike Terry wrote:
> Obviously a simulator has access to the internal state (tape
> contents etc.) of the simulated machine. No problem there.
This seems to indicate that the Turing machine UTM version of HHH
can somehow see each of the state transitions of the DDD resulting
from emulating its own Turing machine description emulating DDD.
has no idea of its simulation of a simulation two levels down, only
of the immediate simulation; the rest is just part of whatever
program the simulated simulator is simulating, which happens to be
itself.
according to the semantics of the x86 language people with sufficient
technical competence can see that the halt status criteria that
professor Sipser agreed to has been met.
If emulating termination analyzer HHH emulates its input DDD
until HHH determines that its emulated DDD would never stop
running unless aborted ...
Same as the outer HHH returning that the inner ones wouldn't.Yet that is based on the factually incorrect assumption that every*Joes can't seem to understand this*This is very simple to understand. Almost as simple as: even if only
Only the outer-most HHH meets its abort criteria first, thus unless
it aborts as soon as it meets this criteria none of them will ever
abort.
the outermost HHH didn't abort, it would still halt,
instance of HHH does not use the exact same machine code.
On 10/18/2024 2:10 PM, joes wrote:
The existence of the check has an effect right from the start;
besides, it is true the first time it is executed.
So maybe you have ADD too. You can't seem to pay
attention when things are explained to you many
different times several different ways.
The root variable has no effect on any aspect
of the emulation until the root variable has been
tested.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 10/18/2024 2:51 PM, Alan Mackenzie wrote:You said nothing at all. Productive communication would have included
olcott <[email protected]> wrote:*I never say that it didn't*
On 10/18/2024 2:10 PM, joes wrote:What you call "explaining" is in actual fact the assertion of
The existence of the check has an effect right from the start;So maybe you have ADD too. You can't seem to pay attention when things
besides, it is true the first time it is executed.
are explained to you many different times several different ways.
falsehoods. This is usually called lying.
The variable Root does indeed affect your program.
The "root" variable has NO EFFECT WHAT-SO-EVER on the correctness or completeness of HHH emulating itself emulating DDD until this DDD calls HHH(DDD).DDD does nothing else but call HHH, and Root is part of HHH, so is
On 10/18/2024 6:17 AM, Richard Damon wrote:
On 10/17/24 11:47 PM, olcott wrote:
On 10/17/2024 10:27 PM, Richard Damon wrote:
On 10/17/24 9:47 PM, olcott wrote:
On 10/17/2024 8:13 PM, Richard Damon wrote:
On 10/17/24 7:31 PM, olcott wrote:
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
When DDD is correctly emulated by HHH according
to the semantics of the x86 language DDD cannot
possibly reach its own machine address [00002183]
no matter what HHH does.
[00002172]-->[00002173]-->[00002175]-->[0000217a]--++------------------------------------------------------+
That may not line up that same way when view
https://en.wikipedia.org/wiki/State_diagram
Except that 0000217a doesn't go to 00002172, but to 000015d2
IS THIS OVER YOUR HEAD?
What is the first machine address of DDD that HHH
emulating itself emulating DDD would reach?
Yes, HHH EMULATES the code at that address,
Which HHH emulates what code at which address?
Everyone, just once, which you should know, but ignore.
The Emulating HHH sees those addresses at its begining and then never
again.
Then the HHH that it is emulating will see those addresses, but not
the outer one that is doing that emulation of HHH.
Then the HHH that the second HHH is emulating will, but neither of the
outer 2 HHH.
And so on.
Which HHH do you think EVER gets back to 00002172?
What instruction do you think that it emulates that would tell it to
do so?
It isn't the call instruction at 0000217a, as that tells it to go into
HHH.
At best the trace is:
00002172
00002173
00002175
0000217a
conditional emulation of 00002172
conditional emulation of 00002173
conditional emulation of 00002175
conditional emulation of 0000217a
CE of CE of 00002172
...
OK great this is finally good progress.
The "state" never repeats, it is alway a new state,
Every emulated DDD has an identical process state at every point
in its emulation trace when adjusting for different top of stack values.
and if HHH decides to abort its emulation, it also should know that
every level of condition emulation it say will also do the same thing,
If I understand his words correctly Mike has already disagreed
with this. Let's see if you can understand my reasoning.
Not exactly. Each HHH can only abort its emulation when its
abort criteria has been met. The outermost HHH can see one
more execution trace than the next inner one thus meets its
abort criteria first.
Message-ID: <[email protected]>
On 3/1/2024 12:41 PM, Mike Terry wrote:
Obviously a simulator has access to the internal state
(tape contents etc.) of the simulated machine. No problem
there.
This seems to indicate that the Turing machine UTM version of
HHH can somehow see each of the state transitions of the DDD
resulting from emulating its own Turing machine description
emulating DDD.
Even though this is a little different for Turing machines it
is equivalent in essence to HHH being able to see the steps of
the DDD resulting from HHH emulating itself emulating this DDD.
*Joes can't seem to understand this*
Only the outer-most HHH meets its abort criteria first, thus
unless it aborts as soon as it meets this criteria none of
them will ever abort.
and thus the call HHH at 0000217a will be returned from, > and HHH has
no idea what will happen after that, so it KNOWS it is ignorant of the
answer.
That you don't quite yet understand the preceding points
will make it impossible for you to understand any reply
to the above point.
On 10/18/2024 9:41 AM, joes wrote:
Am Fri, 18 Oct 2024 09:10:04 -0500 schrieb olcott:
On 10/18/2024 6:17 AM, Richard Damon wrote:The more interesting part is HHH simulating itself, specifically the
On 10/17/24 11:47 PM, olcott wrote:
On 10/17/2024 10:27 PM, Richard Damon wrote:
On 10/17/24 9:47 PM, olcott wrote:
On 10/17/2024 8:13 PM, Richard Damon wrote:
On 10/17/24 7:31 PM, olcott wrote:
When DDD is correctly emulated by HHH according to the semantics >>>>>>>>> of the x86 language DDD cannot possibly reach its own machine >>>>>>>>> address [00002183] no matter what HHH does.
[00002172]-->[00002173]-->[00002175]-->[0000217a]--+
Except that 0000217a doesn't go to 00002172, but to 000015d2
The Emulating HHH sees those addresses at its begining and then never
again.
Then the HHH that it is emulating will see those addresses, but not the >>>> outer one that is doing that emulation of HHH.
And so on.
Which HHH do you think EVER gets back to 00002172?
What instruction do you think that it emulates that would tell it to do >>>> so?
At best the trace is:OK great this is finally good progress.
00002172 00002173 00002175 0000217a conditional emulation of 00002172
conditional emulation of 00002173 conditional emulation of 00002175
conditional emulation of 0000217a CE of CE of 00002172 ...
if(Root) check on line 502.
That has nothing to do with any aspect of the emulation
until HHH has correctly emulated itself emulating DDD.
He hasn't.and if HHH decides to abort its emulation, it also should know thatIf I understand his words correctly Mike has already disagreed with
every level of condition emulation it say will also do the same thing,
this.
Message-ID: <[email protected]>
On 3/1/2024 12:41 PM, Mike Terry wrote:
> Obviously a simulator has access to the internal state (tape
contents
> etc.) of the simulated machine. No problem there.
This seems to indicate that the Turing machine UTM version of HHH can
somehow see each of the state transitions of the DDD resulting from
emulating its own Turing machine description emulating DDD.
Of course. It needs to, in order to simulate it. Strictly speaking
it has no idea of its simulation of a simulation two levels down,
only of the immediate simulation; the rest is just part of whatever
program the simulated simulator is simulating, which happens to be
itself.
From the concrete execution trace of DDD emulated by HHH
according to the semantics of the x86 language people with
sufficient technical competence can see that the halt status
criteria that professor Sipser agreed to has been met.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
I will paraphrase this to use clearer language that directly applies
to HHH and DDD.
If emulating termination analyzer HHH emulates its input DDD
according to the semantics of the x86 language (including HHH
emulating itself emulating DDD) until HHH correctly determines
that its emulated DDD would never stop running unless aborted
then ...
HHH can abort its emulation of DDD and correctly report that DDD
specifies a non-terminating sequence of x86 instructions.
*Joes can't seem to understand this*
Only the outer-most HHH meets its abort criteria first, thus unless it
aborts as soon as it meets this criteria none of them will ever abort.
This is very simple to understand. Almost as simple as: even if only
the outermost HHH didn't abort, it would still halt,
Yet that is based on the factually incorrect assumption
that every instance of HHH does not use the exact same
machine code.
Since you should know that this assumption is factually
incorrect I could it as flat out dishonestly on your part.
since it is
simulating a halting program: the nested version will abort.
and thus the call HHH at 0000217a will be returned from, > and HHH has >>>> no idea what will happen after that, so it KNOWS it is ignorant of the >>>> answer.
On 10/18/2024 6:19 PM, Richard Damon wrote:
On 10/18/24 12:39 PM, olcott wrote:
On 10/18/2024 9:41 AM, joes wrote:
Am Fri, 18 Oct 2024 09:10:04 -0500 schrieb olcott:
On 10/18/2024 6:17 AM, Richard Damon wrote:The more interesting part is HHH simulating itself, specifically the
On 10/17/24 11:47 PM, olcott wrote:
On 10/17/2024 10:27 PM, Richard Damon wrote:
On 10/17/24 9:47 PM, olcott wrote:
On 10/17/2024 8:13 PM, Richard Damon wrote:
On 10/17/24 7:31 PM, olcott wrote:
When DDD is correctly emulated by HHH according to the semantics >>>>>>>>>>> of the x86 language DDD cannot possibly reach its own machine >>>>>>>>>>> address [00002183] no matter what HHH does.
[00002172]-->[00002173]-->[00002175]-->[0000217a]--+
Except that 0000217a doesn't go to 00002172, but to 000015d2
The Emulating HHH sees those addresses at its begining and then never >>>>>> again.
Then the HHH that it is emulating will see those addresses, but
not the
outer one that is doing that emulation of HHH.
And so on.
Which HHH do you think EVER gets back to 00002172?
What instruction do you think that it emulates that would tell it
to do
so?
At best the trace is:OK great this is finally good progress.
00002172 00002173 00002175 0000217a conditional emulation of 00002172 >>>>>> conditional emulation of 00002173 conditional emulation of 00002175 >>>>>> conditional emulation of 0000217a CE of CE of 00002172 ...
if(Root) check on line 502.
That has nothing to do with any aspect of the emulation
until HHH has correctly emulated itself emulating DDD.
He hasn't.and if HHH decides to abort its emulation, it also should know that >>>>>> every level of condition emulation it say will also do the sameIf I understand his words correctly Mike has already disagreed with
thing,
this.
Message-ID: <[email protected]>
On 3/1/2024 12:41 PM, Mike Terry wrote:
> Obviously a simulator has access to the internal state (tape
contents
> etc.) of the simulated machine. No problem there.
This seems to indicate that the Turing machine UTM version of HHH can >>>>> somehow see each of the state transitions of the DDD resulting from
emulating its own Turing machine description emulating DDD.
Of course. It needs to, in order to simulate it. Strictly speaking
it has no idea of its simulation of a simulation two levels down,
only of the immediate simulation; the rest is just part of whatever
program the simulated simulator is simulating, which happens to be
itself.
From the concrete execution trace of DDD emulated by HHH
according to the semantics of the x86 language people with
sufficient technical competence can see that the halt status
criteria that professor Sipser agreed to has been met.
Nope.
Proven previously and you accepted by default by not pointing out an
error.
Your HHH neither "correctly simulated" per his definitions or
correctly predicts the behavior of such a simulation, and thus never
acheived the required criteria.
So you are still trying to stupidly get away with saying
that when a finite string of x86 code is emulated according
to the semantics of the x86 language
(including HHH emulating itself emulating DDD)
THAT THE EMULATION CAN BE WRONG ???
On 10/18/2024 4:24 PM, joes wrote:It has the effect of not aborting the simulation.
Am Fri, 18 Oct 2024 15:18:46 -0500 schrieb olcott:It is possible that I am not communicating this clearly enough
On 10/18/2024 2:51 PM, Alan Mackenzie wrote:You said nothing at all. Productive communication would have included
olcott <[email protected]> wrote:*I never say that it didn't*
On 10/18/2024 2:10 PM, joes wrote:What you call "explaining" is in actual fact the assertion of
The existence of the check has an effect right from the start;So maybe you have ADD too. You can't seem to pay attention when
besides, it is true the first time it is executed.
things are explained to you many different times several different
ways.
falsehoods. This is usually called lying.
The variable Root does indeed affect your program.
an agreement and clarification.
The "root" variable has NO EFFECT WHAT-SO-EVER on the correctness orDDD does nothing else but call HHH, and Root is part of HHH, so is
completeness of HHH emulating itself emulating DDD until this DDD
calls HHH(DDD).
simulated the first time around.
The root variable cannot possibly have have any effect what-so-ever on
the correctness of HHH emulating DDD or HHH emulating itself emulating
DDD until the root variable tests true.
On 10/19/2024 2:22 AM, joes wrote:
Am Fri, 18 Oct 2024 16:46:03 -0500 schrieb olcott:
On 10/18/2024 4:24 PM, joes wrote:
Am Fri, 18 Oct 2024 15:18:46 -0500 schrieb olcott:It is possible that I am not communicating this clearly enough
On 10/18/2024 2:51 PM, Alan Mackenzie wrote:You said nothing at all. Productive communication would have included
olcott <[email protected]> wrote:*I never say that it didn't*
On 10/18/2024 2:10 PM, joes wrote:What you call "explaining" is in actual fact the assertion of
The existence of the check has an effect right from the start; >>>>>>>> besides, it is true the first time it is executed.So maybe you have ADD too. You can't seem to pay attention when
things are explained to you many different times several different >>>>>>> ways.
falsehoods. This is usually called lying.
The variable Root does indeed affect your program.
an agreement and clarification.
The "root" variable has NO EFFECT WHAT-SO-EVER on the correctness or >>>>> completeness of HHH emulating itself emulating DDD until this DDDDDD does nothing else but call HHH, and Root is part of HHH, so is
calls HHH(DDD).
simulated the first time around.
The root variable cannot possibly have have any effect what-so-ever on
the correctness of HHH emulating DDD or HHH emulating itself emulating
DDD until the root variable tests true.
It has the effect of not aborting the simulation.
It has this effect only after every competent software
engineer can independently verify that it is correct:
Emulating termination analyzer HHH emulates its input DDD
according to the semantics of the x86 language (including HHH
emulating itself emulating DDD) until HHH correctly determines
that its emulated DDD would never stop running unless aborted.
Apart from that, Root is true in the root invocation of HHH (duh).
The other place that root is true has no effect on the correctness
of the x86 emulation. Do I have to tell you this 175 times before
you notice that I said it once?
On 10/19/2024 6:21 AM, Richard Damon wrote:
On 10/19/24 6:53 AM, olcott wrote:
On 10/19/2024 2:22 AM, joes wrote:
Am Fri, 18 Oct 2024 16:46:03 -0500 schrieb olcott:
On 10/18/2024 4:24 PM, joes wrote:
Am Fri, 18 Oct 2024 15:18:46 -0500 schrieb olcott:It is possible that I am not communicating this clearly enough
On 10/18/2024 2:51 PM, Alan Mackenzie wrote:You said nothing at all. Productive communication would have included >>>>>> an agreement and clarification.
olcott <[email protected]> wrote:*I never say that it didn't*
On 10/18/2024 2:10 PM, joes wrote:What you call "explaining" is in actual fact the assertion of
The existence of the check has an effect right from the start; >>>>>>>>>> besides, it is true the first time it is executed.So maybe you have ADD too. You can't seem to pay attention when >>>>>>>>> things are explained to you many different times several different >>>>>>>>> ways.
falsehoods. This is usually called lying.
The variable Root does indeed affect your program.
The "root" variable has NO EFFECT WHAT-SO-EVER on the correctness or >>>>>>> completeness of HHH emulating itself emulating DDD until this DDD >>>>>>> calls HHH(DDD).DDD does nothing else but call HHH, and Root is part of HHH, so is >>>>>> simulated the first time around.
The root variable cannot possibly have have any effect what-so-ever on >>>>> the correctness of HHH emulating DDD or HHH emulating itself emulating >>>>> DDD until the root variable tests true.
It has the effect of not aborting the simulation.
It has this effect only after every competent software
engineer can independently verify that it is correct:
Emulating termination analyzer HHH emulates its input DDD
according to the semantics of the x86 language (including HHH
emulating itself emulating DDD) until HHH correctly determines
that its emulated DDD would never stop running unless aborted.
Except that the correct determination doesn't happen in the case that
Root doesn't affect the behavior of the emulated DDD, so that impurity
does have affect.
The root variable has no effect what-so-ever on
the correctness of the emulation up to the point
where everyone can see that HHH is correct to reject DDD.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 716 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 56:38:11 |
| Calls: | 12,117 |
| Files: | 15,010 |
| Messages: | 6,518,666 |