royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <>
Subject Re: How to get assets (svg, png,...) inside *-js.swc and *-swf.swc libraries
Date Wed, 28 Feb 2018 17:13:26 GMT
We could do that if we get enough complaints, but the nice thing about the
way it currently works is that the output folder is all-inclusive.  You
can deploy (after a Maven build) the target/javascript/bin/js-release
folder and your assets will be in there, and the URLs will be
URL("assets/MyAsset.jpg").  In your proposal, the user has to remember to
copy the assets folder as well, and the URLs will look like
URL("../../../../assets/MyAsset.jpg") and the layout on the web server
will have to have the same deep folder structure.

Are you seeing long build times?  We could just choose to not overwrite
existing files.  That might save time.

My 2 cents,

On 2/28/18, 8:40 AM, " on behalf of Carlos Rovira"
< on behalf of> wrote:

>Hi, don't know if I understand right since all the things about the
>compiler are beyond my scope, but what I'm suggesting is to realocate
>resources. But don't know if this sounds crazy or not. In this way we can
>support current outputs (JS and SWF) but prepare for future outputs
>(WEBASM, iOS, Android,...)
>so it will end as is:
>  |
>  ------ assets (inside this folder all output like css, svg, png,...)
>  |
>  ------- swf (in this folder the .swf (s) app + modules, but for this all
>should search for resources in "../assets" for all assets not @Embeded in
>  |
>  ------- js (in this folder will go html and all js files that again
>should look for resources in  "../assets"
>  |
>  -------- webasm
>  |
>  -------- iOS
>  |
>  --------  Android
>  |
>  --------  whatever other output we want to implement
>if not I understand that each output should provide its own assets folder,
>and this will end wasting resources for duplication (n times depending on
>how many outputs we want to get) and wasting time and CPU process..
>does this make sense?
>2018-02-27 18:11 GMT+01:00 Alex Harui <>:
>> Hi Jason,
>> Actually, I didn't know that.  I'm not a compiler guy.  Someone else
>> the key pieces.  I could see that way back, a compiler might have
>> out intermediate information for the next step, like having a separate
>> linker that links the object files.  But I don't think I've seen (or
>> I just haven't used) options to output extra information for
>> post-processing after the final output.  We could certainly output extra
>> information, but then that information needs to be parsed again to be
>> by the publisher.
>> If that's the way folks want to go, all we need is a volunteer to make
>> happen.  Currently, the publisher does not need the AST so it might even
>> be possible to write the publisher in ActionScript.  But that might make
>> it harder to integrate with Maven.
>> What do others think?
>> -Alex
>> On 2/27/18, 8:54 AM, "Jason Guild" <> wrote:
>> >Alex:
>> >
>> >As you probably know, compilers in the old days were implemented in a
>> >series of stages as separate processes due to memory size limitations.
>> >The output from the previous stage was fed to the next stage as
>> >compilation proceeded until object files were produced.
>> >
>> >Maybe it makes sense for the compiler to output everything the
>> >needs (final ASTs and/or other metadata, etc) when it exits.
>> >Then a separate publisher process could optionally use that output to
>> >all the expected publish-type things without being intermingled with
>> >compiler itself.
>> >
>> >The publisher would probably be simpler to understand on its own and
>> >maybe more people could be involved with it.
>> >
>> >Jason
>> >
>> >On 2/26/2018 8:49 PM, Alex Harui wrote:
>> >> The only
>> >> downside I've thought of is just that it is weird to have a publisher
>> >> attached to the compiler.  I don't think most compilers have a
>> >>publisher.
>> >
>> >--
>> >Jason Guild
>> >Analyst/Programmer V
>> >State of Alaska - Department of Transportation & Public Facilities
>> >Information Systems and Services Division
>> >820 E. 15th Ave.
>> >Anchorage, Alaska 99501
>> >
>Carlos Rovira

View raw message