nPawn - обновление Pawn до самой новой версии

[Desulaid]

В SA-MP из коробки используется Pawn версии 3.2.*, которая является очень устаревшей: в ней не только нет нового функционала, но и нет необходимых исправлений, некоторые из которых могут крашнуть сервер (valstr или работа с запакованными строками, к примеру). Данный плагин обновляет Pawn до последней версии из официального репозитория CompuPhase (https://github.com/compuphase/pawn) (последнее изменение 21 час назад на момент создания темы). Совместим со всеми версиями SA-MP (с CR-MP тоже).

Известные баги:
- Возможно использовать только мод, скрипты (filterscripts) использовать нельзя. Это сделано для поддержки всех версий SA-MP, а также для сохранения производительности
- Возможна некорректная работа с некоторыми плагинами

Небольшой обзор некоторых новых возможностей:

new msg[.text{30}, .priority];
msg.priority = 10;
strpack(msg.text, "update: {30} means [30 char]");
print(msg.text);


Пример из file.inc:
const filemode:
{
io_read = 0, /* file must exist */
io_write, /* creates a new file */
io_readwrite, /* opens an existing file, or creates a new file */
io_append, /* appends to file (write-only) */
}


INI:
native readcfg(const filename[]=``'', const section[]=``'', const key[], value[], size=sizeof value, const defvalue[]=``'', bool:pack=true);
native readcfgvalue(const filename[]=``'', const section[]=``'', const key[], defvalue=0);
native bool: writecfg(const filename[]=``'', const section[]=``'', const key[], const value[]);
native bool: writecfgvalue(const filename[]=``'', const section[]=``'', const key[], value);
native bool: deletecfg(const filename[]=``'', const section[]=``'', const key[]=``'');

Новые функции file.inc:
native bool: fcopy(const source[], const target[]);
native bool: frename(const oldname[], const newname[]);
native bool: fcreatedir(const name[]);
native bool: fstat(name[], &size = 0, ×tamp = 0, &mode = 0, &inode = 0);
native bool: fattrib(const name[], timestamp=0, attrib=0x0f);
native filecrc(const name[]);


И многое другое, некоторые изменения есть здесь: http://www.compuphase.com/pawn/pawnhistory.htm, также рекомендую посмотреть стандартные примеры https://github.com/g3o0or/npawn-samp/tree/master/lib/pawn/examples и поковыряться в обновленных инклудах.

Изменения в API, не связанные напрямую с обновлением Pawn:
1. Все строки в аргументах кэллбеков запакованы
2. Запакованные строки можно использовать со всеми функциями SA-MP
3. Для функций вроде GetPlayerName (т. е. для тех, которые записывают строку в аргумент) добавлен последний аргумент bool:ispacked. По умолчанию он равен true.
4. В SA-MP использовалась функция format, взятая из AMXMODX. Она заменена функцией strformat, вся разница в том, что она работает с запакованными строками и добавлен третий аргумент ispacked.
5. Добавлен инклуд a_vec.inc (по умолчанию включен в a_samp.inc), который включает в себя некоторые (будут добавляться) функции, использующие одну переменную Vector3, а не три float, у них добавлен суффикс Vec. Vector3 является структурой с полями Float:x, Float:y и Float:z. Пример:


new pos[Vector3];
GetPlayerPosVec(playerid, pos);
pos.z += 20.0;
SetPlayerPosVec(playerid, pos);


Примеры использования новых фич:
http://image.prntscr.com/image/b819c850a9f649a2979d5b2070c1858a.png

Автор: g3o0or

Исходный код: https://github.com/g3o0or/npawn-samp
Бинарники: https://github.com/g3o0or/npawn-samp/releases
Инклуды, которые необходимо заменить: https://github.com/g3o0or/npawn-samp/tree/master/resources/include

[$continue$]

С векторами прикольно, но это все:

http://img0.reactor.cc/pics/comment/%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BA%D0%BE%D1%81%D1%82%D1%8B%D0%BB%D1%8C-%D0%B1%D0%B0%D0%B3%D0%B8-%D0%B2%D0%B5%D0%BB%D0%BE%D1%81%D0%B8%D0%BF%D0%B5%D0%B4-1827848.jpeg

[ziggi]

С векторами прикольно, но это все:

http://img0.reactor.cc/pics/comment/%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BA%D0%BE%D1%81%D1%82%D1%8B%D0%BB%D1%8C-%D0%B1%D0%B0%D0%B3%D0%B8-%D0%B2%D0%B5%D0%BB%D0%BE%D1%81%D0%B8%D0%BF%D0%B5%D0%B4-1827848.jpeg


Да не костыли совсем, с этим плагином даже производительность не теряется, так что можно спокойно использовать.

Кстати, копирование библиотек лучше заменить на использование git submodule, будет удобнее обновлять.

[Daniel_Cortez]

Да не костыли совсем, с этим плагином даже производительность не теряется, так что можно спокойно использовать.
Производительность заметно теряется в функциях SA-MP, работающих только с неупакованными строками, не говоря уже о дополнительных требованиях к объёму секции стека/кучи для временного размещения распакованных строк.
К тому же, там ещё есть, что улучшить. Под вендой можно использовать альтернативную ассемблерную реализацию amx_Exec (с последними версиями MASM она не очень дружит, но можно взять версию для NASM), а под пингвином - ещё одно альтернативное ядро, использующее фичи GNU C++. В обеих альтернативных реализациях можно добиться ~2x прироста производительности за счёт использования таблицы переходов вместо switch.

[g3or]

Производительность заметно теряется в функциях SA-MP, работающих только с неупакованными строками, не говоря уже о дополнительных требованиях к объёму секции стека/кучи для временного размещения распакованных строк..
Речь идет о восьми функциях, которые очень редко используются (чаще всего - один раз в OnPlayerConnect), но большинство из этих функций, как правило, не используются вовсе. И, если бы Kalcor использовал amx_SetString, этого можно бы было избежать.

upd: производительность этих функций улучшена, при использовании распакованных строк разницы нет
http://image.prntscr.com/image/a9884c70d6af49d8b46094baac4f3279.png



К тому же, там ещё есть, что улучшить. Под вендой можно использовать альтернативную ассемблерную реализацию amx_Exec (с последними версиями MASM она не очень дружит, но можно взять версию для NASM), а под пингвином - ещё одно альтернативное ядро, использующее фичи GNU C++. В обеих альтернативных реализациях можно добиться ~2x прироста производительности за счёт использования таблицы переходов вместо switch.
Да, вчера я хотел для линуксовой версии использовать оптимизации для GCC и Intel Compiler, но оказался занят другим.


С векторами прикольно, но это все:

http://img0.reactor.cc/pics/comment/%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BA%D0%BE%D1%81%D1%82%D1%8B%D0%BB%D1%8C-%D0%B1%D0%B0%D0%B3%D0%B8-%D0%B2%D0%B5%D0%BB%D0%BE%D1%81%D0%B8%D0%BF%D0%B5%D0%B4-1827848.jpeg

В чем костыльность заключается? В том, что ты совсем ничего опять не осилил?

[$continue$]

О, неадекватные люди подлетели =)
В том, что обновление языка с помощью плагина. Чем не костыль?

