Re: Embedded Assets (was Re: AIR and Royale)

[Carlos Rovira]

Hi,

I think in the case of HTML, does not have sense to me the concept of Embed
like in Flex. Maybe of SWF target or others (don't know if WebAsm could
benefit from something like this)
Maybe for HTML use something like Embed metadata, could just copy the
assets to the resources folder to be available, since like Alex said, a
request per asset is needed and making other kind of big file seems strange
in this case (maybe not). Although we have solved the copying of assets in
different ways through compiler for libraries and ANT/MAVEN automation in
Application.

for me this could be something to investigate in the future, but with low
priority, since I think we still have bigger fish to fry

just my 2...


El mié., 5 jun. 2019 a las 18:07, Alex Harui ()
escribió:

> Regarding embedded assets in Royale:
>
> There is no embedded asset support at this time because it is not obvious
> to me it will be worth it.  We need a volunteer to devise a strategy that
> works and implement it.
>
> In Flex/Flash, my understanding is that folks embedded assets to save on
> server requests for assets like images.  That makes sense because, since a
> SWF is a compressed binary and most assets are compressed binaries, you can
> essentially append the assets to the SWF.
>
> However, for Royale in the browser, every implementation of "embedding"
> I've seen seems to Base64 encode the asset, converting it to text and
> increasing the number of bytes.  And the resulting Base64 bytes may
> deteriorate the gzip compression of the .html file.
>
> Flash also had frames in the SWF and assets could be embedded on later
> frames allowing a download progress bar to show up before all of the rest
> of the SWF is downloaded.  I don't know what the equivalent for that is
> without Flash.
>
> I believe another advantage of embedding in Flash was that the asset was
> ready to be instantiated and placed on the display list right away.  I'm
> not clear that an embedded Base64 image can be used in an  tag and
> prevent "popping" given that Royale generates the  tags dynamically.
>
> So, we need a volunteer to create some examples of how to use browser
> embedding in dynamically generated  tags so we can see if there will
> be any benefit or not.  And if not, possibly explore other options, such as
> delivering all assets in one true binary blob somehow.
>
> HTH,
> -Alex
>
> On 6/5/19, 7:05 AM, "Frost, Andrew"  wrote:
>
> Yes, me :-)
>
> I'm pushing Royale internally, I think it has a lot of promise -
> although I still do find it a little frustrating at times internally! In
> terms of what support you can give, the sorts of things you're already
> doing are great, but yes it might mean we lean a little more on this
> mailing list if we're facing tricky issues.
>
> We have one sales case in particular at the moment which has the
> potential to be very big, we're hoping they move forwards with a proof of
> concept project which would take a small part of their app and port this to
> Royale. A few issues we've found so far from investigations:
> - their flex code is embedding icons that are contained within a SWF.
> Royale compiler didn't seem to like this, not sure whether it's just syntax
> or whether we need to pull all the assets out (not a big job, we can
> automate that..)
> - they have binding using functions e.g.
> text="{localizationHelper.getString('fieldName')}", which caused an issue
> when generating the JavaScript code as the string-within-a-string seemed to
> upset the parser. We can look at this later perhaps though..
> - when we got it compiling, the main thing was with responsiveness
> i.e. trying to get the app to resize and for all the internal elements to
> then resize. We may use the MX emulation classes for this but it still
> looked like more support is needed - although we only looked briefly at
> this.
>
> Once those issues are sorted though, we would have one big task (to
> recreate a very advanced data grid control that they'd developed in
> Flex/Flash) and a lot of the rest - around the AS3 logic - should fall into
> place! I'm hoping we can convince them to go with this solution..
>
>
> thanks
>
>Andrew
>
>
>
> -Original Message-
> From: Harbs [mailto:harbs.li...@gmail.com]
> Sent: 04 June 2019 14:41
> To: dev@royale.apache.org
> Subject: [EXTERNAL] Re: AIR and Royale
>
> Well to start with: Does anyone know anyone working for them?
>
> I’d like to hear from them what it would take for them to push Royale
> more.
>
> > On Jun 4, 2019, at 4:10 PM, Carlos Rovira 
> wrote:
> >
> > Hi,
> >
> > what's the kind of support you're thinking ?
> >
> >
> >
> > El mar., 4 jun. 2019 a las 9:36, Piotr Zarzycki
> > ()
> > escribió:
> >
> >> Hi Harbs,
> >>
> >> I was exactly think the same about that, so I'm keeping finger
> >> crossed to that effort.
> >>
> >> Thanks,
> >> Piotr
>

Re: Compiler Build Failing on Windows

[Carlos Rovira]

I have pendent to check build with Env vars, although can't say where I
could try since that requieres some hours to pursue that task.
I think we should all try to do this, since in doing that we can finally
refine the process of build that is the biggest problem in Royale along
with releases.
Getting Royale to build without any issue for any new comers is the most
important thing along with getting releases monthly without much effort.
(And of course continue with documentation)



El mié., 5 jun. 2019 a las 17:53, Alex Harui ()
escribió:

> As discussed recently on some other thread, environment variables matter
> and the documentation may not be up-to-date.
>
> We build both SWF&JS or JS-Only packages based on environment variables.
> Either you have the Adobe stuff for SWF and environment variables pointing
> to them or not.  If you only have some of the Adobe environment variables
> but not others, you'll probably confuse the builds.
>
> AIR_HOME
> PLAYERGLOBAL_HOME
> FLASHPLAYER_DEBUGGER
>
> Either set all 3 or don't set any of the 3.
>
> HTH,
> -Alex
>
> On 6/5/19, 7:27 AM, "Piotr Zarzycki"  wrote:
>
> Carlos,
>
> I think it is ANT build. Yesterday I tried locally and had the same
> issue.
> I was going to report it here as well.
>
> Thanks,
> Piotr
>
> śr., 5 cze 2019 o 16:00 Carlos Rovira 
> napisał(a):
>
> > Hi
> >
> > can you provide more info about what method are you using to build?
> ANT?
> > Maven? and provide the steps you use, also if you have set up some
> env
> > vars?
> > thanks
> >
> > El mié., 5 jun. 2019 a las 12:43, Shiffy ()
> escribió:
> >
> > > I’m trying to build the compiler on Windows and it keeps failing
> in the
> > > tests.
> > >
> > > Here’s one example of a failed test that I’m getting:
> > >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2FTpQynEmF&data=02%7C01%7Caharui%40adobe.com%7C0c7d3e7f051245540c5508d6e9c1fbc1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636953416690581144&sdata=R9R5myGACz%2BUaexnDobnVD%2FMvf1J%2FCjXeaSlNI5GrOA%3D&reserved=0
> > >
> > > The test results are hard to read, but one difference I see
> between the
> > > expected results and the actual results is that it expects extends
> Object
> > > and it’s extending flash.display::Sprite.
> > >
> > > Any ideas on what’s wrong?
> > >
> >
> >
> > --
> > Carlos Rovira
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0c7d3e7f051245540c5508d6e9c1fbc1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636953416690581144&sdata=F%2By0%2BMDEJg0wYdAsOTHGIeWGbaCGuzRfKPAFLJh6JMI%3D&reserved=0
> >
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C0c7d3e7f051245540c5508d6e9c1fbc1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636953416690581144&sdata=mGRcOuyal9mZruQc%2FPG39mGoHPvyVbWciHoGzELiGsA%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C0c7d3e7f051245540c5508d6e9c1fbc1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636953416690581144&sdata=mGRcOuyal9mZruQc%2FPG39mGoHPvyVbWciHoGzELiGsA%3D&reserved=0
> >*
>
>
>

-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Compiler Build Failing on Windows

[Piotr Zarzycki]

I believe the most important thing right now is to getting back our nightly
build and see whether there it doesn't occur. If it doesn't you may have
your answer to the issue without doing anything on your local machine.

czw., 6 cze 2019 o 12:36 Carlos Rovira  napisał(a):

