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

2009-12-01:

[0:27] <ashb> kriskowal: yeah you probably did write that at my urging >_>
[0:31] <ashb> kriskowal: so i still feel a little bit like the multi-loader stuff is baking in narhwall's behaviour into spec
[0:32] <kriskowal> i don't follow the structure of that sentence
[0:33] <ashb> 2.2
[0:33] <ashb> in http://wiki.commonjs.org/wiki/Modules/Loaders/B
[0:33] <ashb> i feel slightly uneasy about how its specified.
[0:35] <ashb> (not the intent, i'm happy with that, just something about the API)
[0:35] <kriskowal> what, the words?
[0:35] <kriskowal> names of the functions, not the behavior?
[0:35] <ashb> i'm not quite sure at the moment.
[0:35] <ashb> not helpful i know
[0:35] <kriskowal> the intent is really all i care about.
[0:35] <ashb> the API doens't *quite* feel structured right
[0:36] <kriskowal> like a million souls cried out and were suddenly silenced, no doubt.
[0:36] <ashb> the intent is just some way of a loader saying 'yes i can laod this' or 'no i can't
[0:36] <ashb> , right?
[0:37] <kriskowal> oh, whoa, i was reading the wrong section
[0:38] <kriskowal> would you say 2.2-2 is what's giving you more nausea or 2.2-1
[0:39] <kriskowal> is it the flexibility of canLoad and loader pairing?
[0:39] <ashb> -2 i think
[0:39] <ashb> the flexability i am fine with. i'm really not sure
[0:40] <ashb> it might just be something as simple as i can't get a clear view of how the API is used by loaders
[0:40] <kriskowal> okay.
[0:40] <kriskowal> that i think i can help with?
[0:40] <kriskowal> i don't have an exact implementation of this specification, but we do have a multi-loader that just does the [extension, loader] behavior.
[0:40] <ashb> i.e. i've written (or stollen inimos) PEG parser and I want to be able to do require('my-grammar') and have it load my-grammar.peg
[0:41] <kriskowal> it's not a far cry from [canLoad, loader] or the loader, loader.canLoad variant we're going for
[0:41] <ashb> sure
[0:41] <ashb> i think most of it might just be the wording
[0:41] <ashb> you've got an implementation so it makes sense to you
[0:41] <kriskowal> http://github.com/kriskowal/narwhal/blob/refactor/lib/loader/multi.js
[0:41] <ashb> (as a whole, not just that specific point 2.2-2)
[0:42] <kriskowal> so, you can see the path, .isFile, and .canLoad traversal in the .find method of the multi-loader.
[0:43] <ashb> and how do new loaders register themselves?
[0:43] <ashb> and how global is that?
[0:43] <ashb> shouldn't affect outside the sandbox i guess
[0:43] <kriskowal> by supplanting or altering require.loader.loaders, much like we can currently alter require.paths
[0:43] <ashb> k
[0:44] <kriskowal> and it's my intent to automate that process using the package system in narwhal
[0:44] <kriskowal> by prioritizing loaders automatically based on the package dependency graph
[0:44] <ashb> k
[0:44] <kriskowal> ?much like how we automate the rewrite of require.paths when we load packages
[0:45] <ashb> tbh i'm not sure we really need require.paths going forward if we have a package proposal
[0:45] <ashb> s/if/once/
[0:48] <ashb> i really need to summon some motivation and finish off the damn DOM tests so i can move onto something else
[0:50] <kriskowal> i'll prolly eventually be able to get narwhal's package system working with helmang *because* it provides require.paths.
[0:51] <ashb> hmmmm true
[0:51] <kriskowal> architecturally, the package system is a layer on top. you could make them work as a cohesive unit, but having them separated like that makes things a bit more flexible.
[0:51] <kriskowal> i might be able to get narwhal running on flusspferd too
[0:52] <kriskowal> hours in the day though.
[0:52] <kriskowal> only so many of them.
[0:52] <ashb> all i really want is a way of specifinyg multiple package dirs
[0:52] <ashb> yeah.
[0:52] <kriskowal> what, package roots? directories in which there are packages?
[0:52] <ashb> yeah. seas as tusk calls them i think
[0:52] <kriskowal> aye
[0:53] <kriskowal> in narwhal, require("system").prefixes is the list of package roots. the first one is the "sea". it gets configured in the bootstrap process.
[0:53] <kriskowal> so, the engine has some control over what prefixes get installed.
[0:54] <ashb> naughty naughty: thats against the spec :)
[0:54] <kriskowal> what, the additional name in the system module?
[0:54] <ashb> 'Any names not mentioned here or amended into this specification later should begin with "x"'
[0:54] <ashb> yeah
[0:54] <kriskowal> yeah
[0:54] <kriskowal> still working on a new draft of binary/d, btw.
[0:54] <ashb> k
[0:55] <kriskowal> it's hard to keep four dimensions consistent
[0:55] <kriskowal> but i wrote some automation, so this next draft will be pretty cool.
[0:55] <ashb> {Bit,Byte}{String,Array} ?
[0:55] <kriskowal> pardon, two dimensions, yeah. four objects.
[0:56] <kriskowal> i hope the base64 example was convincing.
[0:56] <ashb> for the Bit or for Content?
[0:56] <kriskowal> bits
[0:56] <kriskowal> discovered i needed to specify .valueOf through that example.
[0:57] <ashb> Bits i'm fine with.
[0:57] <ashb> Content is the one i'm not quite sure hte need for
[0:57] * kriskowal shrugs.
[0:57] <kriskowal> it's not onerous.
[0:57] <ashb> oh and the whole [0]/new thing. still need to write down my thoughts and some samples on that
[0:58] <kriskowal> the new ByteString() thing?
[0:58] <ashb> yeah
[0:58] <kriskowal> what's [0] about?
[0:58] <ashb> byteString[x]
[0:58] <ashb> what it should return
[0:59] <ashb> they are related issues in my mind
[1:00] <kriskowal> the only common factor between those issues is whether ByteStrings should be objects or like strings
[1:00] <ashb> yeah
[1:01] <ashb> which is part of my reasoning.
[1:01] <ashb> the other being i honestly can't htink of a case when you'd want bs[0] to return another bytestring
[1:01] <kriskowal> which is really a question of whether it should be possible to grandfather String-based algorithms into ByteString algorithms in certain cases.
[1:01] <kriskowal> which is the central thesis of the proposal. the proposal is designed around the answer, "yes".
[1:02] <ashb> but even given that, when is a unary bytestring useful?
[1:04] <ashb> thats what i've been trying to think of, and i couldn
[1:04] <ashb> t
[1:04] <ashb> but i wasn't really thinking about using it in string alrgorithms.
[1:04] <ashb> will think again for that case
[1:09] <kriskowal> consider that there are a bunch of existing algorithms that look like http://github.com/280north/narwhal/blob/master/lib/base64.js written for the browser, that should be nearly trivial to port to use bytes instead of strings.
[1:11] <ashb> nothing in there uses [] does it tho?
[1:11] <kriskowal> that particular one doesn't throw up any warning signs, but it's my *theory* that making byte-string and string interoperable will ease that process. the question then is only "how" interoperable, which i think is unknowable.
[1:11] <ashb> right now [0] is esentially a usless op right now
[1:12] <kriskowal> are you *sure*?
[1:12] <ashb> too many right nows. i think thats a sign it might be time to sleep soon
[1:12] <kriskowal> always
[1:12] <kriskowal> night
[1:12] <ashb> when you know its a bytestring, yes. if you aren't sure if its a string or a bytestring, i think so but i'm not sure
[1:12] <ashb> nn
[6:07] <kriskowal> some info on erlang's binary patterns http://www.erlang.org/euc/00/bit_syntax.html
[6:08] <kriskowal> seems like functionality like that could reside as an api layer on top of binary/d
[6:08] <kriskowal> much like pack, unpack, calcsize could be implemented on top of the byte types
[6:17] <kriskowal> and higher level stream apis with methods like .readUInt32BE
[9:25] <kriskowal> new draft of http://wiki.commonjs.org/wiki/Binary/D
[10:34] <kriskowal> ashb: clarified your point on FS/0 http://wiki.commonjs.org/index.php?title=Filesystem/A/0&curid=316&diff=1810&oldid=1769
[10:35] <ashb> kriskowal: cool. glad you went that way
[10:35] <ashb> you're up late/early
[10:35] <kriskowal> i'm restless
[10:35] <kriskowal> finished the binary/d draft and read a chapter of a book. anxious for feedback and waiting for an article i wrote to get published
[10:38] <ashb> will read through /d when i'm more awake
[10:43] <ashb> kriskowal: hmmm .supports
[10:44] <ashb> is that meant to just be the builtin alphabets (baseX, etc)
[10:44] <ashb> or things from the encodings module too?
[10:44] <kriskowal> it is meant only to be stuff from encodings
[10:44] <kriskowal> not radix encoding
[10:44] <kriskowal> charset and radix are separate domains.
[10:45] <ashb> in which case that can't be implmeneted with iconv
[10:45] <kriskowal> surely, it must be possible, at the very least falling back to trying and catching
[10:45] <ashb> hmmm perhaps. you've have to have 2 charsets tho
[10:46] <ashb> iconv_open(x, "utf-8") i guess;
[10:46] <kriskowal> yeah, i don't know. it just seemed like something that ought to be there.
[10:46] <ashb> probably more belongs on the encodings module, no?
[10:47] <kriskowal> ultimately, sure.
[10:48] <ashb> hmmm. === support is going to be a memory nightmare
[10:48] <kriskowal> for strings?
[10:48] <ashb> hmmm maybe not actually
[10:48] <kriskowal> in a way that it isn't already a nightmare for strings?
[10:48] <ashb> it might be a bit of an impl challange
[10:48] <kriskowal> (i don't know)
[10:49] <ashb> === for byte string means we need to keep a list of all currently active ByteStrings
[10:49] <ashb> and if we are asked to create a new one we need to return that old object instead
[10:49] <ashb> is === overridable easily in rhino?
[10:50] <kriskowal> let's not worry too much about rhino
[10:50] <ashb> okay. cos its flat out not overridable for spidermonkey
[10:50] <ashb> they only way to get two values to be === is to be the same object
[10:51] <kriskowal> you might consider using a hashing set. it's my guess that's how strings work
[10:51] <ashb> yeah, i've probably already got one I can use form the DOM module
[10:51] <kriskowal> and i think it will be okay in the short term for rhino implementations to fall short of the specification. the binary data api is intentionally very low level.
[10:52] <ashb> valueAt should maybe throw a range error if the value is too large?
[10:52] <kriskowal> as a product of a discussion long ago?that there would be little point in supporting it in the browser
[10:52] <ashb> RangeError? TypeError?
[10:53] <ashb> some other random error
[10:53] <kriskowal> RangeError was what i wrote originally.
[10:53] <kriskowal> but i wasn't consistent. in some places i coerced, in others i threw.
[10:53] <ashb> ah
[10:54] <ashb> byteStringAt: what API does this mirror?
[10:54] <kriskowal> i only care that the behavior be consistent. at the moment i'm assuming coercion is more useful.
[10:54] <kriskowal> and more javascripty
[10:55] <kriskowal> read the section on genericity in the errata
[10:55] <kriskowal> bottom
[10:57] <kriskowal> the premise is that [[Get]]'s return type is type dependent, but valueAt and byteStringAt are consistent across types.
[10:59] <ashb> ah k.
[10:59] <ashb> i still remain dubious of the usefullnes of a unary bStr
[11:00] <kriskowal> and i do not think that i can convince you that it is anything short of dubious, but it might be useful to frame the debate in terms of regret minimzation instead of risk optimization
[11:01] <ashb> yeah
[11:01] <ashb> hmmm bStr.copy
[11:01] <ashb> returns a BSTR?
[11:01] <kriskowal> last sentence.
[11:01] <kriskowal> returns this.
[11:02] <ashb> oh copy into. there we go
[11:02] <kriskowal> following the javascripty convention of returning this when there's nothing else meaningful to return, so that it can be chained.
[11:02] <ashb> x.copy(y) i was expecting to copy from y into x for somereason. no i say it outloud it seems a bit silly
[11:03] <kriskowal> yeah, that parallels the stream and file apis
[11:04] <kriskowal> fs.copy(source, target). source.copy(target). input.copy(output).
[11:04] <ashb> yeah
[11:04] <ashb> makes sesne
[11:04] <ashb> just my internal view was backwards for some reason
[11:04] <ashb> concat should accept (1,2,3,4) as well as an array perhaps?
[11:04] <kriskowal> i have that problem with world maps, but only in my home town.
[11:05] <ashb> so do i actually. i live north of the town
[11:05] <ashb> but i always think of going into town as heading north
[11:06] <ashb> hmmm i guess its not that oneruse to wrap it in an array. nm on that one
[11:06] <kriskowal> i could deal with concat promoting numbers to unary arrays of numbers
[11:06] <kriskowal> there's precedent elsewhere
[11:06] <ashb> ctors do that dont they?
[11:06] <kriskowal> no
[11:07] <kriskowal> Array(length:Number)
[11:07] <ashb> oh: -ve values on range?
[11:07] <kriskowal> but indexOf does promote numbers
[11:07] <ashb> .range(-4, -2)
[11:08] <kriskowal> ah, good catch.
[11:08] <ashb> http://flusspferd.org/docs/js/commonjs%20core/binary/binary.html some verbage there if you need it
[11:09] <ashb> mmm space in urls are annoying
[11:09] <ashb> will have to fix that
[11:11] <kriskowal> alright, done for the night.
[11:12] <ashb> k
[11:12] <kriskowal> thanks for the time
[14:22] <MisterN> so commonjs is on the hompeage of arstechnica hmm
[15:06] <ashb> 'Open BlueDragon, is the worlds favourite open source GPL J2EE CFML runtime engine' modest isn't he :)
[15:06] <ashb> perhaps its the only GPL J2EE CFML engine.
[15:06] <ashb> what *is* CFMLK?
[15:06] <ashb> s/K//
[15:07] <ashb> oh wow coldfusion
[15:12] <Nathan__> i noticed that too ashb
[15:13] <nrstott> I thought coldfusion was dead
[17:16] <jeromatron> wow - lots of press on the jsconf.eu + commonJS today :) nice to see so much going on to get some common apis out there, esp to break the web/javascript out of the sandbox :)
[17:22] <Wes-> jeromatron: links?
[17:22] <Wes-> (saw Kris Kowal's article on arstechnica already)
[17:23] <jeromatron> Wes-: mostly seeing references to that, but then Dion A. tweeted about that article and slashdot linked to that article... so kind of "see also" press I suppose.
[17:24] <Wes-> OIC
[17:24] * Wes- didn't read /. yet today
[17:34] <emilis_info> HN top news :)
[18:46] <pmuellr> Anyone on the webkit-dev mailing list? chit-chat going on regarding the "GlobalScript" proposal, which is kinda like modules - provides shareable JavaScript contexts in a browser anyway. Thread here: https://lists.webkit.org/pipermail/webkit-dev/2009-November/010603.html
[18:46] <pmuellr> The GlobalScript (guess it's named SharedScript) proposal is available here: http://docs.google.com/View?id=dxv3cth_2rnj9wffz
[19:58] <Wes-> pmuellr: Doesn't that solve the same problem as window.opener? (and did they kill window.opener? I don't really do client-side work since the 4-days)
[20:00] <Wes-> oh, saw the end of that article, never mind
[20:00] <Wes-> good points I'd forgotten
[20:00] <inimino> Wes-: window.opener still exists
[20:00] <Wes-> inimino: I used to use that for almost exactly one of the use-cases in that article (email compose reaching back to main app to grab address book data without server hit)
[20:03] <inimino> you could still do it that way too, but window.open isn't as popular as it once was
[20:05] <Wes-> yeah.. that's a good point, too. I keep forgetting that web devs nowadays have to deal with popup blockers
[20:05] <Wes-> (at least they are much better/more intelligent than the last breed)
[20:12] <kriskowal> pmuellr thanks for the links.
[20:14] <pmuellr> kriskowal: btw, I posted something a little bit ago on the list, mentioning CommonJS - https://lists.webkit.org/pipermail/webkit-dev/2009-December/010757.html
[20:14] <Wes-> kriskowal: thanks for the article
[20:15] <kriskowal> Wes- thanks
[20:15] <Wes-> thinking on Binary/D ATM
[20:16] <Wes-> Good work there too
[20:22] <ashb> fleh. the DOM api is a bit inconsistent at times
[20:23] <ashb> removeAttributeNode, getAttributeNode, getAttributeNodeNS, but no removeAttrNodeNS
[20:55] <hannesw> I guess array index properties in binary/* should be enumerable
[20:55] <hannesw> spec doesn't say so currently, unless I missed it
[20:56] <hannesw> in other words: a for-in loop over a binary object should work as expected
[21:02] <MisterN> kriskowal: ruediger was quite sad about not being named :)
[21:03] <MisterN> kriskowal: also flusspferd does support Binary/B (maybe not the most recent changes), and of course i think we should have been the first framework to be named :D
[21:04] <MisterN> but thank you for naming us at all.
[21:16] <kriskowal> MisterN ah, sorry about that. you might consider updating the wiki.
[21:17] <MisterN> kriskowal: where?
[21:17] <kriskowal> just which proposals flusspferd has implemented.
[21:17] <MisterN> http://wiki.commonjs.org/wiki/CommonJS#Implementations <- ?
[21:18] <MisterN> ashb: can you please update this? you know more precisely which part of filesystem you have updated and whether our Binary/B support is up-to-date
[21:18] <ashb> fs-base. everything but perms and the iterator obj
[21:18] <ashb> binary/B i dont actually know
[21:24] <MisterN> i think we support most of it
[21:24] <MisterN> but haven't looked recently
[21:26] <MisterN> kriskowal: maybe we should change the implementations list into a table?
[21:27] <kriskowal> MisterN whatever works for you
[21:27] <MisterN> with columns for js engine, supported programming languages (i.e. Java or C++. matters for module writers) and a column for each part of the commonjs
[21:29] <ashb> oh and no 'yes this is compliant' without a unit test?
[21:29] <ashb> with the possible exception of UnitTest proposal itself
[21:29] <ashb> as writing meta unit tests is a PITA
[21:30] <MisterN> ashb: we support the testing stuff, too, no?
[21:30] <ashb> not quite the latest
[21:30] <ashb> very similar, but not exact
[21:30] <Wes-> kriskowal: BTW please don't take long email as sign of negativity, only as sign of really caring!
[21:30] <MisterN> ashb: oh, make a redmine issue for that :)
[21:32] <ashb> done
[21:32] <ashb> 171
[21:32] <Wes-> mistern: a column for API or something would be at least as useful as programming language
[21:32] <ashb> well lanague is part of the API
[21:32] <kriskowal> Wes- no qualms at all about long email. needs to happen more.
[21:32] <Wes-> mistern: i.e. "jsapi" is more useful than "c++" in many contexts
[21:33] <Wes-> kriskowal: I can't believe I actually spent nearly two hours total today thinking about that proposal. It's much tighter than Binary?B
[21:33] <MisterN> Wes-: flusspferd would have "Flusspferd" as API?
[21:33] <Wes-> Mistern: yes
[21:34] <MisterN> Wes-: and GPSEE would have "JSAPI"?
[21:34] <Wes-> MisterN: Probably flusspferd, jsapi -- assuming you can expose cx and global object
[21:34] <ashb> should mention C++ as well otherwise it will be confusing as hell
[21:34] <Wes-> ashb: Yes
[21:34] <MisterN> yeah it must mention c++ for flusspferd
[21:34] <ashb> cx gives you global, and yeah we can get that the JSContext* if you need it
[21:34] <Wes-> ashb: But c++ doesn't mean automatic support for v8
[21:34] <ashb> very true
[21:34] <Wes-> which is why both dev lang and API are useful in a cross-compare chart
[21:34] <MisterN> ?
[21:35] <MisterN> that's a weird way of thinking to me :)
[21:35] <Wes-> mistern: if you have tonnes of c++ v8 code, would you select flusspferd as your common-js embedding?
[21:35] <MisterN> to me, for flusspferd, JSAPI is not the API but the ENGINE
[21:36] <ashb> you could get at hte JSContext* and use JSAPI directly
[21:36] <MisterN> Wes-: sure, after writing a v8 backend for flusspferd
[21:36] <Wes-> mistern: API, engine, I don't really see the difference. Whatever you call it, it's important though
[21:36] <ashb> it might be a bit error prone in some cases, but it should work
[21:36] <MisterN> Wes-: i did propose a column for the engine :P
[21:36] <Wes-> ashb: exactly, so somebody with existing jsapi code could move to flusspferd fairly easily
[21:36] <ashb> yeah
[21:36] <Wes-> mistern: oh, missed that, lol
[21:37] <Wes-> ashb: in fact, flusspferd + gpsee should (IN THEORY) be able to run multiple pieces of legacy jsapi code even if they would otherwise stomp on each other's resources
[21:37] <Wes-> JS_GetRuntimePrivate() being the exceptional resource there
[21:37] <ashb> yeah - the only place the interop will fall down is native modules. they'd be opaqeu to each other
[21:37] <Wes-> (but could be fixed too probably)
[21:38] <Wes-> ashb: Yep - that's where a lot of my motivation comes from
[21:38] <ashb> Wes-: interesting. that could mean we could compile jslibs in. intersting...
[21:38] <Wes-> unfortunately I haven't done much intergration because it seems everything I'm interested in is GPL
[21:38] <ashb> yeah
[21:38] <Wes-> ashb: totally doable
[21:39] <Wes-> I don't think I can distribute jslibs, though, it's GPLv3, right?
[21:39] <Wes-> I suppose I could distribute a Makefile to build it, though
[21:40] <ashb> hmmm bzr send doesn't seem to want to work when the upstream repo is down
[22:00] <MisterN> Wes-: does gpsee have command line parsing?
[22:01] <MisterN> Wes-: i'm asking for the sake of the completeness of http://wiki.commonjs.org/wiki/Command_Line#Prior_Art
[22:02] <ashb> MisterN: you mean a getopt module
[22:02] <MisterN> yeah
[22:02] <MisterN> i'm completely unbiased when i say that flusspferd's getopt module does it right
[22:02] <ashb> apart from the bug
[22:02] <ashb> go fix that :D
[22:03] <MisterN> :P
[22:03] * ashb runs git cvsimport
[22:03] <Wes-> MisterN: Nope, I haven't needed it yet. Was going to use getopt.js from v8 if I did.
[22:03] <MisterN> Wes-: i think you should implement the flusspferd getopt api so we can then declare it the standard :D
[22:04] <Wes-> MisterN: What is it like?
[22:04] <MisterN> Wes-: http://flusspferd.org/docs/js/flusspferd%20core/getopt.html
[22:05] <ashb> look for "getopt Specifications"
[22:05] <ashb> MisterN: the [options] is a bit odd, and stop-early default should prbably be reveresed
[22:06] <Wes-> Exmaples - are those guys that used to play for Toronto?
[22:06] <ashb> \o. go go gadget Ash fingers!
[22:06] <MisterN> ashb: stop-early is NOT the default?!
[22:06] <MisterN> -?!+!?
[22:06] <ashb> dont think so
[22:06] <MisterN> it is not the default, is what is want to say
[22:06] <MisterN> not ask
[22:06] <MisterN> and it should not be the default either
[22:06] <ashb> i think it should be :)
[22:07] <Wes-> does it support "--" stop parsing and give me rest raw?
[22:07] <ashb> yup
[22:07] <Wes-> Is that "_" ?
[22:07] <ashb> yeah _ is anything else
[22:07] <ashb> The returned object has a key for each option found on the command line, and all remaining arguments in an array under the _ key:
[22:07] <MisterN> Wes-: yeah it always supports --
[22:07] <MisterN> Wes-: i tried to be as close to getopt_long as possible
[22:08] <Wes-> _bash and _man are probably not standards-track
[22:08] <Wes-> other than that I think it's a fine API
[22:08] <ashb> yeah the _bash and _man are just what we use for building prt of flusspferd
[22:08] <Wes-> does it support repetition?
[22:09] <Wes-> i.e. /usr/bin/gsr -zz
[22:09] <ashb> yes
[22:09] <ashb> the example shows that too
[22:09] <ashb> or the exmaple rather :)
[22:09] <Wes-> ah yes
[22:09] <Wes-> any reason the example uses '1', '2', '3' rather than 1,2,3?
[22:10] <ashb> `foo -bvv --name=arg 1 2 3`
[22:10] <ashb> is what the example is showing
[22:10] <Wes-> ah yes
[22:10] <ashb> should probably make that a bit clearer
[22:10] <Wes-> I would like to see ,arguments not optional in standards-track proposal
[22:10] <Wes-> an optional trailing optind might be handy though
[22:10] <ashb> hmm?
[22:11] <ashb> oh i see
[22:11] <Wes-> ashb: I don't want it falling back to system.args, that entrains the system spec
[22:11] <ashb> in the getopt call.
[22:11] <Wes-> yeah
[22:11] <Wes-> avoid the whole issue by making it non-optional in the specification
[22:13] <Wes-> BTW is your impl mostly C++ or mostly JS?
[22:13] <MisterN> only c++.
[22:15] <Wes-> bah
[22:15] <Wes-> you people need to start writing more reusable code! :)
[22:15] <MisterN> Wes-: it is reusable as long as you use flusspferd :)
[22:16] <ashb> Wes-: its c++ because we use it for pargins arguemnts for flusspferd itself too
[22:16] <ashb> *parsing
[22:17] <ashb> this new keyboard is really thworing off my otherwise impecable typing
[22:17] <Wes-> ashb: Ah, I used good ol' getopt(3c) for my own parsing
[22:17] <Wes-> might need to think about --long arguments at some point, thogh
[22:17] <ashb> blame MrN - he likes writing C++ :D
[22:18] <Wes-> Hey, did you guys get around to comment-embedded options yet?
[22:18] <Wes-> that's on my horizon sometime soon
[22:18] <ashb> ditto
[22:18] <Wes-> would make it possible, e.g, for evilstreak to write code which ran on both our engines reasonably
[22:19] <Wes-> and I'm thinking we should both offer commonjs links during install
[22:19] <Wes-> that way we can #! /usr/bin/env commonjs
[22:19] <ashb> ah i see.
[22:19] <ashb> yeah that should be possible
[22:20] <Wes-> with that ^^ as long as the commonjs link is the guy's path, he's good to go
[22:21] <Wes-> and we can actually distribute programs which can theoretically run on multiple engines without changing a byte
[22:21] <Wes-> You know, this is actually kind of novel
[22:21] <Wes-> I can't think of another interpreter which had that kind of ability, since /bin/sh
[22:22] <Wes-> perl, python, php, lua, etc, all have a single implementation
[22:22] <ashb> heh
[22:24] <ashb> there's a fork of perl5 actually
[22:26] <MisterN> python has a number of impls too
[22:26] <MisterN> but only cpython is normally used from the shebang, i think
[22:31] <ashb> MisterN: so i tried doing #157 (sqlite3 tests)
[22:31] <MisterN> ashb: was hard?
[22:31] <ashb> ish
[22:32] <ashb> part of the problem is src/plugins/slqite3 is in the search path
[22:32] <ashb> so we can just try and check for "Library not found"
[22:32] <MisterN> huh?
[22:33] <MisterN> can or cannot?
[22:33] <ashb> can't. sorry
[22:33] <ashb> cos of our 'we load .js and .dylib' we end up with "SQLite3 is not defiend" reference error
[22:34] <ashb> and i din't just want ot catch any old error
[22:34] <ashb> oops wrong channel
[22:41] <ashb> mmmm time for everyones favourit task. getting XSLT to produce text;
[23:12] <ashb> ahah - anyone on the es-ciscuss mailing list?
[23:12] <ashb> oh no thats not what i thought it was
[23:20] <JohnnyL> it'd be cool is cjs had a yield operator akin to pythons. Perhaps you can use it to link up to an actor-thread-like process.
[23:20] <ashb> JohnnyL: use a mozilla engine
[23:21] <ashb> it has exactly that
[23:21] <ashb> i.e. use flusspferd :D
[23:22] <ashb> JohnnyL: but thats not something that CJS can add -it needs new syntax in the JS engine
[23:22] <JohnnyL> yeah
[23:23] <JohnnyL> If js supported some kind of multi-* it would take off alot faster than not.
[23:23] <ashb> multi-*?
[23:25] <JohnnyL> ashb multi-core, multi-processor
[23:25] <ashb> ah
[23:27] <deanlandolt> JohnnyL: what can cooperative concurrency do that web workers can't?
[23:28] <JohnnyL> wth is a web worker?
[23:29] <JohnnyL> There are languages today, now... that have no boiler plate code for both concurrent and parallel based multi-*.
[23:29] <deanlandolt> shared nothing concurrency
[23:30] <JohnnyL> having said that, would there be a way to make all objects in js non-mutable?
[23:30] <deanlandolt> JohnnyL: it's just message passing, part of html5
[23:30] <JohnnyL> oh.
[23:30] <JohnnyL> i see
[23:30] <deanlandolt> there's an implementation in narwhal for it that i believe krisz did
[23:31] <JohnnyL> well, for one it takes up quite a bit of boiler plate code.
[23:31] <deanlandolt> no doubt...that's what libraries are for :)
[23:31] <ashb> ah 166
[23:31] <JohnnyL> it's also not cheap.
[23:32] <JohnnyL> why would you need to change variables in js?
[23:32] <deanlandolt> change variables?
[23:32] <JohnnyL> if you use closures this would not make sense.
[23:32] <JohnnyL> :)
[23:32] <JohnnyL> yes.
[23:32] <deanlandolt> you mean immutability?
[23:33] <deanlandolt> so you want js to be erlang?
[23:33] <JohnnyL> You could store and memoize and cache them.
[23:33] <JohnnyL> deanlandolt no more like haskell.
[23:33] <ashb> go write haskell then :)
[23:33] <JohnnyL> it's too complicated.
[23:33] <deanlandolt> haven't played with haskell yet
[23:34] <JohnnyL> though I believe that js is flexible enough to support nonmutable vars.
[23:34] <deanlandolt> JohnnyL: well, that's the beauty of js then...you can probably bend it and shape it into something haskell-like
[23:34] <JohnnyL> deanlandolt yeah i was thinking that too.
[23:34] <JohnnyL> Eloquent JS really shined a light.
[23:34] <JohnnyL> It's a free tut on the web.
[23:34] <deanlandolt> yeah, i've read a good bit of it
[23:34] <ashb> JohnnyL: its not.
[23:35] <ashb> well if oyu use const everywhere it is i guess
[23:35] <ashb> but that requires user support. you can't implicitly make everything const
[23:38] <JohnnyL> Well, if you had server side source you could change it. It doesn't make a heck of alot of side on the client (although I'm sure that will change the more you multitask on the client), but with that said, the impl. would not be that big a deal. like you said const. I don't even know if const works in js. does it?
[23:38] <ashb> oh if you dont mind pre-compiling it sure
[23:38] <ashb> you can do what ever hte hell you like then
[23:38] <ashb> const works in mozilla agains
[23:39] <ashb> and is a ES Harmony proposal i think
[23:41] <JohnnyL> hahaha
[23:41] <JohnnyL> you sound pissed.
[23:42] <JohnnyL> "ashb> you can do what ever hte hell you like then"
[23:42] <ashb> not at this/you
[23:42] <JohnnyL> i know, but it's fnuny.
[23:42] <ashb> just and how shitty the W3C dom tests are
[23:42] <JohnnyL> funny
[23:42] <JohnnyL> ok it's settled.
[23:43] <inimino> JohnnyL: always glad to see someone reading Eloquent JavaScript :-)
[23:43] <JohnnyL> therefore as of 2009.12.01 we shall have immutable variables in javascript leading next to subdividables processesfor multi-core support.
[23:43] <JohnnyL> inimino: :)
[23:43] <JohnnyL> inimino why, are you the author?
[23:44] <JohnnyL> ack, typos
[23:44] <inimino> JohnnyL: no, but I recommend it
[23:44] <inimino> JohnnyL: it's the introduction I'd like to have written if I were going to write one
[23:45] <inimino> I actually was considering writing something like it until I found it
[23:46] <JohnnyL> inimino okay, but whatever you do in the introduction don't say that Christianity has more credence than Darwin's book.
[23:46] <JohnnyL> :)
[23:46] <JohnnyL> lmao
[23:46] <inimino> and it gives people a good perspective on writing JavaScript in a functional style
[23:46] <JohnnyL> inimino agreed. the examples are killer.
[23:47] <JohnnyL> i love the way it uses closures.
[23:47] <inimino> hehe
[23:47] * inimino scratches plans for "JavaScript: A Christian's Guide"
[23:47] <JohnnyL> You can literally program from bottom up as easy as top down.
[23:48] <inimino> yes, closures are introduced without being some big scary thing
[23:48] <JohnnyL> I feel that bottom-up has more reuse than top down albeit it depends on what program/industry you write for.
[23:48] <JohnnyL> Inheritence makes more sense for real world modeling imho.
[23:49] <JohnnyL> Though I'm probably preaching to the converted. :)
[23:49] <inimino> I'm not sure inheritance is even a good fit there :-)
[23:50] <inimino> even in the real world, things don't fall into neat hierarchies
[23:50] <JohnnyL> Well, even subatomic structures have inheritence properties/methods.
[23:51] <JohnnyL> What , in this world, is not a coarising interbeing object of some sort?
[23:51] <inimino> and in any serious large OO project I've seen, the inheritance hierarchy breaks down and you end up with some kind of mixin/friend/aspect sorts of patterns...
[23:51] <inimino> the trouble with real-world modeling is that the model is always so many orders of magnitude simpler than the real-world phenomenon being modeled
[23:51] <ashb> 'The prefix "xml" cannot be bound to any namespace other than its usual namespace; neither can the namespace for "xml" be bound to any prefix other than "xml"' FUCK YOU XML
[23:52] <inimino> unless you're talking about subatomic physics simulations, maybe :-)
[23:52] <inimino> ashb: fun with XSLT?
[23:52] <ashb> inimino: massive of it
[23:53] <inimino> yeah, I don't miss it
[23:56] <inimino> JohnnyL: there's an interesting paper on OO...
[23:56] <ashb> theres just a bug in the provided 1700 line XSLT somewhere
[23:56] <ashb> if oyu want OO, look at smalltack and CLOS
[23:56] <ashb> *talk

 

 

Logs by date :