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

Среда PascalABC.NET
#277

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

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

#278

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

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

2 лайка
#279

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

#280

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

1 лайк
#281

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

1 лайк
#282

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

Мнимые ошибки PascalABC.NET
#283

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

  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: И не пишите, что это неэффективно. Я тесты генерировал для проверки )

#284

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

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

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

#285

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

#286

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

#287
  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…

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

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

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

#290

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

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

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

#291

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

#292

#2206

В его фиксе этот иногда_падающий файл теста и добавили. GCHandle только запрещает удалять объект. А память фиксирует именно GCHandleType.Pinned.

Да и кстати, раз уж подняли эту тему - пожалуйста, добавьте хоть предупреждение, для записи @a[...], где a - или массив, или строка. С текстом в этом духе:

Запись @a[...] приводит к утечкам памяти [и редким вылетам], её использование не рекомендуется. Используйте типы вроде GCHandle.

А то я хоть и написал об этом в общей справке OpenCL/OpenGL, но всё равно как то боязно, что народ будет насматриваться старых туториалов (а новых для OpenGL в PABC.Net в принципе нет), использовать @[] в своём коде, видеть что память утекает и думать что паскаль/модуль какой то не такой.

#293

Мы устранили эту ошибку. Issue закрыта. Тесты проходят.

У вас странные предложения.

А что вы написали в справке OpenCL / OpenGL ?

#294

Тесты проходят, но теперь это:

Стало неправдой. Вы не фиксируете память массивов записей с полем типа string, вам это GCHandle не позволит.

Какая разница, на сколько редко они могут падать - если всё равно когда то да упадут? И таки уже упало, хоть у меня и были более благоприятные для падения условия…
Вот я говорю - добавлять код с неопределённым поведение в тесты принципиально неправильно.

Там - только про утечку памяти. Случай с записями, содержащими string - вряд ли встретится в OpenCL и OpenGL. Подробнее - почитайте сами, страница справки Маршлинг >> Массивы.

1 лайк
#295

Нет там никаких условий для падения. В примере память вообще нигде в цикле не выделяется. А проверяется многопоточная фиксация указателей

#296

А при чём тут циклы? Я говорю что перемещается тело массива, потому что выражение @x[...] не делает никаких фиксаций.

Вообще странно вам это объяснять, кроме того что я это уже пару раз объяснил выше - вы же сами коммитили изменение, позволяющее @x[...] без фиксации.

Ну впрочем, если вы всю теорию мимо ушей пропускаете - вот вам практика:

image
image1366×768 75.3 KB

Конечно, Debug.WriteLine - это хак, совершенно непонятно как работающий. Но он всё равно показывает, что массив может перемещаться в памяти, когда системе захочется.