> I have pendent to check build with Env vars, although can't say where I
> could try since that requieres some hours to pursue that task.
> I think we should all try to do this, since in doing that we can finally
> refine the process of build that is the biggest problem in Royale along
> with releases.
> Getting Royale to build without any issue for any new comers is the most
> important thing along with getting releases monthly without much effort.
> (And of course continue with documentation)
>
>
>
> El mié., 5 jun. 2019 a las 17:53, Alex Harui ()
> escribió:
>
> > As discussed recently on some other thread, environment variables matter
> > and the documentation may not be up-to-date.
> >
> > We build both SWF&JS or JS-Only packages based on environment variables.
> > Either you have the Adobe stuff for SWF and environment variables
> pointing
> > to them or not.  If you only have some of the Adobe environment variables
> > but not others, you'll probably confuse the builds.
> >
> > AIR_HOME
> > PLAYERGLOBAL_HOME
> > FLASHPLAYER_DEBUGGER
> >
> > Either set all 3 or don't set any of the 3.
> >
> > HTH,
> > -Alex
> >
> > On 6/5/19, 7:27 AM, "Piotr Zarzycki"  wrote:
> >
> > Carlos,
> >
> > I think it is ANT build. Yesterday I tried locally and had the same
> > issue.
> > I was going to report it here as well.
> >
> > Thanks,
> > Piotr
> >
> > śr., 5 cze 2019 o 16:00 Carlos Rovira 
> > napisał(a):
> >
> > > Hi
> > >
> > > can you provide more info about what method are you using to build?
> > ANT?
> > > Maven? and provide the steps you use, also if you have set up some
> > env
> > > vars?
> > > thanks
> > >
> > > El mié., 5 jun. 2019 a las 12:43, Shiffy ()
> > escribió:
> > >
> > > > I’m trying to build the compiler on Windows and it keeps failing
> > in the
> > > > tests.
> > > >
> > > > Here’s one example of a failed test that I’m getting:
> > > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2FTpQynEmF&data=02%7C01%7Caharui%40adobe.com%7C0c7d3e7f051245540c5508d6e9c1fbc1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636953416690581144&sdata=R9R5myGACz%2BUaexnDobnVD%2FMvf1J%2FCjXeaSlNI5GrOA%3D&reserved=0
> > > >
> > > > The test results are hard to read, but one difference I see
> > between the
> > > > expected results and the actual results is that it expects
> extends
> > Object
> > > > and it’s extending flash.display::Sprite.
> > > >
> > > > Any ideas on what’s wrong?
> > > >
> > >
> > >
> > > --
> > > Carlos Rovira
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0c7d3e7f051245540c5508d6e9c1fbc1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636953416690581144&sdata=F%2By0%2BMDEJg0wYdAsOTHGIeWGbaCGuzRfKPAFLJh6JMI%3D&reserved=0
> > >
> >
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C0c7d3e7f051245540c5508d6e9c1fbc1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636953416690581144&sdata=mGRcOuyal9mZruQc%2FPG39mGoHPvyVbWciHoGzELiGsA%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C0c7d3e7f051245540c5508d6e9c1fbc1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636953416690581144&sdata=mGRcOuyal9mZruQc%2FPG39mGoHPvyVbWciHoGzELiGsA%3D&reserved=0
> > >*
> >
> >
> >
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>


-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
*

Re: Embedded Assets (was Re: AIR and Royale)

[Frost, Andrew]

Thanks, Alex & Carlos

Yes I agree basically, embedding something in terms of how Flex does it isn't 
something that's relevant for Royale or HTTP-based solutions in the same way, 
and we certainly don't want to end up encoding something into text base64 
formats..

It might be nice to have the compiler do some magic to recognise this scenario 
and to grab the swf file, extract the image and then change the mxml so that it 
just becomes a url reference.. but that's probably a lot of work compared to 
just doing this as a manual operation which is just a one-off update needed in 
the code.

So that:

is turned into something like


Anyway, if we get asked to do this then I'll take a look to see whether it 
could be merged into the toolchain somehow.. having a quick look into the SWF 
it could be fun as these icons are actually not just pure images but include 
some shape output from the Flash/Animate authoring tools too.. but I guess we 
can just have some quick AS3 tool to extract these with the appropriate shape 
and save them to png..

For now I'll wait to see whether the project does actually go ahead!!

thanks

   Andrew


-Original Message-
From: Carlos Rovira [mailto:carlosrov...@apache.org] 
Sent: 06 June 2019 11:33
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Embedded Assets (was Re: AIR and Royale)

Hi,

I think in the case of HTML, does not have sense to me the concept of Embed 
like in Flex. Maybe of SWF target or others (don't know if WebAsm could benefit 
from something like this) Maybe for HTML use something like Embed metadata, 
could just copy the assets to the resources folder to be available, since like 
Alex said, a request per asset is needed and making other kind of big file 
seems strange in this case (maybe not). Although we have solved the copying of 
assets in different ways through compiler for libraries and ANT/MAVEN 
automation in Application.

for me this could be something to investigate in the future, but with low 
priority, since I think we still have bigger fish to fry

just my 2...


El mié., 5 jun. 2019 a las 18:07, Alex Harui ()
escribió:

> Regarding embedded assets in Royale:
>
> There is no embedded asset support at this time because it is not 
> obvious to me it will be worth it.  We need a volunteer to devise a 
> strategy that works and implement it.
>
> In Flex/Flash, my understanding is that folks embedded assets to save 
> on server requests for assets like images.  That makes sense because, 
> since a SWF is a compressed binary and most assets are compressed 
> binaries, you can essentially append the assets to the SWF.
>
> However, for Royale in the browser, every implementation of "embedding"
> I've seen seems to Base64 encode the asset, converting it to text and 
> increasing the number of bytes.  And the resulting Base64 bytes may 
> deteriorate the gzip compression of the .html file.
>
> Flash also had frames in the SWF and assets could be embedded on later 
> frames allowing a download progress bar to show up before all of the 
> rest of the SWF is downloaded.  I don't know what the equivalent for 
> that is without Flash.
>
> I believe another advantage of embedding in Flash was that the asset 
> was ready to be instantiated and placed on the display list right 
> away.  I'm not clear that an embedded Base64 image can be used in an 
>  tag and prevent "popping" given that Royale generates the  tags 
> dynamically.
>
> So, we need a volunteer to create some examples of how to use browser 
> embedding in dynamically generated  tags so we can see if there 
> will be any benefit or not.  And if not, possibly explore other 
> options, such as delivering all assets in one true binary blob somehow.
>
> HTH,
> -Alex
>
> On 6/5/19, 7:05 AM, "Frost, Andrew"  wrote:
>
> Yes, me :-)
>
> I'm pushing Royale internally, I think it has a lot of promise - 
> although I still do find it a little frustrating at times internally! 
> In terms of what support you can give, the sorts of things you're 
> already doing are great, but yes it might mean we lean a little more 
> on this mailing list if we're facing tricky issues.
>
> We have one sales case in particular at the moment which has the 
> potential to be very big, we're hoping they move forwards with a proof 
> of concept project which would take a small part of their app and port 
> this to Royale. A few issues we've found so far from investigations:
> - their flex code is embedding icons that are contained within a SWF.
> Royale compiler didn't seem to like this, not sure whether it's just 
> syntax or whether we need to pull all the assets out (not a big job, 
> we can automate that..)
> - they have binding using functions e.g.
> text="{localizationHelper.getString('fieldName')}", which caused an 
> issue when generating the JavaScript code as the 
> string-within-a-string seemed to upset the parser. We can look at this later 
> perhaps though..
> - when we got it compiling, the 

Build failed in Jenkins: royale-asjs_jsonly #3059

[Apache Royale CI Server]

See 


--
[...truncated 2.12 MB...]
[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

Re: Embedded Assets (was Re: AIR and Royale)

[Andrew Wetmore]

I just added a brief statement about using a URL instead of embedding
assets in Royale in the "Flex Equivalents" page [1].

@Carlos Rovira  , where does that page appear when
a user is looking through the documentation? I can't find my way to it
through the compiled Help Docs, or in the ToC.



[1]  royale-docs /user-interface
/
flex-equivalents.md

On Thu, Jun 6, 2019 at 9:26 AM Frost, Andrew 
wrote:

> Thanks, Alex & Carlos
>
> Yes I agree basically, embedding something in terms of how Flex does it
> isn't something that's relevant for Royale or HTTP-based solutions in the
> same way, and we certainly don't want to end up encoding something into
> text base64 formats..
>
> It might be nice to have the compiler do some magic to recognise this
> scenario and to grab the swf file, extract the image and then change the
> mxml so that it just becomes a url reference.. but that's probably a lot of
> work compared to just doing this as a manual operation which is just a
> one-off update needed in the code.
>
> So that:
> 
> is turned into something like
> 
>
> Anyway, if we get asked to do this then I'll take a look to see whether it
> could be merged into the toolchain somehow.. having a quick look into the
> SWF it could be fun as these icons are actually not just pure images but
> include some shape output from the Flash/Animate authoring tools too.. but
> I guess we can just have some quick AS3 tool to extract these with the
> appropriate shape and save them to png..
>
> For now I'll wait to see whether the project does actually go ahead!!
>
> thanks
>
>Andrew
>
>
> -Original Message-
> From: Carlos Rovira [mailto:carlosrov...@apache.org]
> Sent: 06 June 2019 11:33
> To: dev@royale.apache.org
> Subject: [EXTERNAL] Re: Embedded Assets (was Re: AIR and Royale)
>
> Hi,
>
> I think in the case of HTML, does not have sense to me the concept of
> Embed like in Flex. Maybe of SWF target or others (don't know if WebAsm
> could benefit from something like this) Maybe for HTML use something like
> Embed metadata, could just copy the assets to the resources folder to be
> available, since like Alex said, a request per asset is needed and making
> other kind of big file seems strange in this case (maybe not). Although we
> have solved the copying of assets in different ways through compiler for
> libraries and ANT/MAVEN automation in Application.
>
> for me this could be something to investigate in the future, but with low
> priority, since I think we still have bigger fish to fry
>
> just my 2...
>
>
> El mié., 5 jun. 2019 a las 18:07, Alex Harui ()
> escribió:
>
> > Regarding embedded assets in Royale:
> >
> > There is no embedded asset support at this time because it is not
> > obvious to me it will be worth it.  We need a volunteer to devise a
> > strategy that works and implement it.
> >
> > In Flex/Flash, my understanding is that folks embedded assets to save
> > on server requests for assets like images.  That makes sense because,
> > since a SWF is a compressed binary and most assets are compressed
> > binaries, you can essentially append the assets to the SWF.
> >
> > However, for Royale in the browser, every implementation of "embedding"
> > I've seen seems to Base64 encode the asset, converting it to text and
> > increasing the number of bytes.  And the resulting Base64 bytes may
> > deteriorate the gzip compression of the .html file.
> >
> > Flash also had frames in the SWF and assets could be embedded on later
> > frames allowing a download progress bar to show up before all of the
> > rest of the SWF is downloaded.  I don't know what the equivalent for
> > that is without Flash.
> >
> > I believe another advantage of embedding in Flash was that the asset
> > was ready to be instantiated and placed on the display list right
> > away.  I'm not clear that an embedded Base64 image can be used in an
> >  tag and prevent "popping" given that Royale generates the 
> tags dynamically.
> >
> > So, we need a volunteer to create some examples of how to use browser
> > embedding in dynamically generated  tags so we can see if there
> > will be any benefit or not.  And if not, possibly explore other
> > options, such as delivering all assets in one true binary blob somehow.
> >
> > HTH,
> > -Alex
> >
> > On 6/5/19, 7:05 AM, "Frost, Andrew"  wrote:
> >
> > Yes, me :-)
> >
> > I'm pushing Royale internally, I think it has a lot of promise -
> > although I still do find it a little frustrating at times internally!
> > In terms of what support you can give, the sorts of things you're
> > already doing are great, but yes it might mean we lean a little more
> > on this mailing list if we're facing tricky issues.
> >
> > We have one sales case in particular at the moment which has the
> > potential to be very big, we're hoping they move forwards with a proof
> > of concept project which would take

Re: Embedded Assets (was Re: AIR and Royale)

[Frost, Andrew]

Thanks! I'd not seen that page before, looks useful :-)

cheers


-Original Message-
From: Andrew Wetmore [mailto:cottag...@gmail.com] 
Sent: 06 June 2019 14:07
To: dev@royale.apache.org; Carlos Rovira 
Subject: [EXTERNAL] Re: Embedded Assets (was Re: AIR and Royale)

I just added a brief statement about using a URL instead of embedding assets in 
Royale in the "Flex Equivalents" page [1].

@Carlos Rovira  , where does that page appear when a 
user is looking through the documentation? I can't find my way to it through 
the compiled Help Docs, or in the ToC.

Re: Embedded Assets (was Re: AIR and Royale)

[Alex Harui]

The JS emitters in the compiler could ignore the embedding directive and output 
something useful.  I think there are several scenarios that need to be handled:

1) MXML embedded PNG/GIF/JPG (other file types) in an assets folder:
   
This would be the easiest since the assets folder gets copied into the output 
by default.

2) AS embedded assets:
  [Embed(source="assets/icon.png")]
  public static var MyIcon:Class;
The tricky part here is that sometimes MyIcon is passed into an mx:Image (and 
thus it would work) but other times, folks write:
  var myIcon:MyIcon = new MyIcon();
  addChild(myIcon);
And that would require more complex generated code.

3) Embedding of SWF/SWC assets
  
This would additionally require some sort of transcoder.  It might be easier to 
leverage the SVG transcoder than transcode to PNG.  And if there is frame-based 
animation, it gets even harder.

HTH,
-Alex

On 6/6/19, 5:27 AM, "Frost, Andrew"  wrote:

Thanks, Alex & Carlos

Yes I agree basically, embedding something in terms of how Flex does it 
isn't something that's relevant for Royale or HTTP-based solutions in the same 
way, and we certainly don't want to end up encoding something into text base64 
formats..

It might be nice to have the compiler do some magic to recognise this 
scenario and to grab the swf file, extract the image and then change the mxml 
so that it just becomes a url reference.. but that's probably a lot of work 
compared to just doing this as a manual operation which is just a one-off 
update needed in the code.

So that:

is turned into something like


Anyway, if we get asked to do this then I'll take a look to see whether it 
could be merged into the toolchain somehow.. having a quick look into the SWF 
it could be fun as these icons are actually not just pure images but include 
some shape output from the Flash/Animate authoring tools too.. but I guess we 
can just have some quick AS3 tool to extract these with the appropriate shape 
and save them to png..

For now I'll wait to see whether the project does actually go ahead!!

thanks

   Andrew


-Original Message-
From: Carlos Rovira [mailto:carlosrov...@apache.org] 
Sent: 06 June 2019 11:33
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Embedded Assets (was Re: AIR and Royale)

Hi,

I think in the case of HTML, does not have sense to me the concept of Embed 
like in Flex. Maybe of SWF target or others (don't know if WebAsm could benefit 
from something like this) Maybe for HTML use something like Embed metadata, 
could just copy the assets to the resources folder to be available, since like 
Alex said, a request per asset is needed and making other kind of big file 
seems strange in this case (maybe not). Although we have solved the copying of 
assets in different ways through compiler for libraries and ANT/MAVEN 
automation in Application.

for me this could be something to investigate in the future, but with low 
priority, since I think we still have bigger fish to fry

just my 2...


El mié., 5 jun. 2019 a las 18:07, Alex Harui ()
escribió:

> Regarding embedded assets in Royale:
>
> There is no embedded asset support at this time because it is not 
> obvious to me it will be worth it.  We need a volunteer to devise a 
> strategy that works and implement it.
>
> In Flex/Flash, my understanding is that folks embedded assets to save 
> on server requests for assets like images.  That makes sense because, 
> since a SWF is a compressed binary and most assets are compressed 
> binaries, you can essentially append the assets to the SWF.
>
> However, for Royale in the browser, every implementation of "embedding"
> I've seen seems to Base64 encode the asset, converting it to text and 
> increasing the number of bytes.  And the resulting Base64 bytes may 
> deteriorate the gzip compression of the .html file.
>
> Flash also had frames in the SWF and assets could be embedded on later 
> frames allowing a download progress bar to show up before all of the 
> rest of the SWF is downloaded.  I don't know what the equivalent for 
> that is without Flash.
>
> I believe another advantage of embedding in Flash was that the asset 
> was ready to be instantiated and placed on the display list right 
> away.  I'm not clear that an embedded Base64 image can be used in an 
>  tag and prevent "popping" given that Royale generates the  
tags dynamically.
>
> So, we need a volunteer to create some examples of how to use browser 
> embedding in dynamically generated  tags so we can see if there 
> will be any benefit or not.  And if not, possibly explore other 
> options, such as delivering all assets in one true binary blob somehow.
>
> HTH,
> -Alex
>
> On 6/5/19, 7:05 AM

Re: Embedded Assets (was Re: AIR and Royale)

[OmPrakash Muppirala]

In recent applications using React/Webpack, I have seen defaults of using
base64 embedding of files less than 10k in size.

I guess the tradeoff is in between firing off several http requests for
small files vs embedding them is a less efficient format.

I think a similar strategy would work for Royale.

Thanks,
Om

On Thu, Jun 6, 2019, 3:32 AM Carlos Rovira  wrote:

