gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] std::bad_cast


From: Richard Wilbur
Subject: Re: [Gnash-dev] std::bad_cast
Date: Sun, 24 May 2009 16:29:29 -0600

On Sun, 2009-05-24 at 18:53 +0200, Andrea Palmatè wrote:
> 
> > 
> > 
> > Dear Andrea,
> > 
> > Do you think this project would be amenable to division of labor?
> >  If
> > you would like assistance, I would be happy to work on the default
> > implementation to bring it up to the current baseline and coordinate
> > with you regarding the AmigaOS implementation.
> > 
> > Richard
> 
> What do you mean?
> I was only askin for his old string implementation patch to see if
> this could be applied to the current trunk without problems.
> I have my small patch that is doing its work but if there is a patch
> that can help also other platforms is better. or not?
> I was thinking that HAVE_WSTRING could be a solution but if there is
> something else why doesn't take a look to see if can help platforms
> like Haiku for examples?
> 
> 
> Andrea

I agree that if there is a solution that benefits all platforms it
sounds superior.  I offered to collaborate because I thought it sounded
like there may be quite a lot of work involved as the patch doesn't any
longer apply to the trunk and is unfinished.

I may have misunderstood Mr. Wolsey's meaning:

Il giorno 14/mag/09, alle ore 23:39, Benjamin Wolsey ha scritto:
>
> I can think of two proper ways of fixing it:
>
> (a) use a custom string implementation for actionscript in Gnash that
> allows platforms to supply their own implementations if the default
> one doesn't work. I almost did this once, but never applied it and
> the patch got obsoleted. This should probably be done sometime anyway,
> as it makes string processing much more efficient and fixes a number
> of swfdec testcases.
>
[...]
> if anyone would like to work on a string implementation for
> ActionScript, I can supply my patch as a start. It supplied a libICU
> and a std::string implementation, but should really use a std::wstring
> type with some extra constructors to pass all the testsuite. The very
> time consuming part is finding the right places to use it more than
> anything else.

I took his meaning as:
'Create a custom string interface class in Gnash which provides
functionality from std::string and std::wstring as needed but whose
implementation avoids unnecessary conversions between the two, among
other optimizations.  Further, those platforms lacking a complete
implementation of std::wstring, locales, or any other constituent could
then provide an alternate implementation of said custom string interface
class to supply the needed functionality.  Caveat:  The patch is a start
that has been obsoleted by progress on the trunk and should be
implemented slightly differently.  Furthermore, there is considerable
time to be spent determining where to use the new class.'

This sounds like, although there is a bit of work to be done, the result
is a win for everyone:
1.  Default implementation of the new class provides much more efficient
string processing and fixes several swfdec testcases.
2.  Other platforms gain a more efficient framework on which to
implement full Gnash string processing capability.
3.  Platforms have a standard interface to implement the missing
functionality needed to provide full Gnash string processing capability.

As both my Amigas are classic models with AmigaOS 3.1 but I own several
other machines which run GNU/Linux, I thought I could be more help
rehabilitating Mr. Wolsey's obsolete patch for the default
implementation.

Richard





reply via email to

[Prev in Thread] Current Thread [Next in Thread]