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

Re: [Ming-dev] Future Stable vs Development branches?

[Justin C. <ju...@sa...>]

Klaus Rechert wrote:
> Hi,
> 
> current CVS is pretty stable. One major point preventing a final release is 
> getting the language bindings in sync. There are good chances that 
> synchronizing the bindings and the main lib is done by end of this month. 

Hi Klaus,

It's nearly the end of the month.

Are we ok to do a (stable) release in the next few days? :)

Regards and best wishes,

Justin Clift

-- 
Salasaga  -  Open Source eLearning IDE
               http://www.salasaga.org

Re: [Ming-dev] SWFShape_setLineStyle deprecated?

[Klaus R. <kl...@re...>]

Hi,

first the width value of a LineStyle structure is a 16 bit unsigned int 
value.

SWFShape_setLine() takes an unsigned short value which is multiplied by 
Ming_scale. With a scale value of 20.0 (default) the result should be 
equivalent to a pixel.

SWFShape_setLine2[filled]() creates LineStyle2 structures.

For low-level access SWFLineStyle[2] objects could be used, where the 
width value is interpreted as TWIPS. The associated SWFShape methods 
aren't in CVS yet... thats also why i deprecated

void SWFShape_setLineStyle(SWFShape shape, unsigned short width, byte r, 
byte g, byte b, byte a)

I hope this helps
    Klaus


strk schrieb:
> Just to ping out this thread.
> I happen to need subpixel accuracy for stroke thickness for Gnash testing,
> and see the issue is still open.
> SWFShape_setLine() [ the non-deprecated one ] still takes int...
> Is it expected to be Ming_setScale-sensitive ?
>
> --strk;
>
> On Mon, Jan 14, 2008 at 04:53:43AM +1100, Justin Clift wrote:
>   
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> strk wrote:
>> <snip>
>>     
>>>> As you mentioned correctly the comment / help for the above function is wrong. 
>>>> Width is used as pixel value and not as TWIPS.
>>>>
>>>> Some time ago there was a discussion how to handle this: use always pixel 
>>>> values or use always TWIPS values. Current ming is a little bit chaotic here. 
>>>>         
>>> Part of the chaos is using the ming's "scale" isn't it ?
>>> Ming_setScale() changes interpretation of all to/from user values, defaulting to 20,
>>> correct ?
>>>
>>>       
>>>> I would propose the following solution: change all values from or to users in 
>>>> TWIPS and introduce a SWF_PIXEL() macro allowing users passing pixel values.
>>>>
>>>> This change will probably break some existing user code, but it is easily 
>>>> fixable and from now on the behavior of the library is easily documentable 
>>>> and predictable by users.
>>>>
>>>> Comments ? 
>>>>         
>>> We surely want to allow specifying subpixel accuracy.
>>> What I was used to do in the past is call Ming_setScale(1) to obtain
>>> this...
>>>       
>> Ahhhh.  One of those No Clear Answer things.
>>
>> Sound like for end users either approach would work, but it would be
>> really beneficial to have One Consistent Approach all around.
>>
>> For developers, leaving it "as is" is probably most efficient. ;->
>>
>> Heh.
>>
>> For me, I don't really care at this point.  I just want us to get a
>> non-beta (i.e. Release) version out the door, even if it's not perfect,
>> as that will let distributions package it and provide it.
>>
>> I mostly use Gentoo Linux, and the most recent "stable" version for that
>> version is... 0.2a.
>>
>> (Yeah, *ugh*.)
>>
>> So, I like Klaus's idea but it sounds like it could be quite a lot of
>> change, and quite a lot of work to "get right".
>>
>> ?
>>
>> Regards and best wishes,
>>
>> Justin Clift
>>
>>     
>>> --strk;
>>>       
>> - --
>> The Flame Project - Open Source GUI for animated SVG & Flash
>> http://www.flameproject.org
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.7 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>
>> iD8DBQFHilAnFAuZn5lS2IMRAulfAJ9V/I5XRHC+YPHyXQsiFS47iJkSpwCgvBtB
>> V+cYM7zmqXFkelSbbJPKt0U=
>> =QRK/
>> -----END PGP SIGNATURE-----
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>> _______________________________________________
>> Ming-devr mailing list
>> Min...@li...
>> https://lists.sourceforge.net/lists/listinfo/ming-devr
>>     
>
>   

Re: [Ming-dev] SWFShape_setLineStyle deprecated?

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

Just to ping out this thread.
I happen to need subpixel accuracy for stroke thickness for Gnash testing,
and see the issue is still open.
SWFShape_setLine() [ the non-deprecated one ] still takes int...
Is it expected to be Ming_setScale-sensitive ?

--strk;

On Mon, Jan 14, 2008 at 04:53:43AM +1100, Justin Clift wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> strk wrote:
> <snip>
> >> As you mentioned correctly the comment / help for the above function is wrong. 
> >> Width is used as pixel value and not as TWIPS.
> >>
> >> Some time ago there was a discussion how to handle this: use always pixel 
> >> values or use always TWIPS values. Current ming is a little bit chaotic here. 
> > 
> > Part of the chaos is using the ming's "scale" isn't it ?
> > Ming_setScale() changes interpretation of all to/from user values, defaulting to 20,
> > correct ?
> > 
> >> I would propose the following solution: change all values from or to users in 
> >> TWIPS and introduce a SWF_PIXEL() macro allowing users passing pixel values.
> >>
> >> This change will probably break some existing user code, but it is easily 
> >> fixable and from now on the behavior of the library is easily documentable 
> >> and predictable by users.
> >>
> >> Comments ? 
> > 
> > We surely want to allow specifying subpixel accuracy.
> > What I was used to do in the past is call Ming_setScale(1) to obtain
> > this...
> 
> Ahhhh.  One of those No Clear Answer things.
> 
> Sound like for end users either approach would work, but it would be
> really beneficial to have One Consistent Approach all around.
> 
> For developers, leaving it "as is" is probably most efficient. ;->
> 
> Heh.
> 
> For me, I don't really care at this point.  I just want us to get a
> non-beta (i.e. Release) version out the door, even if it's not perfect,
> as that will let distributions package it and provide it.
> 
> I mostly use Gentoo Linux, and the most recent "stable" version for that
> version is... 0.2a.
> 
> (Yeah, *ugh*.)
> 
> So, I like Klaus's idea but it sounds like it could be quite a lot of
> change, and quite a lot of work to "get right".
> 
> ?
> 
> Regards and best wishes,
> 
> Justin Clift
> 
> > --strk;
> 
> - --
> The Flame Project - Open Source GUI for animated SVG & Flash
> http://www.flameproject.org
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFHilAnFAuZn5lS2IMRAulfAJ9V/I5XRHC+YPHyXQsiFS47iJkSpwCgvBtB
> V+cYM7zmqXFkelSbbJPKt0U=
> =QRK/
> -----END PGP SIGNATURE-----
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Ming-devr mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/ming-devr

-- 

 ()   ASCII Ribbon Campaign
 /\   Keep it simple! 

[Ming-dev] Sprite / Movieclip Objects in Perl and other languages

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

Hi,

currently Sprites and MovieClips are available in language wrappers. 
Both classes are equivalent and usually realized as an alias.

Removing silently a public interface which has been part of ming for a 
long time isn't a good idea. Having two object types for the same thing 
isn't a good idea neither. Therefore the users should be warned when 
using a deprecated interface to give some time to adopt the code (1-2 
releases maybe).

I've just re-added the SWF::Sprite perl module. But we need a perl 
hacker to add a deprecation message if using SWF::Sprite. Any volunteers 
? Or just some hints how to do it ?

Cheers
    Klaus

[Ming-dev] Anyone built Ming on a BSD system lately ?

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

Anyone built Ming on a BSD system lately ?
If so, could you tell us what's the libming.so full
name when installed ?

--strk;

 ()   ASCII Ribbon Campaign
 /\   Keep it simple! 

Re: [Ming-dev] Salasaga works with Ming 0.3.0 now

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

Hi Justin,
> After several nail-biting hours of coding, testing, retesting, more nail 
> biting, etc... Salasaga now works with Ming 0.3.0.
>   
Good to hear that. Are there any special issues which should be fixed 
before releasing 0.4-final to make transition from 0.3 easier?

    Klaus

[Ming-dev] Salasaga works with Ming 0.3.0 now

[Justin C. <ju...@sa...>]

Hi all,

After several nail-biting hours of coding, testing, retesting, more nail 
biting, etc... Salasaga now works with Ming 0.3.0.

