Re: [Vala] LADSPA bindings

[Victor Aurélio Santos]

What I've done:

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

[CCode (has_target = false)]
public delegate void DescriptorConnectPort(Handle? instance, ulong
port, ref double dataLocation);

[CCode (copy_function="", destroy_function="")]
public struct Descriptor
{
[CCode (cname = "UniqueID")]
public ulong unique_id;
[CCode (cname = "Label")]
public unowned string label;
[CCode (cname = "Properties")]
public Properties properties;
[CCode (cname = "Name")]
public unowned string name;
[CCode (cname = "Maker")]
public unowned string maker;
[CCode (cname = "Copyright")]
public unowned string copyright;
[CCode (cname = "PortCount")]
public ulong port_count;
[CCode (cname = "PortDescriptors")]
public const PortDescriptor[] port_descriptors;
[CCode (cname = "PortNames")]
public unowned string[] port_names;
[CCode (cname = "PortRangeHints")]
public const PortRangeHint[] port_range_hints;
[CCode (cname = "ImplementationData")]
public void[] implementation_data;

public Handle? instantiate(Handle? descriptor, ulong sampleRate);

public DescriptorConnectPort? connect_port;

public void activate(Handle? instance);

public void run(Handle? instance, ulong sampleCount);

public void run_adding(Handle? instance, ulong sampleCount);

public void set_run_adding_gain(Handle? instance, Data gain);

public void deactivate(Handle? instance);

public void cleanup(Handle? instance);
}

but...

src/CompressorBackend.c: In function ‘ajami_compressor_backend_connect’:
src/CompressorBackend.c:674:2: error: unknown type name
‘LADSPA_DescriptorConnectPort’
  LADSPA_DescriptorConnectPort _tmp2_ = NULL;
src/CompressorBackend.c:745:2: error: called object ‘_tmp2_’ is not a
function or function pointer
  _tmp2_ (_tmp4_, (gulong) AJAMI_COMPRESSOR_FLAGS_RMS_PEAK, &(*s).rms_peak);

2016-09-11 14:27 GMT-03:00 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.



-- 
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

[Michael Gratton]

On Fri, Sep 9, 2016 at 3:34 AM, Timm Bäder  wrote:

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.


I'd like to see Vala continue, it's IMHO the only reasonable way to 
write high-level apps in GObject, but I /am/ biased. :)


As people have pointed out, we can get patches landed, bindings are 
being updated, and we can respond and triage bugs, improve automated 
testing coverage and debate hosting choice of infrastructure, but none 
of that's going to be terribly useful unless significant new releases 
continue.


It really sounds like Vala needs some maintainers. Perhaps Jürg, Luca 
and Flo are still keen but too busy at the moment, perhaps someone else 
needs to step up. But either way there needs to be one or a few people 
with some idea of where they want Vala to go, who have the time to put 
in to make sure it starts heading in that direction. In the end, its 
the maintainers that would decide if things like wip/transform is the 
way to go or not.


//Mike

--
⊨ Michael Gratton, Percept Wrangler.
⚙ 


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

Re: [Vala] The future of Vala

[Michael Gratton]

On Tue, Sep 13, 2016 at 2:19 AM, oyster  wrote:

some killer apps may be a good AD.


Like these? 



;)

--
⊨ Michael Gratton, Percept Wrangler.
⚙ 


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

Re: [Vala] The future of Vala

[oyster]

some killer apps may be a good AD.

2016-09-12 0:51 GMT+08:00 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
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>