07.04.2011 19:53, intrigeri пишет:
> There are dozens of other programming languages' "About" pages that
> list their advantages and pretty valid reasons you could choose them
> against Vala.
No problem, I can re-phrase using my own words :)
Vala id the language made by gnome developers for gnome developers (just like gdm
itself) so I expect it to be always supported and well maintained {1}. It is also
"compiles" directly to C source code so it will not bring any run-time dependencies
(less resources to use, no need to track library versions carefully). {2}
For example things like pygtk -> pygobject migration should be easier with vala:
http://www.johnstowers.co.nz/blog/index.php/2011/04/03/end-of-an-era-pygtk/
In terms of syntax it is pretty-much comparable to python\perl.
>> Also it looks like it will be more fun to work with.
>
> Ah. This I can hear :)
{3} :)
Downside of choosing vala is that it is less familiar [1].
I do agree that all {1}, {2}, {3} doesn't seem like a big deal. But so do [1].
That's why I think vala is preferred.
> 1. Does use Python (one of the package in the build-deps tree is
> probably written in Python); I agree this is somewhat irrelevant
> since the gdm3 packaging does not need to deal with Python
> versionning and dependencies itself.
Agree.
> 2. Does not use Vala at all. It seems to me the Vala language is still
> evolving, backward compatibility has been broken a few times
> between the 1-year-old version shipped in Debian Squeeze and the
> most recent upstream one => you'll have to track the appropriate
> version and significantly change the build process using Vala as
> well.
I doubt that significant changes will be required but I do not have solid argument to
back this claim up until I have custom build env. up and running.
> => I wonder why you're so damn sure using Python (or Perl, or
> whatever) would be more of a maintenance burden than using Vala.
Discussed above.
> Anyway, you need to take into account that it would be much, much,
> much better if you could implement tails-greeter in a way that does
> *not* force us to ship a modified gdm3 package.
I do not see how this could be done regardless of programming language:
gdm-simple-greeter is not in separate .deb so replacing it with tails-greeter will
force us to rebuild gdm .deb, isn't it?
>>> What are the obstacles that prevent you from implementing
>>> tails-greeter in Perl? Missing bindings? Binding on CPAN but not in
>>> Debian? Other issues?
Things like
http://live.gnome.org/GTK2-Perl/FrequentlyAskedQuestions#Everything_hangs_at_Gtk2-.3Einit_or_Gtk2_.27-init.27_.2BAC8_What.27s_up_.27make_test.27_just_stops_as_soon_as_it_starts
seems kind of scary.
Of course it could be worked-around but I do not see any feature in gtk2-perl which
is so remarkable that it will justify efforts to do so.
> I'm confused. You told us "I think I'm mostly proficient in C\C++ and
> Perl" and the only Perl program you produce (after I asked twice for
> it) is a 40 lines script "derived from some post forum". The code is
> good, sure, but what do you think I can infer from your Perl skills
> and experience, based on this?
This misunderstanding is probably my fault: most of my perl projects are just bunch
of small scripts - I never produced any .pl bigger than 400 loc. In fact, I've
actively tried to avoid working with big perl files: splitting task into dozen of
small more or less independent scripts always worked for me.
cheers,
Max.
