Re: Using vala in GNOME

[Kjartan Maraas]

on., 09.07.2008 kl. 08.25 +, skrev Stef:
> Stef wrote:
> > Kjartan Maraas wrote:
> >> Well the objections were raised and still the code is in svn. This hit
> >> me today when trying to build with jhbuild and we need to make a
> >> decision whether vala is blessed as a dependency or not. I don't
> >> personally have anything against this but I think the vala maintainers
> >> need to chime in with some kind of guarantees for stability etc.
> >>
> >> Frederic added vala as a tarball to the modulesets so people can build
> >> it to make seahorse build, but didn't add the dep yet.
> > 
> > Hmm, I built seahorse module on a machine without vala, immediately
> > after checking it in in order to test this. What are the messages you
> > experienced when building without vala? That would help fix that bug.
> 
> I've found a few problems, which I've fixed. My autofoo wasn't
> completely correct for all corner cases. In addition 'make clean'
> deleted some generated C code, and obviously with that gone, seahorse
> would not build on machines without vala. These are now fixed in SVN.
> 
> I'm eager to hear of any other problems building seahorse. The goal (at
> least for the time being) is certainly to have it buildable without
> vala. Apologies for the inconvenience this has caused.
> 
Thank you very much for fixing these up. I'll leave the rest of the
discussion up to those who actually have a stake in it :-)

Cheers
Kjartan


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Stef]

Stef wrote:
> Kjartan Maraas wrote:
>> Well the objections were raised and still the code is in svn. This hit
>> me today when trying to build with jhbuild and we need to make a
>> decision whether vala is blessed as a dependency or not. I don't
>> personally have anything against this but I think the vala maintainers
>> need to chime in with some kind of guarantees for stability etc.
>>
>> Frederic added vala as a tarball to the modulesets so people can build
>> it to make seahorse build, but didn't add the dep yet.
> 
> Hmm, I built seahorse module on a machine without vala, immediately
> after checking it in in order to test this. What are the messages you
> experienced when building without vala? That would help fix that bug.

I've found a few problems, which I've fixed. My autofoo wasn't
completely correct for all corner cases. In addition 'make clean'
deleted some generated C code, and obviously with that gone, seahorse
would not build on machines without vala. These are now fixed in SVN.

I'm eager to hear of any other problems building seahorse. The goal (at
least for the time being) is certainly to have it buildable without
vala. Apologies for the inconvenience this has caused.

Cheers,
Stef

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Stef]

Kjartan Maraas wrote:
> Well the objections were raised and still the code is in svn. This hit
> me today when trying to build with jhbuild and we need to make a
> decision whether vala is blessed as a dependency or not. I don't
> personally have anything against this but I think the vala maintainers
> need to chime in with some kind of guarantees for stability etc.
> 
> Frederic added vala as a tarball to the modulesets so people can build
> it to make seahorse build, but didn't add the dep yet.

Hmm, I built seahorse module on a machine without vala, immediately
after checking it in in order to test this. What are the messages you
experienced when building without vala? That would help fix that bug.

The objections were as to the stability of vala's interfaces, and these
did not play into the use in seahorse. If required I can revert the vala
code commited to seahorse.

The commit represents a few thousand lines of C code. It'd certainly be
a set back for seahorse meeting 2.24 goals, but not the end of the world.

Cheers,
Stef Walter

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Kjartan Maraas]

sø., 29.06.2008 kl. 22.02 +, skrev Stef:
> I've been implementing some parts of seahorse (and maybe soon
> gnome-keyring) in Vala.
> 
> http://live.gnome.org/Vala
> 
> I'm assuming this is an acceptable thing for a gnome module to do, as it
> adds no new dependencies (build-time or run-time).
> 
> However it does add a 'hacking' dependency. That is, obviously if
> someone wants to get involved in those portions of seahorse that are
> written in vala, they'd need to build vala (which is easy to do).
> 
> I believe this is an acceptable tradeoff, since seahorse and
> gnome-keyring have most of their code contributed by a small number of
> people ... and using vala speeds up development for that small number of
> people.
> 
> Barring any objections, the next release of seahorse will contain some
> vala code.
> 
Well the objections were raised and still the code is in svn. This hit
me today when trying to build with jhbuild and we need to make a
decision whether vala is blessed as a dependency or not. I don't
personally have anything against this but I think the vala maintainers
need to chime in with some kind of guarantees for stability etc.

Frederic added vala as a tarball to the modulesets so people can build
it to make seahorse build, but didn't add the dep yet.

Cheers
Kjartan


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Dave Neary]

Hi,

Johan Dahlin wrote:
> CMake *is* considerably better. Xcode/VisualStudio are killer features
> which alone would make a switch worth it.