That should avoid a bunch of problems. :)

As a side benefit, the swf output also seems to play ok with Gnash 0.8.2 
as well.

Will release a new development snapshot of Salasaga soon.  Found a 
difference in the fade vs movement behaviour in the main display that 
should get fixed first.  Not related to Ming version. ;->

Regards and best wishes,

Justin Clift

-- 
Salasaga  -  Open Source eLearning IDE
               http://www.salasaga.org

Re: [Ming-dev] Future Stable vs Development branches?

[Justin C. <ju...@sa...>]

(re-post after accidentally replying only to Klaus - Sorry Klaus)

Klaus Rechert wrote:
 > Hi Justin,
 >
 > I see your point but I still have some concerns:
<snip>
 > If you develop for some time only in CVS the next release (say 0.5 or 
0.6) will be a bumpy ride for developers and also for users. The 
problems you experience right now are caused by exactly the same 
release/development process you propose.

Yep, but I think the main difference here is that from the 0.4.x 
*release version* (0.4.1?) onwards, there will be enough features in it 
that _most_ apps won't need to be on the "development stream" 0.5.0.

Sure, cutting edge ones will, and they're going to have no choice but to 
keep with more cutting edge code.

But that won't be the majority of things using Ming.


 > Ming 0.3 is old and (kind of) stable. Very few release were made in 
between. So it was difficult to propagate changes and give users time to 
adopt.

Agreed.  It's going to be a fairly large transition in this instance. :(

As an aside, earlier today I started looking at moving Salasaga to use 
Ming 0.3.0 instead.  Wow a lot of stuff has changed between 0.3.0 and 
even beta5. (sigh)


 > But currently *any* release style is better then the current one.

Heh.  Oh, we *have* a release style at the moment? ;->


 > Thanks for caring that much about MING!

No worries.

Its in my direct best interest -> need something to produce swf for 
Salasaga. :)

Regards and best wishes,

Justin Clift

 >    Klaus


-- 
Salasaga  -  Open Source eLearning IDE
               http://www.salasaga.org

Re: [Ming-dev] Future Stable vs Development branches?

[Klaus R. <kl...@re...>]

Hi Justin,

I see your point but I still have some concerns:

Currently I care a lot not breaking stable interfaces. Some interfaces 
will be removed in the future. Using these interfaces will issue a 
compiler warning and people have time to adopt.

If you develop for some time only in CVS the next release (say 0.5 or 
0.6) will be a bumpy ride for developers and also for users. The 
problems you experience right now are caused by exactly the same 
release/development process you propose.
Ming 0.3 is old and (kind of) stable. Very few release were made in 
between. So it was difficult to propagate changes and give users time to 
adopt.

But currently *any* release style is better then the current one.

Thanks for caring that much about MING!
    Klaus
> Klaus Rechert wrote:
> <snip>
>   
>> IMHO doing small and frequent releases is the better way. If there are new 
>> features available people should use them instead of waiting until the whole 
>> dev-cycle is finished. Otherwise we would end up in a similar situation with 
>> a very old "stable" release and a huge pile of new code in CVS with very few 
>> active users. 
>>     
>
> Hi Klaus,
>
> Have had some time to think about this, and am now pretty sure that's 
> *not* the approach we should be using for Ming. (specifically)
>
> The reason I'm thinking this way, is that since Ming is a library, its 
> real target market is other applications.  i.e. PHP, Salasaga, etc.
>
> Applications generally need something stable they can rely on.
>
> Ming has had a capable feature set for a while now (in the 0.4.0 series 
> at least), so many apps are only going to need stuff in there.
>
> When Ming has a "stable" 0.4.0, if we keep development in a 0.5.0 
> branch, then most applications can rely on Ming to work.
>
> However, if we keep on introducing changes to the 0.4.0 stream as part 
> of our standard dev process, we're *going* to break things for the apps 
> using Ming.  Even if unintentional and accidentally.
>
> I reckon that if we want Ming to be more widely used, that's not a 
> workable way to do things.
>
> Learning this pretty much first hand with Salasaga btw, so not just 
> speaking "in theory".  When I've coded Salasaga to work with Ming 0.4.0, 
> I expect it to *keep* working with Ming 0.4.0. ;->
>
> Does this make sense?
>
> Regards and best wishes,
>
> Justin Clift
>
>   
>> 	Klaus
>>     
>
>
>   

