PascalABC.NET версия 3.6

Вышла версия PascalABC.NET 3.6

Новое:

  • foreach по a.Indices заменяется на for по индексам
  • Операция if (min := if a<b then a else b;)
  • Операция взятия диапазона a..b
  • Оптимизация s[a:b] для строк
  • Из PABCSystem убрана операция умножения последовательности на число как провоцирующая ошибки
  • Добавлен when при матчинге кортежей
  • Метод Clamp
  • Автозавершение кода
  • Плагин образцов кода
  • Стандартная функция ReadInt64
  • Стандартная процедура Reverse для строки

Кроме того, создан сайт документации и примеров: https://pascalabcnet.github.io/mydoc_release_notes_3_6.html

2 лайка

А где неосновые? ))) Или, как обычно, см. Github?

А чем этот сайт отличается от pascalabc.net?

github.io это как ReadMe.md, но более продвинутое. Там вроде можно полностью свои html ставить. Но я в этом всё ещё не разобрался. А вот разработчики, похоже, решили разобраться.

Опять пытаюсь собрать билд на новом компе и опять та же ошибка:

File: "..\bin\CodeTemplatesPlugin.dll" -> no files found.
Usage: File [/nonfatal] [/a] ([/r] [/x filespec [...]] filespec [...] |
   /oname=outfile one_file_only)
!include: error in script: "sect_VisualPABCNET.nsh" on line 14
!include: error in script: "PascalABCNET_sections.nsh" on line 9
Error in script "PascalABCNETStandart.nsi" on line 4 -- aborting creation process

Я так понимаю это значит что _GenerateAllSetups.bat не перекомпилирует какой то из проектов.

собери билд, перекомпилируй все модули и запусти ReleaseGenerators\Samples\ExportSamples.bat

При чём тут это? Чтоб исправить это - надо только вручную откомпилировать из студии проект CodeTemplatesPlugin. И ошибка появляется после копирования примеров и до окончания сборки билда.

Да, знаем это. Пока думаем, как устранить эту проблему. Не знаем, как. Пересоберите CodeTemplatesPlugin.dll из Студии.

Данная проблема связана с тем, что проект CodeTemplatesPlugin собран под NET 4.7.1 и ссылается на проект визуальной оболочки тоже под 4.7.1. А остальные проекты собираются под NET 4.0. И при сборке bildа из bat-файла CodeTemplatesPlugin.dll в какой-то момент удаляется для возможности создать сборку для WindowsXP

Это что? Чем IntPtr отличается от других типов из System?

В чём ваш вопрос? Мы исправили - всё работает. Найдёте что-то ещё - милости просим.

Ссылка на строчку что то не сработала, я имел в виду вот это:

В чём смысл по особому обрабатывать IntPtr? Что произойдёт с остальными типами из System на этой строчке?

Вот для меня это выглядит как костыль чтоб не падал тест от фикса #2168, который имеет потенциал усложнить поиск минимального кода.

Мы не будем здесь рассматривать причины правок. И уж тем более отчитываться, почему мы сделали именно так.

Еще раз повторю - сделайте полный тест и попытайтесь найти второе исключение.

Я прошу не отчёт а дискуссию, которая поможет улучшить язык.

Как минимум, с IntPtr всегда идёт UIntPtr. Это типы - братья. И таки да, собрал последний билд - это падает:

type
  DT1 = procedure(i: System.UIntPtr);
  
begin
  var cb: DT1 := i->exit();
end.

Хотя другие типы из System, которые я попробовал, не падают.

Вот я задаю этот вопрос как раз чтоб вместе подумать, какие ещё типы могут ломаться.


Поэтому, для начала, ещё раз: Чем IntPtr такой особенный в данной ситуации, что ему (и UIntPtr) нужно такое специальное исправление, а всем остальным типам из System - нет?

uses System; // <--

type
  DT1 = procedure(i: System.UIntPtr);
  
begin
  var cb: DT1 := i->exit();
end.
type
  DT1 = procedure(i: System.UIntPtr);
  
begin
  var cb: DT1 := procedure(i: System.UIntPtr)->exit(); // <--
end.

Теперь не падает.

То что падает потому что ищёт IntPtr вместо System.IntPtr - было известно уже при создании #2168. И это в любом случае не решение проблемы.

В качестве временного способа обхода проблемы - сойдёт. Но ситуация подобна попыткам сокращения кода, когда скобки при вызовах методов и подпрограмм опускаются - это порождает некоторые проблемы, однако, порой достаточно пары лишних скобок, чтобы не натыкаться на них. Точнее - следует писать по некоторому “шаблону”, не выходить за его рамки, чтобы не сталкиваться с подобными проблемами. Однако, ибо этот “шаблон” точно неизвестен полностью избежать ошибок трудно.

Да, точно - спасибо - поправил.

Подключайтесь к проекту и попробуйте лучше исправлять Issue вместо бесполезных дискуссий.

1 лайк

Обсуждался ли ранее короткий синтаксис для обнуления статических массивов? Например, как в Python создание списков из десяти нулей a = [0]*10. Для ЕГЭ было бы полезно. В требованиях указано, что за отсутствие инициализации списывается балл. А писать полноценный цикл (или вложенные для многомерных массивов) для ЕГЭ много писанины. Генераторы не хотелось бы использовать, т.к. есть некий допустимый минимум знаний для успешного прохождения ЕГЭ.

Никаких статических массивов! Они только для совместимости. Делать что-то дополнительное для них - потеря времени. И никто не требует в ЕГЭ использовать статические массивы. В том же Питоне нет статических массивов - и никто не страдает от их отсутствия.

Это Ваши придумки. Читайте материалы ФИПИ.

Я и не утверждаю, что “некий допустимый минимум” это требования ЕГЭ )))) А в требованиях про инициализацию переменных и массивов говорится. И не важно, статических или динамических.