ming-devr — a list for ming developers and those interested in ming's guts

Re: [Ming-dev] gotoFrame, gotoAndPlay, gotoAndStop

[strk <st...@ke...>]

Updates on this issue.

I committed a patch dropping special support for 'gotoFrame'.
With current HEAD, gotoFrame(2) will just be a function/method call.

On the other hand, gotoAndPlay and gotoAndStop are either
converted to specific tags (GOTOFRAME, GOTOFRAME2, GOTOLABEL)
or considered method calls:

	gotoAndPlay(3)          ---> GOTOFRAME
	gotoAndPlay("label")    ---> GOTOLABEL
	gotoAndPlay(target)     ---> GOTOFRAME2

	this.gotoAndPlay(<anything>) ---> callMethod

--strk;

On Wed, Feb 21, 2007 at 06:00:38PM +0100, strk wrote:
> 
> Trying to output GOTOFRAME or GOTOFRAME2 tags I found
> out that Ming output those only if using the 'gotoFrame'
> construct, which is NOT a valid ActionScript builtin.
> 
> Also, I found out that some compilers convert 
> gotoAndPlay and gotoAndStop to GOTOFRAME or GOTOFRAME2
> (maybe GOTOLABEL too ?) tags, rather then introducing
> another construct. Dunno how they do to actually output
> a function call to the _global or MovieClip methods.
> 
> Anyway, hard-coding a non-standard gotoFrame() doesn't
> seem a good idea to me. Additionally, it seems there's no
> way to output a GOTOFRAME2 with *play* semantic . Rather,
> when GOTOFRAME2 is output [gotoFrame(<expression>)] it's
> 'play' flag is always set to 0.
> 
> Ideas on how to proceed with these ?
> 
> --strk; 
> 
>  ()   ASCII Ribbon Campaign
>  /\   Keep it simple! 
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Ming-devr mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/ming-devr

-- 

 ()   ASCII Ribbon Campaign
 /\   Keep it simple! 

[Ming-dev] gotoFrame, gotoAndPlay, gotoAndStop

[strk <st...@ke...>]

Trying to output GOTOFRAME or GOTOFRAME2 tags I found
out that Ming output those only if using the 'gotoFrame'
construct, which is NOT a valid ActionScript builtin.

Also, I found out that some compilers convert 
gotoAndPlay and gotoAndStop to GOTOFRAME or GOTOFRAME2
(maybe GOTOLABEL too ?) tags, rather then introducing
another construct. Dunno how they do to actually output
a function call to the _global or MovieClip methods.

Anyway, hard-coding a non-standard gotoFrame() doesn't
seem a good idea to me. Additionally, it seems there's no
way to output a GOTOFRAME2 with *play* semantic . Rather,
when GOTOFRAME2 is output [gotoFrame(<expression>)] it's
'play' flag is always set to 0.

Ideas on how to proceed with these ?

--strk; 

 ()   ASCII Ribbon Campaign
 /\   Keep it simple! 

Re: [Ming-dev] time for a beta4 release ?

[Klaus R. <kla...@rz...>]

On Tuesday 20 February 2007 14:20, strk wrote:
> I've been reported ming-config --version to return an empty string
> with beta3, so I'd like to see a beta4 out.
> Are there unstable changes in the repository making this
> a bad idea ?
beta releases are beta :) 
But everything that worked in beta3 should still work.

>
> Things to do before next release (IMHO):
>
> 	- update the NEWS file

> 	- Add some testcases for the new tags added by klaus 
I'll upload them.

	Klaus

[Ming-dev] time for a beta4 release ?

[strk <st...@ke...>]

I've been reported ming-config --version to return an empty string
with beta3, so I'd like to see a beta4 out.
Are there unstable changes in the repository making this
a bad idea ?

Things to do before next release (IMHO):

	- update the NEWS file
	- Add some testcases for the new tags added by klaus

--strk; 

 ()   ASCII Ribbon Campaign
 /\   Keep it simple! 

[Ming-dev] Ming_setScale for C++ binding ?

[strk <st...@ke...>]

I've seen swftocxx work for the firt time :)
No compile-time errors, and no runtime errors.

Anyway, visual result is wrong, and seems related
to TWIPS or PIXELS (or scale in general).

Here is an excerpt:

