Re: [nodejs] Re: process.env - documentation?

[Alex Kocharin]

I think that common nodejs related env variables like NODE_ENV or 
NODE_DEBUG should be there, but there's no need to add any others.

On Thursday, November 1, 2012 5:13:39 PM UTC+4, Matt Sergeant wrote:
>
> If the docs covered every aspect of how programming networks, child 
> processes, systems and filesystems worked they would be huge.
>
> There's a place for tutorials though - but it's not in the core docs IMHO. 
> If you don't know what an environment variable is then you have some basic 
> learning to do before diving straight into programming.
>
>
> On Wed, Oct 31, 2012 at 7:28 PM, SL >wrote:
>
>> Or we could make the docs a bit clearer...
>>
>>
>> On 31 October 2012 18:46, Jorge 
>> > wrote:
>>
>>> On 31 oct, 17:26, Scott Elcomb  wrote:
>>> > On Wed, Oct 31, 2012 at 10:59 AM, Jorge
>>> >
>>> >  wrote:
>>> > > On Oct 31, 2:04 pm, Bgsosh  wrote:
>>> > >> Hi, I'm tring to understand the structure of the process.env 
>>> object, but
>>> > >> the online docs just say 'An object containing the user 
>>> environment. See
>>> > >> environ(7).'
>>> >
>>> > >> I can't find 'environ(7)' (whatever that is!).  Is this documented
>>> > >> somewhere?
>>> >
>>> > > Type this in the terminal:
>>> >
>>> > > $ man 7 environ
>>> >
>>> > That'd be tricky for Windows users to do if they're not running a
>>> > *nix-like shell. (Cygwin comes to mind)
>>> >
>>> > I'd imagine the best bet for Windows users would be to search for "man
>>> > 7 environ" on the web to find a copy of the relevant man page; there
>>> > are a number of mirrors like the one Adam suggested.
>>> >
>>> > (BTW, for those not familiar with man pages, see also
>>> > )
>>>
>>>
>>> Perhaps Windowzs users should better search for "environment
>>> variables" @ msdn or something, I guess, yeah.
>>> --
>>> Jorge.
>>>
>>> --
>>> Job Board: http://jobs.nodejs.org/
>>> Posting guidelines: 
>>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>>> You received this message because you are subscribed to the Google
>>> Groups "nodejs" group.
>>> To post to this group, send email to 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=en
>>>
>>
>>  -- 
>> Job Board: http://jobs.nodejs.org/
>> Posting guidelines: 
>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>> You received this message because you are subscribed to the Google
>> Groups "nodejs" group.
>> To post to this group, send email to 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=en
>>
>
>

-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] tail a log and send out using socket.io

[Alex Kocharin]