> Hi,
>
> I think in the case of HTML, does not have sense to me the concept of Embed
> like in Flex. Maybe of SWF target or others (don't know if WebAsm could
> benefit from something like this)
> Maybe for HTML use something like Embed metadata, could just copy the
> assets to the resources folder to be available, since like Alex said, a
> request per asset is needed and making other kind of big file seems strange
> in this case (maybe not). Although we have solved the copying of assets in
> different ways through compiler for libraries and ANT/MAVEN automation in
> Application.
>
> for me this could be something to investigate in the future, but with low
> priority, since I think we still have bigger fish to fry
>
> just my 2...
>
>
> El mié., 5 jun. 2019 a las 18:07, Alex Harui ()
> escribió:
>
> > Regarding embedded assets in Royale:
> >
> > There is no embedded asset support at this time because it is not obvious
> > to me it will be worth it.  We need a volunteer to devise a strategy that
> > works and implement it.
> >
> > In Flex/Flash, my understanding is that folks embedded assets to save on
> > server requests for assets like images.  That makes sense because, since
> a
> > SWF is a compressed binary and most assets are compressed binaries, you
> can
> > essentially append the assets to the SWF.
> >
> > However, for Royale in the browser, every implementation of "embedding"
> > I've seen seems to Base64 encode the asset, converting it to text and
> > increasing the number of bytes.  And the resulting Base64 bytes may
> > deteriorate the gzip compression of the .html file.
> >
> > Flash also had frames in the SWF and assets could be embedded on later
> > frames allowing a download progress bar to show up before all of the rest
> > of the SWF is downloaded.  I don't know what the equivalent for that is
> > without Flash.
> >
> > I believe another advantage of embedding in Flash was that the asset was
> > ready to be instantiated and placed on the display list right away.  I'm
> > not clear that an embedded Base64 image can be used in an  tag and
> > prevent "popping" given that Royale generates the  tags dynamically.
> >
> > So, we need a volunteer to create some examples of how to use browser
> > embedding in dynamically generated  tags so we can see if there will
> > be any benefit or not.  And if not, possibly explore other options, such
> as
> > delivering all assets in one true binary blob somehow.
> >
> > HTH,
> > -Alex
> >
> > On 6/5/19, 7:05 AM, "Frost, Andrew"  wrote:
> >
> > Yes, me :-)
> >
> > I'm pushing Royale internally, I think it has a lot of promise -
> > although I still do find it a little frustrating at times internally! In
> > terms of what support you can give, the sorts of things you're already
> > doing are great, but yes it might mean we lean a little more on this
> > mailing list if we're facing tricky issues.
> >
> > We have one sales case in particular at the moment which has the
> > potential to be very big, we're hoping they move forwards with a proof of
> > concept project which would take a small part of their app and port this
> to
> > Royale. A few issues we've found so far from investigations:
> > - their flex code is embedding icons that are contained within a SWF.
> > Royale compiler didn't seem to like this, not sure whether it's just
> syntax
> > or whether we need to pull all the assets out (not a big job, we can
> > automate that..)
> > - they have binding using functions e.g.
> > text="{localizationHelper.getString('fieldName')}", which caused an issue
> > when generating the JavaScript code as the string-within-a-string seemed
> to
> > upset the parser. We can look at this later perhaps though..
> > - when we got it compiling, the main thing was with responsiveness
> > i.e. trying to get the app to resize and for all the internal elements to
> > then resize. We may use the MX emulation classes for this but it still
> > looked like more support is needed - although we only looked briefly at
> > this.
> >
> > Once those issues are sorted though, we would have one big task (to
> > recreate a very advanced data grid control that they'd developed in
> > Flex/Flash) and a lot of the rest - around the AS3 logic - should fall
> into
> > place! I'm hoping we can convince them to go with this solution..
> >
> >
> > thanks
> >
> >Andrew
> >
> >
> >
> > -Original Message-
> > From: Harbs [mailto:harbs.li...@gmail.com]
> > Sent: 04 June 2019 14:41
> > To: dev@royale.apache.org
> > Subject: [EXTERNAL] Re: AIR and Royale
> >
> > Well 

Re: Language improvements

[Greg Dove]

Hi Alex, it seems I do need to make one more post after all.
I do feel like I have shared all this information before, but I will make
'one more entry' in case I did not do that with clarity:


On Wed, Jun 5, 2019 at 6:36 PM Alex Harui  wrote:

> Your summary of my opinion is not correct.
>
> If Vector-as-array is what the current develop branch output is, I am
> unable to understand how that output is incorrect or poses any risks for
> anyone who knows they will not need runtime type-checking or runtime
> fixed-length checking.  And thus, it should remain an option.  For sure, it
> was good enough for at least two production apps.
>
> I said previously that I don't consider that single case to be a
validation for a more general case, it is just using index access and one
push, iirc. And it really offers no value for runtime safety in the swf
version because the runtime safety for the push call was already guarded by
the signature of the enclosing method. It has already been addressed in the
branch in ways we already discussed at length.
I'd guess that Harbs' experience might validate Vector-as-Array more,
because it sounds like he was using Vector (and therefore Vector-as-Array)
much more than that, iiuc, but Harbs also seemed willing to consider other
options.
While I personally don't think that example justifies it as a feature, I'm
not interested in using it as any justification to oppose it. Like I said,
I will add it back.

I consider that specific example (as it is currently in develop) 'safe' in
the swc *because* it abides by the following:
'Don't use any emulation classes in library code unless your emulation
class is Array, and if it is Array, don't expose the Vector type on any
public or protected api surface because it will be a misleading
representation of the type to the user of that api'
The Vector instance being substituted with Array is a private instance and
is never exposed via public or protected access, so it is 'safe'

If someone (anyone), at some point, released the same swc after adding
public function getMyBeadVector():Vector.IBead {
 return _beads; //share the private instance
}

I consider it not to be 'safe'.
(I'm not using angle brackets above because they mess up some readers it
seems)

At that point it gives someone else a potential problem, because it is
really returning an Array, instead of a distinctive Vector type, and can
only be 'safe-ish' if the user of the swc (it might be another library or
application) knows its limitations or happens to be applying the same
optimization to their own code (and accepting whatever risks they do with
that). It may not be obvious to the user of the swc that the instance is an
Array because their IDE tells them it is a Vector, but it can behave
differently to how they expect a Vector to behave. They might end up adding
code to offset the unusual behaviour, or doing things which break things
later if a more conformant Vector is swapped in. Using Array here is just a
specific example of the more general emulation class like approach, so
similar concerns apply to using other emulation classes.
Anyway, we can set that specific example of IBead aside. Like I said it is
'safe' as it is.

For the other points, most of them have been discussed already. The sky's
the limit for what options we could provide. But providing lots of options
is not itself without cost.
I already mentioned I'd rather add things for Vector optimization based on
feedback for what people need than try to guess what those things are or
assume that what I think is what they want.

For the Vector case in general, I think of it in two different ways

1. People trying to port existing as3 codebases.
Usually the goal is to get things working first and then optimize/customize
as necessary. At least that is the approach I am familiar with.
The first part of that is what I have been focused on with Vector - code
that 'just works' as-is when ported. The second part could be achieved by
using Vector configuration/tuning options. Or it could be by refactoring
portions of the original code to reflect best practice for specific
targets, or it could be by substituting new options (Harbs' and Josh'
suggestions) which reflect improved cross-target features for compile-time
only safety.

2. People writing new as3 code from scratch for royale
If 'compile-time' safety is the main goal, then what Harbs and Josh
suggested is the thing I personally would use most instead of Vector here.
That is what the (proposed) feature represents as being more
fit-for-purpose than Vector which has limited compile-time type safety
anyway. That could probably even support 'opt-in' runtime-safety checks for
things like push and unshift etc (instead of 'opt-out' from Vector, for
example), or maybe it could leverage the complex-implicit-coercions feature
in the branch which is more general, and can also be switched off globally
or toggled locally.
if 'run-time' safety is the main goal, they can choose Vector, wit

Re: Embedded Assets (was Re: AIR and Royale)

[Carlos Rovira]

ok Om thanks for sharing.
Do you have some url with some code to see an example of how they do it?
thanks

El jue., 6 jun. 2019 a las 19:05, OmPrakash Muppirala ()
escribió:

