| olcott <NoOne@NoWhere.com>: Oct 24 12:49PM -0500 On 10/24/2020 11:37 AM, Mike Terry wrote: >> cannot be contradicted. > The Linz halt decider corresponds to the correct (HP) definition of a > halt decider. If you change this definition you are not discussing HP. As long as a halt decider cannot be shown to make this decision incorrectly for any of its inputs then the halting problem cannot be shown to be undecidable: bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) >> ever get the wrong halting answer. > A halt decider is what the HP says a halt decider is. There is nothing > in that definition about "cannot be shown to...". You've made that up. The conventional halting problem proof counter-examples can be decided by this function: bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) because they are infinitely recursive and never reach their undecidable states. >> itself always halts then all of the other details are moot. > The point of the Linz proof is that it /does/ show that any halt decider > will always give a wrong answer for at least one input (the (H^,H^) input). No not at all, not in the least little bit. The Linz proof only shows that one kind of halt decider gets the wrong answer some of the time because this halt decider is subject to pathological self-reference. You are spouting off your view as if it was the primary tenet of your religion. Instead of that try and find an input this this function could not decide correctly: bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) -- Copyright 2020 Pete Olcott |
| Mike Terry <news.dead.person.stones@darjeeling.plus.com>: Oct 24 07:32PM +0100 On 24/10/2020 18:49, olcott wrote: > incorrectly for any of its inputs then the halting problem cannot be > shown to be undecidable: > bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) The Linz proof shows HP to be undecidable. Your refuting code conforms with the Linz conclusion, and does not refute anything. (And stop repeating the same phrases over and over - saying something 50 times does not make it suddenly right, and people are not going to suddenly change their minds unless you present a new argument.) > bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) > because they are infinitely recursive and never reach their undecidable > states. All "conventional halting proof counter-examples" can be decided by /some/ partial halt decider. You need to come up with one specific H() which correctly decides (actual) halting for its own H_Hat running with input (H_Hat). If you're saying in YOUR soon-to-be-delivered machine H() you have a function bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I), and in this example it correctly decides the H_Hat(H_Hat) halting, then you're clearly wrong, as shown by my stack traces which you've pretty much agreed are correct. > The Linz proof only shows that one kind of halt decider gets the wrong > answer some of the time because this halt decider is subject to > pathological self-reference. No, the Linz H proof applies to /any/ purported halt decider H. Nothing in the proof restricts the kind of logic employed within H. Stop spouting off your view as though you were saying something sensible. Instead just admit you're wrong and you've wasted n years of effort. > religion. Instead of that try and find an input this this function could > not decide correctly: > bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) That function is not a halt decider, so your request is irrelevant, even if you could specify it coherently. That's not spouting anything off, it's just looking at what a halt decider is defined to be. Mike. ps. there's no point posting anything further unless you have some new idea to post. |
| olcott <NoOne@NoWhere.com>: Oct 24 01:38PM -0500 On 10/24/2020 10:58 AM, Mike Terry wrote: >> Infinitely recursive. > What do you mean by that? Are you agreeing or disagreeing with the > line? How should the line be corrected? I mean that H_Hat() does not loop. H_Hat() executes infinite recursion and thus never reaches its undecidable states. > Does Was_Its_Execution_Aborted() decide the emulated H_Hat(H_Hat) is > exhibiting infinite recursion)? That is a form of "not halting", so we > could make the line 100% correct by rewording it Yes you got it. > wording to > Was_Its_Execution_Aborted decides the emulated program .. > .. will never terminate if not aborted Perfect !!! > I.e. the problem(?) is just my use of the word "loop" rather than the > more general "never terminate". Exactly !!! > So this is easily corrected - we just have to know how ABORTED is to be > translated into H's HALT/NOT_HALT decision. (I.e. whether H sets EAX to > 0 or 1 when ABORTED is true...) (a) Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) == true means that an error was detected and the program's execution was aborted. (b) Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) == false means that NO ERROR WAS DETECTED and the program's execution WAS NOT ABORTED. Although (b) is an example of HALTED (a) is not an example of NOT_HALTED > >> H_Hat does the opposite of HALT/NOT_HALT > to > >> H_Hat halts Yes. When either H(H_Hat, H_Hat) or H_Hat(H_Hat) is called from the x86utm execution context they both call Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) from this context and they both receive a return value of TRUE. Both of these execution contexts create another execution context where another Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) is executed that get aborted before it ever returns any value. > Not really, H_Hat is not a decider. It is only you who sees weirdness, > because you /tried/ to design H/H^ to work in a particular way, and in > the end they do not. :) What I mean by really weird is only that other people besides myself may have very great difficulty in understanding how the same function Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) does not return the same result from what superficially seems to be the same input. They may even have great difficulty in understanding that an outer instance of Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) can possibly exist. If they can't understand that an outer instance can possibly exist then they can't understand that this outer instance has seen a longer sequence of execution steps than the inner instance. Ben would probably respond as he has responded in the past and simply dogmatically assert that there cannot possibly be any inner or outer instance there can only be a single instance. The key difference this time is that I have a fully operational x86utm operating system to empirically prove otherwise. He would then go on to say that this same sort of thing has nothing to do with Turing machines as if it was impossible for a UTM to execute another UTM that executes yet another UTM. At this point he would go back to his dogmatic assertions and simply ignore everything that I say. > (Also, the trace is only for the outer level process, and you are trying > to explain something about the inner levels, which is OK but not > relevant to this level of trace.) The outermost instance of bool Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) that is executed in the x86utm execution context simply traces the execution of H_Hat(H_Hat) until it decides that this execution is infinitely recursive then its stops tracing this execution trace and reports true. When executed in the outermost execution context of x86utm both H(H_Hat, H_Hat) and H_Hat(H_Hat) call bool Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) thus they both get the same return value of true. > .. will never terminate if not aborted > Was_Its_Execution_Aborted stops emulating and returns ABORTED > H_Hat halts It only halts because it was aborted thus it was decided to be incorrect. If (as in the olden days before there were user interface infinite loops) a program that never halted was always incorrect then bool Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) always divides programs into correct / incorrect. > Great! > Except that now the H_Hat and H machine traces are in conflict for the > expected reason. In every single case Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) divides programs into correct / incorrect There are no undecidable case. Either a program had to be terminated because it would not otherwise halt or it need not be terminated because it has halted. Either a program had to be terminated because it would not otherwise halt or it need not be terminated because it has halted. Either a program had to be terminated because it would not otherwise halt or it need not be terminated because it has halted. Either a program had to be terminated because it would not otherwise halt or it need not be terminated because it has halted. Either a program had to be terminated because it would not otherwise halt or it need not be terminated because it has halted. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 24 01:42PM -0500 On 10/24/2020 1:32 PM, Mike Terry wrote: >> bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) > The Linz proof shows HP to be undecidable. Your refuting code conforms > with the Linz conclusion, and does not refute anything. Unless you can concretely show how this function would get the wrong answer all of your rebuttal is ultimately totally vacuous: bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 24 01:46PM -0500 On 10/24/2020 11:04 AM, Malcolm McLean wrote: > which blows up the entire computer. > However currently DebugTrace doesn't abort itself. That's the mistake you're > making. The outer instance of Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) that is executed in the operating system process context of x86utm aborts the whole process tree that is connected to the process that it is emulating. -- Copyright 2020 Pete Olcott |
| Mike Terry <news.dead.person.stones@darjeeling.plus.com>: Oct 24 08:00PM +0100 On 24/10/2020 19:42, olcott wrote: > Unless you can concretely show how this function would get the wrong > answer all of your rebuttal is ultimately totally vacuous: > bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) In your code, the function answers "non halting behaviour detected" for input which actually halts, and so by any reasonable definition of the words, it has decided incorrectly. Look, here are the traces: H_Hat machine trace ------------------- H_Hat starts (main() calls H_Hat(H_Hat)) H_Hat calls Was_Its_Execution_Aborted(H_Hat,H_Hat) Was_Its_Execution_Aborted emulates H_Hat(H_Hat) Was_Its_Execution_Aborted decides the emulated program .. .. will never terminate if not aborted Was_Its_Execution_Aborted stops emulating and returns ABORTED H_Hat *halts* H machine trace --------------- H starts (main() calls H(H_Hat,H_Hat)) H calls Was_Its_Execution_Aborted(H_Hat,H_Hat) Was_Its_Execution_Aborted emulates H_Hat(H_Hat) Was_Its_Execution_Aborted decides the emulated program .. .. will never terminate if not aborted Was_Its_Execution_Aborted stops emulating and returns ABORTED H halts, with EAX=0 [= *NOT_HALT* decision] Mike. |
| olcott <NoOne@NoWhere.com>: Oct 24 02:01PM -0500 On 10/24/2020 10:43 AM, Andy Walker wrote: >> counter-examples ever reach their undecidable state transitions. > The reason why no-one ever noticed such things is that the > "conventional" proofs are neither recursive [infinitely or otherwise] // M has address of H_Hat() void H_Hat(u32 M) { if (DebugTrace(M, M)) // M(M) Aborted? MOV_EAX_0 // Execution of M(N) has been aborted else { MOV_EAX_1 // M(N) has halted HERE: goto HERE; } HALT } Since DebugTrace(M, M) executes its input one step at a time it is obvious that the first line of H_Hat() is infinitely recursive. There may be other ways to decide halting besides executing the program one step at a time carefully examining each step to look for non-halting behavior, yet this way is the simplest and most reliable. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 24 02:05PM -0500 On 10/24/2020 2:00 PM, Mike Terry wrote: > In your code, the function answers "non halting behaviour detected" for > input which actually halts, and so by any reasonable definition of the > words, it has decided incorrectly. Bullshit. The actual question that it always correctly answers is: Does the input have to be aborted to prevent infinite execution? This question correctly divides the set of all programs into correct and incorrect and it cannot be fooled by any cheap trick. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 24 02:08PM -0500 On 10/24/2020 12:27 PM, Richard Damon wrote: >> Now it correctly decided halting AND got the correct answer. > And since you changed the question to something different, you CAN'T say > anything about the original question! I can say that the halting problem, cannot be shown to be undecidable when we simply rephrase the question to a question that is not subject to a cheap trick: Does the input have to be aborted to prevent infinite execution? This question correctly divides the set of all programs into correct and incorrect and it cannot be fooled by any cheap trick. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 24 02:13PM -0500 On 10/24/2020 12:36 PM, Richard Damon wrote: > That is like refute the fact that there is no highest prime number by > redefining prime numbers (or maybe redefining the Natural Numbers that > primes are part of). Not at all. Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) == true means that the input has infinite execution. Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) == false means that the input DOES NOT HAVE infinite execution. and there are no programs left over that can be shown to be undecidable. -- Copyright 2020 Pete Olcott |
| Mike Terry <news.dead.person.stones@darjeeling.plus.com>: Oct 24 08:44PM +0100 On 24/10/2020 20:05, olcott wrote: >> the words, it has decided incorrectly. > Bullshit. The actual question that it always correctly answers is: > Does the input have to be aborted to prevent infinite execution? I provided the traces which back up what I said, so it's not bullshit. You have snipped them because you don't want to look stupid, so I'm going to restore them: H_Hat machine trace ------------------- H_Hat starts (main() calls H_Hat(H_Hat)) H_Hat calls Was_Its_Execution_Aborted(H_Hat,H_Hat) Was_Its_Execution_Aborted emulates H_Hat(H_Hat) Was_Its_Execution_Aborted decides the emulated program .. .. will never terminate if not aborted Was_Its_Execution_Aborted stops emulating and returns ABORTED H_Hat *halts* OK, so the H_Hat calculation halts... H machine trace --------------- H starts (main() calls H(H_Hat,H_Hat)) H calls Was_Its_Execution_Aborted(H_Hat,H_Hat) Was_Its_Execution_Aborted emulates H_Hat(H_Hat) Was_Its_Execution_Aborted decides the emulated program .. .. will never terminate if not aborted Was_Its_Execution_Aborted stops emulating and returns ABORTED H halts, with EAX=0 [= *NOT_HALT* decision] And when H calls Aborted_Because_Non_Halting_Behavior_Detected [which is yet another name for the same function Was_Its_Execution_Aborted] for the calculation which YOU'VE AGREED actually halts, Aborted_Because_Non_Halting_Behavior_Detected() answers "aborted". This is an example of your function returning the wrong answer. Duh! You can try to dismiss by changing the names of functions making them longer and longer, and snipping out the traces in your reply, but you don't fool me! :) (Alternatively, you could actually try to explain why Aborted_Because_Non_Halting_Behavior_Detected () returned "aborted" for a terminating input calculation.) Mike. |
| olcott <NoOne@NoWhere.com>: Oct 24 03:41PM -0500 On 10/24/2020 2:44 PM, Mike Terry wrote: > Was_Its_Execution_Aborted stops emulating and returns ABORTED > H_Hat *halts* > OK, so the H_Hat calculation halts... In this case we have an outer instance of H_Hat() an inner instance of H_Hat(). The outer instance of H_Hat() is executed in the master UTM process context of x86utm. This outer instance of H_Hat() invokes Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) which creates the inner instance of H_Hat() in its own process context and executes it. It then returns true to the outer instance of H_Hat() after aborting the inner instance. > .. will never terminate if not aborted > Was_Its_Execution_Aborted stops emulating and returns ABORTED > H halts, with EAX=0 [= *NOT_HALT* decision] In this case we have an instance of H() and an instance of H_Hat(). The instance of H() is executed in the master UTM process context of x86utm. H() invokes Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) which creates the instance of H_Hat() and executes it. It then returns true to H() after aborting the instance of _H_Hat(). -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 24 03:48PM -0500 On 10/24/2020 2:54 PM, Alan Mackenzie wrote: > Even after following this thread, more or less, I can't see how that > question is essentially different from the proper halting problem > question. The difference is that the revised question cannot be contradicted to make the halting problem undecidable: Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) == true means that the input has infinite execution. Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) == false means that the input DOES NOT HAVE infinite execution. There is no input that the redefined halt decider cannot decide. Every input is divided into: (a) Has infinite execution. (b) DOES NOT HAVE infinite execution. -- Copyright 2020 Pete Olcott |
| Mike Terry <news.dead.person.stones@darjeeling.plus.com>: Oct 24 09:57PM +0100 On 24/10/2020 21:41, olcott wrote: > creates the inner instance of H_Hat() in its own process context and > executes it. It then returns true to the outer instance of H_Hat() after > aborting the inner instance. ..*and then terminates* The calculation H_Hat(H_Hat) halts. So if Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) says there was "non-halting behaviour" it was wrong. No point in saying this over and over.... > H() invokes Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) > which creates the instance of H_Hat() and executes it. It then returns > true to H() after aborting the instance of _H_Hat(). Again, returning true to H is supposed to say it detected non-halting behaviour, but the calculation it is examining actually halts. There, I said it again! :) (last time, really...) |
| olcott <NoOne@NoWhere.com>: Oct 24 04:05PM -0500 On 10/24/2020 3:57 PM, Mike Terry wrote: > Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) says there > was "non-halting behaviour" it was wrong. > No point in saying this over and over.... When-so-ever H_Hat(H_Hat) is executed and it is never aborted at any level of outer or inner invocations the H_Hat(H_Hat) never terminates. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 24 04:24PM -0500 On 10/24/2020 3:55 PM, Richard Damon wrote: > execution. > I run H_Hat(H_Hat), the function returns true, so H_Hat halts, and thus > H_Hat does NOT have infinite execution, contrary to what H said. You must be able to follow the key nuances that an outer instance of Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) that was invoked by the outer instance of H_Hat() has a longer execution trace thus more data than the inner instance of Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) that was invoked by the inner instance of H_Hat(). If you cannot follow this analysis because it is too complex or you simply don't believe in different instances then you can wait until I finish encoding it as fully executable code. When-so-ever H_Hat(H_Hat) is executed and it is never aborted at any level of outer or inner invocations then H_Hat(H_Hat) never terminates. > implement the machine H, is incapable of doing the job. Linz did you one > better, he showed that NO machine can do the job. > The question asked was, will the program stop. When-so-ever H_Hat(H_Hat) is executed and it is never aborted at any level of outer or inner invocations then H_Hat(H_Hat) never terminates. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 24 04:31PM -0500 On 10/24/2020 4:06 PM, Malcolm McLean wrote: > However in fact the proof is sound. The weakness is that it requires that > H be a Turing machine. It's not a proof that no halt decider is possible, > just that the halt decider is not a Turing machine. Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) == true means that the input has infinite execution. Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) == false means that the input DOES NOT HAVE infinite execution. All Input is divided into exactly one of these two sets: (a) The input Program/TM has infinite execution. (b) The input Program/TM DOES NOT HAVE infinite execution. There is no reason why a UTM halt decider could not be implemented so that it examines every state transition of its input UTM in the exact same way as described above. -- Copyright 2020 Pete Olcott |
| Mike Terry <news.dead.person.stones@darjeeling.plus.com>: Oct 24 10:44PM +0100 On 24/10/2020 22:05, olcott wrote: >> No point in saying this over and over.... > When-so-ever H_Hat(H_Hat) is executed and it is never aborted at any > level of outer or inner invocations the H_Hat(H_Hat) never terminates. Wrong. (Read the trace) |
| olcott <NoOne@NoWhere.com>: Oct 24 05:01PM -0500 On 10/24/2020 4:44 PM, Mike Terry wrote: >> When-so-ever H_Hat(H_Hat) is executed and it is never aborted at any >> level of outer or inner invocations the H_Hat(H_Hat) never terminates. > Wrong. (Read the trace) Your trace is based on false assumptions my trace is based on working code. Although I don't have the halt decider code completed yet because the x86utm operating system is completed I can see exactly how the halt deciding code would work. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 24 03:13PM -0500 x86utm was created to be a master UTM that can execute subordinate UTMs or TMs in DebugStep() mode. Here are some of its key operating system functions: u32* Allocate(u32 size); void SaveState(Registers* state); void LoadState(Registers* state); u32 DebugStep(Registers* master_state, Registers* slave_state); void PushBack(u32* S, u32 M); // similar to c++ The following code is based on the Linz H and Ĥ Turing Machine templates: http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf void H_Hat(u32 M) { if (Aborted_Because_Non_Halting_Behavior_Detected(M, M)) MOV_EAX_0 // Execution of M(N) has been aborted else { MOV_EAX_1 // M(N) has halted HERE: goto HERE; } HALT } void H(u32 M, u32 N) { if (Aborted_Because_Non_Halting_Behavior_Detected(M, N)) MOV_EAX_0 // Execution of M(N) has been aborted else MOV_EAX_1 // M(N) has halted HALT } int main() { u32 M = (u32)H_Hat; H(M, M); HALT; } The simplest possible way to define a halt decider is to have a UTM execute its program under test (PUT) until it detects non-halting behavior of its (PUT) or its (PUT) terminates on its own. When the UTM halt decider decides that its (PUT) would not otherwise halt it stops executing its (PUT) and reports that non halting behavior has been detected. If it does not detect non-halting behavior then it reports that its input program has terminated. This is exactly the same thing as the conventional NON_HALTING / HALTING return values of a conventional halt decider except that this definition of a halt decider cannot be fooled by any cheap trick. Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) == true means that the input has infinite execution. Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) == false means that the input DOES NOT HAVE infinite execution. There are no programs left over that can be shown to be undecidable. ALL INPUT IS DIVIDED INTO EXACTLY ONE OF THESE TWO SETS (a) The input Program/TM has infinite execution. (b) The input Program/TM DOES NOT HAVE infinite execution. -- Copyright 2020 Pete Olcott |
| Mike Terry <news.dead.person.stones@darjeeling.plus.com>: Oct 24 10:38PM +0100 On 24/10/2020 21:13, olcott wrote: > The simplest possible way to define a halt decider is to have a UTM > execute its program under test (PUT) until it detects non-halting > behavior of its (PUT) or its (PUT) terminates on its own. What happens if it detects no "non-halting behaviour" (loops or infinite recursion, or whatever) but its PUT does not terminate either? > This is exactly the same thing as the conventional NON_HALTING / HALTING > return values of a conventional halt decider except that this definition > of a halt decider cannot be fooled by any cheap trick. ..and yet YOUR code is "fooled" into saying it has detected non-halting behaviour for a calculation you agree actually halts. All covered in your previous thread. No point in repeating arguments here. Mike. |
| olcott <NoOne@NoWhere.com>: Oct 24 04:58PM -0500 On 10/24/2020 4:38 PM, Mike Terry wrote: >> behavior of its (PUT) or its (PUT) terminates on its own. > What happens if it detects no "non-halting behaviour" (loops or infinite > recursion, or whatever) but its PUT does not terminate either? First of all this is more aptly stated as fails to detect non-halting behavior. Yes any halt decide that is not infallibly all knowing will certainly miss some cases. Remember that the scope is not to solve the halting problem with a halt decider that is omniscient (all knowing). The scope is to show the conventional proofs do not prove that the halting problem is undecidable. >> of a halt decider cannot be fooled by any cheap trick. > ..and yet YOUR code is "fooled" into saying it has detected non-halting > behaviour for a calculation you agree actually halts. H_Hat(H_Hat) never ever halts unless and until it is aborted at some level of inner to outer invocation. Ignoring what I say does not count as any form or rebuttal what-so-ever. -- Copyright 2020 Pete Olcott |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 24 10:39PM +0100 If you are a bit racist, sexist or homophobic then please watch https://vimeo.com/331247247 to re-baseline. /Flibble -- ¬ |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 24 02:20PM -0400 On 10/24/20 12:48 PM, Rick C. Hodgin wrote: > https://github.com/RickCHodgin/Earth_Solar_System_OpenGL > I haven't pushed the source code yet. But, it will be up there sometime > soon (Lord willing, James 4:15). :-) Code is pushed. I can get it to compile on my machine, but I also have the other files there. If someone could pull this repository: https://github.com/RickCHodgin/Earth_Solar_System_OpenGL.git Open this Visual Studio solution. It's VS2008 you may have to upgrade if you don't have that version: \Earth_Solar_System_OpenGL\c++\03_earth_solar_system_open_gl\earth_solar_system_opengl.sln ----- Sorry for all the Earth Solar System Open GL levels. :-) Once you open it up once, it will be in your most recently used list. You'll never have to worry about it again. The code compiles and goes to these two folders: \Earth_Solar_System_OpenGL\c++\test_opengl\ \Earth_Solar_System_OpenGL\c++\test_opengl\x64\ There's where you can run the executables. They are self-contained except for the DLL dependencies. The graphics are compiled into the binary through the graphics\ folder .BAT files and raw 24-bit BMP files. I use that format because it doesn't have any OS dependencies for decompression, and it's lossless. Please report any troubles compiling or bugs. I'll get them fixed later on this afternoon. Have some stuff to do outside right now. -- Rick C. Hodgin |
| Bart <bc@freeuk.com>: Oct 24 09:08PM +0100 On 24/10/2020 17:25, Rick C. Hodgin wrote: > If you're daring, add an exception. If not, wait for the source code > and compile it in Visual Studio 2008 or later from the solution, or > probably almost any version of Visual Studio 2003 or later otherwise. I turned off AV and this time it stayed on-screen. But it didn't much. The keyboard controls all worked except '3'. Does it update each time there's a new frame? If so there should be an indication such as a frame counter, if the difference is too subtle to notice. Whatever it is that's making it slow, I don't think it's OpenGL. I also tried it with glut32.dll (also a free download from somewhere), renamed to freeglut.dll, and that was OK. (One technical note about glew.dll (is that yours?); it exports over 3000 names, but only 7 of those are functions. The rest are variables. I suspect a lot of variables either don't have 'static', or are shared across modules of this library, but are not intended as exports from the DLL.) |
| 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:
Post a Comment