Ideas for future versions

[IS4Code]

There are still some ideas that I have that could be added in the future versions, or just would be interesting to explore.

[IS4Code]

• The ability to create fibers/coroutines or switch contexts even across native boundaries (i.e. public calls). For example using the k<…> specifier in sscanf, which calls a public function to handle the string, could be "paused" by async calls inside the public function (instead of returning the argument of task_set_yielded). This should be safe for reentrant native functions.

[IS4Code]

• Context and site-specific custom data. Basically each context (something created in an external public call) or site (a location in code of a specific instance of AMX machine) could be associated with a custom data object.

[IS4Code]

• Owning containers. Currently all containers are non-owning, i.e. adding or removing elements does not attempt to acquire or release resources, unless told explicitly (the *_deep functions). All containers should be configurable to automatically guard their own data (all objects or just GC-objects), plus a set of *_shallow functions and extraction functions for non-GC-objects.

[IS4Code]

• Unifying the arguments of task_bind and pawn_call_*. Preferably all occurences of a function call format string (specifier list) should be consistent and use the same symbols.

[IS4Code]

• Move threads to a different plugin or make them compile-time optional. The presence of threading code makes std::shared_ptr objects use mutexes for synchronization, but considering all mutable objects are not thread-safe anyway, this does not bring any value and just impairs performance.

[IS4Code]

• A "multistring" object, i.e. a collection of strings, intended to be conveying the same "meaning" but in different "forms". Examples include producing a localized message for each supported language, a message with different colors schemes, a message with optional player ids or timestamps, but only selecting one such message when displaying to a player. A lot of the "actions" performed on a multistring object would be lazily evaluated and performed only when it is actually needed (with the result stored in the multistring object in case it is needed for other players). This could be coupled with expressions, formatting and regular expressions, and made into a really powerful system.

[IS4Code]

• Encoding conversions and locale-specific information. With the exception of global pp_locale, there are not many cases where locale objects are used, but being able to use them without side effects just to perform charset conversions or extract culture-specific information (formatting conventions etc.) would be useful in a multi-language server.

This and more implemented in 1.5!

[IS4Code]

• Date and time functions. There is just a pp_daytime function at the moment, but many more are needed to make a proper time module (working with timestamps, time zones, finding the day of week etc.) I suppose these features are already covered by other plugins, and there is not much opportunity of interaction between them and other PawnPlus features.

[IS4Code]

• Process information and diagnostics, available memory etc. This is something that has to be done by parsing text files on Linux, and again I suppose there are existing plugins that cover this area sufficiently, so I don't feel much like doing it anytime soon.

[DobbysGamertag]

There's existing plugins that tell you the available system memory etc? Where? I'd love to know this. That seems like a really useful thing to have.

[IS4Code]

I don't know actually; I just assumed there has to be some plugin that offers these features. 😀

[DobbysGamertag]

To be honest, that's one of the things I've always felt should've been in SA:MP by default:

• The ability to see the remaining memory of the server.
• Basic diagnostics (uptime, OS errors/warnings). List of processes open.
• Crash detect, but built into the server.

[IS4Code]

• String and variant "views". At the moment, strings and variants manage their own memory, but there is a possibility of making some of them point into the AMX memory instead and use them in natives that don't require a specific location in memory (regular expressions for example). It is to be decided whether this would mean a separate StringView: tag or just a "hack" that would make it possible to produce a fake String: value from an address.

[IS4Code]

• A rundll-style function that would look for a function address in a dynamically-linked module and call it. Perhaps a specific memory-hacking plugin would be better for this, as this is kinda dangerous.

[spacemud]

A way to debug containers and their data would be helpful. At the moment I'd writing my own debug functions that manually print out the keys and values of a map container.

[IS4Code]

• A method to preserve the state of the AMX machine between "sessions" and a way to swap in an updated version of the script to create a new session. Two options are here:

  • A simple solution would be just to have two callbacks, one to save and serialize the state, one to deserialize and load it back. Whatever consistutes "user-data" would be marked so by the programmer.
  • A more complicated solution (possibly building off the first one) would be to be able to automatically store all the global variables (in the static data section) and verify that the new script is "compatible" with the old one to an extent. This is something that might be useful even without the script swapping as means of creating a debuggable dump of the script's memory (i.e. Map:amx_save_state() and amx_load_state(Map:)). The debug info could be used to build the dump.

  Thanks to tasks and asynchronous code however, there could be contexts waiting to be resumed between the two sessions. Again the option is either to kill to all the contexts (but risk that paused code somewhere would not be resumed), or to go through every context and relocate every address to point to the guessed location in the new version of the script, based on the addresses of various "checkpoints" throughout the code. Again there could be similar functions to those for saving the state that do this.

[IS4Code]

• Incorporating the Boehm garbage collector. This could be run in full GC mode, scanning memory and marking unreachable objects, or just in memory leak detection mode.