Hi,
Since the last update I'm having problems with the ActionScript bundle and XTrace. All my debugging code now gets printed out in the flash movie rather than in the XTrace window as it used to before.
I think I've done all the necessary steps:
1. Add my folder in the security settings in Flash 2. Fire up XTrace 3. Add the trace argument to mtasc.yaml
Firstly nothing displayed in the preview window. The .swf file ran fine in a browser but not under TextMate. I modified the build script (point c below) to represent the file as a proper URL rather than a file:// path and this worked, but I still don't get any debug out, nor do I get a security warning.
I made a few tweaks to the mtasc build script:
a. Add the command it used to build the swf as a comment in underneath the HTML b. Allow for the 'app' yaml statement to be an array of files rather than a single file c. Allow me to prefix a location to the swf file, such that the output HTML is:
http://localhost/~gaby/game/blah.swf
rather than
/Users/gaby/Sites/game/blah.swf
Which made the preview work.
I'm really stuck here as I found the XTrace output invaluable, whereas the in-swf version is next to useless as the important data always runs off the edge of the movie! Help! I'm going mad!
Gaby
-- Junkets for bunterish lickspittles since 1998! http://www.playr.co.uk/
Gaby,
could you please send me a copy of your project so I can take a look at it? If you can also include your modified command, that would be great.
Please let me know what version of TM you're using...
In the meantime, please take a look at the MTASC Help (Bundles » ActionScript » MTASC » MTASC Help), section 1.3: Debugging, just in case there's some obvious thing you're missing (happens to me all the time : )
The XTrace debugging feature may be removed from the bundle sometime in the future, as you can get pretty much the same results by using Console.app. Take a look at this post http://bomberstudios.com/2007/03/14/how-to-use-consoleapp-for-flash-debugging/ for more information about this (and maybe some more insights on your problems with XTrace)
Hope it helps...
On 11 Jul 2007, at 00:06, Ale Muñoz wrote:
could you please send me a copy of your project so I can take a look at it? If you can also include your modified command, that would be great.
Please find enclosed:

