Re: this in closures

Harbs, does this warning show for both swf and js? I think that stuff is only for js. On Wed, Dec 4, 2019 at 8:41 PM Harbs wrote: > What about adding it to JSRoyaleEmitterTokens — similar to > @royalesuppresspublicvarwarning? > > > > On Dec 4, 2019, at 1:29 AM, Josh Tynjala > wrote: > > > >

Re: this in closures

What about adding it to JSRoyaleEmitterTokens — similar to @royalesuppresspublicvarwarning? > On Dec 4, 2019, at 1:29 AM, Josh Tynjala wrote: > > It's not possible at this time. > > Java has an annotation for suppressing warnings locally: > > @SuppressWarnings({"unchecked", "deprecated"}) >

Build failed in Jenkins: royale-compiler-integration-tests #176

See Changes: -- [...truncated 124.96 KB...] [junit] scanning for overrides: IFlexInfo [junit] scanning for overrides:

Build failed in Jenkins: royale-compiler-integration-tests #175

See Changes: -- [...truncated 122.62 KB...] [junit] scanning for overrides: ISelectionModel [junit] scanning for overrides:

Build failed in Jenkins: royale-compiler-integration-tests #174

See Changes: [greg.dove] bugfix: support variable definition with assignment via indexed access -- [...truncated 125.30

Jenkins build is back to normal : royale-asjs #303

See

Re: this in closures

It's not possible at this time. Java has an annotation for suppressing warnings locally: @SuppressWarnings({"unchecked", "deprecated"}) More info: https://www.baeldung.com/java-suppresswarnings It might be interesting to allow something similar in AS3:

Jenkins build is back to normal : royale-asjs_jsonly #323

See

Build failed in Jenkins: royale-asjs_jsonly #322

See Changes: [aharui] show close button. Needs CSS to position correctly [aharui] handle 0 length collections better. Should fix #601 [greg.dove] new test for arraylike access

Build failed in Jenkins: royale-asjs #302

See Changes: [greg.dove] bugfix: Make sure that HTTPService does not cache the decoded json from [aharui] show close button. Needs CSS to position correctly [aharui] handle 0 length

Re: Trying to simplify project to just one repository

From a release standpoint I'm concerned about the scalability of a single monolithic release. I would rather we head towards smaller subset releases. Even the Ant release we do now is cumbersome. But from a "get the code and build it" standpoint, a top-level repo that simplifies Maven

Re: Trying to simplify project to just one repository

Hi, @Harbs you are right. the proposal is not disruptive, tries to streamline what we have. After reading the responses it seems my explanation could be bad, since all seems to be misunderstood. Will try to elaborate more soon :) El mar., 3 dic. 2019 a las 19:43, Harbs () escribió: > OK. So

Re: Trying to simplify project to just one repository

OK. So it shouldn’t be disruptive to an existing workflow which uses the three separate repos. I don’t see a downside if it’s helpful for Maven. Harbs > On Dec 3, 2019, at 8:39 PM, Greg Dove wrote: > > " maybe an additional repo can be setup which includes the existing ones as > submodules "

Re: [royale-compiler] branch develop updated: should we add these generated files? (if not please remove)

Hi Josh, I think if after next build someone notice this files changed we can commit that new versions as I assume is ok to do that. thanks El mar., 3 dic. 2019 a las 18:38, Josh Tynjala () escribió: > I don't know why the Maven build would be modifying those two files. When > you committed the

Re: Trying to simplify project to just one repository

" maybe an additional repo can be setup which includes the existing ones as submodules " that is what I interpreted the proposal to be. The advantage for maven is the possibility to do the same as 'ant all' by using the 'shell' repo. On Wed, Dec 4, 2019 at 7:33 AM Harbs wrote: > Submodules

Re: Trying to simplify project to just one repository

Submodules doesn’t seem to have a good name: https://medium.com/@porteneuve/mastering-git-submodules-34c65e940407 I don’t really see a need to use submodules if we’re compiling with ant (or likely other tools). I don’t know

Re: Trying to simplify project to just one repository

I didn't know about "git submodules" and didn't see it referenced in the proposal. I saw "one repository" in the subject. That sounds disruptive and I am concerned about scaling. I read a quick intro on "git submodules" and it sounds like we could add another repository as you propose. That

Re: this in closures

What about locally? > On Dec 3, 2019, at 7:39 PM, Josh Tynjala wrote: > > You can turn it off with the following compiler option: > -warn-this-within-closure=false > > -- > Josh Tynjala > Bowler Hat LLC > > > On Tue, Dec 3, 2019 at 9:36 AM Harbs wrote: > >> I

Re: Trying to simplify project to just one repository

' IMO, it sounds very disruptive to try to collapse 3 repos into 1. ' I did not interpret it that way, at least not for now anyway. It sounds like just making a 'light' repo that has the existing repos as git submodules. That to me actually sounds like an easy way to handle more (than 3) repos

Re: this in closures

You can turn it off with the following compiler option: -warn-this-within-closure=false -- Josh Tynjala Bowler Hat LLC On Tue, Dec 3, 2019 at 9:36 AM Harbs wrote: > I recently started getting some of these warnings: > > Warning: Encountered this keyword within closure.

Re: [royale-compiler] branch develop updated: should we add these generated files? (if not please remove)

I don't know why the Maven build would be modifying those two files. When you committed the modifications, the contents of the files were not changed. The only change was to the file permissions to make them executable:

this in closures

I recently started getting some of these warnings: Warning: Encountered this keyword within closure. Value of this will not be the same as enclosing scope. I understand the desire to have this warning, but I think it either needs to be smarter or be easily turned off. I have a case where I

Re: Trying to simplify project to just one repository

IMO, it sounds very disruptive to try to collapse 3 repos into 1. Honestly, I'd rather we make sure our processes can handle more than 3 repos someday. If the project grows, we may want to release things on different schedules. IOW, I think we should be thinking about more smaller releases

Re: [royale-compiler] branch develop updated: should we add these generated files? (if not please remove)

Hi ok. So what I don't understand is what each time I build from scratch the build indicates that 2 files are modified. Should I commit the modifications? and if you created it, is right that the build is updating those 2 files? thanks! El mar., 3 dic. 2019 a las 16:53, Josh Tynjala () escribió:

Re: [royale-compiler] branch develop updated: should we add these generated files? (if not please remove)

Hi Carlos, I think that you are confused because you believe that these files are generated, but they are not generated. About two weeks ago, I personally created these files in my own text editor. Here's my original commit where I added them to the repository:

Jenkins build is back to normal : royale-asjs_jsonly #319

See

Trying to simplify project to just one repository

Hi, this days I stop my CI work due to some things. I was doing at the same time needed work for a client in implementing Jewel DataGrid and ButtonBar. I'm progressing in those components and hope to contribute soon as they are ok in API terms and looking good. Btw, Chris Dutz was helping me on

Re: [royale-compiler] branch develop updated: should we add these generated files? (if not please remove)

Hi Josh, just put them back. I'm a bit confused with this files, since we should not have generated files. But as well I can't add it to .gitignore list. What should we do with those? thanks El lun., 2 dic. 2019 a las 16:36, Josh Tynjala () escribió: > These files are not actually generated.

Build failed in Jenkins: royale-asjs_jsonly #318

See Changes: [yishayjobs] Multi Drag Drop - Ignore dragging of non-selected items, unless it's a -- [...truncated 1.16 MB...] [java]