Angelo, see pupergrep ( https://github.com/bobrik/pupergrep ), I think it's does exactly the same as an app you are trying to implement.-- // alex  10.11.2012, 13:53, "Angelo Chen" :you are correct, removing broadcast works. a not so related question, in the browser side, I'd like to display only 10 of the lines, if more than that, it scrolls up, what's a good approach to this? thanks.On Saturday, November 10, 2012 5:14:51 PM UTC+8, Cryptic Swarm wrote:You are starting a new process for every connection.You are using the broadcast flag in socket.io.""" Quoted from http://socket.io/#how-to-useBroadcasting means sending a message to everyone else except for the socket that starts it."""In your case you would likely have the messages show up N-1 times (where N is the number of clients connected).  If you only had one client connect you would see the messages 0 times.On Sat, Nov 10, 2012 at 2:03 AM, Angelo Chen  wrote:Hi,  I was trying to tail a log and send the out put to a connected browser, i can see the log data in the part of: tail_child.stdout.on('data', function (data)  from console.log, but the socket.broadcast.emit seems not sending out any data, any way to make this work？ thanks, Angelo  part of app.js  socketio.listen(server).on('connection', function (socket) {     console.log("new socket")      // everytime there is a new request, spawn an child process     var tail_child = spawn('tail', ['-f', '/var/log/system.log']);      tail_child.stdout.on('data', function (data) {         // write it on the console         console.log(data.toString());  // yes, i can see the data here         // send it to the browser because the browser will be waiting for the next chunk of data         socket.broadcast.emit('message', data.toString());  // no, browser can not see any     });      socket.on('disconnect', function () {         tail_child.kill();         console.log('disconnected me')     }); }); index.html             http://ajax.googleapis.com/ajax/libs/jquery/1.7.2/
 jquery.min.js">         socket.io/socket.io.js">         
             $(function () {
                 var iosocket = io.connect();
 
                 iosocket.on('connect', function () {
                     $('#incomingChatMessages').append($
 ('
Connected
'));
 
                     iosocket.on('message', function (message) {
                         $('#incomingChatMessages').append($('
 li>').text(message));
                     });
                     iosocket.on('disconnect', function () {
                         $
 ('#incomingChatMessages').append('
Disconnected
');
                     });
                 });
 
                 $('#outgoingChatMessage').keypress(function (event) {
                     if (event.which == 13) {
                         event.preventDefault();
                         iosocket.send($
 ('#outgoingChatMessage').val());
                         $('#incomingChatMessages').append($('
 li>').text($('#outgoingChatMessage').val()));
                         $('#outgoingChatMessage').val('');
                     }
                 });
             });
                    Incoming Chat:                                 -- 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.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=en  --  Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en



-- 
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

Re: [nodejs] ANN: ssh2 module

[Alex Kocharin]

Hi mscdex,


What about the server part? I've seen plenty of ssh clients, but I couldn't 
find an appropriate node ssh server module, so that could be useful.

-- 
// alex

12.11.2012, 03:00, "mscdex" :
> Hello all!
>
> I'm announcing the first version of my ssh2 module, now available on
> npm.
>
> ssh2 aims to be a complete SSH2 client written in pure JavaScript that
> implements the SSH2 protocol (it does not shell out to a command-line
> ssh client).
>
> Currently it can execute one-off commands and start interactive shell
> sessions. There are still several things to be implemented and
> tweaked, but I think it's at least in a fairly usable and stable state
> now.
>
> Feel free to give it a whirl and report any bugs you may come across.
>
> https://github.com/mscdex/ssh2 (`npm install ssh2`)
>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines: 
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en

-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] understanding module.export

[Alex Kocharin]

 console.log hides object's prototype-- // alex  15.11.2012, 05:41, "Ken Koontz" :I am working on an express app. I've separated my route logic outside of the app.js file, which I'm using for config. I'm trying to configure my db in app.js and export this into any route module that needs it.Here is my db code that i'm pulling into app.js.db file snippethttps://gist.github.com/4076060app.js file snippethttps://gist.github.com/4076065The output from console.log(db); in the app.js file appears to be an empty object. However, when I reference a function such as console.log(db.create) it returns [ Function ]. Why does console.log(db) return {} and not something like {create: [ Function ].} --  Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en



-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] First node.js project would anyone be willing to review my code and give me some feedback?

[Alex Kocharin]

Hi Ryan and Nick,

> Your package.json is not valid json (it's missing commas after some entries). 
> The syntax highlighting in github shows this, as does the error message I got 
> when trying to run "npm start".

Yeah, that's why I usually make package.js and compile it into json later. Why 
aren't it a common practice?


> In package.json, you've listed "*" as some version numbers. You don't know 
> how the authors of those projects will change the interface in the future, so 
> you should understand what semver versions mean and how to specify a version 
> number

I'd point out that, while it might be a good advice for applications (with "~" 
semver operator), it's definitely a wrong one for public packages.

Dependency means "should work with", not "known to work with". If some version 
of a package is excluded, it means that there is a certain reason why it is 
excluded, and this version should be placed in documentation somewhere. This 
way, "*" is fine unless you tested it and proved otherwise.

Packages with locked dep versions effectively prevent to update software  (see 
http://www.mikealrogers.com/posts/nodemodules-in-git.html), can cause multiple 
versions of the same package being used on the same system, etc. In other 
words, they just cause trouble. Don't do that.


-- 
Regards,
Alex

02.12.2012, 14:53, "Ryan Schmidt" :
> On Dec 1, 2012, at 13:31, Nick Italiano wrote:
>
>>  I made a simple single room chat using express, mongoose, and socket.io.
>>  If anyone is willing to give me some feedback or even a code review I would 
>> really appreciate it.
>>
>>  Here is the repo : https://github.com/unboundfire/wowel
>
> Thanks for sharing your code! I ran it briefly and looked through the code 
> and have the following feedback.
>
> Your package.json is not valid json (it's missing commas after some entries). 
> The syntax highlighting in github shows this, as does the error message I got 
> when trying to run "npm start".
>
> In package.json, you've listed "*" as some version numbers. You don't know 
> how the authors of those projects will change the interface in the future, so 
> you should understand what semver versions mean and how to specify a version 
> number that will allow you to accept compatible upstream changes while 
> avoiding potentially incompatible ones. 
> http://blog.nodejitsu.com/package-dependencies-done-right
>
> In app.js, the variable name siteUrl is confusing, since it seems only to be 
> used as the hostname of the mongodb server; you might change this variable 
> name. In javascripts/index.js that variable name is used again but as the 
> hostname of the web server, which seems like a more reasonable use for a 
> variable of that name. But in javascripts/index.js you're only using it to 
> connect back to socket.io, so you probably don't need to hardcode it; you can 
> probably get the correct value out of the location object. Same for 
> javascripts/login.js.
>
> In app.js, you probably shouldn't start listening on your server until after 
> it's been set up (after the app.configure calls, and after the routes are 
> connected).
>
> In app.js and javascripts/index.js, you have some cross-site scripting 
> vulnerabilities because you're not making any attempt to escape 
> msgs['msgs'][i]['msg'] or msgs['msgs'][i]['userid'] or 
> sessionStorage.getItem('userId') or $('#myMsg').val() when concatenating 
> htmlString. http://en.wikipedia.org/wiki/Cross-site_scripting
>
> Whenever you have a form with fields that have labels, like in login.ejs, 
> each  element should have a unique id, and you should enclose the 
> labels in  tags, and use the "for" attribute of the label tag to 
> reference the corresponding input element's id. This way users can click the 
> label to place the insertion point into the corresponding field. 
> https://developer.mozilla.org/en-US/docs/HTML/Element/label
>
> Where you use the term "WhiteSpaces", it should not be plural, and the S 
> probably should not be capitalized. 
> http://en.wikipedia.org/wiki/Whitespace_character
>
> Where you require('mongoose/'), there's no need for there to be a slash at 
> the end.
>
> Where you write require('./UserModel.js'), although that's fine, note that 
> you don't need to specify the ".js" extension; you could just write 
> require('./UserModel').
>
> In models/ChatHistory.js, the addMsg function needs a callback parameter, 
> which it should then call when the save has completed (or has failed with an 
> error). You should use this to test for an error anytime you use the addMsg 
> function. Same goes for addUser in models/User.js.
>
> I'm not sure why you've divided each model into two JavaScript files. Every 
> other example I've seen has just one js file per model and that's worked fine 
> for me.
>
> Of course you should not store the user's password in plain text. Use bcrypt 
> or PBKDF2 or something.
>
> There's no validation on the email address.
>
> The binary files comprising the mongodb datab

Re: [nodejs] Why does htop show mutiple threads for node.js ?

[Alex Kocharin]

Hi Ben,


Would it make sense to use AIO if filesystem supports it? How faster it would 
be? Did somebody run any benchmarks?


I don't know what Windows is (sorry, just trolling), but Linux have a lot of 
filesystems and it's open. If just one filesystem supports AIO and work with 
node.js much better, other will follow. If something silently fall back to sync 
IO, file a bugreport against it, it's as simple as this.


Somebody could even write a npm package that does AIO for a specified 
filesystem. So, anything come up to one question: is it worth it? Any 
benchmarks?


-- 
// alex

29.11.2012, 06:41, "Ben Noordhuis" :
> On Thu, Nov 29, 2012 at 2:43 AM, Tolga Tekin  wrote:
>
>>  Actually that is not completely true - Both Windows and MacOSX's native file
>>  APIs support async file operations.
>>  The limitation might be coming from linux posix api.
>
> I'm aware of them but neither are really usable.
>
> Windows AIO only works with files opened in direct I/O mode, meaning
> you bypass the disk cache.  When a file system doesn't support AIO, it
> either raises an error (in which case you have to fall back to
> user-space threads) or silently (!) switches to synchronous I/O.
>
> OS X AIO is implemented with kernel threads but the default settings
> are way too low to do anything useful, you have to tweak a bunch of
> sysctls first.  FreeBSD has similar issues (the implementations are
> very similar) and you need to manually load a kernel module first,
> otherwise everything fails with ENOSYS.
>
> Native Linux AIO has the same issues as Windows.  glibc's POSIX AIO
> implementation doesn't even bother with it, it always uses user-space
> threads.
>
> The only operating system I know of that has a remotely usable
> implementation is Solaris and who uses that?
>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines: 
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en

-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Why does htop show mutiple threads for node.js ?

[Alex Kocharin]

Hi Ryan,

1) The talk is about AIO, not about OS (and yes, it is broken anywhere except 
Solaris according to prev. discussion, didn't check though)
2) The talk is about performance (which means things will still work, but a bit 
slower)
3) The talk is about production servers where bits of performance do matter (do 
66 million people even exist in this industry?)

-- 
Regards,
Alex

05.12.2012, 14:57, "Ryan Schmidt" :
> On Dec 5, 2012, at 04:11, Ben Noordhuis  wrote:
>
>>  OS X is not worth considering even if it wasn't broken.  No one runs
>>  his production systems on OS X.
>
> Certainly many users use node on OS X on their development systems, and Apple 
> does sell capable servers and a server OS, so why shouldn't I use node on OS 
> X in production? Calling 66 million users' choice of OS "broken" doesn't seem 
> constructive, and given the lengths that this community has recently gone to 
> to be inclusive of and add support for Windows, I'm surprised at this 
> dismissive attitude with regard to such a popular UNIX OS.
>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines: 
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en

-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] preferred license for node modules?

[Alex Kocharin]

 Chad, you can use LGPL then, it's not very infectious. David, you can use any open opensource license you want. If your package is simple enough, it's just easier to use BSD. If your package is a large framework and it takes a lot of time to do, maybe GPL or LGPL is better, but it's a matter of taste.-- // alex  18.12.2012, 16:32, "Chad Engler" :I prefer to release under MIT or MPL; GPL can infect other applications that use your module. -Chad From: nodejs@googlegroups.com [mailto:nodejs@googlegroups.com] On Behalf Of David HerronSent: Friday, December 14, 2012 10:29 PMTo: nodejs@googlegroups.comSubject: [nodejs] preferred license for node modules? I'm curious about the preferred license for modules that are distributed through the npmjs.org repository In particular is there any legal barrier to using GPL in such modules? As far as I understand it, the legal barrier would be whether a module which uses a GPL'd module is derivative of that module.  I don't think that it would be, but then the LGPL license does exist for a reason.   + David Herron - nodejs.davidherron.com -- Job Board: http://jobs.nodejs.org/Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-GuidelinesYou received this message because you are subscribed to the GoogleGroups "nodejs" group.To post to this group, send email to nodejs@googlegroups.comTo unsubscribe from this group, send email tonodejs+unsubscr...@googlegroups.comFor more options, visit this group athttp://groups.google.com/group/nodejs?hl=en?hl=en --  Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en



-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[nodejs] comments in package.json

[Alex Kocharin]

Hello, everybody.


TL;DR: I think that JSON is not a suitable config file format, and I want npm 
to be able to read configs stored in some other way by default. It might be 
just javascript, or yaml, I don't really care as long as it better for 
configuration files than json.


So, there is a dependency list in package.json, and it would be a good practice 
to have a comment for every line describing why we require that package, why we 
require that version of that package, what known problems we have and so on.

But there's a small issue. JSON format doesn't allow comments in any way.

Right now there are a couple of different ways around it of course:

1. Non-standard JSON entries like "@comment": "blablabla". Unfortunately, 
javascript editors doesn't highlight it as a comment, and it's just plain ugly. 
Also this violates strict javascript mode, so God knows what trouble it'll 
cause in the future.
2. Keep a commented dependency list in a separate file. This violates DRY 
principle, so we could update one file and forget to update another. The same 
goes for /**package **/ hack I believe.
3. Use some kind of build system. Just for damn comments in one file?

Also, there's another wrong thing with JSON, it's too strict. You can't omit 
double quotes from keys, you can't leave a trailing comma, etc. JSON is 
human-readable, but it's just not damn human-writable.

Well... I went for 3rd option for a very long time. We used package.js file and 
a Makefile that compile js to json. Yes, that's three damn files instead of 
one. That's an example of our package.js file. https://gist.github.com/4462764 
. But a number of supported packages grew, and compiling this slowly became a 
major pain in the ass. I recently got an issue when I updated package.js, but 
forgot to compile it, and debugging this one was a quite interesting 
experience. So, I'm now in a mood of forking things and making all my public 
packages incompatible with mainstream npm...


So, there's a couple of alternatives. For example, Travis use YAML, and there 
is CSON (it's coffeescript version with blackjack and hookers).

And I think there was a couple of discussions about it. So, did anybody come up 
with more or less sane idea how to deal with this? What happened to 
package.json.js?


Happy New Year!

-- 
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

Re: [nodejs] comments in package.json

[Alex Kocharin]

Hi Ilya, What all comments in source code are used for? We can just strip *.js out of comments and place well commented *.js.txt file nearby. Why don't anybody do that? :) -- Regards,Alex  06.01.2013, 00:35, "Ilya Dmitrichenko" :Why cannot you add a section on dependencies in the README file? There you can explain in plain-english whatever you wanna say about those dependencies! Cheers,-- Ilya On 5 January 2013 18:22, Alex Kocharin <a...@kocharin.ru> wrote:Hello, everybody.   TL;DR: I think that JSON is not a suitable config file format, and I want npm to be able to read configs stored in some other way by default. It might be just _javascript_, or yaml, I don't really care as long as it better for configuration files than json.   So, there is a dependency list in package.json, and it would be a good practice to have a comment for every line describing why we require that package, why we require that version of that package, what known problems we have and so on.  But there's a small issue. JSON format doesn't allow comments in any way.  Right now there are a couple of different ways around it of course:  1. Non-standard JSON entries like "@comment": "blablabla". Unfortunately, _javascript_ editors doesn't highlight it as a comment, and it's just plain ugly. Also this violates strict _javascript_ mode, so God knows what trouble it'll cause in the future. 2. Keep a commented dependency list in a separate file. This violates DRY principle, so we could update one file and forget to update another. The same goes for /**package **/ hack I believe. 3. Use some kind of build system. Just for damn comments in one file?  Also, there's another wrong thing with JSON, it's too strict. You can't omit double quotes from keys, you can't leave a trailing comma, etc. JSON is human-readable, but it's just not damn human-writable.  Well... I went for 3rd option for a very long time. We used package.js file and a Makefile that compile js to json. Yes, that's three damn files instead of one. That's an example of our package.js file. https://gist.github.com/4462764 . But a number of supported packages grew, and compiling this slowly became a major pain in the ass. I recently got an issue when I updated package.js, but forgot to compile it, and debugging this one was a quite interesting experience. So, I'm now in a mood of forking things and making all my public packages incompatible with mainstream npm...   So, there's a couple of alternatives. For example, Travis use YAML, and there is CSON (it's coffeescript version with blackjack and hookers).  And I think there was a couple of discussions about it. So, did anybody come up with more or less sane idea how to deal with this? What happened to package.json.js?   Happy New Year!  -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en  --  Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en



-- 
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

Re: [nodejs] comments in package.json

[Alex Kocharin]

Hi Dick,  I explained that in an initial message. Well... it won't hurt to repeat though. 1. This is not highlighted by editors properly2. This is too long, dozen characters instead of two or three3. No multiline comments4. Isn't allowed by strict _javascript_ (so, we might expect some trouble in the far future)5. Looks ugly -- Regards,Alex  06.01.2013, 02:21, "Dick Hardt" :Or you could add a comment property to the JSON , comment: "Here is a comment" npm will ignore it, or may use it in the future for showing comments in some wayOn Jan 5, 2013, at 1:54 PM, Eric Mill <konkl...@gmail.com> wrote:It can often be a good idea to add comments for yourself and others around your dependencies, especially on a large project. It doesn't mean you made bad choices about your dependencies. When stuff gets large, it helps to group things, label them, etc. As package.json's get used for more and more things (for example, my deploys to my app host involve setting custom fields in package.json that they use to govern DNS and stuff), it'll become handier to have the ability to comment things.  Also, to comment things in and out at will, during development. We all do that with things. Plus, yes, being able to drop the quotes around keys is nice too.  This is why when I make config files for myself, I make them .js files instead of .json. Preface the object with a "module.exports = ", and you can say "var config = require("./config")" very easily. It's a lot more convenient. -- EricOn Sat, Jan 5, 2013 at 3:44 PM, Rick Waldron <waldron.r...@gmail.com> wrote:I'd be more concerned with having configuration options that were obtuse enough to require in-line comments.   RickOn Sat, Jan 5, 2013 at 3:35 PM, Ilya Dmitrichenko <errordevelo...@gmail.com> wrote:Why cannot you add a section on dependencies in the README file? There you can explain in plain-english whatever you wanna say about those dependencies! Cheers,-- Ilya On 5 January 2013 18:22, Alex Kocharin <a...@kocharin.ru> wrote:Hello, everybody.   TL;DR: I think that JSON is not a suitable config file format, and I want npm to be able to read configs stored in some other way by default. It might be just _javascript_, or yaml, I don't really care as long as it better for configuration files than json.   So, there is a dependency list in package.json, and it would be a good practice to have a comment for every line describing why we require that package, why we require that version of that package, what known problems we have and so on.  But there's a small issue. JSON format doesn't allow comments in any way.  Right now there are a couple of different ways around it of course:  1. Non-standard JSON entries like "@comment": "blablabla". Unfortunately, _javascript_ editors doesn't highlight it as a comment, and it's just plain ugly. Also this violates strict _javascript_ mode, so God knows what trouble it'll cause in the future. 2. Keep a commented dependency list in a separate file. This violates DRY principle, so we could update one file and forget to update another. The same goes for /**package **/ hack I believe. 3. Use some kind of build system. Just for damn comments in one file?  Also, there's another wrong thing with JSON, it's too strict. You can't omit double quotes from keys, you can't leave a trailing comma, etc. JSON is human-readable, but it's just not damn human-writable.  Well... I went for 3rd option for a very long time. We used package.js file and a Makefile that compile js to json. Yes, that's three damn files instead of one. That's an example of our package.js file. https://gist.github.com/4462764 . But a number of supported packages grew, and compiling this slowly became a major pain in the ass. I recently got an issue when I updated package.js, but forgot to compile it, and debugging this one was a quite interesting experience. So, I'm now in a mood of forking things and making all my public packages incompatible with mainstream npm...   So, there's a couple of alternatives. For example, Travis use YAML, and there is CSON (it's coffeescript version with blackjack and hookers).  And I think there was a couple of discussions about it. So, did anybody come up with more or less sane idea how to deal with this? What happened to package.json.js?   Happy New Year!  -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en  --  Job Board: http://jobs.nodejs.org/ Po

[nodejs] Re: comments in package.json

[Alex Kocharin]

 Hi Trevor,  I'm talking about package configuration, not build configuration. gyp has absolutely nothing to do with it.  -- // alex  06.01.2013, 10:27, "Trevor Norris" :On Saturday, January 5, 2013 10:22:06 AM UTC-8, Alex Kocharin wrote:Hello, everybody.   TL;DR: I think that JSON is not a suitable config file format, and I want npm to be able to read configs stored in some other way by default. It might be just _javascript_, or yaml, I don't really care as long as it better for configuration files than json.   Whether you think this or not, this has nothing directly to do with node. npm uses gyp, which is used by Google to build v8. And because node is built on top of v8, it makes sense node would use the same build mechanism. Also there is a standing rule that no changes will be made to external dependencies specifically for node. So if you wish to suggest that gyp accept another file format along with JSON I'd suggest posting it on the gyp mailing list (https://groups.google.com/group/gyp-developer).



-- 
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

Re: [nodejs] Re: comments in package.json

[Alex Kocharin]

 I did some googling before I asked this question here, so I saw this quote already. npm doesn't do any minification, it simply does JSON.parse there, so I can't use this suggestion anyway. For my own config files I use _javascript_ right now, and eval'ing it using vm.runInNewContext(), which I bet is much faster that jsmin. So, his suggestion is completely useless. -- // alex  08.01.2013, 18:16, "jmar777" :Just found a relevant quote from Crockford on the subject: I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't.  Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser. Source: https://plus.google.com/118095276221607585885/posts/RK8qyGVaGSrI don't agree with his reasoning there at all, but there you have it.On Saturday, January 5, 2013 1:22:06 PM UTC-5, Alex Kocharin wrote:Hello, everybody.   TL;DR: I think that JSON is not a suitable config file format, and I want npm to be able to read configs stored in some other way by default. It might be just _javascript_, or yaml, I don't really care as long as it better for configuration files than json.   So, there is a dependency list in package.json, and it would be a good practice to have a comment for every line describing why we require that package, why we require that version of that package, what known problems we have and so on.  But there's a small issue. JSON format doesn't allow comments in any way.  Right now there are a couple of different ways around it of course:  1. Non-standard JSON entries like "@comment": "blablabla". Unfortunately, _javascript_ editors doesn't highlight it as a comment, and it's just plain ugly. Also this violates strict _javascript_ mode, so God knows what trouble it'll cause in the future. 2. Keep a commented dependency list in a separate file. This violates DRY principle, so we could update one file and forget to update another. The same goes for /**package **/ hack I believe. 3. Use some kind of build system. Just for damn comments in one file?  Also, there's another wrong thing with JSON, it's too strict. You can't omit double quotes from keys, you can't leave a trailing comma, etc. JSON is human-readable, but it's just not damn human-writable.  Well... I went for 3rd option for a very long time. We used package.js file and a Makefile that compile js to json. Yes, that's three damn files instead of one. That's an example of our package.js file. https://gist.github.com/4462764 . But a number of supported packages grew, and compiling this slowly became a major pain in the ass. I recently got an issue when I updated package.js, but forgot to compile it, and debugging this one was a quite interesting experience. So, I'm now in a mood of forking things and making all my public packages incompatible with mainstream npm...   So, there's a couple of alternatives. For example, Travis use YAML, and there is CSON (it's coffeescript version with blackjack and hookers).  And I think there was a couple of discussions about it. So, did anybody come up with more or less sane idea how to deal with this? What happened to package.json.js?   Happy New Year!  --  Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en



-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] http/ https server on same port

[Alex Kocharin]

 In order to do that you can create a tcp server (net module) and listen for any requests on a port. If it is plaintext request it's http, otherwise it's https. Simple enough. You can even put ssh server on the same port if you aren't so scary of a witchcraft :) So, the general idea is to create three servers, http, https and net. Net server would receive all connections and proxy them to others. I've done that using three different ports (1 external, 2 internal), but I'm quite sure you can simulate connection to a http(s) server internally without binding it to a port. Maybe it's "request" event I don't know, you can look in node.js source code how it can be done. --// alex  06.02.2013, 23:05, "V'Raj Kanwade" :I am building a proxy server which needs to listen for both http and https proxy on same port. http.createServer does not call response handler for https traffic. So I created the server using net.createServer. The question I have is, how can I leverage the http functionality once I have the input request? For eg. when I see the start of request is GET http://nodejs.org/ HTTP/1.1, I want to convert it into a http request so that the headers etc are parsed accordingly and if the request starts with CONNECT, I can implement my own tunneling? --  --  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: V8 team will start working on generators

[Alex Kocharin]

 He was probably talking about node-fibers -- // alex  30.03.2013, 10:50, "Mark Hahn" :> node has had generators since early 2011 Reference please?On Fri, Mar 29, 2013 at 9:22 PM, Marcel Laverdet  wrote:?_? node has had generators since early 2011. ;) ;) ;)On Fri, Mar 29, 2013 at 9:53 PM, Bruno Jouhier  wrote:Good news!For us the migration be a one line code change! Will be interesting to compare the performance between generators and callbacks. BrunoOn Thursday, March 28, 2013 8:17:30 PM UTC+1, cpprototypes wrote:Source: http://code.google.com/p/v8/issues/detail?id=2355I think generators have the potential to greatly change how node.js code is written (for example it could look like this http://taskjs.org).  However, it depends on many factors: 1) How easy will it be to migrate existing node.js code?  It seems that most of the community has decided that a simple async library (https://github.com/caolan/async) is good enough instead of promises.  So it may be difficult to migrate that to something like tasks.js or anything else using generators. 2) Since node.js developers are used to chaining callbacks and using async library, there may be a lot of inertia to overcome before generators can have much impact.3) What kind of impact, if any, will generators have on the core node.js API?    --  --  Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en   ---  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.     --  --  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] What Editor / OS / Dev enviroment do you use?

[Alex Kocharin]

vim / linux debian

-- 
// alex

21.09.2012, 21:10, "P. Douglas Reeder" :
> I develop under OS X (Snow Leopard), using Eclipse and the command line.  The 
> OS X command line environment is close enough to the Linux command line 
> environment on the machines I deploy to.
>
> Eclipse is OK, but IntelliJ (which I use in my other job) is better.
>
> I use Miller's JavaScript Lint instead of Crockford's JSLint, because it 
> catches more real problems and can be configured to ignore non-problems.
>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines: 
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en

-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Re: npm search

[Alex Kocharin]

Adam, Yeah, I liked old search.npmjs.org site, but moving to google search was a mistake imho. :( I'm using http://toolbox.no.de/ for that now.-- // alex  26.09.2012, 02:34, "Adam Crabtree" :Niice.NPM search feels broken IMHO. Google search UI is awful in this case, esp. since most searches are looking for modules, not people, keywords, or "packages depending on", etc... and then typically my first course of action is not to read the Readme on npmjs.org, but to find the github repo and read it there where I can browse through the code easier.Cheers,Adam CrabtreeOn Sun, Sep 23, 2012 at 6:18 AM, samm  wrote:Actually I just found you can go here:http://eirikb.github.com/nipster/ and type in, for example, irc, and then click the npm icon at the right of the result line.It will take you back to npm site with the npm install command for that module.On Sunday, September 23, 2012 8:59:39 AM UTC-4, samm wrote:I don't understand how to use this.I type in, for example, irc. But there is no search or go button anywhere.If I press enter it goes to a google search results page.I guess I have to use the command line to search.Why bother having the web page version then? --  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-- Better a little with righteousness        than much gain with injustice.Proverbs 16:8 --  Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en



-- 
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

Re: [nodejs] npm search

[Alex Kocharin]

Jose, Are you sure you aren't violating Google's terms of service there? -- // alex  26.09.2012, 03:09, "José F. Romaniello" :+1 It feels broken, but it will feel better if instead of redirecting to google it embeds the result in the npm page... Like my  static blog does:http://joseoncode.com/search/?q=NodeCode  https://github.com/jfromaniello/joseoncodecom/blob/master/search.html El martes, 25 de septiembre de 2012, Adam Crabtree escribió:Niice.NPM search feels broken IMHO. Google search UI is awful in this case, esp. since most searches are looking for modules, not people, keywords, or "packages depending on", etc... and then typically my first course of action is not to read the Readme on npmjs.org, but to find the github repo and read it there where I can browse through the code easier.Cheers,Adam CrabtreeOn Sun, Sep 23, 2012 at 6:18 AM, samm  wrote:Actually I just found you can go here:http://eirikb.github.com/nipster/ and type in, for example, irc, and then click the npm icon at the right of the result line.It will take you back to npm site with the npm install command for that module.On Sunday, September 23, 2012 8:59:39 AM UTC-4, samm wrote:I don't understand how to use this.I type in, for example, irc. But there is no search or go button anywhere.If I press enter it goes to a google search results page.I guess I have to use the command line to search.Why bother having the web page version then? --  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-- Better a little with righteousness        than much gain with injustice.Proverbs 16:8 --  Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --  Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en



-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] "node_modules" for private modules that need to be committed?

[Alex Kocharin]

Tom, If you want it to be managed by npm, use git+ssh:// scheme, that works. But there are several issues with that. For example, if you use npm update, it will try to update your private package from repository. And if there's a package with the same name, you will have trouble. Another way is to put these packages to another folder, say my_modules and invoke node.js with node_path env like that:NODE_PATH=my_modules node server.jsThis way you can safely separate private modules from the public ones.-- // alex  10.10.2012, 19:09, "Tom" :I've added the node_modules folder to my .gitignore file, which works fine thanks to NPM Shrinkwrap (after deploying I need to run npm install using the shrinkwrap.json file).However, I've got some private modules now that I won't publish to NPM. I would like to require these modules like the other modules in node_modules.Unfortunately I cannot put these modules in node_modules, because they'd be ignored by git, messing with my future deployment.Where should I place these modules instead? I've been told that editing the paths variable for node's module lookup is highly unrecommended.Note that these are small undocumented nonpublic modules, which is why I don't want to publish them to NPM.Tom --  Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en



-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] multiple applications in single node.js process

[Alex Kocharin]

Hello Alexey, 2 and 3 is quite doable using domains, and 1st could be achievable with v8 debugger. It's a hack, but nevertheless it's possible, if all your processes follow some rules and don't mess with each other. But I'm afraid that an infinite loop in a service will screw the whole process anyway.-- // alex  13.10.2012, 13:29, "Alexey Guskov" :Hello everybody. I'm a huge fan of node.js and ve're actively using it in our project for creating various services.Recently we've faced a problem of significant ram overhead required to run each node.js instance (about 40Mb). This is an issue since we are running a number of different node.js services on one machine, and the memory is limited.So what we trying to use is run multiple services in single node.js process using vm.runInNewContext(), but compared this approach is missing some functionality:1) We cannot monitor amount of memory allocated by each subprocess.2) We cannot cancel all setTimeouts and process.nextTicks for given process to effectively stop its execution.3) We cannot get a list of open sockets and file descriptors for given process.With this functionality we could use node.js similar to erlang - run a number of processes inside a single vm - and use some erlang features (like 'let it fail') that would certanly lead us to world domination ;)So, is there any projects targeted to solve similar problem? --  Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en



-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Stop readline Writing Input to the Output

[Alex Kocharin]

Replace process.stdout with a custom stream?-- // alex  14.10.2012, 22:44, "Volkan Yazıcı" :How can I make readline stop writing the read input to the output? That is, when I dolines = [];var rl = readline.createInterface(process.stdin, process.stdout);rl.resume()rl.on("line", function (line) {    lines.push(line);});read lines get written to the output as well. I would like to shut that behaviour down. Any ideas?  --  Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en



-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] node dev on windows

[Alex Kocharin]

Hi Jerome, If you are going to use native node.js libraries, you'll almost certainly get yourself a nice time figuring out how to compile it. If you are going to use just _javascript_ libraries, you have a chance that everything will work out of the box, but I wouldn't count on it. Windows isn't POSIX-compatible, and that's one big pitfall. For example, just imagine what would it take on windows to get processor or memory information. It's just fs.readFile('/proc/cpuinfo') on unixes, but what about windows? Yeah, that's about it. But it's certainly possible to run linux in a virtual box or remote computer and share disk between them, so you can run an editor on windows pc, but compile and test your app in linux.-- // alex  19.10.2012, 18:22, "Jerome Covington" :Hi All,For various reasons, I may be switching to a Windows PC at home, but would like to continue playing with Node.I've been on a Mac for years. Am I likely to encounter any pitfalls or gotchas doing node dev on Windows?A buddy of mine reminded me that some of the add ons require a C compiler. What are my options?-- Regards,JeromeMusic || Web Dev --  Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en



-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Use of Node / Express / MongoDB for a e-commerce website?

[Alex Kocharin]

 Wrong.  I believe here http://www.mongodb.org/display/DOCS/Schema+Design#SchemaDesign-Videos are videos with some talking related to e-commerce. And mongodb does this job quite nicely.-- // alex  22.10.2012, 14:04, "Adam Reynolds" :You use an ACID compliant DB for e-commerce. This excludes Mongo. On Mon, Oct 22, 2012 at 10:50 AM, Hakan Guzelgoz  wrote:Hi there,I am planning to use ExpressJS & MongoDB for a e-commerce website for something that would have similar functionalities like groupon. Clients would simply view the various pages and be able to purchase or book some of the offers - and pay online.I was wondering if any of you had experience with Express & MongoDB for such an "easy" e-commerce website. What kind of problems / solutions would you see or suggest?Many thanks,Hakan --  Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en  --  Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en



-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[nodejs] npm: version locking in modules

[Alex Kocharin]

Hi all,

Some node.js modules depend on strict versions of another modules like that:
"dependencies":{"mongodb":"0.9.9-3"} // mongode

or that:
"engines": { "node": "~0.6" } // express did it some time ago

Now suppose I want to always use newer versions of any modules and don't care 
much about what maintainers thinks about it. What should I do?

Is there any option for npm to lose respect for upper bounds of version range, 
but still respect lower bounds? Or any configuration like "whenever you see 
module@X, always install module@Y"?

-- 
// alex

-- 
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

Re: [nodejs] NodeJS Chat framework

[Alex Kocharin]

 socket.io ?-- // alex  23.10.2012, 16:09, "Vivekanandan M" :Hi,I'm searching for a good chat framework built over nodejs, let me suggest if you have any idea.Vivek --  Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en



-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Re: npm: version locking in modules

[Alex Kocharin]

 It's because I strongly believe that, if you have enough time for testing, it's far better to always use latest versions of every software. If you have a good knowledge of the software you use, and good integration tests, and a testing team, it's nothing wrong with usage of, say, node 0.9.x on production, right? I assume that newer versions of a software is generally better, if you have a time to test everything and track all API changes.-- // alex  23.10.2012, 11:06, "greelgorke" :only option is to install all dependencies, then remove all sub-dependencies and reinstall then manually also.but why do you that that anyway?  Am Dienstag, 23. Oktober 2012 01:22:47 UTC+2 schrieb Alex Kocharin:Hi all,  Some node.js modules depend on strict versions of another modules like that: "dependencies":{"mongodb":"0.9.9-3"} // mongode  or that: "engines": { "node": "~0.6" } // express did it some time ago  Now suppose I want to always use newer versions of any modules and don't care much about what maintainers thinks about it. What should I do?  Is there any option for npm to lose respect for upper bounds of version range, but still respect lower bounds? Or any configuration like "whenever you see module@X, always install module@Y"?  -- // alex  --  Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en



-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Is NodeJS SP800-131A compliant?

[Alex Kocharin]

 Node.js does not do anything to be complaint with this. It uses openssl library to handle cryptographic tasks, so if openssl supports it, node.js supports it. Therefore all questions like this should be asked to openssl-related mailing lists. I can say that node.js/openssl supports the most secure open protocols in the world, so if your only concern is security, you'll be fine. If you're working for the government and really need to use some weird/unsecure protocols to pass audits, google for "openssl sp800-131a". -- // alex  29.04.2013, 16:46, "Vishwanath" :Hi,I couldn't find any discussion related to SP800-131A compliance. I would like to know if NodeJS does anything special to be complaint with this section?  (*National Institute of Standards and Technology, Special Publications 800-131A which is entitled "Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths")  thanks,Vishwanath  --  --  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] EMFILE error in Async file reading

[Alex Kocharin]

Raising ulimit smells like a bad solution, doesn't it?

I'd suggest to use https://github.com/isaacs/node-graceful-fs instead. Why 
isn't something like that included in the core by the way? Issue seems to be 
quite common.

... or write a wrapper to readFile to explicitly limit an amount of open 
files...

On the other hand, I might be missing a point here. Why is this limit of 1024 
opened files enforced by default in the first place?

-- 
// alex


29.04.2013, 18:38, "Ben Noordhuis" :
> On Mon, Apr 29, 2013 at 4:13 PM, Afshin Mehrabani  
> wrote:
>
>>  Today when I tried to implement an example of using async/sync I/O methods
>>  in NodeJs, I faced an strange problem. When I'm trying to send requests with
>>  ab, I get this error in Async method:
>>>  { [Error: EMFILE, open 'sample.txt'] errno: 20, code: 'EMFILE', path:
>>>  'sample.txt' }
>>  But the same functionality in Sync mode works well, without any errors.
>>
>>  This is my ab command for running the test: ab -n 1 -c 1000 -vhr
>>  http://localhost:8080/
>>
>>  Here is my both codes:
>>
>>  Async:
>>>  http.createServer(function (req, res) {
>>>    fs.readFile('sample.txt', function (err, data) {
>>>  if(err) {
>>>    res.writeHead(500, {'Content-Type': 'text/plain'});
>>>    res.end();
>>>    console.log(err);
>>>  } else {
>>>    res.writeHead(200, {'Content-Type': 'text/plain'});
>>>    res.end(data);
>>>  }
>>>    });
>>>  }).listen(8080, '127.0.0.1');
>>  Sync:
>>>  http.createServer(function (req, res) {
>>>    var fileOutput = fs.readFileSync('sample.txt').toString();
>>>    if(!fileOutput) {
>>>    res.writeHead(500, {'Content-Type': 'text/plain'});
>>>    res.end('Error in reading the file.');
>>>    } else {
>>>  res.writeHead(200, {'Content-Type': 'text/plain'});
>>>  res.end(fileOutput);
>>>    }
>>>  }).listen(8081, '127.0.0.1');
>>  What's the matter? Is there any problem in using Async methods?
>
> There is in the way you use them.
>
> The synchronous version is effectively serial, i.e. it processes
> requests one by one (IOW, there is only one file descriptor at any
> point in time that refers to sample.txt) and that's why you don't hit
> the open file descriptor limit.  It also means that fs.readFileSync()
> is now the single largest bottleneck in your application.
>
> The asynchronous version runs concurrently, meaning there are 1,000
> file descriptors - or however many simultaneous connections you're
> serving - referring to sample.txt.  Raise `ulimit -n` and the problem
> goes away (or cache the contents of sample.txt, of course.)
>
> --
> --
> 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.

[nodejs] Re: Module search path safety?

[Alex Kocharin]

If this server allows auto-creation of users with arbitrary names, someone 
could create user with "node_modules" name and cause trouble.

On the other hand, I used /home/node_modules folder to deliberately share 
the same modules between different users. No... I'd say it is more useful 
than risky.


// alex

On Saturday, April 27, 2013 4:27:21 PM UTC, Carlos wrote:
>
> From the docs:
>
> For example, if the file at '/home/ry/projects/foo.js' called 
> require('bar.js'), then node would look in the following locations, in 
> this order:
>
>- /home/ry/projects/node_modules/bar.js
>- /home/ry/node_modules/bar.js
>- /home/node_modules/bar.js  [color added by me]
>- /node_modules/bar.js
>
> Maybe I'm paranoid.  Ok, I am paranoid.  But is there a potential for 
> injection of untrusted code here?  I mean, it's really unlikely that I 
> would be running a node-based service on a machine I don't own-as-in-root. 
>  But suppose I have users, and one of them is using node to do whatever 
> just because node is the coolest thing ever.  Should she trust me not to 
> have put something evil in /home/node_modules?  I mean, I could be evil.  I 
> could dump the list of the top ten downloads from the npm registry and then 
> run those module names through a typo predictor (This is insanely easy to 
> automate, plus you have variations of foo, node-foo and foo-node which 
> create even more open space for evil.) and seed /home/node_modules with 
> compromised versions of the real thing.  The next time Karen Koder does an 
> 'npm install' on a new package file she might very well end up pulling 
> compromised code.  I'm not saying this is a big security risk.  It's not. 
>  If it were, I would not be posting here.  But I question whether this is 
> really good design practice and suggest that maybe pulling code from other 
> user directories is more risky than useful.
>
>

-- 
-- 
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: Best practices for token-based authentication in REST API

[Alex Kocharin]

Hmm... Resource Owner Password flow looks very much like session_id cookies 
in browser applications. Is it really the same thing named differently, or 
am I missing something here?


On Thursday, May 2, 2013 6:40:47 AM UTC, Domenic Denicola wrote:
>
> OAuth 2 is definitely what you're looking for. In particular it looks like 
> you want the Resource Owner Password 
> Credentialsflow.
>
> If by chance you are using Restify, I made a thing that will automatically 
> handle this for you: 
> Restify–OAuth2. 
> Even if you're not, take a look at the readme to understand the basic 
> RESTful flow of authentication, and at the code and example server to see 
> the basic idea implementations.
>
> On Wednesday, May 1, 2013 1:20:24 PM UTC-4, Alan Fay wrote:
>>
>> Hello!
>>
>> I'm trying to develop a REST API using node.js, to support an Android 
>> app.  I've been able to find several resources on the web, however, most of 
>> the examples I come across fall into two camps:
>> 1) Basic authentication over HTTPS
>> 2) OAuth
>>
>> I don't want to do basic authentication over HTTPS with a username and 
>> password, because in the Android app, I have it setup to store a username 
>> and token via the AccountManager (they seem to have taken down reference to 
>> the code on Android's site; my implementation is very similar the sample 
>> code that ships with the SDK: *
>> android-sdk-linux/samples/android-17/SampleSyncAdapter* except I'm not 
>> using any of the Sync features).
>>
>> I don't want to use OAuth because I am not sure we can count on users to 
>> have accounts with Google or some other third-party OAuth provider.
>>
>> This is my first round at implementing web authentication; from what I'm 
>> reading, the steps go something like this:
>> - [Service] Administrator creates an account with a username and a 
>> generated strong code is stored temporarily in the user record; emailed to 
>> user
>> - [App] User selects account and enters username and code, plus password 
>> of their choice, into the form
>> - [App] Basic authentication over HTTPS sends over username, code, and 
>> password (just this once)
>> - [Service] Stores random salt and password hash in the user record, and 
>> the generated token (a)
>> - [Service] Replies back to App with the token
>> - [App] Username and token is stored via AccountManager
>>
>> Then,
>> - [App] User sends username and token to service (b)
>> - [Service] *authenticates* the user if the token matches and is not 
>> expired (c)
>> - [App] User can access the various REST API calls (d)
>>
>> In this way, the password is never stored on the Android device or in the 
>> database.  When the token expires, then User re-enters password.  The User 
>> can request a password reset, which generates a strong code again and the 
>> process starts from the top.
>>
>> My questions (referenced above) are:
>> (a) Should the generated token be stored on the user record, or in a 
>> separate table?  My thinking for a separate table/collection would be to 
>> have a background process that could remove expired tokens; keeping this 
>> information separate from the user record; or perhaps a user could have a 
>> valid reason to have multiple different tokens (one on the phone, another 
>> on the tablet).
>> (b) Is this simply done through basic authentication over HTTPS, sending 
>> the username and token (in place of password)?
>> (c) I've seen examples of node.js code setting values on request.session; 
>> effectively, marking the session as authenticated.  Is this specific to 
>> browsers/cookies and/or does it work when communicating to Android?
>> (d) Kind of an extension of (c), does the username/token have to be sent 
>> every time, or can I reference something like the 
>> request.session.authorized value?
>>
>> Also:
>> - Does anyone know of a good working example of a node.js REST API 
>> implementation for an Android app?  Sometimes it's easier to just learn 
>> from code.
>> - Is there working example code of the node dependencies I see referenced 
>> everywhere (everyauth, connect-auth, passport) being used with an Android 
>> app?  Most seem to implement OAuth solutions.
>> - Any security/implementation pitfalls with this approach?
>>
>> References:
>> * [The Definitive Guide to Forms-based Website Authentication](
>> http://stackoverflow.com/a/477578/172217)
>> * [Designing a Secure REST (Web) API without OAuth](
>> http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/
>> )
>> * [How to Implement a Secure REST API with node.js](
>> http://stackoverflow.com/a/15500784/172217)
>> * [RESTful Authentication](http://stackoverflow.com/a/7158864/172217)
>> * [Securing my node.js App REST API](
>> http://stackoverflow.com/a/9126126/172217)
>> * [Connect Session Middleware](
>> http://www.senchalabs.org/connect/session.html)
>> * [Secure Salted Password Hashin

[nodejs] Re: Capturing a web page as an image on the server?

[Alex Kocharin]

I solved such task launching a separate X server and making a screenshot of 
a chromium running there. It's perfect in terms of accuracy, but might be 
just too heavy on resources.


On Sunday, May 5, 2013 2:59:10 AM UTC, Mark Hahn wrote:
>
> I need to make thumbnails that represent web pages given the urls.  I'd 
> prefer to do it in a node environment.  I wouldn't like to install lampp or 
> some other environment for this one purpose.
>
> I know jsdom and cheerio but that only gets me to the dom.  How do I 
> render that to an image?  Node already has V8 lying around but that doesn't 
> include webkit, right?
>
> Any ideas, no matter how wild, would be appreciated.
>
>

-- 
-- 
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] How to prepare a C10K demo

[Alex Kocharin]

 I'm not sure http library allows it, but you can always open 10k raw tcp sockets and write a request there at the same time... what do you need websocket for? -- // alex  05.05.2013, 13:25, "Afshin Mehrabani" :Actually I want to write a client to simulate this 10,000 concurrent clients. I saw this C10K demo in django: https://github.com/aaugustin/django-c10k-demo And I want to do something like that. Is that possible via websocket?On Sunday, May 5, 2013 12:16:28 PM UTC+4:30, Ben Noordhuis wrote:On Sun, May 5, 2013 at 6:54 AM, Afshin Mehrabani  wrote: > Hello all, > > I want to prepare a C10K demo in NodeJs but I don't have any idea how. Could > someone say how can I prepare a C10K demo in NodeJs HTTP Server (or maybe > with expressjs) > > Thanks, > Afshin  What do you want to demo besides 10K concurrent clients?  If you only want to demonstrate that node.js can handle that many connections, copy the example from the home page and hit it with `ab -k -c 1 -n  `.  --  --  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] preferred license for node modules?

[Alex Kocharin]

 You can use dual-licensing. Let people choose GPL or commercial license, so anyone who can't use infectious type will be forced to pay... -- // alex  07.05.2013, 16:51, "Saleem Abdul Hamid" :Is there a license that says most people can do whatever you want with my stuff but if Microsoft (example) uses it to make 100 million dollars, I want to negotiate for a piece of it? That's really the question everyone is asking, although they're too shy to say it, because wanting to make money off of your stuff is considered bad form in certain quarters. Personally, even if a huge company with a lot of money was using one of my projects as an integral part of a moneymaker, I'd be happy with a very, very fair (for them) royalty that they would probably not even consider significant. But if you use the MIT, the question of negotiating anything doesn't even come up. To be clear, I want a license that is not infectious at all. That lets people use, modify, redistribute, all that good stuff. But just leaves open the door that if someone gets really rich using my project, I can benefit from coming up with the idea and doing the work. Is there a license that represents this?On Friday, December 14, 2012 10:38:05 PM UTC-5, Forrest L Norvell wrote:On Fri, Dec 14, 2012 at 7:29 PM, David Herron  wrote:I'm curious about the preferred license for modules that are distributed through the npmjs.org repository We discussed this a bit at NodeConf summer camp this year, and the consensus was pretty strongly in favor of BSD or MIT licenses, or at least pretty liberal, commercial-use friendly licenses (including the Perl and Apache licenses). In particular is there any legal barrier to using GPL in such modules? As far as I understand it, the legal barrier would be whether a module which uses a GPL'd module is derivative of that module.  I don't think that it would be, but then the LGPL license does exist for a reason.   Isaac can speak to this more authoritatively than I can, but npm itself prescribes / proscribes no particular licenses. You could attach GPL3 licenses to your modules if you wanted, but uptake would probably be hampered, especially if there were some kind of associated Canonical-style contributor's agreement. Node is still pretty much the wild west, and it's tough to say if today's random hack project might not become tomorrow's startup idea, and I think most devs want to keep their options open. F --  --  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.
 
 

[nodejs] event loop load average?

[Alex Kocharin]

Hi everyone,

I'm looking for a way to check a responsiveness of node.js app, and find 
out if it tries to do more work that it should, and I need to scale up it 
somehow.

CPU time isn't it. If I see 100% cpu load, it might indicate that node.js 
is currently successfully serving thousands of requests, or it might 
indicate that someone put in extra semicolon in "while(1); {blablabla}" 
sentence, and there's no way to distinguish these.

On the other hand, a difference between time when some callback should fire 
and a time when it actually fires shows what's needed. If some callback 
executes a second after it should, we surely are in trouble. There is a lot 
of packages like 'toobusy' seem to do exactly that, they fire up a callback 
every second and measure a time when it fired. But it sounds like too rough 
or imprecise way.

When I was thinking about that, I remembered how load average in unix 
kernels is calculated. If there was such thing for node.js core, that would 
solve an issue. I mean, just like 'os kernel load average' shows amount of 
currently runnable processes, I'd like to see 'node.js event loop load 
average' that shows amount of currently runnable functions in node.js event 
loop. Is there such thing?

Anyway, what performance metrics does event loop expose? Maybe some libuv 
functions I can use to get that? Or maybe I can register a custom c++ 
function that gets executed in every tick in event loop?

--
alex

-- 
-- 
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] what are the merits / demerits of require.extensions?

[Alex Kocharin]

I agree with that. npm modules should be compiled to js. I even suggest 
them to be concatenated and minified for performance reasons, why don't 
anybody do that?

But it's NOT about published npm modules. It's about developing. When I 
develop my coffeescript libraries (see 
https://github.com/rlidwka/asset-pipeline for example), I put 
'module.exports = require("./src/index");' in index.js and using on-the-fly 
compilation. On production system I change it to require("./lib/index") to 
use compiled version.

So, how am I supposed to do this without require.extensions? Oh... well, 
you're right, it'll probably be 
require("good-old-require")("./src/blablabla.coffee") with a help of a 
library that would reimplement all filesystem searching/reading stuff by 
itself all over again. 

How will require("something.json") be dealt with anyway?


On Friday, May 10, 2013 2:02:19 PM UTC, Eldar wrote:
>
> No one argues about modules for npm. What about apps? What about 
> components private for organization?
>
> There is never any need for additional filetype extensions. Node runs 
>> JavaScript. Ultimately, you have to compile it to JS before it runs *
>> anyway*, so you may as well do that up front, rather than adding a 
>> global hook for it.
>
>
> Ok, Then we'd like to see setups as simple as `mocha --requrie FooLang` 
> for running tests and `node ./support/foo script.foo` for everything else. 
>
> On Friday, May 10, 2013 5:16:18 PM UTC+4, Ben Noordhuis wrote:
>>
>> On Thu, May 9, 2013 at 5:29 PM, ~flow  wrote: 
>> > i recently opened an issue https://github.com/joyent/node/issues/5430 
>> > concerning require.extensions, and got told that 
>> > 
>> > "People should not be using require.extensions. It's officially 
>> deprecated", 
>> > "Compile your code to JavaScript prior to running it." "There is never 
>> any 
>> > need for additional filetype extensions. Node runs JavaScript"; "we're 
>> not 
>> > bothered with tens of other dialects that require compilation and are 
>> > written in code that's not readable for JavaScript programmer"; "stop 
>> > relying on this horrible feature" 
>> > 
>> > in no unclear words. i was a little shocked, since my perception has 
>> always 
>> > been that require.extensions was the strike of a genius. with little 
>> effort, 
>> > you can hook in filetypes and make it so that they are require'd 
>> > transparently, no matter whether they represent data / programs as 
>> > javascript, json, coffeescript, whatever. 
>> > 
>> > ok it's a global hook which, in theory might lead to problems (but in 
>> years 
>> > of writing coffeescript hasn't been a problem even once. 
>> > 
>> > i love the fact that i do not have to compile everything in advance / 
>> add a 
>> > buildscript / are forced to keep a coffeescript watch process in the 
>> > background. coming from python, i was also very happy to see that those 
>> > pernacious *.pyc files that used to litter my directories were now a 
>> thing 
>> > of the past—i mean, that is code duplication enforced by the system, 
>> utterly 
>> > avoidable. 
>> > 
>> > to me, javascript is a wonderful language with some rough edges and a 
>> > horribly cluttered syntax. now here comes nodejs and all those 
>> wonderful 
>> > home-grown programming languages that take advantage of the great 
>> compiling 
>> > target that javascript running on nodejs is. dumbing down `require` 
>> will be 
>> > sad news for all the many people that are using those new languages 
>> daily. 
>> > 
>> > as a user of coffeescript, the fact that coffeescript compiles to 
>> javascript 
>> > is a fact that i have to be aware of, but it is not something that i 
>> want to 
>> > be (or need be) constantly reminded of. doing on-the-fly, transparent 
>> > compilation is the way to go; it has never been any appreciable drain 
>> on 
>> > resources, either. it sure will continue doing things that way. 
>> > 
>> > if they kill require.extensions with no sensible replacement, things 
>> will 
>> > just get more difficult. it won't be too difficult to come up with a 
>> > sensible replacement—one could even predict that sooner or later, there 
>> will 
>> > be modules in npm that will allow you to `require 'old-require'` to 
>> replace 
>> > the new require with the good ole'. gone a bit of efficiency, gone a 
>> bit of 
>> > standardization. 
>> > 
>> > so what are the good, the bad and the ugly facts about 
>> require.extensions? 
>>
>> You're essentially saying that deprecating require.extensions makes 
>> your life as a module author harder, right?  That's the wrong way to 
>> look at it: it makes life for _users_ of your module easier. 
>>
>> The quintessential example is where someone has a project that depends 
>> on two modules, both written in FooScript(TM), but with module A 
>> depending on fooscript@1.0.0 and module B depending on 
>> foos...@2.0.0. 
>>
>> require.extensions is global; if FooScript 1 and 2 are incompatible, 
>> then your user is between a rock

Re: [nodejs] what are the merits / demerits of require.extensions?

[Alex Kocharin]

 How do you do that? Do you use some kind of C++ native module for this? Because from I've seen so far, most "encrypted" _javascript_s can be "decrypted" by replacing eval with console.log... -- // alex  11.05.2013, 14:30, "Bruno Jouhier" :I'm not going to repeat the reasons why require.extensions is bad,  just that I fully support Isaac's move of deprecating it. What about people who need to encrypt source code. What do you propose?  --  --  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] what are the merits / demerits of require.extensions?

[Alex Kocharin]

Can you post a hello-worldish example of such working encrypted module? I'm 
just curious how it is possible to use such module without source code 
appearing somewhere.


On Saturday, May 11, 2013 10:53:20 AM UTC, Bruno Jouhier wrote:
>
> Yes, we do it with a C++ module. And fn.toString() won't give you the 
> source of exported functions.
>
> On Saturday, May 11, 2013 12:43:17 PM UTC+2, Alex Kocharin wrote:
>>
>>  
>> How do you do that? Do you use some kind of C++ native module for this? 
>> Because from I've seen so far, most "encrypted" javascripts can be 
>> "decrypted" by replacing eval with console.log...
>>  
>> -- 
>> // alex
>>  
>>  
>> 11.05.2013, 14:30, "Bruno Jouhier" :
>>
>> I'm not going to repeat the reasons why require.extensions is bad,  
>> just that I fully support Isaac's move of deprecating it. 
>>
>>
>> What about people who need to encrypt source code. What do you propose?
>>  
>>
>>  
>> -- 
>> -- 
>> 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.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=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+un...@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] NPK - Node.js packaging Utility

[Alex Kocharin]

 Well, if NPK will be able to join all dependencies in one _javascript_ file, it will already be a big deal. On my system "npm" executable file takes 1.153s to load from disk and 0.153s to load from cache. All binary executables like "gpg" or "dpkg" take 0.004s to load. It's really annoying sometimes... -- // alex  11.05.2013, 10:03, "Fred Chien" :Hi All, I am glade to introduce NPK, which is a packaging utlity for Node.js. :-) NPK aims to package project which is based on Node.js, and bundle all _javascript_ files to make all in one file, even protect source code. Here is repository at Github: https://github.com/cfsghost/npk You also can install it directly via npm: npm install npk -g BTW, We are now trying to support a feature that precompile _javascript_ files to be binary to speed up loading time of program of Node.js. Cheers,Fred --  --  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.
 
 

[nodejs] EMFILE issues

[Alex Kocharin]

Hi everyone,

I wonder if it would make sense to recommend everyone to set "ulimit -n" to 
unlimited when using node... I seem to run into issues with it every now 
and then.

Anyway, it seems that node.js core itself has serious trouble with it. I 
used "ab -n 1 -c 5000" to bombard a simple http server with thousands 
of requests, and after that node.js starts to eat up 100% CPU and never 
returns control to javascript. HTTP port remains open, but connection is 
closed as soon as anybody connects to it.

Can you recheck it? Maybe I have some silly settings on my computer that 
cause this.

Tested several versions. 0.8.23 fails with EMFILE (this is to be expected), 
0.8.7 and 0.9.1 handles anything successfully (surprising, but ok), but all 
versions starting I believe from 0.9.2 including current version have this 
issue.

I wonder if it's a security issue, and everybody can freeze node.js server 
by just opening 2k connections to it.


I'm using this for testing:
```
setInterval(function() {
   console.log('I\'m alive, ', Date.now());
}, 1000);

require('http').createServer(function(req, res) {
   res.end('xxx');
}).listen(12345);
```

In another console (under root because ordinary user can't up ulimit by 
himself):
# ulimit -n 1

# ab -n 1 -c 5000 http://127.0.0.1:12345/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
apr_socket_recv: Connection reset by peer (104)
Total of 59 requests completed

# ps aux | grep node
alex  4582 91.7  0.2 592480 11192 pts/11   Rl+  12:58   0:31 node 
/tmp/test.js
root  4596  0.0  0.0   8976   876 pts/4S+   12:59   0:00 grep node

# time telnet 127.0.0.1 12345
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Connection closed by foreign host.

real0m0.004s
user0m0.004s
sys 0m0.000s

-- 
-- 
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] NPK - Node.js packaging Utility

[Alex Kocharin]

 If we are talking about non-compatible solutions, I might as well use python instead ;) -- // alex  14.05.2013, 01:04, "Tim Caswell" :Alex, I share your pain.  That is why I made a version/port of node that didn't use V8, but rather, the much lighter-weight luajit engine.  It's at luvit.io. (warning, not compatible with node.js code or ecosystem, just the same idea / API style)On Sun, May 12, 2013 at 6:21 AM, Alex Kocharin <a...@kocharin.ru> wrote: Well, if NPK will be able to join all dependencies in one _javascript_ file, it will already be a big deal. On my system "npm" executable file takes 1.153s to load from disk and 0.153s to load from cache. All binary executables like "gpg" or "dpkg" take 0.004s to load. It's really annoying sometimes... -- // alex  11.05.2013, 10:03, "Fred Chien" <cfsgh...@gmail.com>:Hi All, I am glade to introduce NPK, which is a packaging utlity for Node.js. :-) NPK aims to package project which is based on Node.js, and bundle all _javascript_ files to make all in one file, even protect source code. Here is repository at Github: https://github.com/cfsghost/npk You also can install it directly via npm: npm install npk -g BTW, We are now trying to support a feature that precompile _javascript_ files to be binary to speed up loading time of program of Node.js. Cheers,Fred --  --  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.     --  --  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] NPK - Node.js packaging Utility

[Alex Kocharin]

 Another implementation will go terribly slow. V8 is a browser thingy, and I'm sure it is as fast as it could possibly be, because every millisecond counts there. So there is nothing wrong with V8. But there could be something wrong with node.js itself. Think about hundreds of .js files it needs to read on startup... "npm" itself do 964 system calls to various */node_modules/*.js files when it's starting (use strace to check that). -- // alex  14.05.2013, 01:17, "Tim Caswell" :If you ever come across a JS engine that boots as fast as Lua, I'll port node to it.  On my raspberry pi and my various webos smart-phones, node process booting takes over 1000ms, but lua is nearly instant. Actually, I think a new JS engine who's goal is to be light-weight would be really neat actually.  As long as it doesn't run too terribly slow.On Mon, May 13, 2013 at 4:07 PM, Alex Kocharin <a...@kocharin.ru> wrote: If we are talking about non-compatible solutions, I might as well use python instead ;) -- // alex  14.05.2013, 01:04, "Tim Caswell" <t...@creationix.com>:Alex, I share your pain.  That is why I made a version/port of node that didn't use V8, but rather, the much lighter-weight luajit engine.  It's at luvit.io. (warning, not compatible with node.js code or ecosystem, just the same idea / API style)On Sun, May 12, 2013 at 6:21 AM, Alex Kocharin <a...@kocharin.ru> wrote: Well, if NPK will be able to join all dependencies in one _javascript_ file, it will already be a big deal. On my system "npm" executable file takes 1.153s to load from disk and 0.153s to load from cache. All binary executables like "gpg" or "dpkg" take 0.004s to load. It's really annoying sometimes... -- // alex  11.05.2013, 10:03, "Fred Chien" <cfsgh...@gmail.com>:Hi All, I am glade to introduce NPK, which is a packaging utlity for Node.js. :-) NPK aims to package project which is based on Node.js, and bundle all _javascript_ files to make all in one file, even protect source code. Here is repository at Github: https://github.com/cfsghost/npk You also can install it directly via npm: npm install npk -g BTW, We are now trying to support a feature that precompile _javascript_ files to be binary to speed up loading time of program of Node.js. Cheers,Fred --  --  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.     --  --  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] Re: [ANN] Ghost

[Alex Kocharin]

It's just another CMS, right?

I don't know... never used those, but I suppose it'd be nice to have.


On Saturday, May 18, 2013 6:30:58 PM UTC+4, Nuno Job wrote:
>
> Hi guys,
>
> Ghost is an amazing project that is trying to re-invent blogging 
> platforms. It's written in nodejs and the authors use nodejs to create 
> content. The project is being funded in kick starter and is already fully 
> financed. Did I mention how good the ux is? :)
>
> I personally invited Hannah to speak at LXJS about this awesome project, 
> and really look forward to their foss release.
>
> If you like what they are doing i would invite you to help them in their 
> kickstarter. Not only you will get perks that will only last for 10 more 
> days you are also backing some super awesome, independent developers trying 
> to make authoring content sooo much easier:
>
>
> http://www.kickstarter.com/projects/johnonolan/ghost-just-a-blogging-platform
>
> Nuno
>
>

-- 
-- 
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: Best way to send data between php and Node

[Alex Kocharin]

PHP is designed to be ran under some apachy stuff and live for just one 
request. So it would indeed be simpler to keep a node.js server constantly 
polling server with php module in it with ajax requests.

But if this system will ever eat a lot of resources and you would like to 
turn it to a long-running daemon... I'd suggest to stop there and rewrite 
anything to node.js (or python or erlang or go or whatever). Because 
there're some things that PHP will never do good.


On Saturday, May 18, 2013 3:05:43 PM UTC+4, jasonl...@gmail.com wrote:
>
> HTTP requests would likely be best because most existing PHP software is 
> designed around the HTTP request/responce model. And yes, Node vs '...' 
> aguments are mute when you must use existing  software, especially if your 
> working on existing production systems.

-- 
-- 
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] Getting multiple responses from express get (app.get)

[Alex Kocharin]

> Note that this is *not* the best way to do it, because a) we find points, 
and then when that's done, we find balloons (in serial) whereas it would be 
more efficient to begin trying to find both points and balloons at the same 
time (in parallel);

If there's a lot of overhead involved (networking stuff), looking for them 
in parallel would be necessary.

But if we're looking for points and baloons in the same place (say, the 
same filesystem or database), they will be looked for in serial anyway, 
n'est-ce pas? You can't really turn a harddrive to a quantum superposition 
state so it would do two things at once. Therefore time to read would be 
the same, but async.js would really increase complexity here.


On Saturday, May 18, 2013 2:07:00 AM UTC+4, ryandesign wrote:
>
> On May 17, 2013, at 07:45, Are wrote: 
>
> > I am currently using mongoose, node.js , express. I need to fill up 
> multiple drop down menus from MongoDB. 
>
>
> > This calls the index (in app.js), which returns 1 collection.. but only 
> the one: 
> > app.get('/', activityList.showActivities.bind(activityList)); 
>
> This line doesn't *call* anything; it *defines* that *when* a user 
> requests "/" from your server, the server will invoke a request handler 
> function called activityList.showActivities. 
>
>
> > activitylist.js 
> > ActivityList.prototype = { 
> >   showActivities: function(req, res) { 
> >   point.find({}, function foundPoints(err, items) { 
> > res.render('index2',{title: 'CapCredits' , points: items}) 
> >   }); 
> > }, 
>
> When activityList.showActivities is invoked, it uses mongoose to find all 
> data in the "point" collection, and when the results are received, calls 
> res.render() to fill the indicated Jade template with the supplied 
> variables and sends the resulting HTML to the browser. 
>
>
> > and in my index.jade: 
> > 
> > form(action="/asdad", method="post") 
> >   select(name = "item[activity]") 
> > each activity in activities 
> >   option(value='Test') #{activity.activityName} 
>
> The res.render() invocation above uses the template "index2" not "index". 
> And here you're iterating over a variable called "activities", which your 
> res.render() invocation did not supply; you supplied a variable called 
> "points", so that's what you would be iterating over in the template. 
>
>
> > How can I do this for several collections? I have two collections which 
> I want to fill two drop down menus with. 
>
> Instead of just calling find() on the point collection, you'll also call 
> find on additional collections. Here's an example of finding all points and 
> all balloons: 
>
>   showActivities: function(req, res) { 
>   point.find({}, function foundPoints(err, points) { 
> balloon.find({}, function foundBalloons(err, balloons) { 
>   res.render('index2',{title: 'CapCredits' , points: points, 
> balloons: balloons}) 
> }); 
>   }); 
> }, 
>
> Note that this is *not* the best way to do it, because a) we find points, 
> and then when that's done, we find balloons (in serial) whereas it would be 
> more efficient to begin trying to find both points and balloons at the same 
> time (in parallel); and b) the ever-increasing indentation is ugly and 
> harder to follow. This is a common problem in nodejs for which there are an 
> unlimited number of npm modules that can help you structure your code 
> better. "async" is a very popular module for this. 
>
>
> > Is there any way I can use rest-calls like: 
> > app.get('/otherMenu', activityList.showActivities.bind(activityList)); 
>
> That line would define that when a user requests "/otherMenu" from your 
> server, the server would invoke the same activityList.showActivities 
> function you've defined above. That's probably not useful. 
>
> I don't see how REST enters into what you're trying to do at all. The term 
> "REST" is often used when talking about web services, but what you've 
> described above is not a web service; it's a web server producing a normal 
> HTML web site. Users will make one HTTP request to your server (for "/" for 
> example) and will receive a formatted HTML response containing all sorts of 
> information from various database collections that your server has 
> assembled. 
>
> If you want a web service, and want, for example, that "/otherMenu" 
> returns *just* the items of some database collection, perhaps in JSON 
> format that you'll access via AJAX and turn into DOM elements on the fly in 
> some client-side JavaScript, you can do that, but that's not what you were 
> talking about above. 
>
>

-- 
-- 
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 o

[nodejs] Re: Having trouble replicating with npm repo (couchdb) - anyone tried it lately and/or seen this error?

[Alex Kocharin]

Why do you want replication at all? I was thinking about it for myself 
recently, but I found out that there're lots of libraries you won't ever 
use. 

So isn't it better to write something like proxying repository server that 
would host your private projects, but proxy all other requests to npm 
central repository (with caching of course to avoid heavy load)? 


On Tuesday, May 14, 2013 7:16:51 AM UTC+4, andy wrote:
>
> Based on the awesome feedback I got from 
> https://groups.google.com/d/msg/nodejs/sX4mbsRPwls/WtDDE-To2o4J, we tried 
> replicating the npm repo so we could use it in an offline environment.
>
> We're essentially following the instructions at 
> http://clock.co.uk/tech-blogs/how-to-create-a-private-npmjs-repositorybut 
> replication fails after syncing about 17k documents.
>
> We've tried reinstalling couch (found one issue that suggested using a 
> patched version of SpiderMonkey) but the same thing keeps happening, even 
> after restarting replication several times.
>
> Here's our setup:
>
> CentOS 6.4
> CouchDB 1.3
> SpiderMonkey 1.8.5-7 
>
> Replication works fine for over 17,000 documents, then we see this error 
> and can't get past it:
>
> [Sat, 11 May 2013 00:55:39 GMT] [error] [<0.12970.4>] Replicator: couldn't 
> write document `bufferhelper`, revision 
> `19-d339684ee7f5eaf4cc18d84da753832d`, to target database `registry`. 
> Error: `unauthorized`, reason: `Please log in before writing to the db`.
>
> Any ideas?
>
> Thanks,
>
> Andy
>

-- 
-- 
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: Having trouble replicating with npm repo (couchdb) - anyone tried it lately and/or seen this error?

[Alex Kocharin]

Cache will protect against an outage. I mean, if you was using some module 
before, and npmjs.org is gone, such repository would just answer with an 
old version of a package pretending like new versions were not published. 
If you are beginning to use some new package, it would fail all right, but 
it's better than installing couchdb and replicating...

By the way, is it possible to track changes to a list of packages on 
npmjs.org repository? I mean something like partial replication, if I want 
to have an update of express.js ASAP, but if there is update to 
some-unknown-lib.js, I wouldn't even want to spend a traffic to know about 
it.

I'm checking out shadow-npm, but it's 400 lines of js code and it wasn't 
modified in a year. Doesn't look so promising -_-And it still uses 
CouchDB... for some reason I think this task could be solved without any 
database at all (as long as we're trying to keep things simple and don't 
talk about heavy loading, filesystem could serve as a database).


On Saturday, May 18, 2013 8:53:15 PM UTC+4, Martin Cooper wrote:
>
>
>
>
> On Sat, May 18, 2013 at 9:45 AM, Alex Kocharin 
> 
> > wrote:
>
>>
>> Why do you want replication at all? I was thinking about it for myself 
>> recently, but I found out that there're lots of libraries you won't ever 
>> use. 
>>
>
> One reason for replicating is to protect yourself against an outage of the 
> npmjs.org registry. It doesn't happen often, but it does happen.
>  
>
>> So isn't it better to write something like proxying repository server 
>> that would host your private projects, but proxy all other requests to npm 
>> central repository (with caching of course to avoid heavy load)? 
>>
>
> Something like shadow-npm, for example:
>
> https://github.com/dominictarr/shadow-npm
>
> (Caveat - I haven't actually used this, I just know it's out there.)
>
> --
> Martin Cooper
>  
>
> On Tuesday, May 14, 2013 7:16:51 AM UTC+4, andy wrote:
>>
>> Based on the awesome feedback I got from 
>> https://groups.google.com/d/msg/nodejs/sX4mbsRPwls/WtDDE-To2o4J, we 
>> tried replicating the npm repo so we could use it in an offline environment.
>>
>> We're essentially following the instructions at 
>> http://clock.co.uk/tech-blogs/how-to-create-a-private-npmjs-repositorybut 
>> replication fails after syncing about 17k documents.
>>
>> We've tried reinstalling couch (found one issue that suggested using a 
>> patched version of SpiderMonkey) but the same thing keeps happening, even 
>> after restarting replication several times.
>>
>> Here's our setup:
>>
>> CentOS 6.4
>> CouchDB 1.3
>> SpiderMonkey 1.8.5-7 
>>
>> Replication works fine for over 17,000 documents, then we see this error 
>> and can't get past it:
>>
>> [Sat, 11 May 2013 00:55:39 GMT] [error] [<0.12970.4>] Replicator: 
>> couldn't write document `bufferhelper`, revision 
>> `19-d339684ee7f5eaf4cc18d84da753832d`, to target database `registry`. 
>> Error: `unauthorized`, reason: `Please log in before writing to the db`.
>>
>> Any ideas?
>>
>> Thanks,
>>
>> Andy
>>
> -- 
> -- 
> 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.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=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+un...@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] How to Firmly Establish your Reputation

[Alex Kocharin]

Please, tag this as a joke... I'm afraid some people would take it for real. :)


-- 
// alex

21.05.2013, 19:35, "Ray Connell" :
> 1. Publish your project idea to git. At this point it doesn't matter if it
> works. Someone will immediately contribute it and fix up the bugs.
> 2. Make sure it has a fairly high revision level to start out. That way lots
> of people will download it and you have the best chance of getting some
> contributors.
> 3. Do as many of these projects as possible so people will know how creative
> you are.
> 4. Finally, make sure your full name is on everything so the credit will go
> where the credit is due.
> Best of Luck in your new career.
>
> --
> --
> 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] How to Firmly Establish your Reputation

[Alex Kocharin]

 I'm too lazy to spend a weekend on it... Maybe it's better to write a bot to grind this reputation? -_-  -- // alex  22.05.2013, 01:04, "José F. Romaniello" :you should write a book "build your reputation in a weekend with github"2013/5/21 Ray Connell 1. Publish your project idea to git. At this point it doesn't matter if it works. Someone will immediately contribute it and fix up the bugs. 2. Make sure it has a fairly high revision level to start out. That way lots of people will download it and you have the best chance of getting some contributors. 3. Do as many of these projects as possible so people will know how creative you are. 4. Finally, make sure your full name is on everything so the credit will go where the credit is due. Best of Luck in your new career.  -- -- 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.    



-- 
-- 
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: Having trouble replicating with npm repo (couchdb) - anyone tried it lately and/or seen this error?

[Alex Kocharin]

Andy,

> I would prefer to use some sort of proxy/cache, were we only pull mods we 
need (ala Artifactory or Nexus in Java land) but I hadn't really seen 
anything like that.

Well... what do you think about creating one? :)

I started a project on github - https://github.com/rlidwka/npmrepod , and 
described how I would like to see this thingy. There's no code there, but 
it's expected to change soon enough. The idea was around for 6 months or 
so, and I more or less know how it would work (except for authentication 
and access rights...).

Any thoughts on this?


--
// alex

On Sunday, May 19, 2013 2:39:40 AM UTC+4, andy wrote:
>
> Alex,
>  Response inline. :)
>
> Sent from my iPhone
>
> On May 18, 2013, at 10:45 AM, Alex Kocharin > 
> wrote:
>
>
> Why do you want replication at all? I was thinking about it for myself 
> recently, but I found out that there're lots of libraries you won't ever 
> use. 
>
>
> So isn't it better to write something like proxying repository server that 
> would host your private projects, but proxy all other requests to npm 
> central repository (with caching of course to avoid heavy load)? 
>
> We don't have any other choice, sadly - we have no network connectivity to 
> npm central where we have to develop from. 
>
> So our thought was to replicate against npm while connected, then take a 
> copy of couch/npm (even with a bunch of stuff we won't use) offline. 
>
> I would prefer to use some sort of proxy/cache, were we only pull mods we 
> need (ala Artifactory or Nexus in Java land) but I hadn't really seen 
> anything like that. Ill have to check out shadow-npm.
>
> Andy
>
>
> On Tuesday, May 14, 2013 7:16:51 AM UTC+4, andy wrote:
>>
>> Based on the awesome feedback I got from 
>> https://groups.google.com/d/msg/nodejs/sX4mbsRPwls/WtDDE-To2o4J, we 
>> tried replicating the npm repo so we could use it in an offline environment.
>>
>> We're essentially following the instructions at 
>> http://clock.co.uk/tech-blogs/how-to-create-a-private-npmjs-repositorybut 
>> replication fails after syncing about 17k documents.
>>
>> We've tried reinstalling couch (found one issue that suggested using a 
>> patched version of SpiderMonkey) but the same thing keeps happening, even 
>> after restarting replication several times.
>>
>> Here's our setup:
>>
>> CentOS 6.4
>> CouchDB 1.3
>> SpiderMonkey 1.8.5-7 
>>
>> Replication works fine for over 17,000 documents, then we see this error 
>> and can't get past it:
>>
>> [Sat, 11 May 2013 00:55:39 GMT] [error] [<0.12970.4>] Replicator: 
>> couldn't write document `bufferhelper`, revision 
>> `19-d339684ee7f5eaf4cc18d84da753832d`, to target database `registry`. 
>> Error: `unauthorized`, reason: `Please log in before writing to the db`.
>>
>> Any ideas?
>>
>> Thanks,
>>
>> Andy
>>
>  -- 
> -- 
> 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.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=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+un...@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.

[nodejs] Re: Node JS and DOM Manipulation

[Alex Kocharin]

Jsdom have terrible performance, so think about using "cheerio" instead.

As for cpu-intensiveness, you have plenty of options here. Easiest solution 
would be to increase an amount of node.js processes using "cluster" 
library. But the best way is to write another node.js server that would do 
all blocking tasks, so your frontend would be a bridge between that server 
and the user and it would be always responsive.


On Friday, May 24, 2013 11:17:49 AM UTC+4, Tamil selvan R.S wrote:
>
> Hi,
>  This is a post to get some suggestions over DOM Manipulation using JSDOM 
> in nodejs. 
>  We have currently written a service which crawls given url on the fly and 
> input it to JSDOM to inspect DOM with jQuery.
>  We see that this service consumes 90% of CPU [Expected]. The urls scraped 
> are quite heavy in their html content and around ~100 req/sec
>  As the task is quite CPU intensive [not really async aswell] we feel that 
> when concurrency of requests increases our service goes unresponsive.
>  Are we missing out something?
>

-- 
-- 
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] Module naming

[Alex Kocharin]

RPG name generator could do the job. :)

-- 
// alex

25.05.2013, 10:49, "George Stagas" :
> Hi all,
>
> I really want to name my modules however I like and be installable and
> require-able.
>
> For example, I want to write a 'merge' utility, and I don't want to
> struggle coming up with a random set of letters because I want my code
> to read require('merge') not require('golalamergifiable').
>
> What are my options currently? Anyone have any solutions?
>
> --
> --
> 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] Module naming

[Alex Kocharin]

It's an answer to unrelated question. If a package is intended to be used 
in public, it should be in public registry (npmjs.org). If it's for 
internal use, github will do fine.

But namespaces could do the job if you publish a package with a name like 
"stagas.merge". It's quite uncommon though.


