Erroneous symbols and broken code generated by Core Builder

[mootools]

Erroneous symbols and broken code generated by Core Builder

[cpojer]

This is the best bug report ever. Thank you very much for this very detailed guide on how to debug these problems.

We have fixed the first issue and we'll fix the second one soon and release 1.4.1.

Keep it up!

[milesj]

Have to agree, what an awesome bug report.

I also lost it at "unmolested", kudos, haha.

[timwienk]

Like cpojer said, thanks for the great report. Very detailed, very nice. We didn't even have to debug to fix it. ++

Anyway, the first problem you described is an encoding problem. In some weird way, a 0xC2A0 (no-break space in UTF-8) made its way into the code, rather than a 0x20 (a normal space). When serving the file UTF-8 encoded, there is no problem, a no-break space is treated as just a whitespace character. When serving the file as ISO-8859, 0xC2 is an Â, while 0xA0 is a no-break space.

This explains why the error wasn't caught (it's no excuse though), as we probably(/apparently) all work and test in UTF-8 environments. (MooTools-More's Locale files, for example, are UTF-8 by design, but obviously for just Core it shouldn't matter.) Like cpojer said, 1.4.1 will be out the door soon enough, fixing this nasty issue!

The second issue you raised is because $family changed from an object to a function in 1.3. It's only used by $type/typeOf. The fact that it throws an error about an object with $family.name == 'array' is rather awkward, should be something in the APE test itself (I hope)? In any case, technically $family is private (which is why there currently is no compatibility), but the issue will be discussed, and decided whether there should be compatibility in the $type function for it.

Thanks again!

[Xunnamius]

Anything to help!

Even with an infinitesimally small encoding issue, MooTools is still the best JS framework I've ever used =)

Now for that $family.name == 'array' debacle, the only test code (javascript) was what was shown in the pictures. Still, the problem is definitely APE's fault for still clinging to 1.2. I may just rewrite the whole dang engine one weekend (if I ever get that annoyed).

As always, thanks for the quick fix!

[timwienk]

I just realized you said it does work with 1.3+1.2compat, there was no compatibility for this either in 1.3. So that issue will need some more investigation.

[GCheung55]

@Xunnamius: I'm going to attempt to replicate the $family issue.

Could you tell me about your current setup?

[Xunnamius]

@timwienk I am (or was) constantly playing around with the Moo 1.3 source (although nothing so deep as to mess with the $family variable directly), so I guess it wasn't so fair of me to include that statement in my post.

@GCheung55 what would you like to know specifically?

• I'm running my server on Ubuntu 11, Zend Server 5.5 + LAMP stack, APE Server version 1.0 is reported at the CLI
• Chrome (13.0.7820) as my debugging browser
• MooTools 1.4 w/ compat as my framework
• APE-JSF apeClientMoo.js (based on Moo 1.2) as my intercessor to the APE core.js
• Using xHTML 1.1 in standards compliant (non-quirks) mode
• Running tests on a Windows computer
• No other frameworks are used (jquery, dojo, etc.)

[ibolmo]

@Xunnamius figured out your bug :D.

Glad to say it wasn't MooTools this time.

In your ACJ.js file

(function(){
    for (var i = 0; i < arguments.length; i++)
        APE.Config.scripts.push(APE.Config.baseUrl + '/Source/' + arguments[i] + '.js');
})(/* --> */ 'mootools-core' /* <-- */, 'Core/APE', 'Core/Events', 'Core/Core', 'Pipe/Pipe', 

To:

(function(){
    APE.Config.scripts.push(APE.Config.baseUrl + 'mootools-core-1.4.0.js');
    for (var i = 0; i < arguments.length; i++)
        APE.Config.scripts.push(APE.Config.baseUrl + '/Source/' + arguments[i] + '.js');
})('Core/APE', 'Core/Events', 'Core/Core', 'Pipe/Pipe', 'Pipe/PipeProxy', 'Pipe/PipeMulti', 'Pipe/PipeSingle', 'Request/Request','Request/Request.Stack', 'Request/Request.CycledStack', 'Transport/Transport.longPolling','Transport/Transport.SSE', 'Transport/Transport.XHRStreaming', 'Transport/Transport.JSONP', 'Transport/Transport.WebSocket', 'Core/Utility', 'Core/JSON');

Effectively. You were including 1.3.2 in the iframe that APE creates. Since the mootools loaded in the iframe affects the MooTools in the parent frame, you or APE should include the 1.4 version.

[Xunnamius]

Ah, I thought the iframe would have isolated the two Moo implementations from one another. Mistaken I was!

Well, my little hackfix is working at the moment (I'm a little scared to take it out), but I'll forward this to the APE guys. Maybe they'll look at it and finally upgrade their Moo!

Thanks.

[ibolmo]

If they build from github master, they shouldn't have problems. We're
releasing 1.4.1 this week.

On Tue, Sep 20, 2011 at 8:27 PM, Tre Giles <
[email protected]>wrote:

Ah, I thought the iframe would have isolated the two Moo implementations
from one another. Mistaken I was!

Well, my little hackfix is working at the moment (I'm a little scared to
take it out), but I'll forward this to the APE guys. Maybe they'll look at
it and finally upgrade their Moo!

Thanks.

Reply to this email directly or view it on GitHub:
#2062 (comment)