This is the easiest to use thing I've found:
https://github.com/terinjokes/docker-npmjs
On Friday, October 11, 2013 4:31:21 PM UTC+2, Timothy Rupe wrote:
I've been searching all over for a solution for this but always come
across unanswered questions, half-truths, and misinformation. I'm
The docs are broken; they are missing a `new` before `broadcast(i,
message)`.
Right now it just puts an `i` on the global scope in sloppy mode; strict
mode prevents this error.
On Thursday, October 10, 2013 2:15:16 PM UTC+2, Ket wrote:
Hello,
I try to send data with the child_process
I don't see what the problem is? You don't have to call read() immediately;
the bytes will still be there after your async processing is done.
On Monday, July 1, 2013 9:23:44 AM UTC-4, Gil Pedersen wrote:
Hi,
I have a case where I want to consume a Readable, by:
1. Read n bytes.
2.
That's overstating it a bit. It's very easy to convert to promise-based code,
e.g.:
var fs = require('fs');
var Q = require('q');
var readFile = Q.denodeify(fs.readFile);
var writeFile = Q.denodeify(fs.writeFile);
readFile('src.txt').then(function (result) { writeFile('dest.txt', result);
OAuth 2 is definitely what you're looking for. In particular it looks like
you want the Resource Owner Password
Credentialshttp://tools.ietf.org/html/rfc6749#section-1.3.3flow.
If by chance you are using Restify, I made a thing that will automatically
handle this for you:
On Thursday, April 4, 2013 11:40:54 PM UTC-4, Forrest L Norvell wrote:
However, putting everything in try/catch/finally clauses is expensive
(i.e. they can't be fully optimized by V8).
This is slightly misleading. In the following code:
```js
try {
doStuff();
} catch (e) {
// handle
This link reflects a no-longer-accepted proposal. The current thinking is
more along these lines:
http://wiki.ecmascript.org/doku.php?id=strawman:maximally_minimal_classes
but even then, that is not fully accurate. You should check the
specification drafts for actually-accurate information:
On Sunday, December 30, 2012 4:40:19 PM UTC-5, Rick Waldron wrote:
On Sunday, December 30, 2012, Tristan Slominski wrote:
RE: No one should use --harmony today anyway..
I didn't see block-scoped let in es6-shim (pretty sure that's
impossible to shim without compilation, right?), so
For me checking in a npm-shrinkwrap.json gives all of the advantages of
checking node_modules into git, with none of the drawbacks. That's my
preferred solution.
On Wednesday, December 26, 2012 7:05:45 PM UTC-5, José F. Romaniello wrote:
Hi all, I have read few times that is better to
I don't believe `require` works with absolute paths, like those generated
by path.resolve. (Could be wrong.) If I'm correct, then you may find
path.relative to be a useful method.
Also note that of course path.resolve without a second argument will
resolve relative to process.cwd(), not
An interesting alternative is to use Q’s new “nodeify” function:
function returnsPromiseOrCallsback(callback) {
return Q.resolve(5).nodeify(callback);
}
If callback is a function, it will call callback(null, 5); otherwise it will
return the promise for 5. Similarly it will pass rejection
that are tripping up the existing parser..
On Friday, October 26, 2012 10:57:06 PM UTC+7, Domenic Denicola wrote:
Very nice. As maintainer of jsdom, I've been looking for a replacement
default HTML parser that could solve many of the parsing issues we've
encountered. I'll put you
Very nice. As maintainer of jsdom, I've been looking for a replacement
default HTML parser that could solve many of the parsing issues we've
encountered. I'll put you on the shortlist. Thanks for announcing.
On Friday, October 26, 2012 6:07:48 AM UTC-4, Dean Mao wrote:
Hi All,
I created a
I summed up my experiences with writing and dealing with cross-platform
Node code in this blog post:
http://nodeblog.azurewebsites.net/how-to-write-portable-nodejs-code
Mainly it deals with gotchas I encountered and has lots of links to pull
requests I submitted to take care of them.
On
On Thursday, October 4, 2012 10:07:31 AM UTC+2, Mikeal Rogers wrote:
I totally understand what you're saying but I think there are a few things
you're missing.
The problem we had with errors in the node implementation of promises,
which was not great, was that errors were often unhandled
On Tuesday, October 2, 2012 11:44:23 PM UTC-4, Raynos wrote:
domains have a parallel to sync code. Use event emitters for your sync
flow. promises only have a parallel to sync code if you use promises for
sync async code.
By sync code I meant code with functions that return values and
On Monday, October 1, 2012 3:46:19 PM UTC-4, Mariusz Nowak wrote:
In Deferred I solved it by making end function with same signature as then:
promise.end(function (value) {
// do something with value
});
If onerror callback is not provided, eventual error will just throw. So no
3:32:13 PM UTC+2, Domenic Denicola wrote:
On Monday, October 1, 2012 3:46:19 PM UTC-4, Mariusz Nowak wrote:
In Deferred I solved it by making end function with same signature as
then:
promise.end(function (value) {
// do something with value
});
If onerror callback is not provided
jQuery promises also aren't interoperable with other promise-consuming
libraries, because they do not transform errors thrown in callbacks into
rejection reasons, violating Promises/A. So e.g.
function doOperationAndDontGiveUp(operation) {
return operation().then(null, function (error) {
exceptions into rejections, this
entire benefit is lost and you're back in traditional callback land, where
an exception inside a callback jumps all the way back up to window.onerror.
On Tuesday, October 2, 2012 10:18:42 PM UTC-4, Domenic Denicola wrote:
jQuery promises also aren't interoperable
Very cool; I'm a big fan of these kind of utilities. See e.g.
https://github.com/domenic/opener
A few points of constructive criticism:
* Putting node- in the package name is generally bad practice. As a
GitHub repo name it's fine, but in package.json it should be just
copy-paste
* Exposing
On Saturday, July 7, 2012 12:05:05 PM UTC-4, Nathan Rajlich wrote:
The trick with native addons on Windows 64-bit node is that you have to
invoke npm/node-gyp from inside a 64-bit MSVC command prompt. There's a
shortcut to in in the start menu, but it's different than both the 32-bit
MSVC
On Monday, August 6, 2012 6:03:59 AM UTC-4, mscdex wrote:
On Aug 6, 5:30 am, Domenic Denicola dome...@domenicdenicola.com
wrote:
Sorry to necromance this thread, but any ideas on how to get VC++2010
Express to do x64 things? I think the Express version only works on x86
by
default
Promises are designed to be an exact async parallel of synchronous return
values and exceptions, and so might be along the line of what you're
looking for. See
http://www.slideshare.net/domenicdenicola/callbacks-promises-and-coroutines-oh-my-the-evolution-of-asynchronicity-in-javascript
that the underlaying
connection was terminated before response.end() was called or able to
flush, which is not the case.
That's as far as documentation goes.
On Tuesday, July 10, 2012 6:48:00 PM UTC-4, mscdex wrote:
On Jul 10, 5:25 pm, Domenic Denicola dome...@domenicdenicola.com
wrote:
I am trying
Thank you! This is perfect. Still not sure exactly which events would be
most accurate (maybe connection and the resulting socket's close?), but
with this in hand I can just check the number of connections in a
setInterval, which is good enough.
On Wednesday, July 11, 2012 10:19:59 AM UTC-4,
I am trying to create a mini dashboard for my server that shows number of
unfinished requests. (BTW if there's a better term for that let me know.)
Here is what I have, but I don't think it's catching all the response
finishes:
server.server.on(request, function (request, response) {
Could someone expand on the busy loop fixes? Are they OMG I'd better
deploy this or are they very rare edge cases?
On Monday, July 9, 2012 1:25:58 PM UTC-4, Isaac Schlueter wrote:
2012.07.09, Version 0.8.2 (Stable)
* npm: Upgrade to 1.1.36
* readline: don't use Function#call() (Nathan
FWIW All the native modules I've tried fail to compile when using x64, so
there's that as a *dis*advantage.
On Saturday, July 7, 2012 12:53:49 AM UTC-4, Glenn Scott wrote:
I see there's an x64 Node executable built for Windows:
http://nodejs.org/dist/v0.8.1/x64/node-v0.8.1-x64.msi
Are
On Friday, June 29, 2012 5:23:47 AM UTC-4, mscdex wrote:
Your reference for calling req.pause() useless is a set of mailing
list posts from early last year and things have improved at least
somewhat since then. Since node 0.7.x (specifically [1]), there
shouldn't be any 'data' events
If you develop on Windows, it is very easy to accidentally do:
var Q = require(Q);
for the package named q. Similarly for modules, one could do:
var x = require(./LiB/UtiL/X);
for the module which is checked in to source control as lib/util/x (and
appears in Windows explorer lowercased as
On Friday, June 1, 2012 2:32:50 AM UTC-4, Diego Varese wrote:
I have a question regarding these requirement bundlers above mentioned. Is
there one of these that will allow me to include the separate modules
during development while using require(), and then just concat-minify all
of the
I noticed in https://github.com/joyent/node/pull/3228 TooTallNate used
__proto__ but anticipated some resistance to it. Does Node core have a
position on __proto__ vs. Object.create? I'm really just curious, and
didn't want to clog the pull request with an unrelated question.
The line in
On Monday, May 7, 2012 3:50:17 PM UTC-4, Nathan Rajlich wrote:
The reason __proto__ was used in this case was because
SlowBuffer.prototype already had properties set on it from C++-land, which
we don't want to overwrite.
Got it. I didn't quite understand what the win was, but after that
34 matches
Mail list logo
