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

2010-01-15:

[01:27am] <SubtleGradient> ashb> ahoy, cpojer says you had context-based natives in flossfred er? flusspferd. What issues did you run into?
[01:38am] <SubtleGradient> an interesting wrapper for `require` would keep track of the keys of the global object and the prototypes of all natives. Then it would compare the differences and log them after requiring happened. Then you can be aware of any extensions that each module might be doing
[01:39am] <SubtleGradient> cpojer> you think?
[01:41am] <cpojer> yah
[01:41am] <cpojer> I saw something like this somewhere already
[01:41am] <cpojer> just for the global only though
[03:12am] <ryah is now known as ryah_away.
[06:49am] <kriskowal> ashb, ondras, zumbrunn, tlrobinson? Wes-- just did a bunch of work on the "fs-base" proposal. Got opinions?
[08:05am] <ondras> kriskowal> I saw the diff and it looks reasonable
[08:08am] <kriskowal> coo
[09:59am] <oberhamsi> was the reason behind readLines() not trimming away the line-seperator really the EOF issue? found all the loooong discussion threads and i'm lazy
[10:00am] <oberhamsi> i bumped into this yesterday and filed a bug against helmang... when i noticed this is speced behaviour lol
[11:23am] <inimino> oberhamsi> the EOF issue is somewhat hairy, I implemented a streamLines function twice, the second time leaving the separators in because it makes a better API in practice
[11:37am] <oberhamsi> but i understood correctly that EOF and seperator are related? i don't care about EOF i just don't like the \n in my lines
[11:39am] <ondras> stripping newlines is evil
[11:39am] <ondras> current spec allows .readLines().join("") => identical content
[11:39am] <ondras> if you decide to strip newlines, you are unable to reconstruct them
[11:41am] <oberhamsi> you can always 'rb' if you care about the exact content
[11:42am] <ondras> this is not related to "b"inary file mode
[11:42am] <ondras> but to the fact that there are various newlines used out there
[11:43am] <ondras> imagine a code, for instance, that removes 2nd line from a file
[11:43am] <oberhamsi> whatever they are i want them stripped when i say readLines(). any csv reader adding the seperator to every field would be called buggy
[11:43am] <oberhamsi> yes
[11:43am] <ondras> how do you implement it?
[11:43am] <ondras> .readLines().splice(1).join("")
[11:43am] <ondras> and voila
[11:44am] <ondras> provided no stripping is done
[11:44am] <oberhamsi> .readLines().splice(1).join("\n")
[11:44am] <oberhamsi:
[11:44am] <ondras> nono
[11:44am] <ondras> you have done something different
[11:44am] <ondras> you affected other rows as well
[11:44am] <ondras> the task was only to remove 2nd line
[11:44am] <oberhamsi> no just the seperator might be different now
[11:44am] <oberhamsi> if you care that much about what the exact line seperator is open it in binary
[11:44am] <ondras> there is no difference opening it in binary .)
[11:45am] <ondras> you still failed to complete the simple task of removing 2nd line
[11:45am] <oberhamsi> i don't like it but won't open the EOF worm-can again
[11:45am] <ondras> afaik there is no relation to EOF here
[11:46am] <oberhamsi> that's what i gathered from the commons discussions
[12:08pm] <evilstreak> ondras> pretty sure you need `file = readlines(); file.splice(1,1); file.join("")`
[12:08pm] <evilstreak> just for pedantry
[12:09pm] <evilstreak> since a) splice needs a howMany parameter unless you're using Spidermonkey which removes them all
[12:09pm] <evilstreak> and b) splice returns the removed elements
[12:10pm] <evilstreak> but yeah, new line futzing isn't cool, don't do it
[12:10pm] <ondras> evilstreak> yeah, yourre right, my example was too simplified
[12:23pm] <oberhamsi> sorry lunch
[12:24pm] <oberhamsi> ok, identical content is the benefit. will think about it
[1:32pm] <kripken_ is now known as kripken.
[4:12pm] <Wes--> oberhamsi> not the only benefit. If you strip lines, you cannot accurately reconstruct the last line of the file, or know whether you have done a full-line read from a socket
[4:23pm] <oberhamsi> yet you see my point that it's unexpected to have the seperator at the end of each line when i tell it to readLines()
[4:23pm] <oberhamsi> but i get your concerns
[4:24pm] <Wes--> oberhamsi> well, first of all, I think making an array from a file is not particularly useful. A straight-up iterator is probably a better choice. The question becomes, though, WTF do you do with the last line of the file without the \n?
[4:25pm] <Wes--> An interesting interface would be an iterator which returns something like
[4:25pm] <oberhamsi> iterator +1
[4:25pm] <Wes--> { toString> function() { return "the string" }, hasNewline> true
[4:25pm] <Wes--> basically, a boxed string
[4:26pm] <evilstreak> we do something similar in our markdown code
[4:26pm] <Wes--> this also has the advantage that you can delay the charset decoding and 8->16 bit promotino until the API consumer has indicated he wants to view the line as a string
[4:26pm] <oberhamsi> i'm not sure i want to make an even bigger fuss... i can to trim()
[4:26pm] <ashb> we actually use new String() tho
[4:26pm] <ashb> since then you can use match etc on it
[4:26pm] <evilstreak> yeah
[4:26pm] <evilstreak> but we separate the block dividers from the block content
[4:26pm] <Wes--> oberhamsi> But trim() means you are reallocating the string. decisions, decisions!
[4:26pm] <ashb> http://github.com/evilstreak/markdown-js/blob/master/lib/markdown.js#L95-116
[4:26pm] <ashb> Wes--> ^^
[4:26pm] <inimino> oberhamsi> line=line.slice(0,-1)
[4:26pm] <oberhamsi> inimino> even better, yeah
[4:27pm] <evilstreak> line = new String( "foo" ); line.end = "\n";
[4:27pm] <evilstreak> return that from your iterator
[4:27pm] <Wes--> ashb> that's a good point
[4:27pm] <evilstreak> job\s a good'un
[4:27pm] <ondras> inimino> in the case of CRLF ?
[4:28pm] <inimino> ondras> -2 in that case
[4:28pm] <ondras> inimino> yeah, that is the pain
[4:29pm] <evilstreak> .replace( /\r?\n?$/, "" )
[4:30pm] <oberhamsi> current spec> would readLine() add \n to the last line if it's missing?
[4:30pm] <ondras> noo
[6:41pm] <ryah_away is now known as ryah.
[8:39pm] <kriszyp is now known as kriszyp_afk.
[9:02pm] <ondras> guys
[9:02pm] <ondras> binary/d
[9:02pm] <Wes--> what about it?
[9:02pm] <ondras> why are those alphabets part of returned exports?
[9:02pm] <Wes--> which alphabets?
[9:03pm] <ondras> http://wiki.commonjs.org/wiki/Binary/D
[9:03pm] <ondras> base8, base16, base32, ..
[9:03pm] <Wes--> ondras> presumably for encoding binary data in a neutral format
[9:03pm] <Wes--> I would probably never use anything other than base64
[9:04pm] <ondras> and, also - what is that hype around base32 encoding?
[9:04pm] <Wes--> and that in the MIME context
[9:04pm] <* Wes-- does not know
[9:04pm] <ondras> omg
[9:04pm] <* ondras agrees with base64
[9:04pm] <ondras> but all those other alphabets..
[9:04pm] <ondras> ohmygod.
[9:04pm] <Wes--> ondras> FWIW, they are the same algorithm, but different alphabets
[9:04pm] <Wes--> I'm not sure it belongs in binary/*
[9:04pm] <Wes--> but it's not expensive, either
[9:05pm] <ondras> yeah, the same algorithm, that is logical
[9:05pm] <ondras> but, most importantly
[9:05pm] <ondras> I believe that everyting regarding these bastards
[9:05pm] <ondras> can be done on js level
[9:05pm] <ondras> *everything
[9:07pm] <Wes--> ondras> That is why gpsee has blended modules
[9:07pm] <inimino> ondras> sure, lots of Binary/* was designed to be implementable in JavaScript, no?
[9:07pm] <Wes--> but you can't implement the BLOB part of binary/* in pure JS without being wasteful
[9:07pm] <Wes--> inimino> yes
[9:08pm] <Wes--> in fact, the rhino implementation is mostly JS IIUC
[9:08pm] <ondras> Wes--> well, this is precisely the reason I will add hybrid modules to v8cgi
[9:08pm] <Wes--> ondras> if you need design assistance feel free to ping
[9:08pm] <ondras> Wes--> btw, I do not see ByteString.length ... am I looking wrong?
[9:09pm] <Wes--> ondras> ....it must be theere; if not, it's a mistake
[9:09pm] <ondras> okay
[9:09pm] <ondras> doing hybrid modules should not be difficult
[9:09pm] <ondras> but there are still some things in binary/d which are puzzling me
[9:09pm] <ondras> forinstance, ByteString::valueOf
[9:10pm] <ondras> what does this exactly do?
[9:10pm] <Wes--> good question
[9:10pm] <isaacs_ is now known as isaacs.
[9:11pm] <ondras> also, I understand how Content works, but what is it good for?
[9:12pm] <Wes--> ondras> remind me what Content is?
[9:12pm] <ondras> var myBinaryString = new BinaryString([0,1,2]);
[9:12pm] <ondras> myBinaryString.Content == BinaryString
[9:12pm] <ondras> (aha! myBinaryString[2] <instanceo myBinaryString.Content)
[9:12pm] <ondras> *instanceof
[9:12pm] <ondras> but what the...
[9:13pm] <ondras> .Content tells you what [[Get]] <yields
[9:14pm] <Wes--> that's not bad, actually
[9:14pm] <ashb> i still think yielding ByteString is *wrong*
[9:15pm] <ondras> ashb> I agree
[9:15pm] <* ondras is going to switch to binary/b apparently
[9:15pm] <ondras> at least now, in the beginning
[9:15pm] <ondras> ashb> myBinaryString[index] <should return Number, okay?
[9:16pm] <ashb> thats what i think, yes
[9:16pm] <ondras> that would nicely extend binary/b
[9:16pm] <ondras> ah, binary/b already specifies yielding bytestrings
[9:16pm] <ondras:
[9:17pm] <ashb> Wes--> what do you think it should be?
[9:17pm] <Wes--> ashb> You think that bs[0] <should not be a byte string?
[9:18pm] <Wes--> let's see
[9:18pm] <ashb> a ByteString of length one is approx useles for every case i've ever wanted
[9:18pm] <Wes--> pros for byte string> .... can use as a byte string, cheap to allocate memory
[9:18pm] <Wes--> cons for byte string> ... makes deep iteration hard, object allocation overhead
[9:19pm] <ashb> useing the value hard
[9:19pm] <Wes--> con assumes that alternative repn isnumber
[9:19pm] <ashb> i can't think of an actual usecase for [x] <on a ByteString as it stands
[9:19pm] <Wes--> ISTR having to use charCodeAt() with binary/b for something similar as well
[9:19pm] <Wes--> when I really wanted []
[9:19pm] <ashb> yeah
[9:19pm] <Wes--> might've been on bytearray?
[9:19pm] <ashb> probably both similar
[9:20pm] <Wes--> I'll let you right now, the main use for [] <on ByteSTring will be to look for trailing new lines!
[9:20pm] <ashb> or other such separators (JPEGs etc)
[9:21pm] <ashb> or just to read individual bytes - to me its the natural way to process the data in it
[9:21pm] <ondras> detach, have fun guys
[9:22pm] <Wes--> oh, actually
[9:22pm] <deanlandolt> FWIW (i don't do all that much with binary) but i'm w/ ashb> i don't know of a good reason to have [] <return bs
[9:22pm] <Wes--> it will be used to implement other methods, like split and stuff in the naive cases too
[9:22pm] <Wes--> deanlandolt> I'm sort of ambivalent as long as charCodeAt() works
[9:24pm] <isaacs_ is now known as isaacs.
[9:24pm] <ashb> deanlandolt> "because 'string'[1] <returns a String"
[9:24pm] <ashb> to which my argument has always been, thats because there is no Character type
[9:24pm] <deanlandolt> a String primative
[9:24pm] <ashb> yes
[9:24pm] <deanlandolt> exactly
[9:25pm] <ashb> Number is the natrual byte type
[9:25pm] <deanlandolt> agreed
[9:25pm] <ashb> imnsho
[9:27pm] <deanlandolt> it's the only logical way to represent a "byte" in js...and given tc39's reluctance to make sweeping changes i doubt they'd add "char" or "byte" type any time in the foreseeable future, so it would always be number
[9:28pm] <Wes--> ashb> you can look at that a different way
[9:28pm] <ashb> i choose not to
[9:29pm] <Wes--> It's not that String[1] <returns are String
[9:29pm] <Wes--> It's that String[1] <returns a primitive
[9:29pm] <Wes--> so, ByteString[1] <should also return a primitive!
[9:29pm] <Wes--> So then, the question becomes> which primitive?
[9:29pm] <ashb> we are .... 4 years from having a ByteString primitive
[9:29pm] <deanlandolt> Wes--> yeah, that's what i was getting at above
[9:29pm] <ashb> at least
[9:29pm] <* Wes-- nods @ dean
[9:30pm] <ashb> cmon pdebuild. WORK ALREADY
[9:30pm] <deanlandolt> which primitive? why not string> "00001010"
[9:31pm] <* deanlandolt ducks
[9:32pm] <Wes--> actually, how about an array of boolean?
[9:33pm] <deanlandolt> that's clearly better than my joke, but what is it really good for?
[9:33pm] <inimino> better make it an iterator
[9:34pm] <Wes--> deanlandolt> true
[9:34pm] <Wes--> HA HA HA HA HA
[9:35pm] <inimino> hehe
[9:44pm] <ashb> hmmm why does sudo not run on this fresh vm
[9:44pm] <ashb> oh it was trying to resolve host name
[9:44pm] <Wes--> ashb> did you chmod 755 sudo? That would screw it up!
[9:44pm] <ashb> and i haven't got the network working right on it yet
[9:44pm] <deanlandolt> actually, it just occured to me...what's wrong with bytestring returning a string primative?
[9:45pm] <ashb> storing binary data in strings is Wrong
[9:45pm] <ashb> if it was going to that, then we could just use Strings themselves
[9:45pm] <deanlandolt> i'm not suggesting storing them as strings...
[9:45pm] <deanlandolt> clearly they're numbers
[9:45pm] <Wes--> just use the bottom byte, heh.
[9:46pm] <Wes--> is "\0" falsey?
[9:46pm] <deanlandolt> heh...no...interesting point
[9:46pm] <deanlandolt> still, to me, returning a bytestring on [] <would be equivilent to returning a boxed String on indexOf
[9:47pm] <deanlandolt> but (if you're working in ascii) getting a string primative back would be logical...if you're not, well, you'll find out mighty quick when your system start flipping out on you
[9:48pm] <ashb> if you want to deal with ascii decode it to ascii
[9:48pm] <deanlandolt> fair enough, i'm just trying to think of a way to provide the consistency kk seems to be looking for
[9:49pm] <deanlandolt> charCodeAt seems like the logical thing to do if you want a number...
[9:49pm] <deanlandolt> a single ascii character does seem like a logical "byte"
[9:50pm] <deanlandolt> i know js strings aren't ascii, but js numbers aren't restricted to 0 to 255 either
[9:51pm] <deanlandolt> whatever...i'm pretty ignorant to (and ambivelant about) all this...but it'd be nice to find a resolution to these remaining binary issues
[10:04pm] <inimino> a single ASCII character isn't even 8 bits
[10:05pm] <Wes--> for certain values of ascii
[10:05pm] <Wes--> personally, I think we should all change to PETSCII
[10:05pm] <inimino> treating bytes as strings implies an encoding and at that point they're not bytes anymore, they're just another kind of string
[10:13pm] <deanlandolt> yeah, that wasn't a very well thought out suggestion
[10:13pm] <deanlandolt> but...there are two very good arguments why bytestring[] <shouldn't return a ByteString that came out of this at least...
[10:15pm] <deanlandolt> or one, stated two different ways...it should return a primitive type and it returning a ByteString would be about the same as String.prototype.indexOf returning a boxed new String()

 

 

Logs by date :