I'm clueless about Vala, so I can't help much, but I noticed that you're copying (or at least it looks like that to someone who doesn't know Vala) SinkInfo objects. If that means that your code somehow relies on the size of the pa_sink_info struct, your code is broken, because its size can grow in future libpulse versions without notice. We don't consider it an ABI breakage if fields are added to the end of the struct.

(In reply to comment #1)

Thanks, I should have removed that code snippet from this bug report.

That code was in reference to a question on how to copy a struct in Vala, and it turns out that while that code is incorrect, the bindings are as well.

The failure occurs because to_string() is generated with the assumption that the enum is a GEnum. We either need to add a manual to_string override for all enums (which is doable, just painful), or you need to do the switch-case yourself.

(In reply to comment #3)
> The failure occurs because to_string() is generated with the assumption that
> the enum is a GEnum. We either need to add a manual to_string override for all
> enums (which is doable, just painful), or you need to do the switch-case
> yourself.

The Vala documentation sets the expectation level by stating that the to_string() method is built in.  If the code were not added, then I think it should be clearly documented. 

This was posted on the Vala list regarding list items 1 and 3.
1.
>> /.../Source/vala/pulse-device-chooser/src/main.t c:160:47: error:
>> ‘PA_CONTEXT_TYPE_STATE’ undeclared (first use in this function)
> Looks like a missing CCode annotation in the VAPI. Depending on whether
> Context.State has a GType
>
> [CCode (type_id = "pa_context_state_get_type ()")]
>
> or
>
> [CCode (has_type_id = false)]

3 . 
>> main.c:643:31: error: ‘PULSE_AUDIO_TYPE_SINK_INFO’ undeclared (first
>> use in this function)
> The solution is the same as above... either specify the correct type id
> or set has_type_id = false for SinkInfo.

In reference to list item 2.

I started with this simple code:

	public SinkInfo devinfo_to_sinkinfo (DeviceInfo* di) {
		uint32 index = di->index;
		SinkInfo si = SinkInfo ();
		context.get_sink_info_by_index (index, (context, i, eol) => {
			if (eol > 0) {return;}
			sinkinfo_copy(i, &si); // dummy method
		});

		return si;
	}

which generates the following c code:

static void _lambda0_ (pa_context* context, pa_sink_info* i, gint eol, Block1Data* _data1_) {
	Main * self;
	self = _data1_->self;
	g_return_if_fail (context != NULL);
	if (eol > 0) {
		return;
	}
	main_sinkinfo_copy (self, i, &_data1_->si);
}


static void __lambda0__pa_contextsinkinfocb (pa_context* c, pa_sink_info* i, gint eol, gpointer self) {
	_lambda0_ (c, i, eol, self);
}

void main_devinfo_to_sinkinfo (Main* self, MainDeviceInfo* di, pa_sink_info* result) {
	Block1Data* _data1_;
	guint32 index;
	pa_operation* _tmp0_ = NULL;
	pa_operation* _tmp1_;
	pa_sink_info _tmp2_ = {0};
	pa_sink_info _tmp3_;
	g_return_if_fail (self != NULL);
	_data1_ = g_slice_new0 (Block1Data);
	_data1_->_ref_count_ = 1;
	_data1_->self = g_object_ref (self);
	index = (*di).index;
	memset (&_data1_->si, 0, sizeof (pa_sink_info));
	_tmp0_ = pa_context_get_sink_info_by_index (self->priv->context, index, __lambda0__pa_contextsinkinfocb, _data1_);
	_tmp1_ = _tmp0_;
	_pa_operation_unref0 (_tmp1_);
	pulse_audio_sink_info_copy (&_data1_->si, &_tmp2_);
	_tmp3_ = _tmp2_;
	*result = _tmp3_;
	block1_data_unref (_data1_);
	_data1_ = NULL;
	return;
}


And compiling produces this output:

[...]
main.o: In function `main_devinfo_to_sinkinfo':
/home/bwinfrey/Source/vala/pulse-device-chooser/src/main.c:461: undefined reference to `pulse_audio_sink_info_copy'
main.o: In function `block1_data_unref':
/home/bwinfrey/Source/vala/pulse-device-chooser/src/main.c:423: undefined reference to `pulse_audio_sink_info_destroy'
[...]
collect2: ld returned 1 exit status
make[2]: Leaving directory `/home/bwinfrey/Source/vala/pulse-device-chooser/src'
make[1]: Leaving directory `/home/bwinfrey/Source/vala/pulse-device-chooser'
make[2]: *** [pulse_device_chooser] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

compilation end with exit status 2

Thanks a lot for following this up -- we needed to add a has_type_id=false to all our structs, classes and enums for correctness because of recent changes in vala. I've pushed a fix here:

http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=fb107fc77056b6bfcc7902d3ee048c271c212145

Now going back to your code, you're trying to make a copy of the SinkInfo struct, which is not something you should be doing. Could you explain why you need the copy? Would it be sufficient to copy the fields you need?

Created attachment 50744 [details]
Small vala example using introspection api

For reference, I'm attaching a small Vala example that uses introspection API and seems to work fine here.

(In reply to comment #6)

> 
> Now going back to your code, you're trying to make a copy of the SinkInfo
> struct, which is not something you should be doing. Could you explain why you
> need the copy? Would it be sufficient to copy the fields you need?

The code in comment #5 demonstrates that the code generated by Vala attempts to copy the struct when struct is passed as a parameter or returned by the method.

I really don't need to copy the struct at all.  It was for experimental/discovery purposes.

(In reply to comment #7)

Thanks. I will test and report back if it doesn't work after I apply update from comment #6.

I guess this works fine now and can be closed?

(In reply to comment #9)
> I guess this works fine now and can be closed?

I haven't been able to test the changes in comment #6.  I will update my vapi files to test.

I don't know if comment #5 and comment #8 are addressed or even considered issues or not. ie.
 
if passing the struct as an argument or returning it from a function the  code will generate 'pulse_audio_sink_info_copy (&_data1_->si, &_tmp2_);' see comments #5 and #8.

(In reply to comment #10)
> (In reply to comment #9)
> > I guess this works fine now and can be closed?
> 
> I haven't been able to test the changes in comment #6.  I will update my vapi
> files to test.
> 
> I don't know if comment #5 and comment #8 are addressed or even considered
> issues or not. ie.
> 
> if passing the struct as an argument or returning it from a function the  code
> will generate 'pulse_audio_sink_info_copy (&_data1_->si, &_tmp2_);' see
> comments #5 and #8.

I tested with the sample code attachment ( slightly modified to include #5 type scenario ) and there were no issues.

Created attachment 50923 [details]
modified attachment 50744 [details] 

Adding the modified file as an attachment.

Great. Thanks for following all this up!