Oolite Windows - Trunk nightly builds

[JensAyton]

Um… unless you’ve done more testing than I have, I’m not sure that’s a good idea. There are still a bunch of API contract violations and almost certainly crashers. I’m not sure I’ll be prepared to stomp out fires for the rest of this week…

[another_commander]

Um… unless you’ve done more testing than I have, I’m not sure that’s a good idea. There are still a bunch of API contract violations and almost certainly crashers. I’m not sure I’ll be prepared to stomp out fires for the rest of this week…

You are right that crashers are expected, but maybe we can still get reports that could point us to possible problem spots that may have been missed. And I am sure that I have not done more testing (the only test I've run is the 41-suite you have written, actually). Anyway, if you consider it a bad idea, we still have time to flip the build switch to "Old JS" before the next nightly is run.

Edit: Nightly switched back to using JS 1.70 for now, as per Ahruman's suggestion above. New JS builds will wait for a little longer.

[Getafix]

I could set a separate windows nightly for SpiderMonkey testing if you like.
Would a separate branch in svn be necessary?

[Eric Walch]

Edit: Nightly switched back to using JS 1.70 for now, as per Ahruman's suggestion above. New JS builds will wait for a little longer.

I don't know if it matters much which JS is used now. Through the changes currently made also the old JS 1.70 crashes always because a lot of JS instructions cause crashes anyway.

e.g. with this mornings build and no other oxps

Code: Select all

this.v = new Vector3D(0,0,0) <---- craches Oolite
system.mainStation.launchShipWithRole("role") <-- crashes Oolite

And there must be lots more, so using it with oxp installed is guaranteed to hit a JS command that crashes Oolite. Than it is just as good to remove the crashes with the new JS.

[another_commander]

I could set a separate windows nightly for SpiderMonkey testing if you like.
Would a separate branch in svn be necessary?

I don't think a separate branch would be necessary. When we decide that we are OK to start JS testing, we can just flip the switch again.

[JensAyton]

Crashes with the new JS engine are expected. Crashes with the old JS engine are regressions that need to be fixed. Please report them.

My position is that we should switch to using the new JS engine for test release builds where supported (currently only Windows) starting next week, because there’s some sort of holiday thing this week.

[Switeck]

Is the Trunk nightly build for Feb 14th, 2011 "dead"?
I cannot access this webpage:
http://www.terrastorage.ath.cx/oolite/status_win32.html

[Getafix]

There was an issue with the DNS service, which is now fixed.
The nightly page will start being available while the DNS servers are informed with the IP information.
It would be good to clear the browser's cache though.

I can already reach the page from various IPs.

EDIT: You have to remove the "www" from the address!

[Switeck]

Has the nightly builds switched to an every-other-day buildrate?
Or other problems causing this?

[JensAyton]

Has the nightly builds switched to an every-other-day buildrate?
Or other problems causing this?

No, it’s more like an every-other-day doing-anything-to-the-code rate.

[Getafix]

The last date the nightly has run (for Windows and Linux) is indicated by the row:
Generated on <date>
If the build date is "stuck", it means that nothing (to be built) has changed since then.

[another_commander]

As of r4490, the Debug OXP (Basic-debug.oxp) is being distributed with the Windows port installer as an optional component. This way, users such as OXP developers who want to have the debug console functionality, can be certain that they have the correct version of the Debug OXP installed together with the game, instead of having to look for it on the Wiki or elsewhere and possibly risk downloading a version of the OXP that may not be suitable for the version of the game they are running.

The intention is to distribute the Debug OXP with the test releases and nightly builds (i.e. the Developer/Tester configurations of the game, which is what we currently have), but not include it in the final End-User configuration that will ship when the next stable goes gold.

Note that if you already have a Basic-debug.oxp folder in your AddOns, any files with the same filenames as those contained in the installer's Basic-debug.oxp will be overwritten.

[Zireael]

I thought Debug ran only on Macs?
BTW Oolite tries to connect to Internet. Is that 'cause of Debug.oxp or is it normal? Or did smth happen?

[JensAyton]

I thought Debug ran only on Macs?

The debug OXP works on all platforms, but it does more on Macs.

BTW Oolite tries to connect to Internet. Is that 'cause of Debug.oxp or is it normal? Or did smth happen?

When the debug OXP is installed, Oolite tries to open a TCP connection to the computer it’s running on in order to communicate with an external console application. (It can connect to other computers, but only if you edit debugConfig.plist.) If your security whatever is calling a loopback connection “connecting to the Internet”, I’d argue that it’s lying to you.

[another_commander]

The basic debug OXP, which enables communication with the external Debug Console (found here) is supported on all three platforms and it is fully recommeded that it be used if you are serious about OXP development.

Oolite is not trying to connect to the Internet, when you use the Debug OXP on Windows, it will try to connect to the loopback (127.0.0.1), at port 8563 because that is where it expects to locate the debug console, which should be already running for the connection to be established. This, in simple terms means that it is looking at port 8563 on the machine it's running on and you certainly do not need to be connected to the net to get it to work, nor does Oolite try to do something security related with your machine. All is normal.

Edit: Ninja'd by Ahruman.