Hi all,
I'm creating a framework for my game server, and developing the module hot
update feature.
My design is very similar to the Erlang hot update feature. Modules will be
hot updated should meet the interface:
module.exports = {
'status': data,
'version': 1.0,
'init': function() {
function removeCached(mod) {
delete require.cache[require.resolve(mod)];
}
// then
require('foo');
// ... later
removeCached('foo');
2013/8/17 Tony Huang cnwz...@gmail.com
Hi all,
I'm creating a framework for my game server, and developing the module hot
update feature.
My design
I have following query which is giving me what I want
'START user=node({userId}), other=node({otherId})',
'MATCH (user) -[rels?]- (other)',
'RETURN rels'
but I'm unable to access the object it send.I need following high
lightened object which I have no idea to access.Object is
I've had logging woes recently trying debug code with the help of different
logging frameworks.
I have several projects for which I am responsible, and these projects have
to be tested in a production-like environment (solaris on a remote server)
instead of my development environment (macbook
Very nice, thanks for this. You do good work.
On Saturday, August 17, 2013 7:52:11 AM UTC+12, Isaac Schlueter wrote:
Anyone currently on v0.10 should upgrade to this version as soon as
possible. It includes a V8 security fix for CVE-2013-2882, as well as
performance improvements and other
I've read that article too.
It seems to me that async/wait is a more elegant approach than twisting the
yield semantics.
However I don't quite see how this differs from blocking I/O calls and
threads.
These are cooperative threads, wihch were also an acceptable programming
model in the 60's
I'm on vacation this week, but decided to see how the node.js list is going.
First I want to reply to Eldar's concerns., Yes, I'm also frustrated with
streams in node.js. But, I do *not* advocate we all stop using node
streams in node modules. Isaac is right that node has reached a level of
There are a couple of issues with that.
First, if 'mod' loaded other modules to do its job, those other modules are
not removed from the cache. For example, suppose package 'foo' has main
module a.js, and that loads module b.js to do some of its work. Now if you
delete 'foo', or even a.js, from
The literal you pasted is an array of objects. You appear to be assuming
it's already the first object in that array. So if 'rels' is actually what
you pasted, you want rels[0].rels.type.
--
Martin Cooper
On Sat, Aug 17, 2013 at 2:45 AM, Jyoti Chhetri nitrous.ooox...@gmail.comwrote:
I have
@George
This is really cool! Is this a public API? Or it's just hacking into the
internal implementation of node.js?
On Sat, Aug 17, 2013 at 5:42 PM, George Stagas gsta...@gmail.com wrote:
function removeCached(mod) {
delete require.cache[require.resolve(mod)];
}
// then
@Martin
I have noticed this risk. So:
1) This will be just a limited feature used in my framework, it might go
open source, but I will never try to make this a part of node.js API. So
the risk will affect very little area.
2) I will implement it in this way:
a) Get the old exports object
@Tony
The latter. If you need more control and stability then you could roll your
own module loading/injecting system with fs, vm or eval.
2013/8/17 Tony Huang cnwz...@gmail.com
@George
This is really cool! Is this a public API? Or it's just hacking into the
internal implementation of
Your implementation is still subject to both potential issues I mentioned.
Let's suppose M is the module you are removing from the cache in (b), and
let's suppose the code for M includes the following lines:
var b = require(./b.js);
var thing = { ... };
exports.getThing = function () { return
@Martin
We could list all the hypothetical breaking cases but I don't think that's
useful. Every case is different and we should address issues that belong to
the real use case. So, until it becomes an issue it's only speculation and
leads to over-engineering and it's a waste of time and effort.
Not surprisingly, I disagree. :-) Since the OP is talking about building a
framework based on this, I believe it's important to understand the
limitations *before* committing to this approach, building the framework,
and discovering only later, when there are numerous modules written and
possibly
First to note - Coffee-Script actually *prohibits* this kind of code
organization, because all functions are necessarily assignments.
It is a myth that you have to put function definitions before the calling
code in coffee. Here is a pattern I use in all my code ...
start = - doNext()
doNext =
Hi,
Let's say I want to boost the SlowBuffer size like this:
// set to 1 Mb
Buffer.poolSize = 1024 * 1024;
Is it a good practice for boosting performance, if there is lots of memory
available?
-Laurent
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
I'm not entirely sure when support for this API was introduced, but this
works fine in my code on v0.8.25:
// create regular TCP connection
var socket = net.connect({ host: 'google.com', port: 443 });
// upgrade to TLS
socket = tls.connect({
socket: socket,
doNext()
doNext = -
ReferenceError: doNext is not defined
vs
doNext()
function doNext() {
}
On Saturday, August 17, 2013 2:47:07 PM UTC-4, Mark Hahn wrote:
First to note - Coffee-Script actually *prohibits* this kind of code
organization, because all functions are necessarily
ReferenceError: doNext is not defined
Wrong. Run it. It works great. The first two lines are just assignments.
So they are both defined when start runs.
I've gotten this exact response when I've posted this before. People
blindly believe the myth.
On Sat, Aug 17, 2013 at 1:26 PM, Andrew
Ok, I apologize for the rudeness in my tone. Let me explain what is going
on.
Your example fails not because the call is above the definition in the
file, it fails because the call happens before the definition in time.
My example has the call above the definition in the file but the definition
You didn't sound rude to me - it's fine.
I am specifically talking about calling a function before defining it.
That's the whole point. What I said holds true.
On Saturday, August 17, 2013 5:02:51 PM UTC-4, Mark Hahn wrote:
Ok, I apologize for the rudeness in my tone. Let me explain what is
The blog that the OP pointed to said that in coffeescript you can't place
the calling code higher in the file than the called function definition. He
was wrong. He ruled out coffeescript for this reason. That is incorrect
and you can code the style he is promoting in coffeescript.
I felt this
Oh, I just realized he is you. Again I hope you don't think I'm rude.
On Sat, Aug 17, 2013 at 4:12 PM, Mark Hahn m...@reevuit.com wrote:
The blog that the OP pointed to said that in coffeescript you can't place
the calling code higher in the file than the called function definition. He
was
I am familiar with bunyan and how you can add arbitrary fields to the JSON
output. The client lets you filter based on those fields, but it still has
the weakness of hiding log lines under log levels and giving you more than
you want.
Tagged logs allow you to ignore subjects you are not
I don't feel any rudeness from you. But I do feel like we're failing to
communicate. Maybe someone else can chime in?
On Saturday, August 17, 2013 7:13:53 PM UTC-4, Mark Hahn wrote:
Oh, I just realized he is you. Again I hope you don't think I'm rude.
On Sat, Aug 17, 2013 at 4:12 PM, Mark
Performance proportionally plateaus with regard to the size of the slice. Since
the average allocation is already relatively small in comparison to the size of
the pool, increase in the poolSize won't show much if any noticeable
performance gains. I wouldn't recommend making it any larger than
I do feel like we're failing to communicate
It appears so. Let me try to phrase it in two questions. If you could
give simple answers to these then we can make progress in our communication.
1) Did your blog say that because you couldn't call a function defined
below the call in
Perfect approach! I'm going to start using it, thanks!
On Saturday, August 17, 2013 2:53:26 AM UTC-3, Andrew Kelley wrote:
I wrote this article as a response to all the recent callback hate:
http://andrewkelley.me/post/js-callback-organization.html
It contains:
- Acknowledgement of
29 matches
Mail list logo
