Re: [Vala] The future of Vala

[Al Thomas]

- Original Message -
> From: Evan Nemerson 
> Sent: Saturday, 10 September 2016, 21:44
> Subject: Re: [Vala] The future of Vala

> Chris Daley has been working on moving a version of Valadate into the
> Vala tree (see ) so tests are
> easier to write.  I'd like to get some feedback from people on his
> work, and if it would encourage people to write more tests we should
> merge it after 0.34 is branched.


Instead of 'make check' the Valadate version also allows you to:
cd tests
./valactests-0.34
This shows TAP output for the tests and produces a log in TAP
format called valactests-0.34.log This includes HTTP links to
bugzilla reports and can be fed into a CI system such as Jenkins.

Ultimately it would be nice to specify a subset of tests so test
first development could be made easier. Then run the full regression
suite once the feature is passing the initial tests.

I hope people like it,

Al
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] The future of Vala

[Baptiste Gelez]

Le 2016-09-10 23:58, Evan Nemerson a écrit :

On Sat, 2016-09-10 at 21:22 +, Ben Iofel wrote:

Sounds awesome. Even if we don't move to github, we should still
allow
people to submit pull requests on the mirror
(https://github.com/gnome/vala)


I completely disagree.  There should be one place to somehow request a
change in the code.  The only way we should accept pull requests
through a GitHub *mirror* is if they are transparently mirrored to the
canonical location, which is extremely non-trivial.

Obviously, without automatic mirroring you're forcing the developers to
monitor multiple channels, which sucks, but there are also other
consequences.  If the PRs aren't mirrored automatically they won't
properly interact with CI, which means they won't be properly tested.

You would also have to mirror all comments in both directions;
commenting on GitHub would have to result in a comment on the canonical
location so developers see them, and if a developer comments on the
canonical location it would have to be mirrored back to GitHub so the
contributor sees it.  You might be able to get a bot account going for
this, but then it's a poor experience for anything involving more than
one person on each site.

Even if you do mirror comments in both directions, you still couldn't
handle things GitHub doesn't support (like real code review).

Finally, I'm not sure it's fair to GNOME to accept PRs through GitHub.
It would set a precedent for other projects which isn't fair for them,
and likely end up making everyone more frustrated.

As for moving to GitHub instead of just accepting PRs through the
mirror, I really don't think that is the right answer here, and I say
that as someone who does a decent amount of open source work on GitHub
these days (see ).  Off the top of my head,
the pros are:

 * Most developers already have a GitHub account and are already
   comfortable with it.
 * Travis CI only works with GitHub.

Travis CI support doesn't really matter; there are lots of CI services
which do work with non-GitHub projects.

The cons, OTOH:

 * The issue tracker is absolutely terrible.  It's easy to use, but
   very limited.
 * Code review support is a joke; it's a stretch to even say it exists.
   It's really just an issue is opened, and you can add comments.
 * It's proprietary. Given the choice, I'd rather use open source
   software unless the proprietary stuff is *significantly* better.
 * There is no way to fix bugs or add features, and relying on GitHub
   doesn't work.  I've reported issues to them before and it has never
   done any good.

I could make that list a lot longer with a bunch of paper-cut type
stuff, but the final bullet point covers a lot.  Besides, the first two
issues negate a lot of the reason I think we should consider some
infrastructure changes.

Frankly, if the choice is between moving to GitHub and sticking to the
current setup I'd prefer the latter.  IMHO the tighter integration with
GNOME is more valuable than not making people sign up for another
account to contribute.


-Evan



I think Gitlab is a good solution (or at least a better solution than 
Github) :


- It's free/open-source software
- When you are comfortable with Github, Gitlab is easy to use
- You have got a good CI, with Gitlab CI
- Code review and issue tracker seems to be similar to Github's ones, 
but because it's open-source we could improve it, or send a request for 
it (Gitlab devs seems to be quite reactives to the feature requests). 
There is also a Bugzilla integration.

- We could also fix bugs if needed.
- You can log in with Github, if you don't want to create an account for 
a small contribution.


And if we don't want to depend of gitlab.com, we can host our own 
instance, perhaps on GNOME servers, if they want.


Baptiste
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] The future of Vala

[Timm Bäder]

On 10.09, Evan Nemerson wrote:
> This is something I've been thinking about lately, too.  We currently
> rely on Jürg and Luca's expertise pretty heavily for development and
> patch review, and since they are both busy with other stuff Vala
> development has slowed down quite a bit.
> 
> Assuming we can't organize financing to pay Jürg and/or Luca to work on
> Vala, I think we need to focus on a more decentralized development
> approach where we rely more on contributions from people with less
> expertise with the Vala internals.

I agree that a more decentralized approach would be better, but as I
said that can't possibly happen if nobody ever even tries to work with
valac internals. Basically, I'm not saying that Jürg or Luca need to
even work on valac, but a patch review now and then would already help
a lot. And some of those patches are really quite simple and obviously
correct, but no review except theirs has any weight.

> 

I assume "more testing" is basically interesting because we need less
(sophisticated) review? That might be true from a functionality POV but
not regarding architecture etc. But more tests are always good of
course.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] The future of Vala

[Dev_NIX]

+1

--

*   EOF   *

2016-09-10 22:44 GMT+02:00 Evan Nemerson :

> This is something I've been thinking about lately, too.  We currently
> rely on Jürg and Luca's expertise pretty heavily for development and
> patch review, and since they are both busy with other stuff Vala
> development has slowed down quite a bit.
>
> Assuming we can't organize financing to pay Jürg and/or Luca to work on
> Vala, I think we need to focus on a more decentralized development
> approach where we rely more on contributions from people with less
> expertise with the Vala internals.  However, we obviously also need to
> keep the compiler's code quality as high as possible.  There are a lot
> of unreviewed patches rotting away on Bugzilla right now, and that's a
> tragic waste of effort.
>
> The answer, at least from my perspective, is to embrace automated
> testing.  We need to significantly beef up the tests shipped with the
> compiler (the ones `make test` runs) so we can check make sure patches
> don't break anything.  This, in turn, would allow people a bit less
> comfortable with the valac internals (such as myself) to review a lot
> more patches, and hopefully get development back up to a much higher
> rate.
>
> Chris Daley has been working on moving a version of Valadate into the
> Vala tree (see ) so tests are
> easier to write.  I'd like to get some feedback from people on his
> work, and if it would encourage people to write more tests we should
> merge it after 0.34 is branched.
>
> I'd also like to provide a robust way to have assorted projects written
> in Vala tested, which would be especially important for changes to
> bindings.  We already have this to some extent (see
> ), but there is no integration with Bugzilla
> and it's not very well maintained (many projects are broken due to non-
> Vala issues), and AFAIK the configuration isn't public so there is no
> way for people to help.
>
> There are a lot of great free CI services we can take advantage of to
> improve this, including (off the top of my head):
>
>  * Travis CI
>  * AppVeyor
>  * GitLab
>  * Snap CI
>  * Drone.io
>  * Semaphore
>
> We don't have to choose one; we can use multiple services (especially
> if AppVeyor is one of them).
>
> One major barrier here is Bugzilla.  I'm not really concerned with
> requiring people to sign up for an account, and I really like the
> workflow (especially with git-bz), but CI integration is a problem and
> I'm not sure how to resolve it.
>
> The obvious solution would be moving development to GitHub, but I'm
> certainly uneasy about depending on a proprietary platform, and I'd
> sure others would be as well.
>
> Perhaps a better option would be moving to GitLab, or installing a
> GitLab instance somewhere (possibly on the GNOME infrastructure?).
> AFAIK Travis only supports GitHub, but Travis isn't our only option.
> If it were up to me, I would probably move to GitLab.com.
>
> Once we have good automated testing support, a good code review tool
> would be extremely helpful.  If we stick with Bugzilla, I know it's
> possible to integrate Gerrit, though AFAIK it would require a plugin
> for Bugzilla.  GitHub sucks for code review, but there are external
> tools (including Gerrit) we could use.  GitLab, OTOH, has pretty good
> integrated code reviews.
>
> So, IMHO as soon as 0.34 is branched, we should start working on two
> things:
>
>1. Make it easier to add tests to valac (i.e., merge the Valadate stuff
>   from Chris Daley's repo).
>2. Write tests.  LOTS of tests.  Luckily, this doesn't require a great
>   deal of knowledge, so if you're looking for a way to start
>   contributing this could be an excellent choice.
>
> At the same time, we need to start talking about infrastructure.  I
> love the fact that Vala is part of GNOME, but we need to figure out how
> to get CI up and integrated with our issue tracker.  GNOME Continuous
> is great, but it's just not enough.  If this means moving to GitLab,
> GitHub, BitBucket, etc., or installing GitLab or Phabricator, then so
> be it.  IMHO this is more important than having Vala's issue tracker at
> the same place as GNOME's.
>
>
> -Evan
>
>
>
> On Thu, 2016-09-08 at 19:34 +0200, Timm Bäder wrote:
> > Hey,
> >
> > this is probably just a mail for Jürg and maybe Luca, but if you have
> > a relevant opinion on the matter, that might be a fine reply as well.
> >
> > So, for quite a while the Vala project has seen very little activity.
> > The three people most involved (Jürg, Luca and Flo) are barely on IRC
> > and/or otherwise reachable which makes it hard to get an opinion or
> > info from them. On the other hand, some people are still doing a
> > great job, namely Rico with all the binding work, as well as Evan (I
> > haven't kept up with what Al is doing other than replying to bugzilla
> > issues that won't be fixed unless it's a binding issue).
> >
> > Lots of people are worried about ho

Re: [Vala] LADSPA bindings

[Victor Aurélio Santos]

What I've tried:

[CCode (copy_function="", destroy_function="")]
public struct Descriptor
{
public ulong UniqueID;
public const char[] Label;
public Properties Properties;
public const char[] Name;
public const char[] Maker;
public const char[] Copyright;
public ulong PortCount;
public const PortDescriptor[] PortDescriptors;
public const char[,] PortNames;
public const PortRangeHint[] PortRangeHints;
public void[] ImplementationData;

public Descriptor instantiate(Descriptor* descriptor, ulong sampleRate);

[CCode (has_target = false)]
public delegate void connect_port(Descriptor* instance, ulong
port, double* dataLocation);

public void activate(Descriptor* instance);

public void run(Descriptor* instance, ulong sampleCount);

public void run_adding(Descriptor* instance, ulong sampleCount);

public void set_run_adding_gain(Descriptor* instance, Data gain);

public void deactivate(Descriptor* instance);

public void cleanup(Descriptor* instance);
}

The valac complaints:

LADSPA.vapi:52.9-52.41: error: unexpected declaration
public delegate void connect_port(Descriptor* instance, ulong
port, double* dataLocation);

2016-09-10 20:18 GMT-03:00 Al Thomas :
>> From: Victor Aurélio Santos 
>> Sent: Saturday, 10 September 2016, 23:57
>> Subject: Re: [Vala] LADSPA bindings
>
>> I'm trying to use plugins from vala, not to write!
>> I'm stuck at writing the vapi file, most specifically at the Descriptor 
>> struct.
>
>
> Take a look at 
> https://wiki.gnome.org/Projects/Vala/LegacyBindings#Binding_a_C_Struct.27s_Fields
> The function pointers are targetless delegates. There is no
>
> memory handling for the struct so I don't think it should be
>
> bound as a compact class.



-- 
Victor Aurélio Santos
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] The future of Vala

