Sunday, September 6, 2020

Digest for comp.lang.c++@googlegroups.com - 18 updates in 6 topics

Vir Campestris <vir.campestris@invalid.invalid>: Sep 06 09:55PM +0100

On 04/09/2020 18:38, Frederick Gotham wrote:
 
> Like this:
 
> some_other_program | sed 's/../\\x&/g' | xargs echo -e
 
> Can anyone think of an even more simple way?
 
You have sed (109000 bytes on my system) but not xxd (18552 bytes)?
 
You picked the wrong tools.
 
Andy
Jeff Barnett <jbb@notatt.com>: Sep 05 05:52PM -0600

On 9/5/2020 4:01 PM, Mike Terry wrote:
> legitimate input (H^Hat, H_Hat), enabling it to behave differently when
> it's invoked internally within H_Hat.  (Input from global variables?
> Something in his emulator implementation? ...)
 
Experience has shown he's not intelligent enough to make those kind of
mistakes unless utterly by accident. Also there is a lot of troll in him
and the only detectable trait is that he wants people to respond to his
inanities. Just remember that he claimed to have all of this ready to
go, i.e. coded, around two years ago - lies of course - and this is all
a rearguard action to cover his ego. In other, words don't expect to
ever see a TM or equivalent encoding for H.
 
--
Jeff Barnett
Richard Damon <Richard@Damon-Family.org>: Sep 05 09:12PM -0400

On 9/5/20 7:52 PM, Jeff Barnett wrote:
> ever see a TM or equivalent encoding for H.
 
>> But he's not going to give any details, so we'll just have to wait and
>> see...
 
My first guess, is that he somehow thinks that if H doesn't say Halted,
that is good enough to be considered as the 'Not Halting' answer, when
of course it isn't. That or some other 'small' change to the ground
rules, that would actually allow H to be something trivial or
uninteresting, so proving that this modified H can exist actully means
nothing.
olcott <NoOne@NoWhere.com>: Sep 05 09:49PM -0500

On 9/5/2020 5:01 PM, Mike Terry wrote:
 
> But he's not going to give any details, so we'll just have to wait and
> see...
 
> Mike.
 
Linz H
(q0)---->(HDC)---->((qy)) or ((qn))
based on some halting deciding code in (HDC).
 
Linz Ĥ
(q0)---->(qx)---->(HDC)---->(qy)---->(infinite_loop) or ((qn))
based on same halting deciding code in (HDC).
 
As long as the halt deciding code in HDC is the same in H and H_Hat and
shows that its decision is correct then the Linz proof has been refuted.
The halting code is the only unspecified detail of H or Ĥ.
 
I make sure that the halting code is the same in H and Ĥ by having them
both call the same function.
 
I don't have to show that H can correctly decide halting for every
possible encoding of the halting code. I only have to show that it is
not the H / H_hat template that prevents a correct halting decision.
 
http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
 
--
Copyright 2020 Pete Olcott
Mike Terry <news.dead.person.stones@darjeeling.plus.com>: Sep 06 04:35AM +0100

On 06/09/2020 03:49, olcott wrote:
> The halting code is the only unspecified detail of H or Ĥ.
 
> I make sure that the halting code is the same in H and Ĥ by having them
> both call the same function.
 
That is a sensible way to do it. Also, of course, the /input/ to H when
H decides (Ĥ, Ĥ) must be the same as the input to the embedded copy of H
within Ĥ when Ĥ runs with input (Ĥ). That should essentially be
guaranteed by the coding of Ĥ assuming it is correctly related to H, but
also the embedded H cannot receive any "hidden" input from global
variables or elsewhere. (This can't happen with a TM, as input is
exactly what is on the tape and nothing more, and that is precisely (Ĥ,
Ĥ) [suitably encoded etc.] in both situations.)
 
To save possible problems here, it would be clearest to simply ban
global variables - they are not required, since all required input can
simply be passed to routines explicitly, and banning them eliminates one
possible source of objection to whatever you finally deliver.
 
 
Mike.
 
 
olcott <NoOne@NoWhere.com>: Sep 05 10:50PM -0500

On 9/5/2020 10:35 PM, Mike Terry wrote:
> simply be passed to routines explicitly, and banning them eliminates one
> possible source of objection to whatever you finally deliver.
 
> Mike.
 
Yes the only actual global variables that are needed are needed by the
UTM environment itself to keep track of heap allocations of memory.
Because user code can store a pointer to its heap allocated memory it
needs no global data at all.
 
I don't currently know of a way to distinguish between global data and
static local data or I could simply ban access to global data by user
code. It may say somewhere in the COFF file how to tell the difference.
 
 
--
Copyright 2020 Pete Olcott
olcott <NoOne@NoWhere.com>: Sep 05 10:58PM -0500

On 9/5/2020 10:35 PM, Mike Terry wrote:
> global variables - they are not required, since all required input can
> simply be passed to routines explicitly, and banning them eliminates one
> possible source of objection to whatever you finally deliver.
 
