In looking at the code, unless explicitly sized, SkinnableComponent will
get sized to the measuredWidth/Height of its skin.
If the skin defers its content, then the measurement might take place
before the content defines the size in $width/$height. Or a subcomponent
might get sized to 0 regardles
I can’t push to the repo, and I see that Jenkins is having trouble as well.
How do we go about getting this resolved?
Thanks,
Harbs
Well, if you ask me how'd I like this to be, then, probably, I'd like
this to have hierarchical structure (maybe I'm biased by how C
compilers go about it). In other words, I'd like warnings to be
grouped (not necessary by severity). Whether to warn on assignment
inside condition is a matter of sty
It is affecting all of apache. Infra is working on it.
Sent via the PANTECH Discover, an AT&T 4G LTE smartphone.
Harbs wrote:
I can’t push to the repo, and I see that Jenkins is having trouble as well.
How do we go about getting this resolved?
Thanks,
Harbs
GitHub user kevinGodell opened a pull request:
https://github.com/apache/flex-sdk/pull/13
Update Alert.as
This typo causes an error when assigning a skinClass at runtime. This is my
first time using git. Forgive me if I have done this incorrectly.
You can merge this pull request in
I am trying to have a better understanding of the overall process of how bugs
are fixed, files are updated, and releases are made. This has left me with
several questions that I hope to have answered.
Does a jira ticket need to be made for a bug to be fixed, or can I submit a
patch without a jira
Github user asfgit closed the pull request at:
https://github.com/apache/flex-sdk/pull/13
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is ena
Hi Kevin,
Thanks for helping!
The way you did it is perfectly fine. We have it set up so the mailing list
alerts us to pull requests. I just merged your request.
We’re in the process of working on the 4.14 release. Your change was merged
into the develop branch. Hopefully we’ll apply it to the
BTW, I used the "git pull" command and the commit came through attributed to
Kevin, but the commit email came from my account.
This seems like a nice way of recording who made the fix while being able to
track who applied it for accountability.
On Jan 1, 2015, at 8:55 PM, kevinGodell wrote:
>
>>Darrell, don't -error-problems, -warning-problems, and -ignore-problems
allow the problems to be specified either by fully-qualified class >>name
or by numeric problem code? And isn't the numeric problem code displayed
along with the problem message?
The numeric problem code is not accepted in t
>>The way warnings may be grouped is for example: syntactical, related
>>to project structure, related to security, related to code safety (as
>>opposed to security - a suspicious cast, an object used in a strange
>>way etc.), related to code sloppiness - unused variables, function
>>arguments, ure
In the future, if you reference the JIRA ticket in the pull request, it would
make it easier to mark the JIRA as resolved. I only realized that there was a
JIRA ticket on this because of your email.
On Jan 1, 2015, at 9:53 PM, kevin.godell wrote:
> I am trying to have a better understanding of
>>No problem. It was not obvious, and I don’t think I’ve ever seen that
>>pattern before. That’s why I’m hoping you or Gordon know how to teach the
>>parser or reducer and other code how to handle this. It looks like the
>>compiler sees the {} as a block and not an object literal.
I'm currently
I'll try to find time to look at this later in the month.
- Gordon
> Date: Thu, 1 Jan 2015 16:07:04 -0500
> Subject: Re: [FALCON] internal error related to identifier resolution (?)
> From: darrell.love...@gmail.com
> To: dev@flex.apache.org
>
> >>No problem. It was not obvious, and I don’t t
But
-ignore-problems=org.apache.flex.compiler.problems.AbstractSemanticProblem
doesn't currently cause all subclasses of AbstractSemanticProblem to be
ignored, does it?
- Gordon
> Date: Thu, 1 Jan 2015 15:50:11 -0500
> Subject: Re: [FALCON] don't warn on assignment in while (condition)
flex-sdk_release-candidate - Build #54 - Successful
Changes since last build:
[harbs] Update Alert.as
For more information, check the console output at
http://apacheflexbuild.cloudapp.net:8080/job/flex-sdk_release-candidate/54/.
>>But
>>-ignore-problems=org.apache.flex.compiler.problems.
AbstractSemanticProblem
>> doesn't currently cause all subclasses of AbstractSemanticProblem to be
ignored, does it?
I think it does.
-Darrell
On Thu, Jan 1, 2015 at 5:07 PM, Gordon Smith wrote:
> But
>
>
> -ignore-problems=org.
I haven’t looked at the diffs, but usually I want to understand why
something is giving sub-pixel diffs before cutting new baselines. Once it
was because we changed the parenting of child objects in the skin. That
made the player choose slightly different color values. Once it was
because we adde
On 1/1/15, 2:43 AM, "Left Right" wrote:
>if I wanted to convince someone
>to try Falcon, what would be the good argument to do so?
IMO, if you have a bug you want fixed in Falcon or a question about it you
want answered, you’ll find several folks on this mailing list who might be
able to help.
19 matches
Mail list logo
