I put hljs.as class in a library, and in doing that hljs.as is processed in GoogDepsWriter and inject_html is pulled from that @externs class. This solve the problem from that point.
So the real problem here is: If users has @externs classes in the Application project, then they will get another processing different to have this one in a library. And inject_html is not processed and, another thing: source map file is generated when the externs class is in Application project (while I removed creating in a recent commit). Do you know some way to fix this problem in the best way? thanks El lun., 3 jun. 2019 a las 16:13, Carlos Rovira (<[email protected]>) escribió: > Hi Alex, > > trying to make inject_html work for @externs classes. > I'm seeing that GoogDepsWriter are not processing hljs.as extern class in > my B012 example, that is located directly in top level package. > I output with println all getFileInfo() classes there and hljs is not part > of that set. Maybe is only processing @extern classes inside libraries? > in this case the @externs class is located in the Application project. > > I'm going to see if I can get it's processed in other part and try to read > from there the inject_html > > Just want to inform since could be something by design or not wanted effect > > thanks > > Carlos > > > El sáb., 4 may. 2019 a las 5:36, Alex Harui (<[email protected]>) > escribió: > >> I just searched the compiler code. Current inject_html handling appears >> to be in GoogDepsWriter.java. >> >> On 5/3/19, 2:04 PM, "Carlos Rovira" <[email protected]> wrote: >> >> Hi, >> >> I now Greg is busy now with an important update >> I can try to do it myself if Alex point me to the code I should look, >> for >> me it would be part of the task to make this blog example in the best >> way >> possible. >> thanks >> >> El vie., 3 may. 2019 a las 22:58, Greg Dove (<[email protected]>) >> escribió: >> >> > 'I'm pretty sure externs are not scanned for inject_html. >> Volunteers are >> > welcome to teach the compiler to do so.' >> > I am happy to look into this sometime in the next few days. Just >> trying to >> > finish up something else first... >> > >> > >> > >> > On Sat, May 4, 2019 at 8:54 AM Alex Harui <[email protected] >> > >> > wrote: >> > >> > > Hi Carlos, >> > > >> > > I'm pretty sure externs are not scanned for inject_html. >> Volunteers are >> > > welcome to teach the compiler to do so. >> > > >> > > -Alex >> > > >> > > On 5/3/19, 1:50 PM, "Carlos Rovira" <[email protected]> >> wrote: >> > > >> > > Hi, >> > > >> > > while putting the pieces together for the blog example I'm >> finding >> > the >> > > following. >> > > >> > > For classes that wraps a js code that is an intrinsic file >> needed to >> > > make >> > > the code function I think inject_html should work but I'm >> trying it >> > and >> > > seems this is not working. The code is like this: >> > > >> > > package >> > > { >> > > /** >> > > * @externs >> > > */ >> > > public class hljs >> > > { >> > > /** >> > > * <inject_html> >> > > * <script src=" >> > > >> > > >> > >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcdnjs.cloudflare.com%2Fajax%2Flibs%2Fhighlight.js%2F9.12.0%2Fhighlight.min.js&data=02%7C01%7Caharui%40adobe.com%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439&sdata=ubvldliTsViH69h%2FGeKby02C8H%2BKJ7HtblUo7dCnbrk%3D&reserved=0 >> > > "></script> >> > > * <link rel="stylesheet" title="Atom One Dark" href=" >> > > >> > > >> > >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcdnjs.cloudflare.com%2Fajax%2Flibs%2Fhighlight.js%2F9.12.0%2Fstyles%2Fatom-one-dark.min.css&data=02%7C01%7Caharui%40adobe.com%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439&sdata=uBI0vW721xJqBH2I%2FuUrq92KIu2Vgf6YzcrOXEFGLHM%3D&reserved=0 >> > > "> >> > > * </inject_html> >> > > */ >> > > public function hljs() >> > > { >> > > } >> > > >> > > public static function >> highlightBlock(block:Element):void {} >> > > } >> > > } >> > > >> > > So instead of add the inject_html in the code that calls the >> methods >> > in >> > > this step, I think it should be here >> > > >> > > Make this sense? >> > > >> > > >> > > >> > > El vie., 3 may. 2019 a las 9:38, Carlos Rovira (< >> > > [email protected]>) >> > > escribió: >> > > >> > > > Hi Alex, >> > > > >> > > > for me is difficult right now think about what would be >> better for >> > > > TypeScript. I think all will depend on how people interact >> in the >> > > following >> > > > months/years to show us what't the best for Royale in the >> long >> > term. >> > > > I think bringing TS to Royale as a first citizen language >> will make >> > > us >> > > > more accesible and people will considere us more since TS >> is the >> > > language >> > > > people choose over AS3 (although I for example like AS3 >> more and if >> > > we get >> > > > few things like generics we'll be great to compete with >> TS), but >> > > this is a >> > > > very complex task, so I know this hardly be done unless >> someone >> > > comes with >> > > > time and knowledge to make it happen. And if we think about >> things >> > > that are >> > > > complex and hard to add and see the importance/value it >> will bring >> > to >> > > > Royale I think a WebAssembly target will be over TS since it >> > clearly >> > > > enhance the Roayle purpose of generate multiple sources. >> > > > >> > > > In the other hand, make TS just to do TypeDefs, again maybe >> users >> > > should >> > > > express here if it could be needed, I can't say right now >> how much >> > > this >> > > > could be important for Royale, so maybe time and users will >> let us >> > > know >> > > > what to do. >> > > > >> > > > >> > > > >> > > > El jue., 2 may. 2019 a las 22:44, Alex Harui >> > > (<[email protected]>) >> > > > escribió: >> > > > >> > > >> The word "package" has many meanings. In AS3 it is a way >> of >> > > avoiding API >> > > >> name collisions. AIUI, an AS3 package in SWF code has no >> object >> > or >> > > >> function representation. It effectively just creates a >> longer >> > > "qualified >> > > >> name". IOW, in a SWF, if there is a class >> "mx.core.UIComponent", >> > > there is >> > > >> no "mx.core" object you can iterate to see all of the >> classes. >> > > >> >> > > >> For Royale's JS output, an AS3 package has an object >> > representation >> > > in >> > > >> debug mode because we use the same pattern as Google >> Closure. So >> > > there >> > > >> really would be an "mx" Object with a "core" property >> object with >> > a >> > > >> UIComponent function that serves as the constructor. >> However, in >> > > >> production, these package objects are often collapsed, so >> it is >> > > best to not >> > > >> assume the objects exist. >> > > >> >> > > >> Then there are Node/NPM packages and modules and other >> sorts of >> > > >> "packaging". But in this thread I was only referencing >> AS3 >> > > Packages. >> > > >> >> > > >> Also in this thread I mentioned TypeScript. While Royale >> could >> > > support >> > > >> TypeScript as Carlos mentioned, as an alternative to >> writing AS3, >> > I >> > > only >> > > >> mentioned it because the existence of a TypeScript >> definition for >> > a >> > > library >> > > >> indicates that the library can have a strongly-typed API >> surface >> > > which >> > > >> means it is highly likely you can create Royale typedefs >> for that >> > > library, >> > > >> and because I thought that Josh's converter was still >> working. >> > > Supporting >> > > >> TypeScript as an alternative programming language in >> Royale is a >> > > >> significant chunk of work and is not something I plan to >> work on >> > at >> > > this >> > > >> time. But I was only mentioning using TypeScript to >> generate >> > > typedefs, >> > > >> which is a different effort and could be a smaller effort >> and give >> > > us >> > > >> access to a huge set of typedefs. I have no plans to work >> on that >> > > at this >> > > >> time either, but I could imagine myself working on that if >> there >> > > was enough >> > > >> demand for it. >> > > >> >> > > >> HTH, >> > > >> -Alex >> > > >> >> > > >> On 5/2/19, 11:24 AM, "Dany Dhondt" >> <[email protected]> >> > > wrote: >> > > >> >> > > >> Hi Josh, >> > > >> >> > > >> Aren’t most of the packages just functions? >> > > >> In ES6, you’d import packages as >> > > >> Import { myFunct, myVar } from ‘my-package’ >> > > >> In older javascript you’d: >> > > >> const myPackagePointer = require(‘my-package’) >> > > >> >> > > >> So your ‘fun’ example sounds like heaven to me! This is >> > exactly >> > > what >> > > >> we need. >> > > >> >> > > >> About Typescript: do we need that at all? I think, but >> maybe >> > > this >> > > >> goes beyond my technical knowledge, all node packages are >> compiled >> > > into >> > > >> plain old javascript functions. Typescript is only needed >> for >> > > authoring the >> > > >> packages. Once compiled there’s no trace of Typescript at >> all. If >> > > this is >> > > >> indeed true, then we shouldn’t bother about Typescript at >> all, and >> > > just >> > > >> concentrate on incorporating the pure javascript libs. >> > > >> >> > > >> Dany >> > > >> >> > > >> > Op 2 mei 2019, om 19:57 heeft Josh Tynjala < >> > > [email protected]> >> > > >> het volgende geschreven: >> > > >> > >> > > >> > Just for fun, here's another way that you could >> create a >> > > typedef >> > > >> for hljs so that the highlightBlock() function is directly >> in a >> > > package >> > > >> (similar to flash.net.navigateToURL), instead of as a >> static >> > method >> > > on a >> > > >> class: >> > > >> > >> > > >> > >> > > >> >> > > >> > >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FkhVI&data=02%7C01%7Caharui%40adobe.com%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439&sdata=nfefmf7ErxCMnNeY2UPTyFQ5BG%2BOPHyTtS4vZ1ea14Q%3D&reserved=0 >> > > >> > >> > > >> > If you did it this way, you'd need to import it >> before you >> > > can call >> > > >> the function, like this: >> > > >> > >> > > >> > import hljs.highlightBlock; >> > > >> > >> > > >> > Or this should work too, if you prefer: >> > > >> > >> > > >> > import hljs.*; >> > > >> > >> > > >> > And then you can call the function directly (without >> the >> > hljs. >> > > >> prefix): >> > > >> > >> > > >> > highlightBlock(block); >> > > >> > >> > > >> > As you can see, the way that you choose to expose a >> JS >> > > library to >> > > >> ActionScript is pretty flexible. Some JavaScript libraries >> are >> > just >> > > a >> > > >> function, and some have APIs that work more like classes. >> > Depending >> > > on the >> > > >> library, one way may work better than the other. >> > > >> > >> > > >> > - Josh >> > > >> > >> > > >> > On 2019/05/02 17:48:49, Josh Tynjala < >> > [email protected]> >> > > >> wrote: >> > > >> >> Exactly right. When you create a typedef class, >> you're >> > > trying to >> > > >> simulate how you would access the API as if you were >> writing in >> > > plain >> > > >> JavaScript. You call hljs.highlightBlock() in JavaScript, >> so you >> > > need a >> > > >> class that works the same way in ActionScript. >> > > >> >> >> > > >> >> Another option for organization would be to keep >> all of >> > your >> > > >> typedefs in a separate folder from your app's source >> files, and >> > > reference >> > > >> the typedefs folder using the source-path compiler option. >> > > >> >> >> > > >> >> - Josh >> > > >> >> >> > > >> >> On 2019/05/02 16:23:45, Alex Harui >> > <[email protected] >> > > > >> > > >> wrote: >> > > >> >>> Hi Carlos, >> > > >> >>> >> > > >> >>> I don’t think hljs is in a package called >> "externs". In >> > > Josh's >> > > >> example, hljs was in the top-level package. And that's >> because >> > > hljs is >> > > >> found at runtime off of the global window object, not some >> > > sub-object >> > > >> called "externs". So, the hljs.as file containing the >> externs >> > has >> > > to go >> > > >> in the root of a source-path, not in some folder called >> "externs" >> > > (which is >> > > >> why some folks will take the time to create a separate >> typedefs >> > SWC >> > > so as >> > > >> not to clutter the root of their application's source >> directory). >> > > >> >>> >> > > >> >>> Then instead of "import externs.hljs", it should be >> > "import >> > > hljs" >> > > >> (or shouldn’t be needed at all). >> > > >> >>> >> > > >> >>> HTH, >> > > >> >>> -Alex >> > > >> >>> >> > > >> >>> On 5/2/19, 9:11 AM, "Carlos Rovira" < >> > > [email protected]> >> > > >> wrote: >> > > >> >>> >> > > >> >>> Hi, >> > > >> >>> >> > > >> >>> in my latest commit I added hljs extern class >> like Josh >> > > show >> > > >> in package >> > > >> >>> externs in TDJ >> > > >> >>> >> > > >> >>> Then I didn't commit the following since is not >> working >> > > for me: >> > > >> >>> >> > > >> >>> 1.- In HighlightCode class (in utils package >> TDJ) >> > > >> >>> >> > > >> >>> added: >> > > >> >>> >> > > >> >>> import externs.hljs; >> > > >> >>> >> > > >> >>> changed the method highlightBlock to: >> > > >> >>> >> > > >> >>> COMPILE::JS >> > > >> >>> /** >> > > >> >>> * block is the element (WrappedHTMLElement) >> inside the >> > > >> component (the >> > > >> >>> <code> tag) >> > > >> >>> */ >> > > >> >>> public function >> > > highlightBlock(block:Element):void >> > > >> >>> { >> > > >> >>> hljs.highlightBlock(block); >> > > >> >>> } >> > > >> >>> >> > > >> >>> and running it I get: >> > > >> >>> >> > > >> >>> Uncaught ReferenceError: externs is not defined >> > > >> >>> at utils.HighlightCode.highlightBlock >> > > (HighlightCode.as:53) >> > > >> >>> at >> > > >> >>> >> > > >> >> > > >> > >> WelcomeSection.components.ExampleAndSourceCodeTabbedSectionContent.dataReadyHandler >> > > >> >>> >> (ExampleAndSourceCodeTabbedSectionContent.as:138) >> > > >> >>> at >> > > >> >> services.GitHubService.goog.events.EventTarget.fireListeners >> > > >> >>> (eventtarget.js:284) >> > > >> >>> at >> > > Function.goog.events.EventTarget.dispatchEventInternal_ >> > > >> >>> (eventtarget.js:381) >> > > >> >>> at >> > > >> >> services.GitHubService.goog.events.EventTarget.dispatchEvent >> > > >> >>> (eventtarget.js:196) >> > > >> >>> at >> > > >> >>> services.GitHubService.org >> > > >> .apache.royale.events.EventDispatcher.dispatchEvent >> > > >> >>> (EventDispatcher.js:71) >> > > >> >>> at >> > > >> >> services.GitHubService.services_GitHubService_completeHandler >> > > >> >>> (GitHubService.as:54) >> > > >> >>> at >> > > >> >>> org.apache.royale.net >> > > >> .HTTPService.goog.events.EventTarget.fireListeners >> > > >> >>> (eventtarget.js:284) >> > > >> >>> at >> > > Function.goog.events.EventTarget.dispatchEventInternal_ >> > > >> >>> (eventtarget.js:381) >> > > >> >>> at >> > > >> >>> org.apache.royale.net >> > > >> .HTTPService.goog.events.EventTarget.dispatchEvent >> > > >> >>> (eventtarget.js:196) >> > > >> >>> >> > > >> >>> What I'm doing wrong? >> > > >> >>> >> > > >> >>> thanks! >> > > >> >>> >> > > >> >>> >> > > >> >>> El jue., 2 may. 2019 a las 18:02, Carlos Rovira >> (< >> > > >> [email protected]>) >> > > >> >>> escribió: >> > > >> >>> >> > > >> >>>> Hi Josh, >> > > >> >>>> >> > > >> >>>> I think this piece of knowledge you just exposed >> here is >> > > key for >> > > >> the >> > > >> >>>> success of Royale. >> > > >> >>>> >> > > >> >>>> I'll try to use this in TDJ to experiment with it >> and >> > will >> > > use >> > > >> in the blog >> > > >> >>>> example I plan to do. >> > > >> >>>> >> > > >> >>>> thanks! >> > > >> >>>> >> > > >> >>>> >> > > >> >>>> El jue., 2 may. 2019 a las 16:36, Josh Tynjala (< >> > > >> [email protected]>) >> > > >> >>>> escribió: >> > > >> >>>> >> > > >> >>>>>> Users can't do this, they required that Royale >> > framework >> > > devs >> > > >> add >> > > >> >>>>> typedefs to the typedefs repo and wait to next >> SDK >> > > release. >> > > >> What does not >> > > >> >>>>> seems very useful. >> > > >> >>>>> >> > > >> >>>>> Users can create their own typedefs from scratch. >> > > >> >>>>> >> > > >> >>>>> I just created a quick example for hljs, that >> exposes >> > the >> > > >> >>>>> highlightBlock() function: >> > > >> >>>>> >> > > >> >>>>> >> > > >> >> > > >> > >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FdIq0&data=02%7C01%7Caharui%40adobe.com%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439&sdata=ogITciULRUGWvwRsTg9kw68vqr5pCfcsgm8AC%2F6W0Kw%3D&reserved=0 >> > > >> >>>>> >> > > >> >>>>> Basically, the class needs an asdoc comment with >> the >> > > @externs >> > > >> tag (this >> > > >> >>>>> is something that comes from Google Closure >> compiler, >> > > which we >> > > >> use to >> > > >> >>>>> create release builds) and the compiler should >> handle >> > the >> > > rest. >> > > >> >>>>> >> > > >> >>>>> As I understand it, you don't even need to >> create a SWC >> > > library >> > > >> for >> > > >> >>>>> custom typedefs. Recently, Alex mentioned that >> the mxmlc >> > > >> compiler is smart >> > > >> >>>>> enough to handle a source file as long as it has >> the >> > > @externs >> > > >> tag. >> > > >> >>>>> >> > > >> >>>>> - Josh >> > > >> >>>>> >> > > >> >>>>> On 2019/05/02 09:34:37, Carlos Rovira < >> > > [email protected]> >> > > >> wrote: >> > > >> >>>>>> Hi, >> > > >> >>>>>> >> > > >> >>>>>> to sumarize (let me know if I'm wrong), the >> current >> > ways >> > > to >> > > >> integrate an >> > > >> >>>>>> existing library are 3: >> > > >> >>>>>> >> > > >> >>>>>> 1.- access vía brackets notation: This is the >> most easy >> > > and >> > > >> direct, an >> > > >> >>>>>> example is TourDeJewel in class >> utils.HighlightCode >> > > >> >>>>>> >> > > >> >>>>>> var hljs:Object = window["hljs"]; >> > > >> >>>>>> hljs["highlightBlock"](block); >> > > >> >>>>>> >> > > >> >>>>>> but this one is not what we really want since >> we are >> > > going >> > > >> with Roayle >> > > >> >>>>> and >> > > >> >>>>>> AS3 to get type checking and strong typing. So >> this, >> > > although >> > > >> useful is >> > > >> >>>>> not >> > > >> >>>>>> what we really want to use in out Apps, but >> since we >> > > want to >> > > >> maintain >> > > >> >>>>> the >> > > >> >>>>>> dynamic aspect of the language it could be very >> useful >> > > >> sometimes >> > > >> >>>>>> >> > > >> >>>>>> 2.- using typedefs >> > > >> >>>>>> >> > > >> >>>>>> This will be the next step to use a real type >> and dot >> > > >> notation, but >> > > >> >>>>> seems >> > > >> >>>>>> not easy or direct. >> > > >> >>>>>> Users can't do this, they required that Royale >> > framework >> > > devs >> > > >> add >> > > >> >>>>> typedefs >> > > >> >>>>>> to the typedefs repo and wait to next SDK >> release. What >> > > does >> > > >> not seems >> > > >> >>>>> very >> > > >> >>>>>> useful. >> > > >> >>>>>> >> > > >> >>>>>> In the other hand we'll need to know how to >> extend >> > > current >> > > >> typedefs >> > > >> >>>>> since >> > > >> >>>>>> don't know if we have docs about this. Until >> now I >> > added >> > > to >> > > >> "missing.js" >> > > >> >>>>>> file fo now, but this doesn't seems a valid >> path since >> > > it lacks >> > > >> >>>>>> organization, separation, and a way for all >> people >> > > >> contributing to know >> > > >> >>>>> wha >> > > >> >>>>>> we have, what can be added and where, if not >> we'll find >> > > in >> > > >> time lots of >> > > >> >>>>>> code very difficult to maintain. >> > > >> >>>>>> >> > > >> >>>>>> Yishay and Josh talked about to use TypeScript, >> but >> > > seems that >> > > >> is >> > > >> >>>>> already >> > > >> >>>>>> explored by Josh but not a valid path since >> will be >> > very >> > > >> difficult to >> > > >> >>>>>> maintain. >> > > >> >>>>>> >> > > >> >>>>>> 3.- wrapping libraries >> > > >> >>>>>> >> > > >> >>>>>> This is how we did with MDL. This will be >> recommended >> > > when we >> > > >> want to >> > > >> >>>>>> integrate existing libraries with Royale to >> make it >> > work >> > > with >> > > >> our APIs >> > > >> >>>>> in a >> > > >> >>>>>> more seamless way. But the problems is that >> this is >> > very >> > > >> laborious. Can >> > > >> >>>>> be >> > > >> >>>>>> useful for some concrete libraries and we >> should do >> > when >> > > >> needed (the >> > > >> >>>>> case >> > > >> >>>>>> is MDL). But the problem is that this not solve >> the >> > > problem of >> > > >> our users >> > > >> >>>>>> that need to integrate a existing library >> themselves >> > in a >> > > >> quick way. >> > > >> >>>>>> >> > > >> >>>>>> Let me know if you know other way. >> > > >> >>>>>> >> > > >> >>>>>> For me method 1, is ok to do the work, but >> doesn't make >> > > us >> > > >> justice. >> > > >> >>>>>> method 2 should be the main one if there's a >> fast and >> > > easy >> > > >> way... I'm >> > > >> >>>>>> missing something here? Can users create >> typedefs >> > > themselves? >> > > >> >>>>>> method 3 can be useful for us or for users >> (doing their >> > > own >> > > >> libs, and >> > > >> >>>>>> eventually can share with us to add to official >> royale >> > > repo >> > > >> and sdk) >> > > >> >>>>>> but is something not fast at all and not as >> convenient >> > > and >> > > >> direct as >> > > >> >>>>> method >> > > >> >>>>>> 2, and will require maintenance as libs change. >> > > >> >>>>>> >> > > >> >>>>>> Could we agree that this is the currently >> available >> > ways >> > > in >> > > >> Royale now >> > > >> >>>>> to >> > > >> >>>>>> use external JS libs? >> > > >> >>>>>> >> > > >> >>>>>> thanks >> > > >> >>>>>> >> > > >> >>>>>> -- >> > > >> >>>>>> Carlos Rovira >> > > >> >>>>>> >> > > >> >> > > >> > >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439&sdata=yJoOS7qX8F%2BNfgKgjRCT97W5t2c1DEVRAyJ%2ByHahD90%3D&reserved=0 >> > > >> >>>>>> >> > > >> >>>>> >> > > >> >>>> >> > > >> >>>> >> > > >> >>>> -- >> > > >> >>>> Carlos Rovira >> > > >> >>>> >> > > >> >> > > >> > >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439&sdata=yJoOS7qX8F%2BNfgKgjRCT97W5t2c1DEVRAyJ%2ByHahD90%3D&reserved=0 >> > > >> >>>> >> > > >> >>>> >> > > >> >>> >> > > >> >>> -- >> > > >> >>> Carlos Rovira >> > > >> >>> >> > > >> >> > > >> > >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439&sdata=yJoOS7qX8F%2BNfgKgjRCT97W5t2c1DEVRAyJ%2ByHahD90%3D&reserved=0 >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > > >> > > > -- >> > > > Carlos Rovira >> > > > >> > > >> > >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602112444&sdata=Ata%2BBbvYb4O9GX%2FzRS6qkcF7DcNCTfSC4C%2BqdNWW2U4%3D&reserved=0 >> > > > >> > > > >> > > >> > > -- >> > > Carlos Rovira >> > > >> > > >> > >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602112444&sdata=Ata%2BBbvYb4O9GX%2FzRS6qkcF7DcNCTfSC4C%2BqdNWW2U4%3D&reserved=0 >> > > >> > > >> > > >> > >> >> >> -- >> Carlos Rovira >> >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602112444&sdata=Ata%2BBbvYb4O9GX%2FzRS6qkcF7DcNCTfSC4C%2BqdNWW2U4%3D&reserved=0 >> >> >> > > -- > Carlos Rovira > http://about.me/carlosrovira > > -- Carlos Rovira http://about.me/carlosrovira
