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

2010-01-20:

[11:01] <ondras> ByteString.join([1,2,3], 0)
[11:01] <ondras> hmm
[11:01] <ondras> shouldn't this be rather ByteArray.join(arr, delimiter) ?
[12:44] <ondras> some binary/b implementor here?
[12:44] <ashb_> yeah
[12:45] <ondras> ashb_: first, ByteString.join? shouldn't that be ByteArray.join ?
[12:45] <ashb> dunno - its an entierly usless method in opractive either way
[12:46] <ashb> i have it but i think the docs are wrong
[12:47] <ashb> since 'ive got it doc'd as a class method
[12:47] <ondras> okay
[12:48] <ondras> ashb: next, .indexOf - what is the meaning of ByteString/ByteArray as a first argument?
[12:48] <ondras> are we searching for a whole substring/subarray, or for any of its elements?
[12:48] <ondras> (as in split)
[12:56] <ondras> ashb: have you written something while in the netsplit?
[12:57] <ashb> our .indexOf only accepts a single byte
[12:57] <ashb> but i'm not sure thats right
[12:57] <ondras> e.g. a Number?
[12:57] <ashb> yeah
[12:58] <ondras> okay
[12:58] <ondras> let's start with that.
[14:53] <lelec> hi all, i've got a question about the Modules specification, is there someone qualified here ?
[14:58] <ondras> just shoot
[15:02] <lelec> Thanks. Well i'm working on an ORM in javascript, that should work both client (using Web Database Api) and server side. And i don't know if it's a good idea to use modules to do it since there is a lot of talk about it. I just wanted to know if narwhal implementation for server and client was working and if there was others solutions.
[15:03] <ondras> it is certainly a good idea to aim for modules compatibility
[15:03] <ondras> (it is really pretty simple)
[15:04] <ondras> unfortunately, I am not familiar with current state of narwhal's client side modules support
[15:04] <ondras> someone else on this channel will know, though
[15:04] <ondras> and server side modules support is complete in narwhal iirc
[15:05] <lelec> ok, thanks
[15:06] <lelec> i will wait
[15:06] <evilstreak> what are client/server modules?
[15:06] <Wes-> I don't know squat about narwhal, either
[15:06] <Wes-> Although, it would be relatively easy to roll a half-decent client-side module system
[15:07] <Wes-> I could have a working prototype in CommonJS in probably 2 days
[15:07] <lelec> oh great
[15:07] <Wes-> or shell if you don't have CommonJS on the server
[15:07] <Wes-> I posted the rough scaffolding for such a system in the CommonJS newsgroup last month
[15:07] <lelec> i though it was a bit difficult because of this post
[15:07] <lelec> http://www.davidflanagan.com/2009/11/commonjs-module.html
[15:08] <lelec> see the response of Kris Kowal
[15:08] <ondras> Wes-: ha, another person to ask about binary/b :)
[15:08] <ondras> Wes-: may I ?
[15:08] <Wes-> lelec: This is not rocket science. It's really quite easy. David under-thinks, Kris over-thinks. :)
[15:08] <Wes-> ondras: of course!
[15:09] <ondras> Wes-: first, ByteString.join? shouldn't that be ByteArray.join ?
[15:09] <ondras> next, .indexOf - what is the meaning of ByteString/ByteArray as a first argument?
[15:09] <lelec> thanks wes
[15:10] <Wes-> ondras: wierd, we don't have a join implementation, but yes, I'd agree (maybe it was added late?)
[15:10] <ondras> okay
[15:10] <ondras> will ask Kris
[15:10] <Wes-> ondras: ba.indexOf(new ByteArray[10]) would find the first \n in ba
[15:11] <ondras> Wes-: the question is, what if a BS/BA supplied in this way has .length > !
[15:11] <ondras> * >1
[15:11] <ondras> (or == 0)
[15:11] * Wes- reads code
[15:12] <Wes-> That's a good question. We implemented with memchr(). Not convinced that's right.
[15:13] <Wes-> ondras: wait!
[15:13] <kriszyp> lelec, if you are interested in using a common DB API server and client side, you might want to check out github.com/kriszyp/perstore/. W3C and browsers are basically abandoning the web database api in lieu of the W3C indexed database API, which is what this project is based on
[15:13] <Wes-> ondras: indexOf takes a byte according to the spec
[15:13] <Wes-> But, yet, the spec says ByteSTring of any length
[15:13] <Wes-> well, that's dumb
[15:14] <Wes-> ondras: the *right* behaviour would be to model String::indexOf and Array::indexOf
[15:14] <ondras> hmhm
[15:14] <ondras> okay
[15:14] <ondras> so a whole match must occur
[15:16] <ondras> okay, my impl also used a trivial search, but this certainly has to take the more difficult path
[15:17] <ondras> Wes-: String::indexOf(Array) and vice versa don't make much sense
[15:17] <ondras> err
[15:17] <ondras> Anything::indexOf(Array) :)
[15:17] <ondras> this is imho just plain bad
[15:18] <Wes-> ondras: My advice - make a note in your comments and implement single-char search
[15:18] <ondras> okay
[15:18] <lelec> thanks kriszyp, i take a look
[15:18] <Wes-> Then when Binary/final is on the table, make sure you get out your notebook and help to make the spec bullet proof. :)
[15:19] <ondras> yeah :)
[15:19] * ondras will now familiarize himself with iconv
[15:19] <ondras> detach, going home
[15:19] <ondras> Wes-: thanks for consultations
[15:24] <Wes-> ondras: my pleasure!
[15:24] <Wes-> ondras: hey, you should read through the gpsee code for that
[15:25] <ondras> will do
[15:25] <ondras> but - you know - one is often intrigued just by the code which is not present
[15:25] <ondras> (ByteString.join, indexOf(ByteArray), ...)
[15:26] <Wes-> I'm actually surprised we don't have ByteArray.join
[15:26] <ondras> it actually makes sense to me :)
[15:26] <Wes-> that's actually a really freakin' useful method in the general case
[15:26] <Wes-> like struct iovec
[15:26] <Wes-> but ByteArray (not string) join would need to behave slightly differently from Array to be really useful
[15:26] <ondras> well, it is, but when specced as ByteString.join...
[15:26] <Wes-> it needs to join with *nothing* when no argument is present
[15:27] <Wes-> instead of commas like ARray
[15:27] <Wes-> So you could use that to build data structures
[15:27] <ondras> and the return value ... ?
[15:27] <Wes-> Actually, another method that would be spank: structJoin -- join a ByteArray, with nothing, on the current platform's struct alignment boundary
[15:27] <ondras> ByteArray.join([1,2,3]).join() == ByteString([1,2,3]) ?
[15:28] <Wes-> ondras: another ByteArray. Or a ByteString. Doesn't really matter
[15:28] <ondras> I made a mistake there though
[15:28] <ondras> never mind
[15:28] <ondras> rather go home
[15:28] <ondras> afk .)
[15:28] <Wes-> People seem to ascribe magical things to Array/String, I just treat them as immutable/mutable BLOB with worker methods that I might want
[15:28] <Wes-> :)
[18:23] <ashb> tlrobinson: you had a regexp to split command line arguments didn't you?
[18:24] <ashb> split a stirng as cmd line arguments that is
[18:34] <akahn> Reading http://commonjs.org/ , what allows the interpreters to be so fast? As compared to Ruby's MRI, for example.
[18:34] <evilstreak> the amount of work being put into them largely
[18:35] <evilstreak> Google, Mozilla, Opera, Apple and Microsoft are all working on the problem to make client-side execution on resource-starved machines seem spritely
[18:35] <evilstreak> actually, is it Apple for Webkit?
[18:36] <akahn> evilstreak: interesting. so there's nothing about the language that *allows* the interpreter to be fast.
[18:37] <evilstreak> there may be. for that you'll have to ask someone who understands more about code execution than I
[18:37] <Wes-> akahn: if you really want to know, lots of patience and a question in #jslang on irc.mozilla.org will yield a good answer
[18:37] <akahn> Wes-: thanks
[18:37] <inimino> akahn: the language features of course play a part in what optimizations can be done
[18:39] <akahn> Wes-: what is their interpreter called?
[18:40] <Wes-> akahn: whose?
[18:40] <akahn> mozilla
[18:40] <ashb> spidermonkey is the one in firefox
[18:40] <inimino> akahn: spidermonkey
[18:40] <Wes-> Mozilla has three, SpiderMonkey, Rhino and Narcissuss
[18:40] <ashb> and rhino is the java version, but that is a different team
[18:43] <Wes-> ashb: I just posted an interesting implementation of Byte to the list
[18:43] <ashb> k
[19:24] <ashb> stupid valueOf context
[19:24] <ashb> for a moment there i thought we'd be able to have Byte work for == 10 and == "\n"
[19:25] <ashb> but valueOf is passed "undefined" (yes a string) each time
[19:32] <Wes-> ashb: you might be able to make it work for 10 == instead of == 10
[19:33] <Wes-> and of course, you can make it work "right" in spidermonkey, but that doesn't help the specification case
[19:36] <ashb> yeah
[21:19] <tlrobinson> ashb: i thought i did but it turned out to fail in lots of cases, or at least it doesn't match bash exactly
[21:19] <ashb> ah
[21:22] <tlrobinson> ashb http://gist.github.com/274690
[21:22] <ashb> thanks
[22:44] <micheil> morning all.
[22:44] <micheil> Is there anything further on the Email API?
[22:45] <deanlandolt> micheil: there was an email api?
[22:45] <micheil> http://wiki.commonjs.org/wiki/Email
[22:46] <micheil> I've been working on an SMTP Client module for node recently, so if there's an spec, it'd be good to have it follow that
[22:46] <deanlandolt> well, we look specless, so you're in a pretty good position to propose one :)
[22:47] <micheil> heh heh
[22:47] <dmachi> I have a little one i wrote on top of persevere, but would generally work with any rhino, though its pretty simple at the moment. Seems like that page is only laying out what exists for it to be defined in the future, so implementations work towards that, hopefully not like javax mail though :P
[22:47] <micheil> dmachi: anywhere for the world to see?
[22:48] <deanlandolt> i think nrstott was working on one too
[22:48] <dmachi> I could probably copy it somewhere for the world to see, i think kris is using some version of it for pintura
[22:48] <dmachi> or at least something base don pintura
[22:48] <deanlandolt> dmachi: i'll see if i can't find it in pintura...i saw some mention of email in the wiki example settings
[22:49] <dmachi> deanlandolt: i think its likely for a project that kris is using to build up pintura, not pintura itself, but maybe there is osmething in the wiki
[22:49] <dmachi> it was nothing extensive, mostly me trying to figure out how to work through the java :P
[22:50] <dmachi> I'd skew towards super simple api for sending though, as its common but also the simple case is the common case out of that :)
[22:50] <deanlandolt> hopefully the commonjs api doesn't require such machinations :)
[22:50] <micheil> As much as it'd be good to say, "Oh yeah, this smtp client is non-blocking" it's probably not possible.
[22:50] <dmachi> true not there, but i guess lowerlevel :)
[22:50] <deanlandolt> micheil: perhaps you could have it send you an email when it's done ;)
[22:50] <dmachi> oh, i' think that would work (and be a requirement) myself
[22:50] <micheil> I've been implementing the raw protocol
[22:50] <micheil> deanlandolt: email address?
[22:51] <micheil> ;P
[22:51] <deanlandolt> heh
[22:51] <micheil> deanlandolt: it currently sends emails, http://github.com/miksago/node-smtp
[22:51] <dmachi> micheil: oh my bad, i forgot what channel and sometimes have trouble distinguishing between general ssjs and all the specific projects
[22:51] <deanlandolt> what's it missing?
[22:51] <dmachi> :)
[22:52] <dmachi> i guess you are trying to get the pure js (or at least as close as possible) impl
[22:52] <micheil> yeah
[22:52] <deanlandolt> micheil: so the main issue is ssl/tls?
[22:52] <micheil> yeah
[22:53] <micheil> hopefully node will have ssl/tls soon
[22:53] <dmachi> micheil: (assuming you are teh same micheil I usually talk to) you are always a glutton for punishment eh? :)
[22:53] <micheil> dmachi: hmm? #dojo, then yes ;P
[22:53] <dmachi> :)
[22:54] <deanlandolt> micheil: what about it has to block?
[22:54] <micheil> deanlandolt: currently it's event based, although, the smtp protocol is very reply oriented
[22:55] <micheil> so, you send the server something, and have to wait for an OK type status code before proceeding
[22:55] <deanlandolt> sounds like a lot of nested promises, certainly
[22:56] <deanlandolt> does it do any blocking i/o in its current form?
[22:56] <micheil> well, currently I have in based on those nested promises
[22:56] <ashb> micheil, deanlandolt : an email client is *not* something that needs to be speced
[22:56] <ashb> that sort of task is why we have modules
[22:57] <ashb> all that would need to be speced at hte commonjs level is sockets/network
[22:57] <micheil> ashb: no standard ways for sending emails?
[22:57] <deanlandolt> ashb: good point
[22:57] <deanlandolt> i always kinda forget that ;)
[22:57] <ashb> micheil: no. its a module that can very easily be implemted in pure js
[22:57] <deanlandolt> ashb: /very/ easily? ;)
[22:57] <ashb> (fsvo very easy)
[22:57] <micheil> ashb: I take it you've done so?
[22:57] <ashb> not had the need
[22:57] <ashb> bnut specs have a habit of bikeshedding hugely
[22:57] <ashb> so they should be avoided when not strictly needed
[22:57] <micheil> so you can't really talk as to whether it'd be easy to implement..
[22:58] <ashb> and if the underlying tech needed is specs (in this case socket io_ then a module suits it much better
[22:58] <ashb> micheil: I can sent email via telnet
[22:58] <ashb> a trivial case isn't hard. its the error handling that gets harder
[22:58] <micheil> telnet emailing isn't that hard
[22:58] <ashb> but my point is that commonJS doesn't need and shouldn't have a proposal on how to sent emails.
[22:59] <micheil> for some, all you need is to open a connection and then send all the commands at once, which may work, but isn't reliable
[22:59] <micheil> I'm not saying there should be a spec for smtp in commonjs, but rather something like a mailer class, as to how emails can easily be setn (without using raw protocols)
[23:00] <ashb> s/spec/module/ and yes, i agree
[23:00] <deanlandolt> but we can't have a decent module without a sockets spec :-/
[23:00] <ashb> yes. we need a socket spec of some form
[23:01] <ashb> but thats the only bit of an email/smtp module that couldn't be done in pure js
[23:01] <ashb> and anything that can be done in pure JS doesn't belong as a CommonJS spec
[23:02] <micheil> fair enough :)
[23:02] <ashb> there are obviously going ot be exceptions to that rulem, because there always are
[23:02] <ashb> but its a good stance to take

 

 

Logs by date :