We're definitely not going to change node in the way you suggest.
Async is the default by design. Mark Hahn expressed the reasons quite
well, so I won't reiterate them.
Sync methods look different because they *are* different.
Automatically switching from async to sync would be a violation of
No
>> I'm sorry if this has been discussed before, but I couldn't find
anything.
It has, probably 10 times a month. :) No joke!
Nuno
On Mon, Apr 2, 2012 at 12:09 AM, Isaac Schlueter wrote:
> We're definitely not going to change node in the way you suggest.
>
> Async is the default by design. Mar
On Apr 2, 2012 3:19 AM, "Nuno Job" wrote:
>
> >> I'm sorry if this has been discussed before, but I couldn't find
anything.
>
> It has, probably 10 times a month. :) No joke!
>
Also, 'use the right tool for the job'. No one seems to get this.
I'd start killing if I ever saw a js library talking
Asynchronicity in Node can not be made optional as it is (by design)
the default.
On Mon, Apr 2, 2012 at 4:20 AM, Olivier Lalonde wrote:
> I believe there would be an easy way to change the status quo without
> impacting developers who chose to adhere to a strict async style. The
> solution I pr
> I'm aware of that. Writing sync web apps would imply using one
> process/worker by request like other popular languages do (PHP/Ruby/etc.). I
> think it is still interesting to use Javascript for backend development even
> without the async stuff.
Since Node/V8 has a rather longish startup time,
> Sync methods look different because they *are* different.
'xcept require...
--
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.
T
I think the Sync alternative functions in core should go entirely.
They clutter APIs (and mentalities).
On Mon, Apr 2, 2012 at 10:53 AM, Oliver Leics wrote:
> Asynchronicity in Node can not be made optional as it is (by design)
> the default.
>
>
> On Mon, Apr 2, 2012 at 4:20 AM, Olivier Lalonde
Hi everyone,
Still tired of hugely different Web APIs etc etc... ok, I'll cut to
the chase again. There's a new version of 'awssum' - v0.4.0 released!
:)
* npm show awssum
* http://search.npmjs.org/#/awssum
* https://github.com/appsattic/node-awssum
Since v0.3.0 there have been a couple of impor
Hi STT,
I'm the author of The Node Beginner Book. I'm not sure which code you are
referring to. I've searched the book to double-check it, but there is no
code that looks like
route(handle, pathname, query, response, postData);
At the end of the tutorial, the complete route function signature
> It goes against the grain of everything node is.
I'm gonna second that. And besides, I imagine it shouldn't that hard
to roll a thin sync interface over the node core APIs using something
like fibers (https://github.com/laverdet/node-fibers)
On Apr 2, 10:00 am, Mark Hahn wrote:
> > I think i
Cool!!! I am using AWS this is much help
Victor Pereira
On Apr 2, 2012 8:42 AM, "Andrew Chilton" wrote:
> Hi everyone,
>
> Still tired of hugely different Web APIs etc etc... ok, I'll cut to
> the chase again. There's a new version of 'awssum' - v0.4.0 released!
> :)
>
> * npm show awssum
> * ht
Thanks Andy, this is a really useful module!
On 2 April 2012 12:42, Andrew Chilton wrote:
> Hi everyone,
>
> Still tired of hugely different Web APIs etc etc... ok, I'll cut to
> the chase again. There's a new version of 'awssum' - v0.4.0 released!
> :)
>
> * npm show awssum
> * http://search.n
I think that the sync API is useful (and I extensively used it) for
shell scripts mainly.
Especially the following API *should* (in my opinion) have sync
alternatives (maybe a separate module so that there is NO confusion
what-so-ever).
1. Filesystem (already exists)
2. SQL (sqlite/mysql/pg/etc..
Async is a lower level of abstraction than sync, so having sync versions of
existing calls wouldn't be as useful as it may first seem.
For example, to make an HTTP request and read data from it, you would still
need to make multiple calls: first to make the request, then upon receiving
the soc
Node is non-blocking and will always be. That's the core concept of node.
However there are other use cases. I believe the original question was
asking if there was a way to have a blocking system (which is simpler in
many respects), but only diverge from node as much as required.
The one quest
The Ace lib does this, via some Fiber stuff. https://github.com/maccman/ace.
I've never tried it myself though.
BTW, with ruby 1.9 you can handle lots of requests per process via native Fiber
support. See Sinatra::Synchrony
(https://github.com/kyledrake/sinatra-synchrony) and Goliath
(http:/
> The pure JS modules from node can be used mostly as-is.
The only one I can thing of is underscore.
--
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
Fibers aren't blocking. They are faux blocking. If the process was really
blocked it wouldn't be able to work on other stuff. And you can do fibers
in node today, just be aware of the tradeoffs and concurrency gotchas
involved.
My recommendation is to not use fibers or code transforms like stre
On Mon, Apr 2, 2012 at 8:33 PM, Tim Caswell wrote:
> My recommendation is to not use fibers or code transforms like streamline,
> or even coffeescript till your first understand the simple callback based
> approach of raw node with vanilla javascript. Then once you're mastered
> that, if the othe
On Mon, Apr 2, 2012 at 20:42, Oliver Leics wrote:
> On Mon, Apr 2, 2012 at 8:33 PM, Tim Caswell wrote:
>> My recommendation is to not use fibers or code transforms like streamline,
>> or even coffeescript till your first understand the simple callback based
>> approach of raw node with vanilla ja
> I suspect that the OP is congratulating himself on a well-executed
April Fools' joke...
Damn, you're probably right.
--
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 subscri
@deitch-
I see the problem differently. I would say that the fundamental problem of
a client-side module loader is exactly the same as that of a server-side
one:
1) Allow me to write really modular reusable code, without artificial
restrictions.
The client-side module loader has a lot of doma
As I understand it, webmake is the same thing as requirejs+optimizer: the
only difference is webmake uses sync require syntax and requirejs+optimizer
uses async syntax. In the end you have all 100+ files loading as a single
file.
Opposed to this, consider just using requirejs without its optimi
I am using nano (nuno's excellent couch module) and Mikeal's excellent
Request module to access couch db. I'm processing about 5 to 25 PUTs/sec
and around 200 GETs/sec.
In a specific situation I am seeing a PUT (create new doc) take 10 to 20
seconds to respond. It takes 5 seconds to get the http
Node Filewalker
Fast and rock-solid asynchronous traversing of directories and files for node.js
https://github.com/oleics/node-filewalker
npm install filewalker
To run the tests: mocha -R spec
node v0.4 is enabled in the npm package and should theoretically work,
but it is untested as mocha ha
Little late here, but I use a buffering mechanism for reading like so:
https://github.com/cretz/node-tds/blob/master/src/buffer-stream.coffee. I
found myself getting stuck several times where only half of what I expected
was available, so I implemented a "transaction" type of thing that rolls
b
On Mon, Apr 2, 2012 at 16:52, Oliver Leics wrote:
> Node Filewalker
> Fast and rock-solid asynchronous traversing of directories and files for
> node.js
> Feedback is very welcome.
a find2node or find2walk (shell command - idea from find2perl) where
you take find parameters and convert it into
Have you tried listening on 2 different port. I don't think you can bind
twice on the same port.
Naouak, Grade 2 de Kobal.
Site web: http://www.naouak.net
On Mon, Apr 2, 2012 at 23:35, Emerson Espínola wrote:
> Hi,
>
> I'm trying to listen for datagrams in 2 address.
>
> var dgram = require('dg
Looks awesome!
Thank you.
--
Shaun
On Tuesday, 3 April 2012 at 6:57, shawn wilson wrote:
> On Mon, Apr 2, 2012 at 16:52, Oliver Leics wrote:
> > Node Filewalker
> > Fast and rock-solid asynchronous traversing of directories and files for
> > node.js
> >
>
>
> > Feedback is very welcome
On Mon, Apr 2, 2012 at 23:35, Emerson Espínola
wrote:
> Hi,
>
> I'm trying to listen for datagrams in 2 address.
>
> var dgram = require('dgram');
> var server = dgram.createSocket("udp4");
> server.bind(8001, "192.168.65.66");
> server.bind(8001, "192.168.33.34");
>
> I'm always able to bind to t
> The one question I have with such a suggestion is how much code do you
> expect to share with the node ecosystem?
I suppose if the answer is zero, this is what I've also been looking
for! A syncronous javascript engine for little syncronous scripting
tasks. Not web-serving, not web-scale etc. Ju
On Saturday, March 31, 2012 5:07:40 AM UTC-7, Ben Noordhuis wrote:
>
> On Sat, Mar 31, 2012 at 03:57, zaheer ahmad wrote:
> > http.request doesnt seem to fire error callback if there is not network
> > connection on linux. on windows it seems to work fine. Are there
> workarounds
> > to check for
So I would like to know where node thinks it will be in 1 year?
What are things that are been looked at for improvement with node as a
whole?
At some point nodes going to run into a wall, and that wall is javascript.
I feel that js is nodes achilles heel. I LOVE js and live by it but its has
f
> At some point nodes going to run into a wall, and that wall is
javascript.
In what way is javascript limiting?
--
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
> So I would like to know where node thinks it will be in 1 year?
Well, node core, I think, is in a place where it's starting to
converge on an intended final state. You won't see any sweeping api
changes probably, and instead will see improvement in the user
experience and a lot of stability fix
hey chad how does your buffer stream define a piece, is it just length based or
is there an interface for defining what constitutes a piece, I think something
flexible like that would be great for making various streaming parsers
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https:
Hi,
I have no idea, but can you send me a script that helps me reproduce the
bug?
I can act on that,
Nuno
On Mon, Apr 2, 2012 at 12:31 PM, Mark Hahn wrote:
> I am using nano (nuno's excellent couch module) and Mikeal's excellent
> Request module to access couch db. I'm processing about 5 to
Also NANO_ENV=testing will log stuff out.
nuno
On Mon, Apr 2, 2012 at 5:21 PM, Nuno Job wrote:
> Hi,
>
> I have no idea, but can you send me a script that helps me reproduce the
> bug?
>
> I can act on that,
>
> Nuno
>
>
> On Mon, Apr 2, 2012 at 12:31 PM, Mark Hahn wrote:
>
>> I am using nano
I hate it when this happens. I enabled logging and the problem went away.
I removed logging and the problem is still gone. I'll just cross my
fingers that it doesn't come back.
On Mon, Apr 2, 2012 at 5:22 PM, Nuno Job wrote:
> Also NANO_ENV=testing will log stuff out.
>
> nuno
>
>
> On Mon, A
Maybe you exhausted your network pipe and fucked with your hardware a bit?
Make it reproducible and I'll try to fix it
Nuno
On Mon, Apr 2, 2012 at 5:25 PM, Mark Hahn wrote:
> ss my finge
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-Li
My internet pipes must have been clogged.
On Mon, Apr 2, 2012 at 5:28 PM, Nuno Job wrote:
> Maybe you exhausted your network pipe and fucked with your hardware a bit?
>
> Make it reproducible and I'll try to fix it
>
> Nuno
>
> On Mon, Apr 2, 2012 at 5:25 PM, Mark Hahn wrote:
>
>> ss my finge
>
What about stuff like JSON.stringify. The whole idea of node and its stream
with stringify and parse just dont fit. It worked in the browser but might
not be the best for node.
How can we better do things that javascript is not so great at. Like
JSON.pipe with the work been done in c++ and it pa
Can't this be dealt with in external modules?
On Mon, Apr 2, 2012 at 6:33 PM, Tim Price wrote:
> What about stuff like JSON.stringify. The whole idea of node and its
> stream with stringify and parse just dont fit. It worked in the browser but
> might not be the best for node.
> How can we bette
On Mon, Apr 2, 2012 at 6:53 PM, TipTop wrote:
> So I would like to know where node thinks it will be in 1 year?
>
> What are things that are been looked at for improvement with node as a
> whole?
>
> At some point nodes going to run into a wall, and that wall is javascript.
> I feel that js is no
In a year v8 will implement yield in the form of generators and finally we
will have a robust tool that can expressively mitigate the nested callback
problem.
I'm sorry.
On Mon, Apr 2, 2012 at 5:53 PM, TipTop wrote:
> So I would like to know where node thinks it will be in 1 year?
>
> What are
> Can't this be dealt with in external modules?
Yes it can but should it?
Extending the language is where my mind drifts. JavaScript has a lot of
baggage thanks to 20 years of crap browsers, and think some of the baggage
has been brought along with the coming of node.
--
Job Board: http://jo
> Extending the language is where my mind drifts.
That's not really something node's interested in. The various working
groups might make language proposals and the v8 peeps might implement
some of them, but that stuff's outside node's scope.
> These are the improvements that node need to think a
> JavaScript has a lot of baggage thanks to 20 years of crap browsers,
Your trolling isn't really working. Why did you change your name since the
OP?
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this
On Monday, April 2, 2012 11:22:45 PM UTC-5, Mark Hahn wrote:
>
> > JavaScript has a lot of baggage thanks to 20 years of crap browsers,
>
> Your trolling isn't really working. Why did you change your name since
> the OP?
>
Apparently threading isn't working, because I can't tell what you are
Who says we have to fall back to C++.
https://gist.github.com/1973743
No limits! 30k lines of wrappers is a go.
At that point, just like Rails did with Ruby, you need to extend the
> language by coding C++ modules and wrappers to improve performance where
> needed, or isolate calculation hea
It does look like it. I think I like the sync style better only because it
maps so cleanly to what we know and love in node. On the other hand, the
browser is *not* node; modules in node are loaded directly from the local
filesystem, which can be done much more efficiently than in the browser,
51 matches
Mail list logo
