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

2010-01-08:

[0:04] <Dantman> T_T Ugh... I don't want to allow ftp access to our new servers. Thinking about the madness dealing with .php scripts is insane.
[0:08] <ashb> Dantman: so dont. scp or sftp or webdav over https
[0:40] <Dantman> Webdav would require client sites to be completely webserver writable. Scp would require shell access. My real issue isn't ftp, it's allowing clients the ability to upload scripts to our server.
[0:40] <Dantman> T_T I didn't want to deal with the maze of security issues to consider.
[2:34] <Dantman> Rackspace Cloud Servers is looking nice, an instance running idle (not really using any bandwidth) for 34 days cost about $12.
[2:35] <inimino> Dantman: what's it cost when you actually use it?
[2:35] <Dantman> ^_^ A linode vps doing about the same costs me $20 a month iirc
[2:35] <Dantman> We'll see
[2:42] <joshthecoder> sure is cheaper than ec2
[2:44] <Dantman> Hmm... Cloud Servers is 22 cents a gb out while AWS is 17 cents a gb out for the first 10TB... (It does go down to 10 cents but that's only after paying for 150Tb in a month, like that'll happen)
[2:45] <Dantman> Oh well... The cheaper server costs will probably offset that price difference enough that it's overall cheaper.
[2:47] <Dantman> Especially compared to paying something like a hundred for an idle ec2 instance
[2:47] <Dantman> iirc greg said something like $300 or so a month for our current costs on aws.
[2:48] <joshthecoder> do you use reserved or spot instances at all?
[2:49] <joshthecoder> that can help reduce the price a bit
[2:52] <Dantman> nah... I never had any real control over the aws account anyways
[2:52] <Dantman> And the firewall is annoying.
[3:18] <Dantman> ^_^ I'd better make a note to make sure that bash-completion is installed on all the new servers...
[3:20] <Dantman> Tch, damn... I forgot that I put the internal wiki I've been documenting config on over on the new server, before I decided to take down apache to experiment with varnish
[4:01] <lotia> apologies if this has already been answered, but is node.js an implementation of the commonjs spec?
[4:04] <deanlandolt> lotia: which spec?
[4:04] <deanlandolt> they implement SecurableModules, and it looks like they'll implement the Promise proposal
[4:05] <deanlandolt> as for file stuff, commonjs is mostly sync stuff for now so until async comes along not so much
[4:06] <lotia> thanks deanlandolt
[4:43] <erikvold> llari: nope didn't work
[4:45] <erikvold> llari: that's weird isn't it? I added a path to gitosis-serve to PATH, but it's not found when I try 'git clone git@ip:gitosis-admin.git'
[4:46] <erikvold> it's like .bashsrc isn't working..
[7:36] <Dantman> @_@ Agh... configuration planning maze... T_T
[15:29] <Wes-> Does anybody in here understand extended file attributes?
[15:30] <ashb> only nominally
[15:30] <ashb> mac resource forks are an example of them?
[15:31] <ashb> i guess NTFS alternate streams aren't tho?
[15:31] <MisterN> isn't there many kinds of them?
[15:31] <MisterN> xfs xattr being perhaps the most portable
[15:32] <ashb> seems you can have xattr on ext* too
[15:32] <ashb> Wes-: why?
[15:32] <Wes-> I want to finish implementing fs-base, but don't understand the end of the spec
[15:32] <ashb> ah
[15:33] <Wes-> did you do anything for them?
[15:33] <ashb> they are basically key/value stores associtated with a filename
[15:33] <ashb> didn't bother
[15:33] <ashb> its optional :)
[15:35] <ashb> so on OSX its http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man2/listxattr.2.html
[15:36] <ashb> Wes-: http://en.wikipedia.org/wiki/Extended_file_attributes might be of some help
[15:50] <Wes-> ashb: Thanks. I think I'm going to be leaving that alone for now - at least until it gets standardized across POSIX
[15:51] <ashb> ha.
[18:27] <ashb> Wes-: 'It is an error to specify a directory for target when source is a file.'
[18:27] <ashb> move("foo.txt", "bar/")
[18:27] <ashb> not allowed?
[18:27] <Wes-> correct
[18:28] <ashb> seems a bit odd as `mv` supports that
[18:28] <Wes-> ashb: but POSIX rename() doesn't -- I'm not married to the status quo, just the rigorousness of spec -- but mv could certainly be implemented at a higher level
[18:28] <Wes-> (also mv supports multiple files, so it HAS to do that)
[18:29] <ashb> ah okay.
[18:30] <ashb> [EISDIR] new is a directory, but old is not a directory.
[18:30] <ashb> i'm guessing that text is just wrong
[18:30] <ashb> as it doesn't say the same thing reversed
[18:31] <ashb> oh theres [ENOTDIR] too
[18:33] <ashb> symlinks dont have permissions of their own do they?
[18:34] <Wes-> ashb: Actually, they do, but nobody uses anything but 777 in practice
[18:34] <Wes-> see lchmod
[18:34] <ashb> ah
[18:38] * Wes- discovers fs-base has no close method
[18:44] <MisterN> lchmod doesn't seem to exist on linux
[19:07] <ashb> Wes-: that would part of the stream interface
[19:07] <ashb> we dont say what rawOpen returns either
[19:08] <MisterN> python got streams completely wrong.
[19:08] <ashb> oh?
[19:09] <MisterN> there's only "this is a file-like object except: [list of changes]" or "this is a generator"
[19:09] <MisterN> nothing structured :/
[19:09] <ashb> isn't a generator just a stream interface?
[19:09] <MisterN> and it combines the write and read pointer into one
[19:09] <ashb> well i guess oyu can't read arbitrary data from it
[19:09] <ashb> only what it wants to return
[19:10] <MisterN> ashb: you can't call the read member function
[19:10] <ashb> what ever?
[19:10] <MisterN> which you can for file-like objects
[19:10] <MisterN> sometimes interfaces _are_ useful, if only for documentation.
[19:11] <ashb> agreed
[19:11] <ashb> i really think that the stream should just be a ducktype interface
[19:12] <MisterN> at least provide a couple of "concepts", then
[19:12] <MisterN> concepts in this sense are sets of supported methods, basically
[19:13] <ashb> i'm not quite sure how text/binary streams should be related yet (in my mind)
[19:13] <MisterN> ashb: do you know c++ stl concepts?
[19:13] <ashb> InputIterator etc?
[19:14] <MisterN> yeah
[19:14] <ashb> eys then :) I know them as traits or roles tho
[19:14] <MisterN> you can say "this function needs an InputIterator" or "this function needs a ForwardIterator"
[19:14] <MisterN> concepts is the preferred word, in c++
[19:15] <MisterN> here's a couple of concepts: http://www.sgi.com/tech/stl/table_of_contents.html
[19:15] <MisterN> ashb: but the great thing is you can specify behaviors formally, this way, without having to use inheritance
[19:16] <ashb> http://flusspferd.org/docs/js/bundled%20modules/gmp/base.html
[19:16] <ashb> much like that, but slightly more formal
[19:34] <jmerlin> anyone around?
[19:34] <Wes-> kinda
[19:35] <jmerlin> i have a problem with v8 :(
[19:35] <jmerlin> rather, its lack of documentation outside of reading the internal source code
[19:37] <Wes-> Ah, I don't use v8, but have read some of the code. It's fairly decently reaedable.
[19:38] <jmerlin> true enough, but the issue i have i can't help but believe that the solution is already within v8 and no inheritence or hackery would be required to make things work properly
[19:40] <jmerlin> my goal is not dissimilar to commonjs's, i have some projects that would benefit to an incredible degree from JS's prototype based dynamic object system, allowing me to on-the-fly make changes to code and not need to constantly restart to test/debug features, so i went about exposing some API to v8 by extending and improving the shell example, primarily adding a very simple tcp/ip networking api
[19:41] <MisterN> jmerlin: seen flusspferd?
[19:41] <jmerlin> in this case, i have several classes in C++ exposed through function objects storing pointers to the objects in internal fields, but the issue I have, is since I do not actually track objects created in these factories, and the GC doesn't call delete on external pointers, the instances are guaranteed to leak memory every time
[19:43] <Wes-> sounds like you need to learn about js object finalization in v8 (provided it has it... it must?)
[19:45] <jmerlin> Wes-: i'm not seeing it going through the api, in v8.h
[19:45] <MisterN> ashb: we need a v8 backend, eh?:)
[19:45] <jmerlin> i see you could probably do it with weak handles but that seems iffy, a finalization on external pointers on a GC pass where they're about to be freed would make tons more sense to me
[19:45] <ashb> MisterN: yeah.
[19:46] <ashb> MisterN: should prtoqably change the rooting API first
[19:46] <ashb> so that it becomse closer to v8's
[19:46] <ashb> jmerlin: are you tied to using v8?
[19:46] <jmerlin> ashb: not really but i like it more than others i've looked at
[19:47] <ashb> jmerlin: http://flusspferd.org/docs/cpp-tutorial-values_and_objects.html
[19:47] <ashb> flusspferd makes binding C++ classes a lot easier
[19:48] <MisterN> functions too
[19:48] <jmerlin> it's not the binding that's difficult, that's really simple
[19:48] <ashb> spidermonkey only currently, but we do have medium term plans to add support for JSC and v8 (all without changing hte user code)
[19:48] <jmerlin> i already ahve a generic binding api i made
[19:48] <MisterN> jmerlin: you are having problems precisely with the bindings, so i can't follow.
[19:49] <ashb> binding to me means exposing to JS, creating and life-cycle managment
[19:50] <ashb> jmerlin: so which way round are you having GC issues? the JS value is getting freed to early, ot the C++ one isn't getting freed?
[19:51] <ashb> or something else
[19:53] <ondras> the latter I believe
[19:53] <jmerlin> it's the latter
[19:53] <ondras> afaik a weak persistent handle must be used here
[19:53] <ondras> (I do this in v8cgi)
[19:53] <jmerlin> that's what i was thinking
[19:54] <jmerlin> make a persistent handle, weaken it, give it a callback, and then when the JS drops the handle, the GC will trigger your callback because only weak handles remain
[19:54] <ondras> exactly.
[19:54] <jmerlin> seems like an odd way of doing things lol.
[19:54] <ondras> well, as long as it works...
[19:54] <jmerlin> let me test that really quick, should be an easy modification
[19:55] <jmerlin> btw your site is really slow :(
[19:55] <ondras> note that you should create *many* instances in order to trigger the GC
[19:55] <ondras> which one?
[19:55] <jmerlin> or down
[19:55] <jmerlin> commonjs.org/impl/v8cgi.html, just a white page (intentional?)
[19:55] <ondras> I am not related to that page in any way
[19:56] <ondras> it is bogus I suppose
[19:56] <jmerlin> ah
[19:56] <ashb> yeah - not sure who created/linked to those
[19:56] <ondras> http://code.google.com/p/v8cgi/
[19:56] <ondras> this is the preferred one
[19:56] <ashb> there's one for all of them
[19:56] <ondras> ah
[19:56] <jmerlin> i'll make a few thousand instances in a for loop, discarding the handle in the loop scope
[19:56] <ondras> yes
[19:56] <jmerlin> this object allocates a 4KB block so it'll need a sweep in the older generation
[19:57] <ondras> last time I tried, it took approx 50k iterations
[19:57] <jmerlin> well not really, that's c++ heap :|
[19:57] <ashb> v8 doesn't havea zealous GC mode does it?
[19:57] <ashb> that is one featuer which is *really* useful in spidermonkey
[19:57] <jmerlin> it really takes 50k iterations? they are proud of their generational GC sweeps
[19:57] <ashb> https://developer.mozilla.org/en/JS_SetGCZeal
[19:58] <ondras> jmerlin: that was long ago...
[19:58] <ashb> "With GC zeal enabled, GC-related crashes are much easier to reproduce (they happen more reliably) and debug (they happen sooner, closer to the source of the bug). The drawback is that GC zeal causes JavaScript code to run very (or extremely) slowly."
[19:58] <jmerlin> also, anyone tried to get things like multithreading working across contexts or even within JS itself, i have a vision in which it would work but it'd require the engine be modified extensively to work :|
[19:58] <ondras> ashb: iirc some discussion was going on the v8 mailing list regarding forced gc sweeping
[19:59] <ondras> jmerlin: I recently got a mail from some guy who was elaborating on that
[19:59] <ondras> a sec...
[19:59] <ondras> jmerlin: http://code.google.com/p/v8/issues/detail?id=510
[20:01] <jmerlin> yeah that's similar to what i had planned to do to isolate it per-thread
[20:01] <jmerlin> then threads could execute in different contexts simultaneously, which would allow a lot of power with a little inter-context API
[20:13] <jmerlin> hmm, from 100 to 150 thousand objects, the entire app crashes :|, never a GC triggered though
[20:15] <ondras> wow
[20:16] <jmerlin> what are you doing in v8cgi exactly?
[20:17] <ondras> http://code.google.com/p/v8cgi/source/browse/trunk/src/js_gc.cc
[20:17] <ondras> lines 30-34
[20:17] <ondras> a class calls this and registers its method to be called when GC happens
[20:18] <jmerlin> looks like you're just wrapping C apis :P, nice
[20:18] <ondras> it is mainly mixed stuff
[20:21] <jmerlin> do you have a buffer for packet creation of some type?
[20:24] <ondras> i am not sure i understand
[20:28] <jmerlin> in connections that require binary data transmitted over the stream
[20:29] <ondras> ah, no
[20:29] <jmerlin> ah you're doing it with strings
[20:29] <ondras> or with arrays of numbers
[20:29] <ondras> that is how binary is (so far) handled in v8cgi
[20:30] <MisterN> ondras: no binary/{a,b,c,d} yet?
[20:30] <ondras> MisterN: unfortunately no
[20:30] <ondras> I am a bit puzzled by the amount of proposals
[20:30] <ondras> i don't know which one to pick
[20:30] <jmerlin> the byte buffer object i have is explicitly made to build binary packets from bytes, words, dwords, qwords, floats/doubles
[20:30] <ondras> when none of them is definitely standardized
[20:31] <ondras> MisterN: /d looks best so far, correct?
[20:31] <Wes-> binary/b is standardized. And possibly slated for deprecation!
[20:31] <ondras> :D
[20:31] <Wes-> yes and no. d and b both have advantages
[20:31] <MisterN> ondras: i think flusspferd only supports /b so far
[20:31] <ondras> Wes-: I understand that you finished /d in gpsee and continue with fs-base ?
[20:31] <MisterN> ashb: do we support /d?
[20:32] <Wes-> if _I_ was going to implement something right now, I'd pick d without bit operators, and with new
[20:32] <Wes-> MisterN: no
[20:32] <ondras> hehe
[20:32] <ondras> the new case
[20:32] <Wes-> having new means you can write at least SOME programs which work on B or D
[20:32] <MisterN> Wes-: with new? huh?
[20:32] <Wes-> MisterN: binary/d makes var a = new ByteSTring() throw
[20:33] <Wes-> he wants var a = ByteString() instead
[20:33] <ondras> but not ByteArray, ok?
[20:33] <ondras> to comply with non-Byte types
[20:33] <ondras> as kris explained
[20:33] <Wes-> same for ByteArray
[20:33] <Wes-> IIRC
[20:33] <ondras> that is strange
[20:33] <Wes-> ondras: new String() does not throw
[20:33] <ondras> last time I spoke with kris, he told that ByteArray should use new
[20:33] <MisterN> When constructed with "new", it must throw a TypeError.
[20:33] <MisterN> WTF
[20:33] <ondras> Wes-: but people regard it as a bad practice
[20:33] <MisterN> why this shit?
[20:34] <Wes-> ondras: that's irrelevant, IMO
[20:34] <inimino> it's to allow for future standardization without constraining the behavior
[20:34] <Wes-> ondras: new String() is not great practice because it creates and object, whereas a string literal does not
[20:34] <ondras> http://wiki.commonjs.org/wiki/Binary/D#ByteArray
[20:34] <Wes-> ondras: but there is no such thing as a ByteString literal
[20:34] <ondras> A ByteArray function must exist. Calling and constructing a ByteArray both return a new ByteArray instance.
[20:34] <ondras> so ByteArray is out of question
[20:35] <Wes-> oh, so he's fixed ByteArray but not ByteString
[20:35] <ondras> Wes-: agreed. kris's point was that by standardizing an expcetion, we can force people not to do what is not right
[20:35] <MisterN> i don't follow, why is new ByteString prohibited?
[20:35] <Wes-> ondras: I don't agree that it is not right
[20:35] <Wes-> ondras: name one other object which is created in JS without new, where new makes it throw
[20:35] <ondras> generally, if I understand, Kris would standardize new String() -> throw if he could
[20:35] <ondras> and according to this...
[20:36] <ondras> Wes-: none, but having a bad spec does not imply we cannot extend it in a better way
[20:36] <Wes-> but new String() is the exception -- strings are atoms in the JS language!
[20:36] <Wes-> new Number() is also the exception
[20:36] <ondras> and new Boolean()
[20:36] <Wes-> but I don't see anybody proposing a syntax for literal ByteStrings
[20:36] <MisterN> i don't see how kris' crazy obsessions belong into commonjs.
[20:36] <Wes-> IMO ByteString without new is questionable, and new ByteSTring() throwing is simply wrong.
[20:37] <ondras> Wes-: the absence of free literals is sad, that is true, but we cannot fix this :)
[20:37] <Wes-> ondras: Exactly, so why pretend we have them?
[20:37] <ondras> hm
[20:37] <ondras> I am not sure I consider this "pretending we have them"
[20:37] <Wes-> the argument you have presented is as follows:
[20:37] <ondras> also, it would be better to speak with kris instead
[20:38] <Wes-> - we have string literals
[20:38] <MisterN> get rid of the new restriction.
[20:38] <Wes-> - therefore wrapping them with new String() is wasteful
[20:38] <Wes-> - therefore new ByteString() should throw
[20:38] <Wes-> this argument does not hold water
[20:38] <ondras> Wes-: the first "therefore" does not exist
[20:38] <Wes-> ?
[20:38] <ondras> there is no implication
[20:38] <ondras> it is generally true that we have string literals
[20:39] <Wes-> Yes, there is. If there were no string literals, instanciating a String object owuld not be wasteful.
[20:39] <ondras> but that is not related to the fact that new String() is considered evil by some
[20:39] <inimino> Wes-: yes, I agree for all those reasons
[20:39] <inimino> if anything, new Bytestring() should be the only one of the two allowed, and ByteString() would throw
[20:39] <Wes-> in this case, when I say string literals, I also include the fact that strings are atoms in the language
[20:39] * Wes- nods @ inimino
[20:39] <ondras> Wes-: if there were no string literals, doing new String() would be the same evil as is now
[20:39] <deanlandolt> Wes-: isn't the problem with new String that typeof new String("") === "object"?
[20:40] <jmerlin> so what's this stuff you're talking about, without having me read these proposals
[20:40] <inimino> that would allow ByteString(), later on, to actually generate a primitive type, presumably with corresponding literal syntax
[20:40] <ondras> jmerlin: http://wiki.commonjs.org/wiki/Binary/D
[20:40] <Wes-> deanlandolt: Right, but if there were no string literals / string atoms, that would not be a problem
[20:40] <jmerlin> "without having me read these proposals" :p
[20:40] <ondras> the trouble imho is that kris is not here right now
[20:40] <deanlandolt> Wes-: true
[20:40] <Wes-> jmerlin: don't read, just skim. ;)
[20:40] <ondras> and I do not want to advocate his opinions
[20:40] <ondras> but we had a long talk about that
[20:41] * Wes- summons KrisK
[20:41] <ondras> and I feel that I understand his motivation(s)
[20:41] <Wes-> I've talked with him at length, too - I just happen to disagree. :)
[20:41] <ondras> :}
[20:41] <ondras> Wes-: anyway - why do you think that absence of string literals implies usage of new String()?
[20:41] <ondras> if we agree that new String() is bad...
[20:42] <Wes-> ondras: without string literals / string atoms, there is no penalty for instanciating an object -- your only choice then is "an object or nothing"
[20:42] <deanlandolt> ondras: without atoms there'd be no such thing as typeof "string" ...every string would be "boxed"
[20:42] <MisterN> ondras: why even compare ByteString to String if there are no literals?
[20:42] <ondras> well
[20:42] <ondras> I was not talking about atoms
[20:42] <ondras> my point was about literals
[20:43] <ondras> e.g. the easy syntactic way
[20:43] <deanlandolt> MisterN: there probably will be...that's the gist of krisk's argument
[20:43] <ondras> of creating a string
[20:43] <Wes-> MisterN: I believe that KrisK believes at some point that TC39 will recommend ByteString adoption where ByteStrings are JS intrinsics (atoms)
[20:43] <MisterN> Wes-: lol?
[20:43] <Wes-> It's not as crazy as it sounds, although I disagree
[20:43] <Wes-> take a look at ES4
[20:43] <ashb> new String() can be very useful
[20:43] <MisterN> didn't some ecma guy say that our binary stuff sucks?
[20:43] <Wes-> That said - there is reason why ES4 died..
[20:43] <Wes-> MisterN: which ecma guy, and when?
[20:44] <ashb> Allen Wilfs...
[20:44] <ashb> the IE guy
[20:44] <deanlandolt> Brenden said it looked nice
[20:44] <Wes-> Oh, right. Allen may have said that, true.
[20:44] <ondras> "my ecma guy is bigger than your ecma guy!"
[20:44] <Wes-> Kris has a longer-term focus than I do for this stuff, I think
[20:45] <MisterN> ondras: but brendan didn't say that new ByteString is bad either
[20:45] <MisterN> :D
[20:45] <inimino> Wirfs-Brock
[20:45] <ondras> anyway, these obscurities are keeping me from implementing some binary/? in v8cgi
[20:45] <MisterN> Wes-: and i want to be able to write both new X and X
[20:45] <ondras> MisterN: :)
[20:45] <Wes-> Do you remember what Allen's objections were? I think they were pretty base-level, i.e. "I hate it lock stock and barrel" rather than quibbling about this-or-that feature
[20:46] <Wes-> ondras: you could implement the intersection of /B and /D pretty safely, assuming you allow new
[20:46] <ashb> all i recall was 'I dont like this'
[20:46] <Wes-> that would get you a lot of functionality
[20:46] <inimino> anyway, I think to design a binary format without looking forwand to eventual standardization would be extremely short-sighted
[20:46] <inimino> it's a well-known limitation in the language with a lot of interest in getting it fixed currently
[20:46] <ondras> Wes-: overall, the atmosphere of "nothing is stable and a completely new proposal can came up any day" is something I dislike
[20:46] <Wes-> Holy, Allen waded into CommonJS threads while I was AFK?
[20:47] <Wes-> (/me reads ~dec 15 2009)
[20:47] <Wes-> ondras: I think my suggested implementation area is pretty safe for you.
[20:47] <ondras> but yes, having at least some binary in v8cgi is necessary
[20:47] <Wes-> ondras: It's very basic, pretty much all stuff that you just *have* to have
[20:47] <ondras> okay
[20:48] <ashb> Wes-: i think he got pulled in, possibly via es-discuss
[20:49] <deanlandolt> Looks like he got pulled in by Mark Miller
[20:49] <deanlandolt> so what are the objections to something like the intersection of binary b and d?
[20:50] <deanlandolt> obviously the new thing would have to get worked out but otherwise, what's the problem with slapping a Level 0 on it and calling it a day?
[20:50] <Wes-> lack of completeness, I'm guessing, but I don't think anybody's formally figured out what features that exactly compromises
[20:50] <Wes-> that said, if it's wide enough, we could call it binary-base and maybe get it a stronger blessing?
[20:51] <Wes-> big deals are ByteString, ByteArray. charAt, charCodeAt, [], decodeToString / toString and constructors
[20:51] <Wes-> I think everything else is gravy
[20:52] <deanlandolt> i hadn't heard anything about the decodeToString / toString thing...what do you mean?
[20:52] <inimino> write it up, node is probably adding some binary stuff soonish too
[20:52] <MisterN> deanlandolt: decodeToString() must assume an encoding, and i think that's something that shouldn't be a side-note
[20:53] <deanlandolt> MisterN: what encoding would you want it to assume?
[20:54] <MisterN> deanlandolt: i wouldn't want to specify a default encoding.
[20:54] <MisterN> deanlandolt: decodeToString(encoding) with an explicit encoding parameter would work
[20:54] <Wes-> deanlandolt: binary/b decodeToString = binary/d toString, they are both a way to turn a ByteString into a String based on a particular charset
[20:54] <deanlandolt> yeah, i'm familiar
[20:54] <Wes-> I still believe, personally, that ByteStrings should be allowed to carry around an encoding property
[20:55] <deanlandolt> but i didn't realize they assumed an encoding
[20:55] <Wes-> this way we can have file streams which yield ByteStrings
[20:55] <inimino> toString seems wrong, as things will call it without an argument
[20:55] <deanlandolt> Wes-: that seems logical
[20:55] <Wes-> and to turn them into Strings for priniting, you only need to tell the system what the encoding is once -- during file open
[20:55] <ashb> inimino: binary/B had that toString called with no argument would return [1,2,3] or similar
[20:55] <ashb> Wes-: if you tell it what the encoding is, why not return Strings directly
[20:56] <inimino> (unless they have such a property of course)
[20:56] <Wes-> ashb: because then you're assuming that I *want* strings!
[20:56] <inimino> ashb: that sounds reasonable, like Arrays
[20:56] <ashb> Wes-: read(5) - 5 bytes or 5 chars? what if the last char is a surrogate?
[20:56] <deanlandolt> if a ByteString had knowledge of it's charset toString would be sensible
[20:57] <deanlandolt> ehh, maybe not
[20:57] <Wes-> ashb: 5 bytes when your stream yields ByteStrings
[20:57] <deanlandolt> but i dig the idea of a bytestring carrying around its encoding with it
[20:57] <ashb> and then how do you convert it ot a string?
[20:58] <Wes-> ashb: If you want to convert your ByteSTrings to Strings, you should be reading a line-at-a-time, or be using a different stream type (i.e. a String stream)
[20:58] <ashb> since hippo's encoding module will die with an error on the uncompleted surrogate
[20:58] <Wes-> everybody's encoding module would
[20:59] <Wes-> it should never be given the opportunity to do that
[20:59] <ashb> i'm missing something then.
[20:59] <Wes-> actually -- Stream.read(5) should probably simply not set the encoding property of the ByteString (if such a prop was defd)
[20:59] <Wes-> only Stream.readln() would
[20:59] <ashb> if you have a separate String stream type, what is the use in yielding ByteStrings+encoding?
[21:00] <MisterN> Wes-: bytestrings with an optional encoding property... that sounds very unclean
[21:00] <Wes-> ashb: well, you can build a String stream type out of it, for starters
[21:01] <inimino> yeah, I don't see the point in having the encoding property
[21:01] <inimino> just let higher layers add that
[21:01] <Wes-> MisterN: Not at all. The programmer is just telling the stream yielder to add encoding information to his yielded lines, so you can do this
[21:01] <inimino> the bare necessity is just a binary type
[21:01] <Wes-> var file = fopen("myfile", "utf8");
[21:01] <Wes-> for (line in file)
[21:01] <Wes-> print(line);
[21:01] <Wes-> instead of
[21:01] <Wes-> var file = fopen("myfile");
[21:01] <Wes-> for (line in file)
[21:01] <MisterN> Wes-: the uncleanness comes from the fact that not all bytestrings will have an encoding defined (at all points)
[21:02] <Wes-> print(line.toString("utf8"));
[21:02] <inimino> anything else added to it makes that less likely to happen
[21:02] <deanlandolt> MisterN: a ByteString wouldn't need to have an encoding...it would just a lot more like a ByteArray at that point
[21:02] <Wes-> MisterN: I don't see that as a problem. If I tell a ByteString that it is utf8, it should be able to remember that.
[21:02] <ashb> fopen("myfile", "utf8") <--- to my ind would yield Strings
[21:02] <MisterN> Wes-: and if you don't tell it what it is, what should it be? ASCII or what?
[21:03] <Wes-> MisterN: Then it's nothing until you tell it!
[21:03] <inimino> Wes-: you can easily add that with a higher level API
[21:03] <MisterN> Wes-: and toString() throws an exception?
[21:03] <Wes-> inimino: Sure, but if you make your ByteString and Stream classes work together like that, you wind up with better code overall. All we're doing is instructing the Stream class about how ByteStrings should be converted to Strings
[21:04] <Wes-> MisterN: If it doesn't know the encoding, then something like that sure has to happen
[21:04] <deanlandolt> toString should probably never throw an exception
[21:05] <Wes-> deanlandolt: That's a good point - what does it do now?
[21:05] <Wes-> deanlandolt: [ 65, 72, 72, 66 ] would be acceptable
[21:05] <deanlandolt> [ByteString 1-]
[21:05] <inimino> Wes-: but you can just as well add something like encodedString = {encoding:"utf8", data:<ByteString>}
[21:05] <deanlandolt> [ByteString 10]
[21:05] <Wes-> oh, right
[21:06] <Wes-> inimino: So you're suggesting a wrapper around ByteStrings, rather than indicating what they contain as ~meta-data
[21:06] <Wes-> that does allow the same solution, I just find it a little wordier
[21:06] <inimino> I think the best chance to get momentum behind something like this is if it's just a simple datatype
[21:06] <inimino> and anything that can trivially be built atop it shouldn't be in it, IMO
[21:06] <inimino> Wes-: yes, precisely
[21:06] <Wes-> FWIW, that's not my first choice, but I could totally get behind that.
[21:07] <ashb> i'm not against a byteStr.encoding property, it just doesn't make much sense as a return from a stream to me right now
[21:08] <ashb> also doing seeking on a character stream is a right pain anyway.
[21:08] <inimino> if you think of ByteStrings as something that's analogous to other primitive types, it would be weird if they had a metadata property
[21:08] <Wes-> ashb: I just don't see the point of fully promoting to string until you absolutely have to
[21:08] <ondras> dtach, zzz
[21:08] <ashb> Wes-: to my mind the IO would be either strings, or binary
[21:08] <Wes-> inimino: that is a good point, although, Strings already have that piece of meta-data implicility (UTF-16 nE)
[21:08] <ashb> and if its not binary, you want strings
[21:09] <ashb> inimino: array's have a .length property
[21:09] <ashb> Classes have a .prototype
[21:09] <inimino> Wes-: yes, implicitly, but they don't have a property that defines use
[21:09] <ashb> its not that odd
[21:10] <inimino> and Arrays aren't primitives
[21:11] <ashb> fine, strings have .length
[21:12] <deanlandolt> heh
[21:12] <deanlandolt> still, it'd be tough to standardize on something requiring non-enumerable properties
[21:13] <ashb> why?
[21:13] <Wes-> it's doable with tracemonkey, rhino, ES5
[21:13] <deanlandolt> because this would need to work in the browser, wouldn't it?
[21:13] <Wes-> anybody know about v8?
[21:13] <ashb> Wes-: it is.
[21:13] <Wes-> deanlandolt: point
[21:13] <Wes-> we're going to have ES3 browsers for at least another year
[21:13] <ashb> and the rest
[21:13] <ashb> what with IE6 still having a stupid share
[21:13] <deanlandolt> ie8 for the _very_ distant future
[21:14] <inimino> ashb: true, strings have .length
[21:14] <Wes-> I don't think we need to worry about ie8
[21:14] <Wes-> orgs adopting ie8 will probably be able to move to ie9
[21:14] <Wes-> ie6 is the real problem browser
[21:15] <deanlandolt> that's true, but the rest will be on 6
[21:15] <deanlandolt> yeah...indeed...but between those three versions that will be a huge percentage of marketshare for some time
[21:15] <deanlandolt> it'd be great if something like chromeframe took off, but i'm skeptical
[21:16] <Wes-> I see ie6 as the real problem. I'm pretty confident ie9 will be es5. And I see ie9 killing ie8.
[21:16] <Wes-> what we need is an unpatchable security vuln in ie6
[21:16] <ashb> deanlandolt: i dont see chromeframe taking off - if you could install that, couldn't you just use non IE or a upgrade IE instead?
[21:16] <deanlandolt> ie9 could very likely be fully es5 compliant
[21:17] <Wes-> it's already got a JIT bla de blah
[21:17] <deanlandolt> ashb: no, not if you're mandated by your org to use ie
[21:17] <deanlandolt> you can install it in userland
[21:17] <Wes-> they are doing real, active work on it
[21:17] <ashb> ah
[21:17] <Wes-> anybody thought about CommonJS in flash
[21:17] <Wes-> ?
[21:17] <deanlandolt> ashb: iirc they did some serious contortions to make that possible
[21:17] <Wes-> man, my model M is wearing out!
[21:17] <ashb> oh noes!
[21:26] <Wes-> FWIW http://old.nabble.com/Re%3A-Binary-Data---possible-topic-for-joint-session-tt26229087.html#a26229087
[21:29] <jmerlin> ondras: you ever get weird access violations when your scripts execute a function template to create a native object?
[21:29] <jmerlin> the access violations being inside of v8's internal code
[21:30] <Wes-> jmerlin: is it possible you're hitting DEP? (I don't know enough about v8 arch to comment fully)
[21:30] <jmerlin> DEP?
[21:31] <Wes-> data execution prevention
[21:31] <jmerlin> i don't think so...
[21:31] <jmerlin> Unhandled exception at 0x01169c1f in shell.exe: 0xC0000005: Access violation reading location 0x6c6c7575.
[21:31] <jmerlin> it seems to always be under the Script::Compile call
[21:31] <Wes-> that smells more like programmer-pointer-error, tough to say though
[21:32] <jmerlin> well i compile the same code 50 times before, but on the 51th time it crashes
[21:32] <jmerlin> works fine doing other things too, very weird
[21:32] <Wes-> Hmm, maybe stray gamma rays are modifying your program and introducing bugs when you're not looking
[21:33] <jmerlin> always in NewFunctionFromBoilerplate
[21:38] <jmerlin> http://code.google.com/p/v8/issues/detail?id=555#c5
[21:38] <jmerlin> looks like it's a known bug
[21:38] <Wes-> Bummer. :(
[21:38] <jmerlin> makes me very unsettled using v8, if it's so shaky i can't trust that my code isn't going to randomly go *BOOM*
[21:38] <Wes-> can you just roll back maybe to a stable chrome release snapshot?
[21:39] <jmerlin> this is their stable lol
[21:39] <Wes-> lol
[21:40] <Wes-> well, fwiw, I have found bleeding-edge spidermonkey to be very stable over the last ~18 months
[21:40] <jmerlin> tracemonkey?
[21:41] <MisterN> yes tracemonkey
[21:41] <Wes-> It wasn't that 18 months ago, but it is now. :)
[21:41] <MisterN> Wes-: fp on the other hand has a few weird crashes :/
[21:42] <Wes-> ah, well, that's life with C++, y'know? ;
[21:42] <Wes-> ;
[21:42] <Wes-> FRIG!
[21:42] <Wes-> No more right paren!
[21:42] <jmerlin> well this is very reproducible
[21:42] <jmerlin> for(var i=0;i<10000;i++){var c = new Array();}
[21:43] <jmerlin> compile/execute that about 4-5 times in v8 and it crashes
[21:43] <jmerlin> consistently
[21:43] <Wes-> that's insane
[21:43] <jmerlin> let me try it in chrome, i'd not be surprised if it crashed the tab'
[21:47] <jmerlin> works in chrome, must be my compiling code?
[21:57] <jmerlin> i hate it when bugs are in my code :(
[21:59] <Wes-> jmerlin: try this: http://hazelwoodsoapcompany.com/bug_be_gone_1.html
[22:03] <jmerlin> :)
[22:03] <jmerlin> worked like a charm, thx!!
[22:08] <jmerlin> what's worse
[22:08] <jmerlin> is that the shell code google provided that mine is based on doesn't have this issue :(
[22:08] <jmerlin> looks like i'm into some fun diff debugging tonight
[22:10] <Wes-> jmerlin: divide and conquer
[22:11] <jmerlin> yup, the code seems isolated to a single function so it *shouldn't* be hard
[22:11] <jmerlin> i have an idea of what it is, but we shall see

 

 

Logs by date :