As one of the (few?) people around here who's been involved in a project
which used CMake as a build system (OpenWengo), I have a little more to
add than this.

Indeed, for a cross-platform project, CMake is great, it generates a
variety of build scripts.

However, in my experience it had one major weakness on Linux systems -
it had no means of versioning library dependencies (apart from those
using pkgconfig, with a custom CMake module). Given that lots of
different distributions and build environments exist in Linux, this was
one of the things I quite liked in autotools - even if it was a bit
hacky at times.

One guy working on the team got so sick of copying & pasting the same
thing everywhere that he even wrote his own system of macros:
http://dev.openwengo.org/trac/openwengo/trac.fcgi/wiki/OWBuild to
provide things like "inheritance" of libraries and linker flags.

I'm not saying that any of this is fatal, but perhaps the grass is
greener, and a little more reflection is required (as Johan suggested,
seeing what went well & badly with KDE's migration would be a good start).

Cheers,
Dave.

-- 
Dave Neary
GNOME Foundation member
[EMAIL PROTECTED]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Johan Dahlin]

Jason D. Clinton wrote:
On Mon, Jun 30, 2008 at 9:47 AM, Gustavo J. A. M. Carneiro 
<[EMAIL PROTECTED] > wrote:

[..]
I watched the CMake transition in KDE with interest. It was very painful 
for them. A search of Planet KDE for the word "cmake" will return no end 
of complaints about it.


That should not be an argument against CMake as we have the chance to from 
their experiences before we start doing a migration.



IMO, the only hope that we can get away from autofoo is the Quagmire effort.


Quagmire would be another option to evaluate.
Could you download it and check if it would meet the (still somewhat fuzzy) 
requirements described on the wiki page Alberto just required?


Johan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Johan Dahlin]

Gustavo J. A. M. Carneiro wrote:

On Mon, 2008-06-30 at 15:07 +0100, Alberto Ruiz wrote:

[..]


Plus, CMake is getting more mature and stable and it already supports
VisualStudio and XCode project files conversion, lack of proper
extensibility being its only downside at the moment.


Lack of extensibility, and use of another arcane custom made programming
language (if we can call it that) for everything.

No, CMake is not an answer.  It is not significantly better than
autotools to justify a switch to it IMHO.


CMake *is* considerably better. Xcode/VisualStudio are killer features which 
alone would make a switch worth it.


Can we please start to organize ourselves and try to move forward with 
switching to another build system?


Proposal:
- Decide features we need to do a migrate
- Create a table of proposed build systems x features
- Check the KDE build system migration and see what we can learn[1]
- An obvious option will eventually appear
- Start migrate some modules

[1]: Tim has some notes on this: 
http://blogs.gnome.org/timj/2008/06/02/02062008-linuxtag-2008/


Johan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Stef]

Interesting. That's a very valid concern.

Although this is a decidedly different case. Vala is used to generate C
code for parts of seahorse. This C code is then checked into the
repository, and included in the tarballs, so that people can build it
without vala.

Said another way, the idea is that this won't affect the build process
of GNOME in any way.

In addition Vala API stability is only about 3 months from stable:
http://live.gnome.org/Vala/RoadMap

But again this isn't being used as a dependency. It's being used as a
tool for quickly generating tedious GObject C code.

Cheers,

Stef Walter

Bastien Nocera wrote:
> On Sun, 2008-06-29 at 22:02 +, Stef wrote:
>> I've been implementing some parts of seahorse (and maybe soon
>> gnome-keyring) in Vala.
> 
>> Barring any objections, the next release of seahorse will contain some
>> vala code.
> 
> I object. Given that I see people filing bugs against Totem whenever the
> Vala API changes (which is, since Totem got Vala plugin support, about 3
> times) we have to make changes.
> 
> I'd rather we only added Vala as a core dependency when its API is
> actually stable.
> 
> 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Loïc Minier]

On Tue, Jul 01, 2008, Josselin Mouette wrote:
> > and the build
> > system should rebuild the C code when the .vala files have changed,
> > similar to how other generated files are handled.
> 
> This does not. Magic rules to rebuild stuff that is not supposed to
> change when you use a tarball often fail miserably when you use a patch
> system over the sources. This is why we set AM_MAINTAINER_MODE wherever
> possible.

 Well it's the same issue we have with all generated files when
 AM_MAINTAINER_MODE isn't used, sadly.

-- 
Loïc Minier
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Loïc Minier]

On Tue, Jul 01, 2008, Josselin Mouette wrote:
> And don’t forget downstream. If patching the code requires grabbing the
> Vala file from the SVN, regenerate the C code and then diff it, it is
> going to be a big pain for us, while a new build-dependency on valac is
> trivial to deal with.

 I do hope that vala files are being redistributed in all cases, just
 like configure.in, Makefile.am and the like.  All the real sources
 should be for sure.

-- 
Loïc Minier
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Jürg Billeter]

On Tue, 2008-07-01 at 11:32 +0200, Josselin Mouette wrote:
> Le mardi 01 juillet 2008 à 10:49 +0200, Jürg Billeter a écrit :
> > and the build
> > system should rebuild the C code when the .vala files have changed,
> > similar to how other generated files are handled.
> 
> This does not. Magic rules to rebuild stuff that is not supposed to
> change when you use a tarball often fail miserably when you use a patch
> system over the sources. This is why we set AM_MAINTAINER_MODE wherever
> possible.

It should certainly be possible to guard the valac calls with

if MAINTAINER_MODE

I'm not a huge fan of maintainer mode but it probably makes sense to use
it for valac rules to get the same behavior as with other generated
files.

Jürg

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Josselin Mouette]

Le mardi 01 juillet 2008 à 10:49 +0200, Jürg Billeter a écrit :
> The tarball should also contain the .vala source files

This sounds OK, we can manage them like the autotools files with quilt.

> and the build
> system should rebuild the C code when the .vala files have changed,
> similar to how other generated files are handled.

This does not. Magic rules to rebuild stuff that is not supposed to
change when you use a tarball often fail miserably when you use a patch
system over the sources. This is why we set AM_MAINTAINER_MODE wherever
possible.

Cheers,
-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Jürg Billeter]

On Tue, 2008-07-01 at 10:08 +0200, Josselin Mouette wrote:
> Le mardi 01 juillet 2008 à 10:30 +1200, Callum McKenzie a écrit :
> > As an aside: ultimately it will be necessary to move it from a hacking
> > dependency to a build dependency. Novice developers work from tarballs,
> > not SVN and you will get patches against your generated code appearing
> > in bugzilla.
> 
> And don’t forget downstream. If patching the code requires grabbing the
> Vala file from the SVN, regenerate the C code and then diff it, it is
> going to be a big pain for us, while a new build-dependency on valac is
> trivial to deal with.

The tarball should also contain the .vala source files and the build
system should rebuild the C code when the .vala files have changed,
similar to how other generated files are handled. Does this sound ok?

Jürg

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Jan de Groot]

On Tue, 2008-07-01 at 10:08 +0200, Josselin Mouette wrote:
> Le mardi 01 juillet 2008 à 10:30 +1200, Callum McKenzie a écrit :
> > As an aside: ultimately it will be necessary to move it from a hacking
> > dependency to a build dependency. Novice developers work from tarballs,
> > not SVN and you will get patches against your generated code appearing
> > in bugzilla.
> 
> And don’t forget downstream. If patching the code requires grabbing the
> Vala file from the SVN, regenerate the C code and then diff it, it is
> going to be a big pain for us, while a new build-dependency on valac is
> trivial to deal with.

What about making it optional and making clear that source file foo.c is
a generated copy from vala sources that shouldn't be changed. If valac
is found, regenerate the sources, even when building from tarball.
We don't require aclocal/autoconf/automake for tarball releases either
at this moment, but you're allowed to rebuild configure and Makefile.in
by running aclocal/autoconf/automake from tarball releases.


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Josselin Mouette]

Le mardi 01 juillet 2008 à 10:30 +1200, Callum McKenzie a écrit :
> As an aside: ultimately it will be necessary to move it from a hacking
> dependency to a build dependency. Novice developers work from tarballs,
> not SVN and you will get patches against your generated code appearing
> in bugzilla.

And don’t forget downstream. If patching the code requires grabbing the
Vala file from the SVN, regenerate the C code and then diff it, it is
going to be a big pain for us, while a new build-dependency on valac is
trivial to deal with.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Callum McKenzie]

Mathias Hasselmann wrote:

> Just that gob wasn't half as ambitious as Vala. gob took some kind of
> minimum effort approach which lead to the effect that you were mixing
> high-level gob and low-level C code all the time. This just felt flaky
> and hackish.

I used gob with gnome-games for a while (in exactly the same way that
Vala is proposed for Seahorse, but I didn't ask before-hand). Then I
stopped and converted the files back to ordinary C. The reason I did
this was not because of gob's hackish nature - it still achieved its
goal of being less work to write a gobject than plain C - but because of
its obscurity. At the end of the day, expecting people to learn a new
language just to contribute to the code-base was unreasonable.

Vala's advantages over gob are two-fold: a) it looks even more like
languages people are familiar with than gob does and b) it is being
promoted more heavily than gob ever was. I hope it does succeed, and
despite having a lot of sympathy for Bastien's wait-for-1.0 attitude, I
think it should be tried sooner rather than later, otherwise it will
suffer gob's fate.

As an aside: ultimately it will be necessary to move it from a hacking
dependency to a build dependency. Novice developers work from tarballs,
not SVN and you will get patches against your generated code appearing
in bugzilla.

 - Callum

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[natan yellin]

2008/6/30 Alberto Ruiz <[EMAIL PROTECTED]>:

>
>
> 2008/6/30 Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]>:
>
>> On Mon, 2008-06-30 at 15:07 +0100, Alberto Ruiz wrote:
>> >
>> >
>> > 2008/6/30 Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]>:
>> >
>> >
>> > An excellent reason to switch to a more modular build system,
>> > one that
>> > does not require patching the core in order to extend it.
>> >
>> > Something like... WAF :-)
>> >
>> > Well, after some time evaluating waf, there's something that I don't
>> > quite like about it and that I don't see changing anytime soon.
>> >
>> > During its development cycle last year trunk has been broken a few
>> > times, api has changed and the Tools modules to support gnome features
>> > have stopped working. Last time I checked, it lacks a proper test
>> > suite to avoid regression on supported tools.
>> >
>> > There's no difference between well supported features and unstable
>> > ones, so people using those extensions don't know what sort of
>> > stability they should spect.
>> >
>> > As we talk, the gnome demo at trunk is broken, a situation that I've
>> > seen more times than I would like too:
>> >   File "/home/aruiz/src/waf-read-only/demos/gnome/wscript", line 6, in
>> > 
>> > import Params, intltool, gnome
>> > ImportError: No module named Params
>> >
>> > Yes, I think that waf has a lot of potential, and eventually it would
>> > be the way to go, but without a significant change of direction in the
>> > way it is maintained, I don't see GNOME changing to it anytime soon.
>>
>> Yes, I wholehartedly agree.  I periodically discuss these things with
>> the maintainer, to try to change his habits, but it's no use :(
>>
>> Ideally we would need a fork of WAF, with a maintainer that understands
>> how software cycles should work.  However, the current maintainer is a
>> good developer (if not a good maintainer) and would be a shame to lose
>> his contributions, on one hand, and no one else has time to maintain a
>> fork of WAF, on the other hand.
>>
>
> My gut feeling is that he's not aware that such things have such a big
> impact, and maybe we have a hard time to explain him what the concrete
> problems actually are, maybe if we list down concrete examples of which
> practices would be needed to adopt within the waf development model he will
> change his mind.
>
Perhaps drop him a link to Producing OSS  as a
hint? I've seen it pull wonders.

>
> Please, use the wiki page to list every concerns and advantages that you
> found with waf and CMake
>
>
>>
>> The solution I come up with now is to just freeze the WAF version I use.
>> Fortunately, things like vala support can be done on top, rather than
>> within, WAF, so it's not hard to stabilize on a WAF version for a very
>> long time.
>>
>> > Plus, CMake is getting more mature and stable and it already supports
>> > VisualStudio and XCode project files conversion, lack of proper
>> > extensibility being its only downside at the moment.
>>
>> Lack of extensibility, and use of another arcane custom made programming
>> language (if we can call it that) for everything.
>>
>> No, CMake is not an answer.  It is not significantly better than
>> autotools to justify a switch to it IMHO.
>>
>> --
>> Gustavo J. A. M. Carneiro
>> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
>> "The universe is always one step beyond logic" -- Frank Herbert
>>
>>
>
>
> --
> Un saludo,
> Alberto Ruiz
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Jason D. Clinton]

On Mon, Jun 30, 2008 at 9:47 AM, Gustavo J. A. M. Carneiro <
[EMAIL PROTECTED]> wrote:

> > Plus, CMake is getting more mature and stable and it already supports
> > VisualStudio and XCode project files conversion, lack of proper
> > extensibility being its only downside at the moment.
>
> Lack of extensibility, and use of another arcane custom made programming
> language (if we can call it that) for everything.
>
> No, CMake is not an answer.  It is not significantly better than
> autotools to justify a switch to it IMHO.


I watched the CMake transition in KDE with interest. It was very painful for
them. A search of Planet KDE for the word "cmake" will return no end of
complaints about it.

IMO, the only hope that we can get away from autofoo is the Quagmire effort.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Étienne BERSAC]

Hi,

I do fully agree with you Alberto. Autotools has some drawback that
can't be fixed without replacing it, but current alternative seems not
to provide feature parity with autotools.

Regards,
Étienne.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Alberto Ruiz]

2008/6/30 Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]>:

