Alex, testing with the test change to the same jewel code and with actual repo states fails in release mode as expected. So clearly something has changed this days that makes MX RO fail in release mode.
Using DiffMerge to compare both release .js files shows a clear red zone where the significant differences exists. I posted both js files here [1] Day 14 - https://paste.apache.org/tYEj [2] Day 17 - https://paste.apache.org/AcMa Could you check the files and see if you see something relevant. I don't know how to look for. If you need the js files I can send you in email. Hope you find with this info the point of changes and could find some solution so we get release mode working againg thanks Carlos El mié., 17 oct. 2018 a las 15:34, Carlos Rovira (<carlosrov...@apache.org>) escribió: > Hi Alex, > > Going to repos state of Oct, 14th (last commit of that day, in compiler > and framework, and in my project app repo as well), I can confirm all > worked on release more and communication with server is ok > > for our mxroyale MX RO test: I can't get it to work in release mode either > adding: > > debug false > > and > > -js-dynamic-access-unknown-members=true > > or removing mx:method section that was not working right at that time. > > Our test continue showing white browser screen and the error: > > [Error] TypeError: undefined is not an object (evaluating 'a.length') > ez (App.js:997:141) > Vy (App.js:996:181) > qm (App.js:970:266) > qr (App.js:968:323) > mq (App.js:239:887) > R (App.js:166:1223) > W (App.js:511:1288) > mw (App.js:642:796) > Dz (App.js:1044:726) > create (App.js:908:164) > start (App.js:909:229) > Código global (index.html:13) > > So I suppose mx:Application and other implied MX things in the background > are still not suited for release compilation. > > So after this, I changed localy all non MX RO components to Jewel, and I > get the test working in release mode > Interesting thing here is that it worked without setting > -js-dynamic-access-unknown-members=true > So that indicates that MX RO seems does not need this itself. > > Next thing is go to actual code, change the example with the same Jewel > code, compile, test and then compare outputs with DiffMerge to see > differences. > > I'll write result as I get it > > Carlos > > > > El mié., 17 oct. 2018 a las 10:15, Carlos Rovira (<carlosrov...@apache.org>) > escribió: > >> Hi Alex, >> >> the compiler params I reported was not right, were from asconfig.json, >> but since I'm using maven I saw there was not setup anything, so I setup to >> : >> >> <additionalCompilerOptions> >> -source-map=true;-js-dynamic-access-unknown-members=true</ >> additionalCompilerOptions> >> >> And seems the output is still the same >> >> [Error] TypeError: undefined is not an object (evaluating 'a.length') >> hz (App.js:998:141) >> Yy (App.js:997:181) >> rm (App.js:971:266) >> tr (App.js:969:323) >> pq (App.js:239:887) >> R (App.js:166:1223) >> W (App.js:511:1288) >> pw (App.js:642:796) >> Gz (App.js:1045:726) >> create (App.js:908:164) >> start (App.js:909:229) >> Código global (index.html:13) >> >> Now, I'll try to go back in time to a previous commit where it works and >> compare with this output >> >> I'll get back with results >> >> Carlos >> >> >> >> >> >> >> El mar., 16 oct. 2018 a las 23:44, Alex Harui (<aha...@adobe.com.invalid>) >> escribió: >> >>> Ok. Let us know what you find out. I'm curious why you are not using >>> -js-dynamic-access. I thought that was at least a workaround. >>> >>> -Alex >>> >>> On 10/16/18, 2:36 PM, "Carlos Rovira" <carlosrov...@apache.org> wrote: >>> >>> Hi Alex, >>> >>> I'm starting with our simple MXRoyale RO text example and our Java >>> sample. >>> I just pushed a commit to easy change between the old example and >>> the new >>> MX RO test case, and enable RELEASE mode. When doing so and running >>> it >>> doesn't work. this is the output >>> >>> [Error] TypeError: undefined is not an object (evaluating 'a.length') >>> hz (App.js:998:141) >>> Yy (App.js:997:181) >>> rm (App.js:971:266) >>> tr (App.js:969:323) >>> pq (App.js:239:887) >>> R (App.js:166:1223) >>> W (App.js:511:1288) >>> pw (App.js:642:796) >>> Gz (App.js:1045:726) >>> create (App.js:908:164) >>> start (App.js:909:229) >>> Código global (index.html:13) >>> >>> The additional compiler options are: >>> >>> "additionalOptions": "-remove-circulars >>> -js-output-optimization=skipAsCoercions", >>> >>> I must to close for today, but I think it will be more easy to debug >>> from >>> this example than from my real world app that has many other things >>> bundled. >>> >>> Thanks >>> >>> >>> El mar., 16 oct. 2018 a las 18:49, Alex Harui >>> (<aha...@adobe.com.invalid>) >>> escribió: >>> >>> > Hi Carlos, >>> > >>> > Are you saying you can see that the response from the server was >>> received >>> > by XHR in the browser? >>> > >>> > I can't think of anything that I pushed yesterday that would affect >>> > response handling. IMO, the changes I made affected the call to >>> send(), >>> > but not the response handling. The other change would affect what >>> MXML >>> > elements were created. I guess you'll just have to debug into it. >>> > >>> > If it helps, there is a -skip-transpile option that is relatively >>> > untested, but causes the compiler to skip over any transpilation >>> and just >>> > run the Google Closure Compiler on the js-debug folder. This >>> should allow >>> > you to add trace statements (actually console.out) to the .JS >>> files in the >>> > js-debug folder and help you debug. If you are only modifying >>> framework >>> > files and not the application files, you don't even need >>> -skip-transpile, >>> > since the framework JS files from the SWC that are in js-debug are >>> not >>> > overwritten if they already exist. >>> > >>> > You could also revert back until you get a version that works, or >>> compare >>> > the current js-debug against working js-debug, if you still have a >>> working >>> > copy somewhere. >>> > >>> > -Alex >>> > >>> > On 10/16/18, 3:57 AM, "Carlos Rovira" <carlosrov...@apache.org> >>> wrote: >>> > >>> > Hi Alex >>> > >>> > It seems that latest changes makes MX RO not work in >>> js-release mode. >>> > If you remember I could by-pass this problem setting up >>> > -js-dynamic-access-unknown-members=true >>> > compiling my Application, but now testing js-release it's not >>> working >>> > at >>> > all, since we are in release no traces are shown >>> > calling the operation in the backend just fails silenty. >>> > >>> > I only can say that call is done since I can see traces on my >>> java >>> > server, >>> > and enabling XHR in browser I can see the request is received >>> but in >>> > Royale >>> > nothing happens. I think this in an important issue (in the >>> end it >>> > will be >>> > blocking for me to go to production), do you know of something >>> done in >>> > the >>> > latest changes that could make this fail now? >>> > >>> > Thanks >>> > >>> > >>> > >>> > El lun., 15 oct. 2018 a las 21:17, Carlos Rovira (< >>> > carlosrov...@apache.org>) >>> > escribió: >>> > >>> > > Hi Alex, >>> > > with your latest fixes all is working ok :) >>> > > thanks! >>> > > >>> > > El lun., 15 oct. 2018 a las 20:12, Alex Harui >>> > (<aha...@adobe.com.invalid>) >>> > > escribió: >>> > > >>> > >> Either syntax should work. I just pushed changes to >>> > AbstractService that >>> > >> got service.echo() to work. >>> > >> >>> > >> -Alex >>> > >> >>> > >> On 10/15/18, 10:51 AM, "Carlos Rovira" < >>> carlosrov...@apache.org> >>> > wrote: >>> > >> >>> > >> Hi Alex, >>> > >> >>> > >> one thing I not understand is that this: >>> > >> >>> > >> (service.echo as Operation).send(); >>> > >> >>> > >> should be >>> > >> >>> > >> service.echo() >>> > >> >>> > >> I think we're trying to remove "send()" and call >>> directly >>> > "echo()" >>> > >> >>> > >> I can go to your latest commits in both compiler and >>> framework >>> > and >>> > >> try, but >>> > >> don't understand the purpose, since calling with send() >>> was >>> > what we >>> > >> had, >>> > >> right? >>> > >> >>> > >> Or maybe I'm missing something? >>> > >> >>> > >> thanks >>> > >> >>> > >> Carlos >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> El lun., 15 oct. 2018 a las 19:15, Alex Harui >>> > >> (<aha...@adobe.com.invalid>) >>> > >> escribió: >>> > >> >>> > >> > About 10 hours ago, after I cast the call to send in >>> the >>> > example to >>> > >> be >>> > >> > (service.echo as Operation).send() , it worked for me. >>> > >> > >>> > >> > I see you have made several changes to the example >>> since. Go >>> > back >>> > >> to >>> > >> > where the example was about 10 hours ago, make that >>> one >>> > change to >>> > >> > service.echo.send() and it should work. If other >>> things are >>> > not >>> > >> working, I >>> > >> > will look into them later. >>> > >> > >>> > >> > -Alex >>> > >> > >>> > >> > On 10/15/18, 10:11 AM, "Carlos Rovira" < >>> > carlosrov...@apache.org> >>> > >> wrote: >>> > >> > >>> > >> > Hi Alex, >>> > >> > >>> > >> > El lun., 15 oct. 2018 a las 18:54, Alex Harui >>> > >> > (<aha...@adobe.com.invalid>) >>> > >> > escribió: >>> > >> > >>> > >> > > There may be a couple of things affecting you. >>> One is >>> > that >>> > >> in the >>> > >> > bug you >>> > >> > > reported, it looks like only the first RO is >>> created >>> > and the >>> > >> others >>> > >> > are not. >>> > >> > > >>> > >> > >>> > >> > I 'm pretty sure the bug about mx:method is not >>> present >>> > since I >>> > >> test >>> > >> > in my >>> > >> > real project and in the example in our repo. In >>> the first >>> > one I >>> > >> don't >>> > >> > have >>> > >> > any mx:method and in the second I comment to >>> test. Maybe >>> > we >>> > >> should >>> > >> > comment >>> > >> > mx:method section in the example for now. >>> > >> > >>> > >> > >>> > >> > > >>> > >> > > Second, if you notice in the example, you'll >>> see things >>> > like >>> > >> > (service.echo >>> > >> > > as Operation).lastResult. After adding support >>> for >>> > >> callProperty, >>> > >> > the calls >>> > >> > > now have to change to be either (service.echo as >>> > >> Operation).send() or >>> > >> > > service.echo(). The current syntax in the repo: >>> > >> service.echo.send() >>> > >> > will >>> > >> > > result in an error because the compiler cannot >>> know if >>> > the >>> > >> echo >>> > >> > property on >>> > >> > > service is also a proxy or not. The compiler >>> currently >>> > >> guesses >>> > >> > "yes" to >>> > >> > > make it easier for folks who have existing >>> nested >>> > ObjectProxy >>> > >> data >>> > >> > sets. >>> > >> > > So, Royale developers will have to do more >>> "casting" >>> > with >>> > >> "as" than >>> > >> > in >>> > >> > > Flash. >>> > >> > > >>> > >> > >>> > >> > check the example since I change already to the >>> new >>> > syntax to >>> > >> help you >>> > >> > try >>> > >> > it. There's no "send()" anymore in the example in >>> our >>> > repo. >>> > >> > >>> > >> > >>> > >> > > >>> > >> > > In Flash, the difference between proxy access >>> and >>> > regular >>> > >> property >>> > >> > access >>> > >> > > is handled in the runtime. The JS runtimes do >>> not do >>> > this. >>> > >> The >>> > >> > compiler >>> > >> > > could generate code that tests the class at >>> runtime, >>> > but I >>> > >> think >>> > >> > that will >>> > >> > > be too slow. >>> > >> > > >>> > >> > > Specific to RemoteObject, it might be possible >>> to >>> > declare the >>> > >> JS >>> > >> > > RemoteObject to not be a Proxy and just Dynamic >>> and >>> > have the >>> > >> > constructor >>> > >> > > and getOperation call Object.defineProperty, >>> but that >>> > is not a >>> > >> > general case >>> > >> > > solution for Proxy. >>> > >> > > >>> > >> > >>> > >> > Hi Alex, that's for me a bit far from my >>> knowledge. I'm >>> > sure >>> > >> whatever >>> > >> > you >>> > >> > get would be the best solution. >>> > >> > Currently mx:RO is broken and I'm working with >>> the repo >>> > just >>> > >> before the >>> > >> > change localy to advance, hope you could take a >>> look and >>> > see if >>> > >> you >>> > >> > can fix >>> > >> > the issue. >>> > >> > If not, probably is better to comment the changes >>> in the >>> > >> compiler (and >>> > >> > maybe in the framework?) to make it work again >>> until we >>> > know >>> > >> how to >>> > >> > fix it. >>> > >> > >>> > >> > One thing I could test today (not related) in the >>> > meanwhile is >>> > >> if mx:RO >>> > >> > works with small messages on. The response is >>> not, I >>> > think that >>> > >> is the >>> > >> > AMF >>> > >> > serialization-deserialization. But I think this >>> is not >>> > crucial, >>> > >> just >>> > >> > disabling it could be ok for now for most of >>> folks out >>> > there >>> > >> (just >>> > >> > knowing >>> > >> > that they need to configure that to false). >>> > >> > >>> > >> > Thanks >>> > >> > >>> > >> > Carlos >>> > >> > >>> > >> > >>> > >> > > >>> > >> > > My 2 cents, >>> > >> > > -Alex >>> > >> > > >>> > >> > > On 10/15/18, 4:51 AM, "Carlos Rovira" < >>> > >> carlosrov...@apache.org> >>> > >> > wrote: >>> > >> > > >>> > >> > > Hi Alex, >>> > >> > > >>> > >> > > I added to the RO test example the >>> CompressedRO >>> > test case >>> > >> > commented to >>> > >> > > help >>> > >> > > you find the problem. >>> > >> > > I couldn't test like in net RO since now >>> the entire >>> > >> example is >>> > >> > > failing, but >>> > >> > > once the callProperty works for a normal >>> case >>> > should help >>> > >> us to >>> > >> > check >>> > >> > > if >>> > >> > > the rest of RO works since it uses >>> > >> "convertParametersHandler" >>> > >> > > >>> > >> > > I'll revert localy this changes in order to >>> advance >>> > in my >>> > >> real >>> > >> > world >>> > >> > > app in >>> > >> > > the mean while >>> > >> > > >>> > >> > > thanks >>> > >> > > >>> > >> > > >>> > >> > > >>> > >> > > El lun., 15 oct. 2018 a las 13:40, Carlos >>> Rovira (< >>> > >> > > carlosrov...@apache.org>) >>> > >> > > escribió: >>> > >> > > >>> > >> > > > Hi Alex, >>> > >> > > > >>> > >> > > > I found that even if I remove completely >>> > >> > CompressedRemoteObject and >>> > >> > > use >>> > >> > > > only normal mx:RemoteObject the error >>> shows: >>> > >> > > > >>> > >> > > > [Error] TypeError: undefined is not an >>> object >>> > >> (evaluating >>> > >> > > > >>> 'this.remoteObject.convertParametersHandler') >>> > >> > > > >>> > >> > > > >>> > >> > > > >>> > >> > > > >>> > >> > > > El lun., 15 oct. 2018 a las 13:00, Carlos >>> Rovira >>> > (< >>> > >> > > carlosrov...@apache.org>) >>> > >> > > > escribió: >>> > >> > > > >>> > >> > > >> Hi Alex, >>> > >> > > >> >>> > >> > > >> I'm finding a problem with callProperty. >>> I'm >>> > using a >>> > >> > > >> CompressedRemoteObjeect that uses two >>> hooks in >>> > >> RemoteObject >>> > >> > API >>> > >> > > >> >>> > >> > > >> public var >>> convertParametersHandler:Function; >>> > >> > > >> >>> > >> > > >> and >>> > >> > > >> public var convertResultHandler:Function; >>> > >> > > >> >>> > >> > > >> this makes the call fail with >>> > >> > > >> >>> > >> > > >> [Error] TypeError: undefined is not an >>> object >>> > >> (evaluating >>> > >> > > >> >>> 'this.remoteObject.convertParametersHandler') >>> > >> > > >> send (Operation.js:109) >>> > >> > > >> callProperty (AbstractService.js:147:111) >>> > >> > > >> dologin (LoginForm.js:181) >>> > >> > > >> $EH1 (LoginForm.js:226) >>> > >> > > >> (función anónima) >>> > >> > > >> fireListener (events.js:744) >>> > >> > > >> fireListenerOverride >>> (HTMLElementWrapper.js:61) >>> > >> > > >> handleBrowserEvent_ (events.js:870) >>> > >> > > >> (función anónima) (events.js:289) >>> > >> > > >> >>> > >> > > >> So I guess the proxy is trying to proxy >>> all even >>> > its >>> > >> own >>> > >> > member >>> > >> > > functions >>> > >> > > >> that should not be affected, makes this >>> sense? >>> > >> > > >> >>> > >> > > >> thanks >>> > >> > > >> >>> > >> > > >> >>> > >> > > >> El lun., 15 oct. 2018 a las 7:15, Alex >>> Harui >>> > >> > > (<aha...@adobe.com.invalid>) >>> > >> > > >> escribió: >>> > >> > > >> >>> > >> > > >>> I pushed changes to the compiler and >>> framework >>> > to try >>> > >> to get >>> > >> > > >>> callProperty to work. I don't have a >>> test case >>> > but >>> > >> give it >>> > >> > a try >>> > >> > > and see >>> > >> > > >>> what happens. >>> > >> > > >>> >>> > >> > > >>> If you compare the size of the output >>> with and >>> > without >>> > >> > > >>> -js-dynamic-access, you can see the >>> theoretical >>> > >> savings of >>> > >> > not >>> > >> > > using that >>> > >> > > >>> option. If that savings might matter, >>> then it >>> > might >>> > >> be worth >>> > >> > > spending some >>> > >> > > >>> time on fixing up the issues that >>> > -js-dynamic-access >>> > >> "works >>> > >> > > around". But >>> > >> > > >>> keep in mind that there probably isn't >>> any way >>> > to >>> > >> grab all >>> > >> > of the >>> > >> > > >>> theoretical savings. What we don’t >>> know yet is >>> > where >>> > >> you'll >>> > >> > > actually end >>> > >> > > >>> up. It might even be true that >>> > -js-dynamic-access is >>> > >> more >>> > >> > optimal. >>> > >> > > >>> >>> > >> > > >>> -Alex >>> > >> > > >>> >>> > >> > > >>> On 10/14/18, 3:02 PM, "Carlos Rovira" < >>> > >> > carlosrov...@apache.org> >>> > >> > > wrote: >>> > >> > > >>> >>> > >> > > >>> Hi Alex >>> > >> > > >>> >>> > >> > > >>> El dom., 14 oct. 2018 a las 23:48, >>> Alex >>> > Harui >>> > >> > > >>> (<aha...@adobe.com.invalid>) >>> > >> > > >>> escribió: >>> > >> > > >>> >>> > >> > > >>> > I got the resources working so I >>> will >>> > look into >>> > >> > > Proxy.callProperty. >>> > >> > > >>> > >>> > >> > > >>> > >>> > >> > > >>> That's cool, I'm closing for today, >>> I can >>> > try in >>> > >> some >>> > >> > hours if >>> > >> > > you >>> > >> > > >>> upload >>> > >> > > >>> some changes. Thanks >>> > >> > > >>> >>> > >> > > >>> >>> > >> > > >>> > The issue with js-dynamic-access >>> isn't >>> > about MX >>> > >> > RemoteObject >>> > >> > > vs >>> > >> > > >>> Basic >>> > >> > > >>> > RemoteObject, it is whether, if >>> we fixed >>> > places >>> > >> in any >>> > >> > of >>> > >> > > the code >>> > >> > > >>> where >>> > >> > > >>> > minification breaks things, what >>> the >>> > >> size/performance >>> > >> > > trade-off >>> > >> > > >>> would be. >>> > >> > > >>> > Some variable names would be >>> longer, but >>> > some >>> > >> other >>> > >> > code >>> > >> > > might be >>> > >> > > >>> more >>> > >> > > >>> > verbose as public vars are >>> converted into >>> > >> > getter/setters and >>> > >> > > have >>> > >> > > >>> function >>> > >> > > >>> > call overhead. I guess we'll >>> find out >>> > when we >>> > >> get >>> > >> > someone's >>> > >> > > app >>> > >> > > >>> to the >>> > >> > > >>> > point where they are ready to get >>> the >>> > production >>> > >> > version to >>> > >> > > run. >>> > >> > > >>> > >>> > >> > > >>> >>> > >> > > >>> Well, I'll need to have my app in >>> > production by >>> > >> the >>> > >> > end/start >>> > >> > > of the >>> > >> > > >>> year, >>> > >> > > >>> so we'll can check this with mine. >>> For now >>> > it >>> > >> seems I >>> > >> > need to >>> > >> > > left >>> > >> > > >>> this >>> > >> > > >>> configuration or release version >>> can pass >>> > the >>> > >> login (the >>> > >> > mx RO >>> > >> > > call >>> > >> > > >>> to the >>> > >> > > >>> server) >>> > >> > > >>> >>> > >> > > >>> >>> > >> > > >>> >>> > >> > > >>> > >>> > >> > > >>> > -Alex >>> > >> > > >>> > >>> > >> > > >>> > On 10/14/18, 2:23 PM, "Carlos >>> Rovira" < >>> > >> > > carlosrov...@apache.org> >>> > >> > > >>> wrote: >>> > >> > > >>> > >>> > >> > > >>> > Hi Alex, >>> > >> > > >>> > >>> > >> > > >>> > El dom., 14 oct. 2018 a las >>> 18:32, >>> > Alex >>> > >> Harui >>> > >> > > >>> > (<aha...@adobe.com.invalid>) >>> > >> > > >>> > escribió: >>> > >> > > >>> > >>> > >> > > >>> > > Hi Carlos, >>> > >> > > >>> > > >>> > >> > > >>> > > JS proxy doesn't support >>> > callProperty >>> > >> yet. Feel >>> > >> > free >>> > >> > > to add >>> > >> > > >>> it, or >>> > >> > > >>> > I will >>> > >> > > >>> > > after I finish up >>> ResourceManager. >>> > >> > > >>> > > >>> > >> > > >>> > >>> > >> > > >>> > JS proxy is >>> mx.utlis.ObjectProxy or >>> > you >>> > >> mean maybe >>> > >> > > >>> AbstractService >>> > >> > > >>> > callProperty? >>> > >> > > >>> > I could take a look, but no >>> promises >>> > since >>> > >> I don't >>> > >> > know >>> > >> > > >>> exactly how >>> > >> > > >>> > that >>> > >> > > >>> > works. A little of guidance >>> here >>> > could me >>> > >> make get >>> > >> > this >>> > >> > > done. >>> > >> > > >>> > >>> > >> > > >>> > >>> > >> > > >>> > > >>> > >> > > >>> > > I don't doubt that >>> minification >>> > breaks >>> > >> lots of >>> > >> > things >>> > >> > > that >>> > >> > > >>> > > js-dynamic-access fixes. >>> Hard to >>> > say how >>> > >> much >>> > >> > smaller >>> > >> > > your >>> > >> > > >>> app >>> > >> > > >>> > would be if >>> > >> > > >>> > > we fixed anough stuff >>> without that >>> > option. >>> > >> > > >>> > > >>> > >> > > >>> > > >>> > >> > > >>> > well, including >>> mx:RemoteObject seems >>> > to >>> > >> increase >>> > >> > > >>> significantly my >>> > >> > > >>> > current >>> > >> > > >>> > app in release mode "mx" is >>> 1'8mb >>> > while >>> > >> > > "org.apache.royale" is >>> > >> > > >>> > 1'8mb...but >>> > >> > > >>> > is ok for me since I think is >>> a normal >>> > >> payload for >>> > >> > the >>> > >> > > base of >>> > >> > > >>> a normal >>> > >> > > >>> > App, and MX RO here does an >>> important >>> > role >>> > >> in my >>> > >> > case. So >>> > >> > > >>> happy to pay >>> > >> > > >>> > the >>> > >> > > >>> > price ;) >>> > >> > > >>> > >>> > >> > > >>> > >>> > >> > > >>> > >>> > >> > > >>> > > -Alex >>> > >> > > >>> > > >>> > >> > > >>> > > -- >>> > >> > > >>> > > Carlos Rovira >>> > >> > > >>> > > >>> > >> > > >>> > >>> > >> > > >>> >>> > >> > > >>> > >> > >>> > >> >>> > >>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C15634d41d3284235c0e308d633af7aaa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636753226104890710&sdata=fxQa4zktHZekw9sqzbJDmYhG7smZ6uKBbjpLbPPHLvQ%3D&reserved=0 >>> > >> > > >>> > > >>> > >> > > >>> > > >>> > >> > > >>> > > >>> > >> > > >>> > > >>> > >> > > >>> > >>> > >> > > >>> > >>> > >> > > >>> > >>> > >> > > >>> >>> > >> > > >>> -- >>> > >> > > >>> Carlos Rovira >>> > >> > > >>> >>> > >> > > >>> >>> > >> > > >>> > >> > >>> > >> >>> > >>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C15634d41d3284235c0e308d633af7aaa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636753226104890710&sdata=fxQa4zktHZekw9sqzbJDmYhG7smZ6uKBbjpLbPPHLvQ%3D&reserved=0 >>> > >> > > >>> >>> > >> > > >>> >>> > >> > > >>> >>> > >> > > >> >>> > >> > > >> -- >>> > >> > > >> Carlos Rovira >>> > >> > > >> >>> > >> > > >>> > >> > >>> > >> >>> > >>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C15634d41d3284235c0e308d633af7aaa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636753226104890710&sdata=fxQa4zktHZekw9sqzbJDmYhG7smZ6uKBbjpLbPPHLvQ%3D&reserved=0 >>> > >> > > >> >>> > >> > > >> >>> > >> > > > >>> > >> > > > -- >>> > >> > > > Carlos Rovira >>> > >> > > > >>> > >> > > >>> > >> > >>> > >> >>> > >>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C15634d41d3284235c0e308d633af7aaa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636753226104890710&sdata=fxQa4zktHZekw9sqzbJDmYhG7smZ6uKBbjpLbPPHLvQ%3D&reserved=0 >>> > >> > > > >>> > >> > > > >>> > >> > > >>> > >> > > -- >>> > >> > > Carlos Rovira >>> > >> > > >>> > >> > > >>> > >> > >>> > >> >>> > >>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C15634d41d3284235c0e308d633af7aaa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636753226104890710&sdata=fxQa4zktHZekw9sqzbJDmYhG7smZ6uKBbjpLbPPHLvQ%3D&reserved=0 >>> > >> > > >>> > >> > > >>> > >> > > >>> > >> > >>> > >> > -- >>> > >> > Carlos Rovira >>> > >> > >>> > >> > >>> > >> >>> > >>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C15634d41d3284235c0e308d633af7aaa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636753226104890710&sdata=fxQa4zktHZekw9sqzbJDmYhG7smZ6uKBbjpLbPPHLvQ%3D&reserved=0 >>> > >> > >>> > >> > >>> > >> > >>> > >> >>> > >> -- >>> > >> Carlos Rovira >>> > >> >>> > >> >>> > >>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C15634d41d3284235c0e308d633af7aaa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636753226104890710&sdata=fxQa4zktHZekw9sqzbJDmYhG7smZ6uKBbjpLbPPHLvQ%3D&reserved=0 >>> > >> >>> > >> >>> > >> >>> > > >>> > > -- >>> > > Carlos Rovira >>> > > >>> > >>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C15634d41d3284235c0e308d633af7aaa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636753226104890710&sdata=fxQa4zktHZekw9sqzbJDmYhG7smZ6uKBbjpLbPPHLvQ%3D&reserved=0 >>> > > >>> > > >>> > >>> > -- >>> > Carlos Rovira >>> > >>> > >>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C15634d41d3284235c0e308d633af7aaa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636753226104900709&sdata=PqEdmzLveMAyzsSu5ix7vQj%2BeRzj80fxeb18WD5q7Cc%3D&reserved=0 >>> > >>> > >>> > >>> >>> -- >>> Carlos Rovira >>> >>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C15634d41d3284235c0e308d633af7aaa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636753226104900709&sdata=PqEdmzLveMAyzsSu5ix7vQj%2BeRzj80fxeb18WD5q7Cc%3D&reserved=0 >>> >>> >>> >> >> -- >> Carlos Rovira >> http://about.me/carlosrovira >> >> > > -- > Carlos Rovira > http://about.me/carlosrovira > > -- Carlos Rovira http://about.me/carlosrovira
