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

2009-12-18:

[12:00am] <the_undefined> kriszyp> really?
[12:00am] <kriszyp> yeah
[12:00am] <the_undefined> kriszyp> the first gist mutates the promise value
[12:01am] <kriszyp> with functional promises it doesn't mutate the promise return from sys.exec, the addCallback returns a new promise that receives the value from the callback
[12:01am] <kriszyp> so the first gist works fine with functional promises
[12:01am] <the_undefined> kriszyp> interesting
[12:01am] <kriszyp> and actually, the third gist is necessary with mutating promises if you wanted to protect a promise from mutation, with functional promises you could just always use the first gist
[12:02am] <the_undefined> kriszyp> what about the error handling?
[12:02am] <the_undefined> will the addCallback() propagate errors from the parent promise?
[12:02am] <kriszyp> the error handling works the same
[12:02am] <kriszyp> yes
[12:02am] <the_undefined> alright, that makes the whole thing a lot more attractive right away
[12:03am] <the_undefined> I did not get that from the wiki page
[12:03am] <kriszyp> I probably wrote the proposal poorly
[12:03am] <the_undefined> well, it's just very short
[12:03am] <the_undefined> alright I like that, lets move on
[12:04am] <the_undefined> then() wants you to pass in 3 functions at once
[12:04am] <the_undefined> I understand you can skip any argument
[12:04am] <kriszyp> yeah
[12:04am] <the_undefined> I think that's very limited
[12:04am] <the_undefined> now you did they people are free to extend
[12:05am] <kriszyp> yeah
[12:05am] <the_undefined> but why ship something so limited that you almost have to extend it to be useful
[12:05am] <the_undefined> I really like addBoth() from dojo for examplke
[12:05am] <the_undefined> makes tons of sense to me
[12:05am] <kriszyp> you mean it is hard to provide the same function to handle both success and failure?
[12:06am] <the_undefined> kriszyp> yip
[12:06am] <kriszyp> and remember it is a spec, not really shipping anything, just try to achieve a minimal level of interoperability between projects... but I am not opposed to adding other functions to the spec
[12:06am] <the_undefined> I just like dedicate functions for adding different listeners
[12:06am] <the_undefined> cool
[12:07am] <kriszyp> and still is not too painful, IMO:
[12:07am] <kriszyp> async().then(handler, handler);
[12:07am] <kriszyp> function handler(){
[12:07am] <kriszyp> ...
[12:07am] <kriszyp> });
[12:07am] <kriszyp> but having addBoth isn't a big problem for me
[12:08am] <the_undefined> ok
[12:08am] <the_undefined> then lets not debate that for now either
[12:08am] <the_undefined> the last thing I disagree with is the progress handler
[12:08am] <the_undefined> I think that really goes too far for a minimal spec
[12:09am] <the_undefined> I know its useful, but it seems it only is for a small sub-set of the promises people work with
[12:09am] <kriszyp> hmm, but is it disruptive at all?
[12:09am] <the_undefined> I think there should be another API that describes async streams or event machines
[12:09am] <kriszyp> it seems to be so purely additive as to be easily ignored by promises that don't do progress
[12:09am] <the_undefined> * state machines
[12:10am] <the_undefined> hm
[12:10am] <the_undefined> ok
[12:11am] <kriszyp> if it placed any type of normative burden on promise producers or consumers I would leave it out...
[12:11am] <the_undefined> how do I report the progress to a promise?
[12:11am] <kriszyp> but it really doesn't seem to
[12:11am] <kriszyp> well, that is up to the promise implementor, the one I wrote for narwhal has a progress() function that you can call
[12:12am] <kriszyp> but a promise certainly doesn't have to have any type of progress
[12:12am] <kriszyp> I think the value is when you have an existing API defined around promises, and then you later realize that there is UI component that would really love to be able to provide feedback to a user on the progress of an operation, you can easily add in progress events without breaking the API
[12:13am] <RayMorgan_ is now known as RayMorgan.
[12:14am] <the_undefined> kriszyp> well, wouldn't you be able to do this just the same by passing the progress handler to the function creating the promise?
[12:15am] <kriszyp> you could, but that is technically an API change and if the promise is going through different layers that might not be code that can be changed...
[12:15am] <kriszyp> and it seems nice to have the progress actually tied to the promise object that it is related to
[12:16am] <the_undefined> kriszyp> ok. I don't mind it so much that I'm against it, but I'd rather see it as an optional addition to the spec
[12:16am] <kriszyp> now if an API is really all about multiple events, than promises is the wrong choice, I certainly admit that. but if progress events are more just an informative addition to a central single operation...
[12:16am] <kriszyp> I am not sure how to make it more optional, it is already an optional argument
[12:17am] <kriszyp> Is there a way to make it more optional?
[12:17am] <kriszyp> I could make it clear that promises do not need to support or utilize progress events
[12:17am] <the_undefined> kriszyp> yeah - just make it clear that it is an optional part to the spec. I.e. you don't have to implement it to be compliant
[12:17am] <the_undefined> I think
[12:18am] <kriszyp> ok, you are right, that is a good suggestion
[12:18am] <the_undefined> I might actually push for it to be in node
[12:18am] <the_undefined> but that's because I have an app that could benefit from it
[12:18am] <the_undefined> and I'll admit to my evil motives
[12:19am] <kriszyp> heh, I use promises pretty extensively too, so I have motives as well
[12:19am] <the_undefined> the main thing to me really is the ease of composing new promises and that seems to be something we agree on
[12:20am] <the_undefined> I guess the only thing left is the exception handling
[12:20am] <kriszyp> yeah, that is very important indeed
[12:20am] <kriszyp> oh yeah
[12:20am] <the_undefined> your suggestion of a timeout seems whacky
[12:20am] <kriszyp> I know
[12:20am] <kriszyp> and exceptions can be a pain
[12:20am] <the_undefined> I had the idea of being able to "toggle" a trycatch mode on a promise
[12:20am] <the_undefined> when creating it
[12:20am] <kriszyp> hmm, thats interesting
[12:21am] <ashb> hmmm?
[12:21am] <ashb> wow lots of backscroll. quick summary?
[12:21am] <the_undefined> that would however require to use setTimeout(function(){}, 0) when firing the promise
[12:21am] <the_undefined> (in case the result is immediately available, lets say due to cache)
[12:22am] <kriszyp> you mean the timeout would require a setTimeout? yeah
[12:22am] <the_undefined> otherwise the consumer couldn't decide whether or not invoke the try..catch mechanism
[12:22am] <the_undefined> kriszyp> no, I mean the consumer being able to always decide on the error handling strategy for callbacks
[12:22am] <kriszyp> ashb, just discussing commonjs promises vs dojo deferred style api (for use in node)
[12:23am] <the_undefined> I assume your promise proposal also plans on memorizing the results if no callbacks are attached right away, right?
[12:23am] <kriszyp> right
[12:24am] <kriszyp> and so if the promise "fails"... what are the options that a consumer would want to consider?
[12:24am] <the_undefined> ok, I guess ignore my comment about setTimeout(), I think I was getting off track there
[12:24am] <kriszyp> or is this about how the exceptions in the callback are handled?
[12:24am] <the_undefined> kriszyp> yes
[12:24am] <the_undefined> exceptions that are being thrown
[12:24am] <the_undefined> dojo catches them automatically which I think is bad in most cases
[12:24am] <the_undefined> (but possibly good in some)
[12:25am] <kriszyp> so its less about an intentional promise failure, and more about incidental exceptions in callback handlers...
[12:25am] <the_undefined> yeah
[12:25am] <kriszyp> yeah, thats a good point
[12:25am] <the_undefined> dojo catches those
[12:25am] <kriszyp> right
[12:25am] <the_undefined> I think they should not be caught unless specifically asked for
[12:25am] <ashb> you have to catch them dont you, or rather, where would they get thrown form if you dont catch them?
[12:25am] <the_undefined> for node we decided on not do any catching at all
[12:26am] <the_undefined> as it just gets too messy
[12:26am] <kriszyp> do you still have a way to get into the error callback chain?
[12:26am] <kriszyp> return an instance of Error, I presume?
[12:26am] <the_undefined> kriszyp> yes
[12:26am] <kriszyp> (if you are porting dojo code)
[12:26am] <ashb> i assum the event loop will have to catch/silence the errors still tho?
[12:26am] <RayMorgan_ is now known as RayMorgan.
[12:26am] <the_undefined> that would be the only way, or by invoking Promise.errback right away
[12:27am] <kriszyp> thats interesting, that might be a good idea the_undefined
[12:27am] <the_undefined> ashb> in node we crash the process on all exceptions, but we have a process.addListener('uncaughtException') thingy
[12:27am] <ashb> oh right.
[12:27am] <the_undefined> its a bit of a hack (I'm to blame), but its useful for some people
[12:28am] <the_undefined> kriszyp> what was your plan for dealing with exceptions that are being *thrown* so far?
[12:28am] <the_undefined> did you plan on doing any try..catching ?
[12:28am] <kriszyp> well, I'll concede on the try/catch thing, it sounds like you have a good idea. I might scratch my head on that a bit more, but catching all errors is definitely not central to my goals of promises
[12:29am] <kriszyp> yeah, I was planning catching errors and sending them to the error callback like dojo does
[12:29am] <ashb> also depends what you are doing. a browser like setTimeout should probably catch since thats expected
[12:31am] <kriszyp> the_undefined> you currently don't have any switch/option for choosing try/catch or not, right? none of the callback errors are caught, right?
[12:31am] <the_undefined> kriszyp> I guess to me you should be able to work with promises like you can with functions, which includes try..catching errors. However, with asynchronous functions (promises) that's very hard so I do think one should be able to do something similar by the means of promises
[12:31am] <the_undefined> kriszyp> no, right now we have no switch
[12:31am] <inimino> kriszyp> I'm glad to see someone coming out against mutating promises!
[12:31am] * inimino looks at the mailing list
[12:31am] <the_undefined> actually thinking more about it, I wonder if the "errback" should be used for anything BUT exceptions
[12:31am] <the_undefined> I mean functions can only return 1 value
[12:32am] <the_undefined> with promises that have callbacks and errbacks, we actually make them return 2 different kind of values
[12:32am] <inimino> I think the only benefit is a minor syntactic convenience IMO
[12:32am] <the_undefined> inimino> right
[12:32am] <the_undefined> but they complicate things
[12:32am] <the_undefined> I think to do things properly, we would need 3 types of callbacks
[12:32am] <the_undefined> success, error, exception
[12:32am] * inimino is still reading the backscroll
[12:32am] <kriszyp> well, if we are following the principle of promises being the non-blocking counterpart to functions, we need a counterpart to errors
[12:33am] <the_undefined> kriszyp> right
[12:33am] <the_undefined> kriszyp> but functions don't have "errors" as a concept
[12:33am] <the_undefined> only return values
[12:33am] <the_undefined> or exceptions
[12:33am] <kriszyp> (even if the callback functions uncaught errors aren't directed to the error callback)
[12:33am] <kriszyp> well, it is one of the two ways to exit a function
[12:33am] <kriszyp> (thrown exception)
[12:34am] <kriszyp> or returning
[12:34am] <the_undefined> kriszyp> right, but with the promise API we are introducing a 3rd type
[12:34am] <the_undefined> which I think is wrong
[12:35am] <kriszyp> it almost sounds like you are arguing that all return values (including instances of Error) should go to the callback handler, and thrown errors should go the error handler
[12:35am] <kriszyp> but I know you are not saying that
[12:35am] <the_undefined> I am saying that
[12:35am] <the_undefined> why, what's wrong with that?
[12:35am] <kriszyp> but of course the callback returns -> callback handler, callback throws -> error handler is based on following the principle of promises as async functions
[12:36am] <kriszyp> well, you said you didn't want thrown errors to go the error handler, but rather just be uncaught, I thought
[12:36am] <kriszyp> or are you saying that they should be uncaught *and* go to the errback handler?
[12:38am] <the_undefined> sorry, I'm confusing. Yes, over at the nodejs mailing list we decided to not do any error catching for our promise callbacks
[12:38am] <the_undefined> But in here I'm starting to think that maybe we should
[12:38am] <the_undefined> and make a clear distinction between errors thrown and errors returned
[12:39am] <the_undefined> throw Error-> errback, return Error -> callback
[12:39am] <the_undefined> I'm just thinking out loud here
[12:39am] <kriszyp> having errors returned go to the error handler is a little sketchy IMO
[12:39am] <the_undefined> but it seems to closely mirror the behavior of functions
[12:39am] <the_undefined> kriszyp> right
[12:39am] * kriszyp wonders how he implemented it narwhal...
[12:40am] <ashb> promises dont have any inherit reactor/ready to be run do they?
[12:40am] <kriszyp> ashb, that is another good question
[12:40am] <kriszyp> should callbacks go on the event queue?
[12:40am] <ashb> they are just an api for what to do when the event is ready, right?
[12:40am] <kriszyp> do callbacks go on the event queue in node?
[12:40am] <inimino> I still haven't seen any convincing reason why promises need to catch exceptions at all
[12:41am] <kriszyp> and in narwhal, returning an Error goes to the callback (not the error handler)
[12:41am] <inimino> I think people who want that should present some use cases
[12:41am] <kriszyp> (there are no return value type checks for errors)
[12:41am] <the_undefined> inimino> the reason is that you can catch errors in regular functions, so you should be able to catch them in their async counterparts as well
[12:41am] <ashb> returning an Error seems like a really odd thing to do
[12:41am] <RayMorgan_ is now known as RayMorgan.
[12:41am] <inimino> the_undefined> right, but JavaScript in the browser doesn't have any such thing either
[12:42am] <the_undefined> inimino> we are not talking about leaving the scope of JavaScript here, its merely how to use JavaScripts semantics to model async function calls
[12:42am] <inimino> the_undefined> e.g. the browser doesn't give you a setTimeout(f,1000,tryCatchHandler) API
[12:42am] <kriszyp> the_undefined> do you know if callbacks go on the event queue in node or are they executed immediately?
[12:43am] <the_undefined> kriszyp> right now, immediately
[12:43am] <kriszyp> k
[12:43am] <inimino> I think "async function calls" is a stretched metaphor, events is a much better one
[12:43am] <the_undefined> inimino> I think its a different metaphor, one we are planning to improve on as well
[12:43am] <kriszyp> events is good metaphor for events, promises are different
[12:44am] <the_undefined> kriszyp> so if callbacks would be queued, it would be easy for the consumer to decide if errors should be caught, right?
[12:45am] <inimino> I see a promise as nothing more that a convenient bundle of event handlers
[12:45am] <kriszyp> hmm, I don't know how it affects error handling
[12:46am] <kriszyp> inimino> the key aspect of a promise is that it represents something that a singular conclusions. Events often happen multiple times
[12:46am] <nrstott> inimino, there's a difference between a promise and event handlers in that a promise can already be resovled and return the same value as when it was first resolved
[12:46am] <kriszyp> Events can drive the conclusion of a promise
[12:46am] <nrstott> a promise is a wrappr around an event
[12:47am] <nrstott> promises imo should be impemented ontop of an observable module (*cough* mine *cough*) or pubsub module if you prefer to call it that
[12:47am] <inimino> nrstott> in Dojo promises are like that, in node they aren't
[12:48am] <inimino> (yet, anyway)
[12:48am] <inimino> maybe there's a terminology issue
[12:48am] <nrstott> inimino, what are they in node
[12:49am] <the_undefined> anyway, I'll get some sleep now, it's late over here. Thanks for the insights kriszyp, I'm certainly more interested in agreeing on a common API now. I will let you know once I have thought through some of the things discussed a little more
[12:49am] <nrstott> someoen was telling me that in node thye call them "deferreds" but that's the same thing as a promise in my lingo
[12:49am] <nrstott> promise, deferred, and future are all the same to me...
[12:49am] <the_undefined> nrstott> we call them Promises in node too
[12:49am] <inimino> nrstott> in node a promise is an object, you can attach event handlers to it (for the 'success' and 'error' events), but you have to do that before you return to the event loop
[12:49am] <kriszyp> thanks for talking, the_undefined
[12:49am] <the_undefined> right now they are a sub-class of event emitters
[12:49am] <the_undefined> but I think that's wrong
[12:49am] <nrstott> inimino, ok, that's not what id call a 'classical' promise
[12:50am] <nrstott> what youve gt it some sort of eventy promisy thing then
[12:50am] <the_undefined> and ryan (node's author) thinks they are a leaky abstraction as well
[12:50am] <kriszyp> nrstott> I think it is best to consider them synonyms
[12:50am] <inimino> nrstott> once an event is sent, the value of it is not held onto
[12:50am] <ashb> "deferreds" is what python/twisted calls them istr
[12:50am] <inimino> yes, it seems a non-optimal middle ground between "classical" promises and something else
[12:50am] <the_undefined> anyway, gn8
[12:50am] <the_undefined> kriszyp> was nice talking to you as well
[12:50am] <kriszyp> I don't think there is any real acedemic literature that provides a useful distinction, they just have had different names in different projects
[12:50am] <the_undefined> see you guys waround
[12:51am] <nrstott> inimino, are there advantages that you guys don't want to lose from your approach?
[12:51am] <kriszyp> talk to you later
[12:51am] <ashb> defered, promise, future are the names i've heard
[12:51am] <nrstott> ashb, me too, and they all mean the same thing to me
[12:51am] <ashb> yeah
[12:51am] <ashb> largely
[12:51am] <inimino> nrstott> I wouldn't be the guy to ask about that, but I'm under the impression Ryan is open to API changes
[12:52am] <nrstott> inimino, ok, fair enough
[12:52am] <inimino> (assuming something unambiguously better comes along)
[12:52am] <nrstott> I have never heard anyone call a promise something you attach events to that doesn't save the result of the event when it first is available...
[12:52am] <nrstott> so the advantage would be not confusing people ;0
[12:53am] <inimino> yes, I agree that either the API or the name needs to change
[12:53am] <nrstott> excellent
[01:41am] <kriskowal> ashb> plz make a concrete proposal for your external dependency idea. i'm not sure what you're shooting for.
[01:42am] <ashb> kriskowal> ext_depends> ['cmake', 'libmysql']
[01:42am] <ashb> nothing more than that
[01:43am] <kriskowal> i'd be chill with externalDependencies
[01:44am] <kriskowal> or {"external"> {"dependencies"> []}} if you soo don't want to argue about case conventions
[01:44am] <ashb> u_c is just a habit for me is all
[01:44am] <ashb> i dont actually like camelCase all that much
[01:44am] <kriskowal> yeah. lots of snake_case leaking from ruby and c
[01:45am] <kriskowal> i don't either. consistency
[01:45am] <ashb> yeah.
[01:45am] <ashb> consistency by osmosis!
[01:45am] <ashb> i shall provide under_score versions of all the methods
[01:45am] <kriskowal> weak
[01:45am] <ashb> >_>
[01:45am] <ashb> kriskowal> while you are here. the interoperablejs test suite
[01:46am] <ashb> anyone run it much?
[01:46am] <kriskowal> it's part of narwhal's continuous integration, so yeah.
[01:46am] <kriskowal> actually caught a bug with it this week.
[01:46am] <ashb> so i had to make some changes to get it running on hippo
[01:46am] <ashb> basicaly centered around print
[01:46am] <ashb> http://github.com/ashb/interoperablejs/commits/master
[01:46am] <kriskowal> aye.
[01:47am] <ashb> http://github.com/ashb/interoperablejs/commit/5bb7e66ef9ba0b38ab12167eec4b00ce8ef93a17#diff-35
[01:47am] <kriskowal> yeah, what with the test suite being lower level than the modules?
[01:47am] <ashb> yeah, so it uses a free print() function if there is one. tho actually that should be typeof function
[01:47am] <kriskowal> the trouble is that it gets chicken-egg
[01:47am] <kriskowal> ah
[01:48am] <ashb> and if there isn't one it falls vack to require('system') which is very chicken-egg, yes
[01:48am] <kriskowal> i think that'd be fine though, in terms of progressive enhancment. early implementations could just inject print, while others would fall back to using the system or io
[01:49am] <kriskowal> but require("system").print didn't make it to the spec.
[01:49am] <kriskowal> and require("system").stdio depends on the IO spec, which isn't ratified.
[01:49am] <kriskowal> and probably won't be until after binary
[01:51am] <ashb> true.
[01:51am] <ashb> i think everyone who has system has .stdout.print
[01:51am] <ashb> the other things i fixed was no more var print in the program.js's
[01:51am] <ashb> (cos that messed up the test.print detection)
[01:52am] <kriskowal> ah, yeah
[01:52am] <ashb> or caused it to loop
[01:52am] <ashb> since in flusspferd at least, the main program is run in the global scope
[01:52am] <ashb> (at least for now. i'm not sure i'm happy with that)
[01:52am] <kriskowal> we need to move the suite into the commonjs repo
[01:52am] <kriskowal> it's drifted in narwhal too
[01:53am] <ashb> ah is there a commonsj one?
[01:53am] <kriskowal> the narwhal copy doesn't have var print
[01:53am] <kriskowal> we provide a "print" free variable.
[01:53am] <ashb> any other changes?
[01:53am] <kriskowal> i don't recall
[01:53am] <ashb> as it stands flusspfed passes all the compliance tests and a good chunk of the others
[01:54am] <kriskowal> yeah.
[01:54am] <ashb> some are obv testing narwhal specific features (or at least currently unspeced)
[01:55am] * ashb goes back to writing mongodb docs
[01:55am] <kriskowal> ah, well. print is narwhal-specific.
[01:55am] <kriskowal> what else is not standard?
[01:55am] <ashb> flusspferd has print top level too fwiw
[01:55am] <ashb> um, require.isLoaded, exports object being an instance of a Module class
[01:55am] <ashb> few other things
[01:56am] <kriskowal> oh, those aren't in the compliance suite.
[01:56am] <kriskowal> i haven't run those on narwhal ever
[01:56am] <ashb> oh all of compliance passes
[01:56am] <ashb> i meant the other folders
[01:56am] <kriskowal> man, forgot i wrote those. those were ideas.
[01:56am] <ashb> wasn't sure if they were still run
[01:56am] <ashb> so i just made the same fixed i did elsewhere
[01:56am] <kriskowal> i should update those and use them, actually.
[01:57am] <kriskowal> but no pretense that they should end up in the commonjs test suite. they're definitely not standard.
[01:58am] <kriskowal> it would be nice to eventually standardize all the stuff we need to make the entire module test suite *scaffold* run on all systems.
[01:58am] <ashb> oh extensions/id should be there now
[01:58am] <kriskowal> http://github.com/280north/narwhal/blob/master/tests/commonjs/modules/all-tests.js
[01:58am] <ashb> tho the test could do with expanding a bit
[01:59am] <kriskowal> we don't have a modules/1.1 suite yet. that should be made.
[01:59am] <ashb> yeah
[01:59am] <ashb> thoe it would be 1.2 with the module.setExports wouldn't it?
[01:59am] <kriskowal> if we ratify it, probably
[01:59am] <ashb> guess a 1.1 test suite doesn't hurt even if we do
[01:59am] <kriskowal> aye
[01:59am] <kriskowal> incremental
[03:59am] <ducktype> hi ho
[03:59am] <ducktype> i'm drunk
[04:00am] <ducktype> gnight ashb
[11:01am] <ryah_away is now known as ryah.
[11:06am] <ryah is now known as ryah_Away.
[2:48pm] <ryah_Away is now known as ryah.
[4:29pm] <ryah is now known as ryah_Away.
[4:52pm] <nrstott> is anyone using "inspec", the BDD module?
[4:52pm] <ashb> not heard anyone talk much about it
[4:53pm] <nrstott> ive talked to the owner a couple of times via github and got him to fix the most blatnat bug i saw which was that error msgs weren't shown for failng tests
[4:53pm] <nrstott> now it seems pretty good
[4:53pm] <nrstott> it looks like a ton of time was put into writing it, then no one used it ;0
[4:53pm] <ashb> link?
[4:53pm] <nrstott> http://github.com/aq1018/inspec
[4:54pm] <ashb> oh i should use that - he writes stuff with flusspferd
[4:54pm] <nrstott> oh, you know him?
[4:54pm] <nrstott> I haven't seen him in this channel or on the mailing list
[4:54pm] <ashb> he's come into #flusspferd a few times
[4:54pm] <ashb> http://github.com/aq1018/jsorx
[4:54pm] <nrstott> that's cool
[4:54pm] <nrstott> he's obviously a good coder
[4:57pm] <colinclark_ is now known as colinclark.
[4:59pm] <nrstott> im going to try to use inspec
[5:00pm] <nrstott> I really want a BDD framework like that
[5:00pm] <nrstott> I can't imagine why it took so many lines of code to make it happen in JS though, inspec is h-u-g-e ;0
[5:00pm] <nrstott> but it seems to work
[5:00pm] <ashb> heh
[5:00pm] <ashb> i was thinking of a simple module that does somethinkg like
[5:01pm] <ashb> check(x).is(y, "x = y").isnt(z, "x != z")
[5:01pm] <nrstott> ashb, write it plz ;0
[5:01pm] <nrstott> bleh has to have nested describe blocks
[5:01pm] <ashb> (slightly silly example)
[5:01pm] <ashb> you probably wont chain things very often tho
[5:01pm] <ashb> well check(x).isDefined().has("y", "x.y exists")
[5:01pm] <ashb> might be a more sensible example
[5:02pm] <? ashb goes back to markdown
[5:02pm] <nrstott> why not assert.that(x).isDefined()
[5:02pm] <ashb> could be. but just not on the assert module cos it snot stnadard and wont every be
[5:02pm] <ashb> (or every need to be)
[5:03pm] <nrstott> well you could have a module that could monkey patch it
[5:03pm] <nrstott> that's what i was thinking
[5:04pm] <ashb> just make it another module
[5:04pm] <ashb> that was why the AssertionError was defined
[5:04pm] <ashb> so that things can exist in seperate modules
[5:05pm] <nrstott> when i see this in node code> process.mixin(....) what is it doing? is that how they mix stuff into their global scope?
[5:05pm] <ashb> yeah
[5:47pm] <colinclark_ is now known as colinclark.
[6:01pm] <ashb> testRquires or testDepends
[6:01pm] <ashb> modules you need to test (and buildX too) but dont need at runtime
[6:01pm] <ashb> worth adding?
[6:25pm] <ryah_Away is now known as ryah.
[6:32pm] <ashb> 17:01 < ashb> testRquires or testDepends
[6:32pm] <ashb> 17:01 < ashb> modules you need to test (and buildX too) but dont need at runtime
[6:32pm] <ashb> 17:01 < ashb> worth adding?
[6:32pm] <ashb> kriskowal> ^^
[6:32pm] <ashb> (sorry to jump you)
[6:32pm] <kriskowal> aaah
[6:33pm] <kriskowal> are we talking about package.json?
[6:33pm] <ashb> yeahn
[6:56pm] <ashb> hmmmm - seeming to have trouble sending to commonjs list
[6:58pm] <zumbrunn> ashb> why? ...a message from you just came through 3 minutes ago
[6:58pm] <ashb> one before that bounced
[6:58pm] <ashb> delivery error
[6:58pm] <zumbrunn> hmm
[7:59pm] <Nathan_ is now known as nrstott.
[8:48pm] <ashb> do other platforms have anything like //@line 1 "my-file.js"
[8:48pm] <ashb> https://developer.mozilla.org/en/JS_SetOptions
[8:48pm] <ashb> JSOPTION_ATLINE
[8:49pm] <ashb> ryah> ^^
[8:49pm] <ashb> tlrobinson> ^^
[9:02pm] <kriskowal> ashb, i suspect that javascriptcore supports it
[9:03pm] <ashb> i'm not sure if i should turn that flag on or bind a version of eval that takes filename and linenumber too
[9:19pm] <ashb> inimino> found a bug!
[9:19pm] <inimino> oh?
[9:20pm] <ashb> evilstreak> explain
[9:22pm] <evilstreak> I have a really mangled tree as output!
[9:23pm] <ashb> pastie already!
[9:23pm] <ashb> >_>
[9:23pm] <evilstreak> working on it
[9:23pm] <inimino> oh, scary
[9:23pm] <inimino> got a test case?
[9:23pm] <evilstreak> keep your knickers on
[9:23pm] <evilstreak> (ashb, not inimino
[9:24pm] <inimino> I'll leave mine on anyway
[9:24pm] <evilstreak> http://pastie.org/749194
[9:25pm] <evilstreak> the \## Lists ## thing is just to stop Pastie making it a section, that slash isn't actually there
[9:25pm] <inimino> oh, that's not a tree
[9:25pm] <inimino> that's a failure result
[9:25pm] <evilstreak> how do I interpret it?
[9:25pm] <evilstreak> why so many empty arrays?
[9:25pm] <evilstreak> why [, , , , ,...] ?
[9:26pm] <inimino> you can't yet, there's an API for it but I haven't exported it
[9:26pm] <inimino> and it needs some tweaks for the current result table format
[9:26pm] <ashb> is there no context on where the error happend yet?
[9:26pm] <inimino> basically those are all the rules that it tried and the positions where it tried them
[9:26pm] <ashb> there dont seem to be any positions
[9:26pm] <inimino> [false, 0, [...]]
[9:27pm] <inimino> 0 is the position at which the whole thing failed
[9:27pm] <inimino> in this case...
[9:27pm] <ashb> a line can be anything tho...
[9:27pm] <inimino> Document succeeded at position 0, because Block matched 0 times
[9:28pm] <inimino> Block, Para, and Line all failed at that same position
[9:28pm] <inimino> that's what "[[true, 0, []], false, false, false]," tells me
[9:28pm] <ashb> How would line fail?
[9:28pm] <evilstreak> surely Line should match any line?
[9:29pm] <ashb> so longh as it has 1 character on it
[9:29pm] <inimino> at position 9, Newline failed
[9:30pm] <ashb> oh. is "\n" not doing the right thing?
[9:30pm] <ryah> ashb> ?
[9:31pm] <ashb> ryah> 19:48 < ashb> do other platforms have anything like //@line 1 "my-file.js"
[9:31pm] <inimino> I'm not sure why that would fail there
[9:31pm] <ryah> no
[9:31pm] <ashb> k
[9:31pm] <inimino> can I see the generated parser?
[9:31pm] <ashb> i will go for plan b) of binding an eval that takes a filename and line no into JS space instead
[9:32pm] <inimino> maybe there's a bug in handling "\n" in string literals
[9:33pm] <evilstreak> inimino> http://pastie.org/749209
[9:36pm] <inimino> ok, yeah, that's a bug
[9:36pm] <inimino> it's matching those as literal strings
[9:37pm] <inimino> I guess I should either document that or interpret them as in C
[9:37pm] <ashb> yeah
[9:39pm] <evilstreak> meanwhile rewrite to be> Newline <- [ U+000A ] / ....
[9:39pm] <evilstreak> ?
[9:39pm] <inimino> in the meantime you can use Newline ? [U+000D][U+000A] / [U+000D U+000A]
[9:39pm] <inimino> yeah
[10:46pm] <ashb> inimino> negative lookahead match?
[10:48pm] <inimino> ashb> hm?
[10:49pm] <ashb> http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html#op-unm
[10:49pm] <inimino> you mean what's the syntax?
[10:49pm] <ashb> yeah
[10:49pm] <inimino> !( ... ) for negative, &( ... ) for positive
[10:49pm] <ashb> ta
[10:50pm] <inimino> the () are required for now
[10:50pm] <ashb> k
[10:52pm] <ashb> and how to match EoF?
[10:52pm] <ashb> !([^])
[10:52pm] <ashb> i guess?
[10:57pm] <inimino> yes
[10:57pm] <inimino> ashb> though often it's not necessary, the parser will test at the end that all the input was consumed
[10:58pm] <ashb> yeah, but it means the new line at the end of a para is optional
[10:58pm] <ashb> Chars ( NewLine / EoF )
[10:58pm] <inimino> ah
[10:58pm] <inimino> yeah
[11:07pm] <evilstreak> inimino> are there any quantity modifiers other than * and +?
[11:12pm] <inimino> yeah, {M,N}
[11:12pm] <inimino> http://boshi.inimino.org/3box/PEG/PEG.peg
[11:13pm] <inimino> that's the actual grammar, though the generated parser in the release is a little behind that
[11:15pm] <inimino> http://boshi.inimino.org/3box/blog/post.peg also might be similar to what you're doing, though it's by no means actual markdown
[11:16pm] <ashb> thanks
[11:20pm] <evilstreak> inimino> I think it does, but just to check, I can have {3,} and {,6} and the like, right?
[11:21pm] <ashb> no not currently {m} or {m,n}
[11:21pm] <inimino> I think so, but I should probably double-check
[11:21pm] <inimino> ah, that's right
[11:21pm] <ashb> "{" M ("," N)? "}"
[11:21pm] <inimino> there we go
[11:21pm] <evilstreak> actualky {,6} is silly
[11:21pm] <evilstreak> since you can just do {0,6}
[11:21pm] <evilstreak> but {3,} is useful
[11:22pm] <evilstreak> ashb> N ? [0-9]*
[11:22pm] <evilstreak> zero or more
[11:22pm] <evilstreak> right?
[11:22pm] <ashb> yeah
[11:24pm] <ashb> this lua peg is fruity
[11:27pm] <inimino> is that the one that has its own pattern-matching state machine?
[11:27pm] <inimino> mm, yep
[11:28pm] <inimino> I read the paper about it, really fascinating stuff
[11:29pm] <ashb> oh its not just a packrat?
[11:29pm] <ashb> (the syntax is confusing as hell)
[11:29pm] <inimino> it's packrat with optimizations
[11:30pm] <inimino> which is where mine is trending
[11:30pm] <inimino> the syntax looks like it's shoehorned into arithmetic operators, maybe a limitation of the host language
[11:30pm] <ashb> patt / stringstring, with some marks replaced by captures of patt
[11:30pm] <ashb> what the hell does *that* mean
[11:31pm] <ashb> (there's a table cell between those two "string"s
[11:31pm] <inimino> I just read that, hehe
[11:32pm] <ashb> (nonindentspace * p"\t") / ""
[11:32pm] <inimino> it means there are substitutions of submatches from patt into the result string
[11:32pm] <inimino> like backreferences in regexes
[11:32pm] <ashb> but empty string?
[11:32pm] <ashb> the full rule is
[11:32pm] <ashb> indent = p" " + (nonindentspace * p"\t") / ""
[11:33pm] <ashb> nonindentspace = (p" ")^-3
[11:33pm] <ashb> (p" ") is litterl, + is ordered choice
[11:33pm] <ashb> and * is just x and y
[11:33pm] <inimino> hm, or p" " is literal?
[11:34pm] <ashb> yeah p" " matches 4 spaces
[11:34pm] <inimino> s/or/oh,/
[11:34pm] <inimino> so is the p"" part of lua syntax like Python u"" or something?
[11:34pm] <ashb> no
[11:34pm] <evilstreak> p is an alised function
[11:34pm] <evilstreak> lpeg.P
[11:35pm] <ashb> in lua brackets are optional if the thing only takes one argument
[11:35pm] <ashb> p("") === p""
[11:35pm] <ashb> its odd.
[11:35pm] <ashb> you can put spaces there too
[11:35pm] <inimino> ah, so it's just function application, ok
[11:35pm] <ashb> yup
[11:37pm] <inimino> + is ordered choice, makes sense if you think of it as set-union
[11:37pm] <ashb> its confusing as - is neg look ahead tho
[11:38pm] <inimino> yeah
[11:38pm] <inimino> and (p" ")^-3 is (p" "){0,3}
[11:38pm] <ashb> yeah that was the easy part
[11:39pm] <ashb> (" "){0,3} you mean?
[11:39pm] <inimino> well, yeah
[11:39pm] <? inimino is mixing up syntaxes with abandon
[11:39pm] <ashb> win
[11:40pm] <inimino> ah, I can read it now
[11:41pm] <inimino> so it's
[11:42pm] <inimino> indent ? " "{4} / " "{0,3} "\t"
[11:43pm] <inimino> it matches either four spaces, or fewer than four spaces followed by a tab (which would hide them)
[11:43pm] <inimino> and then it replaces all of that with the empty string in what it returns
[11:44pm] <ashb> we obviously can't do the tweaking of return yet
[11:44pm] <ashb> oh so it assumes tabstop is 4
[11:44pm] <inimino> I don't think I'll be taking much inspiration from their syntax, but I'll look over the other stuff
[11:44pm] <inimino> right
[11:44pm] <evilstreak> the syntax is pretty nasty
[11:44pm] <evilstreak> very dirty and messy
[11:44pm] <inimino> yeah, if you have ts=4 it just gives you the number of tabs you'd see visually
[11:45pm] <inimino> agreed on the syntax
[11:45pm] <inimino> the stuff they did with code generation was really clever though
[11:45pm] <ashb> char ranges have to be unicode hex right,
[11:45pm] <ashb> oh no i can do [0-9]
[11:45pm] <evilstreak> I don't get the difference between "foo - ( bar * baz )" and "foo * -( bar * baz )"
[11:46pm] <evilstreak> maybe the former isn't even valid
[11:46pm] <evilstreak> no, it is
[11:46pm] <inimino> once I've finished this round of codegen work I need to go back and read that paper again and see how similar it is to what I have
[11:46pm] <evilstreak> they have different ways in different places
[11:47pm] <inimino> ashb> yeah, the only chars you can't use directly are any kind of whitespace, the hyphen-minus, and closing square bracket, or something like that
[11:47pm] <inimino> ashb> you can also freely mix ranges and single values as in regex
[11:47pm] <ashb> oh wow.
[11:47pm] <ashb> interblockspace = lpeg.Cmt(blankline^0, function(s,i) if i == 1 then return i, "" else return i, "\n" end end)
[11:47pm] <ashb> thats a fun one to port
[11:48pm] <ashb> -- yields a blank line unless we're at the beginning of the document
[11:48pm] <ashb> aka impossible i think?
[11:48pm] <ashb> since there is no look behind?
[11:48pm] <inimino> hm...
[11:49pm] <inimino> oh wow, yeah
[11:49pm] <inimino> embedded functions that can alter the current position
[11:49pm] <inimino> I'm not sure I believe in that
[11:50pm] <ashb> can't alter position, just alter wether or not it matches
[11:50pm] <inimino> I guess I'll wait till I see a use case that requires it, but I think I'd prefer to find a declarative extension that extends PEG rather than letting people reach into the guts of the parser as it runs
[11:50pm] <ashb> strikes me as a better idea
[11:50pm] <inimino> "If the call returns a number, the match succeeds and the returned number becomes the new current position."
[11:51pm] <ashb> oh urgk
[11:51pm] <ashb> tho it is just returning the same position in that case
[11:51pm] <inimino> the position has to be within the length of the match
[11:51pm] <inimino> yeah
[11:52pm] <inimino> 'return i, ""' is sugary
[11:52pm] <ashb> yeah lua does have some nice syntax at times
[11:53pm] <inimino> yeah one of the goals of this parser generator is to be able to do all sorts of analysis of grammars, and make things that are resumable, incremental parsing, etc
[11:54pm] <ashb> yeah i saw the deisng goals
[11:54pm] <ashb> they look cool
[11:54pm] <inimino> which means I want to keep things purely declarative
[11:54pm] <ashb> more complex than i need for this, but cool none the less
[11:54pm] <inimino> ok
[11:56pm] <ashb> hmmm another fun one
[11:56pm] <ashb> closeblocktag = p"<" * spnl * p"/" * lpeg.Cmt(c(alphanumeric^1) * lpeg.Cb("opentag"), function(s,i,a,b) return string.lower(a) == string.lower(b) and i end) * spnl * p">"
[11:57pm] <ashb> oh thats just changing what its stored as again
[11:57pm] <inimino> oh, a matching lookup, very cool
[11:57pm] <ashb> thats fine
[11:57pm] <ashb> isn't it?
[11:57pm] <inimino> I've given some thought to how to do that but not enough yet
[11:57pm] <ashb> oh of hte previous opentag match
[11:58pm] <ashb> so yeah, i just will be a bit more permissive
[11:58pm] <inimino> yeah
[11:58pm] <evilstreak> inimino> is there any way to write stupidly long rules over multiple lines?
[11:58pm] <ashb> yeah break where ever you like
[11:58pm] <ashb> http://boshi.inimino.org/3box/PEG/PEG.peg
[11:58pm] <inimino> yeah, just indent them
[11:59pm] <evilstreak> cool
[11:59pm] <inimino> if the line starts with a space it's a continuation
[11:59pm] <inimino> (or a tab too, probably)

 

 

Logs by date :