OberonCore

По мануалу SUBJ должен ставиться на SP4, но при установке говорит, что kernel.* более старой версии чем имеется в системе. Обе сборки от 19.12.2006.
===================
Уже после установки понял в чем дело... Active BlackBox подменяет ядро Kernel на многопоточную версию т.е. хронологически он может быть и более старым, но технологически...

Ща сижу любуюсь новой цацкой. Всё о чем мечтал вроде есть, но документация требует доробртки.

Details.odc

Проверяет, имеет ли объект obj деталь типа mod.type. Учитываются все детали - и экспортированные, и неэкспортированные. Учитываются только экспортированные детали.

(вероятно ^c & ^v из предидущего абзаца)
=================================
Ao.odc

Стоп-переменные, используются для подачи сигнала остановки циклическим активностям, которые периодически опрашивают ShouldStop(). Возвращаемое значение является ИЛИ-комбинацией значения стоп-переменной и от наличия (*) стоп-сигнала Kenel.cShouldCompelete (**) для опрашивающего переменную потока.

(*) Что называется "читал, много думал". Может лучше выбросить кусочек или переформулировать?
(**) не хватает буквы.

Хе-хе...

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

Как грит Process Explorer от Sysinternals ActiveBlackBox таскает с собой 9 процессов (просто BlackBox 1.5sp4 только 7 . раньше их вообще было только два (главный процесс и Ctrl+Breack), но я о другом - Shift+F12 вообще никого не показывает. Я так понимаю DevTaskMan.List выводит список только тех процессов которые созданы через сервисы (System)Ao?

Ну и мне первому наверно удалось завесить новую версию
Запустил демо с шариками, наплодил их штук 200 (тяжело подсчитать, но эффект воспроизводимый), сделал несколько комнат... и через 3-4 минуты завесил фреймворк. Т.е. шарики не шуволятся, в заголовке надпись (задача не отвечает), но окошки перерисовываются. Что характерно при снятии задачи и повторном зауске хоть ABB, хоть просто BB, имеем пустые висящие окна с нерабочими менюшками и так до перезагрузки компьютера..

Хм.. умудрился завесить с тремя шариками и одной комнатой. Во всех экспериментах один шарик собирался выйти из комнаты и по крайне мере два пытались войти.

И еще одно наблюдение. Порядок разблокировки не соответсвует порядку входа в комнату. Почти всегда разблокировка происходит как в стеке (последний пришел - первый вышел), но пару раз были исключения. Это не есть гуд, т.к. при большом кол-ве процессов возможна ситуация, когда один из них так и останится заблокированным.

А сколько ядер у вас в процессоре? процессорах?

Да, кстати, не путайте процессы и потоки. Речь в системе идет о потоках.

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

По поводу зависаний - да, в бета-версии есть еще неустранненые взаимоблокировки в ядре, которые проявляются только на многоядерных/гипертрединг-процессорах, буду доделывать.

Сейчас интересно в первую очередь мнение о введенных концепциях и т.п.

По-моему слишком сложно и сразу много всего. Я бы сначала сделал только многопоточные NEW/сборку мусора, да выделил в отдельный модуль процедуры управления потоками. А уж потом на это дело навешивал слабые указатели и "детали".
Что касается модуля Ao - ну прямо просится в псевдомодули.

Сейчас скачал дистрибутив. Там нет, собственно, самого файла BlackBox.exe - его самому надо компилировать?

-----

Слинковал сам:

DevLinker.Link
ActiveBlackBox.exe := National Kernel$+ Files HostFiles StdLoader
1 Applogo.ico 2 Doclogo.ico 3 SFLogo.ico 4 CFLogo.ico 5 DtyLogo.ico
1 Move.cur 2 Copy.cur 3 Link.cur 4 Pick.cur 5 Stop.cur 6 Hand.cur 7 Table.cur

При попытке выполнить что-либо, всё-равно ругается:
command error: object Kernel.Detail not found (imported from Details)

Т.е. ядро осталось старым. Чего-то я не понял как новое ядро залинковать в exe?..

А, нашёл... Тот инсталлятор, что я скачал это на самом деле вовсе никакой не инсталятор. Инсталлировать надо как обычно и описано это в документе Docu/Active/General.odc

А всё равно не работает. Установил SP4, поверх него записал Active, слинковал как описано в General, и всё-равно:

command error: object Kernel.ZeroRec not found (imported from DevTaskMan)

Эээ. Верно. Естественно о потоках.

А после компиляции и линковки запускаете ActiveBlackBox.exe?
А то я тоже в начале понять не мог в чем дело. Давно свои проекты не линковал - в среде удобней.

Вот я вижу исходного текста (System)Kernel (Активного) нет. А как же п.3. лицензионного соглашения с OMInc?

Ну для этого я так понимаю надо компилятор править, а это уже слишком.

Я бы описания опасных функций (отладка и прочее) передвинул в отдельный мануал, а в доках по модулям поставил бы в лучших традициях BB "used internally".

И до релиза больше ничего не добавлять!

Конечно.

Я нашёл как победить эту беду!!!
Надо сначала файлы из \System\Code и \System\Sym скопировать просто в \Code и \Sym, вот после этого слинковать, тогда заработает.

А! Документированная Багофича! Так это у вас дублирование получилось. В \Code и \Sym обычно живут модули без подсистем. Плюс туда почемуто компилятся модули \System (точнее известно почему - у них префиксов нет). Получается перекрытие: вначале просматриваются эти папки, а потом \System\*\ .

А, дошло!!! Надо было не копировать туда, а стереть от туда старый Kernel.*

Проверил. Задал для BB соответствие одному процессору. Всё работает. Уже наверно час развлекаюсь, а дело стоит .
Но одна проблемка осталась. Вход / выход с эксклюзивный блок не коррелирует. Гдето пол минуты наблюдал как два шарика гонялись друг за другом, при этом остальные 59 стояли в очереди.

p.s. Ну точно стек.

2O.Nick:
1) По поводу лицензии:
а) все это еще не окончательно, на период работ пока так и т.п.
б) лицензия не противоречит лицензии ББ, т.к. мое ядро не использует модули ББ, наоборот - ББ может использовать мое ядро.
в) по поводу "некорреляции" - так работают семафоры, а семафоры реализованы на WinAPI.QueueAPC, смотрите HostSynch. Другого способа реализовать семафоры пользовательского режима я не знаю... Хотя пока с "корреляцией" не разбирался вообще. Ближе к концу недели повожусь.

2Ivor:
Постепенно было нельзя. Вынести API потоков из ядра также нельзя, т.к. сборщик мусора, обработчик трапов и т.п. не могут работать без доступа к информации о потоках. Процедуры ядра - не просто шлюзы к ВинАПИ, там целая прослойка - диспетчер задач.