...
m->setDimension(550.000000, 400.000000);
...
character1->movePenTo(1380, 0);
character1->drawCurve(0, 572, -404, 404);
character1->drawCurve(-404, 404, -572, 0);
character1->drawCurve(-572, 0, -404, -404);
character1->drawCurve(-404, -404, 0, -572);
character1->drawCurve(0, -572, 404, -404);
character1->drawCurve(404, -404, 572, 0);
character1->drawCurve(572, 0, 404, 404);
character1->drawCurve(404, 404, 0, 572);

You can see that coordinates used in drawing seem
to be in TWIPS, while we need PIXELS to work
with mingpp.h.

Better yet, we'd set a global scale to ensure
we talkg TWIPS, so we don't miss any information
found in the SWF, but I can't find a call
for Ming_setScale() with the C++ wrapper.

Anyone ?


--strk;

[Ming-dev] listswf chokes on openlaszlo generated stuff

[strk <st...@ke...>]

Attached a simple SWF that makes 'listswf' choke.
The sourcecode (buildable with openlaszlo) is as follows:

 <canvas>
  <text>This is some text</text>
  <view bgcolor="red" width="100" height="100"  y="40"/>
 </canvas>

'flasm' decompiles it fine (but yes, it's not an actions problem).

Ming gives:

  Stream out of sync after parse of blocktype 34 (SWF_DEFINEBUTTON2). 155 but expecting 151.
  ...
  Stream out of sync after parse of blocktype 26 (SWF_PLACEOBJECT2). 189 but expecting 193.

Then finally:

  Offset: 193 (0x00c1)
  Block type: 0 (SWF_END)
  Block length: 0
  
  extra garbage (i.e., we messed up in main):
  
  
  0000: 03 00 00 0c 00 08 01 00  01 00 02 00 44 00 00 00    ........ ....D...
  0010: 00 00 1a 00 ff 09 15 00  00 00 04 00 02 00 02 03    ........ ........


--strk;

 ()   ASCII Ribbon Campaign
 /\   Keep it simple! 

Re: [Ming-dev] SWF_assert

[<ham...@t-...>]

>> 
>> 
>> > A solution could be adding a second argument containing
>> > a message, but using a macro for user input checking
>> > seems more appropriate.
>> 
>> How about:
>> 
>> Index: error.c
>> ===================================================================
>> RCS file: /cvsroot/ming/ming/src/blocks/error.c,v
>> retrieving revision 1.11
>> diff -u -r1.11 error.c
>> --- error.c     8 Jul 2006 13:10:55 -0000       1.11
>> +++ error.c     9 Feb 2007 10:44:30 -0000
>> @@ -89,12 +89,7 @@
>>  
>>  
>>  
>> -void
>> -SWF_assert(int c)
>> -{
>> -       if ( !c )
>> -               SWF_error("failed assertion");
>> -}
>> +
>>  
>>  
>>  /*
>> Index: error.h
>> ===================================================================
>> RCS file: /cvsroot/ming/ming/src/blocks/error.h,v
>> retrieving revision 1.7
>> diff -u -r1.7 error.h
>> --- error.h     8 Jul 2006 13:10:55 -0000       1.7
>> +++ error.h     9 Feb 2007 10:44:30 -0000
>> @@ -23,6 +23,8 @@
>>  SWFMsgFunc setSWFWarnFunction(SWFMsgFunc warn);
>>  SWFMsgFunc setSWFErrorFunction(SWFMsgFunc error);
>>  
>> -void SWF_assert(int c);
>> +#define SWF_assert(__condition)                                                
>> \
>> +       if ( !(__condition) )                                                   
>> \
>> +               SWF_error("failed assertion in %s:%i\n", __FILE__,__LINE__);    
>> \
>>  
>>  #endif /* SWF_ERROR_H_INCLUDED */
>> 
>> -------------------------------------------------------------------------

Hi,

this makes debugging ming itself somewhat easier. It does not help users with a precompiled
binary finding errors caused by invalid scripts / data values

Wolfgang

Re: [Ming-dev] tags 63 and 64

[<ham...@t-...>]

tag 63 .... not in swf8 file format

Wolfgang

Re: [Ming-dev] tags 63 and 64

[Klaus R. <kla...@rz...>]

> Does anyone know anything about SWF tags 63 and 64 ?

SWF_ENABLEDEBUGGER2           = 64

I've not seen a tagtype 63 yet.

	Klaus

Re: [Ming-dev] Patch for ming test suite

[strk <st...@ke...>]

I finally installed python and also other interpreters
to check this myself. The provided patch didn't work here.
I committed a simple patch ensuring execute bit is set
to the non-executable builders (it happens for script builders).
Proppy suggested this as the first thing, btw :)

