Почему не улучшается язык Pawn?

[Scander]

Привет.
Задался вопросом: как бы создавать мод в ООП стиле, чтоб вот прям был класс игрока, его поля и методы, а потом создавать его экземпляры и т. д., а не хранить все в массиве и в отдельных функциях.
Потом понял, что в Pawn даже сраных структур нет и это невозможно.

Почему нельзя добавить новые возможности в язык? Ведь я видел кто-то там из наших САМПовских ребят исправляет ошибки и баги компилятора. Так почему бы не добавить новый функционал? Или это как-то связано с тем, что надо согласовывать с авторами этого языка?

[DeimoS]

Потому что это не так просто сделать и этим занимается полтора человека из всего комьюнити? Или потому что те, кто сейчас держат github модифицированного компилятора, довольно редко им занимаются, а так же все идеи тщательно отфильтровываются, дабы сильно не ломать совместимость со старыми скриптами (которые, в том числе, могут работать на багах компилятора)?

[Scander]

Потому что это не так просто сделать и этим занимается полтора человека из всего комьюнити? Или потому что те, кто сейчас держат github модифицированного компилятора, довольно редко им занимаются, а так же все идеи тщательно отфильтровываются, дабы сильно не ломать совместимость со старыми скриптами (которые, в том числе, могут работать на багах компилятора)?

Аа, вот оно что.
Просто блуждая по форумам по Pawn, у меня создалось впечатление, что у этого языка много поклонников. Видимо, я ошибался.
Ну совместимость можно и не трогать, просто хотя бы структуры добавить или базовый функционал классов.

[execution]

Точно такой же вопрос можно задать разрабам C.
Наверное это неактуально для данного языка

[Daniel_Cortez]

Задался вопросом: как бы создавать мод в ООП стиле, чтоб вот прям был класс игрока, его поля и методы, а потом создавать его экземпляры и т. д., а не хранить все в массиве и в отдельных функциях.

Никак. В Pawn вся память резервируется статически при загрузке скрипта. Лучшее, что можно сделать - это "красть" память из сегмента стека/кучи, злоупотребляя одним из багов ВМ (стек и куча используют один сегмент памяти, с той лишь разницей, что стек "растёт" с конца сегмента, а куча - с начала; по умолчанию этот сегмент ограничен размером в 16 Кб, т.е. 4096 ячеек - при слишком большом выделении можно словить "столкновение" стека и кучи), либо сделать "имитацию" на основе глобального массива в несколько тысяч или даже миллионов ячеек, из которого и резервировать память. К слову, оба подхода уже используются в y_malloc из YSI.

Почему нельзя добавить новые возможности в язык? Ведь я видел кто-то там из наших САМПовских ребят исправляет ошибки и баги компилятора. Так почему бы не добавить новый функционал? Или это как-то связано с тем, что надо согласовывать с авторами этого языка?

Во-первых, я планирую по очереди реализовать сначала структуры, а затем и хоть какое-то подобие методов, но на их согласование и реализацию уйдёт время.
Во-вторых, сейчас в очереди и без этого достаточно изменений, которые ожидают рассмотрения и принятия. Сколько будет мариноваться очередная порция изменений - вопрос не ко мне, но последняя куча изменений копилась полгода (с середины ноября и по начало мая). Впрочем, следует понимать, что рассматривает предлагаемые в компилятор изменения всего лишь один человек, и ему же приходится тянуть на себе разработку open.mp, YSI и модифицированных инклудов SA-MP.
В-третьих, в данном контексте само по себе понятие "авторы языка" некорректно, ибо речь о неофициальном ответвлении (форке) от языка Pawn версии 3.2. И даже если в нём исправлено больше багов и добавлено больше функционала, чем в официальном Pawn 4.0, это всё равно всего лишь неофициальное ответвление, которое автором Pawn не контролируется. У форка есть лишь сопровождающие (собственно, те, кто занимается развитием форка и приёмом изменений друг от друга и от других пользователей), и из них, как я уже упомянул, активным остаётся только один человек.

[Pa4enka]

