flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: why can not open this code?
Date Thu, 26 May 2016 15:02:32 GMT

On 5/26/16, 7:21 AM, "Andy Dufilie" <andy.dufilie@gmail.com> wrote:

>On Wed, May 25, 2016 at 9:44 PM, lizhi <sliz@qq.com> wrote:
>> yes,i will try.but i do not know.why no debug theyself of flexjs sdk
>> developer?
>> why not do not like check out the spriteflexjs code.and debug.
>> it is a sdk bug,look at the bug,will improte the flexjs sdk.
>> why not it just useful for myself?
>Because I have other obligations in both my personal and professional life
>at the moment and I'm currently not feeling well.  I thought it would be a
>valuable thing for you to learn how to debug an error in the browser if
>did not already know.  It's much easier for you to test since you already
>have it up and running.  I just tried the build.bat and it did not work
>because test/src/Test3.as  does not exist in your repository.  It would be
>much easier for us to test if you provided a live demo like you have here:

For me, I thought it was common practice to reduce a potential bug down to
a simple test case.  For compiler/runtime issues, that generally involves
getting it down to as few files and lines of code as possible.  I quite
frequently request that folks reduce their code and attach it to a JIRA.
Reproducing a bug should not require cloning a repo.  The reduction helps
prove that the issue is not in your code, and it usually makes it easier
to describe the problem because the reduction only contains the code that
is truly involved.  And those who are going to diagnose and fix the
problem are more likely to do so when the test case doesn't contain a lot
of extra stuff.

And, as I said before, if you already have the information available to
you, just share it with us via copy/paste or screenshots.  Why should we
have to duplicate your work, find out we can't easily duplicate it and ask
questions for clarification?  Consider that each email is potentially read
by over 700 people.  That's a lot of community time consumed when the
information is not efficiently transmitted.

In general, if you report errors that contain line numbers, also share the
code at that line number, and other versioning related information like
which release or nightly build you are using if you have it.  I wish there
was an algorithm for "asking for help" that could guarantee capture of the
pertinent facts, but I think it remains an "art".  But especially when
there are language barriers, reduction to simple test cases, and
associating errors with lines of code helps because there is less words to
write:  just data to copy and paste.


View raw message