NAVIGATION
CATEGORIES
REFERRENCE
LINKS
about types
10 answers - 767 bytes -
While wrapping symbols for gtk+-2.8, I have noticed:
- on the following example type error, the error message is misleading:
irb(main):002:0Gtk::VBox.new.add(1)
TypeError: fundamental type glong isn't supported
- there seems to be missing type checks for example the following
should be possible only with a Gtk::Widget, which is not the case of a
Gdk::DragContext:
irb(main):003:0Gtk::VBox.new.add(Gdk::DragContext. new)
=#<Gtk::VBox:0xb7a29e54 ptr=0x8268d00>
and I also don't understand why we don't see the assertion failure message:
(a.out:7981): Gtk-CRITICAL **: gtk_container_add: assertion
`GTK_IS_WIDGET (widget)' failed
Were these problems left out on purpose for any reason?No.1 | | 1326 bytes |
| 
So, 2005-09-11 at 17:05 +0200, Guillaume Cottenceau wrote:
While wrapping symbols for gtk+-2.8, I have noticed:
- on the following example type error, the error message is misleading:
irb(main):002:0Gtk::VBox.new.add(1)
TypeError: fundamental type glong isn't supported
- there seems to be missing type checks for example the following
should be possible only with a Gtk::Widget, which is not the case of a
Gdk::DragContext:
irb(main):003:0Gtk::VBox.new.add(Gdk::DragContext. new)
=#<Gtk::VBox:0xb7a29e54 ptr=0x8268d00>
and I also don't understand why we don't see the assertion failure message:
(a.out:7981): Gtk-CRITICAL **: gtk_container_add: assertion
`GTK_IS_WIDGET (widget)' failed
ruby-gnome2 blocks these. hour before your email I reported this
behaviour as a bug. I don't think that this behaviour is good for
developers, let's see what the other devs thinks about it.
Were these problems left out on purpose for any reason?
The Changelogs advertized this as "support GLib::Log.set_log_handler"
though I still cannot see the advantage of these.
Regards,
Sven
PGP SIGNATURE
Version: GnuPG v1.4.1 (GNU/Linux)
6+l170mYawCdWjEq7jKWjUM=
=Sclb
PGP SIGNATURENo.2 | | 1326 bytes |
| So, 2005-09-11 at 17:05 +0200, Guillaume Cottenceau wrote:
While wrapping symbols for gtk+-2.8, I have noticed:
- on the following example type error, the error message is misleading:
irb(main):002:0Gtk::VBox.new.add(1)
TypeError: fundamental type glong isn't supported
- there seems to be missing type checks for example the following
should be possible only with a Gtk::Widget, which is not the case of a
Gdk::DragContext:
irb(main):003:0Gtk::VBox.new.add(Gdk::DragContext. new)
=#<Gtk::VBox:0xb7a29e54 ptr=0x8268d00>
and I also don't understand why we don't see the assertion failure message:
(a.out:7981): Gtk-CRITICAL **: gtk_container_add: assertion
`GTK_IS_WIDGET (widget)' failed
ruby-gnome2 blocks these. hour before your email I reported this
behaviour as a bug. I don't think that this behaviour is good for
developers, let's see what the other devs thinks about it.
Were these problems left out on purpose for any reason?
The Changelogs advertized this as "support GLib::Log.set_log_handler"
though I still cannot see the advantage of these.
Regards,
Sven
PGP SIGNATURE
Version: GnuPG v1.4.1 (GNU/Linux)
6+l170mYawCdWjEq7jKWjUM=
=Sclb
PGP SIGNATURENo.3 | | 1428 bytes |
| and I also don't understand why we don't see the assertion failure message:
(a.out:7981): Gtk-CRITICAL **: gtk_container_add: assertion
`GTK_IS_WIDGET (widget)' failed
ruby-gnome2 blocks these. hour before your email I reported this
behaviour as a bug. I don't think that this behaviour is good for
developers, let's see what the other devs thinks about it.
Thanks, I didn't know that.
For the record: I really strongly think that a default behaviour of
glib/gtk should not be changed in ruby-gnome2. A binding should be as
close as the library binded as possible. This is simply to ease the
life of gtk-aware developers using ruby-gnome2. If we are unhappy with
a default behaviour of glib/gtk, we have to try to fix it in glib/gtk.
If glib/gtk developers don't want and we still are unhappy, we should
still stick to the default behaviour but add an additional way in
ruby-gnome2 to change the behaviour if needed.
In short: glib by default prints all sorts of warnings/errors to
stdout, we should do the same. And as Sven pointed out, it would have
eased tracking previous bugs. These warnings and errors are simply
Good(tm) to develop good gtk software, everyone using ruby-gnome2
should see them - except if really strongly against (hence the
additional method, if needed - personally, I don't think we do).No.4 | | 1763 bytes |
| Hi,
Sun, 11 Sep 2005 17:05:32 +0200
Guillaume Cottenceau <gcottenc (AT) gmail (DOT) comwrote:
While wrapping symbols for gtk+-2.8, I have noticed:
- on the following example type error, the error message is misleading:
irb(main):002:0Gtk::VBox.new.add(1)
TypeError: fundamental type glong isn't supported
Fixed. Now it shows:
irb(main):003:0Gtk::VBox.new.add(1)
TypeError: Fixnum isn't supported
from (irb):3:in `add'
from (irb):3
- there seems to be missing type checks for example the following
should be possible only with a Gtk::Widget, which is not the case of a
Gdk::DragContext:
irb(main):003:0Gtk::VBox.new.add(Gdk::DragContext. new)
=#<Gtk::VBox:0xb7a29e54 ptr=0x8268d00>
and I also don't understand why we don't see the assertion failure message:
(a.out:7981): Gtk-CRITICAL **: gtk_container_add: assertion
`GTK_IS_WIDGET (widget)' failed
Were these problems left out on purpose for any reason?
We need to check what object should be accepted by hand.
For example, in this case, you need to check the argument like as:
(rbgtkcontainer.c)
static VALUE
cont_add(argc, argv, self)
int argc;
VALUE *argv;
VALUE self;
{
VALUE other, properties;
GtkWidget *child;
rb_scan_args(argc, argv, "11", &other, &properties);
if (! rb_obj_is_kind_of(tag, GTYPE2CLASS(GTK_TYPE_WIDGET))) #HERE
rb_raise(); #HERE
child = GTK_WIDGET(RVAL2GBJ(other));
:
:
return self;
}
We don't implement them first, because it's very hard to implement all of
them by hand. course, we know it's better to check them first.
Good idea?No.5 | | 1657 bytes |
| Hi,
Sun, 11 Sep 2005 18:55:08 +0200
Sven Herzberg <herzi (AT) gnome-de (DOT) orgwrote:
So, 2005-09-11 at 17:05 +0200, Guillaume Cottenceau wrote:
While wrapping symbols for gtk+-2.8, I have noticed:
- on the following example type error, the error message is misleading:
irb(main):002:0Gtk::VBox.new.add(1)
TypeError: fundamental type glong isn't supported
- there seems to be missing type checks for example the following
should be possible only with a Gtk::Widget, which is not the case of a
Gdk::DragContext:
irb(main):003:0Gtk::VBox.new.add(Gdk::DragContext. new)
=#<Gtk::VBox:0xb7a29e54 ptr=0x8268d00>
and I also don't understand why we don't see the assertion failure message:
(a.out:7981): Gtk-CRITICAL **: gtk_container_add: assertion
`GTK_IS_WIDGET (widget)' failed
ruby-gnome2 blocks these. hour before your email I reported this
behaviour as a bug. I don't think that this behaviour is good for
developers, let's see what the other devs thinks about it.
Hmm. Actually, it's a limitation of Ruby-GNME2, but won't fix.
I changed your ticket:1287808 from bugs to "Featuer Requests", status as Pending,
Resolution as "Wont Fix".
course, you have good solution, I'll accept it.
Were these problems left out on purpose for any reason?
The Changelogs advertized this as "support GLib::Log.set_log_handler"
though I still cannot see the advantage of these.
It works to show the line of ruby-script correctly.
If you are instersted in it, see glib/src/rbglib_messages.c.No.6 | | 948 bytes |
| Hi Masao,
Thanks for all your replies.
irb(main):003:0Gtk::VBox.new.add(Gdk::DragContext. new)
=#<Gtk::VBox:0xb7a29e54 ptr=0x8268d00>
and I also don't understand why we don't see the assertion failure message:
(a.out:7981): Gtk-CRITICAL **: gtk_container_add: assertion
`GTK_IS_WIDGET (widget)' failed
ruby-gnome2 blocks these. hour before your email I reported this
behaviour as a bug. I don't think that this behaviour is good for
developers, let's see what the other devs thinks about it.
Hmm. Actually, it's a limitation of Ruby-GNME2, but won't fix.
I changed your ticket:1287808 from bugs to "Featuer Requests", status as Pending,
Resolution as "Wont Fix".
Can you explain why it is considered a limitation, and why it is a
wontfix? Is it not possible to output the warnings/errors/criticals by
default on stdout as in default glib?No.7 | | 1961 bytes |
| Hi,
Mon, 12 Sep 2005 08:58:23 +0200
Guillaume Cottenceau <gcottenc (AT) gmail (DOT) comwrote:
Hi Masao,
Thanks for all your replies.
irb(main):003:0Gtk::VBox.new.add(Gdk::DragContext. new)
=#<Gtk::VBox:0xb7a29e54 ptr=0x8268d00>
and I also don't understand why we don't see the assertion failure message:
(a.out:7981): Gtk-CRITICAL **: gtk_container_add: assertion
`GTK_IS_WIDGET (widget)' failed
ruby-gnome2 blocks these. hour before your email I reported this
behaviour as a bug. I don't think that this behaviour is good for
developers, let's see what the other devs thinks about it.
Hmm. Actually, it's a limitation of Ruby-GNME2, but won't fix.
I changed your ticket:1287808 from bugs to "Featuer Requests", status as Pending,
Resolution as "Wont Fix".
Can you explain why it is considered a limitation, and why it is a
wontfix? Is it not possible to output the warnings/errors/criticals by
default on stdout as in default glib?
At first, I'm sorry I misunderstood what you said.
I thought you suggested me to show them with "rubyish" messages.
Anyway, WARNING messages are't shown defaultly.
Some environment like MS Windows, too many warning messages are shown.
So I filtered them.
You can get the error with -d option.
(test.rb)
require 'gtk2'
Gtk.init
Gtk::VBox.new.add(Gdk::DragContext.new)
$ ruby -d test.rb
test.rb: line 1
GLib-GWARNING **:invalid cast from `GdkDragContext' to `GtkWidget'
test.rb: line 1
Gtk-CRITICAL ** assertion `GTK_IS_WIDGET (widget)' failed
test.rb: line 1
Gtk-CRITICAL **:gtk_container_add: assertion `GTK_IS_WIDGET (widget)' failed
test.rb: line 1
Gtk-CRITICAL **:gtk_widget_thaw_child_notify: assertion `GTK_IS_WIDGET (widget)' failed
Hmm. "line 1" seems wrongNo.8 | | 2393 bytes |
| Mo, 2005-09-12 at 16:42 +0900, Masao Mutoh wrote:
Mon, 12 Sep 2005 08:58:23 +0200
Guillaume Cottenceau <gcottenc (AT) gmail (DOT) comwrote:
irb(main):003:0Gtk::VBox.new.add(Gdk::DragContext. new)
=#<Gtk::VBox:0xb7a29e54 ptr=0x8268d00>
and I also don't understand why we don't see the assertion failure message:
(a.out:7981): Gtk-CRITICAL **: gtk_container_add: assertion
`GTK_IS_WIDGET (widget)' failed
ruby-gnome2 blocks these. hour before your email I reported this
behaviour as a bug. I don't think that this behaviour is good for
developers, let's see what the other devs thinks about it.
Hmm. Actually, it's a limitation of Ruby-GNME2, but won't fix.
I changed your ticket:1287808 from bugs to "Featuer Requests", status as Pending,
Resolution as "Wont Fix".
Can you explain why it is considered a limitation, and why it is a
wontfix? Is it not possible to output the warnings/errors/criticals by
default on stdout as in default glib?
At first, I'm sorry I misunderstood what you said.
I thought you suggested me to show them with "rubyish" messages.
Anyway, WARNING messages are't shown defaultly.
Some environment like MS Windows, too many warning messages are shown.
So I filtered them.
You can get the error with -d option.
(test.rb)
require 'gtk2'
Gtk.init
Gtk::VBox.new.add(Gdk::DragContext.new)
$ ruby -d test.rb
test.rb: line 1
GLib-GWARNING **:invalid cast from `GdkDragContext' to `GtkWidget'
test.rb: line 1
Gtk-CRITICAL ** assertion `GTK_IS_WIDGET (widget)' failed
test.rb: line 1
Gtk-CRITICAL **:gtk_container_add: assertion `GTK_IS_WIDGET (widget)' failed
test.rb: line 1
Gtk-CRITICAL **:gtk_widget_thaw_child_notify: assertion `GTK_IS_WIDGET (widget)' failed
Hmm. "line 1" seems wrong
I think your snippet is broken: gtk_container_add() expects a GtkWidget
as the second parameter and GdkDragContext is not a widget. So these
errors are printed for a good reason.
I have (except for the GTK+ 2.8.0 release) never seen g_log()-warnings
that one should ignore.
Regards,
Sven
PGP SIGNATURE
Version: GnuPG v1.4.1 (GNU/Linux)
jcRfuVPSKUL8UdDCv6NR2TQ=
=BSfa
PGP SIGNATURENo.9 | | 927 bytes |
| Hi,
Can you explain why it is considered a limitation, and why it is a
wontfix? Is it not possible to output the warnings/errors/criticals by
default on stdout as in default glib?
At first, I'm sorry I misunderstood what you said.
I thought you suggested me to show them with "rubyish" messages.
Anyway, WARNING messages are't shown defaultly.
Some environment like MS Windows, too many warning messages are shown.
So I filtered them.
You can get the error with -d option.
But my point is: these messages are shown by default in glib/gtk.
They should be shown by default on ruby-gnome2, without the need for
the -d (or -v) option. What is the reason to hide them by default?
I don't know Windows because I never use it, but if the warnings are
pointless, the warnings should be "fixed", we should not hide useful
warnings for other platforms.No.10 | | 1238 bytes |
| Hi,
Mon, 12 Sep 2005 10:31:01 +0200
Guillaume Cottenceau <gcottenc (AT) gmail (DOT) comwrote:
Hi,
Can you explain why it is considered a limitation, and why it is a
wontfix? Is it not possible to output the warnings/errors/criticals by
default on stdout as in default glib?
At first, I'm sorry I misunderstood what you said.
I thought you suggested me to show them with "rubyish" messages.
Anyway, WARNING messages are't shown defaultly.
Some environment like MS Windows, too many warning messages are shown.
So I filtered them.
You can get the error with -d option.
But my point is: these messages are shown by default in glib/gtk.
They should be shown by default on ruby-gnome2, without the need for
the -d (or -v) option. What is the reason to hide them by default?
I followed ruby rule. In ruby, warning messages should be shown with -d
or -v option.
I don't know Windows because I never use it, but if the warnings are
pointless, the warnings should be "fixed", we should not hide useful
warnings for other platforms.
K. I changed my mind. Actually it's useful to find problem for developers
even users.
QUESTION ON "Development"
- New - ENOENT, connect and beagle.
- invalid code generated (x86, "int $5") with __builtin_va_arg(va, char);
- r49906 - trunk/mcs/class/System.Web/System.Web.Util
- Remote access to an SVN Repository
- New - mcs fails to install after acomplete build
- r49908 - trunk/monologue/worker
- r49907 - trunk/mcs/class/System.Web
- ANNOUNCE: twill 0.7.2
- Compiling problem
- r49905 -trunk/mcs/class/System.Web/Test/System.Web.Util
- What is exactly definition of Architecture
- When will I know all of the user stories?
- New: Is this right?
- fix PR libfortran/20179
- Future of ruby-gnome
- Mono port to ARM
- Feature request: svn ignore
- New: ICE in dominated_by_p, at dominance.c:827
- New: ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:398
- New: ICE in extract_insn, at recog.c:2084