[Vala] POSIX and Dova profiles
Hi, valac has had experimental support to build applications without GLib for a while now. However, the POSIX profile still supports only a subset of the language and there is no indication that this will change anytime soon. I'm still working on the experiment that started with Dova, but the differences to Vala/GObject have grown to a point that it no longer makes sense to maintain both compilers in the same repository. Is anyone actively using either of these two profiles despite their limitations? If that is not the case, I'd be in favor of dropping them from master and keeping the focus on GLib/GObject. Any comments? Regards, Jürg ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] POSIX and Dova profiles
Vala is always marketed as being integrated with GObject, which I think is advantage - IMO to make product consistent team should focus on Vala/GObject. m. 2012/8/3 Jürg Billeter j...@bitron.ch: Hi, valac has had experimental support to build applications without GLib for a while now. However, the POSIX profile still supports only a subset of the language and there is no indication that this will change anytime soon. I'm still working on the experiment that started with Dova, but the differences to Vala/GObject have grown to a point that it no longer makes sense to maintain both compilers in the same repository. Is anyone actively using either of these two profiles despite their limitations? If that is not the case, I'd be in favor of dropping them from master and keeping the focus on GLib/GObject. Any comments? Regards, Jürg ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
[Vala] R: Re: R: POSIX and Dova profiles
Hi Andrea, Hi, On Fri, 2012-08-03 at 11:12 +0200, sejerpz@tin. it wrote: What I really, really like would be the implementation of light classes on the Posix profile (in the spirit of [1]) with support for: * Single inheritance * Interfaces * Properties and may be later: * Signals I don't know if all of this is really feasible, but reading the dova sources it seems that the first 3 features are very simple to implement and light enough to be used on some embedded hardware (not really an expert here ;) ) As there are various ways to implement this on top of POSIX/C, classes and interfaces defined using the POSIX profile would not be compatible with types from existing libraries. This means that we'd essentially Yes, but sometimes C interoperability is all that is needed when a micro is really... micro :) define a new platform. However, without a runtime library, it would not be very convenient to use that platform. I agree with you and I've to say that and I'm not an embedded system expert (I just wrote some bounce of code for work, when I was younger ;) in C and assembly for some micros, but today it's just an hobby). But I think having classes and some more oop machinery will be also useful in micros with very low resources (32-64Kb of memory), where of course a full framework doesn't make any sense (nor a rich string class etc...) In my opinion, the continuation of the Dova experiment will be better suited for embedded hardware (where you can't or don't want to use GLib). It will support interfaces and it will allow embedding the needed bits of the runtime library into the executable without making the executable larger than necessary. I agree, but taking Dova as a reference I think that should be usable with the bare minimum. For example why Uri, Node, ArrayList, List are member of the dova-base lib? One hypothetical library should include just the minimum to implement classes, interfaces and signal, leaving all the rest, and I mean also rich string classes or other enanched datatypes, to the upper layers. The syntax won't be identical to Vala but as code typically cannot be reused between Vala/GObject and Vala/POSIX either, I don't expect this to be a big issue. Will still be a C based language? A lot of people are used to C in micro land ;) (On a side note I'm not sure that I like the result = blah of the dova profile, it reminds me vb6 when you have to write funcion_name = blah, and I think that return blah is still better and more clear) Regards, Jürg Regards, Andrea P.S. Now I included also the vala- list... Do I already said that I hate this web email client? ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] R: Re: R: POSIX and Dova profiles
On Fri, 2012-08-03 at 16:12 +0200, seje...@tin.it wrote: But I think having classes and some more oop machinery will be also useful in micros with very low resources (32-64Kb of memory), where of course a full framework doesn't make any sense (nor a rich string class etc...) In my opinion, the continuation of the Dova experiment will be better suited for embedded hardware (where you can't or don't want to use GLib). It will support interfaces and it will allow embedding the needed bits of the runtime library into the executable without making the executable larger than necessary. I agree, but taking Dova as a reference I think that should be usable with the bare minimum. For example why Uri, Node, ArrayList, List are member of the dova-base lib? One hypothetical library should include just the minimum to implement classes, interfaces and signal, leaving all the rest, and I mean also rich string classes or other enanched datatypes, to the upper layers. Unused parts of the library will not have any impact on the size of the binary in the current plan. The syntax won't be identical to Vala but as code typically cannot be reused between Vala/GObject and Vala/POSIX either, I don't expect this to be a big issue. Will still be a C based language? A lot of people are used to C in micro land ;) Are you referring to a C backend or to C-like syntax? (On a side note I'm not sure that I like the result = blah of the dova profile, it reminds me vb6 when you have to write funcion_name = blah, and I think that return blah is still better and more clear) The current plan is to move back to return statements, although possibly with a caveat that the return will not be allowed to act as an arbitrary jump. Jürg ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] R: Re: R: POSIX and Dova profiles
On Fri, Aug 3, 2012 at 5:26 PM, Jürg Billeter j...@bitron.ch wrote: On Fri, 2012-08-03 at 16:12 +0200, seje...@tin.it wrote: But I think having classes and some more oop machinery will be also useful in micros with very low resources (32-64Kb of memory), where of course a full framework doesn't make any sense (nor a rich string class etc...) In my opinion, the continuation of the Dova experiment will be better suited for embedded hardware (where you can't or don't want to use GLib). It will support interfaces and it will allow embedding the needed bits of the runtime library into the executable without making the executable larger than necessary. I agree, but taking Dova as a reference I think that should be usable with the bare minimum. For example why Uri, Node, ArrayList, List are member of the dova-base lib? One hypothetical library should include just the minimum to implement classes, interfaces and signal, leaving all the rest, and I mean also rich string classes or other enanched datatypes, to the upper layers. Unused parts of the library will not have any impact on the size of the binary in the current plan. How will this be achieved? Dead function elimination by the C compiler and multiple static libraries like in Dova? The syntax won't be identical to Vala but as code typically cannot be reused between Vala/GObject and Vala/POSIX either, I don't expect this to be a big issue. Will still be a C based language? A lot of people are used to C in micro land ;) Are you referring to a C backend or to C-like syntax? C-like syntax ;) , but I think that the C backend will remain right? (On a side note I'm not sure that I like the result = blah of the dova profile, it reminds me vb6 when you have to write funcion_name = blah, and I think that return blah is still better and more clear) The current plan is to move back to return statements, although possibly with a caveat that the return will not be allowed to act as an arbitrary jump. Cool, what will substitute the arbitrary jump then? Jürg Thanks for the info. Regards, Andrea ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] R: Re: R: POSIX and Dova profiles
On Fri, 2012-08-03 at 17:42 +0200, Andrea Del Signore wrote: On Fri, Aug 3, 2012 at 5:26 PM, Jürg Billeter j...@bitron.ch wrote: Unused parts of the library will not have any impact on the size of the binary in the current plan. How will this be achieved? Dead function elimination by the C compiler and multiple static libraries like in Dova? At least one possibility will be to directly build from library sources and application sources, in which case dead code will not even generate C code. This will not only eliminate unused classes but also unused methods of used classes. In case you're wondering, the base library will have a permissive license (MIT/BSD). Are you referring to a C backend or to C-like syntax? C-like syntax ;) , but I think that the C backend will remain right? It will still use braces but the syntax will be closer to Go in some aspects. The initial release is expected to contain a C backend, which I expect to stay around. However, the compiler is designed to make it relatively easy to add other backends for LLVM IR or even machine code. (On a side note I'm not sure that I like the result = blah of the dova profile, it reminds me vb6 when you have to write funcion_name = blah, and I think that return blah is still better and more clear) The current plan is to move back to return statements, although possibly with a caveat that the return will not be allowed to act as an arbitrary jump. Cool, what will substitute the arbitrary jump then? The usual control flow statements such as 'if' and 'switch'. The return statement will simply have to be at a point where the succeeding block is already the exit block. Jürg ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Single instance...
When I try to run this code show error Violación de segmento. Any
ideas to fix it?
I want to run a single instance of my app.
//valac valac --pkg unique-1.0
using Unique;
int main(string[] args){
Unique.App app = new Unique.App(org.centinela.unique, null);
//Error here!
if(app.is_running) {
print(is running... take arguments and do something...\n);
return 0;
}
print(OK, no problem\n);
return 0;
}
smime.p7s
Description: Firma criptográfica S/MIME
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] POSIX and Dova profiles
I'm not sure what gaps in gobject that Dova is supposed to fill in. But is it possible to improve gobject to incorporate those features? Perhaps the vala team can make suggestion to the glib team. Sorry if my suggestion is naive. Nice day Nor Jaidi Tuah ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