On Saturday, May 25, 2013 1:39:19 PM UTC+4, Jonathan Ong wrote:
>
> just don't bother publishing it. use github namespaces in npm.
>
> {
>   "dependencies": {
> "merge": "stagas/merge"
>   }
> }
>
> On Saturday, May 25, 2013 1:34:51 AM UTC-7, Alex Kocharin wrote:
>>
>>
>> RPG name generator could do the job. :) 
>>
>> -- 
>> // alex 
>>
>> 25.05.2013, 10:49, "George Stagas" : 
>> > Hi all, 
>> > 
>> > I really want to name my modules however I like and be installable and 
>> > require-able. 
>> > 
>> > For example, I want to write a 'merge' utility, and I don't want to 
>> > struggle coming up with a random set of letters because I want my code 
>> > to read require('merge') not require('golalamergifiable'). 
>> > 
>> > What are my options currently? Anyone have any solutions? 
>> > 
>> > -- 
>> > -- 
>> > 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.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=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+un...@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] Non-web always-blocking cpu-intensive high-memory node worker

[Alex Kocharin]

What about rounding? Do you round all values after every operation? How do 
you do that?

I mean, if there is 10 dollars to be evenly split between three people, one 
of them must receive $3.3334, and two others must receive $3. (all 
banks I know of work with 1/100 of a cent). Otherwise money will not add 
up, and manager will be mad. If you're working with integers, it comes 
almost naturally because you know a priori you can't really divide evenly. 
But with floats it could be a different story.


On Friday, May 24, 2013 10:41:49 PM UTC+4, Mark Hahn wrote:
>
> > Which is okay for most use cases but not, say, when you are processing 
> monetary transactions.
>
> This is somewhat of a myth.  People are afraid of floating point numbers 
> because they are somehow "imprecise".  In fact, up to around 50 bits they 
> are as precise as integers.  I've used them for money many times.  It is as 
> simple as keeping the units in pennies.
>

-- 
-- 
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] Module naming

[Alex Kocharin]

> Whoever likes can publish to npm, whoever likes can push to Github. Both 
should be given equal chance of discovery though.

Github is a tool for development, npm registry is a tool for deployment. Am 
I missing something here? By the way, mix of those two is very well known 
to create serious trouble (https://github.com/isaacs/npm/issues/1727).

Also, there was a holywar in npm issues about namespacing... I guess 
anything about "proper naming" has been said there already:
https://github.com/isaacs/npm/issues/798


On Saturday, May 25, 2013 3:49:36 PM UTC, stagas wrote:
>
> 2013/5/25 Alex Kocharin >: 
> > 
> > It's an answer to unrelated question. If a package is intended to be 
> used in 
> > public, it should be in public registry (npmjs.org). If it's for 
> internal 
> > use, github will do fine. 
> > 
> > But namespaces could do the job if you publish a package with a name 
> like 
> > "stagas.merge". It's quite uncommon though. 
> > 
>
> I want both visibility and proper naming. That logic isn't valid. 
> Github is very public. We just need to find a way to index these along 
> with the rest npm modules. Whoever likes can publish to npm, whoever 
> likes can push to Github. Both should be given equal chance of 
> discovery though. 
>
> > 
> > 
> > On Saturday, May 25, 2013 1:39:19 PM UTC+4, Jonathan Ong wrote: 
> >> 
> >> just don't bother publishing it. use github namespaces in npm. 
> >> 
> >> { 
> >>   "dependencies": { 
> >> "merge": "stagas/merge" 
> >>   } 
> >> } 
> >> 
> >> On Saturday, May 25, 2013 1:34:51 AM UTC-7, Alex Kocharin wrote: 
> >>> 
> >>> 
> >>> RPG name generator could do the job. :) 
> >>> 
> >>> -- 
> >>> // alex 
> >>> 
> >>> 25.05.2013, 10:49, "George Stagas" : 
> >>> > Hi all, 
> >>> > 
> >>> > I really want to name my modules however I like and be installable 
> and 
> >>> > require-able. 
> >>> > 
> >>> > For example, I want to write a 'merge' utility, and I don't want to 
> >>> > struggle coming up with a random set of letters because I want my 
> code 
> >>> > to read require('merge') not require('golalamergifiable'). 
> >>> > 
> >>> > What are my options currently? Anyone have any solutions? 
> >>> > 
> >>> > -- 
> >>> > -- 
> >>> > 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.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=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+un...@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 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=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+un...@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: Module naming

[Alex Kocharin]

On Sunday, May 26, 2013 8:14:29 PM UTC+4, Isaac Schlueter wrote:

> What would you think if I had a module in github called "request", 
> which was *not* related to Mikeal's "request" module?  I can do this 
> today with github, and there are some cases with github where this may 
> be sensible.  Maybe my thing is a Ruby program, that has nothing to do 
> with Node.  The context of github is vast, because it covers all of 
> OSS. 
>

Context of npm registry... is it "registry" or "repository"?.. could be 
just as vast. I mean, one module might be called "merge" because it merges 
objects, another module might be called "merge" because it merges modules, 
third one might merge universes together and still be in npm registry 
because it's written in js... 


Of course, if you have a thing that you think ought to be called 
> "merge" *instead*, and you would like to take over the "merge" name, 
> ask the author nicely.  See http://npm.im/doc/disputes.html 
>

How many disputes do you receive per month? Is there a mailing list or 
something where I can see ownership changes and reasons for such changes?


--
// alex

-- 
-- 
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: [ANN] precond - precondition checking utilities for Node.js

[Alex Kocharin]

There is a built-in "assert" library...


On Sunday, May 26, 2013 8:54:26 PM UTC+4, Mathieu Turcotte wrote:
>
> Hi all,
>
> Precond is a small library inspired by Guava's precondition checking 
> utilities.
>  
> It provides the same basic API plus some additions relevant to a 
> dynamically typed language like Javascript. It also leverages some of 
> Javascript's introspection capabilities to generate stack traces starting 
> from the precondition check itself, i.e. the same stack trace that would be 
> generated by a plain throw statement.
>
> Here's a simple example.
>
> function div(a, b) {
>>   precond.checkArgument(b != 0, 'Expected denominator != 0 but was %s.', 
>> b);
>>   return a / b;
>> }
>
>
> The following precondition checks are provided.
>
>- checkArgument(expression, [messageFormat, [formatArgs, ...]])
>- checkState(expression, [messageFormat, [formatArgs, ...]])
>- checkIsDef(expression, [messageFormat, [formatArgs, ...]])
>- checkIsDefAndNotNull(expression, [messageFormat, [formatArgs, ...]])
>- checkIsString(expression, [messageFormat, [formatArgs, ...]])
>- checkIsArray(expression, [messageFormat, [formatArgs, ...]])
>- checkIsNumber(expression, [messageFormat, [formatArgs, ...]])
>- checkIsBoolean(expression, [messageFormat, [formatArgs, ...]])
>- checkIsFunction(expression, [messageFormat, [formatArgs, ...]])
>- checkIsObject(expression, [messageFormat, [formatArgs, ...]])
>
> The documentation, source code and examples can be found on Github. As 
> usual, the module can be installed from npm.
>
>- https://github.com/MathieuTurcotte/node-precond
>- https://npmjs.org/package/precond
>
> Simple, but hopefully useful stuff.
>
> Cheers,
> Mathieu
>

-- 
-- 
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: Module naming

[Alex Kocharin]

On Sunday, May 26, 2013 10:29:07 PM UTC+4, stagas wrote:

> As I see it, npm is 3 things right now:
>
> 1. a registry (single namespace by design, never going to change, fine)
> 2. a package manager (works with npm registry and recently gh user/repo, 
> great!)
> 3. a module discovery platform (but sadly, only for the npm registry)
>

1. This is the registry: https://github.com/isaacs/npmjs.org
2. This is the package manager: https://github.com/isaacs/npm
3. ... well... sorry, but there is no such thing called "module discovery 
platform"

What do you mean by #3 here?


--
// alex

-- 
-- 
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] how to downgrade node v0.10.8 to node-v0.8.22 on ubuntu?

[Alex Kocharin]

 Remove/uninstall your v0.10.8 version and look here: http://nodejs.org/dist/v0.8.22/ You might want to download and compile that thingy: http://nodejs.org/dist/v0.8.22/node-v0.8.22.tar.gz , or use binaries from there.  -- // alex  27.05.2013, 02:34, "rayCO RAY" :Hello, how i can downgrade node v0.10.8 to node-v0.8.22 on Ubuntu 12.04 tls? thanks --  --  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: how to downgrade node v0.10.8 to node-v0.8.22 on ubuntu?

[Alex Kocharin]

 You probably have 0.10.8 installed in /usr/bin/node and 0.8.22 in /usr/local/bin/node So, you need to uninstall old version first. I guess it's "sudo apt-get remove nodejs" or something.  -- // alex  27.05.2013, 03:06, "rayCO RAY" : i installed old version but with node -v command i still get v0.10.8i used this commands.wget http://nodejs.org/dist/v0.8.22/node-v0.8.22.tar.gz
tar xf node-v0.8.22.tar.gz
cd node-v0.8.22/
./configure
make -j2 && sudo make installOn Monday, May 27, 2013 2:55:02 AM UTC+4:30, rayCO RAY wrote:Hello, how i can downgrade node v0.10.8 to node-v0.8.22 on Ubuntu 12.04 tls? thanks --  --  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.
 
 

[nodejs] Re: [ANN] node-ifconfig: a simple module that execs ifconfig and parses its output

[Alex Kocharin]

Is it possible to make a patch for require('os').networkInterfaces() to 
show mac addresses? It would be a bit more useful...


On Wednesday, May 29, 2013 2:32:21 AM UTC+4, Ken wrote:
>
> Relatively untested so not published to npm yet, but you can clone it from 
> here
>
> https://github.com/femto113/node-ifconfig
>
> All this module does is use child_process.exec to run ifconfig (with no 
> arguments), and then parses its seizure inducing output format
> into nested javascript objects.  From there it's relatively simple to do 
> whatever you want with it, e.g. dig out MAC addresses.
> There exist far more ambitious 
> projectsthat are supersets of this 
> functionality, and also some that simply regex 
> out the MAC addresses 
> from ifconfig without bothering to parse the output, but none of them 
> quite fit my needs.  Comments/issues/pull requests welcome.
>
> --Ken
>
> By way of explanation here's some sample ifconfig output, and below is the 
> corresponding parsed objects:
>
> lo0: flags=8049 mtu 16384
> options=3
> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
> inet 127.0.0.1 netmask 0xff00 
> inet6 ::1 prefixlen 128 
> en0: flags=8823 mtu 1500
> ether 99:ff:99:42:4d:12
> media: autoselect ()
> status: inactive
> en1: flags=8863 mtu 1500
> options=2b
> ether 41:7c:9f:14:56:8c
> inet6 fe90::417c:8fff:fe12:567c%en1 prefixlen 64 scopeid 0x7
> inet 10.0.0.140 netmask 0xff00 broadcast 10.0.0.255
> media: autoselect (1000baseT )
> status: active
>
> parsed:
>
> {
>   "lo0": {
> "flags": "8049 mtu 16384",
> "options": "3",
> "inet6": "fe80::1 prefixlen 128",
> "inet": "127.0.0.1 netmask 0xff00"
>   },
>   "en0": {
> "flags": "8823 mtu 1500",
> "ether": "99:ff:99:42:4d:12",
> "media": "autoselect ()",
> "status": "inactive"
>   },
>   "en1": {
> "flags": "8863 mtu 1500",
> "options": "2b",
> "ether": "41:7c:9f:14:56:8c",
> "inet6": "fe90::417c:8fff:fe12:567c%en1 prefixlen 64 scopeid 0x7",
> "inet": "10.0.0.140 netmask 0xff00 broadcast 10.0.0.255",
> "media": "autoselect (1000baseT )",
> "status": "active"
>   }
> }
>
>

-- 
-- 
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] meaning of the semver ~

[Alex Kocharin]

A. false
B. false
C. false
D. false
E. false

'cause you submitted the arguments in a wrong order. ;)


On Thursday, May 30, 2013 11:52:47 PM UTC+4, Dominic wrote:
>
> without looking in the documentation or trying it in the repl 
>
> what do you expect to be the results of these tests on semver ranges? 
>
> A. semver.satisfies('~1.2.3', '1.2.4') 
>
> B. semver.satisfies('~1.2', '1.3.0') 
>
> C. semver.satisfies('~1.2', '1.2.6') 
>
> D. semver.satisfies('1.2', '1.3.0') 
>
> E. semver.satisfies('1.2', '1.2.4') 
>
> please don't look at the documentation, the question is: 
>
> what do you think it means? 
>

-- 
-- 
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] Using shorter ids (hashids) for mongodb objectids with mongoose

[Alex Kocharin]

> I'd like my user-facing ids to look "more random" than that. 

In other words, you want this:
4273efa0006b70
4273efa000b400
4273efa000f7e0
4273efa0013810

To look like this?:
8fe615a3dfd19b0c
0673b4d04ffa4b17
67126afba95997b4
292717c7064e6019


Well, there's a standard way of doing that. :)

var crypto = require('crypto');
var password = new Buffer('mysuperpuperpassword');

// encoding
var date = new Buffer(8);
date.writeDoubleBE(Date.now(), 0);
date = date.slice(0, 7); // fucking autopadding
var cipher = crypto.createCipher('CAST-cbc', password);
var result = cipher.update(date, null, 'hex') + cipher.final('hex');
//if (result.length == 16)
console.log('encoded thingy:', result);

// decoding
var decipher = crypto.createDecipher('CAST-cbc', password);
var final = decipher.update(result, 'hex', 'hex') + decipher.final('hex');
console.log('decoded thingy:', final.toString('hex'));
console.log('original date:', new Date(new Buffer(final+'00', 
'hex').readDoubleBE(0)));



On Thursday, May 30, 2013 11:35:53 PM UTC+4, ryandesign wrote:
>
> Thanks for your responses. 
>
>
> On May 29, 2013, at 00:40, Martin Wawrusch wrote: 
>
> > Why not simply use base56 encoding of the object id? 
>
> I haven't tried base56 (is there a module or built-in function you'd 
> recommend for that?) but a mongodb objectid begins with 4 bytes of 
> timestamp, which will be very similar for large periods of time, and then 3 
> bytes of machineid and 2 bytes of processid, which will be identical for 
> large periods of time, so a base-anything encoding of such ids would tend 
> to look quite similar. I'd like my user-facing ids to look "more random" 
> than that. 
>
>
> On May 29, 2013, at 00:48, Stuart P. Bentley wrote: 
>
> > ```js 
> > modelSchema.virtual('hashid').get(function () { 
> >   var oidhex = this._id.toHexString(); 
> >   return 
> hashids.encrypt(parseInt(oidhex.slice(0,12),16),parseInt(oidhex.slice(12),16));
>  
>
> > }); 
> > 
> > modelSchema.virtual('hashid').set(function (hashid) { 
> >   var halves = hashids.decrypt(hashid); 
> >   var zeroes = ''; 
> >   this._id = new 
> ObjectID((zeroes+halves[0]).slice(-12)+(zeroes+halves[1]).slice(-12)); 
> > }); 
> > ``` 
>
> Thanks, this is along the lines I was originally thinking. I just have to 
> train myself to set and get the "hashid" field instead of the "id" field. 
> I'll use this for now. Since I may need a hashid on multiple models, I made 
> a function to add the virtuals which I can call when defining each model. 
>
> I was hoping for actual real-world experience though. How do I find a 
> database record with a hashid? To find by objectid, I just do: 
>
> Thing.findOne({_id: req.params.thingid}, function(err, thing) {...}); 
>
> It seems like even if finding on a virtual field works, it would be slow, 
> since the index would be on the id, not the hashid. And as it turns out I 
> can't get it to work; there's no error, it just doesn't return any results. 
> So instead I've done: 
>
> Thing.findOne({_id: fromHashId(req.params.thingid)}, function(err, thing) 
> {...}); 
>
> where fromHashId does like your virtual('hashid').get() function. 
>
>
> On May 29, 2013, at 00:37, George Snelling wrote: 
>
> > FWIW, we scratched our head over the same problem, gave up, and wrote 
> our own _id generator. It's a glorified timestamp with a big random seed 
> after milliseconds part, formatted to be read by humans and look reasonable 
> in urls.  Since the high-order part increases with time, it shards well. 
>  We found it much easier to simply check for a unique index violation error 
> on insert and retry with a new key whenever that happens than to solve the 
> problem you're trying to solve. 
>
> That's good to know, thanks. What are other people actually using for 
> their short ids, regardless of backend storage system? Are you generating 
> them yourself? How are you dealing with collisions? Has it been a problem? 
>
> I want the impossible! :) I want short ids that people posting urls to 
> twitter will appreciate, but I don't want collisions or the overhead of 
> verifying that there aren't any. 
>
>

-- 
-- 
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/g

Re: [nodejs] Using shorter ids (hashids) for mongodb objectids with mongoose

[Alex Kocharin]

If you want small changes in the input to affect all bits in the output, 
then yes, that's what good ciphers are doing. If you just want users to 
clearly distinguish one value from another, that will do fine. I just hope 
you aren't going to use 64bit cipher to ensure unpredictability of ids...

I don't know what base56 is... But you can just use base64. Youtube uses 
URL-base64 encoding replacing last two chars with "-" and "_".

But anyway... mongodb id is 12 bytes. It would be 16 bytes base64-encoded. 
That's too long, and I'd very much like to see a solution to create shorter 
or more user-friendly ids.

Did you think about assigning auto-incrementing number to a message? Or a 
string like "user_number"? Or whatever... mongodb _ids are very much 
necessary, but they don't always need to be exposed to user.


On Friday, May 31, 2013 8:40:34 PM UTC+4, ryandesign wrote:
>
>
> On May 31, 2013, at 04:56, Alex Kocharin wrote: 
>
> >> I'd like my user-facing ids to look "more random" than that. 
> > 
> > In other words, you want this: 
> > 4273efa0006b70 
> > 4273efa000b400 
> > 4273efa000f7e0 
> > 4273efa0013810 
> > 
> > To look like this?: 
> > 8fe615a3dfd19b0c 
> > 0673b4d04ffa4b17 
> > 67126afba95997b4 
> > 292717c7064e6019 
> > 
> > 
> > Well, there's a standard way of doing that. :) 
>
> Ok, thanks for letting me know about crypto. So you would suggest objectid 
> -> crypto -> base56? If so, what's a good module for doing base56? 
>
>

-- 
-- 
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: try{...} can't catch exceptions with event listener

[Alex Kocharin]

Yes, there is a bug. Using throw in asyncronous programming is a bug indeed.

You're right, "throw" function is in the same context in a sense that it 
can access outer variables (it's called closure). But it is out of the 
execution context in a sense that it doesn't happen in try-catch block.

That's how node.js executes it:
1st phase (starting). 49-50-51(try)-53-54(catch)-55
2nd phase (when data is received). 52

To confirm that you can get a stack trace from function(data) and see where 
it is executed from. It won't be your function(req,res).


On Saturday, June 1, 2013 2:09:54 PM UTC+4, revin wrote:
>
> Hi,there:
>
> There may be a bug in try{...} frame that 
> can't catch exceptions triggered by event listeners inside it.
>
> I'm so interested in nodeJs,
> but since it was young,
> it has a lot of drawbacks.
>
> I've noticed that nodeJs don't have a concurrent api interface,
> so I've decided to write my own framework extension based on nodeJs.
> But soon I've encountered a problem:
> 49:function(req,res){
> 50:try{
> 51:  req.on("data",function(data){
> 52:throw new Error("FIXME: DebugTrap");
> 53:  }
> 54:}cat1ch(e){}
> 55:}
> I think everyone, of course including me,
> will hope this works,
> but it won't.
>
> The weired thing is,
> when execution reaches line 52,
> it kinds of "inherited" the execution context from line 49,
> see it can access the variables, req and res.
> But the try{...} frame on line 50 can't catch Error on line 52.
>
> It's a V8 problem? Could it be fixed with nodeJs?
> I just don't want to build try{...} frames inside every event listener...
>

-- 
-- 
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] Build Node without debugger

[Alex Kocharin]

 Change source code, but... how is it supposed to help with security anyway? It's hard to accidentally launch node.js with debugger, and node.js listens on localhost anyway (if you're allowing untrusted things connect to your localhost you have a serious issue somewhere). -- // alex  04.06.2013, 12:11, "slorobot" :I am building node.js v0.8.11 under windows 7 and would like to exclude the V8 debugger feature for security reasons. In other words, "node --debug main.js" should not spin up a debugger resulting in following output...debugger listening on port 5858Node would ignore the --debug directive.Is there a way to build Node without the debugger? --  --  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: Ask for explanation

[Alex Kocharin]

Pretty much all asynchronous code with callbacks relies on a fact that 
noone throws exceptions here and there. It's simple enough: if there is a 
callback, don't throw (unless you're working with domains).

