incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Smith <>
Subject RE: [FALCON] Logging in an extension program
Date Mon, 24 Sep 2012 17:18:27 GMT
> Where do I pass in and take advantage of the ProblemQuery.

Clients like MXMLC create a ProblemQuery to handle enabling/disabling various kinds of problems
based on configuration options like -show-binding-warnings. I think the ProblemQuery also
handles sorting the problems. Do you need to customize the ProblemQuery to enable and disable
documentation problems?

- Gordon

-----Original Message-----
From: Michael Schmalle [] 
Sent: Friday, September 21, 2012 11:55 AM
Subject: Re: [FALCON] Logging in an extension program

Gordon et al,

I've pretty much figured out that using COMPC as a starting point/inspiration is the way to

I also spent half the day studying the Configuration class and it's siblings. This has shed
a lot of light about how to implement something that will use quite a few compiler arguments.

I've also managed to create my own configuration with flags.

The problems problem, :) also has been solved since the MXMLC class tracks these. Basically
there is a lot of setup to do things using all the functionality available, that is why subclassing
MXMLC is a good idea from the standpoint of a platform ready to go.


Quoting Michael Schmalle <>:

> Hi,
> I'm in the process of porting a documentor using the compiler's model 
> and just wondered about logging.
> I have some logging statements in code etc. and was wondering about 
> the Problems. I know the main framework uses ICompilerProblem API to 
> log, so I am asking what is the correct way for me to handle these?
> ... Where do I pass in and take advantage of the ProblemQuery.
> I have been spending so much time on the documentor code that I still 
> haven't quite figured out when I create a workspace, project and add 
> source files, SWCs that I set up a problems List correctly to get the 
> compiler problems and then be able to add documentor problems on top 
> of the list.
> BTW So far not optimized and completely alpha the program parses, 
> processes and renders the framework, spark projects in 30 seconds 
> using Velocity templates. I still need to port the metadata renders 
> but using my old parser and AST we were taking minutes. The parser is 
> extremely fast.
> In the next week or so I will post up the asdocs created(for you to
> see) and eventually when I get this thing stable and APIs solid I will 
> add it to my whiteboard. The asdocs as it stands are complete copies 
> of the standard asdoc HTML with frames for default.
> I think this program will definitely be usable for a lot of mid users 
> that want a completely extensible documentor solution. The old ASDoc 
> code really scares me. ;-) Also, using a walker/visitor pattern, it 
> should no be a problem to add an XML output module mirroring the one 
> spit out by asdoc so the XSL templates can be used in the future.
> Mike
> --
> Michael Schmalle - Teoti Graphix, LLC

Michael Schmalle - Teoti Graphix, LLC

View raw message