date:20121229

Re: [nodejs] Re: new concept for structured asynchronous programming

2012-12-29 Thread Eldar

@Raynos, @greelgorke I would recommend reading Out of the 
tarpit. 
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 UTC+4, Raynos wrote:
>
> You can implement the same idea with two functions
>
> Here the code is explicit about how it runs code.
>
> ```js
> var execute = require("execute")
> , serial = require("serialize") // unimplemented see 
> https://gist.github.com/4405173
>
> var run = serial([
> function (cb) {
> execute({
> sum1: function (cb) { add(1, 2, cb) }
> , sum2: function (cb) { add(3, 4, cb) }  
> }, cb)
> }
> , function (result, cb) {
> add(result.sum1, result.sum2, cb)
> }
> ])
>
> run(printResult)
>
> function printResult(err, result) {
> if (err) {
> throw err
> }
> console.log("result", result) // prints "result=10" 
> }
> ```
>
> Although your idea is interesting, it's hard to build something that's 
> cleaner then just being explicit about how you do things.
>
> Also notice that because we are using clean functional abstractions they 
> compose trivially ( http://jsfiddle.net/fvz7N/4/ ) like functions should.
>
> Your ideas however are interesting, the problem is that they are far more 
> complex to grok and require trust on self organizing code. Also it's full 
> of implicit magic by the very definition of self organizing code.
>
> It should be noted substack had a similar idea with disorder ( 
> https://github.com/substack/node-disorder#disorder )
>

-- 
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: PHP in node.js feature call

2012-12-29 Thread Pedro Teixeira

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 
> would be a pointless and even wasteful to a degree. The examples where meant 
> to illustrate capabilities, not to suggest how it should be used.
> 
> On Friday, December 28, 2012 10:13:01 PM UTC-8, mscdex wrote:
> > Seems to me that if you're going through all of this trouble just for 
> > "the familiarity of the PHP platform," then you should just use PHP in 
> > the first place because doing all this synchronous stuff pretty much 
> > makes this usage of node pointless. 
> -- 
> 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

-- 
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] Inconsistent method names?

2012-12-29 Thread greelgorke

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 bunch of tasks. even if its to big to include, one still could 
copy some implementations for own use.

Am Samstag, 29. Dezember 2012 00:04:36 UTC+1 schrieb Rick Waldron:
>
>
>
> On Friday, December 28, 2012, greelgorke wrote:
>
>> well, yes, you are right at this point. Mark said, he uses much of typeof 
>> and sometimes instanceof for Array detection. So, his use case may be a 
>> good one for underscore. but if you just want this one single function, it 
>> is an overkill, but even then it's worth to look at its code and just take 
>> the picks you need, and use them. it's MIT
>>
>> > Furthermore, underscore has a nasty history of not correctly matching 
>> native implementations
>> is this a claim like: "don't use it, because it had bugs earlier"? huh?
>>
>
> No, because they still exist. Natives have sparse array handling, 
> underscore does not. indexOf has some made up third param that isn't 
> fromIndex. 
>
> Anything else?
>
> Rick
>
>
>
>
>> Am Freitag, 28. Dezember 2012 23:03:27 UTC+1 schrieb Rick Waldron:
>>
>>
>>
>> On Friday, December 28, 2012, greelgorke wrote:
>>
>> look further, there is more than just isArray. AND underscore falls back 
>> to native implementations, if any present. and it's just it: same interface 
>> for every plattform.
>>
>>
>> Yes, I'm very aware of underscore, thank you. I don't believe in adding a 
>> full on library for the sake of using a single function that language 
>> already offers natively. Furthermore, underscore has a nasty history of not 
>> correctly matching native implementations, so lucky you: same API, 
>> different behaviour.
>>
>> The only platforms that don't support Array.isArray are old IEs.  
>>
>>
>> Rick
>>
>>
>>
>> Am Freitag, 28. Dezember 2012 22:31:28 UTC+1 schrieb Rick Waldron:
>>
>>
>>
>> On Friday, December 28, 2012, greelgorke wrote:
>>
>> psst.. i heard underscore have some cool tools for the typeof pain, like 
>> http://underscorejs.org/#isArray 
>>
>>
>> *facepalm*
>>
>> Really? On a platform that supports Array.isArray built-in?
>>
>> Rick
>>  
>>
>>
>> Am Donnerstag, 27. Dezember 2012 22:32:03 UTC+1 schrieb Mark Hahn:
>>
>> >  what sort of program scenarios you've found yourself in where 
>> instanceof was the "go to" solution 
>>
>> I use typeof a lot, but instanceof not so often.  I sometimes use 
>> instanceof Array when I don't have a helper around for that. 
>>
>> I've just started a module for use in node and the client that "fixes" 
>> these as much as possible.  It is annoying when I get an error just 
>> because of lack of camelCasing.  My mind isn't good at remembering 
>> minor things. 
>>
>> Does anyone know how I could fix typeof in node?  I can see how to do 
>> it in the client.  Luckily I'm using coffeescript so making typeOf a 
>> function will be used like `typeOf x` and it will look the same as 
>> typeof `x`. 
>>
>> > Completely irrelevant to the discussion... 
>>
>> What is irrelevant? 
>>
>> On Thu, Dec 27, 2012 at 1:06 PM, Rick Waldron  
>> wrote: 
>> > Inline... 
>> > 
>> > 
>> > On Thursday, December 27, 2012, Mark Hahn wrote: 
>> >> 
>> >> Why not also allow readDir?  It would cause no harm to do so. 
>> >> 
>> >> This isn't node, but what also bugs me is typeof and instanceof.  I 
>> >> cringe every time I type them. 
>> > 
>> > 
>> > Completely irrelevant to the discussion... but you have my attention 
>> now—I'm 
>> > curious to know what sort of program scenarios you've found yourself in 
>> > where instanceof was the "go to" solution (but painful to use?), aside 
>> from 
>> > useful type checking (types as in "object types", not as in 
>> "data-types"). 
>> > If you want to know if x has Foo constructor in its prototype chain, 
>> > instanceof has you covered. 
>> > 
>> > Rick 
>> > 
>> > 
>> >> 
>> >> 
>> >> 
>> >> On Thu, Dec 27, 2012 at 11:47 AM, David Habereder 
>> >>  wrote: 
>> >> > That clears that up. Thanks. 
>> >> > 
>> >> > Am Donnerstag, 27. Dezember 2012 20:36:30 UTC+1 schrieb Matt 
>> Sergeant: 
>> >> >> 
>> >> >> I think you'll likely find where it isn't the case (such as 
>> readdir) 
>> >> >> the 
>> >> >> name comes from the POSIX function name. There's no readfile 
>> function 
>> >> >> in 
>> >> >> POSIX, but there is readdir(). The only other case seems to be 
>> >> >> readlink, 
>> >> >> which is the same issue. 
>> >> >> 
>> >> >> http://linux.die.net/man/2/**readdir
>> >> >>  
>> >> >> http://linux.die.net/man/2/**readlink
>> >> >>  
>> >> >> 
>> >> >> 
>> >> >> On Thu, Dec 27, 2012 at 1:02 PM, David Habereder <
>> david.h...@gmail.com> 
>> >> >> wrote: 
>> >> >>> 
>>

[nodejs] String.prototype.localeCompare

2012-12-29 Thread Harald Hanche-Olsen

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='æ', y='å'
undefined
> x.localeCompare(y)
1
(the correct answer is negative)

This is on linux. I have verified that both python and /usr/bin/sort
get it right, so the host locale implementation is not to blame.

- Harald

-- 
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

[nodejs] convention for publishing modules requiring --harmony?

2012-12-29 Thread Tristan Slominski

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: 
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

[nodejs] Re: convention for publishing modules requiring --harmony?

2012-12-29 Thread Tristan Slominski

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 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: 
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] pipe npm completion result to another script

