You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Alex Harui <ah...@adobe.com.INVALID> on 2019/06/01 06:08:10 UTC
Re: Language improvements
We have an implementation/optimization now that works for many people. Greg has another implementation that will work for some other people. He is free to add it as an option and make it the default option. It would be wrong to take away the current option. I can't think of any good reason to throw away working code that is smaller.
PAYG, choices. That's what we've been doing in Royale/FlexJS since the beginning. IMO, the option could have easily been implemented in the time we've spent on this thread. And probably significant progress would have been made on Vector and AMF.
-Alex
On 5/31/19, 2:51 PM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Alex,
don't think is one thing or another. I think there's a disagreement here.
Your point is one: give options event at the language level. Greg has
another point, that seems valid too (at least to me), not give options at
language level *at least in this iteration*. Nobody is saying this could
not be done in the future.
My opinion in this case is go with this and left that optimization for the
future. For sure others could have other opinions too. People needs this
new Vector implementation. We need it for use in our real production app
with AMF updates (implemented next and based on this work). I think we all
can have what we want, with this simple plan:
1.- Merge now Language improvements from Greg
2.- Continue working on Vector
a) Greg wants to add AMF support as next step
b) you want to make it a choice, you can do this as your next step
too.
Result: We all win. We all have what we want.
If we don't go. We have a problem, since people like me can't progress in a
feature we need to add in our real production app. Maybe others too. I
think that's not good. And I want to have choices too, but I can wait to
improve Vector implementation more to get to that, since priority, at least
for me, is to have support for Vector in AMF/ RemoteObject.
So I think we should not discuss more on the points we discussed largely in
this thread and we all know how we all think right? I think we need a plan
to execute. I think is the most practical thing we can do right now.
Do you find any problem in making this way based on the points I described
before? If not, let us know what could be your plan / steps to do (but
please, describe something doable, since if not we continue stuck in an
endless discussion).
Thanks in advance for your help.
El vie., 31 may. 2019 a las 22:26, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Greg, you are still trying to use the language conformance argument. This
> is not an issue of language conformance, it is an issue of optimization.
> Code paths not needed should not be downloaded. Every app development tool
> I've used that offers optimizations offers optimization levels and
> documentation of risks.
>
> There is a disagreement on how to implement Vector in JS as well. The
> whole point of giving choices is to avoid having to spend so many emails
> trying to reach a decision. Just provide choices so we can move on. Every
> argument you make below is an argument for giving choices.
>
> -Alex
>
> On 5/30/19, 9:03 PM, "Greg Dove" <gr...@gmail.com> wrote:
>
> "And so we will stop using Vector and migrate to using a plain Array.
> That
> agreement proves that the proposed changes are not right." We will
> effectively encourage others to do the same.
>
> It does not prove that at all, Alex. It depends on the criteria, and we
> have no commonly accepted guiding principles for what is 'right' here.
> At least one of us believes that it is more correct that (in the
> absence of
> other proposed options) it be an Array in the original code.
> If you take a step back and look at it from a broader perspective, it
> can
> be equally true to say 'This agreement proves that the original
> implementation was not right'.
> Firstly, I don't think Vector type was providing any benefit in this
> case
> in the first place (but that alone is not a reason to change it,
> awareness
> that it 'costs more' would however be a valid reason if there are no
> benefits to using it).
> Secondly, the collaborative outcome resulting in the use of explicit
> Array
> and the goog.DEBUG check is better than the original Vector-as-Array
> output
> because it offers the runtime type safety that was missing because it
> was
> not behaving like a Vector - and it retains the advantage of
> zero-weight in
> release build. Making these changes *is* a form of optimization based
> on
> using options currently available, it just happens to be hand-coded
> and not
> compiler-generated.
> I know it's at least a little bit useful in its new form, because prior
> testing with the branch level Vector implementation flagged a
> non-conforming IBead in the 2nd app I tested it with, something that
> was
> not found by the original 'Array' implementation.
> SWF testing in parallel would have caught that too, but is not a
> realistic
> assumption to have that as part of the workflow for checking runtime
> behavior anymore, so this 'Array with debug-only typecheck' in
> javascript
> is a good outcome.
> In this case, going back to Vector-as-Array output without making the
> other
> change would be a step backwards.
>
> That is however just one specific case, and I needed to present what I
> believe is a more balanced view of that... but I will not focus on it
> in
> any further discussion.
> I do understand that your point is intended to be more general.
> In general, and *by definition*, the cases where you want Vector to be
> Array without adverse consequences are always cases where it can also
> *be*
> Array in the original as3 code. If the only justification for it being
> a
> Vector in as3 code is 'compile-time type safety', then the proposed
> alternative from Harbs and Josh is a better option because it retains
> the
> benefits you seek and is a better quality cross-target representation
> for
> this specific sort of requirement (it will also provide more benefits:
> most
> Vector methods do not have compile-time type safety because most their
> method signatures do not specify :T types, I hope the proposed
> alternative
> might address that).
> For the performance-oriented numeric types, which is another thing
> that has
> been raised, maybe Josh can somehow include that with the typed Arrays
> feature as he suggested, maybe not. If yes, then great, but if not, I
> am
> happy to explore other options for that.
>
> What I'd really like to hear are your thoughts about the concerns I
> raised
> for the:
> "new whateverclasstheconfigordirectivespecified()"
> approach to doing any of this.
>
> How do you propose to avoid risk to the community and potentially to
> Royale's reputation with release of swcs that can have different
> language-level variations in them (XML, Vector or anything that
> represents
> a core as3 'type')?
> Do we have to warn people not to do that, and then hope that they
> don't? A
> user of that swc doesn't see the emulation class that the swc may
> expose
> without investigating at runtime, they normally only see the type it
> represents, and unless they are warned, they have no reason to assume
> it
> won't do all the things it should. There could also be runtime conflict
> implications when mixing swcs with different emulation decisions, and
> that
> could even add weight overall compared to using one. None of this
> represents stuff that can't be figured out and addressed by developers
> who
> have to deal with it. But it seems to me to be something negative,
> which
> would be better to avoid.
>
> I think you are indicating the same desire to avoid this problem by
> saying
> that you want to specify things by 'the swc' you add (e.g. XML
> replacement)... but that can be too late, because even if an alternate
> emulation class itself is not bundled into a swc's code, all the calls
> to
> instantiate it are, which reflect its distinct package name and class
> name.
> I can envisage ways to achieve optimization and to avoid risks for the
> general case, but only if the instantiation calls for these language
> level
> emulations can never vary throughout the entire codebase (all swcs
> included), and the 'optimization' is therefore largely driven from the
> application build, and not dictated at swc level. Maybe swc libraries
> could
> be advertised as being compatible with some well-known optimizations in
> this case, it could even be a 'marketing' claim for the swc.
> The most appealing optimization solution (to me) would be one that
> takes
> more advantage of GCC (which I consider will be 'safer', and also least
> effort for the developer) when the application gets built, instead of
> actually changing the content of individual methods (for example) in
> 'lite'
> versions of replacement classes. However, I can see that doing the
> latter
> (or both) should also be possible and should not be much different, I
> think, from a regular monkey-patch approach, or from your desire for
> swc
> level replacement - but it only works if there is no variation in the
> actual naming of the classes that are being 'patched' (whether its via
> an
> alternate XML-like swc as a direct substitute for the standard one, or
> a
> local monkey patch). Maybe I'm missing something that is obvious to
> you...
> please tell me if I am.
>
>
> On Fri, May 31, 2019 at 6:37 AM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> > It is pretty simple to me. The proposed Vector implementation is
> heavy
> > enough that we all agree that we don't want to use it for just one
> use case
> > in the Strand. And so we will stop using Vector and migrate to
> using a
> > plain Array. That agreement proves that the proposed changes are not
> > right. We will effectively encourage others to do the same.
> >
> > It would be much better if Royale had a way for developers to
> specify that
> > the one use of Vector in the Strand should be converted to plain
> Array by
> > the compiler and other uses could use the proposed Vector. That's
> how
> > optimization should be made available for all kinds of code in
> Royale, not
> > just for Vector.
> >
> > The current Vector output in the develop branch is low cost and fully
> > functional for some uses cases. As long as that output is still
> available
> > as a compiler option then having other output fine.
> >
> > I still haven't found time to look at the actual proposed changes,
> but I
> > would strongly prefer that, instead of having to modify compiler
> output
> > each time someone proposes a different Vector implementation, that
> the
> > changes can all be done by which SWC you choose for your Vector
> > implementation. There are other places in the compiler where you can
> > choose the class to use for Binding or ClassFactory. Hopefully the
> same
> > approach is being used for Vector. Ideally, the compile would just
> output
> > "new whateverclasstheconfigordirectivespecified()" and then just
> output the
> > usual push/pop/index calls and so it could just be plain Array where
> > specified or the proposed Vector and some other Vector someday.
> >
> > This is a case were "there is no one right way". And when we have
> those
> > situations, we must offer choices.
> >
> > -Alex
> >
> > On 5/30/19, 1:34 AM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> >
> > Hi,
> >
> > @Alex Harui <ah...@adobe.com> I think you misunderstood me.
> I'm not
> > saying
> > we should "remove choices". What I say is that we have finally a
> more
> > robust implementation and we can evolve to have more choices
> from that
> > point. I think continue from that safe point will give us many
> > benefits. So
> > I want those choices. What I don't want is to wait to make it
> perfect
> > to
> > merge. As I said before perfection is enemy of the progress.
> >
> > An important point I can't agree with you: Why we don't use
> Vector in
> > our
> > production App? Cause we can't. To do that we need: a) Greg
> changes
> > merged,
> > b) make AMF understand Vectors (still to be done to make Vector
> usable
> > for
> > us). Without both points Vectors are not an option for us. So I
> think
> > the
> > premise of "we have 2 apps in production without Vectors" are not
> > right. We
> > don't have still Jewel DataGrid, or Swiz Global Dispatcher, and
> that
> > does
> > not mean it's ok for us. Is just we still don't have it, but
> making us
> > to
> > make our product without all of that is a serious issue that we
> need to
> > workaround in some way. But we can do that as something
> "temporal",
> > due to
> > current Royale limitations. But our goal is to have all that,
> > Vector-AMF
> > included :)
> >
> > For this reason, I prefer to have Greg's Vector now, since it
> makes our
> > production App be one step closer to remove current workarounds
> :)
> > And I'm sure that not having a Vector solution like this, could
> be a
> > reason
> > why some people still didn't try Royale to migrate to this date.
> > So if you ask me or those people for a "priority path", we will
> say
> > "let's
> > get Vector first, then evolve from that to have more choices".
> > That's what I'm saying it's ok to merge now.
> >
> > I'm ok with having Vector as we all know it from AS3 (since is
> > that...AS3
> > Vector, don't forget that, and is what people expect to have at
> first
> > sight, then we can give them more choices and they will
> appreciate for
> > sure), and have as well a new Typed Array too as other proposed
> too.
> > That
> > will be for me options. But we should not wait to make all that
> happen
> > to
> > merge current branch, right?, All that we'll be lots of time to
> make it
> > perfect from day 0.
> >
> > The key concept for me was what Harbs said in his response to
> the end.
> > If
> > you don't use it the impact is 0, not 2-3k, since people don't
> have
> > Vector
> > presence in their codes. So that's PAYG. For that reason it's ok
> for
> > me to
> > merge and continue from that safe point, since we really only get
> > positive
> > things and nothing negative, and since we all agree in the same
> terms,
> > just
> > we need more time to continue evolving it to get to that perfect
> final
> > point.
> >
> >
> >
> >
> > El jue., 30 may. 2019 a las 7:56, Greg Dove (<
> greg.dove@gmail.com>)
> > escribió:
> >
> > > Harbs some quick comments inline...
> > >
> > > On Thu, May 30, 2019 at 4:27 PM Harbs <ha...@gmail.com>
> wrote:
> > >
> > > > The only niggle I have with my approach is that Vector in
> Flash is
> > more
> > > > performant than array, while in JS, it’s going to be the
> other way
> > > around.
> > > > So if someone has a performance-sensitive piece of code, how
> > should they
> > > > write it so it outputs as performant as possible on both
> platforms?
> > > >
> > > > Vector in flash is only substantially faster for its 3
> numeric
> > types
> > > which
> > > are optimized. It is (slightly) slower than Array in other
> cases - I
> > think
> > > it is normal that the extra type checking takes time even in
> native
> > code.
> > > I remember seeing some data which said it was 30% slower for
> some
> > methods
> > > with the non-primitive types, but that may be old.
> > >
> > > In terms of the emulation version, you can get javascript Array
> > speed with
> > > the index access and assignment, which should be a direct copy
> of
> > the same
> > > parts of code that are heavily optimized in flash I think.
> > >
> > > I was running performance tests on the non-debug flash player
> > alongside
> > > javascript. I actually see the regular native javascript Array
> > beating
> > > flash numeric Vectors in Chrome on windows, for the same tasks.
> > Perhaps the
> > > pepper plugin is getting less cpu resource than the browser or
> > something
> > > like that, not sure. I had assumed TypedArrays would be
> faster, but
> > > recently you said you weren't sure because of js engine
> smarts. I
> > will
> > > still check that.
> > >
> > >
> > >
> > > > I have not spent the time looking into the implementation,
> but I
> > think
> > > > there might be some cross-communication. My understanding
> from
> > what Greg
> > > > wrote is that if Vector is not used in an application, there
> will
> > be no
> > > > extra code due to dead code removal. If that’s correct, I
> think
> > we’re in
> > > > agreement that the implementation is fine. Do I understand
> > correctly?
> > > >
> > >
> > > That is correct.
> > >
> > >
> > > >
> > > > Harbs
> > > >
> > > > > On May 30, 2019, at 1:26 AM, Josh Tynjala <
> > joshtynjala@apache.org>
> > > > wrote:
> > > > >
> > > > > I definitely want the default choice to have as few
> surprises as
> > > > possible when it comes to how ActionScript behaves in Royale.
> > We'll never
> > > > have a perfect emulation, of course, but there are things
> that I
> > think
> > > can
> > > > still be improved. At the same time, I think it's perfectly
> valid
> > for
> > > > someone to want to opt into a typed Array that doesn't have
> the
> > runtime
> > > > overhead of Vector and isn't as heavy in file size. I'm wary
> of the
> > > > solution being a custom implementation of Vector with missing
> > features,
> > > > though. It will lead to confusion, even if it's opt-in.
> > > > >
> > > > > What Harbs suggested seems like a smart way to go. Rather
> than
> > having a
> > > > separate Vector implementation that doesn't work as
> developers are
> > used
> > > to,
> > > > a new variation of Array that has compile-time type checks
> but no
> > runtime
> > > > checks sounds like a more elegant solution. Like Vector
> works in
> > Royale
> > > > today, it can compile down to a regular JS Array, but at
> > compile-time,
> > > we'd
> > > > have some extra safety and could even possibly cast back and
> forth
> > with
> > > > untyped Arrays (which we can't do with Vector).
> > > > >
> > > > > - Josh
> > > > >
> > > > > On 2019/05/29 18:07:31, Alex Harui
> <ah...@adobe.com.INVALID>
> > wrote:
> > > > >> We must not eliminate choices.
> > > > >>
> > > > >> I still haven't had time to look at the branch.
> > > > >>
> > > > >> There must be away to avoid even a 1K cost to those who
> don't
> > need it.
> > > > >>
> > > > >> If there is such a way, then it is fine to merge.
> Otherwise,
> > everyone
> > > > is going to pay 2K to use a Vector when we know at least two
> apps
> > are in
> > > > production without needing that 2k.
> > > > >>
> > > > >> There are too many words being written and no technical
> points
> > being
> > > > made. I will try to resummarize.
> > > > >>
> > > > >> 1) It does not matter how fast your network is. Every
> other
> > app will
> > > > use more bandwidth and when the network gets busy or
> connectivity
> > gets
> > > poor
> > > > (something I see quite frequently where I live) either you
> get
> > your app
> > > to
> > > > run or you run out of time.
> > > > >>
> > > > >> 2) If you are not using some feature of our code, you
> should
> > not have
> > > > to pay for it in download cost. That's PAYG. That would be
> true
> > for
> > > > Vector, XML and even if we had to write a Date
> implementation. It
> > is not
> > > > an issue of non-conforming. It is an issue of
> optimization. If
> > you
> > > aren't
> > > > going to use some feature of E4x you should have the option
> of
> > using code
> > > > that doesn't have those code paths. Same for if we had to
> do Date.
> > > > >>
> > > > >> We know that if you don't need runtime-type checking and
> > fixed-length
> > > > checking that a plain Array is just fine and 2K cheaper.
> Let's
> > give
> > > folks
> > > > the option to do that.
> > > > >>
> > > > >> I will repeat that I do not have any objection to having
> a full
> > Vector
> > > > implementation with runtime type-checking and fixed length
> > checking be
> > > the
> > > > default choice as long as folks can optimize back to using
> the
> > plain
> > > Array
> > > > code we use now.
> > > > >>
> > > > >> For the one Vector we currently have in all apps for the
> > Strand, it
> > > > might be time to change that to an array and check the type
> (in
> > > debug-only
> > > > code) on addBead. Either that or we add compiler options so
> that
> > one
> > > > Vector gets optimized to the current plain Array code.
> > > > >>
> > > > >> It is not a technical argument to classify Vector as
> "Language"
> > and
> > > > therefore somehow an exception to being optimizable.
> > > > >>
> > > > >> My 2 cents,
> > > > >> -Alex
> > > > >>
> > > > >>
> > > > >> On 5/28/19, 2:59 AM, "Carlos Rovira" <
> carlosrovira@apache.org>
> > > wrote:
> > > > >>
> > > > >> Hi,
> > > > >>
> > > > >> I think that we all agree in most of the things, and
> > although we're
> > > > >> discussing some particularities on how to solve, my
> opinion
> > is that
> > > > those
> > > > >> particularities can be solved after merging Language
> > improvements
> > > > branch.
> > > > >> We all agree we need this Vector (and other
> improvements in
> > this
> > > > branch)?.
> > > > >> So, after that merge folks wanting to improve, let's
> say,
> > > Vector(for
> > > > >> example) even more with new choices can do that without
> > problem and
> > > > will
> > > > >> make it even better.
> > > > >>
> > > > >> Are we ok with that?
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> El mar., 28 may. 2019 a las 11:07, Harbs (<
> > harbs.lists@gmail.com>)
> > > > escribió:
> > > > >>
> > > > >>>
> > > > >>>> On May 28, 2019, at 11:12 AM, Greg Dove <
> greg.dove@gmail.com>
> > > wrote:
> > > > >>>>
> > > > >>>>> "I personally have never used length checking in
> Vector. Nor
> > was
> > > > runtime
> > > > >>>>> type checking on Vectors important to me. "
> > > > >>>> length checking is automatic in flash. I don't know
> that you
> > 'use'
> > > > it...
> > > > >>> it
> > > > >>>> is just there.
> > > > >>>
> > > > >>> True. What I meant is that I never used fixed length
> Vectors.
> > > > >>>
> > > > >>>> In javascript I expect it would most often be switched
> off in
> > all
> > > > release
> > > > >>>> builds, but having it on by default provides another
> check of
> > > > something
> > > > >>>> that could provide a vital clue to help people figuring
> out
> > problems
> > > > in
> > > > >>>> code.
> > > > >>>> So far each 'stronger typing' feature added in the last
> few
> > months
> > > has
> > > > >>>> revealed potential issues or - most often - bad code
> that was
> > > working
> > > > >>> when
> > > > >>>> it should not
> > > > >>>
> > > > >>> Good points, and one that argues for the ability to have
> these
> > checks
> > > > >>> while debugging and have the run-time code removed on
> release.
> > > > >>>
> > > > >>>> One thing about the mxml stuff is that it gets
> processed in a
> > way
> > > > that is
> > > > >>>> untyped.
> > > > >>>
> > > > >>>
> > > > >>> Agree. I do wish there was some way for MXML to be output
> > “better”
> > > > where
> > > > >>> minified vars could “just work” and types could be better
> > inferred
> > > > from the
> > > > >>> MXML files.
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Carlos Rovira
> > > > >>
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ca5d2bf322f6f4fc516fd08d6e61223ca%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636949363104909263&sdata=jiO6laah7%2BQJco8dZGD76QWu93eJzPLGpsPRT66GoPg%3D&reserved=0
> > > > >>
> > > > >>
> > > > >>
> > > >
> > > >
> > >
> >
> >
> > --
> > Carlos Rovira
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ca5d2bf322f6f4fc516fd08d6e61223ca%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636949363104909263&sdata=jiO6laah7%2BQJco8dZGD76QWu93eJzPLGpsPRT66GoPg%3D&reserved=0
> >
> >
> >
>
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ca5d2bf322f6f4fc516fd08d6e61223ca%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636949363104909263&sdata=jiO6laah7%2BQJco8dZGD76QWu93eJzPLGpsPRT66GoPg%3D&reserved=0