[Gambas-user] BUG Install on mandriva

[Benoît Minisini]

> 
> 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...

Ha, ok, I see! This is a mistake in the installation scripts. You are right, 
if the compilation fails, no executable should be made!

> 
> >> 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?

Yes, the better should be a fully selectable size.

> 
> > 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?

As soon as gambas 3 is out. I will say this year, but this kind of predictions 
you know...

> 
> >> 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.

You just have to use the MEMORY instruction to get a memory stream, and 
replace the #pointer by #memoryStream.

> 
> >>     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. 

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

> 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.

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.

> 
> >> 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.

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!

> 
> >> 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.

Sorry for that!

Regards,

-- 
Benoît Minisini