[Al Thomas]

- Original Message -
> From: Timm Bäder 
> Sent: Sunday, 11 September 2016, 16:30
> Subject: Re: [Vala] The future of Vala

> Basically, I'm not saying that Jürg or Luca need to
> even work on valac, but a patch review now and then would already help
> a lot. And some of those patches are really quite simple and obviously
> correct, but no review except theirs has any weight.


Anyone with GNOME commit access can add to the Vala repository.
So for these two recent patches, a positive review was given and
then the submitter committed their own patch:
https://bugzilla.gnome.org/show_bug.cgi?id=760436
https://bugzilla.gnome.org/show_bug.cgi?id=765785

The purpose of review is to challenge the assumptions of the submitter.
While a solution might be "simple and obviously correct" to the submitter
the reviewer needs to think outside the box and consider which circumstances
may cause problems. Reviews need to be critical, but also offer constructive
advice on improvement. It's developing that subjective idea of what is good 
quality
code for Vala that is the hard part in review.


> I assume "more testing" is basically interesting because we need less

> (sophisticated) review? 

I don't think they are distinct concepts. Testing is part of the review
process. We are talking regression tests here. Tests should not be testing 
implementation
details (the conceptual architecture) too rigidly, if at all, because that 

will limit innovation and refactoring in the code base. You may want some 

integration tests between the parsers and the AST for example, but to test
every function would be far too rigid. We're talking about code samples
that are run against valac to ensure that no regressions occur and the compiler
is running to spec. I'm hoping the valadate version will ultimately include
timings so we can start to identify slow points in the compiler as well.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] LADSPA bindings

[Gergely Polonkai]

Should not that be (Descriptor instance, ulong port, double? dataLocation)
instead? Using asterisk in Vala seems unnatural to me…

On Sun, Sep 11, 2016, 18:09 Victor Aurélio Santos <
victoraur.san...@gmail.com> wrote:

> What I've tried:
>
> [CCode (copy_function="", destroy_function="")]
> public struct Descriptor
> {
> public ulong UniqueID;
> public const char[] Label;
> public Properties Properties;
> public const char[] Name;
> public const char[] Maker;
> public const char[] Copyright;
> public ulong PortCount;
> public const PortDescriptor[] PortDescriptors;
> public const char[,] PortNames;
> public const PortRangeHint[] PortRangeHints;
> public void[] ImplementationData;
>
> public Descriptor instantiate(Descriptor* descriptor, ulong
> sampleRate);
>
> [CCode (has_target = false)]
> public delegate void connect_port(Descriptor* instance, ulong
> port, double* dataLocation);
>
> public void activate(Descriptor* instance);
>
> public void run(Descriptor* instance, ulong sampleCount);
>
> public void run_adding(Descriptor* instance, ulong sampleCount);
>
> public void set_run_adding_gain(Descriptor* instance, Data gain);
>
> public void deactivate(Descriptor* instance);
>
> public void cleanup(Descriptor* instance);
> }
>
> The valac complaints:
>
> LADSPA.vapi:52.9-52.41: error: unexpected declaration
> public delegate void connect_port(Descriptor* instance, ulong
> port, double* dataLocation);
>
> 2016-09-10 20:18 GMT-03:00 Al Thomas :
> >> From: Victor Aurélio Santos 
> >> Sent: Saturday, 10 September 2016, 23:57
> >> Subject: Re: [Vala] LADSPA bindings
> >
> >> I'm trying to use plugins from vala, not to write!
> >> I'm stuck at writing the vapi file, most specifically at the Descriptor
> struct.
> >
> >
> > Take a look at
> https://wiki.gnome.org/Projects/Vala/LegacyBindings#Binding_a_C_Struct.27s_Fields
> > The function pointers are targetless delegates. There is no
> >
> > memory handling for the struct so I don't think it should be
> >
> > bound as a compact class.
>
>
>
> --
> Victor Aurélio Santos
> ___
> 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

Re: [Vala] LADSPA bindings

[Victor Aurélio Santos]

Don't know.. but the error stays even changing

Em 11 de set de 2016 13:30, "Gergely Polonkai" 
escreveu:

> Should not that be (Descriptor instance, ulong port, double? dataLocation)
> instead? Using asterisk in Vala seems unnatural to me…
>
> On Sun, Sep 11, 2016, 18:09 Victor Aurélio Santos <
> victoraur.san...@gmail.com> wrote:
>
>> What I've tried:
>>
>> [CCode (copy_function="", destroy_function="")]
>> public struct Descriptor
>> {
>> public ulong UniqueID;
>> public const char[] Label;
>> public Properties Properties;
>> public const char[] Name;
>> public const char[] Maker;
>> public const char[] Copyright;
>> public ulong PortCount;
>> public const PortDescriptor[] PortDescriptors;
>> public const char[,] PortNames;
>> public const PortRangeHint[] PortRangeHints;
>> public void[] ImplementationData;
>>
>> public Descriptor instantiate(Descriptor* descriptor, ulong
>> sampleRate);
>>
>> [CCode (has_target = false)]
>> public delegate void connect_port(Descriptor* instance, ulong
>> port, double* dataLocation);
>>
>> public void activate(Descriptor* instance);
>>
>> public void run(Descriptor* instance, ulong sampleCount);
>>
>> public void run_adding(Descriptor* instance, ulong sampleCount);
>>
>> public void set_run_adding_gain(Descriptor* instance, Data gain);
>>
>> public void deactivate(Descriptor* instance);
>>
>> public void cleanup(Descriptor* instance);
>> }
>>
>> The valac complaints:
>>
>> LADSPA.vapi:52.9-52.41: error: unexpected declaration
>> public delegate void connect_port(Descriptor* instance, ulong
>> port, double* dataLocation);
>>
>> 2016-09-10 20:18 GMT-03:00 Al Thomas :
>> >> From: Victor Aurélio Santos 
>> >> Sent: Saturday, 10 September 2016, 23:57
>> >> Subject: Re: [Vala] LADSPA bindings
>> >
>> >> I'm trying to use plugins from vala, not to write!
>> >> I'm stuck at writing the vapi file, most specifically at the
>> Descriptor struct.
>> >
>> >
>> > Take a look at https://wiki.gnome.org/Projects/Vala/LegacyBindings#
>> Binding_a_C_Struct.27s_Fields
>> > The function pointers are targetless delegates. There is no
>> >
>> > memory handling for the struct so I don't think it should be
>> >
>> > bound as a compact class.
>>
>>
>>
>> --
>> Victor Aurélio Santos
>> ___
>> 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

