Ошибки компилятора PascalABC.Net

Спасибо за предложение

1 лайк

Тут дело такое, что прежде чем говорить об ошибке (они есть, конечно же, в каждой сборке что-то, да меняется, правда, не всегда именно ошибка исправляется, есть и замены, добавления), обязательно надо скачать самую новую версию и проверить на ней.

2 лайка

При использовании библиотеки SFML после нескольких десятков успешных запусков программ. Все программы перестали запускаться, выдавая три типа ошибок:

  • Нет перегруженной подпрограммы с такими типами параметров
  • Нельзя преобразовать тип SFML.System.Vector2f к SFML.System.Vector2f
  • Нельзя преобразовать тип SFML.Window.VideoMode к SFML.Window.VideoMode

После нескольких часов танцев с бубном и гуглежа всё снова заработало, но буквально через полчаса опять посыпались эти ошибки. Перезапуск/переустановка PascalABC.net проблему не решают, перезапуск ПК тоже не помогает. Как прошлый раз восстановил работоспособность - сам не понял. Использованный код и библиотека: ссылка Используемая ОС: Win10x64

Автор книги (В. Рубанцев) рекомендует сначала запустить SFML shader.pas Помогите решите эту проблему.

Я даже к программе на C# не могу эти сборки подключить:

Там что-то с этими сборками не так

Следуйте совету Рубанцева. Другие бубны не помогут. Это не проблемы сборок. Такие ошибки компилятор выдаёт и с другими сторонними библиотеками. У компилятора время от времени ум заходит за разум. Если дать ему время очухаться, то всё снова заработает. На Си-шарпе все сборки работают. Я целую книгу написал про SFML на Си-шарпе. Там проблем нет.

PascalABC.NET - прекрасная вещь, но всё же хотелось бы большей надёжности в поведении. Я стараюсь рекламировать и в меру сил продвигать эту систему, но подобные ошибки убивают энтузиазм.

Ага, понятно - вижу.

Валерий, скачайте последнюю версию и попробуйте - всё ли теперь работает.

2 лайка

Глубоко не копал, но на паре программ всё работает! Если так, то SFML смело можно использовать в программах. А там есть немало интересного!

Да! И похоже, что большинство ошибок с другими .NET dll ушли

1 лайк

Неожиданный, но приятный побочный эффект!

1 лайк

17 сообщений перенесены в тему Мнимые ошибки PascalABC.NET

Странно работает код:

  ReadArrInteger(ReadInteger)
    .Combinations(2)
    .Where(x->x.Sum mod 11 = 7)
    .OrderByDescending(x->x.Sum)
    .Print;

// 8 56 1 12 19 71 85 39 21 
// [39,21] [39,21] [39,21] [39,21] [39,21]  <<<= должны быть разные! как ниже
  ReadArrInteger(ReadInteger)
    .Combinations(2)
    .Where(x->x.Sum mod 11 = 7)
    //.OrderByDescending(x->x.Sum)
    .Print;

// 8 56 1 12 19 71 85 39 21 
// [56,39] [1,39] [12,39] [19,21] [85,21]
 var a = new[] { 56, 1, 12, 19, 71, 85, 39, 21 };
 var n = a.Length;
 var aa = a.SelectMany((x, i) => a.Skip(i + 1).Select(y => new[] { x, y }));
 var seq = aa.Where(t => t.Sum() % 11 == 7)
    .OrderByDescending(t => t.Sum());
 Console.WriteLine(string.Join(" ",seq.Select(t=>$"[{t[0]}+{t[1]}]")));

// [85+21] [56+39] [12+39] [1+39] [19+21]

PS: И не пишите, что это неэффективно. Я тесты генерировал для проверки )

Исправил. Залил на сайт.

Дело в том, что в Combinations(2) возвращался всё время один массив. Пришлось делать клоны всякий раз. Стало ещё более неэффективно. Зато сохраняется запись “в строчку”.

Видимо, надо сделать функцию NextCombination, которая переставляла бы элементы массива. Тогда бы программист думал бы, как сделать клоны этого массива и потом отсортировать.

А когда планируется новый релиз с исправленной ошибкой?

Я же написал, что залил на сайт. Проверьте

  1. Вы забыли залить файл SyntaxVisitors\PatternsVisitors\ReplaceNamesInIsVarVisitor.cs на гитхаб - без него ничего не собирается.

  1. А файл TestSuite\pointers12.pas:
type
 TPerson = record
  fam: string[15];
  name: string[10];
  id: integer;
 end;
type
  PPerson = ^TPerson; 
var x: array[1..3] of TPerson;
    p: PPerson;

procedure test1;
begin
  var p1: PPerson := @x[1];
  for var i := 1 to 1000 do
  begin
    p1^.name := 'abc';
    assert(p1^.name = 'abc');
  end;
  
end;
procedure test2;
begin
  var p2: PPerson := @x[2];
  for var i := 1 to 1000 do
  begin
    p2^.name := 'abc';
    assert(p2^.name = 'abc');
  end;
end;
begin
  {$omp parallel sections}
  begin
    test1;
    test2;
  end;
  p := @x[1];
  p^.name := 'abc';
  assert(p^.name = 'abc');
  p := @x[2];
  p^.name := 'def';
  assert(p^.name = 'def');
end.

У меня на ноутбуке время от времени падает. И понятно почему - @x[] создаёт нестабильный указатель, который сломается когда ему захочется.
На пк не падало, наверное, только потому что там не было таких проблем с объёмом RAM…

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

  1. Залил
  2. Указатели стабильны. За все годы сборки на разных устройствах у меня этот тест не падал

У меня тоже никогда не падал

Я вам уже несколько раз объяснял, почему @a[] - не может быть стабильно. Оно или даёт утечку памяти, или падает. Редко, но падает.

Чтоб упало - нужна очень неудачная сборка мусора между созданием указателя и использованием данных.
Если у вас по хотя бы 16гигов оперативки - понятно что вам нереально увидеть эту ошибку. Но я ещё неделю буду со своим старым ноутбуком, у которого всего 4гига. Он задыхается от одного только браузера, и без студии.

Ну, я пишу не о проблеме слабых компов. “обычно не упадёт, но если вы очень неудачны упадёт” - это ужасное поведение. Если что, понять что пошло не так - будет нереально. Поэтому такой код не должен быть в тестах - в том, что используется для поиска проблем.

А я вот этого не помню. Мы вроде бы фиксируем память перед использованием указателя.