> In recent applications using React/Webpack, I have seen defaults of using
> base64 embedding of files less than 10k in size.
>
> I guess the tradeoff is in between firing off several http requests for
> small files vs embedding them is a less efficient format.
>
> I think a similar strategy would work for Royale.
>
> Thanks,
> Om
>
> On Thu, Jun 6, 2019, 3:32 AM Carlos Rovira 
> wrote:
>
> > Hi,
> >
> > I think in the case of HTML, does not have sense to me the concept of
> Embed
> > like in Flex. Maybe of SWF target or others (don't know if WebAsm could
> > benefit from something like this)
> > Maybe for HTML use something like Embed metadata, could just copy the
> > assets to the resources folder to be available, since like Alex said, a
> > request per asset is needed and making other kind of big file seems
> strange
> > in this case (maybe not). Although we have solved the copying of assets
> in
> > different ways through compiler for libraries and ANT/MAVEN automation in
> > Application.
> >
> > for me this could be something to investigate in the future, but with low
> > priority, since I think we still have bigger fish to fry
> >
> > just my 2...
> >
> >
> > El mié., 5 jun. 2019 a las 18:07, Alex Harui ( >)
> > escribió:
> >
> > > Regarding embedded assets in Royale:
> > >
> > > There is no embedded asset support at this time because it is not
> obvious
> > > to me it will be worth it.  We need a volunteer to devise a strategy
> that
> > > works and implement it.
> > >
> > > In Flex/Flash, my understanding is that folks embedded assets to save
> on
> > > server requests for assets like images.  That makes sense because,
> since
> > a
> > > SWF is a compressed binary and most assets are compressed binaries, you
> > can
> > > essentially append the assets to the SWF.
> > >
> > > However, for Royale in the browser, every implementation of "embedding"
> > > I've seen seems to Base64 encode the asset, converting it to text and
> > > increasing the number of bytes.  And the resulting Base64 bytes may
> > > deteriorate the gzip compression of the .html file.
> > >
> > > Flash also had frames in the SWF and assets could be embedded on later
> > > frames allowing a download progress bar to show up before all of the
> rest
> > > of the SWF is downloaded.  I don't know what the equivalent for that is
> > > without Flash.
> > >
> > > I believe another advantage of embedding in Flash was that the asset
> was
> > > ready to be instantiated and placed on the display list right away.
> I'm
> > > not clear that an embedded Base64 image can be used in an  tag and
> > > prevent "popping" given that Royale generates the  tags
> dynamically.
> > >
> > > So, we need a volunteer to create some examples of how to use browser
> > > embedding in dynamically generated  tags so we can see if there
> will
> > > be any benefit or not.  And if not, possibly explore other options,
> such
> > as
> > > delivering all assets in one true binary blob somehow.
> > >
> > > HTH,
> > > -Alex
> > >
> > > On 6/5/19, 7:05 AM, "Frost, Andrew"  wrote:
> > >
> > > Yes, me :-)
> > >
> > > I'm pushing Royale internally, I think it has a lot of promise -
> > > although I still do find it a little frustrating at times internally!
> In
> > > terms of what support you can give, the sorts of things you're already
> > > doing are great, but yes it might mean we lean a little more on this
> > > mailing list if we're facing tricky issues.
> > >
> > > We have one sales case in particular at the moment which has the
> > > potential to be very big, we're hoping they move forwards with a proof
> of
> > > concept project which would take a small part of their app and port
> this
> > to
> > > Royale. A few issues we've found so far from investigations:
> > > - their flex code is embedding icons that are contained within a
> SWF.
> > > Royale compiler didn't seem to like this, not sure whether it's just
> > syntax
> > > or whether we need to pull all the assets out (not a big job, we can
> > > automate that..)
> > > - they have binding using functions e.g.
> > > text="{localizationHelper.getString('fieldName')}", which caused an
> issue
> > > when generating the JavaScript code as the string-within-a-string
> seemed
> > to
> > > upset the parser. We can look at this later perhaps though..
> > > - when we got it compiling, the main thing was with responsiveness
> > > i.e. trying to get the app to resize and for all the internal elements
> to
> > > then resize. We may use the MX emulation classes for this but it still
> > > looked like more support is needed - although we only looked briefly at
> > > this.
> > >
> > > Once those issues are sorted though, we would have one big task (to
> > > recreate a very advanced data grid control that they'd developed in
> > >

Re: Embedded Assets (was Re: AIR and Royale)

[Carlos Rovira]

Hi Andrew,

Can see so much about that page, I didn't know about it. looking at history
I just renamed it when I was refactoring names, but I think you created
that, isn't it? Maybe you had some plan to put in a certain place in the
TOC to be accesible?
Or maybe you're asking me to add it to the TOC? if so let me know in what
point you want it and I can add it

thanks


El jue., 6 jun. 2019 a las 15:07, Andrew Wetmore ()
escribió:

> I just added a brief statement about using a URL instead of embedding
> assets in Royale in the "Flex Equivalents" page [1].
>
> @Carlos Rovira  , where does that page appear
> when
> a user is looking through the documentation? I can't find my way to it
> through the compiled Help Docs, or in the ToC.
>
>
>
> [1]  royale-docs /user-interface
> /
> flex-equivalents.md
>
> On Thu, Jun 6, 2019 at 9:26 AM Frost, Andrew 
> wrote:
>
> > Thanks, Alex & Carlos
> >
> > Yes I agree basically, embedding something in terms of how Flex does it
> > isn't something that's relevant for Royale or HTTP-based solutions in the
> > same way, and we certainly don't want to end up encoding something into
> > text base64 formats..
> >
> > It might be nice to have the compiler do some magic to recognise this
> > scenario and to grab the swf file, extract the image and then change the
> > mxml so that it just becomes a url reference.. but that's probably a lot
> of
> > work compared to just doing this as a manual operation which is just a
> > one-off update needed in the code.
> >
> > So that:
> > 
> > is turned into something like
> > 
> >
> > Anyway, if we get asked to do this then I'll take a look to see whether
> it
> > could be merged into the toolchain somehow.. having a quick look into the
> > SWF it could be fun as these icons are actually not just pure images but
> > include some shape output from the Flash/Animate authoring tools too..
> but
> > I guess we can just have some quick AS3 tool to extract these with the
> > appropriate shape and save them to png..
> >
> > For now I'll wait to see whether the project does actually go ahead!!
> >
> > thanks
> >
> >Andrew
> >
> >
> > -Original Message-
> > From: Carlos Rovira [mailto:carlosrov...@apache.org]
> > Sent: 06 June 2019 11:33
> > To: dev@royale.apache.org
> > Subject: [EXTERNAL] Re: Embedded Assets (was Re: AIR and Royale)
> >
> > Hi,
> >
> > I think in the case of HTML, does not have sense to me the concept of
> > Embed like in Flex. Maybe of SWF target or others (don't know if WebAsm
> > could benefit from something like this) Maybe for HTML use something like
> > Embed metadata, could just copy the assets to the resources folder to be
> > available, since like Alex said, a request per asset is needed and making
> > other kind of big file seems strange in this case (maybe not). Although
> we
> > have solved the copying of assets in different ways through compiler for
> > libraries and ANT/MAVEN automation in Application.
> >
> > for me this could be something to investigate in the future, but with low
> > priority, since I think we still have bigger fish to fry
> >
> > just my 2...
> >
> >
> > El mié., 5 jun. 2019 a las 18:07, Alex Harui ( >)
> > escribió:
> >
> > > Regarding embedded assets in Royale:
> > >
> > > There is no embedded asset support at this time because it is not
> > > obvious to me it will be worth it.  We need a volunteer to devise a
> > > strategy that works and implement it.
> > >
> > > In Flex/Flash, my understanding is that folks embedded assets to save
> > > on server requests for assets like images.  That makes sense because,
> > > since a SWF is a compressed binary and most assets are compressed
> > > binaries, you can essentially append the assets to the SWF.
> > >
> > > However, for Royale in the browser, every implementation of "embedding"
> > > I've seen seems to Base64 encode the asset, converting it to text and
> > > increasing the number of bytes.  And the resulting Base64 bytes may
> > > deteriorate the gzip compression of the .html file.
> > >
> > > Flash also had frames in the SWF and assets could be embedded on later
> > > frames allowing a download progress bar to show up before all of the
> > > rest of the SWF is downloaded.  I don't know what the equivalent for
> > > that is without Flash.
> > >
> > > I believe another advantage of embedding in Flash was that the asset
> > > was ready to be instantiated and placed on the display list right
> > > away.  I'm not clear that an embedded Base64 image can be used in an
> > >  tag and prevent "popping" given that Royale generates the 
> > tags dynamically.
> > >
> > > So, we need a volunteer to create some examples of how to use browser
> > > embedding in dynamically generated  tags so we can see if there
> > > will be any benefit or not.  And if not, possibly explore other
> > > options, such as delivering all assets in one true binary blo

Re: Embedded Assets (was Re: AIR and Royale)

[Harbs]

I don’t know how they do it, but it seems pretty straight-forward:
1. The compiler reads the binary file.
2. It Base64 encodes the content. 
https://www.baeldung.com/java-base64-encode-and-decode 

3. It writes the src or background using the Base64 string. That could be 
either in CSS or in code.
Details on data uris here: https://css-tricks.com/data-uris/ 


Harbs

> On Jun 7, 2019, at 12:12 AM, Carlos Rovira  wrote:
> 
> ok Om thanks for sharing.
> Do you have some url with some code to see an example of how they do it?
> thanks
> 
> El jue., 6 jun. 2019 a las 19:05, OmPrakash Muppirala ()
> escribió:
> 
>> In recent applications using React/Webpack, I have seen defaults of using
>> base64 embedding of files less than 10k in size.
>> 
>> I guess the tradeoff is in between firing off several http requests for
>> small files vs embedding them is a less efficient format.
>> 
>> I think a similar strategy would work for Royale.
>> 
>> Thanks,
>> Om
>> 
>> On Thu, Jun 6, 2019, 3:32 AM Carlos Rovira 
>> wrote:
>> 
>>> Hi,
>>> 
>>> I think in the case of HTML, does not have sense to me the concept of
>> Embed
>>> like in Flex. Maybe of SWF target or others (don't know if WebAsm could
>>> benefit from something like this)
>>> Maybe for HTML use something like Embed metadata, could just copy the
>>> assets to the resources folder to be available, since like Alex said, a
>>> request per asset is needed and making other kind of big file seems
>> strange
>>> in this case (maybe not). Although we have solved the copying of assets
>> in
>>> different ways through compiler for libraries and ANT/MAVEN automation in
>>> Application.
>>> 
>>> for me this could be something to investigate in the future, but with low
>>> priority, since I think we still have bigger fish to fry
>>> 
>>> just my 2...
>>> 
>>> 
>>> El mié., 5 jun. 2019 a las 18:07, Alex Harui (>> )
>>> escribió:
>>> 
 Regarding embedded assets in Royale:
 
 There is no embedded asset support at this time because it is not
>> obvious
 to me it will be worth it.  We need a volunteer to devise a strategy
>> that
 works and implement it.
 
 In Flex/Flash, my understanding is that folks embedded assets to save
>> on
 server requests for assets like images.  That makes sense because,
>> since
>>> a
 SWF is a compressed binary and most assets are compressed binaries, you
>>> can
 essentially append the assets to the SWF.
 
 However, for Royale in the browser, every implementation of "embedding"
 I've seen seems to Base64 encode the asset, converting it to text and
 increasing the number of bytes.  And the resulting Base64 bytes may
 deteriorate the gzip compression of the .html file.
 
 Flash also had frames in the SWF and assets could be embedded on later
 frames allowing a download progress bar to show up before all of the
>> rest
 of the SWF is downloaded.  I don't know what the equivalent for that is
 without Flash.
 
 I believe another advantage of embedding in Flash was that the asset
>> was
 ready to be instantiated and placed on the display list right away.
>> I'm
 not clear that an embedded Base64 image can be used in an  tag and
 prevent "popping" given that Royale generates the  tags
>> dynamically.
 
 So, we need a volunteer to create some examples of how to use browser
 embedding in dynamically generated  tags so we can see if there
>> will
 be any benefit or not.  And if not, possibly explore other options,
>> such
>>> as
 delivering all assets in one true binary blob somehow.
 
 HTH,
 -Alex
 
 On 6/5/19, 7:05 AM, "Frost, Andrew"  wrote:
 
Yes, me :-)
 
