Re: GSoc 2009

[Johannes Schmid-4]

Hi!

> > If you want, you should also be able to get access to GNOME git and
> work directly on a remote branch there.

Have a look here:
http://live.gnome.org/NewAccounts

> As you can see, the code that parsed JS used in the debugger (for
> determination the current values of variables).
> Integration with ctags would lead to duplication of code.
>
> Should I integrate it into ctags(with full rewrite)?
>
Hmm, what I could think of was to create multiple backends for
symbol-db. I don't know how difficult that could be but in general I
would think of something like that:

symbol-db/
        backends/
                ctags/ (that would default, current code)
                javascript/
                python/
                improved-c-c++ parser(?)

Massimo', do you think the code could be refactored like that? The
backends could probably be implemented as usual anjuta plugins. Maybe
those could be combined with the language support also, in this way.

symbol-db/
symbol-scanner-ctags/
language-support-cpp-java/
language-support-javascript/
language-support-python/

The interface should be kept simple as
ianjuta_symbol_scanner_scan_file() (would use IAnjutaAsyncInterface)
which returns an IAnjutaIterable* of IAnjutaSymbols. For other languages
it might be needed to extend IAnjutaSymbol somehow but that can be done
later.

Regards,
Johannes


------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Massimo Cora']

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Johannes Schmid wrote:

> Hi!
>
>>> If you want, you should also be able to get access to GNOME git and
>> work directly on a remote branch there.
>
> Have a look here:
> http://live.gnome.org/NewAccounts
>
>> As you can see, the code that parsed JS used in the debugger (for
>> determination the current values of variables).
>> Integration with ctags would lead to duplication of code.
>>
>> Should I integrate it into ctags(with full rewrite)?
>>
> Hmm, what I could think of was to create multiple backends for
> symbol-db. I don't know how difficult that could be but in general I
> would think of something like that:
>

I don't think I get the point of the discussion. Why should we write
different backends? Symbol-db is based on ctags and then it could
support all languages parsed by ctags, that are many.

> symbol-db/
> backends/
> ctags/ (that would default, current code)
> javascript/
> python/
> improved-c-c++ parser(?)
>
> Massimo', do you think the code could be refactored like that? The
> backends could probably be implemented as usual anjuta plugins. Maybe
> those could be combined with the language support also, in this way.
>
> symbol-db/
> symbol-scanner-ctags/
> language-support-cpp-java/
> language-support-javascript/
> language-support-python/
>

the language-support plugins are ok. What I don't understand is the
symbol-scanner-ctags. I'd prefer to have only one centralized scanner,
which is ctags inside symbol-db.
I'm currently writing a cxxparser inside language-support-cpp-java,
which will give completion capabilities once done.

> The interface should be kept simple as
> ianjuta_symbol_scanner_scan_file() (would use IAnjutaAsyncInterface)
> which returns an IAnjutaIterable* of IAnjutaSymbols. For other languages
> it might be needed to extend IAnjutaSymbol somehow but that can be done
> later.
>

well, IAnjutaSymbol is done with a general purpose in mind. It's not
necessary to write another IAnjutaSymbol iface for a different language.
Think of it as a wrapper of ctags' tag: it works fine for different
languages.


regards,
Massimo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkn7bwcACgkQcfVTgMRILk1fDgCfYcykNWYi585qGueAV3zGAhKO
hxIAn3544rzEUxoTIpHHx/7QhVWuCEtX
=OYvT
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Sébastien Granjoux]

Hi all,

I think this part should be more clear as both GSOC students are working
on this. I have understood that it works like in Massimo reply:

- The symbol-db plugin is a wrapper around ctags, used by all supported
languages: C,C++ and at least python, I don't know for javascript.

- A language-support plugin is present for each language in order to
support additional features not present in ctags. By example, the type
of the value returned by a function.

- I think, Ishan and Maxim have to write a new language-support plugin
and check that it fits well in Anjuta. A bit like the improved C/C++
language support plugin on which Massimo is working.


