I have a naive question here. If cluster doesn't know if the worker is
busy, what happens when a new connection comes in and it is still busy? Do
requests queue at each worker? What behavior should be expected if you're
using round robin with lots of busy workers? I'm thinking of the Heroku
I like this pattern for making nice utilities available on the function
prototype. IMO it's the safest proto to modify. It would be handy in
modules that do other specific function-wrapping things, like memoizing,
currying, throttling, etc. This opinion is probably ripe for sparking nerd
This is the more insidious bug in my mind, because things just hang.
Requests randomly time out. It sucks.
On Tuesday, October 1, 2013 1:09:28 PM UTC-7, Mark Hahn wrote:
I'm seeing those bugs much more frequently than I'd like to.
Me too. And I also see the opposite where I don't remember
You could check out geddyjs http://geddyjs.org/. It's a framework more akin
to rails. It doesn't have explicit rest support right now. But it has nice
data models built in, and it's pretty easy to set up controllers for basic
rest support.
On Saturday, September 21, 2013 6:02:16 AM UTC-7,
Assuming the C dependency is the same or compatible version between A and B,
then this is working as expected. npm knows how to resolve recursive
dependencies such that they are not duplicated. If A and B depended on
different versions of C, then you would be both of those as you originally
@greelgorke is right that npm link is meant for development and not
deployment. But I think I understand your problem. You have a single module
repo, myLib, that you want to share between projects. I assume it's an
internally developed module and not suitable for publishing to the public
npm
Why don't you describe your troubles with socket.io sessions. Maybe someone can
help with that.
:Marco
--
--
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
If you want to try out proxies, check out this repo. Tom has implemented a
polyfill of the newer direct proxies by using the old non-standard ones in v8.
It should give you an idea of how they behave.
https://github.com/tvcutsem/harmony-reflect
This worked in nodejs when I was poking around
No there's nothing built into core for this. The core apis actually want to
encourage streaming and it's generally considered the more efficient
pattern. There are lots of modules like the one you found that make it easy
to accumulate the streamed data chunks. If you are making an http calls,
You've got the right idea. But you're right that it can be difficult to
work out the details. I've been giving talks on this recently, and I've got
a repo that may help. Check out my example gzip stream. There are slides
and other examples in there that may also be helpful.
this topic, visit
https://groups.google.com/d/topic/nodejs/sbvdxC6i5Yw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Marco Rogers
marco.rog
, visit https://groups.google.com/groups/opt_out.
--
Marco Rogers
marco.rog...@gmail.com | https://twitter.com/polotek
Life is ten percent what happens to you and ninety percent how you respond
to it.
- Lou Holtz
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https
It's not clear from this thread what you want exactly. You want to name
your modules whatever you want, not use namespaces, have them on npm, and
also avoid name collision? How exactly do you see that working?
:Marco
On Saturday, May 25, 2013 11:06:28 AM UTC-7, stagas wrote:
2013/5/25 Alex
This is a pretty comprehensive list. I can't imagine you'd walk into any
community with such a specific list and get a ready-made solution. Maybe
java, but who wants to do that? ;)
That said, you should check out geddy. It's a framework that leans more
towards batteries included and convention
/opt_out.
--
Marco Rogers
marco.rog...@gmail.com | https://twitter.com/polotek
Life is ten percent what happens to you and ninety percent how you respond
to it.
- Lou Holtz
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting
I've been trying to follow this thread, but there's a lot here. I apologize
in advance if I'm retreading anything that's already been said.
I have a simple question first. Are you considering having both the
flexible cork/uncork api and also putting a nice api on top of it with C/D
option?
+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Marco Rogers
marco.rog...@gmail.com | https://twitter.com/polotek
Life is ten percent what happens to you and ninety percent how you respond
to it.
- Lou Holtz
--
--
Job Board: http
of uncorking automatically when you
call .end() solves most of that hazard.
So getting some perspective on the use cases might be helpful here.
The primary use case is the http-tcp interaction, and saving syscalls
in web sites.
On Wed, Apr 24, 2013 at 5:12 PM, Marco Rogers
marco
I'm not sure why this stopped working. But I'm also not sure why you would
expect pushing no data to do something. Don't get me wrong, I understand
the argument. I just don't know which behavior really makes the most sense.
There's an argument that the new behavior is better.
:Marco
On
Nice.
On Thursday, March 28, 2013 5:12:26 PM UTC-7, Adam Crabtree wrote:
There are a lot of gotchas to wrapping core IO functions like done
trycatch, long-stack-traces, longjohn and other modules, especially with
EventEmitter. It's easier to get it wrong than it is to get it right.
So, I
:32 AM UTC-4, Marco Rogers wrote:
@Nathan's response is right. Creating a writable stream is
preferable in
most cases. But I wanted to add a little context to that. If
you're dealing
with a base readable stream, it's just pushing chunks of data at
you off
to frame my understanding and help
me convey it to other people.
:Marco
On Mon, Mar 25, 2013 at 2:23 PM, Dean Landolt d...@deanlandolt.com wrote:
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
keep sequence of events under control?
Anyway, thanks Node team, I'm very impressed!
On Wednesday, March 20, 2013 4:45:32 AM UTC-4, Marco Rogers
wrote:
@Nathan's response is right. Creating a writable stream is
preferable in
most cases. But I wanted to add
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 25, 2013, at 2:40PM, Marco Rogers marco.rog...@gmail.com wrote:
I'm more and more convinced that need to go back and read all
On Monday, March 18, 2013 11:06:48 AM UTC-7, Sigurgeir Jonsson wrote:
The new streams have excellent support for high/low watermarks and
auto-pausing/resuming, but the documentation confuses me a little...
particularly the read method.
When I read the new docs for the first time I was
@Nathan's response is right. Creating a writable stream is preferable in
most cases. But I wanted to add a little context to that. If you're dealing
with a base readable stream, it's just pushing chunks of data at you off
the wire. Your first task is to collect those chunks into meaningful
Your problem is way simpler than this (though a little tough to explain).
The problem in your example is that you are creating a dynamic object based
on the AsLinker constructor before you have finished setting up the
constructor. See my comments on your example.
// Pull in your dependencies
friends and a small number of my
clients and may expand if it works out so well.
Thank you,
On Tuesday, January 8, 2013 2:41:31 PM UTC+7, Marco Rogers wrote:
From your link, it looks like you want to do live streaming to a
dynamic
list of recipients. That is a large topic, and use
Condition style is always available as an option. But in the types of
situations you're describing, where you actually want to end the execution
early, you end up using condition style because abort style does not exist.
That's the case with array.forEach, and it's one of the reasons array.some
From your link, it looks like you want to do live streaming to a dynamic
list of recipients. That is a large topic, and use nodejs doesn't begin
to cover it. Voxer does live audio streaming with node and they have a
large system and use many many servers. So I'd think real hard about
standing
Here's the article I wrote on checking in modules as well. I haven't really
tried shrinkwrap, but it sounds like there are enough differences between
the two approaches that you should explore both and see which one suits
your needs best. I would employ shrinkwrap on a project where the deploy
://groups.google.com/group/nodejs?hl=en?hl=en
--
Marco Rogers
marco.rog...@gmail.com | https://twitter.com/polotek
Life is ten percent what happens to you and ninety percent how you respond
to it.
- Lou Holtz
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki
Yeah I wish there was a better story for this. It's easy to forward errors.
It could become difficult to determine in what context the error was thrown.
:Marco
On Wednesday, November 28, 2012 9:10:51 AM UTC-8, Jeff Barczewski wrote:
I was recently testing some stream piping like
rstream
@Mark It's not really apples and oranges in this case. More so than other
languages used for building applications, PHP can't really be separated
from all the built-in stuff that comes with it. It becomes more of a
platform, like node. There are a lot of significant differences, but those
One thing you may be missing is that requiring a module multiple times does
not load multiple version of it. Modules are cached after the first time
they are required, so you get the same reference every time. So one answer
to your question is that people re-use modules by requiring them in
It took me a while to get a good conceptual understanding of the node async
networking layer (I still don't have a concrete understanding). I just did
a quick search around and didn't really find anything. I think it's really
interesting and instructive to get a handle on how different OSes
I tend to agree with the OP. If node supports strings, they should be valid
strings. The name setEncoding implies that we plan to respect that
encoding. Anything else is surprising. I think we're all sympathetic to the
perf arguments. But that's something that can be worked on. I'd like to see
Turns out I was full of shit here. Sorry for helping stir things up without
doing my homework.
https://github.com/joyent/node/issues/4160#issuecomment-9553750
:Marco
On Wednesday, October 17, 2012 9:19:34 PM UTC-7, Marco Rogers wrote:
I tend to agree with the OP. If node supports strings
Do you guys wonder why there is a collective groan when you show up?
Especially considering how difficult it is for a group of geographically
remote people to convey a collective groan in a written medium ;)
Threads-a-go-go lives exactly where it should; in userland where anyone who
wants to
, at September 17, 20123:08 PM, Jorge
jo...@jorgechamorro.com wrote:
On 17/09/2012, at 12:04, Marco Rogers wrote:
Do you guys wonder why there is a collective groan when you show up?
Especially considering how difficult it is for a group of geographically
remote people to convey a collective groan
the
experimentation phase, and that is decidedly where node is at.
-Mikeal
On Sep 17, 2012, at September 17, 20124:25 PM, Marco Rogers
marco@gmail.com javascript: wrote:
I admit to willingly participating in this because I was off today and had
nothing better to do. :)
I don't think
Your link is being weird for some reason. Here's a better
url. https://github.com/hut78/troop.js
On Sunday, September 16, 2012 4:54:24 PM UTC-7, Kevin Jones wrote:
Just thought I would add from experience of building a threaded version of
node. The process.* problem does not really exist if
It depends on the module and what it's doing. Can you point to it and give
some more info about your use case?
:Marco
On Sunday, September 16, 2012 1:59:02 PM UTC-7, Mike Nichols wrote:
I am using a module which uses a net.createConnection (for redis) per
stream instance. This would seem
stream.redis.write(Redis.parse([ 'select', this.db ]))
return stream
On Sunday, September 16, 2012 7:45:46 PM UTC-5, Marco Rogers wrote:
It depends on the module and what it's doing. Can you point to it and
give some more info about your use case?
:Marco
On Sunday, September 16, 2012 1:59
answer whether creating a connection each time is too
expensive, or whether I should cache connections for reuse.
On Sunday, September 16, 2012 9:09:58 PM UTC-5, Marco Rogers wrote:
You can definitely get into trouble if you plan to create lots of these
steam objects. node_redis and other
I'd change lots of things. But it's probably a good idea that I'm not in
charge. Ditto Crockford.
:Marco
On Saturday, September 15, 2012 7:42:45 PM UTC-7, Mark Hahn wrote:
I would like to see a fork of node.
What would you change?
On Sat, Sep 15, 2012 at 6:35 PM, Tim Dickinson
Don't know if you were at Node Summercamp, but we talked a lot about
domains. It's clear that there's lots of confusion about the semantics.
I've got some of the same questions. I had planned on finally sitting down
to explore them tomorrow. I can tell you that domains *are* nested. When
you
2.5. Never used it.
:Marco
On Wednesday, August 29, 2012 4:07:23 PM UTC-7, Isaac Schlueter wrote:
Do you use the clientError event?
Please choose one:
1. Yes, I use it all the time. Please don't change it ever, thank you.
2. I don't use it, but I'm aware of it, and I think I might
that enable backwards compatibility
like the buffer-compat I mentioned above. And then maybe collect those into
a node-0.8-compat that folks can pull into their modules as an easy way to
try and support older environments. That may not be feasible. But it's an
idea.
Thanks
:Marco
--
Marco Rogers
It looks like you want to use the google jsapi in the server in node. I think
you'll have a hard time because that library assumes a browser DOM environment.
You can't just use it as is.
But that's not your only problem here. chunk.google.load doesn't make any
sense. It sounds like you may
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
--
Marco Rogers
marco.rog...@gmail.com | https://twitter.com/polotek
Life is ten percent what happens to you and ninety
Recommended by a majority of your community peers that you respect. And yes
that is a vague and fuzzy definition. It should be because there's no
prescription here. We're just talking about a rough priority list that tries to
reflect the prevailing trends.
Or at least that's what I've been
Your rant has a lot of truth to it. But many people in the node community
don't see this as completely negative. Node is still young and it has a lot
of catching up to do in terms of developing a large robust library space.
Having a lot of activity and people reinventing wheels is part of that.
Yep. And I always steer people away from instanceof. It's too unpredictable
and often unnecessary.
I'm in agreement with Mikeal. As often as possible you should try to make
node host objects behave like js objects.
:Marco
On Saturday, June 23, 2012 12:20:50 AM UTC-7, Jorge wrote:
Yeah I think there are 2 things happening here.
- Should process.env and other node host objects try as hard as possible to
behave like real js objects?
I think the majority says yes here.
- Should objects used as simple hashes have their prototype nulled out, in
order to avoid some of common
On Saturday, June 23, 2012 4:51:06 PM UTC-7, josh wrote:
Another question, regarding the documentation of http -
how come the res argument of the callback that is called on http.reuest is
not listening to the 'end' event in the example?
://groups.google.com/group/nodejs?hl=en?hl=en
--
Marco Rogers
marco.rog...@gmail.com | https://twitter.com/polotek
Life is ten percent what happens to you and ninety percent how you respond
to it.
- Lou Holtz
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki
And object with a blank prototype is a little nicer for using as a hash.
You don't have to worry about iterating over they keys with for..in and
getting the Object.prototype properties.
var o = {}
o.toString // function toString() { [native code] }
'toString' in o // true
o =
Buffer.concat FTW! I just wrote this myself the other day.
On Friday, June 15, 2012 12:48:36 PM UTC-7, Isaac Schlueter wrote:
This is the most stable 0.7 release yet. Please try it out.
Version 0.8 will be out very soon. You can see the remaining issues
on the github issue tracker.
I'm only just now reading this thread. But I want to add a couple of
comments about __proto__. I've been doing a lot of messing around with
inheritance patterns in js. I've come to feel that using __proto__ is
useful in only a few rare cases and there are usually more standard ways to
That option won't work in this case, because we need
SlowBuffer.prototype to be the exact same object returned from C++.
Interesting. Can you elaborate on this? Is it due to the weirdness with
retrieving the right this object when in C++ land?
:Marco
properties manually.
So for brevity's sake, __proto__ wins here.
On Mon, Jun 11, 2012 at 1:17 PM, Marco Rogers marco.rog...@gmail.comwrote:
That option won't work in this case, because we need
SlowBuffer.prototype to be the exact same object returned from C++.
Interesting. Can you elaborate
/browse_thread/thread/b564ac42ac53e424/7b85530b465f578d
--
Jorge.
--
Marco Rogers
marco.rog...@gmail.com | https://twitter.com/polotek
Life is ten percent what happens to you and ninety percent how you respond
to it.
- Lou Holtz
not paying money, you're not the customer, you're the product. I
would add a corollary. If you're not the customer or the product, then you
don't really matter. Not saying that applies here. But it's an interesting
line of thought.
:Marco
--
Marco Rogers
marco.rog...@gmail.com | https
--
Marco Rogers
marco.rog...@gmail.com | https://twitter.com/polotek
Life is ten percent what happens to you and ninety percent how you respond
to it.
- Lou Holtz
not to take the advice, but what you're doing is trying
to re-characterize this request to something that it is not.
There's currently no good way to assign a handler to the end of the
current RTC.
Agreed. We should add one and call it something besides nextTick :)
:Marco
--
Marco Rogers
I don't know why we can't change it. Sure it may break a lot of working
code. But as you've outlined, replacing it with more preferable methods is
fairly straight forward. It's even easily shimmable for folks who don't
want to upgrade. We're talking about breaking nextTick but can't get rid
of
, results in
unnecessarily convoluted logic.
This isn't going to change for v0.8, but if no one has a use-case
where it's known to break, we can try it early in v0.9.
--
Marco Rogers
marco.rog...@gmail.com | https://twitter.com/polotek
Life is ten percent what happens to you
. The suggestion that we should let it remain
because the current behavior (which is broken for the desired use case)
fills another one it was not designed for and for which we have other
specifically designed API is ludicrous.
-Mikeal
On May 29, 2012, at May 29, 20122:08 PM, Marco Rogers wrote
I believe the current state of things is that the closure method of binding
is optimized and very fast in v8. Function#bind is not. This is partly due
to the fact that nobody uses it, so it may not be worth the time to
optimize. But I agree with those that say do what works for you. Deal with
-optimizations only where they matter.
On Tue, May 29, 2012 at 10:37 AM, Marco Rogers marco.rog...@gmail.com
wrote:
I believe the current state of things is that the closure method of
binding
is optimized and very fast in v8. Function#bind is not. This is partly
due
to the fact that nobody
I'd be fine if people distributed binaries as long as they're not huge. Npm
doesn't try to build anything by default. The only real trick is having
some way to tell npm which bin to use when doing install -g. It may be
something Isaac is willing to help out with. I would ping him on this
There are several potential issues I'm seeing here. But it looks like you
have an incoming stream of json messages that are encrypted and separated
by newlines. You want parse the stream, decrypt each message and then pass
the message to a data handler that expect to each message one by one. Is
Here are the slides from my nodeconf talk last year. Not much about
building properly, but some approachable info about how a native module
works in node. Hope it helps.
http://marcorogers.com/nodeconf-2011/node_addons_presentation.html
:Marco
On Saturday, April 21, 2012 6:50:49 PM UTC-7,
+1
:Marco
If someone has developed a language tool or a library that can ease the
life of the second audience, he should be able to talk about it without
triggering a war.
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
Thanks for the backhanded support Axel :)
Since when can we not make general statements once they've proven
themselves to be generally true? How would we ever have best practices if
nothing ever presented itself as best in the general sense?
:Marco
On Thursday, April 12, 2012 7:48:13 AM
I would've hoped you had more fortitude against the attacks on streamline
then to start throwing around hastily designed benchmarks to prove your
point. It sucks that the sync-looking advocates have to deal with the
level of aggression they do here. I've expressed that to some people
myself,
Yeah I think you need to provide some code. It should actually be pretty
difficult for you to get throughput that slow from node :) I suspect that
you're not doing you async callbacks correctly and blocking the event loop
more than you should be.
:Marco
On Tuesday, April 10, 2012 10:15:34 AM
I'm confused about this. Isolates is being removed from node, not from v8.
node-fibers should still be able to use them right?
On Monday, April 9, 2012 2:51:24 PM UTC-7, Joe Ferner wrote:
Many streamline like APIs use node-fibers (https://github.com/laverdet/
node-fibers
There was a very long and heated debate about this last year sometime. I
can't find it right now. I believe it was split between pull request
comments and a thread on the mailing list. Things were pretty split on
whether we wanted to greatly expand the scope of EventEmitter, by merging
in some
Just sent you a quick pull request :)
On Monday, April 9, 2012 4:32:31 PM UTC-7, Oliver Leics wrote:
Now available on npm:
caevents - 'Catch all events' event emitter for node.js
npm install caevents
Repository:
https://github.com/oleics/node-caevents
--
Job Board:
I use parseInt and always specify the radix. The Number constructor used as
a cast does something totally different. Neither will always do what you
want. But if you're looking for an integer from a string, and you don't
even control it enough to be sure it doesn't have a 0 at the beginning,
On Feb 13, 2012, at February 13, 201210:49 AM, Marco Rogers wrote:
Well there's a separate plan being discussed right now to upgrade the
API to ServerResponse anyway. writeHead is going to be deprecated, so
that's not the best place to put it. But I do agree we should minimize
unnecessary
If you're building an app, check in your dependencies. Take npm out of the
equation (mostly) :)
http://eng.yammer.com/blog/2012/1/4/managing-nodejs-dependencies-and-deployments-at-yammer.html
:Marco
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
+1 one the long-awaited upgrades to http.
I have lots of thoughts on this. But right now I just want to mention a few
things that I think should be part of the criteria here. This may be
controversial, but it helps to illustrate where a lot of my concerns come
from.
A big factor for core APIs
:22 PM, Ben Noordhuis i...@bnoordhuis.nl wrote:
On Thu, Feb 9, 2012 at 03:58, Marco Rogers marco.rog...@gmail.com wrote:
I also think there is a bit of a contradiction between low level and
hiding implementation. IMO low level apis should expose as much as of
the
guts as possible
It looks like what you're created here is a BufferedStream. A read/write
stream that sits between a readstream and a writestream and allows you to
pause/resume and will by buffering data. That's great and I'm finding that
people really need this. I wrote one a while back and tried to get some
Assuming you're sticking with the pipe() method for connecting streams
(which you probably should), there are a few methods for telling when a
stream is done.
The error event will disconnect the pipe and it will throw the error unless
there is another error listener to catch it. The error
88 matches
Mail list logo
