[01:51:31] *** Arbalest has quit IRC
[01:53:29] *** briandealwis has quit IRC
[02:46:18] *** Arbalest has joined #eclipse-e4
[04:11:00] *** rcjsuen has quit IRC
[06:08:02] *** susanmccourt has quit IRC
[06:08:06] *** paulweb515_ has quit IRC
[06:08:11] *** Arbalest has quit IRC
[06:08:17] *** magnet has quit IRC
[09:25:19] *** borisb6i has joined #eclipse-e4
[09:42:09] *** borisb6i has quit IRC
[09:47:29] *** borisb6i has joined #eclipse-e4
[09:54:37] *** magnet has joined #eclipse-e4
[09:54:48] *** paulweb515_ has joined #eclipse-e4
[09:56:00] *** susanmccourt has joined #eclipse-e4
[11:43:27] *** borisb6i has quit IRC
[11:50:40] *** borisb6i has joined #eclipse-e4
[12:15:07] *** borisb6i has quit IRC
[12:59:41] *** Arbalest has joined #eclipse-e4
[13:07:12] *** briandealwis has joined #eclipse-e4
[13:48:32] *** rcjsuen has joined #eclipse-e4
[14:27:18] *** yarthorn has joined #eclipse-e4
[14:44:00] *** tschindl has joined #eclipse-e4
[14:49:08] <tschindl> rcjsuen: did you managed to install my tooling?
[14:49:22] <rcjsuen> tschindl: I installed it from when Indigo GA'd
[14:49:24] <rcjsuen> yes
[14:49:47] <tschindl> ok
[14:51:59] <tschindl> rcjsuen: do you know why all those unused .git-repos are kept?
[14:52:11] <rcjsuen> No.
[14:52:20] <rcjsuen> paulweb515_: Paul, should we delete those "test" repos?
[14:52:20] <tschindl> this is quite confusing
[15:40:48] <rcjsuen> tschindl: In Egit you have to commit and then make a patch
[15:40:51] <rcjsuen> but maybe you knew that alrdy
[15:41:17] <tschindl> yes I know that but i don't want to commit in my local repo for now
[15:42:09] <tschindl> i know that git workflow is supposed to be different to how it was with CVS but not providing me a possibility to create a patch easily is at least for me a drawback when it comes to communicating through bugzilla
[15:42:30] <rcjsuen> yes it is
[15:42:33] <tschindl> i guess the standard workflow is that I create my local branch right
[15:42:35] <rcjsuen> and of course there is a bug in egit about this alrdy
[15:42:44] <tschindl> do you know it?
[15:43:10] <rcjsuen> i think james opened it
[15:43:29] <tschindl> i guess before I work on platform git repo I'll add such a feature to it
[15:43:36] <rcjsuen> the description is not clear
[15:43:38] <rcjsuen> but i'm guessing it's ~341036
[15:43:39] <Arbalest> Bug 341036 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=341036 - EGit / UI / unspecified - All / All - NEW / enhancement / - Assignee: egit.ui-inbox - Team > Create patch is missing
[15:44:17] <rcjsuen> oh the one James opened is ~354800
[15:44:17] <Arbalest> Bug 354800 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=354800 - EGit / UI / 1.1 - All / All - NEW / enhancement / - Assignee: egit.ui-inbox - Egit should support creating a patch against an arbitrary commit
[15:44:20] <rcjsuen> which is of course, just as important
[16:04:08] <rcjsuen> tschindl: In your line 144. I'm wondering if we should do > rv = p.getVariable(name);
[16:04:41] <rcjsuen> But I guess the assumption is that that implementation of IEvaluationContext also doesn't have a complicated eclipse context backing it?
[16:05:29] <tschindl> well when doing p.getVariable() i would not need to iteration because this would be definition be a recursion
[16:05:55] <rcjsuen> I'm wondering if we'd ever get into a case where the returned variable isn't correct.
[16:06:48] <tschindl> my assumption was that i first have to search the local-stores because the IEclipseContext lookup is always using the the active leave
[16:07:45] <tschindl> so p.getVariable() == getVariable() all the time if you are NOT hitting the local-store
[16:08:11] <rcjsuen> What do you mean by "hit"
[16:08:17] <rcjsuen> That none of the local storages has this value?
[16:08:34] <tschindl> or did i understand getActiveLeaf() wrong
[16:09:19] <tschindl> what I'm trying to say is that we only need to search in the local caches in the parent hierarchy because the IEclipseContext value is not hierarchical
[16:10:03] <tschindl> because we are anyways always call getActiveLeave so will end up always in the same IEclipseContext
[16:10:18] <rcjsuen> A ExpressionContext (var defined)
[16:10:18] <rcjsuen>           |
[16:10:18] <rcjsuen> B IEvaluationContext implementation (var defined)
[16:10:18] <rcjsuen>           |
[16:10:18] <rcjsuen> C ExpressionContext (var undefined)
[16:10:19] <rcjsuen>           |
[16:10:21] <rcjsuen> D ExpressionContext (var defined)
[16:10:23] <rcjsuen> If we ask C for "var", does the user expect to get the value from B or D? Pre-patch they'd get D, post-patch they'd get C.
[16:10:28] <rcjsuen> I guess the user expects to get it from B.
[16:10:54] <rcjsuen> As the evaluation context does not imply it knows about its children
[16:11:16] <rcjsuen> Sorry, post-patch they would get B.
[16:12:53] <tschindl> well i I ask C for a var I expect it to search up in B and A
[16:13:30] <rcjsuen> Right now they'd get D. Well, assuming D is the active child of C
[16:13:38] <rcjsuen> So that seems like a bug, as you say.
[16:14:17] <tschindl> right
[16:15:44] <tschindl> i think my search local algorithm does what we'd expected but the getActiveLeaf stuff is wrong
[16:15:58] <rcjsuen> yes the getAL is suspect here
[16:16:09] <rcjsuen> i was wondering if we needed to chng your code slightly
[16:16:14] *** borisb6i has joined #eclipse-e4
[16:16:20] <rcjsuen> wrt map.get
[16:16:31] <rcjsuen> change to map.containsKey first and return null if someone actually did ctxt.addVar("a", null)
[16:16:44] <tschindl> hm - right
[16:16:46] <rcjsuen> but it seems the default impl ignores nulls and goes up
[16:16:48] <rcjsuen> 	public Object getVariable(String name) {
[16:16:49] <rcjsuen> 		Assert.isNotNull(name);
[16:16:49] <rcjsuen> 		Object result= null;
[16:16:49] <rcjsuen> 		if (fVariables != null) {
[16:16:49] <rcjsuen> 			result= fVariables.get(name);
[16:16:49] <rcjsuen> 		}
[16:16:51] <rcjsuen> 		if (result != null)
[16:16:53] <rcjsuen> 			return result;
[16:16:55] <rcjsuen> 		if (fParent != null)
[16:16:57] <rcjsuen> 			return fParent.getVariable(name);
[16:16:59] <rcjsuen> 		return null;
[16:17:01] <rcjsuen> 	}
[16:17:05] <rcjsuen> org.eclipse.core.expressions.EvaluationContext.getVariable(String)
[16:17:54] <tschindl> rcjsuen: i think we need paul to look at this right?
[16:18:07] <rcjsuen> yes this is something he should bless
[16:21:00] <tschindl> i think the getActiveLeaf should only be called in the leaf ExpressionContext and once we create a parent we'll have to use the context itself
[16:21:29] <rcjsuen> 	public void addVariable(String name, Object value) {
[16:21:29] <rcjsuen> 		Assert.isNotNull(name);
[16:21:29] <rcjsuen> 		Assert.isNotNull(value);
[16:21:29] <rcjsuen> 		if (fVariables == null)
[16:21:29] <rcjsuen> 			fVariables= new HashMap();
[16:21:30] <rcjsuen> 		fVariables.put(name, value);
[16:21:32] <rcjsuen> 	}
[16:21:34] <rcjsuen> oh in addVar it doesn't even allow nulls ;o
[16:21:50] <tschindl> ok - good need to add this then
[16:23:02] *** borisb6i has quit IRC
[16:23:12] <rcjsuen> tschindl: I just added my comment summarizing what we talked about here.
[16:24:07] <rcjsuen> <tschindl> i think the getActiveLeaf should only be called in the leaf ExpressionContext and once we create a parent we'll have to use the context itself
[16:24:19] <rcjsuen> so you mean every time another ExprC is created, the parent should record itself as not being the leaf ExprC?
[16:24:37] <tschindl> yes
[16:24:43] <rcjsuen> I see what you mean now.
[16:24:54] <rcjsuen> that seems to make sense to me from an IEvaluationContext pov
[16:25:12] <rcjsuen> (as we want to maintain the parent-lookup, since the chld lookup doesn't really make sense for IEvaCs
[16:28:12] <tschindl> hm i guess i also need to fix set setAllowPluginActivation in a local store
[16:37:04] *** borisb6i has joined #eclipse-e4
[16:40:58] *** borisb6i has quit IRC
[16:57:24] <paulweb515_> rcjsuen: which test repos?
[16:57:37] <rcjsuen> paulweb515_: I think there are still some lingering e4 ones
[16:57:50] <rcjsuen> paulweb515_: like http://git.eclipse.org/c/e4/eclipse.platform.ui.e4.git/
[16:57:55] <rcjsuen> http://git.eclipse.org/c/e4/eclipse.platform.ui.compat.git/
[16:57:56] <rcjsuen> http://git.eclipse.org/c/e4/eclipse.platform.runtime.e4.git/
[16:57:59] <rcjsuen> We don't care about these do we
[16:59:08] <paulweb515_> rcjsuen: those have history of plugins in them that didn't graduate to platform
[16:59:08] <paulweb515_> rcjsuen: they're real repos, and some of them even have build features in them
[16:59:08] <paulweb515_> rcjsuen: we'd have to do something to them to get rid of them
[16:59:17] <rcjsuen> ah
[16:59:27] <rcjsuen> i thot at least the compat one was useless
[16:59:32] <paulweb515_> rcjsuen: as for getActiveLeaf(), if that is to be used, it's determined by the caller (not usually something in IEclipseContext itself, but it depends).
[17:00:00] <paulweb515_> i.e. when executing an MMenuItem, we find the containing context and call getActiveLeaf() before we start looking up values
[17:00:29] <rcjsuen> we're looking at IEvaluationContext right now
[17:14:08] *** yarthorn has quit IRC
[17:14:30] *** susanmccourt has quit IRC
[17:15:14] *** borisb6i has joined #eclipse-e4
[17:25:27] *** borisb6i has quit IRC
[17:27:03] *** borisb6i has joined #eclipse-e4
[17:53:25] *** borisb6i has quit IRC
[17:55:01] *** susanmccourt has joined #eclipse-e4
[17:56:21] *** yarthorn has joined #eclipse-e4
[18:02:13] *** magnet has quit IRC
[18:04:18] *** magnet has joined #eclipse-e4
[18:07:30] <paulweb515_> rcjsuen: the mapping between them is less than perfect ... since IEvalContext is supposed to represent the global app state, in theory all calls into an ExpressionContext (or whatever it is) should go to the active leaf, making the lookups simple
[18:31:43] <tschindl> paulweb515_: so what is the hierarchy then for in it?
[18:32:23] <tschindl> would be nice if you could take a look at ~358020
[18:32:24] <Arbalest> Bug 358020 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=358020 - Platform / UI / 4.2 - PC / Mac OS X - NEW / major / - Assignee: Platform-UI-Inbox - [Compat] Git-Commit Dialog destroys IEclipseContext by calling IEvaluationContext#addVariable
[18:36:30] *** tschindl has quit IRC
[19:46:30] *** borisb6i has joined #eclipse-e4
[19:47:55] *** borisb6i has quit IRC
[21:21:05] *** tschindl has joined #eclipse-e4
[21:29:31] *** tschindl has left #eclipse-e4
[21:35:23] *** borisb6i has joined #eclipse-e4
[21:40:02] *** tschindl has joined #eclipse-e4
[21:41:07] *** borisb6i has quit IRC
[21:58:44] *** lpereira has joined #eclipse-e4
[22:35:24] *** rcjsuen is now known as rcjsuen_
[22:35:31] *** rcjsuen_ has quit IRC
[22:38:35] *** susanmccourt has quit IRC
[22:45:20] *** lpereira has quit IRC
[23:02:37] *** rcjsuen has joined #eclipse-e4
[23:06:03] <briandealwis> I like the maximiize/minimize part fade-in/out.  Groovy
[23:10:52] <rcjsuen> ~tell briandealwis about 357939
[23:10:53] <Arbalest> briandealwis: Bug 357939 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=357939 - Platform / UI / 4.2 - All / All - NEW / enhancement / - Assignee: platform-ui-triaged - Feedback and suggestions for making Eclipse 4 'cool'
[23:11:51] <briandealwis> Thanks
[23:12:30] *** briandealwis has quit IRC
[23:21:41] *** borisb6i has joined #eclipse-e4
[23:31:22] *** yarthorn has quit IRC
[23:54:19] *** borisb6i has quit IRC





top