The disadvantage of this architecture is that there are 2 parsers for
each languages: one in ctags and one in the language support plugin.
Even 3 if you take in account the one in the editor used to highlight
syntax.

Moreover, at least the current language-support-cpp-java doesn't provide
any interface like the symbol-db plugin to get informations about the
symbols. Currently, it hooks itself on the editor plugin to provide the
additional functions (completion). It means that by example the debugger
plugin cannot ask it more information about something not handled by the
symbol-db plugin.


The current solution is not perfect but it should work. Then, it would
be great to improve it but I don't know how to make it better

Regards,

Sébastien

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Johannes Schmid-4]

Hi!

> I don't think I get the point of the discussion. Why should we write
> different backends? Symbol-db is based on ctags and then it could
> support all languages parsed by ctags, that are many.

Yes, it support many, put for the most languages it only support a very
small subset of the symbols and improving the ctags scanners seems
almost impossible as they tend to do only one release in 10 years.

> well, IAnjutaSymbol is done with a general purpose in mind. It's not
> necessary to write another IAnjutaSymbol iface for a different language.
> Think of it as a wrapper of ctags' tag: it works fine for different
> languages.

That wasn't what I proposed. IAnjutaSymbol is good enough for all
languages but it's not limited to ctags. In fact, there can be other
sources to get IAnjutaSymbols than ctags if we have a superioir scanner
for some language.

The point was to modify symbol-db in a way that it's possible to read
symbol information from other sources than ctags and those sources could
be provided by the language-support plugins.

Regards,
Johannes


------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Massimo Cora']

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Johannes Schmid wrote:

>
> Yes, it support many, put for the most languages it only support a very
> small subset of the symbols and improving the ctags scanners seems
> almost impossible as they tend to do only one release in 10 years.
>
>> well, IAnjutaSymbol is done with a general purpose in mind. It's not
>> necessary to write another IAnjutaSymbol iface for a different language.
>> Think of it as a wrapper of ctags' tag: it works fine for different
>> languages.
>
> That wasn't what I proposed. IAnjutaSymbol is good enough for all
> languages but it's not limited to ctags. In fact, there can be other
> sources to get IAnjutaSymbols than ctags if we have a superioir scanner
> for some language.
>

ok now I've got the point. What are the other scanners we're taking into
consideration? Are they really superior to ctags? I'm talking about
speed, absolutely needed features, stability etc.

> The point was to modify symbol-db in a way that it's possible to read
> symbol information from other sources than ctags and those sources could
> be provided by the language-support plugins.
>

ok you'd like to have a sort of strategy pattern with modules that scan
files and give informations about parsed symbols etc.
Theoretically it's feasible by extrapolating the ctags code from the
symbol-db-core, by creating some good interfaces for a general purpose
scanner, and by modularizing ctags and scanner-x, scanner-y etc.
The first problem I see is that yet another layer is added to the stack.
And this means slowness.
The second one is the huge refactoring needed to have such
implementation done. This costs a lot time and third: is this worth
having? I mean, I can understand if we have N really good scanners to
integrate, but adding a layer just to support one or two scanner seems
like not a good idea to me.

regards,
Massimo




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkn8EXwACgkQcfVTgMRILk3j9gCghoR4uFPJER6eDPGpP1rOfikK
TK4AnA33jCb5mKtiaozK19lE2zJZN/MF
=E7Ez
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Johannes Schmid-4]

Hi!

> ok now I've got the point. What are the other scanners we're taking into
> consideration? Are they really superior to ctags? I'm talking about
> speed, absolutely needed features, stability etc.
>

The libraries behind python, javascript and vala provide direct access
to the parsers used by the interpreter/compiler which means that
defintily produce better results (and might even be faster) than ctags.

Anyway, my question was first to ask you what you think about it and if
you think it possibly and worthy to refactor symbol-db in a way it can
use other parser than ctags.

Regards,
Johannes


------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Massimo Cora']

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Sébastien Granjoux wrote:
> Hi all,
>
> I think this part should be more clear as both GSOC students are working
> on this. I have understood that it works like in Massimo reply:
>
> - The symbol-db plugin is a wrapper around ctags, used by all supported
> languages: C,C++ and at least python, I don't know for javascript.

yes js is included too, see `$ ctags --list-languages`.

>
> - A language-support plugin is present for each language in order to
> support additional features not present in ctags. By example, the type
> of the value returned by a function.
>

well, that's not exact. I mean the type of the returned value is a
side-effect of a ctags lack. The language-support plugin should have the
logic to create completions, tooltips etc, just using the model provided
by symbol-db.
Think of it as a controller+view in a MVC architecture, where the model
is symbol-db.

> - I think, Ishan and Maxim have to write a new language-support plugin
> and check that it fits well in Anjuta. A bit like the improved C/C++
> language support plugin on which Massimo is working.
>
>
> The disadvantage of this architecture is that there are 2 parsers for
> each languages: one in ctags and one in the language support plugin.
> Even 3 if you take in account the one in the editor used to highlight
> syntax.
>
> Moreover, at least the current language-support-cpp-java doesn't provide
> any interface like the symbol-db plugin to get informations about the
> symbols. Currently, it hooks itself on the editor plugin to provide the
> additional functions (completion). It means that by example the debugger
> plugin cannot ask it more information about something not handled by the
> symbol-db plugin.
>
>
> The current solution is not perfect but it should work. Then, it would
> be great to improve it but I don't know how to make it better
>

we can hack at ctags level, providing some useful informations like the
return value of a function. We would then be able to reuse the current
architecture without many modifications.
Eran Ifrah of CodeLite has put some code into ctags to provide such
features (tought I don't remember which ones). Doing so we risk to have
the maintenance problems we had before with tagsmanager, but considering
that the release cycle of ctags is really slow we can have a thought at it.

regards,
Massimo



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkn8FScACgkQcfVTgMRILk2bqgCdFr8uKAa0CztldZPliaf2Qzbh
raAAn3BxhwUBS/Z05APhlt6Vw7KOGIHf
=CUUw
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Sébastien Granjoux]

Hi Massimo,

Massimo Cora' a écrit :
> well, that's not exact. I mean the type of the returned value is a
> side-effect of a ctags lack. The language-support plugin should have the
> logic to create completions, tooltips etc, just using the model provided
> by symbol-db.

Yes, but the type of the returned value is useful for completion and
symbol-db plugin or rather ctags doesn't provide it. So how could we do it ?

I have understood that we have to handle this outside symbol-db plugin
and so in the language support plugin. But it could mean write another
parser for the supported language.

I'm agree that it would be better to handle this in symbol-db plugin.
But then it looks like we can have to use the idea proposed by Johannes
and to have symbol-db backend plugin. Or do you have another idea ?

> Think of it as a controller+view in a MVC architecture, where the model
> is symbol-db.

I'm agree that this would be perfect, but some informations are missing
currently.


> we can hack at ctags level, providing some useful informations like the
> return value of a function. We would then be able to reuse the current
> architecture without many modifications.

I think your are already working on improving the C/C++ symbol support.
You should have the same problem to know the type of a returned value by
example. How do you plan this ?

Do you plan to improve ctags to support his directly ?

Have you added some code inside the symbol-db plugin ? adding additional
information in the database (return type of a function) and using this
in the language-support plugin to provide a more intelligent completion.

Or, have you added more code inside the language-support-C++ plugin ?
finding the return type of a function an providing the completion

Regards,

Sébastien

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Ishan Chattopadhyaya]

Hello everyone,

On Sat, 2009-05-02 at 12:19 +0200, Sébastien Granjoux wrote:

