wait.for.function parameter must be a function that takes an async
callback. Try changing function a to:
function a(cb) {
console.log(hello);
process.nextTick(cb);
}
wait-for-stuff polls the event loop. This is a hack (see the deasync README
Node-RED?
https://nodered.org/
On Sunday, August 20, 2017 at 11:35:08 PM UTC+2, Aditya Manay wrote:
>
> Any successful working npms for node workflow project
--
Job board: http://jobs.nodejs.org/
New group rules:
https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group
Callbacks are asynchronous! They are called after your function returns.
The sequence is:
enter login function
con.execQuery initiates query
return from login function (result variable is still empty array)
later:
node event loop invokes the callback
rows is assigned to result variable (too
JavaScript has classes now. You should take a look at EcmaScript 6
classes: http://exploringjs.com/es6/ch_classes.html
On Thursday, November 17, 2016 at 2:17:20 AM UTC+1, An Nguyễn wrote:
>
> Hi all,
> When developing my web application, I need inheritance and other features
> of OOP. I tried
Did you try nodemailer?
https://github.com/nodemailer/nodemailer
On Friday, September 23, 2016 at 6:14:21 PM UTC+2, King Mhar Bayato wrote:
>
> Hi,
>
> I'm new to nodejs, It's very hard for me to find a new guides on how to
> this. Please help me :)
>
> Thank you in advance
>
--
Job board:
Microsoft's edge library may help you: http://tjanczuk.github.io/edge/#/
On Thursday, February 18, 2016 at 6:38:25 AM UTC+1, Sudhir Goswami wrote:
>
> Hi Geeks,
>
> I have library which contains some methods and property written in C#
> Language ,I want to access those methods from Node.js?
>
>
Google for GLIBC_2.14 not found
Looks like you need to install libc6
On Friday, July 17, 2015 at 6:34:28 AM UTC+2, Reynier Pérez wrote:
I am trying to build an app using `grunt build` and I got this error:
# grunt build
Running clean:dist (clean) task
Running wiredep:app
As you wrote it Tokens.create will not return your token; it will return
undefined! The return token statement is inside the callback, not inside
Tokens.create.
To make this work you have to turn Tokens.create into an async function and
call it with a callback:
Tokens.create(function(ex,
You should take a look at https://github.com/Sage/streamlinejs
Same basic idea but it goes beyond simple sequencing of async calls; it
handles async calls in every JS construct.
Also, async/await is being considered for ES7 and there are already some
polyfills that implement it with
FWIW ez-streams lets you handle it with a single read.parse.reduce chain:
var ez = require('ez-streams');
function analyze(filename, callback) {
ez.devices.file.text.reader(filename)
.transform(ez.transforms.lines())
.reduce(callback, function(cb, result, line) {
Hi Jordan,
This is really cool. We are currently using the node-oracle driver but we
are definitely going to take a very serious look at the official driver.
Bruno
On Tuesday, January 27, 2015 at 9:26:09 PM UTC+1, Jordan Kasper wrote:
Still pretty fresh, but Oracle just released their
Yes. You can create an HTTP service or a socket (tcp/ip) service on the
node.js side, and call it from Java.
I'm replying in English because this is an English mailing list.
Bruno
On Sunday, February 15, 2015 at 7:13:43 PM UTC+1, mima yola wrote:
svp j'aimerais savoir s'il est possible
You don't need threads for this. With node's async model you can handle
many requests efficiently on a single thread. Requests spend most of their
time doing I/O. While they are doing I/O, other requests can pop in and be
serviced.
On Sunday, February 15, 2015 at 6:59:43 PM UTC+1, mima yola
Your control flow is wrong. I've added a few console.log in your code
below. Output should be:
BEFORE FIND
BEFORE DB FOREACH
AFTER FIND
DB FOREACH CALLBACK
AFTER CURRDATA ASSIGNMENT
This should explain why currData is still undefined after the find call.
Bruno
On Wednesday, February 4, 2015
TJ Fontaine did a bit of experimentation with node-tracing, and Forrest
Norvell made CLS. Trevor Norris had also created AsyncListener to track
changes between async contexts. But all the approaches so far have been too
naive or simplistic and ultimately flawed.
Isn't this a bit of a
Hi Andreas,
My little contribution to the
topic: https://github.com/Sage/streamline-flamegraph. It does not depend on
an external service but it assumes that you are writing your code with
streamline.js.
The cool feature is that it gives you insights into your long stack
traces and it
Mark,
sync XHR may be a bandaid solution but I think that it should really be a
last resort.
For info, vim has been ported to the browser by Lu Wang. The challenge was
similar to yours because the implementation uses blocking calls to read
from the terminal. The challenge was even higher
Hi Mark,
It is possible but the solution is too inefficient to be usable.
See
http://smellegantcode.wordpress.com/2012/12/28/a-pure-library-approach-to-asyncawait-in-standard-javascript/
Bruno
On Friday, October 24, 2014 6:44:41 AM UTC+2, Mark Hahn wrote:
I've been following async to sync
What's V9?
One of the design choices of node.js is to keep the core small and let
user-land packages do the things that only some people need. I don't need
Canvas rendering server side (at least not yet). So it's better for me, and
probably for lots of others, that this feature is not bundled.
(_, ez.devices.console.log);
It will handle the backpressure on the child process standard output.
Bruno
On Thursday, October 9, 2014 9:27:05 PM UTC+2, Bruno Jouhier wrote:
Hi Aseem,
You could use ez-streams 's ez.devices.file.list(path) function. It will
give you a stream of file names over
Your problem seems to originate from node-weak.
With normal node modules, the code that gets executed during one turn of
the event loop is 100% related to the JS calls that you are making in the
response to the event. Nothing interferes. If other I/O operations are
pending they won't interfere
Looks like node-weak should use a different mechanism to invoke the
callback. It should call the function directly instead of going through
MakeCallback.
On Friday, October 10, 2014 9:00:18 PM UTC+2, Matt Ginzton wrote:
Yeah, I know (and hopefully anyone using node-weak knows) that the
Hi Aseem,
You could use ez-streams 's ez.devices.file.list(path) function. It will
give you a stream of file names over a directory tree. Unfortunately it
won't really stream over the content of a single dir because there is no
native API to support this (it will just do virtual streaming over
Though, as someone very familiar with the pitfalls of Javascript, and very
unfamiliar with streamline, I'd have to look at the generated code to
assure myself that's actually doing what I think I want it to, as I could
imagine many ways in which that code could be converted to raw
http://www.ckwop.me.uk/Why-Exceptions-Suck.html
Checked exceptions are certainly better than unchecked exceptions !!!
Java had checked exception but its successors (C#) removed this feature.
The designers of Java libraries have moved away from checked exceptions too
(the presence of
; you can catch globally.
Bruno
On Monday, September 22, 2014 3:18:40 AM UTC+2, Matt Sergeant wrote:
On Sat, Sep 20, 2014 at 9:17 AM, Bruno Jouhier bjou...@gmail.com
javascript: wrote:
How do you implement it with async?
This is a good question, so here's an example translation
As usual, when this topic comes to the mailing list, there is a lot of
talking and very little facts. Let's come back to the OP's code (and fix it
a bit so that it also works when the path is *not* a symlink.
Here is how I implement it with streamline.js and express-streamline:
:26:32 PM UTC+2, manwood wrote:
Bruno - interesting, do you have any blogs, or can you give me any detail
on how you're using it? Where does it fit in your architecture?
Thanks
On Wednesday, September 17, 2014 10:50:08 PM UTC+1, Bruno Jouhier wrote:
We (Sage) have been using node.js
We (Sage) have been using node.js heavily in the new version of our mid
market ERP product (Sage ERP X3 V7). This is not large enterprise, rather
mid-market but the fact that node has been chosen by an ERP vendor may help
you sell your story.
Bruno
On Tuesday, September 16, 2014 11:21:25 PM
Plenty of tools have been developed to solve this problem.
See
http://spion.github.io/posts/analysis-generators-and-other-async-patterns-node.html
for a comparison.
Here is how I write your example (handling the else clause of your if test
BTW):
CDN.use(config.CDN.baseUrl, function(req,
On Monday, September 15, 2014 2:51:17 AM UTC+2, Rick Waldron wrote:
On Sat, Sep 13, 2014 at 9:46 AM, Bruno Jouhier bjou...@gmail.com
javascript: wrote:
Generators have a * because it is sometimes desirable to be able to
create a generator that does not yield. Consider the following
Can you create an issue in the node-oracle GitHub repo with more details:
your source code, the error that you are getting (with stack trace). We'll
follow up from there.
Bruno
On Monday, August 25, 2014 12:22:11 PM UTC+2, mamatha medepalli wrote:
hi all,
For sample ,you can refer to
If you ever dreamed of an X-ray of your execution stacks, with complete
async stacks (long stack traces) and optional I/O wait times, take a look
at this: https://github.com/Sage/streamline-flamegraph.
Bruno
--
Job board: http://jobs.nodejs.org/
New group rules:
Hi Santiago,
This is very similar to the starting point of my ez-streams library. The
difference is that I'm passing an error parameter to the callback and that I
called the method read rather than next.
Next step is to treat it as a monad and decorate it with an array-like API (but
async)
No need for an object sentinel. Undefined is good enough. Allowing undefined
values in streams is looking for trouble as they don't even serialize to JSON.
Otherwise streams API is way too complex and should be redesigned with simple
continuation callbacks: data = read(cb).
--
Job board:
Hi TJ. Your post did go through but the mailing list is now moderated. It
prevents flame wars but it also means long delays, especially when posting
from Europe.
Bruno
On Monday, July 7, 2014 6:28:57 AM UTC+2, tjholowaychuk wrote:
Weird apparently what I posted didn't work. Anyway I think
I reacted on my blog:
https://bjouhier.wordpress.com/2014/07/05/tj-leaving-node-js/
On Friday, July 4, 2014 5:40:25 PM UTC+2, vitor.sh...@gmail.com wrote:
TJ is leaving node as he posted here
https://medium.com/code-adventures/4ba9e7f3e52b
What do you think about it and what projects are
Hi Glenn,
We use https://github.com/joeferner/node-oracle. This is just a low level
wrapper around Oracle's instant client.
It works well under normal conditions but exceptions can sometimes cause
problems (see https://github.com/joyent/node/issues/6463 and
Looks like oboe is built around clarinet. So performance must be similar.
Oboe can parse JSON on the server and in the browser. C++ gives i-json an
edge on the server side. On the browser side, you can use i-json's JS
fallback implementation. Not as fast but still faster than clarinet in my
, 2014 4:05:58 AM UTC+2, Nuno Job wrote:
why is it different from clarinet or jsonparse[1]?
for what class of application is the difference meaningful?
would be happy to refer to this in the clarinet readme,
nuno
On Sun, Jun 1, 2014 at 12:27 PM, Bruno Jouhier bjou...@gmail.com
javascript
time
used by JSON.parse.
Bruno
On Sunday, June 1, 2014 5:36:01 AM UTC+2, Alex Yaroshevich wrote:
Hi Bruno!
Did you tried to write it on C or Go?
On Saturday, May 31, 2014 3:12:13 AM UTC+4, Bruno Jouhier wrote:
I just released a first version of i-json, a fast incremental JSON
parser
I just released a first version of i-json, a fast incremental JSON parser:
https://github.com/bjouhier/i-json
Main features:
- It is FAST :-), but still slower than JSON.parse :-(. On my bench
(parsing a realistic 8 MB JSON file), it comes out as only 60% slower than
JSON.parse. In
to dramatically reduce
code size (we got rid of lots of Java layers).
@Paolo. This is cool. I'll put you in contact with our channel guys.
Bruno
On Thursday, May 15, 2014 1:35:52 AM UTC+2, Bruno Jouhier wrote:
Today was a special day for our RD team. Sage launched version 7 of Sage
ERP X3, our flagship
to stop the video, and the
autostart is normal because this is not the main page, you get there by
following a link with a little movie icon. So I don't really know what to
report to our webmaster here. I think they did a pretty good job.
Bruno
On Thursday, May 15, 2014 12:35:52 AM UTC+1, Bruno
Today was a special day for our RD team. Sage launched version 7 of Sage
ERP X3, our flagship ERP offering for mid-market businesses:
http://www.sageerpx3.com/#/video/2/Discover-Sage-ERP-X3-version-7/
This version is a major technology revamp of our product: a complete
refresh of all client
Also, you should test the err parameter at the beginning of every callback,
and do something if it is not null: log it, throw it, pass it to an another
callback, etc. Don't ignore it.
Bruno
On Tuesday, May 6, 2014 7:34:51 AM UTC+2, Folivi Fofo wrote:
Thanks to all for your replies,
You have 2 entries in your array and each entry is an object with 7
properties (Periodo, Total, etc.).
The entries are in the same order. This is what really matters.
The properties of the individual entries are in a different order. Why does
it matter?
Note that V8 does not always enumerate
Did you look at edge.js?
http://www.infoq.com/articles/the_edge_of_net_and_node
On Sunday, April 27, 2014 10:10:44 AM UTC+2, Joseph Baiden wrote:
Hi All,
I have a work-related project to develop an application using NodeJS. This
application needs to capture data and use wrapper classes
On Thursday, April 24, 2014 10:11:21 AM UTC+2, Floby wrote:
It seems to me that `yield` instructions block the same way that `wait`
blocks with thread or processes. async/wait is more or less threading
(cooperative threading).
Yes. The main difference is that you know where yield will
Tim, your historical perspective is great. I got involved later than you,
in 2010, a couple months before Ryan decided to drop promises and go with
callbacks. So in our project, we did start with promises, then we went back
to callbacks for a few months, and then to streamline.
I noticed one
We are interested too!
On Thursday, April 24, 2014 8:01:08 PM UTC+2, Raymond Feng wrote:
The MS SQL connector is coming soon :-)
On Thursday, April 24, 2014 10:34:47 AM UTC-7, Will Hoover wrote:
Excellent! Great Job!
Any plans for MS SQL connector support in the near future?
. As Tomek said, using Edge to talk to
SQL is rock solid and yields the best possible performance (IMO).
I am not sure it works yet on the mono side (thought it may), but I
imagine if it doesn't that's a shorter term issue.
On Sat, Apr 19, 2014 at 2:57 AM, Bruno Jouhier bjou...@gmail.comjavascript
On Friday, April 18, 2014 8:54:10 PM UTC+2, Aria Stewart wrote:
Exactly: Promises give you something else, without being ‘sync’-style.
They let you manipulate as-yet-unavailable values relatively transparently.
Actual order of operations can be factored out instead of made explicit;
Hit the wrong key too quickly. The end of the sentence is when it can all
be done with what we already have.
On Saturday, April 19, 2014 11:33:10 AM UTC+2, Bruno Jouhier wrote:
On Friday, April 18, 2014 8:54:10 PM UTC+2, Aria Stewart wrote:
Exactly: Promises give you something else
I probably sounded a bit weird yesterday. A quick explanation: I've been
advertising a bit loudly for my own solution on this mailing list some time
ago. I'm trying to be a bit more discrete these days.
But just for the fun of it, I'll do it one more time. Here is what your
last example
margin (~3x) compared to the
next alternative. Ping @danpolivy for details.
On Friday, April 18, 2014 11:24:56 AM UTC-7, Bruno Jouhier wrote:
Just looked at the official driver project (
https://github.com/Azure/node-sqlserver) and was very disappointed to
see that it has not been updated
Floby, some quick remarks/corrections:
- streams and pipes are a high level concept. They don't really help
with sync-style in low level code (dealing with sequence of calls,
conditionals, loops, exception handling, etc.)
- fibers don't need any special version of node. Fibers is a
On Friday, April 18, 2014 9:33:00 AM UTC+2, willem dhaeseleer wrote:
What galaxy demonstrates is that generators are sufficient. You can do all
you want with generators, you don't need promises (or any other
abstraction) around them.
In the node.js ecosystem any other async function is a
On Friday, April 18, 2014 2:46:29 PM UTC+2, willem dhaeseleer wrote:
// async
I think that is very verbose, It will not be very helpful to someone who
doesn't know galaxy well or even does know coroutines. ( is it a coroutine,
is it a generator ? its both ! )
If your APIs return
Just looked at the official driver project
(https://github.com/Azure/node-sqlserver) and was very disappointed to see
that it has not been updated for more than 1 year.
Tedious (https://github.com/pekim/tedious) seems to be the only really
active project. Is this the right?
Anyone willing to
a(_);
b(_);
c(_);
Bruno
On Friday, April 18, 2014 8:52:16 PM UTC+2, Kevin Burton wrote:
Alex, I think in this case I need to. I have about 20 functions to
execute, each of which depends on the side-effects of the previous
function. I can basically make it synchronous by making what looks
On Friday, April 18, 2014 9:08:04 PM UTC+2, // ravi wrote:
On Apr 18, 2014, at 2:52 PM, Kevin Burton
ronald.ke...@gmail.comjavascript:
wrote:
Alex, I think in this case I need to. I have about 20 functions to
execute, each of which depends on the side-effects of the previous
On Friday, April 18, 2014 10:19:30 PM UTC+2, Ben Noordhuis wrote:
On Fri, Apr 18, 2014 at 8:24 PM, Bruno Jouhier
bjou...@gmail.comjavascript:
wrote:
Just looked at the official driver project
(https://github.com/Azure/node-sqlserver) and was very disappointed to
see
that it has not been
PM UTC-5, Bruno Jouhier wrote:
a(_);
b(_);
c(_);
Bruno
On Friday, April 18, 2014 8:52:16 PM UTC+2, Kevin Burton wrote:
Alex, I think in this case I need to. I have about 20 functions to
execute, each of which depends on the side-effects of the previous
function. I can basically make
javascript:
2014-04-18 18:44 GMT-03:00 Bruno Jouhier bjou...@gmail.com javascript:
:
Thanks Ben,
I took a look at it before asking and I was wondering how people can use
it to stream the rows returned by very large queries. The callback API is
unhelpful for this and I did not see any pause/resume
Found some bench figures here:
https://github.com/patriksimek/node-mssql/issues/15. Looks like C++ driver
is the fastest.
Bruno
On Saturday, April 19, 2014 12:13:46 AM UTC+2, Bruno Jouhier wrote:
Thanks Alejandro.
What if your query returns zillions of rows (and you really want them all
Easy!
var ez = require('ez-streams');
var reader = ez.devices.file.text.reader('mystuff.txt')
.transform(ez.transforms.lines.parser());
// now you can use reader.read(cb) to read one line at a time.
You can also apply further transforms, filter, map, etc. For example:
reader =
http://heartbleed.com/
It looks very serious. Is node impacted?
--
--
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
Cool. Thanks.
On Tuesday, April 8, 2014 11:49:23 AM UTC+2, 3rdEden wrote:
https://twitter.com/nodejs/status/453298698714230784
A.K.A. — Nope
On Tuesday 8 April 2014 at 11:48, Bruno Jouhier wrote:
http://heartbleed.com/
It looks very serious. Is node impacted?
--
--
Job Board
UTC-7, Bruno Jouhier wrote:
That's cool but if I understand well calls to EMS are blocking: they
wait on state transitions that get triggered by the processes that you
forked (the EMStranitionFEtag calls in ems.cpp). So EMS will let you
speed up computations by running them in parallel
to implement callbacks in EMS, if you have
any ideas please let me know!
-J
On Thursday, April 3, 2014 10:23:35 AM UTC-7, Bruno Jouhier wrote:
That's cool but if I understand well calls to EMS are blocking: they wait
on state transitions that get triggered by the processes
I created an issue for the callback based API:
https://github.com/SyntheticSemantics/ems/issues/1
We can discuss the details there.
Bruno
On Saturday, April 5, 2014 12:04:28 AM UTC+2, Bruno Jouhier wrote:
Hi Jace,
What you call threads are actually processes because the fork call
creates
That's cool but if I understand well calls to EMS are blocking: they wait
on state transitions that get triggered by the processes that you forked
(the EMStranitionFEtag calls in ems.cpp). So EMS will let you speed up
computations by running them in parallel on forked processes but your main
I have all sorts of data pumps running between JSON files, mongo, mysql and
oracle. Memory usage is completely flat (I actually used it to debug memory
leaks in the Oracle driver).
The pumps are built with https://github.com/Sage/ez-streams
For example JSON to mongo:
var ez =
Hi Bob,
setPrefetchRowCount(50) is only a hint. It tells the driver to fetch 50
records at a time instead of fetching them 1 by 1. It should only impact
performance, not the actual result set that you get.
I saw your message on GitHub. I added the reader API to the driver and I
may be able to
Thanks Bob. I'll enjoy for sure. Beach time :-)
The oracle driver is used by a smaller community than some other drivers
(mongodb for ex) so you are more likely to run into bugs, and maybe
platform specific bugs too because it is implemented with a binary module.
Don't hesitate to report the
There are plenty of solutions that let you program node in sync-style with
robust exception handling:
CPS transformations:
- https://github.com/Sage/streamlinejs
- http://maxtaco.github.io/coffee-script/
Coroutines/fibers:
- https://github.com/laverdet/node-fibers
ES6 Generators
Hi Nuri,
I'll follow up with a private reply as I need to know a little more about
your relationship with us (partner, customer?).
Bruno
On Thursday, January 30, 2014 3:18:31 AM UTC+1, Nuri Kevenoglu wrote:
Hi Bruno,
We're running Sage X3 v6.5 here in Sydney and will upgrade to v7 at some
MesaXYZ: http://mesa-reprap.blogspot.com.br/
http://mesa-reprap.blogspot.com.br/ ===
Em 16-01-2014 06:48, Bruno Jouhier escreveu:
No water-tight technical solution? There are some. Problem is that people
are reluctant to go with them.
For me, the exception handling problem has been
You won't get the problem is you use either streamline.js or fibers. A
try/catch in your request handler will catch all exceptions that may be
thrown by the current request (and only those exceptions). Streamline will
also give you a TLS (thread local storage) equivalent: useful if you need
to
I've heard that generators helps to catch errors but didn't seen any good
explanation how to do that, if anyone knows such an article please post
link here
With the galaxy library, you just use try/catch to handle errors with
generators. The model is the same as async/await in other
Of course I can use all sorts of API/functional twists to improve things
but:
1) Code will still be more difficult to read. For example, compare:
function asyncFn4(_) { return asyncFn1(_, a, b).asyncFn2(_, c, d,
e).asyncFn3(_, f); }
and:
function asyncFn4(_) { return yield(asyncFn3(yield
, January 9, 2014 9:24:02 AM UTC+1, Bruno Jouhier wrote:
Of course I can use all sorts of API/functional twists to improve things
but:
1) Code will still be more difficult to read. For example, compare:
function asyncFn4(_) { return asyncFn1(_, a, b).asyncFn2(_, c, d,
e).asyncFn3(_, f
Here is how I would write it with streamline (if I understand it well):
var flows = require('streamline/lib/util/flows');
function timeyWimeyBall(endpoint, obody, _) {
var resp1 = localPost(endpoint, obody, [_]);
var fut = localGet(resp1[0].headers.location, !_); // don't wait, get a
future
what to do about it.
If I wanted to write sync-like code, I'd probably turn to generators and
co module. It looks nice, but I didn't actually manage to try it, since
generators aren't on by default even in 0.11.x...
// alex
08.01.2014, 11:37, Bruno Jouhier bjou...@gmail.com
The async stack is reconstructed when you *catch* the exception (would be
very inefficient otherwise). The normal pattern is to have at least one try
catch in your high level HTTP dispatcher. You actually automatically get
one if you use the companion streamline-streams or ez-streams companion
Recently published to NPM:
streamline 0.10.4: just bug fixes
galaxy 0.1.4 and galaxy-stack 0.1.1: upgrade for node 0.11.10 (deals with
last V8 API changes)
ez-streams 0.1.1: bug fixes + first brew of XML streaming parser and
formatter
Bruno
--
--
Job Board: http://jobs.nodejs.org/
Posting
The sync wrapper will only help you if you are using node to write command
line scripts. You should *never* use sync calls when processing server
events. And the fact that it takes less than 1 s is no excuse because node
can process a lot of events in 1 s, even in 1 ms!
The only way to return
://www.infoq.com/presentations/Simple-Made-Easy)
but I really don't know which one to choose right now. So I stick to the
node core's one.
On Tuesday, 17 December 2013 03:05:17 UTC+1, Bruno Jouhier wrote:
Just published first brew of ez-streams to NPM: Easy streaming API for
node.js.
http
Hesitated to jump into this. I just want to express my gratitude to Ben for
the great work he did on libuv and node.
Bruno
Politics is like an andouillette – it should smell a little like shit, but
not too much -- Edouard Herriot.
On Monday, December 9, 2013 9:38:51 PM UTC+1, Ben Noordhuis
FWIW co/koa still don't entirely solve the problem, there's really no way
to completely solve it without coroutines with separate stacks,
No! Problem can be solved with generators alone. Of course it is easier
with real coroutines (fibers) but it is also manageable with shallow
Thanks to all. My review list is growing.
My main use case is building setups by updating source trees from git,
launching compilers (sometimes on remote machines because I need binaries
for several OSes), downloading stuff from internet, etc. I did not really
need all the power of Chef for
You will have difficulties getting an agreement on a best approach.
If you want something simple and robust, you may want to take a look the
tools that let you write code in sync style. Most of them (all the ones
based on fibers and generators, some of the CPS transforms) give you
try/catch
the name qop.
Bruno Jouhier bjou...@gmail.com javascript: wrote:
I googled a bit but did not find anything like it. Did anyone consider it?
Cool features would be:
* It's JavaScript
* Windows is fully supported (Ruby isn't great on Windows).
Bruno
--
--
Job Board: http://jobs.nodejs.org
I googled a bit but did not find anything like it. Did anyone consider it?
Cool features would be:
* It's JavaScript
* Windows is fully supported (Ruby isn't great on Windows).
Bruno
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
Our tests were done with 0.10 and 0.11. We did not test with 0.8 because we
upgraded to 0.10 a while ago.
I looked at the figures again. The large oscillations and big drop in
fibers mode that I gave were actually on the heap used. The RSS figures
oscillate too but the drop is smaller. First
ACID compliance has serious financial implications and is why people keep
harping on about it. It's really really really important.
Sure! And, as your stock is managed in your ERP you really really need a
DTChttp://en.wikipedia.org/wiki/Distributed_Transaction_Coordinatorbetween
your
Great news!
We would be very interested by an AIX port. PowerPC is a first step (and
likely the most difficult one). Any plans for AIX?
Bruno
On Tuesday, September 3, 2013 8:41:53 PM UTC+2, Andrew Low wrote:
Hi folks, allow me to introduce myself. I'm Andrew Low and I work for IBM.
I've
Looks like Michaël has been working with generators in Firefox (he mentions
JavaScript 1.7 somewhere).
Michaël, you should take a look at *harmony* generators. They will
superseed the JS 1.7 generators in Firefox. It's the same concept but the
syntax has evolved a little bit. For example yield
Right! I was in the logic of my own bench, which is just a simple loop. If
you are benching with concurrent requests it doesn't make much difference.
Bruno
On Tuesday, August 13, 2013 1:16:10 AM UTC+2, spion wrote:
On Monday, August 12, 2013 10:23:51 AM UTC+2, Bruno Jouhier wrote:
A lot
1 - 100 of 244 matches
Mail list logo