There an easy way to ban access to global variables by user code.
That is a good idea I think I will implement it as a compile time switch.
 
 
 
--
Copyright 2020 Pete Olcott
Richard Damon <Richard@Damon-Family.org>: Sep 06 08:47AM -0400

On 9/5/20 10:49 PM, olcott wrote:
 
> Linz H
> (q0)---->(HDC)---->((qy)) or ((qn))
> based on some halting deciding code in (HDC).
 
Should be Linz H(M,x)
That makes the decision based on whether the machine M with input x will
halt or not.
 
> Linz Ĥ
> (q0)---->(qx)---->(HDC)---->(qy)---->(infinite_loop) or ((qn))
> based on same halting deciding code in (HDC).
 
Linz Ĥ(M, x)
That makes the decision based on whether the machine M with input x will
halt or not
 
Not sure where (qx) came from, and the or is placed a bit awkward too. I
might write it as:
 
(q0)---->(HDC)---->((qn)) or (qy)---->(infinite_loop)
 
> possible encoding of the halting code. I only have to show that it is
> not the H / H_hat template that prevents a correct halting decision.
 
> http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
 
You need to break the paradox that Linz Ĥ(Ĥ, Ĥ) doesn't have a valid
answer. That would require either showing an answer it could give that
meets the requirement (some sort of Non-Halting Halting??), or that
somehow the construction of Ĥ some how is an impossibility even if we
can make a H. I suppose the latter could be describe as it is not the H
/ H_Hat template that prevents a correct halting decision, but that
seems to be awkward wording, and seems more like trying to open up some
wiggle room for inserting a fallacious argument.
olcott <NoOne@NoWhere.com>: Sep 06 11:42AM -0500

On 9/6/2020 7:47 AM, Richard Damon wrote:
 
> Not sure where (qx) came from, and the or is placed a bit awkward too. I
> might write it as:
 
> (q0)---->(HDC)---->((qn)) or (qy)---->(infinite_loop)
 
(qx) come from a correction to the Linz definition of H_hat having two
start states.
 
> / H_Hat template that prevents a correct halting decision, but that
> seems to be awkward wording, and seems more like trying to open up some
> wiggle room for inserting a fallacious argument.
 
I explain it all here in terms of the Linz diagrams.
http://www.liarparadox.org/Linz_Diagrams.pdf
 
 
--
Copyright 2020 Pete Olcott
"André G. Isaak" <agisaak@gm.invalid>: Sep 06 11:43AM -0600

On 2020-09-06 10:42, olcott wrote:
 
> (qx) come from a correction to the Linz definition of H_hat having two
> start states.
 
You're going to have to clarify this. Where does Linz do this and how
does your qx correct this?
 
André
 
--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.
olcott <NoOne@NoWhere.com>: Sep 06 01:04PM -0500

On 9/6/2020 12:43 PM, André G. Isaak wrote:
 
> You're going to have to clarify this. Where does Linz do this and how
> does your qx correct this?
 
> André
 
Look at the Linz definition of H_Hat and notice that he has two (q0)
start states one after the other. I changed the name of the second one
to (qx).
 
 
I also wrote this succinct summary detailing the architecture of how my
x86 based UTM equivalent implements H and H_Hat.
 
http://www.liarparadox.org/Linz_Diagrams.pdf
 
 
--
Copyright 2020 Pete Olcott
olcott <NoOne@NoWhere.com>: Sep 06 01:08PM -0500

On 9/5/2020 8:12 PM, Richard Damon wrote:
> rules, that would actually allow H to be something trivial or
> uninteresting, so proving that this modified H can exist actully means
> nothing.
 
I explain the architecture of my solution here:
http://www.liarparadox.org/Linz_Diagrams.pdf
 
--
Copyright 2020 Pete Olcott
olcott <NoOne@NoWhere.com>: Sep 06 12:22PM -0500

On 9/6/2020 11:00 AM, Mike Terry wrote:
>> directly execute COFF object files.
 
> Will you be making the emulator (source code) available as part of your
> delivery?
 
Better than that, I will be making it available first.
 
>> execute COFF object files representing x86 code.
 
> A minor question (just curious):  a COFF file can contain many function
> implementations, so how would the emulator know which was the entry point?
 
The assumption is that the COFF file is generated by a Microsoft "C"
compiler, thus the entry point is always main().
 
>> be initialized or they don't exist at all.
 
>> The only output is an assembly language execution trace.
 
> OK, but how does my C code get a value into EAX?  If I included a return
 
Here are all of the details of a complete example:
 
// "C" Source code
unsigned int Test()
{
return 0x12345678;
}
 
 
int main()
{
Test();
__asm hlt
}
 
// Intel XED Disassembly
b4: 55 push ebp
b5: 8BEC mov ebp, esp
b7: E803000000 call 0xbf
bc: F4 hlt
bd: 5D pop ebp
be: C3 ret
 
bf: 55 push ebp
c0: 8BEC mov ebp, esp
c2: B878563412 mov eax, 0x12345678
c7: 5D pop ebp
c8: C3 ret
 
// Debug Trace
[00b4] 55 push ebp
[00b5] 8bec mov ebp,esp
[00b7] e803000000 call 000000bf
[00bf] 55 push ebp
[00c0] 8bec mov ebp,esp
[00c2] b878563412 mov eax,12345678
[00c7] 5d pop ebp
[00c8] c3 ret
[00bc] f4 hlt
 
The halt decider is executed this same way, returning a value to main()
this same way.
 
> question for the C coding itself (do I just code void Add (int a, int b)
> {...} and assume inputs are passed as a,b), and also for the scenario
> where I want to run the program in your emulator.
 
Its just regular ordinary "C" code that generates regular ordinary COFF
object files with the Microsoft "C" compiler.
 
The only thing that makes an x86 emulator into a UTM equivalent are four
operating system function calls that the master UTM equivalent provides
to its user programs:
 
// Saves the state of the current virtual-machine
void SaveState(u32* s);
 
// Loads the state of a saved virtual-machine
void LoadState(u32* s);
 
// Allocates memory from the heap
u32* Allocate(u32 size);
 
// The master machine executes the slave machine
void DebugStep(u32* master_state, u32* slave_state);
 
Each user code UTM equivalent can be the master to its own slave to an
arbitrary recursion depth.
 
 
> But the decider function does not return, right?  it somehow executes a
> HLT instruction.
 
> Mike.
 
unsigned int H() is invoked from main() and returns to main() where
main() reaches HLT and halts. (see complete example above).
 
--
Copyright 2020 Pete Olcott
olcott <NoOne@NoWhere.com>: Sep 06 12:40PM -0500

On 9/6/2020 12:22 PM, olcott wrote:
>>> be initialized or they don't exist at all.
 
>>> The only output is an assembly language execution trace.
 
>> OK, but how does my C code get a value into EAX?  If I included a return
 
Here is a slightly more complete example.
 
// "C" source code
unsigned int Test2()
{
return 0x12345678;
}
 
 
int main()
{
unsigned int M = Test2();
__asm hlt
}
 
// Intel XED Disassembly
b4: 55 push ebp
b5: 8BEC mov ebp, esp
b7: 51 push ecx
b8: E808000000 call 0xc5
bd: 8945FC mov dword ptr [ebp-0x4], eax
c0: F4 hlt
c1: 8BE5 mov esp, ebp
c3: 5D pop ebp
c4: C3 ret
 
c5: 55 push ebp
c6: 8BEC mov ebp, esp
c8: B878563412 mov eax, 0x12345678
cd: 5D pop ebp
ce: C3 ret
 
// Execution trace
[00b4] 55 push ebp
[00b5] 8bec mov ebp,esp
[00b7] 51 push ecx
[00b8] e808000000 call 000000c5
[00c5] 55 push ebp
[00c6] 8bec mov ebp,esp
[00c8] b878563412 mov eax,12345678
[00cd] 5d pop ebp
[00ce] c3 ret
[00bd] 8945fc mov [ebp-04],eax
[00c0] f4 hlt
 
--
Copyright 2020 Pete Olcott
Jorgen Grahn <grahn+nntp@snipabacken.se>: Sep 06 02:38PM

On Mon, 2020-08-31, Keith Thompson wrote:
 
> I encourage anyone in comp.lang.c or comp.lang.c++ who wants to
> reply to these posts to take a look at comp.theory, which has been
> dominated by these arguments for years.
 
And now, six days later, the normal/crackpot ratio in both comp.lang.c
and comp.lang.c++ has dropped to close to zero. (Not that it was very
high to begin with, especially not in comp.lang.c.)
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Paavo Helde <eesnimi@osa.pri.ee>: Sep 06 11:09AM +0300

04.09.2020 17:44 RM kirjutas:
> }
 
> I failed to find C++ regex tester in WWW, thus I don't know what's wrong
> with my regex. Please help.
 
This is more a regex question, not so much C++. I'm not a regex expert
either, but when I tested your regex with normal egrep command-line, it
seemed to work better when I used [\s\n] instead of (\s|\n).
Jorgen Grahn <grahn+nntp@snipabacken.se>: Sep 06 08:30AM

On Sun, 2020-09-06, Paavo Helde wrote:
> 04.09.2020 17:44 RM kirjutas:
...
>> I failed to find C++ regex tester in WWW, thus I don't know what's wrong
>> with my regex. Please help.
 
> This is more a regex question, not so much C++.
 
It could be a C++ question if there was something unique about
std::regex ... but the normal flavor of std::regex is ECMAScript, so
an online Javascript regex tester should be good enough. Options like
"multiline" most likely have direct equivalents, too.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Brian Wood <woodbrian77@gmail.com>: Sep 05 06:59PM -0700

On Saturday, September 5, 2020 at 3:34:17 PM UTC-5, Mr Flibble wrote:
> > can't kill the truth. I'd be happy to work with that
> > prof.
> That is because you are a bigot like him.
 
I think we know who is the bigot here. It's not the
professor and it's not me.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.

No comments: