[nodejs] streams2 polyfill/shim for browser

[rektide]

howdy node'ers-

i've spotted deoxxa's streams2 shim, but it's built upon
streams1. slightly OT, but is anyone aware of a streams2
polyfill/shim that works on the browser directly?

kudos,
-r

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

--- 
You received this message because you are subscribed to the Google Groups 
nodejs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [nodejs] Wanted: federated-event/message-emitting platform?

[rektide]

Sounds like you have a series of agents that need to be social with each other? 
Have you
considered using something derived from the original web collection/stream of 
content, Atom?
In particular, a bunch of OStatus/ActivityStrea.ms nodes can pass data down a 
chain of
processing agents, appending data into the next guys queue and the next guy 
picking it up,
doing whatever intermediary processing it needs, and passing it along. Changing 
the runtime
behavior is a matter of altering an ingesting process/agent's behavior, 
redirecting it to
another endpoint or reconfiguring it.

I'd definitely look at repruposing social networking software such as pump.io 
to get your
machines making a social network of work or data items: machines, the most 
social of beasts
I know! 

I'd be most interested in hearing any mismatches, where people feel this high 
level
implementation idea doesn't suit this high level problem description. There's a 
lot of very
low level transport-grade technologies listed, but a resourceful outlook, and a 
standards
stack built to talk about collections of things, is what I would naturally turn 
to if one
needs to socialize a data flow across systems: you'll get much further much 
faster than
hacking some coordination schema yourself, or borrowing a raw message transport.

It'd be a delight if dr-ses (Distributed Resilient Secure EcmaScript) were 
further along, as
a low level language construct for weaving together systems, but it's not, so 
use web
standards to create and data-flow across collections.

-rektide

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

--- 
You received this message because you are subscribed to the Google Groups 
nodejs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [nodejs] Trivial stream.Transform Attempt

[rektide]

That was super fun! I'd neglected to call stream.Transform's constructor when I 
derived from
it. Everything appears to be working fine now, I think. The nop branch reflects 
this change.

Thanks,  please pardon the interruption.

O Mon, Feb 11, 2013 at 12:52:37AM -0500, rektide wrote:
 Hello hello lovely Node-js people-
 
 I'm trying to implement a very simple stream.Transform, but I appear to be 
 doing something
 wrong! Please help me figure out how to get going with stream.Transform!
 
 My utterly trivial sample code is at-
 https://github.com/rektide/arclamp2/blob/nop/src/ClarinetStream.js
 
 It's essentially-
 function clarinetStream(){return this}
 util.inherit(clarinetStream, stream.Transform)
 clarinetStream.prototype._transform= 
 function(chunk,outFn,callback){callback()}
 
 When I try to run my sample (which can be done via `npm test`), I get this 
 stack trace-
 _stream_writable.js:129
   if (state.ended) {
^
 TypeError: Cannot read property 'ended' of undefined
 at ClarinetStream.Writable.write (_stream_writable.js:129:12)
 at write (_stream_readable.js:481:24)
 at flow (_stream_readable.js:491:7)
 at ReadStream.pipeOnReadable (_stream_readable.js:523:5)
 at ReadStream.EventEmitter.emit (events.js:91:17)
 at emitReadable (_stream_readable.js:343:10)
 at onread (_stream_readable.js:288:7)
 at ReadableState.onread (_stream_readable.js:64:5)
 at onread (fs.js:1509:5)
 at Object.wrapper [as oncomplete] (fs.js:419:17)
 
 
 I had been attempting to use a 0.9.9-pre vintage build, and am now locked  
 loaded with the
 latest trunk work. I've looked around some of Node's lib/_stream_* impl, but 
 thusfar I don't
 have a good registration on what's going on, what I could be doing wrong.
 
 Any help getting a sample stream.Transform running would be much appreciated!!
 -rektide de la faye
 
 -- 
 -- 
 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
 
 --- 
 You received this message because you are subscribed to the Google Groups 
 nodejs group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to nodejs+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
 
 

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

--- 
You received this message because you are subscribed to the Google Groups 
nodejs group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [nodejs] New GContext module, Integration between uv and GLib

[rektide]

Nicely done! Hopefully this work can be integrated with node-gir, which 
requires the user to
execute the gst.main() loop the themselves (#2 on their Things which dont 
work).

https://github.com/piotras/node-gir

On Sat, Dec 15, 2012 at 05:47:05PM +0800, Fred Chien wrote:
Hi All,
I've done a Node.js module to integrate event loops from uv and Glib(Used
by GTK+, DBus, Clutteretc).
Actually, some node.js modules(jsdx-toolkit, jsdx-power, dbus... etc) I am
working on. They all need to run a GLib event loop on node.js cause I do
the same job again and again. Well, that's why I make it as individual
module.
BTW, for older version of node.js, we used libev to integrate GLib main
context loop. Unfortunately, libev is deprecated since node.js 0.8, most
of node.js modules doesn't work on the new node.js anymore if it require
GLib event loop. So�I just use uv APIs to re-implement it to solve this
issue, it should work well on node.js 0.8 and higher version now. :-D
You guys can install it directly with NPM:
$ npm install gcontext
More information from github repository:
[1]https://github.com/cfsghost/node-gcontext
Cheers,
Fred

-- 
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] Server-to-Server Communication

[rektide]