Please let me know what version of TM you're using...
The most recent one that got automatically downloaded I think:
Version 1.5.6 (1405)
In the meantime, please take a look at the MTASC Help (Bundles » ActionScript » MTASC » MTASC Help), section 1.3: Debugging, just in case there's some obvious thing you're missing (happens to me all the time : )
Yep, pretty much done all that, several times over. No joy...
The XTrace debugging feature may be removed from the bundle sometime in the future, as you can get pretty much the same results by using Console.app. Take a look at this post <http://bomberstudios.com/2007/03/14/how-to-use-consoleapp-for- flash-debugging/> for more information about this (and maybe some more insights on your problems with XTrace)
I'll give that a go, thanks! Also, nice to see my addition to asd.rb, the part with the multi-library lookups :)
Gaby
-- Junkets for bunterish lickspittles since 1998! http://www.playr.co.uk/
Gaby,
I've checked your mtasc.yaml and have found the following issues with it:
- you need to change the line that reads "trace: console" to "trace: xtrace" - you don't need to add the path to the MTASC binary unless you are using a custom binary. - depending on how you get your application started, you may be missing a "-main" parameter on your parameters line. So, it should be "params: -mx -keep -main". This is assuming you're using the MTASC default behavior of having the main() method start your app.
Your custom build_with_mtasc.rb looks good to me. I'll test your modifications and see if I can include them on the bundle. Thank you very much : )
Please, let me know if this fixes your problem... I understand the documentation is quite sparse about this issue, and would like to hear your comments ; )
On 11 Jul 2007, at 14:27, Ale Muñoz wrote:
I've checked your mtasc.yaml and have found the following issues with it:
- you need to change the line that reads "trace: console" to
"trace: xtrace"
When it was set to that, I couldn't make any data go into XTrace. I changed it over as I needed to do some debugging quickly.
- you don't need to add the path to the MTASC binary unless you are
using a custom binary.
The path specified in the build script seemed to be wrong so I ended up specifying it explicitly.
- depending on how you get your application started, you may be
missing a "-main" parameter on your parameters line. So, it should be "params: -mx -keep -main". This is assuming you're using the MTASC default behavior of having the main() method start your app.
I took that out as it was of no use to me. I have a whole pile of classes that needed building so I do them all in one file, I have no use for the main() loop in my application.
Your custom build_with_mtasc.rb looks good to me. I'll test your modifications and see if I can include them on the bundle. Thank you very much : )
Glad to be of help. I think they were just a few extra flags that could be set in mtasc.yaml to perform useful things.
The only other problem I had was that TextMate wouldn't preview the .swf file if it was the full path to the file, hence me needing to add the file as a url rather than just a file. I'm not sure what was gong on here as I could play the .swf as a file:// in the browser, but not in TextMate.
Gaby
-- Junkets for bunterish lickspittles since 1998! http://www.playr.co.uk/
Hello, It is kind of frustrating to see the compile window disappear when there are compilation warnings . How do I make it stay on the screen ? (Or go in the background, but stay open at least!)
Thanks,
Maxime Boissonneault
On 7/12/07, Maxime Boissonneault maxime.boissonneault@usherbrooke.ca wrote:
Hello, It is kind of frustrating to see the compile window disappear when there are compilation warnings . How do I make it stay on the screen ? (Or go in the background, but stay open at least!)
Preferences --> Advanced --> Shell Variables: Variable: TM_LATEX_ERRLVL Value: 0 or 1
Or just look at the help of bundle: 3.4 Preview Options
The environment variable TM_LATEX_ERRLVL controls the behavior of the HTML window in the absence of critical errors in the typesetting step. It has three possible values:
2: If a document was successfully built, it will jump directly to the preview. This is the default. 1: If there are any warnings, these are shown, together with a link to the preview. 0: Halt on any errors or warnings, a link to the preview is only included if the document was built. If the document could not be built, then the error messages are always shown regardless of the value of TM_LATEX_ERRLVL.
Niels *who wonders why he's using ERRLVL 3*
Le jeudi 12 juillet 2007 à 22:46 +0200, Niels Kobschätzki a écrit :
On 7/12/07, Maxime Boissonneault maxime.boissonneault@usherbrooke.ca wrote:
Hello, It is kind of frustrating to see the compile window disappear when there are compilation warnings . How do I make it stay on the screen ? (Or go in the background, but stay open at least!)
Preferences --> Advanced --> Shell Variables: Variable: TM_LATEX_ERRLVL Value: 0 or 1
Or just look at the help of bundle: 3.4 Preview Options
This a problem because I work with osx and ubuntu and sometimes I try to compile with TeXshop on OS X or Kile with Ubuntu documents that I have compiled with TexTMate and now the compilation fails. So There are warnings and warnings. A lot of warnings are errors I think the default value of TM_LATEX_ERRLVL is not good because we are not sure of the compilation and we must look at the fic.log in any case
Greetings Alain Matthes
On 7/13/07, Alain Matthes alain.matthes@mac.com wrote:
I think the default value of TM_LATEX_ERRLVL is not good because we are not sure of the compilation and we must look at the fic.log in any case
For what it's worth, I strongly agree.
It is bizarre that the default should be to ignore errors; I've never seen another TeX front-end that behaves like this, and I'm struggling to imagine a situation where ignoring an error is the right thing to do.
Does anyone know why it was done like this in the first place?
Robin
On 7/13/07, Robin Houston robin.houston@gmail.com wrote:
On 7/13/07, Alain Matthes alain.matthes@mac.com wrote:
I think the default value of TM_LATEX_ERRLVL is not good because we are not sure of the compilation and we must look at the fic.log in any case
For what it's worth, I strongly agree.
It is bizarre that the default should be to ignore errors; I've never seen another TeX front-end that behaves like this, and I'm struggling to imagine a situation where ignoring an error is the right thing to do.
The default is not to ignore errors. The default is to ignore warnings, and I remember we debated this quite a bit at the time I wrote the script to parse the output from xxxTeX. Looking at the log, I can see that I changed the script to return a 2 if there were warnings, 1 if there were errors and 0 otherwise way back in may 2005.
If you are saying that there are warnings that are really errors, and there is a way to tell that the warning should be really treated as an error, I would be happy to learn about it and adjust the script. Right now I'm just using a series of regexps to try and pull the important stuff from all the output from pdflatex.
Brad
______________________________________________________________________
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
On 7/13/07, Brad Miller bmiller@luther.edu wrote:
The default is not to ignore errors. The default is to ignore warnings,
Okay, I've tested this a bit more, and I see that it does not always happen. It seems that errors are ignored if $TM_LATEX_PROGRAM or $TEX_PSTRICKS is set.
So I guess this is a bug, rather than a design decision. Sorry for the confusion.
Robin
On Jul 13, 2007, at 9:58 AM, Robin Houston wrote:
On 7/13/07, Brad Miller bmiller@luther.edu wrote:
The default is not to ignore errors. The default is to ignore warnings,
Okay, I've tested this a bit more, and I see that it does not always happen. It seems that errors are ignored if $TM_LATEX_PROGRAM or $TEX_PSTRICKS is set.
So I guess this is a bug, rather than a design decision. Sorry for the confusion.
Indeed, if errors are ignored it is definitely a bug in the script, very likely caused by me in trying to mess with the script. Patches are welcome.
Robin
Haris Skiadas Department of Mathematics and Computer Science Hanover College
On Jul 13, 2007, at 4:22 PM, Charilaos Skiadas wrote:
Indeed, if errors are ignored it is definitely a bug in the script
here's a short example from he log-file:
! Extra }, or forgotten \endgroup. \endbeamer@frameslide ...amer@framepauses}\egroup \ifx \beamer@frametitle @... l.1738 \end{frame}
? ! Emergency stop.
in the source code, \end{frame} is missing. the script ignores this problem completely and produces/shows a pdf-file up to the previous frame.
christoph
Christoph,
Thanks for the example. I have not seen that format for an error message before. But then I have not used beamer very much either.
One more question,
What LaTeX command are you using to typeset your document? When I removed a \end{frame} from my own beamer file and ran it through I got a different error message, but in a format that I look for:
./Beamer/treeApps.tex:7: Argument of \frame has an extra }.
Specifically, the script assumes that file:line:error style messages are enabled... That does not look like it is true in your case.
Brad
On Jul 14, 2007, at 3:00 PM, Brad Miller wrote:
What LaTeX command are you using to typeset your document? When I removed a \end{frame} from my own beamer file and ran it through I got a different error message, but in a format that I look for:
./Beamer/treeApps.tex:7: Argument of \frame has an extra }.
hi brad,
that's what i get when runnning latex from the command line (as expected, latex stops with the ?)
%-------------------------------------------------------- ! Extra }, or forgotten \endgroup. \endbeamer@frameslide ...amer@framepauses}\egroup \ifx \beamer@frametitle @... l.1738 \end{frame}
? %--------------------------------------------------------
the following is from the log file written when i press command+R in textmate (i get pdf-file):
%-------------------------------------------------------- ! Extra }, or forgotten \endgroup. \endbeamer@frameslide ...amer@framepauses}\egroup \ifx \beamer@frametitle @... l.1738 \end{frame}
? ! Emergency stop. \endbeamer@frameslide ...amer@framepauses}\egroup \ifx \beamer@frametitle @... l.1738 \end{frame} %--------------------------------------------------------
in case this is relevant: i load pstricks in the preamble.
if you want me to send you a minimal file, plase let me know.
christoph
On 7/14/07, Christoph Eyrich ceyrich@gmx.net wrote:
in case this is relevant: i load pstricks in the preamble.
Yeah, the error handling doesn't work if PSTricks is detected (among other things).
It shouldn't be too hard to fix; I'll have a look when I get time.
Robin
I think I will also update the log parsing script so that it will warn the user if it does not see a "file:line: error style messages enabled" message in the first few lines of output.
Brad
On 7/14/07, Robin Houston robin.houston@gmail.com wrote:
On 7/14/07, Christoph Eyrich ceyrich@gmx.net wrote:
in case this is relevant: i load pstricks in the preamble.
Yeah, the error handling doesn't work if PSTricks is detected (among other things).
It shouldn't be too hard to fix; I'll have a look when I get time.
Robin
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
-
Alain Matthes -
Ale Muñoz -
Brad Miller -
Charilaos Skiadas -
Christoph Eyrich -
Gaby Vanhegan -
Maxime Boissonneault -
Niels Kobschätzki -
Robin Houston