But nobody really cares about theoretical "stack exceeded" errors, they are 
so unlikely to happen with just a few function calls, so it's easier to 
forget them until they become an issue somewhere. 


On Thursday, June 6, 2013 4:08:55 PM UTC+4, Matthew Larionov wrote:
>
> So this code relies on fact there would be no exception in 'writeFile', 
> 'fs.write' or any other called function. And if I try to change those, I 
> should keep in mind that sometimes I can throw exceptions and sometimes I 
> don't, like here:
>
>   if (!Buffer.isBuffer(buffer)) {
> // legacy string interface (fd, data, position, encoding, callback)
> callback = arguments[4];
> position = arguments[2];
> assertEncoding(arguments[3]);
>
> buffer = new Buffer('' + arguments[1], arguments[3]);
> offset = 0;
> length = buffer.length;
>   }
>
> assertEncding throws an error, but you just know that there would be a buffer 
> if it is called from 'writeAll'... Is that so?
>
>
>
>
> On Thu, Jun 6, 2013 at 2:36 PM, Ben Noordhuis 
> 
> > wrote:
>
>> On Thu, Jun 6, 2013 at 11:51 AM, Matthew Larionov 
>> > 
>> wrote:
>> > I was curious what would happen if this exception is being cought.
>> > Wonder what would happen to 'fd' - file descriptor - as far as I know 
>> there
>> > is no such thing as garbage collector for file descriptors or any other
>> > resources except memory...
>> >
>> > Do you really don't see any way for exception to be raised? Just have a 
>> look
>> > at 'writeAll' function - it's recursive. What would happen if stack is
>> > exceeded? I don't understand javascript well actually, but I thought the
>> > exception would be thrown.
>>
>> The self-recursion only goes one level deep.  writeAll() calls itself
>> from inside fs.write(), which is an asynchronous function that runs on
>> a fresh stack.
>>
>> --
>> --
>> 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.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=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/gILn3SPCyx4/unsubscribe?hl=en.
>> 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_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: Ask for explanation

[Alex Kocharin]

 Probably. But I think you can use domains, and domain.dispose() should get rid of such leaks, that's what it was designed for. -- // alex  06.06.2013, 17:07, "Matthew Larionov" :So It's ok if i call something likefs.writeFile('some_file', 'data', {encoding: 'utf8', flag : {toString : function(){ throw new Error('ps');}}}, function(err) { if(err) console.log(err); })to expect somewhere there would be a resource leak?On Thursday, June 6, 2013 4:30:13 PM UTC+4, Alex Kocharin wrote:Pretty much all asynchronous code with callbacks relies on a fact that noone throws exceptions here and there. It's simple enough: if there is a callback, don't throw (unless you're working with domains).But nobody really cares about theoretical "stack exceeded" errors, they are so unlikely to happen with just a few function calls, so it's easier to forget them until they become an issue somewhere. On Thursday, June 6, 2013 4:08:55 PM UTC+4, Matthew Larionov wrote:So this code relies on fact there would be no exception in 'writeFile', 'fs.write' or any other called function. And if I try to change those, I should keep in mind that sometimes I can throw exceptions and sometimes I don't, like here:   if (!Buffer.isBuffer(buffer)) {// legacy string interface (fd, data, position, encoding, callback)callback = arguments[4];position = arguments[2];assertEncoding(arguments[3]); buffer = new Buffer('' + arguments[1], arguments[3]);offset = 0;length = buffer.length;  }assertEncding throws an error, but you just know that there would be a buffer if it is called from 'writeAll'... Is that so? On Thu, Jun 6, 2013 at 2:36 PM, Ben Noordhuis <in...@bnoordhuis.nl> wrote:On Thu, Jun 6, 2013 at 11:51 AM, Matthew Larionov <matth...@gmail.com> wrote: > I was curious what would happen if this exception is being cought. > Wonder what would happen to 'fd' - file descriptor - as far as I know there > is no such thing as garbage collector for file descriptors or any other > resources except memory... > > Do you really don't see any way for exception to be raised? Just have a look > at 'writeAll' function - it's recursive. What would happen if stack is > exceeded? I don't understand _javascript_ well actually, but I thought the > exception would be thrown. The self-recursion only goes one level deep.  writeAll() calls itself from inside fs.write(), which is an asynchronous function that runs on a fresh stack. -- -- 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.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=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/gILn3SPCyx4/unsubscribe?hl=en. 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_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] JS or node? require("http://scripthost/myModule.js");

[Alex Kocharin]

For the benefit of keeping and updating all modules in one place.

Imagine one node.js application running on a cluster of servers. Suppose you 
want to update it on every server. You can't just log on to all of them and run 
usual "mv node_modules node_modules_`date +%s` && npm install ." because some 
servers could be down (not mentioning that it's a waste of time). And things 
like "puppet" are too complex and require some scripting.

But you can have just one fileserver and update all modules right there. After 
that just restart all servers one by one (restart command could be issued with 
a database, no need to log in), and those down servers will magically use the 
new version when they'll start up.

I hope there's no need for synchronous interfaces because harmony generators 
will do the job. I wonder if fs.*Sync methods will become obsolete when 
generators will be stable.

So anyway, the idea makes sense. But I guess remote file systems are already 
doing this job just fine.

-- 
// alex

12.06.2013, 04:37, "Isaac Schlueter" :
> Remote script execution is not worth the hazards it introduces.
>
> We could, in theory, provide some synchronous TCP/HTTP interfaces, but
> it would be extremely difficult to do well, and very hazardous to ever
> use in production.
>
> And for what?  A feature that is a security vulnerability waiting to
> happen?  Introducing all the problems that browsers have with script
> tags?
>
> No thanks.
>
> Fetch the file.  Then run the program locally.  It's not so much of a
> restriction, really.
>
> On Tue, Jun 11, 2013 at 2:06 PM, Aria Stewart  wrote:
>
>>  On June 11, 2013 at 4:59:50 PM, nos...@hoodel.com (hoodelnos...@gmail.com)
>>  wrote:
>>
>>  I'm reading JavaScript on the Server Using Node.js and Express. Having just
>>  read the chapter on modules, it seems overly restrictive to make require()
>>  refer only to files. It seems to me that a hosted module server could be
>>  really useful in some applications. Would this be a node.js issue or
>>  confined to JavaScript?
>>
>>  That's a node.js issue -- but it's one that's not easy to solve without
>>  making the simple cases harder. Remote modules implies asynchronous loading,
>>  which doesn't play nicely with the elegance of require.
>>
>>  It's so often better to separate data from code, and while data is loaded
>>  asynchronously, let code be synchronous. Then you can handle the remote
>>  loading case by downloading first (and automating this), then executing.
>>  
>>
>>  Aria Stewart
>>
>>  --
>>  --
>>  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.

-- 
-- 
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: Passing variable to the command

[Alex Kocharin]

var execFile = require('child_process').execFile;
execFile('lsof', ['-t', '-i:'+portnumber], function(err, stdout, stderr) {
   execFile('kill', [stdout], function(err, stdout, stderr) {
  // ...
   });
});

I'm skipping error checks for readability, but obviously they should be 
present in a real code.


On Thursday, June 13, 2013 1:02:32 PM UTC+4, Amit Kumar wrote:
>
> I need to to free a port by running a command kill `lsof -t -i:4723` from 
> a node.js file my code is
>
>  var sys = require('sys')
> var exec = require('child_process').exec;
> var child;
> child = exec("kill `lsof -t -i:4723`", function (error, stdout, 
> stderr) 
>{
> sys.print('stdout: ' + value);
> sys.print('stderr: ' + stderr);
> if (error !== null) {
> console.log('exec error: ' + error);
> }
> });
> it works fine but it is only for port 4723 and i want to take variabe say 
> portnumber and then use **kill `lsof -t -i:$portnumber`**  instead of 
> **kill `lsof -t -i:4723`**  and the value for the variable portnumber is 
> obtained from code file
>
> How to do this ?
>
>
>  
>

-- 
-- 
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: What is your favorite editor, (using QtCreator)?

[Alex Kocharin]

vim


On Wednesday, June 12, 2013 7:28:04 PM UTC+4, surgemcgee wrote:
>
> So hasd anyone got the *perfect* editor for Nodejs? I find that Qt Creator 
> works really well but does not auto complete the built-in stuff. I wonder 
> if there is anyone who is accomplishing this, e.g. res.wri [write, 
> writeHead]?..
>
>
>
> -- 
> Bust0ut, Surgemcgee: Systems/Web/Software Engineer
>
> "Freedom is empowered by those without power" - Robert Edward Steckroth II
> "Injustice, regarding the internet, is fashioned through laws and 
> enforcement" - Robert Edward Steckroth II
> "Reality is the fuel of the universe and the roadblock to human 
> understanding" - Robert Edward Steckroth II
>
>
>  

-- 
-- 
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: modules & deploying non-production code e.g. (docs/examples/tests?)

[Alex Kocharin]

I'm sending a response back to mailing list 'cause I was being stupid and
sent it to private...


>> There is a good reason. If a github repository will cease to exist
somehow, it ensures that docs and examples won't be lost.
> npm shouldn't be considered a backup solution

So what?...It's customary in opensource world to distribute all sources
with packages. For example, for every .deb file in Debian repository there
is a .tar.gz file with source code. Debian repository isn't a backup
solution, right? But sources are all there.


>> Documentation usually don't take much space. Well... everybody knows
that developers hate writing documentation, right? :)
> tests/examples/docs usually take up the MOST space

So you suggest to remove 5 Kb of documentation from 7 Kb module to save
space, right? Pretty nice idea, guess why I don't agree with that.


>> So I guess there are no good reasons to NOT keep it in published npm
packages.
> Except if you need to deploy on a bad internet connection. this isn't a
problem for your typical simcity 6, xbox one user, but not everyone has a
good net connection.

If you have a bad internet connection, you are in trouble anyway. npm
registry serving package metadata uncompressed, and you'll be downloading
800kb of metadata instead of 30kb compressed data. I think this question
should be attended to first. :)


>> npm packages contain too much garbage anyway. I'm talking about optional
dependencies. For example, AFAIR restify depend on a 5MB spdy library even
though very few people use spdy. So there's no point to try to save
diskspace I guess, 'cause nobody doing that anyway.
> I'm deploying on a device that doesn't have much diskspace or network
bandwidth.

Then you should be able to remove docs and tests somehow... Hm... yes, I
guess a command like `npm strip` to remove those can sometimes make sense.


>> And yes, there is a 3rd party module/tool. I think you can use
browserify to strip all this stuff and concatenate it to one js file. And
you can minimize this file later hoping that v8 would load it faster. I
didn't try that though. :)
> This is not for browser.

What is the difference? It's the same javascript.



On Thu, Jun 13, 2013 at 6:46 PM, Tim Oxley  wrote:

> haha, thanks for the response, I'm going to disagree with everything :D
>
> > There is a good reason. If a github repository will cease to exist
> somehow, it ensures that docs and examples won't be lost.
>
> npm shouldn't be considered a backup solution
>
> > Documentation usually don't take much space. Well... everybody knows
> that developers hate writing documentation, right? :)
>
> tests/examples/docs usually take up the MOST space
>
> > So I guess there are no good reasons to NOT keep it in published npm
> packages.
>
> Except if you need to deploy on a bad internet connection. this isn't a
> problem for your typical simcity 6, xbox one user, but not everyone has a
> good net connection.
>
> > npm packages contain too much garbage anyway. I'm talking about optional
> dependencies. For example, AFAIR restify depend on a 5MB spdy library even
> though very few people use spdy. So there's no point to try to save
> diskspace I guess, 'cause nobody doing that anyway.
>
> I'm deploying on a device that doesn't have much diskspace or network
> bandwidth.
>
> > And yes, there is a 3rd party module/tool. I think you can use
> browserify to strip all this stuff and concatenate it to one js file. And
> you can minimize this file later hoping that v8 would load it faster. I
> didn't try that though. :)
>
> This is not for browser.
>
> :D
>
>
>  On 13 June 2013 20:12, Alex Kocharin  wrote:
>
>>
>> There is a good reason. If a github repository will cease to exist
>> somehow, it ensures that docs and examples won't be lost. Documentation
>> usually don't take much space. Well... everybody knows that developers hate
>> writing documentation, right? :)
>>
>> So I guess there are no good reasons to NOT keep it in published npm
>> packages.
>>
>> npm packages contain too much garbage anyway. I'm talking about optional
>> dependencies. For example, AFAIR restify depend on a 5MB spdy library even
>> though very few people use spdy. So there's no point to try to save
>> diskspace I guess, 'cause nobody doing that anyway.
>>
>> And yes, there is a 3rd party module/tool. I think you can use browserify
>> to strip all this stuff and concatenate it to one js file. And you can
>> minimize this file later hoping that v8 would load it faster. I didn't try
>> that though. :)
>&g

[nodejs] Re: How can a web service send both requested output and errors/warnings to the client

[Alex Kocharin]

Use "Warning" HTTP header. See 
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

It's not a "custom http header", but a standard one. ;)


On Friday, June 14, 2013 5:47:03 AM UTC+4, ryandesign wrote:
>
> I'm trying to figure out the best way to report non-fatal errors from a 
> nodejs web service to a browser while also delivering the requested 
> content. 
>
> Suppose I have a web service that makes images, using input from the user, 
> perhaps parameters in the URL. Let's say it renders a text message in a 
> particular font: 
>
>
> http://www.example.com/makeimage.png?message=Hello%20World&font=Comic%20Sans 
>
> The result would be a PNG image of the string "Hello World", but perhaps 
> there is a non-fatal error in the user's parameters and I want to let them 
> know that as well. For example perhaps the server does not have the font 
> Comic Sans available, and it uses a fallback font instead. 
>
> Obviously for fatal errors I have to show an error message to the user. 
> But for non-fatal errors or warnings, the possibilities that occur to me 
> are: 
>
> * Ignore errors (bad: nobody sees them; user doesn't know about potential 
> problems) 
> * Log errors to the server's console only (bad: user never sees them; 
> server admin can't force users to submit perfect input) 
> * Send errors only; don't send requested output at all (bad: the specific 
> error or warning might be unimportant to the user) 
> * Render the error message(s) as text in the output image (bad: uglies up 
> the user's output with potentially unimportant cruft; also harder to 
> implement) 
> * Send errors in custom HTTP headers (bad: user could inspect them but 
> wouldn't know to look for them) 
> * Send output and errors in a JSON object (bad: binary image data would be 
> harder to use; user couldn't just use URL e.g. in an img tag's src 
> attribute) 
> * Send output and errors in a multipart/form-data or multipart/alternative 
> response (bad: browsers don't support it, do they?) 
> * Send output and errors in an HTTP status 207 Multi-Status response (bad: 
> this is for WebDAV; browsers don't support it, do they?) 
>
> Is there a best practice for this situation that I'm unaware of? 
>
>

-- 
-- 
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] modules & deploying non-production code e.g. (docs/examples/tests?)

[Alex Kocharin]

I believe we can do that right now.

package.json allows a "directories" object, see 
https://npmjs.org/doc/json.html#directories .

So you could ask sqlite maintainers to add this object to their json and 
write a software/patch that does this.


On Thursday, June 13, 2013 8:21:42 PM UTC+4, Shane Holloway wrote:
>
> >>> npm packages contain too much garbage anyway. I'm talking about 
> optional dependencies. For example, AFAIR restify depend on a 5MB spdy 
> library even though very few people use spdy. So there's no point to try to 
> save diskspace I guess, 'cause nobody doing that anyway. 
> >> I'm deploying on a device that doesn't have much diskspace or network 
> bandwidth. 
> > 
> > Then you should be able to remove docs and tests somehow... Hm... yes, I 
> guess a command like `npm strip` to remove those can sometimes make sense. 
>
> +1 to `npm strip` — it would be very useful for deploying packages like 
> sqlite where the sqlite3.c & .h are 5MB themselves. 
>
> node_modules/sqlite3% du -hd1 
> 424K  ./benchmark 
> 8.6M  ./build 
> 8.9M  ./deps 
> 4.0K  ./examples 
> 908K  ./lib 
> 692K  ./node_modules 
> 92K   ./src 
> 444K  ./test 
> 20M   . 
>
> If you trim this by hand, you can get it down to around 940K by keeping 
> the lib directory and the supporting files in the root. (measured on OSX 
> 10.8, Node 0.10.9) 
>
> It would be incredibly useful if that knowledge could be captured once by 
> the developers/maintainers of the npm modules.

-- 
-- 
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] modules & deploying non-production code e.g. (docs/examples/tests?)

[Alex Kocharin]

Get hawk authors to add something like this to package info:

"directories": {
"doc": "./images", // those pictures surely are documentation, aren't 
they
"example": "./example",
"test": "./test", // this is not in spec, but why not extend it?
}

But it's a convention. You might assume that these directories can be 
safely deleted, but it's a good idea to check everything.

Anyway, it's hard to get people publish information you need. So it might 
be a good idea to create private registry and republish packages there by 
hand (removing unnecessary information and adding whatever you want).


On Friday, June 14, 2013 1:18:19 PM UTC+4, Tim Oxley wrote:
>
> Interesting.
>
> I'd like to have an explicit set of "stuff you can safely delete in 
> production" since cruft does always fall under the categories in the spec 
> (man/example/lib/bin/doc). 
>
> For example: https://github.com/hueniverse/hawk
>
> I'd want to delete:
> - images
> - example
> - tests
>
> and maybe
> Makefile
>
> What would the logic would look like to purge those folders using 
> package.json directories?
>
>
> On Friday, 14 June 2013 15:30:42 UTC+8, Alex Kocharin wrote:
>>
>>
>> I believe we can do that right now.
>>
>> package.json allows a "directories" object, see 
>> https://npmjs.org/doc/json.html#directories .
>>
>> So you could ask sqlite maintainers to add this object to their json and 
>> write a software/patch that does this.
>>
>>
>> On Thursday, June 13, 2013 8:21:42 PM UTC+4, Shane Holloway wrote:
>>>
>>> >>> npm packages contain too much garbage anyway. I'm talking about 
>>> optional dependencies. For example, AFAIR restify depend on a 5MB spdy 
>>> library even though very few people use spdy. So there's no point to try to 
>>> save diskspace I guess, 'cause nobody doing that anyway. 
>>> >> I'm deploying on a device that doesn't have much diskspace or network 
>>> bandwidth. 
>>> > 
>>> > Then you should be able to remove docs and tests somehow... Hm... yes, 
>>> I guess a command like `npm strip` to remove those can sometimes make 
>>> sense. 
>>>
>>> +1 to `npm strip` — it would be very useful for deploying packages like 
>>> sqlite where the sqlite3.c & .h are 5MB themselves. 
>>>
>>> node_modules/sqlite3% du -hd1 
>>> 424K  ./benchmark 
>>> 8.6M  ./build 
>>> 8.9M  ./deps 
>>> 4.0K  ./examples 
>>> 908K  ./lib 
>>> 692K  ./node_modules 
>>> 92K   ./src 
>>> 444K  ./test 
>>> 20M   . 
>>>
>>> If you trim this by hand, you can get it down to around 940K by keeping 
>>> the lib directory and the supporting files in the root. (measured on OSX 
>>> 10.8, Node 0.10.9) 
>>>
>>> It would be incredibly useful if that knowledge could be captured once 
>>> by the developers/maintainers of the npm modules.
>>
>>

-- 
-- 
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] Cluster - should I use it in production?

[Alex Kocharin]

Hmm... this module is a pretty good idea. I wrote something like that as a 
university project 2 years ago, but there were no reliable cluster module 
and the code was real crappy, so it never got released.

An amount of codebase in node-forever isn't really an issue. I don't 
understand why not use "colors" or "cliff" or other libraries. If you're 
worried about install time, it's not a "forever" issue, it's "npm" issue. 

But "forever" have it's quirks. For example, they use obscure logfile names 
and thinks like that. And "forever" uses dependencies that break EVERY time 
node.js releases a major version (0.4 -> 0.6, 0.6 -> 0.8, 0.8 -> 0.10), 
that's annoying...

Anyway... I hope you don't mind if I send a couple of dozens pull requests 
there? :)


On Monday, June 17, 2013 9:07:14 PM UTC+4, Alexandre Strzelewicz wrote:
>
> I've done this module which permits to cluster your app without modifying 
> your code and manage processes/clusters quite easily : 
> https://github.com/Unitech/pm2 
> It intends to be a modern replacement of node-forever with a much lighter 
> code base
>
> Hope it can be usefull,
> Cheers 
>
> On Monday, June 17, 2013 11:30:00 PM UTC+8, Jerry Liu wrote:
>>
>> At 2013/6/17 23:17, Phil Jackson wrote: 
>> > Hey, 
>> > 
>> > I was just wondering if people are using the Cluster code in 
>> > production. If so, how's it working out so far? 
>> > 
>> > Cheers, 
>> > Phil 
>>
>> Well, it's pretty good for my program. 
>> But don't forget to check https://github.com/supershabam/net-cluster. 
>> You'll need it when mix with net module. 
>>
>

