В том, что кто-то не прочёл до конца тему. Причина и исправление ошибок уже обсуждались.
Вид для печати
Ещё один неофициальный релиз 3.10.9+ (тоже выдаёт себя за обычный "3.10.9").
Новые исправления:
- Устранён краш из-за пустого текста в #warning и #error (#369).
- Исправлен баг, из-за которого при выводе warning 224 ("массив в sizeof имеет неопределённый размер") не отображалось название массива (#370).
- Устранён краш дизассемблера (pawndisasm) из-за неправильных инструкций (#424).
- Исправлены некорректные предложения (обычно выдаются при опечатках), выдаваемые для переменных, имеющих состояние (#431).
- Исправлен баг с возможностью инициализировать локальные переменные самими собой при объявлении (#436).
Скачать: https://www.dropbox.com/s/3fa3ak5ewf...fixed.zip?dl=0
Исходный код: https://github.com/Daniel-Cortez/paw...e/master-fixes
Как насчёт того, чтоб в основном посте оставить ссылку на исправленные стандартные инклуды, по типу этих?
UPD: А лучше, как по мне, нечто подобное так же и на сайте wiki.pro-pawn.ru разместить, чтоб появилось место, где всегда можно найти актуальную версию исправленных инклудов.
Со следующим релизом именно так и хотел сделать. Правда, непонятно, когда этот релиз ещё будет и будет ли вообще; ИМХО, накопившихся за год нововведений и исправлений могло бы хватить не то, чтобы на один - на три релиза.
Если в предыдущих релизах были костыли для совместимости со стандартными инклудами (например, сообщение о const-корректности warning 239 специально было отключено для нативных функций, т.к. некоторые функции SA-MP были объявлены некорректно), то сейчас сопровождающие проекта больше придерживаются мнения, что эта совместимость не нужна, т.к. теперь есть исправленные инклуды (к примеру, Y_Less высказывался, что эта совместимость больше ни к чему; да и взять то же ограничение warning 239 - пару дней назад я сделал PR, который это ограничение удаляет, и этот PR практически сразу же одобрили).
Для этого нужно сначала создать что-то вроде нового раздела ("Программное обеспечение"? "Программы/утилиты для скриптинга"?) и по-хорошему заполнить его несколькими статьями, в том числе про компилятор (уже готовое содержимое есть в 1-м посте).
Я бы и сам это сделал, но почти всё свободное время уходит на эксперименты с новыми фичами для компилятора.
Такая неразбериха происходит из-за того, что люди не могут понять, чего они хотят. Я забил на это после того, как Zeex замержил мой PR... когда он был в состоянии WIP. Хотя после этого они начали делать тесты, что довольно похвально.
Релизы они выпускают хаотично. Нет никакого регламента (хотя бы самого простого: если есть 3-5 исправлений в течении 3 месяцев - выпускаем релиз в конце этих 3 месяцев).
ИМХО не вижу смысла изобретать что-то новое. Тот же compuphase забил на него. __emit оператором никто не пользуется (можно было переписать всю библиотеку amx_assembly, сделав ее код более лучше; либо сделать его поддержку в YSI).
Ну во-первых, он это сделал, когда сам только отказался от работы над форком, поэтому недостаток внимания на тот момент можно понять.
Во-вторых, можно было в начале описания PR оставить примечание, что-нибудь вроде:
как, к примеру, было сделано в #303.Код:### [DO NOT MERGE - WORK IN PROGRESS]
Да уж лучше бы так и было. Сейчас вообще за год ни одного изменения, хотя изменений накопилось, хоть отбавляй :)
В compuphase могли быть свои причины. Здесь же речь о форке Pawn 3.2, в котором накопилось достаточно много багфиксов и новых фич в сравнении с оригиналом. И на эти фичи есть спрос, т.к. сообщество SA-MP ещё далеко от полного вымирания, сколько бы усилий Kalcor не прилагал.
Если же речь конкретно о моих мотивах, то для меня это просто хорошая возможность для 1) развития собственных навыков программирования; и 2) применения на практике знаний в области англ. языка для общения с другими опытными скриптерами. К тому же, этому форку Pawn помимо SA-MP можно найти другие применения.
Оператором __emit изначально не пользовались в первую очередь из-за отсутствия какой-либо документации - ни в wiki в репозитории, ни статей на зарубежных форумах, ничего. Есть статья на этом форуме и я оставлял на неё ссылку в репо компилятора, но никто не хочет её переводить, т.к. оператором не пользуются. Ловушка 22.
Мерджить не протестированный бенч... такое себе. А вообще мы вроде бы об этом в джаббер с тобой говорили.
Оно умирает.
Про твои мотивы я уже давно знаю) Это похвально. Дальнейшего тебе развития) Кстати, спасибо тебе)
Так у тебя есть возможность подкрепить свои знания в английском языке.
P.S.(0): ты допилил свой проект?
P.S.(1): старый акк можно удалять к чертям, ибо я на него уже не смогу зайти... В порыве избавится от Pawn в моей голове... я изменил пароль на черт его знает какой.
При создании таймера, если количество аргументов не совпадает, следует ввести напоминание в виде варнинга.
Пример:
PHP код:
SetTimerEx("@__TIMER", 1, true, "d", test, test);
Да, приходила в голову подобная идея, как для SetTimerEx()/CallLocalFunction()/CallRemoteFunction(), так и для format()/printf(), тем более в популярных компиляторах для C/C++ (MSVC, GCC, Clang) нечто подобное уже давно есть.
С точки зрения пользователя да, вроде бы простая и полезная фича, но вот как это примерно может выглядеть с точки зрения разработчика:
- В компиляторах для тех же C/C++ такая возможность реализуется через нестандартные расширения. Например, в glibc заголовок функции printf() объявлен с постфиксом "__attribute__((format(printf, 1, 2)))".
- Следовательно, в компиляторе Pawn сначала потребуется реализовать оператор __attribute (возможность создания этого оператора уже обсуждалась в одном из issue в репо компилятора год назад, поэтому я более чем уверен, что мейнтейнеры будут настаивать именно на таком варианте). У этого оператора одним из возможных аргументов будет format, а у того, в свою очередь параметром будет либо printf (т.е. "__attribute format printf"), либо тот формат спецификаторов, который применим к SetTimerEx()/CallLocalFunction()/CallRemoteFunction() - и если с названием "printf" всё очевидно, для этого формата я понятия не имею, как его можно назвать.
- Также непонятно, где можно было бы хранить информацию о нестандартном атрибуте функции (т.е. флаги присутствия атрибутов, позицию форматной строки, и позицию, с которой начинаются соответствующие аргументы). Создавать для этой цели отдельные поля в структуре symbol - такое себе быдлокодерское решение, т.к. это увеличит расход памяти под все виды идентификаторов, т.е. и под функции, и под переменные, и под константы.
И это только те подводные камни, которые я сейчас смог вспомнить сходу; уверен, при попытке реализации всплывёт ещё больше проблем. Я ни в коем случае не утверждаю, что идея сама по себе плохая, но то, что воплотить её будет затруднительно - факт. Я могу взяться за её реализацию, но позже, как только закончу с другими экспериментальными фичами, коих у меня уже скопилось несколько штук в локальном репо.