I'm pushing Royale internally, I think it has a lot of promise -
 although I still do find it a little frustrating at times internally!
>> In
 terms of what support you can give, the sorts of things you're already
 doing are great, but yes it might mean we lean a little more on this
 mailing list if we're facing tricky issues.
 
We have one sales case in particular at the moment which has the
 potential to be very big, we're hoping they move forwards with a proof
>> of
 concept project which would take a small part of their app and port
>> this
>>> to
 Royale. A few issues we've found so far from investigations:
- their flex code is embedding icons that are contained within a
>> SWF.
 Royale compiler didn't seem to like this, not sure whether it's just
>>> syntax
 or whether we need to pull all the assets out (not a big job, we can
 automate that..)
- they have binding using functions e.g.
 text="{localizationHelper.getString('fieldName')}", which caused an
>> issue
 when generating the JavaScript code as the string-within-a-string
>> seemed
>>> to
 upset the parser. We can

Re: AIR and Royale

[Carlos Rovira]

Hi
I think so. All people that want to be listed as "Royale specialist"
(developers, consultants, or other posible denominations), should be
admitted too in that list

El mié., 5 jun. 2019 a las 17:57, Piotr Zarzycki ()
escribió:

> Hi Dave,
>
> If I understand from those page not only companies can be listed but also
> individuals - Am I correct?
>
> Thanks,
> Piotr
>
>
> On Wed, Jun 5, 2019, 5:53 PM Dave Fisher  wrote:
>
> > This is fine as long as it is done in a vendor neutral manner with clear
> > instruction on how to ask to be added. Also, there should be clarity that
> > no vendor is “endorsed”.
> >
> > Examples:
> > https://www.openoffice.org/bizdev/consultants.html
> > https://wiki.apache.org/cassandra/ThirdPartySupport
> >
> >
> https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Service+Providers
> >
> https://wiki.apache.org/hadoop/Distributions%20and%20Commercial%20Support
> >
> >
> https://cwiki.apache.org/confluence/display/WICKET/Companies+that+provide+services
> >
> > Regards,
> > Dave
> >
> > > On Jun 5, 2019, at 7:06 AM, Carlos Rovira 
> > wrote:
> > >
> > > Hi,
> > >
> > > I think one thing we can do is create some page on website where we can
> > > list companies that can give services around Royale (consultancy,
> > > development, etc...). I think that could be good for Royale.
> > > Don't know if that is a problem with Apache. Only giving a list of
> > posible
> > > companies should be ok.
> > > Other than that I can't think where we can help
> > >
> > > If you consider this ok, I can create a thread so companies that want
> to
> > be
> > > listed, can express they want to, and I can create a page in our site
> > with
> > > the logos and urls and maybe more (contact person?, ...)
> > >
> > > thanks
> > >
> > >
> > >
> > > El mar., 4 jun. 2019 a las 15:40, Harbs ()
> > escribió:
> > >
> > >> Well to start with: Does anyone know anyone working for them?
> > >>
> > >> I’d like to hear from them what it would take for them to push Royale
> > more.
> > >>
> > >>> On Jun 4, 2019, at 4:10 PM, Carlos Rovira 
> > >> wrote:
> > >>>
> > >>> Hi,
> > >>>
> > >>> what's the kind of support you're thinking ?
> > >>>
> > >>>
> > >>>
> > >>> El mar., 4 jun. 2019 a las 9:36, Piotr Zarzycki (<
> > >> piotrzarzyck...@gmail.com>)
> > >>> escribió:
> > >>>
> >  Hi Harbs,
> > 
> >  I was exactly think the same about that, so I'm keeping finger
> crossed
> > >> to
> >  that effort.
> > 
> >  Thanks,
> >  Piotr
> > 
> >  wt., 4 cze 2019 o 09:34 Harbs  napisał(a):
> > 
> > > I just heard about this announcement.[1]
> > >
> > > I went over to the Harman site and was reading this page.[2]
> > >
> > > I was particularly struck by this statement:
> > >
> > > HARMAN’s offerings also include consultancy, support and migration
> > > services for companies looking to move their applications away from
> > >> Flash
> > > technologies over to HTML5 via solutions such as Angular, Apache
> > Royale
> >  and
> > > other JavaScript based frameworks.
> > >
> > >
> > > Considering that they mention Royale explicitly as the number 2
> >  framework,
> > > I’m guessing they will be pushing Royale to a certain degree. We
> > should
> > > probably look to support that effort.
> > >
> > > [1]https://theblog.adobe.com/the-future-of-adobe-air/ <
> > > https://theblog.adobe.com/the-future-of-adobe-air/>
> > > [2]https://services.harman.com/partners/adobe <
> > > https://services.harman.com/partners/adobe>
> > 
> > 
> > 
> >  --
> > 
> >  Piotr Zarzycki
> > 
> >  Patreon: *https://www.patreon.com/piotrzarzycki
> >  *
> > 
> > >>>
> > >>>
> > >>> --
> > >>> Carlos Rovira
> > >>> http://about.me/carlosrovira
> > >>
> > >>
> > >
> > > --
> > > Carlos Rovira
> > > http://about.me/carlosrovira
> >
> >
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: AIR and Royale

[Dave Fisher]

Yes. I agree that that would be vendor neutral.

Sent from my iPhone

