Болталка PascalABC.NET

Все что ты сказал - верно. Полностью поддерживаю. Желание писать на PascalABC.Net оно существует, но по мере наталкивания на множество багов, оно стремительно начинает падать…

Например, отлов багов участниками форума или написание модулей для PascalABC.Net и т.д.

На практике мы позиционируем Паскаль для другого - не для низкоуровневой работы с памятью

2 лайка

Я никогда не поверю, что разработчики не хотят добавлять или модернизировать те конструкции языка, которые позволяют оптимизировать приложение. :wink: Кстати, я не предлагал превратить Паскаль в Ассемблер.

А что мешает это сделать? Понятное дело, что такие уловки не предназначены для совсем начинающих, но это ведь не повод отказываться от этого. Вы могли бы привести код, как правильно это делать(может, я и правда ошибаюсь)?

Разработчики уже неоднократно высказывались на тему, чтО им мешает сделать то-то и то-то. И чтобы им поверить, достаточно взглянуть на количество открытых issue, которое за последние полгода, похоже, ни разу не опустилось хотя бы до 20. И некоторые из них висят годами :disappointed_relieved:

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

Снимок

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.

При чём ``` всегда должны быть на пустых строчках.

Спасибо за разъяснения. Я не ожидал столкнуться на мехмате с понятием верхнего левого угла окружности ))

А знаете ли Вы, что эллипс - это окружность, вписанная в прямоугольник? :rofl:

2 лайка

И равномерно приплюснутая перед этим :yum:

2 лайка

Главное - это чтобы она касалась середин каждой из сторон прямоугольника. А частный случай прямоугольника - квадрат - дает нам классическую окружность.

  • Докладчик: Представим себе решетчатый параболический агрегат, водруженный на четыре моноциклических агрегата, движущиеся по эквидистантным траекториям.
  • Популяризатор: Представим себе … э… телегу.
1 лайк

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

То что появились сторонние активные тестировщики уже хорошо. Только это не должно сопровождаться бесконечным нытьем про баги в среде.

Если внимательно проследите цепочку, то увидите, что я это не только понимаю, но пытаюсь обратить на это внимание других с тем, чтобы как-то повлиять на объем того, что Вы определили как

Речь о том, что по моему мнению, разработчики из-за отвлечения на все новые мелкие проблемы не успевают все разгребать: из-за мелочей руки не доходят до, быть может, действительно важного. Отсюда и неубывающее количество issues.