Re: Upgrading Guides

That looks good Benn. The upgrading docs should look almost identical across platforms, and I think you've started it well (the big bold note about having to add the old core apis as plugins now). A few things that I think need doing for those docs to be complete: - Plugins need READMEs. I imagin

Re: Upgrading Guides

There is a document that talks about the cordova-cli : https://github.com/apache/cordova-docs/blob/master/docs/en/edge/guide/cli/index.md But I don't see any mention of how to install the core plugins (or any plugins...) For the windows phone upgrade guides I did something like this : https://git

Upgrading Guides

What's the story here? I assume we all have a common one, in that we require the user to install cordova-cli through npm, etc and instruct them on how to add the core plugins using this tool. Have I missed a doc somewhere already written? (probably)

3.0.0 Testing thread

So far I went and tested with the plugins (specified in the dependencies-plugin on cordova-mobile-spec) on master for iOS, with 1 test failing: File API DirectoryReader interface readEntries file.spec.109 should return an empty entry list on the second call. Expected 0 not to be 0.

Re: Getting Organized for 3.0

+1 on tagging only. BTW: In the RC stage, we should tag the plugins before the platform maintainers test so it's clear what was tested. We can re-tag a plugin if it craps the bed. It's easier than just grabbing whatever is on master at any point when reproducing and fixing the error. On Jul 15,

Re: Getting Organized for 3.0

I am having issues branching all of the repos using coho. I am going to try and fix them (issues related to grunt and cordovajs). If someone else wants to handling the branching of all repos for now, feel free. On Mon, Jul 15, 2013 at 5:09 PM, Shazron wrote: > +1 Fil > > On Monday, July 15, 201

Re: Getting Organized for 3.0

I _think_ moving to tags-only on the plugin repos would work. My thinking was that we would be way less trigger-shy with releasing minor/patch revisions of plugins than we are with the frameworks and the JS. The plugins being revisions independently doesn't introduce the same issues as cordova-js +

Re: Getting Organized for 3.0

+1 Fil On Monday, July 15, 2013, Steven Gill wrote: > Agree with Fil. We should probably stick to the apache way for now and > release source for all of the repos. > > Another question. Are we branching plugins as well? Shaz made a good point > that since we aren't developing on 3.0.x branches fo

Re: Getting Organized for 3.0

Agree with Fil. We should probably stick to the apache way for now and release source for all of the repos. Another question. Are we branching plugins as well? Shaz made a good point that since we aren't developing on 3.0.x branches for plugins, might as well just stick to only tagging plugins and

Re: Getting Organized for 3.0

While I would personally like to see that approach, in the spirit of the "apache way", I think we should still be packaging a release with a specific commit from all relevant project repos (whether they include the plugin repos or not is up for debate but I am fairly ambivalent on that topic). This

Re: tag 3.0.0rc1 on Monday the 15th

get a babycarrier :) although you would then have to type with your arms extended and further away from your screen (external keyboard I suppose) On Mon, Jul 15, 2013 at 4:26 PM, Andrew Grieve wrote: > huzzah! great. > > btw - im still learning to type with a baby in one arm :) > > that command

Re: tag 3.0.0rc1 on Monday the 15th

huzzah! great. btw - im still learning to type with a baby in one arm :) that command doesnt exist in coho. ./cordova-coho/coho repo-update -b 3.0.x -r REPOS comes close, but wont change branch if there were no changes. On Mon, Jul 15, 2013 at 7:15 PM, Steven Gill wrote: > Hey Andrew, > > I

Re: Plugin packages on Android

On Mon, Jul 15, 2013 at 5:23 PM, Brian LeRoux wrote: > A package namespace is not a part of the API? Are we saying we in > Cordova draw the semantic line at a method signature? (Its certainly > not a normal view on what defines an API. Anyhow! Super not > important.) > > One more time! Specifics.

Re: tag 3.0.0rc1 on Monday the 15th

Hey Andrew, I posted in here before reading the getting organized for 3.0 thread. I retract my statement that every plugin needs issues and agree with plugins being tested by platform maintainers before they tag their respective platforms. I created one issue to tag all of the plugins once platfor

Re: tag 3.0.0rc1 on Monday the 15th