Re: [Vala] The future of Vala

[Timm Bäder]

On 11.09, Al Thomas wrote:
> > Basically, I'm not saying that Jürg or Luca need to
> > even work on valac, but a patch review now and then would already help
> > a lot. And some of those patches are really quite simple and obviously
> > correct, but no review except theirs has any weight.
> 
> 
> Anyone with GNOME commit access can add to the Vala repository.
> So for these two recent patches, a positive review was given and
> then the submitter committed their own patch:
> https://bugzilla.gnome.org/show_bug.cgi?id=760436
> https://bugzilla.gnome.org/show_bug.cgi?id=765785

That's not interesting. In the scope of this thread I don't care about
bindings whatsoever; that is covered by Rico and Evan.


> The purpose of review is to challenge the assumptions of the submitter.
> While a solution might be "simple and obviously correct" to the submitter
> the reviewer needs to think outside the box and consider which circumstances
> may cause problems. Reviews need to be critical, but also offer constructive
> advice on improvement. It's developing that subjective idea of what is good 
> quality
> code for Vala that is the hard part in review.

Again, not the point.


> > I assume "more testing" is basically interesting because we need less
> > (sophisticated) review?
>
> I don't think they are distinct concepts. Testing is part of the review
> process. We are talking regression tests here. Tests should not be testing 
> implementation
> details (the conceptual architecture) too rigidly, if at all, because that 

This thread is specifically about the inactivity of the two maintainers
of the compiler; I'd want someone with a good understanding of both the
fine-grained and the high-level concepts of valac to review the patches;
your testing doesn't help there. Which is why I asked Evan about the
purpose of the improved testing. Otherwise I don't see a strong reason
why more testing would attract more people to work on the compiler.

Since wip/transform exists and because that's generally how things work,
I also assume that the maintainers have some idea of where the project
should be heading and I don't want patches reviewed by other people to
later stand in the way of that direction.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] LADSPA bindings

[Gergely Polonkai]

Try removing it everywhere. Structs are always translated into pointers, so
every Descriptor * should be plain Descriptor instead. Where you need to
pass pointers to simple types (e.g. double *), use “typename?” instead,
like double? double_pointer_param.

Another thing that is suspicious to me is char[,] PortNames, but it may be
I just haven’t seen such Vala construct before.

On Sun, Sep 11, 2016, 18:37 Victor Aurélio Santos <
victoraur.san...@gmail.com> wrote:

