| Component Pascal и среда разработки BlackBox |
Здравствуйте!
Начал изучать новый язык программирования Component Pascal
http://www.oberon.ch/
http://www.inr.ac.ru/~info21/
http://www.uni-vologda.ac.ru/oberon/
Но нигде не нашел рускоязычного сайта, на котором был бы форум посвященный этому
языку.
Наверняка среди посетителей этого сайта есть специалисты по языку Component Pascal и
среде BlackBox.
А посему, перейду сразу к делу. У меня есть вопрос про сборщик мусора в BlackBox.
Может быть кто-нибудь сможет объяснить что нужно
сделать чтобы он заработал?
Я имею в виду следующую простейшую тестовую програмку:
MODULE sgTest003;
IMPORT StdLog;
PROCEDURE Проверка*;
TYPE A = POINTER TO ARRAY 10000000 OF INTEGER;
VAR a: A;
BEGIN
StdLog.String(" Создаю "); StdLog.Ln();
NEW(a); (* В этом месте я вижу через Windows Task Manager как BlackBox забрал
память*)
StdLog.String(" Выхожу из области видимости "); StdLog.Ln();
a := NIL; (* Я думаю, что сборщик мусора должен активизироваться в этом месте *)
END Do;
(* В этом месте я ожидаю, что BlackBox отдаст память обратно в распоряжение Windows
XP*)
BEGIN
END sgTest003.
Вызываю процедуру Проверка посредством кликания мышью на
(Коммандер)sgTest003.Проверка
и наблюдаю через Task Manager за памятью. BlackBox ее только забирает и назад не
отдает.
Даже если я выгружу модуль Dev ---> Unload, все равно BlackBox не вернет память
обратно
в распоряжение Windows XP. Память возвращается только когда я выключаю сам
BlackBox 1.4 Shareware Edition.
Кто-нибудь понимает в чем дело?
С уважением,
Сергей Губанов
Всего в теме 117 сообщений
Добавить свое сообщение
Отслеживать это обсуждение  Обсуждение из раздела
Школа ОБЕРОНА
| № 57 07-06-2006 07:32 |   |
Ответ на »сообщение 53« (AVC)
___________________________
Я имею в виду механизм исполнения команд и сериализации объектов.
Помоему в персистентных объектов изначально не было (только Text), их потом добавили.
| № 56 07-06-2006 07:30 | |
Ответ на »сообщение 55« (Руслан Богатырев)
___________________________
Мы начинаем все дальше уклоняться от темы форума. А после ряда последних событий я стараюсь особенно аккуратно чтить правила. Начинает надоедать мотание с "беспризорным" классическим Обероном по чужим углам. Сначала "Информатика-21", потом новые "Мысли", теперь это место. Лучше по этим вопросам подожду открытия подобающего места обсуждения.
Нда...
Я интересуюсь классическим Обероном. Да, я лучше знаком с ЧЯ/КП. Причина - я раньше с ним познакомился и больше времени потратил на его изучение.
Я определенно признаю, что в КП идеи оберона "завалены" в сторону общепринятой интерпретации норм императивного ООП. В связи с этим я осознаю, что он представляет меньшую фундаментальную ценность (хотя бы для моего самообразования). Я знаю ваше пристрастие именно к классическому Оберону и поэтому меня особенно интересует ваше мнение об этом языке, а так же взаимосвязь с другими языками и технологиями. Я не вижу, чем тема нашего разговора выходит за рамки " мыслей об Обероне". Не вижу причин, что бы считать это место "чужим углом". Если вы считаете, что я вышел за допустимые рамки, прошу извинить меня.
| № 55 07-06-2006 06:31 | |
Ответ на »сообщение 51« (Takun)
___________________________
Одна из задач нашего форума - выявить эту истину. Вы готовы ее сформулировать?
Мы начинаем все дальше уклоняться от темы форума. А после ряда последних событий я стараюсь особенно аккуратно чтить правила. Начинает надоедать мотание с "беспризорным" классическим Обероном по чужим углам. Сначала "Информатика-21", потом новые "Мысли", теперь это место. Лучше по этим вопросам подожду открытия подобающего места обсуждения.
| № 54 07-06-2006 06:31 | |
Ответ на »сообщение 47« (Руслан Богатырев)
___________________________
Метапрограммирование -- это средство из разряда трансформации исходных текстов на лету. Очень сильнодействующий механизм. Похлеще нейрохирургии.
Сколько угодно. Пока существующие модули не затрагивает. Тексты модулей могут быть не доступны.
| № 53 07-06-2006 06:27 | |
Ответ на »сообщение 47« (Руслан Богатырев)
___________________________
Метапрограммирование -- это средство из разряда трансформации исходных текстов на лету. Очень сильнодействующий механизм. Похлеще нейрохирургии.
Вместе с тем, ИМХО (прав ли я?), Оберон (как ОС или среда вроде BlackBox) без него немыслим.
Я имею в виду механизм исполнения команд и сериализации объектов.
| № 52 07-06-2006 06:26 | |
Ответ на »сообщение 50« (Руслан Богатырев)
___________________________
Вопрос относительно того, имеет ли смысл все модули грести под одну гребенку, либо делить их на категории по степени "капризности" при загрузке-выгрузке (а не только по статическому -- через IMPORT -- или динамическому импорту). Если загрузчик модулей будет иметь соответствующую подсказку/хинтовку, то он может решать свою задачу, наверное, более эффективно, нежели без знания оной информации?
Определенно нет. Хинтов не напасешся...
| № 51 07-06-2006 06:25 | |
Ответ на »сообщение 47« (Руслан Богатырев)
___________________________
Неужели Вы думаете, что если столь чтимый мной классический Оберон выдвигается на уникальное место сомнительным для меня критерием, то я это безоговорочно приму? Отнюдь. Истина дороже.
Одна из задач нашего форума - выявить эту истину. Вы готовы ее сформулировать?
Проблема в том, что чистота инвариантов -- не очень практичная вещь. Это надежность, но никак не практичность.
Во первых есть ситуации, когда надежность является необходимой, а не желательной. А во вторых, что такое практичность? В особенности в промышленном программировании?
| № 50 07-06-2006 06:22 | |
Ответ на »сообщение 43« (Takun)
___________________________
Эээ... не понял вопроса.
Вопрос относительно того, имеет ли смысл все модули грести под одну гребенку, либо делить их на категории по степени "капризности" при загрузке-выгрузке (а не только по статическому -- через IMPORT -- или динамическому импорту). Если загрузчик модулей будет иметь соответствующую подсказку/хинтовку, то он может решать свою задачу, наверное, более эффективно, нежели без знания оной информации?
| № 49 07-06-2006 06:17 | |
Ответ на »сообщение 46« (AVC)
___________________________
Даже без выгрузки импортирующих модулей.
Насколько это целесообразно -- вопрос.
В определенных случаях вполне целесообразно. Если требуется создавать т.н. адаптивные системы, то необходимо в зависимости от изменений операционных условий переключаться на разные схемы динамической "деградации/турбирования" системы. Модули могут выступать в роли ресурсов, за которые конкурируют другие модули. Загрузкой-выгрузкой этих ресурсов, а также управлением/регламентированием доступа к ним может заниматься специально выделенный диспетчер/"супервизор". Причем именно модулей, а не потоков (threads) и не процессов (processes).
| № 48 07-06-2006 06:16 | |
Ответ на »сообщение 44« (AVC)
___________________________
Но мне кажется, это мало поможет в данном случае.
Оберон-технология характеризуется не только орграфом динамически подгружаемых модулей, но и составными документами, содержащими в своем составе произвольные объекты.
Конечно. Пример: если в ЧЯ выгрузить модуль, содержащий код от некой вьюшки (View), то вьюшка не сможет в дальнейшем отрисовываться и функционировать вообще. Но с другой стороны это и не приводит к крушению системы в целом. Мы просто имеем серый прямоугольник с крестиком. Возможно следует считать определенную категорию ошибок, связанной с выгрузкой модуля, допустимой, и учиться их корректно обрабатывать. Как collision в Ethernet'е.
Я имел в виду идею добавить подобный механизм в Оберон, а не использовать непосредственно .NET. :)
Я тоже это имел в виду. ^_^=b
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
| 