Re: [Ming-dev] Future Stable vs Development branches?

[Justin C. <ju...@sa...>]

Klaus Rechert wrote:
<snip>
> IMHO doing small and frequent releases is the better way. If there are new 
> features available people should use them instead of waiting until the whole 
> dev-cycle is finished. Otherwise we would end up in a similar situation with 
> a very old "stable" release and a huge pile of new code in CVS with very few 
> active users. 

Hi Klaus,

Have had some time to think about this, and am now pretty sure that's 
*not* the approach we should be using for Ming. (specifically)

The reason I'm thinking this way, is that since Ming is a library, its 
real target market is other applications.  i.e. PHP, Salasaga, etc.

Applications generally need something stable they can rely on.

Ming has had a capable feature set for a while now (in the 0.4.0 series 
at least), so many apps are only going to need stuff in there.

When Ming has a "stable" 0.4.0, if we keep development in a 0.5.0 
branch, then most applications can rely on Ming to work.

However, if we keep on introducing changes to the 0.4.0 stream as part 
of our standard dev process, we're *going* to break things for the apps 
using Ming.  Even if unintentional and accidentally.

I reckon that if we want Ming to be more widely used, that's not a 
workable way to do things.

Learning this pretty much first hand with Salasaga btw, so not just 
speaking "in theory".  When I've coded Salasaga to work with Ming 0.4.0, 
I expect it to *keep* working with Ming 0.4.0. ;->

Does this make sense?

Regards and best wishes,

Justin Clift

> 	Klaus


-- 
Salasaga  -  Open Source eLearning IDE
               http://www.salasaga.org

Re: [Ming-dev] BUG: infinite loop in decompiler

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

Hi,
> This movie:
> http://inpost.pl/swf/punkty_sprzedazy.swf
>
> Triggers an infinite loop in the decompiler (listswf_d)
> with Ming head.
> It did trigger a segfault with latest release or so.
>   
I've fixed decompile.c that reads and outputs the above file but i've no 
idea if the output is correct.

Klaus

[Ming-dev] BUG: infinite loop in decompiler

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

This movie:
http://inpost.pl/swf/punkty_sprzedazy.swf

Triggers an infinite loop in the decompiler (listswf_d)
with Ming head.
It did trigger a segfault with latest release or so.

--strk;

 ()   ASCII Ribbon Campaign
 /\   Keep it simple! 

Re: [Ming-dev] Class SWFPrebuiltClip not found

[Klaus R. <kl...@re...>]

Hi,

there was a bug preventing SWFPrebuiltClip support to be built. Please 
checkout current CVS or put
#define HAVE_SWFPREBUILTCLIP 1
somewhere after the #include statements in php_ext/ming.c

    Klaus