Так же стоит добавить, что павн позиционирует себя как простой язык с которого можно начать свой путь в мир айти. С этой задачей он справляется прекрасно. Зачем усложнять? Хотите писать моды на С++ или Java? Используйте SDK. В чем проблема?

Что касается большого комьюнити и столь слабое развития языка. Не все знакомы с принципами работы компилятора и имеют хорошие познания в Си. При всем уважении, не наберётся и 1% таких людей от всего комьюнити.

[tnc]

Раз пошла такая пьянка, то все же изменения которые вносятся в компилятор на данный момент, то это диагностики. Да, они нужны, но так же нужны и другие фичи. К сожалению из-за основного направления я не могу найти время разобраться в коде компилятора. Но есть как минимум две просьбы к @Daniel_Cortez:

• Пофиксить тот баг с файлами (когда кодировка не совпадает в препроцессорах) и/или добавить диагностику на счет этого.
• Добавить больше измерений в массивах.
• Добавить прогрессивную иницилизацию для многомерных массивов (я уже как-то писал и там были "лайки". так что это нужна фича коммьюнити)

P.S: Я понимаю что ты убиваешь собственное время и в приоритете свои фичи, но думаю что иногда можно прислушаться с коммьюнити :)

[Scander]

Никак. В Pawn вся память резервируется статически при загрузке скрипта. Лучшее, что можно сделать - это "красть" память из сегмента стека/кучи, злоупотребляя одним из багов ВМ (стек и куча используют один сегмент памяти, с той лишь разницей, что стек "растёт" с конца сегмента, а куча - с начала; по умолчанию этот сегмент ограничен размером в 16 Кб, т.е. 4096 ячеек - при слишком большом выделении можно словить "столкновение" стека и кучи), либо сделать "имитацию" на основе глобального массива в несколько тысяч или даже миллионов ячеек, из которого и резервировать память. К слову, оба подхода уже используются в y_malloc из YSI.


Во-первых, я планирую по очереди реализовать сначала структуры, а затем и хоть какое-то подобие методов, но на их согласование и реализацию уйдёт время.
Во-вторых, сейчас в очереди и без этого достаточно изменений, которые ожидают рассмотрения и принятия. Сколько будет мариноваться очередная порция изменений - вопрос не ко мне, но последняя куча изменений копилась полгода (с середины ноября и по начало мая). Впрочем, следует понимать, что рассматривает предлагаемые в компилятор изменения всего лишь один человек, и ему же приходится тянуть на себе разработку open.mp, YSI и модифицированных инклудов SA-MP.
В-третьих, в данном контексте само по себе понятие "авторы языка" некорректно, ибо речь о неофициальном ответвлении (форке) от языка Pawn версии 3.2. И даже если в нём исправлено больше багов и добавлено больше функционала, чем в официальном Pawn 4.0, это всё равно всего лишь неофициальное ответвление, которое автором Pawn не контролируется. У форка есть лишь сопровождающие (собственно, те, кто занимается развитием форка и приёмом изменений друг от друга и от других пользователей), и из них, как я уже упомянул, активным остаётся только один человек.

Круто, буду ждать с нетерпением!

[Daniel_Cortez]

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

Не только диагностики. Из самого значимого, что будет в следующем релизе:

