PageRenderTime 68ms CodeModel.GetById 20ms RepoModel.GetById 1ms app.codeStats 0ms

/data/irc-logs/raw/2010-11-21.txt

https://github.com/Marak/node-stats
Plain Text | 1852 lines | 1852 code | 0 blank | 0 comment | 0 complexity | 16f3e0604e28f71070d558fcbf65258f MD5 | raw file

Large files files are truncated, but you can click here to view the full file

  1. [00:04] mscdex has joined the channel
  2. [00:06] ilpoldo has joined the channel
  3. [00:07] vdrab has joined the channel
  4. [00:07] saml has joined the channel
  5. [00:08] tapwater has joined the channel
  6. [00:08] saml: so module loading is not asynchronous!
  7. [00:08] Aria: Nope.
  8. [00:09] tanepiper: not yet anyway
  9. [00:10] tanepiper: it's still not commonjs standard, athough there is a spec out there for it
  10. [00:11] Aria: As much as commonjs /is/ a standard.
  11. [00:11] c4milo has joined the channel
  12. [00:11] saml: so things can block during loading
  13. [00:11] saml: is there a way to preload stuff before event loop even starts?
  14. [00:11] Aria: Sure. Put it at the top ;-)
  15. [00:12] SvenDowideit_ has joined the channel
  16. [00:13] atmos has joined the channel
  17. [00:14] zimbatm has joined the channel
  18. [00:15] henrikh has left the channel
  19. [00:18] tanepiper: cloudhead: ping
  20. [00:19] galaxywatcher has joined the channel
  21. [00:20] monokrome: Anyone know what to do about "ReferenceError: StopIteration is not defined"
  22. [00:20] jashkenas: monokrome: don't use StopIteration outside of firefox.
  23. [00:20] monokrome: Only reason that I'm using it is because someone in here told me to :/
  24. [00:21] jashkenas: Idle question: Why is it that Node includes ["node", "path/to/script.js"] in process.ARGV? Why isn't it preferable for ARGV to just include the actual arguments passed?
  25. [00:21] jashkenas: monokrome: you can feature-detect it if you like: http://documentcloud.github.com/underscore/docs/underscore.html#section-5
  26. [00:22] tanepiper: jashkenas: nope, expected behaviour for args
  27. [00:22] tanepiper: for example, python does the same thing
  28. [00:22] jashkenas: Ruby does not -- it just gives you the real arguments.
  29. [00:23] jashkenas: I mean, does anyone use the first two args for anything productive, or is there a lot of process.ARGV.slice(2) going on here?
  30. [00:23] jashkenas: (not that I'm suggesting it should be changed and break things ... just curious if there's a use-case.)
  31. [00:25] tanepiper: well i've never coded ruby, but other languages i have always have the full arg string as an array, including the calling program
  32. [00:25] jashkenas: tanepiper: have you personally ever used the first two args?
  33. [00:27] tanepiper: personally, no, but if it's there i'm sure others do. unix geeks do weird things
  34. [00:30] tanepiper: hmm, this is the weirdest damn bug in cradle :(
  35. [00:31] tanepiper: saves fine for existing documents, crashes on saving new ones
  36. [00:31] confoocious has joined the channel
  37. [00:35] tanepiper: ahh bloody depricated features
  38. [00:38] Tim_Smart has joined the channel
  39. [00:38] charlenopires has joined the channel
  40. [00:39] teemow has joined the channel
  41. [00:40] teemow has left the channel
  42. [00:40] RevoOf has left the channel
  43. [00:40] noahcampbell has joined the channel
  44. [00:41] monokrome: path doesn't have a method for converting the path to an absolute path?
  45. [00:42] sstephenson: fs.realpath
  46. [00:42] monokrome: ah
  47. [00:43] monokrome: you'd think it'd be: path.real :)
  48. [00:43] monokrome: thank you
  49. [00:44] cloudhead: tanepiper: sup
  50. [00:45] Tim_Smart: monokrome: Not really, path are just utility functions, whereas realpath is a syscall
  51. [00:45] Tim_Smart: fs contains the file system syscalls
  52. [00:45] tanepiper: cloudhead: nothing, fixed it in the end - my code was randomly still using an insert somewhere
  53. [00:46] cloudhead: ah : )
  54. [00:46] tanepiper: npm version wasn't telling me, just saying Object didn't have query
  55. [00:46] tanepiper: but head version told me it was depricated so i was able to trace it
  56. [00:46] cloudhead: oh
  57. [00:46] cloudhead: yea, it's @latest on npm
  58. [00:46] kriszyp has joined the channel
  59. [00:48] cloudhead: Is there a way I can use `global` to set global vars?
  60. [00:48] cloudhead: doesn't seem to work
  61. [00:49] tanepiper: global.foo = 'bar'; not working for you?
  62. [00:50] jashkenas: global should work.
  63. [00:50] arpegius has joined the channel
  64. [00:51] maushu: Dammit, I wonder if I'm making my project way too interfacy.
  65. [00:53] masahiroh has joined the channel
  66. [00:54] cloudhead: jashkenas: tanepiper: so I should be able to access the same object in all required() modules?
  67. [00:54] jashkenas: yep.
  68. [00:54] cloudhead: ok, guess I'll try that again
  69. [00:54] jashkenas: I use it for making tests easier... global[key] = value for key, value of require('assert')
  70. [00:55] jchris has joined the channel
  71. [00:59] killfill has joined the channel
  72. [01:00] cloudhead: jashkenas: k I got it. The weird thing is if you console.log(global), it'll look empty no matter what..
  73. [01:02] InsDel has joined the channel
  74. [01:03] tanepiper: cloudhead: you can also do exports.foo = bar
  75. [01:03] tanepiper: then use module.parent.exports
  76. [01:03] isaacs: ryah: hey, i figured out a workaround. it sucks a lot, though
  77. [01:04] isaacs: ryah: just doing the readStream.resume() on a process.nextTick in utils.pump makes it work, but it also makes pump() really slow.
  78. [01:05] isaacs: ryah: the problem seems to be that write() returns false, and then somehow emits "drain" before the readStream is actually paused.
  79. [01:05] killfill has joined the channel
  80. [01:05] isaacs: but that seems like it makes no sense.
  81. [01:06] isaacs: the flow seems to be: write() returns false, writeStream emits "drain", readStream resumes, readStream gets paused
  82. [01:06] isaacs: and then at that point, it's halted.
  83. [01:07] isaacs: i'm looking at the code, though, and it does not do that.
  84. [01:07] isaacs: I notice that I am confused. My mental model is making inaccurate predictions.
  85. [01:13] ryah: isaacs: hm
  86. [01:13] isaacs: ryah: sense makes this none, right?
  87. [01:14] isaacs: the fact that wrapping the readStream.resume() in a nextTick actually works is really strange.
  88. [01:14] isaacs: also, it's not a solution, because it makes things crazy slow
  89. [01:14] ryah: i'm afraid my house might be blown down
  90. [01:14] ryah: :(
  91. [01:14] aubergine has joined the channel
  92. [01:14] isaacs: little pig little pig...
  93. [01:15] dnolen has joined the channel
  94. [01:16] aubergine_ has joined the channel
  95. [01:16] isaacs: ryah: have the semantics chaned at all wrt write() returning false, or "drain" being emitted?
  96. [01:16] ryah: isaacs: can you turn on the debug output and see what it looks like - you have to set -DDUMP_DEBUG in build/c4che/default.build.py
  97. [01:16] ryah: isaacs: in the CPPFLAGS
  98. [01:16] ryah: and recompile
  99. [01:17] isaacs: right, i just added a bunch of process.binding("stdio").writeError in utils.js
  100. [01:17] isaacs: and my own logging in npm, as well. seems to confirm
  101. [01:17] ryah: so that it looks like this
  102. [01:17] ryah: CPPFLAGS = ['-DDUMP_DEBUG', '-DHAVE_OPENSSL=1', '-DEV_FORK_ENABLE=0', ...
  103. [01:17] isaacs: sure, i'll try that
  104. [01:18] killfill has joined the channel
  105. [01:18] ryah: build/c4che/default.cache.py i meant
  106. [01:18] tilgovi has joined the channel
  107. [01:18] isaacs: right
  108. [01:21] jchris has joined the channel
  109. [01:23] unomi has joined the channel
  110. [01:25] isaacs: yeah, it's definitely ending on a write() returning false, and then pausing, and never draining
  111. [01:26] aubergine_ has joined the channel
  112. [01:26] JimRoepcke has joined the channel
  113. [01:28] isaacs: ok, an equally hacky, but much faster solution: don't pause() the readStream unless write() returns false twice.
  114. [01:28] isaacs: and don't resume() the readStream unless i'ts actually been paused.
  115. [01:30] mjr__ has joined the channel
  116. [01:30] isaacs: my suspicion there is that write() is returning false when it shouldn't.
  117. [01:32] jchris has joined the channel
  118. [01:36] ryah: yeah
  119. [01:36] ryah: stream._writeWatcher.queueSize would be interesting to see
  120. [01:36] ryah: since that determines when it returns false...
  121. [01:36] isaacs: interesting
  122. [01:37] ryah: https://github.com/ry/node/blob/15d5378684e630e341d674c7f67aecb76bd802c6/lib/net.js#L337
  123. [01:38] atmos has joined the channel
  124. [01:40] isaacs: ryah: yeah, at least some of the time, the writeWatcher.queueSize is 0, but it's still returning false.
  125. [01:41] ryah: ok
  126. [01:41] ryah: well that's not good :)
  127. [01:43] isaacs: var ww = writeStream._writeWatcher ; ww = ww ? ww.queueSize : "writeWatcher is falsey" ; x("pump PAUSE "+ww);
  128. [01:43] isaacs: and i'm seeing: "pump PAUSE 0" and then it never returns from that state.
  129. [01:43] bmizerany has joined the channel
  130. [01:47] tilgovi has joined the channel
  131. [01:47] isaacs: ryah: is it possible that the IOWatcher.flush() is flushing out the queue, so even though the queueSize WAS >64kb, it's no longer?
  132. [01:47] bsstoner has joined the channel
  133. [01:47] erlnoob has joined the channel
  134. [01:49] aubergine_ has joined the channel
  135. [01:49] ryah: yes
  136. [01:50] ryah: that might be it.
  137. [01:50] SvenDowideit has joined the channel
  138. [01:54] evanmeagher has joined the channel
  139. [01:55] isaacs: yes, that is it.
  140. [01:55] isaacs: hooray for one line fixes!!
  141. [01:55] ryah: :)
  142. [01:56] ryah: is there somehow you can reverse engineer a simple test?
  143. [01:56] ryah: these sort of things are super difficult to find - it's good to have tests
  144. [01:57] saschagehlich has joined the channel
  145. [01:57] isaacs: ryah: https://gist.github.com/708366
  146. [01:58] isaacs: lightening!!
  147. [01:58] isaacs: the gods approve of this patch!!
  148. [01:58] isaacs: is ther a way to cork a writeStream?
  149. [01:59] isaacs: you could cork it, write 64*1024+1 bytes, uncork, write 1 byte, and that'd at least have a very high probability of encountering the problem.
  150. [01:59] isaacs: another option would be to stub out a fake IOWatcher that *always* flushes everything
  151. [01:59] isaacs: (by throwing it away)
  152. [02:00] halfhalo has joined the channel
  153. [02:00] halfhalo has joined the channel
  154. [02:04] cjm has joined the channel
  155. [02:04] polotek: whew
  156. [02:04] polotek: that was harder than it should've been
  157. [02:04] polotek: ryah: https://github.com/polotek/node/commit/2dd8dc962c804934107123dcb892b1a7c1d1c7a7
  158. [02:05] isaacs: yeah, writing tests for the repl is a bit of a chore
  159. [02:06] isaacs: polotek: when hacking on the repl, i usually pipe &2 to a different terminal, or a file, so that you can actually get debug output without screwing up what you're doing
  160. [02:06] isaacs: makes it a lot easier
  161. [02:07] polotek: isaacs: thx
  162. [02:07] polotek: I think the main problem was that I testing errors coming from the repl. testing for bad output is harder than testing for good :)
  163. [02:10] [[zz]] has joined the channel
  164. [02:16] polotek: haha, I'm screwing all kinds of stuff
  165. [02:16] polotek: can someone help me sort out this git stuff?
  166. [02:16] polotek: I had 2 commits for the repl stuff
  167. [02:16] polotek: and pushed them to my github fork
  168. [02:16] polotek: but then I decided to squash them into one
  169. [02:17] polotek: I did that locally and that's fine
  170. [02:17] polotek: but how do I update the github fork now?
  171. [02:17] polotek: it rejects my push because I changed the commit history
  172. [02:18] polotek: do I just --force ?
  173. [02:19] isaacs: yeah, just --force
  174. [02:19] isaacs: use the force
  175. [02:19] polotek: cool, that worked
  176. [02:20] isaacs: polotek: another option would be to pull from origin, revert the two commits in a new commit, and then apply the squashed commit, and push that
  177. [02:20] isaacs: but that's dumb
  178. [02:21] polotek: isaacs: this worked the way I wanted. killed the 2 commits at origin and rewrote the history
  179. [02:22] isaacs: yep
  180. [02:22] isaacs: for repos that serve as upstreams to a lot of people, --force pushes are not polite.
  181. [02:23] isaacs: because if i'd pulled from you, and made a bunch of changes, and then try to pull from you again a month after you've rebased out a commit i have in my history, then all the sha's change, and it's this big gnarly rebase.
  182. [02:23] isaacs: but it's unlikely that that's a big deal anyway
  183. [02:24] polotek: isaacs: yeah I hear
  184. [02:24] polotek: that's why I wanted to be sure what I was doing
  185. [02:26] alek_br has joined the channel
  186. [02:29] jchris has joined the channel
  187. [02:30] sivang: I now how to use nodelad!
  188. [02:30] sivang: jchris: ! :)
  189. [02:30] sivang: *know
  190. [02:30] evanmeagher: if a script times out on the line below, what could it be a symptom of?
  191. [02:30] evanmeagher: https://github.com/ry/node/blob/master/lib/net.js#L574
  192. [02:32] jamescarr has joined the channel
  193. [02:32] jamescarr: why does console have time and timeEnd methods?
  194. [02:32] jamescarr: I didn't know that console functioned as a stopwatch!
  195. [02:33] jamescarr: console.time('foo'); console.time('bar'); console.timeEnd('bar'); console.timeEnd('foo');
  196. [02:34] polotek: wtf. github pull requests aren't as clear as I thought they were
  197. [02:34] cainus_: hey all...any express users in here? the hello world example doesn't respond to http requests, and I'm wondering if the example's out of date, or if I'm just a total failure
  198. [02:34] sudoer has joined the channel
  199. [02:35] Aria: did you expect cherry-picks polotek?
  200. [02:35] jamescarr: cainus_, type express -v from the command line
  201. [02:35] cainus_: 1.0.0rc4
  202. [02:35] polotek: Aria: I thought I'd be able to pick 1 or more commits to include in the request
  203. [02:36] cainus_: it seems to be running... no errors, but it doesn't respond... I tried a few ports as well as accessing from localhost to make sure its not firewall related or something
  204. [02:36] sivang has left the channel
  205. [02:36] Aria: Yeah, that's cherry-picking. In general, not something to do if you can topic-branch instead.
  206. [02:37] jamescarr: cainus_, what port is it running on?
  207. [02:37] polotek: Aria: yeah I'll probably do that next time.
  208. [02:37] polotek: Anyway
  209. [02:37] polotek: ryah: http://groups.google.com/group/nodejs-dev/browse_thread/thread/952f369abb8bdbd2
  210. [02:38] cainus_: tried 3000, and 8080
  211. [02:38] jamescarr: gist the code
  212. [02:38] cainus_: it's the example at the top of http://expressjs.com/guide.html
  213. [02:39] cainus_: http://expressjs.com/guide.html#Creating-An-Application is a better link
  214. [02:39] jamescarr: it works
  215. [02:40] jamescarr: did you run localhost:3000 ?
  216. [02:40] agnat has joined the channel
  217. [02:40] cainus_: yeah wget localhost:3000
  218. [02:40] jamescarr: also, did you install via npm?
  219. [02:40] cainus_: yes via npm
  220. [02:41] cainus_: "Connecting to localhost|127.0.0.1|:3000... failed: Connection refused."
  221. [02:41] jamescarr: well, you should probably just upgrade. TJ released express 1.0 a co uple days ago
  222. [02:41] jamescarr: also, are you SURE your server is running? :)
  223. [02:41] cainus_: I put a sys.print("got here") just before the last line even and it got there
  224. [02:42] cainus_: and it's in ps
  225. [02:42] jamescarr: just do a npm install express and try again :)
  226. [02:44] cainus_: nope... still no luck
  227. [02:44] jamescarr: how are you running it?
  228. [02:44] jamescarr: node app.js ?
  229. [02:44] cainus_: heh must be something I'm doing
  230. [02:44] cainus_: yeah
  231. [02:45] jamescarr: replace the last line with app.listen(3000, function(){ console.log('running on port 3000');});
  232. [02:45] jamescarr: ?
  233. [02:45] jamescarr: and try again?
  234. [02:46] cainus_: wow that worked
  235. [02:46] cainus_: ??!?
  236. [02:47] cainus_: it needs the callback?
  237. [02:47] jamescarr: the server running?
  238. [02:47] jamescarr: no, it doesnt need a callback
  239. [02:47] cainus_: yeah it responds now
  240. [02:47] jamescarr: the callback just gets called on server startup
  241. [02:47] cainus_: but the only diff is the callback
  242. [02:47] jamescarr: take it out, rerun, and try again
  243. [02:48] jamescarr: but leave app.listen(3000) in
  244. [02:48] cainus_: refused without the callback
  245. [12:48] frigg: VERSION
  246. [12:48] nodelog has joined the channel
  247. [12:52] Wizek: tanepiper: Yes, I think. But what is nto?
  248. [12:52] tanepiper: not
  249. [12:52] tanepiper: typo :)
  250. [12:53] Wizek: tanepiper: Chrome sends GET, so I quess it is
  251. [12:53] Wizek: *guess
  252. [12:53] Nohryb has joined the channel
  253. [12:53] Wizek: tanepiper: But how does that help me?
  254. [12:54] Wizek: Also, how can I access the request body with Node?
  255. [12:54] arpegius has joined the channel
  256. [12:54] tanepiper: are you building a website?
  257. [12:55] Wizek: tanepiper: I'm mainly experimenting and learning Node, but yes, if I find it suitable, I'll use it
  258. [12:55] tanepiper: you might be better looking at an existing framework build on top of nodejs
  259. [12:55] SubStack: connect is a good place to start I think
  260. [12:55] tanepiper: expressjs, geddy, meryl (personally i use expressjs)
  261. [12:56] tanepiper: indeed, express is built on connect so you have the power of both :)
  262. [12:57] Wizek: Well, I have bad experience with frameworks for node. First, npm doesn't work in Cygwin, and I found the documentation lacking of most of these, so I feel there is nowhere to start
  263. [12:57] SubStack: http://expressjs.com/
  264. [12:58] arpegius has joined the channel
  265. [12:58] SubStack: Wizek: it seems to be possible to install npm on top of cygwin
  266. [12:59] SubStack: http://elegantcode.com/2010/11/08/taking-baby-steps-with-node-js-introduction/
  267. [12:59] arpegius has joined the channel
  268. [13:02] mikedeboer has joined the channel
  269. [13:03] Wizek: SubStack: I've done just that, and it halted with error
  270. [13:04] Wizek: SubStack: http://prntscr.com/17bkd
  271. [13:04] Wizek: So even after extensive seraching, I couldn't get npm onto my cygwin
  272. [13:04] rajeshsr has joined the channel
  273. [13:05] SubStack: http://groups.google.com/group/npm-/browse_thread/thread/561e1c54b8da6b90
  274. [13:06] SubStack: which links to the solution here: https://github.com/isaacs/npm/issues/issue/79/#comment_301690
  275. [13:09] Locke23rus has joined the channel
  276. [13:13] delapouite has joined the channel
  277. [13:20] rkieffer has joined the channel
  278. [13:24] Wizek: SubStack: The solution links here: https://github.com/ry/node/wiki/Building-node.js-on-Cygwin- <-- which has been deleted. I don't know what step 4 is, or what to add to that conf.
  279. [13:25] SubStack: here it is: https://github.com/ry/node/wiki/Building-node.js-on-Cygwin-(Windows)
  280. [13:26] fly-away: hi2all
  281. [13:26] kriszyp has joined the channel
  282. [13:26] fly-away: is there some books or papers about nodejs programming patterns?
  283. [13:27] mscdex: node builds fine on cygwin
  284. [13:28] mscdex: the only thing i did was build and install gcc4.4.3 instead of 3.x which is what cygwin still has
  285. [13:28] mscdex: the rest is the same as plain linux
  286. [13:28] mscdex: configure, make, make install
  287. [13:28] liar has joined the channel
  288. [13:28] mscdex: i've never tried npm though
  289. [13:28] Wizek: SubStack: WOW! Thanks a lot! I can't believe I was once so close to this solution, but gave up and tried another thing! lol. Ty very much
  290. [13:29] SubStack: succeeding is hard
  291. [13:30] cnu has joined the channel
  292. [13:32] masahiroh has joined the channel
  293. [13:37] Wizek: tanepiper: So, now I have express, and connect inside, back to the initial issue: how does express help me with what I do?
  294. [13:38] jashkenas has joined the channel
  295. [13:43] kaichen has joined the channel
  296. [13:46] Wizek: Like, how can I access the request body (from server), either with express, or with plain Node?
  297. [13:47] stephank has joined the channel
  298. [13:50] rkieffer: anyone here know what the status of http://nodul.es/ is? Is that being actively developed?
  299. [13:53] rkieffer: One thing the npm world desperately needs is a place for community feedback - e.g. comments & ratings.
  300. [13:53] kaichen has joined the channel
  301. [13:58] niko has joined the channel
  302. [14:02] iszak has joined the channel
  303. [14:02] iszak has joined the channel
  304. [14:07] saschagehlich: does anyone know a really good video search engine with an api where you can set which video sites should be crawled?
  305. [14:07] pagameba has joined the channel
  306. [14:17] atmos has joined the channel
  307. [14:23] spetrea has joined the channel
  308. [14:25] mklappst1hl has joined the channel
  309. [14:29] ntelford has joined the channel
  310. [14:32] matjas has joined the channel
  311. [14:36] iszak: Hmm, that is unusual. I can access http.ServerResponse however I cannot access http.ServerRequest.
  312. [14:40] Wizek: How do I access request body from Node?
  313. [14:40] iszak: in createServer?
  314. [14:40] Wizek: ye
  315. [14:40] iszak: the second parameter.
  316. [14:40] iszak: in the callback
  317. [14:42] Wizek: iszak: With that I can send a response. But I mean when a request comes in, and I can hev it's url with request.url, and it's method with request.method, but how to get it's body?
  318. [14:42] Wizek: iszak: Like if it's a PUT
  319. [14:43] iszak: oh right.
  320. [14:43] liar has joined the channel
  321. [14:44] fangel: Wizek: you need to do a bind on the data and end-events of the http.ServerResponse..
  322. [14:45] fangel: Wizek: ie var body = ''; req.on('data', function(chunk) { body += chunk; }); req.on('end', function() { /* now the PUT'ed file is in the variable 'body' */ });
  323. [14:45] ooooPssss has joined the channel
  324. [14:46] iszak: i don't actually know how to get the data.
  325. [14:47] iszak: fangel, the data event.
  326. [14:48] fangel: check http://nodejs.org/docs/v0.3.1/api/http.html#http.ServerRequest - my example should work..
  327. [14:49] Wizek: fangel: Wow, nice
  328. [14:49] Wizek: ty
  329. [14:50] wdperson has joined the channel
  330. [14:51] fangel: np
  331. [14:52] MattJ has joined the channel
  332. [14:52] iszak: I must say the whole event driven design certainly makes your brain work.
  333. [14:53] fangel: I guess.. I don't find it that hard anymore, so give it time :)
  334. [14:53] _mql has joined the channel
  335. [14:54] iszak: Not so much hard.
  336. [14:54] SubStack: unfamiliar
  337. [14:54] SubStack: my brain hurts when I try to write procedural code anymore
  338. [14:55] SubStack: C macros are a poor substitute for higher-order combinators
  339. [14:56] iszak: heh.
  340. [14:57] iszak: I guess when you write low level JS you're still writing OO.
  341. [14:57] cognominal has joined the channel
  342. [14:57] mbrochh has joined the channel
  343. [14:57] sveimac has joined the channel
  344. [14:58] _mql: Hey! In an express.js app, how would you protect entire actions from being executed when the there's no user assigned to the current session (I'm looking for some sort of ensure_authorized/authenticated filter)
  345. [15:00] sveimac_ has joined the channel
  346. [15:01] _mql: Would I implement my own middleware for that… that prematurely sends a 401-response when the user is not logged in? How could this work for certain but not all routes…?
  347. [15:03] mbrochh: _mql, i saw examples for this... you can define some helper functions that check for authorization and add them to the route's parameters or so
  348. [15:03] _mql: I guess some code snippets regarding express.js authentication / authorization would already help. I'm going to not use an auth-framework, since I want to do the authorization logic (which will be straight-forward) myself.
  349. [15:04] faust45 has joined the channel
  350. [15:04] mbrochh: _mql, http://expressjs.com/guide.html#Route-Middleware read on from there
  351. [15:05] _mql: mbrochh: yeah that would be helpful.
  352. [15:05] iszak: we need monolithic libraries.
  353. [15:05] mbrochh: _mql, never tried it but looks simple enough :)
  354. [15:05] _mql: Mhh sure. I shouldn't be that lazy with reading the docs ^^
  355. [15:06] derren13 has joined the channel
  356. [15:06] _mql: But you can't remember some code snippets that implement such a authentication middleware?
  357. [15:06] SamuraiJack has joined the channel
  358. [15:07] iszak: It's hard to believe express js is the BEST we've got.
  359. [15:07] tanepiper: Zope used to be the best Python had
  360. [15:08] tanepiper: it was a few years before Django, Pylons, etc
  361. [15:08] iszak: If anyone wants to create a monolithic library I'm down for that.
  362. [15:08] iszak: Be more than happy to contribute.
  363. [15:08] iszak: more so "use at will".
  364. [15:10] _mql: Do you guys think it would make any sense (for a single-page web-app) to do the whole client/server communication via websockets, making the http layer obsolete?
  365. [15:10] saschagehlich: how can I do sth like "for i in [0...count]" in jade?
  366. [15:12] _mql: I'm already using web-sockets for realtime syncing text fragments.. but for all other actions I still use RESTful HTTP as usual...
  367. [15:12] rkieffer: saschagehlich: Use a script tag
  368. [15:12] rkieffer: I don't think jade does for loops like that - just the "each" enumeration.
  369. [15:13] saschagehlich: okay
  370. [15:14] _mql: Not sure if should go with just sockets ;) — http://substance.quasipartikel.at/ is the implied app I'm working on…
  371. [15:15] sstephenson: in an eco template, you can write exactly that: <% for i in [0...count]: %> ... <% end %>
  372. [15:15] iszak: I don't see the point in templating languages for node.js
  373. [15:16] SubStack: iszak: I have something interesting planned on the web frameworks front
  374. [15:16] iszak: SubStack, elaborate?
  375. [15:17] SubStack: I'm thinking it will merge routes, sessions, and dnode continuations
  376. [15:17] iszak: ...thinking or it does?
  377. [15:17] SubStack: thinking as in not entirely certain how it will work yet
  378. [15:18] SubStack: I have some notes and a few hypothetical code snippets is all at this point
  379. [15:18] SubStack: it's in my queue
  380. [15:18] iszak: eh, doesn't sound like what I want.
  381. [15:18] SubStack: what do you think would be super useful?
  382. [15:19] iszak: I would like to see an implemention of something like Zend Framework in Node.JS
  383. [15:19] SubStack: what does zend do that others don't?
  384. [15:19] Aikar: node is a lil young for that
  385. [15:19] iszak: well it emphasis's decoupling of components.
  386. [15:19] Aikar: the api is changing too much
  387. [15:19] SubStack: I want frameworks that play to node's strengths instead of just copying what other languages have
  388. [15:19] iszak: I know.
  389. [15:19] Aikar: all zend is is a collection of libraries
  390. [15:20] iszak: SubStack, yeah of course, no point going against the grain.
  391. [15:20] iszak: Aikar, indeed however it does provide MVC if you want to.
  392. [15:20] Aikar: so i think your more looking for an mvc in node lol
  393. [15:20] iszak: ZF is MVC.
  394. [15:20] herbySk has joined the channel
  395. [15:20] SubStack: Decoupling eh? My latest big project is just 4+n processes that all talk together over the network
  396. [15:21] Aikar: really its not much code to do it
  397. [15:21] SubStack: it's a webapp too
  398. [15:21] iszak: Aikar, but to do it right.
  399. [15:21] iszak: I don't know, I just feel a lot of the things we do in Node.JS is low level and for developing web apps that primitive things should be taken care off with convention over config approach.
  400. [15:21] SubStack: and you can kill any one of those processes and the rest of the system that doesn't directly depend on it remains operational
  401. [15:22] Aikar: app.get(':controller?/:method?:/?blah',function(req,res) { /handle/ });
  402. [15:22] Aikar: node isnt exactly tailored for throwing up basic websites
  403. [15:22] SubStack: and once the killed process comes back up all of the other processes know about it
  404. [15:22] Aikar: and id say the opposite, id say its more high level O.o
  405. [15:22] iszak: of course not, nor should it be restricted to just that.
  406. [15:23] Aikar: node isnt trying to be an httpd server
  407. [15:23] iszak: I don't see it wouldn't.
  408. [15:23] SubStack: oh right, and it launches tomorrow ;)
  409. [15:25] c4milo has joined the channel
  410. [15:25] Aikar: SubStack: what you use for IPC? I wrote up a parser based on the Node Network Protocol doc someone put up, so i figured a TCP link between the processes with nnp will be effecient
  411. [15:25] iszak: the good thing about doing it like zend framework is we can feed back the components into the community.
  412. [15:25] Aikar: thats what people are doing iszak
  413. [15:25] herbySk has joined the channel
  414. [15:25] Aikar: look at npm
  415. [15:25] Aikar: a giant collection of 'components'
  416. [15:25] SubStack: Aikar: dnode, which I wrote
  417. [15:25] Aikar: ah
  418. [15:26] iszak: Aikar, but it's only dribs and drabs here and there.
  419. [15:26] iszak: nothing like ZF.
  420. [15:26] Aikar: iszak: because node is a baby... zend is many years of building
  421. [15:26] SubStack: being able to throw around continuations like nobody's business is a very powerful technique, I found
  422. [15:26] Aikar: give it time
  423. [15:26] iszak: zend framework != zend, indeed.
  424. [15:26] iszak: Well I'm ready to start now.
  425. [15:27] Aikar: i know very well zend != zf im a PHP dev for 8 years :P i was justing it as short reference
  426. [15:27] Aikar: just using*
  427. [15:28] iszak: those ZF guys get really touche feeling about that.
  428. [15:28] Aikar: but really tho, have you looked at express js?
  429. [15:29] iszak: Yeah.
  430. [15:29] Aikar: express makes things extremely simple. you can build an mvc design on top of it within an hr of coding
  431. [15:30] iszak: it's not so much the MVC thing.
  432. [15:30] iszak: although it is.
  433. [15:30] iszak: it's just having all the components I need there, I don't want to have to go out and find middleware, it's time consuming to test them also.
  434. [15:30] Aikar: well if your just looking for a "large collection of prebuilt librarys", as i said before, node is just too young its slowly building up a library
  435. [15:30] iszak: But they'll be fragmented.
  436. [15:30] iszak: you'll still have to go and find them.
  437. [15:30] SubStack: what, node has a crazy number of libraries
  438. [15:31] SubStack: considering how young it is
  439. [15:31] Aikar: well you wont see that probally for years
  440. [15:31] rkieffer has left the channel
  441. [15:31] iszak: You're being very negative Aikar.
  442. [15:31] Aikar: no, im being realistic :/
  443. [15:31] iszak: Instead of saying it won't for ages, why not start now?
  444. [15:31] aconbere has joined the channel
  445. [15:31] SubStack: if you don't have something, build it
  446. [15:31] Aikar: because it would be silly
  447. [15:31] Aikar: node is changing too much
  448. [15:32] iszak: so stick to the stable versions.
  449. [15:32] SubStack: and share it so everybody else can benefit
  450. [15:32] iszak: 0.2.x, 0.4.x
  451. [15:32] SubStack: and help you fix bugs and such
  452. [15:32] Aikar: but yeah, you can start building stuff you need and feel free to release to public
  453. [15:32] SubStack: it's so easy too, just throw up a github project and npm publish
  454. [15:32] sveimac has joined the channel
  455. [15:33] iszak: SubStack, but then how do you sift through the crap from the good modules?
  456. [15:33] iszak: it takes time.
  457. [15:33] SubStack: not really
  458. [15:33] Aikar: look at the code, understand the code, use the code, make judgement
  459. [15:33] SubStack: if it's on npm, it's probably good to go
  460. [15:33] iszak: why doesn't it?
  461. [15:33] iszak: I am sure that's not the case.
  462. [15:33] SubStack: you can just npm install package and pow you're up and running
  463. [15:33] mbrochh has joined the channel
  464. [15:33] iszak: Aikar, and with something as large as a database adapter it's going to take MUCH longer.
  465. [15:34] Aikar: iszak: i think its safe to say anyone who is playing with node is likely not your run of the mill hello world php dev
  466. [15:34] iszak: but what's to say they're not the run of the mill hello world js dev
  467. [15:34] SubStack: node is bad for boring crud apps, it's true
  468. [15:34] Aikar: those kind of 'newbies' wouldnt even know how to compile node :3
  469. [15:34] SubStack: it's great for experimental new hotness though
  470. [15:34] iszak: apt makes it easy.
  471. [15:34] itissid has joined the channel
  472. [15:35] iszak: or synaptic, you guys are making excuses that there won't / isnt any crap code in rpm / node modules.
  473. [15:35] itissid: Hey whats the best HTML DOM parser in NODE?
  474. [15:35] iszak: Good question, go search for all the HTML DOM parsers, try them out, and then bam you know.
  475. [15:36] Aikar: your asking for someone else to build a 'high quality large collection of librarys'. if you want that, then build it :/ its almost like your demanding someone here write it
  476. [15:36] iszak: exactly what I'm talking about ^ how do we know the "good" from the "bad".
  477. [15:36] itissid: I could... or someone who did the hard work can tell me...
  478. [15:36] SubStack: itissid: well jsdom is the only one on npm, so I bet it's that one
  479. [15:36] iszak: Aikar, no I'm not asking anyone to build it, I am just looking for people who want to, I am more than happy to help develop it.
  480. [15:36] iszak: but best != good.
  481. [15:36] iszak: atleast in this case, best == only.
  482. [15:37] ashleydev has joined the channel
  483. [15:37] SubStack: being on npm is a good fitness signal
  484. [15:37] SubStack: since it indicates that somebody took the time to package it correctly and intends for other people to use it
  485. [15:37] iszak: It's a false sense of security though.
  486. [15:38] iszak: it doesn't promise it's maintained either.
  487. [15:38] kjeldahl_ has joined the channel
  488. [15:38] iszak: where as it we had something like ZF we could ensure everything is kept up-to-date.
  489. [15:38] SubStack: you could say the same thing about /any/ positive heuristic
  490. [15:38] iszak: You're right.
  491. [15:42] iszak: I don't see why people wouldn't be against creating a collection of libraries, it'll be a good thing for Node.js
  492. [15:42] itissid: Well i figured that if someting is compatible with the latest version of node.. then its probably well maintained...
  493. [15:42] iszak: well done :)
  494. [15:43] femtoo has joined the channel
  495. [15:44] jchris has joined the channel
  496. [15:46] itissid: jsdom is v0.3.0 compatible
  497. [15:49] mu-hannibal has joined the channel
  498. [15:50] jherdman has joined the channel
  499. [15:50] EGreg_ has joined the channel
  500. [15:50] skiz has joined the channel
  501. [15:50] unomi: next up: npm rate package +1 "Good, but not great, version 0.68 had an issue with foo. See http://blah for details"
  502. [15:56] aho has joined the channel
  503. [16:03] bnoordhuis has joined the channel
  504. [16:03] Wizek: if a variable returns [Function], How can I see the function itself?
  505. [16:04] jchris has joined the channel
  506. [16:04] SubStack: see?
  507. [16:04] bnoordhuis: v8: f = function() { return "foo"; } f.toString()
  508. [16:04] v8bot: bnoordhuis: SyntaxError: Unexpected identifier
  509. [16:04] SubStack: the source? if it's not a builtin, you can .toString()
  510. [16:04] bnoordhuis: v8: f = function() { return "foo"; }; f.toString()
  511. [16:04] v8bot: bnoordhuis: "function () { return "foo"; }"
  512. [16:05] SubStack: yep
  513. [16:07] itissid: The node REPL behaves sort of wierdly if I copy paste stuff... Especially with comments and empty lines... Does some one know what to do about this?
  514. [16:08] itissid: Like instead of the > prompt it just shows the ...
  515. [16:08] itissid: after pasting
  516. [16:14] Nevtus has joined the channel
  517. [16:14] Nevtus has joined the channel
  518. [16:15] dtrasbo has joined the channel
  519. [16:19] Gregor has joined the channel
  520. [16:20] cognominal has joined the channel
  521. [16:22] _mql: I've just put together some thoughts regarding an application that exclusively uses websockets for client/server communication, rather than AJAX. The following link should work on current webkit-browsers that support websockets. http://substance.quasipartikel.at/#load/e91fad537283dbd1fa8ae5a5b7dac6cd — would be great to hear your thoughts on this. The document shown can be edited collaboratively in realtime, but only existing content-n
  522. [16:26] dnolen has joined the channel
  523. [16:29] mpoz2 has joined the channel
  524. [16:31] unomi: _mql, awesome
  525. [16:31] unomi: I was
  526. [16:33] _mql: thanks! :) a lot of work ahead, though......
  527. [16:34] kkaefer: hm
  528. [16:34] kkaefer: apparently node's buffer fails on 0 terminated strings
  529. [16:34] _mql: anyways… regarding websocket-only apps, what's your opinion?
  530. [16:34] _mql: could this make sense?
  531. [16:35] unomi: I think it depends on the target group
  532. [16:35] unomi: I think it makes as much sense as canvas reliant or webworker reliant apps
  533. [16:36] _mql: sure.. for the editor i imply a websocket capable browser.. so in this case it would fit.
  534. [16:36] unomi: in terms of no http, there is no need to stay married to it.
  535. [16:36] _mql: renderers for that document can be browsed as usual through http clients.
  536. [16:36] rajeshsr has joined the channel
  537. [16:37] unomi: there is a lot of existing infrastructure for it though, proxies, firewalls etc could be an issue, but again, that is all about the market/target group, and not really a technical issue per se
  538. [16:37] _mql: that's the service for the pre-rendered output http://substance.quasipartikel.at/documents/e91fad537283dbd1fa8ae5a5b7dac6cd.html
  539. [16:38] _mql: k I wonder if there is any higher level framework for bigger websocket apps (server+client)
  540. [16:38] _mql: don't want to duplicate work (i'm super-new to node.js and socket servers, that's why i'm asking)
  541. [16:39] unomi: are you talking about something like socket.io or?
  542. [16:40] _mql: not really. i'm already using socket.io already… i wonder how communication is done by others. how they call the right methods on the server/client (i call it routing, based on the message)
  543. [16:40] unomi: besides going thru a different transport, are there other issues that need solving? I am a bit ignorant regarding this
  544. [16:41] unomi: ah, well, you might want to look at how tunguska works
  545. [16:41] dilvie has joined the channel
  546. [16:41] unomi: it is used by persevere for inter-multinode and browser event communication
  547. [16:42] unomi: https://github.com/kriszyp/tunguska
  548. [16:43] unomi: http://www.sitepen.com/blog/2010/07/19/real-time-comet-applications-on-node-with-tunguska/
  549. [16:43] _mql: ah thanks… I ask myself if i could abstract on('message') in some way… https://github.com/michael/substance/blob/master/server.js#L303
  550. [16:44] _mql: unomi: thanks that will be a good read!
  551. [16:45] unomi: the globbing style hubs that tunguska uses is similar in intent
  552. [16:45] unomi: as I read it anyway.
  553. [16:46] unomi: in that, your server will listen to the 'register' hub, and clients can send to it
  554. [16:46] unomi: likewise your clients can listen to it, and get 'new user joined' etc
  555. [16:51] matjas has joined the channel
  556. [16:52] johan_bouveng: hello, any tip on how to catch errors in a good way with mongodb+mongoose?
  557. [16:52] johan_bouveng: especially when a insert fails.
  558. [16:52] johan_bouveng: http://pastie.org/1315390
  559. [16:57] _mql: unomi: jeah that make sense. I'll play through various use-cases to get i better idea what i want. But I guess, creating my own little layer of abstraction for that would make sense anyway.
  560. [17:01] prettyrobots has joined the channel
  561. [17:01] rauchg_ has joined the channel
  562. [17:03] _mql1 has joined the channel
  563. [17:03] arpegius has joined the channel
  564. [17:08] Aikar: anyone know of any eta on FD passing between processes being fixed in master?
  565. [17:10] olivvv_ has joined the channel
  566. [17:10] _mql1: I wonder how I could implement authentication with secure websockets eventually… (Just in case someone can point me to some code/resources)
  567. [17:13] SubStack: holy crap my dnode ssl example just started working with the latest socket.io
  568. [17:14] SubStack: _mql1: you can pass secure : true to socket.io and also .setSecure() on the http instance
  569. [17:14] softdrink has joined the channel
  570. [17:17] saschagehlich: is there a jade plugin / function that shortens strings after a specific amount of characters?
  571. [17:17] SubStack: just call .slice()
  572. [17:17] _mql1: SubStack: ah thanks… one question: if i don't want to support fallbacks (that are provided by socket.io) wouldn't it make more sense to instead use the raw api? However using a regular node.js tcp server doesn't seem to be enough.
  573. [17:18] SubStack: /the/ raw api?
  574. [17:18] nsolsen has joined the channel
  575. [17:18] SubStack: oh the `net` stuff?
  576. [17:18] _mql1: yes
  577. [17:19] _mql1: and on the client side… if i just want to support FF4, webkit I could just use the official websocket api.
  578. [17:19] _mql1: however I didn't get it to work with net.createServer…..
  579. [17:20] SubStack: but why would you go out of your way to avoid fallbacks?
  580. [17:20] mikeal1 has joined the channel
  581. [17:23] AAA_awright has joined the channel
  582. [17:24] _mql1: I'm just trying to keep dependencies at a minimum. And a polling fallback for example doesn't make really sense for a app that sports truly realtime editing..
  583. [17:24] SubStack: why keep dependencies at a minimum?
  584. [17:24] SubStack: you can just npm install everything you need
  585. [17:24] SubStack: it's not like you have to do any /work/
  586. [17:25] _mql1: SubStack: I don't need to support older browsers, so I'm trying to stay as close to the metal as possible.
  587. [17:25] SubStack: well you can have realtime editing in browsers that don't even have websockets, it's just slower is all
  588. [17:25] _mql1: SubStack: yeah the main problem is the client-side that needs an additional socket.io.js file
  589. [17:25] SubStack: _mql1: that doesn't seem to follow
  590. [17:26] programble has joined the channel
  591. [17:26] SubStack: _mql1: not in the latest socket.io, which registers a default route
  592. [17:26] SubStack: just do <script src="/socket.io/socket.io.js"></script>
  593. [17:27] SubStack: "The client-side files are served automatically by Socket.IO-node."
  594. [17:28] _mql1: SubStack: supporting older browsers is tricky on so many levels. I just want to keep testing efforts at a minimum…
  595. [17:28] SubStack: well you don't /have/ to support them
  596. [17:29] SubStack: socket.io is really easy to get something running with
  597. [17:29] _mql1: SubStack: I'm aware of that, but it is an additional .js file that needs to be run by the client (potentially making problems (in terms of not exactly understanding how the internals work, which is in general a problem with frameworks)
  598. [17:30] mjr_ has joined the channel
  599. [17:30] _mql1: SubStack: that's true… I guess I'll keep using it. Just wanted to ask how easy it is to drop it, if I dont need it.
  600. [17:30] SubStack: you don't need to understand the internals
  601. [17:30] SubStack: that is the point of abstractions like socket.io
  602. [17:30] jbaron has joined the channel
  603. [17:31] SubStack: they've been independently tested and lots of hours have gone into making sure they work properly
  604. [17:32] confoocious has joined the channel
  605. [17:32] confoocious has joined the channel
  606. [17:32] SubStack: don't let bullshit frameworks like rails ruin all abstractions for you
  607. [17:33] _mql1: SubStack: Sure, you are probably right :) — I may be too wary.
  608. [17:33] SubStack: I too know the pain of leaky abstractions, but socket.io is pretty watertight in my usage
  609. [17:34] mu-hannibal has joined the channel
  610. [17:34] SubStack: ACTION wrote a further abstraction on top of socket.io even
  611. [17:35] tylerstalder has joined the channel
  612. [17:35] _mql1: I guess I'll create my own little abstraction (facet) that my client code can call — just to preserve the option of switching the implementation at some point.
  613. [17:35] SubStack: that's a good way to mitigate transitions
  614. [17:35] _mql1: SubStack: Seen. I'd like to have a look on it. Do you have it online?
  615. [17:35] c4milo has left the channel
  616. [17:36] SubStack: http://github.com/substack/dnode
  617. [17:36] jbaron: Anyone using Redis with node ?
  618. [17:36] SubStack: oh I should update the readme
  619. [17:37] SubStack: the web usage is quite a bit simpler now that it has default routes with connect
  620. [17:37] trotter has joined the channel
  621. [17:38] jacobolus has joined the channel
  622. [17:38] SubStack: the new style is in examples/connect
  623. [17:38] SubStack: and you can use express too since it subclasses connect
  624. [17:38] sudoer has joined the channel
  625. [17:38] _mql1: SubStack: Ahh it may be the case that this is exactly what I'm looking for.
  626. [17:38] SubStack: ^_^
  627. [17:39] technoweenie has joined the channel
  628. [17:39] _mql1: did you have a look at the link i posted before? http://substance.quasipartikel.at/#load/e91fad537283dbd1fa8ae5a5b7dac6cd
  629. [17:40] SubStack: reading
  630. [17:40] _mql1: SubStack: So how much do you think this applies to dnode?
  631. [17:40] _mql1: take your time :)
  632. [17:40] olivvv_: hi
  633. [17:41] olivvv_: what is the link between socket.io and expressjs ?
  634. [17:41] herbySk has joined the channel
  635. [17:41] olivvv_: is socket.io builtin ?
  636. [17:42] SubStack: olivvv_: no link besides both using the node http libs
  637. [17:42] SubStack: they play nicely together as a result of being based on the same base libraries though
  638. [17:42] SubStack: _mql1: seems like you've had some of the same ideas I've had
  639. [17:42] felixge has joined the channel
  640. [17:42] felixge has joined the channel
  641. [17:42] SubStack: I've settled on using continuations for authentication though
  642. [17:43] SubStack: like this: https://github.com/substack/dnode/blob/master/examples/auth/server.js
  643. [17:43] olivvv_: in fact Im trying to define the stuffs I need to start coding. I d like some mvc alike structure plus stuff to handle nicely chat features
  644. [17:44] itissid has joined the channel
  645. [17:44] olivvv_: so I guess jquery template + expressjs + socket.io
  646. [17:44] SubStack: olivvv_: express has a scaffolding type thing
  647. [17:45] SubStack: I don't use it, but if you type `express pow` it'll make a pow/ directory with goodies inside
  648. [17:45] olivvv_: I ve the doc there, I dont see what you are referring to
  649. [17:45] SubStack: well just try it
  650. [17:45] rauchg_: olivvv_: express is routing + nice IncomingMessage / OutgoingResponse extensions + templating caching / hooks
  651. [17:45] mikew3c_ has joined the channel
  652. [17:45] SubStack: a rauchg_ appears!
  653. [17:45] olivvv_: I mean I know what scaffolding from php frameworks exprerience
  654. [17:46] rauchg_: connect is middleware, like support for serving static images
  655. [17:46] rauchg_: that would change from framework to framework
  656. [17:46] dnolen has joined the channel
  657. [17:46] _mql1: SubStack: Ah, this is particularly helpful :) Need to experiment with it. We are likely to talk again.. soon? :)
  658. [17:46] rauchg_: socket.io doesn't care about either, it's a different request/response cycle
  659. [17:46] rauchg_: since it tries to keep connections "open"
  660. [17:47] itissid: hey is the jsdom author here?
  661. [17:47] olivvv_: rauchg_:connections "open" ---> thats what is required for a chat, isn'it ?
  662. [17:47] SubStack: _mql1: oh and message routing is the whole reason why I wrote dnode, reading the last item on your notes page
  663. [17:48] olivvv_: I want to be able to create a chat, but for the rest I d like some simple mvc thinking
  664. [17:48] rauchg_: olivvv_: correct
  665. [17:48] ajpi has joined the channel
  666. [17:48] SubStack: rauchg_: you'll be in SF next week right?
  667. [17:48] rauchg_: in reality, the connection being open or not is decided by Keep-Alive
  668. [17:48] olivvv_: I m so noob I dont know what is alredy available in node and what needs to ne added
  669. [17:48] rauchg_: but we want to minimize headers overhead
  670. [17:48] rauchg_: SubStack: correct
  671. [17:49] rauchg_: also, support websocket
  672. [17:49] rauchg_: serve the flash policy, prevent connection starvation and other nice thingies
  673. [17:49] SubStack: yeah I like the new flash policy stuff
  674. [17:49] SubStack: also https just started working with my dnode example!
  675. [17:50] SubStack: you must've fixed something
  676. [17:50] mikedeboer has joined the channel
  677. [17:50] rauchg_: yep
  678. [17:50] rauchg_: how we get the ws location
  679. [17:50] rauchg_: wss
  680. [17:51] SubStack: oh right then I broke it by porting to connect
  681. [17:51] rauchg_: be careful of `master` though, lots of experimental stuff
  682. [17:51] SubStack: I'm running the npm version here
  683. [17:51] rauchg_: k
  684. [17:51] galaxywatcher has joined the channel
  685. [17:52] prettyrobots has joined the channel
  686. [17:52] rauchg_: 0.7 will support multiplexing
  687. [17:52] rauchg_: you'll be able to initialize multiple io.Socket per window
  688. [17:52] SubStack: oh nice
  689. [17:52] rauchg_: and they'll go through the same channel
  690. [17:52] mAritz has joined the channel
  691. [17:55] Aikar: o.o your opting into jquery template lol?
  692. [17:56] _mql1: SubStack: Tight! Using the same interface for communication in the browser and on the server, is exactly what I was looking for.
  693. [17:56] SubStack: :D
  694. [17:56] SubStack: also I wrote some articles on substack.net about it
  695. [17:56] _mql1: reading through it.. right now.
  696. [17:56] Aikar: olivvv_: you should look at the other languages, ie EJS for more traditional templating
  697. [17:56] SubStack: the latest should be a pretty good crash-course
  698. [17:56] Aikar: jquery looked so bad
  699. [17:57] Aikar: EJS is like php, no extra lang to learn
  700. [17:57] olivvv_: Aikar:I m afraid of any templating system that contains logic
  701. [17:57] Aikar: so dont use logic in it lol
  702. [17:57] olivvv_: ok
  703. [17:57] Aikar: but thats a silly saying :3
  704. [17:57] olivvv_: I thought jquery template was logic free and not ejs
  705. [17:57] Aikar: always found templating engines to be rather silly, why restrict yourself
  706. [17:57] SubStack: yeah I like knowing that I can turn my templates into a horrible mess even though I shouldn't
  707. [17:58] rauchg_: olivvv_: use https://github.com/visionmedia/jade
  708. [17:58] Aikar: do what you need to do to get the job done cleanly
  709. [17:58] SubStack: Aikar: I agree!
  710. [17:58] SubStack: it's the programmer's responsibility to keep everything tidy, not the technology
  711. [17:58] Aikar: thats why ill be opting to EJS, ill put most my code in controller, but if i want to put some logic in my view, then i can!
  712. [17:58] Aikar: exactly
  713. [17:58] rauchg_: (html (head (title "Hello")))
  714. [17:58] SubStack: power, responsibility, etc
  715. [17:59] olivvv_: SubStack:true too
  716. [17:59] olivvv_: In fact I want something as close as possible to a view file in a php framework
  717. [17:59] olivvv_: no meta language
  718. [17:59] Aikar: olivvv_: EJS is that then
  719. [17:59] rauchg_: jade is that too
  720. [17:59] Aikar: EJS is exactly like PHP (but diff open tags, actually configurable)
  721. [17:59] SubStack: rauchg_: lisper!
  722. [17:59] Aikar: jade is special syntax
  723. [17:59] Aikar: it doesnt use <html> blah
  724. [17:59] rauchg_: true
  725. [17:59] rauchg_: xml sucks
  726. [17:59] rauchg_: agreed
  727. [17:59] rauchg_: :D
  728. [17:59] rauchg_: use jade :P
  729. [18:00] SubStack: ACTION has been using jade lately
  730. [18:00] Aikar: i also hate the concept of learning another syntax/language to get the job done :P so i dont want to use stuff like that lol
  731. [18:00] rauchg_: jade's compiler/parser/lexer separation is a thing of beauty
  732. [18:00] rauchg_: so you can do whatever you want with jade
  733. [18:00] SubStack: it's really simple
  734. [18:00] Aikar: http://codeangel.org/articles/simple-php-template-engine.html hits the point dead on
  735. [18:00] rauchg_: for example
  736. [18:00] rauchg_: i extended jade for
  737. [18:01] rauchg_: i18n in a way that is not intrusive
  738. [18:01] rauchg_: (no __() bs)
  739. [18:01] rauchg_: realtime with zero-coding (nodestream)
  740. [18:01] _mql1: SubStack: To be honest, I always somehow disliked how http works. URL-based routing and stuff (url-encoding query params in GET requests, etc.) in an RMI scenario things feel much better. However I can't tell at the moment where new problems occur. Caching may be an issue.
  741. [18:01] rauchg_: and assets compilation in s3 without altering our templates
  742. [18:01] rauchg_: or adding any middleware
  743. [18:01] rauchg_: :D
  744. [18:02] Wizek: What parse error means? http://prntscr.com/17cdi
  745. [18:02] isaacs has joined the channel
  746. [18:02] SubStack: _mql1: yeah synchronizing objects for local access can be a bother
  747. [18:02] Aikar: invalid syntax
  748. [18:02] isaacs: ryah: 2320497 :(
  749. [18:02] rauchg_: Wizek: an error in node's http parser
  750. [18:02] rauchg_: happened to me with http multipart
  751. [18:02] SubStack: _mql1: also if you're not careful you can make a real mess of callbacks…

Large files files are truncated, but you can click here to view the full file