There's node-webworker at https://github.com/pgriess/node-webworker . It's 
programmed via an
API alike W3C's WebWorkers. Internally it's a very simple message passing 
protocol, hosted
on top of WebSockets. Between the too low level (ZeroMQ, dealing intimiately 
with sockets)
and too high level (plenty of targets, let's call out hook.io randomly), 
creating
MessageChannels and MessagePorts is to me a great middle-level of messaging 
abstraction, and
it's one we'll continue to see more of in places outside of Node-land.

-rektide

-- 
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] Dynamic content scrape with Node.js

[rektide]

Only just picked it up last week, but it worked well enough-- node.io.  It 
exposes a
jQuery-esque interface for querying scraped pages. Extremely high level, just 
works
scraping module, in my book!

It also has a fairly sizable task-processing system built in, which I have not 
used.

Good luck:
https://github.com/chriso/node.io

-rektide

On Sat, Oct 06, 2012 at 01:34:03PM -0700, Narek Musakhanyan wrote:
Hey guys . I tried to scrape a data from a website using PHP cURL lib but
I failed  since cURl allows you to scrape only static content . But the
content I want to scrape changes via javascript(AJAX)  since cURL cant
hanfle that I couldnt handle scraping via cURL . So I heard the this type
of things can be done via node . Basically I need to make my node app
handle this js wait for some time until AJAX is done and the pass it to
php .So is it possible to do via node.js ? I dont know node and I have to
start from scratch so I am here you to point out the right node framework
to use to get the result I explained . 

-- 
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: Crockford : Ynode : I would fork node.js

[rektide]

 I wasn't really addressing you—your comments were entirely reasonable. I 
 was addressing the shit-talking dog-pile.


I challenge you to find anything in this thread that directly shit-talks 
Node or Joyent. I *want* to believe this is fair and balanced discussion. 
Jorge got a little tweaked at one point, but still refrained from shit 
talking either.
 

 ps. In case it wasn't clear, the only part that I agree with is threads 
 have no place in JavaScript or Node.


Who is shit talking now? Why hate Rick?

There's a whole lot of over-reactionary fear to a topic some people don't 
like: as Isaac once insisted, lighten up people

-- 
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: Crockford : Ynode : I would fork node.js

[rektide]

 

 Yes they do. I'm following this through the Google web UI. The two 
 discussions are interleaved in a single list and I did not pay attention to 
 the titles. Maybe Google does not like threads either :-)


Sorry! I see the same WTF'itude: I meant to cleanly fork  provide some 
consistency, but it's a mess if you're not email-subscribed, and sorry for 
that: had hoped for better. How does Google Groups work?
http://3.bp.blogspot.com/-fuukRVObpiI/T_W_LVsivkI/BB8/YcXkIn4QeDE/s320/magic.gif
 
(translation: magic)

Not sure where this meme came from, having to rock some *Axis of Eval*here. For 
the record, although amusing, I'm pretty sure 'macros' is not 
actually what he's saying.
http://axisofeval.blogspot.com/2012/07/when-somebody-asks-me-how-i-added-dsl.html

-- 
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: Threading, and Dogmatisms.

[rektide]

On Wednesday, September 19, 2012 6:30:07 PM UTC-4, Mikeal Rogers wrote:


 On Sep 19, 2012, at September 19, 20123:21 PM, rektide 
 rek...@voodoowarez.com javascript: wrote:

  

  I humbly propose not participating in things which annoy you or you 
 find overly distracting. 


 Mikeal was complaining about nothing except people discussing things, 
 about feeling hurt for others talking. He deserves counter-meta-moderation, 
 and there should be no problems with that. I unequivocally renounce any 
 charge of trolling or inappropriateness on this front.


 I take issue with these discussions because they make the list a place for 
 your favorite arguments and alienate people from asking real questions 
 about problems they have using node.js. Of the last 100 messages to the 
 list less than 10% are about real user problems.


Who here has been alienated anyone? Aside from you trying to shut me down 
Mikeal? Link me, anyone.


You don't have to be trolling to be alienating and counterproductive, which 
 is what i charge this conversation with.


I certainly gained a lot more knowledge about threading than when I asked 
for an explanation in February of why Isolates was being cancelled. It may 
not lead to directly useful things for everyone, here, now but it's part of 
a wider dialectic, and I charge all civilized people with the 
responsibility to engage or at least be willing to permit dialectics to 
happen. I want to learn, I have learned: things were gained. Please deny 
that.
 

 You're also ignoring the main point Isaac has been trying to make this 
 whole time: ***that this is not how you engage with the node.js project 
 if you want to get something in to core.***


My main point is that this is a mailing list for discussion. 5% of topics 
are about node core. Should I show up in all them and tell them, on behalf 
of Mikeal, stfu, you're damaging our community? Would you like that? If 
not, just gtfo out of a useful constructive thread we're trying to have for 
interested parties on prospective ways of making Node core better: we're 
certainly closer to home than 95% of this mailing list. Do you deny that?
 

 Isaac has reiterated over and over again what you would need to do to make 
 this productive and nobody has followed up. It appears that you prefer to 
 have a discussion that will bear no fruit other than satisfying your own 
 intellectual curiosity at the expense of others.

 
