> > 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 ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user