-- 
-- 
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: hopefully dumb question: what's the correct way to explicitly close an http connection from the client?

[Alex Kocharin]

res.connection.end();

On Monday, June 17, 2013 10:53:43 PM UTC+4, Ken wrote:
>
> I have a simple test client that performs load tests against a REST 
> service with http.request, essentially executing the following inside of a 
> big loop
>
>   var body = 'whatever=something';
>
>   var options = {
> hostname: 'my.api.server',
> port: 1234,
> path: '/api/that/i/want/to/test',
> method: 'POST',
> headers: {
>   'Content-Type': 'application/x-www-form-urlencoded',
>   'Content-Length': body.length
> }
>   };
>
>   var req = http.request(options, function(res) {
> console.log(res.statusCode);
> res.emit('end'); // force the connection to close (IS THIS REALLY 
> CORRECT?)
>   });
>   req.end(body);
>
> If the server is configured to send the Connection: close header (or if I 
> include the res.emit('end')line) this works fine.  However if the server 
> doesn't send that header (and e.g. restify doesn't by default) my client 
> stops getting responses after about 5 requests have been sent.  The emit 
> trick was gleaned from here
>
>
> http://stackoverflow.com/questions/14459644/node-js-howto-close-response-request-while-retrieving-data-chuncks
>
> But is this really the "node correct" way to do this?
>

-- 
-- 
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: An app to write personal thoughts in Node

[Alex Kocharin]

I loaded a page... see two buttons (login with facebook/twitter, I don't 
have one so ignoring), and undoubtedly interesting about page... where is 
an app anyway? :)

On Tuesday, June 18, 2013 11:33:50 AM UTC+4, Sourabh Agrawal wrote:
>
> I have built out a simple app in Node using ExpressJS framework. It uses 
> ridict to do some sentiment analysis. Check it out at : Pnned.com
>
> I am still working on it and is far from complete. Feedback and any other 
> kind of support is welcome.
>
> Regards. 
>

-- 
-- 
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: Serialize: a simple node utility to serialize execution of asynchronous functions

[Alex Kocharin]

It's exactly that kind of thing streamlinejs does, isn't it?


On Saturday, June 22, 2013 12:39:23 AM UTC+4, Chaoran Yang wrote:
>
> Dear all,
>
> I'm tired of the poor syntax of Step or Async or any other existing flow 
> control libraries. I created a new flow control library in nodejs: 
> Serialize (http://github.com/chaoran/node-serialize).
>
> Here's a brief introduction. There's more in the Github page.
>
> Serialize
>
> A simple node utility to serialize execution of asynchronous functions.
>
> What
>  
> does it do?
>
> Asynchrony in nodejs is great, except that it makes your code looks 
> horrible because of all the callbacks. If you use synchronous functions, 
> which give you good-looking, easy-to-read code, they will block the thread 
> and make your server not responsive.
>
> Here's serailize to the rescue! serialize converts your asynchronous 
> functions into serialized versions. Serialized functions are executed one 
> after another, without explicitly chaining them with callback functions.
> serialize does *NOT* execute the function synchronously (block the 
> thread), it just serialize the execution of asynchronous functions. So that 
> it makes the code looks synchronous, but it is actually ascynhronous 
> underneath.
>
> How
>  
> to use it?
>
> To create a serialized version of an asynchronous function, call serialize 
> with 
> it. For example, if you want to make serialized versions of fs.writeFile
>  and fs.mkdir, you do:
>
> var serialize = require('serialize');
> fs.mkdir = serialize(fs.mkdir);fs.writeFile = serialize(fs.writeFile);
>
> Then, you can use fs.mkdir and fs.writeFile like they are synchronous 
> functions:
>
> fs.mkdir('new');fs.mkdir('new/folder');fs.writeFile('new/folder/hello.txt', 
> "hello world", callback);
>
> These function will be executed one after another, but they will not block 
> the thread as their synchronous versions do. The callback will be invoked 
> after the last call completes.
>
>
>

-- 
-- 
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] [ANN] ynpm: using package.yaml files instead of package.json

[Alex Kocharin]

Hi guys,

TL;DR: I developed a package that monkey-patches npm to work with 
package.yaml files without any json ever written to a disk. Hope it will be 
useful.

Published as npm module a month ago: https://npmjs.org/package/ynpm 
(github: https://github.com/rlidwka/ynpm ), and I think it's ready to use 
now.

So, 6 months ago I asked in the mailing list about how to place comments in 
package.json files ( 
https://groups.google.com/forum/?fromgroups#!topic/nodejs/NmL7jdeuw0M ) and 
found no good answer for that. So for a long time I used package.js and a 
Makefile to generate package.json. Rather ugly solution.

We were developing a large and complex project, and I submitted dozens pull 
requests to other packages. But until these PR were merged, I needed to 
point these dependencies to my git repositories with these changes in 
place. And THAT is why I desperately needed comments.

So anyway... these are fundamental issues with JSON:

1. JSON have no comments, you can't comment out why did you put some 
dependency, but not the other.
2. JSON have no trailing comma. So you can't easily remove an item, add an 
item or interchange two arbitrary lines in a list.
3. JSON require ugly enquoting both keys and values in object. Javascript 
require enquoting values only, and YAML doesn't require quotes in most 
cases.

JSON is designed to be written by computers, not humans. Humans could read 
it easily, but maintaining JSON is a pain.

Why YAML? Well, I would certainly not use XML. :) Anyway, YAML it's easier 
to read and edit than all other widely known serialization formats, and it 
solves all issues described above. I would fully support if Isaacs returns 
package.js back to work (see 3y old github issue 
https://github.com/isaacs/npm/issues/408 ), it would be good enough, but it 
doesn't seem to happen.

So, a lot of other people suggested to use YAML. That's the most recent 
github issue https://github.com/isaacs/npm/issues/3336 , but there were 
others.

And there are some existing solutions to do that, for example npm-yaml: 
https://npmjs.org/package/npm-yaml. But all these solutions just 
pre-compile package.yaml before npm is executed. It's not good enough 
because json remains written on the disk, and if npm modifies json, yaml 
remains unmodified.

So, I wrote a wrapper that replaces fs.* calls, so whenever npm reads 
package.json file, and if there is a yaml file, we compile and return yaml 
contents. If npm writes package.json, we change yaml instead.

I made sure that all npm functionality is working with this new approach. 
For example, in order to make `npm version` working I replaced 
execFile("git", ["add", "package.json"]) with an appropriate substitute. 
Other features required to replace readdir and file streams, and so on.

If something is wrong with this approach or if something breaks beyond 
fixing with future npm versions, I'll go for a fork. But as for now things 
seem to work out nicely.

PS: to guys who write YAML parsers: could you please write a module to 
change one particular node in YAML file without rewriting the entire file? 
Because it is the only thing here that ain't very good. I know it can't be 
done in a general case, but it doesn't mean we shouldn't try.

Regards,
alex

-- 
-- 
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] [ANN] ynpm: using package.yaml files instead of package.json

[Alex Kocharin]

When ynpm looks in a directory, it sees both files: real yaml file and a 
"virtual" json file. So it packs both.

It's very much intentional to ensure interoperability. We can use whatever 
we want in development enviroment (coffee-script, package.yaml, other cool 
stuff), but other people who will install a package from registry should 
have as little issues with it as possible, which means compiled to 
javascript modules and a package.json format.


On Sunday, June 23, 2013 10:32:19 PM UTC+4, José F. Romaniello wrote:
>
> Do you pack/publish with package.yaml inside? How does that works with the 
> npm service? 
> El 23/06/2013 13:12, "Alex Kocharin" > 
> escribió:
>
>> Hi guys,
>>
>> TL;DR: I developed a package that monkey-patches npm to work with 
>> package.yaml files without any json ever written to a disk. Hope it will be 
>> useful.
>>
>> Published as npm module a month ago: https://npmjs.org/package/ynpm(github: 
>> https://github.com/rlidwka/ynpm ), and I think it's ready to use now.
>>
>> So, 6 months ago I asked in the mailing list about how to place comments 
>> in package.json files ( 
>> https://groups.google.com/forum/?fromgroups#!topic/nodejs/NmL7jdeuw0M ) 
>> and found no good answer for that. So for a long time I used package.js and 
>> a Makefile to generate package.json. Rather ugly solution.
>>
>> We were developing a large and complex project, and I submitted dozens 
>> pull requests to other packages. But until these PR were merged, I needed 
>> to point these dependencies to my git repositories with these changes in 
>> place. And THAT is why I desperately needed comments.
>>
>> So anyway... these are fundamental issues with JSON:
>>
>> 1. JSON have no comments, you can't comment out why did you put some 
>> dependency, but not the other.
>> 2. JSON have no trailing comma. So you can't easily remove an item, add 
>> an item or interchange two arbitrary lines in a list.
>> 3. JSON require ugly enquoting both keys and values in object. Javascript 
>> require enquoting values only, and YAML doesn't require quotes in most 
>> cases.
>>
>> JSON is designed to be written by computers, not humans. Humans could 
>> read it easily, but maintaining JSON is a pain.
>>
>> Why YAML? Well, I would certainly not use XML. :) Anyway, YAML it's 
>> easier to read and edit than all other widely known serialization formats, 
>> and it solves all issues described above. I would fully support if Isaacs 
>> returns package.js back to work (see 3y old github issue 
>> https://github.com/isaacs/npm/issues/408 ), it would be good enough, but 
>> it doesn't seem to happen.
>>
>> So, a lot of other people suggested to use YAML. That's the most recent 
>> github issue https://github.com/isaacs/npm/issues/3336 , but there were 
>> others.
>>
>> And there are some existing solutions to do that, for example npm-yaml: 
>> https://npmjs.org/package/npm-yaml. But all these solutions just 
>> pre-compile package.yaml before npm is executed. It's not good enough 
>> because json remains written on the disk, and if npm modifies json, yaml 
>> remains unmodified.
>>
>> So, I wrote a wrapper that replaces fs.* calls, so whenever npm reads 
>> package.json file, and if there is a yaml file, we compile and return yaml 
>> contents. If npm writes package.json, we change yaml instead.
>>
>> I made sure that all npm functionality is working with this new approach. 
>> For example, in order to make `npm version` working I replaced 
>> execFile("git", ["add", "package.json"]) with an appropriate substitute. 
>> Other features required to replace readdir and file streams, and so on.
>>
>> If something is wrong with this approach or if something breaks beyond 
>> fixing with future npm versions, I'll go for a fork. But as for now things 
>> seem to work out nicely.
>>
>> PS: to guys who write YAML parsers: could you please write a module to 
>> change one particular node in YAML file without rewriting the entire file? 
>> Because it is the only thing here that ain't very good. I know it can't be 
>> done in a general case, but it doesn't mean we shouldn't try.
>>
>> Regards,
>> alex
>>
>> -- 
>> -- 
>> 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&qu

Re: [nodejs] [ANN] ynpm: using package.yaml files instead of package.json

[Alex Kocharin]

Hi Isaac,

> I'd recommend against using `ynpm` as the bin name, if only because I'm 
an ex-yahoo, and `ynpm` sounds like Yahoo!'s fork of npm ;) 

Isn't it a good thing that Yahoo won't be able to fork it under this name? 
:)

Oh well... could you please suggest another name? I really so bad at naming 
things...

Special keys are obviously ugly and generate too much noise. Besides, 
originally I wanted to comment dependencies, so it can't be used anyway. 
This was discussed over and over in the past. There was just one acceptable 
solution (it's javascript instead of json which compiles to json when 
publishing), but it's long gone now. :(


On Monday, June 24, 2013 7:37:07 PM UTC+4, Isaac Schlueter wrote:
>
> As with using CoffeeScript or Streamline to write your JavaScript, I 
> have no problem with stuff like this for publishing to npm, as long as 
> what ends up in the registry is "regular" json and javascript. 
>
> I'd recommend against using `ynpm` as the bin name, if only because 
> I'm an ex-yahoo, and `ynpm` sounds like Yahoo!'s fork of npm ;) 
>
> You know, you CAN put comments in JSON by just using a key that isn't 
> used for anything else.  You can't put it in places (such as 
> `dependencies`) where the key name is relevant information, of course. 
>  But at the top-level, this is fine: 
>
> ```json 
> { "name": "silverware-drawer" 
> , "description": "BECAUSE ITS FULL OF FORKS GET IT!?" 
> , "//": 
>   [ "This package.json file has a lot of forks on github" 
>   , "of things that I've forked and added patches to." 
>   , "I'll use the 'real' one once they're merged." ] 
> , "//0": "Use an ID on multiple comments so they don't clobber" 
> , "//1": {"this":"may","not":"be","ideal":"but","it":"works"} 
> , "dependencies": { "foo":"my/fork" } 
> } 
> ``` 
>
>
> On Sun, Jun 23, 2013 at 11:59 AM, Alex Kocharin 
> > 
> wrote: 
> > 
> > When ynpm looks in a directory, it sees both files: real yaml file and a 
> > "virtual" json file. So it packs both. 
> > 
> > It's very much intentional to ensure interoperability. We can use 
> whatever 
> > we want in development enviroment (coffee-script, package.yaml, other 
> cool 
> > stuff), but other people who will install a package from registry should 
> > have as little issues with it as possible, which means compiled to 
> > javascript modules and a package.json format. 
> > 
> > 
> > 
> > On Sunday, June 23, 2013 10:32:19 PM UTC+4, José F. Romaniello wrote: 
> >> 
> >> Do you pack/publish with package.yaml inside? How does that works with 
> the 
> >> npm service? 
> >> 
> >> El 23/06/2013 13:12, "Alex Kocharin"  escribió: 
> >>> 
> >>> Hi guys, 
> >>> 
> >>> TL;DR: I developed a package that monkey-patches npm to work with 
> >>> package.yaml files without any json ever written to a disk. Hope it 
> will be 
> >>> useful. 
> >>> 
> >>> Published as npm module a month ago: https://npmjs.org/package/ynpm 
> >>> (github: https://github.com/rlidwka/ynpm ), and I think it's ready to 
> use 
> >>> now. 
> >>> 
> >>> So, 6 months ago I asked in the mailing list about how to place 
> comments 
> >>> in package.json files ( 
> >>> https://groups.google.com/forum/?fromgroups#!topic/nodejs/NmL7jdeuw0M) 
> >>> and 
> >>> found no good answer for that. So for a long time I used package.js 
> and a 
> >>> Makefile to generate package.json. Rather ugly solution. 
> >>> 
> >>> We were developing a large and complex project, and I submitted dozens 
> >>> pull requests to other packages. But until these PR were merged, I 
> needed to 
> >>> point these dependencies to my git repositories with these changes in 
> place. 
> >>> And THAT is why I desperately needed comments. 
> >>> 
> >>> So anyway... these are fundamental issues with JSON: 
> >>> 
> >>> 1. JSON have no comments, you can't comment out why did you put some 
> >>> dependency, but not the other. 
> >>> 2. JSON have no trailing comma. So you can't easily remove an item, 
> add 
> >>> an item or interchange two arbitrary lines in a list. 
> >>> 3. JSO

Re: [nodejs] [ANN] ynpm: using package.yaml files instead of package.json

[Alex Kocharin]

> Actually, Yahoo! has had an internal customised version of npm under the 
> name 'ynpm' for about 2 years now. It's not published to the public 
> registry because the changes and extensions relate to proprietary 
> technologies.
>
 
They already have? Well, fair enough, changing a name now.

I guess that's another argument why npm needs namespaces. :)

 

> Oh well... could you please suggest another name? I really so bad at 
>> naming things...
>>
>
> I'm not good at naming things either. A few ideas off the top of my head: 
> alt-npm, yapm, ypkg, yaml-pkg, ypnpm (yaml-patched npm). Did I say I was no 
> good at naming things? :-)
>

Actually, "yapm" sounds pretty good... I think I'll pick that one. Changing 
repository/package name as well because bin name and package name should 
match to avoid confusion: https://npmjs.org/package/yapm

--
Regards,
alex

Special keys are obviously ugly and generate too much noise. Besides, 
>> originally I wanted to comment dependencies, so it can't be used anyway. 
>> This was discussed over and over in the past. There was just one acceptable 
>> solution (it's javascript instead of json which compiles to json when 
>> publishing), but it's long gone now. :(
>>
>>
>>
>> On Monday, June 24, 2013 7:37:07 PM UTC+4, Isaac Schlueter wrote:
>>
>>> As with using CoffeeScript or Streamline to write your JavaScript, I 
>>> have no problem with stuff like this for publishing to npm, as long as 
>>> what ends up in the registry is "regular" json and javascript. 
>>>
>>> I'd recommend against using `ynpm` as the bin name, if only because 
>>> I'm an ex-yahoo, and `ynpm` sounds like Yahoo!'s fork of npm ;) 
>>>
>>> You know, you CAN put comments in JSON by just using a key that isn't 
>>> used for anything else.  You can't put it in places (such as 
>>> `dependencies`) where the key name is relevant information, of course. 
>>>  But at the top-level, this is fine: 
>>>
>>> ```json 
>>> { "name": "silverware-drawer" 
>>> , "description": "BECAUSE ITS FULL OF FORKS GET IT!?" 
>>> , "//": 
>>>   [ "This package.json file has a lot of forks on github" 
>>>   , "of things that I've forked and added patches to." 
>>>   , "I'll use the 'real' one once they're merged." ] 
>>> , "//0": "Use an ID on multiple comments so they don't clobber" 
>>> , "//1": {"this":"may","not":"be","**ideal":"but","it":"works"} 
>>> , "dependencies": { "foo":"my/fork" } 
>>> } 
>>> ``` 
>>>
>>>
>>> On Sun, Jun 23, 2013 at 11:59 AM, Alex Kocharin  
>>> wrote: 
>>> > 
>>> > When ynpm looks in a directory, it sees both files: real yaml file and 
>>> a 
>>> > "virtual" json file. So it packs both. 
>>> > 
>>> > It's very much intentional to ensure interoperability. We can use 
>>> whatever 
>>> > we want in development enviroment (coffee-script, package.yaml, other 
>>> cool 
>>> > stuff), but other people who will install a package from registry 
>>> should 
>>> > have as little issues with it as possible, which means compiled to 
>>> > javascript modules and a package.json format. 
>>> > 
>>> > 
>>> > 
>>> > On Sunday, June 23, 2013 10:32:19 PM UTC+4, José F. Romaniello wrote: 
>>> >> 
>>> >> Do you pack/publish with package.yaml inside? How does that works 
>>> with the 
>>> >> npm service? 
>>> >> 
>>> >> El 23/06/2013 13:12, "Alex Kocharin"  escribió: 
>>> >>> 
>>> >>> Hi guys, 
>>> >>> 
>>> >>> TL;DR: I developed a package that monkey-patches npm to work with 
>>> >>> package.yaml files without any json ever written to a disk. Hope it 
>>> will be 
>>> >>> useful. 
>>> >>> 
>>> >>> Published as npm module a month ago: https://npmjs.org/package/ynpm 
>>> >>> (github: 
>>> >>> https://github.com/rlidwka/**ynpm<https://github.com/rlidwka/ynpm>), 
>>> >>> and I think it's ready to use 
>>> >>

[nodejs] Re: Best way to return HTTP 500 errors to all open connections when one errors

[Alex Kocharin]

On Wednesday, June 26, 2013 2:22:05 AM UTC+4, Tyler Cooke wrote:

> This e-mail, and any attachments, is intended only for use by the 
> addressee(s) named herein and may contain legally privileged and/or 
> confidential information.  It is the property of Telogis.  If you are not 
> the intended recipient of this e-mail, you are hereby notified that any 
> dissemination, distribution or copying of this e-mail, any attachments 
> thereto, and use of the information contained, is strictly prohibited.  If 
> you have received this e-mail in error, please notify the sender and 
> permanently delete the original and any copy thereof. 
>

Well, since I'm not the addressee (my name isn't appear on the email 
anywhere), I hereby officially notify you about that. I will permanently 
delete this message and... should I try to hack google mailing list servers 
because they contain copies?

-- 
-- 
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] [ANN] yapm: using package.yaml files instead of package.json

[Alex Kocharin]

 I'm not talking about how to develop dependencies right now. I'm talking about how to track relevant information about them. When I see a critical bug in a 3rd party npm module, I fix it and send a PR. But PRs sometimes take months to get merged, so I change dependency version to a git fork. When PR gets merged, I return back to npm version. Therefore it's extremely important to preserve information about why was a particular fork was created. I could add this to readme, but that's what comments are for. This is how our dependency list for one project looked a few months ago (right now most of these are resolved and current version doesn't look so impressive). I can't imagine how to write all this information and keep it in sync with actual package data without comments. # main dependenciesdependencies: {   # require express 3 api   express: ">= 3.0.1"   # we depend on this PR: https://github.com/jed/cookies/pull/18   cookies: ">= 0.3.4"   async: ">= 0.1.22"   # date packages   date-utils: ">= 1.2.12"   strftime: ">= 0.4.7"   # severe bug fixed by me, but not yet approved: https://github.com/TooTallNate/node-time/pull/22   time: "git://github.com/rlidwka/node-time.git"   # this package is outdated in NPM, trouble with startRecording   tropo-webapi: ">= 1.0.16"   # another critical bug here: https://github.com/stevegraham/twilio-js/pull/3   twilio-js: "git://github.com/rlidwka/twilio-js.git"   # TODO: unfixed bug: https://github.com/visionmedia/jade/issues/761   # also waiting for this PR: https://github.com/visionmedia/jade/pull/629   # the same PR rebased: https://github.com/visionmedia/jade/pull/812   jade: "git://github.com/rlidwka/jade.git"   nodemailer: ">= 0.3.31"   mailparser: ">= 0.2.30"   # we require "type: raw" for bunyan logs that appears in 0.10   bunyan: ">= 0.10.2"   # severe bug fixed, but not yet pushed to the repository: https://github.com/milewise/mongode/pull/6   # also this one: https://github.com/milewise/mongode/pull/7   mongode: "git://github.com/rlidwka/mongode.git"   # bug: https://github.com/andris9/simplesmtp/pull/17   simplesmtp: ">= 0.1.25"   # it's my own assets manager, opensource and released as npm module   asset-pipeline: ">= 0.2.0"   # assets compilers   less: ">= 1.3.1"   ejs: ">= 0.8.3"   # for development only   hotswap: ">= 1.0.0"   hashish: "*"   # for API reference   marked: "*"   highlight: "*"   # there's a lot of nexmo modules, but none really good; this one at least working   node-nexmo-api: "*"}  -- // alex  26.06.2013, 13:42, "Floby" :Why are you not using git submodules ? this seems like something you'd want to try out if most of your dependencies are git repos.On Sunday, 23 June 2013 18:12:28 UTC+2, Alex Kocharin wrote:Hi guys,TL;DR: I developed a package that monkey-patches npm to work with package.yaml files without any json ever written to a disk. Hope it will be useful.Published as npm module a month ago: https://npmjs.org/package/ynpm (github: https://github.com/rlidwka/ynpm ), and I think it's ready to use now.So, 6 months ago I asked in the mailing list about how to place comments in package.json files ( https://groups.google.com/forum/?fromgroups#!topic/nodejs/NmL7jdeuw0M ) and found no good answer for that. So for a long time I used package.js and a Makefile to generate package.json. Rather ugly solution.We were developing a large and complex project, and I submitted dozens pull requests to other packages. But until these PR were merged, I needed to point these dependencies to my git repositories with these changes in place. And THAT is why I desperately needed comments.So anyway... these are fundamental issues with JSON:1. JSON have no comments, you can't comment out why did you put some dependency, but not the other.2. JSON have no trailing comma. So you can't easily remove an item, add an item or interchange two arbitrary lines in a list.3. JSON require ugly enquoting both keys and values in object. _javascript_ require enquoting values only, and YAML doesn't require quotes in most cases.JSON is designed to be written by computers, not humans. Humans could read it easily, but maintaining JSON is a pain.Why YAML? Well, I would certainly not use XML. :) Anyway, YAML it's easier to read and edit than all other widely known serialization formats, and it solves all issues described above. I would fully support if Isaacs returns package.js back to work (see 3y old github issue https://github.com/isaacs/npm/issues/408 ), it would be good enough, but it doesn't seem to happen.So, a lot of other people suggested to use YAML. That's the most recent github issue https://github.com/isaacs/npm

[nodejs] Re: Private variables and setTimeout issue.

[Alex Kocharin]

> What am I missing here?

It's a well-known V8 bug, it just doesn't understand let statements without 
strict mode. Hope it'll be fixed soon.


On Thursday, July 11, 2013 11:02:12 PM UTC+4, Jean-Michel Hiver wrote:
>
> The OP is lost :-)
>
> Matt, excuse my poor Javascript mastery... you said I should use "let", but
>
> let foo = "bar";
>
> Yields:
>
> function (exports, require, module, __filename, __dirname) { let foo = 
> "bar";
>   ^^^
> SyntaxError: Unexpected identifier
> at Module._compile (module.js:437:25)
> at Object.Module._extensions..js (module.js:467:10)
> at Module.load (module.js:356:32)
> at Function.Module._load (module.js:312:12)
> at Module.runMain (module.js:492:10)
> at process.startup.processNextTick.process._tickCallback 
> (node.js:244:9)
>
> What am I missing here?
>

-- 
-- 
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: update git dependencies

[Alex Kocharin]

1. mv node_modules node_modules.backup
2. npm install

`npm update` is just broken, and there is no way around it :(


On Monday, July 8, 2013 8:15:50 PM UTC+4, Maxim Yefremov wrote:
>
> I got lib1 that depends on lib2 via git:
> "dependencies": {
> "lib2": "git+ssh://g...@repo.com:userName/lib2.git"
>   }
> When code changed in lib2 repository I want to have changes in lib1. What 
> should I do to get that changes in lib1. I try* npm install* in lib1 but 
> nothing had changed. 
>

-- 
-- 
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] new project - simpleio

[Alex Kocharin]

err... guys, what is wrong with socket.io? I used socket.io for a long time 
(until moved to pure websockets 'cause screw ie6), and was quite happy with 
it then.


On Tuesday, July 9, 2013 6:49:52 PM UTC+4, mgutz wrote:
>
> I've come to the  same conclusion Meteor, Pusher and you have and that 
> SockJS is the way to go. I'm reluctant to use engine.io having 
> experienced socket.io from the same group. How long  has socket.io 1.0 
> been ready ready to release? Last I checked the socket.io repo master 
> branch doesn't even work and has not been updated in months.
>
> On Monday, July 8, 2013 9:04:47 AM UTC-7, Eric Mill wrote:
>>
>> Hi Oleg,
>>
>> Could you describe how simpleio would be preferable to using 
>> sockjs? 
>> It was also borne out of frustration with socket.io, and I've had a 
>> great experience with it.
>>
>> -- Eric
>>
>>
>> On Mon, Jul 8, 2013 at 9:27 AM, Oleg Slobodskoi wrote:
>>
>>> Forgot to mention, that in-memory and mongodb storage adapters are 
>>> already in the package.
>>>
>>>  
>>> Am 08.07.2013 um 15:01 schrieb Oleg Slobodskoi :
>>>
>>> Hello there :)
>>>
>>> I have recently started a new project after lots of frustration with 
>>> socketio. Simpleio is not a full replacement of all the features of 
>>> socketio, but its actually everything one might need to create chatty like 
>>> messaging on any hosting using a long polling which works everywhere. Most 
>>> important design goals are:
>>>
>>>- support for router/balancer without sticky sessions (f.e. Heroku) 
>>>- optimized for horizontal scaling
>>>- reliable message delivery (built-in delivery confirmation)
>>>- multiplexing on the server and client
>>>- lightweight client (appr. 2.5 kb minified and gzipped) 
>>>- simple client spec, which can be implemented easily in any language
>>>
>>> Native clients for anroid and ios are will be usable in some weeks.
>>>
>>> Best,
>>> Oleg
>>>
>>> http://github.com/kof/simpleio
>>>
>>>
>>>
>>> -- 
>>> -- 
>>> 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.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=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+un...@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 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=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+un...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>  
>>>  
>>>
>>
>>
>>
>> -- 
>> konklone.com | @konklone 
>>  
>

-- 
-- 
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: Is it possible to prevent require() from resolving the realpath of linked modules?

[Alex Kocharin]

You can also try to make use of module.parent.require() function and 
module.parent.parent.(...).parent.require() to get dependencies using 
context of modules that required current module.


On Tuesday, July 9, 2013 7:58:47 AM UTC+4, j...@team9.com.au wrote:
>
> Thanks for the suggestions guys, I'm going with a similar approach to 
> Floby's suggection and making it possible to provide mongoose to mymodule 
> for development (whereas in production it will inherit from the parent 
> project).
>
> On Wednesday, July 3, 2013 1:29:51 PM UTC+10, j...@team9.com.au wrote:
>>
>> I am developing a module which requires access to the same cached version 
>> of a module (mongoose) that my main application uses.
>>
>> As explained by the docs, here: 
>> http://nodejs.org/api/modules.html#modules_addenda_package_manager_tips
>>
>> *...Node looks up the realpath of any modules it loads (that is, 
>> resolves symlinks), and then looks for their dependencies in the 
>> node_modules folders as described above...*
>>
>> In this case I have a directory structure:
>>
>> ~/projects/mymodule <- exposed using npm link
>>
>> ~/projects/app/web.js
>> ~/projects/app/node_modules/mongoose
>> ~/projects/app/node_modules/mymodule <- points to ~/projects/mymodule 
>> thanks to npm link mymodule
>>
>> In *~/projects/app/web.js:*
>>
>> var mongoose = require('mongoose'), mymodule = require('mymodule');
>> // followed by configuration of the mongoose instance
>>
>> In *~/projects/mymodule/index.js:*
>>
>> var mongoose = require('mongoose');
>> // needs to be the same instance of mongoose configured 
>> by ~/projects/app/web.js
>>
>>
>> Because require() looks up the realpath of mymodule, it never finds the 
>> mongoose module installed in app.
>>
>> This is different from how it will behave in real-world usage (when 
>> mymodule is installed via npm).
>>
>> I understand this is a bit of a special case, in that I explicitly want 
>> the same version of a module in use by the main app, and never a specific 
>> one. I have not specified mongoose as a dependency of mymodule, and 
>> leave the author to ensure a valid, compatible version is required by the 
>> author of the app using mymodule.
>>
>> If there is a way to fix this (or a better structure), please let me 
>> know. To achieve what I am trying to do, it is crucial that the same 
>> instance of mongoose is shared between mymodule and the app.
>>
>> Thanks,
>> Jed.
>>
>>

-- 
-- 
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: Organizing Socket IO code

[Alex Kocharin]

You can pass client/socket object and whatever else you need to different 
files. I see no problem with that. Also, socket.io supports namespaces 
exactly for this kind of things.

PS: another good solution would be to forget about MVC forever ;)


On Sunday, June 30, 2013 8:50:29 AM UTC+4, Mike Chen wrote:
>
> Hi guys,
>
> I'm pretty new to Node.JS and socket IO, so I was wondering if I could get 
> some guidance on project I'm working on. I would like to build a single 
> page multiplayer game that basically communicates solely through socket.IO. 
>
> However, I am quickly seeing that my socket.js file is getting very 
> clumsy. I am using express to manage the MVC side of things, but I feel 
> like socket connections don't really fit in the MVC paradigm. 
>
> I have read a bunch of tutorials on node JS and socket IO, but all of them 
> have small socket components. 
>
> Essentially I am wondering how to break down a large socket.js file into 
> smaller more manageable components? For example, I have a chat room in the 
> page, as well as the game part, and some meta game aspects. I don't feel 
> like these all belong in the same socket.js file, but it doesnt seem clean 
> to divide them in separate files either because you need access to the 
> client and the socket object ( to emit to all users in a room lets say) 
>
> Thanks
>
>
>
>

-- 
-- 
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: Which is faster javascript run on server and browser

[Alex Kocharin]

Client-side is run by C++ too. There is no difference between server side 
and client side. It is the same javascript anyway. So performance in the 
ideal case would be exactly the same.

But keep in mind that your server would be busy serving other clients, and 
browser would be busy rendering stuff, so it depends not on javascript 
performance, but on the other stuff a computer is doing. Usually browser is 
busy rendering a page in the exactly the same moment javascript should 
start working, so it is usually slower because of that.


On Sunday, July 14, 2013 7:42:05 AM UTC+4, Ket wrote:
>
> Thank you,
>
> I always think server side is faster because it is run by C++. But user 
> base would grow over time. Use sense sometimes not make sense.
>

-- 
-- 
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: Template engine usage statistics

[Alex Kocharin]

There is an amount of stars in github and an amount of downloads in npm 
repository, so yes it is available.


On Saturday, July 13, 2013 9:03:21 PM UTC+4, Samuel Neff wrote:
>
> I'm deciding on a template engine to use for a simple first Node.js site 
> and am curious if there are any usage statistics anywhere.  I searched and 
> didn't find any.
>
> I've seen performance statistics but don't feel they're relevant since I 
> don't expect templating to be a bottleneck.  I've compared features and 
> have preferences, but I also don't want to use a template engine that is 
> rarely used by others and thus may die out.  The only type of quantitative 
> statistics I've found are github commits and contributors.  Is there 
> something else available?
>
> Thanks,
>
> 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] Hope next release supports "strict mode"

[Alex Kocharin]

 Why on Earth would you need that? User modules can work as is because strict mode affects lexical scope and don't affect function calls. As for core code... if core team chooses to ignore 'use strict', I'd be happy with that because this mode is a silly idea anyway. -- // alex  14.07.2013, 19:07, "Bo B" :version 0.8.15 supports "strict mode" but later 0.8.x does not due to "fs" api.. for 0.10.x branch , "strict mode" is broken by "tls.js" node need another code clearing --  --  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.
 
 

[nodejs] Re: local private npm repository

[Alex Kocharin]

Hi Osher,

I'm trying to implement such server in this project: 
https://github.com/rlidwka/sinopia

It's very much unstable right now, but seem to work good enough for us so 
far.

But a basic idea seem to be a right one: we proxy all package requests that 
haven't been found locally to a npm repository this way avoiding 
replication.



On Wednesday, July 31, 2013 8:36:33 PM UTC+4, Osher E wrote:
>
> Hi all,
>
> 'ok, this is kind'a embarrassing a little, 
> we've tried few times in few ways but still did not get it right:
>
>- we're trying to set a local npm repo for our packages 
>- we don't want to host an entire replica of the npm (which is *HUGE 
> *these 
>days, and growing)
>i.e - the private replica should hold only our packages, the rest can 
>come from the public repo
>- publishing should direct to our repo 
>- install should take our packages from our repo, and public packages 
>from the global repo
>
> What's the best way to do it?
> What's the best contemporary tutorial/doc/explanation about it on the web?
>
> Thanks...
>   Don
>

-- 
-- 
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: How to reliably get rid of (terminate) piped streams?

[Alex Kocharin]

Just open a stream using createWriteStream and wait for events without 
piping anything. If you get 'open' event, start your pipe. If you get 
'error' event, create directory and repeat.

There is no need to re-pipe anything in this use-case.

On Thursday, September 26, 2013 11:48:26 PM UTC+4, sardyh...@gmail.com 
wrote:
>
> I'm doing a file copy using fs.createReadStream & fs.createWriteStream. 
> When write stream throws an ENOENT error because destination directory 
> doesn't exist, I want to create it, and than re-create and re-pipe the 
> streams.
>
> To do that, first I need to kill & get rid of already existing streams 
> without them causing any more issues and not breaking the app. Currently, 
> I'm doing this: http://hastebin.com/qeketakofi.js
>
> Bu I don't know whether some lines inside terminate() are not redundant, 
> or whether I'm not doing something that I should. Node docs are generally 
> quite brief, leaving tons of questions unanswered :/
>
> Also, for the sake of efficiency, is it possible to just recycle the read 
> stream, and pipe it to a new write stream?
>

-- 
-- 
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: How to reliably get rid of (terminate) piped streams?

[Alex Kocharin]

> i sugest you to check the dir existence with fs.stat first. It's more 
> reliable and it's a better code style to check explicitly for expeting 
> error states, before it creates a runtime error like ENOENT.
>

It's actually less reliable because of race conditions. 

It doesn't matter very much in this particular case, but checking a temp 
file existence before opening it is a classic "never do that" example.

-- 
-- 
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: Large dataset/Response will hang server in rest service

[Alex Kocharin]

It's probably caused by buffering. Both mongodb and node.js are able to 
perform well when you're streaming data, but if you're downloading the 
entire dataset into memory, you'll easily get such issues.


On Friday, September 27, 2013 1:31:54 PM UTC+4, Luke Han wrote:
>
> Hi Experts.
> We are building a data feed rest service with node.js and 
> MongoDB/Express. The server perform very well if the query result is small. 
> But it will hang the server when the client query a large dataset, such as 
> 1m rows (already using gzip to compression). Is this caused by node.js 
> single thread design? 
> I would like to consulting you about any idea to handle this. 
> Any comments are welcome:)
> Thank you very much.
>
> Luke
>

-- 
-- 
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: Streaming asynchronous template engine

[Alex Kocharin]

When this thread started, this option didn't exist yet, but now we can just 
patch any template engine to use async interface with harmony generators. 
So I guess this question is pretty much outdated.


On Monday, September 30, 2013 12:58:37 PM UTC+4, Tim Shnaider wrote:
>
> I guess you've gone through the list here: 
> https://github.com/joyent/node/wiki/Modules#wiki-templating
>
> I had the same frustration finding a decent engine that had a syntax I 
> liked with async support.
>
> I love Swig, but it has no async support.  DustJs supports async, but it 
> has a horrible syntax, especially since my users can customise their own 
> templates.
>
> I've added async support to Swig, but it needs to be tweaked so it's more 
> integrated in the syntax, perhaps an additional parameter to {{ }} for 
> function calls e.g. {{ func(a,b,c) async }}
> My intention is to keep it in sync with Swig.
>
> https://github.com/TimNZ/swig-async
> https://github.com/paularmstrong/swig/pull/333
>
>
>
> On Thursday, May 31, 2012 12:15:46 AM UTC+12, Oliver Leics wrote:
>>
>> Hallo, 
>>
>> is dustjs[1] really the only template engine that implements rt 
>> streamed render output and supports asynchronous calls within 
>> template-functions? 
>>
>> [1] https://github.com/akdubya/dustjs 
>>
>

-- 
-- 
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: How to learn the source of nodejs

[Alex Kocharin]

> The source of nodejs is a very good meterial to learn,but how to learn? 
> Who can provide a advice,thank you.
>

Just clone github repository and start reading!

For example, I found this piece of code very inspirational:
https://github.com/joyent/node/blob/master/test/fixtures/semicolon.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] How to prevent disasters caused by the callback getting called multiple times?

[Alex Kocharin]

It's rather simple to create a wrapper that counts a number of times 
callback is called and throws when this number isn't 1. And call it like 
this:

fs.readFile('something', wrap(callback));

But you'll have to do it every time, so I don't think it's going to be used 
widely. 


On Tuesday, October 1, 2013 10:28:34 AM UTC+4, jeevan kk wrote:
>
> Mark,
>
> I agree with you that in some cases its meaningful. But I am into a huge 
> project where we use a large number of third party modules. Its not 
> practical to keep a flag everywhere and check it. I was searching for some 
> general approach which we can follow. We can't find the faulty module until 
> it lands in that edge case. And there are cases where we can ignore the 
> callback getting called multiple times. 
>
> On Tuesday, 1 October 2013 11:32:18 UTC+5:30, Mark Hahn wrote:
>>
>> The http module calls back every request.  Sometimes multiple callbacks 
>> make sense.  Are the modules you are having trouble with supposed to only 
>> return once?  If so then post a bug report. 
>>
>> I don't know what else you could do.  I guess you could set a flag when 
>> you send the callback function, clear it the first callback, and then 
>> ignore the callback after that.  I would never do this because I would be 
>> blindly ignoring a problem.
>>
>>
>> On Mon, Sep 30, 2013 at 10:17 PM, jeevan kk  wrote:
>>
>>> I am using different 3rd party modules in my project. I have seen, in 
>>> some odd situations the 3rd party module which I am using is calling the 
>>> callback multiple times. 
>>>
>>> Is there any general approach which I can follow so avoid such 
>>> situations. 
>>>
>>> -- 
>>> -- 
>>> 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.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=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+un...@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] How to prevent disasters caused by the callback getting called multiple times?

[Alex Kocharin]

> The answer depends on the reason why the callback called multiple times, 
> possible are:
> - by design
> - when multiple parallel running functions callback
>

or:

- when there's a missing return statement

like this:
function read_something(name, cb) {
fs.readFile(name, 'utf8', function(err, result) {
if (err) cb(err);
result = foo(bar(result));
cb(null, result);
});
});

I'm seeing those bugs much more frequently than I'd like to.


// alex

-- 
-- 
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.