00:00:09  <isaacs>eventually i want to remove scripts.install from package.json entirely
00:00:17  <isaacs>but it's going to take some steps to get there.
00:00:58  <TooTallNate>isaacs: i'm just trying to think of how to elegantly solve this: https://github.com/rbranson/node-ffi/blob/master/deps/README
00:01:03  * travis-cijoined
00:01:04  <travis-ci>[travis-ci] joyent/node#377 (master - 23514fc : Andreas Madsen): The build is still failing.
00:01:04  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/5e1471c...23514fc
00:01:04  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/636011
00:01:04  * travis-cipart
00:01:29  <isaacs>TooTallNate: right
00:01:32  <tjfontaine>but what about commonjs? :)
00:01:34  <isaacs>how can you even do that on windows?
00:01:35  <isaacs>i dunno.
00:01:42  <isaacs>tjfontaine: what about what now?
00:02:11  <TooTallNate>isaacs: well libffi is kinda a special case, it required the MozillaBuild thingy to build properly
00:02:14  <tjfontaine>isaacs: http://wiki.commonjs.org/wiki/Packages/1.0 has the scripts {} construct
00:02:26  <isaacs>tjfontaine: you're funny. ;P
00:02:29  <tjfontaine>hehe
00:02:39  <isaacs>tjfontaine: commonjs is over.
00:02:43  <isaacs>we've got node now.
00:02:59  <TooTallNate>is this a bad idea:?
00:03:02  <TooTallNate>scripts.configure
00:03:09  <TooTallNate>scripts.build
00:03:12  <TooTallNate>scripts.clean
00:03:23  <tjfontaine>isaacs: see, TooTallNate wants commonjs :P
00:03:34  <TooTallNate>they could be called with the corresponding node-gyp commands
00:03:39  <TooTallNate>but they would have to be JS files
00:03:45  <TooTallNate>not arbitrary commands
00:04:23  <TooTallNate>isaacs: tjfontaine: the difference with these is that they are not invoked when a package is npm installed
00:04:43  <tjfontaine>TooTallNate: then the responsibility probably shouldn't be in package.json
00:05:07  <CIA-101>node: isaacs master * re5db01e / deps/v8/build/common.gypi : v8: Remove OutputDirectory from build/common.gypi - http://git.io/k-HpQA
00:05:11  <CIA-101>node: isaacs master * r8be6994 / (130 files in 15 dirs): Upgrade V8 to 3.9.2 - http://git.io/1H4jqA
00:05:11  <TooTallNate>tjfontaine: package.json is just a place for package metadata, seems appropriate to me
00:05:49  <isaacs>TooTallNate: i'd like to have npm just detect the Right Thing based on the presence of a gyp file
00:06:13  <tjfontaine>I'm not entirely convinced that the build metadata should be in the dependency tracking mechanism
00:06:32  <tjfontaine>unless you want to go down the debian build-dep path
00:07:26  <TooTallNate>tjfontaine: the problem i'm trying to solve is that most modules have deps that may need to be configured/compiled along with the module
00:08:01  <TooTallNate>like node-ffi, the gyp file expects libffi in the deps folder to have been statically compiled before running node-gyp
00:08:11  <TooTallNate>but ideally they would be integrated
00:08:40  <tjfontaine>TooTallNate: right I understand that, but as I understand isaacs he's trying to decouple building from installing, so I'm not sure if that information should be in package.json, since it isn't useful for npm after the package is built
00:08:57  <TooTallNate>so where does it go then?
00:09:04  <isaacs>tjfontaine: build-decoupling is decoupled from being able to build more nicely
00:09:42  <tjfontaine>but you want to be careful that you're not working against what gyp is for with npm, right? I mean there's not much sense making npm into a psueo build system
00:09:47  <tjfontaine>*pseudo
00:10:02  <isaacs>tjfontaine: that's a separate feature, which could be tackled now, but is less feasible as long as building is so painful in itself.
00:10:42  <isaacs>tjfontaine: that's fair, but npm already touches the "build system" realm a little
00:10:57  <isaacs>tjfontaine: if you have a wscript, it already assumes a node-waf install command
00:11:21  <isaacs>no reason it can't have a node-gyp install cmd if you have a binding.gyp file
00:11:33  <tjfontaine>sure, but I don't have to keep that information in package.json for it to work
00:11:59  <tjfontaine>having a configure/clean/build definition in package.json doesn't necessarily match the world view as I understand it
00:12:42  <TooTallNate>i'm so lost
00:12:53  <tjfontaine>TooTallNate: your point was for ordering of building deps, right?
00:12:54  <isaacs>yeah, i don't want to add new fields to package.json if we can get away with it
00:12:56  <CIA-101>node: isaacs master * r1168355 / (22 files in 9 dirs): (log message trimmed)
00:12:56  <CIA-101>node: Merge remote-tracking branch 'ry/v0.6'
00:12:56  <CIA-101>node: Conflicts:
00:12:56  <CIA-101>node: ChangeLog
00:12:56  <CIA-101>node: deps/v8/src/version.cc
00:12:56  <CIA-101>node: deps/v8/tools/gyp/v8.gyp
00:12:56  <CIA-101>node: doc/about/index.html
00:13:18  <isaacs>ok, need to make some dinner and head to class.
00:13:33  <TooTallNate>isaacs: all i'm proposing is hooks into the various build steps of node-gyp
00:13:37  <TooTallNate>not related to npm at all
00:13:37  <isaacs>right
00:13:57  <TooTallNate>where these hook definitions go is irrelevant as well
00:14:03  <isaacs>forcing them to be js files would be fine, imo
00:14:04  <TooTallNate>could be package.json could be something new
00:14:19  <TooTallNate>but since package.json already exists, why make something new?
00:14:29  <isaacs>why not just hard-code it?
00:14:42  <isaacs>if you want a pre-node-gyp configure step or whatever, write a configure.js, and node-gyp will run it
00:14:51  <TooTallNate>that could work
00:14:54  <isaacs>anyway, gotta run.
00:14:59  <TooTallNate>isaacs: ok have a good class
00:15:04  <TooTallNate>sign language?
00:15:06  <isaacs>as long as the default use-case is easy, things that are more complicated can be ugly.
00:15:07  <isaacs>yessir
00:15:11  <TooTallNate>awesome
00:15:15  <isaacs>it's fun
00:15:24  <isaacs>everyone should learn it. makes talking in noisy bars much easier.
00:15:27  <isaacs>:)
00:15:39  <TooTallNate>haha, nice use-case
00:16:13  <tjfontaine>TooTallNate: could you use gyp's shell-out and normal dependency tree for invoking a configure step if your package needed it?
00:17:14  <TooTallNate>tjfontaine: that's possible, and wouldn't require any additional code to node-gyp, but i think libffi's setup is too compilicated
00:17:18  <TooTallNate>not too sure though
00:17:29  <TooTallNate>you're right though, ideally it's gyp all the way down
00:18:13  <tjfontaine>I haven't investigated everything I need yet, but for my wscript migration I know I'll be using things like '<!@(<(pkg-config) --cflags libpng)'
00:18:34  <TooTallNate>so dynamic linking?
00:19:09  * travis-cijoined
00:19:09  <travis-ci>[travis-ci] joyent/node#378 (master - e5db01e : isaacs): The build is still failing.
00:19:09  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/23514fc...e5db01e
00:19:09  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/636097
00:19:09  * travis-cipart
00:19:09  <tjfontaine>yes, from my stand point, static is really a windows-ism
00:19:44  <TooTallNate>well are you offering precompiled binaries?
00:19:51  <TooTallNate>or rather, at some point npm will be
00:20:03  <TooTallNate>so then what's the benefit of dynamic linking?
00:20:13  <tjfontaine>yes, my personal belief is that this will be much harder than expected on unix platforms
00:20:34  <TooTallNate>i.e. in node-ffi i get to use the newer features since i have the newest libffi
00:20:48  <TooTallNate>and don't have to depend on what system version is installed (if any)
00:21:04  <tjfontaine>and if node-ffi (god forbid) were to ever be stale it would have all those security flaws as well
00:22:11  <tjfontaine>my point is, (exclude windows from the discussion), most unix flavors have preferred mechanisms for handling libraries, flying in the face of that is quite frustrating
00:23:12  <tjfontaine>Do One Thing, Do It Well
00:24:12  <TooTallNate>well i'd hardly call the apt dependency experience doing it well
00:24:22  <TooTallNate>that was isaacs motivation for local modules, etc.
00:24:27  <tjfontaine>compared to rpm, .dpkg is a god send
00:24:42  <TooTallNate>well my point exactly
00:24:47  <tjfontaine>there are two competing things here though
00:24:53  <tjfontaine>1) deployment experience
00:24:58  <tjfontaine>2) development experience
00:25:24  <tjfontaine>I get local modules from a deployment side, but for every other use case, development experience beats out
00:26:12  <tjfontaine>local modules makes sense in a "I am running a website" sorta way, but that's clearly not how everyone uses node
00:26:27  <TooTallNate>so you're bummed that you have to 'npm install' for every project?
00:26:27  * pieternquit (Quit: pietern)
00:26:39  <tjfontaine>no, of course not
00:26:56  <TooTallNate>how are local modules a problem for development?
00:27:26  <tjfontaine>I misnomered the 2nd case, it's not properly named development but I can't think of a better name for it
00:28:13  * travis-cijoined
00:28:14  <travis-ci>[travis-ci] joyent/node#379 (master - 1168355 : isaacs): The build is still failing.
00:28:14  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/e5db01e...1168355
00:28:14  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/636162
00:28:14  * travis-cipart
00:28:27  <tjfontaine>perhaps better would be from distributions standpoint, say debuntu/redhat etc, who would want to use the dependencies that they've alredy built
00:29:29  <tjfontaine>having lib<x>-[perl|python|ruby] means that I don't get 3 different statically compiled versions of the same base layer
00:30:18  <tjfontaine>so enforcing a static policy, merely because it aids in one form of distribution, doesn't mean it's the sensible choice for the platform as a whole
00:30:50  <tjfontaine>and from my standpoint it's a push from the people who want to rsync/xcopy their deployments
00:31:12  * pieternjoined
00:37:22  <TooTallNate>tjfontaine: my personal opinion is that this is node+npm, not debian/redhat, so there's different ideologies
00:43:19  * bnoordhuisquit (Ping timeout: 248 seconds)
00:56:09  <tjfontaine>TooTallNate: there will always be different ideologies, but other things like perl, python, and ruby have found a way to keep useful package management while at the same time not doing too much to prevent wider adoption, moving to static linking for modules is a good way to get packages to never be accepted for mainline distributions
01:06:37  <isaacs>tjfontaine: there will always be the option to take the source and do whatever you want with it.
01:06:55  <isaacs>tjfontaine: we're working on the node+npm distribution mechanism, and not really concerned with any other.
01:07:26  <isaacs>i don't exactly see redhat or debian stepping up to deploy programs that benefit windows users :)
01:08:35  <tjfontaine>isaacs: I understand not wanting to fit every use case, but by the same token I don't feel like static really solves anything except for windows people
01:08:56  <TooTallNate>it solves being able to use stable APIs
01:08:58  <isaacs>it solves having to install libffi on their own
01:09:12  <isaacs>actually, for almost any kind of deployment, static is much btter.
01:09:26  <tjfontaine>because you know, unix has utterly failed at this
01:09:27  <isaacs>node uses a static v8, and without fail, systems that override this with the system v8 do nothing but cause pain for users.
01:09:37  <isaacs>tjfontaine: yes, it has.
01:09:46  <isaacs>it's optimized for a time that no longer exists, when hard drives were a megabyte
01:10:03  <TooTallNate>module authors can always offer a --use-shared flag on their modules or something, like how node uses zlib
01:10:32  <tjfontaine>for instance I have modules that wrap libclang and imagemagick, static linking those sons of bitches is a terrible idea, and the point of the modules is to not use node-ffi
01:10:51  <tjfontaine>I jsut don't want to see static something that's forced on everyone
01:11:19  <TooTallNate>gyp is all that's being forced, static is just being encouraged
01:11:59  <TooTallNate>and i think some things that all computers will have is safe to dynamic link, like libc
01:12:06  <tjfontaine>an actual use case for scripts.install is to check that the platform its being installed on has a required system dependency
01:12:11  <TooTallNate>why wouldn't you want to statically link imagemagick though?
01:12:30  <tjfontaine>because I lose shared pages from anything else that might already be using it
01:12:30  <isaacs>tjfontaine: right now, almost no one binds to their deps statically, because we've done nothing to encourage it, and waf doesn't make it the default.
01:12:40  <TooTallNate>tjfontaine: i'll add support for hooks in node-gyp, but probably just hard-coded names, not touching package.json
01:13:22  <isaacs>the list of things that it's safe to dynamically link is *incredibly* small.
01:13:26  <isaacs>openssl is not on that list.
01:13:31  <isaacs>neither is zlib.
01:13:35  <isaacs>and those are almost everywhere.
01:13:45  <tjfontaine>I didn't really want this conversation to get this long :)
01:13:48  <isaacs>haha
01:14:05  <isaacs>tjfontaine: if all you're doing is detecting a system lib in scripts.install, then that shoudl be abstracted out to some declarative api.
01:14:25  <isaacs>"I need X Y and Z, and haven't bundled them mysefl. installer builder thingie, please make sure this is ok"
01:14:59  <TooTallNate>isaacs: that is a valid concern, wscript allowed us to do that but I don't think gyp has an equivalent
01:15:01  <tjfontaine>isaacs: I don't necessarily disagree with that, and I think it's something that could be done, if you're interested in it I will look at way to do it and work up a pull request :)
01:15:02  <isaacs>and if that's present, then we'll disable pre-built deployments, since they'll be unsafe at any speed.
01:16:41  <TooTallNate>isaacs: can we sort that list of modules by most depended on?
01:17:00  <TooTallNate>i just sent ben a pull for buffertools :p
01:17:02  <isaacs>TooTallNate: hm... don't think so
01:17:08  <isaacs>kewl :)
01:17:28  <isaacs>TooTallNate: not in the next 5 minutes anyway
01:17:36  <TooTallNate>ok no prob
01:28:18  <tjfontaine>TooTallNate: in node-bindings is the suffix '.node' optional?
01:29:21  <TooTallNate>tjfontaine: not currently but it would be trivial to add that
01:29:25  <TooTallNate>tjfontaine: pull request welcome :)
01:29:29  <tjfontaine>heh ok
01:29:38  <tjfontaine>I was just looking over the code now
01:33:35  <TooTallNate>tjfontaine: here you go acutally :) https://github.com/TooTallNate/node-bindings/commit/ec4a52811e67d2ba24d2977d944a5d062d377ec3
01:33:51  <tjfontaine>:)
01:34:05  <tjfontaine>thanks!
01:34:12  <TooTallNate>no prob
01:38:29  * isaacsquit (Remote host closed the connection)
01:56:30  * mikealjoined
02:20:33  * dapquit (Quit: Leaving.)
02:21:37  * mikealquit (Quit: Leaving.)
02:29:39  * mikealjoined
02:41:36  * benviepart
02:44:20  * brsonquit (Quit: leaving)
02:46:56  * benviejoined
03:18:25  * mmaleckiquit (Ping timeout: 252 seconds)
03:36:13  * mikealquit (Quit: Leaving.)
03:37:16  * dannycoatesquit (Quit: dannycoates)
03:41:49  * mmaleckijoined
03:53:32  * skabbesquit (Quit: skabbes)
03:55:47  * mikealjoined
04:22:19  * isaacs_mobilejoined
04:30:51  * isaacs_m_joined
04:31:03  * isaacs_mobilequit (Ping timeout: 248 seconds)
04:36:39  * TooTallNatequit (Quit: Linkinus - http://linkinus.com)
04:47:24  * isaacs_m_quit (Ping timeout: 272 seconds)
05:11:08  * isaacsjoined
05:37:23  * mraleph1joined
05:48:24  * stephankquit (Ping timeout: 265 seconds)
05:50:12  * stephankjoined
05:58:49  * mikealquit (Quit: Leaving.)
06:03:04  * mikealjoined
06:10:30  * dshaw_quit (Quit: Leaving.)
06:27:07  * mraleph1quit (Quit: Leaving.)
06:31:59  * mikealquit (Quit: Leaving.)
06:34:14  * mikealjoined
06:38:05  * isaacsquit (Remote host closed the connection)
06:41:10  * paddybyersjoined
06:45:37  * mikealquit (Quit: Leaving.)
07:01:46  <CIA-101>node: isaacs master * r986785c / doc/index.html :
07:01:46  <CIA-101>node: Fix merge-conflicts in HTML
07:01:46  <CIA-101>node: Thanks, @AndreasMadsen - http://git.io/24lUnQ
07:06:24  * dshaw_joined
07:15:36  <indunty>heh
07:15:39  <indunty>merge conflicts
07:15:41  <indunty>are lame
07:15:47  * travis-cijoined
07:15:47  <travis-ci>[travis-ci] joyent/node#380 (master - 986785c : isaacs): The build is still failing.
07:15:47  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/1168355...986785c
07:15:47  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/637551
07:15:47  * travis-cipart
07:44:59  * stephankquit (Ping timeout: 252 seconds)
08:27:07  * alex_rquit (Read error: Operation timed out)
08:28:22  * Raynosquit (Ping timeout: 245 seconds)
08:28:27  * mrb_bkquit (Ping timeout: 240 seconds)
08:34:38  * alex_rjoined
08:39:46  * Raynosjoined
08:43:10  * mrb_bkjoined
08:44:27  * alex_rquit (Read error: Operation timed out)
08:46:53  * paddybyers_joined
08:49:32  * paddybyersquit (Ping timeout: 252 seconds)
08:49:32  * paddybyers_changed nick to paddybyers
08:57:32  * orlandovftwquit (Ping timeout: 245 seconds)
09:03:30  * alex_rjoined
10:11:59  * piscisaureus_joined
11:59:44  * bnoordhuisjoined
12:11:18  * piscisaureus_quit (Read error: Connection reset by peer)
12:11:32  * piscisaureus_joined
12:12:01  <bnoordhuis>piscisaureus_: http://groups.google.com/group/nodejs/msg/62420d704070bdb5
12:12:33  <bnoordhuis>he's wrong about the result of _open_osfhandle() not being checked though
12:20:07  * piscisaureus_quit (Ping timeout: 256 seconds)
12:38:25  <bnoordhuis>ircretary: tell piscisaureus_ https://github.com/joyent/libuv/pull/307
12:38:25  <ircretary>bnoordhuis: I'll be sure to tell piscisaureus_
12:49:49  <bnoordhuis>indunty: name change?
12:49:51  <bnoordhuis>indunty: Undefined symbols: "v8::internal::Dictionary<v8::internal::SeededNumberDictionaryShape, unsigned int>::SlowReverseLookup(v8::internal::Object*)", referenced from: v8::internal::JSObject::ReferencesObjectFromElements(v8::internal::FixedArray*, v8::internal::ElementsKind, v8::internal::Object*)in objects.o
12:49:57  <bnoordhuis>any idea why that happens?
12:50:37  <bnoordhuis>v0.6.10, only happens to a couple of people on os x
12:53:02  <indunty>bnoordhuis: hua
12:53:05  <indunty>one sec
12:53:16  <indunty>bnoordhuis: yes, name change
12:53:24  <indunty>bnoordhuis: let me check
12:53:32  <indunty>bnoordhuis: are they using brew installs?
12:53:40  <bnoordhuis>indunty: maybe, i haven't asked
12:53:50  <indunty>bnoordhuis: that matters
12:53:58  <bnoordhuis>i'm thinking it's a compiler/linker bug
12:54:04  <indunty>bnoordhuis: looks like so
12:54:09  <bnoordhuis>i'll ask
12:54:52  <indunty>ooh
12:54:57  <indunty>I know what is causing it
12:55:20  <bnoordhuis>it's compiled with /usr/bin/g++
12:55:23  <indunty>one sec
12:55:24  <indunty>k
12:55:44  <indunty>bnoordhuis: https://github.com/v8/v8/blob/master/src/objects.cc#L11281
12:56:49  <bnoordhuis>indunty: yes?
12:57:06  <indunty>no template declaration for SeededNumberDictionary
12:58:02  <indunty>bnoordhuis: what g++ version?
12:58:11  <bnoordhuis>don't know, i'll have to ask
12:58:35  <bnoordhuis>that missing template declaration isn't actually used, right?
12:58:48  <indunty>bnoordhuis: yes, it isn't used directly
12:59:03  <indunty>bnoordhuis: oh
12:59:04  <indunty>not
12:59:05  <indunty>it is
12:59:05  <indunty>https://github.com/v8/v8/blob/master/src/objects.cc#L4060
12:59:48  <indunty>strange that it doesn't happens on 0.7.x
12:59:53  <indunty>probably less people testing it
12:59:57  <bnoordhuis>so how come it compiles on other platforms?
13:00:11  <indunty>bnoordhuis: it compiles on osx too
13:00:12  <indunty>:D
13:00:22  <indunty>gcc version 4.2.1
13:00:27  <indunty>gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)
13:00:54  <indunty>bnoordhuis: https://plus.google.com/u/0/114952216726212307316/posts/P5gzigzMybH?gpinv=AMIXal8iiQRYFkYVjBWUa9CdrUPGpb5k__iDeIgofg2UoJzWWY3NU8tlFw1vBDGdt9_ZQgbiwyjC3EyNPbviTeE0cPUR3C5kcPDq6RF4wtIPYedDYXAEYTs&hl=en
13:01:14  <bnoordhuis>:)
13:01:36  <indunty>Erik is going to fix it
13:03:38  <indunty>bnoordhuis: we can try hotfixing it
13:03:50  <indunty>bnoordhuis: but better wait for "official" fix
13:03:54  <bnoordhuis>indunty: one sec, phone call
13:03:58  <indunty>np
13:04:03  <indunty>who you gonna call?
13:04:06  <indunty>ghost busters
13:05:10  * piscisaureus_joined
13:35:26  <CIA-101>libuv: Luis Lavena v0.6 * rc800043 / src/win/winsock.h :
13:35:26  <CIA-101>libuv: Add missing IPV6_HOPLIMIT definition for MinGW
13:35:26  <CIA-101>libuv: Closes GH-307 - http://git.io/v0l0pA
13:37:12  * travis-cijoined
13:37:12  <travis-ci>[travis-ci] joyent/libuv#83 (v0.6 - c800043 : Luis Lavena): The build is still failing.
13:37:12  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/dbc046c...c800043
13:37:12  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/638644
13:37:12  * travis-cipart
14:02:19  <indunty>bnoordhuis: http://code.google.com/p/v8/issues/detail?id=1936&thanks=1936&ts=1328622995
15:04:39  <bnoordhuis>indunty: good!
15:07:17  * isaacs_mobilejoined
15:18:11  * isaacs_mobilequit (Remote host closed the connection)
15:22:31  <piscisaureus_>bnoordhuis: what us uv_spawn performance do on unix?
15:23:23  <piscisaureus_>bnoordhuis: sorry that came out garbled. What is the output of libuv's spawn benchmark on unix?
15:28:02  * isaacsjoined
15:37:49  <piscisaureus_>indunty: ?
15:40:05  <indunty>piscisaureus_: bert?
15:40:13  <piscisaureus_>indunty: that's me
15:40:19  <indunty>I am indutny
15:40:26  <indunty>sup?
15:41:00  <piscisaureus_>indunty: can you tell me what libuv's spawn benchmark reports on unix?
15:41:11  <piscisaureus_>try run-benchmarks spawn spawn
15:41:25  <indunty>piscisaureus_: one sec
15:43:07  * stephankjoined
15:47:28  * stephankquit (Ping timeout: 244 seconds)
15:48:02  <indunty>piscisaureus_: running
15:50:18  <indunty>piscisaureus_:
15:50:25  <indunty>spawn: 229 spawns/s
15:50:29  <piscisaureus_>hmm
15:50:33  <indunty>osx
15:50:38  <piscisaureus_>win32: 89 spawns/s
15:50:42  <indunty>ooh
15:50:44  <indunty>not good
15:50:51  <piscisaureus_>win64: 170 spawns/s
15:51:00  <piscisaureus_>not good sherlock
15:52:04  <isaacs>good morning
15:52:13  <indunty>isaacs: morning
15:52:19  <piscisaureus_>good morning
15:55:37  <creationix>good morning west coast
15:56:02  <mmalecki>morning!
16:22:10  <piscisaureus_>blogs.msdn.com/b/oldnewthing/archive/2011/12/16/10248328.aspx <-- wow
16:22:30  <piscisaureus_>12-16-2011: tthe day that someone at microsoft started thinking
16:36:03  <isaacs>piscisaureus_: speaking of blogs... please take a few minutes to write up what domains are. just a few paragraphs.
16:39:32  * isaacsquit (Remote host closed the connection)
16:45:19  <piscisaureus_>http://blogs.msdn.com/b/oldnewthing/archive/2005/01/18/355177.aspx
16:47:31  <tjfontaine>jesus
16:48:41  * AndreasMadsenjoined
16:50:21  * dapjoined
17:03:36  * stephankjoined
17:16:23  * isaacs_mobilejoined
17:21:26  * orlandovftwjoined
17:22:28  * philipsquit (Excess Flood)
17:23:22  * philipsjoined
17:25:26  * isaacs_mobilequit (Ping timeout: 240 seconds)
17:26:31  * skabbesjoined
17:32:31  * AndreasMadsenquit (Remote host closed the connection)
17:33:44  * AndreasMadsenjoined
17:43:51  * dshaw_quit (Quit: Leaving.)
17:57:05  * brsonjoined
17:57:08  * isaacsjoined
17:59:54  <igorzi>isaacs: hey, when are you planning to do next 0.6 release?
18:08:16  <isaacs>igorzi: thursday
18:08:37  <isaacs>why, got something you wanna land?
18:09:11  <indunty>isaacs: we need to wait for v8 fix
18:09:24  <igorzi>isaacs: yep, i'm almost done with 64bit windows build
18:09:35  <indunty>isaacs: http://code.google.com/p/v8/issues/detail?id=1936&sort=-id&colspec=ID%20Type%20Status%20Priority%20Owner%20Summary%20HW%20OS%20Area%20Stars
18:09:46  <isaacs>igorzi: kickass
18:11:23  <isaacs>indunty: that's weird... it works for me on os x
18:11:59  <igorzi>isaacs: once we have it building, we need to figure out if/how it makes it into the binary distribution
18:12:07  <isaacs>igorzi: yes.
18:12:32  <isaacs>igorzi: maybe should we have node-v0.6.11.msi and node-x64-v0.6.11.msi or something?
18:12:39  * dannycoatesjoined
18:12:58  <isaacs>or maybe just have an x64 subfolder.
18:13:23  <isaacs>ugh. adding another compile, though... we really need to get this stuff automated...
18:13:43  <igorzi>isaacs: the only issue with that is we put programfiles/nodejs on the path.. so if we have 2 flavors of node.exe, which would should be on the path
18:14:29  <igorzi>maybe both executables should be in the same directory (node.exe + node64.exe)
18:14:35  <isaacs>igorzi: hmm...
18:14:47  <isaacs>igorzi: is there any way to detect and just put the right one there?
18:15:14  <isaacs>igorzi: or just have different msi's, i was thinking. one for x64 and another for 32
18:15:53  <igorzi>isaacs: yeah, we can do that.. i was assuming that on x64 machines we want to install both x64 and x86 binaries
18:15:55  <indunty>isaacs: that's how it works with most of the apps
18:16:16  <isaacs>ok
18:16:17  <igorzi>isaacs: people might want to have both
18:16:21  <indunty>igorzi: may be just separate \Program files(x86) \Program files folders?
18:16:44  <isaacs>it should follow whatever is the normal windows pattern, if applicable.
18:16:47  <igorzi>indunty: yeah, that works.. but which folder does PATH point to?
18:16:57  <indunty>igorzi: developer decides :)
18:16:59  <indunty>haha
18:17:27  <igorzi>indunty: that means we have to add some UI to the installer, which sucks :)
18:17:36  <indunty>heh
18:17:40  <indunty>node64 sucks too
18:17:53  <isaacs>yeah, the executable shall be called "node"
18:18:14  <isaacs>anything else is just a recipe for confusing
18:18:47  <creationix>Thou shalt not have any other binary names before "node"
18:19:40  <igorzi>there are actually 2 cmd.exe's on 64bit windows (32bit and 64bit).. i think that we can make each one of those point to the right path (if you open 64bit cmd.exe it'll point to 64bit node folder, and 32bit cmd.exe will point to 32bit node folder)
18:21:02  <igorzi>isaacs: which means we could probably just create 2 separate installers (which can be installed together), and then people can decide which one (or two) they want
18:21:42  <isaacs>sure
18:24:38  * TooTallNatejoined
18:37:18  <toothr>sounds strange to me to install both x86 and x64
18:38:25  <toothr>(as far as installing in Program Files and Program Files(x86))
18:39:05  * orlandovftwquit (Ping timeout: 245 seconds)
18:42:02  * paddybyersquit (Quit: paddybyers)
18:42:56  * mikealjoined
18:43:20  <piscisaureus_>igorzi: hey. You can't really rename node.exe because that name is hardcoded into compiled addons
18:43:40  <piscisaureus_>igorzi: so *if* we go for node64.exe then we will have to stick with it
18:50:47  <igorzi>piscisaureus_: i think isaacs already shut down the node64.exe idea
18:54:32  <igorzi>https://gist.github.com/1761210
18:54:43  <igorzi>piscisaureus_: review pls --^
18:57:45  <mmalecki>igorzi: you sure you want 'deps/openssl/config/k8/openssl/opensslconf-posix.h' there?
18:59:38  <igorzi>mmalecki: there's one under deps/openssl/config/piii/openssl, so i included one for k8. it'd be good if someone could try to do x64 unix build with it
19:00:15  <mmalecki>igorzi: what I mean is, it says it's automatically generated
19:02:23  <piscisaureus_>isaacs: msft call
19:02:28  <piscisaureus_>bnoordhuis: sic
19:02:36  * dshaw_joined
19:03:24  <igorzi>mmalecki: yep.. we don't run ./configure for openssl, so the pre-gen'ed headers are included in the tree (same for piii headers -> https://github.com/joyent/node/blob/master/deps/openssl/config/piii/openssl/opensslconf-posix.h)
19:03:41  <piscisaureus_>dap: is isaacs at the office, and if yes, can you kick him for me?
19:04:19  <mmalecki>igorzi: I see, thanks for explanation!
19:04:45  <igorzi>mmalecki: np.. does the rest of the patch look ok to you?
19:04:58  <piscisaureus_>bnoordhuis: hey
19:06:10  <dap>piscisaureus_: kick received.
19:07:12  <isaacs>hola
19:07:14  <isaacs>call time?
19:07:17  <piscisaureus_>isaacs: yes
19:07:21  <mmalecki>igorzi: I'm not any kind of gyp master, but I think so!
19:09:33  * mikealquit (Quit: Leaving.)
19:15:40  * dannycoatesquit (Remote host closed the connection)
19:15:55  * bentkus_joined
19:15:57  * dannycoatesjoined
19:20:46  <creationix>if it possible to use ioctl APIs with libuv?
19:20:49  <creationix>I'm guessing no
19:21:20  <creationix>I want to use section 4 of http://www.kernel.org/doc/Documentation/input/joystick-api.txt
19:33:47  * dshaw_quit (Ping timeout: 245 seconds)
19:33:51  * dshaw_joined
19:38:10  <bnoordhuis>piscisaureus_: ho
19:38:18  <piscisaureus_>bnoordhuis: msft call
19:38:24  <bnoordhuis>piscisaureus_: still ongoing?
19:38:33  <piscisaureus_>almost done I guess
19:40:57  <AndreasMadsen>anyone how would like to land a oneline patch -> https://github.com/joyent/node/pull/2650/files
19:41:23  * orlandovftwjoined
19:43:17  <bnoordhuis>AndreasMadsen: doesn't seem like a good change to me. calling the channel when it's closed is a programmer bug
19:43:29  * dshaw_quit (Quit: Leaving.)
19:44:01  <AndreasMadsen>bnoordhuis: oh I should return after emitting, dub
19:44:24  <bnoordhuis>AndreasMadsen: yes, but that's not what i mean :)
19:45:10  <bnoordhuis>creationix: ioctl(handle->fd, ...). won't work from inside node though
19:46:03  <AndreasMadsen>bnoordhuis: Then I'm confused, should errors not be emitted when an appopiate EventEmitter object exist?
19:47:04  <bnoordhuis>AndreasMadsen: error events are for external errors (i.e. network errors), exceptions for programmer mistakes
19:47:39  <bnoordhuis>in this case, calling child.send() when the channel's been closed is a programmer mistake
19:48:16  <creationix>bnoordhuis, could this be exposed to the scripting language somehow? I'll add it to luvit if it's possible
19:48:24  <AndreasMadsen>bnoordhuis: you need a well defined policy then. issacs convinced me about emitting error here: https://github.com/joyent/node/blob/master/lib/child_process.js#L144
19:48:56  <bnoordhuis>creationix: no. ioctls are very platform (sometimes even architecture) specific
19:49:28  <bnoordhuis>AndreasMadsen: that's also missing a return :)
19:49:34  <bnoordhuis>but yes, that should be an exception
19:50:47  <creationix>bnoordhuis, yeah, all the docs I find are macro heavy, oh well
19:51:13  <AndreasMadsen>bnoordhuis: hmm, any other voices - If i remove my own I have isaccs+ and bnoordhuis- | and I see logic in both
19:51:26  <bnoordhuis>isaacs: ^
19:51:52  <AndreasMadsen>yes please
19:55:23  <AndreasMadsen>oh github is down, can't update the patch :(
19:56:23  * dshaw_joined
19:57:36  * skabbes_joined
19:58:10  <isaacs>bnoordhuis: we should only throw errors if the user has called a function inappropriately.
19:58:44  <isaacs>bnoordhuis: if something can be called internally and potentially be called inappropriately (ie, in a stream.pipe) then it's better to emit than throw.
19:59:04  * skabbesquit (Ping timeout: 276 seconds)
19:59:04  * skabbes_changed nick to skabbes
19:59:12  <bnoordhuis>isaacs: agreed. and it's inappropriate to call child.send() when the channel's already been closed
19:59:20  <AndreasMadsen>isaacs: so if I call .disconnect and .connected === false - is that an inappropriately call?
19:59:28  <bnoordhuis>it means the developer failed to catch the exit event
19:59:29  <isaacs>it's not that emitting error is *always* better than throwing, but it is better if it's something that's likely to be buried in the internals, and when in doubt, it's better to emit than throw.
19:59:48  <isaacs>since emitting error throws anyway
20:02:47  * isaacs_mobilejoined
20:07:15  <piscisaureus_>igorzi: the patch looks good to me if it actually works
20:07:44  <piscisaureus_>igorzi: I am kind of surprised that v8's gyp can produce x64 builds now because when we started with gyp it couldn't
20:08:15  <piscisaureus_>igorzi: also, I forgot what's next up on your list. Can you say it again?
20:11:48  <AndreasMadsen>isaacs: if you have found an agreement I have updated the patch, you can land or close
20:12:46  * isaacs_mobilequit (Remote host closed the connection)
20:14:14  <piscisaureus_>bnoordhuis: did you talk to the rust guys already?
20:14:27  <bnoordhuis>piscisaureus_: a little. why?
20:14:47  <AndreasMadsen>isaacs: also land https://github.com/joyent/node/pull/2708 if #2650 should land
20:14:52  <piscisaureus_>bnoordhuis: https://mail.mozilla.org/pipermail/rust-dev/2012-February/001347.html
20:15:34  <bnoordhuis>piscisaureus_: yes, i've seen it
20:15:46  <piscisaureus_>bnoordhuis: ok, I assume you can figure it out now
20:16:10  <bnoordhuis>piscisaureus_: the thing rust most needs is the ability for c code to call rust functions
20:16:27  <bnoordhuis>if you want libuv bindings without tons of c++ glue code, that is
20:16:41  <bnoordhuis>it's in the works
20:16:43  <piscisaureus_>bnoordhuis: yeah. node has the same problem
20:16:45  <piscisaureus_>:-)
20:16:51  <piscisaureus_>bnoordhuis: we should cut back on our glue layer
20:16:59  <bnoordhuis>ah, but how?
20:17:54  <piscisaureus_>bnoordhuis: maybe we can have some sort of bitflag in every uv_stream_t that "describes" the type of stream we're dealing with
20:17:59  <creationix>cut back on glue?
20:18:14  <creationix>is rust C++ or C?
20:18:19  <bnoordhuis>creationix: c++
20:18:20  <piscisaureus_>e.g. whether it supports read/write, write2, send/recv, listen, shutdown etc
20:18:43  <bnoordhuis>piscisaureus_: we already kind of have that
20:18:53  <piscisaureus_>bnoordhuis: "we" as in unix?
20:18:56  <bnoordhuis>maybe not listen/shutdown
20:19:00  <creationix>what about the uv_fs stream type?
20:19:03  <creationix>is that still coming?
20:19:24  <piscisaureus_>creationix: I'd like to have it. But I am not clear about what the API should be
20:19:26  <bnoordhuis>piscisaureus_: no, i mean that you can look at handle->type
20:19:33  <piscisaureus_>bnoordhuis: oh like that
20:21:40  * mraleph1joined
20:22:17  <mraleph1>dap: hi. you wanted to ask something yesterday?
20:22:52  <mraleph1>bnoordhuis: hi to you too; it seems you also was asking me something yesterday :-)
20:23:23  <piscisaureus_>so one has to ask mraleph1 a question to get a greeting from him?
20:23:44  <bnoordhuis>mraleph1: oh, nothing important - i was wondering how v8's version numbering works (and why it works like that)
20:24:01  <bnoordhuis>i imagine back-porting all those patches takes quite a bit of effort
20:24:30  <bnoordhuis>with node we just say 'upgrade' and be done with it. works well :)
20:27:18  <mraleph1>bnoordhuis: it's pretty simple X.Y.Z.P
20:27:43  <mraleph1>X is incremented when there are major-major-major changes like Crankshaft.
20:28:13  <mraleph1>Y is incremented when we branch for a Chrome version.
20:29:20  <mraleph1>if trunk is X.Y.Z => canary & dev channel, X.(Y-1) is beta branch, X.(Y-2) is stable branch
20:29:52  <mraleph1>once X.Y.Z goes from trunk to versioned branch we stop incrementing Z and start incrementing P
20:30:15  <mraleph1>Z is incremented when we push from bleeding edge where development is done to the trunk.
20:30:26  <mraleph1>P is patch version.
20:30:35  <mraleph1>how it explains it
20:30:51  <bnoordhuis>mraleph1: clear, thanks
20:30:51  <indunty>omg
20:31:19  <bnoordhuis>even if 'simple' is not the word i'd pick for it :)
20:33:30  <tjfontaine>heh, it could certainly be worse
20:34:42  <mraleph1>seems pretty natural to me :-)
20:35:01  <indunty>bnoordhuis: you haven't seen version numbers at Yndx
20:35:02  * paddybyersjoined
20:35:20  <indunty>can't say much, but it really could be worse
20:35:25  * elijah-mbpquit (Remote host closed the connection)
20:37:03  <indunty>gtg
20:37:04  <indunty>ttyl
20:37:07  * induntychanged nick to indutny_sleeping
20:38:37  * elijah-mbpjoined
20:45:25  <tjfontaine>does anyone else see --debug-brk broken on 0.6.10? (<= 0.6.9 seem to be working appropriately)
20:46:59  * piscisaureus_quit (Read error: Operation timed out)
20:47:58  <bnoordhuis>tjfontaine: broken in what respect?
20:49:19  <tjfontaine>well, it's passing straight through and not breaking on start
20:53:39  * igorziquit (Ping timeout: 245 seconds)
20:53:41  <tjfontaine>I'll build 6.10 on linux and see if I get the same there
20:59:32  <tjfontaine>ya, same, falls through to the console.log("hello world") instead of breaking
20:59:42  <tjfontaine>I'll file an issue I guess
21:06:18  * mikealjoined
21:11:29  * mikealquit (Quit: Leaving.)
21:13:08  * AndreasMadsenquit (Remote host closed the connection)
21:20:25  <bnoordhuis>tjfontaine: so it works with 0.6.9, fails with 0.6.10?
21:20:31  * perezdjoined
21:21:33  <tjfontaine>bnoordhuis: yes, also fails on master https://github.com/joyent/node/issues/2710
21:21:55  <bnoordhuis>tjfontaine: thanks. also: weird
21:22:12  <tjfontaine>agreed.
21:23:20  * dap1joined
21:24:43  * dapquit (Ping timeout: 244 seconds)
21:24:43  * dap1quit (Read error: Connection reset by peer)
21:26:37  * igorzijoined
21:30:47  * dapjoined
21:37:19  <CIA-101>node: Igor Zinkovsky v0.6 * r0a34755 / (8 files in 4 dirs):
21:37:19  <CIA-101>node: enable x64 windows build
21:37:19  <CIA-101>node: use "vcbuild x64" to do x64 build of node.exe - http://git.io/ZN5BrQ
21:44:33  * bnoordhuisbisects...
21:45:14  * travis-cijoined
21:45:14  <travis-ci>[travis-ci] joyent/node#381 (v0.6 - 0a34755 : Igor Zinkovsky): The build passed.
21:45:14  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/7543c38...0a34755
21:45:14  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/640939
21:45:14  * travis-cipart
21:50:20  * isaacs_joined
21:53:08  * isaacsquit (Ping timeout: 244 seconds)
21:55:15  <isaacs_>bnoordhuis: hey, why do we have a binding to ftruncate(fd, len) but not truncate(path, len)?
21:55:31  * isaacs_changed nick to isaacs
21:56:22  <isaacs>that seems like a mistake to me.
21:56:59  <bnoordhuis>isaacs: i don't know
21:57:04  <bnoordhuis>are people complaining about it?
21:57:17  <isaacs>nah, just doing doc stuff, and it's an inconsistency i noticed.
21:57:27  <isaacs>not a high priority thing, and easy to fix. i'll log an issue on it.
21:57:42  <isaacs>or maybe just fix it... this stuff is kind of boring :)
21:59:38  * brsonquit (Ping timeout: 260 seconds)
22:00:20  <bnoordhuis>paddybyers: ping
22:01:13  <bnoordhuis>isaacs: maybe you know - 840229a breaks `node --debug-brk script.js` and i don't see why...
22:02:16  <isaacs>that's... really weird.
22:02:32  * isaacsbecoming more and more firm in the position that lib/module.js never ever changes for any reason ever.
22:02:37  <bnoordhuis>heh
22:02:45  <isaacs>even ostensibly "safe" cleanup is never safe.
22:02:59  <bnoordhuis>i should probably revert it but i'd like to understand the why
22:03:22  <isaacs>bnoordhuis: yeah, i would, too.
22:03:40  <isaacs>but, if you don't have time to read through and root-casue what --debug-brk is doing, i'm ok with just reverting it and asking questions later.
22:03:57  <isaacs>it'd be nice to have a test that verifies --debug-brk works. i thought we had one (maybe that was in master?)
22:04:35  <bnoordhuis>i don't think we do
22:04:41  <bnoordhuis>i'll see if i can come up with something
22:05:47  <tjfontaine>man, that's not a fun answer to a bisect
22:07:45  <isaacs>ohhhh... wait, i think i know why
22:08:06  <isaacs>there's some module jiggery pokery that had to be added to make --debug-brk work when the file is symlinked.
22:08:20  <isaacs>bnoordhuis: there's probably a better fix.
22:09:19  * bnoordhuislooks at ccf7b41
22:13:06  <mmalecki>why do we need all that utf8 crap here? JSON.parse deals with buffers just fine
22:13:07  <mmalecki>https://github.com/joyent/node/blob/840229a8251955d2b791928875f36d35127dcad0/lib/module.js#L465-466
22:14:06  <isaacs>igorzi: is there a way to truncate based on a path on windows? like _chsize(char*,int)?
22:14:17  * creationixpart ("Ex-Chat")
22:14:59  <isaacs>mmalecki: scroll up a few lines. lib/module.js may not be touched unless it's causing an actual demonstrable bug.
22:15:31  <mmalecki>isaacs: that's why I'm looking at lib/module.js :)
22:15:47  <dap>Hi again mraleph. Sorry I missed you earlier.
22:15:47  <mmalecki>isaacs: not wanting to change it, just curious
22:15:57  <bnoordhuis>isaacs: https://github.com/bnoordhuis/node/commit/ae11537
22:16:15  <isaacs>bnoordhuis: lgtm. that's exactly the kind of fix i figured it would take.
22:16:19  <isaacs>thanks for tracking that down
22:16:48  <bnoordhuis>simple/test-net-write-slow is failing for me btw (with and without that patch)
22:17:19  <CIA-101>node: Ben Noordhuis v0.6 * r09c296b / lib/module.js :
22:17:20  <CIA-101>node: debugger: fix --debug-brk
22:17:20  <CIA-101>node: Commit 840229a forgot to update the debugger special case in lib/module.js
22:17:20  <CIA-101>node: Fixes #2710. - http://git.io/ruHAdw
22:17:43  <dap>or should that be mraleph1?
22:17:52  <tjfontaine>bnoordhuis: excellent thanks
22:17:59  <igorzi>isaacs: yes, there's _chsize on windows (that's what fs.ftruncate uses)
22:18:17  <isaacs>igorzi: right, but is there one that takes a char* rather than a int?
22:18:21  <isaacs>ie, a path rather than a fd
22:19:53  <igorzi>isaacs: no, i don't think so
22:19:58  <igorzi>isaacs: why do you need it?
22:20:08  <isaacs>igorzi: well, it just breaks the pattern, that's all.
22:20:17  <isaacs>igorzi: we've got chmod/fchmod, chown/fchown, etc.
22:20:46  <isaacs>usually you've got xyz(path, blah, balh) and a counterpart fxyz(fd, blah blah)
22:21:02  <isaacs>but node's fs.truncate is actually ftruncate
22:21:16  <igorzi>isaacs: we could implement it in libuv (with open+ftruncate+close).. that's how some of the xyz functions are implemented (using fxyz)
22:21:58  <isaacs>yeah, that's how we're doing some of the link functions, as well.
22:22:57  <isaacs>api symmetry would be nice, if it's easy
22:25:18  * travis-cijoined
22:25:18  <travis-ci>[travis-ci] joyent/node#382 (v0.6 - 09c296b : Ben Noordhuis): The build passed.
22:25:18  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/0a34755...09c296b
22:25:18  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/641194
22:25:18  * travis-cipart
22:30:59  <paddybyers>bnoordhuis: hi
22:31:48  <bnoordhuis>paddybyers: hey. false alarm, the problem's already been solved :)
22:32:03  <paddybyers>ok :)
22:34:21  <paddybyers>oops, I see what happened
22:34:32  <isaacs>paddybyers: mostly my fault, actually
22:34:40  <isaacs>paddybyers: patches got applied out of order :)
22:36:14  <paddybyers>isaacs: there should be something in github to deal with that - warn if rebasing triggers merges before landing something
22:37:34  <isaacs>we dont' do auto-merges on github anyway
22:37:57  <isaacs>in this case, i'd just flat-out forgotten that i'd suggest indutny touch that private _resolveFilename method
22:43:57  <bnoordhuis>isaacs: https://github.com/bnoordhuis/node/commit/81d1839 <- --debug-brk test
22:44:47  <isaacs>bnoordhuis: lgtm
22:44:57  <isaacs>bnoordhuis: 2 seconds seems like kind of a lot, though
22:45:00  <CIA-101>node: Ben Noordhuis v0.6 * r81d1839 / (2 files in 2 dirs): test: add --debug-brk regression test - http://git.io/DNMqWQ
22:45:20  <bnoordhuis>isaacs: the debug build takes quite some time to start up the debugger
22:45:33  <bnoordhuis>especially when you run `make test-all`
22:46:15  <isaacs>fair enough
22:46:32  * AvianFluquit (Quit: Leaving)
22:50:23  <bnoordhuis>TooTallNate: https://github.com/bnoordhuis/node-buffertools/pull/23/files <- was that lovingly handcrafted just for buffertools?
22:52:14  <mmalecki>btw, idea: automatically append node minor version to compiled addon filename
22:52:29  <mmalecki>as in addon.v0.7.node
22:52:44  <tjfontaine>hmm
22:52:53  <mmalecki>it'd make rebuilding for different node versions easier. also, no more ABI problems
22:53:11  * travis-cijoined
22:53:11  <travis-ci>[travis-ci] joyent/node#383 (v0.6 - 81d1839 : Ben Noordhuis): The build passed.
22:53:11  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/09c296b...81d1839
22:53:11  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/641294
22:53:11  * travis-cipart
22:53:28  <mmalecki>(and handle that in bindings module)
22:53:42  <mmalecki>what do you guys think?
22:54:13  <TooTallNate>bnoordhuis: yes sir! I'm making my way through as many native modules as I can: https://github.com/TooTallNate/node-gyp/issues/8
22:55:08  <TooTallNate>mmalecki: the 'copy' command in node-gyp was gonna do something equivalent
22:55:22  <bnoordhuis>TooTallNate: that's very sweet. :) - now i have to test it though
22:55:33  <TooTallNate>mmalecki: plus that filename doesn't account for the other things, like platform and arch
22:55:46  <TooTallNate>bnoordhuis: please do :) let me know how node-gyp works out for you
22:56:10  * bnoordhuisstarts up his dusty, dusty windows vm
22:56:12  <mmalecki>TooTallNate: yeah, ideally we'd have almost everything there (as fedora or debian packages do, for example)
22:56:29  <mmalecki>isaacs: what do you think? ^
22:56:30  <tjfontaine>mmalecki: something about that doesn't taste very well, path'ing seems saner than file naming
22:56:39  <TooTallNate>right, i agree. the problem though is that the bindings file requires a certain filename currently
22:57:05  <TooTallNate>which is why node-bindings looks in directories rather than a specific filename
22:58:05  <tjfontaine>mmalecki: but in this case the correlation is more to a library than a package in distribution land
22:58:08  <mmalecki>I can imagine building the right directory structure being harder than using file names
22:58:19  <mmalecki>tjfontaine: yeah
22:58:24  <isaacs>i'm not really a fan of this require("bindings")("fo.node") approach, personally
22:58:42  <TooTallNate>isaacs: really? i like it personally. i'm open to suggestions though
22:58:50  <isaacs>it seems like you ought to just get the version of the package that is compiled for your arch, with the basic case being that you compile it yourself
22:59:05  <isaacs>we shouldn't be delivering a x86 thing to someone not on x86, etc.
22:59:09  <TooTallNate>the problem is that over the course of time, there's so many places that a bindings file can live
22:59:15  * brsonjoined
22:59:16  <tjfontaine>can we make node-gyp symlink into project home, like the common patter with -waf?
22:59:22  <tjfontaine>*pattern
22:59:33  <TooTallNate>symlink is a dirty word on windows :p
22:59:40  <mmalecki>tjfontaine: that's a good idea
22:59:42  <isaacs>TooTallNate: right, but those differences are differences in the computer itself. it's not going to change.
22:59:57  <tjfontaine>ok cp/mv works as well I guess, I'm not opposed to that
23:00:02  <isaacs>the only benefit of doing this is for binary deployments that don't make binary deployment a first-class citizen
23:00:21  <isaacs>so you download windows version on linux, and vice versa, because you only have one hammer to hit the nail with.
23:00:24  <TooTallNate>isaacs: right, npm could easily handle what node-bindings is handling
23:00:32  <TooTallNate>and render node-bindings irrelevant
23:00:33  <isaacs>right. we control the package system.
23:00:56  <TooTallNate>isaacs: the bin-upload thing needs to be done right though
23:01:04  <isaacs>if you're compiling at install time, it's unnecessary. if you're compiling ahead of time, then tag the whole tarball.
23:01:07  <isaacs>TooTallNate: yes, indeed.
23:01:09  <TooTallNate>isaacs: which is why i wrote node-bindings for the interrim
23:01:12  <isaacs>kewl
23:01:26  <isaacs>what are you finding the breakdown should be?
23:01:41  <isaacs>foo-linux-v0.7-x86.node is that enough?
23:01:50  <isaacs>well, linux is a madhouse.
23:01:58  <isaacs>foo-win32-0.7-x86.node
23:02:05  <isaacs>foo-darwin-0.7-x86.node
23:02:15  <TooTallNate>haha, i mean that works, but then what do you "require" in your script to get the right one?
23:02:24  <TooTallNate>node-bindings normalized that for you
23:02:40  <mmalecki>TooTallNate: maybe handle that in require logic?
23:02:44  <tjfontaine>I wish lsb were real, then I'd say -<lsb_release>
23:02:53  <TooTallNate>mmalecki: ya that might work
23:03:10  <mmalecki>TooTallNate: try to require addon.node, then addon-<platform>-<version>-<arch>.node
23:03:14  <TooTallNate>mmalecki: would break backwards compat though
23:03:24  <mmalecki>TooTallNate: no, why?
23:03:58  <TooTallNate>mmalecki: that logic wouldn't be in a 0.6.x node
23:04:15  <mmalecki>TooTallNate: meh, node 0.6 is old
23:04:18  <TooTallNate>so your module wouldn't work there
23:04:22  <TooTallNate>haha, i suppose
23:04:27  <TooTallNate>but if the code works...
23:04:47  <TooTallNate>mmalecki: i was even considering adding 0.4.x support to node-gyp!!!
23:04:51  <TooTallNate>which would be kinda crazy
23:04:54  <mmalecki>TooTallNate: don't
23:04:59  <mmalecki>TooTallNate: really
23:05:05  <mmalecki>I can't wait for it to die
23:05:13  <mmalecki>I hate it so much
23:05:39  <TooTallNate>:p ok no sweat off my back
23:06:08  <TooTallNate>the only reason 0.4.x doens't work out of the box is cause of the way the directory structure changed in nodejs.org/dists
23:06:17  <TooTallNate>nodejs.org/dist i mean
23:07:28  <mmalecki>TooTallNate: oh? it'd be a hassle to support anyway
23:07:46  <TooTallNate>well that's up to the module authors :)
23:07:55  <TooTallNate>but like my node-time for example still works fine on 0.4.x
23:08:09  <TooTallNate>so dropping support for it just cause of the build system kinda tickled me the wrong way
23:08:13  <TooTallNate>but it *is* ancient
23:08:53  <mmalecki>I mean, there are many packages which still work there
23:09:32  <mmalecki>I test my packages for 0.4 compatibility on travis, but when tests stop passing, I'll just remove 0.4 from build matrix
23:09:41  <TooTallNate>anyway, its not a huge deal, i'll probably not even bother unless i'm bored one of these days
23:14:08  <mmalecki>damn, I accidentally myself out of the zone. so I guess I'm staying with you, IRC.
23:15:23  <tjfontaine>is there a flag to use on sockets to treat them like file watchers that if they're the only ones in the event queue it's ok for the process to exit?
23:16:45  <dap>is there a list somewhere of which V8 version shipped with each released node version?
23:19:39  * mjr_joined
23:27:52  <mraleph1>dap: I was away again :-)
23:28:39  <dap>mraleph1: no problem :) I've spent the last couple of days digging deeper into V8. Specifically, I've been trying to figure out how V8 uses the stack.
23:29:41  <dap>I've learned a bunch about how various types of stubs and such are generated, and what they do, and I've also learned that all of the problems our tools have with collecting a full stacktrace come from -fomit-frame-pointer.
23:29:42  <mraleph1>anything I can help you with? :-)
23:29:49  <dap>I was wondering: why does V8 use that?
23:30:08  <mraleph1>you mean -fomit-frame-pointer?
23:30:10  <dap>yeah
23:30:31  <mraleph1>well it gives you 23% more registers (or something like that) ;-)
23:30:53  <dap>yeah, and makes your program undebuggable :)
23:31:27  <mraleph1>I guess on x64 one can remove that option
23:31:50  <dap>have you seen a workload whose performance is measurably affected by having an extra register on i386?
23:32:42  <mraleph1>I vaguely remember doing some measurements but I don't recall anything precise, no.
23:33:28  <dap>okay, that answers my question then. I was curious if it was added in response to some benchmark or something.
23:33:55  <mraleph1>well it very well might have been, but that was before my time :-)
23:34:43  <dap>what would you think about removing it for x86, at least on solaris?
23:35:44  <dap>here's an example of what we can get: https://gist.github.com/3ff613af558447d22f7b
23:36:05  <dap>the trace includes native frames, javascript, back into native, all the way up to main.
23:36:22  <dap>that was actually taken on entry to operator new
23:38:37  <mraleph1>I can at least redo measurements to see if it affects perf.
23:39:26  <dap>cool. that'd be interesting to see.
23:40:05  <dap>I'm thinking of writing up what I've learned about V8 in a series of blog posts.
23:40:49  <dap>for some of my colleagues and I, it's been something of a black box, but it's been nice lately to be able to look inside :)
23:44:01  <mraleph1>"when you gaze long into an abyss the abyss also gazes into you." :-)
23:44:09  <isaacs>Please test: nodejs.org/dist/v0.7.3/node-v0.7.3-RC0.tar.gz
23:44:13  <isaacs>Please test: http://nodejs.org/dist/v0.7.3/node-v0.7.3-RC0.tar.gz
23:45:09  <dap>:)
23:45:37  <dap>anyway, I've been having fun peering into this abyss
23:57:39  * paddybyersquit (Quit: paddybyers)
23:58:16  * mraleph1quit (Quit: Leaving.)