Всем привет!
Ситуация следующая: Пытаюсь "раздеть" образ для публикации приложения отдельно от среды разработки. Использую стандартный инструмент - Runtime Packager. Процесс публикации проходит без сучка и задоринки. Но при попытке выполнить результирующий образ - VM виснет наглухо. Смотрю error.log появившийся при попытке запуска: там тьма тьмущая вот таких записей: ... Caught error "target file not writable" when logging to changes file; entry not logged. Caught error "target file not writable" when logging to changes file; entry not logged. Caught error "target file not writable" when logging to changes file; entry not logged. ... Все эксперименты с настройками пакаджера ни к чему не приводят. Начинаю гуглить. Результат: На сайте цынкома обнаруживается резолюшен No.98776 (http://www.cincomsmalltalk.com/ResolutionsApplication/ CincomResolutionsPortal) VisualWorks 7.7.1 98776 Problem Description: RuntimePackager creates massive Transcript output (Caught error "target file not writable" when logging to changes file). Resolution Text: Method SourceFileManager>>noTargetForWrites checks whether output to the changes file has a chance to get written. It returns true if no changes file is associated or if the file is not writable. The method is called by all methods that create changes file output. Senders do not proceed with logging output in the changes file is not ready. With VisualWorks 7.7 this method has changed. A Transcript message is issued whenever the changes file is not ready. This is not appropriate for Runtime Packaging where the changes file is discarded by default. The solution is a patch of SourceFileManager>>noTargetForWrites such that only real exceptions during access to the changes file or the not- writable condition are reported in the Transcript. The "no changes file" case is regarded as "normal" and will not be reported. И предлагается скачать заплатку с закрытого ftp. Доступ к которому предоставляется, после регистрации, "действующим клиентам". Поскольку я являюсь обладателем NC(Non-Commrcial) версии, то пачь мне видимо не полагается. ( Есть ли среди читающих сие, люди знающие как обойти данную проблему? Ну, или может кто, этой самой заплаткой заделится? Буду премного благодарен! -- http://groups.google.ru/group/sugr |
CONTENTS DELETED
The author has deleted this message.
|
Хотелось бы, конечно, таким образом разрешить ситуацию, чтобы больше о
ней не вспоминать. Поэтому "лобовой вариант" нежелателен, т.к. придется ковырять noTargetForWrites каждый раз перед публикацией. Буду копать в направлении отключения вывода в файл изменений (*.cha) в рантайм режиме. Только, на данный момент, мне не хватает квалификации, чтобы самостоятельно во всем разобраться. Не подскажете ли, методологию определения runtime mode? Ведь это по сути тот-же самый образ, что и раньше, только без "лишних" классов. Спасибо. On 22 дек, 12:47, Владимир Мусулайнен <[hidden email]> wrote: > Ну можно и самим пошаманить. > > Из контекста понятно, что проблема в методе > SourceFileManager>>noTargetForWrites > > Вариант лобовой - при подготовке райнтайм просто оверрайдим этот > метод так, чтобы в транскрипт никогда ничего не выводилось. > Если ломовой прием не подходит, то можно выводить что-то в транскрипт, > только если мы не в runtime mode. > Ну другие рецепты по вкусу можно применить. > > mva > > On Dec 22, 12:36 pm, A_Miller <[hidden email]> wrote: > > > Всем привет! > > > Ситуация следующая: Пытаюсь "раздеть" образ для публикации приложения > > отдельно от среды разработки. > > Использую стандартный инструмент - Runtime Packager. Процесс > > публикации проходит без сучка и задоринки. > > Но при попытке выполнить результирующий образ - VM виснет наглухо. > > Смотрю error.log появившийся при попытке запуска: там тьма тьмущая вот > > таких записей: > > ... > > Caught error "target file not writable" when logging to changes file; > > entry not logged. > > Caught error "target file not writable" when logging to changes file; -- http://groups.google.ru/group/sugr |
CONTENTS DELETED
The author has deleted this message.
|
In reply to this post by AMiller
CONTENTS DELETED
The author has deleted this message.
|
Вы оказались совершенно правы. Причина зависания, совершенно в другом.
Был невнимателен и поспешил с выводами, каюсь. Я исходил из того предположения, что к зависанию приводит попытка записи в несуществующий файл изменений. На деле всё оказалось несколько иначе. Пойду учить мат-часть. Большое спасибо за быстрые и точные ответы. On 22 дек, 15:14, Владимир Мусулайнен <[hidden email]> wrote: > И да, данный резолюшн не исправит проблему, почему образ виснет. > Резолюшн решает только проблему не выводить в транскрипт сообщений по > каждому чиху. > Если только вы не изменяете образ в рантайм режиме. > > mva -- http://groups.google.ru/group/sugr |
Курение документации ни к чему не привело, воз и поныне там. В связи с
чем, вынужден снова обратится за помощью к глубокоуважаемым участникам данной группы. Мне так и не удалось создать ни одного работающего runtime-образа. Сначала грешил на изменения которые я внес в систему, но затем, решив убедится в этом, попробовал сгенерировать образ на основе примера из документации, а именно RuntimePackager.RuntimeExample. И, вуаля, получил один - в один, точно такой-же лог. Перечитал еще раз всё, что мне доступно про создание рантайма. Вроде там и ошибиться-то не где... ==2010/12/25==7:53:47==BEGIN RUNTIME DIAGNOSTIC DUMP Note: this file stored in VisualWorks #source (UTF-8) encoding Cause of Dump: Unhandled exception: The identifier Store.Glorp.StoreRefactoringBrowser has no binding Image Identification: 'Image created 24 декабря 2010 г. 19:57:55' Smalltalk Version: 'VisualWorks(R) NonCommercial, 7.7.1 of 26 июля 2010 г.' Object Memory versionId: #[68 47 68 224 77 1 0 0 68 47 68 224] Class creating this dump: RuntimeFullDumper Command Line: C:\Users\Miller\Desktop\tester.exe ------------------------------------------------------------ Active Process Process named: 'Unnamed Process' Process priority: 100 Process identity hash: 984 Context Stack: [1] LiteralBindingReference(Object)>>error: [2] LiteralBindingReference(GeneralBindingReference)>>binding [3] LiteralBindingReference(GeneralBindingReference)>>value [4] SystemEventInterest class>>notifyStoreBrowser [5] SystemEventInterest(AbstractSystemEventInterest)>>trigger [6] SystemEventInterest(AbstractSystemEventInterest)>>triggerIfInterestedIn: [7] optimized [] in SystemEventInterest class>>notifyDependenciesForEvent: [8] SortedCollection(OrderedCollection)>>do: [9] SystemEventInterest class>>notifyDependenciesForEvent: [10] AbstractSystemEventInterest class>>signalEvent: [11] EarlyInterestNotificationSystem>>setUp [12] EarlyInterestNotificationSystem(Subsystem)>>runActivationActions [13] EarlyInterestNotificationSystem(Subsystem)>>privateActivate [14] EarlyInterestNotificationSystem class(Subsystem class)>>activate [15] EarlyInterestNotificationSystem class(Subsystem class)>>reactToEvent: [16] optimized [] in Subsystem class>>signalEvent:to: [17] Set>>do: [18] Subsystem class>>signalEvent:to: [19] Subsystem class>>signalEvent: [20] Snapshot>>signalSystemEvent: [21] Snapshot>>postSnapshotBootstrap [22] Snapshot>>privateSnapshot [23] optimized [] in [] in Snapshot>>snapshot [24] BlockClosure>>ensure: [25] Cursor>>showWhile: [26] optimized [] in Snapshot>>snapshot [27] BlockClosure>>ensure: [28] Snapshot class>>withSnapshot:do: [29] Snapshot>>snapshot [30] ObjectMemory class>>snapshotAs:thenQuit:withLoadPolicy: [31] RuntimePackager.RuntimeManager class>>doOneStepFinalImageSave [32] RuntimePackager.RuntimeManager class>>createAndSaveFinalImage [33] optimized [] in RuntimePackager.RuntimeStartupController>>unboundMethod [34] BlockClosure>>on:do: [35] optimized [] in Process class>>forBlock:priority: Понятно, что происходит обращение к классу Store.Glorp.StoreRefactoringBrowser который был удален при зачистке образа. Не понятно - кто, а главное ЗАЧЕМ, его вызывает при попытке запустить образ. В общем: спасите и помогите! -- http://groups.google.ru/group/sugr |
CONTENTS DELETED
The author has deleted this message.
|
Большое вам спасибо! Всё заработало.
Не ожидал от VW такого подвоха, первое впечатление было очень положительное: быстрая, удобная и стабильная IDE. К стати, о скорости: на просторах интернета бытует мнение, что у VW самая шустрая виртуальная машина из всех текущих реализаций SmallTalk'a. Так ли это? Очень интересно ваше мнение на этот счет, как человека, по видимому, имеющего обширный опыт в использовании VW. И если позволите, еще вопрос: где можно почерпнуть, такой порой необходимой информации, как формат exeption-дампов? -- http://groups.google.ru/group/sugr |
CONTENTS DELETED
The author has deleted this message.
|
Элиот Миранда грозился обогнать VW на Cog :)
25.12.10, Владимир Мусулайнен<[hidden email]> написал(а): > > > On 25 дек, 10:45, A_Miller <[hidden email]> wrote: >> Не ожидал от VW такого подвоха, первое впечатление было очень >> положительное: быстрая, удобная и стабильная IDE. > > Бяка появилась только в версии 7.7.1 > Я думаю, что они сами не ожидали/не предусмотрели такого подвоха. > В остальном вроде все ок. > >> К стати, о скорости: на просторах интернета бытует мнение, что у VW >> самая шустрая виртуальная машина из всех текущих реализаций >> SmallTalk'a. Так ли это? > > Ну, в общем, да. Я не использовал VisualAge, GNU smalltalk, но по > сравнению с Squeak/Pharo - да быстрее. > Ответ, наверное, был бы более многогранен, если вспомнить, про чисто > виндовые реализации smalltalk, например, > Dolphin ST или MT Smalltalk http://www.objectconnect.com/. Они могут > быть и быстрее на виндах, особенно при работе с UI. > Но, если рассматривать мультиплатформенные решения, VisualWorks > быстрее. > > >> И если позволите, еще вопрос: где можно почерпнуть, такой порой >> необходимой информации, как формат exeption-дампов? > > э-э, только из реализации класса ErrorDumper (или RuntimeFullDumper). > > mva > > -- > http://groups.google.ru/group/sugr -- http://groups.google.ru/group/sugr |
Free forum by Nabble | Edit this page |