You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Michael Schmalle <ap...@teotigraphix.com> on 2012/09/21 13:25:07 UTC
[FALCON] Logging in an extension program
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
http://www.teotigraphix.com
http://blog.teotigraphix.com
RE: [FALCON] Logging in an extension program
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Yes, this was the idea, the doumentor has a bunch of special options
and messages that might be worth printing for advanced users or
developers but not normal users.
Mike
Quoting Gordon Smith <go...@adobe.com>:
>> 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 [mailto:apache@teotigraphix.com]
> Sent: Friday, September 21, 2012 11:55 AM
> To: flex-dev@incubator.apache.org
> 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 go.
>
> 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.
>
> Mike
>
> Quoting Michael Schmalle <ap...@teotigraphix.com>:
>
>> 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
>> http://www.teotigraphix.com
>> http://blog.teotigraphix.com
>>
>>
>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
RE: [FALCON] Logging in an extension program
Posted by Gordon Smith <go...@adobe.com>.
> 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 [mailto:apache@teotigraphix.com]
Sent: Friday, September 21, 2012 11:55 AM
To: flex-dev@incubator.apache.org
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 go.
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.
Mike
Quoting Michael Schmalle <ap...@teotigraphix.com>:
> 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
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FALCON] Logging in an extension program
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Gordon et al,
I've pretty much figured out that using COMPC as a starting
point/inspiration is the way to go.
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.
Mike
Quoting Michael Schmalle <ap...@teotigraphix.com>:
> 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
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com