Замечания и предложения

Admin · 04.Март.2020 07:53:16

И еще об оперативной памяти компьютера - 16 Гб будет тут явно мало

Ross · 04.Март.2020 09:49:19

Получается, что несмотря на наличие средств в самом .Net, выделение непрерывных областей для огромных структур с параллельными “фантомами” - особенно для 32-битных процессов - не спасёт ни дефрагментация, ни принудительный сбор мусора, ни файл подкачки, ни рейд-массив, ни масштабируемость.

Sun_Serega · 04.Март.2020 10:25:36

Не стоит всё в кучу сваливать.

Проблема .Net в этом деле только в высокоуровневости. В нём код всегда будет медленнее.

При чём тут дефрагментация и RAID массивы?

Принудительная сборка мусора нужна только для дебага, .Net сам знает когда оперативка кончается а значит пора чистить.

Файл подкачки спасёт от падения, но не от проблем скорости, которых будет больше.

Так что вы сделать то пытаетесь?

RAlex · 04.Март.2020 12:18:02

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

eva · 04.Март.2020 15:21:41

Да, компьютер тоже должен быть другой, может вообще другой. У меня приятель спалил таки жесткие диски, файл подкачки подкачал а у него было нечто, а не просто комп.

Just_name · 08.Март.2020 21:00:36

Предлагаю добавить функцию:

function TryRead(var x: boolean): boolean;
begin
  Result := True;
  try
    Read(x)
  except
    Result := False;
  end
end;

Admin · 09.Март.2020 10:37:29

Добавили

Just_name · 11.Март.2020 14:08:56

Мне кажется, в “/// Вводит числовое значение x клавиатуры. Возвращает False если при вводе произошла ошибка” забыли добавить предлог “с”, следовательно, должно получиться “…значение x с клавиатуры…”.

Кроме того, предлагаю добавить функции наподобие (комбинация “TryRead(var x: integer): boolean” и “ReadInteger(prompt: string): integer”)

/// Выводит приглашение к вводу и вводит числовое значение x с клавиатуры. Возвращает False если при вводе произошла ошибка
function TryRead(var x: integer; prompt: string): boolean;
begin
  Print(prompt);
  Result := True;
  try
    Read(x)
  except
    Result := False;
  end
end;

Обнаружил необрабатываемое исключение: оно появляется, если зайти в “Окно дизассемблирования”, когда после begin основной программы пусто, либо команды после begin основной программы к этому времени не выполнились (если поставить точку останова до begin основной программы).

Sun_Serega · 11.Март.2020 15:23:54

Приложите код и скриншоты или лучше видео, на словах ничего не понятно.

Just_name · 12.Март.2020 10:26:19

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

Sun_Serega · 12.Март.2020 13:49:02

Да, теперь замечательно. В таком качестве можно сразу в issue. issue для IDE тут:

Если положите в issue - об этой проблеме точно не забудут. Но имейте в виду, что исправления проблем IDE обычно не в приоритете перед проблемами компилятора.

Just_name · 12.Март.2020 16:08:41

Предпочту не класть в issue самостоятельно, поскольку не хочу создавать аккаунт в GitHub.

Sun_Serega · 12.Март.2020 18:05:14

Ну, вы много всяких неточностей сейчас находите, всё за вас туда переписывать не хочу. А на форуме вполне может потеряться.

Alvin-Seville · 15.Март.2020 18:49:28

Вы можете писать на почту (ibondarev@sfedu.ru) разработчикам напрямую, чтобы на форуме не потерялось. Если возникнут трудности при таком подходе - вопросы к самим разработчикам. Если это уже неактуальный способ обращения к ним, то к ним же и вопрос почему он всё еще висит в IDE (Модули -> Сообщить об ошибке). Но, в любом случае самый оптимальный способ - написание Issue на GitHub, поскольку при таком подходе Вам не придётся ждать пока они проанализируют Ваше сообщение им и создадут Issue (или сразу закроют) ошибку/улучшение сами.

Sun_Serega · 16.Март.2020 04:00:51

https://www.cyberforum.ru/pascalabc-net/thread2570021.html

@Admin вы уже давно собираетесь и не как не соберётесь сделать возможность создавать картинки из чего то кроме файлов.

Я всё игнорировал, в первую очередь потому что меня GraphWPF не сильно то касается.

Но у меня есть подозрение, что проблема в том что вы просто забыли, потому что у вас нет отдельного ToDo списка под каждый из ваших модулей. И вот как раз пишу потому что хочу его порекомендовать.

Alvin-Seville · 16.Март.2020 04:47:59

Здесь три замечания:

Насколько это нужно начинающим? Будет ли это часто используемым? Прослеживаются ли частые вопросы по этой теме на форумах? Если да, то это уже один из возможных поводов внедрения этого функционала. Если нет - стоит подумать нужно ли оно.
В то же время, хотя в первую очередь стоит реализовывать достаточно нужный (ссылка на первый пункт) пользователям функционал, ограничивать себя только этим - не стоит. Запас - дело хорошее. Но, есть риск сделать никому ненужные или нужные, но малому количеству пользователей по отношению ко всему их количеству “плюшки”.
Сделать “исключение” раз, а потом и ещё - легче, чем первый. Не превратится ли учебный модуль с подобными предложениями в что-то громоздкое для изучения, как Windows Forms/WPF/Avalonia? По капле и наберётся море возможностей… И не факт, что все будут востребованы. Это - противоположное мнение.

Добавлю, что нет чёткой последовательности исправления Issue, благодаря чему становится возможным откладывать некоторые улучшения и исправления надолго. Была бы чётко-прослеживаемая последовательность действий - было бы легче и пользователям и разработчикам. И претензии пользователей по поводу почему что-то не исправляется быстро объяснялись простым способом - очередь до данной Issue не дошла. Разумеется, планировка займёт время, но впоследствии повысит производительность работы.

Если бы IDE поддерживала ToDo-списки не только в плане подсветки синтаксиса, то было бы гораздо удобнее с ними работать. Иначе - если ToDo раскиданы по коду (ведь, никто не запрещает помещать ToDo именно в том месте, где надо что-то реализовать или исправить, а не одним списком в одном месте) - искать достаточно не удобно.

Sun_Serega · 16.Март.2020 05:27:47

Не любое увеличение функционала усложняет обучение. Вещи как доп. кнопки в IDE или конструкторы в конце их списка - легко игнорируются любым адекватным человеком, в процессе обучения, пока другой (более релевантной) информации полно.

Конечно, поддержка IDE была бы приятна, но не стоит преувеличивать эту необходимость. Сейчас вообще речь про ToDo список 1 модуля.

Вот у OpenCLABC 1 центральный список по общим улучшениям всего модуля, в начале файла + несколько //ToDo по всему модулю, по которым легко пройти с Ctrl+F, потому что это 1 файл.

Alvin-Seville · 16.Март.2020 05:33:08

В моём сообщении и не говорилось про IDE (в трёх пунктах).

Говорится про один модуль, но ToDo уже используется, например, в PABCSystem. И они раскиданы по модулю. Про необходимость (!) и не говорилось, было сказано:

и всё.

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

Я предлагаю (если и делать), то сделать для начала по-простому, в формате:

<line> <label> <description> <file>

, где:

<line> - номер строки
<label> - ToDo/FixMe/Hack
<description> - текст до конца строки после “метки”
<file> - имя файла, в котором определена “метка”

Последнее имеет смысл для проектов, для однофайловых вещей - без этого понятно где находится ToDo/FixMe/Hack.

Реализация в DevC++ (взял её в качестве примера, поскольку она простая IDE, скорее для обучения, чем для профессиональной разработки):

Admin · 16.Март.2020 07:44:33

Да, не собираемся. GraphWpf используют школьники - им картинки из файлов - единственно возможное.

Школьники не создают проекты.

Реализация изображений в ресурсах с поддержкой IDE - непростое дело. Во-первых - да - такая фича может быть востребована 2-3 человеками. Во-вторых, желающие ее реализовать имеют разное представление о сложности и скорее всего будут тянуть в сторону профессиональной разработки, в итоге эта возможность вообще не будет востребована никем.

Ну и - нужен разработчик, который взялся бы за интерфейс, а не точечно “Это надо, то надо”

Alvin-Seville · 16.Март.2020 08:09:39

Есть интересный момент - в языке много средств для решения различных задач, но сама IDE простая. Я не спорю с тем, что в обучении - это позволит сконцентрироваться на написании кода без отвлечений на интерфейс. Но, с другой стороны, продвинутым пользователям средств IDE будет маловато. Аналогия - дать повару много продуктов для приготовления его шедевра, но дать мало инструментов для этого. Такая же проблема есть в онлайн средах разработки - порой поддерживаются самые современные версии компиляторов, но не предоставляется обширных средств для работы с кодом. И именно поэтому desktop-ные IDE всегда будут впереди браузерных. Но, также первые (как и PascalABC.NET, например), позволяют небольшое что-то быстро написать. И поэтому делать Visual Studio 2 я не вижу смысла. В свете этого у меня есть сомнения на счёт нужности поддержки ToDo из IDE, хотя, для продвинутых (!) пользователей это была бы полезная вещь.