2012-12-29 Thread Xananax

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/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

[nodejs] [ANN] make-flow - Make style control flow. Excellent for complex functions.

2012-12-29 Thread Eldar

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 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: PHP in node.js feature call

2012-12-29 Thread JSON

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 29, 2012 1:11:24 AM UTC-8, Pedro Teixeira wrote:
>
> 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 
> would be a pointless and even wasteful to a degree. The examples where 
> meant to illustrate capabilities, not to suggest how it should be used.
>
> On Friday, December 28, 2012 10:13:01 PM UTC-8, mscdex wrote:
>
> Seems to me that if you're going through all of this trouble just for 
> "the familiarity of the PHP platform," then you should just use PHP in 
> the first place because doing all this synchronous stuff pretty much 
> makes this usage of node pointless. 
>
> -- 
> 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 nod...@googlegroups.com 
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com 
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>  
>  
>  

-- 
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

[nodejs] Re: PHP in node.js feature call

2012-12-29 Thread JSON

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 
accessible to node.

On Tuesday, December 25, 2012 4:49:15 PM UTC-8, JSON wrote:
>
> I'm finishing up a php sapi/api for v8. The original taget server is a 
> boost asio based game server, but I will also be making a port for node.js 
> (yes, the node port will be free and open). What type of features would you 
> be most interested in? At the current state, php invocations are made from 
> v8 at run time. the invocation is done like such:
>
> var invocation = {
>
> host:"domain"
>
> user:"username",
>
> pass:"password"
>
> method:"mysql_connect"
>
> }
>
>
>  var link = php.commit(invocation);
>
>
> Commits take under 2 millionths of a second on low end equipment (thats 
> the function invocation, not the function execution) and type conversion is 
> done transparently and directly, without JSON parsing. commit also has an 
> async variant which handles functions in threads outside of v8 (though 
> still part of the same process) and a proxy variant that sends invocation 
> into php userspace rather than invoking them at core level. This is slower 
> but provides more flexibility to PHP/javascript developers. Proxy calls 
> still happen within the same thread if it not called asynchronously.
>
>
> What features would you be most interested in? encryption? gd/image magic? 
> database connectivity? Any input would be very helpfull.
>