So, since we're stuck with coho if we want to get this done this week, how do you get coho to check out a branch of all the plugins? On Mon, Jul 15, 2013 at 4:10 PM, Andrew Grieve wrote: > On Mon, Jul 15, 2013 at 5:22 PM, Steven Gill wrote: > >> We will need to add issues for tagging plugins. >

Re: tag 3.0.0rc1 on Monday the 15th

On Mon, Jul 15, 2013 at 5:22 PM, Steven Gill wrote: > We will need to add issues for tagging plugins. What's your reasoning? > I can create the issue and > tag the plugins. I figure for now, plugins will use same tagging process as > other repos. > And that process is? For the RC - it's triv

Re: Getting Organized for 3.0

I have gone ahead and branched + tagged cordova-js, mobile-spec and app-hello-world using coho. On Mon, Jul 15, 2013 at 2:32 PM, Brian LeRoux wrote: > I'd like to add to that the release would probably be best served as > just shipping cordova-cli instead of all the build artifacts that > reali

Re: Post 3.0 release committer and community meeting

Definitely a good idea. Sent from my BlackBerry 10 smartphone. From: Brian LeRoux Sent: Monday, July 15, 2013 5:45 PM To: dev@cordova.apache.org Reply To: dev@cordova.apache.org Subject: Post 3.0 release committer and community meeting Hey everyone, we're in the final stretch to releasing 3.0 an

Post 3.0 release committer and community meeting

Hey everyone, we're in the final stretch to releasing 3.0 and I think long past due to have an open discussion w/ the committership and larger community. I think we should let the dust settle from 3.0 for a couple of weeks before having this meeting. I'd like to propose the week of August 12th. If

Re: Intel app framwork

Hey Loic! Sorry this list is for the development of Cordova itself not apps built using Cordova (or a downstream distribution like AppMobi or whatevs.) On Sat, Jul 13, 2013 at 5:50 AM, Loic Pfister wrote: > Hello, > > I am not sure it is the right place to ask this but I have just played around

Re: Getting Organized for 3.0

I'd like to add to that the release would probably be best served as just shipping cordova-cli instead of all the build artifacts that realize the cordova-cli interface. Thoughts? On Mon, Jul 15, 2013 at 1:58 PM, Brian LeRoux wrote: > That sounds better to me. Steve is going to verify and tag

Re: Getting Organized for 3.0

This all sounds good to me. So once the platforms are tagged, we use coho to bulk tag the plugins. No need to create issues for tagging each plugin in Jira. We should get this train rolling. Cordova-js ready to tag? On Mon, Jul 15, 2013 at 1:58 PM, Brian LeRoux wrote: > That sounds better to m

Re: Plugin packages on Android

A package namespace is not a part of the API? Are we saying we in Cordova draw the semantic line at a method signature? (Its certainly not a normal view on what defines an API. Anyhow! Super not important.) One more time! Specifics. What packages are changing in precisely what files? Right now we'

Re: tag 3.0.0rc1 on Monday the 15th

We will need to add issues for tagging plugins. I can create the issue and tag the plugins. I figure for now, plugins will use same tagging process as other repos. On Mon, Jul 15, 2013 at 12:02 PM, Filip Maj wrote: > Created the issues: https://issues.apache.org/jira/browse/CB-4208 > > On 7/15/

Re: Plugin packages on Android

OK, Test killed. I get the same thing on this end. Let's close that bug off! On Mon, Jul 15, 2013 at 2:04 PM, Joe Bowser wrote: > I'm going to kill that test! This is the Cordova project, not JQMobile. > > On Mon, Jul 15, 2013 at 1:45 PM, Andrew Grieve wrote: >> Awesome. So for UriResolvers, I

Re: FileTransfer plugin broken

The fix is here: https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-file-transfer.git;a=commitdiff;h=34fd9247ff6992f0b4ae0d1e61516ff52bc7aed8;hp=d39016ecb216b7f317ac6c76b2dcf4e11d34b69c On Mon, Jul 15, 2013 at 4:22 PM, David Kemp wrote: > I have not. its all yours > > > > On Mon, Jul 15,

Re: Plugin packages on Android

I'm going to kill that test! This is the Cordova project, not JQMobile. On Mon, Jul 15, 2013 at 1:45 PM, Andrew Grieve wrote: > Awesome. So for UriResolvers, I just checked in another revision today, and > I'm not happy with it and all that's left is documentation. If you wanted > to do a code re

Re: Getting Organized for 3.0

That sounds better to me. Steve is going to verify and tag the plugin repos to 3.0.0 today. The tacit agreement we've been discussing was that plugins would then only be updated tag wise when they themselves are updated. On Mon, Jul 15, 2013 at 1:41 PM, Andrew Grieve wrote: > On Mon, Jul 15, 201

Re: Plugin packages on Android

Awesome. So for UriResolvers, I just checked in another revision today, and I'm not happy with it and all that's left is documentation. If you wanted to do a code review on it, that would be cool too. I also ran the junit tests (as of an hour ago), and the only test that fails is the JQMTabTest, w

Re: Getting Organized for 3.0

On Mon, Jul 15, 2013 at 3:48 PM, Joe Bowser wrote: > On Mon, Jul 15, 2013 at 12:34 PM, Andrew Grieve > wrote: > > We really need to have a plan for this release, so here goes: > > > > 1. How to tag plugins: > > - Voting via tagging won't work here since each plugin has multiple > > platforms. >

Re: FileTransfer plugin broken

I have not. its all yours On Mon, Jul 15, 2013 at 4:20 PM, Bryan Higgins wrote: > Looks like a merge problem. I'll fix it. Did anyone open an issue? > > > On Mon, Jul 15, 2013 at 3:43 PM, Andrew Grieve > wrote: > > > It should use a relative require: require('./FileTransferError') > > > > > >

Re: FileTransfer plugin broken

Looks like a merge problem. I'll fix it. Did anyone open an issue? On Mon, Jul 15, 2013 at 3:43 PM, Andrew Grieve wrote: > It should use a relative require: require('./FileTransferError') > > > On Mon, Jul 15, 2013 at 3:28 PM, David Kemp wrote: > > > the commit a few hours ago : > > > > > > >

Re: Bash command-line completion for CLI

Sweet ! I was thinking on doing this also. Thanks! I saved it as a gist for now. I also have the same for git commands if someone is interested https://gist.github.com/csantanapr I see that the one I have for git use "complete -o default -o nospace -F" Ian Do you know what - default and - nospa

Re: Outstanding Tasks

I'm taking care of: https://issues.apache.org/jira/browse/CB-4057 I've already deferred or delegated everything else. On Mon, Jul 15, 2013 at 12:57 PM, Shazron wrote: > I'm taking care of this: > https://issues.apache.org/jira/browse/CB-4199 > > Resolving or deferring these as well: > https://is

Re: Plugin packages on Android

I feel like Android is in good shape for the most part, but I can't say the same about the plugins or the CLI that I'm currently using to load them, since I haven't tested today's changes yet. That being said, I think you guys have some open issues still, like the UriResolvers, and I did see a jUn

Re: Outstanding Tasks

I'm taking care of this: https://issues.apache.org/jira/browse/CB-4199 Resolving or deferring these as well: https://issues.apache.org/jira/browse/CB-3530 https://issues.apache.org/jira/browse/CB-4136 On Mon, Jul 15, 2013 at 12:43 PM, Andrew Grieve wrote: > There are 167 "3.0" JIRA issues. >

Re: Outstanding Tasks

I'm in maintenance mode on the cli and plugman. Nothing critical for the release, just keeping an eye on issues and trying to patch / solve bugs / help folk. Always stuff to improve, esp. Windows support! On 7/15/13 12:43 PM, "Andrew Grieve" wrote: >There are 167 "3.0" JIRA issues. > >https://is

Re: Getting Organized for 3.0

On Mon, Jul 15, 2013 at 12:34 PM, Andrew Grieve wrote: > We really need to have a plan for this release, so here goes: > > 1. How to tag plugins: > - Voting via tagging won't work here since each plugin has multiple > platforms. > - Let's create a sub-task for each plugin, and have each platform a

Re: Getting Organized for 3.0

Comments in-line. >We really need to have a plan for this release, so here goes: > >1. How to tag plugins: >- Voting via tagging won't work here since each plugin has multiple >platforms. >- Let's create a sub-task for each plugin, and have each platform add a >comment to the sub-task when they ha

Re: Plugin packages on Android

Joe - what non-polish items are left for Android? If you're feeling like you have too much to do this week, maybe you can delegate some tasks? On Mon, Jul 15, 2013 at 3:27 PM, Filip Maj wrote: > I think what you're saying Andrew is true under the assumption that > plugins are ONLY consumed via

Outstanding Tasks

There are 167 "3.0" JIRA issues. https://issues.apache.org/jira/issues/?jql=project%20%3D%20CB%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%20%223.0.0%22%20ORDER%20BY%20priority%20DESC Like every release, they are not all going to get finished and some will be pushed to 3.1. I

Re: FileTransfer plugin broken

It should use a relative require: require('./FileTransferError') On Mon, Jul 15, 2013 at 3:28 PM, David Kemp wrote: > the commit a few hours ago : > > > https://github.com/apache/cordova-plugin-file-transfer/commit/d39016ecb216b7f317ac6c76b2dcf4e11d34b69c > > Specifies the > > FileTransferError

Getting Organized for 3.0

We really need to have a plan for this release, so here goes: 1. How to tag plugins: - Voting via tagging won't work here since each plugin has multiple platforms. - Let's create a sub-task for each plugin, and have each platform add a comment to the sub-task when they have "signed off" on it. Onc

FileTransfer plugin broken

the commit a few hours ago : https://github.com/apache/cordova-plugin-file-transfer/commit/d39016ecb216b7f317ac6c76b2dcf4e11d34b69c Specifies the FileTransferError = require('org.apache.cordova.core.FileTransfer.FileTransferError'), Which doesn't work since thats not where it is. I am assuming

Re: Plugin packages on Android

I think what you're saying Andrew is true under the assumption that plugins are ONLY consumed via the JS api. I'm not sure whether that assumption is correct in all cases. In any case, clarifying this point (dependency "scope" we could call it, perhaps?) seems like a good idea. On 7/15/13 12:14 P

Re: Plugin packages on Android

On Mon, Jul 15, 2013 at 12:14 PM, Andrew Grieve wrote: > -1 to shims. A plugin's java package name shouldn't be considered a part of > its API. That's why there is a mapping in the config.xml. > > Shouldn't have to change any require() statements, or any JS at all. Those > use plugin IDs, not java

Re: Plugin packages on Android

-1 to shims. A plugin's java package name shouldn't be considered a part of its API. That's why there is a mapping in the config.xml. Shouldn't have to change any require() statements, or any JS at all. Those use plugin IDs, not java namespaces. Replace-all on the package statement at the top of

Re: tag 3.0.0rc1 on Monday the 15th

Created the issues: https://issues.apache.org/jira/browse/CB-4208 On 7/15/13 11:56 AM, "Joe Bowser" wrote: >So, for tagging today, can we get the issues setup and the JS tagged >at least? We can somehow muddle through this RC1. > >On Mon, Jul 15, 2013 at 9:48 AM, Brian LeRoux wrote: >> I'd say

Re: Plugin loading times - Android

On a related note, there is a plugin loading time (iOS native) timing reports, only for startup plugins though: https://github.com/apache/cordova-ios/blob/c24b6e3ac8f4240f75921142fd9d4f6b6d1a50d7/CordovaLib/Classes/CDVViewController.m#L364-L374 Implemented for this issue: https://issues.apache.or

Re: tag 3.0.0rc1 on Monday the 15th

So, for tagging today, can we get the issues setup and the JS tagged at least? We can somehow muddle through this RC1. On Mon, Jul 15, 2013 at 9:48 AM, Brian LeRoux wrote: > I'd say we could consider the core plugins as build ephemera not > unlike docs or automations. Really cordova-cli is the ma

Re: Plugin packages on Android

+1 wait until 3.1. +1 add shims for less breakage Also worth pointing out that we'll need to add this to the deprecation list on the wiki On 7/15/13 11:30 AM, "Simon MacDonald" wrote: >The reason things broke back then was we didn't leave in shims to point >anyone compiling against com.phonega

Re: Wondering what folks think about the default project

But that would kill config.xml. I agree about not wanting to go down the road of making everyone happy. Right now though I think we can please 2 folks - the brand new folks (with the default hello world) and those who are experienced (bare bones mostly empty index.html). On 7/13/13 11:41 AM, "An

Re: Wondering what folks think about the default project

Michael, tell me how you feel after you *aren't* a new user. ;) That was my point. The project is cool when you start, but after that, it is just clutter imo. On 7/12/13 12:26 AM, "Michael Jackson" wrote: >I really like the default app. As a brand new cordova dev it helped me >understand how to

Re: Plugin loading times - Android

