fluid-tech IRC Logs-2012-11-12

[15:09:18 CST(-0600)] <Bosmon> Hi yura - other than the issue with the request error handler, your GIANT PUL request looks great and ready to go in

[15:09:32 CST(-0600)] <yura> Bosmon: great

[15:09:37 CST(-0600)] <yura> i will update it soon

[15:10:16 CST(-0600)] <Bosmon> awesome!

[15:19:44 CST(-0600)] <yura> Bosmon: quick question

[15:21:15 CST(-0600)] <Bosmon> JURA!

[15:22:19 CST(-0600)] <yura> Bosmon: i m assuming i need to wrap it as soon as possible

[15:22:28 CST(-0600)] <yura> e.g. as soon as request is created, correct ?

[15:22:35 CST(-0600)] <Bosmon> yura - there is no timing issue involved

[15:22:44 CST(-0600)] <yura> hmm no

[15:22:45 CST(-0600)] <Bosmon> You will simply register one handler for all time

[15:22:46 CST(-0600)] <yura> btu

[15:24:27 CST(-0600)] <Bosmon> That is, there is no timing issue involved above that created by the existing callback wrapper

[15:24:31 CST(-0600)] <Bosmon> Which you will leave untouched

[15:36:14 CST(-0600)] <yura> Bosmon: so it means that request object must be in environment when fluid.fail is called ?

[15:36:52 CST(-0600)] <Bosmon> yura - it always will be, except during global startup

[15:37:03 CST(-0600)] <Bosmon> That is, node is ALWAYS in the middle of handling one request or another

[15:37:12 CST(-0600)] <Bosmon> And if it isn't, that is a further error in itself

[15:38:57 CST(-0600)] <yura> well in order for it to be i have to wrap every asynchronous callback beforehand no ?

[15:49:23 CST(-0600)] <Bosmon> yura - the wrapping is already done!

[15:49:37 CST(-0600)] <Bosmon> By virtue of our callback which applies "withEnvironment" with the request

[15:49:44 CST(-0600)] <Bosmon> This is what it was always for

[15:50:26 CST(-0600)] <yura> Bosmon: are you referring to my pastie ?

[15:51:05 CST(-0600)] <Bosmon> yura - well, the pastie is still incorrect

[15:51:20 CST(-0600)] <Bosmon> Although it is getting better

[15:51:48 CST(-0600)] <Bosmon> Well, in a sense : P

[15:52:09 CST(-0600)] <Bosmon> The pastie has the worst of both worlds, i) it pollutes our callback wrapper, ii) still doesn't make use of the fact that it pollutes the wrapper : P

[15:52:37 CST(-0600)] <Bosmon> All you need to do now is to take the code containing pushSoftFailure and write it at top level

[15:59:09 CST(-0600)] <Bosmon> yura - ayt?

[15:59:14 CST(-0600)] <yura> Bosmon: yes

[15:59:22 CST(-0600)] <yura> i m trying to understand what you mean :S

[16:02:21 CST(-0600)] <yura> Bosmon: so what do you mean by top level?

[16:03:18 CST(-0600)] <Bosmon> yura - I just mean, outside any other functions

[16:04:19 CST(-0600)] <Bosmon> colinclark - do you think I should indeed commit yevgeni's SPI stuff today, despite that there is an unexplained test failure on my machine?

[16:04:31 CST(-0600)] <yura> Bosmon: and not use callbackWrapper.wrap

[16:04:42 CST(-0600)] <Bosmon> yura - the callback has already done its work

[16:04:53 CST(-0600)] <yura> well that's the problem

[16:05:15 CST(-0600)] <colinclark> Bosmon: It's a good question

[16:05:34 CST(-0600)] <colinclark> Remind me of what we know about the failure...

[16:05:43 CST(-0600)] <colinclark> is it something we think only happens on 64-bit Windows?

[16:05:54 CST(-0600)] <Bosmon> It is a failure when applying the high contrast settings

[16:05:55 CST(-0600)] <yura> Bosmon: that's what you'd expect, unless i call fluid.fail in some async callback that was not wrapped prior to be passed to a data source for example

[16:06:05 CST(-0600)] <Bosmon> And occurs on my machine, and doesn't occur on his

[16:06:18 CST(-0600)] <Bosmon> yura - for any callback not to be wrapped is itself an error

[16:06:24 CST(-0600)] <Bosmon> Since it would stop the rest of the framework working

[16:06:31 CST(-0600)] <yura> yes

[16:06:37 CST(-0600)] <yura> i will fix that

[16:06:46 CST(-0600)] <colinclark> Bosmon: I wonder if it's worth asking Kasper or someone else to do some quick testing on a Windows VM?

[16:06:51 CST(-0600)] <Bosmon> yura - are there any unwrapped callbacks like that?

[16:06:55 CST(-0600)] <yura> 1

[16:07:03 CST(-0600)] <yura> which is an error i guess

[16:07:11 CST(-0600)] <Bosmon> I can test it myself on a couple more VMs I have....

[16:08:18 CST(-0600)] <colinclark> My goals for this release--and I guess I shouldn't speak also for Kasper here...

[16:08:50 CST(-0600)] <colinclark> is to essentially enable a somewhat more stable platform for early integration of Solutions, as well as for the upcoming hackathon

[16:09:16 CST(-0600)] <kasper> agreeing with what colinclark said

[16:09:41 CST(-0600)] <Bosmon> I imagine that we will have to merge the work relatively soon in any case

[16:09:54 CST(-0600)] <Bosmon> Given the fact that the current system doesn't work with any current version of node on windows is a very large blocker

[16:10:03 CST(-0600)] <Bosmon> But I guess we could try to characterise the problem a little better before we do

[16:17:53 CST(-0600)] <kasper> Bosmon: are we talking about the master repo, or some branch? I think I tried it on win only a few weeks back, and it worked then

[16:18:09 CST(-0600)] <yura> Bosmon: please review my updated pull request

[16:18:10 CST(-0600)] <kasper> Bosmon: though I do remember some weird issue on VM

[16:19:36 CST(-0600)] <Bosmon> kasper - the master repo has been broken on Windows since around Linz time

[16:19:45 CST(-0600)] <Bosmon> At least, on a reasonable variety of machines

[16:19:57 CST(-0600)] <yura> Bosmon: oh wow , my commit is not showing up :S

[16:20:27 CST(-0600)] <kasper> Bosmon: oh, ok

[16:20:29 CST(-0600)] <Bosmon> yura - you're right, it isn't : P

[16:20:47 CST(-0600)] <yura> i blame github partial outage

[16:22:19 CST(-0600)] <Bosmon> colinclark, kasper - testing on an XP VM as well as the original failures I get further failures with evgeni's branch

[16:22:52 CST(-0600)] <kasper> Bosmon: auch, that doesn't sound good

[16:23:41 CST(-0600)] <colinclark> It's an 0.1 release, so the nature the term "stable platform" can be fairly flexible

[16:23:58 CST(-0600)] <colinclark> partly this is a process of reminding people that we're still around, and still doing a ton of work that they'll want to pay attention to

[16:24:16 CST(-0600)] <colinclark> part of it is just a discipline for us to slowly transition from "R&D" into making a platform for others to use

[16:24:41 CST(-0600)] <colinclark> All of that is to say that I think I strongly support our need to address the brokenness on Windows

[16:24:50 CST(-0600)] <colinclark> even if it ultimately involves some failures on Windows

[16:27:33 CST(-0600)] <Bosmon> colinclark - so you are generally in favour of a merge then?

[16:27:41 CST(-0600)] <colinclark> Bosmon: Generally speaking, yes

[16:27:51 CST(-0600)] <Bosmon> The branch is certainly hugely better than what we have in master

[16:28:04 CST(-0600)] <colinclark> Along with a big fat JIRA about the issues the code is currently facing

[16:28:05 CST(-0600)] <Bosmon> Given it at least "somewhat works" on most versions of Windows and node.exe

[16:28:15 CST(-0600)] <colinclark> yes; that to me is an improvement

[16:28:32 CST(-0600)] <Bosmon> As opposed to the current master which is quite likely to explode on startup on most versions of Windows

[16:28:53 CST(-0600)] <colinclark> +1 for less exploding

[16:29:10 CST(-0600)] <Bosmon> ok

[16:29:15 CST(-0600)] <Bosmon> I will do the necessaries

[16:30:44 CST(-0600)] <colinclark> thanks Bosmon

[16:30:47 CST(-0600)] <colinclark> kasper, you concur?

[16:32:11 CST(-0600)] <kasper> colinclark, Bosmon: yeah, I agree - less explosions is good

[17:01:23 CST(-0600)] <Bosmon> yura - that looks correct now

[17:01:30 CST(-0600)] <Bosmon> I'm wondering about the other changes in that commit

[17:01:52 CST(-0600)] <Bosmon> In particular the return statements in deferred

[17:02:11 CST(-0600)] <Bosmon> They are doubtless correct, but I'm wondering what got them in at this point?

[17:02:48 CST(-0600)] <Bosmon> I think you still need a fallback in "pushSoftError" that just logs if there is no request

[17:02:54 CST(-0600)] <Bosmon> pushSoftFailure

[17:22:30 CST(-0600)] <Bosmon> sgithens!