I dunno. This is getting dangerously close to being technically topical: I 
for one have already challenged this thread that there is not much 
information on the failure of isolates, on where multi-threading has gone 
awry, and I hereby BEG you to find me some good juicy meat on why. I did 
try searching, I said that, and I already said this thread provided me a 
lot more background than I ever knew before. And still, in spite of you 
insisting we all respectfully STFU, I get fantastic new answers such as 
Paddy Byers contributing really detailed info we've, best I can tell, never 
had before.

I really really want to just be quiet about the last proposition, say 
nothing about it. 'satisfying your own intellectual curiosity at the 
expense of others'? You really think A) I expect satisfaction, or B) 
there's an expense here? Don't we have the faculty to not get dragged down 
by this if we're not interested? How much time am I or anyone else 
demanding of anyone? I'm sorry Mikeal: again, pass the hemlock: not only 
are you persecuting a victimless crime, now you're actually accusing me of 
being bad for trying to raise questions.

What gives Isaac hives is the endless conversations you engage in on this 
 list without any intention of actually creating any of the change you 
 advocate for or taking any measurable steps to do so. Sending emails to a 
 mailing list is not how things get done in this project, if you aren't 
 willing to accept than then you'll need to find a new project to email your 
 ideas to.


And again I repeat the stance I issued you last: you and Isaac need to, for 
your own and everyone elses sakes, find ways to disengage and:

Lighten up people


Could not be an easier thing to deal with. Not sure why you're making it so 
hard. 

-- 
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: Threading, and Dogmatisms.

[rektide]

I gently suggest that if we'd found and settled on some technical topics, 
rather than meta-moderation, there would be six or seven posts here. If you 
feel topics not to your interest, I revert to my former stance which is: 
don't read them.

This is a mailing list: 8/10 topics have no interest to me, but I'd be rude 
and out of line if I or anyone else showed up and claimed those people were 
alienating and annoying me by discussing a relevant topic they are 
interested in on my mailing list.

-- 
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: Threading, and Dogmatisms.

[rektide]

On Wednesday, September 19, 2012 8:55:00 PM UTC-4, Isaac Schlueter wrote:

  No, Isaac. I feel pissed on here. Ack that. 

 Ack'ed. 

 Your original request for threads-in-node has been met with 
 explanations from me, Ben, and Paddybyers about what would need to be 
 done to make that happen, and what the challenges are. 


You are projecting defensively: I never requested this feature. I have no 
expectations for it.
 

 There's 
 nothing else to discuss here. 


I'd love an explanation fulfilling my February request: what factors lead 
to it being deemed Isolates was adding too much internal complexity?

We have had some discussion, but as to the effort that got the furthest, 
that seems to have been fairly close, the most information we have for it's 
cancellation is still:

cause[d] too much instability in node's internal functionality


And your guidance to go figure out what that means for myself:

You should treat this as an experiment: your goal could be to figure out 
 why several people close to the Node project are so against a threading API,


Guess? Repeat the experiment and guess? That's a productive use of my time, 
becoming as good as Node devs at Node? You thought writing that would be a 
productive suggestion for a mailing list? I'm all for leadership by 
anarchy, but certainly there's no reason we ought NOT talk, why finding 
concordance with another or learning from another is a BAD thing? 

I don't demand my 'intellectual curiosity' be satisfied, I'm fine with I'm 
not going to tell you. But I here re-affirm that this hunger is not sated, 
and that this issue is not closed. If there are Node.js people that feel 
they can provide technical contributions about what happened, I probably am 
not going to directly make Node.js better with that knowledge, but I think 
we'd all be better for the wisdom you knowing people can share.

-- 
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: Crockford : Ynode : I would fork node.js

[rektide]

 ps. I'm really a nice guy, hopefully we can meet in person some day and 
 we'll laugh about this.


Me too. I interpretted some subset of the conversation here as your 
intended target of shit-talking dogpile people, which didn't seem fair to 
me. Since you've disavowed that connection, attribute it elsewhere, well, 
fine, I'm not certain I understand, but that's cause enough for peace, and 
I'll rock that.

-- 
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: Threading, and Dogmatisms.

[rektide]

 and is a huge annoyance and distraction for everyone who would like to 
 move forward


I humbly propose not participating in things which annoy you or you find 
overly distracting.

Everyone who feels capable of engaging in progressive dialectic engagement 
on technical topics and knows how to avoid meta-moderating, please carry 
on. Mikeal, this is a victimless crime. If like Socrates you think me in 
violation of your society, pass the hemlock: this is the way it's gotta be, 
and the only harm is people that jump to take injury from 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] Re: Crockford : Ynode : I would fork node.js

[rektide]

WebMessaging for life, and as usual, haters gonna hate. Stay positive kids.

On Tuesday, September 18, 2012 1:31:41 PM UTC-4, Rick Waldron wrote:

 Almost forgot...

 When I mentioned threads, he scoffed and said threads have no place in 
 JavaScript or Node. 

 And there you have it, the rest of the story (sans speculative ad hominem)



-- 
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: Crockford : Ynode : I would fork node.js

[rektide]

On Tuesday, September 18, 2012 1:26:13 PM UTC-4, Rick Waldron wrote:

 This morning I had a chance to ask Doug, in person, to clarify what he 
 meant by his statements about forking Node—as it turns out, his motivations 
 aren't sinister, nor are they really outrageous.

 Historically, Yahoo forks technologies that it relies heavily on, eg. Unix 
 and Apache. This allows them to iterate at their own pace and add features 
 they want, when they want them and exclusively to meet their own internal 
 or product based needs. As he explained to me, he simply meant that if he 
 was asked to be the CEO of Yahoo, he would add Node to the technologies 
 that Yahoo maintains its own fork of. Doug also noted that in this 
 hypothetical scenario, the YNode code would be released as an open-source 
 project (unlike forks of other technologies at Yahoo)


 Seems like way less of a big deal when you actually check sources... 
 weird, right?


I'm not sure what was clarified. This still seems like an entirely wide 
open topic. Aside from doing it under Yahoo's umbrella, I can't read a 
single thing different that Crock would do.

So, it's still open hunting season all! Game on!

-- 
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: Threading, and Dogmatisms.

[rektide]

Isaac: I fully confess to being an ignorant childish distracting useless 
retrogressive drag on the community, and I'm sorry if this discussion in 
fact hurts us. Also, seek trained medical professional help.

Alas, the hunger to know more about this topic STILL calls at me. It did 
before Isolates was cancelled, it did when Isolates was cancelled, and I 
sought to rectify my ignorance by asking others, not investigating the 
source which I feel less than capable of, and blaming no one I did not get 
the help I requested highlighting the subtleties of the technical 
landscape surrounding this still interesting feature:
https://groups.google.com/d/msg/nodejs/zLzuo292hX0/xb30bmk3ds8J

Please let me know if you have constructive advice for better ways to seek 
knowledge than what I've done here, or back in February when Isolates was 
canned. I wish to become more informed, and hope this community is civil 
and mature enough to help explore the topic with me.

Respect,
-rektide

On Monday, September 17, 2012 6:09:32 PM UTC-4, Isaac Schlueter wrote:

 Everybody, 

 These debates give me hives.  Seriously, they make my skin crawl. 

 If you think that providing an API for threads is a great idea, then 
 just go do it, as a userland module.  Jorge did.  What's the big deal? 
  Some people like it, some people don't.  That's how anarchy works. 
 Think his threads_a_go_go thing is the wrong abstraction?  Fine.  Do a 
 different one.  It's just code.  Write some.  There's plenty of room 
 in the npm registry for all of us. 

 If you think that such a thing absolutely MUST be provided by the core 
 library, then that belongs in a github issue.  Be prepared to make a 
 VERY strong case for it.  It's a huge change to the architecture, 
 which was tried in the past and turned out to be not a good idea. 
 You'll need to be patient (since it will take a while), be willing to 
 help work on it, and have a plenty of new data showing that it's 
 actually a valuable change to make in the core, and why the problems 
 encountered last time can be overcome. 

 I can tell you that it won't have any chance of landing before 2.0, 
 and you'll have to (at least) convince Ben Noordhuis and Bert Belder 
 that it's worth doing.  They're both rather skeptical right now, and 
 stubbornly fixated on evidence and use cases and reasonable 
 trade-offs, so that'll be an uphill climb, but I've found them easy 
 to convince if you can provide these things.  If you convince them, 
 that's probably the best way to convince me. 

 This is software.  All is flexible.  But we're not going to make 
 architectural changes just because someone says that we have to, using 
 strong words and providing no data.  That's not responsible, for a 
 platform that is used in production by real companies making real 
 money. 

 If you can do it in userland, great.  Go do that.  There's a good 
 chance we'll never do it in core, then, since we don't have to, it's a 
 lot of work, and there's no compelling reason to.  If you can't accept 
 that, and can't convince us to do it in core, then weigh your 
 discontent against the work of forking node and creating a new 
 project.  Some of us will probably even help you.  It might be an 
 interesting project :) 

 If you are annoyed that people don't *like* the module that you wrote, 
 or the project you forked, well, get over it.  Some people hate 
 request and express.  I have issues with underscore and never use it 
 in my projects, and Mikeal calls me crazy and superstitious for that. 
 Maybe he's right.  And those are the most popular modules out there. 
 I would urge any software developer (or any creative person in any 
 field) to divorce their self-esteem from the things that people say 
 about their work.  Yes, of course, we all want to build things that 
 are appreciated by the people we respect; but there's always a crowd 
 of nay-sayers.  You should be worried when you write a program and no 
 one talks shit about it, because it means you're probably not doing 
 anything interesting or important. 

 I would very much like to get away from the idea that anyone should 
 make passionate speeches about how the world will end if we don't do 
 some feature in node-core, or if some module is or isn't used by 
 everyone or anyone.  Lighten up.  We can all do our thing, explore and 
 experiment, and so on.  Having a small set of core functionality is an 
 important part of a healthy module ecosystem.  We won't be making 
 dramatic architectural changes to node any time soon, and certainly 
 not without data to justify it. 

 In debates like this, both sides tend to miss most of the subtlety of 
 what is actually involved with making major changes to a platform like 
 node.  These debates are an annoying distraction from actually getting 
 anything done.It's not about dogma vs features.  We aren't married 
 to Ryan's original vision of Node; in fact, he wasn't even married to 
 that vision when he was running

Re: [nodejs] Re: Threading, and Dogmatisms.

[rektide]

 Multi-threading, even without zero copy, would allow for faster context 
 switching as well. Context switching is bad, process-per-thread is good and 
 helps avoids context switching, but there is a gain even if there is not an 
 easy zero copy benefit to be had.


*facepalm* s/process-per-thread/process-per-core/ 

-- 
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] Threading, and Dogmatisms.

[rektide]

TL;DR: 

1. Threads are a feature, one that will unlock new exciting things we can do 
and make
existing features better (namely child_process.fork()).
2. We don't have that feature is not a feature, is not a pro.
3. Being dogmatic about what others ought do is bad: accept if not embrace 
input liberally.
4. Doing threads, safe concurrency right is what makes Rust so attractive, and 
Node can do
it safely, cleanly too and nearly did, in the isolates branch.
https://github.com/joyent/node/tree/isolates

Onwards:

On Sat, Sep 15, 2012 at 11:32:56AM -0700, Mark Hahn wrote:
@rektide, are you saying that joyent is asleep at the wheel because they
are stopping the community from using threads?�
The community doesn't want threads because they violate the founding
principle of Node, which is to use non-blocking event loops and get rid of
threads.

violate the founding principle?
community doesn't want?

As for doesn't want and founding principles, before threads became an awful 
horrible
thing the Node community would have nothing to do with ever, there was a 
feature that got
canned for being too complicating called Isolates, that, shock and awe, Node 
leads were hard
at work on which would have added threading as a drop in replacement for 
child_process.fork().
Certainly no one was calling the feature anti-Node at the time, it would have 
been an
implementation detail, offered the same functionality as already exists in Node 
today, and
would have made us capable of doing more.
https://groups.google.com/forum/?fromgroups=#!msg/nodejs/zLzuo292hX0/F7gqfUiKi2sJ
https://github.com/joyent/node/tree/isolates

Threading is not evil. Shared state is evil. Which is why the rest of the 
JavaScript world
has Transferables, a way to move ownership of an object from one isolated 
thread/container
to another. Processes preservation [read: apropo exclamative], Node is already a
multi-reactor not a reactor, and there's no harm, nothing but technical gain 
(faster context
switches, Transferables), from allowing that multi-reactor to run on threads as 
easily as it
runs on processes. Aside from the work to get there, there's no cause to keep 
ourselves
locked in to just using processes.
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#transfer-a-transferable-object

I'm not at all saying Joyent is asleep at the wheel. They punted on this topic, 
this big
hard hairy to implement topic: fine. It does hurt us, is a killer feature a 
mature runtime
ought have in it's toolkit, but I have faith eventually we'll go to bat on the 
topic again
in a serious manner in due time and I'm not sweating the innings lost between 
now and then.
In the mean time, Joyent has been doing great things with Node and I'm 
delighted they
continue doing so much to further Node.



I know Ryah has gone on twitter and said he still sees Node as a web runtime. 
Isaac has
similarly lamented allowing other languages to play in Node's pool.  Online 
discussions have
a lot of people defending node's lack of threading. I think much of this makes 
us look bad,
(hipster-ish, dogmatic, and even jingoistic), to soapbox about what this thing 
is for, to
rather than find value and positives define negatives and ills, to proscribe.

For comparison, I'd champion Larry Wall's Perl: a super flexible language, but 
what I love
more than anything else is how a-dogmatic it was, an explicitly post-modern 
language with
an explicitly post-modern culture, where people didn't tell each other what to 
think or do
and couldn't do otherwise in any kind of definitive manner because there were a 
dozen ways
to do a thing: liberty came standard. Even if you were using it to shoot 
yourself in the
foot, the guy on the other side of the lab can be using feature X or factor Y 
to great
effect.
 
Make options available, help people see what things are possible.  That's 
humble, that's
respectful, and speaks to an understanding that lasting things grow and change 
and take on
new roles. If we knew all the answers, we'd have built ourselves 
all-too-sterile and
flavorless an environment.

Threads are great. Fact. Better than processes (at at least context switching 
and
transfering objects). Fact. And like most great powers, they come with great 
responsibility
(more than processes, fact). Which isolates, WebMessaging all support, all work 
to harness
the capabilities of while insuring they are used responsibly.



Fwiw, Rust is going to be a serious language to look at because it has such 
deeply ingrained
respect for safe concurrent containers. And continuing my opining, Node owes 
itself
isolates, it's parallel: threads are faster context switches than processes, 
and threads allow
Transferable, both are clear safe wins with zero risk or cost to non-users. 
Threading is a
feature, one from a usage standpoint that need not be any different than
child_process.fork(), and it's one I hope Node.js comes back to to continue 
being a
pre

[nodejs] Re: Threading, and Dogmatisms.

[rektide]

Google is too smart for me. I wrote this reply as a new thread, and Google 
has attached it to the old one. Apologies, but I am about to repost it 
sans-excerpts.

-r

-- 
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] Threading, and Dogmatisms.

[rektide]

TL;DR: 

1. Threads are a feature, one that will unlock new exciting things we can do 
and make
existing features better (namely child_process.fork()).
2. We don't have that feature is not a feature, is not a pro.
3. Being dogmatic about what others ought do is bad: accept if not embrace 
input liberally.
4. Doing threads, safe concurrency right is what makes Rust so attractive, and 
Node can do
it safely, cleanly too and nearly did, in the isolates branch.
https://github.com/joyent/node/tree/isolates

Onwards:

On Sat, Sep 15, 2012 at 11:32:56AM -0700, Mark Hahn wrote:
@rektide, are you saying that joyent is asleep at the wheel because they
are stopping the community from using threads?�
The community doesn't want threads because they violate the founding
principle of Node, which is to use non-blocking event loops and get rid of
threads.

