Не стоит всё в кучу сваливать.
Проблема .Net в этом деле только в высокоуровневости. В нём код всегда будет медленнее.
При чём тут дефрагментация и RAID массивы?
Принудительная сборка мусора нужна только для дебага, .Net сам знает когда оперативка кончается а значит пора чистить.
Файл подкачки спасёт от падения, но не от проблем скорости, которых будет больше.
Так что вы сделать то пытаетесь?
Не подходит. Для этого используют суперкомпьютеры, или, как минимум, мультипроцессопрные системы с языками класса “Параллельный Фортран”. Понимаете, ну вот есть прогулочные яхты, а есть авианосцы. И то, и другое - суда. Но никто на пытается взлетать на самолете с палубы яхты, как и катать подружек по морю на авианосце.
Да, компьютер тоже должен быть другой, может вообще другой. У меня приятель спалил таки жесткие диски, файл подкачки подкачал 
а у него было нечто, а не просто комп.
Предлагаю добавить функцию:
function TryRead(var x: boolean): boolean;
begin
Result := True;
try
Read(x)
except
Result := False;
end
end;Добавили
Мне кажется, в “/// Вводит числовое значение 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 основной программы).
Приложите код и скриншоты или лучше видео, на словах ничего не понятно.
То же самое, когда выполнение не перешло begin основной программы (противопоставление begin подпрограмм) (например, жёлтая стрелка на разделе описания переменных), но это был единичный случай, теперь мне не удаётся поставить жёлтую стрелку на строку до begin основной программы.
Да, теперь замечательно. В таком качестве можно сразу в issue. issue для IDE тут:
Если положите в issue - об этой проблеме точно не забудут. Но имейте в виду, что исправления проблем IDE обычно не в приоритете перед проблемами компилятора.
Предпочту не класть в issue самостоятельно, поскольку не хочу создавать аккаунт в GitHub.
Ну, вы много всяких неточностей сейчас находите, всё за вас туда переписывать не хочу. А на форуме вполне может потеряться.
Вы можете писать на почту (ibondarev@sfedu.ru) разработчикам напрямую, чтобы на форуме не потерялось. Если возникнут трудности при таком подходе - вопросы к самим разработчикам. Если это уже неактуальный способ обращения к ним, то к ним же и вопрос почему он всё еще висит в IDE (Модули -> Сообщить об ошибке). Но, в любом случае самый оптимальный способ - написание Issue на GitHub, поскольку при таком подходе Вам не придётся ждать пока они проанализируют Ваше сообщение им и создадут Issue (или сразу закроют) ошибку/улучшение сами.
https://www.cyberforum.ru/pascalabc-net/thread2570021.html
@Admin вы уже давно собираетесь и не как не соберётесь сделать возможность создавать картинки из чего то кроме файлов.
Я всё игнорировал, в первую очередь потому что меня GraphWPF не сильно то касается.
Но у меня есть подозрение, что проблема в том что вы просто забыли, потому что у вас нет отдельного ToDo списка под каждый из ваших модулей. И вот как раз пишу потому что хочу его порекомендовать.
Здесь три замечания:
Windows Forms/WPF/Avalonia? По капле и наберётся море возможностей… И не факт, что все будут востребованы. Это - противоположное мнение.Добавлю, что нет чёткой последовательности исправления Issue, благодаря чему становится возможным откладывать некоторые улучшения и исправления надолго. Была бы чётко-прослеживаемая последовательность действий - было бы легче и пользователям и разработчикам. И претензии пользователей по поводу почему что-то не исправляется быстро объяснялись простым способом - очередь до данной Issue не дошла. Разумеется, планировка займёт время, но впоследствии повысит производительность работы.
Если бы IDE поддерживала ToDo-списки не только в плане подсветки синтаксиса, то было бы гораздо удобнее с ними работать. Иначе - если ToDo раскиданы по коду (ведь, никто не запрещает помещать ToDo именно в том месте, где надо что-то реализовать или исправить, а не одним списком в одном месте) - искать достаточно не удобно.
Не любое увеличение функционала усложняет обучение. Вещи как доп. кнопки в IDE или конструкторы в конце их списка - легко игнорируются любым адекватным человеком, в процессе обучения, пока другой (более релевантной) информации полно.
Конечно, поддержка IDE была бы приятна, но не стоит преувеличивать эту необходимость. Сейчас вообще речь про ToDo список 1 модуля.
Вот у OpenCLABC 1 центральный список по общим улучшениям всего модуля, в начале файла + несколько //ToDo по всему модулю, по которым легко пройти с Ctrl+F, потому что это 1 файл.
В моём сообщении и не говорилось про IDE (в трёх пунктах).
Говорится про один модуль, но ToDo уже используется, например, в PABCSystem. И они раскиданы по модулю. Про необходимость (!) и не говорилось, было сказано:
и всё.
Необязательно так же будет и у других. Кроме того, не забывайте про режим проекта - там может быть не один файл, ведь проекты на это и рассчитаны. Обычный поиск здесь как “палочка-выручалочка” уже не поможет. Ибо искать придётся в каждом (!) файле, что небыстро. Кроме того, сам ToDo - может быть вообще не ToDo (в привычном нам понимании), а каким-то литералом в коде или идентификатором (или его частью), что обязует писать регулярные выражения для нормального поиска (если нет уверенности в том, что ToDo только в комментариях). Так что проблемы возможны даже в границах одного файла, что делает решение через обычный поиск напрямую зависимым от кода и неустойчивым к “экзотическим” случаям.
Я предлагаю (если и делать), то сделать для начала по-простому, в формате:
<line> <label> <description> <file>
, где:
<line> - номер строки<label> - ToDo/FixMe/Hack
<description> - текст до конца строки после “метки”<file> - имя файла, в котором определена “метка”Последнее имеет смысл для проектов, для однофайловых вещей - без этого понятно где находится ToDo/FixMe/Hack.
Реализация в DevC++ (взял её в качестве примера, поскольку она простая IDE, скорее для обучения, чем для профессиональной разработки):
Да, не собираемся. GraphWpf используют школьники - им картинки из файлов - единственно возможное.
Школьники не создают проекты.
Реализация изображений в ресурсах с поддержкой IDE - непростое дело. Во-первых - да - такая фича может быть востребована 2-3 человеками. Во-вторых, желающие ее реализовать имеют разное представление о сложности и скорее всего будут тянуть в сторону профессиональной разработки, в итоге эта возможность вообще не будет востребована никем.
Ну и - нужен разработчик, который взялся бы за интерфейс, а не точечно “Это надо, то надо”
Есть интересный момент - в языке много средств для решения различных задач, но сама IDE простая. Я не спорю с тем, что в обучении - это позволит сконцентрироваться на написании кода без отвлечений на интерфейс. Но, с другой стороны, продвинутым пользователям средств IDE будет маловато. Аналогия - дать повару много продуктов для приготовления его шедевра, но дать мало инструментов для этого. Такая же проблема есть в онлайн средах разработки - порой поддерживаются самые современные версии компиляторов, но не предоставляется обширных средств для работы с кодом. И именно поэтому desktop-ные IDE всегда будут впереди браузерных. Но, также первые (как и PascalABC.NET, например), позволяют небольшое что-то быстро написать. И поэтому делать Visual Studio 2 я не вижу смысла. В свете этого у меня есть сомнения на счёт нужности поддержки ToDo из IDE, хотя, для продвинутых (!) пользователей это была бы полезная вещь.
Когда есть много нерешенных проблем с сопровождением программного продукта, можно выбирать разные стратегии. Первая - решать их в порядке возрастания трудоемкости. Это самообман, но психологически комфортно из-за быстрого убывания общего количества проблем. Вторая - затыкать наиболее существенные дыры. Это разумно с точки зрения поддержки продукта - снижается потенциальное количество пользователей, “нарвавшихся” на проблему, что в свою очередь, работает на общественное мнение о продукте. Это как в дырявом днище лодки: если в большую дыру поступает воды больше, чем в десятки щелей, надо дыру латать, а не щели. И третья стратегия - перемежать латание крупных дыр с мелкими. Пока латаем мелкую, думем, как залатать крупную. Скорее всего это - оптимум.
По поводу ToDo списков мы думали, это было бы полезно для студентов и продвинутых школьников скажем как задания в частичном проекте. Но вещь не настолько критичная, и заняться некому - да.
Более важная вещь - подчистка интерфейсных элементов для разрешений 200% и выше. Что то мы сделали, но там обязательно надо переделывать это, потому что растет число пользователей с такими мониторами
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021