Hi Carlos,
Well, that is my suggestion for how you can figure this out. In theory, there
should be relatively few differences in js-debug and those few differences are
likely to be the difference in the js-release version.
Also, in theory, the source-maps work and running the js-release in the
debugger should show where in the js-debug the exception is coming from.
Hopefully your time budget considered that Royale is still beta quality. This
is, hopefully, a relatively straightforward issue and having more people
understand how to debug production code is a good thing for the community. It
can't always be me.
Good luck,
-Alex
On 10/17/18, 11:19 AM, "Carlos Rovira" <carlosrov...@apache.org> wrote:
Hi Alex,
one thing to take into account, you talk about to compare debug versions,
but the problem is that debug versions works right, so I think you'll
didn't find nothing related to the real problem there.
Thanks
El mié., 17 oct. 2018 a las 17:48, Carlos Rovira (<carlosrov...@apache.org>)
escribió:
> Hi Alex,
>
> do you want to send you a zip file with the js-debug versions?
> In order to compare both je-relase versions, my problem is that I don't
> know what I must look for, so is difficult to see things. In the other
> hand, I'm spending lots of time in this kind of Debugging what makes me
> unable to work on the real project, and I'm starting to be delayed...
>
> thanks
>
>
>
> El mié., 17 oct. 2018 a las 17:19, Alex Harui (<aha...@adobe.com.invalid>)
> escribió:
>
>> This may be a good opportunity for folks like you to develop skills at
>> debugging things like this. It won't scale if it is always up to me.
>> IMO, I would be comparing the un-minified source to see what is
>> different. The release files are hard to read.
>>
>> -Alex
>>
>> On 10/17/18, 6:58 AM, "Carlos Rovira" <carlosrov...@apache.org> wrote:
>>
>> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FtYEj&data=02%7C01%7Caharui%40adobe.com%7Cc01ffc8e334943c65c7d08d6345d234b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636753971960008346&sdata=nUvm817M8DOGllSRz8fj8kQ%2Friec5jvTkH2Kz7P1AWk%3D&reserved=0
>> [2] Day 17 -
>>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FAcMa&data=02%7C01%7Caharui%40adobe.com%7Cc01ffc8e334943c65c7d08d6345d234b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636753971960008346&sdata=i3zV%2FoOc2ObIzmlaCO6pEZRuQoL7fMFOQT9v%2FonE3x4%3D&reserved=0
>>
>>
>> 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%7Cc01ffc8e334943c65c7d08d6345d234b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636753971960008346&sdata=8pzKepOH2zAUSGZ9KOZMt2U7haBFXinRB4sVvYz8y2g%3D&reserved=0
>> >>> > >> > > >>> > >
>> >>> > >> > > >>> > >
>> >>> > >> > > >>> > >
>> >>> > >> > > >>> > >
>> >>> > >> > > >>> >
>> >>> > >> > > >>> >
>> >>> > >> > > >>> >
>> >>> > >> > > >>>
>> >>> > >> > > >>> --
>> >>> > >> > > >>> Carlos Rovira
>> >>> > >> > > >>>
>> >>> > >> > > >>>
>> >>> > >> > >
>> >>> > >> >
>> >>> > >>
>> >>> >
>> >>>
>>
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc01ffc8e334943c65c7d08d6345d234b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636753971960008346&sdata=8pzKepOH2zAUSGZ9KOZMt2U7haBFXinRB4sVvYz8y2g%3D&reserved=0
>> >>> > >> > > >>>
>> >>> > >> > > >>>
>> >>> > >> > > >>>
>> >>> > >> > > >>
>> >>> > >> > > >> --
>> >>> > >> > > >> Carlos Rovira
>> >>> > >> > > >>
>> >>> > >> > >
>> >>> > >> >
>> >>> > >>
>> >>> >
>> >>>
>>
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc01ffc8e334943c65c7d08d6345d234b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636753971960008346&sdata=8pzKepOH2zAUSGZ9KOZMt2U7haBFXinRB4sVvYz8y2g%3D&reserved=0
>> >>> > >> > > >>
>> >>> > >> > > >>
>> >>> > >> > > >
>> >>> > >> > > > --
>> >>> > >> > > > Carlos Rovira
>> >>> >
>
>
>
> --
> Carlos Rovira
>
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc01ffc8e334943c65c7d08d6345d234b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636753971960008346&sdata=8pzKepOH2zAUSGZ9KOZMt2U7haBFXinRB4sVvYz8y2g%3D&reserved=0
>
>
--
Carlos Rovira
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc01ffc8e334943c65c7d08d6345d234b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636753971960008346&sdata=8pzKepOH2zAUSGZ9KOZMt2U7haBFXinRB4sVvYz8y2g%3D&reserved=0