violate the founding principle?
community doesn't want?

As for doesn't want and founding principles, before threads became an awful 
horrible
thing the Node community would have nothing to do with ever, there was a 
feature that got
canned for being too complicating called Isolates, that, shock and awe, Node 
leads were hard
at work on which would have added threading as a drop in replacement for 
child_process.fork().
Certainly no one was calling the feature anti-Node at the time, it would have 
been an
implementation detail, offered the same functionality as already exists in Node 
today, and
would have made us capable of doing more.
https://groups.google.com/forum/?fromgroups=#!msg/nodejs/zLzuo292hX0/F7gqfUiKi2sJ
https://github.com/joyent/node/tree/isolates

Threading is not evil. Shared state is evil. Which is why the rest of the 
JavaScript world
has Transferables, a way to move ownership of an object from one isolated 
thread/container
to another. Processes preservation [read: apropo exclamative], Node is already a
multi-reactor not a reactor, and there's no harm, nothing but technical gain 
(faster context
switches, Transferables), from allowing that multi-reactor to run on threads as 
easily as it
runs on processes. Aside from the work to get there, there's no cause to keep 
ourselves
locked in to just using processes.
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#transfer-a-transferable-object

I'm not at all saying Joyent is asleep at the wheel. They punted on this topic, 
this big
hard hairy to implement topic: fine. It does hurt us, is a killer feature a 
mature runtime
ought have in it's toolkit, but I have faith eventually we'll go to bat on the 
topic again
in a serious manner in due time and I'm not sweating the innings lost between 
now and then.
In the mean time, Joyent has been doing great things with Node and I'm 
delighted they
continue doing so much to further Node.



I know Ryah has gone on twitter and said he still sees Node as a web runtime. 
Isaac has
similarly lamented allowing other languages to play in Node's pool.  Online 
discussions have
a lot of people defending node's lack of threading. I think much of this makes 
us look bad,
(hipster-ish, dogmatic, and even jingoistic), to soapbox about what this thing 
is for, to
rather than find value and positives define negatives and ills, to proscribe.

For comparison, I'd champion Larry Wall's Perl: a super flexible language, but 
what I love
more than anything else is how a-dogmatic it was, an explicitly post-modern 
language with
an explicitly post-modern culture, where people didn't tell each other what to 
think or do
and couldn't do otherwise in any kind of definitive manner because there were a 
dozen ways
to do a thing: liberty came standard. Even if you were using it to shoot 
yourself in the
foot, the guy on the other side of the lab can be using feature X or factor Y 
to great
effect.
 
Make options available, help people see what things are possible.  That's 
humble, that's
respectful, and speaks to an understanding that lasting things grow and change 
and take on
new roles. If we knew all the answers, we'd have built ourselves 
all-too-sterile and
flavorless an environment.

Threads are great. Fact. Better than processes (at at least context switching 
and
transfering objects). Fact. And like most great powers, they come with great 
responsibility
(more than processes, fact). Which isolates, WebMessaging all support, all work 
to harness
the capabilities of while insuring they are used responsibly.



Fwiw, Rust is going to be a serious language to look at because it has such 
deeply ingrained
respect for safe concurrent containers. And continuing my opining, Node owes 
itself
isolates, it's parallel: threads are faster context switches than processes, 
and threads allow
Transferable, both are clear safe wins with zero risk or cost to non-users. 
Threading is a
feature, one from a usage standpoint that need not be any different than
child_process.fork(), and it's one I hope Node.js comes back to to continue 
being a
pre

[nodejs] Re: Threading, and Dogmatisms.

[rektide]

Thanks so much for the informative reply: that's a lot of things I don't 
know about! 

On Sunday, September 16, 2012 6:22:50 PM UTC-4, Bradley Meck wrote:

 There are long discussions in the Node community about what happened when 
 we did try to use Isolates. The lack of thread level protections from 
 things like mucking with process.* 


Caveat emptor, doesn't seem like a real issue, just a fact of life.
 

 and the fact that native modules need to add complex support for Isolates 
 to be first class (many C level libraries deal poorly with Isolates due to 
 them not being exactly like threads from what I understand) are fairly well 
 discussed. 


This in particular would be great to read about! This seems like the chief 
potential show-stopper, and most open ended problem.
 

 In addition things like C's abort(), and any shared memory still cause 
 problems with Isolates.


I'm less willing to say caveat emptor here, sounds harrier, but again 
doing it and creating potential problems (particularly if they're exit 
case problems) seems preferable to not doing it.
 

 It would be interesting to delve into these problems, but for example if 
 you use rust the runtime has explicit knowledge of threads rather than v8 
 so you can reduce most of the problems with concurrency to message passing 
 and the same problems as process.* 

People who complain about threads generally do not have in depth knowledge 
 of difficulties in doing so with Node's environment, but should feel free 
 to look them up and discuss solutions rather than simply stating it should 
 have threads. 


I have done some attempts at research on the topic: this has been 
considerably more informative than any threads I've turned up. Perhaps I 
was doing my search wrong. That all said, apologies for not being able to 
bring a more balanced perspective to my should have threads stance, I 
would like to be able to do better.
 

  personally really like what Threads a Go Go does, but it still faces the 
 difficulties listed above difficulties when you start to delve deep into it.


Thanks for contributing. 

  


-- 
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] Crockford : Ynode : I would fork node.js

[rektide]

On Sat, Sep 15, 2012 at 04:56:40PM +0200, Arnout Kazemier wrote:
 Pull request or it didn't happen

Hi:

https://github.com/xk/node-threads-a-gogo , or preferrably some better isolated 
manner of
multi-threading with Transferable objects. 

 On 15 sep. 2012, at 16:45, Jorge jo...@jorgechamorro.com wrote:
  http://www.youtube.com/watch?v=8HzclYKz4yQ#t=22m30s
  
  I would fork nodejs. Nodejs is a great thing and I would bet the company 
  on it, but I
  would not bet the company on Joyent. I see Joyent doing some stuff which is 
  amateurish,
  maybe a little chidish, so I would fork it, and, I would then give that 
  back to the community,
  and it would be industrial strength and secure and designed to operate a 
  Yahoo scale and would
  make it available for everybody for free

-- 
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] Looking for a good xml parser in stream mode

[rektide]

On Thu, Aug 30, 2012 at 02:05:21PM +0800, jason.桂林 wrote:
A protocol using xml, socket stream
first time I recieve 
root foo=  
2nd time I recieve
 adsfblabl
3rd time I recieve
a/rootroot
Then I should get a xml root foo=asdfblabla/root , and left root
waiting for new coming data.
Any good module to do that?

Still hoping someone makes an streaming Xpath module for Ltx, which seems to be 
the fastest
streaming xml module out there:
https://npmjs.org/package/ltx

There's an existing xpath module but it's not streaming based:
https://npmjs.org/package/ltx-xpath

-- 
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: Why `fs.exists` has signature `(exists)` instead of `(err, exists)` ?

[rektide]

I would really really appreciate it if Node were to consistently get behind 
err being the first param, even when it's nonsensical.

Readline.question could stand being made from answer = void to err,answer 
= void as well.

On Friday, August 17, 2012 6:57:18 PM UTC-4, Alexey Petrushin wrote:

 Wondering why `fs.exists` doesn't comply to async methods pattern and 
 doesn't return error as a first argument?

 It uses

 fs.exists('/etc/passwd', function (exists) {
   util.debug(exists ? it's there : no passwd!);});


 Instead of

 fs.exists('/etc/passwd', function (err, exists) {
   util.debug(exists ? it's there : no passwd!);});



-- 
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] webinos app contest

[rektide]

On Tue, Aug 07, 2012 at 01:10:39PM -0700, Andreas M. Botsikas wrote:
Hi all,

webinos is a cross device platform built entirely on top of node js and is
organizing an application competition so I thought of sharing this with
you just in case you want to do a summer project and win some cool prizes.

More info at [1]http://bit.ly/webinoscomp

From the site:

 What are the cool prizes then?

 We're cross-screen so we stay true to our word! We'll throw in a mix of
 state-of-the-art mobile handsets, tablets and uber-cool android-on-a-stick
 devices. Stay tuned for more details in the comming days!

Make it a BMW and I'll build you the best damned app ever.

Any way you want to lend me one to prototype out my application?

This banter is of course appropriate, as due this cause:
http://dev.webinos.org/specifications/draft/vehicle.html


Just to co-plug ya'll, since you're gonna hook me up with an 2014 M5 now,

Webinos is _awesome_ stuff. So, portable JavaScript sandbox for apps and 
services,
awesome, but, you ask, didn't Es, WebOS, Google Extensions,  soon Tizen all do 
the
same thing?

The killer feature for me is the Personal Zone Proxy, which turns Webinos into 
a fully
connected service mesh overlay of all your devices and services, wherever you 
go. I
submitted my own internetworking challenge to Knight's Network Challenge for a 
similar
construct, 
http://newschallenge1.tumblr.com/post/19482119635/extend-dbus-internetworking-to-the-www

, more protocol oriented (DBus) than your blind-runtime-just-makes-it system, 
but
the idea is near and dear to my heart, and to I think the omni-connected 
ubicomp nerd posse
out there. I haven't done any hardcore in depth review on Webinos's 
architecture in the past
month or two, but webinos goes really far with this concept, there are Personal 
Zone Hubs
which is a central relay for a perons's available Servies, and Personal Zone 
Proxies PZP
which form satellites to make all your Personal Hub services available, and you 
can talk to
other PZP's. There are Applications which can use anything in your Personal 
Zone. It's all
some very cool overlay/ internetworking tech, I think there may be provisions 
for sharing of
services across users beyond the core across device sharing it has. All to make 
a slick
cross device JavaScript runtime for Applications using Services found across 
devices.

Or, something to that effect. Andreas or anyone, is it possible to share 
services between
users? Can't remember what inter-user activity is possible.

Everyeone: Participate or no, I think everyone owes it to themself to check out 
some Webinos.

Ok, way late for the nerdiest of nerdy meetups, our regular EVE Online meetup. 
Cya all
later, 
-rektide

PS: https://plus.google.com/113218107235105855584/posts is my G+. JS, Ubicomp, 
hardware,
space,  writing at least as good/brain meltingly horrible as the above. Say hi.

-- 
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] Where is the app.request() function from Connect's tests defined?

[rektide]

Hi node.js, I'm hoping someone is willing to lend me a pair of eye balls and 
tell me what
I seen unable to spot with my own:

There are 170 separate uses of an 'app.request()' method in Connect's tests[1], 
but I cannot
seem to find where this function is defined! I'm expecting to find it somewhere 
in the main
Conenct lib[2] but after having cruised through the couple files in there a 
couple of times,
I still haven't found where this is defined.

Can anyone help point me to what I'm missing please? Thanks!

[1] https://github.com/rektide/connect/tree/master/test
[2] https://github.com/rektide/connect/tree/master/lib

-- 
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] NodeConf SummerCamp

[rektide]

Oh boy I wish this was in the cards for me this year. Camping  node: the only 
downside is
having to come back to the real world after.

On Wed, Jul 25, 2012 at 09:58:37AM -0700, Mikeal Rogers wrote:
 It's that time of year again :)
 
 We're returning to Walker Creek Ranch for another unconference on node.js. 
 All the details, and pictures from last year, are up at:
 
 http://www.nodeconf.com/
 
 Tickets are available now. You can purchase a ticket with a bed in a shared 
 room or choose to bring your own tent and sleeping bag and get a reduce rate 
 CampOut ticket. Significant others and kids are also welcome, just register 
 them for the relevant SO ticket for a small fee (10 - 30 dollars). And we're 
 running a shuttle up to the camp from SF twice on the 4th.
 
 We've talked about it on NodeUp a few times but SummerCamp is the most 
 important conference/meetup related thing we do. While NodeConf is great and 
 a tremendous effort by all those involved, SummerCamp is where we get 
 together and figure out the direction that node.js needs to go and we really 
 need input from a wide range of people, including newcomers, so I can't 
 encourage people enough to come out and join us.
 
 -Mikeal

-- 
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] remoteable events

[rektide]

Hi nodejs group,

Any suggestions for drop-in enhancements/replacements to EventEmitter which 
allow events to
replicate cross-process or across different systems?

Bonus points for anything that supports multiple transports!

-rektide

-- 
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] worker thread API for node?

[rektide]

I'd love to see this, but then, I was also hoping to see isolates, and was 
imaginging a
perfect fusion of the two. I don't believe there's any plan for either.

Background on isolates:
https://groups.google.com/forum/?fromgroups#!msg/nodejs/zLzuo292hX0/F7gqfUiKi2sJ

On Thu, Jul 12, 2012 at 01:35:49PM -0700, Brendan Miller wrote:
Is there any plan to implement a worker thread API for node similar to the
W3C spec?
[1]http://www.w3.org/TR/workers/
I see that there are third party implementations of this API, but I'm
wondering if something like this will end up in the core node
distribution.

-- 
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] Fwd: [CTTE #614907] Resolution of node/nodejs conflict

[rektide]

Glorious! So say we all!

`node` for all!

On Thu, Jul 12, 2012 at 11:41:39PM +0200, Carl Fürstenberg wrote:
 -- Forwarded message --
 From: Don Armstrong d...@debian.org
 Date: Thu, Jul 12, 2012 at 8:59 PM
 Subject: [CTTE #614907] Resolution of node/nodejs conflict
 To: debian-devel-annou...@lists.debian.org
 
 
 
 === Resolution ===
 The Technical Committee reaffirms the importance of preventing namespace
 collisions for programs in the distribution, while recognizing that
 compatibility with upstreams and with previous Debian releases is also
 important and that sometimes an imperfect balance must be struck between
 these three goals.
 
 The Committee therefore resolves that:
 
 1. The nodejs package shall be changed to provide /usr/bin/nodejs, not
/usr/bin/node.  The package shall declare a Breaks: relationship with any
packages in Debian that reference /usr/bin/node.
 2. The nodejs source package shall also provide a nodejs-legacy binary
package at Priority: extra that contains /usr/bin/node as a symlink to
/usr/bin/nodejs.  No package in the archive may depend on or recommend
the nodejs-legacy package, which is provided solely for upstream
compatibility.  This package shall also declare a Conflicts: relationship
with the node package.
 3. The node source package shall rename its binary to /usr/sbin/ax25-node,
and its binary package to ax25-node.
 4. The node source package shall continue to build a transitional 'node'
binary package for compatibility with deployed Debian installations,
which provides /usr/sbin/node as a symlink to /usr/sbin/ax25-node.  This
package shall declare a reciprocal Conflicts: relationship with the
nodejs-legacy package.  Other packages may reference the 'node' package
as a dependency or recommendation, but are encouraged to transition to
'ax25-node'.
 5. The maintainers of these packages are required to implement the above
changes immediately in unstable.  Failing that, the Technical Committee
reserves the right to NMU to implement these changes.
 6. Once the above changes are implemented, the packages shall be considered
suitable for release with respect to the Debian policy on conflicting
packages.
 
 === End Resolution ===
 
 Please see http://bugs.debian.org/614907 for the background and discussion.
 
 
 Don Armstrong
 
 --
 I may not have gone where I intended to go, but I think I have ended
 up where I needed to be.
  -- Douglas Adams _The Long Dark Tea-Time of the Soul_
 
 http://www.donarmstrong.com  http://rzlab.ucr.edu
 
 
 -- 
 Carl Fürstenberg

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

[rektide]

 but has ultimately turned out to cause too much instability in node's 
 internal functionality to justify continuing with it at this time.

please specify, elaborate, explain or make note upon this conflict, as
if in warning to those who would have wished to pursue the cause
further.

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