Re: [RESULT][VOTE] Raúl Nuñez (raudjcholo) for committer
Congratulations Raúl, Serkan... 23.06.2020 16:45 tarihinde Carlos Rovira yazdı: Hi, After 4 days, vote passes with 6 +1 binding votes. I will send the invite to Raúl. Thanks
Re: MXRoyale layout issues - questions/discussion
+1 Agree Greg, Layout is the most time consuming issue I faced with UIs I worked although most of them look like very simple. Especially if you do not have any WYSWYG editors. There are lots of thing you have to consider while moving old flex app to royale like 3rd party libraries etc. One less is preferable :) Thanks, Serkan 5.06.2020 13:17 tarihinde Greg Dove yazdı: Yeah I understand this is sometimes necessary Piotr. But the whole point of MXRoyale Flex emulation (and why it does appeal more to some) is that those changes should be much less because it matches more closely to Flex. This is certainly why my client is keen on it. I actually think if they had more time they might be interested in reworking/modernizing the UI, but that is not desirable at this point because it will delay things too much. The app is huge and they need to minimize changes in order to meet their deadlines. Also with MXRoyale, it is not usually a simple css fix for layout, maybe in some simple cases it can be, but mostly not I think, because a lot of MXRoyale layout is driven by code. On Fri, Jun 5, 2020 at 9:41 PM Piotr Zarzycki wrote: I think we need to sometimes let it go and just make changes to our original code. In our Jewel application we are preserving around 30% of code of ported Flex app, by our choice. The rest is just rewritten. Even in that rewritten code when I'm seeing some UI, layout issue - I don't waste huge amount of time if I can simply make it work by one line of CSS. It just allows you to move forward. I know it is hard sometimes convince the client to make the changes, but our job as a power users of this framework is educate also that Royale won't provide 100% conversion. Changes in the old code is in many cases inevitable. Thanks, Piotr pt., 5 cze 2020 o 11:36 Greg Dove napisał(a): thanks Serkan - you are right - I did not see that explanation earlier (just the screencaptures) which is why I asked my extra question. It sounds like it could be similar to what I was addressing, but I don't have a 'universal' solution (and possibly not even a 'good' selective solution, which is why I am keen for extra eyes on it), but it might be useful as-is, or possibly give Alex, you or anyone else some other approaches to consider. I am happy to collaborate on an approach once we settle on one that makes sense for all of us. On Fri, Jun 5, 2020 at 2:29 PM serkan wrote: I am not sure but I guess mail not sent to the list Greg :) My application heavily use states to manage visual layout Greg. Alex is working on the issues one by one as open an issue. They are mostly with percentage based. e.g. id="allJobDetail" height="100%"/> This component is the one et the center with name "İş Tüm Detay Formu" which is very ugly displayed in Royale. Some fix works at first like menu bar but as you can see when resize, it is broken again :) Thank Serkan 4.06.2020 13:08 tarihinde Greg Dove yazdı: Thanks Serkan, Do you think you are seeing the same type of issue I described? Are any of those controls being added either via states or via code at runtime into containers that have percentage based dimensions? I think that the changes I have won't break anyone's existing layouts, but I am not sure yet if I should push them as is to develop or not, because this is the first time I looked at emulation layout stuff. I do see improvements for the issues I have been facing, but there still might be more things that need attention, or I may not be addressing things in the right way. @aharui : when you get to see this, what do you think? Would you have time to take a look at this? And do you think I can push what I have to develop or should it go in a branch? (I can monkey patch my client project so we can use these 'fixes' for local progress in the interim if I need to). On Thu, Jun 4, 2020 at 8:52 PM serkan wrote: Hi Greg, Yes I am. Here is my case : Flex: Emulation : Thanks, Serkan 4.06.2020 11:12 tarihinde Greg Dove yazdı: Hi, Just wondered if anyone else is dealing with layout issues in Flex emulation. I have some layout issues that are slowing my progress on a project, and I'd like to resolve them as quickly as I can. In particular, I see issues with BoxLayout-based containers which have percentWidth or percentHeight set. These don't get determined as having width or height 'SizedToContent' when performing layout, but in many situations they behave in a similar way (they can change their size based on their content in terms of layout rules applied by the parent container). This is because in Flex, percentages are not simply a percentage of their parent, but they follow something perhaps a little closer to flexbox layout rules for all the percentWidth or percentHeight siblings (managed by their parent's layout). In other words, they are also related to the measured size of their content if the parent needs to manage them (I'
Re: MXRoyale layout issues - questions/discussion
Sure not Alex,
I am creating issues one by one. I just wanted to respond Greg's question.
Thanks,
Serkan
4.06.2020 18:32 tarihinde Alex Harui yazdı:
Serkan, is there a bug tracking your layout issue?
There should be a difference between first layout if all children have known
sizes and what Greg is describing which is responding to children changing
sizes. I don’t think we’ve dealt with a lot of children changing sizes (other
than Images loading late and a few other things) so it may be time to listen to
widthChanged/heightChanged/sizeChanged as children get added if there isn’t
already code doing that.
There might be other issues with containers having an inner contentArea that
might be getting in the way too.
HTH,
-Alex
From: Yishay Weiss
Reply-To: "dev@royale.apache.org"
Date: Thursday, June 4, 2020 at 4:30 AM
To: "dev@royale.apache.org"
Subject: RE: MXRoyale layout issues - questions/discussion
Call me lazy but this is a bit difficult to parse. If you can spare some time,
maybe come up with a GitHub issue that describes a concrete case so we can
discuss this.
I think the layouts work downward for this, but changes in the children
don't seem to trigger the parent layout.
Yes, I’ve seen that as well. Alex’s advice when I pointed it out to him was to
just add a parent.dispatchEvent(new Event(‘layoutNeeded’)) if it solves a
concrete bug. It’s true that this could result in a performance hit. If that’s
your issue then I guess we can discuss emulation of the layout manager or some
other optimization.
From: Greg Dove
Sent: Thursday, June 4, 2020 11:12:08 AM
To: Apache Royale Development
Subject: MXRoyale layout issues - questions/discussion
Hi,
Just wondered if anyone else is dealing with layout issues in Flex
emulation. I have some layout issues that are slowing my progress on a
project, and I'd like to resolve them as quickly as I can.
In particular, I see issues with BoxLayout-based containers which have
percentWidth or percentHeight set. These don't get determined as having
width or height 'SizedToContent' when performing layout, but in many
situations they behave in a similar way (they can change their size based
on their content in terms of layout rules applied by the parent container).
This is because in Flex, percentages are not simply a percentage of their
parent, but they follow something perhaps a little closer to flexbox layout
rules for all the percentWidth or percentHeight siblings (managed by their
parent's layout). In other words, they are also related to the measured
size of their content if the parent needs to manage them (I'm not sure how
best to describe this, but I think that sort of captures it). They can
expand beyond their percent allocation or contract below it depending on
their measured sizes.
I think the layouts work downward for this, but changes in the children
don't seem to trigger the parent layout.
An example might be
If you have the above at the application level (where the application has
vertical layout) and keep adding buttons (for example) to the HBox via a UI
test button that adds a new Button to that on each click, then it should
expand horizontally greater than 50% width when the volume of buttons
exceeds its nominal 50% width. It is definitely easier to see this if you
add a border to the container.
I have been working on this, and made progress, but the approach I am using
feels a bit patchwork, and just wondered whether others are seeing anything
like this, and/or how it has been addressed elsewhere
Here's a summary of some of the things I have been trying, which do yield
improvements, but don't really solve the problem completely:
1. added extra listener for 'childrenRemoved' in BoxLayout strand setter.
2. Created a new mx 'ContainerView' class
(mx.containers.beads.ContainerView extends
org.apache.royale.html.beads.ContainerView)
This has the following in it:
private var widthBefore:Number = -1
private var heightBefore:Number = -1;
private var sizeChangedBeforeLayout:Boolean;
COMPILE::JS
override public function beforeLayout():Boolean
{
var container:Container = host as Container;
sizeChangedBeforeLayout = (widthBefore != container.width || heightBefore
!= container.height);
widthBefore = container.width;
heightBefore = container.height;
return super.beforeLayout();
}
COMPILE::JS
override public function afterLayout():void
{
var container:Container = host as Container;
//size might change during layout
var sizeChangedDuringLayout:Boolean = !sizeChangedBeforeLayout &&
(widthBefore != container.width || heightBefore != container.height);
if (sizeChangedDuringLayout) {
//prepare for next time
widthBefore = container.width;
heightBefore = container.height;
}
var requestParentLayout:Boolean = sizeChangedBeforeLayout
|| sizeChangedDuringLayout
|| (!isNaN(container.percentWidth) && container.width <
container.measuredWidth) || (!isNaN(conta
Re: [apache/royale-asjs] Can not change locale for menubar constructed via XMLList within declarations (#824)
Hi Alex, 31.05.2020 09:13 tarihinde Alex Harui yazdı: Hi Serkan, I hope I never wrote or implied that the goal of the emulation components was to 100% emulate Flex. With a different runtime, limited time and resources, it would be impossible or impractical to emulate some features with available resources. I don't know every API well enough to come up with a list of things that would be in the category of impossible/impractical, plus that list changes constantly. But things like weak reference and priority in event listeners comes to mind. Turns out FileReference.save() is one, and also a 'cancel' event from FileReference.browse(). I hope I only said that Royale should be the shortest and/or safest path to migration because you don't have to rewrite as much of your application code. But I hope I also said that you would have to rewrite some of your code. I still think that's true, even though early adopters like you and some others have been working on the migration for around 2 years. Who knows how many harder-to-find problems there would have been if you switched to some other language/framework? When you use Royale many of your code paths do not change. If you port to a new language, every line of code pretty much changes. I'm pretty sure and agree with you that is why I am still here. And so, in that reality, we have to make trade-offs to try to get you and others migrated as soon as we can given the resources we have. We did sort of get TLF working in Spark TextArea, but after it broke again, and looking at all of that code, I think mx:TextArea is a better answer. In the example you provided, your code was going to take HTML, convert it to TextFlow, and then the TLF would convert it to a bunch of HTMLElements. It should be much faster to just pass the HTML straight into a Browser's TextArea. It should save everyone time, and make it worth changing your code for a few instances of Spark TextArea. But if you disagree, we can certain discuss further. For one of the cases it is true and I replaced to mx TextArea, for the rest I am going to work on. Similarly for FileReference, unless you want to restrict yourself to Chrome, there is no practical way to emulate the Save method. I'm pretty sure I've also written that some of these hard problems would have been a problem for you if you didn't choose Royale. IOW, I don't think there are other frameworks out there that can popup a Save dialog. If there is, let us know and maybe we can use their solution. I wish Royale could make migration pain-free, but it can't, we can only try to make it less painful, by providing a framework that should let you migrate by touching much less of your code than any other solution out there. In summary, we simply have to collaborate on what the fastest solution is. Sometimes that is changing the framework, sometimes it is changing your code. HTH, -Alex Thanks, Serkan On 5/30/20, 3:59 AM, "serkan" wrote: Hi Alex, 30.05.2020 10:22 tarihinde Alex Harui yazdı: > Hi Serkan, > > I'm sorry, I keep finding some of your emails in my junk mail. I haven't found a way to prevent that. And it has been a particularly busy time for me recently so sorry for not responding sooner. > > I've read this three times now and I'm not sure what kind of response you are looking for. I think we all appreciate that you are still working with us. I’m still trying to find time to help you, but I can't always get to your issues right away. Response matters, what ever it is > As with any user, the hope is that they will learn how the framework works and improve their ability to work with us and eventually provide patches and pull requests and earn committer status. Becoming less reliant on current committers is your best insurance for the future. If you have ideas on how that can happen let us know. I keep hoping other committers will help you more, but they also have their own priorities to juggle. Also, many of the available committers are independent developers so they are going to prioritize paid work, whereas I don't have to. Yes I have ideas but ends up with documentation > IMO, working with the framework code is different than working on application code, especially if the application code is your own code. You are not obligated to try to learn the framework code and remain more of a user than a committer. That said, the better your understanding of the framework, the more efficient the cycle of reporting and fixing bugs will be because the test cases will be easier to work with and you may even provide the answer yourself. So similarly, if you are interested in learning the framework and have ideas on how that can happen let us know. The unfortunate fact is that there really isn't a whole lot of documentation and the current set of committers are unlikely
Re: [apache/royale-asjs] Can not change locale for menubar constructed via XMLList within declarations (#824)
Hi Alex, 30.05.2020 10:22 tarihinde Alex Harui yazdı: Hi Serkan, I'm sorry, I keep finding some of your emails in my junk mail. I haven't found a way to prevent that. And it has been a particularly busy time for me recently so sorry for not responding sooner. I've read this three times now and I'm not sure what kind of response you are looking for. I think we all appreciate that you are still working with us. I’m still trying to find time to help you, but I can't always get to your issues right away. Response matters, what ever it is As with any user, the hope is that they will learn how the framework works and improve their ability to work with us and eventually provide patches and pull requests and earn committer status. Becoming less reliant on current committers is your best insurance for the future. If you have ideas on how that can happen let us know. I keep hoping other committers will help you more, but they also have their own priorities to juggle. Also, many of the available committers are independent developers so they are going to prioritize paid work, whereas I don't have to. Yes I have ideas but ends up with documentation IMO, working with the framework code is different than working on application code, especially if the application code is your own code. You are not obligated to try to learn the framework code and remain more of a user than a committer. That said, the better your understanding of the framework, the more efficient the cycle of reporting and fixing bugs will be because the test cases will be easier to work with and you may even provide the answer yourself. So similarly, if you are interested in learning the framework and have ideas on how that can happen let us know. The unfortunate fact is that there really isn't a whole lot of documentation and the current set of committers are unlikely to be able to stop and provide a bunch of documentation so it tests one's skill at figuring out other people's code. I also develop frameworks Alex, I guess I have an idea and I believe all are specific and need special know-how, background and attention. Which is really different here for me is working on visual framework that I do not really like from the beginning of my career as I am a system/server side software developer. This does not mean that I do not want to participate in bug fixing or learning the framework. But for here, it is really complicated and more than just using and fixing a visual framework. There are lots of things unclear for the way to go, mostly you decide what to do and do it. And there should be documentation even from the architectural view and the path to be followed while fixing bugs. For example, FileReferance case. Which is the right way, to emulate 100% percent flex or just a work around who will decide and how ? (I am happy with workarounds by the way) I don't doubt that you are trying your best to provide good test cases. And my apologies if you felt I singled you out by saying that your test cases could use improvement. You are not the only one who submits test cases that need fixing or simplification. I think that's something that would improve as your knowledge of the internals of the framework improves. Thanks, and agree. For example, in this recent MenuBar case, the issue was not locales at all, but two other parts of the framework: DataBinding to XML (not from) and Collection notification. I was able to much more efficiently build and debug a test case without involving locales. On your insistence, I did take the time to create a test case to prove that locale changes would update XML via DataBinding correctly. The better your understanding of the framework, the fewer times I will have to go do that. i thought it was just related with change notification. For the TextArea issue, stack traces are like fingerprints. They help identify that the same culprit is the problem. Learning to identify stacktraces helps make the development process more efficient. Instead of filing a bug with a stack trace and waiting for me to find time, it would better if somehow you could have realized it was the TextArea issue yourself and then we could have saved time and started discussing the choices. I started on a "reduced" emulation of Spark TextArea, but I put it on the shelf because it appeared that you had switched to mx:TextArea. If you only have a few s:TextAreas, then it might be more efficient to just replace those few instances instead of waiting for me to find time to finish this version and debug it. But if you have dozens of them, it might make more sense to see if we can get a reduced emulation working. I use sTextArea few times and need some time to check if mx is enough. If you are willing to keep using Royale, I will keep trying to help you. I may not be able to help you as quickly as you like. If you can find a way to get to know the framework c
Re: [apache/royale-asjs] Can not change locale for menubar constructed via XMLList within declarations (#824)
No response means some kind of response Harbs, Thank you for considering Serkan 27.05.2020 15:07 tarihinde Harbs yazdı: I noticed this email a couple of weeks ago assuming that someone who has been more involved in the emulation work would respond. It just occurred to me that Serkan never got a response. I assume people were busy and/or missed this. From my perspective I’ve been looking at what Serkan has been doing favorably, but I have not been focused on emulation or really involved much in that work. Piotr, Greg, Yishay or Alex (or anyone else who’s been involved) could someone respond to this and give Serkan some feedback? Thanks! Harbs On May 16, 2020, at 10:50 PM, serkan wrote: Hi all, Moving to list because it became something more than issue comment. Nearly two year - starting with emulating classes - I am trying to make my flex application running with royale emulation. But more than my application, I am trying to be the part of the project that I believe doing very good things mostly the help of Alex and help to remove issues related with emulation components The way I go : 1. Running my app discovering the non-functioning parts. 2. Trying to isolate the case from application - sometimes really time consuming issue because it is client-server app. 3. Preparing a case than can be compiled and executed without server and simplify as possible 4. Creating the issue and attaching the case to the issue 5. Additionally porting the java script files to a server to make online testing available. And let me go step by step. /*If you have an issue with locale change, then create a test case I can run locally that uses a bundle I have (like one from Flex) that exposes the issue. If it is notifications, it should not be necessary to involve MenuBar or XML. Maybe a string in a Label.* /If every text in the application is changing with the locale change except the menubar which is populated with xml, is staying with the initial locale how can I create the case ?//I do not know any other to express myself/. /I am open to advises. /* Almost all of the past examples you've sent that involve resources have been simplified by using string substitution. So that's what I did to this example, and sure enough, the MenuBar did not update, so I proposed a workaround.*/ All the cases I am attaching the issues are the isolated sources from the application sometimes does not have any similarity with app except the bug. I value your propositions. /*I don't recall asking you to host live examples of these scenarios. I would only look at live examples if I could not reproduce a problem locally because locally I have all of the source so I know there aren't any side-effects from other modules and can re-compile with a change if needed.*/ I am trying to make it easier for you to view the issue with less effort but I can see it is going to the opposite direction. /*For your TitleWindow issue, I just looked at the call stack and could see that it was another case of s:TextArea.*/ TitleWindow is the case that we have discussed couple of months ago. Replacing s:TextArea with mx:TextArea need some additional investigation because the component creation call hierarchy is working different and I am going to let you know after my investigation. /* I'm not going to first try remote debugging. It just isn't efficient for me. I'm sorry you don't like the way I work. */ My aim for preparing the live demo is not the alternative for the attached case but the identical working one in case you need to see it alive. I am not trying teach anyone or you Alex which way to work, because I do not want anyone to try to do the same to me, I am just trying to help you to get case as soon as possible but unfortunately it did not worked. Do not have any comments on the way you work - like or dislike. /* You are welcome to tell me not to help you anymore and get someone else to help you. */Nearly 99% of the time only you are interested and involved in emulation components and the bugs./**/How can this be possible or realistic ? At least why I should think that way ? Of course not. Just want to express my self. But if you think this is not helping Royale for improving the emulation components you just tell me to drop. /* */Thanks, Serkan İletilmiş İleti Konu: Re: [apache/royale-asjs] Can not change locale for menubar constructed via XMLList within declarations (#824) Tarih: Sat, 16 May 2020 09:00:15 -0700 Kimden: aharui Reply-To: apache/royale-asjs Kime: apache/royale-asjs CC: Serkan Taş , Author If you have an issue with locale change, then create a test case I can run locally that uses a bundle I have (like one from Flex) that exposes the issue. If it is notifications, it should not be necessary to involve MenuBar or XML. Maybe a string in a Label. Almost all of the past examples you've sent that involve resources have been
Fwd: Re: [apache/royale-asjs] Can not change locale for menubar constructed via XMLList within declarations (#824)
Hi all, Moving to list because it became something more than issue comment. Nearly two year - starting with emulating classes - I am trying to make my flex application running with royale emulation. But more than my application, I am trying to be the part of the project that I believe doing very good things mostly the help of Alex and help to remove issues related with emulation components The way I go : 1. Running my app discovering the non-functioning parts. 2. Trying to isolate the case from application - sometimes really time consuming issue because it is client-server app. 3. Preparing a case than can be compiled and executed without server and simplify as possible 4. Creating the issue and attaching the case to the issue 5. Additionally porting the java script files to a server to make online testing available. And let me go step by step. /*If you have an issue with locale change, then create a test case I can run locally that uses a bundle I have (like one from Flex) that exposes the issue. If it is notifications, it should not be necessary to involve MenuBar or XML. Maybe a string in a Label.* /If every text in the application is changing with the locale change except the menubar which is populated with xml, is staying with the initial locale how can I create the case ?//I do not know any other to express myself/. /I am open to advises. /* Almost all of the past examples you've sent that involve resources have been simplified by using string substitution. So that's what I did to this example, and sure enough, the MenuBar did not update, so I proposed a workaround.*/ All the cases I am attaching the issues are the isolated sources from the application sometimes does not have any similarity with app except the bug. I value your propositions. /*I don't recall asking you to host live examples of these scenarios. I would only look at live examples if I could not reproduce a problem locally because locally I have all of the source so I know there aren't any side-effects from other modules and can re-compile with a change if needed.*/ I am trying to make it easier for you to view the issue with less effort but I can see it is going to the opposite direction. /*For your TitleWindow issue, I just looked at the call stack and could see that it was another case of s:TextArea.*/ TitleWindow is the case that we have discussed couple of months ago. Replacing s:TextArea with mx:TextArea need some additional investigation because the component creation call hierarchy is working different and I am going to let you know after my investigation. /* I'm not going to first try remote debugging. It just isn't efficient for me. I'm sorry you don't like the way I work. */ My aim for preparing the live demo is not the alternative for the attached case but the identical working one in case you need to see it alive. I am not trying teach anyone or you Alex which way to work, because I do not want anyone to try to do the same to me, I am just trying to help you to get case as soon as possible but unfortunately it did not worked. Do not have any comments on the way you work - like or dislike. /* You are welcome to tell me not to help you anymore and get someone else to help you. */Nearly 99% of the time only you are interested and involved in emulation components and the bugs./**/How can this be possible or realistic ? At least why I should think that way ? Of course not. Just want to express my self. But if you think this is not helping Royale for improving the emulation components you just tell me to drop. /* */Thanks, Serkan İletilmiş İleti Konu: Re: [apache/royale-asjs] Can not change locale for menubar constructed via XMLList within declarations (#824) Tarih: Sat, 16 May 2020 09:00:15 -0700 Kimden: aharui Reply-To: apache/royale-asjs Kime: apache/royale-asjs CC: Serkan Taş , Author If you have an issue with locale change, then create a test case I can run locally that uses a bundle I have (like one from Flex) that exposes the issue. If it is notifications, it should not be necessary to involve MenuBar or XML. Maybe a string in a Label. Almost all of the past examples you've sent that involve resources have been simplified by using string substitution. So that's what I did to this example, and sure enough, the MenuBar did not update, so I proposed a workaround. I don't recall asking you to host live examples of these scenarios. I would only look at live examples if I could not reproduce a problem locally because locally I have all of the source so I know there aren't any side-effects from other modules and can re-compile with a change if needed. For your TitleWindow issue, I just looked at the call stack and could see that it was another case of s:TextArea. I'm not going to first try remote debugging. It just isn't efficient for me. I'm sorry you don't like the way I work. You
Re: Prioritize Release Jobs on CI
It should be related with the shell which ant is executed in. It seems like you should set PATH for that shell. 20.04.2020 07:36 tarihinde OmPrakash Muppirala yazdı: I'm a bit stumped here. The royale-compiler is failing with this error: BUILD FAILED c:\jenkins\workspace\royale-compiler\jenkins.xml:55: Execute failed: java.io.IOException: Cannot run program "git" (in directory "c:\jenkins\workspace\royale-compiler"): CreateProcess error=2, The system cannot find the file specified at java.lang.ProcessBuilder.start(Unknown Source) It is from this part of the jenkins.xml: https://github.com/google/closure-library; /> Cloned fresh copy of Google Closure Library I am not sure how this executable call works without the full path. I checked the env variables, I do have both the git/bin and git/cmd directory in the PATH: image.png What am I missing? Thanks, Om On Sat, Apr 18, 2020 at 11:54 PM OmPrakash Muppirala mailto:bigosma...@gmail.com>> wrote: Update - I have successfully attached my VM as a slave agent of our Jenkins instance. I am going to pull the job - /royale-asjs_jsonly and tie it to my agent so I can test it. It will fail for a sometime while I go set up my VM with all the dependencies. Once we have the job successfully building on my VM, we can figure out how to divide the load between the master and agent. Thanks, Om On Sat, Apr 18, 2020 at 8:59 AM OmPrakash Muppirala mailto:bigosma...@gmail.com>> wrote: We could achieve the same by creating a new agent (separate vm) and attaching it as a slave to the current Jenkins server. Then we can use labels/tags to tie release jobs to one agent and non release jobs to another agent. That way we can maintain everything in one UI, one login while achieving the concurrent building capabilities we want. Jenkins is built for this kind of stuff and I think it would be best we followed this practice. Thanks, Om On Sat, Apr 18, 2020, 8:18 AM Alex Harui wrote: Om, I thought you were going to get the image from my VM and run it on another VM. Then we'd remove all non-release jobs from your VM and all of the release jobs from my VM. That won't solve the problem of how long it takes for a commit to be built and tested, but will allow the RM to get a release out without getting stuck behind the commit jobs. Is that currently the plan? -Alex On 4/18/20, 12:43 AM, "OmPrakash Muppirala" mailto:bigosma...@gmail.com>> wrote: Makes sense to me. I will set parallel executors back to 1. And start working on a new Jenkins instance. Thanks, Om On Sat, Apr 18, 2020, 12:28 AM Alex Harui wrote: > Are you saying that Java, Ant and Maven do not know how to distribute work > to different cores? > > To repeat my main concern: our Jenkins jobs often use shared resources. > If you want to take the time to fix that, feel free, but I do not know how > you are going to keep two jobs from both trying to launch Flash Player > Debugger at the same time and open the same socket to communicate with it, > or try to parse the flashlog.txt that they have both written to. > > The royale-asjs job will use the royale-compiler workspace to get the > compiler. If the compiler is building, the jars are not there and the > royale-asjs build fails. > > There is also only so much memory and some of our jobs use all of it and > I'm not sure if jobs slowed down due to paging memory and writing/reading > from disk, even if it is an SSD. > > I'm done for tonight, but that's what I was seeing last time I tried to > have both master and an agent running jobs in parallel. > > Thanks, > -Alex > > On 4/17/20, 11:52 PM, "OmPrakash Muppirala" mailto:bigosma...@gmail.com>> wrote: > > A typical setup would be to have 0 executors on master and at least n > number of executors on each agent, where n = number of cpu cores. > I see that the current VM has 2 cores. So, I started with setting the
Re: Requirements for Releases
I guess the operating system may be added. * The release process should ideally work on these OS's (Linux, Windows, MacOS,..) 21.03.2020 12:20 tarihinde Christofer Dutz yazdı: Hi all, I would like to use this thread to collect some requirements for the release process. Also would I like to ask you not to formulate things like “The release artifacts must be built with X” but rather “The release artifacts should be usable by X” cause that’s what really matters. I hope you get what I mean. So far I have this: * The release artifacts should be usable by Maven * The release artifacts should be usable by Ant * The release should include tests, which ensure the correct function of the royale-maven-plugin * The release should include tests which ensure the correct function of the Ant targets * It should be possible to verify a release by comparing it’s binary artifacts for equality (reproducible builds) * It should be ensured a release candidate builds correctly with Ant and with Maven * The release process should ideally work on any machine Did I miss something? Chris
Re: Let's bump Royale version to 1.0
Congratulations Alex, Serkan... 18.02.2020 10:42 tarihinde Alex Harui yazdı: Today, I received permission to disclose that Alina & Pashmina's team has 88 of their modules ready for release (tested and validated by their QA team). They still have more modules to migrate before they deliver to their customer, but it is a good sign that the emulation is sufficient for many needs. Once I can merge the "has" branch and re-stabilize, I will hope that's the last big change we need for a while. I have heard that there are other migration efforts underway using migration and I'm sure they will keep finding bugs, but I'm feeling better about the emulation code. -Alex On 12/18/19, 9:05 AM, "Alex Harui" wrote: Every day, I hope to hear news that Alina & Pashmina or Serkan or somebody else has deployed a production app using the MXRoyale and/or Spark Royale emulation components. But instead, I see more bugs being filed for "obvious" things. You can look at the issues list of open and fixed issues and the commits that fixed them to get a feel for it. Each of us has their own threshold of how good a 1.0 version should be, so if more of you can look at these bugs and think it is ok for a 1.0 to have these problems, then great, let's release the next version as 1.0, but when I try to remember what Flex 1.0 was like, I think it didn't have these kinds of problems. As Carlos said below, we get one chance to make a good first impression, so I am being conservative. But it isn't my decision alone. It is really up to the rest of you. -Alex On 12/18/19, 6:41 AM, "Carlos Rovira" wrote: Hi Piotr, I'm afraid my perception is that we need to get to 1.0 in a natural way. I mean: releasing 1.0 and giving exposure in all ways we can (webs, social media, magazines,...), means people will try us. If they try and fail, will never come back. So think about this as "only on bullet in your gun", if you fail de shot, that will be bad for all the work we are done. I'm ok to release 1.0 as soon as we see from "bird eye perspective" that all things work as we expect. For me that things are: * Documentation will need to have at least some missing pages of features like: DataBindnig, Loading External Data (HTTPSerice, RemoteObject, JSON), View States, Item Renderers. Things like this are essential. * Emulation components need to be in a shape that allow migrations in a good degree. I think people approaching direct migration with emulation components will many issues. I don't take into account look and feel of emulation components, just functionality and working from a flex code perspective, and just normal use cases with MX/Spark code, not third party libraries that we have no control over. Simple apps like TDF, and examples should work. If we decided we want to bypass the previous, at least we need to ensure "first try" of Royale for a newcomer (someone that knows very few about the tech) is successful. This is most important things of all. The other two are needed if we want people does not get frustrated and have solutions on their own and stay with us. The opposite is people can have a first try successful but abandon Royale due to unfinished things. I think 0.9.7-SNAPSHOT captures in a realistic number where we are. Technology works, and most people using it now can do lots of things, but we still need to cover some things to reach that 1.0. We are not too far but I think is still some month in the future. just my 2 :) Carlos El mié., 18 dic. 2019 a las 10:30, Piotr Zarzycki (< piotrzarzyck...@gmail.com>) escribió: > Hello, > > This thread is old and this was the last message from me. What has changed > on your end guys ? > > Thanks, > Piotr > > wt., 30 kwi 2019 o 10:07 Piotr Zarzycki > napisał(a): > > > Hi Guys, > > > > Thank you so far for a great discussion. I see that there is an obvious > > needs to improve documentation the most. > > > > I would like to express my personal feelings regarding releasing anything > > what is not 1.0 after 0.9.6. Based on my experience with this project I > > don't believe that releasing 0.9.7, 0.9.8 till 1.0 etc. will take less > than
Re: New ASF staff member
Congrats. Andrew Alıntı Andrew Wetmore : Hi, friends: Wanted you all to be the first [1] to know that I will be working part-time for the Apache Software Foundation as a Technical Writer-Editor. I start tomorrow, as far as I can tell. My work will focus on the thousands of words of ASF text that have silted up over twenty years, some of which represent the equivalent of "technical debt" in a software project: material that is no longer relevant or no longer accurate. I am very much looking forward to this, and am grateful to whomever it was who pointed out the job opening around six months ago. [1] After Infra and my wife, in that order. -- Andrew Wetmore http://cottage14.blogspot.com/ -- Serkan Taş Mobil : +90 532 250 07 71 Likya Bilgi Teknolojileri ve İletişim Hiz. Ltd. Şti. www.likyateknoloji.com -- Bu elektronik posta ve onunla iletilen bütün dosyalar gizlidir. Sadece yukarıda isimleri belirtilen kişiler arasında özel haberleşme amacını taşımaktadır. Size yanlışlıkla ulaşmışsa bu elektonik postanın içeriğini açıklamanız, kopyalamanız, yönlendirmeniz ve kullanmanız kesinlikle yasaktır. Lütfen mesajı geri gönderiniz ve sisteminizden siliniz. Likya Bilgi Teknolojileri ve İletişim Hiz. Ltd. Şti. bu mesajın içeriği ile ilgili olarak hiç bir hukuksal sorumluluğu kabul etmez. This electronic mail and any files transmitted with it are intended for the private use of the persons named above. If you received this message in error, forwarding, copying or use of any of the information is strictly prohibited. Please immediately notify the sender and delete it from your system. Likya Bilgi Teknolojileri ve İletişim Hiz. Ltd. Şti. does not accept legal responsibility for the contents of this message. --
Re: Welcome Greg Dove to Apache Royale's PMC
Congrats. Greg, Good luck ! Serkan 29.10.2019 11:05 tarihinde Piotr Zarzycki yazdı: Hi Greg, Welcome among PMCs and good luck! Piotr wt., 29 paź 2019 o 08:51 Harbs napisał(a): It is with great pleasure that I announce that the Apache Royale PMC members have voted in Greg Dove to the PMC. Please join us in welcoming him. This is a recognition of Greg's great work in helping out with Apache Royale's compiler and architecture among other things. Regards, Harbs (On behalf of Apache Royale PMC)
Re: Welcome Andrew Wetmore to Apache Royale's PMC
Congrat. Andrew. Serkan. Android için Outlook'u edinin On Thu, Oct 3, 2019 at 8:56 PM +0300, "OmPrakash Muppirala" wrote: It is with great pleasure that I announce that the Apache Royale PMC members have voted in Andrew Wetmore to the PMC. Please join us in welcoming him. This is a recognition of Andrew's great work in helping out with Apache Royale's documentation among other things. Regards, Om (On behalf of Apache Royale PMC)
Re: [MAVEN-BUILD] Royale-asjs - Build # 1321 - Still Failing
Thanks Carlos, it is fixed by cleaning maven repo. 17.11.2018 14:02 tarihinde Carlos Rovira yazdı: I think I fixed the build and was some poms not updated. typedefs and framework was using 0.9.4 so that made MXRoyale fail. I removed my royale folder in .m2 and all is generating ok just using 0.9.5-SNAPSHOT and as well SDK generation with ant is ok as well El sáb., 17 nov. 2018 a las 10:12, Serkan Taş (< serkan@likyateknoloji.com>) escribió: +1 17.11.2018 12:07 tarihinde Carlos Rovira yazdı: Hi, I 'm trying to build locally but some changes to MXRoyale are failing Are someone looking at this now? I need to build so, let me know in order to see if I must work on fixing the issue thanks El vie., 16 nov. 2018 a las 23:25, Apache Jenkins Server (< jenk...@builds.apache.org>) escribió: The Apache Jenkins build system has built Royale-asjs (build #1321) Status: Still Failing Check console output at https://builds.apache.org/job/Royale-asjs/1321/ to view the results.
Re: [MAVEN-BUILD] Royale-asjs - Build # 1321 - Still Failing
+1 17.11.2018 12:07 tarihinde Carlos Rovira yazdı: Hi, I 'm trying to build locally but some changes to MXRoyale are failing Are someone looking at this now? I need to build so, let me know in order to see if I must work on fixing the issue thanks El vie., 16 nov. 2018 a las 23:25, Apache Jenkins Server (< jenk...@builds.apache.org>) escribió: The Apache Jenkins build system has built Royale-asjs (build #1321) Status: Still Failing Check console output at https://builds.apache.org/job/Royale-asjs/1321/ to view the results.
