В тестирование входят только баги которые были исправлены. То есть оно сделано чтоб не добавлять исправленные баги. А новые фичи тестируются только пользователями паскаля…
Но разве разработчикам не следует ли тестировать для начала самим новые фичи? Лучше если разработчики выявят баг и исправят его, зачем “демонстрировать” баги?
1 лайк
На мой взгляд, основная проблема этого проекта – отсутствие деления на стабильную и нестабильные ветки.
Стабильная ветка должна иметь четко оговоренный минимальный срок поддержки (напр., 12 мес.) и включать в себя только консервативные багфиксы из текущей нестабильной ветки, находящейся в активной разработке. А все новые фичи, модули и рискованные багфиксы (в т.ч. нарушающие бинарную совместимость, семантику, интерфейсы и прочие задокументированные соглашения) не должны её затрагивать никоим образом.
Стабильность / нестабильность любого релиза должна также визуально отражаться в нумерации версий (напр., 3.2.x – стабильная ветка, 3.3.x - нестабильная альфа/бетка/RC, 3.4 – след. стабильная, и т.д.). После выделения временной ветки под релиз-кандидат должен наступать мораторий на добавление любых новых фич – только консервативные или критические багфиксы + минимальное время на стабилизацию и обкатку активными членами сообщества (скажем, за 1-2 мес. до объявления очередного финального стабильного релиза). Примерно то же самое – для временной ветки под бетку, только подольше (напр., 3-4 мес.), чтобы было время не только отладить код, но и отразить все изменения в офиц. документации, написать тесты/примеры/туториалы.
Т.е. примерно 6-8 мес. активно пекутся новые фичи для нового релиза (можно даже без публичных билдов, а только для доверенных тестеров/контрибуторов), затем форк на публичную бетку – активный фидбек/доводка/доки, потом “мягкая” заморозка фич в RC + стабилизация/полировка перед финальной подачей.
Кроме того, все официальные билды дистрибутивов на сайте должны иметь четкие ссылки на последний коммит, которому они соответствуют. Сейчас номер и дата билда не имеет строгой связи с состоянием исходников.
Все коммиты должны быть атомарными и иметь короткий, но понятный комментарий (не только основным разработчикам, но и любым “внешним” контрибуторам/тестерам и прочим опытным членам сообщества). Непрозрачные слияния накопленных за период изменений (мёржды) с любой веткой должны быть исключены.
Все новые хотелки/баги/фичи должны время от времени анализироваться и помечаться соответств. тэгами и признаками будущих/текущих версий на гитхабе, то же самое – для критических багов, чтобы разработчики и члены сообщества могли эффективнее взаимодействовать и прозрачно расставлять приоритеты по проблемам/задачам проекта.
Любые принципиальные вопросы, такие как общее направление развития проекта, его цели и задачи должны более открыто обсуждаться с сообществом, а не постулироваться жестко, категорично и пост-фактум (в стиле – весь код открытый, кому что-то не нравится – форкайте и пилите дальше сами, мы вам ничем не обязаны). Проекту жизненно необходимы новые силы, ресурсы и идеи, но они никогда не появятся при таком подходе к работе с коммъюнити.
В общем, ничего необычного, просто нужен более-менее полноценный и открытый проект- и релиз-менеджмент. В настоящий же момент проект хоть и формально открытый, но по методу управления – сугубо проприетарный, я бы даже сказал – авторитарный. Это у многих довольно быстро отбивает всякое желание активно ему помогать и иногда приводит к открытым конфликтам/непониманию даже среди активных и опытных участников.
Чего уж там говорить про перспективы замены ТурбоПаскаля, стандартизацию и появление полноценных учебников и массовое внедрение в учебные заведения (особенно школы) – пока что шансы равны 0. Да и узнаваемость среди мирового IT-сообщества, даже закоренелых паскалистов, несмотря на все очевидные достоинства и прогрессивные фичи – также ноль… (с) “Абидно, слюшай!”
P.S. Не сочтите это за неблагодарность по отношению к авторам, просто накипело за пару-тройку лет, как говорится, “за державу обидно!”.
4 лайка
Всё что Вы пишете - хорошо и правильно. Но нуждается в больших ресурсах и в большом сообществе разработчиков. Я согласен про новые силы и ресурсы. Но если эти силы будут заключаться в “а давайте вы сделаете то”, то это не годится - силы у нас маленькие. Про положительную помощь кроме поиска багов я не слышал с момента выкладывания проекта на Github.
Про “Форкайте и пилите сами” я никогда не говорил - никто не позволит добавлять в проект неконтролируемый код. Но я и не видел сколько-нибудь значимых попыток исправить хотя бы один Issue сторонними разработчиками.
Про перспективы замены Турбо-Паскаля в школах - эта замена де факто уже произошла. Турбо-Паскали используются в очень малом проценте случаев в школе сейчас, поэтому говорить про какие-то странные перспективы того, что уже произошло - это непонимание происходящего. Про написание новых учебников для школ - этот процесс абсолютно ничего не имеет с развитием проекта - проект может быть как угодно замечательный, а учебника ни одного не будет написано и наоборот.
Ещё раз - в школы PascalABC.NET фактически внедрён. То, что Вы пишете - про 0 вероятность - это параллельный мир.
Про 6-8 месяцев… Если внимательно посмотреть на последний год в Что нового, то можно утверждать, что в основном это - исправление багов. Вообще, новые языковые фичи добавлялись достаточно давно. Так что эту рекомендацию я отношу к тем самым советам “Вы делайте, а мы будем говорить, что не так”.
Комьюнити кстати пока весьма незначительный - здесь на форуме отмечено максимум 10 человек. И непонимание - да - оно существует. В основном между нашими возможностями и вашими желаниями. И скажем в трактовке того, что считать “активной помощью”.
Вот эта фраза конечно характерна своим “должны”: “Все новые хотелки/баги/фичи должны время от времени анализироваться и помечаться соответств. тэгами и признаками будущих/текущих версий на гитхабе, то же самое – для критических багов, чтобы разработчики и члены сообщества могли эффективнее взаимодействовать и прозрачно расставлять приоритеты по проблемам/задачам проекта”. Всего на Githubе около 30 открытых Issue (посмотрите кстати сколько закрыто) - если бы мы могли их быстро устранить, то давно устранили бы. Из этих ISSUE собственно серьёзных багов языка (не оболочки, не Intellisense, а языка) - 4 штуки. Какие там приоритеты должны расставляться в этих четырёх багах? Их просто надо исправить и всё.
4 лайка
Все что ты сказал - верно. Полностью поддерживаю. Желание писать на PascalABC.Net оно существует, но по мере наталкивания на множество багов, оно стремительно начинает падать…
На практике мы позиционируем Паскаль для другого - не для низкоуровневой работы с памятью
2 лайка
Я никогда не поверю, что разработчики не хотят добавлять или модернизировать те конструкции языка, которые позволяют оптимизировать приложение. 
Кстати, я не предлагал превратить Паскаль в Ассемблер.
А что мешает это сделать? Понятное дело, что такие уловки не предназначены для совсем начинающих, но это ведь не повод отказываться от этого. Вы могли бы привести код, как правильно это делать(может, я и правда ошибаюсь)?
Разработчики уже неоднократно высказывались на тему, чтО им мешает сделать то-то и то-то.
И чтобы им поверить, достаточно взглянуть на количество открытых issue, которое за последние полгода, похоже, ни разу не опустилось хотя бы до 20. И некоторые из них висят годами 
Ну не может пара человек с саперными лопатками разгрести все то гуано, которое десятки людей набрасывают совковыми лопатами. Неужели это так сложно понять?
1 лайк
Нет, на самом деле опускало, вроде ближе к новому году… Но это было быстро исправлено)))
Если посмотреть на открытые Issue, то можно увидеть следующее. Из 40 штук:
- 15 - это хотелки (не баги)
- 9 - это баги в Intellisense и оболочке
- 7 - мелкие баги, которые встречаются в крайне редких надуманных ситуациях и которые долго и тяжело исправлять
- 1 - баг в конструкции, которой нет в описании языка
- 2 - средних бага с лямбдами
Всё это явно не стыкуется с той якобы удручающей картиной, которая рисуется здесь на форуме.
Причём, некоторые дошли до того, что вместо того чтобы задать вопрос на форуме, они открывают Issue на гитхабе.
2 лайка
Вот лично меня они волнуют достаточно сильно. Потому что на их базе уже столько всего выскакивало, просто я не писал об этом на форуме, считая что причина уже описана.
Да и баги в Intellisense - тоже не подарок, когда пишешь что-то в условиях цейтнота.
Замечание к модулю ABCObjects. Вопреки документации, начало локальных координат CircleABC находится не в центре изображения, а в левом верхнем углу описанного квадрата, поэтому изображение приходится сдвигать по осям влево и вверх на радиус окружности. Хотелось бы уточнить, что правильно: документация или реализация?
А что такое локальные координаты CircleABC?
Если я правильно понял что вы написали, то следующая программа должна ставить верхний левый угол прямоугольника, в который вписан рисуемый круга, на координаты (0;0):
uses ABCObjects;
begin
new CircleABC(0,0,10,Color.Black);
end.
Но у меня в туда ставит центр круга, как и должно.
Ваша правда, я сначала неправильно понял суть проблемы. На самом деле проблема в процедуре перемещения объекта. Попробуйте такой пример:
uses ABCObjects;
begin var shape := new CircleABC(0,0,10,Color.Black); shape.MoveTo(0,0); end.
По смыслу, объект вроде-бы должен остаться на месте, но не тут-то было.
/// Перемещает левый верхний угол графического объекта к точке (x,y)
procedure MoveTo(x,y: integer);
И попробуйте выделять текст программы нормально:
```
begin
end.
```
Превращается в:
begin
end.
При чём ``` всегда должны быть на пустых строчках.
Спасибо за разъяснения. Я не ожидал столкнуться на мехмате с понятием верхнего левого угла окружности ))
А знаете ли Вы, что эллипс - это окружность, вписанная в прямоугольник? 
2 лайка
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021