> Hi Massimo,
>
> Massimo Cora' a écrit :
> > well, that's not exact. I mean the type of the returned value is a
> > side-effect of a ctags lack. The language-support plugin should have the
> > logic to create completions, tooltips etc, just using the model provided
> > by symbol-db.
>
> Yes, but the type of the returned value is useful for completion and
> symbol-db plugin or rather ctags doesn't provide it. So how could we do it ?
>
> I have understood that we have to handle this outside symbol-db plugin
> and so in the language support plugin. But it could mean write another
> parser for the supported language.
>
> I'm agree that it would be better to handle this in symbol-db plugin.
> But then it looks like we can have to use the idea proposed by Johannes
> and to have symbol-db backend plugin. Or do you have another idea ?
>

As for Python, I get a feeling that best way to get completions could be
to use the libraries provided by Python package (libraries like parser,
AST etc). [As jhs mentioned in an earlier post] I believe the best
available python IDEs at the moment use it. These libraries could be
used through Python scripts (spawned from the language-support plugin,
maybe), or perhaps some bindings to those libs could be used/made.
Is there any aversion in dealing with external python scripts from the
symbol-db module or at ctags level? If that's the case, then the libs
could be used from the language-suppport plugin, maybe..?

Regds,
Ishan


------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

> As for Python, I get a feeling that best way to get completions could be
> to use the libraries provided by Python package (libraries like parser,
> AST etc). [As jhs mentioned in an earlier post] I believe the best
> available python IDEs at the moment use it. These libraries could be
> used through Python scripts (spawned from the language-support plugin,
> maybe), or perhaps some bindings to those libs could be used/made.
> Is there any aversion in dealing with external python scripts from the
> symbol-db module or at ctags level? If that's the case, then the libs
> could be used from the language-suppport plugin, maybe..?

This is slightly off-topic but I would like to throw in the use of
pylint and maybe bicycle-repair-man.


------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Abderrahim Kitouni-2]

Hi,

On Thu, 30 Apr 2009 22:56:56 +0200
Johannes Schmid <jhs@...> wrote:
> Hmm, what I could think of was to create multiple backends for
> symbol-db. I don't know how difficult that could be but in general I
> would think of something like that:

I was thinking about something like this, maybe just saparating the ui and the
backend and let the ui use the standard IAnjutaSymbolManager API to communicate
with the backend.

Regards,
Abderrahim

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Massimo Cora']

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Sébastien Granjoux wrote:

> Hi Massimo,
>
> Massimo Cora' a écrit :
>> well, that's not exact. I mean the type of the returned value is a
>> side-effect of a ctags lack. The language-support plugin should have the
>> logic to create completions, tooltips etc, just using the model provided
>> by symbol-db.
>
> Yes, but the type of the returned value is useful for completion and
> symbol-db plugin or rather ctags doesn't provide it. So how could we do
> it ?
>
> I have understood that we have to handle this outside symbol-db plugin
> and so in the language support plugin. But it could mean write another
> parser for the supported language.
>

look the problem the other way: we don't have a ctags that gives the
return type for C/C++ (currently the main language of Anjuta). If you
implement your backend for the new language X we will always remain with
the same problem of not having something good for C/C++ that do
everything in one way.

> I'm agree that it would be better to handle this in symbol-db plugin.
> But then it looks like we can have to use the idea proposed by Johannes
> and to have symbol-db backend plugin. Or do you have another idea ?
>

the problem is, IMHO, that you cannot stay without a second parser.
Think for instance to local variables in C/C++/Java. How can you get
them without a lexer/parser into language-support plugin?
Codelite IDE (C/C++) uses four grammars to achieve these tasks: an
expression
grammar, a function grammar, a variable grammar and a scope grammar.
It uses a tags database to get the global symbols and together with the
other lex/yacc parsers it can resolve an expression and give completions.
The local variables in javascript or language X exist the same, and you
must always provide a second parser.

>> Think of it as a controller+view in a MVC architecture, where the model
>> is symbol-db.
>
> I'm agree that this would be perfect, but some informations are missing
> currently.
>

true. But thinking to store everything, like local variables, into db is
impossible and even not performant.

This is particulary true for languages that don't have reflection, like
C/C++.

>
>> we can hack at ctags level, providing some useful informations like the
>> return value of a function. We would then be able to reuse the current
>> architecture without many modifications.
>
> I think your are already working on improving the C/C++ symbol support.
> You should have the same problem to know the type of a returned value by
> example. How do you plan this ?
>

I'm currently studying the code and writing some examples but it should
work like I told you before: a global symbols/functions db with the help
of grammar parsers.

> Do you plan to improve ctags to support his directly ?
>

I wanted to do it but it seems like using grammars is the easiest way.


> Have you added some code inside the symbol-db plugin ? adding additional
> information in the database (return type of a function) and using this
> in the language-support plugin to provide a more intelligent completion.
>

nope I didn't. We should hack on ctags to have such features but I
didn't touch it. Mostly because the lack of time, and secondly because
the ctags' c parser is really hard to understand. Thirdly it's likely
the ctags devs won't accept patches to implement those features. Eran
himself submitted some patches but they went uncommitted.


> Or, have you added more code inside the language-support-C++ plugin ?
> finding the return type of a function an providing the completion
>

That's my target. Maybe this week or the next I can have some example
code to do that.

regards,
Massimo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEUEARECAAYFAkn83XIACgkQcfVTgMRILk20TQCbBcFUDwQraDU4Ribr7cV9z3Vp
CzAAl2jsdKpe25E5FhmeDGCZh1QGh0o=
=jgnm
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Massimo Cora']

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Ishan Chattopadhyaya wrote:

> Hello everyone,
>
> As for Python, I get a feeling that best way to get completions could be
> to use the libraries provided by Python package (libraries like parser,
> AST etc). [As jhs mentioned in an earlier post] I believe the best
> available python IDEs at the moment use it. These libraries could be
> used through Python scripts (spawned from the language-support plugin,
> maybe), or perhaps some bindings to those libs could be used/made.
> Is there any aversion in dealing with external python scripts from the
> symbol-db module or at ctags level? If that's the case, then the libs
> could be used from the language-suppport plugin, maybe..?
>

I'm not an experienced user in python, but AFAIK symbol-db indexes the
python global symbols, like classes, methods and so on.
I think that the libraries you'll talking about use trees made of
global symbols and some parsers to match the right completions.
The key could be to understand where they use the global symbols and
where the other parsers. We should then focus on the latter ones.

regards,
Massimo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkn84DIACgkQcfVTgMRILk3a6QCfc+xW5kic3yysrGA/NsCnwUve
1ncAn0QQCLb1NLlONwvH2IAzmFJHDqX2
=4BjR
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Ishan Chattopadhyaya]

On Sun, 2009-05-03 at 02:07 +0200, Massimo Cora' wrote:

> I'm not an experienced user in python, but AFAIK symbol-db indexes the
> python global symbols, like classes, methods and so on.
> I think that the libraries you'll talking about use trees made of
> global symbols and some parsers to match the right completions.
> The key could be to understand where they use the global symbols and
> where the other parsers. We should then focus on the latter ones.
>
I think these libraries are for parsing the user python scripts and
returning a tree model for their symbols (and possibly types?).
If it works fine, maybe we might not need to write a significant parser
in the language support, rather just call these libs on the user files.

I've come across PySmell, which is an auto completion tool for python
IDEs. I have asked on some lists about how stable/production ready it
is. Can we use it if it really is good?

> regards,
> Massimo



------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Ishan Chattopadhyaya]

On Sun, 2009-05-03 at 06:14 +0530, Ishan Chattopadhyaya wrote:

> On Sun, 2009-05-03 at 02:07 +0200, Massimo Cora' wrote:
>
> > I'm not an experienced user in python, but AFAIK symbol-db indexes the
> > python global symbols, like classes, methods and so on.
> > I think that the libraries you'll talking about use trees made of
> > global symbols and some parsers to match the right completions.
> > The key could be to understand where they use the global symbols and
> > where the other parsers. We should then focus on the latter ones.
> >
> I think these libraries are for parsing the user python scripts and
> returning a tree model for their symbols (and possibly types?).
> If it works fine, maybe we might not need to write a significant parser
> in the language support, rather just call these libs on the user files.
>
> I've come across PySmell, which is an auto completion tool for python
> IDEs. I have asked on some lists about how stable/production ready it
> is. Can we use it if it really is good?

