Is this a Pulseaudio bug or a Vala bug? (v2)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi again Alexander,

On Wed, Mar 30, 2011 at 1:12 PM, Alexander Kurtz
<kurtz.alex at googlemail.com> wrote:
> Hi,
>
> I've got another problem with Vala and Pulseaudio's official Vala bindings.
>
> This is my source code:
>
> ? ? ? ?$ cat test.vala
> ? ? ? ?class MyClass : Object {
> ? ? ? ? ? ? ? ?PulseAudio.ChannelMap map;
> ? ? ? ? ? ? ? ?static void main(){
> ? ? ? ? ? ? ? ?}
> ? ? ? ?}
> ? ? ? ?$
>
> Compiling it fails:
>
> ? ? ? ?$ valac --pkg=libpulse --vapidir=. test.vala
> ? ? ? ?test.vala:2.2-2.26: warning: field `MyClass.map' never used
> ? ? ? ? ? ? ? ?PulseAudio.ChannelMap map;
> ? ? ? ? ? ? ? ?^^^^^^^^^^^^^^^^^^^^^^^^^
> ? ? ? ?/tmp/ccCFqscK.o: In function `myclass_finalize':
> ? ? ? ?test.vala.c:(.text+0x152): undefined reference to `pulse_audio_channel_map_destroy'
> ? ? ? ?collect2: ld returned 1 exit status
> ? ? ? ?error: cc exited with status 256
> ? ? ? ?Compilation failed: 1 error(s), 1 warning(s)
> ? ? ? ?$
>
> I thought this was a bug in Vala, since valac accepted the code but gcc
> threw an error. I reported this to the Debian BTS[1] and was told that
> this is a bug in the bindings which I doubt[3].
>
> Can anybody confirm (or deny) that this is *not* a Pulseaudio bug?

FYI, this page is an absolute lifesaver:
http://live.gnome.org/Vala/Manual/Attributes#CCode_Attribute

With the attached patch, I get:

$ valac --pkg=libpulse --vapidir=/usr/share/vala-0.12/vapi test2.vala
test2.vala:2.16-2.40: warning: field `MyClass.map' never used
               PulseAudio.ChannelMap map;
               ^^^^^^^^^^^^^^^^^^^^^^^^^
Compilation succeeded - 1 warning(s)

The result is that the struct is created with _init() using memory you
already allocated (on the stack, or on the heap) and then you are
responsible for calling pa_xfree() later to free it if it's allocated
on the heap. This is how most structs work in my experience (except
for GObjects).


As to your bugs in [3] (from your message):

> (1) valac doesn't fail if you try to put a dynamically-sized array
>     into a struct

Probably a bug, yes.

> (2) valac doesn't allow adding a destructor function to a struct

Not sure that this is a bug. The destructor syntax in Vala more or
less assumes that you are working with an (instance of a) class
inheriting from GObject (the `Object' class in Vala), which structs
cannot possibly be. The attribute hack isn't nearly as pretty, but eh,
bindings are write-once use-everywhere, and bindings in other
languages are much nastier (cf. native code written to generate Python
bindings to C, etc.)

> (3) valac doesn't allow making fixed-sized arrays from constants.
>     This is absolutely necessary since there are no preprocessor
>     directives in vala and most C libraries define symbolic names
>     for these things.

If this is true, it sounds like a bug. A trivial test program not
involving the vapi cruft would be nice.

> (4) valac doesn't handle fixed-size arrays correctly, as it still
>     thinks they need to freed after use.

Sounds ugly, but I haven't confirmed it myself. A trivial test program
not involving the vapi cruft would be nice.


HTH,

Sean

>
> Best regards
>
> Alexander Kurtz
>
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619345
> [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619345#10
> [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619345#15
>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-vala-ChannelMap-has-no-destroy-function.patch
Type: text/x-patch
Size: 792 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110330/e5748289/attachment.bin>


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux