Thanks for the quick reply. I have made my comments below:
On 3/13/07, Ale Muñoz bomberstudios@gmail.com wrote:
On 3/13/07, Aaron Clinger aaron@aaronclinger.com wrote:
Not sure who to address this to, but I have a few suggestions about how the MTASC compile works in the ActionScript bundle. The new MTASC addition is really great, way better than the one I built for myself, but I do have a few suggestions to make.
Hi there,
I'm the current maintainer of the ActionScript bundle. Suggestions are really welcome :)
- The option to not use XTrace, a lot of Mac Flash developers use
Console and the debug Flash player for this. Right now it seems if no trace is defined it uses XTrace; so there is no way to fall back on the Flash default. Also removing the XTrace class paths if not using them.
The current system for setting up tracers is quite crappy. Thus, it is being re-written from scratch. I plan on adding support for the most common tracers, and also make it easy to add your custom tracer.
In the meantime, you can use a (simple) custom tracer by editing the mtasc.yaml file and adding this line:
trace: com.namespace.for.your.trace.function
The problem is currently there is no way to NOT use a custom trace function without editing the '.rb' file. It defaults to XTrace by default. A lot of Flash developers don't use a custom trace function at all and instead install the debug Flash player from Adobe. When the debug flash player is configured correctly it spits out all trace outputs to a text file on the users system. You can then use Console or 'tail' in Terminal to watch these messages in real time. This is a cross platform option that doesn't require and additional classes or tools and you can debug the same way off a server or locally. So it would be nice to have an option not to remap the trace functions.
Here is a link to the debug players: http://tinyurl.com/lzqp4 A link to an old article: http://tinyurl.com/2delt9 This will create a flashlog.txt at: /Users/YOUR_NAME/Library/Preferences/Macromedia/Flash Player/Logs/flashlog.txt
- The option to easily add additional MTASC arguments in the yaml; for
example '- strict'.
This is a common suggestion. I'll try to add it right now (as in "I have the script open in another TextMate window as I write this" timeframe :)
- The option to NOT include the 'std' and the 'std8' classes.
Could you please elaborate on this?
Sure. The 'std' and 'std8' are just intrinsic classes that MTASC uses for generating compile-time code errors. If you are publishing for Flash 7 you wouldn't want to use the 'std8' classes. That way MTASC would show a warning if you are trying to use Flash 8 features while publishing for 7. The other problem is if you are using a custom version of MTASC or a custom version of the intrinsic classes. Currently the '.rb' file is explicitly pointing to the 'std' and 'std8' folders in the TextMate app; this will create issues if you try to add a -cp to those folders elsewhere.
The simplest way to solve is is by not breaking the MTASC folder structure like it is currently. MTASC by default looks at the directory it lives in for the 'std' and 'std8' folders. So if you move them from the 'lib' directory to the 'bin' directory where MTASC is, the classes will be included as needed. If a user specifies a different location for MTASC it will look there for them there or a user can point MTASC to where they live without causing conflicts.
- '- keep' should not be called by default if a SWF is present. This
could cause some classes to be present two times if also compiled with MTASC. I would suggest allowing the user to add this command in the additional MTASC arguments variable I mentioned above.
I remember having problems with SWF files exported from the Adobe IDE if I didn't -keep them, that's why it's there. If your experience is different and you can shed some light on this, I'll remove it right away.
That could be the case sometimes, like when you are using components etc... Most of the time I only publish from the IDE when I create assets, but I am wanting MTASC to recompile ALL the code. Like stated before if classes are compiled in both MTASC and MMC you might have multiple occurrences of the same class and some of the MTASC error checking wont work etc...
There are cases where you might need to use it, and some where you wouldn't want to. I think it should just be made as an option.
My apologizes if there is currently a way to do any of the above without editing the 'build_with_mtasc.rb'. I would be glad to make the changes myself...
The only way to add your changes is editing the 'build_with_mtasc.rb'
If you ever make a modification of it you want to share, I will happily apply the patch if you send it to me or to the list.
I have made most of these changes already for myself. I would be glad to refine and send them to you if you would like...
Thanks for your suggestions!
Thank you for your response and maintaining the bundle.
best, Aaron Clinger
-- Ale Muñoz http://sofanaranja.com http://bomberstudios.com