-- 
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: new concept for structured asynchronous programming

2012-12-29 Thread Tatumizer

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 - plain code, much like sequential one; BUT it knows itself what is 
parallel and what is sequential. So, with almost no extra noise it supports 
parallelism, which is very important in server applications.
"Nothing cleaner than being explicit"? I think circuit is as explicit as it 
gets.

about "disorder": yes, there are many libraries that are based on the raw 
idea of  "reactive programming". 

The difference is:
I tried to make CONCEPT out of this raw idea so that all details associated 
with NODEJS async programming I'm aware of fit into it nicely. Central 
point of control is important. Loops (over streams) are important. 
Debugging. Timeouts. Circuit KNOWS its structure (no other solution I'm 
aware of knows it), Based on this knowledge, you can build nice debugging 
tool that shows the graph , etc. Based on this knowledge, you can 
parallelize beyond one processor.

I am not sure many people read the entire writeup, and I'm sorry I couldn't 
keep it shorter (really takes time to read), but I wanted to tell the 
entire story.

Isn't it interesting that circuit.run() and circuit.loop() cover A LOT of 
real world use cases?

Guys, let's discuss it, I think it can make nodejs programming more 
accessible, help to bring it more mainstream. I need your criticism really. 
Is there something that is missing from the picture?
Something wrong? Of 2 versions of syntax, which is better? Is it really as 
"elegant" as I imagine? If not, what should be changed? Etc.

I will appreciate any feedback

Thanks,
Alex

