From gambas at ...1... Sun Apr 6 13:06:42 2014 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Sun, 06 Apr 2014 13:06:42 +0200 Subject: [Gambas-devel] GB.Signal.Register() keeps program running? In-Reply-To: <20140406092128.GA516@...693...> References: <20140204170401.GE515@...693...> <52F16D38.70204@...1...> <20140205115800.GA8944@...693...> <53407BD1.4080009@...1...> <20140406092128.GA516@...693...> Message-ID: <53413542.3070703@...1...> Le 06/04/2014 11:21, Tobias Boege a ?crit : > On Sat, 05 Apr 2014, Beno?t Minisini wrote: >> Le 05/02/2014 12:58, Tobias Boege a ?crit : >>>> >>>> Yes, you must use GB.Signal.Unregister() to remove the signal handler. >>>> >>> >>> Hmm, but when? How about this: I always register the signal handler and use >>> GB_HOOK_WATCH to detect when nothing is watched anymore. Then, I can remove >>> the signal handler and the program will terminate. >>> >>> The only case where this doesn't work, is when nothing is watched at all >>> during the process' lifetime... >>> >>> Regards, >>> Tobi >>> >> >> Hi Tobias, >> >> I suggest that you have a counter that counts the number of opened windows >> (do you have just one with gb.ncurses?). >> >> When you create/open a window, you increment the counter, and call >> GB.Signal.Register() for the first window. >> >> Then you add a Window.Close() method. If the user calls it, the window is >> closed (whatever that means), and the counter is decremented. If the counter >> reaches zero, then you call GB.Signal.Unregister(). >> >> It will be up to the user to call the Close() method to end the program. >> >> What do you think? >> > > There are potentially multiple windows in gb.ncurses and a Close() method > makes perfect sense, even in the terms of ncurses (delwin()). But if you > close a window then, you can't open it anymore - it is destroyed. > > Would that behaviour be compatible with that of other Window classes > (like in gb.qt4)? If not, I could trick a bit so that the window seems gone > and the counter is decremented but the window is always ready to be > repainted. Do your best. If "closing" <> "destroy" is useful with gb.ncurses, implement it. Otherwise don't. > >> By the way, why both ncurses example have a red background? It is normal? >> > > Ui! Normally (read: on my system) they're black. But neither Pong nor > Invaders modify the background. Has your terminal a red background by > default? > > Regards, > Tobi > No, my background is black. This is why I found that strange. I use KDE and so my terminal emulator is Konsole. -- Beno?t Minisini From gambas at ...1... Sun Apr 6 13:26:30 2014 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Sun, 06 Apr 2014 13:26:30 +0200 Subject: [Gambas-devel] GB.Signal.Register() keeps program running? In-Reply-To: <53413542.3070703@...1...> References: <20140204170401.GE515@...693...> <52F16D38.70204@...1...> <20140205115800.GA8944@...693...> <53407BD1.4080009@...1...> <20140406092128.GA516@...693...> <53413542.3070703@...1...> Message-ID: <534139E6.6080601@...1...> On Sun, 06 Apr 2014, Beno?t Minisini wrote: > >>By the way, why both ncurses example have a red background? It is normal? > >> > > > >Ui! Normally (read: on my system) they're black. But neither Pong nor > >Invaders modify the background. Has your terminal a red background by > >default? > > > >Regards, > >Tobi > > > > No, my background is black. This is why I found that strange. I use KDE and > so my terminal emulator is Konsole. When I tick Konsole as terminal emulator in my IDE's Preferences, the program won't even start (immediately returns 254). I'm using TDE 3.5.13, so I use Konsole every day but for Gambas projects I have settled to xterm long ago (maybe that strange behaviour was the reason?). Could you try to use xterm and tell me what happens? If it's better, I have at least a direction where to look... -- "There's an old saying: Don't change anything... ever!" -- Mr. Monk From gambas at ...1... Sun Apr 6 13:32:24 2014 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Sun, 06 Apr 2014 13:32:24 +0200 Subject: [Gambas-devel] GB.Signal.Register() keeps program running? In-Reply-To: <534139E6.6080601@...1...> References: <20140204170401.GE515@...693...> <52F16D38.70204@...1...> <20140205115800.GA8944@...693...> <53407BD1.4080009@...1...> <20140406092128.GA516@...693...> <53413542.3070703@...1...> <534139E6.6080601@...1...> Message-ID: <53413B48.3030402@...1...> Le 06/04/2014 13:26, Beno?t Minisini a ?crit : > On Sun, 06 Apr 2014, Beno?t Minisini wrote: >>>> By the way, why both ncurses example have a red background? It is normal? >>>> >>> >>> Ui! Normally (read: on my system) they're black. But neither Pong nor >>> Invaders modify the background. Has your terminal a red background by >>> default? >>> >>> Regards, >>> Tobi >>> >> >> No, my background is black. This is why I found that strange. I use KDE and >> so my terminal emulator is Konsole. > > When I tick Konsole as terminal emulator in my IDE's Preferences, the > program won't even start (immediately returns 254). I'm using TDE 3.5.13, > so I use Konsole every day but for Gambas projects I have settled to xterm > long ago (maybe that strange behaviour was the reason?). > > Could you try to use xterm and tell me what happens? If it's better, I have > at least a direction where to look... > With xterm I have a black background. If I choose xterm as terminal in the IDE, the program runs correctly, but if I close the xterm window during its execution, it segfaults. But I didn't succeed in reproducing that outside of the IDE. What returns "254" when you choose Konsole? -- Beno?t Minisini From tobias at ...692... Sun Apr 6 13:38:37 2014 From: tobias at ...692... (Tobias Boege) Date: Sun, 6 Apr 2014 13:38:37 +0200 Subject: [Gambas-devel] GB.Signal.Register() keeps program running? In-Reply-To: <53413B48.3030402@...1...> References: <20140204170401.GE515@...693...> <52F16D38.70204@...1...> <20140205115800.GA8944@...693...> <53407BD1.4080009@...1...> <20140406092128.GA516@...693...> <53413542.3070703@...1...> <534139E6.6080601@...1...> <53413B48.3030402@...1...> Message-ID: <20140406113837.GD516@...693...> On Sun, 06 Apr 2014, Beno?t Minisini wrote: > Le 06/04/2014 13:26, Beno?t Minisini a ?crit : > > On Sun, 06 Apr 2014, Beno?t Minisini wrote: > >>>> By the way, why both ncurses example have a red background? It is normal? > >>>> > >>> > >>> Ui! Normally (read: on my system) they're black. But neither Pong nor > >>> Invaders modify the background. Has your terminal a red background by > >>> default? > >>> > >>> Regards, > >>> Tobi > >>> > >> > >> No, my background is black. This is why I found that strange. I use KDE and > >> so my terminal emulator is Konsole. > > > > When I tick Konsole as terminal emulator in my IDE's Preferences, the > > program won't even start (immediately returns 254). I'm using TDE 3.5.13, > > so I use Konsole every day but for Gambas projects I have settled to xterm > > long ago (maybe that strange behaviour was the reason?). > > > > Could you try to use xterm and tell me what happens? If it's better, I have > > at least a direction where to look... > > > > With xterm I have a black background. > > If I choose xterm as terminal in the IDE, the program runs correctly, > but if I close the xterm window during its execution, it segfaults. But > I didn't succeed in reproducing that outside of the IDE. > Hmm. I can't reproduce that inside or outside of the IDE (tried 5 times at different stages in program logic). > What returns "254" when you choose Konsole? > When I hit the "play" button, that Balloon appears over my project TreeView on the left saying: "The program has returned the value: 254". PS: Sorry, this time, the mail will go the mailing list! -- "There's an old saying: Don't change anything... ever!" -- Mr. Monk From gambas at ...1... Sun Apr 6 14:11:05 2014 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Sun, 06 Apr 2014 14:11:05 +0200 Subject: [Gambas-devel] GB.Signal.Register() keeps program running? In-Reply-To: <20140406113837.GD516@...693...> References: <20140204170401.GE515@...693...> <52F16D38.70204@...1...> <20140205115800.GA8944@...693...> <53407BD1.4080009@...1...> <20140406092128.GA516@...693...> <53413542.3070703@...1...> <534139E6.6080601@...1...> <53413B48.3030402@...1...> <20140406113837.GD516@...693...> Message-ID: <53414459.7090802@...1...> Le 06/04/2014 13:38, Tobias Boege a ?crit : > On Sun, 06 Apr 2014, Beno?t Minisini wrote: >> Le 06/04/2014 13:26, Beno?t Minisini a ?crit : >>> On Sun, 06 Apr 2014, Beno?t Minisini wrote: >>>>>> By the way, why both ncurses example have a red background? It is normal? >>>>>> >>>>> >>>>> Ui! Normally (read: on my system) they're black. But neither Pong nor >>>>> Invaders modify the background. Has your terminal a red background by >>>>> default? >>>>> >>>>> Regards, >>>>> Tobi >>>>> >>>> >>>> No, my background is black. This is why I found that strange. I use KDE and >>>> so my terminal emulator is Konsole. >>> >>> When I tick Konsole as terminal emulator in my IDE's Preferences, the >>> program won't even start (immediately returns 254). I'm using TDE 3.5.13, >>> so I use Konsole every day but for Gambas projects I have settled to xterm >>> long ago (maybe that strange behaviour was the reason?). >>> >>> Could you try to use xterm and tell me what happens? If it's better, I have >>> at least a direction where to look... >>> >> >> With xterm I have a black background. >> >> If I choose xterm as terminal in the IDE, the program runs correctly, >> but if I close the xterm window during its execution, it segfaults. But >> I didn't succeed in reproducing that outside of the IDE. >> > > Hmm. I can't reproduce that inside or outside of the IDE (tried 5 times at > different stages in program logic). > >> What returns "254" when you choose Konsole? >> > > When I hit the "play" button, that Balloon appears over my project TreeView > on the left saying: "The program has returned the value: 254". > > PS: Sorry, this time, the mail will go the mailing list! > Here are two screenshots, so that you confirm I'm not daltonic. :-) -- Beno?t Minisini -------------- next part -------------- A non-text attachment was scrubbed... Name: ncurses1.png Type: image/png Size: 18215 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ncurses2.png Type: image/png Size: 16645 bytes Desc: not available URL: From ron at ...572... Tue Apr 8 20:15:23 2014 From: ron at ...572... (Ron) Date: Tue, 8 Apr 2014 20:15:23 +0200 Subject: [Gambas-devel] Gambas 3.5.3 Message-ID: Is building 3.5.3 broken or did I miss something? ~/gambas$ ./reconf-all libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: You should add the contents of the following files to `aclocal.m4': libtoolize: `/usr/share/aclocal/libtool.m4' libtoolize: `/usr/share/aclocal/ltoptions.m4' libtoolize: `/usr/share/aclocal/ltversion.m4' libtoolize: `/usr/share/aclocal/ltsugar.m4' libtoolize: `/usr/share/aclocal/lt~obsolete.m4' libtoolize: Remember to add `LT_INIT' to configure.ac. libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --output=aclocal.m4t Can't exec "aclocal": No such file or directory at /usr/share/autoconf/Autom4te/FileUtils.pm line 326. autoreconf: failed to run aclocal: No such file or directory Regards, Ron. From ron at ...572... Tue Apr 8 20:47:08 2014 From: ron at ...572... (Ron) Date: Tue, 8 Apr 2014 20:47:08 +0200 Subject: [Gambas-devel] Gambas 3.5.3 In-Reply-To: References: Message-ID: please ignore automake was not found. 2014-04-08 20:15 GMT+02:00 Ron : > Is building 3.5.3 broken or did I miss something? > > ~/gambas$ ./reconf-all > libtoolize: putting auxiliary files in `.'. > libtoolize: copying file `./ltmain.sh' > libtoolize: You should add the contents of the following files to `aclocal.m4': > libtoolize: `/usr/share/aclocal/libtool.m4' > libtoolize: `/usr/share/aclocal/ltoptions.m4' > libtoolize: `/usr/share/aclocal/ltversion.m4' > libtoolize: `/usr/share/aclocal/ltsugar.m4' > libtoolize: `/usr/share/aclocal/lt~obsolete.m4' > libtoolize: Remember to add `LT_INIT' to configure.ac. > libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and > libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. > libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. > autoreconf: Entering directory `.' > autoreconf: configure.ac: not using Gettext > autoreconf: running: aclocal --output=aclocal.m4t > Can't exec "aclocal": No such file or directory at > /usr/share/autoconf/Autom4te/FileUtils.pm line 326. > autoreconf: failed to run aclocal: No such file or directory > > Regards, > Ron. From willy at ...732... Sun Apr 13 13:35:14 2014 From: willy at ...732... (Willy Raets) Date: Sun, 13 Apr 2014 13:35:14 +0200 Subject: [Gambas-devel] Subversion Message-ID: <1397388914.2539.9.camel@...735...> Hi all, Beno?t granted me write access to the Gambas svn repo a while ago. This so I would be able to upload translations myself, instead of sending all to him. I had a look at the instructions in the Gambas Wiki(http://gambaswiki.org/wiki/howto/svn). Somehow it is not working for me, so either something in the instructions is not quite as it should or I am misunderstanding them. For checkout wiki says: svn checkout --username=<user> svn +ssh://gambas at ...733.../p/gambas/code/gambas/trunk I replaced user with my Source Forge account name that Beno?t granted write access, but this generated some errors: willy at ...734... ~/Gambas3 $ svn checkout --username=<myusername> svn +ssh://gambas at ...733.../p/gambas/code/gambas/trunk [1] 3703 bash: /usr/bin/lt: File or directory does not exist bash: svn+ssh://gambas at ...733.../p/gambas/code/gambas/trunk: File or directory does not exist willy at ...734... ~/Gambas3 $ svn: E205001: Try 'svn help' for more info svn: E205001: Not enough arguments provided What am I doing wrong? P.S. I have done checkouts before, but just to compile and install Gambas, never with write access. I have looked at svn help but it is not helpful at all. -- Kind regards, Willy (aka gbWilly) http://gambasshowcase.org/ http://howtogambas.org http://gambos.org From tobias at ...692... Sun Apr 13 15:44:06 2014 From: tobias at ...692... (Tobias Boege) Date: Sun, 13 Apr 2014 15:44:06 +0200 Subject: [Gambas-devel] Subversion In-Reply-To: <1397388914.2539.9.camel@...735...> References: <1397388914.2539.9.camel@...735...> Message-ID: <20140413134406.GA622@...693...> On Sun, 13 Apr 2014, Willy Raets wrote: > Hi all, > > Beno??t granted me write access to the Gambas svn repo a while ago. > This so I would be able to upload translations myself, instead of > sending all to him. > > I had a look at the instructions in the Gambas > Wiki(http://gambaswiki.org/wiki/howto/svn). > > Somehow it is not working for me, so either something in the > instructions is not quite as it should or I am misunderstanding them. > > For checkout wiki says: > svn checkout --username=<user> svn > +ssh://gambas at ...733.../p/gambas/code/gambas/trunk > > I replaced user with my Source Forge account name that Beno??t granted > write access, but this generated some errors: > > willy at ...734... ~/Gambas3 $ svn checkout --username=<myusername> svn > +ssh://gambas at ...733.../p/gambas/code/gambas/trunk > [1] 3703 > bash: /usr/bin/lt: File or directory does not exist > bash: svn+ssh://gambas at ...733.../p/gambas/code/gambas/trunk: File > or directory does not exist > willy at ...734... ~/Gambas3 $ svn: E205001: Try 'svn help' for more info > svn: E205001: Not enough arguments provided > > What am I doing wrong? > > P.S. I have done checkouts before, but just to compile and install > Gambas, never with write access. I have looked at svn help but it is not > helpful at all. > "<" is an HTML entity for "<", so the above --username parameter string would look like "--username=", so that only denotes a placeholder. The correct line is: $ svn co --username=name svn+ssh://... where you literally replace "name" by your username. Regards, Tobi -- "There's an old saying: Don't change anything... ever!" -- Mr. Monk From rmorgan62 at ...176... Wed Apr 16 03:23:24 2014 From: rmorgan62 at ...176... (Randall Morgan) Date: Tue, 15 Apr 2014 18:23:24 -0700 Subject: [Gambas-devel] Gambas Logo Message-ID: I am not sure who created the Gambas logos but I am hoping they are on this mailing list. I would like to inquire about the licensing of the logo. Is it creative commons or something else. I'd like to use the logo for an online Gambas Magazine to help support the community. And would like to incorporate the logo into the magazine header and other locations. So I am simply looking for permission and artwork. I am also looking for articles and article ideas for issues. While the site is is just now being setup and there is no current issues yet. You can find the site at: http://www.gambasmag.com There is a submission guidelines page and the magazine will be donation-ware to help support the magazine. If anyone here is interested in submitting articles or if you have article suggestions please contact me via this thread, or on the website or at editor.gambasmag at ...176... Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at ...692... Wed Apr 16 14:57:49 2014 From: tobias at ...692... (Tobias Boege) Date: Wed, 16 Apr 2014 14:57:49 +0200 Subject: [Gambas-devel] Gambas Logo In-Reply-To: References: Message-ID: <20140416125749.GC513@...693...> On Tue, 15 Apr 2014, Randall Morgan wrote: > I am not sure who created the Gambas logos but I am hoping they are on this > mailing list. I would like to inquire about the licensing of the logo. Is > it creative commons or something else. I'd like to use the logo for an > online Gambas Magazine to help support the community. And would like to > incorporate the logo into the magazine header and other locations. So I am > simply looking for permission and artwork. > > I am also looking for articles and article ideas for issues. While the site > is is just now being setup and there is no current issues yet. You can find > the site at: http://www.gambasmag.com > > There is a submission guidelines page and the magazine will be > donation-ware to help support the magazine. > > If anyone here is interested in submitting articles or if you have article > suggestions please contact me via this thread, or on the website or at > editor.gambasmag at ...176... > > Thanks! Marvellous idea! I think it was me who last asked about the logo's license. So I guess it's me to pass the baton on to you: [0]. :-) Regards, Tobi [0] http://sourceforge.net/p/gambas/mailman/message/31694840/ -- "There's an old saying: Don't change anything... ever!" -- Mr. Monk From gambas.fr at ...176... Wed Apr 16 17:58:16 2014 From: gambas.fr at ...176... (Fabien Bodard) Date: Wed, 16 Apr 2014 17:58:16 +0200 Subject: [Gambas-devel] Gambas Logo In-Reply-To: <20140416125749.GC513@...693...> References: <20140416125749.GC513@...693...> Message-ID: Yes it's ok... Free to use if related with our favorite language Le 16 avr. 2014 14:59, "Tobias Boege" a ?crit : > On Tue, 15 Apr 2014, Randall Morgan wrote: > > I am not sure who created the Gambas logos but I am hoping they are on > this > > mailing list. I would like to inquire about the licensing of the logo. Is > > it creative commons or something else. I'd like to use the logo for an > > online Gambas Magazine to help support the community. And would like to > > incorporate the logo into the magazine header and other locations. So I > am > > simply looking for permission and artwork. > > > > I am also looking for articles and article ideas for issues. While the > site > > is is just now being setup and there is no current issues yet. You can > find > > the site at: http://www.gambasmag.com > > > > There is a submission guidelines page and the magazine will be > > donation-ware to help support the magazine. > > > > If anyone here is interested in submitting articles or if you have > article > > suggestions please contact me via this thread, or on the website or at > > editor.gambasmag at ...176... > > > > Thanks! > > Marvellous idea! > > I think it was me who last asked about the logo's license. So I guess it's > me to pass the baton on to you: [0]. :-) > > Regards, > Tobi > > [0] http://sourceforge.net/p/gambas/mailman/message/31694840/ > > -- > "There's an old saying: Don't change anything... ever!" -- Mr. Monk > > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/NeoTech > _______________________________________________ > Gambas-devel mailing list > Gambas-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmorgan62 at ...176... Wed Apr 16 21:24:32 2014 From: rmorgan62 at ...176... (Randall Morgan) Date: Wed, 16 Apr 2014 12:24:32 -0700 Subject: [Gambas-devel] Gambas Logo In-Reply-To: References: <20140416125749.GC513@...693...> Message-ID: Thanks All! If any of you have sites or services related to Gambas please provide information and I will include it as a free service, at least for now. On Wed, Apr 16, 2014 at 8:58 AM, Fabien Bodard wrote: > Yes it's ok... Free to use if related with our favorite language > Le 16 avr. 2014 14:59, "Tobias Boege" a ?crit : > > On Tue, 15 Apr 2014, Randall Morgan wrote: >> > I am not sure who created the Gambas logos but I am hoping they are on >> this >> > mailing list. I would like to inquire about the licensing of the logo. >> Is >> > it creative commons or something else. I'd like to use the logo for an >> > online Gambas Magazine to help support the community. And would like to >> > incorporate the logo into the magazine header and other locations. So I >> am >> > simply looking for permission and artwork. >> > >> > I am also looking for articles and article ideas for issues. While the >> site >> > is is just now being setup and there is no current issues yet. You can >> find >> > the site at: http://www.gambasmag.com >> > >> > There is a submission guidelines page and the magazine will be >> > donation-ware to help support the magazine. >> > >> > If anyone here is interested in submitting articles or if you have >> article >> > suggestions please contact me via this thread, or on the website or at >> > editor.gambasmag at ...176... >> > >> > Thanks! >> >> Marvellous idea! >> >> I think it was me who last asked about the logo's license. So I guess it's >> me to pass the baton on to you: [0]. :-) >> >> Regards, >> Tobi >> >> [0] http://sourceforge.net/p/gambas/mailman/message/31694840/ >> >> -- >> "There's an old saying: Don't change anything... ever!" -- Mr. Monk >> >> >> >> ------------------------------------------------------------------------------ >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and their >> applications. Written by three acclaimed leaders in the field, >> this first edition is now available. Download your free book today! >> http://p.sf.net/sfu/NeoTech >> _______________________________________________ >> Gambas-devel mailing list >> Gambas-devel at lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/gambas-devel >> > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/NeoTech > _______________________________________________ > Gambas-devel mailing list > Gambas-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-devel > > -- If you ask me if it can be done. The answer is YES, it can always be done. The correct questions however are... What will it cost, and how long will it take? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at ...692... Sun Apr 20 10:57:36 2014 From: tobias at ...692... (Tobias Boege) Date: Sun, 20 Apr 2014 10:57:36 +0200 Subject: [Gambas-devel] GB.Signal.Register() keeps program running? In-Reply-To: <53414459.7090802@...1...> References: <20140204170401.GE515@...693...> <52F16D38.70204@...1...> <20140205115800.GA8944@...693...> <53407BD1.4080009@...1...> <20140406092128.GA516@...693...> <53413542.3070703@...1...> <534139E6.6080601@...1...> <53413B48.3030402@...1...> <20140406113837.GD516@...693...> <53414459.7090802@...1...> Message-ID: <20140420085736.GA843@...693...> On Sun, 06 Apr 2014, Beno?t Minisini wrote: > Le 06/04/2014 13:38, Tobias Boege a ?crit : > >On Sun, 06 Apr 2014, Beno?t Minisini wrote: > >>Le 06/04/2014 13:26, Beno?t Minisini a ?crit : > >>>On Sun, 06 Apr 2014, Beno?t Minisini wrote: > >>>>>>By the way, why both ncurses example have a red background? It is normal? > >>>>>> > >>>>> > >>>>>Ui! Normally (read: on my system) they're black. But neither Pong nor > >>>>>Invaders modify the background. Has your terminal a red background by > >>>>>default? > >>>>> > >>>>>Regards, > >>>>>Tobi > >>>>> > >>>> > >>>>No, my background is black. This is why I found that strange. I use KDE and > >>>>so my terminal emulator is Konsole. > >>> > >>>When I tick Konsole as terminal emulator in my IDE's Preferences, the > >>>program won't even start (immediately returns 254). I'm using TDE 3.5.13, > >>>so I use Konsole every day but for Gambas projects I have settled to xterm > >>>long ago (maybe that strange behaviour was the reason?). > >>> > >>>Could you try to use xterm and tell me what happens? If it's better, I have > >>>at least a direction where to look... > >>> > >> > >>With xterm I have a black background. > >> > >>If I choose xterm as terminal in the IDE, the program runs correctly, > >>but if I close the xterm window during its execution, it segfaults. But > >>I didn't succeed in reproducing that outside of the IDE. > >> > > > >Hmm. I can't reproduce that inside or outside of the IDE (tried 5 times at > >different stages in program logic). > > > >>What returns "254" when you choose Konsole? > >> > > > >When I hit the "play" button, that Balloon appears over my project TreeView > >on the left saying: "The program has returned the value: 254". > > > >PS: Sorry, this time, the mail will go the mailing list! > > > > Here are two screenshots, so that you confirm I'm not daltonic. :-) > Wow, I totally forgot this thread until I just saw a thread in the ncurses mailing list that subconsciously drew my attention (but why didn't it when I first saw it?): it is about colour initialisation problems in konsole- 256color and there was a patch merged into ncurses at the end of March. Maybe you can update ncurses and see if that helps? Regards, Tobi -- "There's an old saying: Don't change anything... ever!" -- Mr. Monk From mckaygerhard at ...176... Mon Apr 21 23:18:41 2014 From: mckaygerhard at ...176... (PICCORO McKAY Lenz) Date: Mon, 21 Apr 2014 16:48:41 -0430 Subject: [Gambas-devel] Gambas 3.5.3 Message-ID: DOES 3.5.3 release include the wiki example or web example complety? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at ...692... Tue Apr 22 11:26:48 2014 From: tobias at ...692... (Tobias Boege) Date: Tue, 22 Apr 2014 11:26:48 +0200 Subject: [Gambas-devel] Gambas 3.5.3 In-Reply-To: References: Message-ID: <20140422092647.GA1216@...693...> On Mon, 21 Apr 2014, PICCORO McKAY Lenz wrote: > DOES 3.5.3 release include the wiki example or web example complety? No. Gambas versions are structured as M.m.r. 3.5.3 is, as always when the r increases, a bugfix release. New features always come when m increases. So the Wiki example will be in 3.6. Regards, Tobi -- "There's an old saying: Don't change anything... ever!" -- Mr. Monk From nigel.dh.gerrard at ...176... Thu Apr 24 13:34:50 2014 From: nigel.dh.gerrard at ...176... (Nigel Gerrard) Date: Thu, 24 Apr 2014 12:34:50 +0100 Subject: [Gambas-devel] gb.ncurses Message-ID: During my testing on cygwin-X of gambas, the gb.ncurses component was crashing. Debugging gbx3 I found that the issue was related to c_input.c in gb.ncurses\src: GB_DESC CInputDesc[] = { GB_DECLARE("Input", 0), GB_NOT_CREATABLE(), GB_CONSTANT("NoTimeout", "i", TIMEOUT_NOTIMEOUT), GB_CONSTANT("Cooked", "i", INPUT_COOKED), GB_CONSTANT("CBreak", "i", INPUT_CBREAK), GB_CONSTANT("Raw", "i", INPUT_RAW), #if 0 GB_CONSTANT("NoDelay", "i", INPUT_NODELAY), GB_STATIC_PROPERTY_READ("IsConsole", "b", Input_IsConsole), GB_STATIC_PROPERTY("RepeatDelay", "i", Input_RepeatDelay), #endif GB_END_DECLARE /* Needs to be added */ }; Which was missing the GB_END_DECLARE. This seems to slip through ok on Linux builds but on the cygwin build crashed. Could you apply the change to the repository. Regards Nigel -------------- next part -------------- An HTML attachment was scrubbed... URL: From nigel.dh.gerrard at ...176... Thu Apr 24 13:46:40 2014 From: nigel.dh.gerrard at ...176... (Nigel Gerrard) Date: Thu, 24 Apr 2014 12:46:40 +0100 Subject: [Gambas-devel] Porting Gambas to cygwin Message-ID: Under cygwin and with cygwin-X I have been able to progress to a point where I can actually get some of the examples running and the IDE up but there are still a lot of things still to work on: One of the issues I have struggled to resolve is the following: $ make --trace Makefile:397: update target 'config.h' due to: stamp-h1 if test ! -f config.h; then rm -f stamp-h1; else :; fi if test ! -f config.h; then make stamp-h1; else :; fi Makefile:358: update target 'all' due to: config.h make all-recursive make[1]: Entering directory '/home/Administrator/gambas3-3.5.2/gb.sdl' Makefile:427: target 'all-recursive' does not exist fail=; \ if (target_option=k; case ${target_option-} in ?) ;; *) echo "am__make_running_with_option: internal error: invalid" "target option '${target_option-}' specified" >&2; exit 1;; esac; has_opt=no; sane_makeflags=$MAKEFLAGS; if test -n ' Makefile' && test -n '1'; then sane_makeflags=$MFLAGS; else case $MAKEFLAGS in *\\[\ \ ]*) bs=\\; sane_makeflags=`printf '%s\n' "$MAKEFLAGS" | sed "s/$bs$bs[$bs $bs ]*//g"`;; esac; fi; skip_next=no; strip_trailopt () { flg=`printf '%s\n' "$flg" | sed "s/$1.*$//"`; }; for flg in $sane_makeflags; do test $skip_next = yes && { skip_next=no; continue; }; case $flg in *=*|--*) continue;; -*I) strip_trailopt 'I'; skip_next=yes;; -*I?*) strip_trailopt 'I';; -*O) strip_trailopt 'O'; skip_next=yes;; -*O?*) strip_trailopt 'O';; -*l) strip_trailopt 'l'; skip_next=yes;; -*l?*) strip_trailopt 'l';; -[dEDm]) skip_next=yes;; -[JT]) skip_next=yes;; esac; case $flg in *$target_option*) has_opt=yes; break;; esac; done; test $has_opt = yes); then \ failcom='fail=yes'; \ else \ failcom='exit 1'; \ fi; \ dot_seen=no; \ target=`echo all-recursive | sed s/-recursive//`; \ case "all-recursive" in \ distclean-* | maintainer-clean-*) list='src' ;; \ *) list='src' ;; \ esac; \ for subdir in $list; do \ echo "Making $target in $subdir"; \ if test "$subdir" = "."; then \ dot_seen=yes; \ local_target="$target-am"; \ else \ local_target="$target"; \ fi; \ (CDPATH="${ZSH_VERSION+.}:" && cd $subdir && make $local_target) \ || eval $failcom; \ done; \ if test "$dot_seen" = "no"; then \ make "$target-am" || exit 1; \ fi; test -z "$fail" Making all in src make[2]: Entering directory '/home/Administrator/gambas3-3.5.2/gb.sdl/src' Makefile:614: update target 'gb_sdl_la-Cconst.lo' due to: Cconst.cpp ../gambas.h ../config.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/stdint.h /usr/include/stdint.h /usr/include/bits/wordsize.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/stddef.h /usr/include/sys/types.h /usr/include/_ansi.h /usr/include/newlib.h /usr/include/sys/config.h /usr/include/machine/ieeefp.h /usr/include/sys/features.h /usr/include/cygwin/config.h /usr/include/machine/_types.h /usr/include/machine/_default_types.h /usr/include/sys/_types.h /usr/include/sys/lock.h /usr/include/machine/types.h /usr/include/cygwin/types.h /usr/include/endian.h /usr/include/bits/endian.h /usr/include/byteswap.h /usr/include/sys/sysmacros.h Cconst.h main.h ../gb_common.h /usr/include/math.h /usr/include/sys/reent.h /usr/include/unistd.h /usr/include/sys/unistd.h /usr/include/sys/cdefs.h /usr/include/getopt.h /usr/include/stdlib.h /usr/include/machine/stdlib.h /usr/include/alloca.h /usr/include/cygwin/stdlib.h /usr/include/cygwin/wait.h /usr/include/stdio.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/stdarg.h /usr/include/sys/stdio.h /usr/include/string.h /usr/include/sys/string.h /usr/include/inttypes.h /usr/include/fcntl.h /usr/include/sys/fcntl.h /usr/include/sys/_default_fcntl.h /usr/include/sys/stat.h /usr/include/time.h /usr/include/machine/time.h /usr/include/cygwin/time.h /usr/include/signal.h /usr/include/sys/signal.h /usr/include/cygwin/signal.h /usr/include/cygwin/stat.h /usr/include/sys/time.h /usr/include/cygwin/sys_time.h /usr/include/sys/select.h /usr/include/sys/param.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include-fixed/limits.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include-fixed/syslimits.h /usr/include/limits.h /usr/include/features.h ../gb.image.h SDL_h.h /usr/include/GL/glew.h /usr/include/GL/glu.h /usr/include/GL/gl.h /usr/include/SDL/SDL.h /usr/include/SDL/SDL_main.h /usr/include/SDL/SDL_stdinc.h /usr/include/SDL/SDL_config.h /usr/include/SDL/SDL_platform.h /usr/include/strings.h /usr/include/ctype.h /usr/include/SDL/begin_code.h /usr/include/SDL/close_code.h /usr/include/SDL/SDL_audio.h /usr/include/SDL/SDL_error.h /usr/include/SDL/SDL_endian.h /usr/include/SDL/SDL_mutex.h /usr/include/SDL/SDL_thread.h /usr/include/SDL/SDL_rwops.h /usr/include/SDL/SDL_cdrom.h /usr/include/SDL/SDL_cpuinfo.h /usr/include/SDL/SDL_events.h /usr/include/SDL/SDL_active.h /usr/include/SDL/SDL_keyboard.h /usr/include/SDL/SDL_keysym.h /usr/include/SDL/SDL_mouse.h /usr/include/SDL/SDL_video.h /usr/include/SDL/SDL_joystick.h /usr/include/SDL/SDL_quit.h /usr/include/SDL/SDL_loadso.h /usr/include/SDL/SDL_timer.h /usr/include/SDL/SDL_version.h /usr/include/SDL/SDL_syswm.h /usr/include/X11/Xlib.h /usr/include/X11/X.h /usr/include/X11/Xfuncproto.h /usr/include/X11/Xosdefs.h /usr/include/X11/Xatom.h /usr/include/X11/cursorfont.h SDLapp.h SDLerror.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/string /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/i686-pc-cygwin/bits/c++config.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/i686-pc-cygwin/bits/os_defines.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/i686-pc-cygwin/bits/cpu_defines.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/stringfwd.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/memoryfwd.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/char_traits.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/stl_algobase.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/functexcept.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/exception_defines.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/cpp_type_traits.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/ext/type_traits.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/ext/numeric_traits.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/stl_pair.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/move.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/concept_check.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/stl_iterator_base_types.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/stl_iterator_base_funcs.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/debug/debug.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/stl_iterator.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/postypes.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/cwchar /usr/include/wchar.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/allocator.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/i686-pc-cygwin/bits/c++allocator.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/ext/new_allocator.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/new /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/exception /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/atomic_lockfree_defines.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/localefwd.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/i686-pc-cygwin/bits/c++locale.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/clocale /usr/include/locale.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/iosfwd /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/cctype /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/ostream_insert.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/cxxabi_forced.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/stl_function.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/backward/binders.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/range_access.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/basic_string.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/ext/atomicity.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/i686-pc-cygwin/bits/gthr.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/i686-pc-cygwin/bits/gthr-default.h /usr/include/pthread.h /usr/include/sched.h /usr/include/sys/sched.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/i686-pc-cygwin/bits/atomic_word.h /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/basic_string.tcc SDLdebug.h echo " CXX " gb_sdl_la-Cconst.lo;/bin/sh ../libtool --silent --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/SDL -I/usr/include/GL -pipe -Wall -fno-exceptions -Wno-unused-value -fsigned-char -g -ggdb -Os -fno-omit-frame-pointer -DDATA_DIR=\"/usr/share/gambas3/gb.sdl\" -MT gb_sdl_la-Cconst.lo -MD -MP -MF .deps/gb_sdl_la-Cconst.Tpo -c -o gb_sdl_la-Cconst.lo `test -f 'Cconst.cpp' || echo './'`Cconst.cpp CXX gb_sdl_la-Cconst.lo In file included from /usr/include/sys/types.h:20:0, from ../gambas.h:30, from Cconst.cpp:25: ../gambas.h:1213:22: error: expected initializer before '.' token #define strcasecmp GB.StrCaseCmp ^ ../gambas.h:1214:23: error: expected initializer before '.' token #define strncasecmp GB.StrNCaseCmp ^ Makefile:614: recipe for target 'gb_sdl_la-Cconst.lo' failed make[2]: *** [gb_sdl_la-Cconst.lo] Error 1 make[2]: Leaving directory '/home/Administrator/gambas3-3.5.2/gb.sdl/src' Makefile:427: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/Administrator/gambas3-3.5.2/gb.sdl' Makefile:358: recipe for target 'all' failed make: *** [all] Error 2 Any ideas as to what I am missing? Kind regards Nigel -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at ...692... Thu Apr 24 13:45:34 2014 From: tobias at ...692... (Tobias Boege) Date: Thu, 24 Apr 2014 13:45:34 +0200 Subject: [Gambas-devel] Should we provide different implementations to the same abstract datatype? Message-ID: <20140424114534.GA512@...693...> Hi Benoit, I want to implement a Graph class for gb.data and I'm struggling with what internal representation to use because depending on the application, one data structure may perform badly and another one well. This may invert for a different application. To have a well-performing Graph in their application, the programmer should choose the internals themselves and I'm thinking that I can do the following to support that: - Create a non-creatable class Graph that provides a common interface - Create a GraphAdjMatrix class which Inherits Graph and overrides its methods and properties to be an adjacency matrix based implementation - Create a GraphAdjList class " to be an adjacency list based implementation - etc. - If the user cares, they can explicitly request, e.g., an adjacency matrix. Maybe there will be a Graph._call() static method that returns a default implementation's object for those that don't care. - Method signatures will only need to refer to the Graph class so that a non-expert user (not familiar with that inheritance tree) doesn't need to be confused. But still the correct methods are applied to the objects as Gambas uses virtual dispatching. [ For a more intuitive feeling, I can also make Graph creatable and do the same in _new() that I planned to do in _call()... right? ] Does that sound reasonable? If you don't have strong objections, I would really like to do it that way. Maybe I can also introduce an abstract SearchTree class and have AvlTree (the only search tree at present) inherit from this class - because there it is the same principle but better developed as there are plenty of search tree implementations with a common set of operations. This way, there would be some analogon to the UserControl class of gb.qt4 for abstract datatypes, i.e. the user can also design Graph/SearchTree/... implementations in Gambas and pass them equally to all the methods that accept abstract Graph/SearchTree/... objects, i.e. methods that are agnostic about the implementation. Regards, Tobi -- "There's an old saying: Don't change anything... ever!" -- Mr. Monk From tobias at ...692... Thu Apr 24 13:50:35 2014 From: tobias at ...692... (Tobias Boege) Date: Thu, 24 Apr 2014 13:50:35 +0200 Subject: [Gambas-devel] gb.ncurses In-Reply-To: References: Message-ID: <20140424115035.GB512@...693...> On Thu, 24 Apr 2014, Nigel Gerrard wrote: > During my testing on cygwin-X of gambas, the gb.ncurses component was > crashing. Debugging gbx3 I found that the issue was related to c_input.c in > gb.ncurses\src: > > GB_DESC CInputDesc[] = { > GB_DECLARE("Input", 0), > GB_NOT_CREATABLE(), > > GB_CONSTANT("NoTimeout", "i", TIMEOUT_NOTIMEOUT), > > GB_CONSTANT("Cooked", "i", INPUT_COOKED), > GB_CONSTANT("CBreak", "i", INPUT_CBREAK), > GB_CONSTANT("Raw", "i", INPUT_RAW), > #if 0 > GB_CONSTANT("NoDelay", "i", INPUT_NODELAY), > > GB_STATIC_PROPERTY_READ("IsConsole", "b", Input_IsConsole), > GB_STATIC_PROPERTY("RepeatDelay", "i", Input_RepeatDelay), > #endif > GB_END_DECLARE /* Needs to be added */ > }; > > Which was missing the GB_END_DECLARE. > This seems to slip through ok on Linux builds but on the cygwin build > crashed. Could you apply the change to the repository. > Wow, strange that it never crashed over here... Thanks anyway. It is done in the latest revision. Regards, Tobi -- "There's an old saying: Don't change anything... ever!" -- Mr. Monk From gambas at ...1... Thu Apr 24 14:04:48 2014 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Thu, 24 Apr 2014 14:04:48 +0200 Subject: [Gambas-devel] Porting Gambas to cygwin In-Reply-To: References: Message-ID: <5358FDE0.4050109@...1...> Le 24/04/2014 13:46, Nigel Gerrard a ?crit : > Under cygwin and with cygwin-X I have been able to progress to a point > where I can actually get some of the examples running and the IDE up but > there are still a lot of things still to work on: > > One of the issues I have struggled to resolve is the following: > > $ make --trace > Makefile:397: update target 'config.h' due to: stamp-h1 > if test ! -f config.h; then rm -f stamp-h1; else :; fi > if test ! -f config.h; then make stamp-h1; else :; fi > Makefile:358: update target 'all' due to: config.h > make all-recursive > make[1]: Entering directory '/home/Administrator/gambas3-3.5.2/gb.sdl' > Makefile:427: target 'all-recursive' does not exist > fail=; \ > if (target_option=k; case ${target_option-} in ?) ;; *) echo > "am__make_running_with_option: internal error: invalid" "target option > '${target_option-}' specified" >&2; exit 1;; esac; has_opt=no; > sane_makeflags=$MAKEFLAGS; if test -n ' Makefile' && test -n '1'; then > sane_makeflags=$MFLAGS; else case $MAKEFLAGS in *\\[\ \ ]*) bs=\\; > sane_makeflags=`printf '%s\n' "$MAKEFLAGS" | sed "s/$bs$bs[$bs $bs > ]*//g"`;; esac; fi; skip_next=no; strip_trailopt () { flg=`printf '%s\n' > "$flg" | sed "s/$1.*$//"`; }; for flg in $sane_makeflags; do test > $skip_next = yes && { skip_next=no; continue; }; case $flg in *=*|--*) > continue;; -*I) strip_trailopt 'I'; skip_next=yes;; -*I?*) > strip_trailopt 'I';; -*O) strip_trailopt 'O'; skip_next=yes;; -*O?*) > strip_trailopt 'O';; -*l) strip_trailopt 'l'; skip_next=yes;; -*l?*) > strip_trailopt 'l';; -[dEDm]) skip_next=yes;; -[JT]) skip_next=yes;; > esac; case $flg in *$target_option*) has_opt=yes; break;; esac; done; > test $has_opt = yes); then \ > failcom='fail=yes'; \ > else \ > failcom='exit 1'; \ > fi; \ > dot_seen=no; \ > target=`echo all-recursive | sed s/-recursive//`; \ > case "all-recursive" in \ > distclean-* | maintainer-clean-*) list='src' ;; \ > *) list='src' ;; \ > esac; \ > for subdir in $list; do \ > echo "Making $target in $subdir"; \ > if test "$subdir" = "."; then \ > dot_seen=yes; \ > local_target="$target-am"; \ > else \ > local_target="$target"; \ > fi; \ > (CDPATH="${ZSH_VERSION+.}:" && cd $subdir && make $local_target) \ > || eval $failcom; \ > done; \ > if test "$dot_seen" = "no"; then \ > make "$target-am" || exit 1; \ > fi; test -z "$fail" > Making all in src > make[2]: Entering directory '/home/Administrator/gambas3-3.5.2/gb.sdl/src' > Makefile:614: update target 'gb_sdl_la-Cconst.lo' due to: Cconst.cpp > ../gambas.h ../config.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/stdint.h /usr/include/stdint.h > /usr/include/bits/wordsize.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/stddef.h > /usr/include/sys/types.h /usr/include/_ansi.h /usr/include/newlib.h > /usr/include/sys/config.h /usr/include/machine/ieeefp.h > /usr/include/sys/features.h /usr/include/cygwin/config.h > /usr/include/machine/_types.h /usr/include/machine/_default_types.h > /usr/include/sys/_types.h /usr/include/sys/lock.h > /usr/include/machine/types.h /usr/include/cygwin/types.h > /usr/include/endian.h /usr/include/bits/endian.h /usr/include/byteswap.h > /usr/include/sys/sysmacros.h Cconst.h main.h ../gb_common.h > /usr/include/math.h /usr/include/sys/reent.h /usr/include/unistd.h > /usr/include/sys/unistd.h /usr/include/sys/cdefs.h /usr/include/getopt.h > /usr/include/stdlib.h /usr/include/machine/stdlib.h > /usr/include/alloca.h /usr/include/cygwin/stdlib.h > /usr/include/cygwin/wait.h /usr/include/stdio.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/stdarg.h > /usr/include/sys/stdio.h /usr/include/string.h /usr/include/sys/string.h > /usr/include/inttypes.h /usr/include/fcntl.h /usr/include/sys/fcntl.h > /usr/include/sys/_default_fcntl.h /usr/include/sys/stat.h > /usr/include/time.h /usr/include/machine/time.h > /usr/include/cygwin/time.h /usr/include/signal.h > /usr/include/sys/signal.h /usr/include/cygwin/signal.h > /usr/include/cygwin/stat.h /usr/include/sys/time.h > /usr/include/cygwin/sys_time.h /usr/include/sys/select.h > /usr/include/sys/param.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include-fixed/limits.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include-fixed/syslimits.h > /usr/include/limits.h /usr/include/features.h ../gb.image.h SDL_h.h > /usr/include/GL/glew.h /usr/include/GL/glu.h /usr/include/GL/gl.h > /usr/include/SDL/SDL.h /usr/include/SDL/SDL_main.h > /usr/include/SDL/SDL_stdinc.h /usr/include/SDL/SDL_config.h > /usr/include/SDL/SDL_platform.h /usr/include/strings.h > /usr/include/ctype.h /usr/include/SDL/begin_code.h > /usr/include/SDL/close_code.h /usr/include/SDL/SDL_audio.h > /usr/include/SDL/SDL_error.h /usr/include/SDL/SDL_endian.h > /usr/include/SDL/SDL_mutex.h /usr/include/SDL/SDL_thread.h > /usr/include/SDL/SDL_rwops.h /usr/include/SDL/SDL_cdrom.h > /usr/include/SDL/SDL_cpuinfo.h /usr/include/SDL/SDL_events.h > /usr/include/SDL/SDL_active.h /usr/include/SDL/SDL_keyboard.h > /usr/include/SDL/SDL_keysym.h /usr/include/SDL/SDL_mouse.h > /usr/include/SDL/SDL_video.h /usr/include/SDL/SDL_joystick.h > /usr/include/SDL/SDL_quit.h /usr/include/SDL/SDL_loadso.h > /usr/include/SDL/SDL_timer.h /usr/include/SDL/SDL_version.h > /usr/include/SDL/SDL_syswm.h /usr/include/X11/Xlib.h > /usr/include/X11/X.h /usr/include/X11/Xfuncproto.h > /usr/include/X11/Xosdefs.h /usr/include/X11/Xatom.h > /usr/include/X11/cursorfont.h SDLapp.h SDLerror.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/string > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/i686-pc-cygwin/bits/c++config.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/i686-pc-cygwin/bits/os_defines.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/i686-pc-cygwin/bits/cpu_defines.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/stringfwd.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/memoryfwd.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/char_traits.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/stl_algobase.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/functexcept.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/exception_defines.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/cpp_type_traits.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/ext/type_traits.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/ext/numeric_traits.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/stl_pair.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/move.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/concept_check.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/stl_iterator_base_types.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/stl_iterator_base_funcs.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/debug/debug.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/stl_iterator.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/postypes.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/cwchar > /usr/include/wchar.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/allocator.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/i686-pc-cygwin/bits/c++allocator.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/ext/new_allocator.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/new > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/exception > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/atomic_lockfree_defines.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/localefwd.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/i686-pc-cygwin/bits/c++locale.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/clocale > /usr/include/locale.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/iosfwd > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/cctype > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/ostream_insert.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/cxxabi_forced.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/stl_function.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/backward/binders.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/range_access.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/basic_string.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/ext/atomicity.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/i686-pc-cygwin/bits/gthr.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/i686-pc-cygwin/bits/gthr-default.h > /usr/include/pthread.h /usr/include/sched.h /usr/include/sys/sched.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/i686-pc-cygwin/bits/atomic_word.h > /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits/basic_string.tcc > SDLdebug.h > echo " CXX " gb_sdl_la-Cconst.lo;/bin/sh ../libtool --silent > --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -D_GNU_SOURCE=1 > -D_REENTRANT -I/usr/include/SDL -I/usr/include/GL -pipe -Wall > -fno-exceptions -Wno-unused-value -fsigned-char -g -ggdb -Os > -fno-omit-frame-pointer -DDATA_DIR=\"/usr/share/gambas3/gb.sdl\" -MT > gb_sdl_la-Cconst.lo -MD -MP -MF .deps/gb_sdl_la-Cconst.Tpo -c -o > gb_sdl_la-Cconst.lo `test -f 'Cconst.cpp' || echo './'`Cconst.cpp > CXX gb_sdl_la-Cconst.lo > In file included from /usr/include/sys/types.h:20:0, > from ../gambas.h:30, > from Cconst.cpp:25: > ../gambas.h:1213:22: error: expected initializer before '.' token > #define strcasecmp GB.StrCaseCmp > ^ > ../gambas.h:1214:23: error: expected initializer before '.' token > #define strncasecmp GB.StrNCaseCmp > ^ > Makefile:614: recipe for target 'gb_sdl_la-Cconst.lo' failed > make[2]: *** [gb_sdl_la-Cconst.lo] Error 1 > make[2]: Leaving directory '/home/Administrator/gambas3-3.5.2/gb.sdl/src' > Makefile:427: recipe for target 'all-recursive' failed > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory '/home/Administrator/gambas3-3.5.2/gb.sdl' > Makefile:358: recipe for target 'all' failed > make: *** [all] Error 2 > > Any ideas as to what I am missing? > > Kind regards > > Nigel > No idea. Weird... You should run "gcc -E" manually on the offending source file to see what the C preprocessor does exactly. According to the error message, it seems there is something strange in '/usr/include/sys/types.h'. Regards, -- Beno?t Minisini From gambas at ...1... Thu Apr 24 14:13:10 2014 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Thu, 24 Apr 2014 14:13:10 +0200 Subject: [Gambas-devel] Should we provide different implementations to the same abstract datatype? In-Reply-To: <20140424114534.GA512@...693...> References: <20140424114534.GA512@...693...> Message-ID: <5358FFD6.3040002@...1...> Le 24/04/2014 13:45, Tobias Boege a ?crit : > Hi Benoit, > > I want to implement a Graph class for gb.data and I'm struggling with what > internal representation to use because depending on the application, one > data structure may perform badly and another one well. This may invert for > a different application. > > To have a well-performing Graph in their application, the programmer should > choose the internals themselves and I'm thinking that I can do the following > to support that: > > - Create a non-creatable class Graph that provides a common interface > - Create a GraphAdjMatrix class which Inherits Graph and overrides its > methods and properties to be an adjacency matrix based implementation > - Create a GraphAdjList class " to be an adjacency list based > implementation > - etc. > - If the user cares, they can explicitly request, e.g., an adjacency > matrix. Maybe there will be a Graph._call() static method that returns a > default implementation's object for those that don't care. > - Method signatures will only need to refer to the Graph class so that a > non-expert user (not familiar with that inheritance tree) doesn't need to > be confused. But still the correct methods are applied to the objects as > Gambas uses virtual dispatching. > > [ For a more intuitive feeling, I can also make Graph creatable and do the > same in _new() that I planned to do in _call()... right? ] > > Does that sound reasonable? If you don't have strong objections, I would > really like to do it that way. Maybe I can also introduce an abstract > SearchTree class and have AvlTree (the only search tree at present) inherit > from this class - because there it is the same principle but better > developed as there are plenty of search tree implementations with a common > set of operations. > > This way, there would be some analogon to the UserControl class of gb.qt4 > for abstract datatypes, i.e. the user can also design Graph/SearchTree/... > implementations in Gambas and pass them equally to all the methods that > accept abstract Graph/SearchTree/... objects, i.e. methods that are agnostic > about the implementation. > > Regards, > Tobi > AFAIK, there are a lot of different graph types. Maybe you cannot create a common parent class for all of them. But in all cases, you should provide the same interface to the user, at most as possible. In other words, the user does not care if there is a common parent class. But he will be not happy if he has to use a different interface for each different Graph class. As for using a common parent class, it's up to you. Of course it's better. Another possibility is having one Graph class, and using a property to define how to store the data. All the virtual dispatching is done inside the component. For me, it may be a better idea (less classes to write, document and learn, just one line of code to change if the user wants to change its algorithm...). Same remark for SearchTree. What do you think about that? -- Beno?t Minisini From tobias at ...692... Thu Apr 24 17:10:04 2014 From: tobias at ...692... (Tobias Boege) Date: Thu, 24 Apr 2014 17:10:04 +0200 Subject: [Gambas-devel] Should we provide different implementations to the same abstract datatype? In-Reply-To: <5358FFD6.3040002@...1...> References: <20140424114534.GA512@...693...> <5358FFD6.3040002@...1...> Message-ID: <20140424151004.GF512@...693...> On Thu, 24 Apr 2014, Beno?t Minisini wrote: > Le 24/04/2014 13:45, Tobias Boege a ?crit : > > Hi Benoit, > > > > I want to implement a Graph class for gb.data and I'm struggling with what > > internal representation to use because depending on the application, one > > data structure may perform badly and another one well. This may invert for > > a different application. > > > > To have a well-performing Graph in their application, the programmer should > > choose the internals themselves and I'm thinking that I can do the following > > to support that: > > > > - Create a non-creatable class Graph that provides a common interface > > - Create a GraphAdjMatrix class which Inherits Graph and overrides its > > methods and properties to be an adjacency matrix based implementation > > - Create a GraphAdjList class " to be an adjacency list based > > implementation > > - etc. > > - If the user cares, they can explicitly request, e.g., an adjacency > > matrix. Maybe there will be a Graph._call() static method that returns a > > default implementation's object for those that don't care. > > - Method signatures will only need to refer to the Graph class so that a > > non-expert user (not familiar with that inheritance tree) doesn't need to > > be confused. But still the correct methods are applied to the objects as > > Gambas uses virtual dispatching. > > > > [ For a more intuitive feeling, I can also make Graph creatable and do the > > same in _new() that I planned to do in _call()... right? ] > > > > Does that sound reasonable? If you don't have strong objections, I would > > really like to do it that way. Maybe I can also introduce an abstract > > SearchTree class and have AvlTree (the only search tree at present) inherit > > from this class - because there it is the same principle but better > > developed as there are plenty of search tree implementations with a common > > set of operations. > > > > This way, there would be some analogon to the UserControl class of gb.qt4 > > for abstract datatypes, i.e. the user can also design Graph/SearchTree/... > > implementations in Gambas and pass them equally to all the methods that > > accept abstract Graph/SearchTree/... objects, i.e. methods that are agnostic > > about the implementation. > > > > Regards, > > Tobi > > > > AFAIK, there are a lot of different graph types. Maybe you cannot create > a common parent class for all of them. But in all cases, you should > provide the same interface to the user, at most as possible. > Good point. I was only thinking about ordinary directed graphs in the Graph class, not about weights or undirected stuff... (That's what you were targetting, right?) I could solve that by having the most powerful Graph (weighted and directed) with a default weight and the option to have each inserted edge (directed) also automatically inserted in the reverse direction, which would make the Graph practically undirected... maybe. For the other Graph types that Wikipedia lists, e.g. Multigraph, Hypergraph, Quiver, distinct classes should be made (if anyone cares about them). But for directed vs. undirected and weighted vs. unweighted, distinct classes are painful. > In other words, the user does not care if there is a common parent > class. But he will be not happy if he has to use a different interface > for each different Graph class. > > As for using a common parent class, it's up to you. Of course it's better. > > Another possibility is having one Graph class, and using a property to > define how to store the data. All the virtual dispatching is done inside > the component. For me, it may be a better idea (less classes to write, > document and learn, just one line of code to change if the user wants to > change its algorithm...). Same remark for SearchTree. > > What do you think about that? > Also possible. But if I integrate the four "ordinary" Graph types into the Graph class AND add stuff to change the internal data layout, I fear that the class just becomes too bulky with a dozen possible configurations of its behaviour. I admit that I would find it a bit strange to say: Dim hTree As New SearchTree(SearchTree.AvlTree) ' get me an AvlTree or hTree.Type = SearchTree.RedBlackTree instead of having the classes ready: Dim hTree As New AvlTree ' Inherits SearchTree I'll start with the inheritance approach and see how far I get... Regards, Tobi -- "There's an old saying: Don't change anything... ever!" -- Mr. Monk From mckaygerhard at ...176... Mon Apr 28 15:16:20 2014 From: mckaygerhard at ...176... (PICCORO McKAY Lenz) Date: Mon, 28 Apr 2014 08:46:20 -0430 Subject: [Gambas-devel] Gambas 3.5.3 Message-ID: arrggggg @?~?@"#$%% ok so, the daily build of ppa contains all features always? From: Tobias Boege > On Mon, 21 Apr 2014, PICCORO McKAY Lenz wrote: > > DOES 3.5.3 release include the wiki example or web example complety? > > No. Gambas versions are structured as M.m.r. 3.5.3 is, as always when the r > increases, a bugfix release. New features always come when m increases. So > the Wiki example will be in 3.6. > > Regards, > Tobi > > -- > "There's an old saying: Don't change anything... ever!" -- Mr. Monk > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at ...692... Mon Apr 28 15:33:38 2014 From: tobias at ...692... (Tobias Boege) Date: Mon, 28 Apr 2014 15:33:38 +0200 Subject: [Gambas-devel] Gambas 3.5.3 In-Reply-To: References: Message-ID: <20140428133338.GA4463@...693...> On Mon, 28 Apr 2014, PICCORO McKAY Lenz wrote: > arrggggg @??~??@"#$%% ok so, the daily build of ppa contains all features > always? > Yes. -- "There's an old saying: Don't change anything... ever!" -- Mr. Monk From nigel.dh.gerrard at ...176... Tue Apr 29 17:12:03 2014 From: nigel.dh.gerrard at ...176... (Nigel Gerrard) Date: Tue, 29 Apr 2014 16:12:03 +0100 Subject: [Gambas-devel] Porting gambas to cygwin - what is the purpose of jit_gambas_pass_dummy.cpp Message-ID: When compiling under cygwin the gb.jit component, linking fails with the following: /bin/sh ../libtool --silent --tag=CXX --mode=link g++ -pipe -Wall -fno-exceptions -Wno-unused-value -fsigned-char -g -ggdb -Os -fno-omit-frame-pointer -std=gnu++0x -fno-exceptions -module -no-undefined -o gb.jit.la -rpath /usr/lib/gambas3 gb_jit_la-jit_api.lo gb_jit_la-jit_codegen.lo gb_jit_la-jit_compile.lo gb_jit_la-jit_conv.lo gb_jit_la-jit_expressions.lo gb_jit_la-jit_read.lo gb_jit_la-jit_runtime.lo gb_jit_la-jit_gambas_pass.lo gb_jit_la-jit_gambas_pass_dummy.lo gb_jit_la-main.lo -lc -L/usr/lib -lpthread -lffi -lm -lLLVM-3.1 -lgcc_s .libs/gb_jit_la-jit_gambas_pass_dummy.o:jit_gambas_pass_dummy.cpp:(.bss+0x0): multiple definition of `typeinfo for llvm::FunctionPass' .libs/gb_jit_la-jit_gambas_pass.o:jit_gambas_pass.cpp:(.rdata$_ZTIN4llvm12FunctionPassE[__ZTIN4llvm12FunctionPassE]+0x0): first defined here collect2: error: ld returned 1 exit status What is the purpose of jit_gambas_pass_dummy.cpp (complete code below): =================================================== // I found no easy way to compile jit_gambas_pass.cpp with -no-rtti as CXXFLAGS while still // have rtti enabled for jit_codegen.cpp ... extern "C" { void* _ZTIN4llvm12FunctionPassE; } ================================================== regards Nigel -------------- next part -------------- An HTML attachment was scrubbed... URL: From nigel.dh.gerrard at ...176... Wed Apr 30 14:35:33 2014 From: nigel.dh.gerrard at ...176... (Nigel Gerrard) Date: Wed, 30 Apr 2014 13:35:33 +0100 Subject: [Gambas-devel] Porting Gambas to cygwin Message-ID: I have now resolved the issue with the following when compiling gb.sdl in cygwin: > In file included from /usr/include/sys/types.h:20:0, > from ../gambas.h:30, > from Cconst.cpp:25: > ../gambas.h:1213:22: error: expected initializer before '.' token > #define strcasecmp GB.StrCaseCmp > ^ > ../gambas.h:1214:23: error: expected initializer before '.' token > #define strncasecmp GB.StrNCaseCmp > ^ It comes down to the order of the header definitions e.g. where gambas.h is declared before any of the SDL headers that contain STD_stdinc.h (and thus ). In this case my assumption is that the prepocessor incorporates all the includes and then redefines strcasecmp etc. including the definitions picked up from the standard header. The question then is why does this cause a problem under cygwin and not Linux. Regards Nigel -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at ...692... Wed Apr 30 14:44:44 2014 From: tobias at ...692... (Tobias Boege) Date: Wed, 30 Apr 2014 14:44:44 +0200 Subject: [Gambas-devel] Porting Gambas to cygwin In-Reply-To: References: Message-ID: <20140430124444.GA10729@...693...> On Wed, 30 Apr 2014, Nigel Gerrard wrote: > I have now resolved the issue with the following when compiling gb.sdl > in cygwin: > > > In file included from /usr/include/sys/types.h:20:0, > from > ../gambas.h:30, > from Cconst.cpp:25: > ../gambas.h:1213:22: error: > expected initializer before '.' token > #define strcasecmp GB.StrCaseCmp > > ^ > ../gambas.h:1214:23: error: expected initializer before '.' token > > #define strncasecmp GB.StrNCaseCmp > ^ It comes down to the order of the > header definitions e.g. where gambas.h is declared before any of the SDL > headers that contain STD_stdinc.h (and thus ). In this case my > assumption is that the prepocessor incorporates all the includes and then > redefines strcasecmp etc. including the definitions picked up from the > standard header. The question then is why does this cause a problem under > cygwin and not Linux. > I think what happens is the following: gambas.h #defines "strncasecmp" as something belonging to the GB structure (maybe to workaround a bug or something). As it ought to be, on Linux, the gambas.h header, being an "application" header, is included as late as possible during compilation so that precisely the uses of strncasecmp() in application code can be replaced with the wanted function in the GB structure. For some reason - I think -, the gambas.h header is read on cygwin _before_ where strncasecmp is declared. Obviously, if the macro (because since the point gambas.h is read, it is a macro) strncasecmp is expanded to GB.StrNCaseCmp in the place where normally a function is declared, that will make the compiler complain. If that's the case, you have to either figure out why the inclusion order is this way and correct it (if possible) or simply remove the #define from gambas.h since, hey, the C library's strncasecmp() can't be _that_ bad :-) Regards, Tobi -- "There's an old saying: Don't change anything... ever!" -- Mr. Monk