[Gambas-user] Extern howto/tutorial

Tue Aug 24 10:33:40 CEST 2010

Benoît Minisini ha scritto:
>> Hi,
>>
>> I finally wrote the tutorial about using external declarations.
>>     
> This is not HTML, but plain text. If you can make an HTML version of your 
> document, with formatted text, I will be able to add it to the wiki.
>   
Mmm... this is an excerpt from the first lines of "External-howto.html", 
the file attached to my previous message:

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
    "http://www.w3.org/TR/html4/loose.dtd">
    <html>
        <head>
            <meta http-equiv="Content-Type" content="text/html;
    charset=UTF-8">

This seems HTML to me... what document are you speaking about? Perhaps 
the .t2t one?

>
>> In the Drum Machine project, after having verified that it works
>> correctly using pointers for read/write, I tried to create a new class
>> which should be a gambas representation for an alsa event (which is a C
>> struct). It does not work, and I don't know how to debug it (well, I
>> could, using gdb or similar, but I was looking for a more direct way).
>>     
>
> Give me the C declaration, and your class declaration, and I will be able to 
> see if they correctly match.
>   
Both are contained in the attached files - the C declaration, along with 
explanation and unrolling of structs/typedef/#define and so on, in the 
document; the Gambas class trying to emulate the C declaration, in the 
project "Gambas2-Drummachine....". For your convenience, I will repeat 
both at the end of this email.

>
> It is explicitely said that "WRITE #Pointer" is not supported anymore in 
> Gambas 3, in the WRITE documentation page. And so on for the READ instruction.
>   
Sorry, I think that it is not so clear. "No more supported", or 
equivalent semantics, is totally absent from the page. It is true that 
there is a frame specifying the syntax for READ in Gambas3, but it 
speaks only about "READ #Stream". This makes me think that the "READ 
#Stream" syntax or behavior changed, not necessarily that pointers are 
no more valid. Perhaps would be better to say something more in the 
first frame, the one just below the title of the page: "WARNING! The 
syntax has changed in Gambas 3. READ/WRITE with pointers is no more 
supported in Gambas 3. See below."

You said that you removed this syntax because of possible problems with 
memory alignment. What about BytePtr(), SinglePtr() and the alike? Do 
they not suffer from the same problem? (Just a curiosity).

> The Gambas 3 structures were implemented for the use of extern C structures. 
> Moreover, in Gambas 3, you can now use Gambas functions as C function pointer  
> (as known as "callbacks") almost transparently.
>   
I know... it was me that kindly requested that feature, I suppose... :-)
And, apropos...
I saw that alsa does not really provides a callback - there is something 
about in an undocumented source (an utility for alsa). Instead, what 
alsa provides, is a file descriptor which can be poll()ed or select()ed. 
Then I have seen a source for QT, which uses this capability. It seems 
the QT has a way to pass it a file descriptor, so it can raise events 
intermixed with GUI events. Glib too has something similar. I thought to 
use or fool some gambas stream to obtain the same result... but perhaps 
you have a better idea.

Now let us see the problem about the alsa (musical) event structure. 
Giving that I made it to work, probably I did understand that structure 
and, if I only had a simple way to debug my gambas implementation, I 
would have had success. The alsa declaration is:

    snd_seq_event_type_t    type
    unsigned char           flags
    unsigned char           tag
    unsigned char           queue
    snd_seq_timestamp_t     time
    snd_seq_addr_t          source
    snd_seq_addr_t          dest
    union {
       snd_seq_ev_note_t    note
        ...

The first field, type, is a byte. The fifth field, time, is a union 
having a total length of two ints, eight bytes in total.
The source and dest fields are struct composed of two bytes each. After 
this fields, that are common to every alsa event, comes a specialized 
part for every different event. I only used the snd_seq_ev_note_t.

My gambas translation is:

    ' Gambas class file

    ' object data to simulate a C struct

    type AS Byte            '    snd_seq_event_type_t type
    flags AS Byte           '    unsigned char flags
    tag AS Byte             '    unsigned char tag
    PUBLIC queue AS Byte    '    unsigned char queue
    time_tick AS Integer    '    snd_seq_timestamp_t Time
    time_dummy AS Integer   '    snd_seq_timestamp_t Time (2 part of union)
    PUBLIC sourceq AS Byte  '    snd_seq_addr_t source (source client)
    PUBLIC sourcep AS Byte  '    snd_seq_addr_t source (source port)
    PUBLIC destq AS Byte    '    snd_seq_addr_t dest (dest client)
    PUBLIC destp AS Byte    '    snd_seq_addr_t dest (dest port)

    ' note on fields of union {   snd_seq_ev_note_t note ...
    channel AS Byte
    note AS Byte
    velocity AS Byte

    ' a few bytes as filler
    dummy1 AS Integer
    dummy2 AS Integer
    ...

If you can use MIDI, or you have a soft synth like timidity, you can try 
to run the project to see what is going on.
In FMain.class, in the subroutine btLegato2_Click(), you find:

    ' alsa.playnoteobj(-10 * i, 0, 60 + i, 100, 20)
    alsa.playnote(-10 * i, 0, 60 + i, 100, 20)

Decomment the first line and comment-out the second. The second line 
prepares a C struct as the one above, using pointers to write in a 
memory region previously allocated, once for the whole life of the 
running program. The first line instead, tries to do the same by using a 
gambas class. An instance of that class is created once, and then 
repeatedly written to to set the various fields; finally, a pointer to 
the instance is passed to alsa, but alsa replies with "invalid 
argument". My machine is a 32-bit AMD Duron, with a Debian stable 
distribution; the test was made with gambas 2.0.0.

Best regards,
Doriano