[Gambas-user] BUG Install on mandriva

[Doriano Blengino]

Benoît Minisini ha scritto:
>
>
> You just have to use the MEMORY instruction to get a memory stream, and 
> replace the #pointer by #memoryStream.
>   
As you already stated, it is necessary to get informed. I will fetch the 
wiki for that.
>
>   
>>>> 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. 
>>     
>
> It is a non-sense in a Gambas way, because ByRef does not use pointers in 
> Gambas. See that page for more details: http://gambasdoc.org/help/doc/byref
>
> ...
>> ...
>>     
> You must do that then:
>
> 	Private Extern snd_seq_open(Pseq As Pointer, name As String, streams As
> 		Integer, mode As Integer) As Integer
>
> 	snd_seq_open(VarPtr(handle), ...)
>
> VarPtr() must be used when a C-function argument is actually a pointer to a 
> variable that will be modified by the called function.
>   
I disagree for two or three reasons. First, an external declaration 
already implies that the declaration refers to something extraneous to 
gambas, where things are different. This is even more true for gambas, 
which only needs EXTERN to interface to modules written in other 
languages, because it has a more natural and efficient way to use its 
own modules/components.
The second reason is that using BYREF in the external declaration, the 
task of the function is well defined for now and forever. Actually, in 
that case, BYREF would internally mean something different - but anyway 
all the declaration takes a totally different way in its implementation. 
But, at high, logic level, BYREF would keep its intimate meaning.
Third, if I can not declare an external parameter with BYREF, I must 
then use varptr() on every call - this moves the logic from declaration 
to its usage - and there is more to type on the keyboard.
>   
>> 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.
>>     
>
> I think so. And PACKED can be implemented, but then your sources won't work 
> anymore on ARM architecture, where non-aligned access are forbidden and lead 
> to a bus fault!
>   
The same is true with pointers and MEMORY streams. The idea about PACKED 
is extreme, it lets the programmer do whatever he wants, with all the 
(few) benefits and (lot of) caveats of such a thing. But are you saying 
that memory streams have no risk on ARM?
The problem is: are you sure that pointers, memory streams and varptr() 
are needed? Memory streams can be used to peek everywhere in memory, but 
you know well that this is a non-sense. The only legitimate memory 
addresses are those returned by some form of alloc(), or indirectly by 
functions which use, in turn, alloc(), or addresses already in use by 
variables. All these things could disappear if you implement correctly 
"byref" and structures, gaining a much more clean design.

>
>> 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.
>>     
>
> Sorry for that!
>   
If it was not funny for me to write a tutorial, I didn't start to do it. 
So, if *two* tutorials have to be written, there is double fun! :-) 
...and double time... :-(

Regards,
Doriano