On Saturday, December 29, 2012 3:16:39 AM UTC-5, Eldar wrote:
>
> @Raynos, @greelgorke I would recommend reading Out of the 
> tarpit. 
> 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 UTC+4, Raynos wrote:
>>
>> You can implement the same idea with two functions
>>
>> Here the code is explicit about how it runs code.
>>
>> ```js
>> var execute = require("execute")
>> , serial = require("serialize") // unimplemented see 
>> https://gist.github.com/4405173
>>
>> var run = serial([
>> function (cb) {
>> execute({
>> sum1: function (cb) { add(1, 2, cb) }
>> , sum2: function (cb) { add(3, 4, cb) }  
>> }, cb)
>> }
>> , function (result, cb) {
>> add(result.sum1, result.sum2, cb)
>> }
>> ])
>>
>> run(printResult)
>>
>> function printResult(err, result) {
>> if (err) {
>> throw err
>> }
>> console.log("result", result) // prints "result=10" 
>> }
>> ```
>>
>> Although your idea is interesting, it's hard to build something that's 
>> cleaner then just being explicit about how you do things.
>>
>> Also notice that because we are using clean functional abstractions they 
>> compose trivially ( http://jsfiddle.net/fvz7N/4/ ) like functions should.
>>
>> Your ideas however are interesting, the problem is that they are far more 
>> complex to grok and require trust on self organizing code. Also it's full 
>> of implicit magic by the very definition of self organizing code.
>>
>> It should be noted substack had a similar idea with disorder ( 
>> https://github.com/substack/node-disorder#disorder )
>>
>

-- 
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] new concept for structured asynchronous programming

2012-12-29 Thread Forrest L Norvell

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 to consider, though:

1. JavaScript uses OO techniques to manage state, especially when
performance is a consideration. It is much faster to use direct mutation on
an object than it is to create any kind of persistent data structure.
2. JavaScript has a simply-typed functional core. While there is imperative
control flow, in most circumstances JS developers are encouraged to use
anonymous functions passed to higher-order functions to achieve most common
goals.
3. Node.js's fundamental control flow paradigm is the asynchronous
execution of chains of callbacks. In some ways this is similar to
continuation-passing style, but because it is the result of ad hoc design
decisions (as opposed to the result of a mechanical transformation applied
by a compiler or macro system), user and library code can make few
assumptions about control flow beyond those specified by their own
interfaces.
4. "Simplicity" in the Node world is coming to mean "composability" first
and foremost. Each module should export one unit of functionality, and then
users can choose the modules that they feel will work best to solve their
particular problems. This places a premium on the traditional software
engineering values of loose coupling and tight cohesion. It also means that
the streams of data passed between modules tend to be basic data types
rather than structures, with Buffers being about the most complex type
commonly encountered.
5. Node was designed to build fast web services. As such, it's accumulated
a body of lore that can be used to work with V8's JIT, the system calls for
each platform, and other things that frequently result in awkward
combinations of JS's twin OO and functional natures.

Jake's sketched-out solution does a good job of reconciling some of the
contradictions inherent in Node's approach. It's stateful but not based on
mutation, it uses two simple functions to define control flow, and it's
quite clear and explicit about how it works without slapping a pile of
abstractions in the way.

Node is built to do a certain class of tasks as quickly and efficiently as
possible. Its design decisions were made with an eye towards simplicity and
performance, not elegance or purity. The emerging consensus of the
community seems to be that the best way to deal with the rough edges of
Node's use of JavaScript is to keep things small and simple, but also
idiomatic. New techniques for control flow are fun to develop and play
with, but the more they become controlling abstractions, the less useful
they are to the general body of Node developers. IMHO, at least.

F

On Saturday, December 29, 2012, Eldar wrote:

> @Raynos, @greelgorke I would recommend reading Out of the 
> tarpit.
> 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 UTC+4, Raynos wrote:
>>
>> You can implement the same idea with two functions
>>
>> Here the code is explicit about how it runs code.
>>
>> ```js
>> var execute = require("execute")
>> , serial = require("serialize") // unimplemented see
>> https://gist.github.com/**4405173 
>>
>> var run = serial([
>> function (cb) {
>> execute({
>> sum1: function (cb) { add(1, 2, cb) }
>> , sum2: function (cb) { add(3, 4, cb) }
>> }, cb)
>> }
>> , function (result, cb) {
>> add(result.sum1, result.sum2, cb)
>> }
>> ])
>>
>> run(printResult)
>>
>> function printResult(err, result) {
>> if (err) {
>> throw err
>> }
>> console.log("result", result) // prints "result=10"
>> }
>> ```
>>
>> Although your idea is interesting, it's hard to build something that's
>> cleaner then just being explicit about how you do things.
>>
>> Also notice that because we are using clean functional abstractions they
>> compose trivially ( http://jsfiddle.net/fvz7N/4/** ) like functions
>> should.
>>
>> Your ideas however are interesting, the problem is that they are far more
>> complex to grok and require trust on self organizing code. Also it's full
>> of implicit magic by the very definition of self organizing code.
>>
>> It should be noted substack had a similar idea with disorder (
>> https://github.com/substack/**node-disorder#disorder
>>  )
>>
>  --
> 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

[nodejs] Re: convention for publishing modules requiring --harmony?

2012-12-29 Thread Bradley Meck

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: 
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: convention for publishing modules requiring --harmony?

2012-12-29 Thread Mark Hahn

> 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 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: convention for publishing modules requiring --harmony?

2012-12-29 Thread Bradley Meck

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 
pretty de-facto in JS. Putting this into package.json etc would mean that 
you are requiring CLI switches that are non-standard to be in place. 
Shimming and throwing are perfectly valid for this case.

I see this as little difference from requiring a peer module or a module 
that expects a non-present global variable (lots of tests suites bootstrap 
in globals, errors are usually but not always obvious due to this).

-- 
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: convention for publishing modules requiring --harmony?

2012-12-29 Thread Tristan Slominski

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 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 
> pretty de-facto in JS. Putting this into package.json etc would mean that 
> you are requiring CLI switches that are non-standard to be in place. 
> Shimming and throwing are perfectly valid for this case.
>
> I see this as little difference from requiring a peer module or a module 
> that expects a non-present global variable (lots of tests suites bootstrap 
> in globals, errors are usually but not always obvious due to this).
>

-- 
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

[nodejs] Version 0.9.5 (Unstable)

2012-12-29 Thread Isaac Schlueter

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 (isaacs)

* domain: Do not use uncaughtException handler (isaacs)

* fs: make 'end' work with ReadStream without 'start' (Ben Noordhuis)

* https: optimize createConnection() (Ryunosuke SATO)

* buffer: speed up base64 encoding by 20% (Ben Noordhuis)

* doc: Colorize API stabilitity index headers in docs (Luke Arduini)

* net: socket.readyState corrections (bentaber)

* http: Performance enhancements for http under streams2 (isaacs)

* stream: fix to emit end event on http.ClientResponse (Shigeki Ohtsu)

* stream: fix event handler leak in readstream pipe and unpipe (Andreas Madsen)

* build: Support ./configure --tag switch (Maciej Małecki)

* repl: don't touch `require.cache` (Nathan Rajlich)

* node: Emit 'exit' event when exiting for an uncaught exception (isaacs)


Source Code: http://nodejs.org/dist/v0.9.5/node-v0.9.5.tar.gz

Macintosh Installer (Universal): http://nodejs.org/dist/v0.9.5/node-v0.9.5.pkg

Windows Installer: http://nodejs.org/dist/v0.9.5/node-v0.9.5-x86.msi

Windows x64 Installer: http://nodejs.org/dist/v0.9.5/x64/node-v0.9.5-x64.msi

Windows x64 Files: http://nodejs.org/dist/v0.9.5/x64/

Linux 32-bit Binary: http://nodejs.org/dist/v0.9.5/node-v0.9.5-linux-x86.tar.gz

Linux 64-bit Binary: http://nodejs.org/dist/v0.9.5/node-v0.9.5-linux-x64.tar.gz

Solaris 32-bit Binary:
http://nodejs.org/dist/v0.9.5/node-v0.9.5-sunos-x86.tar.gz

Solaris 64-bit Binary:
http://nodejs.org/dist/v0.9.5/node-v0.9.5-sunos-x64.tar.gz

Other release files: http://nodejs.org/dist/v0.9.5/

Website: http://nodejs.org/docs/v0.9.5/

Documentation: http://nodejs.org/docs/v0.9.5/api/

Shasums:

```
d44535e086c3f0fe47152b9323189c18a488d995  node-v0.9.5-darwin-x64.tar.gz
b588332e38e3ddd0424b18d14a3c6c65c5cad6f6  node-v0.9.5-darwin-x86.tar.gz
17b07641b59bc56582e68db6bd52c1b41bb06a5e  node-v0.9.5-linux-x64.tar.gz
89656e3dc094a6fa4244a03ac85e9b08b7443a50  node-v0.9.5-linux-x86.tar.gz
bf84b80ea80b4cb20767d4b3f276979f0f3d8866  node-v0.9.5-sunos-x64.tar.gz
4f98560e55db63f323b6f75b22538d96b199892c  node-v0.9.5-sunos-x86.tar.gz
7ed38be34e5377f45e8906c4d887de262c1925e2  node-v0.9.5-x86.msi
a1f1322fcaa5535ae830f3242bcdd213388357cc  node-v0.9.5.tar.gz
94c22b744945e9bc8b3f9fd31991cb6b87f727ce  node.exe
e809779c8071abf05650fbb47e207140829dc62c  node.exp
cec09944297546185070c809a78931839e3c2695  node.lib
5a3a4f3de4b8bf4209ecc2e6d40418d6a7e8fcac  node.pdb
55c986c14a72081757002f8df43272b20f024c57  x64/node-v0.9.5-x64.msi
55514dd925a9b24cb3925f89facbec5efb2a99aa  x64/node.exe
920e2d3319eac8a3356023a1cb8c61f139f80398  x64/node.exp
e072006328dacce920e4951596e457e58e6310d0  x64/node.lib
633816d865155148129ca21399e411f1240b2cce  x64/node.pdb
```

-- 
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

[nodejs] Revisiting "error" events in EventEmitter

2012-12-29 Thread Jeff Lee

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 debate there was about adding built-in special-case 
events to a general library class. The throwing behavior seems like an 
abstraction flaw. Event handles are an "userspace" concept, and the 
lib/runtime shouldn't be imposing semantics on that. In particular, 'error' 
is a very generic term, and useful enough that it ought to be reserved for 
whatever the app intends for it.

For example, I might have an app that produces "success" or "error" events. 
The "error" events may even be anticipated and normal within the concept 
space of the app. They may be being broadcast simply for logging hooks--if 
I care to log "error" events, I'll listen for them, but if I don't care, I 
shouldn't be required to install a listener to prevent the app from 
halting. You might argue that I should rename the "error" event to 
"failure" or some other term, but that seems awfully heavy-handed. If 
variable naming truly is one of the hard problems of computer science, then 
event naming is similarly difficult, and as such it's a little rude for the 
API to impose any restrictions, especially for such a semantically 
ambiguous term. 

Of course, it's probably not feasible at this point to remove throwing 
behavior from the API entirely, but it seems fairly easy to change it to a 
switchable default. One could imagine a lot of different ways of 
implementing this using module-level configuration:

1. A simple on/off boolean property
2. A method that lets you set the name of the 'error' event, or blank if 
you don't want the automatic throwing
3. A method that lets you set a common callback for all emitters that 
aren't handling 'error'.

Personally, I prefer some combination of 2 and 3. In any case, if there's 
interest from the community, I'd be happy to contribute a pull request for 
this.

-- 
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] new concept for structured asynchronous programming

2012-12-29 Thread Tatumizer

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 there's 
more than one type of costs (though all of them eventually have $$ 
expression).

Imagine writing program consisting of 300 async calls in the "idiomatic" 
way you propose. Handling correctly all exceptions... Debugging such 
program... MAINTAINING it (300 is a number of async calls in a modest size 
project I saw recently). 

I don't know. If nodejs team believes current solutions are optimal, so be 
it. 








>>  

-- 
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] new concept for structured asynchronous programming

