@Raynos, @greelgorke I would recommend reading Out of the
tarpithttp://shaffner.us/cs/papers/tarpit.pdf.
It argues that traditional imperative approach with control flow being
messed with logic leads to complex unmaintainable just ugly software.
On Saturday, December 29, 2012 11:39:28 AM
PHP does I/O in a blocking way.
Using these php functions in node will block the event loop, limiting the
responsiveness and scalability of your app.
--
Pedro
On Saturday, 29 de December de 2012 at 06:35, JSON wrote:
But I also agree that creating full routines using php within javascript
ah this. well it's ok, that underscore does not match native API.
underscore is not a shim, it uses nativ implementations under the hood, if
any present. this is ok. it uses it's own api and not implement the
standard. anyway, underscore IS one solution, may be a better in some
cases, for a
Apparently, localeCompare ignores the locale settings. [*]
Do I blame node for this, or is it a V8 shortcoming?
If the former, consider this a feature request.
Or is there a bug tracker I should use for this?
[*] Evidence:
; locale | grep LC_COLLATE
LC_COLLATE=nb_NO.utf8
; node
var x='æ',
Is there a convention for publishing modules that won't run on vanilla
latest node but instead need --harmony flag to be set? I didn't see
anything in package.json that would serve this function.
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
To clarify further.. I mean a module that will be used programmatically (so
'npm start' won't work and such). For example, a module that relies on
WeakMap.
On Saturday, December 29, 2012 8:43:13 AM UTC-6, Tristan Slominski wrote:
Is there a convention for publishing modules that won't run on
Thank you, using this, I was able to get it working.
My implementation isn't pretty but at least it works.
If anyone cares, the code is available at http://pastie.org/5593289
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/eldargab/make-flow
--
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
Hi Pedro,
Most PHP IO can be set as non-blocking (well, the appropriate readers,
writers, polls, etc). At a point this can become extension specific, but
they're all writen in C (some in C++) using mainstream counterparts, so you
generaly have the same options available.
On Saturday, December
Also, PHP can be ran in different threads as v8. They're not different
processes, but the two environments are different enough that they can be
completely isolated from each other. At this point I have two ways of
calling PHP in worker threads, which then place data in shared zend_tables
I'd like to address some concerns
@Mark: no, there's no slowdown. Compilation is done only once in a lifetime
of a function, results are cached.
@Raynos: please note how elegant and readable the circuit solution is: it
speaks for itself in 3 lines, and it does not have and russian dolls in
it
That was an interesting paper, and thank you for sending it along. I often
find myself describing the essential problems I have working in Node as
rooted in resolving the tensions inherent in JavaScript. This is precisely
due to the presence in JS of both OO and functional paradigms.
Some things
Well if its just runtime needs, you could throw an error on require if a
global for w/e you need is not present? Placing Javascript dialect into the
package.json would get complex and hairy quite quickly.
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
you could throw an error on require if a global for w/e you need is not
present?
That is not a solution. That would be as bad as throwing an error if
they hadn't required a needed module themselves.
I happen to need this also in my new app.
--
Job Board: http://jobs.nodejs.org/
Posting
If you are using a non-standard (harmony) expectation in your library you
should test and bail on an environment that does not supply the interfaces
expected. I think throwing on missing expectations is one solution the
other is to require a shim if the expectation is not present. Both are
That makes sense.. and as you say, it is well established in JS. I don't
see any other sane way of accomplishing that. It works for my use case,
I'll make sure it's obvious in the README as well. Thanks.
On Saturday, December 29, 2012 7:13:54 PM UTC-6, Bradley Meck wrote:
If you are using a
For the next month at least, the primary focus will be on bug fixing
and performance. Expect nearly-weekly releases until v0.10 is ready.
2012.12.30, Version 0.9.5 (Unstable)
* assert: improve support for new execution contexts (lukebayes)
* domain: use camelCase instead of snake_case
A modest proposal: throwing errors on uncaught 'error' events in
EventEmitter should be made optional, rather than mandatory.
Looking back at the original thread that proposed the throwing behavior
(https://groups.google.com/d/topic/nodejs/7BU_1BB9zeM/discussion), I'm
surprised at how little
What you describe as small and simple, but also idiomatic, can be said
also about assembly language.
Basically, what is the reason for having high-level languages? Everything
can be done more efficiently in assembly, for sure.
The problem of this logic is that it discounts the costs, and
Imagine writing program consisting of 300 async calls
My app currently has several thousand such calls.
If nodejs team believes current solutions are optimal
There is no optimal solution. If there were one everyone would jump on it.
I think it is great that you developed an interesting
On Sat, Dec 29, 2012 at 8:45 PM, Tatumizer tatumi...@gmail.com wrote:
What you describe as small and simple, but also idiomatic, can be said
also about assembly language.
Basically, what is the reason for having high-level languages? Everything
can be done more efficiently in assembly, for
21 matches
Mail list logo
