Dannii's extension updates

Hey all, I’m pleased to announce some extension updates! They will eventually go up on the official Inform extensions website, but for now you can download them from Github: github.com/i7/extensions

Benchmarking has some minor updates. The extension is essentially the same, but the way tests are presented is slightly different. There is also a use option for when your test cases aren’t to be compared against each other, in which case they won’t be sorted.
Get it here: https://raw.github.com/i7/extensions/master/Dannii%20Willis/Benchmarking.i7x

If you use Flexible Windows by Jon Ingold you will definitely want this update - it improves performance by 30 times. You shouldn’t need to change your code, however it does make a slightly incompatible change: g-windows are now a kind of container. So be careful not to just repeat through all containers.
Get it here: https://raw.github.com/i7/extensions/master/Jon%20Ingold/Flexible%20Windows.i7x

Lastly I have a new extension, which I wrote for Counterfeit Monkey: Ultra Undo. Counterfeit Monkey has problems with interpreters like Gargoyle because it is too big for the undo function to work. Ultra Undo will keep undo working by using external files if needed. Counterfeit Monkey is the only story I’ve ever heard of with this problem, but if you find yourself writing something of the same size, you’ll want to give this extension a try.
Get it here: https://raw.github.com/i7/extensions/master/Dannii%20Willis/Ultra%20Undo.i7x

(There’s also an update for Simple Unit Tests, but only in the documentation: raw.github.com/i7/extensions/ma … 0Tests.i7x)

30 times? Dayammn!

  • Wade

There are unfortunately a lot of slow parts of Inform. If we’re lucky we can rewrite the code or work around it. If we’re unlucky we’ll need to wait until the Inform 7 source code is eventually made public.

I put your new Flex Windows in my Leadlight port. It compiled fine. In the Zoom IDE, it runs about the same as before, but I can’t really check for hyperacceleration in the compiled form in Gargoyle, where the game was already way fast. Maybe I could check the compiled version running in Zoom. But this game probably isn’t pushing Flex Windows very hard anyway.

  • Wade

How many windows do you have? For comparison Kerkerkruip has 20 windows, and with the old version it would sometimes take up to 6 seconds to open them all up. Now it’s barely noticeable.

Wade, the acceleration is solely in the opening and closing of windows, particularly in a situation where you have multiple g-windows open.

Good luck on that! It takes multi-years just for a new release to come out. I can’t imagine a full source release being any time soon. Nice extensions, though. The benchmarking one actually gave me some good insight into I6.

Graham has always said he wants to do it, but he wants to fix up the documentation first.

And thanks!

I think I’ve only got 3 windows :sunglasses:

  • Wade

These are up at the Inform 7 extensions website, along with some by other authors too.

I’ve written a new extension: xorshift. It replaces Inform’s random number generator with one that is consistent across all interpreters and computers. It probably won’t be useful for very many people, but we’ll be using it in Kerkerkruip.

Is xorshift compatible with Procedural Randomness?

I don’t think there’d be any reason for it not to be. Procedural Randomness doesn’t use Inform 6’s random() function, so it wouldn’t interact with xorshift at all.

Cool, thanks! So this could be combined with Procedural Randomness to set up something like generating a random universe from a keyword that would be the same across all interpreters and computers – or are you telling me that Procedural Randomness doesn’t need xorshift for that to happen?

I don’t think you’d need Procedural Randomness at all for that. Just calculate a number from your keyword (with some sort of hash function) or object (by casting it to an integer), then set the xorshift seed to that and use [purely at random] (or “a random X”).

Well the point wouldn’t be just to generate one consistently random number – you’d want to generate the number from your object, and then do something like add a longitude to that number and use that number as the seed so every time you went back to the same longitude you could psuedo-randomly generate the same stuff again (without needing to store what you’d generated, because you could just regenerate it). Procedural Randomness is designed for stuff like that – I think just reseeding xorshift to do that might require rebuilding a lot of the functionality of Procedural Randomness. Or maybe not.

Part of my question here is, does Procedural Randomness also behave consistently across interpreters and computers?

Interesting. I looked at the source code for Procedural Randomness and it seems to implement its own pseudo-random number generator. So yes, I expect it would behave consistently (although not between Z-Machine and Glulx, because of the word size difference).

Cool, thanks! And yes, it behaves differently between z-machine and Glulx (as I found out when I reported a difference in behavior between 6G60 and 6L02 which turned out to be because I left the defaults on, meaning I was compiling to z in 6G60 and Glulx in 6L02).

I think my extension might work better for that matt. Procedural Randomness’s strengths are with the say phrases - you set the seed every time you enter a room and then the random descriptions get pinned for that room. In your case it sounds like you just need a lot of random numbers. xorshift will be easier to use for that, and its random numbers will probably be of a higher quality. If you did want the same room specific stuff you could simply seed it with the room as well.

Interesting, thanks! I’ll look into it if I ever come up with any actual code to work with.