Here's the link to PySmell: http://pypi.python.org/pypi/pysmell
Could we use this from inside the language support plugin? Probably by
copying the pysmell python scripts as they are from the downloadable
distribution (pysmell-0.7) inside the language-plugin directory.
Possibly some changes to the pysmell could be needed to make it more
suitable for Anjuta. Already, pysmell comes with plugins for some other
IDEs, maybe a small patch to pysmell for anjuta support could be needed.
Is all this worth the effort? Or should I try to gather more information
on this?


------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Sébastien Granjoux]

Hi Massimo,

Massimo Cora' a écrit :
> look the problem the other way: we don't have a ctags that gives the
> return type for C/C++ (currently the main language of Anjuta). If you
> implement your backend for the new language X we will always remain with
> the same problem of not having something good for C/C++ that do
> everything in one way.

Sure, we have to do something for C/C++.


> the problem is, IMHO, that you cannot stay without a second parser.
> Think for instance to local variables in C/C++/Java.

Ok, it is just to make this clear. There are 3 parsers: one in editor
plugin (for syntax highlight), one in symbol-db plugin (in ctags) and
the last one in language-support plugin.


> nope I didn't. We should hack on ctags to have such features but I
> didn't touch it. Mostly because the lack of time, and secondly because
> the ctags' c parser is really hard to understand. Thirdly it's likely
> the ctags devs won't accept patches to implement those features. Eran
> himself submitted some patches but they went uncommitted.

Ok


> That's my target. Maybe this week or the next I can have some example
> code to do that.

It's not urgent, I just want to understand how things should work to be
able to reply to Ishan questions.

Regards,

Sébastien

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Sébastien Granjoux]

Hi All,

I looks like we really need to have a parser for Python in order to
provide the functionalities we want, the ctags parser used by symbol-db
is not enough.

I think we shouldn't write a Python parser especially if one is already
existing. It seems that we could use http://pypi.python.org/pypi/pysmell

This parser is written in Python and I don't know any parser written in
C. So there is a problem to interface Anjuta and this parser.


1. It could be done via text files:
Writing a wrapper around pysmell and make it generates a text file that
can be read later by some C code to provided the needed function. This
approach is already used by gnome build project backend which are using
perl script. The drawback is that it could be a bit slow.


2. Call the python script from C code:
Python functions can be called from C, it needs some wrapping code. I'm
a bit afraid about what's happen if you have 2 plugins using such
approach as I think the Python interpreter needs some global variables.


3. Write a plugin in Python:
I have already written all the code necessary to use in Anjuta a plugin
written in Python. I haven't spent much time on it recently but it
should still work. The issue is that the whole plugin has to be written
in Python. It means that you can write the whole language support python
plugin in Python or have to define a new interface to write a backend
plugin used by the language support plugin. I don't really see a problem
with this, but the GSOC project description mention that the plugin will
be written in C which won't be the case here.

If we go in this direction, I think we need to create another gnome
module anjuta-python or something like this including the current
libanjuta-python code. As I don't like to have Anjuta depending of python.


What do you thinks about this ?


Regards,

Sébastien

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Sébastien Granjoux]

Hi All,

I'm currently working on the replacing the gnome build project manager.

It needs to do some real parsing work and I haven't found any already
written parser. I think I will use bison and flex as they are by far the
most common. Other parser exists (ANTLR or Lemon by example) but they
don't look so much better and I'm afraid that using one of them will
make more difficult to compile Anjuta. Take care that I will request
bison and not yacc, same for flex instead of lex. Both programs get some
useful improvements, as basic as allowing to have several parsers in the
same program.

Currently, I'm more of less able to read an automake project. The
progress are really slow, so I'm sure I will not be able to write the
backend for makefile in this release cycle.

I run into some limitations imposed by the current project manager
interface. So, in Anjuta 2.28, what do you prefer ?

1. Keep the same project manager interface with the same makefile
backend and a bit improved automake backend.

2 Have an improved project manager interface with only the automake backend.


Regards,

Sébastien

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Johannes Schmid-4]

hi!

> It needs to do some real parsing work and I haven't found any already
> written parser. I think I will use bison and flex as they are by far the
> most common. Other parser exists (ANTLR or Lemon by example) but they
> don't look so much better and I'm afraid that using one of them will
> make more difficult to compile Anjuta. Take care that I will request
> bison and not yacc, same for flex instead of lex. Both programs get some
> useful improvements, as basic as allowing to have several parsers in the
> same program.

The ugly perl scripts in gnome-build actually originate from the
original automake parser which is written in perl.

> I run into some limitations imposed by the current project manager
> interface. So, in Anjuta 2.28, what do you prefer ?
>
> 1. Keep the same project manager interface with the same makefile
> backend and a bit improved automake backend.
>
> 2 Have an improved project manager interface with only the automake backend.

I would prefer the latter as the project-manager interface is not used
much inside anjuta and where it is used, the usage is usually
imcomplete. The two points where I know that it is used is the search
plugin and the symbol-db plugin. Both just query all files of the
project. Some other plugin probably add files to the project but that's
rather ugly in the moment.

I would also love if we could get some better graphical view of the
project than the current project-viewer.

Thanks for doing all the work on the project-manager!

Johannes


------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Johannes Schmid-4]

Hi!

OK, lets give the students some construtive things they can work on now.

- Let's assume the ctags parser gives us enough information about python
and javascript. Where it does not we should definitly extend it. If
ctags people do not accept our patches, we can still try to fork ctags
somehow though I would like to void that. ctags code additions should
follow the ctags style, e.g. not using external libraries and not using
anything else than standard C. I think the most important would be to
find out the return type of methods and integrate this somehow.

- For the language-support-plugin we should really try to use existing
parsers. I would prefer if those could be accessed from C but if that
doesn't seem a good idea we could also try to use some other language.
For python I would rather prefer that the whole plugin is in python and
we move the python bindings directly into the anjuta codebase,
anjuta-extras or gnome-python-extras.

The advantage for now is that we can live with the existing symbol-db
stuff while still getting a fairly good autocompletion hopefully.

Regards,
Johannes


Am Sonntag, den 03.05.2009, 10:55 +0200 schrieb Sébastien Granjoux:

> Hi All,
>
> I looks like we really need to have a parser for Python in order to
> provide the functionalities we want, the ctags parser used by symbol-db
> is not enough.
>
> I think we shouldn't write a Python parser especially if one is already
> existing. It seems that we could use http://pypi.python.org/pypi/pysmell
>
> This parser is written in Python and I don't know any parser written in
> C. So there is a problem to interface Anjuta and this parser.
>
>
> 1. It could be done via text files:
> Writing a wrapper around pysmell and make it generates a text file that
> can be read later by some C code to provided the needed function. This
> approach is already used by gnome build project backend which are using
> perl script. The drawback is that it could be a bit slow.
>
>
> 2. Call the python script from C code:
> Python functions can be called from C, it needs some wrapping code. I'm
> a bit afraid about what's happen if you have 2 plugins using such
> approach as I think the Python interpreter needs some global variables.
>
>
> 3. Write a plugin in Python:
> I have already written all the code necessary to use in Anjuta a plugin
> written in Python. I haven't spent much time on it recently but it
> should still work. The issue is that the whole plugin has to be written
> in Python. It means that you can write the whole language support python
> plugin in Python or have to define a new interface to write a backend
> plugin used by the language support plugin. I don't really see a problem
> with this, but the GSOC project description mention that the plugin will
> be written in C which won't be the case here.
>
> If we go in this direction, I think we need to create another gnome
> module anjuta-python or something like this including the current
> libanjuta-python code. As I don't like to have Anjuta depending of python.
>
>
> What do you thinks about this ?
>
>
> Regards,
>
> Sébastien

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel