Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: vallor <vallor@cultnix.org>
Newsgroups: comp.theory
Subject: Re: Turing Machine computable functions apply finite string
 transformations to inputs
Date: Tue, 13 May 2025 11:01:00 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 52
Message-ID: <vvv8pc$1mff2$2@dont-email.me>
References: <vu6lnf$39fls$2@dont-email.me> <vua9oi$2lub6$1@dont-email.me>
	<vudkah$1ona3$1@dont-email.me> <vufi61$3k099$1@dont-email.me>
	<vugddv$b21g$2@dont-email.me>
	<0a2eeee6cb4b6a737f6391c963386745a09c8a01@i2pn2.org>
	<vugvr3$pke9$8@dont-email.me>
	<4818688e0354f32267e3a5f3c60846ae7956bed2@i2pn2.org>
	<vuj18i$2lf64$6@dont-email.me>
	<f0d3f2e87d9a4e0b0f445f60a33d529f41a4fcf7@i2pn2.org>
	<vuj55m$2lf64$10@dont-email.me> <vuj8h3$2uahf$3@dont-email.me>
	<vujfuu$35hcg$1@dont-email.me>
	<65dddfad4c862e6593392eaf27876759b1ed0e69@i2pn2.org>
	<vujlj0$3a526$1@dont-email.me> <vujln7$32om9$8@dont-email.me>
	<vujmmm$3a526$2@dont-email.me> <vujmrj$32om9$9@dont-email.me>
	<vujtcb$3gsgr$1@dont-email.me>
	<XpecnXs9MtzKApD1nZ2dnZfqnPudnZ2d@brightview.co.uk>
	<QJ-dnfPs3ckgO5D1nZ2dnZfqn_adnZ2d@brightview.co.uk>
	<KvSdnTEjuOT7x5P1nZ2dnZfqlJydnZ2d@giganews.com>
	<8d96b4dc99c7e8643b6fda45f200891d920b2acd@i2pn2.org>
	<vun3an$2hlca$1@dont-email.me> <vun7sc$2fjjl$3@dont-email.me>
	<vvv74g$1mff2$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 13 May 2025 13:01:02 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0f5a868160e7b3b323478088f8a7b392";
	logging-data="1785314"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19FPOxi7KjSBJqbgVHCvwQi"
User-Agent: Pan/0.162 (Hmm4; 7b109588; Linux-6.14.6)
Cancel-Lock: sha1:+VimcH8CS4fVK6QSqVl5qQRD7lY=
X-Face: \}2`P"_@pS86<'EM:'b.Ml}8IuMK"pV"?FReF$'c.S%u9<Q#U*4QO)$l81M`{Q/n
 XL'`91kd%N::LG:=*\35JS0prp\VJN^<s"b#bff@fA7]5lJA.jn,x_d%Md$,{.EZ

On Tue, 13 May 2025 10:32:48 -0000 (UTC), vallor <vallor@cultnix.org>
wrote in <vvv74g$1mff2$1@dont-email.me>:

> On Mon, 28 Apr 2025 07:40:12 +0100, Richard Heathfield <rjh@cpax.org.uk>
> wrote in <vun7sc$2fjjl$3@dont-email.me>:
> 
>> On 28/04/2025 06:22, vallor wrote:
>>> On Sun, 27 Apr 2025 21:06:29 -0400, Richard Damon
>>> <richard@damon-family.org> wrote in
>>> <8d96b4dc99c7e8643b6fda45f200891d920b2acd@i2pn2.org>:
>>> 
>>>> Which is just an admission that your HHH's are not actual correct
>>>> emulator, and you can only apply that statement in the version of
>>>> your claims where you retract your claim about Halt7.c being part of
>>>> the system (as then then is one and only one HHH), and thus your DD
>>>> just is not a program unless you include HHH as part of it, and thus
>>>> each is a DIFFFERENT input.
>>> 
>>> Sorry to butt in...
>>> 
>>> Where does one find this Halt7.c?
>> 
>> <https://github.com/plolcott/x86utm>
>> 
>> (If you're expecting something amazing, prepare yourself for a
>> disappointment.)
> 
> Thank you.
> 
> Looks complicated.  Appears to obfuscate the issue.

So to get it to compile -m32 with its included headers, I have to
do this:

*DON'T DO THIS* // sudo apt install linux-libc-dev:i386 // *DON'T DO THIS*

Inspecting the results of what it wanted to do (removing a lot
of the system), it was apparent that it would screw up my
workstation royally.

So, I thought I'd try building Halt7.o 64-bit, from whose warnings
it was apparent that this is hard-coded for 32-bits, including 32-bit
pointers.

$ egrep "warning|note" nohup.out | wc -l
74

I guess I could install a 32-bit virtual machine and try it there,
but I'm not _that_ interested.

-- 
-v