Here is my test code (to be run using node --harmony-proxies foo.js:
var a = Proxy.create({
get : function (proxy, prop)
{
return 5
}
})
console.log(a['foo'])
console.log(a.length)
console.log(a['10'])
console.log(a[10])
Why the last 2 lines fail to print 5, why the proxy fails to intercept properties looking like integers? Is it an implementation bug or is it how it is specified? Is there a separate way to intercept array indices so I can implement my own arrays (e.g. sparse arrays)?
If I read the node changelogs correctly, then node 0.6.18 is still running on V8 3.6.6, which is a fairly old version (from October 2011). In that version, support for proxies was still work in progress (as the other supported Harmony features). Don't expect proxies to function properly before V8 3.8 (from December 2011). Unfortunately, I cannot tell you when the stable version of node will upgrade beyond that.
As A. Rossberg indicated, that bug (and a couple of other showstoppers) are fixed in V8 3.8 (node 0.7.x is quite stable and 0.8.x nears release). If you're working with proxies though, there's still some bugs that you'll have to watch out for. This github issue has a pretty good quick overview of them: https://github.com/tvcutsem/harmony-reflect/issues/4
Related
I have a code running in Node 9.8
Node 9 will reach End-of-life soon.
If I switch to node 10, how can I check if my code will run in node 10 without having to execute all paths of the code ?
Or if I go down to 8.11, how can I check if my code will run in node 8.11 ?
There is no test cases written on the code.
This is a good example of why solid unit/integration tests are critical to long-term maintainability. That said, there are a few steps you can take to reduce the risk of breaking things:
Take a look at the change logs pertaining to the versions you're moving to/from. The NodeJS team kindly includes a Notable Changes section in each change log, though I wouldn't rely on that alone as being 100% inclusive of the potentially breaking changes you may be up against.
Consider writing unit/integration tests, both as part of your assurance that things won't break from this version change, as well as that things won't break from later version changes (or everyday changes for that matter).
As much as I hate to say it, Googling around for guides on upgrading (or downgrading?) NodeJS versions may help you identify potential danger zones.
Generally, I'd consider it safer and better practice to upgrade the version than downgrade. For one, you're moving forward to the newer and greater experience the NodeJS team wants you work with, and secondly, future versions are probably more likely to be backwards compatible, whereas the old version may be missing features you're using.
I have a website I'm developing. I try to use SEMVER with any changes I make. Sometimes I'm not sure when I need to bump up the minor version. For example,
I have my website/app at v0.9.0. I have this deployed on a production site. One day, I decide to add some new functionality to the website. I add my new functionality, test it and deploy it and it works great. Since this is not a bug fix, does that mean I need to go from v0.9.0 to v1.0.0? So essentially, if I'm at vX.0.0, it only takes 10 new features to be independently added (no matter the size) in order to go to version X+1 ?
It seems like there should be some way to incrementally increase the minor version. I see a lot of people do v0.10.0 as the next version.
Is that the recommended way to do it?
No Jake, it does not mean you need to go to version 1.0.0. The next minor version after version 0.9.0 would be 0.10.0.
See https://docs.npmjs.com/getting-started/semantic-versioning for a nice intro.
Currently I need to resort in a sparse solver for a project. However I use an old version of Eigen3 on Ubuntu 12.04 (during the thesis I avoid unnecessary updates/upgrades), which means that all the information that I find online cannot be used at the moment because of my outdated version, while the few unsupported tools of my version are very hard to use (weird compilation errors - e.g. with unsupported/Eigen/SparseExtra)
I think that I should upgrade to the last stable version, however it is very critical that I will be able to replicate the numbers of all the experiments that I got with the current outdated version. Is Eigen safe when it comes to backwards compatibility?
Eigen is also a dependency for PCL that I'm using, so I'm not sure if this complicates things. Everything is installed with apt-get. Linking to a new version of Eigen locally for experimentation is not possible, because PCL complains and expects to find Eigen installed globally (i.e. in /usr/local/include).
Eigen is source (API) and binary (ABI) backward compatible (of course, except for unsupported/*). However, the numerical results might be slightly different due to different rounding errors, but that's already the case when, e.g., enabling/disabling SSE or OpenMP.
Since Eigen is header only, it is very easy to try the newest version.
Node.JS v0.11.3 claims to have support for ECMAScript 6 modules with the flag --harmony_modules.
I have tried various examples, such as the following.
module math {
export var pi = 3.141593;
}
What is the syntax to get modules working in Node.JS?
The modules implementation in V8 is incomplete. There's parsing support when enabled with --harmony-modules, but support of the actual functionality was put on hold. The reason for this is because the specification for how ES6 modules will actually work has been in the works and is still not fully nailed down.
The implementation in Continuum (the linked screenshot from Crazy Train's answer) dates back to an interim spec from November 2012 and is now woefully out of date because of the ongoing changes to the ES6 module's spec. This is why the V8 devs put development of support for modules on hold.
It seems like the modules spec is approaching stability (though I expect we'll see small refinements for a while) and I think (hope at least) that we'll see SpiderMonkey and V8 moving forward with implementations over the next 6 months.
Useful links:
V8 modules bug: https://code.google.com/p/v8/issues/detail?id=1569
SpiderMonkey modules bug: https://bugzilla.mozilla.org/show_bug.cgi?id=harmony%3Amodules
You can use Continuum, which is an ES6 virtual machine written in (current) JavaScript.
I've just inherited an application written in Groovy (version 1.3.5) and would like to upgrade it to the newest release (version 1.7.5).
I can't seem to find a reference that enumerates the differences in syntax, etc., which I would need to be aware of ... and yes, I looked at http://groovy.codehaus.org
Does anyone know of a good place that lists version changes?
Many thanks,
~Aki
I think your best bet would be to try it and see where your tests fail.
You do have tests right? ;-)
If not, I'd write some, then try the upgrade and fix where needed.
I don't believe there is a single page where you'd find all the changes from one version to another.
You could maybe collate something by going through all the release notes, but it's probably quicker to just try it.
You can find the changes from one version to another by looking at the release notes. However, the release notes only describe the changes from version N to version N + 1. I don't know how many versions there were between 1.3.5 and 1.7.5, but I'd guess at least 10.
To discover all the changes between 1.3.5 and 1.7.5, you'll have to look at the release notes for each release. Starting from this page, you should be able to find them all, here are some links to get you started.
1.7.5
1.7.4
1.6.9
1.6.8
1.5.8
You should be able to get older releases (and their notes) from the distribution archive.
Having said all that, reading release notes doesn't guarantee anything, (though it's a good way to learn about new features). The only way to be sure that your code runs under the newest version is to compile and test it under that version.