Re: [Gambas-user] BUG Install on mandriva
Hello everybody, I tried to compile Gambas 2.21 from the svn. First of all, I observed that the problems with the share symbolic link between gb.qt and gb.gtk share folders are not existing with the sources from svn. The link is presente whereas it is not with the .tar.gz as I wrote above. I think you have a problem on your Mandriva, because the symbolic links are present in the *.tar.gz file. How do you uncompress it? Unfortunately as you will see in the attached file, I have another issue. Thank you for your answer. Best regards, Apparently your reconf-all output is truncated. Can you provide the full one? And can you run './reconf-all', './configure' and 'make' as a normal user? Regards, -- Benoît Minisini -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] BUG Install on mandriva
Doriano Blengino ha scritto: This leads to my last question: how can I download a local copy of the wiki? I tried two or three times with wget, but the result is unuseable. Forget it - I finally got what I need. May be that in the help, about pointers (url: /help/lang/type/pointer), it should be specified that Gambas3 does not permit anymore to read/write from them as they were a stream? Regards, Doriano Done. I did it in the READ and WRITE documentation pages. Regards, -- Benoît Minisini -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] BUG Install on mandriva
Rnak you, everything is fine now with the 2.20 release. I will check for the 2.21 issue as I will have time Le 27/07/2010 08:41, Benoît Minisini a écrit : Hello everybody, I tried to compile Gambas 2.21 from the svn. First of all, I observed that the problems with the share symbolic link between gb.qt and gb.gtk share folders are not existing with the sources from svn. The link is presente whereas it is not with the .tar.gz as I wrote above. I think you have a problem on your Mandriva, because the symbolic links are present in the *.tar.gz file. How do you uncompress it? Unfortunately as you will see in the attached file, I have another issue. Thank you for your answer. Best regards, Apparently your reconf-all output is truncated. Can you provide the full one? And can you run './reconf-all', './configure' and 'make' as a normal user? Regards, -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] BUG Install on mandriva
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. This is not possible, because Gambas use dynamic linking. You have to specify VarPtr() at function call. Moreover, even if I agree that the ByRef syntax is nicer, it cannot be used there again because of the dynamic linking: ByRef for a Gambas function implies compiling a different code than your ByRef for an extern function, and as Gambas may not know at compile time if a function is extern or intern, he cannot do that. Moreover, whereas ByRef can be applied to any Gambas assignment expression, VarPtr() can only be applied to a local variable or a global variable of the current class. So... 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? Yes, because data is read by using memcpy(), not a pointer access. The problem is: are you sure that pointers, memory streams and varptr() are needed? Yes. Having a stream allows to use all the stream functions, so it is useful. 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 admit that the design may not be perfect, but again all these syntax cover all the needed features for memory access. This is not just a matter of using one keyword instead of another one. And structures are implemented correctly, except that you cannot pack them. And beware: memory allocated by Alloc() must be freed with Free(), and you must not use Free() to free memory allocated by an extern function! Alloc() does not call the glibc malloc() directly, and Free() does not call the glibc free() directly too. Regards, -- Benoît Minisini -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] BUG Install on mandriva
Benoît Minisini ha scritto: 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. This is not possible, because Gambas use dynamic linking. You have to specify VarPtr() at function call. Moreover, even if I agree that the ByRef syntax is nicer, it cannot be used there again because of the dynamic linking: ByRef for a Gambas function implies compiling a different code than your ByRef for an extern function, and as Gambas may not know at compile time if a function is extern or intern, he cannot do that. I understand. I admit that the design may not be perfect, but again all these syntax cover all the needed features for memory access. This is not just a matter of using one keyword instead of another one. And structures are implemented correctly, except that you cannot pack them. And beware: memory allocated by Alloc() must be freed with Free(), and you must not use Free() to free memory allocated by an extern function! Alloc() does not call the glibc malloc() directly, and Free() does not call the glibc free() directly too. I see your point - I will use what's already inside the box. This leads to my last question: how can I download a local copy of the wiki? I tried two or three times with wget, but the result is unuseable. Regards, Doriano -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] BUG Install on mandriva
Doriano Blengino ha scritto: This leads to my last question: how can I download a local copy of the wiki? I tried two or three times with wget, but the result is unuseable. Forget it - I finally got what I need. May be that in the help, about pointers (url: /help/lang/type/pointer), it should be specified that Gambas3 does not permit anymore to read/write from them as they were a stream? Regards, Doriano -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] BUG Install on mandriva
Benoît Minisini ha scritto: Sorry, but the sources haven't got gb.qt4 but only gb.qt Florent talks about compiling Gambas 2 from the *.tar.bz2 sources, whereas Doriano talks about compiling Gambas 3 from the subversion repository! Yes - sorry. I was so deep inside my problems that I made a wrong mental connection. Be careful! To Doriano: if you have a file instead of a symbolic link, then I think this is a uncompatibility problem between your subversion client and the sourceforge subversion server. How do you checkout? Hm - I did not use svn, I downloaded a tarball from surceforge. Here at home I can not connect to internet, so I downloaded a .tar.gz file and extracted it into my machine. The first time sourceforge gave me a file 400Mib long, the second time something else went wrong, it seems. 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. Regards, Doriano -- 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
Re: [Gambas-user] BUG Install on mandriva
Benoît Minisini ha scritto: Sorry, but the sources haven't got gb.qt4 but only gb.qt Florent talks about compiling Gambas 2 from the *.tar.bz2 sources, whereas Doriano talks about compiling Gambas 3 from the subversion repository! Yes - sorry. I was so deep inside my problems that I made a wrong mental connection. Be careful! To Doriano: if you have a file instead of a symbolic link, then I think this is a uncompatibility problem between your subversion client and the sourceforge subversion server. How do you checkout? Hm - I did not use svn, I downloaded a tarball from surceforge. Here at home I can not connect to internet, so I downloaded a .tar.gz file and extracted it into my machine. The first time sourceforge gave me a file 400Mib long, the second time something else went wrong, it seems. 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. Regards, Doriano 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. 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
Re: [Gambas-user] BUG Install on mandriva
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. 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); 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. 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? This seems to be a back-compatibility break. While searching for help about that, I noticed that there is no help around - I will have to get it separately. 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?). 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. 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). 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. What should I do now? Regards, Doriano -- 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
Re: [Gambas-user] BUG Install on mandriva
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
Re: [Gambas-user] BUG Install on mandriva
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.
Re: [Gambas-user] BUG Install on mandriva
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
Re: [Gambas-user] BUG Install on mandriva
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 -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] BUG Install on mandriva
Thank you for answering again, I thought that my first post had the same message but it's wrong. So I compiled another time. First try : reconf then all the commmands in the gb.qt.kde component : outputRootComponent.txt attached. Second try : reconf-all then all the commands : outputRootGlobal.txt All thos try have been compiled under root priviledges. I remiend that I work under Mandriva 2010.0 and I follow the tutorial here : http://gambasdoc.org/help/install/mandriva Best regards As I said, I need the *full* output of the configuration and installation process. To do that, follow what is explained in the Reporting a problem page on the web site, especially the paragraph #2. I don't know what you installed exactly as KDE3 development headers... I suggest you install the KDE3 packages from Mandriva 2009.1: - kdebase3-common - libkdecore4 - libkdecore4-devel Or just disable the compilation of KDE components at configuration time (./configure --help for more information). 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
Re: [Gambas-user] BUG Install on mandriva
Hy, I'm really sorry, but I followed strictly the procedure described in the install file. So I now I consider the website here are some additionnal pieces of information : Mandriva 2010.0 Intel Centrino DUo Kernel : 2.6.31.13-desktop-1mnb Trying to compile gambase 2.20 what is installed : kdebase3-common for 2009.1 kdebase3 libkdecore4 libkdecore4-devel here in attached file the different step of my compilation executed as root on the main folder : 1 # ./reconf-all 1-recon-all_as_root.txt 21 see in attached file 2 # ./configure 2-configure_as_root.txt 21 see in attached file 3 # make 3-make_as_root.txt 21 see in attached file The error is at the end of the third file. If you ask something more to me, please precise what you want because, I think I followed the procedure, isn't it? Anyway, I really want to thank you for considering my emails. Best regards Le 24/07/2010 10:14, Benoît Minisini a écrit : Thank you for answering again, I thought that my first post had the same message but it's wrong. So I compiled another time. First try : reconf then all the commmands in the gb.qt.kde component : outputRootComponent.txt attached. Second try : reconf-all then all the commands : outputRootGlobal.txt All thos try have been compiled under root priviledges. I remiend that I work under Mandriva 2010.0 and I follow the tutorial here :http://gambasdoc.org/help/install/mandriva Best regards As I said, I need the *full* output of the configuration and installation process. To do that, follow what is explained in the Reporting a problem page on the web site, especially the paragraph #2. I don't know what you installed exactly as KDE3 development headers... I suggest you install the KDE3 packages from Mandriva 2009.1: - kdebase3-common - libkdecore4 - libkdecore4-devel Or just disable the compilation of KDE components at configuration time (./configure --help for more information). Regards, Allcommands as root.tar.gz Description: GNU Zip compressed data -- 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
Re: [Gambas-user] BUG Install on mandriva
MailingLists ha scritto: Thank you for answering. I executed the following command in order to have the symbolici link: ln -s gb.qt/share/ gb.gtk/share. No more success but I have an idea. Ehm... shouldn't it be ln -s gb.qt4/share/ gb.gtk/share? Note in qt4 then 4 after qt... Probably a typo in this email, but who knows...? Regards, Doriano Actually as I saw that you put a new release I try to compile it. And when I decompress the archive, I have 2 times this message : tar:/gb.qt/share is a folder whereas a file was expected. As it concerns the folder you were talking about, I imagine that it could help you. I execute the make command on the 2.21 release and attach you the result. Best regards Le 24/07/2010 14:02, Benoît Minisini a écrit : Hy, I'm really sorry, but I followed strictly the procedure described in the install file. So I now I consider the website here are some additionnal pieces of information : Mandriva 2010.0 Intel Centrino DUo Kernel : 2.6.31.13-desktop-1mnb Trying to compile gambase 2.20 what is installed : kdebase3-common for 2009.1 kdebase3 libkdecore4 libkdecore4-devel here in attached file the different step of my compilation executed as root on the main folder : 1 # ./reconf-all 1-recon-all_as_root.txt 21 see in attached file 2 # ./configure 2-configure_as_root.txt 21 see in attached file 3 # make 3-make_as_root.txt 21 see in attached file The error is at the end of the third file. If you ask something more to me, please precise what you want because, I think I followed the procedure, isn't it? Now yes. :-) You have an error message about a missing file that should be there. Do you have a symbolic linkSOURCEDIR/gb.gtk/share that points at SOURCEDIR/gb.qt/share?SOURCEDIR is the directory of the gambas sources you uncompressed... -- 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 -- 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
Re: [Gambas-user] BUG Install on mandriva
I dont know if I am too late, just try this: (made some mistakes myself with even the properties of the trunk) kill the trunk what you allready has. rm -r, stay sure you are on the right position. then just follow the lines on the gambas-hp, using the commands for your system. and if using ubuntu, mkdir WITHOUT sudo. that is important. worked for me. regards, dag Am Freitag, den 23.07.2010, 21:55 + schrieb MailingLists: Hy, thank you to all of us for answering so fast. But the problem still even with root priviledges Le 23/07/2010 17:31, Benoît Minisini a écrit : Hy, My first time on this list. I'm french and discover Gambas as I was looking for a data modeler for postgreSQL. Naturally I found the project pgDesigner from luigi carlotto. This project is using gb-qt-kde but I'm currently working on mandriva 2010 with no KDE3.x packages. So I installed the appropriate kde3.x developement header and try to compile and install the appropriate component form the 2.20 sources Unfortunately O have a bug and I didn't succeed in managing this issue. Any help would be welcome, Best regards --- French version Permission non accordée signifie qu'il faut faire l'installation en root. Cordialement, --- Version anglaise Permission non accordé means that you have to make install being root. Regards, -- 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 -- 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
Re: [Gambas-user] BUG Install on mandriva
Sorry, but the sources haven't got gb.qt4 but only gb.qt Florent talks about compiling Gambas 2 from the *.tar.bz2 sources, whereas Doriano talks about compiling Gambas 3 from the subversion repository! Be careful! To Doriano: if you have a file instead of a symbolic link, then I think this is a uncompatibility problem between your subversion client and the sourceforge subversion server. How do you checkout? -- 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
[Gambas-user] BUG Install on mandriva
Hy, My first time on this list. I'm french and discover Gambas as I was looking for a data modeler for postgreSQL. Naturally I found the project pgDesigner from luigi carlotto. This project is using gb-qt-kde but I'm currently working on mandriva 2010 with no KDE3.x packages. So I installed the appropriate kde3.x developement header and try to compile and install the appropriate component form the 2.20 sources Unfortunately O have a bug and I didn't succeed in managing this issue. Any help would be welcome, Best regards checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for style of include used by make... GNU checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking dependency style of gcc... gcc3 checking whether to enable maintainer-specific portions of Makefiles... no checking whether ln -s works... yes checking how to run the C preprocessor... gcc -E checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ISO C89... (cached) none needed checking dependency style of gcc... (cached) gcc3 checking whether make sets $(MAKE)... (cached) yes checking for long double with more range or precision than double... yes checking for setenv... yes checking for unsetenv... yes checking for getdomainname... yes checking for getpt... yes checking for ccache... no checking for main in -lm... yes checking for main in -lz... yes checking for main in -lgcc_s... yes checking for main in -lstdc++... yes checking target system... LINUX checking target architecture... X86 checking which extension is used for shared libraries... .so checking for threading compiler options... -D_REENTRANT checking for threading linker options... -lpthread checking for mathematic libraries... -lm checking for external gettext library... checking CFLAGS for gcc -fvisibility=hidden... -fvisibility=hidden checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for fgrep... /bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking the maximum length of command line arguments... 1572864 checking whether the shell understands some XSI constructs... yes checking whether the shell understands +=... yes checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for ar... ar checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking whether we are using the GNU C++ compiler... (cached) yes checking whether g++ accepts -g... (cached) yes checking dependency style of g++... (cached) gcc3 checking how to run the C++ preprocessor... g++ -E checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking for shl_load... no checking for shl_load in -ldld... no checking for dlopen... no checking for dlopen in -ldl... yes checking whether a program can dlopen itself... yes checking whether a
Re: [Gambas-user] BUG Install on mandriva
Hi, if you don't have to distribute at once, I would use the SVN-version of Gambas. I used the 2.x version too, but experienced a lot of troubles. It is stable, but in the SVN aka 2.99 aka 3.0 you will find many improvements. In my experience, the SVN pays out - no matter what database you are connecting to. (I'm a MySQL-fan, but have connected to everything I found, just to look). Regards, Dag Harle Johansen Am Freitag, den 23.07.2010, 14:12 + schrieb MailingLists: Hy, My first time on this list. I'm french and discover Gambas as I was looking for a data modeler for postgreSQL. Naturally I found the project pgDesigner from luigi carlotto. This project is using gb-qt-kde but I'm currently working on mandriva 2010 with no KDE3.x packages. So I installed the appropriate kde3.x developement header and try to compile and install the appropriate component form the 2.20 sources Unfortunately O have a bug and I didn't succeed in managing this issue. Any help would be welcome, Best regards -- 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 -- 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
Re: [Gambas-user] BUG Install on mandriva
Hi, sorry, forgot to tell, I am using ubuntu 10.04, with gnome. No KDE. Dag again Am Freitag, den 23.07.2010, 14:12 + schrieb MailingLists: Hy, My first time on this list. I'm french and discover Gambas as I was looking for a data modeler for postgreSQL. Naturally I found the project pgDesigner from luigi carlotto. This project is using gb-qt-kde but I'm currently working on mandriva 2010 with no KDE3.x packages. So I installed the appropriate kde3.x developement header and try to compile and install the appropriate component form the 2.20 sources Unfortunately O have a bug and I didn't succeed in managing this issue. Any help would be welcome, Best regards -- 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 -- 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
Re: [Gambas-user] BUG Install on mandriva
Hy, My first time on this list. I'm french and discover Gambas as I was looking for a data modeler for postgreSQL. Naturally I found the project pgDesigner from luigi carlotto. This project is using gb-qt-kde but I'm currently working on mandriva 2010 with no KDE3.x packages. So I installed the appropriate kde3.x developement header and try to compile and install the appropriate component form the 2.20 sources Unfortunately O have a bug and I didn't succeed in managing this issue. Any help would be welcome, Best regards --- French version Permission non accordée signifie qu'il faut faire l'installation en root. Cordialement, --- Version anglaise Permission non accordé means that you have to make install being root. 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
Re: [Gambas-user] BUG Install on mandriva
Hy, thank you to all of us for answering so fast. But the problem still even with root priviledges Le 23/07/2010 17:31, Benoît Minisini a écrit : Hy, My first time on this list. I'm french and discover Gambas as I was looking for a data modeler for postgreSQL. Naturally I found the project pgDesigner from luigi carlotto. This project is using gb-qt-kde but I'm currently working on mandriva 2010 with no KDE3.x packages. So I installed the appropriate kde3.x developement header and try to compile and install the appropriate component form the 2.20 sources Unfortunately O have a bug and I didn't succeed in managing this issue. Any help would be welcome, Best regards --- French version Permission non accordée signifie qu'il faut faire l'installation en root. Cordialement, --- Version anglaise Permission non accordé means that you have to make install being root. Regards, -- 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
Re: [Gambas-user] BUG Install on mandriva
Hy, thank you to all of us for answering so fast. But the problem still even with root priviledges If you don't provide the full output of all configuration and compilation process, nobody can help you! -- 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
