| 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 сообщений
Добавить свое сообщение
Отслеживать это обсуждение  Обсуждение из раздела
Школа ОБЕРОНА
| № 77 08-06-2006 01:06 |   |
Ответ на »сообщение 74« (AVC)
___________________________
Адреса процедур также хранятся в местах, доступных сборщику мусора.
| № 76 08-06-2006 01:01 | |
сообщение от модератораОтвет на »сообщение 67« (info21)
___________________________
Призыв к модератору: вырубать подобные посты независимо от остального содержания. Если человеку есть, что сказать, пусть постится еще раз.
Напоминаю ещё раз, что действия модератора в данной ветке не обсуждаются, а призывы к модератору сделать что-либо являются формой обсуждения. Можно писать в Книгу жалоб и предложений или, в особых случаях, мне лично, но не здесь. В связи со сложной ситуацией пока я допускал некоторые отклонения от правил и обсуждения не только заявленной темы, но и ситуации вокруг Оберона в Королевстве. Но сейчас разговор в целом вошёл в нормальное русло, поэтому я считаю, что переходный период закончился и с этого момента буду строже следить за соблюдением правил.
| № 75 08-06-2006 00:50 | |
Ответ на »сообщение 64« (info21)
___________________________
Достаточно не использовать процедурные переменные. Тогда корректная выгрузка модулей не сложнее сбора мусора.
Не уверен, что это так просто.
Кажется, когда-то (уже давно) я проводил соответствующий эксперимент, и мне удалось довести BlackBox до глюка.
Но мысль интересная, ведь в Обероне-2 и КП именно в дескрипторе типа пересекаются модульная и объектная структуры, а их несовпадение, ИМХО, и является основной причиной опасности выгрузки модулей.
| № 74 08-06-2006 00:38 | |
Ответ на »сообщение 72« (Trurl)
___________________________
Ответ на »сообщение 64« (info21)
___________________________
>>> Достаточно не использовать процедурные переменные. Тогда корректная выгрузка модулей не сложнее сбора мусора.
Процедурные переменные в этом плане ничем не отличаются от методов.
Кажется, все же, не совсем так.
Адреса методов в Обероне-2 и КП хранятся в дескрипторе типа, а он, в свою очередь, размещается (или может размещаться) в куче и доступен через указатель type tag.
Т.е. как раз сборщик мусора и может (хотя бы теоретически) "накласть вето" на опасную выгрузку модуля.
Надо еще раз это обдумать, но, похоже, что уважаемый info21 в принципе прав.
| № 73 08-06-2006 00:17 | |
Ответ на »сообщение 62« (Takun)
___________________________
Кажется, так и было.
Я имел в виду, что задействовали, в общем, тот же механизм: Oberon.Call etc.
Так вроде это не сереализация. Просто в глобальную переменную помещают строку текста с параметрами, которые процедура потом парсит. Объект с произвольной структурой так не передашь, только примитивные типы.
Я долго мучился, никак не мог вспомнить, откуда у меня всплыл этот Oberon.Call... :)
Наконец вспомнил -- из упражнения к 12-й главе книги Вирта и Рейзера "Программирование на Обероне" (1992). (Упражнение 12.12.)
Там рассматривается сохранение/восстановление графических объектов с помощью (специфических для каждой фигуры) процедур Store/Load, вызываемых с помощью Oberon.Call.
Отсюда, видимо, у меня и отложилось в памяти, что используются сходные механизмы.
А то я уже было подумал, что у меня глюк... :)
Как бы то ни было, немного сам себя запутав, я хотел сказать, что и для вызова команды, и для сохранения/восстановления составного документа в Обероне необходимы метапрограммные механизмы.
ИМХО, это требуется для поддержания неограниченной расширяемости.
(Еще одна возможная сфера их применения -- обработка исключений.)
| № 72 07-06-2006 23:53 | |
Ответ на »сообщение 64« (info21)
___________________________
>>> Достаточно не использовать процедурные переменные. Тогда корректная выгрузка модулей не сложнее сбора мусора.
Процедурные переменные в этом плане ничем не отличаются от методов.
| № 71 07-06-2006 16:43 | |
Ответ на »сообщение 69« (Руслан Богатырев)
___________________________
ОС UNIX практически невозможно написать на языке SETL. Думаю, можно назвать еще не менее дюжины языков, на которых это также нельзя сделать.
По этой ссылке ( http://www.99-bottles-of-beer.net/) легко найти пару десятков языков, на которых нормальный человек даже Hello World! не напишет. :)
| № 70 07-06-2006 16:03 | |
Ответ на »сообщение 59« (Takun)
___________________________
Где я вам другой возьму? :(
Значит, будем ждать, когда откроют.
| № 69 07-06-2006 16:01 | |
Ответ на »сообщение 45« (Takun)
___________________________
В этом смысле UNIX можно написать на любом языке, но не на любом языке можно написать ОС Оберон.
Классический Оберон в определенном смысле эквивалентен языку Си. Со всеми вытекающими отсюда последствиями. ОС UNIX практически невозможно написать на языке SETL. Думаю, можно назвать еще не менее дюжины языков, на которых это также нельзя сделать.
| № 68 07-06-2006 15:56 | |
Ответ на »сообщение 67« (info21)
___________________________
Призыв к модератору: вырубать подобные посты независимо от остального содержания. Если человеку есть, что сказать, пусть постится еще раз.
Уважаемый info21 ну никак не уймется. Однако, мое терпение в общем-то не беспредельное.
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
| 