Речь идет о восьми функциях, которые очень редко используются (чаще всего - один раз в OnPlayerConnect), но большинство из этих функций, как правило, не используются вовсе. И, если бы Kalcor использовал amx_SetString, этого можно бы было избежать.
http://image.prntscr.com/image/a9884c70d6af49d8b46094baac4f3279.png



Да, вчера я хотел для линуксовой версии использовать оптимизации для GCC и Intel Compiler, но оказался занят другим.


В чем костыльность заключается? В том, что ты совсем ничего опять не осилил?

[g3or]

О, неадекватные люди подлетели =)
В том, что обновление языка с помощью плагина. Чем не костыль?

Если для тебя любой плагин - костыль, то ок. Даже добавлять ничего не буду. Нормальных аргументов ожидаемо нет.

[Daniel_Cortez]

производительность этих функций улучшена, при использовании распакованных строк разницы нет
Делать вызов функции amx_Swap32 ради каждой ячейки - тоже далеко не самый оптимальный вариант.
Попробуй вот это:


inline static void AlignCell(cell &value)
{
(void)value;
#if BYTE_ORDER==LITTLE_ENDIAN
const size_t cellsize = sizeof(cell);
unsigned char *bytes = (unsigned char *)(size_t)(&value);
unsigned char t;
#if PAWN_CELL_SIZE >= 16
t = bytes[0], bytes[0] = bytes[cellsize - 1], bytes[cellsize - 1] = t;
#if PAWN_CELL_SIZE >= 32
t = bytes[1], bytes[1] = bytes[cellsize - 2], bytes[cellsize - 2] = t;
#if PAWN_CELL_SIZE == 64
t = bytes[2], bytes[2] = bytes[cellsize - 3], bytes[cellsize - 3] = t;
t = bytes[3], bytes[3] = bytes[cellsize - 4], bytes[cellsize - 4] = t;
#endif // PAWN_CELL_SIZE == 64
#endif // PAWN_CELL_SIZE == 32
#endif // PAWN_CELL_SIZE == 16
#endif // BYTE_ORDER==LITTLE_ENDIAN
}

Я сделал эту функцию специально для работы с массивами из байтов в одном из своих проектов.
На первый взгляд оверкилл, но компилятор делает из неё всего 6-8 инструкций lea/mov (которые ещё и хорошо распараллеливаются) прямо на месте использования.


Касаемо лицензии в исходниках (GPLv3), она на инклуды тоже распространяется? Если да, то не слишком ли это? Возможно, стоило бы лицензировать их под условиями, не обязывающими раскрывать исходники мода (например, MPL, MIT или Zlib License)?

[g3or]

