удаление trace()
Alex Davydov
Собственно, во Флаше у нас есть галка "Омит трэйс". А вот как флекс0вый
компайлер заставить не включать трейсы в релиз?
В сети встречаются разные методы\рекомендации... Через Ант, через ключи...
Через ключи - категорически не работает.
Кто какие методы юзает? А то для релиза приходиться через Флаш компилить...
Максим Буньков
Максим Буньков
Roma Oskolkov
Яски
(). То что их не видно, не значит что они не делаются.
Нужен другой подход.
Tatyana White
from 'trace'
to '//trace'
w.
--
Татьяна Белая;
флэш экспериментатор;
[http://0xFFFFFF.ru | in...@0xFFFFFF.ru];
Alex Davydov
Вот и я о том же!
Alex Davydov
> from 'trace'
> to '//trace'
Это что ж, каждый раз так релизить? Мука же! Неужеле свича не могли
сделать???
Yuriy Yarovoy
Куда катится мир...
Alex Davydov
> сути тоже просто отдает SDK как раз аргумент debug=false.
Ничего это не меняет.
Все строчечки в СВФ-ку попадают.
Со всеми моими идиотскими комментсами.
Сейчас тольки компиляция через Флаш решает проблему.
С этим надо как-то бороться...
Alex Davydov
Я Вас умоляю! Для чего у нас существуют конфигурации?
В ФДТ, например.
Дебуговые, релизовые.
Для того и существуют, чтоб выставить там все опции для каждой сборки и не
держать себе в голове уже, что надо еще не забыть replace прогнать, а потом
обратно "отогнать".
Для того мы и юзаем все эти билдеры-шмилдеры, чтоб не держать такие вещи в
башке.. И так мозга кипит...
Tatyana White
использования. раздражает когда при
запуске сыпется куча трейсов. поэтому
такой проблемы не имею.
а в случае когда постоянно нужны
трейсы для дебага, лучше написать свою
обертку-консоль, которую можно
включать и выключать и выводить
сообщения в трейс или в текстовое поле.
Yuriy Yarovoy
Alex Davydov
> выводить сообщения в трейс или в текстовое поле.
Сделано..
Юзаю чере SOS:
// -------- SOS
// import mx.logging.ILogger;
// import com.soenkerohde.logging.LogFactory;
// private static const logger :ILogger = LogFactory.getLogger('Main');
// public static var trace :Function = logger.debug;
// ------------
соответственно, можно комментить тольки это участочек, когда хочешь заткнуть
трейсы.
Но это не выход.
Строчки с комментсами все равно остаются, как в случае с debug=false
Alex Davydov
> таковой.
Хм, интересно. Живут же люди..
Я лично без трейсов без своих, как без рук. Т.е., без без глаз. Никак нельзя
удалять! Кроме как в релизе, конечно.
Недавно попался в руки проект одного гражданина.. Вообще без трейсов!!
Был изумлён...
Roma Oskolkov
Со всеми моими идиотскими комментсами.»
Извиняюсь, а разве компилятор не тупо вырезает трэйсы при debug-false? (до компиляции как таковой)
(не говоря уже о том что закомментированные строки и блоки само собой вырезаются).
Dima Pilipenko
Максим Буньков
разберут... то обфускаторить легче..
Alex Davydov
не.. Иначе б я тут не активничал с вопросами...
Alex Davydov
Вроде настраиваемо, поэтому и интересуюсь, кто как проблему решает.
Alex Davydov
Тем, что все мои матюки комментсовые видны.
Тем, что весят до фига.
Релиз без трейсов гораздо меньше по размеру.
Работает, соответственно, тоже быстрее.
Tatyana White
> видны.
ты о комментах..
по-моему увидеть в дебагплеере
сообщение, позывающее путь до ошибки и
соответственно все названия классов
(черт знает как названных) страшнее,
чем мат в комментах, которые тоже не
много кто увидит, а если и увидит, то
может хоть улыбнется.
Alex Davydov
Тогда остается скорость и размер!
Tatyana White
> Тогда остается скорость и размер!
мне смешно :)
а про скорость и размер могу только
повторить на счет find and replace. хотя если
ты делаешь релизы по 10 раз в день - то
этот вариант тебе врядли подходит.
Андрей Скорик
> Был изумлён...
О, Аллах! Дык ведь код надо писать так - чтобы его именно писать, а
не отлаживать.. Когда у вас правильно распределены роли и все
организовано "по путю" локализовать ошибку не составляет труда.. и без
трейсов.
ну может вам понадобится 1-2 раза где-то что-то проверить или вывести....
и в конце концов есть дебаггер. где можно поставить брикпойнт и
посмотреть все значения в рантайме - что дает гораздо больше
информации чем вывод в трейс.
логом пользуюсь в основном в тех случаях когда проблема зависима от
каких-то юзерских действий и/или типа, версии плейера, оси.. что бы
хоть как-то получить информацию о том что делал юзер перед тем как
что-то сломал..
для флексового компилятора есть возможность условной компиляции..
когда вы можете компилить одну версию метода для debug другую для
release...
и еще такой момент :)) в понятие релиз наверное включается не только
релизная swf но и релиз самого кода (сдача заказчику, передача для
поддержки и тд) :)) и тут просто однозначно не должно быть никакого
мусора :)) а должны быть качественные asdoc комменты с описанием
--
С уважением, Скорик Андрей. andrew...@gmail.com
Андрей Скорик
> когда вы можете компилить одну версию метода для debug другую для
> release...
тока вот FDT ее не понимает к сожалению
Nox Noctis
сначала готовит релизную копию проекта, удаляя все обращения к логгеру и
трейсы (хотя у нас просто трейсов практически нет). Т.е. в исходном
коде, который собирается при релизной сборке, логгера вообще нет.
Делать условную компиляцию для всех вызовов логгера -- слишком запарно.
А простые трейсы мы вообще не используем ибо они неуправляемы. Их не
включить не выключить, не отфильтровать по категории/уровню, не
перенаправить в другой лог-таргет и т.д.
Yuriy Yarovoy:
> Полностью солидарен в этом вопросе с Татьяной. Не вижу проблемы как
таковой.
> лично я просто удаляю трейсы после
> использования. раздражает когда при
Это все хорошо, но если проект живет и растет больше года и если в нем
1100 классов и интенсивная работа с сервером (который может чего-то не
прислать, прислать невовремя, прислать в битом виде и т.п.), то вызовы
логгера/трейсы вы навсегда оставите в некоторых местах. И консоль при
работе приложения в отладочном режиме у вас всегда будет заполнена.
Потому что на сотый раз, возвращая стертый до этого трейс в то же место,
где вы уже все отладили, вы решите его там оставить. Предсказываю. :)
--
Michael Antipin
______________________________________________________________________
fe...@noregret.org | http://skazkastudio.ru | http://noregret.org
Denis Kolyako
> Потому что на сотый раз, возвращая стертый до этого трейс в то же место,
> где вы уже все отладили, вы решите его там оставить. Предсказываю. :)
Остальные стираем нахрен.
Ну а логгеры крутятся и в релизе, т. к. часто нужно продиагностировать аппликуху на любой чужой машине.
Денис Коляко
______________________________________________________________________
e...@timezero.ru | http://etcs.ru/ | http://timezero.com/
Nox Noctis
Как бы ни был сделан логгер -- это все равно несколько вызовов и сборка
отладочной строчки. Слишком накладно по производительности для того,
чтобы иногда отладить на чужой машине.
Для отладки у конечных пользователей есть механизм багрепорта, который
отсылает из работающего приложения все данные о его состоянии и скриншот.
Nox Noctis
Дело даже не в том, что часто требуется, а что нет.
Зачем, например, удалять вызовы логгера (ну, про трейсы забудем на
минуту) из блоков catch {}, из валидаций, из проверок условий, которые
определяют аварийные ситуации, и т.п.? Они всегда пригодятся. Если даже
такая ситуация возникнет 2 раза за год -- вот ровно тогда они и окажутся
полезны. То же относится к загрузкам критичных ресурсов, к ключевым
моментам переходов приложения из одного состояния в другое. Если консоль
пустая, но произошло что-то непредвиденное, то мы делаем что? Начинаем
втыкать логи. Хотя в 98% случаев эти логи, конечно, будут всегда
одинаковы и вобщем-то бесполезны.
Однако, что бы там ни происходило, клиентам должна достаться вся
возможная производительность. По крайней мере мы пока не пострадали от
такого подхода. :)
Андрей Скорик
> сначала готовит релизную копию проекта, удаляя все обращения к логгеру и
> трейсы (хотя у нас просто трейсов практически нет). Т.е. в исходном
> коде, который собирается при релизной сборке, логгера вообще нет.
аудитория наполнится звучными аплодисментами если еще покажете что у
вас в в replaceregexp :) для такого дела
Nox Noctis
> вас в в replaceregexp :) для такого дела
Тут, пожалуй, нечему аплодировать, все довольно очевидно.
И у меня есть косяк: если трейс или лог встречается в многострочном
комментарии, то все ломается. Это случается крайне редко, поэтому мне
все лень включить мозг еще раз и подумать, как этого избежать.
<replace-in-files pattern="^(\s*)trace\((.+?)\)\s*[;\n]"
substitution="\1/* trace(\2); */"
dir="${release.source.dir}/${classes.dir}" />
<replace-in-files pattern="^(\s*)Log\.(.+?)\);" substitution="\1/*
Log.\2); */" dir="${release.source.dir}/${classes.dir}" />
<replace-in-files pattern="^(\s*)trace\((.+?)\);" substitution="\1/*
trace(\2); */" dir="${release.source.dir}/${launchers.dir}" />
<replace-in-files pattern="^(\s*)Log\.(.+?)\);" substitution="\1/*
Log.\2); */" dir="${release.source.dir}/${launchers.dir}" />
Nox Noctis
да, забыл напомнить, прежде чем что-то там где-то заменять, стоит
скопировать ресурсы в отдельное место. А то всякое может быть, знаете.
<clean-dir dir="${release.source.dir}" />
<copy-dir dir="${basedir}/${classes.dir}"
todir="${release.source.dir}/${classes.dir}" />
Alex Davydov
А всё потому, что кто-то поленился скопировать процедуру вырезания
trace()-ов из флаш0вого компиллера...
foreground
if (enabled) return;
И не париться :)
Зачем такую тонну сложностей с regExp-ами.
Nox Noctis
> А всё потому, что кто-то поленился скопировать процедуру вырезания
> trace()-ов из флаш0вого компиллера...
Бесценное замечание.
Теперь осталось показать, что и откуда нужно было скопировать. Ну, чтобы
идиотом не показаться. И, конечно, учесть, что мы-то просто патчим
текстовые файлы, а компилятор заранее знает, где у него комментарии, а
где нет. И вообще компилятор понимает структуру кода в отличие от анта,
который не знает и знать не будет, что у него там. Ну, это его работа. В
целом.
foreground
А давайте добъёмся публичной порки этого идиота!
> if (enabled) return;
поправка:
if (!enabled) return;
Nox Noctis
> if (enabled) return;
> И не париться :)
> Зачем такую тонну сложностей с regExp-ами.
Я выше уже писал.
1. хотим убрать вообще исполнение дебаговых инструкций
2. слишком геморно везде вставлять условную компиляцию
Если кто-нибудь предложит более цивилизованный подход к обозначенной
проблеме, я буду только рад и воспользуюсь. (Мне самому модификация
сорса до компиляции кажется варварством, хотя по сути, например,
директивы пред-компиляции вроде define в C именно тому и служат).
Nox Noctis
>> Alex Davydov
> А давайте добъёмся публичной порки этого идиота!
Есть одна проблема: моя довольно грубая реплика была хотя бы по делу, и
относилась непосредственно к теме обсуждения. Она осуждает
поверхностность суждения автора и должна побудить его ответить и
привести фактические доводы в поддержку своего высказывания. Хотя, да,
тон реплики излишне резок для модератора.
Но вот твоя реплика никак к обсуждению не относится и ничего кроме
тролль-феста не порождает. Особенно на фоне твоего не менее дурацкого
предложения решения сабжевой проблемы.
Поэтому я, как модератор, предупреждаю тебя об ответственности за
_преждевременные_ позывы к называнию кого-то дураком или идиотом в
рамках этого достойного во всех отношениях сообщества.
foreground
А замены типа:
trace(. . . ) => ;
не компилятся?
Nox Noctis
Дело ведь в самом подходе.
В том, что мы патчим собственные сорсы до сборки.
И в этом смысле уже все раскрыто.
И с этим можно поспорить или нет.
А вот как именно патчить сорсы и почему один способ лучше другого -- это
уже другой вопрос. И его можно раскрыть.
Евгений Н., не с чем тут завязывать.
Андрей Скорик
немножко в оффтоп... но спрошу - близко к теме..
никто не подскажет как сделать в сценарии многострочный
пользовательский ввод на русском...
треба для комментариев к обновлениям AIR приложения, номера версий
меняются... а вот лезть каждый разв в update.xml для правки коммента -
как-то не климат.. а вот сделать это в Ant у меня не получилось... не
получилось две вещи:
1. сделать input многострочным
2. заставить подставлять русский текст (не подставляется вообще ни
одного символа, остается просто **)
делал примерно так (по памяти)
<target name="notes">
<input
message="примечания к релизу:"
addproperty="vars.notes.input"
defaultvalue="${vars.notes.default}"
/>
</target>
<target name="update">
<replaceregexp file="${file.config.config}"
match="v\s{0,}[0-9]{1,}"
replace="v${build.number}"
byline="true"/>
<replaceregexp file="${file.config.update}"
match="v\s{0,}[0-9]{1,}"
replace="v${build.number}"
byline="true"/>
<replaceregexp file="${file.config.update}"
match="\*[\w\W]{0,}(?=\n]])"
replace="*${vars.notes.input}*"
/>
</target>
Daniil Tutubalin
Например, распространённая конструкция, вывод всех полей объекта:
for (i in obj) trace (i+": "+obj[i]);
При включенном Omit trace actions превратиться в:
for (i in obj);
Выводить, разумеется, ничего не будет, но на производительность всё
равно повлияет.
Denis Kolyako
> substitution="\1/* trace(\2); */"
А swc вы как патчите?
Alex Davydov
Ну дык trace же Вам выдрали успешно!! Чего ж еще желать!
С условным переходом также получается:
var obj:Object = {};
var boo:Boolean = true;
for (var i in obj) trace (i+": "+obj[i]);
if(boo) trace(obj);
Выдает:
this.obj = {};
this.boo= true;
for (this.i in this.obj) { }
if (this.boo) { }
foreground
В таких случаях наверно не только trace в цикле находится. Иначе это
лишний наворот со стороны разработчика я считаю. Такие конструкции
можно не оставлять вовсе.
Nox Noctis
Перед сборкой. :)
Ivan Dembicki
странное обсуждение простого вопроса.
Делается на раз:
Если вы используете стандартный логгер, то достаточно указать уровень
важности лога = none и все упоминания о нем исчезнут в swf. Ну, если
любой другой уровень, то воспоминания о нем останутся везде, где этот
уровень равен или выше указанного.
Вы также можете сделать собственный логгер как языковое расширение и
задать ему аналогичное предкомпиляционное поведение.
И есть еще вариант в ASAnt написать скрипт, который снесёт всё, что скажете.
Единственный недостаток - этими советами могут воспользоваться только
пользователи Realaxy Script Editor.
Эхххх...
Valentin Simonov
>
Единственный
> недостаток - этими советами могут воспользоваться только
пользователи Realaxy
> Script Editor.
Эхххх...
--
я когда мне не лень убиваю трейсы и другие логи антом как Nox сказал
примерно
Ivan Dembicki
есть еще вариант, может кого-то устроит:
не удалять логгер, а заменить его методы на пустышки.
Не думаю, что такие вызовы способны оказать какое-то
влияние на производительность.
Если в вашем проекте они всё-таки оказывают влияние,
то это повод задуматься, а не слишком ли много вызовов
логера использовано?
Андрей Скорик
> Если вы используете стандартный логгер, то достаточно указать уровень
> важности лога = none и все упоминания о нем исчезнут в swf.
Ну это наверное не совсем правда.. у логера обычно есть LogTarget
которая тем или иным образом визуализирует данные получаемые от
лога...(traceTarget - делает обычный trace? просто как-то его
оформляет, чтобы другая часть логера могла понять форматирование, или
например может плевать xml сообщения в сокет так как это сделано в
SOS)
установка уровная лога в NONE - заставит таргет игнорировать сообщения
лога, т.е. не выводить их в трей или в сокет или кудато еще... но сами
вызовы и вся прочая логика сязанная с логом от этого никуда не денется
Ivan Dembicki
> не удалять логгер, а заменить его методы на пустышки.
- в этом раскладе есть еще одна интересная возможность: можно сделать
так, что при необходимости, пользователь нажмет волшебную еомбинацию
клавиш и загрузится всё необходимое, чтобы оживить и показать логгер.
Ivan Dembicki
> Ну это наверное не совсем правда..
- правда-правда. Это вполне обычная и даже очень необходимая
возможность любого расширения ActionScript - можно указать в какую
конструкцию на родном ActionScript он будет трансформирован. Указать,
что данное языковое расширение должно трансформироваться в пустую
строку не представляет никакой сложности.
Nox Noctis
> влияние на производительность.
Любые вызовы хоть копеечку да стоят. А десять старушек -- рубль. Но
главное, что плохо -- это сборка строки которая уходит в логгер. При
этой опервции обычно происходит много всего, куча дополнительных
toString() и т.п.
Ivan Dembicki
> Любые вызовы хоть копеечку да стоят. А десять старушек -- рубль.
- это предположительный подход. Разумеется, бывают разные проекты, в
том числе, где важен каждые пол процента производительности. Но что-то
я таких проектов не встречал за 10 лет своей практики. При тестах
разница в производительности не выходила за рамки статистической
погрешности. И с трудом представляю такую насыщенность логами, которая
может как-то повлиять. Ну, разве что, если специально постараться.
Всё остальное - от лукавого. Желание не только оптимизнуть, но и
выоптимизнуть код - один из 1024-х смертных грехов программиста.
Nox Noctis
> том числе, где важен каждые пол процента производительности. Но что-то
> я таких проектов не встречал за 10 лет своей практики. При тестах
Готов спорить, один такой точно встречал.
Удаление логов при сборке позволяет осталять их в рабочей версии проекта
столько сколько нужно для решения текущих задач. Если, например,
оставить вывод статистики по собранной карте при риалтаймовом
перемещении по ней, разница становится заметна при измерениях.
А логирование такого рода было регулярно нужно до тех пор пока очередная
редакция движка не стала полностью стабильной. При поиске гейзенбагов в
том числе. Удалять логи не приходилось поскольку в релизный билд они все
равно не попадали.
Ivan Dembicki
> [...] Если, например,
> оставить вывод статистики по собранной карте при риалтаймовом
> перемещении по ней, разница становится заметна при измерениях.
- я не предлагаю оставлять as is, а заменять на пустышки.
> При поиске гейзенбагов в том числе.
- неужели такое возможно? :)
Ivan Dembicki
и вот еще в тему, кому не лень:
http://onenterframe.ru/2009/10/29/%D0%BC%D0%B0%D0%BA%D1%80%D0%BE%D1%81%D1%8B-%D0%BA%D0%BE%D0%BC%D0%BF%D0%B8%D0%BB%D1%8F%D1%82%D0%BE%D1%80%D0%B0-actionscript/
foreground
не знаю что такое вы там придумали ("гейзенбагов"), но все эти
манипуляции с релизными сорцами могут вам в результате выйти боком. Вы
получите после оптимизации не тот рабочий код с которым работали в
дебаге.
Nox Noctis
В целом все сводится к одному: мы до сборки редактируем сорсы.
Заменять на пустышки или просто удалять -- уже детали.
Пустышки ведь ничем не лучше простого удаления, если отладочное
сообщение не собирается и не передается.
>> При поиске гейзенбагов в том числе.
> - неужели такое возможно? :)
Хорошо ловить баг, когда известно хотя бы одно из двух: "что" происходит
или "где" происходит. А если известен только сам факт, то иногда
помогает сделать избыточные логи и покурить их. За один сеанс понять
проблему удается не всегда и приходится собирать очередной билд с этими
логами. Ну, то есть, без них. Они же вырезаются.
Nox Noctis
Так я выше писал: слишком запарно везде, где пишешь какое-нибудь
логирование, использовать условную компиляцию. Но можно конечно, спору
нет. Есть еще одна неприятность: FDT не поддерживает такие конструкции
(и, судя по ответам разработчиков, вряд ли будет). Собственно, кроме
Флекс Билдера вроде бы никто и не поддерживает. Поэтому если
использовать условную компиляцию повсеместно, то только ФБ остается.
Ivan Dembicki
> Есть еще одна неприятность: FDT не поддерживает такие конструкции
- я тут поскрипел мозгами и победил ругань в FDT.
Написал в отдельный топик.
Roma Oskolkov
Что-то встроенное во флекс де факто?
Ivan Dembicki
> А что такое «стандартный логгер»?
> Что-то встроенное во флекс де факто?
- ты, видимо, то мое письмо не дочитал до конца, там есть про редактор.