> Benoît Minisini ha scritto: > >> Now, the single file that should be a link it's easy to correct. But, a > >> line saying "link ../component.am" in the middle of a makefile is > >> different: the makefile is generated by ./configure; where are the > >> instructions that make configure think to do such a thing? Otherwise, I > >> can give up for today, and try to download something else next week. I > >> am reluctant to use svn because I must put my hands onto a production > >> machine: it's not terrible, but at first, I decided not to do it: to > >> download a tarball should be trivial. > > > > I see: you must use a svn client to extract the sources. > > > > What you are downloading is an image of the subversion repository, which > > is the way the subversion server internally stores the data. Useful if > > you want to duplicate the repository, not useful if you want to compile > > the sources. > > > > You can do the checkout, and then compress it into a *.tag.gz before > > bringing it home. > > Well: ignoring as usual all the advices I've received (my head is harder > than my computer screen), I managed to compile gambas3. Some comments > follow, and by no mean they have the sole purpose to criticize; instead, > giving that gambas3 is still open to modifications, may be that some > idea can be stimulating. > > 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? > > 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? > when choosing the terminal emulator I see konsole, gnome > terminal, xfce, xterm. No one of them is installed, in my (strictly > mine) opinion, they all suck. No problem, this option is not used anymore! Instead the xdg scripts are used, so that the opened terminal is the one associated without your desktop. I don't know which terminal will be used on your system then. > > Then I loaded my experimental "Gambas drum machine", where I am > developing an ALSA interface class. The first run attempt gave me an > error because, it seems, there is no more support for reading/writing to > pointers. > Is this planned? 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! > While searching for help about that, I noticed that there is no help > around - I will have to get it separately. As generating an online help is time-consuming and always out-of-date, I don't do it anymore. The help needs internet now. But: 1) This may change in the future, after the first release candidate. 2) You can use a web spider to generate the online help, but it takes a long time, there are a lot of pages, even if you download the english pages only. > 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. > Unfortunately, the CAlsa class is full of pointer > playing. Anyway, I tried to do a little step ahead. I have a call to > initialize alsa: > > 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. 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 > > Now alsa is correctly initialized, but the rest of the class relies > heavily on pointers, and I am not ready to convert all that mess into > gambas structures (have no information about this topic). Read the wiki documentation on structures first. > 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. :-) > > 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! 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