Re: +configname=flex
Hi Josh,
I rebuild all in the branch and can confirm your fix worked :)
Thanks for taking the time check this and showing the way to fix it! :)
Carlos
El jue., 6 dic. 2018 a las 19:10, Carlos Rovira ()
escribió:
> Hi Josh,
>
> thanks for looking at it, I'll going to check now and report
>
> El jue., 6 dic. 2018 a las 19:03, Josh Tynjala ()
> escribió:
>
>> Carlos,
>>
>> I wish that you had included the list of problems that you are seeing, as
>> I requested. I wanted to be completely certain that I'm seeing the exact
>> same ones that you are.
>>
>> Regardless, here's my initial attempt to reproduce and fix your issue.
>>
>> In examples/mxroyale/RemoteObjectAMFTest/asconfig.json, I switched to
>> App_Jewel.mxml.
>>
>> Instead of using your branch, I simply modified royale-config.xml in my
>> local SDK. When I did this, I saw the following problems appear in Visual
>> Studio Code:
>>
>> App_Jewel.mxml(30): col: 20 Warning: Definition mx.rpc.AsyncToken could
>> not be found.
>> App_Jewel.mxml(31): col: 20 Warning: Definition mx.rpc.Responder could
>> not be found.
>> App_Jewel.mxml(32): col: 20 Warning: Definition mx.rpc.events.FaultEvent
>> could not be found.
>> App_Jewel.mxml(33): col: 20 Warning: Definition mx.rpc.events.ResultEvent
>> could not be found
>> App_Jewel.mxml(38): col: 33 Error: Type was not found or was not a
>> compile-time constant: FaultEvent.
>> App_Jewel.mxml(44): col: 31 Error: Type was not found or was not a
>> compile-time constant: AsyncToken.
>> App_Jewel.mxml(45): col: 35 Error: Type was not found or was not a
>> compile-time constant: Responder.
>> App_Jewel.mxml(48): col: 33 Error: Call to a possibly undefined method
>> Responder.
>> App_Jewel.mxml(54): col: 49 Error: Type was not found or was not a
>> compile-time constant: ResultEvent.
>> App_Jewel.mxml(70): col: 23 Error: Type was not found or was not a
>> compile-time constant: Responder.
>> App_Jewel.mxml(70): col: 39 Error: Call to a possibly undefined method
>> Responder.
>> App_Jewel.mxml(71): col: 23 Error: Type was not found or was not a
>> compile-time constant: AsyncToken.
>> App_Jewel.mxml(76): col: 55 Error: Type was not found or was not a
>> compile-time constant: ResultEvent.
>> App_Jewel.mxml(142): col: 23 Error: Type was not found or was not a
>> compile-time constant: Responder.
>> App_Jewel.mxml(142): col: 39 Error: Call to a possibly undefined method
>> Responder.
>> App_Jewel.mxml(143): col: 23 Error: Type was not found or was not a
>> compile-time constant: AsyncToken.
>> App_Jewel.mxml(148): col: 60 Error: Type was not found or was not a
>> compile-time constant: ResultEvent.
>> App_Jewel.mxml(170): col: 9 Error: This tag is unexpected. It will be
>> ignored.
>>
>> These problems are expected, of course, since MXRoyaleJS.swc is not in
>> the library path anymore.
>>
>> In asconfig.json, I added the following two compiler options:
>>
>> "library-path": [
>> "${royalelib}/js/libs/MXRoyaleJS.swc"
>> ],
>> "js-library-path": [
>> "${royalelib}/js/libs/MXRoyaleJS.swc"
>> ]
>>
>> This cleared up all of the problems. Does this work for you?
>>
>> - Josh
>>
>> On 2018/12/06 10:05:36, Carlos Rovira wrote:
>> > Hi Josh
>> >
>> > El mié., 5 dic. 2018 a las 17:59, Josh Tynjala (> >)
>> > escribió:
>> >
>> > > Carlos, can you include more details about your issue?
>> > >
>> > > > MX RO test with Jewel
>> > >
>> > > Can you mention the exact project inside royale-asjs that I can load
>> with
>> > > VSCode to see this issue? I'm guessing that it might be one of the
>> > > RemoteObjectAMFTest projects, but there are more than one!
>> > >
>> > >
>> > Check this one:
>> >
>> https://github.com/apache/royale-asjs/blob/develop/examples/mxroyale/RemoteObjectAMFTest/pom.xml
>> >
>> > but notice that App setup by default is not the right one (check lines
>> 49
>> > and 50 here):
>> >
>> >
>> https://github.com/apache/royale-asjs/blob/develop/examples/mxroyale/RemoteObjectAMFTest/pom.xml
>> >
>> > You must use "App_Jewel.mxml"
>> >
>> > Remember to use "feature/refactor-config-name-changes" branch where my
>> > commit is reverted and things are set up like Alex want.
>> >
>> > You should try to make another config (for example:
>> > "jewel-config-template.xml") that can pick up Jewel and MXRoyale SWCs
>> > and VSCode and your extension should not show any errors.
>> >
>> >
>> >
>> > > > Results: you should see the problems in VSCode
>> > >
>> > > Can you list the exact problems that you are seeing in VSCode? I'd
>> like to
>> > > make sure that I'm not running into unrelated issues.
>> > >
>> >
>> > With Alex changes all classes coming from MXRoyale are not recognized
>> hence
>> > show error.
>> > If I try to make a new config file and add MXRoyale, rebuild all and SDK
>> > too, reopen VSCode, nothing changes
>> >
>> > So my bet is that there's some issue in Royale that makes this new
>> config
>> > changes not work far beyond the special configuration Alex did and need
>> to
>> > find where is the issue.
Re: +configname=flex
Hi Josh,
thanks for looking at it, I'll going to check now and report
El jue., 6 dic. 2018 a las 19:03, Josh Tynjala ()
escribió:
> Carlos,
>
> I wish that you had included the list of problems that you are seeing, as
> I requested. I wanted to be completely certain that I'm seeing the exact
> same ones that you are.
>
> Regardless, here's my initial attempt to reproduce and fix your issue.
>
> In examples/mxroyale/RemoteObjectAMFTest/asconfig.json, I switched to
> App_Jewel.mxml.
>
> Instead of using your branch, I simply modified royale-config.xml in my
> local SDK. When I did this, I saw the following problems appear in Visual
> Studio Code:
>
> App_Jewel.mxml(30): col: 20 Warning: Definition mx.rpc.AsyncToken could
> not be found.
> App_Jewel.mxml(31): col: 20 Warning: Definition mx.rpc.Responder could not
> be found.
> App_Jewel.mxml(32): col: 20 Warning: Definition mx.rpc.events.FaultEvent
> could not be found.
> App_Jewel.mxml(33): col: 20 Warning: Definition mx.rpc.events.ResultEvent
> could not be found
> App_Jewel.mxml(38): col: 33 Error: Type was not found or was not a
> compile-time constant: FaultEvent.
> App_Jewel.mxml(44): col: 31 Error: Type was not found or was not a
> compile-time constant: AsyncToken.
> App_Jewel.mxml(45): col: 35 Error: Type was not found or was not a
> compile-time constant: Responder.
> App_Jewel.mxml(48): col: 33 Error: Call to a possibly undefined method
> Responder.
> App_Jewel.mxml(54): col: 49 Error: Type was not found or was not a
> compile-time constant: ResultEvent.
> App_Jewel.mxml(70): col: 23 Error: Type was not found or was not a
> compile-time constant: Responder.
> App_Jewel.mxml(70): col: 39 Error: Call to a possibly undefined method
> Responder.
> App_Jewel.mxml(71): col: 23 Error: Type was not found or was not a
> compile-time constant: AsyncToken.
> App_Jewel.mxml(76): col: 55 Error: Type was not found or was not a
> compile-time constant: ResultEvent.
> App_Jewel.mxml(142): col: 23 Error: Type was not found or was not a
> compile-time constant: Responder.
> App_Jewel.mxml(142): col: 39 Error: Call to a possibly undefined method
> Responder.
> App_Jewel.mxml(143): col: 23 Error: Type was not found or was not a
> compile-time constant: AsyncToken.
> App_Jewel.mxml(148): col: 60 Error: Type was not found or was not a
> compile-time constant: ResultEvent.
> App_Jewel.mxml(170): col: 9 Error: This tag is unexpected. It will be
> ignored.
>
> These problems are expected, of course, since MXRoyaleJS.swc is not in the
> library path anymore.
>
> In asconfig.json, I added the following two compiler options:
>
> "library-path": [
> "${royalelib}/js/libs/MXRoyaleJS.swc"
> ],
> "js-library-path": [
> "${royalelib}/js/libs/MXRoyaleJS.swc"
> ]
>
> This cleared up all of the problems. Does this work for you?
>
> - Josh
>
> On 2018/12/06 10:05:36, Carlos Rovira wrote:
> > Hi Josh
> >
> > El mié., 5 dic. 2018 a las 17:59, Josh Tynjala ( >)
> > escribió:
> >
> > > Carlos, can you include more details about your issue?
> > >
> > > > MX RO test with Jewel
> > >
> > > Can you mention the exact project inside royale-asjs that I can load
> with
> > > VSCode to see this issue? I'm guessing that it might be one of the
> > > RemoteObjectAMFTest projects, but there are more than one!
> > >
> > >
> > Check this one:
> >
> https://github.com/apache/royale-asjs/blob/develop/examples/mxroyale/RemoteObjectAMFTest/pom.xml
> >
> > but notice that App setup by default is not the right one (check lines 49
> > and 50 here):
> >
> >
> https://github.com/apache/royale-asjs/blob/develop/examples/mxroyale/RemoteObjectAMFTest/pom.xml
> >
> > You must use "App_Jewel.mxml"
> >
> > Remember to use "feature/refactor-config-name-changes" branch where my
> > commit is reverted and things are set up like Alex want.
> >
> > You should try to make another config (for example:
> > "jewel-config-template.xml") that can pick up Jewel and MXRoyale SWCs
> > and VSCode and your extension should not show any errors.
> >
> >
> >
> > > > Results: you should see the problems in VSCode
> > >
> > > Can you list the exact problems that you are seeing in VSCode? I'd
> like to
> > > make sure that I'm not running into unrelated issues.
> > >
> >
> > With Alex changes all classes coming from MXRoyale are not recognized
> hence
> > show error.
> > If I try to make a new config file and add MXRoyale, rebuild all and SDK
> > too, reopen VSCode, nothing changes
> >
> > So my bet is that there's some issue in Royale that makes this new config
> > changes not work far beyond the special configuration Alex did and need
> to
> > find where is the issue. Other possibility is that VSCode extension is
> > failing, but since it already loads different configs, this seems more
> > strange to me, although possible.
> >
> >
> > >
> > > I don't think that this is an issue with VSCode or with the changes
> that
> > > Alex made. I suspect that it's just some configuration changes that are
> > > needed.
> > >
> > > -
Re: +configname=flex
Carlos,
I wish that you had included the list of problems that you are seeing, as I
requested. I wanted to be completely certain that I'm seeing the exact same
ones that you are.
Regardless, here's my initial attempt to reproduce and fix your issue.
In examples/mxroyale/RemoteObjectAMFTest/asconfig.json, I switched to
App_Jewel.mxml.
Instead of using your branch, I simply modified royale-config.xml in my local
SDK. When I did this, I saw the following problems appear in Visual Studio Code:
App_Jewel.mxml(30): col: 20 Warning: Definition mx.rpc.AsyncToken could not be
found.
App_Jewel.mxml(31): col: 20 Warning: Definition mx.rpc.Responder could not be
found.
App_Jewel.mxml(32): col: 20 Warning: Definition mx.rpc.events.FaultEvent could
not be found.
App_Jewel.mxml(33): col: 20 Warning: Definition mx.rpc.events.ResultEvent could
not be found
App_Jewel.mxml(38): col: 33 Error: Type was not found or was not a compile-time
constant: FaultEvent.
App_Jewel.mxml(44): col: 31 Error: Type was not found or was not a compile-time
constant: AsyncToken.
App_Jewel.mxml(45): col: 35 Error: Type was not found or was not a compile-time
constant: Responder.
App_Jewel.mxml(48): col: 33 Error: Call to a possibly undefined method
Responder.
App_Jewel.mxml(54): col: 49 Error: Type was not found or was not a compile-time
constant: ResultEvent.
App_Jewel.mxml(70): col: 23 Error: Type was not found or was not a compile-time
constant: Responder.
App_Jewel.mxml(70): col: 39 Error: Call to a possibly undefined method
Responder.
App_Jewel.mxml(71): col: 23 Error: Type was not found or was not a compile-time
constant: AsyncToken.
App_Jewel.mxml(76): col: 55 Error: Type was not found or was not a compile-time
constant: ResultEvent.
App_Jewel.mxml(142): col: 23 Error: Type was not found or was not a
compile-time constant: Responder.
App_Jewel.mxml(142): col: 39 Error: Call to a possibly undefined method
Responder.
App_Jewel.mxml(143): col: 23 Error: Type was not found or was not a
compile-time constant: AsyncToken.
App_Jewel.mxml(148): col: 60 Error: Type was not found or was not a
compile-time constant: ResultEvent.
App_Jewel.mxml(170): col: 9 Error: This tag is unexpected. It will be ignored.
These problems are expected, of course, since MXRoyaleJS.swc is not in the
library path anymore.
In asconfig.json, I added the following two compiler options:
"library-path": [
"${royalelib}/js/libs/MXRoyaleJS.swc"
],
"js-library-path": [
"${royalelib}/js/libs/MXRoyaleJS.swc"
]
This cleared up all of the problems. Does this work for you?
- Josh
On 2018/12/06 10:05:36, Carlos Rovira wrote:
> Hi Josh
>
> El mié., 5 dic. 2018 a las 17:59, Josh Tynjala ()
> escribió:
>
> > Carlos, can you include more details about your issue?
> >
> > > MX RO test with Jewel
> >
> > Can you mention the exact project inside royale-asjs that I can load with
> > VSCode to see this issue? I'm guessing that it might be one of the
> > RemoteObjectAMFTest projects, but there are more than one!
> >
> >
> Check this one:
> https://github.com/apache/royale-asjs/blob/develop/examples/mxroyale/RemoteObjectAMFTest/pom.xml
>
> but notice that App setup by default is not the right one (check lines 49
> and 50 here):
>
> https://github.com/apache/royale-asjs/blob/develop/examples/mxroyale/RemoteObjectAMFTest/pom.xml
>
> You must use "App_Jewel.mxml"
>
> Remember to use "feature/refactor-config-name-changes" branch where my
> commit is reverted and things are set up like Alex want.
>
> You should try to make another config (for example:
> "jewel-config-template.xml") that can pick up Jewel and MXRoyale SWCs
> and VSCode and your extension should not show any errors.
>
>
>
> > > Results: you should see the problems in VSCode
> >
> > Can you list the exact problems that you are seeing in VSCode? I'd like to
> > make sure that I'm not running into unrelated issues.
> >
>
> With Alex changes all classes coming from MXRoyale are not recognized hence
> show error.
> If I try to make a new config file and add MXRoyale, rebuild all and SDK
> too, reopen VSCode, nothing changes
>
> So my bet is that there's some issue in Royale that makes this new config
> changes not work far beyond the special configuration Alex did and need to
> find where is the issue. Other possibility is that VSCode extension is
> failing, but since it already loads different configs, this seems more
> strange to me, although possible.
>
>
> >
> > I don't think that this is an issue with VSCode or with the changes that
> > Alex made. I suspect that it's just some configuration changes that are
> > needed.
> >
> > - Josh
> >
>
> Thanks for looking into this Josh
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
Re: +configname=flex
Hi Harbs, you're right, sorry. I thought I already pushed it. Just did now. El jue., 6 dic. 2018 a las 12:26, Harbs () escribió: > I don’t see the branch. Are you sure you pushed it? > > > On Dec 6, 2018, at 12:05 PM, Carlos Rovira > wrote: > > > > Remember to use "feature/refactor-config-name-changes" branch where my > > commit is reverted and things are set up like Alex want. > > -- Carlos Rovira http://about.me/carlosrovira
Re: +configname=flex
I don’t see the branch. Are you sure you pushed it? > On Dec 6, 2018, at 12:05 PM, Carlos Rovira wrote: > > Remember to use "feature/refactor-config-name-changes" branch where my > commit is reverted and things are set up like Alex want.
Re: +configname=flex
Hi Harbs, El mié., 5 dic. 2018 a las 18:42, Harbs () escribió: > Just to examine these steps and try to communicate how I would have > handled them: > > When I run into a similar problem while using “bleeding edge” code, my > first step is to write the problem to the list ASAP. I’ll spend the minimum > time necessary to isolate the problem and then describe the problem as > concisely as possible. Discussion usually helps flush out what the problem > is and helps find a course of action. > > If I am stuck and must continue working, I will do one of two things: > > 1. Locally I will revert to previous code if I can. Usually with compiler > issues, this is possible. > 2. Create a temporary branch for my own use. If the change is useful to > illustrate the problem (or it needs to be shared with others), I will push > the branch to the remote. > > I'm with you in the global way to proceed. > As you mentioned, your commit was likely to be reverted. That makes it a > prime candidate for a temporary branch. Although I’m not sure why you > couldn’t just revert to prior to Alex’s change locally to keep on working. > > I don’t think there was anything wrong with Alex committing his code to > develop. We discussed the problem he was trying to solve and the change > fixes it as intended. I don’t think anyone was aware that you were missing > MXRoyale and Jewel. (I definitely was not.) > If the commit doesn't make any regression, that will be ok for all of us. The problem as you said is maybe nobody was aware about someone using Jewel+MXRoyale. That is a legit way of use Apache Royale and should not be anything strange. So If I were Alex and suppose I make a change, directly in develop, and found someone found a regression, my first way to proceed is to put my muscle to try to help in something that was caused by my changes, not say "is not my problem, do it yourself or pay someone to do it", and start a long thread of emails. If that's the way to do this, I'm with Dave and we should move this issue to a branch and work there to solve the regression. So we don't bother the rest of developments that are confirmed and working. IOW, changes that we detect a problem should be done in a branch, no make the rest of us move to a branch. The use in all projects I now is this, and seems we are trying to do the opposite. > > I can’t imagine why it should not be possible to include the MXRoyale swc > in a Jewel project (or vice versa). It should just be a matter of figuring > out the correct configuration. Like Josh, I’d be interested in the details > to understand the problem better. > > Right, I don't know if is a bug in Royale, in config or in VSCode extension. I spend several hours on my own trying different configs (that's what we supposed it should fix the problem), but this comes in a bad time for me since I'm working hard to get our App ready and our client happy. In other timeframe I'll be already put some hours on this. But in the other hand the way Alex is managing this makes me feel not happy and asking me that I must invest hours or pay persons for something I did't ask for makes me ask myself if that's the way to operate here or if this is the way to go in an apache community. I think I could never ask others to work on something I did and caused some general issue or recommend pay others to solve things to complete the tasks I'm working on, does not seems to me the Apache way and I don't see my self with the power/status to say others to do that...I'm just another contributor to this project. > My $0.02, > Harbs > > > On Dec 1, 2018, at 9:29 PM, Carlos Rovira > wrote: > > > > 1.- You make a commit that introduced IDEs break > > 2.- I spend Saturday morning trying to find a way to fix that > > 3.- Instead of revert your commit I make a change of the thing causing > the > > problem with the comment "to be reverted as we find the solution" > -- Carlos Rovira http://about.me/carlosrovira
Re: +configname=flex
Hi Josh El mié., 5 dic. 2018 a las 17:59, Josh Tynjala () escribió: > Carlos, can you include more details about your issue? > > > MX RO test with Jewel > > Can you mention the exact project inside royale-asjs that I can load with > VSCode to see this issue? I'm guessing that it might be one of the > RemoteObjectAMFTest projects, but there are more than one! > > Check this one: https://github.com/apache/royale-asjs/blob/develop/examples/mxroyale/RemoteObjectAMFTest/pom.xml but notice that App setup by default is not the right one (check lines 49 and 50 here): https://github.com/apache/royale-asjs/blob/develop/examples/mxroyale/RemoteObjectAMFTest/pom.xml You must use "App_Jewel.mxml" Remember to use "feature/refactor-config-name-changes" branch where my commit is reverted and things are set up like Alex want. You should try to make another config (for example: "jewel-config-template.xml") that can pick up Jewel and MXRoyale SWCs and VSCode and your extension should not show any errors. > > Results: you should see the problems in VSCode > > Can you list the exact problems that you are seeing in VSCode? I'd like to > make sure that I'm not running into unrelated issues. > With Alex changes all classes coming from MXRoyale are not recognized hence show error. If I try to make a new config file and add MXRoyale, rebuild all and SDK too, reopen VSCode, nothing changes So my bet is that there's some issue in Royale that makes this new config changes not work far beyond the special configuration Alex did and need to find where is the issue. Other possibility is that VSCode extension is failing, but since it already loads different configs, this seems more strange to me, although possible. > > I don't think that this is an issue with VSCode or with the changes that > Alex made. I suspect that it's just some configuration changes that are > needed. > > - Josh > Thanks for looking into this Josh -- Carlos Rovira http://about.me/carlosrovira
Re: +configname=flex
Just to examine these steps and try to communicate how I would have handled them: When I run into a similar problem while using “bleeding edge” code, my first step is to write the problem to the list ASAP. I’ll spend the minimum time necessary to isolate the problem and then describe the problem as concisely as possible. Discussion usually helps flush out what the problem is and helps find a course of action. If I am stuck and must continue working, I will do one of two things: 1. Locally I will revert to previous code if I can. Usually with compiler issues, this is possible. 2. Create a temporary branch for my own use. If the change is useful to illustrate the problem (or it needs to be shared with others), I will push the branch to the remote. As you mentioned, your commit was likely to be reverted. That makes it a prime candidate for a temporary branch. Although I’m not sure why you couldn’t just revert to prior to Alex’s change locally to keep on working. I don’t think there was anything wrong with Alex committing his code to develop. We discussed the problem he was trying to solve and the change fixes it as intended. I don’t think anyone was aware that you were missing MXRoyale and Jewel. (I definitely was not.) I can’t imagine why it should not be possible to include the MXRoyale swc in a Jewel project (or vice versa). It should just be a matter of figuring out the correct configuration. Like Josh, I’d be interested in the details to understand the problem better. My $0.02, Harbs > On Dec 1, 2018, at 9:29 PM, Carlos Rovira wrote: > > 1.- You make a commit that introduced IDEs break > 2.- I spend Saturday morning trying to find a way to fix that > 3.- Instead of revert your commit I make a change of the thing causing the > problem with the comment "to be reverted as we find the solution"
Re: +configname=flex
Carlos, can you include more details about your issue? > MX RO test with Jewel Can you mention the exact project inside royale-asjs that I can load with VSCode to see this issue? I'm guessing that it might be one of the RemoteObjectAMFTest projects, but there are more than one! > Results: you should see the problems in VSCode Can you list the exact problems that you are seeing in VSCode? I'd like to make sure that I'm not running into unrelated issues. I don't think that this is an issue with VSCode or with the changes that Alex made. I suspect that it's just some configuration changes that are needed. - Josh On 2018/12/05 11:54:13, Carlos Rovira wrote: > Hi Alex, > > you continue talking of this in a way like like if the change you did is > right and my fix is not. But don't see you in a point to put your commit in > question. > I can say the same as you describe in your email, but applied to your > changes. Far beyond this concrete issue, I think we have a problem if you > consider that you can commit a change that breaks current repo (don't need > to be a build break, but other's like IDEs break), and when others fix the > failing problem you state that others changes are really the problem. I > think we're going in circles. > > Always I make a change I'm prepared to others critics and as well I don't > have problems in listen and revert my work or update when others have > explained things and I see my errors. You see me do this taking into > account your advices many times. So you can ensure I consider myself > fallible. > > But you way is always state you're right, and does not have a problem with > your commits. But I'm having. And not's a particular case. Is a case with > Jewel, that has exactly the same importance that the rest of Royale (to > avoid you refer to my case, as something that fails in some personal code > or config in my own) > > This days are difficult to me since I'm fixing things in our current real > world Royale App, so I still couldn't get to the problem in that branch. > I think as well is important for the Apache Royale, this real project gets > success, since that will mean one more success for Apache Royale getting a > new App that works and goes to production. So I think at least this days > that's priority I had to choose. > > About the problem, you said you asked some times in this thread, and I > think I responded some times in this thread. > > Here's another try If you want to check the problem yourself, until I can > get enough time do my own tries: > > 1.- grab VSCode and AS3 extension > 2.- build SDK in the branch where I reverted my commit and point VSCode to > that SDK > 3.- point a project like for example the MX RO test with Jewel example (so > you have a project that uses Jewel and MXRoyale) > > Results: you should see the problems in VSCode > > maybe you can start from the current version to see that with an SDK > generated from current branch problems are 0 and going to the branch with > your changes, VSCode goes crazy. > > I think from now on we can stop to say you don't have enough data to > reproduce the problem right? > > I think the problem could be that you don't use IDEs, but IMHO you should > setup VSCode or Moonlight (that since uses the same core, should shows the > same problem). You must have IDEs in mind, since we, are all in real > projects using real tools for the work, so you can be agnostic of that > reality, and if something breaks IDEs, the solutions we do must ensure IDEs > continue to work. > > Thanks > > Carlos > > > > > > > > El mié., 5 dic. 2018 a las 0:13, Alex Harui () > escribió: > > > When you are writing code for your app, you may or may not care about code > > re-usability. When writing code for a framework, you must always care > > about reusability. Thus, every change must be explainable. It isn't good > > enough to make a change because it was the only way you can get something > > to work. > > > > In this case, the change was to the list of default SWCs. It should be > > possible to override all of those settings for your needs. I have offered > > to help and asked for useful data on at least four posts on this thread. > > So far, I don't have anything to work with. I'm trying to help, but it is > > not a good use of my time to guess what the problem test case is. > > > > We must use sound engineering principles in creating a framework because > > we want lots of folks to rely on it. I was amazed when Adobe shipped the > > first generation of AS2 components with Flash MX that some folks spent > > hours reading the code. We would want folks to do the same for Royale and > > our code must make sense. Before changing someone else's code, you should > > be able to explain why the code you are changing is flawed and why your > > change is better. We have a commits history so you can go back and see > > changes to help determine why things were changed. If you can't explain > > your
Re: +configname=flex
Hi Alex, you continue talking of this in a way like like if the change you did is right and my fix is not. But don't see you in a point to put your commit in question. I can say the same as you describe in your email, but applied to your changes. Far beyond this concrete issue, I think we have a problem if you consider that you can commit a change that breaks current repo (don't need to be a build break, but other's like IDEs break), and when others fix the failing problem you state that others changes are really the problem. I think we're going in circles. Always I make a change I'm prepared to others critics and as well I don't have problems in listen and revert my work or update when others have explained things and I see my errors. You see me do this taking into account your advices many times. So you can ensure I consider myself fallible. But you way is always state you're right, and does not have a problem with your commits. But I'm having. And not's a particular case. Is a case with Jewel, that has exactly the same importance that the rest of Royale (to avoid you refer to my case, as something that fails in some personal code or config in my own) This days are difficult to me since I'm fixing things in our current real world Royale App, so I still couldn't get to the problem in that branch. I think as well is important for the Apache Royale, this real project gets success, since that will mean one more success for Apache Royale getting a new App that works and goes to production. So I think at least this days that's priority I had to choose. About the problem, you said you asked some times in this thread, and I think I responded some times in this thread. Here's another try If you want to check the problem yourself, until I can get enough time do my own tries: 1.- grab VSCode and AS3 extension 2.- build SDK in the branch where I reverted my commit and point VSCode to that SDK 3.- point a project like for example the MX RO test with Jewel example (so you have a project that uses Jewel and MXRoyale) Results: you should see the problems in VSCode maybe you can start from the current version to see that with an SDK generated from current branch problems are 0 and going to the branch with your changes, VSCode goes crazy. I think from now on we can stop to say you don't have enough data to reproduce the problem right? I think the problem could be that you don't use IDEs, but IMHO you should setup VSCode or Moonlight (that since uses the same core, should shows the same problem). You must have IDEs in mind, since we, are all in real projects using real tools for the work, so you can be agnostic of that reality, and if something breaks IDEs, the solutions we do must ensure IDEs continue to work. Thanks Carlos El mié., 5 dic. 2018 a las 0:13, Alex Harui () escribió: > When you are writing code for your app, you may or may not care about code > re-usability. When writing code for a framework, you must always care > about reusability. Thus, every change must be explainable. It isn't good > enough to make a change because it was the only way you can get something > to work. > > In this case, the change was to the list of default SWCs. It should be > possible to override all of those settings for your needs. I have offered > to help and asked for useful data on at least four posts on this thread. > So far, I don't have anything to work with. I'm trying to help, but it is > not a good use of my time to guess what the problem test case is. > > We must use sound engineering principles in creating a framework because > we want lots of folks to rely on it. I was amazed when Adobe shipped the > first generation of AS2 components with Flash MX that some folks spent > hours reading the code. We would want folks to do the same for Royale and > our code must make sense. Before changing someone else's code, you should > be able to explain why the code you are changing is flawed and why your > change is better. We have a commits history so you can go back and see > changes to help determine why things were changed. If you can't explain > your changes, don't push it. > > If something is a mystery, create a simple test case and add complexity > until it fails, or subset your complex test case until it stops failing. > Also consider whether the builds are working and whether anyone else is > complaining about related issues. Committers should be able to build from > sources, so rollback if you are in a hurry, but don't push a change if it > is just a guess. > > My 2 cents, > -Alex > > On 12/1/18, 11:30 AM, "Carlos Rovira" wrote: > > Hi Alex, I don't think that's what happen. > > My version (always considering that there's my version, your version > and > the truth): > > 1.- You make a commit that introduced IDEs break > 2.- I spend Saturday morning trying to find a way to fix that > 3.- Instead of revert your commit I make a change of the thing causing > the >
Re: +configname=flex
When you are writing code for your app, you may or may not care about code re-usability. When writing code for a framework, you must always care about reusability. Thus, every change must be explainable. It isn't good enough to make a change because it was the only way you can get something to work. In this case, the change was to the list of default SWCs. It should be possible to override all of those settings for your needs. I have offered to help and asked for useful data on at least four posts on this thread. So far, I don't have anything to work with. I'm trying to help, but it is not a good use of my time to guess what the problem test case is. We must use sound engineering principles in creating a framework because we want lots of folks to rely on it. I was amazed when Adobe shipped the first generation of AS2 components with Flash MX that some folks spent hours reading the code. We would want folks to do the same for Royale and our code must make sense. Before changing someone else's code, you should be able to explain why the code you are changing is flawed and why your change is better. We have a commits history so you can go back and see changes to help determine why things were changed. If you can't explain your changes, don't push it. If something is a mystery, create a simple test case and add complexity until it fails, or subset your complex test case until it stops failing. Also consider whether the builds are working and whether anyone else is complaining about related issues. Committers should be able to build from sources, so rollback if you are in a hurry, but don't push a change if it is just a guess. My 2 cents, -Alex On 12/1/18, 11:30 AM, "Carlos Rovira" wrote: Hi Alex, I don't think that's what happen. My version (always considering that there's my version, your version and the truth): 1.- You make a commit that introduced IDEs break 2.- I spend Saturday morning trying to find a way to fix that 3.- Instead of revert your commit I make a change of the thing causing the problem with the comment "to be reverted as we find the solution" 4.- You was upset since you consider it a revert, and I asked you to find a way a solution so we all can live in peace and armony 5.- You said me that I must to do it myself or pay someone to do it, and that Alina and others have priority over my needs 6.- Dave told us that we should work on branches, since nobody is a special case here. We are on that point where we have a branch with a first commit that is my commit reverted, in order to find the solution. Since Royale has different sets no one is more important than other. Basic, Jewel, and not Mx/Spark must coexist, and should work in conjunction. I'm using Jewel and MX for RPC part and some other classes (i.e. CurrencyFormatter, and maybe others). The changes in config files make IDEs goes crazy. So I can have a "jewel-config-template.xml", that has jewel, mx,...and other libs needed, no problem on that, but when I tried to create that, I couldn't get it work. That's point 2 in my list. For that reason maybe there's a bug and that could be done, if that's the case, I think is Alex responsibility to fix that to leverage his change, and not make me depend on my time or money to contract other people to do that. IOW, if we make a change that break something, and others complains, don't see a point to make a battle for something like that. I think is more easy to work on fix that instead of invest time in a large thread and emails. Since this Friday I release our real work Apache Royale app first iteration, I plan to work on that this week end, but finaly I must fix things on our release for Monday, so I can work on that on this on Monday or Tuesday. El jue., 29 nov. 2018 a las 10:40, Alex Harui () escribió: > As discussed I changed royale-config.xml to list all of our SWCs except > for MXRoyale and SparkRoyale, and changed flex-config.xml to use all SWCs > and have different default classes such as mx.events.MouseEvent instead of > org.apache.royale.events.MouseEvent. I think Carlos has the only project > using MXRoyale and Jewel and maybe some Basic so neither config is set up > exactly for his needs. Since all configuration is theoretically > overridable as compiler options, he should have been able to get going by > specifying what SWCs he wants to use. > > He said he wasn't able to do that, so he committed a change that went back > to using a wildcard in royale-config.xml and thus pull in all SWCs and > re-introduce the problem. That doesn't make any technical sense to me and > brought back the CSS problem that was affecting folks like you. So I asked > him to revert his wildcard change and so far, he
Re: +configname=flex
Hi Alex, I don't think that's what happen. My version (always considering that there's my version, your version and the truth): 1.- You make a commit that introduced IDEs break 2.- I spend Saturday morning trying to find a way to fix that 3.- Instead of revert your commit I make a change of the thing causing the problem with the comment "to be reverted as we find the solution" 4.- You was upset since you consider it a revert, and I asked you to find a way a solution so we all can live in peace and armony 5.- You said me that I must to do it myself or pay someone to do it, and that Alina and others have priority over my needs 6.- Dave told us that we should work on branches, since nobody is a special case here. We are on that point where we have a branch with a first commit that is my commit reverted, in order to find the solution. Since Royale has different sets no one is more important than other. Basic, Jewel, and not Mx/Spark must coexist, and should work in conjunction. I'm using Jewel and MX for RPC part and some other classes (i.e. CurrencyFormatter, and maybe others). The changes in config files make IDEs goes crazy. So I can have a "jewel-config-template.xml", that has jewel, mx,...and other libs needed, no problem on that, but when I tried to create that, I couldn't get it work. That's point 2 in my list. For that reason maybe there's a bug and that could be done, if that's the case, I think is Alex responsibility to fix that to leverage his change, and not make me depend on my time or money to contract other people to do that. IOW, if we make a change that break something, and others complains, don't see a point to make a battle for something like that. I think is more easy to work on fix that instead of invest time in a large thread and emails. Since this Friday I release our real work Apache Royale app first iteration, I plan to work on that this week end, but finaly I must fix things on our release for Monday, so I can work on that on this on Monday or Tuesday. El jue., 29 nov. 2018 a las 10:40, Alex Harui () escribió: > As discussed I changed royale-config.xml to list all of our SWCs except > for MXRoyale and SparkRoyale, and changed flex-config.xml to use all SWCs > and have different default classes such as mx.events.MouseEvent instead of > org.apache.royale.events.MouseEvent. I think Carlos has the only project > using MXRoyale and Jewel and maybe some Basic so neither config is set up > exactly for his needs. Since all configuration is theoretically > overridable as compiler options, he should have been able to get going by > specifying what SWCs he wants to use. > > He said he wasn't able to do that, so he committed a change that went back > to using a wildcard in royale-config.xml and thus pull in all SWCs and > re-introduce the problem. That doesn't make any technical sense to me and > brought back the CSS problem that was affecting folks like you. So I asked > him to revert his wildcard change and so far, he hasn't and instead he > started in on how I am seeking special treatment. > > -Alex > > On 11/28/18, 7:19 PM, "Harbs" wrote: > > I’m still not following. > > What did you change and what was the issue that Carlos hit? Am I > correct that you were fixing the problem that MXRoyale was overriding the > Basic CSS? > > What exactly was the fix and why was it causing problems? > > > On Nov 28, 2018, at 5:21 PM, Alex Harui > wrote: > > > > Carlos reverted a commit I made without technical justification and > refuses to put back my changes when I asked, instead saying I was acting > like I should have special treatment. Apparently, Carlos couldn't compile > his app even though all of our examples build just fine. I've tried to > help, but cannot get solid data from Carlos. > > > > Somehow Dave Fisher thinks is ok for Carlos to act like that. I > think it sets a dangerous precedent to have committers revert other > people's changes without technical justification, and also a bad precedent > to allow people to basically call people names when they disagree about > something. > > > > -Alex > > > > On 11/27/18, 4:52 PM, "Harbs" wrote: > > > >I have not been following the list very well the last week plus. > (I’ve been busy with some personal things.) > > > >I’m not following the issues here. What was changed, and what’s > the issue here? > > > > > > -- Carlos Rovira http://about.me/carlosrovira
Re: +configname=flex
As discussed I changed royale-config.xml to list all of our SWCs except for MXRoyale and SparkRoyale, and changed flex-config.xml to use all SWCs and have different default classes such as mx.events.MouseEvent instead of org.apache.royale.events.MouseEvent. I think Carlos has the only project using MXRoyale and Jewel and maybe some Basic so neither config is set up exactly for his needs. Since all configuration is theoretically overridable as compiler options, he should have been able to get going by specifying what SWCs he wants to use. He said he wasn't able to do that, so he committed a change that went back to using a wildcard in royale-config.xml and thus pull in all SWCs and re-introduce the problem. That doesn't make any technical sense to me and brought back the CSS problem that was affecting folks like you. So I asked him to revert his wildcard change and so far, he hasn't and instead he started in on how I am seeking special treatment. -Alex On 11/28/18, 7:19 PM, "Harbs" wrote: I’m still not following. What did you change and what was the issue that Carlos hit? Am I correct that you were fixing the problem that MXRoyale was overriding the Basic CSS? What exactly was the fix and why was it causing problems? > On Nov 28, 2018, at 5:21 PM, Alex Harui wrote: > > Carlos reverted a commit I made without technical justification and refuses to put back my changes when I asked, instead saying I was acting like I should have special treatment. Apparently, Carlos couldn't compile his app even though all of our examples build just fine. I've tried to help, but cannot get solid data from Carlos. > > Somehow Dave Fisher thinks is ok for Carlos to act like that. I think it sets a dangerous precedent to have committers revert other people's changes without technical justification, and also a bad precedent to allow people to basically call people names when they disagree about something. > > -Alex > > On 11/27/18, 4:52 PM, "Harbs" wrote: > >I have not been following the list very well the last week plus. (I’ve been busy with some personal things.) > >I’m not following the issues here. What was changed, and what’s the issue here? >
Re: +configname=flex
I’m still not following. What did you change and what was the issue that Carlos hit? Am I correct that you were fixing the problem that MXRoyale was overriding the Basic CSS? What exactly was the fix and why was it causing problems? > On Nov 28, 2018, at 5:21 PM, Alex Harui wrote: > > Carlos reverted a commit I made without technical justification and refuses > to put back my changes when I asked, instead saying I was acting like I > should have special treatment. Apparently, Carlos couldn't compile his app > even though all of our examples build just fine. I've tried to help, but > cannot get solid data from Carlos. > > Somehow Dave Fisher thinks is ok for Carlos to act like that. I think it > sets a dangerous precedent to have committers revert other people's changes > without technical justification, and also a bad precedent to allow people to > basically call people names when they disagree about something. > > -Alex > > On 11/27/18, 4:52 PM, "Harbs" wrote: > >I have not been following the list very well the last week plus. (I’ve > been busy with some personal things.) > >I’m not following the issues here. What was changed, and what’s the issue > here? >
Re: +configname=flex
Carlos reverted a commit I made without technical justification and refuses to put back my changes when I asked, instead saying I was acting like I should have special treatment. Apparently, Carlos couldn't compile his app even though all of our examples build just fine. I've tried to help, but cannot get solid data from Carlos. Somehow Dave Fisher thinks is ok for Carlos to act like that. I think it sets a dangerous precedent to have committers revert other people's changes without technical justification, and also a bad precedent to allow people to basically call people names when they disagree about something. -Alex On 11/27/18, 4:52 PM, "Harbs" wrote: I have not been following the list very well the last week plus. (I’ve been busy with some personal things.) I’m not following the issues here. What was changed, and what’s the issue here?
Re: +configname=flex
OK, I will revert your revert of my commit in the mean time. -Alex On 11/28/18, 12:09 PM, "Carlos Rovira" wrote: Hi Alex, I'm very busy finishing our app for this Friday, so I'll work on this on the weekend and come back with the results I get. Thanks! El mar., 27 nov. 2018 a las 23:09, Alex Harui () escribió: > Carlos, > > What is written below is not really useful data, just a story. It is > really hard for me to guess what is going on. You didn't indicate or show > output that proves that whatever configs you are trying to use actually got > used. Nor is there any indication that you proceeded with any suggestions > I have made so far. You could have typed something incorrectly, used the > wrong compiler option, etc. I have no idea of what errors were output for > what source. There are too many possibilities. > > I thought of another approach for you to try: Because you are not using > MXRoyale UI widgets, I think you don't want configname=flex as it will pick > defaults for Flex that you don't want, so remove that and make sure that > royale-config is being used and has the list of SWCs as I committed it, > instead of the wildcard/folder you committed. > > In theory, that royale-config should list every SWC except MXRoyale and > SparkRoyale. Instead of using a folder, you should be able to add those > two SWCs using -library-path+=/MXRoyale.swc and > -library-path+=/SparkRoyale.swc, and similarly, > -js-library-path+=/MXRoyaleJS.swc and -js-library-path+= to>/SparkRoyaleJS.swc > > IOW, since royale-config used to work for you, and the only change should > have been to unlist MXRoyale and SparkRoyale, it should be the least effort > to re-list those two SWCs. Try that, and report actual data like some > console output, and the source associated with any errors. > > -Alex > > On 11/27/18, 8:11 AM, "Carlos Rovira" wrote: > > Hi, > > just created a branch "feature//config-name-changes" that starts with > the > revert of my commit > > What I tried and didn't work is to : > > 1.- duplicate royale-config-template.xml > 2.- Add "MXRoyale.swc" to both libs list (for SWF and for JS) > 3.- Add a namespace entry for MXRoyale to namespaces > > I think that should work out of the box, but listing concrete SWCs make > IDEs fail > > thanks > > > > > El mar., 27 nov. 2018 a las 10:50, Carlos Rovira (< > carlosrov...@apache.org>) > escribió: > > > Alex, > > > > no body is making this a personal attack. Just pointing that maybe > both > > are doing things wrong. > > > > In the other hand you know that no breaking build does not mean that > we > > are not breaking things. If I remove code in some UIBase setter, I > can > > make all Royale apps fail without breaking the build right?. The > problem > > here is the same but with IDEs. > > > > We all have to accept others people warnings and problems and don't > think > > our commits are infallible. > > > > I think Dave suggestion is the way to go. We can go to a branch and > revert > > my commit so we can try how to get both things working. > > > > And again, we all know how emails works in making things removing the > > human touch, so don't think that I'm making any personal attack > since is > > not my intention. And if I do in some way, just accept my apologies > for > > that. > > > > I'll create the branch today as I have time and revert the change so > we > > can progress with this issue > > > > thanks! > > > > Carlos > > > > > > > > El mar., 27 nov. 2018 a las 8:34, Alex Harui > () > > escribió: > > > >> > >> > >> On 11/26/18, 10:42 PM, "Dave Fisher" wrote: > >> > >> (1) Maybe you should be on a branch too! > >> > >> (2) Merges happen when everyone is ready! > >> > >> Now discuss development branches > >> > >> > >> We have. We use them when we judge them necessary for big > disruptive > >> changes. I didn't and still don't think it was necessary. The > builds and > >> tests and examples passed. > >> > >> If you are supporting reverting other people's commits, personal > attacks, > >> and committing changes without justification, then I am really > surprised > >> and disappointed. I would think we would want less of that, not > more. > >> > >> My 2
Re: +configname=flex
Hi Alex, I'm very busy finishing our app for this Friday, so I'll work on this on the weekend and come back with the results I get. Thanks! El mar., 27 nov. 2018 a las 23:09, Alex Harui () escribió: > Carlos, > > What is written below is not really useful data, just a story. It is > really hard for me to guess what is going on. You didn't indicate or show > output that proves that whatever configs you are trying to use actually got > used. Nor is there any indication that you proceeded with any suggestions > I have made so far. You could have typed something incorrectly, used the > wrong compiler option, etc. I have no idea of what errors were output for > what source. There are too many possibilities. > > I thought of another approach for you to try: Because you are not using > MXRoyale UI widgets, I think you don't want configname=flex as it will pick > defaults for Flex that you don't want, so remove that and make sure that > royale-config is being used and has the list of SWCs as I committed it, > instead of the wildcard/folder you committed. > > In theory, that royale-config should list every SWC except MXRoyale and > SparkRoyale. Instead of using a folder, you should be able to add those > two SWCs using -library-path+=/MXRoyale.swc and > -library-path+=/SparkRoyale.swc, and similarly, > -js-library-path+=/MXRoyaleJS.swc and -js-library-path+= to>/SparkRoyaleJS.swc > > IOW, since royale-config used to work for you, and the only change should > have been to unlist MXRoyale and SparkRoyale, it should be the least effort > to re-list those two SWCs. Try that, and report actual data like some > console output, and the source associated with any errors. > > -Alex > > On 11/27/18, 8:11 AM, "Carlos Rovira" wrote: > > Hi, > > just created a branch "feature//config-name-changes" that starts with > the > revert of my commit > > What I tried and didn't work is to : > > 1.- duplicate royale-config-template.xml > 2.- Add "MXRoyale.swc" to both libs list (for SWF and for JS) > 3.- Add a namespace entry for MXRoyale to namespaces > > I think that should work out of the box, but listing concrete SWCs make > IDEs fail > > thanks > > > > > El mar., 27 nov. 2018 a las 10:50, Carlos Rovira (< > carlosrov...@apache.org>) > escribió: > > > Alex, > > > > no body is making this a personal attack. Just pointing that maybe > both > > are doing things wrong. > > > > In the other hand you know that no breaking build does not mean that > we > > are not breaking things. If I remove code in some UIBase setter, I > can > > make all Royale apps fail without breaking the build right?. The > problem > > here is the same but with IDEs. > > > > We all have to accept others people warnings and problems and don't > think > > our commits are infallible. > > > > I think Dave suggestion is the way to go. We can go to a branch and > revert > > my commit so we can try how to get both things working. > > > > And again, we all know how emails works in making things removing the > > human touch, so don't think that I'm making any personal attack > since is > > not my intention. And if I do in some way, just accept my apologies > for > > that. > > > > I'll create the branch today as I have time and revert the change so > we > > can progress with this issue > > > > thanks! > > > > Carlos > > > > > > > > El mar., 27 nov. 2018 a las 8:34, Alex Harui > () > > escribió: > > > >> > >> > >> On 11/26/18, 10:42 PM, "Dave Fisher" wrote: > >> > >> (1) Maybe you should be on a branch too! > >> > >> (2) Merges happen when everyone is ready! > >> > >> Now discuss development branches > >> > >> > >> We have. We use them when we judge them necessary for big > disruptive > >> changes. I didn't and still don't think it was necessary. The > builds and > >> tests and examples passed. > >> > >> If you are supporting reverting other people's commits, personal > attacks, > >> and committing changes without justification, then I am really > surprised > >> and disappointed. I would think we would want less of that, not > more. > >> > >> My 2 cents, > >> -Alex > >> > >> > >> > > > > -- > > Carlos Rovira > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosroviradata=02%7C01%7Caharui%40adobe.com%7C8426b5aa23034aafe1ad08d65482ee74%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636789318655224607sdata=lr0by7FhNCN%2FyBvvMs%2FR%2BzGNvn6634kyQMhlGqX7uxE%3Dreserved=0 > > > > > > -- > Carlos Rovira > >
Re: +configname=flex
I have not been following the list very well the last week plus. (I’ve been busy with some personal things.) I’m not following the issues here. What was changed, and what’s the issue here?
Re: +configname=flex
Carlos, What is written below is not really useful data, just a story. It is really hard for me to guess what is going on. You didn't indicate or show output that proves that whatever configs you are trying to use actually got used. Nor is there any indication that you proceeded with any suggestions I have made so far. You could have typed something incorrectly, used the wrong compiler option, etc. I have no idea of what errors were output for what source. There are too many possibilities. I thought of another approach for you to try: Because you are not using MXRoyale UI widgets, I think you don't want configname=flex as it will pick defaults for Flex that you don't want, so remove that and make sure that royale-config is being used and has the list of SWCs as I committed it, instead of the wildcard/folder you committed. In theory, that royale-config should list every SWC except MXRoyale and SparkRoyale. Instead of using a folder, you should be able to add those two SWCs using -library-path+=/MXRoyale.swc and -library-path+=/SparkRoyale.swc, and similarly, -js-library-path+=/MXRoyaleJS.swc and -js-library-path+=/SparkRoyaleJS.swc IOW, since royale-config used to work for you, and the only change should have been to unlist MXRoyale and SparkRoyale, it should be the least effort to re-list those two SWCs. Try that, and report actual data like some console output, and the source associated with any errors. -Alex On 11/27/18, 8:11 AM, "Carlos Rovira" wrote: Hi, just created a branch "feature//config-name-changes" that starts with the revert of my commit What I tried and didn't work is to : 1.- duplicate royale-config-template.xml 2.- Add "MXRoyale.swc" to both libs list (for SWF and for JS) 3.- Add a namespace entry for MXRoyale to namespaces I think that should work out of the box, but listing concrete SWCs make IDEs fail thanks El mar., 27 nov. 2018 a las 10:50, Carlos Rovira () escribió: > Alex, > > no body is making this a personal attack. Just pointing that maybe both > are doing things wrong. > > In the other hand you know that no breaking build does not mean that we > are not breaking things. If I remove code in some UIBase setter, I can > make all Royale apps fail without breaking the build right?. The problem > here is the same but with IDEs. > > We all have to accept others people warnings and problems and don't think > our commits are infallible. > > I think Dave suggestion is the way to go. We can go to a branch and revert > my commit so we can try how to get both things working. > > And again, we all know how emails works in making things removing the > human touch, so don't think that I'm making any personal attack since is > not my intention. And if I do in some way, just accept my apologies for > that. > > I'll create the branch today as I have time and revert the change so we > can progress with this issue > > thanks! > > Carlos > > > > El mar., 27 nov. 2018 a las 8:34, Alex Harui () > escribió: > >> >> >> On 11/26/18, 10:42 PM, "Dave Fisher" wrote: >> >> (1) Maybe you should be on a branch too! >> >> (2) Merges happen when everyone is ready! >> >> Now discuss development branches >> >> >> We have. We use them when we judge them necessary for big disruptive >> changes. I didn't and still don't think it was necessary. The builds and >> tests and examples passed. >> >> If you are supporting reverting other people's commits, personal attacks, >> and committing changes without justification, then I am really surprised >> and disappointed. I would think we would want less of that, not more. >> >> My 2 cents, >> -Alex >> >> >> > > -- > Carlos Rovira > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosroviradata=02%7C01%7Caharui%40adobe.com%7C8426b5aa23034aafe1ad08d65482ee74%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636789318655224607sdata=lr0by7FhNCN%2FyBvvMs%2FR%2BzGNvn6634kyQMhlGqX7uxE%3Dreserved=0 > > -- Carlos Rovira https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosroviradata=02%7C01%7Caharui%40adobe.com%7C8426b5aa23034aafe1ad08d65482ee74%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636789318655224607sdata=lr0by7FhNCN%2FyBvvMs%2FR%2BzGNvn6634kyQMhlGqX7uxE%3Dreserved=0
Re: +configname=flex
Hi, just created a branch "feature//config-name-changes" that starts with the revert of my commit What I tried and didn't work is to : 1.- duplicate royale-config-template.xml 2.- Add "MXRoyale.swc" to both libs list (for SWF and for JS) 3.- Add a namespace entry for MXRoyale to namespaces I think that should work out of the box, but listing concrete SWCs make IDEs fail thanks El mar., 27 nov. 2018 a las 10:50, Carlos Rovira () escribió: > Alex, > > no body is making this a personal attack. Just pointing that maybe both > are doing things wrong. > > In the other hand you know that no breaking build does not mean that we > are not breaking things. If I remove code in some UIBase setter, I can > make all Royale apps fail without breaking the build right?. The problem > here is the same but with IDEs. > > We all have to accept others people warnings and problems and don't think > our commits are infallible. > > I think Dave suggestion is the way to go. We can go to a branch and revert > my commit so we can try how to get both things working. > > And again, we all know how emails works in making things removing the > human touch, so don't think that I'm making any personal attack since is > not my intention. And if I do in some way, just accept my apologies for > that. > > I'll create the branch today as I have time and revert the change so we > can progress with this issue > > thanks! > > Carlos > > > > El mar., 27 nov. 2018 a las 8:34, Alex Harui () > escribió: > >> >> >> On 11/26/18, 10:42 PM, "Dave Fisher" wrote: >> >> (1) Maybe you should be on a branch too! >> >> (2) Merges happen when everyone is ready! >> >> Now discuss development branches >> >> >> We have. We use them when we judge them necessary for big disruptive >> changes. I didn't and still don't think it was necessary. The builds and >> tests and examples passed. >> >> If you are supporting reverting other people's commits, personal attacks, >> and committing changes without justification, then I am really surprised >> and disappointed. I would think we would want less of that, not more. >> >> My 2 cents, >> -Alex >> >> >> > > -- > Carlos Rovira > http://about.me/carlosrovira > > -- Carlos Rovira http://about.me/carlosrovira
Re: +configname=flex
Alex, no body is making this a personal attack. Just pointing that maybe both are doing things wrong. In the other hand you know that no breaking build does not mean that we are not breaking things. If I remove code in some UIBase setter, I can make all Royale apps fail without breaking the build right?. The problem here is the same but with IDEs. We all have to accept others people warnings and problems and don't think our commits are infallible. I think Dave suggestion is the way to go. We can go to a branch and revert my commit so we can try how to get both things working. And again, we all know how emails works in making things removing the human touch, so don't think that I'm making any personal attack since is not my intention. And if I do in some way, just accept my apologies for that. I'll create the branch today as I have time and revert the change so we can progress with this issue thanks! Carlos El mar., 27 nov. 2018 a las 8:34, Alex Harui () escribió: > > > On 11/26/18, 10:42 PM, "Dave Fisher" wrote: > > (1) Maybe you should be on a branch too! > > (2) Merges happen when everyone is ready! > > Now discuss development branches > > > We have. We use them when we judge them necessary for big disruptive > changes. I didn't and still don't think it was necessary. The builds and > tests and examples passed. > > If you are supporting reverting other people's commits, personal attacks, > and committing changes without justification, then I am really surprised > and disappointed. I would think we would want less of that, not more. > > My 2 cents, > -Alex > > > -- Carlos Rovira http://about.me/carlosrovira
Re: +configname=flex
On 11/26/18, 10:42 PM, "Dave Fisher" wrote: (1) Maybe you should be on a branch too! (2) Merges happen when everyone is ready! Now discuss development branches We have. We use them when we judge them necessary for big disruptive changes. I didn't and still don't think it was necessary. The builds and tests and examples passed. If you are supporting reverting other people's commits, personal attacks, and committing changes without justification, then I am really surprised and disappointed. I would think we would want less of that, not more. My 2 cents, -Alex
Re: +configname=flex
(1) Maybe you should be on a branch too! (2) Merges happen when everyone is ready! Now discuss development branches Regards, Dave Sent from my iPhone > On Nov 26, 2018, at 9:53 PM, Alex Harui wrote: > > Fundamentally, your problem is almost certain to be a config problem, not a > code path problem. The -config.xml files can be entirely overridden by > compiler parameters or other -config.xml files. All they do is set defaults, > and many of the settings are documented and operate the same way as they did > in Flex. > > If you revert the change you made that undid the changes I made, then we can > try to figure out why things are not working for you without impacting > others. However, I can't help much without useful data and am not motivated > to help you when you make personal attacks when asked to not revert changes > without technical justification. We want to build a framework, not a > hackwork or a guesswork. We have to be able to explain our commits. > > The techniques for generating useful data so others can try to help often > involve: > 1) creating a simple test case > 2) providing source and console output. An error message by itself is not > always helpful without knowing the source that resulted in the error and what > was going on leading up to the error. > 3) how the compiler is being launched (Ant, Maven, IDE, command-line, etc). > > -Alex > > On 11/26/18, 3:22 AM, "Carlos Rovira" wrote: > >Hi Alex, > >El lun., 26 nov. 2018 a las 1:53, Alex Harui () >escribió: > >> We (the Royale project) told Alina that we thought it was feasible to have >> her migrate her app by September. This was before you started your effort, >> and you did not ask for opinions of other PMC members before you engaged >> your client. It is now November, almost December. We are way behind >> schedule. >> > >I think you're not following my reasoning, maybe cause it doesn't like you, >but is difficult to follow a discussion if you switch completely the >subject. That is "you made a change that broke things and are asking me to >invest my time or my money to solve that". > >But ok, about this assert. first, my effort with Jewel is the requisite to >my migration, so I started long time ago before Alina appears on this list. >Many time. But I don't think that's the point, since Alina, like myself, >both and many others has the same importance to make their migration and to >work on Royale. This doesn't have anything with the current issue. I as >well tried to help Alina, in things like MX RO, and I'm paying the current >efforts to fix the actual issues, without that MX ROs are unusable. So what >said all of this about the actual problemalmost nothing...we just are >wasting resources in writing those emails, in my opinion, since the current >issue is not addressed. > > >> >> The change I made was discussed to fix a complaint by others. > > >Ok, are you saying that only others complains are valid (people pursuing >MX/SPARK), and my complain of your changes breaking things and not (since >I'm using only a subset of MX and the new JEWEL lib) ? >IMHO, wanting to help on fixing that or at least give guidance on how to >solve it are the way to go. > > >> You are reverting that fix, returning others to a problem. > > >I'm making a change in a commit marked to be reverted in the comment (so >temporal), so we can continue working and requesting a better solution. >You ask for the same to many of us, why we can ask you the same? > > >> What technical flaw do you find in the changes I made? > > >I spend Saturday morning trying to add to Royale-config file MXRoyale.swc >for SWF and JS and namespace. This doesn't work. >So I'm asking you, why not? if you know how to do it, why don't provide and >example? With that I can create a "jewel-config" file that has Jewel and MX >for example, so we all have what we want. > > >> Just because something isn't working for you in an un-explained way >> doesn't mean that you can go break others just to fix your problem. > > >But I explained why is not working several times now right? don't say the >change is not valid, just say that is breaking IDEs and you should listen >and try to help instead of not recognizing the problem. > > >> I am not making changes for myself, I am making changes for others. Can >> you make the same claim? >> > >Sure. My changes although are for me, are as well for many others. And very >needed. >Just the latest things I did or payed for if you're not aware: > >* Fixing debugger so we can debug MXML (done by Josh) >* Debugging code in other libraries of a project far beyond app project >with source maps (done by Josh) >* Fix MX RemoteObject to transfer complex graphs to and from royale (done >by Greg) >* Fix MX RemoteObject to use
Re: +configname=flex
Fundamentally, your problem is almost certain to be a config problem, not a code path problem. The -config.xml files can be entirely overridden by compiler parameters or other -config.xml files. All they do is set defaults, and many of the settings are documented and operate the same way as they did in Flex. If you revert the change you made that undid the changes I made, then we can try to figure out why things are not working for you without impacting others. However, I can't help much without useful data and am not motivated to help you when you make personal attacks when asked to not revert changes without technical justification. We want to build a framework, not a hackwork or a guesswork. We have to be able to explain our commits. The techniques for generating useful data so others can try to help often involve: 1) creating a simple test case 2) providing source and console output. An error message by itself is not always helpful without knowing the source that resulted in the error and what was going on leading up to the error. 3) how the compiler is being launched (Ant, Maven, IDE, command-line, etc). -Alex On 11/26/18, 3:22 AM, "Carlos Rovira" wrote: Hi Alex, El lun., 26 nov. 2018 a las 1:53, Alex Harui () escribió: > We (the Royale project) told Alina that we thought it was feasible to have > her migrate her app by September. This was before you started your effort, > and you did not ask for opinions of other PMC members before you engaged > your client. It is now November, almost December. We are way behind > schedule. > I think you're not following my reasoning, maybe cause it doesn't like you, but is difficult to follow a discussion if you switch completely the subject. That is "you made a change that broke things and are asking me to invest my time or my money to solve that". But ok, about this assert. first, my effort with Jewel is the requisite to my migration, so I started long time ago before Alina appears on this list. Many time. But I don't think that's the point, since Alina, like myself, both and many others has the same importance to make their migration and to work on Royale. This doesn't have anything with the current issue. I as well tried to help Alina, in things like MX RO, and I'm paying the current efforts to fix the actual issues, without that MX ROs are unusable. So what said all of this about the actual problemalmost nothing...we just are wasting resources in writing those emails, in my opinion, since the current issue is not addressed. > > The change I made was discussed to fix a complaint by others. Ok, are you saying that only others complains are valid (people pursuing MX/SPARK), and my complain of your changes breaking things and not (since I'm using only a subset of MX and the new JEWEL lib) ? IMHO, wanting to help on fixing that or at least give guidance on how to solve it are the way to go. > You are reverting that fix, returning others to a problem. I'm making a change in a commit marked to be reverted in the comment (so temporal), so we can continue working and requesting a better solution. You ask for the same to many of us, why we can ask you the same? > What technical flaw do you find in the changes I made? I spend Saturday morning trying to add to Royale-config file MXRoyale.swc for SWF and JS and namespace. This doesn't work. So I'm asking you, why not? if you know how to do it, why don't provide and example? With that I can create a "jewel-config" file that has Jewel and MX for example, so we all have what we want. > Just because something isn't working for you in an un-explained way > doesn't mean that you can go break others just to fix your problem. But I explained why is not working several times now right? don't say the change is not valid, just say that is breaking IDEs and you should listen and try to help instead of not recognizing the problem. > I am not making changes for myself, I am making changes for others. Can > you make the same claim? > Sure. My changes although are for me, are as well for many others. And very needed. Just the latest things I did or payed for if you're not aware: * Fixing debugger so we can debug MXML (done by Josh) * Debugging code in other libraries of a project far beyond app project with source maps (done by Josh) * Fix MX RemoteObject to transfer complex graphs to and from royale (done by Greg) * Fix MX RemoteObject to use ArrayCollections (done by Greg) * Fix for MX Producer and Consumer classes (done by Greg, currently in WIP but near completion) * Fix for MX CurrencyFormatter (done by me) Other things like my
Re: +configname=flex
Hi Alex, El lun., 26 nov. 2018 a las 1:53, Alex Harui () escribió: > We (the Royale project) told Alina that we thought it was feasible to have > her migrate her app by September. This was before you started your effort, > and you did not ask for opinions of other PMC members before you engaged > your client. It is now November, almost December. We are way behind > schedule. > I think you're not following my reasoning, maybe cause it doesn't like you, but is difficult to follow a discussion if you switch completely the subject. That is "you made a change that broke things and are asking me to invest my time or my money to solve that". But ok, about this assert. first, my effort with Jewel is the requisite to my migration, so I started long time ago before Alina appears on this list. Many time. But I don't think that's the point, since Alina, like myself, both and many others has the same importance to make their migration and to work on Royale. This doesn't have anything with the current issue. I as well tried to help Alina, in things like MX RO, and I'm paying the current efforts to fix the actual issues, without that MX ROs are unusable. So what said all of this about the actual problemalmost nothing...we just are wasting resources in writing those emails, in my opinion, since the current issue is not addressed. > > The change I made was discussed to fix a complaint by others. Ok, are you saying that only others complains are valid (people pursuing MX/SPARK), and my complain of your changes breaking things and not (since I'm using only a subset of MX and the new JEWEL lib) ? IMHO, wanting to help on fixing that or at least give guidance on how to solve it are the way to go. > You are reverting that fix, returning others to a problem. I'm making a change in a commit marked to be reverted in the comment (so temporal), so we can continue working and requesting a better solution. You ask for the same to many of us, why we can ask you the same? > What technical flaw do you find in the changes I made? I spend Saturday morning trying to add to Royale-config file MXRoyale.swc for SWF and JS and namespace. This doesn't work. So I'm asking you, why not? if you know how to do it, why don't provide and example? With that I can create a "jewel-config" file that has Jewel and MX for example, so we all have what we want. > Just because something isn't working for you in an un-explained way > doesn't mean that you can go break others just to fix your problem. But I explained why is not working several times now right? don't say the change is not valid, just say that is breaking IDEs and you should listen and try to help instead of not recognizing the problem. > I am not making changes for myself, I am making changes for others. Can > you make the same claim? > Sure. My changes although are for me, are as well for many others. And very needed. Just the latest things I did or payed for if you're not aware: * Fixing debugger so we can debug MXML (done by Josh) * Debugging code in other libraries of a project far beyond app project with source maps (done by Josh) * Fix MX RemoteObject to transfer complex graphs to and from royale (done by Greg) * Fix MX RemoteObject to use ArrayCollections (done by Greg) * Fix for MX Producer and Consumer classes (done by Greg, currently in WIP but near completion) * Fix for MX CurrencyFormatter (done by me) Other things like my investment in provide a new UI set that works completely and have a nice UI and responsive capabilities is already known. Those points are main ones, but there's so much more on the works on fixing things here and there. Can we concentrate in see how to solve the problem instead of trying to validate our positions? Thanks in advance for your help on this Carlos > > -Alex > > On 11/25/18, 3:49 PM, "Carlos Rovira" wrote: > > Alex, > > "you shouldn't make everyone else pay a price to save you time" > > For me this seems what you did, why don't put yourself in the skin of > others? > > "You didn't need to make that change in the repo, you could have > worked off > a branch" > > Saying that Is again the same, if you break a think but you think you > must > break that in pro of what you're pursuing, why you ask others to make a > branch? is more special the change you want to make than the changes of > others? > > Apache way is where all are equals, and try to pursue a common > objetive, > but in this case, don't know others, but I clearly don't know what you > want > to do, but are you asking me to fix that or spend money paying others > to do > something I still don't know the objective. > > Simply don't understand that position. > > I have a clearly dead line this Friday to show a client our progress > in our > Apache Royale real application. Do you have some dead line as well > that I'm > not aware that explain to be so inflexible with this issue? I mean
Re: +configname=flex
We (the Royale project) told Alina that we thought it was feasible to have her migrate her app by September. This was before you started your effort, and you did not ask for opinions of other PMC members before you engaged your client. It is now November, almost December. We are way behind schedule. The change I made was discussed to fix a complaint by others. You are reverting that fix, returning others to a problem. What technical flaw do you find in the changes I made? Just because something isn't working for you in an un-explained way doesn't mean that you can go break others just to fix your problem. I am not making changes for myself, I am making changes for others. Can you make the same claim? -Alex On 11/25/18, 3:49 PM, "Carlos Rovira" wrote: Alex, "you shouldn't make everyone else pay a price to save you time" For me this seems what you did, why don't put yourself in the skin of others? "You didn't need to make that change in the repo, you could have worked off a branch" Saying that Is again the same, if you break a think but you think you must break that in pro of what you're pursuing, why you ask others to make a branch? is more special the change you want to make than the changes of others? Apache way is where all are equals, and try to pursue a common objetive, but in this case, don't know others, but I clearly don't know what you want to do, but are you asking me to fix that or spend money paying others to do something I still don't know the objective. Simply don't understand that position. I have a clearly dead line this Friday to show a client our progress in our Apache Royale real application. Do you have some dead line as well that I'm not aware that explain to be so inflexible with this issue? I mean in order to try to understand you position. El lun., 26 nov. 2018 a las 0:36, Carlos Rovira () escribió: > Hi Alex, > > don't think that's a good attitude. I'm just trying to solve a thing > broken in the repo, and proposing a change. You essentially did a change > that break things, and you're not taking care of the side effects of doing > that. I'm already paying other people to fix things, but I don't think I > have pay someone to fix something you broke. When I break thinks I use to > try to help as much as I can, remember when I change many files and people > report breaking things, I was some days helping and spending hours to fix > things for others, since I considere I'm responsible of my changes. I'm now > trying to fix a things you break, and made a change that solves it. You > think is not ok, but I don't know what's your goal, and why you did that > change, but you're asking me to spend hours in deal with a change you did. > Simply don't understand that position. > > Remember that I said in my previous email that I already spend yesterday > complete morning to deal with you change, I can't get nothing that solve. > You know what try to do, why don't you take care of my suggestion and help > to create a config file that addresses the problem so you and I can > continue out work? > > > > > > El dom., 25 nov. 2018 a las 23:28, Alex Harui () > escribió: > >> By putting all SWCs back in the library-path in royale-config, you have >> re-introduced a problem I was fixing. You can say you didn't revert the >> actual git commit, but your changes essentially undid my commit. The build >> passed with my commit, as far as I can tell. IF we all start reverting >> stuff we don't like, we'll just end up in a revert war. We are all in a >> time-crunch, not just you. This is cutting-edge development. Things may >> get in your way some times, but you shouldn't make everyone else pay a >> price to save you time. You didn't need to make that change in the repo, >> you could have worked off a branch. If you run into a bug, you'll have to >> take the time to investigate or hire someone to do it if none of the other >> volunteers happen to have time. >> >> My 2 cents, >> -Alex >> >> On 11/25/18, 1:56 AM, "Carlos Rovira" wrote: >> >> Hi Alex, >> >> El dom., 25 nov. 2018 a las 8:34, Alex Harui >> () >> escribió: >> >> > Does configname make any difference in your IDE? Maybe the IDE >> doesn't >> > support it. The compiler output should switch to saying it is >> loading >> > flex-config instead of royale-config. >> > >> > >> I think there's tow ways, one using addtiionalCompiler options like I >> show. >> Another from the AS3 extension is "config: royale" or "config: >> flex" >> (values can be as well "air", and others)
Re: +configname=flex
Alex, "you shouldn't make everyone else pay a price to save you time" For me this seems what you did, why don't put yourself in the skin of others? "You didn't need to make that change in the repo, you could have worked off a branch" Saying that Is again the same, if you break a think but you think you must break that in pro of what you're pursuing, why you ask others to make a branch? is more special the change you want to make than the changes of others? Apache way is where all are equals, and try to pursue a common objetive, but in this case, don't know others, but I clearly don't know what you want to do, but are you asking me to fix that or spend money paying others to do something I still don't know the objective. Simply don't understand that position. I have a clearly dead line this Friday to show a client our progress in our Apache Royale real application. Do you have some dead line as well that I'm not aware that explain to be so inflexible with this issue? I mean in order to try to understand you position. El lun., 26 nov. 2018 a las 0:36, Carlos Rovira () escribió: > Hi Alex, > > don't think that's a good attitude. I'm just trying to solve a thing > broken in the repo, and proposing a change. You essentially did a change > that break things, and you're not taking care of the side effects of doing > that. I'm already paying other people to fix things, but I don't think I > have pay someone to fix something you broke. When I break thinks I use to > try to help as much as I can, remember when I change many files and people > report breaking things, I was some days helping and spending hours to fix > things for others, since I considere I'm responsible of my changes. I'm now > trying to fix a things you break, and made a change that solves it. You > think is not ok, but I don't know what's your goal, and why you did that > change, but you're asking me to spend hours in deal with a change you did. > Simply don't understand that position. > > Remember that I said in my previous email that I already spend yesterday > complete morning to deal with you change, I can't get nothing that solve. > You know what try to do, why don't you take care of my suggestion and help > to create a config file that addresses the problem so you and I can > continue out work? > > > > > > El dom., 25 nov. 2018 a las 23:28, Alex Harui () > escribió: > >> By putting all SWCs back in the library-path in royale-config, you have >> re-introduced a problem I was fixing. You can say you didn't revert the >> actual git commit, but your changes essentially undid my commit. The build >> passed with my commit, as far as I can tell. IF we all start reverting >> stuff we don't like, we'll just end up in a revert war. We are all in a >> time-crunch, not just you. This is cutting-edge development. Things may >> get in your way some times, but you shouldn't make everyone else pay a >> price to save you time. You didn't need to make that change in the repo, >> you could have worked off a branch. If you run into a bug, you'll have to >> take the time to investigate or hire someone to do it if none of the other >> volunteers happen to have time. >> >> My 2 cents, >> -Alex >> >> On 11/25/18, 1:56 AM, "Carlos Rovira" wrote: >> >> Hi Alex, >> >> El dom., 25 nov. 2018 a las 8:34, Alex Harui >> () >> escribió: >> >> > Does configname make any difference in your IDE? Maybe the IDE >> doesn't >> > support it. The compiler output should switch to saying it is >> loading >> > flex-config instead of royale-config. >> > >> > >> I think there's tow ways, one using addtiionalCompiler options like I >> show. >> Another from the AS3 extension is "config: royale" or "config: >> flex" >> (values can be as well "air", and others) >> >> >> > The change you made to royale-config-template re-introduces the >> problem I >> > was trying to fix. IMO, you should make a local change in a branch >> instead >> > of reverting my commits. >> > >> >> I didn't revert your commit, just do a new one to be reverted, since >> it >> seems to be something goes wrong with the changes. For your words I >> understand there's no bugs or things to take care to solve this? >> >> >> > I recommend that you compare the set of manifests loaded by >> flex-config vs >> > royale-config. It looks like some are missing. And you are >> welcome to >> > make another config.xml for your combination. The problem with >> having >> > "everything" in a -config.xml is that it can add too many options to >> > code-hinting. >> > >> >> Ok, the problem is that I spend yesterday morning trying to see >> something >> similar but only the actual patch worked. >> I tried to add to royale config the MXRoyale.swc for SWF and JS and >> namespace, but that didn't make a difference. Do you know what's the >> problem starting from that point? or if the approach is not
Re: +configname=flex
Hi Alex, don't think that's a good attitude. I'm just trying to solve a thing broken in the repo, and proposing a change. You essentially did a change that break things, and you're not taking care of the side effects of doing that. I'm already paying other people to fix things, but I don't think I have pay someone to fix something you broke. When I break thinks I use to try to help as much as I can, remember when I change many files and people report breaking things, I was some days helping and spending hours to fix things for others, since I considere I'm responsible of my changes. I'm now trying to fix a things you break, and made a change that solves it. You think is not ok, but I don't know what's your goal, and why you did that change, but you're asking me to spend hours in deal with a change you did. Simply don't understand that position. Remember that I said in my previous email that I already spend yesterday complete morning to deal with you change, I can't get nothing that solve. You know what try to do, why don't you take care of my suggestion and help to create a config file that addresses the problem so you and I can continue out work? El dom., 25 nov. 2018 a las 23:28, Alex Harui () escribió: > By putting all SWCs back in the library-path in royale-config, you have > re-introduced a problem I was fixing. You can say you didn't revert the > actual git commit, but your changes essentially undid my commit. The build > passed with my commit, as far as I can tell. IF we all start reverting > stuff we don't like, we'll just end up in a revert war. We are all in a > time-crunch, not just you. This is cutting-edge development. Things may > get in your way some times, but you shouldn't make everyone else pay a > price to save you time. You didn't need to make that change in the repo, > you could have worked off a branch. If you run into a bug, you'll have to > take the time to investigate or hire someone to do it if none of the other > volunteers happen to have time. > > My 2 cents, > -Alex > > On 11/25/18, 1:56 AM, "Carlos Rovira" wrote: > > Hi Alex, > > El dom., 25 nov. 2018 a las 8:34, Alex Harui ( >) > escribió: > > > Does configname make any difference in your IDE? Maybe the IDE > doesn't > > support it. The compiler output should switch to saying it is > loading > > flex-config instead of royale-config. > > > > > I think there's tow ways, one using addtiionalCompiler options like I > show. > Another from the AS3 extension is "config: royale" or "config: > flex" > (values can be as well "air", and others) > > > > The change you made to royale-config-template re-introduces the > problem I > > was trying to fix. IMO, you should make a local change in a branch > instead > > of reverting my commits. > > > > I didn't revert your commit, just do a new one to be reverted, since > it > seems to be something goes wrong with the changes. For your words I > understand there's no bugs or things to take care to solve this? > > > > I recommend that you compare the set of manifests loaded by > flex-config vs > > royale-config. It looks like some are missing. And you are welcome > to > > make another config.xml for your combination. The problem with > having > > "everything" in a -config.xml is that it can add too many options to > > code-hinting. > > > > Ok, the problem is that I spend yesterday morning trying to see > something > similar but only the actual patch worked. > I tried to add to royale config the MXRoyale.swc for SWF and JS and > namespace, but that didn't make a difference. Do you know what's the > problem starting from that point? or if the approach is not that? > > I think I can create one for Jewel applications, and remove from that > sets > that are just experiments but not usable like createjs, flat, express > More over, could revert my change and create a > "jewel-config-template.xml" > to test that is possible? I was not able to do it yesterday so maybe > there's a problem and is not possible right now > > I'll be out until today until night, and will catch up if you commit > something to try it. I understand that would be using addtionalcompiler > options path with +configname > > Another thing that could be good is the one you already commented about > separate MXRoyale in MX Rpc, Formatters, and more, to help in this way > to > code intelligence in IDEs to have only the right libraries the users is > using > > Thanks > > Carlos > > > > > > > HTH, > > -Alex > > > > > > On 11/24/18, 7:04 AM, "Carlos Rovira" > wrote: > > > > Hi, > > > > after doing full rebuild I'm finding a problem in IDE (not in > build) > > with > > the new change +configname=flex > > > > - we are using Jewel and MXRoyale, just por MX RPC (and maybe > some
Re: +configname=flex
By putting all SWCs back in the library-path in royale-config, you have re-introduced a problem I was fixing. You can say you didn't revert the actual git commit, but your changes essentially undid my commit. The build passed with my commit, as far as I can tell. IF we all start reverting stuff we don't like, we'll just end up in a revert war. We are all in a time-crunch, not just you. This is cutting-edge development. Things may get in your way some times, but you shouldn't make everyone else pay a price to save you time. You didn't need to make that change in the repo, you could have worked off a branch. If you run into a bug, you'll have to take the time to investigate or hire someone to do it if none of the other volunteers happen to have time. My 2 cents, -Alex On 11/25/18, 1:56 AM, "Carlos Rovira" wrote: Hi Alex, El dom., 25 nov. 2018 a las 8:34, Alex Harui () escribió: > Does configname make any difference in your IDE? Maybe the IDE doesn't > support it. The compiler output should switch to saying it is loading > flex-config instead of royale-config. > > I think there's tow ways, one using addtiionalCompiler options like I show. Another from the AS3 extension is "config: royale" or "config: flex" (values can be as well "air", and others) > The change you made to royale-config-template re-introduces the problem I > was trying to fix. IMO, you should make a local change in a branch instead > of reverting my commits. > I didn't revert your commit, just do a new one to be reverted, since it seems to be something goes wrong with the changes. For your words I understand there's no bugs or things to take care to solve this? > I recommend that you compare the set of manifests loaded by flex-config vs > royale-config. It looks like some are missing. And you are welcome to > make another config.xml for your combination. The problem with having > "everything" in a -config.xml is that it can add too many options to > code-hinting. > Ok, the problem is that I spend yesterday morning trying to see something similar but only the actual patch worked. I tried to add to royale config the MXRoyale.swc for SWF and JS and namespace, but that didn't make a difference. Do you know what's the problem starting from that point? or if the approach is not that? I think I can create one for Jewel applications, and remove from that sets that are just experiments but not usable like createjs, flat, express More over, could revert my change and create a "jewel-config-template.xml" to test that is possible? I was not able to do it yesterday so maybe there's a problem and is not possible right now I'll be out until today until night, and will catch up if you commit something to try it. I understand that would be using addtionalcompiler options path with +configname Another thing that could be good is the one you already commented about separate MXRoyale in MX Rpc, Formatters, and more, to help in this way to code intelligence in IDEs to have only the right libraries the users is using Thanks Carlos > > HTH, > -Alex > > > On 11/24/18, 7:04 AM, "Carlos Rovira" wrote: > > Hi, > > after doing full rebuild I'm finding a problem in IDE (not in build) > with > the new change +configname=flex > > - we are using Jewel and MXRoyale, just por MX RPC (and maybe some > other > class in MX). > - we are using several libraries and one application > > today I found that all MX code throws error in VS Code and is not > recognize. I see the change about configname. To adapt our config > project > to this, I added to each asconfig file in all royale libs and app in > our > project the line > > "additionalOptions": "+configname=flex" > > but this doesn't solves the problem > > in fact I'm seeing more problems like > > In initializer for 'j:icon', type org.apache.royale.icons.FontIcon is > not > assignable to target type 'org.apache.royale.core.IIcon'. > Implicit coercion of a value with static type MouseEvent to a possibly > unrelated type MouseEvent. > In initializer for 'j:previousButton', type > org.apache.royale.jewel.Group > is not assignable to target type 'org.apache.royale.core.UIBase'. > Ambiguous reference to MouseEvent > > and many more > > This makes hundreds of errors and makes the IDE unusable. I suppose > that > this change not block people waning to use a mix of libraries, and is > just > a matter to know how to update configuration, right? I mean if someone > wants
Re: +configname=flex
Hi Alex, El dom., 25 nov. 2018 a las 8:34, Alex Harui () escribió: > Does configname make any difference in your IDE? Maybe the IDE doesn't > support it. The compiler output should switch to saying it is loading > flex-config instead of royale-config. > > I think there's tow ways, one using addtiionalCompiler options like I show. Another from the AS3 extension is "config: royale" or "config: flex" (values can be as well "air", and others) > The change you made to royale-config-template re-introduces the problem I > was trying to fix. IMO, you should make a local change in a branch instead > of reverting my commits. > I didn't revert your commit, just do a new one to be reverted, since it seems to be something goes wrong with the changes. For your words I understand there's no bugs or things to take care to solve this? > I recommend that you compare the set of manifests loaded by flex-config vs > royale-config. It looks like some are missing. And you are welcome to > make another config.xml for your combination. The problem with having > "everything" in a -config.xml is that it can add too many options to > code-hinting. > Ok, the problem is that I spend yesterday morning trying to see something similar but only the actual patch worked. I tried to add to royale config the MXRoyale.swc for SWF and JS and namespace, but that didn't make a difference. Do you know what's the problem starting from that point? or if the approach is not that? I think I can create one for Jewel applications, and remove from that sets that are just experiments but not usable like createjs, flat, express More over, could revert my change and create a "jewel-config-template.xml" to test that is possible? I was not able to do it yesterday so maybe there's a problem and is not possible right now I'll be out until today until night, and will catch up if you commit something to try it. I understand that would be using addtionalcompiler options path with +configname Another thing that could be good is the one you already commented about separate MXRoyale in MX Rpc, Formatters, and more, to help in this way to code intelligence in IDEs to have only the right libraries the users is using Thanks Carlos > > HTH, > -Alex > > > On 11/24/18, 7:04 AM, "Carlos Rovira" wrote: > > Hi, > > after doing full rebuild I'm finding a problem in IDE (not in build) > with > the new change +configname=flex > > - we are using Jewel and MXRoyale, just por MX RPC (and maybe some > other > class in MX). > - we are using several libraries and one application > > today I found that all MX code throws error in VS Code and is not > recognize. I see the change about configname. To adapt our config > project > to this, I added to each asconfig file in all royale libs and app in > our > project the line > > "additionalOptions": "+configname=flex" > > but this doesn't solves the problem > > in fact I'm seeing more problems like > > In initializer for 'j:icon', type org.apache.royale.icons.FontIcon is > not > assignable to target type 'org.apache.royale.core.IIcon'. > Implicit coercion of a value with static type MouseEvent to a possibly > unrelated type MouseEvent. > In initializer for 'j:previousButton', type > org.apache.royale.jewel.Group > is not assignable to target type 'org.apache.royale.core.UIBase'. > Ambiguous reference to MouseEvent > > and many more > > This makes hundreds of errors and makes the IDE unusable. I suppose > that > this change not block people waning to use a mix of libraries, and is > just > a matter to know how to update configuration, right? I mean if someone > wants to use in the same application three different buttons( jewel, > basic, > and mx/spark), that should still be possible right? > > What should I do in my project configuration to solve this problem? > > thanks > > -- > Carlos Rovira > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosroviradata=02%7C01%7Caharui%40adobe.com%7C5d438916f4464d7083ff08d6521e31f9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636786686970715715sdata=PW5OQu%2FUTUsv9SCa31O5X4aSBq%2FS3K6fwg2XdkGKkjI%3Dreserved=0 > > > -- Carlos Rovira http://about.me/carlosrovira
Re: +configname=flex
Does configname make any difference in your IDE? Maybe the IDE doesn't support it. The compiler output should switch to saying it is loading flex-config instead of royale-config. The change you made to royale-config-template re-introduces the problem I was trying to fix. IMO, you should make a local change in a branch instead of reverting my commits. I recommend that you compare the set of manifests loaded by flex-config vs royale-config. It looks like some are missing. And you are welcome to make another config.xml for your combination. The problem with having "everything" in a -config.xml is that it can add too many options to code-hinting. HTH, -Alex On 11/24/18, 7:04 AM, "Carlos Rovira" wrote: Hi, after doing full rebuild I'm finding a problem in IDE (not in build) with the new change +configname=flex - we are using Jewel and MXRoyale, just por MX RPC (and maybe some other class in MX). - we are using several libraries and one application today I found that all MX code throws error in VS Code and is not recognize. I see the change about configname. To adapt our config project to this, I added to each asconfig file in all royale libs and app in our project the line "additionalOptions": "+configname=flex" but this doesn't solves the problem in fact I'm seeing more problems like In initializer for 'j:icon', type org.apache.royale.icons.FontIcon is not assignable to target type 'org.apache.royale.core.IIcon'. Implicit coercion of a value with static type MouseEvent to a possibly unrelated type MouseEvent. In initializer for 'j:previousButton', type org.apache.royale.jewel.Group is not assignable to target type 'org.apache.royale.core.UIBase'. Ambiguous reference to MouseEvent and many more This makes hundreds of errors and makes the IDE unusable. I suppose that this change not block people waning to use a mix of libraries, and is just a matter to know how to update configuration, right? I mean if someone wants to use in the same application three different buttons( jewel, basic, and mx/spark), that should still be possible right? What should I do in my project configuration to solve this problem? thanks -- Carlos Rovira https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosroviradata=02%7C01%7Caharui%40adobe.com%7C5d438916f4464d7083ff08d6521e31f9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636786686970715715sdata=PW5OQu%2FUTUsv9SCa31O5X4aSBq%2FS3K6fwg2XdkGKkjI%3Dreserved=0