2012-12-29 Thread Mark Hahn

> 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 approach to the async
problem.  I think every programmer new to node should write an async
library.  I wrote such a library and I learned a lot, not just about
programming node, but about the nature of async code.  I used it for a
while.

Over the last several years I have found it easier and easier to just use
"boilerplate" as you described it.  Here are some examples ...

*Linear code ...
*
doThing1 = ->
blah blah blah
doThing2()

doThing2 = ->
blah blah blah
done()

doThing1()


*Looping ...*

angryBirds = [bird1, bird2, bird3]
do flingOneBird = ->
if not (bird = angryBirds.shift()) then done(); return
bird.fling()
flingOneBird()

I have used this boilerplate so many times that I can type it without
thinking.  It has also become very easy to read.  I don't think it is hard
for others to read, but I may be wrong.

-- 
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] new concept for structured asynchronous programming

2012-12-29 Thread Martin Cooper

On Sat, Dec 29, 2012 at 8:45 PM, Tatumizer  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 sure.
>
> The problem of this logic is that it discounts the "costs", and there's
> more than one type of costs (though all of them eventually have $$
> expression).
>
> Imagine writing program consisting of 300 async calls in the "idiomatic"
> way you propose. Handling correctly all exceptions... Debugging such
> program... MAINTAINING it (300 is a number of async calls in a modest size
> project I saw recently).
>

One of the issues you're facing right now, I think, is that many people
here already have large systems built on Node, so they know exactly what's
involved, from direct experience. But with Circuit, all we have today is a
readme with some examples of adding and squaring numbers. There's a huge
gulf between those two things.

What would be very helpful to your cause, I think, is one or more of the
following:

* An example of a real Node app built using Circuit, so that people can see
how it would be used to do real work (as opposed to adding numbers).

* An explanation, with an example, of how (if at all) this fits in with
Node's event model, and how it can help with common scenarios such as
stream processing.

* Some code that people can actually play around with to see how it works.

Right now, we don't have any of those, so we can only speculate about what
it might look like if we tried to use it for something real.

--
Martin Cooper

I don't know. If nodejs team believes current solutions are optimal, so be
> it.
>
>
>
>
>
>
>
>
>>>   --
> 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
>

-- 
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: new concept for structured asynchronous programming

Re: [nodejs] Re: PHP in node.js feature call

Re: [nodejs] Inconsistent method names?

[nodejs] String.prototype.localeCompare

[nodejs] convention for publishing modules requiring --harmony?

[nodejs] Re: convention for publishing modules requiring --harmony?

Re: [nodejs] pipe npm completion result to another script

[nodejs] [ANN] make-flow - Make style control flow. Excellent for complex functions.

Re: [nodejs] Re: PHP in node.js feature call

[nodejs] Re: PHP in node.js feature call

Re: [nodejs] Re: new concept for structured asynchronous programming

Re: [nodejs] new concept for structured asynchronous programming

[nodejs] Re: convention for publishing modules requiring --harmony?

Re: [nodejs] Re: convention for publishing modules requiring --harmony?

Re: [nodejs] Re: convention for publishing modules requiring --harmony?

Re: [nodejs] Re: convention for publishing modules requiring --harmony?

[nodejs] Version 0.9.5 (Unstable)

[nodejs] Revisiting "error" events in EventEmitter

Re: [nodejs] new concept for structured asynchronous programming

Re: [nodejs] new concept for structured asynchronous programming

Re: [nodejs] new concept for structured asynchronous programming

21 matches

Site Navigation

Mail list logo

Footer information