• switch-выражения (PR ещё не принят, но согласован с Y_Less'ом и финализирован, ожидает следующего рассмотрения);
  
• операторы __static_assert и __static_check;
  
• оператор __pragma (аналог директивы #pragma, который можно использовать в макросах);

Однако, я намеренно не добавляю этот функционал в свои "неофициальные" релизы, чтобы избежать случаев, когда пользователи преждевременно подстраивают свои скрипты к новым возможностям компилятора.
Например, если нужно использовать в макросе новый функционал __pragma, но при этом сохранить совместимость со старыми версиями компилятора, то в следующей версии (3.10.11) это можно будет сделать так:

#if __Pawn >= 0x030A && defined __PawnBuild    #if __PawnBuild >= 11        #define _MAYBE_UNUSED_ __pragma("unused")    #endif#endif#if !defined _MAYBE_UNUSED_    #define _MAYBE_UNUSED_#endif// ...new _MAYBE_UNUSED_ x; // компилятор не будет жаловаться, что переменная не используется

Однако мои билды распознаются как текущая версия (3.10.10), поэтому если я добавлю туда что-то из нового функционала, пользователи начнут адаптировать под него скрипты так, как будто он появился в текущей версии, а не в следующей:

#if __Pawn >= 0x030A && defined __PawnBuild    #if __PawnBuild >= 10        #define _MAYBE_UNUSED_ __pragma("unused")    #endif#endif

Такая фрагментация среди сообщества недопустима и я не хотел бы вносить в неё вклад. Именно поэтому я специально не включаю новый функционал в свои билды, а добавляю только самое необходимое: багфиксы и новые диагностики.
В принципе про диагностики тоже можно заявить, что они нарушают совместимость, но на самом деле с ними всё проще: для их отключения не обязательно полагаться на конкретную версию компилятора, достаточно лишь проверить объявление __PawnBuild (появилось в релизе 3.10.1, вышедшем 4 года назад), чтобы убедиться, что это не слишком старая версия компилятора и мы можем использовать #pragma warning:

#if __Pawn >= 0x30A && defined __PawnBuild    #pragma warning disable 249#endif

Если в компиляторе есть 249-я диагностика, она будет отключена, если нет - строка с #pragma будет проигнорирована.

Пофиксить тот баг с файлами (когда кодировка не совпадает в препроцессорах) и/или добавить диагностику на счет этого.

По-моему, я уже как-то говорил на этом форуме, что это не просто баг, а недоработка в коде чтения/препроцессирования исходных файлов. Изменения в столь фундаментальном механизме могут отразиться на совместимости с некоторыми скриптами/инклудами, или же замедлить компиляцию.

Добавить больше измерений в массивах.

Уже поддерживается до четырёх измерений. Если есть какие-то реалистичные примеры, в которых может понадобиться 5 или более измерений - я готов выслушать их и при необходимости запросить у сопровождающих компилятора, чтобы увеличили лимит.

Добавить прогрессивную иницилизацию для многомерных массивов (я уже как-то писал и там были "лайки". так что это нужна фича коммьюнити)

Тоже уже говорил об этом раньше, что в последний раз, когда смотрел на код инициализации массивов, ничего из этого спагетти толком разобрать не смог.

P.S: Я понимаю что ты убиваешь собственное время и в приоритете свои фичи, но думаю что иногда можно прислушаться с коммьюнити :)

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

[tnc]

По-моему, я уже как-то говорил на этом форуме, что это не просто баг, а недоработка в коде чтения/препроцессирования исходных файлов. Изменения в столь фундаментальном механизме могут отразиться на совместимости с некоторыми скриптами/инклудами, или же замедлить компиляцию.

Ок. Банальная диагностика и ошибка (?), чтобы люди не тратили много времени, которые не знают об этом.

Уже поддерживается до четырёх измерений. Если есть какие-то реалистичные примеры, в которых может понадобиться 5 или более измерений - я готов выслушать их и при необходимости запросить у сопровождающих компилятора, чтобы увеличили лимит.

Из последних моих систем, которые требовали бы больше измерений то это казино. Если нужно, то могу более подробней рассказать, но это не первый случай, когда не хватает 4 измерении. Чем чревато добавления ключа в компилятор (если такое вообще возможно, не знаю внутренних механизмов массивов), чтобы можно было отрегулировать максимальное значение измерений в массивах? Можно сделать запрет, допустим до 6. Я думаю, что 6 уже будет достаточно. Ибо лучше тратить память, чем процессорное время :)

UPD: Ага, оно просто задано константой. Тогда оптимальный вариант, добавить ключ в компилятор, допустим -adim count. (соответственно, сделать ограничение в этом ключе до 6 допустим или в рамках разумного. По умолчанию оставить: 4) Кому не нужно, тот не платит за повышение количество измерений, а кому нужно, тот может поднять.