> Don't know.. but the error stays even changing
>
> Em 11 de set de 2016 13:30, "Gergely Polonkai" 
> escreveu:
>
>> Should not that be (Descriptor instance, ulong port, double?
>> dataLocation) instead? Using asterisk in Vala seems unnatural to me…
>>
>> On Sun, Sep 11, 2016, 18:09 Victor Aurélio Santos <
>> victoraur.san...@gmail.com> wrote:
>>
>>> What I've tried:
>>>
>>> [CCode (copy_function="", destroy_function="")]
>>> public struct Descriptor
>>> {
>>> public ulong UniqueID;
>>> public const char[] Label;
>>> public Properties Properties;
>>> public const char[] Name;
>>> public const char[] Maker;
>>> public const char[] Copyright;
>>> public ulong PortCount;
>>> public const PortDescriptor[] PortDescriptors;
>>> public const char[,] PortNames;
>>> public const PortRangeHint[] PortRangeHints;
>>> public void[] ImplementationData;
>>>
>>> public Descriptor instantiate(Descriptor* descriptor, ulong
>>> sampleRate);
>>>
>>> [CCode (has_target = false)]
>>> public delegate void connect_port(Descriptor* instance, ulong
>>> port, double* dataLocation);
>>>
>>> public void activate(Descriptor* instance);
>>>
>>> public void run(Descriptor* instance, ulong sampleCount);
>>>
>>> public void run_adding(Descriptor* instance, ulong sampleCount);
>>>
>>> public void set_run_adding_gain(Descriptor* instance, Data gain);
>>>
>>> public void deactivate(Descriptor* instance);
>>>
>>> public void cleanup(Descriptor* instance);
>>> }
>>>
>>> The valac complaints:
>>>
>>> LADSPA.vapi:52.9-52.41: error: unexpected declaration
>>> public delegate void connect_port(Descriptor* instance, ulong
>>> port, double* dataLocation);
>>>
>>> 2016-09-10 20:18 GMT-03:00 Al Thomas :
>>> >> From: Victor Aurélio Santos 
>>> >> Sent: Saturday, 10 September 2016, 23:57
>>> >> Subject: Re: [Vala] LADSPA bindings
>>> >
>>> >> I'm trying to use plugins from vala, not to write!
>>> >> I'm stuck at writing the vapi file, most specifically at the
>>> Descriptor struct.
>>> >
>>> >
>>> > Take a look at
>>> https://wiki.gnome.org/Projects/Vala/LegacyBindings#Binding_a_C_Struct.27s_Fields
>>> > The function pointers are targetless delegates. There is no
>>> >
>>> > memory handling for the struct so I don't think it should be
>>> >
>>> > bound as a compact class.
>>>
>>>
>>>
>>> --
>>> Victor Aurélio Santos
>>> ___
>>> 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

Re: [Vala] The future of Vala

[Evan Nemerson]

On Sun, 2016-09-11 at 17:30 +0200, Timm Bäder wrote:
> On 10.09, Evan Nemerson wrote:
> > 
> > This is something I've been thinking about lately, too.  We
> > currently rely on Jürg and Luca's expertise pretty heavily for
> > development and patch review, and since they are both busy with
> > other stuff Vala development has slowed down quite a bit.
> > 
> > Assuming we can't organize financing to pay Jürg and/or Luca 
> > to work on Vala, I think we need to focus on a more decentralized
> > development approach where we rely more on contributions from
> > people with less expertise with the Vala internals.
> 
> I agree that a more decentralized approach would be better, but as I
> said that can't possibly happen if nobody ever even tries to work
> with valac internals. Basically, I'm not saying that Jürg or Luca
> need to even work on valac, but a patch review now and then would
> already help a lot. And some of those patches are really quite simple
> and obviously correct, but no review except theirs has any weight.

I'm not trying to say nobody should try to work on the internals; quite
the opposite.  I'm saying we need to make it easier to do so.  Even
patches that look obviously correct on the surface can have unintended
side-effects which break things is unexpected ways, especially for
people who aren't extremely familiar with the code.

We currently rely pretty heavily on expert knowledge when looking at
patches to make sure they don't have unintended side-effects, which
means a fairly deep knowledge of valac's internals is required for
reviewing patches.  Unfortunately, the only way to gain that knowledge
is to work on valac and have patches reviewed, so we end up with a bit
of a chicken-and-egg problem.

For a lot of patches we can use testing as an additional check to make
sure the patch doesn't break anything.  With that in place, the bar for
trusting reviewers is significantly lower, to the point where people
who are less familiar with the valac internals could do reviews for a
lot more patches, and Jürg and Luca needn't be bothered for most
issues.

Think of it as a way to build up the trustworthiness of a patch.  In
order to be included in valac, a patch needs a certain level of trust.
Code reviews each build up a bit of trust, and the more expertise the
reviewer has with the vala internals the greater the weight of each
review.  Passing automated tests also boosts the level of trust in a
patch; the better the automated tests, the more trust we start with,
and the less we need to add to get it to the point where we trust it
enough to get it in the compiler.

