[Prototype-core] unit test stalling: enumerable.html
On trunk, on both firefox and safari, the testEachSlice method in enumerable.html is stalling (seemingly indefinitely). Is reproducible by anyone else? I ran it via rake test_units and by loading the html directly into browsers. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: unit test stalling: enumerable.html
Ah, thx again. On Feb 13, 9:21 pm, Tobie Langel [EMAIL PROTECTED] wrote: afaik, rake test_units doesn't run rake dist before. Use rake test instead, which auto builds Prototype each time. Best, Tobie On Feb 13, 12:14 pm, Tobie Langel [EMAIL PROTECTED] wrote: Have you rebuilt Prototype ? Best, Tobie On Feb 13, 12:04 pm, Dr Nic [EMAIL PROTECTED] wrote: On trunk, on both firefox and safari, the testEachSlice method in enumerable.html is stalling (seemingly indefinitely). Is reproducible by anyone else? I ran it via rake test_units and by loading the html directly into browsers. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Cross-browser Event.simulateMouse [bump via kangax]
Since the existing Event.simulateMouse code is labelled experimental, then this code with its suite of tests must be an improvement worth patching in? Even if it retains its experimental label, it will be an enhancement/bug fix patch for existing code. Whilst the ticket is categorised script.aculo.us, it could be repatch against the prototype versions of unittest.js and the patch resubmitted if it will be accepted. Nic On Feb 4, 4:48 pm, Dr Nic [EMAIL PROTECTED] wrote: [posted by kangax in Nov 07 with no responses at the time] Hello team, I recently needed a cross-browser simulateMouse support for some of our tests in Prototype UI and stumbled upon certain limitations in current implementation. Event.simulateMouse is marked as Firefox-only and experimental. Turning it into a somewhat robust solution will definitely benefit other modules' test suits (notable autocompleter and IPE which rely on mouse events quite heavily). Thomas mentioned that any patches and tests are very appreciated, considering that as of now there are NO specific unit tests for this wonderful method. Here's a fresh patchhttp://dev.rubyonrails.org/ticket/10170and unit testshttp://dev.rubyonrails.org/attachment/ticket/10170/simulatemouse_test... (FF2+, IE6+, Opera 9+, Safari 3 all pass happily). Would be nice to know about Safari 2 as well. The coverage is not as complete as I would want it to be, but it's a good start and is better than nothing. My question is: What are the chances of applying it to the current version or would it rather make sense to bake it into a 2.0? best, kangax --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Staring noconflict support - putting $() into a namespace [reposted from Spinoffs group]
I'm ok to retract this request (and offer to do the work). I've been educated about what use a closure meant in the context of a working pastie solution. http://pastie.caboo.se/146564 Inside the closure the happy jquery code runs oblivious to the possible reuse of $ elsewhere. Use one of these per library, for example. I'll close the ticket. On Jan 31, 5:13 pm, Dr Nic [EMAIL PROTECTED] wrote: But it doesn't have to be the $ feature - this can be cleanly noconflict-proofed; giving some useful benefits. I'm still keen to see this refactoring as I think its a Good Thing. On Jan 31, 9:17 am, Tobie Langel [EMAIL PROTECTED] wrote: Right so there are some frameworks that will never work together, and there are some frameworks that could work together with a little love'n'care to prototypejs. The question remains: how will we ever know which ones ? The frameworks which are self contained will always work. The others won't necessarily, and we don't have proper means to test which that. I'd also like to add that, afaik, the only libs concerned by $ are jQuery - which sports a noConflict mode - and mootools, which extends native prototypes about as much as we do - so there would most certainly be conflicts there. I personally don't think it is reasonable to release a feature which, by design, is and always will be incomplete. But that's just my $ .02 and isn't necessarily a view shared by everyone in core. Best, Tobie --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Staring noconflict support - putting $() into a namespace [reposted from Spinoffs group]
And I've managed to misspell Starting in the title (as Staring...) in both posts, ftl. Tobie - what did you mean (in other thread) about doing the work in a closure. Which work were you referring to? On Jan 31, 1:38 am, Tobie Langel [EMAIL PROTECTED] wrote: Just to clarify, I suggested reposting the thread here, not providing a noConflict mode ;) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Staring noconflict support - putting $() into a namespace [reposted from Spinoffs group]
[As suggested by Tobie - reposted from http://groups.google.com/group/rubyonrails-spinoffs/browse_thread/thread/a7edd31205e69472] I've started a path to reimplementing commonly reused global names with a patch (http://dev.rubyonrails.org/ticket/10958) This patch is for $ function. I've giving it the namespace Prototype.upgradeElement, but the actual name is unimportant currently - its very easy to change in my git branch and to recreate the patch. Whilst there are many classes and functions in the global namespace, this patch is a start to give an idea how easy it is to replace the code throughout the src, and ensure the original tests still work (and thus all dependent code will still work). Subsequent patches can fix up other commonly overused variables/ functions, and most importantly, create a noConflict() method to let users manage it at runtime. Cheers Nic --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Staring noconflict support - putting $() into a namespace [reposted from Spinoffs group]
My driving reason is to let jquery developers use unittest for their unit tests as I like it a lot as a test suite. Without noConflict, the jquery app will need to use its noConflict setup, rather than Prototype using its noConflict setup. Fixing prototypes critical namespacing conflicts - the $() - method seemed a solid, clean approach. On Jan 31, 2:12 am, Tobie Langel [EMAIL PROTECTED] wrote: Well, there's more elegant ways to handle that than converting each and every call to a global than the one you're using. Using a closure could be a solution. Dean's got an interesting system in base2 for that kind of stuff:http://base2.googlecode.com/svn/trunk/src/base2/Package.js Personally, I'm not too fond of namespacing, as imho it just encourages poor coding practices. There's technically no reason afaik (except laziness maybe) to include another framework on top of Prototype (and yes, I know Digg does so - shame on them !). But I'm ready to hear any sound argument in that direction. Best, Tobie --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Staring noconflict support - putting $() into a namespace [reposted from Spinoffs group]
Alternately, can I have permission to make unittest independent of prototype? :P I did look at it _very briefly_ and realised that I just needed to cleanup the use of $. I don't mind Prototype.$ as its namespaced version. Its short and if there is no driving cause for complete refactoring to support inter- library namespacing happiness, then it seems a suitably minimal refactoring. Nic On Jan 31, 2:17 am, Dr Nic [EMAIL PROTECTED] wrote: My driving reason is to let jquery developers use unittest for their unit tests as I like it a lot as a test suite. Without noConflict, the jquery app will need to use its noConflict setup, rather than Prototype using its noConflict setup. Fixing prototypes critical namespacing conflicts - the $() - method seemed a solid, clean approach. On Jan 31, 2:12 am, Tobie Langel [EMAIL PROTECTED] wrote: Well, there's more elegant ways to handle that than converting each and every call to a global than the one you're using. Using a closure could be a solution. Dean's got an interesting system in base2 for that kind of stuff:http://base2.googlecode.com/svn/trunk/src/base2/Package.js Personally, I'm not too fond of namespacing, as imho it just encourages poor coding practices. There's technically no reason afaik (except laziness maybe) to include another framework on top of Prototype (and yes, I know Digg does so - shame on them !). But I'm ready to hear any sound argument in that direction. Best, Tobie --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Staring noconflict support - putting $() into a namespace [reposted from Spinoffs group]
Lack of namespace management is thing to be fixed, not protected as sacred. Whether its unittest or a widget that needs to coshare JavaScript-land with other widgets built ontop of other frameworks, I think it should be possible, not impossible. Nic On Jan 31, 2:50 am, Nick Stakenburg [EMAIL PROTECTED] wrote: On 30 jan, 17:22, Dr Nic [EMAIL PROTECTED] wrote: Alternately, can I have permission to make unittest independent of prototype? :P I did look at it _very briefly_ and realised that I just needed to cleanup the use of $. If multi framework unittests is what you want, you should have a look at Ext.js adapters. Writing something similar for your unittests is easier then getting every framework to implement noConflict. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Staring noconflict support - putting $() into a namespace [reposted from Spinoffs group]
/is thing to be fixed/is something to be fixed/ sorry On Jan 31, 7:53 am, Dr Nic [EMAIL PROTECTED] wrote: Lack of namespace management is thing to be fixed, not protected as sacred. Whether its unittest or a widget that needs to coshare JavaScript-land with other widgets built ontop of other frameworks, I think it should be possible, not impossible. Nic On Jan 31, 2:50 am, Nick Stakenburg [EMAIL PROTECTED] wrote: On 30 jan, 17:22, Dr Nic [EMAIL PROTECTED] wrote: Alternately, can I have permission to make unittest independent of prototype? :P I did look at it _very briefly_ and realised that I just needed to cleanup the use of $. If multi framework unittests is what you want, you should have a look at Ext.js adapters. Writing something similar for your unittests is easier then getting every framework to implement noConflict. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Staring noconflict support - putting $() into a namespace [reposted from Spinoffs group]
Right so there are some frameworks that will never work together, and there are some frameworks that could work together with a little love'n'care to prototypejs. Resolving the every framework has its own $ operator conflict is a big win, and doesn't mean prototype needs to plan to be conpatible/non- conflict with all other libraries. On Jan 31, 8:34 am, Tobie Langel [EMAIL PROTECTED] wrote: Sure. Handling namespacing inside of the global scope is one issue, and it's pretty simple to deal with... but what about extended prototypes? How am I supposed to know that some other script / lib / framework, hasn't extended Function.prototype.bind with something else, something that would *totally* break Prototype ? What's the point in handling the global scope issue if we're not handling that issue too ? And we all know what that implies. Best, Tobie Dr Nic wrote: Lack of namespace management is thing to be fixed, not protected as sacred. Whether its unittest or a widget that needs to coshare JavaScript-land with other widgets built ontop of other frameworks, I think it should be possible, not impossible. Nic On Jan 31, 2:50 am, Nick Stakenburg [EMAIL PROTECTED] wrote: On 30 jan, 17:22, Dr Nic [EMAIL PROTECTED] wrote: Alternately, can I have permission to make unittest independent of prototype? :P I did look at it _very briefly_ and realised that I just needed to cleanup the use of $. If multi framework unittests is what you want, you should have a look at Ext.js adapters. Writing something similar for your unittests is easier then getting every framework to implement noConflict. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Staring noconflict support - putting $() into a namespace [reposted from Spinoffs group]
But it doesn't have to be the $ feature - this can be cleanly noconflict-proofed; giving some useful benefits. I'm still keen to see this refactoring as I think its a Good Thing. On Jan 31, 9:17 am, Tobie Langel [EMAIL PROTECTED] wrote: Right so there are some frameworks that will never work together, and there are some frameworks that could work together with a little love'n'care to prototypejs. The question remains: how will we ever know which ones ? The frameworks which are self contained will always work. The others won't necessarily, and we don't have proper means to test which that. I'd also like to add that, afaik, the only libs concerned by $ are jQuery - which sports a noConflict mode - and mootools, which extends native prototypes about as much as we do - so there would most certainly be conflicts there. I personally don't think it is reasonable to release a feature which, by design, is and always will be incomplete. But that's just my $ .02 and isn't necessarily a view shared by everyone in core. Best, Tobie --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
