Read again, this is not what I asked you to try in php. You miss the point entirely.

Please, take the time to ponder the difference between:
- Counting to ten.
- Counting forever.

I think the most common reason for an accidental infinite loop is just a situation where the exit condition can never be reached which can take multiple forms in multiple languages. Corrupting the prior example:That said, it is quite common to have a loop that continues until some process is completed (perhaps you are calculating the first prime with more then 10 digits...) your loop will proceed indefinitely until that is found... in many programs the exit conditions of these loops may require user input or information from another "thread"... so it would be possible for these loops to run forever if not interupted.

So, while it is true to say that you would never purposefully program an infinite loop, they are easy to make by accident and "indefinite loops" are quite common.

EDIT: I can recall having written 2 infinite loops on purpose. The first was to see what would happen if I just kept moving the pointer to new memory locations and zeroing the value there... the second was a "find the first prime with 10 digits" type problem where I figured it would execute faster if I let the program just spit out primes and then I could count the digits myself and then force quit the program when I saw a big enough number get spit out... but in both cases I intended for the program to stop executing eventually... I just didn't intend for that to happen due to something within my code.

NO!


This is the BOS code that caused Spring to hang:

Now, I want you to copy-paste and run this in PHP:

Do it. Now.

It is extremely important that it sinks in!

or just start at 999999999 \o/

The reason why cob/lua needs the sleep is because it must not be faster than the code of the engine, on which it runs. Spring is written in c which does not require silly sleeps in loops. even if the loop is to "infinite."
Example:
https://github.com/spring/spring/blob/develop/rts/Sim/Projectiles/ExplosionGenerator.cpp#L436

for (;;) basically means while (true) - infinite but scroll down, there is no sleep, only short breaks.
Because it is a typed language this allows c to run full throttle real runtime, all the time.
It is basically http://en.wikipedia.org/wiki/Double-clutching the processor.

That makes languages other than Lua so much faster and easier to optimize. For example in phython you can count to potato no problem and the consequences will never be the same as in Lua. (check it out)

I put an extra echo 'Hello World'; in the loop and tested it with http://writecodeonline.com/php/
It did not crash/hang which makes sense because php also has a c-style synthax.

Ok, I give up.

Z, What is your deal? I am well aware of the fact that an infinite loop is bad.

I am fully aware that you CAN create an infinite loop in any language that supports looping.

You obviously didn't pay any attention to the commit you linked to, if you had, you would have noticed that I removed an entire side of the factory. As such, I was removing large swaths of bos. Obviously, I just selected 1 line too many, as there are other places were the sleeps stayed perfectly fine.

It didn't cause a problem then, because the loop never got run! It wasn't until I got the bright Idea to add a tech requirement to the factory that that code finally got run!

Have you never overlooked something trivial that caused huge problems? If that code had been getting run, then when i removed that side of the factory, It would have started crashing and I would have known that something was fucked up. It was an easy thing to overlook, because the code in question never got run!

In the meantime, you've been going off the rockers for a reason I haven't quite figured out yet. You act as though I don't know that an infinite loop in bos is bad ... Well of course it's bad, it causes spring to asplode. I have caused an infinite loop before in bos, but that was back when infolog actually wrote instead of being held in memory and then summarily lost (what a silly thing to change), and considering that I had made a change, started spring, and tested it, I KNEW what went wrong right away. This problem here was caused on Feb 8, 2012. I never knew about it, because the code in question never got run!

(Are you sensing the pattern in my post?)

I was worried because your previous posts read like you thought it was a problem that can't happen in PHP. And also because you answered with a to-ten loop when asked about an infinite one.

Ahhh ok I see where you're coming from now. I was really confused because I didn't understand why you were (from my perspective), going on and on about something I already knew.

What I was trying to point out was that it is a bit more difficult to create an infinite loop in php because one of the basic parameters is specifying when it starts and stops. In bos, that is defined within the loop, which is a little strange imo (not the least of which, the fact that the sleep can be accidentallied). Without the second parameter of a loop in php the loop will completely fail, whereas without the sleep in bos, it becomes infinite. This seems inefficient to me.

I was only trying to illustrate that it was much more difficult to majorly screw it up in php.

Moreover, php and servers generally have protections in place to protect vs infinite loops without causing the entire script to die a painful death.

This in stark contrast to one missing sleep bringing spring to it's knees. Quite radically different.

As shitty as scriptor is, if lua had a parser that told you where the fuckups were, that would be really neat. I do not consider spring to be a good debugger. Like swatting flies with an elephant stampede. Course, I'm sure everyone disagrees with that for one reason or another. For me, I would like a parser just so i can know if the code will run. If I want to see the result I would load up spring.

As a friend of mine says, Wish in one hand and Shit in the other, see which one fills up faster

Both "for" and "while" exist in both in BOS and PHP.

I wanted you to try while(1){} in PHP so that you'd see PHP debugging wouldn't be better for such bug.

It's automatically better if you have just written the code and it screws up. It's much harder to diagnose when everything has been fine and all of a sudden, several months later, it starts causing issues.

and this is why you cannot divide by zero...

Should be possible to report divisions by zero without causing the entire application to lolsplode.

No, because whatever value you were computing that caused div0 will be garbage at that point, and so the app can as well be killed now (no sence processing undefined value any longer).

Some databases return a NULL after div0 instead of crashing, which can actually be worse if you don't check for it :)

Most of the time you can catch div0 with exception handling or with checks for 0 before doing division, and process the situation yourself without crash.