Thank you for reporting this bug. We will make it our priority to review this report.
  1. #1
    Ext JS Premium Member stevil's Avatar
    Join Date
    Nov 2007
    Location
    Denver, CO
    Posts
    1,045
    Vote Rating
    9
    stevil will become famous soon enough

      0  

    Default [FIXED-EXTJSIV-2102]//<debug> code

    [FIXED-EXTJSIV-2102]//<debug> code


    There are approximately 80 code fragments in the source that are marked //<debug>. Are these fragments that should be removed at build, should we expect them to be removed in a future release, are any of them going to stick around?

    stevil

  2. #2
    Sencha - Sencha Touch Dev Team Jacky Nguyen's Avatar
    Join Date
    Jul 2009
    Location
    Palo Alto, California
    Posts
    469
    Vote Rating
    13
    Jacky Nguyen has a spectacular aura about Jacky Nguyen has a spectacular aura about

      0  

    Default


    They are special tags for JSBuilder, and always get stripped out automatically when built, so you don't have to worry about them. In fact you can make use of that for enable specific chunks of code that only exist during development but not production.
    Sencha Touch Lead Architect

  3. #3
    Ext JS Premium Member stevil's Avatar
    Join Date
    Nov 2007
    Location
    Denver, CO
    Posts
    1,045
    Vote Rating
    9
    stevil will become famous soon enough

      0  

    Default


    So ext-all-debug is MORE than just non-minified ext-all?

    In ext-all-debug, the block

    PHP Code:
    //<debug>
            
    if (start end) {
                
    Ext.Error.raise("Start (" start ") was greater than end (" end ")");
            }
    //</debug> 
    is a perfect example - this happens when you guaranteeRange() a buffered store and no rows are returned, which may be an interesting technical error to you, but is a perfectly acceptable business condition to me.

    To be honest, I think that if ext-all-debug is functionally different (because it has ANY additional code) than ext-all, then we should have:
    1. ext-all-debug, as it is
    2. ext-all, unminified but stripped of <debug> tags
    3. ext-all-min, stripped and minified

    That way, a developer can debug into the framework, knowing it's the same as production.

    Thanks,

    stevil

  4. #4
    Sencha - Sencha Touch Dev Team Jacky Nguyen's Avatar
    Join Date
    Jul 2009
    Location
    Palo Alto, California
    Posts
    469
    Vote Rating
    13
    Jacky Nguyen has a spectacular aura about Jacky Nguyen has a spectacular aura about

      0  

    Default


    The purpose of using //<debug> is to strip out unnecessary code for production, which gives maximum performance gain without having the hassle of doing that manually. That includes console.log, warnings, error messages, etc. You can, however, choose to keep them by adding debug: true in your app.jsb3 options. For example:

    Code:
    {
        "name": "Application - Production",
        "target": "app-all.js",
        "compress": true,
        "options": {
            debug: true
        },
        "files": [
            {
                "path": "",
                "name": "all-classes.js"
            },
            {
                "path": "",
                "name": "app.js"
            }
        ]
    }
    Sencha Touch Lead Architect

  5. #5
    Ext JS Premium Member stevil's Avatar
    Join Date
    Nov 2007
    Location
    Denver, CO
    Posts
    1,045
    Vote Rating
    9
    stevil will become famous soon enough

      0  

    Default


    Thanks for the quick reply.

    2 thoughts on that:

    1 - in 3.3, this never seemed to happen, so why now? I used to be able to develop against -debug, then, to ensure it was the same experience in prod, bundle and compress it with my own application code.

    2 - I just ran with ext-all, which is supposed to have the debug code stripped out, and I just got the "Start (0) was greater than end (-1)" error doing a guaranteeRange() that returned no rows.

    So, while the comments may be getting stripped out, the debug code still seems to make it into the final JS. (I verified that my code is using ext-all, not -debug.) That error comes from lines 1543-1547 of Ext.data.Store.js. It's bracketed with //<debug>.

    If you're going to include debug code in ext-all-debug, you really need to provide a non-minified version of the code that has debug code stripped out, so that we can verify, and if necessary, step into that code. Just providing a minified version of that is insufficient.

    "OK, so build your own, then", I can hear people saying. But what I want is a reference version, non-minified, that matches what you release.

    Steve

    Update:

    from the minified code in ext-all.js

    PHP Code:
    ... 
    function(){var 
    g=this,c=g.getTotalCount(),h=g.requestStart,b=((c-1)<g.requestEnd)?c-1:g.requestEnd,d=[],a,e=h;if(h>b){Ext.Error.raise("Start ("+h+") was greater than end ("+b+")")} 
    ... 
    Last edited by stevil; 5 May 2011 at 11:17 AM. Reason: more cowbell!

  6. #6
    Ext JS Premium Member
    Join Date
    Apr 2008
    Posts
    338
    Vote Rating
    15
    rich02818 will become famous soon enough

      0  

    Default


    But what I want is a reference version, non-minified, that matches what you release.
    +1 (really +100)

  7. #7
    Ext JS Premium Member stevil's Avatar
    Join Date
    Nov 2007
    Location
    Denver, CO
    Posts
    1,045
    Vote Rating
    9
    stevil will become famous soon enough

      0  

    Default


    At the very least, you're not stripping out debug code that you think you are. Please make that stop. It's making us tear our hair out.

    Once that's done, we can have a cordial debate about whether developers should have to:

    1) develop and test our code with one version of your framework (ext-all-debug), and then

    2) test (again)/deploy with a different version (ext-all)

    or,

    1) develop, test, and deploy with one version of the framework (ext-all-debug, run through a minifier once, but otherwise known to be functionally the same)

    stevil

  8. #8
    Ext JS Premium Member
    Join Date
    Apr 2008
    Posts
    338
    Vote Rating
    15
    rich02818 will become famous soon enough

      0  

    Default


    This is extremely important as it relates to the integrity of the delivered Sencha product. I sincerely hope that this is resolved immediately.

    Quote Originally Posted by stevil View Post
    At the very least, you're not stripping out debug code that you think you are. Please make that stop. It's making us tear our hair out.

    Once that's done, we can have a cordial debate about whether developers should have to:

    1) develop and test our code with one version of your framework (ext-all-debug), and then

    2) test (again)/deploy with a different version (ext-all)

    or,

    1) develop, test, and deploy with one version of the framework (ext-all-debug, run through a minifier once, but otherwise known to be functionally the same)

    stevil

  9. #9
    Sencha - Community Support Team edspencer's Avatar
    Join Date
    Jan 2009
    Location
    Palo Alto, California
    Posts
    1,939
    Vote Rating
    7
    edspencer is a jewel in the rough edspencer is a jewel in the rough edspencer is a jewel in the rough

      1  

    Default


    Hi guys, we'll resolve this internally today. It sounds like there are two issues:

    1) Debug lines are not being correctly removed when they should be
    2) ext-all-debug.js is not functionally identical to ext-all.js

    Thoughts on this solution?:

    1) ext-all-dev.js is unminified and contains the debug code
    2) ext-all-debug.js is unminified and does NOT contain the debug code
    3) ext-all.js is minified and functionally identical to ext-all-debug.js

    The names are a little tricky to pick out because we have existing conventions to follow - in this case the previous choice of ext-all-debug.js is unfortunate as that would be the best name for the build that includes the debug statements.

    I'm open to a different name for file 1 (which is a new file, and the one we would recommend you use during active development).
    Ext JS Senior Software Architect
    Personal Blog: http://edspencer.net
    Twitter: http://twitter.com/edspencer
    Github: http://github.com/edspencer

  10. #10
    Ext JS Premium Member stevil's Avatar
    Join Date
    Nov 2007
    Location
    Denver, CO
    Posts
    1,045
    Vote Rating
    9
    stevil will become famous soon enough

      0  

    Default


    Quote Originally Posted by edspencer View Post
    Hi guys, we'll resolve this internally today. It sounds like there are two issues:

    1) Debug lines are not being correctly removed when they should be
    2) ext-all-debug.js is not functionally identical to ext-all.js

    Thoughts on this solution?:

    1) ext-all-dev.js is unminified and contains the debug code
    2) ext-all-debug.js is unminified and does NOT contain the debug code
    3) ext-all.js is minified and functionally identical to ext-all-debug.js

    The names are a little tricky to pick out because we have existing conventions to follow - in this case the previous choice of ext-all-debug.js is unfortunate as that would be the best name for the build that includes the debug statements.

    I'm open to a different name for file 1 (which is a new file, and the one we would recommend you use during active development).
    Given your existing file naming conventions, I agree - ext-all-debug.js ought to behave just like ext-all.js. ext-all-dev to have debug code is certainly acceptable for me.

    With regard to issue #1), it did seem to me like the debug code was at least stripped from ext-all in 4.0.1 (at least some of it, anyway - I didn't check exhaustively).

    Cheers,

    stevil

Similar Threads

  1. Help me debug this code
    By Sunforever0220 in forum Sencha Touch 1.x: Discussion
    Replies: 4
    Last Post: 17 Mar 2011, 4:51 AM
  2. Debug ExtJS code for FireFox
    By MakFracta in forum Ext 3.x: Help & Discussion
    Replies: 0
    Last Post: 30 Mar 2010, 3:32 PM
  3. Debug source code
    By fother in forum Ext GWT: Help & Discussion (1.x)
    Replies: 5
    Last Post: 6 Nov 2008, 4:22 AM
  4. [SOLVED] Better debug code
    By dotnetCarpenter in forum Community Discussion
    Replies: 2
    Last Post: 25 Jan 2008, 10:18 AM

Thread Participants: 4

film izle

hd film izle

film sitesi

takipci kazanma sitesi

takipci kazanma sitesi

güzel olan herşey

takipci alma sitesi

komik eğlenceli videolar