[nodejs] Re: Version 0.7.12 (last one before 0.8.0)
Hi, I am currently experimenting with domains in a storage-library that provides me with a uniform interface to s3, memcache, files, mongo, et. al. It is an awesome feature, that allows for much easier error handling and enables me to centralize error-reporting in a structured and easy way. Regards, Phil On Wednesday, June 20, 2012 1:31:28 AM UTC+2, Isaac Schlueter wrote: > > 2012.06.19, Version 0.7.12 (unstable) > > This is the last release on the 0.7 branch. Version 0.8.0 will be > released some time later this week, barring any major problems. > > As with other even-numbered Node releases before it, the v0.8.x > releases will maintain API and binary compatibility. > > The major changes between v0.6 and v0.8 are detailed in > https://github.com/joyent/node/wiki/API-changes-between-v0.6-and-v0.8 > > Please try out this release. There will be very virtually no changes > between this and the v0.8.x release family. This is the last chance > to comment before it is locked down for stability. The API is > effectively frozen now. > > This version adds backwards-compatible shims for binary addons that use > libeio and libev directly. If you find that binary modules that could > compile on v0.6 can not compile on this version, please let us know. > Note that libev is officially deprecated in v0.8, and will be removed > in v0.9. You should be porting your modules to use libuv as soon as > possible. > > V8 is on 3.11.10 currently, and will remain on the V8 3.11.x branch for > the duration of Node v0.8.x. > > > * npm: Upgrade to 1.1.30 > - Improved 'npm init' > - Fix the 'cb never called' error from 'oudated' and 'update' > - Add --save-bundle|-B config > - Fix isaacs/npm#2465: Make npm script and windows shims cygwin-aware > - Fix isaacs/npm#2452 Use --save(-dev|-optional) in npm rm > - `logstream` option to replace removed `logfd` (Rod Vagg) > - Read default descriptions from README.md files > > * Shims to support deprecated `ev_*` and `eio_*` methods (Ben Noordhuis) > > * \#3118 net.Socket: Delay pause/resume until after connect (isaacs) > > * \#3465 Add ./configure --no-ifaddrs flag (isaacs) > > * child_process: add .stdin stream to forks (Fedor Indutny) > > * build: fix `make install DESTDIR=/path` (Ben Noordhuis) > > * tls: fix off-by-one error in renegotiation check (Ben Noordhuis) > > * crypto: Fix diffie-hellman key generation UTF-8 errors (Fedor Indutny) > > * node: change the constructor name of process from EventEmitter to > process (Andreas Madsen) > > * net: Prevent property access throws during close (Reid Burke) > > * querystring: improved speed and code cleanup (Felix Böhm) > > * sunos: fix assertion errors breaking fs.watch() (Fedor Indutny) > > * unix: stat: detect sub-second changes (Ben Noordhuis) > > * add stat() based file watcher (Ben Noordhuis) > > > Source Code: http://nodejs.org/dist/v0.7.12/node-v0.7.12.tar.gz > > Macintosh Installer (Universal): > http://nodejs.org/dist/v0.7.12/node-v0.7.12.pkg > > Windows Installer: http://nodejs.org/dist/v0.7.12/node-v0.7.12-x86.msi > > Windows x64 Installer: > http://nodejs.org/dist/v0.7.12/x64/node-v0.7.12-x64.msi > > Windows x64 Files: http://nodejs.org/dist/v0.7.12/x64/ > > Other release files: http://nodejs.org/dist/v0.7.12/ > > Website: http://nodejs.org/docs/v0.7.12/ > > Documentation: http://nodejs.org/docs/v0.7.12/api/ > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
[nodejs] [ANN] ensure-https
Hi all, I just published a module that is a simple http server that forwards to https. Nothing spectacular, but since it is something that almost all my projects need, I figured packaging it and making it available might be a good thing. Regards, phidelta -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
[nodejs] [ANN] seic (Spdy-Express-socket.Io-Cluster)
Hi all, I have just released seic, which is a basic setup package for setting up an HTTPS server with Express, SPDY and Socket.IO enabled and Cluster. In addition there is a facility that enables the workers to easily broadcast events to all workers, so that socketi.io can work across clusters even without the redis stuff in that background. This is basically what I need to do for almost every web project, so this makes things much easier. Rather than rewriting the same boilerplate every time, I just do a require, and am ready to go. I really hope others might find this useful as well. Regards, phidelta -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
[nodejs] Nested domains or "How do I leave a domain"
Hi,
I am really liking the new domains feature. However I have a question: "How
do I leave a domain"
Is my undesrtanding correct?:
function b(callback) {
// I am running inside the domain created in a
fs.readFile('some-file', 'utf-8', function(err, val) {
// I am running inside the domain created in a
if (err) return callback(err);
callback(undefined, val.replace('A','B'));
});
}
function a() {
var d=domain.create();
d.run(b.bind(null, callback))
}
function callback() {
// I am running inside the domain created in a
}
If so, then how do I leave a domain? Simply dispose of it? Then in which
domain am I afterwards? Think nested domains. Am I in the one I was in
before doing *domain.run()* in *a*?
I I'm wrong in my understanding, then how do I ensure that all my async
calls/callbacks remain in the domain I created?
I would really appreciate if someone could explain this, since I am about
to embark on some major efforts that would really benefit from using
domains. Understanding how they work would be sort of fundamental ;)
Regards,
Philipp
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
[nodejs] Re: Crockford : Ynode : "I would fork node.js"
Look people, think of the context of the statements he made. I think he gave huge kudos to node. I wrote a longer post on that (and this thread) as well: http://instarant.net/crockford-right-nodejs-joyent Regards, Philipp On Saturday, September 15, 2012 4:45:30 PM UTC+2, Jorge wrote: > > http://www.youtube.com/watch?v=8HzclYKz4yQ#t=22m30s > > "I would fork nodejs. Nodejs is a great thing and I would bet the company > on it, but I would not bet the company on Joyent. I see Joyent doing some > stuff which is amateurish, maybe a little chidish, so I would fork it, and, > I would then give that back to the community, and it would be industrial > strength and secure and designed to operate a Yahoo scale and would make it > available for everybody for free" > > -- > Jorge. -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
[nodejs] ANN: Pistachio Template Compiler
Hi all, we (durchblicker.at) are currently in the process of open-sourcing some of the things we have written for our own use over the course of the last 2 years. One of the things we have done recently and currently have in production is a template compiler called *pistachio<https://github.com/phidelta/pistachio> *. It takes regular mustache templates and compiles them to plain Javascript-Functions that can be easily used in the browser as well as within node. We already have an express plugin included that uses pistachio templates as the template rendering engine in express, as well as a jQuery plugin that makes it really easy to use pistachio templates in the browser. In addition we created a Sublime-Text build system that does the compilation directly from Sublime. My colleague tiefenb is currently working on a grunt plugin as well. The resulting Javascript can of course be put through closure compiler to make them even smaller and faster. I really hope others will find this useful as well. As for us, we are using this in production right now, so you can assume that we will maintain and improve it over time. Regards, Philipp https://github.com/phidelta/pistachio -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
[nodejs] Re: Poll for v0.10 feature: Crypto default to 'binary' strings vs defaulting to buffers
d) I use it a lot and find the strangeness of binary strings so dumb that I'd rather have it changed sooner or later even if that means having to rewrite/modify a bit of code. On Tuesday, October 9, 2012 1:24:36 AM UTC+2, Isaac Schlueter wrote: > > Currently, the crypto module defaults to using 'binary' encoded > strings everywhere as the default input and output encoding. > > This is problematic for a few reasons: > > 1. It's slower than necessary. > 2. It doesn't match the rest of Node. > > The reason for this is that crypto predates Buffers, and no one ever > bothered to go through and change it. (The same reason it's got some > odd hodgepodge of update/digest methods vs the Stream interface you > see everywhere else in node.) > > The reason it persists in 0.8 (and perhaps in 0.10) is that we > (perhaps overly optimistically) labelled that API "stable", and don't > want to break anyone's programs. It's going to change eventually to > match the rest of node. The only question is whether the change will > come in 0.10 or 0.12. A stream interface to all the crypto classes is > coming in 0.10; using 'binary' strings by default is thus even more > obviously a departure from the rest of node. > > Note that, if you only use crypto for hashes, and set the 'hex' > encoding, then it won't affect you. If you only ever pass the output > of one crypto function to the input of another (sign/verify, for > example) then it also won't affect you; you'll just pass buffers > around instead of binary strings. > > Please select one, and reply with your choice and perhaps any other > feedback you have on this issue. Thanks. > > a) Go for it. This won't affect me, and if by chance it does, I don't > mind putting 'binary' args here and there. > b) Please wait. Mark the API as unstable in 0.10, but don't change it > until 0.12. > c) I have no opinion, because I don't use the crypto API directly. > > > (Disclaimer: Node is not a democracy. The "winning" vote might still > be out-voted by reasonable considerations of the core dev team. This > is informative only ;) > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
[nodejs] Re: Starting work on a Chrome Devtools addon
Hi, I am also constantly living in bugger (great work Jan!). I am currently looking into extending it to provide saving of local changes. Also bugger does writes to disconnected web-sockets if you do a reload of the dev-tools which is sometimes necessary when more sourcefiles get add via require(). So I am also looking into finding a way to either have bugger catch those send errors if client connections go away or even better forcing dev-tools to update its source list when changes occurr. Maybe putting more effort into bugger, would be time better spent. Regards, Philipp On Wednesday, July 10, 2013 1:32:29 AM UTC+2, Adam Crabtree wrote: > > Howdy all, > > I have LinkedIn's blessing to work full-time for 2 weeks on building a > node.js addon[1] for remote Chrome Devtools debugging. Since I've never > built an addon, this is a rather ambitious task for my first addon, and > nearly everyone in the community would benefit from this, I thought I'd > solicit interest in working with me on it, either directly via pull > requests or indirectly by giving advice on building node.js addons. > > Details: > > Per Pavel Feldman of the Chrome Devtools team, it's possible, with > possibly some limited support from Chrome to decouple some APIs if > necessary. For me personally, the inability to use the native Chrome > debugger has always been a little frustrating, and this is my attempt to do > what I can to resolve it. Any non-trivial contributions will receive > Contributor permissions to accelerate collaboration. > > Pavel has also graciously provided me with the following high-level > overview of where to start: > > // Begin Quote > There is not much info available. These are the rough hints for you (use > cs.chromium.org to navigate Blink source). Then we could chat over VC / > hangouts / Skype. > > [Compile] > InspectorController is a container for remote debugging protocol agents. > We have one for the Page (InspectorController.cpp) and we have one for the > workers (WorkerInspectorController.cpp that has limited functionality). > Given that Node is more like a worker (pure JS execution environment), take > a look at that file for the list of agents to compile in your module > (InspectorDebuggerAgent, InspectorConsoleAgent, InspectorProfileAgent, > etc.). So you would need to compile all of them. > > These agents would pull ScriptDebugServer.cpp, ScriptProfiler.cpp, Script* > etc. These are wrappers around v8, should compile against v8.h. Some of > them (ScriptProfiler) and most of the agents will reference Node and that's > what we need to fix. In fact, most of them will pull Page, Document, Node > for no good reason and that's what we need to fix upstream, in Blink. > > You would also need to generate InspectorBackendDispatcher and > InspectorFrontend from devtools/protocol.json. First one will parse > incoming JSON messages and will dispatch them on controller's agents, > second will generate typed API for agents to send messages back. Some > tweaking would be necessary here as well since currently we generate a > giant dispatch and giant front-end instead of per-domain files. Having them > per-domain would let you only take what you really need. > > [Wire] > Lets assume it all compiled. Now you need to instantiate this controller > and call dispatchMessageFromFrontend on it with every message from the > front-end. Front-end will issue them using web socket transport, so you > need to have a server web socket as a part of your Node module that would > accept connection and do the right thing to the messages (call > dispatchMessageFromFrontend). And for the way back, your m_frontendChannel > would need to send info back using that web socket. > > [Debugging] > After compiling and wiring, console will start working. But you also need > to make things work while on breakpoint. For that, you would need to > implement runMessageLoopOnPause in your version of WorkerScriptDebugServer. > > As I mentioned, it is quite some work both downstream (in the Node module) > and upstream (to remove poor Blink dependencies from agents). But it might > be worth it. > > Regards > Pavel > > // End Quote > > > Feel free to submit pull requests or post issue to > https://github.com/crabdude/lookingglass > > Cheers, > Adam Crabtree > > [1] http://nodejs.org/api/addons.html > > -- > Better a little with righteousness >than much gain with injustice. > Proverbs 16:8 > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the
[nodejs] When require() is slow: ideas on improving node.js require() performance on startup
It sounds like you don't habe to load all files on startup, but do so in order
to not block later. So maybe your solution is to only require what is needes at
start and then switch to async require.
I wrote an async require last week as a test. Since you can in fact
require('module') and interact with the stuff in there it's pretty easy to go
async with it.
of course you do loose some benefits such as automatic load ordering, but if
performance in loading a lot of modules is your concern, then that might be a
way to go.
have a look at https://github.com/joyent/node/blob/master/lib/module.js and
you'll see that the module loader is actually quite simple.
If you need help, give me a shout out, as I said I played with something
similar last week but killes it as overkill for my scenario.
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[nodejs] When require() is slow: ideas on improving node.js require() performance on startup
It sounds like you don't habe to load all files on startup, but do so in order
to not block later. So maybe your solution is to only require what is needes at
start and then switch to async require.
I wrote an async require last week as a test. Since you can in fact
require('module') and interact with the stuff in there it's pretty easy to go
async with it.
of course you do loose some benefits such as automatic load ordering, but if
performance in loading a lot of modules is your concern, then that might be a
way to go.
have a look at https://github.com/joyent/node/blob/master/lib/module.js and
you'll see that the module loader is actually quite simple.
If you need help, give me a shout out, as I said I played with something
similar last week but killes it as overkill for my scenario.
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[nodejs] When require() is slow: ideas on improving node.js require() performance on startup
It sounds like you don't habe to load all files on startup, but do so in order
to not block later. So maybe your solution is to only require what is needes at
start and then switch to async require.
I wrote an async require last week as a test. Since you can in fact
require('module') and interact with the stuff in there it's pretty easy to go
async with it.
of course you do loose some benefits such as automatic load ordering, but if
performance in loading a lot of modules is your concern, then that might be a
way to go.
have a look at https://github.com/joyent/node/blob/master/lib/module.js and
you'll see that the module loader is actually quite simple.
If you need help, give me a shout out, as I said I played with something
similar last week but killes it as overkill for my scenario.
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[nodejs] When require() is slow: ideas on improving node.js require() performance on startup
It sounds like you don't habe to load all files on startup, but do so in order
to not block later. So maybe your solution is to only require what is needes at
start and then switch to async require.
I wrote an async require last week as a test. Since you can in fact
require('module') and interact with the stuff in there it's pretty easy to go
async with it.
of course you do loose some benefits such as automatic load ordering, but if
performance in loading a lot of modules is your concern, then that might be a
way to go.
have a look at https://github.com/joyent/node/blob/master/lib/module.js and
you'll see that the module loader is actually quite simple.
If you need help, give me a shout out, as I said I played with something
similar last week but killes it as overkill for my scenario.
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[nodejs] Re: Mongo vs. Couch vs. LevelDB ?
Hi, each option in the database space is good at different things and have very different usage profiles. The most important question you have to answer before you even think of which DB system to use or whether you even want to use one at all is: What is my data and access profile. For example: * If you never search for data, because you always have a unique identifier (primary key), then maybe you don't need a DB system, but are better off with a Key Value store. * If you never modify data once it has been stored, but simply write once read often, then you have a different need than if you modify your data. (Example: CouchDB gives you strong version enforcement, which you don't need in that case then at the cost of speed and complexity). * How much data are you expecting? Does it even need to be persisted at all? For example if you are only doing session storage, you might be better of just doing a memcached cluster, because if you calculate your data-size, you might be able to handle multiple million users with a few gigs of ram. So the question you have asked is like: "I want to move an object, what kind of vehicle should I use" Well first you need to think about: "What kind of object? Over what kind of terrain? Across Oceans? Off planet? At what speed? …" So before you consider what DB to use, first consider your data, then your access patterns, then research the options, and then decide ;) On Wednesday, August 28, 2013 3:35:40 PM UTC+2, Dylan Hassinger wrote: > > Hi everybody - I am a Node newb building my first app, and trying to > figure out which database system to use. Can anybody shed some light on > what the major differences are between Mongo, Couch and LevelDB - and when > is the right time to to use them? > > Specifically, is the syntax similar between them / is it easy to switch > after-the-fact? > > Also wondering if anybody has suggestions for hosted database-as-a-service > options? I've heard good things about MongoHQ, but not sure if there's > hosted options for Couch or LevelDB. Thanks for any help!! > > dylan > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[nodejs] Re: New gatekeeper
The king is dead; Long live the king! Thanks to your great leadership, this will not negatively impact the vibrant nodejs community. It will however positively impact the personal satisfaction with your daily tasks. So I congratulate you from the bottom of my heart. Let's have an adequate period of mourning and then decide where and how to errect proper statuary and memorials. Oh wait, you have already done so by creating Node. My Bad. ;) On Jan 30, 8:55 pm, Ryan Dahl wrote: > Now that the rewrite on top of libuv is largely complete, I am ceding > my position as gatekeeper to Isaac Schlueter. Our energy will now be > largely focused over the next few months on improving the third party > module system experience including a website for browsing modules, a > new addon build system, and binary installations from npm. Isaac is in > the unique position to bridge the gap between core and external > modules to ensure a pleasant experience. After three years of working > on Node, this frees me up to work on research projects. I am still an > employee at Joyent and will advise from the sidelines but I won't be > involved in the day-to-day bug fixes. Isaac has final say over what > makes it into the releases. Appeals for new features, changes, and bug > fixes should now be directed at him. -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
[nodejs] Re: cluster secret sauce
Hi, Its actually quite simple. The is an IPC-Pipe between the parent process and any child. When you call listen() on a socket in the child, rather than binding to the port (which would cause an EADDRINUSE) the child send a message requesting a handle to the parent. The parent checks if it already has a listening socket for the port you want. If yes it will take that handle and send it via the IPC- Pipe to the child. If not then it will listen to the port, remember the Handle and then send it to the child. This way the only process that ever actually listens to a port is the parent and that simply shares its handle with the children. If you want to look at the code that makes it work you need to look at net.js and child_process.js in Jvaacript as well as the Pipe wrapping stuff in cpp. If the pipe stuff and the ability to pass a handle to a listening socket to listen() were actually documented, and therefore stable, it would actually be easy to write your own clustering solution. Since there are currently a few problems with clustering as is (such as not shutting down correctly), and I really wanted to use it anyhow, I actually wrote my own little API to use. When the clustering stuff actually matures, I intend to simply rewrite it to be a light wrapper around the then stable API. The reason I have not gotten involved with helping on it is simply that I don't have sufficient time and there are already serious efforts by people much more deeply into the subject going on to make the clustering API much better. From what I have seen, it will be absolutely awesome when it's stable. Regards, Phil P.S.: if you need more detailed info, or want a sample of how the magic actually works, just drop me a line. I can send you the stuff I have done or go into a bit more detail if you need it. On Feb 12, 10:36 pm, Mark Volkmann wrote: > I'm trying to learn how the cluster module allows multiple TCP-based > servers to share a port. As far as I can tell, this isn't handled in > lib/cluster.js or lib/child_process.js. Perhaps it is handled in > src/node.js and is related to the environment variable access with > process.env.NODE_CHANNEL_FD. Am I on the right track? It's still a mystery > to me what is going on here. > > How are requests distributed among the workers? In my testing it seems that > the worker that handled the previous request will always handle the next > request as long as it finished processing the previous request. > > -- > R. Mark Volkmann > Object Computing, Inc. -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
[nodejs] Re: cluster secret sauce
Oh and yes, you are absolutely on the right track. NODE_CHANNEL_FD signals that the stein is an IPC Pipe and that is handled in src/ node.js cluster.js simply uses child_process.js to establish children. net.js is where the funky listening port sharing stuff happens. The cop pie wrapping is the actual means by which the child_process stuff manages the IPC. The actual problem with shutting down clusters is that although you close all listening sockets in a child the IPC pipe does not get closed. Also the listening sockets are still open in the parent. So your clustered node processes will never shut down properly, which in turn leads to an issue when you want to restart a cluster (such as after an update) since pretty much everything remains open. And you can't just kill the processes, since it would be possible that they should still be alive sice they are still handling an ongoing request. Regards, Phil On Feb 12, 10:36 pm, Mark Volkmann wrote: > I'm trying to learn how the cluster module allows multiple TCP-based > servers to share a port. As far as I can tell, this isn't handled in > lib/cluster.js or lib/child_process.js. Perhaps it is handled in > src/node.js and is related to the environment variable access with > process.env.NODE_CHANNEL_FD. Am I on the right track? It's still a mystery > to me what is going on here. > > How are requests distributed among the workers? In my testing it seems that > the worker that handled the previous request will always handle the next > request as long as it finished processing the previous request. > > -- > R. Mark Volkmann > Object Computing, Inc. -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
[nodejs] Re: So.. this javascript thing :)
Hi Isaac,
this would make a great addition to the Buffer documentation. I did
not think of that and I actually read the node source code. It's
obvious once you point it out though. Maybe a hint in the docs would
be a "Good Thing"™.
On Mar 15, 8:09 pm, Isaac Schlueter wrote:
> +1 What everyone else said.
>
> However, you MAY still have a race condition here!
>
> ```javascript
> var outputBuffer = "";
>
> SetInterval(function() {
> outputBuffer += "asdf";
>
> }, 100);
>
> websocket.onMessage(function() {
> // reply with outputbuffer
> send(outputBuffer); // Race condition?
> outputBuffer = ""; // What if SetInterval happened?});
>
> ```
>
> Between the two lines in the websocket.onMessage callback, the
> setInterval cannot interrupt. However, it's not clear from reading
> this code whether the function passed to websocket.onMessage will be
> called immediately or at some time in the future. (From the name of
> the function, I'd expect it to be at some future time.) So, it may be
> called either before or after the setInterval, but *not* in parallel
> with it.
>
> Furthermore, actual Buffer objects (unlike your "outputBuffer" string
> shown above) *are* subject to break-ins! Consider this code:
>
> ```javascript
> var fd = fs.openSync("foo.txt", "r")
> var buf = new Buffer(fs.statSync("foo.txt").size)
> buf.fill(0)
> fs.read(fd, 0, buf.length, 0, function () {
> throw new Error("This will never be called")})
>
> while (true) { // loop goes forever, jealously holding onto this tick
> for (var i = 0; i < buf.length; i ++) {
> // I sure hope there are no break-ins...
> if (buf[i] !== 0) {
> throw new Error("HIDE YA KIDS, HIDE YA WIFE")
> // todo: Hide ya husbands too. They takin e'rbody up in here.
> }
> }}
>
> ```
>
> In this case, the JavaScript thread is never given up, but
> nevertheless, the buffer object (which accesses memory outside of the
> V8 heap) is going to be changed in the background by the fs operation
> happening in a libuv thread.
>
> The moral of the story is: If you pass a Buffer to a function, it's no
> longer your buffer! Reading from it or writing to it at that point is
> entering the territory of undefined behavior.
>
> If you exercise care around that one sharp edge, the race conditions
> in nodejs are generally pretty easy to manage. Events may come back
> in arbitrary order, but they'll always come in single file.
>
>
>
>
>
>
>
> On Thu, Mar 15, 2012 at 11:33, Mark Hahn wrote:
> > That beauty of node is that you *don't* have to worry about concurrency
> > issues like that.
>
> > --
> > Job Board:http://jobs.nodejs.org/
> > Posting guidelines:
> >https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> > You received this message because you are subscribed to the Google
> > Groups "nodejs" group.
> > To post to this group, send email to nodejs@googlegroups.com
> > To unsubscribe from this group, send email to
> > nodejs+unsubscr...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/nodejs?hl=en?hl=en
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
[nodejs] Re: finding modules matching a name glob
The problem with doing this via npm is that npm works with the
dependencies from the package.json which is a problem for plugins,
since they are seldom known at the time the package.json is writeen.
I have done something like this for my app. What I ended up doing is
simply defining a folder which all plugins have to be in.
function requirePlugins(plugindir) {
require('fs').readdirSync(plugindir).map(function(item) {
return require('path').resolve(plugindir, item);
}).forEach(function(plugin) {
if (/\.plugin$/.test(plugin)) require(plugin);
});
}
on start-up I simply call
requirePlugins(require('path').resolve('./plugins'));
This avoids traversing a billion directories, and does what you need.
It is synchronous of course, but that is true for require anyhow and
does not matter much since it is ever only called on start-up.
Regards, Philipp
On Apr 21, 8:04 pm, Mike Pilsbury wrote:
> > So doing an `npm ls` from a process is the only way to go? Whatever it
> > takes.
>
> > It looks
> > likehttp://npmjs.org/doc/README.html#Using-npm-Programmaticallyoffers
>
> another option.
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
[nodejs] FN.bind vs fn() { FN() }
Hi all,
I have recently come to use .bind a lot, because it makes for very
clean code.
So rather than doing
var x; // this has some value that comes from prior code
setTimeout(function() { console.log(x) }, 5000);
I am now often doing
var x;
setTimeout(console.log.bind(console, x), 5000);
The question I have is: what is more performant? Is there any reason
to avoid .bind()?
Regards, Phil
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
[nodejs] Re: FN.bind vs fn() { FN() }
Thanks everyone! I know my example was silly, this wasn't really about console log and setTimeout, but rather about the pattern in general. I have fallen in live with using bound functions as event listeners, since it allows me to give them some context explicitly, rather than in a closure. I wanted to know whether there is a huge downside and there seems not to be one. So my question has been fully answered and i will continue to use both styles depending on the circumstance. Thanks again and cheers, Phil -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