> > 
> 
> I assume "more testing" is basically interesting because we need less
> (sophisticated) review? That might be true from a functionality POV
> but not regarding architecture etc. But more tests are always good of
> course.

I certainly wouldn't think of it as a less sophisticated review
process.  If anything, I think it's more sophisticated.  I would say
it's interesting because it would let us accept patches when the
reviewers have less expertise in valac itself, because at least we know
the patch doesn't break everything.

Obviously automated testing can't replace humans entirely.  We would
still need human reviewers, and big architectural changes would still
require feedback from people like Jürg and Luca, but not all patches
would.  If we don't have to bother them with the little stuff
development can move a lot faster, and when something big comes up
*then* we can pull them in.  Both of them are still (AFAIK) available
for the occasional review, they just don't have the same amount of time
for such reviews they once did.

While solid tests may not be as helpful for deciding if major
architectural changes provide a net gain, they are critical for
actually writing them.  In a large project like valac, even if they're
made by someone with a lot of expertise in the internals major changes
are very likely to break something.  A comprehensive test suite lets us
be much more confident in changes like that, so the question becomes
whether or not we want the change, not whether making it will break
everything.

It's also worth noting that getting patches merged also means people
are going to be more likely to contribute again, and as more of their
patches are merged and they work on the compiler more the level of
trust the community has in them will likely grow, and their patch
reviews will carry more weight.  Eventually, that list of two people I
consider to really be experts in vala's internals may grow.


Evan

signature.asc
Description: This is a digitally signed message part
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] LADSPA bindings

[Evan Nemerson]

On Sun, 2016-09-11 at 16:30 +, Gergely Polonkai wrote:
> Should not that be (Descriptor instance, ulong port, double?
> dataLocation)
> instead? Using asterisk in Vala seems unnatural to me…

In general, you shouldn't use pointers in Vala.  In general if you're
using a pointer you're doing it wrong.  The major use case for pointers
is when you want to opt-out of Vala's automatic memory management,
typically because the C API is too weird for Vala to handle
automatically.  That's why you see lots of pointers in libxml2.

In general, marking a parameter as nullable (?) or as a reference (ref)
or output (out) is the right way to go, but usually even that isn't
necessary.  Everything except SimpleType structs are passed as pointers
anyways, so usually you only need to use ?/ref/out to describe the
semantics of the parameter (i.e., can the value be null, or is it an
in/out or out parameter).

That said, LADSPA looks like somewhere a pointer would actually be
appropriate, though not where you used it.  The LADSPA_Handle instances
should probably be a pointer because there is no way to tell Vala how
to free it (you need to do something like
`descriptor.cleanup(instance)`).

Anyways, I would probably bind this as something like

[Compact, CCode (cname = "void")]
public class Handle {
  // ...
}

[CCode (has_target = false)]
public delegate LADSPA.Handle* DescriptorInstantiate(
    Descriptor descriptor,
    ulong sample_rate);

public struct Descriptor {
  [CCode (cname = "UniqueID")]
  public ulong unique_id;
  [CCode (cname = "Label")]
  public unowned string label;
  // ...
  public LADSPA.DescriptorInstantiate instantiate;
}

Note that the string is unowned; AFAICT they should all be.  That means
you don't need to do anything special for the copy and destroy
functions.

> 
> On Sun, Sep 11, 2016, 18:09 Victor Aurélio Santos <
> victoraur.san...@gmail.com> wrote:
> 
> > 
> > What I've tried:
> > 
> > [CCode (copy_function="", destroy_function="")]
> > public struct Descriptor
> > {
> > public ulong UniqueID;
> > public const char[] Label;
> > public Properties Properties;
> > public const char[] Name;
> > public const char[] Maker;
> > public const char[] Copyright;
> > public ulong PortCount;
> > public const PortDescriptor[] PortDescriptors;
> > public const char[,] PortNames;
> > public const PortRangeHint[] PortRangeHints;
> > public void[] ImplementationData;
> > 
> > public Descriptor instantiate(Descriptor* descriptor, ulong
> > sampleRate);
> > 
> > [CCode (has_target = false)]
> > public delegate void connect_port(Descriptor* instance,
> > ulong
> > port, double* dataLocation);
> > 
> > public void activate(Descriptor* instance);
> > 
> > public void run(Descriptor* instance, ulong sampleCount);
> > 
> > public void run_adding(Descriptor* instance, ulong
> > sampleCount);
> > 
> > public void set_run_adding_gain(Descriptor* instance, Data
> > gain);
> > 
> > public void deactivate(Descriptor* instance);
> > 
> > public void cleanup(Descriptor* instance);
> > }
> > 
> > The valac complaints:
> > 
> > LADSPA.vapi:52.9-52.41: error: unexpected declaration
> > public delegate void connect_port(Descriptor* instance,
> > ulong
> > port, double* dataLocation);
> > 
> > 2016-09-10 20:18 GMT-03:00 Al Thomas :
> > > 
> > > > 
> > > > From: Victor Aurélio Santos 
> > > > Sent: Saturday, 10 September 2016, 23:57
> > > > Subject: Re: [Vala] LADSPA bindings
> > > 
> > > > 
> > > > I'm trying to use plugins from vala, not to write!
> > > > I'm stuck at writing the vapi file, most specifically at the
> > > > Descriptor
> > struct.
> > > 
> > > 
> > > 
> > > Take a look at
> > https://wiki.gnome.org/Projects/Vala/LegacyBindings#Binding_a_C_Str
> > uct.27s_Fields
> > > 
> > > The function pointers are targetless delegates. There is no
> > > 
> > > memory handling for the struct so I don't think it should be
> > > 
> > > bound as a compact class.
> > 
> > 
> > 
> > --
> > Victor Aurélio Santos
> > ___
> > 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

signature.asc
Description: This is a digitally signed message part
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] LADSPA bindings

[Al Thomas]

- Original Message -
> From: Victor Aurélio Santos 
> Sent: Sunday, 11 September 2016, 17:08
> Subject: Re: [Vala] LADSPA bindings

> The valac complaints:

> LADSPA.vapi:52.9-52.41: error: unexpected declaration
>public delegate void connect_port(Descriptor* instance, ulong
> port, double* dataLocation);


A delegate is a type, it identifies the function signature of the callback.
So the delegate should be defined outside of the struct. Then in the struct
you identify the callback with its type (the delegate name you've used) and
the identifier for the callback. I hope that gets you a step further forward.
Handling APIs in structs is something that I don't fully understand yet.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] The future of Vala

[Al Thomas]

- Original Message -
> From: Timm Bäder 
> Sent: Sunday, 11 September 2016, 17:43
> Subject: Re: [Vala] The future of Vala

> On 11.09, Al Thomas wrote:
>> Anyone with GNOME commit access can add to the Vala repository.
>> So for these two recent patches, a positive review was given and
>> then the submitter committed their own patch:
>> https://bugzilla.gnome.org/show_bug.cgi?id=760436
>> https://bugzilla.gnome.org/show_bug.cgi?id=765785

> That's not interesting. In the scope of this thread I don't care about
> bindings whatsoever; that is covered by Rico and Evan.


I chose one of each. One is a binding, one is a patch to vapigen. 

> This thread is specifically about the inactivity of the two maintainers

> of the compiler; 


Clearly for you it is, but other people have expressed concerns about
the "future of Vala" so it is important to demonstrate work on Vala goes on.

> Since wip/transform exists and because that's generally how things work,
> I also assume that the maintainers have some idea of where the project
> should be heading and I don't want patches reviewed by other people to
> later stand in the way of that direction.


That is a fair question. If someone is going to work on the internals should
they take account of the various *transformer.vala files, etc. from 
wip/transform?

If, however, you are implying you don't want your patches reviewed by others 
please 

let me know. I have just reviewed a couple of your patches and I understand you
have commit access. So I was expecting after comments were addressed you would 
commit.
I did not do the review because of this thread, I have had a note of those 
patches for some 

time because I try and value people's contributions. If you look at your IRC 
log you 

will see I pointed out about testing for code that shouldn't compile and 
shortly after
the invalid code test patch was committed.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

[Vala] Code style refactor

[rastersoft]

Hi all:

Is there a source code style refactor for Vala? If not, where can I find
documentation about libvala api?

Thanks.

-- 
Nos leemos
 RASTER(Linux user #228804)
ras...@rastersoft.com  http://www.rastersoft.com

___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list