You should see, after Ctrl-c, the script is terminated. I think you
misunderstand this 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
Yes, I always update fast :)
Is actually now a bug or a behavior to avoid recalling read when read is
actually not finished?
Bodo
Am 01.04.2013 um 05:28 schrieb Michael Jackson mjijack...@gmail.com:
Have you tried this on node version 0.10.2? There were some bugs around the
readable event
We would probably need two examples then:
* An application example to compare how the tools let you write a simple
yet non trivial application on top of existing libraries.
* A library example to test compatibility with the rest of the ecosystem.
The streamline tutorial falls in the first
Its lot to ask for a beginner to write a new database driver from scratch..
if there any tutorials related to database driver creation.
How it should be structured.
My use case is little bit easy though. I just want to do *only select
queries* on monetdb.
I have tried both odbc and ffi and
@Bruno
Thanks. I appreciate the example. That sounds like a good demo touching the
key features. Also, your delineation of lib vs app code I think is a good
one, but for now I'll be happy just to have the former. Certainly of course
the goal of this is for individuals motivated by their library of
I was trying to do the following:
1. Read a file from disk
2. Cache the results of the file
3. Use the cache if it's requested again
Everything worked fine unless I read the file multiple times before the
first read came back -- in this case, obviously the file would be read from
disk
On Apr 1, 10:54 am, Gaurav Meena gauravmeena0...@gmail.com wrote:
My use case is little bit easy though. I just want to do *only select
queries* on monetdb.
I have tried both odbc and ffi and found ffi better(or may be easy) to use.
(is odbc better then ffi?)
1. Should I not use ffi for this
Btw, you also CAN return the promise from the function you call:
function doSomethingElse(callback){
var p = promise(callback);
setTimeout(function(){
p(1,2);
}, 1000);
return p;
}
var p = doSomethingElse();
p.finish(function(a,b) { console.log(a, b); });
On Monday, April 1, 2013 11:14:07 AM
When we have been making large scale software a few things have come up.
1. Callbacks suck for linear workflows (a-b-c)
This kind of workflow results in what I like to call the mudslide.
Your code really wants to expand into some minor nesting once you have
shared state (sometimes immutable
@mikeal when I last checked a few weeks ago there where over 350 stream
modules in npm.
On Tue, Mar 26, 2013 at 9:38 PM, Isaac Schlueter i...@izs.me wrote:
You're still doing it wrong. This is like complaining that you can't
tell a stream is ended because you waited to attach an `end`
350 is a big number until you factor out the number of those written by 3
people (you, substack and Raynos). many modules might exists but, it is my
impression, that most of them are written by about a dozen people. this
impression could be wrong but i've been around since we first started
idempotentcy is a perf issue in resource starved JS
Could you expand on this?
I agree completely on your point about branching, excessive then and being
harder to read. Ultimately, it's my personal belief that given equivalent
examples people will choose what they feel is most readable (and it
Domains are useful to categorize and debug the error, even if you shutdown,
don't just throw them away.
For performance starved JS (talking working under 50MB in a production
area) idempotentcy / stateless arch generally results in memory usage or
offloading to a single authority. Single
The problem is not limited to linear block of statements and parallel
branches:
What about async calls inside if/else branches, inside loops, inside
try/catch or try/finally?
What about async calls in call chains (f1().f2().f3()), in functional
composition (f1(f2(f3()))?
What about async
Manually combining state is something I do not want to give up. Passing by
argument is my preferred method rather than introducing variables
(async.waterfall). All compiler based syntaxes I have seen give me concerns
about shared cache if multiple things are done in parallel and you use
shared
https://gist.github.com/bmeck/5287456
Feel free to spec out a reference problem set by forking and modifying.
--
--
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
Ideally, we'd keep this thread to the OP. I know it's easy to begin
discussing the merits of async vs alternative environments like streamline,
but I'd prefer to break new ground.
On Mon, Apr 1, 2013 at 12:55 PM, Bradley Meck bradley.m...@gmail.comwrote:
Manually combining state is something I
Hello Michael.
I'm one of the zeromq.node (aka zmq in npm) project collaborators.
I see you've started developing a zmq-stream on github.
I've played with it a bit and have found these
issues/drawbacks/recommendations/etc:
1) You use only the uv_timer_* functions and no uv_poll_*. Why is that?
Compared with the stuff that you needed to do with streams1, streams2
is much much easier. Basically:
1. Pick the class you're extending: Readable, Writable, Duplex, Transform
2. Implement the constructor, and one method. (Well, 2 for Duplex,
but that's to be expected.)
If you are doing a
error coalescing is listed as a major benefit of promises
None of control-flow helpers (steps, asyncs, promises, futures, tamejs,
) really helps with callbacks. None of them can intercept non-async
errors.
As far as I know it's impossible to reliably catch both sync and async
errors,
None of control-flow helpers (steps, asyncs, promises, futures, tamejs,
) really helps with callbacks.
I misspelled, sorry it should be with errors not with callbacks, i.e.
None of control-flow helpers (steps, asyncs, promises, futures, tamejs,
) really helps with errors. None of them
Hi All,
I still wonder how promises is different with function composition.
Check this library that I created, comp: https://github.com/azer/comp
It allows you create function compositions like this;
steps = comp(step1, step2, step3)
or like this;
steps =
6) Do I understand correctly that the zeromq.node could be alternatively
re-done as a thin layer on top of zmq-stream? Just create socket, subscribe
to 'readable' event, emit 'message' event with read messages. Drain and
write error code is ignored in this case.
7) Does it work well with
Thank you for your reply.
I read in github page that ffi is gives 5x times normal load (at least). So
One solution that came to my mind was to reduce ffi functions. By wrapping
my dynamic library in c program that have only one function as external
function. So by doing this:
I went from
You first have to define helps with errors. I don't know about async, but
step and promises wrap all their callbacks in try/catch and bubble errors
automatically. Stepdown uses my async trycatch library, which before I
switched to domains in 0.2, would wrap every callback to core in a
try/catch
25 matches
Mail list logo