> On Mon, 2008-06-30 at 15:07 +0100, Alberto Ruiz wrote:
> >
> >
> > 2008/6/30 Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]>:
> >
> >
> > An excellent reason to switch to a more modular build system,
> > one that
> > does not require patching the core in order to extend it.
> >
> > Something like... WAF :-)
> >
> > Well, after some time evaluating waf, there's something that I don't
> > quite like about it and that I don't see changing anytime soon.
> >
> > During its development cycle last year trunk has been broken a few
> > times, api has changed and the Tools modules to support gnome features
> > have stopped working. Last time I checked, it lacks a proper test
> > suite to avoid regression on supported tools.
> >
> > There's no difference between well supported features and unstable
> > ones, so people using those extensions don't know what sort of
> > stability they should spect.
> >
> > As we talk, the gnome demo at trunk is broken, a situation that I've
> > seen more times than I would like too:
> >   File "/home/aruiz/src/waf-read-only/demos/gnome/wscript", line 6, in
> > 
> > import Params, intltool, gnome
> > ImportError: No module named Params
> >
> > Yes, I think that waf has a lot of potential, and eventually it would
> > be the way to go, but without a significant change of direction in the
> > way it is maintained, I don't see GNOME changing to it anytime soon.
>
> Yes, I wholehartedly agree.  I periodically discuss these things with
> the maintainer, to try to change his habits, but it's no use :(
>
> Ideally we would need a fork of WAF, with a maintainer that understands
> how software cycles should work.  However, the current maintainer is a
> good developer (if not a good maintainer) and would be a shame to lose
> his contributions, on one hand, and no one else has time to maintain a
> fork of WAF, on the other hand.
>

My gut feeling is that he's not aware that such things have such a big
impact, and maybe we have a hard time to explain him what the concrete
problems actually are, maybe if we list down concrete examples of which
practices would be needed to adopt within the waf development model he will
change his mind.

Please, use the wiki page to list every concerns and advantages that you
found with waf and CMake


>
> The solution I come up with now is to just freeze the WAF version I use.
> Fortunately, things like vala support can be done on top, rather than
> within, WAF, so it's not hard to stabilize on a WAF version for a very
> long time.
>
> > Plus, CMake is getting more mature and stable and it already supports
> > VisualStudio and XCode project files conversion, lack of proper
> > extensibility being its only downside at the moment.
>
> Lack of extensibility, and use of another arcane custom made programming
> language (if we can call it that) for everything.
>
> No, CMake is not an answer.  It is not significantly better than
> autotools to justify a switch to it IMHO.
>
> --
> Gustavo J. A. M. Carneiro
> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
> "The universe is always one step beyond logic" -- Frank Herbert
>
>


-- 
Un saludo,
Alberto Ruiz
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Gustavo J. A. M. Carneiro]

On Mon, 2008-06-30 at 15:07 +0100, Alberto Ruiz wrote:
> 
> 
> 2008/6/30 Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]>:
> 
> 
> An excellent reason to switch to a more modular build system,
> one that
> does not require patching the core in order to extend it.
> 
> Something like... WAF :-)
> 
> Well, after some time evaluating waf, there's something that I don't
> quite like about it and that I don't see changing anytime soon.
> 
> During its development cycle last year trunk has been broken a few
> times, api has changed and the Tools modules to support gnome features
> have stopped working. Last time I checked, it lacks a proper test
> suite to avoid regression on supported tools.
> 
> There's no difference between well supported features and unstable
> ones, so people using those extensions don't know what sort of
> stability they should spect.
> 
> As we talk, the gnome demo at trunk is broken, a situation that I've
> seen more times than I would like too:
>   File "/home/aruiz/src/waf-read-only/demos/gnome/wscript", line 6, in
> 
> import Params, intltool, gnome
> ImportError: No module named Params
> 
> Yes, I think that waf has a lot of potential, and eventually it would
> be the way to go, but without a significant change of direction in the
> way it is maintained, I don't see GNOME changing to it anytime soon.

Yes, I wholehartedly agree.  I periodically discuss these things with
the maintainer, to try to change his habits, but it's no use :(

Ideally we would need a fork of WAF, with a maintainer that understands
how software cycles should work.  However, the current maintainer is a
good developer (if not a good maintainer) and would be a shame to lose
his contributions, on one hand, and no one else has time to maintain a
fork of WAF, on the other hand.

The solution I come up with now is to just freeze the WAF version I use.
Fortunately, things like vala support can be done on top, rather than
within, WAF, so it's not hard to stabilize on a WAF version for a very
long time.

> Plus, CMake is getting more mature and stable and it already supports
> VisualStudio and XCode project files conversion, lack of proper
> extensibility being its only downside at the moment.

Lack of extensibility, and use of another arcane custom made programming
language (if we can call it that) for everything.

No, CMake is not an answer.  It is not significantly better than
autotools to justify a switch to it IMHO.

-- 
Gustavo J. A. M. Carneiro
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
"The universe is always one step beyond logic" -- Frank Herbert

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Alberto Ruiz]

2008/6/30 Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]>:

>
> An excellent reason to switch to a more modular build system, one that
> does not require patching the core in order to extend it.
>
> Something like... WAF :-)
>

Well, after some time evaluating waf, there's something that I don't quite
like about it and that I don't see changing anytime soon.

During its development cycle last year trunk has been broken a few times,
api has changed and the Tools modules to support gnome features have stopped
working. Last time I checked, it lacks a proper test suite to avoid
regression on supported tools.

There's no difference between well supported features and unstable ones, so
people using those extensions don't know what sort of stability they should
spect.

As we talk, the gnome demo at trunk is broken, a situation that I've seen
more times than I would like too:
  File "/home/aruiz/src/waf-read-only/demos/gnome/wscript", line 6, in

import Params, intltool, gnome
ImportError: No module named Params

Yes, I think that waf has a lot of potential, and eventually it would be the
way to go, but without a significant change of direction in the way it is
maintained, I don't see GNOME changing to it anytime soon.

Plus, CMake is getting more mature and stable and it already supports
VisualStudio and XCode project files conversion, lack of proper
extensibility being its only downside at the moment.


> --
> Gustavo J. A. M. Carneiro
> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
> "The universe is always one step beyond logic" -- Frank Herbert
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>



-- 
Un saludo,
Alberto Ruiz
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Gustavo J. A. M. Carneiro]

On Mon, 2008-06-30 at 15:25 +0200, Mathias Hasselmann wrote:
> Am Montag, den 30.06.2008, 12:30 +0100 schrieb Bastien Nocera:
> > On Mon, 2008-06-30 at 13:14 +0200, Mathias Hasselmann wrote:
> > > Am Montag, den 30.06.2008, 10:31 +0100 schrieb Bastien Nocera:
> > > > On Mon, 2008-06-30 at 01:51 +, Stef wrote:
> > > > > Interesting. That's a very valid concern.
> > > > > 
> > > > > Although this is a decidedly different case. Vala is used to generate 
> > > > > C
> > > > > code for parts of seahorse. This C code is then checked into the
> > > > > repository, and included in the tarballs, so that people can build it
> > > > > without vala.
> > > > 
> > > > Right. Some of us have already been there with gob. I don't usually
> > > > think it's worth the pain, but it's your code. I'll start complaining
> > > > when I have to fix bugs in that code.
> > > 
> > > Just that gob wasn't half as ambitious as Vala. gob took some kind of
> > > minimum effort approach which lead to the effect that you were mixing
> > > high-level gob and low-level C code all the time. This just felt flaky
> > > and hackish.
> > > 
> > > Vala on the other hand tries to provide a complete user experience.
> > > Programming with it feels much better than it ever did with gob. Having
> > > written quite some C# and Java code I think, that writing Vala code
> > > feels as natural as with those languages. 
> > 
> > I'm not comparing featuresets. I'm saying it still feels like a
> > pre-processor. It needs native autotools[1] support before it's
> > considered for use in core components.
> > 
> > > While your rant has some justification
> > 
> > Just where you saw a rant, I don't know. I'd rather you didn't
> > attribute those kind of qualifiers to my messages in the future.
> 
> Update the bug:
> http://bugzilla.gnome.org/show_bug.cgi?id=472048#c11
> 
> The automake maintainers received a patch ages ago:
> http://lists.gnu.org/archive/html/automake-patches/2007-09/msg7.html
> 
> After that I've got the FSF's copyright assignment papers sent, and I've
> sent them back. No progress since then.

An excellent reason to switch to a more modular build system, one that
does not require patching the core in order to extend it.

Something like... WAF :-)

-- 
Gustavo J. A. M. Carneiro
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
"The universe is always one step beyond logic" -- Frank Herbert

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Mathias Hasselmann]

Am Montag, den 30.06.2008, 12:30 +0100 schrieb Bastien Nocera:
> On Mon, 2008-06-30 at 13:14 +0200, Mathias Hasselmann wrote:
> > Am Montag, den 30.06.2008, 10:31 +0100 schrieb Bastien Nocera:
> > > On Mon, 2008-06-30 at 01:51 +, Stef wrote:
> > > > Interesting. That's a very valid concern.
> > > > 
> > > > Although this is a decidedly different case. Vala is used to generate C
> > > > code for parts of seahorse. This C code is then checked into the
> > > > repository, and included in the tarballs, so that people can build it
> > > > without vala.
> > > 
> > > Right. Some of us have already been there with gob. I don't usually
> > > think it's worth the pain, but it's your code. I'll start complaining
> > > when I have to fix bugs in that code.
> > 
> > Just that gob wasn't half as ambitious as Vala. gob took some kind of
> > minimum effort approach which lead to the effect that you were mixing
> > high-level gob and low-level C code all the time. This just felt flaky
> > and hackish.
> > 
> > Vala on the other hand tries to provide a complete user experience.
> > Programming with it feels much better than it ever did with gob. Having
> > written quite some C# and Java code I think, that writing Vala code
> > feels as natural as with those languages. 
> 
> I'm not comparing featuresets. I'm saying it still feels like a
> pre-processor. It needs native autotools[1] support before it's
> considered for use in core components.
> 
> > While your rant has some justification
> 
> Just where you saw a rant, I don't know. I'd rather you didn't
> attribute those kind of qualifiers to my messages in the future.

Update the bug:
http://bugzilla.gnome.org/show_bug.cgi?id=472048#c11

The automake maintainers received a patch ages ago:
http://lists.gnu.org/archive/html/automake-patches/2007-09/msg7.html

After that I've got the FSF's copyright assignment papers sent, and I've
sent them back. No progress since then.

Ciao,
Mathias
-- 
Mathias Hasselmann <[EMAIL PROTECTED]>
Openismus GmbH: http://www.openismus.com/
Personal Site: http://taschenorakel.de/


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Jürg Billeter]

On Sun, 2008-06-29 at 23:35 +0100, Bastien Nocera wrote:
> On Sun, 2008-06-29 at 22:02 +, Stef wrote:
> > I've been implementing some parts of seahorse (and maybe soon
> > gnome-keyring) in Vala.
> 
> > Barring any objections, the next release of seahorse will contain some
> > vala code.
> 
> I object. Given that I see people filing bugs against Totem whenever the
> Vala API changes (which is, since Totem got Vala plugin support, about 3
> times) we have to make changes.

Out of the three changes in Totem I've seen, we have
  * one incompatible change in the Vala type system, i.e. the
requirement to specify Object (GObject) as base class, however,
the change in Vala was 10 months ago and a trivial change in
Totem
  * add `abstract' modifier to an abstract class, which was no
change in Vala, just improved checks, we didn't enforce it
before
  * add `throws Error' to the method declaration, which was also no
change in Vala, just a bug in the bindings

That said, I fully understand when people don't want to depend on Vala
as long as we don't guarantee language stability, however, that will be
the case for 2.24, if everything goes as planned. Also, it makes sense
to allow the module maintainers to decide this, in my opinion, as long
as they distribute the generated C sources.

Jürg
-- 
Jürg Billeter <[EMAIL PROTECTED]>

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Jaap A. Haitsma]

On Mon, Jun 30, 2008 at 1:50 PM, Vincent Untz <[EMAIL PROTECTED]> wrote:
> Le dimanche 29 juin 2008, à 22:02 +, Stef a écrit :
>> I've been implementing some parts of seahorse (and maybe soon
>> gnome-keyring) in Vala.
>>
>> http://live.gnome.org/Vala
>>
>> I'm assuming this is an acceptable thing for a gnome module to do, as it
>> adds no new dependencies (build-time or run-time).
>>
>> However it does add a 'hacking' dependency.
>
> Hrm, how do you do the hacking dependency without the build dependency?
>
make dist results in a tarball with the C files, so you don't need a
vala compiler to build the tarball

Jaap
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Vincent Untz]

Le dimanche 29 juin 2008, à 22:02 +, Stef a écrit :
> I've been implementing some parts of seahorse (and maybe soon
> gnome-keyring) in Vala.
> 
> http://live.gnome.org/Vala
> 
> I'm assuming this is an acceptable thing for a gnome module to do, as it
> adds no new dependencies (build-time or run-time).
> 
> However it does add a 'hacking' dependency.

Hrm, how do you do the hacking dependency without the build dependency?

Vincent

-- 
Les gens heureux ne sont pas pressés.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Bastien Nocera]

On Mon, 2008-06-30 at 13:14 +0200, Mathias Hasselmann wrote:
> Am Montag, den 30.06.2008, 10:31 +0100 schrieb Bastien Nocera:
> > On Mon, 2008-06-30 at 01:51 +, Stef wrote:
> > > Interesting. That's a very valid concern.
> > > 
> > > Although this is a decidedly different case. Vala is used to generate C
> > > code for parts of seahorse. This C code is then checked into the
> > > repository, and included in the tarballs, so that people can build it
> > > without vala.
> > 
> > Right. Some of us have already been there with gob. I don't usually
> > think it's worth the pain, but it's your code. I'll start complaining
> > when I have to fix bugs in that code.
> 
> Just that gob wasn't half as ambitious as Vala. gob took some kind of
> minimum effort approach which lead to the effect that you were mixing
> high-level gob and low-level C code all the time. This just felt flaky
> and hackish.
> 
> Vala on the other hand tries to provide a complete user experience.
> Programming with it feels much better than it ever did with gob. Having
> written quite some C# and Java code I think, that writing Vala code
> feels as natural as with those languages. 

I'm not comparing featuresets. I'm saying it still feels like a
pre-processor. It needs native autotools[1] support before it's
considered for use in core components.

> While your rant has some justification

Just where you saw a rant, I don't know. I'd rather you didn't
attribute those kind of qualifiers to my messages in the future.

[1]: http://bugzilla.gnome.org/show_bug.cgi?id=472048

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Mathias Hasselmann]

Am Montag, den 30.06.2008, 10:31 +0100 schrieb Bastien Nocera:
> On Mon, 2008-06-30 at 01:51 +, Stef wrote:
> > Interesting. That's a very valid concern.
> > 
> > Although this is a decidedly different case. Vala is used to generate C
> > code for parts of seahorse. This C code is then checked into the
> > repository, and included in the tarballs, so that people can build it
> > without vala.
> 
> Right. Some of us have already been there with gob. I don't usually
> think it's worth the pain, but it's your code. I'll start complaining
> when I have to fix bugs in that code.

Just that gob wasn't half as ambitious as Vala. gob took some kind of
minimum effort approach which lead to the effect that you were mixing
high-level gob and low-level C code all the time. This just felt flaky
and hackish.

Vala on the other hand tries to provide a complete user experience.
Programming with it feels much better than it ever did with gob. Having
written quite some C# and Java code I think, that writing Vala code
feels as natural as with those languages. 

While your rant has some justification: The Vala language had to be
modified too often in the past, so I really hope of 1.0 reaching good
shape. On the other hand all the binding changes seldomly were caused by
feature happyness, but by the poor quality of our C API (and the lack of
annotations): Functions in the style of g_object_get() and poor data
structures like GList just blur away too much information to
automatically generate reasonable bindings. Binding breaks usually were
caused by identifying just another unbindable function in the large API
stack we use. Fortunately also the  GObject Introspection Framework
seems to make good progress. Vala seems to plan to put its binding tools
around this essential framework.

So to summarize it: Let's hope, that Jürgen and his mates reach there
ambitious goals for Vala 1.0.

Ciao,
Mathias
-- 
Mathias Hasselmann <[EMAIL PROTECTED]>
Openismus GmbH: http://www.openismus.com/
Personal Site: http://taschenorakel.de/


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Bastien Nocera]

On Mon, 2008-06-30 at 01:51 +, Stef wrote:
> Interesting. That's a very valid concern.
> 
> Although this is a decidedly different case. Vala is used to generate C
> code for parts of seahorse. This C code is then checked into the
> repository, and included in the tarballs, so that people can build it
> without vala.

Right. Some of us have already been there with gob. I don't usually
think it's worth the pain, but it's your code. I'll start complaining
when I have to fix bugs in that code.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Kalle Vahlman]

2008/6/30 Bastien Nocera <[EMAIL PROTECTED]>:
> On Sun, 2008-06-29 at 22:02 +, Stef wrote:
>> I've been implementing some parts of seahorse (and maybe soon
>> gnome-keyring) in Vala.
> 
>> Barring any objections, the next release of seahorse will contain some
>> vala code.
>
> I object. Given that I see people filing bugs against Totem whenever the
> Vala API changes (which is, since Totem got Vala plugin support, about 3
> times) we have to make changes.
>
> I'd rather we only added Vala as a core dependency when its API is
> actually stable.

Yeah, given that the stable 1.0 release is aimed for 2.24 but has a
disclaimer that if the quality is not ok it'll be punted to 2.26, I
would consider it quite reasonable to wait for 1.0 release until
opening the doors...

Vala has been eagerly adopted already, so it shouldn't hamper the
development by limiting user base either.

-- 
Kalle Vahlman, [EMAIL PROTECTED]
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala in GNOME

[Bastien Nocera]

On Sun, 2008-06-29 at 22:02 +, Stef wrote:
> I've been implementing some parts of seahorse (and maybe soon
> gnome-keyring) in Vala.

> Barring any objections, the next release of seahorse will contain some
> vala code.

I object. Given that I see people filing bugs against Totem whenever the
Vala API changes (which is, since Totem got Vala plugin support, about 3
times) we have to make changes.

I'd rather we only added Vala as a core dependency when its API is
actually stable.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list