Касаемо лицензии в исходниках (GPLv3), она на инклуды тоже распространяется? Если да, то не слишком ли это? Возможно, стоило бы лицензировать их под условиями, не обязывающими раскрывать исходники мода (например, MPL, MIT или Zlib License)?
Нет, лицензия распространяется лишь на исходный код плагина (т. е. содержимое /src).


Попробуй вот это
Спасибо, попробую.

[123]

Если уж на то пошло, то тогда почему бы не использовать язык PHP? - http://pro-pawn.ru/showthread.php?3032-PHP-for-SA-MP
Думаю, что не для кого не секрет, что в PHP гораздо больше возможностей и встроенных функций, что делает его гораздо удобнее того же Pawn, хоть и самой новой версии. Жалко конечно, что разработчик бросил проект. Думаю, обновление до PHP 7 добавила бы ему производительности.

[g3or]

Если уж на то пошло, то тогда почему бы не использовать язык PHP? - http://pro-pawn.ru/showthread.php?3032-PHP-for-SA-MP
Думаю, что не для кого не секрет, что в PHP гораздо больше возможностей и встроенных функций, что делает его гораздо удобнее того же Pawn, хоть и самой новой версии. Жалко конечно, что разработчик бросил проект. Думаю, обновление до PHP 7 добавила бы ему производительности.
Даже если PHP 7 быстрее Pawn, оно медленнее из-за принципа работы, да и совместимости с плагинами/новыми версиями SA-MP там нет. И да, как это относится к теме?

[Seregamil]

Если уж на то пошло, то тогда почему бы не использовать язык PHP? - http://pro-pawn.ru/showthread.php?3032-PHP-for-SA-MP
Думаю, что не для кого не секрет, что в PHP гораздо больше возможностей и встроенных функций, что делает его гораздо удобнее того же Pawn, хоть и самой новой версии. Жалко конечно, что разработчик бросил проект. Думаю, обновление до PHP 7 добавила бы ему производительности.
Потому что это бред. В пхп больше возможностей, но они не раскроются в сампе.
Это как поставить в бмв двигатель от запорожца. С виду красиво, но медленно....

[123]

Потому что это бред. В пхп больше возможностей, но они не раскроются в сампе.
Это как поставить в бмв двигатель от запорожца. С виду красиво, но медленно....

Более неудачного примера, наверно, сложно придумать. Повышение производительности, конечно, ждать не стоит, но и негативного эффекта не будет. При использование PHP отпадает необходимости использовать дополнительные плагины, типа MySQL, RegEx, и сотни других, делает код более простым и приятным - этого более чем достаточно.

Да и вел к тому, что если и обновлять Pawno подобным образом, ради каких-то исправлений, то лучше сделать выбор в пользу более современных и функциональных языков программирования. Да и мало кому пригодится Pawno где-то еще, когда как PHP - пригодится везде.

[TheMallard]

Pawno, да, уже много лет не обновляется, но Pawn (http://github.com/compuphase/pawn) еще жив и даже баги исправляются!

[ziggi]

Все ссылки мёртвые, проекта в GitHub'е не нашёл.

[Daniel_Cortez]

Все ссылки мёртвые, проекта в GitHub'е не нашёл.
Вряд ли можно считать это невосполнимой потерей. В компиляторе от Zeex'а сейчас куда больше полезных фич, чем в Pawn 4.0 в сравнении с 3.2 (не говоря уже о степени адекватности некоторых "новшеств" в 4.0).



Pawn (http://github.com/compuphase/pawn) еще жив и даже баги исправляются!
Пациент скорее мёртв, чем жив; баги исправляются очень медленно.
Взять, к примеру, захардкоженный вызов файла с расширением ".exe" (https://github.com/compuphase/pawn/commit/989541257f381b72371e945c3ba9c0cd26fbf674#diff-0b8ef0f902db20e5564c99f5c609a831R641) из компилятора, из-за которого сам компилятор можно было собрать только под Windows. Мало того, что непонятно, как такое можно было пропустить в релиз (а это был именно релиз (https://www.compuphase.com/pawn/pawnhistory.htm), версия 4.0.5588), так ещё и исправлено это было только спустя 8 месяцев с момента появления бага, хотя нужно было всего-то добавить пару директив #if и #endif вокруг платформо-специфичного кода.

Либо вот ещё: в прошлом году я сообщил автору Pawn об уязвимостях в обработчиках нескольких опкодов AMX в функции amx_Exec(), затем открыл PR (https://github.com/compuphase/pawn/pull/27) с их исправлением. Прошло больше года - ни единого ответа от владельца репозитория, даже простого объяснения, почему этот PR не может быть принят.

А говорит это всё об одном: у автора Pawn попросту нет либо времени, либо желания (либо и того, и другого) работать над своим ЯП и скоро проект будет полностью заброшен. Собственно, даже тот PR по ссылке выше я уже закрыл, удалив ветку с исправлением, потому что это просто пустая трата времени.