Still, using *built* rather then installed libs is still to
be inspected. The python tests are failing (possibly due
to the used libs).

--strk;

On Sat, Feb 10, 2007 at 07:46:02AM +0100, strk wrote:
> On Fri, Feb 09, 2007 at 07:54:07PM +0000, proppy wrote:
> >       Hi, here is a patch fixing python/perl/php tests runnability
> > against the CVS HEAD. Waiting for reviews and feedbacks.
> 
> Just a quick tought:
> In order to force use of *built* libs, not installed ones, we might
> need to use some switches to PERL,PHP,PYTHON etc.
> If this is the case the check for -r (file existance) of each @testbuildertab
> will not work properly.
> 
> > Thanks in advance.
> 
> Thank you !
> 
> --strk;

[Ming-dev] tags 63 and 64

[strk <st...@ke...>]

Does anyone know anything about SWF tags 63 and 64 ?

--strk;

Re: [Ming-dev] Patch for ming test suite

[strk <st...@ke...>]

On Fri, Feb 09, 2007 at 07:54:07PM +0000, proppy wrote:
>       Hi, here is a patch fixing python/perl/php tests runnability
> against the CVS HEAD. Waiting for reviews and feedbacks.

Just a quick tought:
In order to force use of *built* libs, not installed ones, we might
need to use some switches to PERL,PHP,PYTHON etc.
If this is the case the check for -r (file existance) of each @testbuildertab
will not work properly.

> Thanks in advance.

Thank you !

--strk;

[Ming-dev] Patch for ming test suite

[proppy <pr...@am...>]

       Hi, here is a patch fixing python/perl/php tests runnability
against the CVS HEAD. Waiting for reviews and feedbacks.

Thanks in advance.
-- 
bou ^

Re: [Ming-dev] SWF_assert

[Klaus R. <kla...@rz...>]

> A solution could be adding a second argument containing
> a message, but using a macro for user input checking
> seems more appropriate.

How about:

Index: error.c
===================================================================
RCS file: /cvsroot/ming/ming/src/blocks/error.c,v
retrieving revision 1.11
diff -u -r1.11 error.c
--- error.c     8 Jul 2006 13:10:55 -0000       1.11
+++ error.c     9 Feb 2007 10:44:30 -0000
@@ -89,12 +89,7 @@
 
 
 
-void
-SWF_assert(int c)
-{
-       if ( !c )
-               SWF_error("failed assertion");
-}
+
 
 
 /*
Index: error.h
===================================================================
RCS file: /cvsroot/ming/ming/src/blocks/error.h,v
retrieving revision 1.7
diff -u -r1.7 error.h
--- error.h     8 Jul 2006 13:10:55 -0000       1.7
+++ error.h     9 Feb 2007 10:44:30 -0000
@@ -23,6 +23,8 @@
 SWFMsgFunc setSWFWarnFunction(SWFMsgFunc warn);
 SWFMsgFunc setSWFErrorFunction(SWFMsgFunc error);
 
-void SWF_assert(int c);
+#define SWF_assert(__condition)                                                
\
+       if ( !(__condition) )                                                   
\
+               SWF_error("failed assertion in %s:%i\n", __FILE__,__LINE__);    
\
 
 #endif /* SWF_ERROR_H_INCLUDED */

[Ming-dev] SWF_assert

[strk <st...@ke...>]

Some invalid calls in Ming are using SWF_assert.
What I found (but there are more) is passing
delta args for shape lineTo which needs more then 17 bits
to be encoded.

This kind of error is a programming one, external to ming.
I think using 'assertions' for these kind of error is wrong,
rather we should instruct the developer about the problem
giving as much details as possible.
On the other, Ming internal problems should be handled 
with assertions, and the standard 'assert.h' is much better
then the current SWF_assert.

Simply calling SWF_assert currently only results in
an "failed assertion" printed on stderr and an exit code
!= 0, which is of no much help, even with a debugger.

A solution could be adding a second argument containing
a message, but using a macro for user input checking
seems more appropriate. 

Comments ?

--strk;

 ()   ASCII Ribbon Campaign
 /\   Keep it simple!