Re: [nodejs] Re: node server can't show characters besides English
it depends on how your terminal is configured. on mac osX for example you
can choose wich character encoding should be used.
Am Freitag, 25. Oktober 2013 04:02:44 UTC+2 schrieb yougen zhuang:
I write some Chinese character into the stdin, isn't it valid utf8?
2013/10/24 mscdex msc...@gmail.com javascript:
On Wednesday, October 23, 2013 11:35:51 PM UTC-4, yougen zhuang wrote:
Even setting ReadableStream.setEncoding('**utf8'), node still can't
show Chinese or other chareacters.
Are you sure the text is (valid) utf-8 and not some other character set?
--
--
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 nod...@googlegroups.comjavascript:
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com javascript:
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 a topic in the
Google Groups nodejs group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/nodejs/N_681AM3bXQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
nodejs+un...@googlegroups.com javascript:.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
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.
Re: [nodejs] Chef-like tool powered by node.js?
Hey Bruno, checkout out some of the systems that we have herehttps://github.com/opsmezzo/composer-systems. This might be closer to what you are looking for. We use the cli tool quillhttps://github.com/opsmezzo/quill (with composer https://github.com/opsmezzo/composer as the api endpoint) to install and manage these systems as well as the configuration that can go with them. Hop in #nodejitsu IRC if you have any questions. You can ping me @jcrugzz. Cheers, Jarrett On Tuesday, October 22, 2013 8:19:35 AM UTC-4, Bruno Jouhier wrote: Thanks José and Aria. I took a quick look at opsmezzo. I'm actually more interested by the cookbooks/recipe side than by the infrastructure and I did not find it yet but I'll dig further. Bruno On Monday, October 21, 2013 11:57:22 PM UTC+2, Aria Stewart wrote: Thinking about it under the name qop. Bruno Jouhier bjou...@gmail.com wrote: I googled a bit but did not find anything like it. Did anyone consider it? Cool features would be: * It's JavaScript * Windows is fully supported (Ruby isn't great on Windows). Bruno -- -- 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.
Re: [nodejs] Chef-like tool powered by node.js?
Checkout nodemiral. I have not yet released yet.
https://github.com/arunoda/nodemiral
Build for a cloud automation service. Works pretty well.
On Friday, October 25, 2013, Jarrett Cruger wrote:
Hey Bruno, checkout out some of the systems that we have
herehttps://github.com/opsmezzo/composer-systems.
This might be closer to what you are looking for. We use the cli tool
quill https://github.com/opsmezzo/quill (with
composerhttps://github.com/opsmezzo/composeras the api endpoint) to install
and manage these systems as well as the
configuration that can go with them. Hop in #nodejitsu IRC if you have any
questions. You can ping me @jcrugzz.
Cheers,
Jarrett
On Tuesday, October 22, 2013 8:19:35 AM UTC-4, Bruno Jouhier wrote:
Thanks José and Aria. I took a quick look at opsmezzo. I'm actually more
interested by the cookbooks/recipe side than by the infrastructure and I
did not find it yet but I'll dig further.
Bruno
On Monday, October 21, 2013 11:57:22 PM UTC+2, Aria Stewart wrote:
Thinking about it under the name qop.
Bruno Jouhier bjou...@gmail.com wrote:
I googled a bit but did not find anything like it. Did anyone consider
it?
Cool features would be:
* It's JavaScript
* Windows is fully supported (Ruby isn't great on Windows).
Bruno
--
--
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.comjavascript:_e({}, 'cvml', 'nodejs@googlegroups.com');
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com javascript:_e({}, 'cvml',
'nodejs%2bunsubscr...@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 javascript:_e({}, 'cvml',
'nodejs%2bunsubscr...@googlegroups.com');.
For more options, visit https://groups.google.com/groups/opt_out.
--
Arunoda Susiripala
@arunoda http://twitter.com/arunoda
http://gplus.to/arunodahttps://github.com/arunoda
http://www.linkedin.com/in/arunoda
--
--
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] application/vnd.api+json - IANA specification for the json api
This may be of your interest, IANA approved the mime type of a json api: application/vnd.api+jsonhttp://www.iana.org/assignments/media-types/application/vnd.api+json http://jsonapi.org/ *application/json is still valid, but if your server has a json api that can be consumed by clients I suppose *that application/vnd.api+jsonhttp://www.iana.org/assignments/media-types/application/vnd.api+jsonis more appropiate. -- -- 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] performance tuning trouble
Anyone see what's slowing down this performance test? http://pastebin.com/Wy32u2T8 -- -- 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.
Re: [nodejs] Re: node server can't show characters besides English
Also keep in mind that the native string type in JavaScript is UCS-16 which
means that any code points higher than 16 bits have to be encoded using
surrogate pairs. (Note that the native encoding is quite different from the
UTF-8 encoding commonly used when serializing strings to binary data)
A quick way to check your terminal's settings is to read stdin as node
buffers and inspect the bytes manually. UTF-8 isn't too hard to recognize
and decode by hand for just a few chars.
On Fri, Oct 25, 2013 at 4:08 AM, greelgorke greelgo...@gmail.com wrote:
it depends on how your terminal is configured. on mac osX for example you
can choose wich character encoding should be used.
Am Freitag, 25. Oktober 2013 04:02:44 UTC+2 schrieb yougen zhuang:
I write some Chinese character into the stdin, isn't it valid utf8?
2013/10/24 mscdex msc...@gmail.com
On Wednesday, October 23, 2013 11:35:51 PM UTC-4, yougen zhuang wrote:
Even setting ReadableStream.setEncoding('**ut**f8'), node still can't
show Chinese or other chareacters.
Are you sure the text is (valid) utf-8 and not some other character set?
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/**node/wiki/Mailing-List-*
*Posting-Guidelineshttps://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 nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@**googlegroups.com
For more options, visit this group at
http://groups.google.com/**group/nodejs?hl=en?hl=enhttp://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to a topic in the
Google Groups nodejs group.
To unsubscribe from this topic, visit https://groups.google.com/d/**
topic/nodejs/N_681AM3bXQ/**unsubscribehttps://groups.google.com/d/topic/nodejs/N_681AM3bXQ/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
nodejs+un...@**googlegroups.com.
For more options, visit
https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
.
--
--
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.
--
--
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.
Re: [nodejs] Alleviating pressure on dependencies, the registry, and the module system
I think the fact that the right hand side of a dep specification can be either a repo (user/repo in github, url), or a version spec satisfied from a (single) registry, but not both, is a problem. I'd particularly like a tool that allows git repos to be used as package sources, with some convention about version tags allowing version dependency specs to be applied, and npm update to work. Not sure about your solution, but I do have a suggestion - don't fork npm. Wrap it. You should be able to write a tool that implements your solution to this, calling npm when necessary to leverage its install capabilities, but not its decision making about where packages come from. Sam -- -- 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.
Re: [nodejs] Chef-like tool powered by node.js?
Hi Bruno, Simalar to the Chef resource lib, I build [mecano](https://github.com/wdavidw/node-mecano). I use it dayly to deploy hadoop cluster. d. -- -- 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: Does not accept mesage from REDIS?
Somebody knows solution?
пятница, 25 октября 2013 г., 1:41:47 UTC+3 пользователь Олег П написал:
Hello!
I use Node.js with Redis.
I want read channel Redis and send messages to client.
This is fragment SERVER code:
const *redis* = require('redis');
const *client* = redis.createClient();
const *subscribe* = redis.createClient()
subscribe.subscribe('*realtime*');
subscribe.on(*message*, function(channel, *message*) {
socket.json.send({'event': 'messageSent', 'name': ID, 'text':
*message*, 'time': time});
socket.broadcast.json.send({'event': 'messageReceived',
'name': channel, 'text': *message*, 'time': time})
});
Client code:
socket.on('connect', function () {
socket.on('*message*', function (msg) {
// alert();
});
});
Hope for you help! Thank you!
--
--
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.
Re: [nodejs] Re: Does not accept mesage from REDIS?
I've been using redis pub/sub fine.
Go through the tutorials again. PS: const should not be used like that, use
var.
Publish / Subscribe
Here is a simple example of the API for publish / subscribe. This program
opens two client connections, subscribes to a channel on one of them, and
publishes to that channel on the other:
var redis = require(redis),
client1 = redis.createClient(), client2 = redis.createClient(),
msg_count = 0;
client1.on(subscribe, function (channel, count) {
client2.publish(a nice channel, I am sending a message.);
client2.publish(a nice channel, I am sending a second message.);
client2.publish(a nice channel, I am sending my last message.);
});
client1.on(message, function (channel, message) {
console.log(client1 channel + channel + : + message);
msg_count += 1;
if (msg_count === 3) {
client1.unsubscribe();
client1.end();
client2.end();
}
});
client1.incr(did a thing);
client1.subscribe(a nice channel);
On Fri, Oct 25, 2013 at 10:56 AM, Олег П ponomarchu...@gmail.com wrote:
Somebody knows solution?
пятница, 25 октября 2013 г., 1:41:47 UTC+3 пользователь Олег П написал:
Hello!
I use Node.js with Redis.
I want read channel Redis and send messages to client.
This is fragment SERVER code:
const *redis* = require('redis');
const *client* = redis.createClient();
const *subscribe* = redis.createClient()
subscribe.subscribe('*realtime*'**);
subscribe.on(*message*, function(channel, *message*) {
socket.json.send({'event': 'messageSent', 'name': ID, 'text':
*message*, 'time': time});
socket.broadcast.json.send({'**event': 'messageReceived',
'name': channel, 'text': *message*, 'time': time})
});
Client code:
socket.on('connect', function () {
socket.on('*message*', function (msg) {
// alert();
});
});
Hope for you help! Thank you!
--
--
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.
--
Bruno Fuster
--
--
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.
Re: [nodejs] Re: Does not accept mesage from REDIS?
Const is the new var in the ES6 world, you should use it everywhere except
for mutable references.
On Oct 25, 2013 9:31 PM, Bruno Fuster brunofus...@gmail.com wrote:
I've been using redis pub/sub fine.
Go through the tutorials again. PS: const should not be used like that,
use var.
Publish / Subscribe
Here is a simple example of the API for publish / subscribe. This program
opens two client connections, subscribes to a channel on one of them, and
publishes to that channel on the other:
var redis = require(redis),
client1 = redis.createClient(), client2 = redis.createClient(),
msg_count = 0;
client1.on(subscribe, function (channel, count) {
client2.publish(a nice channel, I am sending a message.);
client2.publish(a nice channel, I am sending a second message.);
client2.publish(a nice channel, I am sending my last message.);
});
client1.on(message, function (channel, message) {
console.log(client1 channel + channel + : + message);
msg_count += 1;
if (msg_count === 3) {
client1.unsubscribe();
client1.end();
client2.end();
}
});
client1.incr(did a thing);
client1.subscribe(a nice channel);
On Fri, Oct 25, 2013 at 10:56 AM, Олег П ponomarchu...@gmail.com wrote:
Somebody knows solution?
пятница, 25 октября 2013 г., 1:41:47 UTC+3 пользователь Олег П написал:
Hello!
I use Node.js with Redis.
I want read channel Redis and send messages to client.
This is fragment SERVER code:
const *redis* = require('redis');
const *client* = redis.createClient();
const *subscribe* = redis.createClient()
subscribe.subscribe('*realtime*'**);
subscribe.on(*message*, function(channel, *message*) {
socket.json.send({'event': 'messageSent', 'name': ID,
'text': *message*, 'time': time});
socket.broadcast.json.send({'**event': 'messageReceived',
'name': channel, 'text': *message*, 'time': time})
});
Client code:
socket.on('connect', function () {
socket.on('*message*', function (msg) {
// alert();
});
});
Hope for you help! Thank you!
--
--
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.
--
Bruno Fuster
--
--
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.
--
--
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.
Re: [nodejs] Re: Does not accept mesage from REDIS?
On Fri, Oct 25, 2013 at 5:34 PM, Brian Di Palma off...@gmail.com wrote: Const is the new var in the ES6 world, you should use it everywhere except for mutable references. What about block scoped primitive values? const is not the new var—that implies s/var/const/, which is not true. Rick -- -- 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.
Re: [nodejs] Alleviating pressure on dependencies, the registry, and the module system
On Friday, October 25, 2013 12:38:59 PM UTC-4, Sam Roberts wrote: I think the fact that the right hand side of a dep specification can be either a repo (user/repo in github, url), or a version spec satisfied from a (single) registry, but not both, is a problem. What's wrong with specifying the tag or branch for the repo, like: user/repo#v0.1.10 ? -- -- 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.
Re: [nodejs] Alleviating pressure on dependencies, the registry, and the module system
On Friday, October 25, 2013 4:18:14 PM UTC-7, mscdex wrote: On Friday, October 25, 2013 12:38:59 PM UTC-4, Sam Roberts wrote: I think the fact that the right hand side of a dep specification can be either a repo (user/repo in github, url), or a version spec satisfied from a (single) registry, but not both, is a problem. What's wrong with specifying the tag or branch for the repo, like: user/repo#v0.1.10 ? Specifying a tag doesn't let you write an updateable version range like =3.2.15 4.0.0. -- -- 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: Node.js high level API needed
In node, the higher level apis are created by the users (by combining existing modules into a larger project). And if anyone ever say that async io has to go, then I'm going to shoot that person personally! -- -- 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] SiteBoot: new version is out
Hello there! I have released the new version of the siteboot node web development framework to the public domain on github and on npm. New version 0.2.0-beta is OUT. Many great improvements - I can't even start listing all the extra features since the last version because they are just too many... Just type npm install siteboot in an empty folder and you siteboot will setup a working example site for you! (then edit config-local-sample.js and supply login and host for an empty database and save the file as config-local.js) Intro video: http://www.youtube.com/watch?v=U2XS8EgLxZo SiteBoot is great! Here is why: - Easily build web interfaces using node js - Widgets can be created as separate modules that accept post data on the page and you can have several widgets on the same page and things like that. - There is support for a predefined directory structure that all modules and extensions are using - ie if john writes a widget component and provides it as a siteboot plugin then you will be able to just install that plugin and start using his widgets on your site. - Excellent code structure: all objects, views, models and behaviours are separate. - Siteboot comes with object relational mapper (sequelize) that maps database objects to javascript - so you never have to write any sql code and neither do you ever have to create any tables yourself. You just provide an empty database and siteboot automatically creates all the objects inside that database according to the object definitions that you have provided in your project. - You can write plugins for siteboot using the plugin architechture. - You can directly make use of the bootstrap layout features since bootstrap 3 ALSO comes siteboot (like fluid layouts for responsive websites that work just as well on mobile platforms as they do on desktop). So node + bootstrap + sql objects and a standalone web server - all in one - for writing apps and guis using node! Tell me this is not great? ;-) Github page: https://github.com/mkschreder/siteboot.js -- -- 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.
Re: [nodejs] Alleviating pressure on dependencies, the registry, and the module system
On Thursday, October 24, 2013 10:08:23 PM UTC-7, Alex Kocharin wrote:
25.10.2013, 07:48, Stuart P. Bentley stu...@testtrack4.comjavascript:
:
The way I see it, the dependencies hash in package.json right now is
pulling double-duty. In some cases (where the value of a dependencies field
is a semver), it's there to describe *generally* what module versions it
expects to be compatible with. In other cases (when the value of a field is
a URL), it's there to describe the *exact* version of a module it's used
with.
Dependencies should specify an open version range (unless there is a
really good reason to do otherwise).
If someone wants an exact version, he should probably learn about
shrinkwrap.
Did you read the rest of the proposal? Take a look at the section that
starts Loose semver ranges used to be a Big Important Deal. tl;dr: in
Node, open version ranges only apply to updates, and there is a really good
reason to shrinkwrap (you can't be sure about those updates before they're
released, and once they are you should explicitly confirm you can use them).
This mixed-purpose approach has a few shortcomings: for one, packages
outside the canonical registry can't specify version ranges.
Why? I don't have any issues with that when I use version ranges for
packages in my private registry.
Because running and requiring a private registry is mega impractical,
especially if you want to publish modules that are usable outside your
registry.
- Use a different hash (let's call it wants) that handles
future-looking package usage, where each package (by
node_modules/package.json/require() name)
Don't add any more hashes. Plase. Just modify a dependency hash to be
a hash of hashes like that:
dependencies: {
package1: {
version: '= 0.1.2-something',
isDevDependency: true,
isOptional: true,
wants: 'more cookies',
},
package2: {
}
}
Changing the read semantics of existing fields in package.json would break
everything that currently reads package.json. That's untenable. That's why
I'm talking about introducing a new hash:it doesn't require any changes to
be compatible with what already exists.
Current situation with multiple, but similar hashes
(optionalDependencies, peerDependencies, devDependencies, etc.) ain't
extensible and very much suck.
I agree that the optionalDependencies and devDependencies solutions suck-
if you read the proposal, you'll notice that the wants hash allows an
extensible alternative to those (one that doesn't break the compatibility
with older systems).
The important thing here is backwards compatibility. Adding a future-proof
hash keeps compatibility and utility of the existing hashes, in a way that
still works with what's already out there. You don't just break 45,000
packages because they weren't perfect.
What does the community think? If npm wouldn't be willing to go ahead with
something like this, any interest in producing some kind of fork?
Almost definitely yes. This feature alone hardly worth a fork, but there
are many things that are wrong with npm, so forks can be quite useful here.
Frankly speaking, I'd even be interested in remaking it from scratch
because some things are just too hard to fix.
npm works pretty well right now and still has tons of traction with module
developers. Gently modifying it to work with what people are already doing
it is a much more feasible approach than saying drop everything and come
do my completely different thing.
--
--
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.
Re: [nodejs] Alleviating pressure on dependencies, the registry, and the module system
On Friday, October 25, 2013 9:38:59 AM UTC-7, Sam Roberts wrote: I think the fact that the right hand side of a dep specification can be either a repo (user/repo in github, url), or a version spec satisfied from a (single) registry, but not both, is a problem. I'd particularly like a tool that allows git repos to be used as package sources, with some convention about version tags allowing version dependency specs to be applied, and npm update to work. The convention is tags that are in the form 'v' followed by a valid semver. Using npm version produces tags that fit this convention. Not sure about your solution, but I do have a suggestion - don't fork npm. Wrap it. You should be able to write a tool that implements your solution to this, calling npm when necessary to leverage its install capabilities, but not its decision making about where packages come from. A fork of npm would essentially be a wrapper- npm is itself largely a wrapper around the modules that provide npm's functionality. I've been thinking a good approach might be making something like a set of grunt plugins that replicate npm's functionality, then building on top of 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 --- 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.
Re: [nodejs] Alleviating pressure on dependencies, the registry, and the module system
On Thu, Oct 24, 2013 at 8:48 PM, Stuart P. Bentley stu...@testtrack4.com wrote: The way I see it, the dependencies hash in package.json right now is pulling double-duty. In some cases (where the value of a dependencies field is a semver), it's there to describe generally what module versions it expects to be compatible with. In other cases (when the value of a field is a URL), it's there to describe the exact version of a module it's used with. Fair point. This mixed-purpose approach has a few shortcomings: for one, packages outside the canonical registry can't specify version ranges. By canonical registry do you mean npmjs.org? Because you definitely can use ranges with a separate registry. What's worse, any discussion of these shortcomings inevitably devolves into a back-and-forth over the utility of the registry (with arguments over everything from naming techniques, to implied triviality, to diplomatic protocol). Indeed. Loose semver ranges used to be a Big Important Deal, back in the packaging flatlands of Python and Ruby. In those worlds, every module in use had to agree to share one particular version of any module- every module had to accommodate any potentially outdated code. Where a dependency was coming from didn't matter, but the ways it would be acceptable to come was. In Node, however, packages, once installed, will never see their dependencies versions any older than the latest they were written (unless they're peerDependencies). The one purpose of ranges is to allow potential optimizations and bugfixes from any future revisions of dependencies, without having to explicitly declare it. At this point, keeping that looseness, as a core attribute of the runtime, is a weakness, one that's overshadowing the increasingly pressing issue of where that package is located. You're neglecting the dedupe case. That's very relevant for some use cases, especially for frontend packages. dependencies is tightened up for repository packages (bringing them to the specificity non-repository packages are already subject to). New packages can't rely on ranges that can become invalid (due to either a too-loose semver requirement or a breaking change in a minor version). A guaranteed shrinkwrapped dependencies field means you know *exactly* what revisions the package was developed against at time of publication. What's the point of doing that? Just to have the metadata for packages that aren't bundling their deps? Changing the semantics of the dependencies field is completely out of the question. If there's a strong case for tracking that info, and a field that's not already in use in the wild, then I'd consider doing it as something other than dependencies. Packages outside the registry are no longer second-class citizens. Well, yeah, they sort of are. Users can't search for them, install them by name, etc. Calling npm install or npm update with a package.json that uses semver ranges (or tagless git URLs) automatically shrinkwraps dependencies and converts the existing dependencies values to the equivalent wants. Never gonna happen, sorry. Way too much stuff depends on dependencies working exactly like it does. `npm update` would have to read the wants field, and would need additions to find available semver tags in non-registry locations (like tags in a Git repo). What cases is that relevant for? npm update already re-fetches from git and urls. If you specify a url, then you want to update, well, ok, put a new thing at that url. Same with git, just specify a branch, and it'll always pull the latest from that branch. For developers, the listed semvers would need to be loosened/tightened appropriately, and `npm update` would be required to update a code's dependencies. (Good.) Why is this good? What's wrong with updating using `npm i asdf --save`? -- -- 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.
Re: [nodejs] Alleviating pressure on dependencies, the registry, and the module system
On Saturday, October 26, 2013 4:26:43 AM UTC+4, Stuart P. Bentley wrote: On Thursday, October 24, 2013 10:08:23 PM UTC-7, Alex Kocharin wrote: This mixed-purpose approach has a few shortcomings: for one, packages outside the canonical registry can't specify version ranges. Why? I don't have any issues with that when I use version ranges for packages in my private registry. Because running and requiring a private registry is mega impractical, especially if you want to publish modules that are usable outside your registry. My private registry currently eats 40 megabytes of memory and 57 megabytes of diskspace, including 33 lines of config file. Sounds impractical yeah. Current situation with multiple, but similar hashes (optionalDependencies, peerDependencies, devDependencies, etc.) ain't extensible and very much suck. I agree that the optionalDependencies and devDependencies solutions suck- if you read the proposal, you'll notice that the wants hash allows an extensible alternative to those (one that doesn't break the compatibility with older systems). The important thing here is backwards compatibility. Adding a future-proof hash keeps compatibility and utility of the existing hashes, in a way that still works with what's already out there. You don't just break 45,000 packages because they weren't perfect. dependencies: Object|String is backward-compatible in regard to existing packages. I thought it's obvious. What does the community think? If npm wouldn't be willing to go ahead with something like this, any interest in producing some kind of fork? Almost definitely yes. This feature alone hardly worth a fork, but there are many things that are wrong with npm, so forks can be quite useful here. Frankly speaking, I'd even be interested in remaking it from scratch because some things are just too hard to fix. npm works pretty well right now and still has tons of traction with module developers. Gently modifying it to work with what people are already doing it is a much more feasible approach than saying drop everything and come do my completely different thing. If npm was working well, we weren't be here discussing this right now. ;) -- -- 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.
Re: [nodejs] Alleviating pressure on dependencies, the registry, and the module system
shrinkwrap doesn't really work well in practice, it almost never makes
sense to not pin versions directly. Even bug fixes introduce
non-deterministic behaviour in an application so if you're not uber
rigorous at the QA level in stage it's pretty likely to screw you over
On Thursday, 24 October 2013 22:08:23 UTC-7, Alex Kocharin wrote:
25.10.2013, 07:48, Stuart P. Bentley stu...@testtrack4.comjavascript:
:
The way I see it, the dependencies hash in package.json right now is
pulling double-duty. In some cases (where the value of a dependencies field
is a semver), it's there to describe *generally* what module versions it
expects to be compatible with. In other cases (when the value of a field is
a URL), it's there to describe the *exact* version of a module it's used
with.
Dependencies should specify an open version range (unless there is a
really good reason to do otherwise).
If someone wants an exact version, he should probably learn about
shrinkwrap.
This mixed-purpose approach has a few shortcomings: for one, packages
outside the canonical registry can't specify version ranges.
Why? I don't have any issues with that when I use version ranges for
packages in my private registry.
- Use a different hash (let's call it wants) that handles
future-looking package usage, where each package (by
node_modules/package.json/require() name)
Don't add any more hashes. Plase. Just modify a dependency hash to be
a hash of hashes like that:
dependencies: {
package1: {
version: '= 0.1.2-something',
isDevDependency: true,
isOptional: true,
wants: 'more cookies',
},
package2: {
}
}
Something along these lines. Current situation with multiple, but similar
hashes (optionalDependencies, peerDependencies, devDependencies, etc.)
ain't extensible and very much suck.
What does the community think? If npm wouldn't be willing to go ahead with
something like this, any interest in producing some kind of fork?
Almost definitely yes. This feature alone hardly worth a fork, but there
are many things that are wrong with npm, so forks can be quite useful here.
Frankly speaking, I'd even be interested in remaking it from scratch
because some things are just too hard to fix.
--
--
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.
