Re: [nodejs] Running nodejs on Windows
Hi, https://lh3.googleusercontent.com/-ZSIaQfwoFQ0/Us7BG2zVqDI/Alg/bn8m0r7lRbM/s1600/1output.PNG That's not nodejs; it's this: http://technet.microsoft.com/en-us/library/cc947691.aspx I guess you need to edit your path so that it finds nodejs before that. Paddy -- -- 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] [Poll/RFC] Remove the built-in debugger
Hi The built-in debugger is a major pain to keep working and some informal polling suggests that no one really uses it or is even aware that it exists. I'm toying with the idea of dropping it altogether and replacing it with some hooks for projects like node-inspector and node-webkit-agent because that's what everyone seems to be using anyway. Before I go ahead, I would like to know whether there are people out there that would be negatively affected by such a change. If you are or if you disagree with the approach outlined above for other reasons, now is the time to speak up! :-) Presumably this will kill the IntelliJ IDE ( http://www.jetbrains.com/idea/features/nodejs.html) ? I don't know how widely used it is, but it is the most effective debug setup I've used with node. Thanks - Paddy -- -- 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] [Poll/RFC] Remove the built-in debugger
Hi, I'm fairly sure it talks to V8 directly. As long as --debug-brk keeps working, there should be no issue. Ditto for node-inspector and friends. Yes it does talk V8 directly but it sounded as if perhaps you were planning to disable the option. Thanks - Paddy -- -- 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] node 0.10.1 failed compiling with Xcode and LLVM (debug-support.cc is missing)
Hi, I've tried this change: https://github.com/paddybyers/node/commit/ab8ca2779c0a767063ff4af6097e40e1d2207e4e which seems to make things build ok on xcode. ... but broke the make build :( I think this works: https://github.com/paddybyers/node/commit/9efd361ca5510cca92365ee6471e75b6d3091e98 Paddy -- -- 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] node 0.10.1 failed compiling with Xcode and LLVM (debug-support.cc is missing)
Hi,
the build process finishes successfully by using make. Mhm… strange. Does
anyone other have a hint?
I looked at this tonight.
The issue is that node's gyp configuration enables 'v8_postmortem_support'
but this creates a dependency on debug-support.cc. The v8 gyp file has a
target ('postmortem-metadata') to create that, but that target isn't a
dependency of anything else, either in node or in v8 itself. I suppose the
v8 view of the world is that you need to have something explicitly depend
on that target or build that target - it doesn't implicitly become a
dependency, according to v8.gyp, when you enable 'v8_postmortem_support'.
The reason it works with make is that the gyp make output automatically
makes 'all' the default target, which depends on all other targets, so
'postmortem-metadata' is built by default, simply by being a dependency of
all.
I've tried this change:
https://github.com/paddybyers/node/commit/ab8ca2779c0a767063ff4af6097e40e1d2207e4e
which seems to make things build ok on xcode.
Paddy
--
--
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] about running node.js v0.8.x on Android / iOS / WP8
Hi, Is there any successful story porting node.js v0.8.x to mobile device, like Android, iOS or WP8? I've not been able to spend any time on 0.8 on Android yet. Andreas Botsikas a...@epu.ntua.gr has been experimenting with a port running on iOS. The current Android port also runs on Firefox OS if anyone's interested. Paddy -- -- 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] node js on android OS, I'm looking for new solutions
Hi, i want to run node js \ v8 like any other android app. just download apk and run. but in this case we'll never have direct access to the hardware. and if we root the device then we'll have some other problems. i'd like to make it simple and safe as possible for the end user. so we need some native Android app to stand between node.js and android OS like a hardware driver but i can't find any good project that do just that. so i'd love to see your opinion about it. thanks Have you looked at https://github.com/paddybyers/anode ? Paddy -- 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] Poll for v0.10 feature: Crypto default to 'binary' strings vs defaulting to buffers
Hi, a) Go for it. This won't affect me, and if by chance it does, I don't mind putting 'binary' args here and there. I definitely support (a). Might I make a plea also for a proper X509Certificate class to be supported in addition to PEM and other encodings of certificates in the factory methods for Credentials, Signer and Verifier? We have a glimpse of a certificate class in the tls module with cleartextStream.getPeerCertificate(); but this is the only place in the API where fields of a certificate are exposed. There are also use-cases in signing and verifying where you want to know about certificate details, and details also about non-trivial certificate paths that were constructed in the course of verifying a signature. An example would be knowing whether or not your validated path qualifies as a valid EV path, or verifying the signature on in an XML signature document. I know the argument is always that this functionality can go in user land in an independent module, instead of in core; and there are modules that do some of this such as dcrypt [1]. The problem is that when you do that you have to re-implement all of the core functionality as well on top of your external certificate library, just because you're unable to pass a certificate object into the APIs in the core. So my suggestion would be to include X509Certificate and X509CRL classes that wrap native OpenSSL X509 structures, and for these to be supported as well as strings in the relevant APIs. Once that is in place, I think the more esoteric use cases can be supported in userland without lots of duplication of code. I'm happy to contribute to the work, and some time ago started implementing support for this [2] based on dcrypt. You can see from the amount of code in there that's simply cut+paste from core that it really would be a fairly modest delta; much of the functionality is already there, but disorganised. Thanks - Paddy [1]: https://github.com/dekz/dcrypt [2]: https://github.com/paddybyers/dcrypt -- 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] Crypto Module: Convert Java snippet to node.js
Hi, The 1 + is not importent, we only need to add this. My problem is that the encryptedHexNumber is not the same as in the Java Snippet These two programs give the same output for me, for input strings that are a multiple of 16 bytes in length when utf8-encoded: https://gist.github.com/3782869 If using input strings that encode to other lengths, then the java code will throw an exception. Note that in the node case the encrypted text that matches the java output is the result of the update call, not the final call. I'm not sure if that's the expected result for CBC mode or not. Paddy -- 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: Threading, and Dogmatisms.
Rektide, I still am very much interested in technical discussion around this feature, know it abstractly but not deeply, and the cause of it being shelved remains shrouded in mystery. I made an independent effort to implement isolates - in the sense of multiple node instances in a process, not TAGG - before the isolates effort by the core team. I wasn't privy to the discussion that led to the decision to remove the isolates feature, but I can give an overview of what I think the issues are in getting that feature implemented, stable and usable in practice. Before diving in, I should say that this feature really is very different from TAGG, although they share the same underpinnings in terms of the v8 features used. Nonetheless, it is certainly confusing the whole discussion for them to be put into the same bucket. My own use-case and constraints were quite specific, but the general motivations, as others have commented, were the possibility of: - lower cost of message-passing between instances, avoiding a data copy. Nobody imagined, realistically, that passing object references from one instance to another was possible, but copies of primitive datatypes, buffers and serialised objects could in principle be enabled between instances in the same process; - reduced context-switch times; - reduced instance start-up time; - miscellaneous reduced overheads from sharing of resources such as libev thread pool, fds, or whatever. There's a summary of a number of implementation issues in this issue: https://github.com/paddybyers/node/issues/16. The core team's implementation followed a similar path although there were differences in detail. All of this sounds quite achievable, and there's no reason why this set of features cannot be completed and stabilised with a lot of careful attention to detail. Don't underestimate the effort needed, and the time it will take to iron out all thread-insecurity problems with existing code, but possible. However, that's only really the beginning. Once you've done this you confront three sets of issues: 1) Lots of expected behaviours simply aren't achievable. This includes state that is shared that people expect not to be shared: process.cwd(), process.env, process.setuid(); now you have to study your app - and reverse-engineer the modules you're using - to understand where these differences in behaviour will affect you. Child_process, SIGCHLD handling, and signal handling generally cannot be implemented completely faithfully. This is all OK if you're prepared to define, document, and accommodate the changed semantics, but it's a huge effort to migrate all existing code to a new set of assumptions - and only worthwhile if there's a big payoff. 2) Existing native modules now operate in quite a different regime, and all existing modules will be broken. When there is only a single v8 isolate you know it's OK to keep v8 handles in statics. You can also get away with being a bit lazy and/or buggy in the way you release native resources. None of that is possible when you have isolates; you need to track and release every resource explicitly and exactly, and you have to have a way of putting your object handles into thread-local storage or some other isolate-wide structure. Every single native module will fail when you use it in the second isolate in a process, which means that every single real-world app that uses a number of such modules will fail in unexpected ways. The maintainers of those modules might not have an interest in your use-case and that's a real barrier to getting any high-quality migration to the new regime. 3) The compelling performance gains you had as motivation for doing any of this are marginal at best. In fact, since you're now using thread-local storage to get context throughout the codebase, it's potentially slower most of the time. The shared memory that you thought was going to be the performance win turns out to be the thing that kills you, and you realise how powerful process separation, with the hardware assistance it gives you, really is. More or less every place you thought of using shared memory - and where it's a practical bottleneck - there's a way of getting pretty much the same thing between processes using shared memory or whatever. Add these things to be backdrop of having other pressing reasons to get v0.8 out, and you can see why the decision was made to abort the development. I'm sure the decision wasn't taken lightly given the effort that had been sunk into it. My own use-case for isolates still remains, however, and I do intend to migrate the work I did to v0.8+. I'm optimistic that the performance degradation from thread-local storage can be kept well below the 2-8% that Ben stated, and can be made negligible in the case that you only ever use a single default isolate. But that's speculation at the moment. Please don't take any of the comments above to apply to TAGG, and I'm not commenting, either positively or negatively,
Re: [nodejs] psutil library for node
Hi, I would really really appreciate it if anyone could shed some light on the problem as I've pretty much wasted a couple of days trying to figure out and I'm sure it's something stupid I've forgot to add in the gyp file. If you disambiguate all references to Handle as v8::Handle then it builds for me, on Debian and Darwin. I guess there is a conflict with a definition in one of the various things you're including. See https://github.com/paddybyers/node-psutil/commit/7e77d53e295e830334d862edbac3f93dca76 Paddy -- 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] app startup woes and raceconditions galore
Hi,
I just noticed a problem in my code after upgrading to 0.8.0. Isolating the
bug got me to this minimal repro-case:
var LISTENPORT = 8081;
var connect = require('connect');
// this does not work:
/* var app = connect().use(connect.static('public-html'));
app.listen(LISTENPORT);
*/
// but this works (!)
var app = connect().use(connect.static('public-html')).listen(8081);
Isn't it because in the second case, you're assigning app to the result of
the listen() call, and not to the app?
Paddy
--
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: [node-dev] about porting node.js on Android
Hi, Is there any story try to build node.js on Android? Yes, see here: https://github.com/paddybyers/node https://github.com/paddybyers/anode Paddy
Re: [node-dev] Re: process.nextTick semantics
Hi, Here's my input, FWIW: The use cases provided in opposition to this change are very bad ideas. In all of the cases presented, what you actually want is either a separate thread of execution or an idle listener; *not* a maximum-priority scheduled task in the current thread. People sometimes use setTimeout(fn,0) in the browser for CPU-intensive operations, **because there is no other choice**, but even in those cases, it's better to use WebWorkers instead, now that they are pretty widely supported. I think this is too simplistic a view. The issue isn't that people are doing compute-intensive tasks like calculating fibonacci numbers; they are processing application state, which involve collections of indefinite size, and this state is necessarily in the current isolate. The work can't be offloaded into a child process. There is a legitimate need, IMO, to be able to perform some processing on those indefinitely-size collections without stalling the event loop for an indefinite time - even if that time is only an unbounded number of microseconds, so to speak. This requires some way of scheduling some work to be done, after completion of the current work, without preempting the handling of (IO and other) events that have occurred during the processing of the current work. The bugs we're seeing in node-core are not just in node-core. Any library that uses nextTick for its *intended purpose*, to defer execution until after the current run-to-completion, but before normal-priority IO events have a chance to fire, will find that they have the same sporadic bugs at scale. This is clearly a fatal problem that needs to be fixed. The real source of this problem is that the concept of a tick is pretty loosely defined in Node, and not very well understood. As a result, a lot of people have come up with their own (mostly wrong) beliefs about how it works, and have built libraries around those beliefs. The semantics are too complicated to get right all the time, and we're seeing the results of that. Quite. Of all of the unfortunate things about nextTick, the name is the most unfortunate. The word 'tick' implies that there is some periodic time interval, and nextTick defers things until that time interval has elapsed. Anyone sensible encountering it for the first time will surely know that it would be insane for things to work that way, so he must then conclude that he has no clue about what it *actually* does; and as we know the docs don't help. If we had a clean sheet of paper - which we don't, of course - then none of the APIs would have the word 'tick' in them because it can only be misleading. So, it seems to me we do need: a) process_before_already_scheduled_events - to address the main use-case, which is Isaac's proposed behaviour for nextTick; b) schedule_after_already_scheduled_events - to address the use case of being able to schedule work in parcels that would otherwise preempt event processing for unbounded time. (a) is a critical need, and the official purpose of nextTick, so its current behaviour is broken and it needs fixing to behave this way. There is an option to introduce a new more meaningful name and deprecate nextTick; but even then nextTick is obviously never going to go away, so it just needs to be very carefully documented and the name explained as an unfortunate artifact of history. (b) I believe is a genuine need and hopefully we can think of a good name for it, and implement it. Paddy
Re: [node-dev] Re: process.nextTick semantics
Hi, If a collection is of indefinite size then it should not be loaded entirely in to memory in order to accomplish computation, it should be streamed. In the case of streaming the collection you can iteratively perform the computation without locking up the process indefinitely and without taking on a large memory footprint of either the original collection or even what has already been processed. Yes, you stream application data in and out of your application. But I'm talking about application state, such as anything you have on a per-connection or per-token basis, for example. It's in memory because it's your application, not your application's data. Thanks - Paddy
Re: [nodejs] Identify object type across vm
Hi, how do i identify ctx.date1 is a date object in the current vm ? Object.prototype.toString.call(ctx.date1) == '[object Date]' Paddy -- 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] running npm project as node program
Hi,
I *conceptually* want to do this ...
npm install wonder-app
node wonder-app
In other words I want to distribute the complete app ready to run via npm.
What is the easiest way to do this?
What about:
npm install wonder-app
node --eval require('wonder-app')()
?
Paddy
--
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] Unsigned integers and Int64 in node.js
Hi, I've implemented a binary based protocol in node.js, and I need a Int64 to present the id of the messages. What library should I use to represent unsigned integers as well as UInt64s? I've taken a look at the node-int64 module, but it doesn't support any calculation which is necessary in my case to decode a compressed int64. Have you looked at Protocol Buffers? Javascript isn't one of their officially supported languages but there is an independent implementation for javascript which includes an implementation of their I64 type: https://github.com/sirikata/protojs/blob/master/protobuf.js#L114 They have a variable-length wire encoding (base 128) for these as well. I'm doing someone a bit similar for thrift's int64 type so I'm happy to contribute to a joint effort. What kinds of calculation do you want to do? Paddy -- 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] How to detect and diagnose event-loop blocking?
Hi,
Any recommendations for the following would be much appreciated:
1. Monitor the 'health' of the NodeJS event loop, to know 'how big the
problem is' – any extended blocking of the event loop is a Bad Thing, so
seems a Good Practice to detect when blocking happens.
As a very simple health-check, do the following:
function timeTick() {
var startTime = (new Date().getTime());
function onTick() {
var interval = (new Date().getTime()) - startTime;
if(interval 5)
console.log('timeTick(): WARNING: interval = ' + interval);
}
process.nextTick(onTick);
}
setInterval(timeTick, 1000);
This simply sets up a periodic timer that checks the interval between one
tick and the next. Set the threshold (5 above) to be a value that
represents the kind of latency that you consider problematic for your app.
It doesn't tell you what's causing the problem but you'll quickly get an
idea of what circumstances are triggering a problem.
Paddy
--
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: Embedding Node?
Hi, This can be easy or hard depending on what you want your app to do. If you are simply re-branding the node executable, in the sense that your app will just enter the node event loop and stay there until the app exits, then you could either include the node source into your app project directly, or link to a separate library built from the node source. If, however, your app is going to be doing something else and you plan just to use node as a library - ie to spawn a node instance from time to time as your app runs, returning results back to the app - then you can't do that directly. To make that work with multiple node instances in the lifetime of your app - whether serially or concurrrently - then you need to use isolates. Since isolates are no longer part of 0.7/0.8, there's no 'off-the-shelf' way to do this. I have a fork that does build a library you can use in this way, and I'm currently trying to decide the best way to maintain this now that we don't have isolates as part of the official roadmap. Paddy -- 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
