Thanks, I was waiting for Andrew's approval.
Issue #CB-6745, opened and closed
@purplecabbage
risingj.com
On Fri, May 23, 2014 at 7:42 AM, Andrew Grieve wrote:
> Yes, should be safe to remove the flag.
>
>
> On Thu, May 22, 2014 at 7:58 PM, Michal Mocny wrote:
>
> > I just removed them local
Yes, should be safe to remove the flag.
On Thu, May 22, 2014 at 7:58 PM, Michal Mocny wrote:
> I just removed them locally and you are right, they are no longer needed.
> SGTM.
>
>
> On Thu, May 22, 2014 at 7:43 PM, Jesse wrote:
>
> > coho has the --harmony-generators directly in the coho bas
I just removed them locally and you are right, they are no longer needed.
SGTM.
On Thu, May 22, 2014 at 7:43 PM, Jesse wrote:
> coho has the --harmony-generators directly in the coho bash script [1], and
> the coho.cmd file. [2]
>
> On windows, I need to remove --harmony-generators from [1] if
coho has the --harmony-generators directly in the coho bash script [1], and
the coho.cmd file. [2]
On windows, I need to remove --harmony-generators from [1] if I am running
from a git-bash terminal, and from [2] if I am running from cmd. Both break
execution in node v0.10.22, so I would like to r
RE: gnode, Awesome.
RE: --harmony-generators, not sure what you mean. Did you add that
manually to your local node flags? I no longer need to do anything to my
environment for coho to run, and I don't much care that coho uses magic
from the future.
-Michal
On Thu, May 22, 2014 at 6:03 PM, Jes
gnode seems good on windows
Can I remove the --harmony-generators then?
Or do I need to make a new root command?
noho, windoho, woho, fauxho ?
@purplecabbage
risingj.com
On Thu, May 22, 2014 at 2:47 PM, Michal Mocny wrote:
> ..but I haven't tested gnode on windows, sorry.
>
>
> On Thu, May 2
..but I haven't tested gnode on windows, sorry.
On Thu, May 22, 2014 at 5:47 PM, Michal Mocny wrote:
> I no longer use node 0.11 and coho runs fine on 0.10 thanks to gnode.
>
> nvm/nave aren't necessary at all (I think), especially now that we don't
> need to switch node versions just for coho,
I no longer use node 0.11 and coho runs fine on 0.10 thanks to gnode.
nvm/nave aren't necessary at all (I think), especially now that we don't
need to switch node versions just for coho, they are just convenient if you
want to jump around environments or lack permissions to do global installs.
Ye
Reviving this thread ...
ping!
Is the only reason we depend on node v0.11 to support 'yield'?
also:
Has anyone managed to run this on windows? Not having good luck with nave
or nvm
@purplecabbage
risingj.com
On Thu, May 15, 2014 at 9:40 AM, Steven Gill wrote:
> Don't you guys just love
Don't you guys just love these dropped emails :)
On May 15, 2014 6:47 AM, "Brian LeRoux" wrote:
> https://github.com/TooTallNate/gnode/blob/master/README.md
> On May 7, 2014 1:18 PM, "Michal Mocny" wrote:
>
> > Damnit. Perplexing choice. Coho isn't released to end users, and the
> > codebase i
Yes, I agree it is much cleaner with everything broken out into modules.
And I agree that we can be a bit more flexible as this is a tool that we
use, and not a tool that our users use.
Is the only reason we depend on node v0.11 to support 'yield'? Because I
can live without that portion of the r
OK, so here is the thing:
We need to be able to be release. Having to use a particular dev version of
node is unacceptable, especially since the tests don't work with the most
recent version of the dev branch of node. (0.11.13)
Saying "it works on my machine" is unacceptable as well, since you're
https://github.com/TooTallNate/gnode/blob/master/README.md
On May 7, 2014 1:18 PM, "Michal Mocny" wrote:
> Damnit. Perplexing choice. Coho isn't released to end users, and the
> codebase is tremendously cleaner and more maintainable now. On the other
> hand, doing release testing using develop
One thing is for sure, the new coho is way better than the old coho.
Fingers crossed for 0.12
On Tue, May 6, 2014 at 7:48 PM, Michal Mocny wrote:
> Damnit. Perplexing choice. Coho isn't released to end users, and the
> codebase is tremendously cleaner and more maintainable now. On the other
Seems we have a happy ending here. Ran into this on the weekend:
https://github.com/TooTallNate/gnode
Added it in and now coho "just works" with v0.10 or v0.11 of node. It adds
about 2 seconds of start-up latency for v0.10, but at least it works.
On Mon, May 12, 2014 at 9:34 AM, Michal Mocny w
Heads up: I tried to publish an npm package with node 0.11 last week and it
did not go well. Published without error, but then you couldn't install on
node 0.10 without a checksum failure. Seems brittle/bug on the part of
npm, but it does mean we should be very careful not to use 0.11 to publish
Damnit. Perplexing choice. Coho isn't released to end users, and the
codebase is tremendously cleaner and more maintainable now. On the other
hand, doing release testing using development version of node does seem odd.
One possible solution, for now, is nvm supports changing the version for a
g
I'd like to see platforms release process be more like plugins/tools in
that it doesn't use a does-a-lot-of-stuff coho command. Feel free to write
a new process.
Possible that we could make coho work via traceur. Feel free to take a stab
at it if you'd like.
If things are failing with v0.11, we s
I got excited and tried to use the latest version of coho but when I saw
that it was using an odd version I just gave up.
On Tue, May 6, 2014 at 4:11 PM, Steven Gill wrote:
> Thanks for sharing Martin!
>
> I also am on the train that we shouldn't be using unstable versions of
> node. I don't kn
Thanks for sharing Martin!
I also am on the train that we shouldn't be using unstable versions of
node. I don't know if the landscape has changed since I started using node,
but I was always taught to stick to even version numbers.
On Tue, May 6, 2014 at 4:03 PM, Martin Gonzalez Glez <
martin.c.
Agree guys we shouldn't be depending on unstable node versions to work,
just sharing what it worked for me. I think coho has been using node 0.11
since the last clean up a few days ago.
Hey Joe, I've just shared with you my findings, it's not the best solution
I know that, but it worked for me.
On
OK, so using 0.11.12 does work to get coho working. Does anyone other
than me think that this is completely stupid?
On Tue, May 6, 2014 at 3:47 PM, Jesse wrote:
> We shouldn't be depending on unstable versions of node, imo.
> Being able to switch versions is not a solution.
>
> @purplecabbage
>
We shouldn't be depending on unstable versions of node, imo.
Being able to switch versions is not a solution.
@purplecabbage
risingj.com
On Tue, May 6, 2014 at 3:40 PM, Martin Gonzalez Glez <
martin.c.glez.g...@gmail.com> wrote:
> I had the same problem with nodejs 0.11, using url.parse module
On Tue, May 6, 2014 at 3:40 PM, Martin Gonzalez Glez
wrote:
> I had the same problem with nodejs 0.11, using url.parse module & and
> running the Unit Test on cordova-js, those are failing with nodejs 0.11.13,
> but with 0.11.12 it works fine.
>
> Nodejs 0.11 it's working unestable, they are goin
I had the same problem with nodejs 0.11, using url.parse module & and
running the Unit Test on cordova-js, those are failing with nodejs 0.11.13,
but with 0.11.12 it works fine.
Nodejs 0.11 it's working unestable, they are going to release one more
11.xx version before nodejs 0.12 (According to t
Hey
I know that for some reason, we decided to use node 0.11 for coho, but
the thing is that it means that we can't run the Unit Tests on
cordova-js now. At least on my machine, coho will now always fail
because of either named branch errors or Unit Test errors. This seems
to be some weird unico
26 matches
Mail list logo
