Re: [Vala] bugs

["Michael Lawrence" <lawremi iastate edu>]

On 9/8/07, pancake <pancake youterm com> wrote:

On Sat, 08 Sep 2007 21:17:13 +0200
Jürg Billeter <j bitron ch> wrote:

> > The same can be applied to the -g flag
>
> Not quite, the -g tells valac to emit #line directives, for example.

Ok. Then it has sense. keep it there :)

I miss the -h flag as an --help alias. Is far more useful :) longopts are
imho a bad idea. And if available, the most important ones should be accesible
via singlechar flags.

I also miss a -v flag to see what commands are executed under valac. (f.ex gcc)

> > The only way I can understand the existence of these flags is to keep operation
> > consistence between different compilers (gcc, tcc, msvc, ...) wrapping these
> > flags to the correct syntax for the target compiler.
> >
> > BTW the best way to do this (imho) is to create another program that acts
> > as a meta-compiler wrapper for gcc/icc/.. and make valac call the meta-compiler
> > and the meta-compiler call the desired compiler with the right flags and environment
> > variables.
>
> I don't want to make half a build-system out of valac, the -X option
> should work fine the same way it does for C compilation.

Can I change the compiler used by valac?

> > A little question... is there any way to browse namespaces classes and methods?
> > a cmdline tool to query this will be nice for an IDE (or vim ;) integration for
> > method autocompletion and so.
>
> You can do that via libvala, although it's probably too slow for IDE
> integration right now as it has to parse the VAPI files every time -
> unless you just keep the symbol tree in memory. A binary - possibly
> mmap-able - cache file might make sense here.

Is there any introspection api for doing it at runtime offering a dbus service
for querying?

BTW a 'valadoc' tool would be cool :) I think this can be done hacking a bit on
the valac parser code to avoid dupping the parser code.

It would probably be best to base this on gtk-doc. A thin wrapper to handle the special constructs in Vala may be all that is needed.

Another question. Are you planning to add any scripting facility for Vala?

Something like a SWIG interface generator for different scripting languages
that emits vala code to implement the native interface to bridge the
script engine and the core application.

This way it will be somewhat easy to make a Vala application be extended with
python, perl, _javascript_, lua, php or whatever else.

Since Vala outputs GObject-based code, the same infrastructure developed for GObject-based library bindings (eg GTK+) can be used. Of course, the C headers will lack information (regarding memory ownership, in/out params, etc) that is present in the VAPI files. I believe a VAPI -> GIDL converter is on the TODO list. It shouldn't take too much work to port the existing GObject binding generation systems, based on formats like GAPI and defs, to GIDL, which should be promoted as the standard interface description for GObject-based APIs.

Michael

  --pancake
_______________________________________________
Vala mailing list
Vala paldo org
http://www.paldo.org/mailman/listinfo/vala