Re: g_remove
>> Glib just cannot require 64bit integer type and be C89 standard compliant > Right. And as far as I know, nobody has claimed it is. Actually, thinking a bit more, isn't it perfectly OK for a fully C89 compliant compiler to provide whatever non-standard stuff it likes as long as the identifiers for that start with two underscores? Like MSVC and its __int64 type. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_remove
> Glib just cannot require 64bit integer > type and be C89 standard compliant Right. And as far as I know, nobody has claimed it is. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_remove
Glib itself wouldn't even compile if I removed that before compilation as it wouldn't find 64bit integer type. Glib just cannot require 64bit integer type and be C89 standard compliant at the same time when C89 doesn't require existence of 64bit integer type. Ok, I won't troll anymore. On 02/19/2011 03:20 PM, Tor Lillqvist wrote: - doesn't compile on x86-32 linux with glibc when I remove all typedefes and occurences of long long in header files Equally interesting, it doesn't compile if you replace all instances of the letter 'a' in your header files with the letter 'b'. Or, if you feel really adventurous, with the letter 'x'. Each GLib build is configured to work with a specific compiler, C library, and associated header files. If you break the header files on purpose, you can't expect the same GLib developer package to work with it any more. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_remove
> - doesn't compile on x86-32 linux with glibc when I remove all typedefes and > occurences of long long in header files Equally interesting, it doesn't compile if you replace all instances of the letter 'a' in your header files with the letter 'b'. Or, if you feel really adventurous, with the letter 'x'. Each GLib build is configured to work with a specific compiler, C library, and associated header files. If you break the header files on purpose, you can't expect the same GLib developer package to work with it any more. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_remove
Le 19/02/2011 15:06, Jaroslav Šmíd a écrit :
> #include
>
> int main(int argc, char **argv)
> {
> gint64 a;
> return 0;
> }
>
> - doesn't compile on x86-32 linux with glibc when I remove all typedefes
> and occurences of long long in header files (long long is not part of
> C89 standard and it would be unfair to leave it there even if it is some
> compiler extension of the C89 standard). Because there is no other 64bit
> integer type on such system, I cannot typedef gint64 to something else.
> I doubt this will get fixed, glib requires 64bit integer type (as stated
> in docs), C89 doesn't guarantee its existence and no C89 type is 64bit
> on x86-32 linux.
It's not that simple. GLib's configuration scripts searches for the
appropriate type, not necessarily for long long [1]. So GLib needs the
system to provide a 64bits type, not necessarily to support C99.
Regards,
Colomban
[1] actually, it seems to check for long, long long or __int64 being a
64bits integer
> On 02/19/2011 02:50 PM, David Nečas wrote:
>> On Sat, Feb 19, 2011 at 02:37:51PM +0100, Jaroslav Šmíd wrote:
>>>
>>> Maybe. Doesn't meen you didn't tell which one.
>>
>> I did not have to because everyone except you understood the context.
>> Since you did not ask the question and evidently know better your
>> failure to understand is of little concern.
>>
>>> * direct, indirect, build time or runtime ... it is depency. Don't know
>>> names, but if you want, you can find out by yourself.
>>
>> It also has dependences that require C++, GMP and Perl – and they are
>> equally irrelvant.
>>
>> Demonstrate that a C99 compiler is required to compile GLib-using
>> programs. And I will go and fill this as a bug in Gnome bugzilla and it
>> will be fixed because the developers have repeatedly declared GLib is
>> C89-compatible.
>>
>> Yeti
>>
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_remove
#include
int main(int argc, char **argv)
{
gint64 a;
return 0;
}
- doesn't compile on x86-32 linux with glibc when I remove all typedefes
and occurences of long long in header files (long long is not part of
C89 standard and it would be unfair to leave it there even if it is some
compiler extension of the C89 standard). Because there is no other 64bit
integer type on such system, I cannot typedef gint64 to something else.
I doubt this will get fixed, glib requires 64bit integer type (as stated
in docs), C89 doesn't guarantee its existence and no C89 type is 64bit
on x86-32 linux.
On 02/19/2011 02:50 PM, David Nečas wrote:
On Sat, Feb 19, 2011 at 02:37:51PM +0100, Jaroslav Šmíd wrote:
Maybe. Doesn't meen you didn't tell which one.
I did not have to because everyone except you understood the context.
Since you did not ask the question and evidently know better your
failure to understand is of little concern.
* direct, indirect, build time or runtime ... it is depency. Don't know
names, but if you want, you can find out by yourself.
It also has dependences that require C++, GMP and Perl – and they are
equally irrelvant.
Demonstrate that a C99 compiler is required to compile GLib-using
programs. And I will go and fill this as a bug in Gnome bugzilla and it
will be fixed because the developers have repeatedly declared GLib is
C89-compatible.
Yeti
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_remove
> that means glib and any app > using glib is indirectly dependent on compiler with C99 support. Interesting. I guess nobody told those who continue to manage to build GLib and the GTK+ stack in general with Microsoft's compiler, which does not claim C99 compliance. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_remove
On Sat, Feb 19, 2011 at 02:42:14PM +0100, Jaroslav Šmíd wrote: > Hmm, resending, got identified as spam ... I would not expect such intelligence from the spam filter but there you have it... Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_remove
On Sat, Feb 19, 2011 at 02:37:51PM +0100, Jaroslav Šmíd wrote: > > Maybe. Doesn't meen you didn't tell which one. I did not have to because everyone except you understood the context. Since you did not ask the question and evidently know better your failure to understand is of little concern. > * direct, indirect, build time or runtime ... it is depency. Don't know > names, but if you want, you can find out by yourself. It also has dependences that require C++, GMP and Perl – and they are equally irrelvant. Demonstrate that a C99 compiler is required to compile GLib-using programs. And I will go and fill this as a bug in Gnome bugzilla and it will be fixed because the developers have repeatedly declared GLib is C89-compatible. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_remove
Hmm, resending, got identified as spam ... On 02/19/2011 02:37 PM, Jaroslav Šmíd wrote: On 02/19/2011 10:19 AM, David Nečas wrote: On Sat, Feb 19, 2011 at 01:21:37AM +0100, Jaroslav Šmíd wrote: C99 has no implicit int ., so don't ignore compiler's warning and fix it. David Nečas: "All according to the C standard". Right, you didn't tell us which one, one could think you mean "every C standard out there". My English is not perfect but I think can distinguish between "a standard", "the standard" and "all standards", thank you very much. Maybe. Doesn't meen you didn't tell which one. So, no "the standard" means a single C standard. The only C standard relevant to the problem. The standard the Criag's C compiler adheres to (or at least tries) while compiling the program. Yes, C99 is the only relevant. I was compiling glib on FreeBSD recently and I noticed that at least 1 depency* of glib required -std=c99 and at least one required -std=gnu99 argument for compiling, that means glib and any app using glib is indirectly dependent on compiler with C99 support. And without C99, glib's condition of "requiring 64bit integer type" could be hardly met e.g. on x86-32 linux with glibc without C99 support - glibc has typedef "long long" to int64_t on such system and long long is only available in C99. So glib depends on C99 compiler, at least on x86-32 linux with glibc and on FreeBSD@amd64. Because of that, "the standard" substitutes to C99 standard in my head. * direct, indirect, build time or runtime ... it is depency. Don't know names, but if you want, you can find out by yourself. Yeti Jardík ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_remove
On 02/19/2011 10:19 AM, David Nečas wrote: On Sat, Feb 19, 2011 at 01:21:37AM +0100, Jaroslav Šmíd wrote: C99 has no implicit int shits, so don't ignore compiler's warning and fix it. David Nečas: "All according to the C standard". Right, you didn't tell us which one, one could think you mean "every C standard out there". My English is not perfect but I think can distinguish between "a standard", "the standard" and "all standards", thank you very much. Maybe. Doesn't meen you didn't tell which one. So, no "the standard" means a single C standard. The only C standard relevant to the problem. The standard the Criag's C compiler adheres to (or at least tries) while compiling the program. Yes, C99 is the only relevant. I was compiling glib on FreeBSD recently and I noticed that at least 1 depency* of glib required -std=c99 and at least one required -std=gnu99 argument for compiling, that means glib and any app using glib is indirectly dependent on compiler with C99 support. And without C99, glib's condition of "requiring 64bit integer type" could be hardly met e.g. on x86-32 linux with glibc without C99 support - glibc has typedef "long long" to int64_t on such system and long long is only available in C99. So glib depends on C99 compiler, at least on x86-32 linux with glibc and on FreeBSD@amd64. Because of that, "the standard" substitutes to C99 standard in my head. * direct, indirect, build time or runtime ... it is depency. Don't know names, but if you want, you can find out by yourself. Yeti Jardík ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: how to connect the gnome aplication(gtk+) to database
On 19 February 2011 09:22, angel kingdom wrote: > HI, > i am working on a application(project Gutenberg ) which is written in gtk+ > and i want to connect this application with database server to store > dictionary.i am having the Dictionary in xml format. > So,please guide me or give me a link of how to do this work. > I am using ubuntu 9.04 > And for database i am using the postgresql.. > > Depending on your needs, you can use the Libgda library ( http://www.gnome-db.org) which integrates well with Gtk+. Regards, Vivien ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_remove
On Sat, Feb 19, 2011 at 01:21:37AM +0100, Jaroslav Šmíd wrote: > C99 has no implicit int shits, so don't ignore compiler's warning and > fix it. > > David Nečas: "All according to the C standard". Right, you didn't tell > us which one, one could think you mean "every C standard out there". My English is not perfect but I think can distinguish between "a standard", "the standard" and "all standards", thank you very much. So, no "the standard" means a single C standard. The only C standard relevant to the problem. The standard the Criag's C compiler adheres to (or at least tries) while compiling the program. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: how to connect the gnome aplication(gtk+) to database
Am Sat, 19 Feb 2011 03:22:52 -0500 schrieb angel kingdom : > HI, > i am working on a application(project Gutenberg ) which is written in > gtk+ and i want to connect this application with database server to > store dictionary.i am having the Dictionary in xml format. > So,please guide me or give me a link of how to do this work. > I am using ubuntu 9.04 > And for database i am using the postgresql.. Hi, install the libpq-dev package. (At least it's called in Debian Squeeze libpq-dev, I guess it is same in Ubuntu) In this package you find a program called pg_config which prints out the compile options you need to compile against it. You have to add this infos in your configure /makefile scripts (or whatever you use) hth Alex > > thank you > Deepa A > ___ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- Alexander Nagel E-mail: alexan...@acwn.de Homepage: http://www.acwn.de/ http://www.standspur-kadaver.de/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
how to connect the gnome aplication(gtk+) to database
HI, i am working on a application(project Gutenberg ) which is written in gtk+ and i want to connect this application with database server to store dictionary.i am having the Dictionary in xml format. So,please guide me or give me a link of how to do this work. I am using ubuntu 9.04 And for database i am using the postgresql.. thank you Deepa A ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: interested in gtk+ project development
On Sat, 2011-02-19 at 00:56 +0100, Jaroslav Šmíd wrote: > If you are currently learning C, please, learn the difference between > size_t, int and long - some of glib/GTK devs didn't and because of that > they use int in places where size_t is more appropriate. where size_t is appropriate, glib developers use gsize. > For example > g_application_open() - quite new API and they had to mess it up by using > (g)int instead of size_t. Or they can do magic and even on system with > sizeof(size_t) < sizeof(int) they actually can manipulate with objects > impossible to allocate (although I don't know of such system, but C > standard doesn't forbid it). so it should have been written for platforms that not only don't have a port of GLib, but are also non-existing? > On the other hand, on systems with > sizeof(size_t) > sizeof(int), they limit you. or we should have written g_application_open() for platforms in which you can open more than 2+ *billion* files at the same time? just one question: are you for real? ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