I did not automate the process, I wrote a quick tool to cat all the js files together, then modified a few lines of code for each test run. It was not the intention to leave this in the codebase. I am planning on running the same tests on iOS, and can provide the detail of the process i used. On

Re: Bash command-line completion for CLI

Thanks Ian! Make that three beers coming your way On 7/15/13 9:42 AM, "Brian LeRoux" wrote: >Oh this rules, thanks so much Ian, I'll add to those beers! > >On Mon, Jul 15, 2013 at 9:33 AM, Michael Brooks > wrote: >> Beautiful Ian! >> >> This has been on my backlog of tasks, so I'm happy to see t

Re: Plugin tag

Which options, 1 or 2? On 7/15/13 9:22 AM, "Max Woghiren" wrote: >Just a heads up‹I plan to make this change and I will make the appropriate >documentation updates. > > >On Tue, Jul 9, 2013 at 4:15 PM, Filip Maj wrote: > >> 2 is more explicit. Either case require a good docs update. >> >> On 7/

Re: Plugin loading times - Android

Yep, Andrew's summary sounds about right. Interesting that XHR vs. script tag injection leads to such differences. I would be interested to see these same tests run on iOS, BB10, WP7+8 devices. David did you happen to automate these steps somehow ? I wouldn't mind running these tests on other de

Re: Plugin packages on Android

The reason things broke back then was we didn't leave in shims to point anyone compiling against com.phonegap.api to org.apache.cordova.api. That was quickly corrected. I agree with the package name change but with 3.0 shipping this week(?). It should probably wait until the next version. Simon

Re: Plugin packages on Android

Yea, to be clear, I'm in favor of namespaces. They're a honking good idea. But lets push this to 3.1 and leave shims around until 3.5/3.6 as per our deprecation policy. On Mon, Jul 15, 2013 at 11:16 AM, Steven Gill wrote: > This will involve changing all of the plugin.xml files as well as any >

Re: Plugin packages on Android

If you guys are uncomfortable with it, it should wait. I don't think it's a huge priority anyway. On Mon, Jul 15, 2013 at 11:16 AM, Steven Gill wrote: > This will involve changing all of the plugin.xml files as well as any > require statements in the javascript files of those plugins. Seems like

Re: Plugin packages on Android

This will involve changing all of the plugin.xml files as well as any require statements in the javascript files of those plugins. Seems like a lot of work to squeeze in for 3.0 On Mon, Jul 15, 2013 at 11:14 AM, Joe Bowser wrote: > Can we NOT do this now? We have in reality three days of dev l

Re: Plugin packages on Android

Can we NOT do this now? We have in reality three days of dev left before we release 3.0. We don't have time for these last minute changes, no matter how trivial. On Mon, Jul 15, 2013 at 11:12 AM, Max Woghiren wrote: > I am proposing we change all of the Android plugins in Cordova 3.0 to > belon

Re: Plugin packages on Android

I am proposing we change all of the Android plugins in Cordova 3.0 to belong in individual packages. For instance, the FileTransfer plugin, which currently exists in the org.apache.cordova.core package, should be moved to, say, org.apache.cordova.plugin.filetransfer. Every plugin should be moved

Re: Plugin packages on Android

No. You are proposing an API change. A package is most certainly a part of the API! When we moved from `com.phonegap` to `org.apache` there was a huge outcry b/c it broke all existing community plugins. I'm completely open to changing stuff for 3.0 but, again, what specifically are you proposing w

Re: Plugin packages on Android

I agree. The only downside I see is that it will be hard to dissociate core plugins from other but I don't think it's really that important. Also because it's not a giant change it could happen for 3.0. On Mon, Jul 15, 2013 at 10:33 AM, Max Woghiren wrote: > I'm not proposing any API changes in

Re: Plugin packages on Android

I'm not proposing any API changes in this email; example (1) does mention the relocation of FileHelper.java, but that's more to illustrate the benefits of repackaging the plugins. I would think the plugin package change should happen *for* 3.0, before people actually start using the plugins all bu

Re: Plugin packages on Android

I think all of this makes good sense but will have to land sometime post 3.0 as that we're pretty much in the final stretch now anyhow. Which APIs are you specifically proposing we change? On Mon, Jul 15, 2013 at 9:14 AM, Max Woghiren wrote: > On Android, all Cordova plugins are in the package

Re: tag 3.0.0rc1 on Monday the 15th

