flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Coleman <david_coleman_...@hotmail.com>
Subject RE: tracking down where "[trace] null" statements are comming from?
Date Wed, 23 Jan 2013 21:48:55 GMT
yeah, jude, I've tried that override the trace trick... no dice.  trace is a low level keyword

> From: flexcapacitor@gmail.com
> Date: Wed, 23 Jan 2013 15:44:22 -0600
> Subject: Re: tracking down where "[trace] null" statements are comming from?
> To: users@flex.apache.org
> 
> Yeah, Search in Files (CTRL + H in Eclipse) is what I ended up doing in a
> similar situation but I had access to all the libraries.
> 
> It's also a good idea to use TraceTargets, although I haven't used it until
> relatively recently. They let you control the destination of trace
> statements, the level of information (debug, info, error, etc), along with
> source of the call, timestamp and so on.
> 
> Maybe in the next Flex SDK we can override trace (or create an alternative
> like "console") to point to an Application or SystemManager level trace
> target.
> 
> 
> On Wed, Jan 23, 2013 at 3:30 PM, David Coleman <
> david_coleman_007@hotmail.com> wrote:
> 
> > yeah Wayne is right, and another option that *I* find particularly useful
> > is go get the source code for your libraries and copy it into your src
> > folder.  then you only link to the code that you need.  You don't use any
> > more space than you would with a pre-compiled swc (in fact you may use
> > less).  AND you have access to all the black magic voodoo that your
> > libraries might be doing.  In this way it ceases to become voodoo and
> > becomes your code to tweak and polish to meet your specific needs.  There
> > are no real licensing concerns with this approach since using the swc in
> > the first place already places you in a position of dependency on your eula
> > for that particular package.
> >
> > This way you can do as Wayne suggests and simply search for the trace in
> > the code and comment it!  :-)  And you now have full a-z control over your
> > application's code.  Two birds, one stone = 1 happy developer.
> >
> > > Subject: Re: tracking down where "[trace] null" statements are comming
> > from?
> > > From: waynestudley@me.com
> > > Date: Wed, 23 Jan 2013 21:17:55 +0000
> > > To: users@flex.apache.org
> > >
> > > Quick question - are your components linked swc's / ane's etc or
> > imported classes (as in a bunch of .as files)?
> > >
> > > If it's the latter you can use a tool like EasyFind (for Mac - no idea
> > what a PC equivalent is) to search inside the files for any 'trace' strings.
> > >
> > > If the components are compiled swc's then you're going to have a tough
> > time omitting the trace but I'm guessing it'll be somewhere in an imported
> > .as file.
> > >
> > > Hope this helps?
> > >
> > > Wayne
> > >
> > > On 23 Jan 2013, at 21:00, "christofer.dutz@c-ware.de" <
> > christofer.dutz@c-ware.de> wrote:
> > >
> > > > Gee ... I really hoped this would work, cause it looked like the type
> > of AS voodoo I was hoping to find.
> > > > So I created a file "trace.as" and pasted in your code. IntelliJ
> > jumped to the right place, but the breakpoint was not hit.
> > > > In order to try if defining functions this way worked, I added the
> > same function (called "lalala" in a file called "lalala.as") and called
> > both functions from initializing code ... lalala was hit, trace wasn't ...
> > so I guess this hack was a good idea, but it didn't work :-(
> > > >
> > > > Decompiling is problematic, as the Flexicious components have a copy
> > protection and decompiling that code would result in me losing my license
> > ... I don't want to risk this after paying that much money for it ;-)
> > > >
> > > > Well I think I'll simply live with the trace statements :-|
> > > >
> > > > But thanks anyway,
> > > >  Chris
> > > >
> > > >
> > > > -----Urspr√ľngliche Nachricht-----
> > > > Von: Gordon Smith [mailto:gosmith@adobe.com]
> > > > Gesendet: Mittwoch, 23. Januar 2013 19:02
> > > > An: users@flex.apache.org
> > > > Betreff: RE: AW: tracking down where "[trace] null" statements are
> > comming from?
> > > >
> > > > Isn't trace() is just a public function in the unnamed package? I'd
> > try putting a file with
> > > >
> > > > package
> > > > {
> > > >   public function trace(...args):void
> > > >   {
> > > >       var i:int = 0; // set breakpoint here
> > > >   }
> > > > }
> > > >
> > > > on the source path. Then mxmlc should find this trace() instead of the
> > trace() in playerglobal.swc. But I've never tried monkey-patching a
> > non-method, or anything that is native.
> > > >
> > > > - Gordon
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Alex Harui [mailto:aharui@adobe.com]
> > > > Sent: Wednesday, January 23, 2013 9:56 AM
> > > > To: users@flex.apache.org
> > > > Subject: Re: AW: tracking down where "[trace] null" statements are
> > comming from?
> > > >
> > > > I'm not sure how to do that.
> > > >
> > > > But consider this: When the flex tool chain creates a SWF in release
> > mode, it cleans out trace statements, so whatever is spitting a trace has
> > debug code in it.  The swfdump decompiler will certainly show you what SWFs
> > have debug code in it.
> > > >
> > > > Then, I generally use divide and conquer by placing breakpoints and
> > seeing if the flashlog.txt has the trace in it.  But once you get to a
> > "reasonable"
> > > > boundary around the area, you can also use the poorly documented
> > flash.trace.Trace to dump all function calls leading up to the trace
> > statement.
> > > >
> > > > On 1/23/13 9:48 AM, "Gordon Smith" <gosmith@adobe.com> wrote:
> > > >
> > > >> Is it possible to monkey-patch trace() to substitute your own version,
> > > >> and set a breakpoint in it?
> > > >>
> > > >> - Gordon
> > > >>
> > > >> -----Original Message-----
> > > >> From: Michael Montoya [mailto:montoyland@gmail.com]
> > > >> Sent: Wednesday, January 23, 2013 4:02 AM
> > > >> To: users@flex.apache.org
> > > >> Subject: Re: AW: tracking down where "[trace] null" statements are
> > > >> comming from?
> > > >>
> > > >> Hey Chris,
> > > >>
> > > >> This may be a long shot, but how about using a an swf decompiler?
I
> > > >> remember ising Trillix awhile back and was very impressed by the
> > > >> amount of detail provided in the diagnostics - It may pinpoint the
> > > >> source of your trace statement...
> > > >>
> > > >> Cheers!
> > > >>
> > > >> On Jan 23, 2013, at 11:46 AM, "christofer.dutz@c-ware.de"
> > > >> <christofer.dutz@c-ware.de> wrote:
> > > >>
> > > >>> Hi Omar,
> > > >>>
> > > >>> thanks for that input ... I knew that "trace" is a Flash function.
 I
> > > >>> was simply hoping for some guru here to give me a hint to the
> > > >>> "ultimate way to debug this" ;-) As it would help quite a lot
...
> > > >>> especially when having AMF serialization/deserialization problems
> > > >>> (The other type of problems that seem to be really hard to debug)
> > > >>>
> > > >>> Chris
> > > >>>
> > > >>> -----Urspr√ľngliche Nachricht-----
> > > >>> Von: Omar Gonzalez [mailto:omarg.developer@gmail.com]
> > > >>> Gesendet: Mittwoch, 23. Januar 2013 11:00
> > > >>> An: users@flex.apache.org
> > > >>> Betreff: Re: tracking down where "[trace] null" statements are
> > comming from?
> > > >>>
> > > >>> On Wednesday, January 23, 2013, christofer.dutz@c-ware.de wrote:
> > > >>>
> > > >>>> Unfortunately I can't set a breakpoint to the "trace" function
...
> > > >>>> perhaps it would be good if in future versions of flex there
would
> > > >>>> be the means to somehow do this.
> > > >>>>
> > > >>>> Chris
> > > >>>
> > > >>> The trace() function is not a method from Flex it comes from Flash
> > player.
> > > >>> There really isn't anything that can be done at the Flex level.
> > > >>>
> > > >>> I would try to get source code for your 3rd party libraries  and
> > > >>> search for trace statements. If the source isn't available then
> > > >>> you're probably out of luck. Or you can try a decompiler.
> > > >>>
> > > >>> Also, I don't know enough about Adobe Scout but maybe that could
help
> > > >>> you narrow it down.
> > > >>>
> > > >>> -omar
> > > >
> > > > --
> > > > Alex Harui
> > > > Flex SDK Team
> > > > Adobe Systems, Inc.
> > > > http://blogs.adobe.com/aharui
> > > >
> > > >
> > >
> >
> >
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message