Модули для работы с OpenCL и OpenGL

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

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

Разработчики всегда могут быть уверены в автоматических тестах, без проведения которых я не залью пулл.

Копировать Запад не нужно,ибо это и есть мировой срач. Но и делать свой срач тоже не нужно. Срач срачем не выбивают. Русские долго запрягают, поэтому не нужно суеты. Спокойствие, только спокойствие. Если не помогает, балуйтесь плюшками (мягкий вариант).

Тем временем, спустя 101 костыль - я кое как запустил отладку. И - вот оно. Вот это тот самый лишний box:

Это точно он, ибо в той подпрограмме больше нет box-ов, и я удостоверился что точка останова попадется только 1 раз:

Сейчас разберусь надо ли там условие или он вообще лишний…

1 лайк
1 лайк

@Admin, пожалуйста, перенесите всё, начиная с этого сообщения - сюда, т.к. это оффтоп.

Кстати, в итоге оказалось что where T: Array было вообще не при чём. Этот код вообще падал:

type
  t0 = abstract class
    function f0: integer; abstract;
  end;
  t1 = class(t0)
    i: integer;
    function f0: integer; override := i;
    constructor(i: integer) := self.i := i;
  end;

function f1<T>: T;
where T: t0;
begin
  
  Result := T(t0(
    new t1(10)
  ));
  
  Result.f0.Println;
  
end;

begin
  
  f1&<t1>;
  
//  readln;
end.

Проблема была та же, и в моём пуле она тоже исправилась.

1 лайк

Да, код падает. Найдёте минимальный падающий код?

  1. Это и есть минимальный падающий.
  2. Я уже исправил это тут:

Я же говорю, это и есть на самом деле минимальный код к той issue в которой вы решили убрать where T: Array. И where T: Array к этой проблеме вообще не имеет никакого отношения.

И, ещё раз, если оно отмоталось куда то:
Я готов взятся за все issue связанные с where (а может и некоторые другие), если это поможет разгрузить вас так чтоб вы не делали запретов от нехватки времени на исправление.

Поэтому пожалуйста, не запрещайте where T: Array. Оно действительно полезно, а если оно что то сломает - я сам исправлю.

1 лайк

А, да, увидел pull request. Мы посоветуемся с ibond.

Если дело было не в ограничении where T: Array, то запрещать нечего.

Два дня поиска информации в Интернете - откуда такое ограничение в C# - к успеху меня не привели. Не вижу в нем ничего сильно криминального.

2 лайка
1 лайк

Видимо, надо заменить модуль OpenGL в комплекте Паскаля

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

Ядро OpenGL (то есть все подпрограммы Не из расширений и которые Не устарели) в целом готово к употреблению.

Когда можно будет принимать pull request?

Уже неделю как можно, я на гитхабе об этом сказал:

Я сильно обновил OpenCLABC и написал справку (в начале исходника, ибо там её найти легче всего).

@Admin, хотел переспросить у вас, я сам то правильно эти термины понимаю?
И, может вы как педагог - знаете как лучше можно это объяснить?

Пока пулл не кидаю, хочу подчистить пару мелочей…

Это всё не очень Это для официального инсталлята недостойно такое писать.

Метод - особая подпрограмма, вызываемая по точке для переменной
//   К примеру, метод Context.SyncInvoke выглядит в коде как "cont.SyncInvoke(...)", где cont - переменная типа Context
// 
// Статичный метод - особый метод, который вызывается по точке для типа вместо переменной
//   К примеру, статичный метод Buffer.ValueQueue выглядит в коде как "Buffer.ValueQueue(...)"
// 
// Остальные термины, которые могут быть непонятны (как свойства, которые property) - ищите в справке паскаля/гуглите

Вот переделанный вариант:

Метод - подпрограмма, описанная в классе и вызываемая в прикладном коде через переменную класса.

Статический метод - подпрограмма, описанная в классе с модификатором static и вызываемая в прикладном коде через имя класса.

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

После исправлений я пройдусь по коду и поправлю ваш русский

Я добавил этот раздел потому, что на куберфоруме почти все новички называют подпрограммы командами и т.п. Если с таким уровнем знаний читать справку - ничего понятно не будет.

А весь смысл справки - сделать модуль более доступным всем. Умники то и без справки разберутся, по одним только примерам…

Поэтому вариант с заумными словами неуместен. Надо что то среднее. Я к вам лично обратился как раз потому что думал - вы знаете как понятнее объяснить…

Кроме всего прочего - примите во внимание что паскаль учат школьники, а давать информацию сложными терминами (с расчётом “не маленький уже, ищи и догадывайся сам”) - это прикол университетов. Поэтому в упрощении некоторых вещей (пусть даже с потерей небольшого кол-ва информации) - имеет смысл. И да, я вижу что в моём варианте не немного информации потерялось и мне самому это не нравится…

Я уже Котова попросил (правда, он ещё не совсем согласился).

Я поправил.

В инсталляте неуместны никакие жаргонизмы. Вообще.