I'd say we could consider the core plugins as build ephemera not unlike docs or automations. Really cordova-cli is the main point of interaction between us and our developer community. On Mon, Jul 15, 2013 at 9:03 AM, Andrew Grieve wrote: > The Apache Way was a part of what I was thinking as wel

Re: Bash command-line completion for CLI

Oh this rules, thanks so much Ian, I'll add to those beers! On Mon, Jul 15, 2013 at 9:33 AM, Michael Brooks wrote: > Beautiful Ian! > > This has been on my backlog of tasks, so I'm happy to see that you've > spearheaded it. > > I'll give the completion and shot and see how it works. I'll also buy

Re: Bash command-line completion for CLI

Beautiful Ian! This has been on my backlog of tasks, so I'm happy to see that you've spearheaded it. I'll give the completion and shot and see how it works. I'll also buy you a beer if you're coming to Portland this week! Michael On Mon, Jul 15, 2013 at 7:59 AM, Ian Clelland wrote: > Thanks,

Re: Plugin tag

Just a heads up—I plan to make this change and I will make the appropriate documentation updates. On Tue, Jul 9, 2013 at 4:15 PM, Filip Maj wrote: > 2 is more explicit. Either case require a good docs update. > > On 7/9/13 12:57 PM, "Andrew Grieve" wrote: > > >Another use-case that's come up w

Plugin packages on Android

On Android, all Cordova plugins are in the package org.apache.cordova.core. It makes sense to put each plugin into its own package. Aside from 3.0's conceptual shift into "plugins as completely individual entities" and the fact that plugins aren't really "core", here's some rationale: 1. If t

Re: Plugin loading times - Android

Thanks for looking into this David! To summarize your results - it looks like: a) For some reason moving the script tag being injected instead of using an XHR made loading faster b) Having all plugin files being loaded separately *is* slowing our start-up time down, but not by enough that it's an

RE: restructuring guide content in doc

Yes, I also understand idea (1) to be out of scope, which is whatever content is in "edge," and see (2) as depending on (1). --Mike S From: Marcel Kinard [cmarc...@gmail.com] Sent: Monday, July 08, 2013 2:51 PM To: dev@cordova.apache.org Subject: Re: res

Re: tag 3.0.0rc1 on Monday the 15th

The Apache Way was a part of what I was thinking as well. Also - it occurs to me that we'll have to change our voting system when it comes to plugins since each plugin repo should have a +1 from each platform maintainer, and can be tagged only once. On Fri, Jul 12, 2013 at 12:53 PM, Joe Bowser

Re: Android - Webview Method on WebViewCoreThread Warning

Raise an enhancement request for that bit. The default is for clearCache to include the disk files. Simon Mac Donald http://hi.im/simonmacdonald On Thu, Jul 11, 2013 at 4:46 PM, Andreas Sander wrote: > Maybe you should also allow to clear only RAM Cache by controlling the > boolean parameter o

Re: codova-mobile-spec test case contacts.spec.21

Sorry for bringing this up really late -- We discovered that issue as well; the code was previously implemented for iOS, so we concluded that the test was correct, and the Android implementation was just lacking support. It was logged as CB-4084, and David fixed it last week for 3.0.0. Ian On

Re: Bash command-line completion for CLI

Thanks, guys! Let me know what's broken :) Ian On Mon, Jul 15, 2013 at 8:52 AM, Lucas Holmquist wrote: > coolio, i will be trying this > On Jul 15, 2013, at 1:06 AM, Kerri Shotts wrote: > > > > > Nice! I'll definitely be trying it out on my system! > > > > > > > > > > > > ___

Review Request 12548: Unify whitelist implementations: Android implementation

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12548/ --- Review request for cordova. Repository: cordova-android-git Description -

Plugin loading times - Android

The following are obtained by running the mobilespec suite - all tests The tests were run on a physical nexus 7 Summary: * on Android , removing the xhr trims off about 250ms on load of mobilespec. * the multi-file plugin loading takes about 1.6 times as long as a single file Details In each case

Re: Bash command-line completion for CLI

coolio, i will be trying this On Jul 15, 2013, at 1:06 AM, Kerri Shotts wrote: > > Nice! I'll definitely be trying it out on my system! > > > > > > ___ > Kerri Shotts > photoKandy Studios, LLC > > On the Web: [http://www.photokandy.com/: