Re: [Vala] Vala Bugfix Hackathon (was: when will vala 0.8 be released?)
On Mon, 2009-11-30 at 20:25 +0100, Michael 'Mickey' Lauer wrote: Am Freitag, den 20.11.2009, 17:36 +0100 schrieb Michael 'Mickey' Lauer: How can we move on with the hackathon? I guess the central question is who apart from Jürg (who seems to be very busy these days) has the knowledge to educate us how to fix certain things in an upstream-acceptable way? These people are critical to such a hackathon, hence we need them to dictate a date that would work. Okay, if noone of the elders are volunteering to help us moving Vala forward, then this pretty much kills the idea of the hackathon. I was/am quite busy (and one week abroad) in November and December due to customer projects, however, it should be better in January and beyond. I really like the idea of a hackathon and we should try to find a date/time in January for this. If it is supposed to happen during the day European time, I will only be able to actively participate if it's at a weekend. If it is just an evening, during the week should be ok for me as well. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Methods/ctors overloading
On Mon, 2009-11-30 at 14:01 -0500, Andrés G. Aragoneses wrote: Abderrahim Kitouni escribió: 2009/11/30 Andrés G. Aragoneses kno...@gmail.com: Replying to myself: Andrés G. Aragoneses escribió: Hello. I'm wondering if the difference between Vala and C# wrt method/ctor overloading is intentional or is its real support planned in It's intentional, one of the main goals of vala is to have libraries that can be used from C. So methods must have sensible names (i.e. name mangling is not an option) btw, Vala has named creation methods (a.k.a. named constructors) so there is no need for overloading (Yes, it would be useful but not necessary) Useful but not necessary, I agree. So this is why, if I were to help providing a patch for this, I would make ctor overloading an option, not dropping support for named constructors. Would that be acceptable? Thanks for offering to work on this, however, I'd like to avoid method/constructor overloading at the moment. In addition to various potential issues with overloading¹ Vala is currently in a stabilization period. No fundamental semantic change as in your proposal will enter master in the near future. Jürg ¹ e.g., confusing effects on differing implementations of overloaded methods and complex method resolution as the combination of default arguments and method overloading can lead to conflicts, the mentioned issue of mapping to C identifiers ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] precompiled vapis
On Fri, 2009-11-27 at 12:20 +0100, Marc-André Lureau wrote: On Fri, Nov 27, 2009 at 12:15 PM, pancake panc...@youterm.com wrote: I was playing around gtk and curses and noticed a huge different in compile times which I think it is caused because of the size of gtk+-2.0.vapi compared to curses.vapi. It will be nice to be able to precompile those .vapis in a binary form, so Vala can directly load the AST instead of having to parse it. What do you think about it? Switching to gir might speed up things, especially if vala supports the typelib format. I would go into that direction instead, if it's possible. As far as I can tell, parsing itself does not appear to be the limiting factor, creating and resolving the AST is. I have some ideas how to improve the situation by lazily creating the AST, however, bug fixing appears to be more important right now. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
