flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Heidegger ...@leichtgewicht.at>
Subject Re: Trace & Log
Date Fri, 20 Jan 2012 14:59:56 GMT
First off: THANK YOU! I completely missed out on this feature. It seems 
already doing half of the job necessary.
I will take a quiet hour on the weekend to investigate int 
version/platform availability.

But, Just half of the job means:
It seems as if the arguments get converted to a string which would be a 
no-go. The line number is a good thing, but
the container type would be a more helpful for proper and consistent 
filtering. Also it is not possible to implement a "isEnabled" flag, 
which is essential for logging in big systems.

To sum it up: Nice thing, I will definitely get into it, but from what I 
can judge right now, it is not enough to implement a clean, fast logging.


On 20/01/2012 23:43, Dirk Eismann wrote:
> I just researched the flash.trace.Trace class Alex mentioned and found
> http://blog.sangupta.com/2011/08/magic-of-flashtracetrace.html
> which was blogged by Sandeep (who is on this list as well).
> A quite interesting (undoc'ed) feature that might be handy but I guess
> this is a debug runtime / debug build feature only.
> Dirk.
> 2012/1/20 Dirk Eismann<bortsen@googlemail.com>:
>> I like the idea. I often wished we had logging capabilities for
>> release version SWFs running in release players that are similar to
>> what e.g.. log4j offers for Java applications (the reason it works in
>> Java is that javac by default always compiles debug information for
>> source files and line numbers into class files. They have no concept
>> of a "release build" vs. a "debug build". Different VM, different
>> features)
>> The use case Martin describes (error only happening in release player
>> or only on specific machine configurations usually at the end user /
>> customer) sounds too familiar. The way I handled this was to add some
>> self crafted logging that accumulates log information and on demand
>> sends them away using http... not nice, but works. But it also could
>> be so much better.
>> So I definitely would like to see these logging features Martin
>> sketched up and would be happy to help out.
>> Dirk.

View raw message