logo       

Re: Manager class: msg#00039

lang.nemerle.devel

Subject: Re: Manager class

06-05-29, NoiseEHC <NoiseEHC@xxxxxxxxxxx> napisał(a):
LOL, just spent some time to read the forum. Seems that the volume of
messages in this mailing list is so low because everybody uses the
forum... :(

It seems many people prefer forum, which is a bit strange for me,
because it is harder to be in sync with new messages. But anyway, let
us not start any list/forum war.

Now, as I read all of Vlad's messages it seems that we have another
nemerle hack plugin for VS. I could not get the source so I could not
see how
they implemented calling LexerColorizer (or anything) but some info
about that would be nice. The link which did not work:
svn://rsdn.ru/Nemerle/Nemerle.SimpleVsIntegration


Hm, it doesn't work for me too. We should ask Vlad if it is possible
to move their implementation to nemerle.org repository. It will
probably make things more accessible to everybody and allow us some
more coordination of efforts.


Ahh, and Nazgul, please do not remove the LexerColorizer. I tried to use

This is a bit strange, since LexerString and LexerColorizer allow very
similar functionality - they just hold a string and position in it. So
in general if you assign previous position to LexerString, it should
correctly "back in time", though there are several fields, which
actually hold the state of lexing - they are used in preprocessor
directives parsing.
It is quite interesting how MS implemented this stuff in C# bindings,
since VS seems to behave quite intelligent with respect to
preprocessor directives - and in general this requite more than a
simple int state.

My original idea for LexerColorizer was that it should be fast and it
should colorize the default code correctly (e.g. assuming that
standard code macros are loaded, not considering preprocessor
directives, etc.). Then in the less frequent parsing passes we could
use LexerString to additionally colorize some new keywords or
preprocessor stuff. But the problem is that if we want for example
matching of parenthesis we must use LexerString anyway.
So it is not clear for me if maintaining two separate implementations
of Lexer makes any sense... but maybe yes :)


ps:
Would it be better for me just to use the forum?

The folks from rsdn.ru seems to check the forum more frequently than
mail ;) So probably for discussions about completion engine and VS you
should stick there.


ps2:
I do get it why it was necessary but still cannot make the modifications
myself. Kamil, can you modify those 5 lines of my code, please?

You probably need to initialize the ManagerClass object. Now as we
have the more object-oriented structure, it should be reasonably easy
to subclass ManagerClass (or use the Nemerle.Completion.Engine) and
make it perform only some chosen set of steps (like only initialize
the library references and then perform lexing) on the Run method.

I'm looking forward for defining some more methods in ManagerClass,
which could be overridden in subclasses, so we can easily enable /
disable some compilation steps or simply jump to single step.
So the idea is to always call some methods defined in ManagerClass and
avoid directly using other compiler's API.


Kamil Skalski wrote:
> There were some massive changes in compiler API to make it capable of
> running in several instances / threads.
> This is mainly needed for completion integration. See:
> http://nemerle.org/forum/viewtopic.php?t=250
>
> 06-05-29, NoiseEHC <NoiseEHC@xxxxxxxxxxx> napisał(a):
>> It seems that meantime the GlobalEnv stuff changed so I cannot
>> initialize the LexerColorizer anymore.
>>
>> It was:
>> LibraryReferenceManager.LoadMacrosFrom(@"c:\program
>> files\nemerle\Nemerle.Macros.dll");
>> GlobalEnv.Init();
>>
>> Now it gives errors. To what shall I change this?
>> C:\Program Files\Visual Studio 2005
>>
SDK\2006.04\VisualStudioIntegration\Samples\NemerleIntegration\LanguageService\PythonScanner.cs(9,4):
>>
>> error CS0122: 'Nemerle.Compiler.LibraryReferenceManager' is inaccessible
>> due to its protection level
>> C:\Program Files\Visual Studio 2005
>>
SDK\2006.04\VisualStudioIntegration\Samples\NemerleIntegration\LanguageService\PythonScanner.cs(9,28):
>>
>> error CS0117: 'Nemerle.Compiler.LibraryReferenceManager' does not
>> contain a definition for 'LoadMacrosFrom'
>> C:\Program Files\Visual Studio 2005
>>
SDK\2006.04\VisualStudioIntegration\Samples\NemerleIntegration\LanguageService\PythonScanner.cs(10,14):
>>
>> error CS0117: 'Nemerle.Compiler.GlobalEnv' does not contain a definition
>> for 'Init'
>>
>>
>> Another change in:
>> NC.LexerString lexer = new
>> Nemerle.Compiler.LexerString(NC.ManagerClass.Instance, req.Text, new
>> NC.Location(0, 1, 1));
>> NC.PreParser preparser = new
>> Nemerle.Compiler.PreParser(lexer);
>> NC.Token.BracesGroup braces = preparser.PreParse();
>>
>>
>> Is "NC.ManagerClass.Instance" a good parameter for for the parser?
>>
>> I mean shall I implement some Manager class and use that or what? Maybe
>> some documentation would not hurt... (I mean maybe 10 lines would
>> suffice)
>>
>> ps:
>> I am asking these questions after messing with the source and SVN log
>> for 2 hours... :(
>>
>>
>> _______________________________________________
>> https://nemerle.org/mailman/listinfo/devel-en
>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> https://nemerle.org/mailman/listinfo/devel-en
>

_______________________________________________
https://nemerle.org/mailman/listinfo/devel-en



--
Kamil Skalski
http://nazgul.omega.pl


<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | FAQ | advertise