Worm1 schrieb:
> Hi,
>  
> I install ming-0.4.0.beta5 on linux server with php 5.0.4.
>  
> -Compiled  it, and place ming.so in dir usr/lib/php/modules
> abnd move libming.a libming.la libming.so libming.so.0 
> libming.so.0.4.0 from usr/local/lib -> usr/lib
>  
> -edited php.ini adding extension=ming.so
>  
> i see mingpp.h,php_ming.h ming.h in usr/local/include too...
>  
> Ming is availabled , but recently i try to use the class 
> SWFPrebuiltClip but i have the class not found ;(
>  
> How can resolves this problem ? i absolutly need this class for my 
> project..
>  
> Ty for helps
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ming-devr mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/ming-devr
>   

[Ming-dev] Class SWFPrebuiltClip not found

[Worm1 <wor...@fr...>]

Hi, 

I install ming-0.4.0.beta5 on linux server with php 5.0.4.

-Compiled  it, and place ming.so in dir usr/lib/php/modules
abnd move libming.a libming.la libming.so libming.so.0 libming.so.0.4.0 from usr/local/lib -> usr/lib

-edited php.ini adding extension=ming.so

i see mingpp.h,php_ming.h ming.h in usr/local/include too...

Ming is availabled , but recently i try to use the class SWFPrebuiltClip but i have the class not found ;(

How can resolves this problem ? i absolutly need this class for my project..

Ty for helps

[Ming-dev] Class SWFPrebuiltClip not found

[Worm1 <wor...@fr...>]

Hi, 

I install ming-0.4.0.beta5 on linux server with php 5.0.4.

-Compiled  it, and place ming.so in dir usr/lib/php/modules
abnd move libming.a libming.la libming.so libming.so.0 libming.so.0.4.0 from usr/local/lib -> usr/lib

-edited php.ini adding extension=ming.so

Ming is availabled , but recently i try to use the class SWFPrebuiltClip but i have the class not found ;(

How can resolves this problem ? i absolutly need this class for my project..

Ty for helps

[Ming-dev] Invalid filenames on Win32

[Justin C. <ju...@sa...>]

Hi all,

Just started to look at building ming on Win32, in order to push out a 
development snapshot of Salasaga compiled for that platform.

Noticed that some of the files for the ming perl subdirectories contain 
':' in them.  i.e.

/ming/docs/perl/SWF::Action.html
/ming/docs/perl/SWF::Bitmap.html
/ming/docs/perl/SWF::Button.html
/ming/docs/perl/SWF::Constants.html
  (etc)

Colon isn't a valid character for filenames on Win32.  Unpacking any of 
the archives results in those files not being created, with error 
messages generated, and the same behaviour when checking out from cvs.

Perl isn't used by Salasaga, so it doesn't affect my app directly.

Thought it should be mentioned though, so someone who works on the perl 
side of things can look at it. :)

Regards and best wishes,

Justin Clift

-- 
Salasaga  -  Open Source eLearning IDE
               http://www.salasaga.org

Re: [Ming-dev] use a dot in SWF module number

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

Hi,

i also had issues with the version number. But i'm not an perl-package expert. 

Does anyone have a better idea ?

	Klaus

Am Donnerstag 03 April 2008 00:01:27 schrieb Patrice Dumas:
> Hello,
>
> I don't know if this patch is acceptable, but my perl 5.10.0 is not
> happy with 0.4.0-beta6. I tried other possibilities, but the patch is
> the best I could do.
>
> --
> Pat

Re: [Ming-dev] set ACLOCAL_AMFLAGS in automake

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

Commited!

Thanks
	Klaus

Am Mittwoch 02 April 2008 23:53:46 schrieb Patrice Dumas:
> Hello,
>
> A simple patch to set ACLOCAL_AMFLAGS in Makefile.am and not in
> configure.in, where autoreconf wants to find it. Moreover it should only
> be set in top level Makefile.
>
> --
> Pat

Re: [Ming-dev] installation of library and includes in perl install directories?

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

Commited!

Thanks
	Klaus

Am Mittwoch 02 April 2008 23:49:27 schrieb Patrice Dumas:
> On Tue, Apr 01, 2008 at 02:08:53PM +0200, strk wrote:
> > On Tue, Apr 01, 2008 at 02:03:27PM +0200, Patrice Dumas wrote:
> > > Hello,
> > >
> > > Currently the ming.h, perl_swf.h and libming.a files are installed
> > > together with the perl modules and .so files. I can't see a case where
> > > they could be useful. (also the corresponding code is broken, but that
> > > could be solved).
> > >
> > > Shouldn't that be removed?
> >
> > Probably. Could you provide a patch ?
>
> Of course. Here it is.
>
> > I assume you mean ming.h in per install dirs (as a ming.h for the
> > lib is expected to be installed).
>
> I mean that ming.h is installed like
> /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/auto/SWF/include/
>ming.h which is certainly useless. (Of course the ming.h file installed as
> part of the C api is useful).
>
> --
> Pat

[Ming-dev] bareword issue in test/Button for perl

[Patrice D. <per...@fr...>]

Hello,

When enabling perl, I get these make check errors:

Executing ././test02.pl in /home/dumas/src/ming/test/Button
Bareword "SWFBUTTON_HIT" not allowed while "strict subs" in use at ././test02.pl line 28.
Bareword "SWFBUTTON_UP" not allowed while "strict subs" in use at ././test02.pl line 28.
Bareword "SWFBUTTON_OVER" not allowed while "strict subs" in use at ././test02.pl line 28.
Bareword "SWFBUTTON_DOWN" not allowed while "strict subs" in use at ././test02.pl line 28.
Bareword "SWFBUTTON_OVER" not allowed while "strict subs" in use at ././test02.pl line 30.
Bareword "SWFBUTTON_DOWN" not allowed while "strict subs" in use at ././test02.pl line 30.
Bareword "SWFBUTTON_DOWN" not allowed while "strict subs" in use at ././test02.pl line 34.
Execution of ././test02.pl aborted due to compilation errors.
Executing ././test03.pl in /home/dumas/src/ming/test/Button
Bareword "SWFBUTTON_HIT" not allowed while "strict subs" in use at ././test03.pl line 45.
Bareword "SWFBUTTON_UP" not allowed while "strict subs" in use at ././test03.pl line 45.
Bareword "SWFBUTTON_OVER" not allowed while "strict subs" in use at ././test03.pl line 46.
Bareword "SWFBUTTON_DOWN" not allowed while "strict subs" in use at ././test03.pl line 47.
Execution of ././test03.pl aborted due to compilation errors.

These are indeed Bareword, but that they are also defined as part of
the xs interface, and one can see, for example:
Constants.c:        cv = newXS("SWF::Constants::SWFBUTTON_HIT", XS_SWF__Constants_constant, file);
corresponding with

I32
constant()
    ALIAS:
.....
        SWFBUTTON_HIT = SWFBUTTON_HIT
.....
    CODE:
    RETVAL = ix;
    OUTPUT:
    RETVAL

When I replace SWFBUTTON_HIT by SWF::Constants::SWFBUTTON_HIT everything
is right. So I think that the SWF::Constants::SWFBUTTON_HIT function is
not exported as SWFBUTTON_HIT. I don't really understand how the XS
stuff work, but maybe the issue is that the functions are not exported
in SWF/Constants.pm?

--
Pat

[Ming-dev] use a dot in SWF module number

[Patrice D. <per...@fr...>]

Hello,

I don't know if this patch is acceptable, but my perl 5.10.0 is not
happy with 0.4.0-beta6. I tried other possibilities, but the patch is
the best I could do.

--
Pat

[Ming-dev] set ACLOCAL_AMFLAGS in automake

[Patrice D. <per...@fr...>]

Hello,

A simple patch to set ACLOCAL_AMFLAGS in Makefile.am and not in
configure.in, where autoreconf wants to find it. Moreover it should only
be set in top level Makefile.

--
Pat

Re: [Ming-dev] installation of library and includes in perl install directories?

[Patrice D. <per...@fr...>]

On Tue, Apr 01, 2008 at 02:08:53PM +0200, strk wrote:
> On Tue, Apr 01, 2008 at 02:03:27PM +0200, Patrice Dumas wrote:
> > Hello,
> > 
> > Currently the ming.h, perl_swf.h and libming.a files are installed
> > together with the perl modules and .so files. I can't see a case where
> > they could be useful. (also the corresponding code is broken, but that
> > could be solved).
> > 
> > Shouldn't that be removed?
> 
> Probably. Could you provide a patch ?

Of course. Here it is.

> I assume you mean ming.h in per install dirs (as a ming.h for the 
> lib is expected to be installed).

I mean that ming.h is installed like
/usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/auto/SWF/include/ming.h
which is certainly useless. (Of course the ming.h file installed as part
of the C api is useful).

--
Pat

Re: [Ming-dev] libflv

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

Hi Dan,

> This message is probably more for Klaus,  I am trying to get the
> libflv library working.  So far screen data works great but I'm having
> trouble getting sound, either on its own or interleaved with the
> video.   When I try and create an flv from an mp3 the sound is choppy
> and garbled.  I have used different mp3's encoded at different rates
> (11k,44k, 192kbs, 16kbs)  and using different encoders (itunes/qt,
> lame) but all seem to have this problem.  Do you have any thoughts on
> what could be the problem?

Hmm. Could you upload the resulting flv and your mp3 file somewhere please. I 
can take a look then...

	Klaus

[Ming-dev] libflv

[Dan C. <dig...@gm...>]

Hello all,

This message is probably more for Klaus,  I am trying to get the
libflv library working.  So far screen data works great but I'm having
trouble getting sound, either on its own or interleaved with the
video.   When I try and create an flv from an mp3 the sound is choppy
and garbled.  I have used different mp3's encoded at different rates
(11k,44k, 192kbs, 16kbs)  and using different encoders (itunes/qt,
lame) but all seem to have this problem.  Do you have any thoughts on
what could be the problem?

Thanks
Dan