Hey Tolgay,
I have done similar things to store userId to socketId relationship
in hbase and then retrieved it while sending it back. You can do
similar thing
Regards,
Vikram
On Mon, Mar 25, 2013 at 11:14 AM, mgutz mario.l.gutier...@gmail.com wrote:
You can use rooms as he said. But if you
I've been trying things around with the new stream2 api.
- catstream https://github.com/Floby/node-catstream: Read filenames,
output contents [transform]
- stream-stream https://github.com/Floby/node-stream-stream: Write
readable streams to a stream, and it concatenates them [read]
no. Definitely not.
Spawn a predefined number of workers (using the cluster api) and queue jobs
in the master process then send them to the workers when they are ready to
process.
On Monday, 25 March 2013 06:49:32 UTC+1, simo wrote:
So, is it a recommended approach to spawn a new process for
What's wrong with the PHP implementation?
Also, you should provide a more throrough description of what you want to
achieve.
On Sunday, 24 March 2013 21:13:14 UTC+1, Bart Barrow wrote:
Hi,
I recently found NodeJS and I was wondering about the best way to make a
gaming control panel that
I compiled my own node, and I do need to have root access for anything
global with npm.
On Monday, 25 March 2013 00:21:43 UTC+1, Phil Jackson wrote:
Hey all,
I'm wondering why `npm link` installs modules in the global node path?
Before I bothered reading the man page I was doing this:
i'm with substack here. my arguments on this are:
the HOW instances are created and IF it's a singleton or not are, in fact,
implementation details and should be hidden most of the time from the user.
when i var foo = require('something') , then it's not obvious, that this is
a constructor. a
a better option is spawning a separate cluster of algorthm workers as
service and using something like https://github.com/substack/dnode for
communication. spawning a new process takes tens of miliseconds, which
probably is to long for short living processes.
Am Montag, 25. März 2013 06:49:32
Hey Floby,
Same here but not everyone does that.
Phil
Floby florent.j...@gmail.com writes:
I compiled my own node, and I do need to have root access for anything
global with npm.
On Monday, 25 March 2013 00:21:43 UTC+1, Phil Jackson wrote:
Hey all,
I'm wondering why `npm link`
and don't forget all the bunch of rails-alikes out there, for all the
opinionated guys ;)
Am Montag, 25. März 2013 09:53:18 UTC+1 schrieb Raynos:
typical node projects use npm browserify for frontend. NOT bower.
typical node projects use JavaScript. NOT coffeescript.
typical node
Thanks Floby, I appreciate your advice, do you know a good blog or source
that talks about workers and jobs queuing?
On Mon, Mar 25, 2013 at 10:52 AM, Floby florent.j...@gmail.com wrote:
no. Definitely not.
Spawn a predefined number of workers (using the cluster api) and queue
jobs in the
You idea is great! but how can I manage load balance on the algorthm
workers? if I have 100 algorthm workers for example?
On Mon, Mar 25, 2013 at 12:35 PM, greelgorke greelgo...@gmail.com wrote:
a better option is spawning a separate cluster of algorthm workers as
service and using something
http://howtonode.org/introduction-to-npm the paragraph about what no sudo
Am Montag, 25. März 2013 11:44:07 UTC+1 schrieb Phil Jackson:
Hey Floby,
Same here but not everyone does that.
Phil
Floby floren...@gmail.com javascript: writes:
I compiled my own node, and I do need to have
http://nodejs.org/api/cluster.html#cluster_how_it_works
Am Montag, 25. März 2013 12:08:27 UTC+1 schrieb simo:
You idea is great! but how can I manage load balance on the algorthm
workers? if I have 100 algorthm workers for example?
On Mon, Mar 25, 2013 at 12:35 PM, greelgorke
Yes, I already found it, amazing tech
On Mon, Mar 25, 2013 at 1:22 PM, greelgorke greelgo...@gmail.com wrote:
http://nodejs.org/api/cluster.html#cluster_how_it_works
Am Montag, 25. März 2013 12:08:27 UTC+1 schrieb simo:
You idea is great! but how can I manage load balance on the algorthm
Hey Greelgorke,
You're missing the point. I'm suggesting that `npm link` shouldn't do
the global thing by default.
Also, if people use package mangers node will end up in /usr/, not
/usr/local.
Cheers,
Phil
greelgorke greelgo...@gmail.com writes:
http://howtonode.org/introduction-to-npm the
npm link shouldn't behave like npm -g link
NB: this has nothing to do with the way node or npm is installed,
while it is true that node end up in /usr, package managers have npm
configured to global-install modules to /usr/local by default.
Jérémy.
On 25/03/2013 13:39, Phil Jackson wrote:
Hi Samir,
I solved that problem for CPU intensive jobs. I ended up with my own
control flow library, because no one has been gone in the route of
queuing task with a work-in-progress limit in a sane way before:
https://github.com/mcollina/kanban. There is async.queue, but it lacks some
Atypical CoffeeScript is #4 on npm
The guy is specifically targeting single page apps. Backbone is the
heavyweight king in that space.
Not sure how npm-www relates?
On Monday, March 25, 2013 1:53:18 AM UTC-7, Raynos wrote:
typical node projects use npm browserify for frontend. NOT bower.
On Mon, Mar 25, 2013 at 11:14 AM, Matteo Collina
matteo.coll...@gmail.comwrote:
The number of worker processes you want to spawn in a given period of time
is strictly dependent to the number of concurrent process you might want to
run in your system. With node.js you can end up prettly quickly
that's it. tell the package manager to install it in the right place.
the other point, the local link. you can do this yourself:
ln -s yourLib ./node_modules/yourLib
the problem with it is, that nearly every developer has it's own dir
layout. the way npm ln works is the only simple way to be
In your use case, I just manually create a symlink directly and bypass the
local stuff:
cd node_modules
ln -s ../../base
cd ..
npm ls
I use npm link to install a module globally, usually because I'm writing a
CLI script and want to test it.
On Sunday, March 24, 2013 6:21:43 PM
there is also threads-a-gogo lib which can be used to spawn threads. i
haven't use it yet (never really had to), but it is another option.
Am Montag, 25. März 2013 12:26:12 UTC+1 schrieb simo:
Yes, I already found it, amazing tech
On Mon, Mar 25, 2013 at 1:22 PM, greelgorke
derbyjs, sailsjs there are more for sure. we just suspect that the call for
boilerplate is born out of not-exploring. express is simple, and you
totally can write wonderful apps with very few boilerplate with it. but
many people don't want to change their mindset comming from opinionated
Hi,
I cannot reach some of the fields of my class and I don't understand why.
Someone please take a look at my code. This is the Nth one, I was changing
this to var, to TCPServer.prototype.sg etc. Nothing helped.
I've started with a sample tcp server from Anwajler's blog
Shouldn't `stream.on('data', onData);` be `this.onData`?
On Monday, March 25, 2013 8:44:02 AM UTC-7, Perrier wrote:
Hi,
I cannot reach some of the fields of my class and I don't understand why.
Someone please take a look at my code. This is the Nth one, I was changing
this to var, to
You may also need to bind `onConnection` to `this` otherwise `this.onData`
would be invalid as well.
On Monday, March 25, 2013 9:28:06 AM UTC-7, mgutz wrote:
Shouldn't `stream.on('data', onData);` be `this.onData`?
On Monday, March 25, 2013 8:44:02 AM UTC-7, Perrier wrote:
Hi,
I
Thanks Mike, appreciate the help :)
On Saturday, March 23, 2013 3:47:31 PM UTC, Mike Pilsbury wrote:
Like most io in node, tedious responds asynchronously. However you are
treating your connect_db function as if it operated synchronously. The
result array will still be empty when the
See the last diagram in http://howtonode.org/object-graphs to understand
that functions on objects are in no-way bound to the object you initially
assigned them to.
On Mon, Mar 25, 2013 at 11:30 AM, mgutz mario.l.gutier...@gmail.com wrote:
You may also need to bind `onConnection` to `this`
@Matteo Thanks, but as I am still at the beginning of this, I will need to
find a way to simulate lots of users, and to find a way to profile
performance, then I can decide what to do, if you can help me how to
simulate virtual users and how to profile performance of my node app in
real time, it
On Mon, Mar 25, 2013 at 2:17 PM, Samir Sabri as3...@gmail.com wrote:
@Mat you said (load should be divided by number of CPUs) isn't load
automatically divided when I node cluster?
The load we were referring to is load average:
Isn't there a cloud hosting provider who would auto scale my app? would it
be possible to stay away from load avarage details so that my cloud hosting
provider handle it? if so, who do you recommend?
On 25 Mar 2013 20:34, Matt hel...@gmail.com wrote:
On Mon, Mar 25, 2013 at 2:17 PM, Samir Sabri
@Rich
Issue w/fix: https://github.com/joyent/node/issues/4375
Commit from Isaac
w/fix:
https://github.com/joyent/node/commit/4401bb47bfa4fe72c2755c428577903ece5cfaa0
The issue that Ben linked to, https://github.com/joyent/node/issues/5114, I
posted to the group for opinions on Friday
here:
Is it correct to assume that a Readable won't emit the readable event
until you're registered for it?
Reading through the streams2 docs, I was under the impression that all
streams start out paused and don't start emitting data until you add either
a data (for old streams) or a readable listener.
readable is emitted after you've actually started reading.
In your example, you dont ever `response.read()`, so no readable event
is ever emitted.
As you said, streams start in paused state and ready to be read.
On 03/25/13 22:28, Michael Jackson wrote:
Is it correct to assume that a Readable
readable is emitted after you've actually started reading.
That's not what it says in the
docshttp://nodejs.org/api/stream.html#stream_event_readable
.
###
Event: 'readable'
When there is data ready to be consumed, this event will fire.
When this event emits, call the read() method to consume
You can always call `stream.read`, at any time. This is how data is
*pulled*off the stream (instead of it being pushed to you, whether
you're ready or
not). Because of this you won't lose any data. With new streams there's no
real notion of a paused state -- it's always paused. Once you grok that
You're right, my bad.
But still, data stay in the buffer until someone tries to `.read()`.
So, if you're being passed a stream that you dont know whether the
first `readable` event has fired, you can try to actually read from
it. If it returns null, then you wait for `readable`.
On 03/25/13
You *must* try to read from it. Otherwise it's likely to remain paused.
On Mar 25, 2013, at 1:50PM, Dan Milon danmi...@gmail.com wrote:
You're right, my bad.
But still, data stay in the buffer until someone tries to `.read()`.
So, if you're being passed a stream that you dont know whether
I haven't experimented with streams2 as much as I should have. But I
remember talking to Isaac about it early on. The way I think about it is
still the same.
It feels like the semantics of how node streams produce data is much more
consistent and predictable now. Node still starts by reading data
On Mon, Mar 25, 2013 at 5:01 PM, Marco Rogers marco.rog...@gmail.comwrote:
I haven't experimented with streams2 as much as I should have. But I
remember talking to Isaac about it early on. The way I think about it is
still the same.
It feels like the semantics of how node streams produce
If stream.read returns null that could mean one of two things:
1) the stream doesn't currently have any data, but still might have some
in the future
2) the stream is already ended
AFAICT, the only way you can know which state you're in is by checking the
stream.readable property which is
You're absolutely right. I totally forgot about that aspect of the
semantics. It changes my metaphor a little. So stream.read() isn't a blind
blocking call that can get you into lots of trouble, which I think my
previous message implied. Instead it's a peek into the underlying semantics
of how
I'm more and more convinced that need to go back and read all the available
info about streams2. Answering these detail semantics questions is pretty
important.
:Marco
On Mon, Mar 25, 2013 at 2:29 PM, Michael Jackson mjijack...@gmail.comwrote:
If stream.read returns null that could mean one of
This thread is pretty huge.
At this point, would people say there is more confusion about streams2 than old
streams? I know that some of this is a little hard to get our heads around but
i always got the feeling that only about 10 people really understood all of old
streams.
-Mikeal
On Mar
Yeah, I think the old streams still had lots of confusion around them and
the adoption wasn't great. If we can't beat that with streams2 then we are
doing a lot of work for not much gain. I think there are common themes that
barrier to understanding with both approaches. I've been trying to think
Ah, looking through the Readable code a bit more it seems that the end
event won't ever fire until read is called at least
oncehttps://github.com/joyent/node/blob/master/lib/_stream_readable.js#L52-L56
.
So I guess what I could do is call read() *and* register an end event
handler in the same
Hi All,
I've just published Nject, a simple dependency injection tool.
https://github.com/autoric/nject
Please take a look, and I welcome any feedback!
Erin
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You
Ok, that makes sense.
So the readable event is more of an advisory event. The docs should
probably say something about how you could possibly miss the event entirely
if you're doing some other IO before you try and read from the stream.
For posterity's sake, I adjusted my previous example:
That's not guaranteed to work.
You're assuming that `stream.read()` will return the whole internal
buffer, which is not documented anywhere.
The right approach is to call `.read()` until it returns null.
Something like that:
function collectStream(stream, cb) {
var bufs = []
function
I can see what you're saying, but the node docs do
sayhttp://nodejs.org/api/stream.html#stream_readable_read_size_1that
if you don't pass a size argument to stream.read then the entire
contents of the internal buffer are returned.
In any case, this would all be a lot easier if the readable event
How did this get so bloody complicated?
On Mon, Mar 25, 2013 at 3:48 PM, Michael Jackson mjijack...@gmail.comwrote:
I can see what you're saying, but the node docs do
sayhttp://nodejs.org/api/stream.html#stream_readable_read_size_1that if you
don't pass a size argument to stream.read then
A small amendment to #3: if read returns null it could also mean that the
stream is ended. So you need to register for the end event as well. It
looks like streams internals refuse to fire end until at least one call
to stream.read has happened, so you're guaranteed to get that event.
It's the
I don't think there's necessarily any *more* confusion over streams2 than
there ever was over old streams, just a different set of questions to
answer.
Part of the reason I was so excited about streams2 is that I thought it
meant I could finally deprecate
On Mar 25, 2013, at 4:40PM, Michael Jackson mjijack...@gmail.com wrote:
I don't think there's necessarily any *more* confusion over streams2 than
there ever was over old streams, just a different set of questions to answer.
Part of the reason I was so excited about streams2 is that I
We have a build environment where our build servers do not have external
SSH access for security reasons. We've got hit by the problem like in the
following pull request [0], where an NPM dependency does not specify both
the git+https protocol.
[0]
Because if your deep into node, your deep into npm. The only obvouis choice
is to use the same package manager for the frontend.
This may only apply to people that use npm in a modular fashion.
On Mon, Mar 25, 2013 at 3:48 AM, José F. Romaniello
jfromanie...@gmail.comwrote:
2013/3/25 Jake
If javascript required you to install javascript a dependency to use it
then it would have 25k modules that dependend on it. so it's about 20:1
ahead.
On Mon, Mar 25, 2013 at 8:27 AM, mgutz mario.l.gutier...@gmail.com wrote:
Atypical CoffeeScript is #4 on npm
The guy is specifically
If you add a `readable` handler, then `'readable'` (and potentially
`'end'`, if there's no data) will be emitted.
So the readable event is more of an advisory event. The docs should probably
say something about how you could possibly miss the event entirely if you're
doing some other IO
My own perspective is that relying on projects that declare their
dependencies this way is a really bad idea. They're relying on unreleased
versions of packages that aren't necessarily considered stable enough for
use by the package author in the first place. If the authors had considered
them
On Sun, Mar 24, 2013 at 4:21 PM, Phil Jackson p...@apiaxle.com wrote:
Hey all,
I'm wondering why `npm link` installs modules in the global node path?
When you `npm link`, it effectively creates a global install that can be
accessed from any other project. You then create a local reference to
Pomelo is a fast scalable game server framework in node.js.
Pomelo has gained 1448 stars in github within 4 months. Not bad. Now we
published the 0.3 version of pomelo.
Pomelo 0.3 improves the communication protocol between client and server
for mobile enviroment. The new protocol uses
If you add a `readable` handler, then `'readable'` (and potentially
`'end'`, if there's no data) will be emitted.
Then there's a bug.
So the readable event is more of an advisory event. The docs should
probably say something about how you could possibly miss the event entirely
if you're
Thanks a lot for this. In introspection it turns out you were right: this
was born out of a bit of ignorance on my part. I had no idea of the
existence of SailsJS, and that seems like the perfect match for this kind
of project, since it automagically creates JSON apis for all your models.
On
That's a really good point. It seems this particular package is the
exception, not the rule, at least I hope so! I'll recommend a fix.
On Monday, March 25, 2013 7:29:49 PM UTC-7, Martin Cooper wrote:
My own perspective is that relying on projects that declare their
dependencies this way
64 matches
Mail list logo
