Mochabot log - CommonJS IRC channel: #commonjs on irc.freenode.net

2009-12-05:

[0:05] <deanlandolt> tlrobinson: you around?
[0:21] <ashb> damn. my 3G dongle doesnt work on snow leopard
[0:23] <Wes-_> well that sucks
[0:23] <Wes-_> I can't even figure out where to plug my 3G PCMCIA card into my new laptop
[0:24] <Wes-_> I guess I should have checked the ports before I bought it. ;)
[0:24] <ashb> heh
[0:24] <Wes-_> (do they make 3G USB dongles for north america?)
[0:24] <ashb> no laptops have pcmciaa anymore
[0:24] <ashb> it express 34 or nothing
[0:25] <Wes-_> well that sucks
[0:25] <Wes-_> I also have a PCMCIA CD drive that doubles as a walkman
[0:25] <Wes-_> what am I going to do with THAT?
[0:25] <ashb> o_O
[0:25] <ashb> throw it at someone
[0:26] <Wes-_> lol - I wonder if they ever made win2k+ drivers for it?
[0:26] <Wes-_> it's an actual branded Sony Discman
[0:45] <Wes-_> deanlandolt / ashb: either of yiou guys ever worked with libev?
[0:45] <ashb> not directly
[0:45] <ashb> used perl's AnyEvent a small bit
[0:46] <Wes-_> any idea what a JS binding for it would look like?
[0:46] <Wes-_> I guess you would somehow bind to libev, kick off the event loop, and then start running the actual JS program (as opposed to the event loop handler)
[0:46] <ashb> hmmmm. not that much to it.
[0:46] <ashb> loop, unlooop, enqueue and maybe a few more
[0:47] <Wes-_> I wonder why ryan does for muliple programs
[0:47] <Wes-_> I guess multiple cx's, multiple global objects
[0:47] <Wes-_> s/why/what/
[0:47] <Wes-_> each global object would need to be in the same runtime
[0:48] <Wes-_> so they could require() the same modules
[0:48] <ashb> mult? node doesnt supprot mult in the same process i dont think
[0:48] <Wes-_> one of those would be require("ev") for .enqueue or something
[0:48] <Wes-_> ashb: does he do ssjs in his webserver?
[0:49] <Wes-_> or, wait
[0:49] <Wes-_> maybe he has a bunch of processes that pipeline around maybe?
[0:49] <ashb> sockets and the http parser is in proc
[0:49] * Wes-_ wishes there was a "node.js arch overview" somewhere
[0:49] <ashb> single proc, with thread pool for unsafe (from a sync fs pov) posix op
[0:50] <Wes-_> interesting, then he probably does ssjs in preforkd processes so he can do async reads from the pipes maybe?
[0:51] * Wes-_ thinks hard
[0:51] <ashb> no forking that i know of
[0:52] <Wes-_> Hmm, I wonder how he runs ssjs then? Or is it just a web server written in JS that serves static content?
[0:52] <ashb> what do you mean?
[0:52] <Wes-_> is his web server written in C++ or JS?
[0:53] <ashb> the http parser is
[0:53] <ashb> C
[0:53] <ashb> reponse /logic is in js
[0:53] <Wes-_> okay.. and he must do ssjs content
[0:53] <Wes-_> do you think he does it in the same context as the response logic?
[0:53] <ashb> theres a trivial example in github.com/ry/node
[0:53] <ashb> benchmarks folder
[0:54] <ashb> there s only one js context afik
[0:56] <Wes-_> so that means that if there is user-supplied js content it can access the innards of the HTTP server
[0:56] <Wes-_> basically everything is analogous to an apache module
[0:57] <ashb> perhaps. i'm not sure how much is exposed
[0:57] <ashb> right: train is pulling in
[0:57] <ashb> &
[0:57] <Wes-_> take it easy, eh?
[0:58] <ashb> have to give BS talk tomorrow on "career development" :/
[0:59] <Wes-_> well, BS is a good way to achieve tht
[0:59] <ashb> exaactly
[1:00] <ashb> somehow i have to expand "make contacts and be cocky" to 45 mins tho
[1:00] <Wes-_> give a demo of "linked in"
[1:00] <Wes-_> people will think you're all web 2.0
[1:01] <ashb> heh
[1:01] <Wes-_> and it will chew up 20 minutes
[1:01] <ashb> &
[1:01] <ashb> really
[1:02] <Wes-_> my strategy of late has been "make friends with well-placed people, let them pick your brains for ideas, then giggle when somebody else phones you and asks if it's a good idea"
[1:19] <ashb> and home
[1:37] <ashb> 'There are already at least a million lines of js out there based on SproutCore' i find that hard to belive for some reason
[1:40] <Wes-_> I dunno, that would only be 500 toy projects
[1:42] <Wes-_> apprently MobileMe is built sproutcore, interesting
[1:59] <okito> hey guys - MobileMe is well over 500,000 lines of SC
[1:59] <okito> OtherInbox is pretty big
[1:59] <okito> Gomez (http://www.gomez.com) is all SC
[2:00] <okito> Eloqua (http://www.eloqua) has rewritten their entire campaign management suite on it. It is very big
[2:00] <okito> Bespin is currently transitioning to it
[2:00] <okito> and there are a half dozen other very big projects I can't talk about
[2:00] <okito> hope that justifies the LOC comment
[2:01] <okito> ashb, Wes-_ ^^
[2:01] <Wes-_> okito: nice, are you charles?
[2:02] <okito> yes
[2:02] <Wes-_> BTW, was just thinking about using it in a next.project.here (currently shoping for right framework)
[2:02] <Wes-_> okito: welcome!
[2:02] <okito> :)
[2:02] <okito> would love to help you out. thanks!
[2:02] <okito> I hope I"m not being rude intruding on the talk. just trying to make the next version of SC as CommonJS friendly as possible
[2:02] <okito> :D
[2:03] <Wes-_> nah
[2:03] <Wes-_> we're a cranky group but only 'cause we care. And more input is always better.
[2:03] <ashb> okito: yeah wes pointed out its not that unresonable at all
[2:03] <Wes-_> okito: what do SproutCore modules currently look like and how many do you figure there are?
[2:04] <okito> well right now SC is not module based
[2:04] <okito> I am converting it
[2:04] <okito> most projects though divide their code into "frameworks", which are basically equivalent to packages
[2:04] <okito> each framework usually has a core.js file where you define your namespace
[2:04] <okito> i.e.
[2:04] <Wes-_> ashb: I've been reading libev docs. I wonder how to selectively turn on an event loop sexily
[2:04] <okito> MyApp = SC.Application.create({ .... })
[2:05] <okito> then all your other files add properties to the root namespace
[2:05] <okito> MyApp.MyView = SC.View.extend({ ... })
[2:05] <okito> with my tiki branch of SC, each file becomes its own module
[2:05] <Wes-_> what do the core SC libraries look like? Big object of objects?
[2:05] <okito> All of SproutCore would be about 200 modules
[2:05] <okito> the SC namespace has a bunch of objects, yes
[2:06] <okito> this was written before modules so we put everything into a single namespace to avoid confusion
[2:06] <okito> er to avoid pollution of the window obj
[2:06] <Wes-_> Since you're already namespaced, I think you should be able to find a way to boiler-plate all of SC in relatively cheaply
[2:06] <okito> my idea was to make all that work with modules
[2:07] <Wes-_> how are you implementing require()?
[2:07] <okito> following the spec
[2:07] <okito> actually the one proposed for ES5
[2:07] <Wes-_> synchronous XHR? preloads? some async extension?
[2:07] <okito> oh.
[2:07] <okito> the loader has a registration API
[2:08] <okito> when you load scripts from the server they register packages, modules, scripts, etc.
[2:08] <okito> the package registration includes a list of all scripts, stylesheets and other packages you depend on
[2:08] <okito> if you do require.async(), then via a promise API I load whatever is missing
[2:08] <Wes-_> Interesting, how do you figure out the package depends? static analysis?
[2:08] <okito> if you do require() it just check to see if the package is already there.
[2:08] <okito> well, SproutCore has some build tools that are pretty complex
[2:08] <Wes-_> interesting
[2:09] <okito> so frameworks are already setup to name dependencies in their config files
[2:09] <okito> so I use that.
[2:09] <Wes-_> you could build a namespace full of require and require async methods
[2:09] <Wes-_> the interesting thing is, that you could thunk them in to avoid a performance penalty
[2:09] <okito> how do you mean?
[2:10] <Wes-_> I proposed a word-coinage last week, around the fact that CommonJS is going to "mandate" certain modifications to the standard classes I don't want to pay the load-time price for (require for me loads and links DSOs):
[2:11] <Wes-_> String.prototype.toByteString = function(charset) {
[2:11] <Wes-_> String.prototype.toByteString = require("binary").String_toByteString;
[2:11] <Wes-_> return String.prototype.toByteString(charset);
[2:11] <MisterN> Wes-_: i think it's unfair that kris listed flusspferd only after sproutcore, wakanda and slideshare, even though we do have commonjs support and they apparently don't really
[2:11] <Wes-_> }
[2:11] <Wes-_> fair, unfair, I don't even know what list you're talking about but I try to avoid competetive oriented stress
[2:11] <okito> interesting idea.
[2:12] <okito> so it automatically requires on demand
[2:12] <okito> actually we built something in the API a while back similar to this
[2:12] <Wes-_> exactly. No, for me, synchronous require makes sense, too, but you could use a similar technique with async
[2:12] <okito> we define a method on SC.Object called invokeWith()
[2:12] <okito> so you can do
[2:12] <Wes-_> I coined the term monkey-thunk because it's like a cross between monkey-patching and real assembler-level API thunking
[2:13] <MisterN> ah, they are in the article because they presented in jsconf.eu
[2:13] <okito> MyApp.invokeWith('Foo', function() { .. })
[2:13] <okito> The default implementation just calls function() with MyApp.Foo as the default
[2:13] <okito> but if you use an SC.StubObject instead
[2:13] <okito> invoekWith would require.async() first
[2:13] <okito> monkey-thunk is a good name! :-)
[2:14] <Wes-_> the clever thing with a monkey-thunk is that if you set of the object hiearchy ahead of time, how it is implemented (or thunked in) doesn't leak out at the programmer
[2:14] <okito> I suppose I could just assume what module imports will be required on a legacy bit of code
[2:14] <okito> right
[2:14] <Wes-_> meaning you can change it, and you get the benefits normally associated with late binding/resolution
[2:14] <okito> well this would only work if you are swapping out methods
[2:15] <Wes-_> OIC
[2:16] <Wes-_> yeah, a module-imports giant object would actually be what you'd need to throw in for a bit of legacy code
[2:16] <okito> so I guess the big issue that most code is written like:
[2:16] <okito> MyApp = SC.Object.... blah blah
[2:16] <okito> it assumes MyApp & SC
[2:17] <Wes-_> Is MyApp a module? a "program" module?
[2:17] <Wes-_> SC is easy
[2:17] <Wes-_> var SC = { Object: require('object") }
[2:17] <okito> yeah if I have to make ppl do that on every file it gets ugly fast
[2:17] <okito> I was trying to save some developer ergonomics
[2:18] <Wes-_> okito: That's why I was suggesting a giant one, with hudnreds of monkey-thunked entries
[2:18] <okito> I see
[2:18] <okito> hm
[2:18] <okito> interesting idea.
[2:18] <okito> well I have to head home to meet the wife
[2:18] <okito> but I'll be back.
[2:18] <okito> thanks for the suggestions. :)
[2:19] <Wes-_> you're welcome
[2:45] <Wes-_> ashb: So, I've been looking at fixing that mmap-on-mac bug you flusspferd guys prompted me to stop earlier this week
[2:45] <Wes-_> ashb: I thought I had a solution, but it wasn't working
[2:45] <Wes-_> Invested 30 minutes in troubleshooting:
[2:46] <Wes-_> it turns out, you have to compile the code on the same machine you're editing it on!
[2:51] <MisterN> Wes-_: sounds like something to stick on a post-it note.
[2:51] <Wes-_> Good idea! LOL
[2:52] <Wes-_> entertaingly enough, by "fixing" it to work the same everywhere, I propagated breakage to Solaris instead of works-good to leopard
[2:53] <Wes-_> So, now by "perfectly" puling the right #defines for the version of UNIX I've said GPSEE is, I've lost MAP_SHARED and friends. *hmmm*, what standard is mmap in?
[3:33] <tolmasky> is there a commonjs equivalent to string.strip in ruby?
[3:49] <Wes-_> tolmasky: String.prototype.trim is slated for ECMAScript-5
[3:50] <Wes-_> It's already present in many implementations and there's plenty of code on the web, I'm sure
[4:44] <kriskowal> tolmasky since String.trim is in ES5, it's in Narwhal
[4:45] <kriskowal> or, might not have landed yet. it's in http://github.com/kriskowal/narwhal/blob/refactor/engines/default/lib/global-es5.js
[4:45] <Wes-_> kriskowal: did you ever realize that the key to cheaply coercing mutable byte-types to immutable ones is a backend COW implementation?
[4:45] <kriskowal> and, for what it's worth, commonjs loosely agreed at one point to support ES5-as-implementable-in-ES3, which is what that module does
[4:46] <kriskowal> yes
[4:46] <Wes-_> damn, it took me half an afternoon to figure it out. Well, that an the mechasnim to implement, and the finalizer-steal algorithm
[4:46] <Wes-_> I felt like a bloody genius when I was done, lol
[4:47] <kriskowal> Wes-_ that was my thesis for sticking with our current proposal's direction instead of going with what maceij stochowiak suggested
[4:48] <kriskowal> maciej's proposal made that optimization explicit at the js layer
[4:48] <Wes-_> nod - I always knew COW was handy, but I never put 2 and 2 together and realized that that was the for going from mutable-to-immutable
[4:48] <kriskowal> there are a bunch of other uses
[4:48] <Wes-_> and THAT is important for reading data, stripping off newlines, and yielding bytestrings
[4:48] <kriskowal> e.g., slice
[4:49] <Wes-_> Yup, slice is obvious - I think I probably missed the mutable->immutable pattern obviousness because I'm a C guy "oh just cast it away"
[4:49] <kriskowal> i'm glad you're making it work. i only suspected that it would work.
[4:49] <Wes-_> I only suspect, too, but I'm pretty dang confident by now. ;)
[4:49] <kriskowal> there are some subtleties
[4:49] <Wes-_> I'm also letting certain immutable-objects' methods work on mutable types
[4:49] <Wes-_> I think that's safe when no threads
[4:49] <kriskowal> theoretically two mutables can share for a while
[4:50] <kriskowal> ah, threads.
[4:50] <Wes-_> depends on the meaning of the sharing - I share backing store for mutables all the time in FFI-related code
[4:50] <Wes-_> I can actually freely "cast" between FFI types (e.g. structs) and Binary/B types
[4:51] <Wes-_> yeah, call()/apply() from ByteString methods are perfectly safe on ByteArray, provided the ByteArray doesn't mutate during the call
[4:51] <Wes-_> threads take away the guarantee that it won't
[4:52] <kriskowal> yeah, you would need fancy locking to share across threads.
[4:52] <kriskowal> share a byte-array anyway.
[4:52] <Wes-_> mozilla implements it for its native objects
[4:53] <Wes-_> it's actually really cool, really cheap and patented royalty-free
[4:53] <Wes-_> it's also kind of over my head, lol
[4:56] <Wes-_> tolmasky: you missed your answers, long story, you want String.prototype.trim, it's in the ES5 draft, in some CommonJS now (flussferd, gpsee, rhino now or soon), probably in all eventually
[4:56] <tolmasky> cool, im currently using prototype's impl
[4:57] <tolmasky> any reason not to just add it to commonjs in an engine agnostic way? (? if (!string.trim) string.trim = ...
[4:57] <Wes-_> tolmasky: no reason
[5:10] <kriskowal> tolmasky http://github.com/kriskowal/narwhal/blob/refactor/engines/default/lib/global-es5.js
[5:11] <kriskowal> it hasn't landed yet, but it's intended for use in any engine
[5:32] <JohnnyL> kripken quite alot of code.
[5:32] <JohnnyL> kriskowal ^
[5:33] <kriskowal> gets the job done
[5:38] <Wes-_> kriskowal: that doesn't come with rhino?
[5:38] <Wes-_> does rhino have generators?
[5:38] <kriskowal> it does now
[5:39] <kriskowal> not in a rhino release yet tho
[5:39] <kriskowal> oh, sorry
[5:39] <kriskowal> rhino now has es5isms
[5:39] <Wes-_> generators *rock*
[5:39] <kriskowal> rhino doesn't yet have generators or comprehensions.
[5:40] <Wes-_> function readln() { while (fgets(line)) { yield ByteString(line) }
[5:40] <Wes-_> ^^^^
[5:40] <kriskowal> yeah. i use generators and comprehensions in python all the time. i've been accused of using them too often.
[5:40] <Wes-_> heh, I am still feeling my way around them
[5:41] <Wes-_> hdon wrote something cool for gpsee, a consume-and-yield pipeline
[5:41] <Wes-_> you can have consume-and-yield functions or strings which behave basically like piped shell commands
[5:41] <kriskowal> yeah. you can also do coroutines with a "trampoline"
[5:41] <Wes-_> for (line in cay("grep wes /etc/passwd")("sed s/wes/kris/")) { print(line) }
[5:41] <Wes-_> Yeah, neil mix's article
[5:41] <Wes-_> that was really neat, too
[5:42] <kriskowal> missed neil's mix article
[5:42] <kriskowal> but i've seen it in py
[5:42] <Wes-_> kriskowal: http://www.neilmix.com/2007/02/07/threading-in-javascript-17/
[5:42] <Wes-_> ignore the T-word
[5:44] <kriskowal> you're familiar with muds?
[5:44] <Wes-_> kriskowal: I played lambda-moo back in '92 for a couple of months
[5:44] <JohnnyL> Funny how gvim takes up 23 megs of ram. I blame the lack of reuse.
[5:44] <Wes-_> I blame lack of emacs
[5:44] <kriskowal> one of the big pains in mud writing is the "nanny", a bunch of state machine code that ushers a use through character creation.
[5:44] <Wes-_> It shoudl take at LEAST 230 megs!
[5:44] <kriskowal> which is its own sort of chose your own ending novel
[5:45] <Wes-_> oh like, a microsoft "wizard"
[5:45] <Wes-_> or creating a D&D character
[5:45] <kriskowal> yeah, so the console is in a "state" that accepts particular kinds of commands at different times.
[5:45] <kriskowal> like "chose a race" and you have to type "elf" or something, and there are a bunch of these states and different transitions along the way
[5:45] <Wes-_> yeah, and if you chose to be a cleric, you're not allowed to have a sword
[5:46] <kriskowal> so, i used generators to express the state machine. you would yield a command state.
[5:46] * Wes-_ is suddenly whisked back to the 80s
[5:46] <Wes-_> Oh, that's a cool idea!
[5:46] <kriskowal> underlying it there was a "state" stack, and some states were generators that would push new states whenever they yielded, and pop when they completed.
[5:47] <kriskowal> so you could push a generic generator for a particular workflow
[5:47] <Wes-_> I wonder if you could use something like that to build a recursive descent parser
[5:47] <kriskowal> yeah, you could.
[5:48] <kriskowal> if you switch "command line state" with "web page", you could also have a persistent generator for a web application to usher a user through application states
[5:48] <Wes-_> I wonder further if you could build a parser whose control code looked remarkably like its BNF form, but was written entirely in legal javascript
[5:48] <kriskowal> like push a login page, so all requests would go to that state. at the moment, and for good reasons, the web is a pretty simple state machine
[5:49] <Wes-_> except you'd need to somehow persist the generator on the service side
[5:49] <kriskowal> but it isn't a push-down state machine
[5:49] <kriskowal> yes.
[5:49] <Wes-_> oh, no, you could do it on the client
[5:49] <kriskowal> m. maybe.
[5:49] <Wes-_> depends on how much you care if the guy cheats or not
[5:49] <Wes-_> and how good your validaton code is
[5:49] <kriskowal> among other things
[5:49] <kriskowal> progressive enhancement
[5:50] <Wes-_> keeping the generator state might not be too hard for a single server running something like node.js
[5:50] <kriskowal> if you care about it. there's definitely a point after which you shouldn't care about PE
[5:50] <kriskowal> right
[5:50] <kriskowal> node is designed for this kind of thing
[5:50] <Wes-_> yeah
[5:50] <Wes-_> I watch ry's presentation
[5:50] <Wes-_> and took a read through libev
[5:50] <kriskowal> i was there :P
[5:51] <kriskowal> he did a really good job
[5:51] <kriskowal> palpable excitement
[5:51] <Wes-_> I'm pretty sure I could pop a libev event loop into gpsee easily, but I'm afraid i wouldn't know what to do with it
[5:51] <Wes-_> Yeah, his talk was great, you're lucky to have been there
[5:51] <Wes-_> he convinced me that his design is probably the winning design for max throughput per cpu
[5:51] <kriskowal> we talked afterward. node is very "ideological", which i think is compelling to a lot of people.
[5:52] <Wes-_> I noticed he was using what appears to be synchronous require
[5:52] <Wes-_> which is not bad, but breaks ideology (barely)
[5:52] <kriskowal> yeah.
[5:52] <Wes-_> only the first time a module is needed
[5:52] <Wes-_> after that, it's just a memo lookup
[5:53] <kriskowal> well, generally require only happens when the application is set up
[5:53] <kriskowal> node definitely needs require.async
[5:53] <Wes-_> true, I can't stand peppering my code with require statements
[5:53] <Wes-_> yeah. I was thinking, too, that you could probably fake require.async in a shell-script-like environment without harm
[5:54] <Wes-_> just execute synchronously and fullfill the promise, no event loop needed
[5:54] <Wes-_> might help to portabilize some code
[5:54] <kriskowal> to get the real advantage of require.async tho, there need to be apis for promise unions and intersections
[5:54] <Wes-_> I wish I had time to spend more time with async code
[5:54] <Wes-_> The last time I *really* worked on any was in VB4
[5:55] <Wes-_> And that was more swearing than working, frankly
[5:55] <kriskowal> yeah, it's problematic
[5:55] <kriskowal> the mud work i was talking about, with generators, runs on twisted
[5:56] <kriskowal> i might consider moving to node, but only maybe.
[5:56] <Wes-_> that also looks like an interesting piece of kit
[5:56] <Wes-_> the other thing that's interesting to me about async is that one of my upcoming mandates is a "research-grade MTA"
[5:56] <Wes-_> I think a node-like implementation would be really cool
[5:57] <kriskowal> ah, yeah. you're in the mail biz
[5:57] <Wes-_> I have some ideas I've been wanting to implement for years
[5:57] <kriskowal> yeah?me too
[5:57] <Wes-_> I have an RFC-2821bis parse written in lex and yacc that generates events
[5:57] <kriskowal> how are we doing on binary?
[5:57] <kriskowal> i have read yours and hannes's comments.
[5:58] <Wes-_> the plan was to kick off JS events right from the parser, and let the parser be all synchronousl.... rethinking that now
[5:58] <Wes-_> kriskowal: Not bad. With a few exceptions, I would be willing to implement it as-is
[5:58] <kriskowal> i will probably write binary/e around some of the challenged assertions
[5:59] <kriskowal> i think that binary/d avoids a lot of issues that will complicated binary/e, but we'll have to see.
[5:59] <Wes-_> I also invited Vlad Vlu???cek to have a look Binary/D, don't know if he will have time
[5:59] <Wes-_> he is implementing WebGL arrays for moz
[5:59] <kriskowal> ah, yeah.
[5:59] <kriskowal> i read the code examples.
[6:00] <kriskowal> it looks like most of it concerns the ability to abstract type-congruous arrays on top of a byte buffer
[6:00] <kriskowal> as a high performance view of the underlying storage
[6:00] <Wes-_> yeah. they are also implementing it right in the interpreter with JIT hooks
[6:01] <kriskowal> [[Get]] and [[Put]] are problematic.
[6:01] <Wes-_> I wish there was a way to use that for commonjs binary without messing with its prototype
[6:01] <Wes-_> [[Get]] and [[Put]] are not as problematic as == and ===
[6:02] <Wes-_> especially if these wind up being objects, like boxed String and any Array
[6:02] <kriskowal> let's use the ecma terminology: wrapped
[6:02] <Wes-_> as of JS1.4, == is not for objects, you are supposed to use .equals
[6:02] <Wes-_> damn, you guys just got me on to boxed, lol
[6:02] <Wes-_> I do like wrapped better
[6:02] <kriskowal> i started using "boxed" because it's similar to the concept in java.
[6:02] <Wes-_> OIC. I've never had to work in Java, not sure how that happened
[6:03] <Wes-_> wasn't around when I went to school, that probably helped
[6:03] <kriskowal> if you need to pass an integer as an Object ref in Java, you have to put it in a "boxed" type new Integer(10)
[6:03] <kriskowal> it loses its native int interface, but you can pass it and return it to functions that expect objects and can't take primitives, like collection types.
[6:03] <Wes-_> And that's an object of class Integer with valueOf 10, and valueOf happens with coercion?
[6:03] <kriskowal> c# took it up a notch and added the idea of automatic boxing and unboxing
[6:03] <Wes-_> or does java not coerce?
[6:04] <kriskowal> java does not coerce
[6:04] <kriskowal> but, there is a method that gets the primitive back
[6:04] <kriskowal> anyhow, in javascript they're called "wrapped" i guess
[6:05] <kriskowal> it's the same idea, but naturally there are particulars.
[6:05] <kriskowal> the upshot is that == does work with wrapped or boxed objects. in java you have to use .equals
[6:05] <Wes-_> == is another interesting ball of wax
[6:05] <kriskowal> there is no analog for that in javascript yet
[6:06] <Wes-_> crock's recommendation to almost always use === is not bad
[6:06] <kriskowal> although there probably should have been.
[6:06] <kriskowal> yeah, but you can't do deep comparison
[6:06] <kriskowal> there is no [].equals([])
[6:06] <Wes-_> true
[6:06] <kriskowal> but you *can* do "a" == "a"
[6:06] <Wes-_> I went a little cheaty with the FFI types and alow pointer objects to be == comparable
[6:07] <kriskowal> we will not have such like with an object-like byte-string.
[6:07] <kriskowal> binary/e would have to establish a precedent for ".eq" or ".equals"
[6:07] <Wes-_> you can't have it without hacking the interpreter itself, though, unfortunately
[6:07] <kriskowal> or binary/d has to postpone that inevitability by specing augmentation to the interpreter
[6:08] <Wes-_> .equals fits with object pattern, probably is what tc39 would take
[6:08] <Wes-_> kriskowal: but then you're stuck with binary/b until 2012
[6:08] <kriskowal> i'm not so sure about that. tc39 has the luxury of modifying the language
[6:08] <kriskowal> that's hyperbole, but i understand the sentiment
[6:08] <Wes-_> yeah
[6:08] <Wes-_> I think we need an improvement on Binary/B soon
[6:08] <kriskowal> tc39 is fully equipped to make major changes to the engine. it would in fact be odd for them not to.
[6:09] <Wes-_> did you follow es-4 at all?
[6:09] <kriskowal> i got disheartened by es-4's direction early on
[6:09] <kriskowal> i was one of the crock-hobbits
[6:09] <Wes-_> they still might not ratify es-5 as drafted because of IBM's insistence on IEEE-748r for god's ake
[6:10] <Wes-_> I wasn't really happy with es4 either, TBH
[6:10] <kriskowal> oh, no. it got ratified yesterday
[6:10] <Wes-_> I like small languages
[6:10] <Wes-_> they are easier to master
[6:10] <Wes-_> really?!?!?!
[6:10] <Wes-_> THAT I didn't know!
[6:10] <kriskowal> es5 is ratified and they also voted to fast track it for ISO
[6:10] <Wes-_> Oh wait, it's decemeber already
[6:10] <Wes-_> where does the time go??
[6:10] * Wes-_ dances for joy
[6:10] <Wes-_> best news I've heard all week!
[6:11] <kriskowal> ibm and intel voted nay, but it wasn't enough to tip the 2/3 majority
[6:11] <Wes-_> I'm going to need to curl up with a copy of the spec now instead of picking at it
[6:11] <Wes-_> kriskowal: what? they changed the rules?
[6:11] <kriskowal> it's an easier read
[6:11] <Wes-_> tc39 used to be acclamation0 only
[6:11] <kriskowal> tc39 is, yes.
[6:11] <kriskowal> but the ecma general assembly is not.
[6:11] <Wes-_> AH
[6:11] <Wes-_> Now I understand
[6:12] <Wes-_> So the IBM rep on TC39, did he vote to send the draft to the ECMA committee?
[6:13] <Wes-_> ES-5 coming out might make noise in the boardroom, too
[6:13] <Wes-_> that would be nice
[6:13] <Wes-_> I am getting sick and tired of the rolling-eye experience
[6:13] <kriskowal> sam ruby. i presume he was swayed.
[6:14] <Wes-_> Yeah, he was (aug 08?) very adamant about IEEE-748r at one point
[6:14] <Wes-_> BTW, do you typeof(/hello/) in ES-5?
[6:14] <Wes-_> (do you know)
[6:14] <kriskowal> i do not think typeof has changed.
[6:14] <kriskowal> but i do not know.
[6:14] <Wes-_> was wondeirng because IIRC it ws spec'd as function in ES3 (callable regexps)
[6:15] <Wes-_> but the implementos went object for some wierd reason
[6:16] <Wes-_> https://mail.mozilla.org/pipermail/es5-discuss/2009-August/003057.html fwiw
[6:18] <kriskowal> on a side note, redrafts of the binary proposal take a couple days of hard work.
[6:20] <kriskowal> and doing a full proposal (not just an idea list) is really the only way to reveal problems with an approach. i'm not going to have time to do another one this week, but someone should volunteer.
[6:22] <Wes-_> kriskowal: I'm not surprised they take that long -- wish I was the volunteer (am not able to unfortunately)
[6:22] <Wes-_> Not surprised because I burned about a half day between those two long emails i wrote and the time I spent reading
[6:22] <Wes-_> well, and thinking
[6:23] <kriskowal> alright. time to bike home. i'm going to finish multi-catalog support this weekend or die trying
[13:56] <Dantman> Ugh, webstats programs make me unhappy
[14:14] <Dantman> T_T Mulling ideas on how to write a new system makes me unhappy to
[14:15] <Dantman> T_T Especially the fact I'd have to use PHP if I wanted wide use of it
[15:44] <Wes-_> Dantman: can you use google analytics?
[15:44] <Dantman> nope, not in this instance
[15:45] <Dantman> I'm trying to do something using server logs... Other than various stats, I want to know how much bandwidth clients are eating up.
[15:45] <Dantman> Anything that doesn't use webserver logs can't get the size, and can't track scripts and other things
[15:46] <Wes-_> Dantman: tried awstats?
[15:46] <Dantman> Ya, that's what I was using...
[15:46] <Wes-_> ah, lol
[15:47] <Dantman> The way it's structured is annoying
[15:47] <Wes-_> you know wyou can change the log file format in apache, right?
[15:47] <Dantman> Ya
[15:48] <Wes-_> I have been known to install a second logging system just to make log file analisys less painful... but webserver logs tend to be pretty good anyhow
[15:48] <Dantman> My annoyance is I can't simply tell it "These domains are for this vhost, etc..." and have it separate out a logfile with all clients combined
[15:49] <Wes-_> are you sure you can't do that? logging directive in the vhost container?
[15:49] <Wes-_> we log per vhost all the time IIRC
[15:50] <Dantman> Domains need to be predefined.
[15:51] <Wes-_> So you don't have vhost containers in your conf?
[15:51] <Dantman> No I do, I was just wanting to trim out nonessential stuff
[15:52] <Wes-_> Oh.. 'cause that's what we do - CustomLog and ErrorLog directive per vhost
[15:52] <Wes-_> piped through rotatelogs, natch
[15:53] <Dantman> Also, something that could handle being the program apache pipes to would be interesting...
[15:54] <Wes-_> just don't screw it up, or you'll take a massive perf hit
[15:55] <Dantman> Something nicely broken up into 3 components to.
[15:58] <Dantman> Nowait, 4
[15:58] <Dantman> Datamining (extracting data from logs, with optional extra js like awstats has, or one of a various set of php scripts or whatnot dynamically doing it; flexible choice of what fits your setup best)
[15:58] <Dantman> Stat generation (taking that database of data, and converting it into the actual statistics)
[15:59] <Wes-_> I just take the data, shove it into a database and run queries against it
[15:59] <Wes-_> and I'll often graph it as well
[15:59] <Wes-_> graphs help to spot operational problems
[15:59] <Dantman> Stat api (Something that takes the data, and provides it as a JSON api)
[16:00] <Dantman> And finally, a pure client side js based ui that connects to that api and does the graphing and display of stats and whatnot
[16:00] <Dantman> If you wanted another view you could just use a different ui to connect to the api
[16:00] <Wes-_> probably best off requesting stats with database-end collation
[16:01] <Wes-_> so SQL in and JSON out or something
[16:01] <Wes-_> and the display could be canvas or svg on the client
[16:02] <Wes-_> http://www.rgraph.net/
[16:11] <MisterN> Wes-_: i recently found this: http://raphaeljs.com/
[16:11] <MisterN> dunno if it is good, but it seems to work on MSIE
[16:12] <evilstreak> we're using that at work
[16:12] <MisterN> evilstreak: is it good?
[16:13] <evilstreak> seems to be, yeah
[16:15] <MisterN> ah, it generates SVG on real browsers and something else on MSIE
[16:15] <evilstreak> VML
[16:50] <Wes-_> MisterN: wow, that's pretty cool!
[16:58] <MisterN> wtf there are still people using cvs for relatively new projects
[17:02] <Wes-_> CVS works
[17:03] <Wes-_> for VERY small teams it's only drawback is that revisions are by-file, not by-repo
[17:03] <Wes-_> How do you guys suggest writing future-proof CommonJS code that uses e.g. binary/b?
[17:04] <Wes-_> should I maybe require('binary/b') and have gpsee generate soft links between binary/b and binary?
[17:20] <MisterN> Wes-_: hmm? which is going to be the standard?
[17:21] <MisterN> Wes-_: flusspferd has only require('binary') and supports Binary/B from a while ago
[17:22] <Wes-_> Mistern: right, but it looks like a new binary module will emerge sooner or later
[17:22] <MisterN> the Binary/D stuff?
[17:22] <Wes-_> so they question is, how do we arrange things /today/ so that we can write code which keeps working with future versions?
[17:23] <Wes-_> MisterN: Yeah, Kris is talking about an /E as well
[17:23] <MisterN> wtf
[17:23] <MisterN> we should get consensus, not EVEN more Binary/X
[17:23] <Wes-_> Binary/D *is* a little saner than Binary/B
[17:24] <Wes-_> but the way CommonJS is decided on right now is really hurting implementors-that-aren't-narwhal
[17:24] <Wes-_> did noticed that they are proposing a new require?
[17:24] <Wes-_> with built-in package management
[17:24] <Wes-_> I think that's a bad plan, personally
[17:25] <Wes-_> I prefer require("package-manager").require() or similar
[17:25] <MisterN> or pm("package-manager").require()?
[17:25] <Wes-_> what is pm?
[17:25] <MisterN> i think require().require() is confusing
[17:25] <MisterN> pm for PackageManager
[17:26] <MisterN> was just making this up on the spot *shrug*
[17:26] <MisterN> Wes-_: implementing Binary/D looks like _effort_ :/
[17:26] <Wes-_> MisterN: except for bit-types it's not too bad, I think
[17:26] <Wes-_> I think bit-types should be a separate item entirely
[17:26] <MisterN> the bit types are what is the big effort...
[17:27] <Wes-_> I also think ByteArray and ByteString should be object constructors
[17:27] <MisterN> and yeah, bit stuff should be separate
[17:27] <Wes-_> MisterN: Yes
[17:27] <Wes-_> MisterN: Might not be a bad idea to take a read through and comment, I am the only commentor thus far
[17:27] <MisterN> Wes-_: making crazy c++ stuff is more fun for me :D
[17:27] <MisterN> but i'll try and take a look
[17:28] <Wes-_> MisterN: *lol*
[17:28] <Wes-_> MisterN: Have you got // flusspferd: args working yet?
[17:33] <MisterN> Wes-_: no, ashb said he would do that
[17:34] <MisterN> Wes-_: have you noticed our nasty spidermonkey crash problem?
[17:34] <Wes-_> we need to get that done (I didn't either, but I have started using it anyhow)
[17:34] <Wes-_> MisterN: Saw something about it in bug report, but thought you had a handle on it?
[17:34] <Wes-_> also we both need to start installing with a commonjs link
[17:34] <Wes-_> so that /usr/bin/env commonjs works
[17:35] <MisterN> Wes-_: no we haven't solved it yet. i have written a test case so it will always be tested in "make test"
[17:35] <MisterN> hmm and then in debian/ubuntu/foobar we could use something like update-alternatives to select the commonjs env
[17:36] <Wes-_> MisterN: mac ports has something like for python selection too
[17:38] <Wes-_> MisterN: link me to the bug?
[17:38] <MisterN> Wes-_: sure. http://redmine.flusspferd.org/issues/show/159
[17:38] <MisterN> i'll add the output of the testcase, too
[17:38] <MisterN> (to the bug)
[17:39] <Wes-_> what does execute() do?
[17:39] <MisterN> execute executes a js file
[17:40] <MisterN> Wes-_: this is the error i get with a very recent m-c build: Assertion failure: obj->dslots, at ../jsops.cpp:2860
[17:40] <Wes-_> JS_CompileUCScript, JS_ExecuteUCScript?
[17:40] <MisterN> i think it used to be JS_ExecuteFileHandle
[17:41] <MisterN> but maybe ashb has changed that. wait a moment, i need to look up
[17:41] <Wes-_> Are you explicitly rooting the intermediary script object?
[17:41] <MisterN> hmm let me check!
[17:42] <MisterN> JSScript *script = JS_CompileUCScript <- should this object be rooted?
[17:43] <MisterN> can JSScript* even BE rooted?
[17:44] <Wes-_> yes!!!
[17:44] <Wes-_> you need obj = JS_NewScriptOBject(script)
[17:44] <Wes-_> JS_AddRoot(obj)
[17:44] <Wes-_> well, except, you know, with cx, and good spelling
[17:45] <MisterN> Wes-_: why do we need that shit?
[17:45] <MisterN> Wes-_: and do we need to KEEP the obj?
[17:45] <Wes-_> if you fail to root it, the garbage collector can free your functions during execute
[17:45] <MisterN> after the script has run?
[17:45] <Wes-_> MisterN: no, after it's run it is rooted by the global object
[17:46] <MisterN> spidermonkey!!!
[17:50] <MisterN> Wes-_: the docs say that if i don't fail to do JS_DestroyScript, there's no problem doing it without JS_NewScriptObject. is that wrong?
[17:51] <Wes-_> MisterN: It is definitely wrong when GC Zeal is. 100% confident.
[17:51] <Wes-_> And of course, if executing triggers a GC, you will have the same effect
[17:51] <MisterN> Wes-_: that sounds like a serious bug in spidermonkey?
[17:51] <Wes-_> I personally witnessed the collector collecting global functions in this case
[17:51] <Wes-_> It's in bugzilla, IIRC I reported it two years ago
[17:52] <Wes-_> but it's not a serious bug
[17:52] <Wes-_> that's why JS_NewScriptObject() exists, so you can root the script
[17:52] <MisterN> Wes-_: if i do JS_NewScriptObject, then i can omit the JS_DestroyScript?
[17:54] <Wes-_> MisterN: No
[17:55] <Wes-_> mistern: no, wait
[17:55] <Wes-_> sec
[17:55] <MisterN> k i'll be away very briefly
[17:56] <Wes-_> MisterN: I never call JS_DestroyScript(), but I might be counting on JS_DestroyRuntime() to clean up
[17:57] <Wes-_> MisterN: Yeah - my suggestion - do not call JS_DestroyScript, do use JS_NewScriptObject, and root the resultant object for the time your script runs
[17:57] <Wes-_> for the first time, if it leaves functions attached to global, that's okay
[17:58] <MisterN> Wes-_: and after the script runs, the functions will be available?
[17:58] <Wes-_> MisterN: Yes, they will now be rooted by global
[17:58] <MisterN> ok, then i'll eat now
[19:01] <MisterN> Wes-_: hmm it doesn't really seem to help.
[21:11] <Wes-> MisterN: Bummer - wasn't a GC hazard then. That change should stay in there, though, or you can have problems, especially with gc zeal
[21:11] <MisterN> Wes-: hmmm
[21:12] <Wes-> you might want to double-check with jorendorff, but I'd sure recommend it
[21:12] <Wes-> not like an extra temporary root is going to hurt you anyhow
[21:19] <MisterN> Wes-: i suspect it's somewhere in our module system
[21:19] <Wes-> mistern: argh
[21:19] <MisterN> Wes-: the problem only happens when the callback is in a module
[21:19] <Wes-> that's really odd
[21:20] <Wes-> do you have another way of loading JS code?
[21:23] <MisterN> hmm
[21:23] <MisterN> well i think we do, but it's not used right now
[21:23] <Wes-> also, it might not hurt to go back to, say, tracemonkey from 6 months ago and see if it still breaks
[21:25] <MisterN> Wes-: i'm not sure if i want this to be a bug in flusspferd or a bug in spidermonkey
[21:25] <MisterN> Wes-: i'm using mozilla-central btw
[21:26] <MisterN> from yesterday
[21:26] <Wes-> yeah, the trick is to isolate the source of the error
[21:26] <Wes-> because IIRC it's just pointer-spew, right?
[21:26] <MisterN> well the backtrace does tell that it's somehow related to the callback :D
[21:27] <Wes-> yeah, but how/why :)
[21:27] <Wes-> funny question, does it work okay if you disable the assertion?
[21:30] <MisterN> i'm too tired right now. but i'll write down to remember to do that
[21:31] <Wes-> easiest way is to build w/o --enable-debug
[21:32] <MisterN> but manually enable --enable-gczeal?
[21:32] <Wes-> does your crash happen only with gczeal?
[21:34] <MisterN> not tested, i always used it so far
[21:34] <Wes-> should probably test
[21:34] <Wes-> crash w/ gczeal means it's probably not GC related, and vice-versa
[21:34] <MisterN> crash w/o you mean?
[21:34] <Wes-> yeah
[21:36] <MisterN> ok, i wrote it all down.
[21:37] <Wes-> if you can somehow easily get a pure jsapi test case I can help debug on monday too
[21:38] <Wes-> probably not possible though
[21:53] <MisterN> Wes-: that would be pretty hard
[21:54] <MisterN> i once tried it when we had some other problem... i wasn't able to make a minimal testcase
[21:55] <MisterN> that's the downside of having a lot of abstraction
[21:56] <MisterN> i also want ashb to look at it, after all he wrote the module system in its current form
[22:02] <Wes-> mistern: are you able to revert to an older version of the module system?
[22:03] <MisterN> Wes-: no, the older version was FULL of gc leaks
[22:03] <MisterN> and the even older version is completely incompatible now

 

 

Logs by date :