> On Jun 6, 2019, at 2:41 PM, Carlos Rovira  wrote:
> 
> Hi
> I think so. All people that want to be listed as "Royale specialist"
> (developers, consultants, or other posible denominations), should be
> admitted too in that list
> 
> El mié., 5 jun. 2019 a las 17:57, Piotr Zarzycki ()
> escribió:
> 
>> Hi Dave,
>> 
>> If I understand from those page not only companies can be listed but also
>> individuals - Am I correct?
>> 
>> Thanks,
>> Piotr
>> 
>> 
>>> On Wed, Jun 5, 2019, 5:53 PM Dave Fisher  wrote:
>>> 
>>> This is fine as long as it is done in a vendor neutral manner with clear
>>> instruction on how to ask to be added. Also, there should be clarity that
>>> no vendor is “endorsed”.
>>> 
>>> Examples:
>>> https://www.openoffice.org/bizdev/consultants.html
>>> https://wiki.apache.org/cassandra/ThirdPartySupport
>>> 
>>> 
>> https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Service+Providers
>>> 
>> https://wiki.apache.org/hadoop/Distributions%20and%20Commercial%20Support
>>> 
>>> 
>> https://cwiki.apache.org/confluence/display/WICKET/Companies+that+provide+services
>>> 
>>> Regards,
>>> Dave
>>> 
 On Jun 5, 2019, at 7:06 AM, Carlos Rovira 
>>> wrote:
 
 Hi,
 
 I think one thing we can do is create some page on website where we can
 list companies that can give services around Royale (consultancy,
 development, etc...). I think that could be good for Royale.
 Don't know if that is a problem with Apache. Only giving a list of
>>> posible
 companies should be ok.
 Other than that I can't think where we can help
 
 If you consider this ok, I can create a thread so companies that want
>> to
>>> be
 listed, can express they want to, and I can create a page in our site
>>> with
 the logos and urls and maybe more (contact person?, ...)
 
 thanks
 
 
 
 El mar., 4 jun. 2019 a las 15:40, Harbs ()
>>> escribió:
 
> Well to start with: Does anyone know anyone working for them?
> 
> I’d like to hear from them what it would take for them to push Royale
>>> more.
> 
>> On Jun 4, 2019, at 4:10 PM, Carlos Rovira 
> wrote:
>> 
>> Hi,
>> 
>> what's the kind of support you're thinking ?
>> 
>> 
>> 
>> El mar., 4 jun. 2019 a las 9:36, Piotr Zarzycki (<
> piotrzarzyck...@gmail.com>)
>> escribió:
>> 
>>> Hi Harbs,
>>> 
>>> I was exactly think the same about that, so I'm keeping finger
>> crossed
> to
>>> that effort.
>>> 
>>> Thanks,
>>> Piotr
>>> 
>>> wt., 4 cze 2019 o 09:34 Harbs  napisał(a):
>>> 
 I just heard about this announcement.[1]
 
 I went over to the Harman site and was reading this page.[2]
 
 I was particularly struck by this statement:
 
 HARMAN’s offerings also include consultancy, support and migration
 services for companies looking to move their applications away from
> Flash
 technologies over to HTML5 via solutions such as Angular, Apache
>>> Royale
>>> and
 other JavaScript based frameworks.
 
 
 Considering that they mention Royale explicitly as the number 2
>>> framework,
 I’m guessing they will be pushing Royale to a certain degree. We
>>> should
 probably look to support that effort.
 
 [1]https://theblog.adobe.com/the-future-of-adobe-air/ <
 https://theblog.adobe.com/the-future-of-adobe-air/>
 [2]https://services.harman.com/partners/adobe <
 https://services.harman.com/partners/adobe>
>>> 
>>> 
>>> 
>>> --
>>> 
>>> Piotr Zarzycki
>>> 
>>> Patreon: *https://www.patreon.com/piotrzarzycki
>>> *
>>> 
>> 
>> 
>> --
>> Carlos Rovira
>> http://about.me/carlosrovira
> 
> 
 
 --
 Carlos Rovira
 http://about.me/carlosrovira
>>> 
>>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Re: Embedded Assets (was Re: AIR and Royale)

[Andrew Wetmore]

@carlos.rov...@gmail.com  I think the
"flex-equivalents" page should go just below the "components" page in the
ToC. If you told me how to add things to the ToC, I don't remember it!

And, really, I think both Component Sets and Flex Equivalents should be
under a User Interface heading, as the source files are.

On Thu, Jun 6, 2019 at 6:20 PM Carlos Rovira 
wrote:

> Hi Andrew,
>
> Can see so much about that page, I didn't know about it. looking at history
> I just renamed it when I was refactoring names, but I think you created
> that, isn't it? Maybe you had some plan to put in a certain place in the
> TOC to be accesible?
> Or maybe you're asking me to add it to the TOC? if so let me know in what
> point you want it and I can add it
>
> thanks
>
>
> El jue., 6 jun. 2019 a las 15:07, Andrew Wetmore ()
> escribió:
>
> > I just added a brief statement about using a URL instead of embedding
> > assets in Royale in the "Flex Equivalents" page [1].
> >
> > @Carlos Rovira  , where does that page appear
> > when
> > a user is looking through the documentation? I can't find my way to it
> > through the compiled Help Docs, or in the ToC.
> >
> >
> >
> > [1]  royale-docs /user-interface
> > /
> > flex-equivalents.md
> >
> > On Thu, Jun 6, 2019 at 9:26 AM Frost, Andrew 
> > wrote:
> >
> > > Thanks, Alex & Carlos
> > >
> > > Yes I agree basically, embedding something in terms of how Flex does it
> > > isn't something that's relevant for Royale or HTTP-based solutions in
> the
> > > same way, and we certainly don't want to end up encoding something into
> > > text base64 formats..
> > >
> > > It might be nice to have the compiler do some magic to recognise this
> > > scenario and to grab the swf file, extract the image and then change
> the
> > > mxml so that it just becomes a url reference.. but that's probably a
> lot
> > of
> > > work compared to just doing this as a manual operation which is just a
> > > one-off update needed in the code.
> > >
> > > So that:
> > > 
> > > is turned into something like
> > > 
> > >
> > > Anyway, if we get asked to do this then I'll take a look to see whether
> > it
> > > could be merged into the toolchain somehow.. having a quick look into
> the
> > > SWF it could be fun as these icons are actually not just pure images
> but
> > > include some shape output from the Flash/Animate authoring tools too..
> > but
> > > I guess we can just have some quick AS3 tool to extract these with the
> > > appropriate shape and save them to png..
> > >
> > > For now I'll wait to see whether the project does actually go ahead!!
> > >
> > > thanks
> > >
> > >Andrew
> > >
> > >
> > > -Original Message-
> > > From: Carlos Rovira [mailto:carlosrov...@apache.org]
> > > Sent: 06 June 2019 11:33
> > > To: dev@royale.apache.org
> > > Subject: [EXTERNAL] Re: Embedded Assets (was Re: AIR and Royale)
> > >
> > > Hi,
> > >
> > > I think in the case of HTML, does not have sense to me the concept of
> > > Embed like in Flex. Maybe of SWF target or others (don't know if WebAsm
> > > could benefit from something like this) Maybe for HTML use something
> like
> > > Embed metadata, could just copy the assets to the resources folder to
> be
> > > available, since like Alex said, a request per asset is needed and
> making
> > > other kind of big file seems strange in this case (maybe not). Although
> > we
> > > have solved the copying of assets in different ways through compiler
> for
> > > libraries and ANT/MAVEN automation in Application.
> > >
> > > for me this could be something to investigate in the future, but with
> low
> > > priority, since I think we still have bigger fish to fry
> > >
> > > just my 2...
> > >
> > >
> > > El mié., 5 jun. 2019 a las 18:07, Alex Harui ( > >)
> > > escribió:
> > >
> > > > Regarding embedded assets in Royale:
> > > >
> > > > There is no embedded asset support at this time because it is not
> > > > obvious to me it will be worth it.  We need a volunteer to devise a
> > > > strategy that works and implement it.
> > > >
> > > > In Flex/Flash, my understanding is that folks embedded assets to save
> > > > on server requests for assets like images.  That makes sense because,
> > > > since a SWF is a compressed binary and most assets are compressed
> > > > binaries, you can essentially append the assets to the SWF.
> > > >
> > > > However, for Royale in the browser, every implementation of
> "embedding"
> > > > I've seen seems to Base64 encode the asset, converting it to text and
> > > > increasing the number of bytes.  And the resulting Base64 bytes may
> > > > deteriorate the gzip compression of the .html file.
> > > >
> > > > Flash also had frames in the SWF and assets could be embedded on
> later
> > > > frames allowing a download progress bar to show up before all of the
> > > > rest of the SWF is downloaded.  I don't know what the equivalent for
> > > > that is wit

Release Step 001 Succeeded

[Apache Royale CI Server]

Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_001 and run the following commands:
git push
git checkout release/0.9.6
git push -u origin release/0.9.6

You will need your Apache/Github username and 2FA token.

Release Step 001a Succeeded

[Apache Royale CI Server]

Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_001a_If_Utils and run the following 
commands:
git push

You will need your Apache/Github username and 2FA token.

Release Step 002 Succeeded

[Apache Royale CI Server]

Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_002 and run the following commands:
git push
git push origin org.apache.royale.compiler-0.9.6-rc1

You will need your Apache/Github username and 2FA token.

Release Step 002a Succeeded

[Apache Royale CI Server]

Continue on to Release Step 003

Release Step 003 Succeeded

[Apache Royale CI Server]

>From the royale-compiler repo:
1. If you are releasing the utils jars (compiler-jburg-types and 
compiler-build-tools), Run:
  ant -f releasesteps.xml Release_Step_003 -Dutils=true -Drelease.version=0.9.6
Otherwise, Run:
 ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.6
This will download the artifacts then unzip and compile the source artifact.
2. Validate that the compiled artifacts match the downloaded artifacts.
3. If they do, then run ant -f releasesteps.xml Release_Step_003_Sign 
-Drelease.version=0.9.6
This will PGP sign the source ZIP and compiled JARs
4. Then run ant -f releasesteps.xml Release_Step_003_Upload 
-Drelease.version=0.9.6
This will upload the signed artifacts to Maven Release Staging.  Do not "Close" 
the staging repository until the other repos have been added.

Release Step 004 Succeeded

[Apache Royale CI Server]

Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_004 and run the following commands:
git push
git checkout release/0.9.6
git push -u origin release/0.9.6

You will need your Apache/Github username and 2FA token.

Release Step 005 Succeeded

[Apache Royale CI Server]

Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_005 and run the following commands:
git push

You will need your Apache/Github username and 2FA token.

Release Step 005a Succeeded

[Apache Royale CI Server]

Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_005a and run the following commands:
git push

You will need your Apache/Github username and 2FA token.

Release Step 006 Succeeded

[Apache Royale CI Server]

Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_006 and run the following commands:
git push
git push origin org.apache.royale.typedefs-0.9.6-rc1

You will need your Apache/Github username and 2FA token.

Release Step 007 Succeeded

[Apache Royale CI Server]

>From the royale-typedefs repo:
1. Run ant -f releasesteps.xml Release_Step_007 -Drelease.version=0.9.6
This will download the artifacts then unzip and compile the source artifact.
2. Validate that the compiled artifacts match the downloaded artifacts.
3. If they do, then run ant -f releasesteps.xml Release_Step_007_Sign 
-Drelease.version=0.9.6
This will PGP sign the source ZIP and compiled JARs
4. Then run ant -f releasesteps.xml Release_Step_007_Upload 
-Drelease.version=0.9.6
This will upload the signed artifacts to Maven Release Staging.  Do not "Close" 
the staging repository until the other repos have been added.

Build failed in Jenkins: royale-asjs_jsonly #3061

[Apache Royale CI Server]

See 


--
[...truncated 2.12 MB...]
[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

Release Step 008 Succeeded

[Apache Royale CI Server]

Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_008 and run the following commands:
git push
git checkout release/0.9.6
git push -u origin release/0.9.6

You will need your Apache/Github username and 2FA token.

Royale_Release_Step_009 - Build # 10 - Failure!

[Apache Royale CI Server]

Royale_Release_Step_009 - Build # 10 - Failure:

Check console output at 
http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/Royale_Release_Step_009/10/
 to view the results.

Release Step 009 Succeeded

[Apache Royale CI Server]

Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_009 and run the following commands:
git push

You will need your Apache/Github username and 2FA token.

Release Step 010 Succeeded

[Apache Royale CI Server]

Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_010 and run the following commands:
git push
git push origin org.apache.royale.framework-0.9.6-rc1

You will need your Apache/Github username and 2FA token.

RE: Compiler Build Failing on Windows

[Yishay Weiss]

I haven’t had problems building the compiler with Ant. Shiffy, can you share 
the values of the env vars Alex wrote down?



AIR_HOME
PLAYERGLOBAL_HOME
FLASHPLAYER_DEBUGGER





From: Piotr Zarzycki 
Sent: Thursday, June 6, 2019 1:40:17 PM
To: dev@royale.apache.org
Subject: Re: Compiler Build Failing on Windows

I believe the most important thing right now is to getting back our nightly
build and see whether there it doesn't occur. If it doesn't you may have
your answer to the issue without doing anything on your local machine.

czw., 6 cze 2019 o 12:36 Carlos Rovira  napisał(a):

> I have pendent to check build with Env vars, although can't say where I
> could try since that requieres some hours to pursue that task.
> I think we should all try to do this, since in doing that we can finally
> refine the process of build that is the biggest problem in Royale along
> with releases.
> Getting Royale to build without any issue for any new comers is the most
> important thing along with getting releases monthly without much effort.
> (And of course continue with documentation)
>
>
>
> El mié., 5 jun. 2019 a las 17:53, Alex Harui ()
> escribió:
>
> > As discussed recently on some other thread, environment variables matter
> > and the documentation may not be up-to-date.
> >
> > We build both SWF&JS or JS-Only packages based on environment variables.
> > Either you have the Adobe stuff for SWF and environment variables
> pointing
> > to them or not.  If you only have some of the Adobe environment variables
> > but not others, you'll probably confuse the builds.
> >
> > AIR_HOME
> > PLAYERGLOBAL_HOME
> > FLASHPLAYER_DEBUGGER
> >
> > Either set all 3 or don't set any of the 3.
> >
> > HTH,
> > -Alex
> >
> > On 6/5/19, 7:27 AM, "Piotr Zarzycki"  wrote:
> >
> > Carlos,
> >
> > I think it is ANT build. Yesterday I tried locally and had the same
> > issue.
> > I was going to report it here as well.
> >
> > Thanks,
> > Piotr
> >
> > śr., 5 cze 2019 o 16:00 Carlos Rovira 
> > napisał(a):
> >
> > > Hi
> > >
> > > can you provide more info about what method are you using to build?
> > ANT?
> > > Maven? and provide the steps you use, also if you have set up some
> > env
> > > vars?
> > > thanks
> > >
> > > El mié., 5 jun. 2019 a las 12:43, Shiffy ()
> > escribió:
> > >
> > > > I’m trying to build the compiler on Windows and it keeps failing
> > in the
> > > > tests.
> > > >
> > > > Here’s one example of a failed test that I’m getting:
> > > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2FTpQynEmF&data=02%7C01%7Caharui%40adobe.com%7C0c7d3e7f051245540c5508d6e9c1fbc1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636953416690581144&sdata=R9R5myGACz%2BUaexnDobnVD%2FMvf1J%2FCjXeaSlNI5GrOA%3D&reserved=0
> > > >
> > > > The test results are hard to read, but one difference I see
> > between the
> > > > expected results and the actual results is that it expects
> extends
> > Object
> > > > and it’s extending flash.display::Sprite.
> > > >
> > > > Any ideas on what’s wrong?
> > > >
> > >
> > >
> > > --
> > > Carlos Rovira
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0c7d3e7f051245540c5508d6e9c1fbc1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636953416690581144&sdata=F%2By0%2BMDEJg0wYdAsOTHGIeWGbaCGuzRfKPAFLJh6JMI%3D&reserved=0
> > >
> >
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C0c7d3e7f051245540c5508d6e9c1fbc1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636953416690581144&sdata=mGRcOuyal9mZruQc%2FPG39mGoHPvyVbWciHoGzELiGsA%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C0c7d3e7f051245540c5508d6e9c1fbc1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636953416690581144&sdata=mGRcOuyal9mZruQc%2FPG39mGoHPvyVbWciHoGzELiGsA%3D&reserved=0
> > >*
> >
> >
> >
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>


--

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
*

Release Step 011 Succeeded

[Apache Royale CI Server]

>From the royale-asjs repo:
1. Run ant -f releasesteps.xml Release_Step_011 -Drelease.version=0.9.6
This will download the artifacts then unzip and compile the source artifact.
2. Validate that the compiled artifacts match the downloaded artifacts.
3. If they do, then run ant -f releasesteps.xml Release_Step_011_Sign 
-Drelease.version=0.9.6
This will PGP sign the source ZIP and compiled JARs
4. Then run ant -f releasesteps.xml Release_Step_011_Upload 
-Drelease.version=0.9.6
This will upload the signed artifacts to Maven Release Staging.  Verify that 
the compiler and typedefs artifacts are there along with the asjs artifacts, 
then hit the close to close the staging repo.