ok Alex, maybe not necessary right now. If we start to get some decent output tied to images in SWF, that could change
thanks 2018-02-28 23:14 GMT+01:00 Alex Harui <[email protected]>: > > > On 2/28/18, 1:52 PM, "[email protected] on behalf of Carlos Rovira" > <[email protected] on behalf of [email protected]> wrote: > > >Hi Alex, > >you're right, maybe this deserves more thinking,...in the actual approach, > >I think that compiler should copy the same assets folder to target so SWF > >can access it right? > > We could do that. Some folks don't think we should copy assets as part of > the compiler, and that the publisher should be a separate thing. Whatever > we do here will take time, so I'm probably not going to spend any time on > it right now. Lots of other bigger fish to fry. At least folks can copy > from bin/js-debug if they want to. I would recommend copying resources in > your Maven and Ant scripts for now. > > Thanks, > -Alex > > > >2018-02-28 18:13 GMT+01:00 Alex Harui <[email protected]>: > > > >> 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, > >> -Alex > >> > >> On 2/28/18, 8:40 AM, "[email protected] on behalf of Carlos > >>Rovira" > >> <[email protected] on behalf of [email protected]> 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: > >> > > >> > > >> >target > >> > | > >> > ------ 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 > >> >swf > >> > | > >> > ------- 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 <[email protected]>: > >> > > >> >> Hi Jason, > >> >> > >> >> Actually, I didn't know that. I'm not a compiler guy. Someone else > >> >>wrote > >> >> the key pieces. I could see that way back, a compiler might have > >> >>written > >> >> 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 > >> >>maybe > >> >> 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 > >> >>used > >> >> by the publisher. > >> >> > >> >> If that's the way folks want to go, all we need is a volunteer to > >>make > >> >>it > >> >> 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" <[email protected]> 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 > >> >>publisher > >> >> >needs (final ASTs and/or other metadata, etc) when it exits. > >> >> >Then a separate publisher process could optionally use that output > >>to > >> >>do > >> >> >all the expected publish-type things without being intermingled with > >> >>the > >> >> >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 > >> >https://na01.safelinks.protection.outlook.com/?url= > >> http%3A%2F%2Fabout.me%2 > >> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > >> 7C3da558b1a44a46dfc41b08d5 > >> >7ec9fc08%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > >> 7C636554328342487363&s > >> >data=aduUVLnj5Q8FYqR9KJ6WZeEoLN1GqSVVbalBmhAwZSA%3D&reserved=0 > >> > >> > > > > > >-- > >Carlos Rovira > >https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fabout.me%2 > >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > 7C43a5a6f66b7b4869aa6c08d5 > >7ef597aa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > 7C636554515653880312&s > >data=%2F90VveLbQkI3GLiIaKQbwXWjhrtKilTmxVkoAN0gaLI%3D&reserved=0 > > -- Carlos Rovira http://about.me/carlosrovira
