Well, whaddayaknow...

Wiki pages · Post by **Thargoid** » Sat Sep 19, 2009 6:30 pm

Kaks wrote:
Oops, I just made a minor change to -verify-oxp in trunk: nothing internal, but now when it's finished it pops a dos terminal in windows saying "Verify complete. Please see 'Logs\oxpname.log',Press any key...". Once you press any key, it closes that popup.

It shouldn't interfere with your parser, though...

Umm, wouldn't it be more useful (and less annoying) to have it just open the log file directly instead?

JensAyton · Post by **JensAyton** » Sat Sep 19, 2009 8:44 pm

At the very least, it should respect the oxp-verifier-open-log preference (i.e., do nothing if oxp-verifier-open-log is false).

Chaky · Post by **Chaky** » Sat Sep 19, 2009 8:50 pm

I've allready covered that by waiting for log file to appear.

Also, there is a nice little thing in winbatch called RunWait (plus some parameters) that actually waits for app it started to stop. I still haven't tested that commandline window popping scenario Kaks mentioned...

Chaky · Post by **Chaky** » Sun Sep 20, 2009 11:58 am

Well, the OXP verification works like a charm.
Only problem I'm having is when a bad path is given. The script hangs while waiting for a log file that is not going to appear. Could someone tell me what it is exactly that Oolite exe is looking for in a OXP and what makes it decide that there is no OXP? I would like to apply the same exact criteria to my script to avoid trying-to-verify-bogus-OXPs scenario.

I admit, I expirianced those problems while finetuning the script, but nevertheless, it is possible to "force" the same scenario with a bug-free script (as it is now).

JensAyton · Post by **JensAyton** » Sun Sep 20, 2009 12:51 pm

It requires an absolute path or a ~-relative path (don’t know how this is handled on Windows) which points at a directory.

Chaky · Post by **Chaky** » Sun Sep 20, 2009 1:12 pm

The script is giving the path all right (absolute), but my point is that it is possible to manually selected path, and therefor wrong one (I'm talking about this script/tool I'm making).
I want to apply same criteria that Oolite applies before the Oolite's OXP vreifying feature is executed.

I mean, I can simply set it to scan the path by itself, but that does not guarantee (atleast, not to myself) that it won't eventually hang while waiting for the Oolite to produce a log. And there is no reliable way to prevent such scenario.

Actually, there is one that comes to my mind now, but it includes deletion of "Latest.log". The only "real" way IMO is to go Oolite way on filtering paths.

JensAyton · Post by **JensAyton** » Sun Sep 20, 2009 1:22 pm

I already told you how Oolite filters paths: it requires them to point at a directory. There is nothing else.

Chaky · Post by **Chaky** » Sun Sep 20, 2009 1:33 pm

Ahruman wrote:
I already told you how Oolite filters paths: it requires them to point at a directory. There is nothing else.

.. and my question is "What happens next?"

How does Oolite decide that it is not a valid path? I know that it does not rely on exe's root, because I've already made script to direct Oolite to check OXPs in completely different root directory (1.74 trunk checking OXPs in 1.73.3's AddOns folder and vice-versa.. I call that cross-checking)

Suma sumarum:
There is a particular decisive condition that turns Oolite away from proceeding with a check, and I would like to know what that is.

JensAyton · Post by **JensAyton** » Sun Sep 20, 2009 1:51 pm

Chaky wrote:
Suma sumarum:
There is a particular decisive condition that turns Oolite away from proceeding with a check, and I would like to know what that is.

Yes. If the given path does not point at a directory, Oolite decisively does not proceed with any checks. If it does point at a directory, it decisively proceeds. As far as the verifier is concerned, any directory is an OXP. It’s very decisive in this respect.

Chaky · Post by **Chaky** » Sun Sep 20, 2009 1:55 pm

Hmmm.. then there is no way to break the script if the script check for existence of folder just before it executes Oolite (and not with an axe

), unless somebody manages to deletes the folder in that split-second.

Cool.

And thanks for the confirmed info.

Post by **Kaks** » Sun Sep 20, 2009 6:16 pm

Thargoid wrote:
Umm, wouldn't it be more useful (and less annoying) to have it just open the log file directly instead?

Well, ok.
We can open it (if oxp-verifier-open-log is true) in wordpad - never in notepad, it's evil, which should be present in all standard windows installations.

Chaky · Post by **Chaky** » Sun Sep 20, 2009 6:19 pm

Please, please, PLEEEEEase, make an option to NOT open the log.

It will undermine what I'm doing now....

Wiki pages · Post by **Thargoid** » Sun Sep 20, 2009 6:32 pm

Both the above sound fine to me. I use wordpad to do my coding and log file checking anyway, and the flag I think defaults to false anyway (?).

There will almost certainly already be a command prompt open to run the verifier in the first place, so having yet another one pop up just for a message is going to get too much.

Chaky · Post by **Chaky** » Sun Sep 20, 2009 6:35 pm

Thargoid wrote:
Both the above sound fine to me. I use wordpad to do my coding and log file checking

One word: Notepad++

Post by **Kaks** » Mon Sep 21, 2009 1:20 am

Chaky wrote:
One word: Notepad++

Very fine choice, sir.

As far as the output of the oxp verifier goes: it'll open in wordpad, because

1) all (fresh) windows installations have got it.
2) it's not notepad.

By setting the option:

oxp-verifier-open-log = NO

inside the GNUstep/Defaults/.GNSstepdefaults file, wordpad won't be called, and oolite will terminate as quietly as possible, so it won't clash with what your program is trying to do.