[Gambas-user] BUG Install on mandriva

[Doriano Blengino]

Benoît Minisini ha scritto:
>> Benoît Minisini ha scritto:
>>     
>>
>> Me and others got caught in the same pit - building of gambas3.gambas
>> succeeds even if some required component is missing. While it is true
>> that examining logs or paying attention to the compilation process this
>> pit could be avoided, may be that a better-planned compilation process
>> could solve more coherently. Just a thought.
>>     
>
> Yes, but how? If the compilation of the IDE fails, this is not an error. You 
> may want to compile gambas without the IDE.
>
> I have started to collect some warnings so that they are printed at the end of 
> the configuration process. Maybe I could add a warning if for sure the IDE 
> won't be compiled because some component is missing?
>   
I mean that gambas3.gambas should not be created, and therefore not 
installed, if it is disabled, much the same as other components. Me and 
the others who saw "no project in..." were fooled by this: if you 
compile a thing, may be a C source or a Gambas source, the compilation 
stops if the target can not be built - the compiler does not generate an 
invalid executable/object, it complains with an error and refuses to go 
on. It does matter little if this step (compiling gambas3.gambas) is 
performed in the installation procedure. As I said before, anyway, this 
is just a thought - as long as there is someone who can say "yes - you 
need webkit", it is not important...

>> After having launched gambas3 I went to the preferences to see how much
>> I could taylor it to my needs. It seems that the preferred way to set
>> preferences is to let the user choose among a few choices. For some
>> things like the font size, "Normal, small, smaller" could be enough (but
>> not always); 
>>     
>
> I don't understand: what is the problem with that configuration?
>   
Simply that if someone wants "bigger"... no way. Only Normal, small or 
smaller. In this very case, a "font size preference" would cover any 
possible need. Again, it is just a thought, may be that there are other 
reasons behind this choice, but I've seen persons using very big fonts 
because of their handicaps, and also I have used some stupid X servers 
where a choice of "bigger than normal" would have been useful. Are you 
afraid that a user can choose a font size of 6 when he needs 18?

> The way for accessing memory has changed in Gambas 3.
>
> 1) The old way, like Gambas 2: use the MEMORY keyword to open a stream on a 
> memory address.
>
> 2) The new way, a bunch of functions to read directly a value at a memory 
> address: BytePtr(), ShortPtr(), IntPtr(), and so on.
>
> 3) Support for C-like structures with the STRUCT keyword.
>
> Read the wiki about all these keywords and functions for the details.
>
>   
>> This seems to be a back-compatibility break.
>>     
>
> Yes it is. But no features disappeared and new ones were added, so logically 
> you will see the light sooner or later!
>   
It is not my problem, I can write and rewrite my code as many time I 
want. But if I write code for gambas3 only, and want to publish it, all 
the other users which still have gambas2 will be left behind. It is true 
that gambas2 will, one day, go to retire, but when?

>
>> Then I thought "ok, let's use
>> the new gambas3 capabilities...". But it would be better to have a way
>> to write code compatible to both gambas2 and gambas3 (conditional
>> compilation?). 
>>     
>
> Alas it is more complex than that. Behind most of the syntax changes you have 
> an internal feature change. I have just the time to enhance gambas, but hardly 
> the time to write a Gambas2 -> Gambas3 translator!
>
> But you can help there: by just taking notes while doing the conversion, we 
> will be able to write a document about what to do to convert a Gambas 2 
> project to a Gambas 3 project.
>   
Uhm, just after the previous email, I realized this is impossible. 
Conditional compilation is not supported by gambas2, so there is no 
point in writing a program with conditional defines in it. It would be 
incompatible with gambas2 anyway. Of course, I can take annotation about 
the required modifications but, at this moment, the only difference is 
that read/write from #pointer does not work anymore.

>>
>>     int snd_seq_open(snd_seq_t **seqp, const char * name, Int streams,
>> Int mode);
>>
>> The first parameter requires a pointer to a pointer, and this is why in
>> the gambas2 version I used a pointer to read from. But now, I wrote:
>>
>>     Private Extern snd_seq_open(ByRef Pseq As Pointer, name As String,
>> streams As Integer, mode As Integer) As Integer
>>
>> This declaration is later used by:
>>
>>       err = snd_seq_open(handle, "default", SND_SEQ_OPEN_DUPLEX, 0)
>>         --or--
>>       err = snd_seq_open(byref handle, "default", SND_SEQ_OPEN_DUPLEX, 0)
>>
>> Both statements die with error #6. This two lines work:
>>
>>     ret = VarPtr(handle)
>>     err = snd_seq_open(ret, "default", SND_SEQ_OPEN_DUPLEX, 0)
>>
>> It seems that "byref" is ignored in external declaration, but no error
>> is generated.
>>     
>
> Yes, Byref is a non-sense for extern declaration. The compiler should raise an 
> error and not ignore it.
>   
Why you say so? This is one of many situations where a pointer in C can 
be translated with BYREF in gambas. I don't think that byref for 
external declaration is a non-sense. Moreover, a byref declaration still 
carries a type definition, where a pointer looses this information. A C 
"float *value" is better translated with "byref value as double", than a 
generic "value as pointer".

> Apparently, snd_seq_t is an opaque type to a structure. A pointer to a pointer 
> is just a Pointer in Gambas. So your declaration must be:
>
> 	Private Extern snd_seq_open(Pseq As Pointer, name As String, streams As
> 		Integer, mode As Integer) As Integer
>   
I don't agree. As before, a pointer in C is often used because the lack 
of "byref" (or "var" in pascal). By defining the external function as 
"byref handle as pointer", in a single line I can define that the 
function writes into my pointer.

>> Moreover,
>> doing so would make the source incompatible with gambas2, and I am not
>> sure about alignment problems. The pointer way can be ugly, but still
>> versatile.
>>     
>
> Variables and structure fields are never packed, but aligned to a memory 
> boundary required by its memory length (a Short is stored at an odd address, a 
> Integer at an address which is a multiple of four, and so on...). The 
> declaration is respected, so you may have holes in your structure, if, for 
> example, you declare a Byte and just after an Integer.
>
> The *big* problem is that the compiler may reorder the structure fields, and 
> that process is not standardized nor documented. Eventually if that is a big 
> problem, there may be a solution in the libffi library that apparently can 
> send a structure to a C function by taking that problem into account. But that 
> library is far less documented by Gambas, so you see the difficulty. :-)
>   
I see it. This is why I stressed on pointers (or MEMORY keyword, which I 
don't know). Another way is to have a PACKED keyword, so the user can 
put holes where needed. Kind of a dirty thing... but I don't believe 
that libffi can do magic - if a compiler chooses to reorder the fields, 
libffi can not know. I say this because I have seen the alsa structures 
- there is nothing that prevents a compiler to do strange things, but 
libasound must be compatible with applications, at least on a 
inter-architecture basis.

>> What should I do now?
>>
>>     
>
> Please read all the documentation about structures, new Gambas functions 
> related to extern functions... Then come back with more precise questions!
>   
I was referring to use or not use some new gambas3 features. I am not 
really interested in writing a gambas drum machine - it is only a 
tutorial on external interfacing. Given that gambas2 and gambas3 has no 
points in common, it is a hard choice. If the pointer interface was 
retained in gambas3, one could explain things that are valid for both, 
and then explain the new features in gambas3. But now, there are two 
tutorials... one for gambas2 and one for gambas3.

Regards,
Doriano