Re: [Vala] LADSPA bindings

[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.
___
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 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


> 
> On Sat, Sep 10, 2016 at 4:44 PM 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.  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

Re: [Vala] LADSPA bindings

[Victor Aurélio Santos]

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.

Em 10 de set de 2016 19:52, "Al Thomas"  escreveu:

>
>
> - Original Message -
> > From: Victor Aurélio Santos 
> > Sent: Saturday, 10 September 2016, 23:10
> > Subject: [Vala] LADSPA bindings
>
> > I'm trying to create LADSPA bindings but no luck.
> > I'm stuck at Descriptor's function pointers, can any one help me with
> this ?
>
>
> From https://github.com/swh/ladspa/blob/master/ladspa.h this
> looks to be a shared object that needs to have a function
> called ladspa_descriptor that returns a constant struct
> containing details of the plugin. A constant struct seems
> fairly standard for plugins. By the way from what I understand
> you are saying it is better to describe your problem as a LADSPA
> plugin, rather than a LADSPA binding. A binding is using a
> library (shared object) and involves writing a VAPI file, whereas
>
> a plugin is creating a shared object.
>
>
> For an example of a constant struct with function pointers
> see the example in https://bugzilla.gnome.org/show_bug.cgi?id=764439
> That example is for GStreamer, but should give you enough clues.
> If not please give an example of your code that doesn't work.
>
> Al
>
___
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: Saturday, 10 September 2016, 23:10
> Subject: [Vala] LADSPA bindings

> I'm trying to create LADSPA bindings but no luck.
> I'm stuck at Descriptor's function pointers, can any one help me with this ?


From https://github.com/swh/ladspa/blob/master/ladspa.h this
looks to be a shared object that needs to have a function
called ladspa_descriptor that returns a constant struct
containing details of the plugin. A constant struct seems
fairly standard for plugins. By the way from what I understand
you are saying it is better to describe your problem as a LADSPA
plugin, rather than a LADSPA binding. A binding is using a
library (shared object) and involves writing a VAPI file, whereas 

a plugin is creating a shared object. 


For an example of a constant struct with function pointers
see the example in https://bugzilla.gnome.org/show_bug.cgi?id=764439
That example is for GStreamer, but should give you enough clues.
If not please give an example of your code that doesn't work.

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

Re: [Vala] The future of Vala

[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 how the project will stay alive (or
> if), and quite a lot of projects are written in Vala (including one
> I maintain) -- and people keep porting projects from C to Vala,
> mostly hoping for more contributions, hoping the Vala's C#-like
> syntax scares 

Re: [Vala] The future of Vala

[Flavio Danesse]

I 'm spending all my applications python Vala , I would like to know the
current state of Vala . Maybe I can contribute in some way to its
continuity.

2016-09-09 18:50 GMT-03:00 rastersoft :

> Hi:
>
> I was hoping to see at least one answer to this, but now I'm really
> scared. I really love Vala, so the perspective of missing it is really
> horrible :(
>
>
> El 08/09/16 a las 19:34, Timm Bäder escribió:
> > 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 how the project will stay alive (or
> > if), and quite a lot of projects are written in Vala (including one I
> > maintain) -- and people keep porting projects from C to Vala, mostly
> > hoping for more contributions, hoping the Vala's C#-like syntax scares
> > off less people.
> >
> > Now, we all know that Vala has enough bugs that need to get fixed, as
> > well as lots of potential for improvements (I'll just disregard all the
> > wishes for special syntax for fringe features on IRC, that's not what
> > I'm talking about). Some of them are easy to fix but even if the patches
> > are present in bugzilla and their author is willing to fix them after
> > a review, the review just never happens. This doesn't just cause those
> > bugs to stay unfixed, but those people will also never get accustomed
> > to the internals of valac and so they will never work on anything more
> > important than this simple fix.
> >
> > I have tried in the past to do exactly that and post some patches for
> > simple fixes to get an understanding of valac internals but it's quite
> > frankly huge and there's not a real high-level documentation one could
> > work with (apart from a few very old blog posts form Luca) and neither
> > working tools do debug it (I've once spent a few hours on fixing valag
> > but then gave up...).
> >
> >
> > So... what's the deal here? Is there any way forward one could look
> > into? Is it wip/transform? IIRC there was some dbus stuff broken here?
> > Are there any TODO items for cleaning up the compiler? Should we just
> > tell people to not use Vala in the first place (which would be better
> > for the in the long run)? All of these are fine, but the current
> > situation not so much.
> >
> >
> > Sincerely,
> > Timm
> > ___
> > vala-list mailing list
> > vala-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/vala-list
> >
>
> --
> 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
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list