On Wed, Apr 18, 2012 at 21:04, Jae Gangemi <
jgangemi@xxxxxxxxx> wrote:
>
> is there a reason you haven't pushed the patch upstream?
>
> i'd prefer not to be in the business of rolling my own core plugin sets,
> at least not yet, i've got enough on my plate w/ this thing as it is. :)
>
>
> On Mon, Apr 16, 2012 at 10:24 AM, Johan Compagner <
jcompagner@xxxxxxxxx>
> wrote:
>>
>> local, i have some patches to the dltk and we ship our own plugins that we
>> build our self.
>>
>>
>>
>> On Mon, Apr 16, 2012 at 16:23, Jae Gangemi <
jgangemi@xxxxxxxxx> wrote:
>>>
>>>
>>> do you have this patched in a sub-class or are you just using a local
>>> patched version of the core?
>>>
>>> i'm just trying to figure out where i'd drop this in (although it does
>>> seem like it's just a potential bug in general).
>>>
>>>
>>> On Mon, Apr 16, 2012 at 10:18 AM, Johan Compagner <
jcompagner@xxxxxxxxx>
>>> wrote:
>>>>
>>>> Not sure if this is related but this is my patch that i have in
>>>> SourceModule
>>>>
>>>> public void makeConsistent(IProgressMonitor monitor) throws
>>>> ModelException {
>>>> // if (isConsistent())
>>>> // return;
>>>> // makeConsistent(false/*don't create AST*/, 0, monitor);
>>>>
>>>> HashSet<Openable> elementsOutOfSynchWithBuffers = ModelManager
>>>> .getModelManager().getElementsOutOfSynchWithBuffers();
>>>> synchronized (elementsOutOfSynchWithBuffers) {
>>>> if (!elementsOutOfSynchWithBuffers.contains(this))
>>>> return;
>>>> elementsOutOfSynchWithBuffers.remove(this);
>>>> }
>>>>
>>>> openWhenClosed(createElementInfo(), monitor);
>>>> }
>>>>
>>>> the above method is what i use, because i also did see double parsing
>>>> and so on.
>>>>
>>>> And we also use very large files so it was noticeable..
>>>>
>>>>
>>>> On Sun, Apr 15, 2012 at 22:22, Jae Gangemi <
jgangemi@xxxxxxxxx> wrote:
>>>>>
>>>>> hello all -
>>>>>
>>>>> i'm noticing some kind of ISourceModuleInfo cache miss occuring in
>>>>> the SourceParserUtil.
>>>>>
>>>>> when i double click on a document to open in the editor, the
>>>>> ISourceModuleInfo is requested (line 48 of SourceParserUtil) is NOT the same
>>>>> object that is returned when SourceParserUtil gets invoked by the folding
>>>>> structure code, but it is the same object when the Reconcile thread fires
>>>>> next.
>>>>>
>>>>> the double parse is causing some slow downs on more complex objects.
>>>>>
>>>>> i've tried stepping through the code numerous times trying to track
>>>>> down the issue, but i haven't been able to figure out why the objects aren't
>>>>> the same. hopefully someone on the list can help. :)
>>>>>
>>>>> --
>>>>> -jae
>>>>>
>>>>> _______________________________________________
>>>>> dltk-dev mailing list
>>>>>
dltk-dev@xxxxxxxxxxx
>>>>>
https://dev.eclipse.org/mailman/listinfo/dltk-dev
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> dltk-dev mailing list
>>>>
dltk-dev@xxxxxxxxxxx
>>>>
https://dev.eclipse.org/mailman/listinfo/dltk-dev
>>>>
>>>
>>>
>>>
>>> --
>>> -jae
>>>
>>> _______________________________________________
>>> dltk-dev mailing list
>>>
dltk-dev@xxxxxxxxxxx
>>>
https://dev.eclipse.org/mailman/listinfo/dltk-dev
>>>
>>
>>
>> _______________________________________________
>> dltk-dev mailing list
>>
dltk-dev@xxxxxxxxxxx
>>
https://dev.eclipse.org/mailman/listinfo/dltk-dev
>>
>
>
>
> --
> -jae
>
> _______________________________________________
> dltk-dev mailing list
>
dltk-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/dltk-dev
>
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev