[Vala] How to check if current thread is main thread?
Hi I need to check (for debugging purposes) if current thread is main thread. How can I do that in Vala? I know that in GLib exists g_thread_self() and I can use result of that function for that purpose but in Vala's vapi it has strange syntax that I cannot truly understand. Thank you in advance, m. ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
[Vala] interfaces
following compiles without warning/error but at runtime it tells me
(process:6285): GLib-GObject-WARNING **: cannot add interface type
`JJJ' to type `BBB' which does not conform to prerequisite `III'
/* [public|private] interface name {
** constant/method/delegate/signal
** }
*/
interface III {
public const int i = 2 ;
public abstract void m ();
}
interface JJJ : III {
// public void m () { stdout.printf(J.m() ueberdeckt I.m(). 'new'
ist nicht erforderlich\n); }
public void n () { stdout.printf(J.n()\n); }
}
abstract class AAA {
}
class BBB : AAA,JJJ,III {
int _j ;
public double d ;
public int j { get{return _j;} set{_j=value;} }
public BBB(){ j=i+12; d=1.23; }
public void m() { stdout.printf(I.m() in class B implementiert\n); }
}
int main ( string[] args ) {
var b = new BBB();
stdout.printf(%d %d %f\n,((III)b).i,b.j,b.d);
b.m();
b.n();
return 0 ;
}
when 'class A : J/*,I*/ {}' a similiar error at compile time.
is there actually need to declare all interfaces in class-declaration, i.e.
interface i1 {} ; interface i2:i1 {} ... interface i99:i98 {}
class C : i99,...,i1 {}
???
thanks in advance
andreas
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
[Vala] gee version
i.e. when i try to install valadoc it requires gee-1.0 but top is 0.7.2 what installs a gee-0.8.pc and gee-documentation tells about gee-1.0, too ?! regards andreas ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Get file name of function
On Fri, Jul 6, 2012 at 1:20 AM, Rodrigo Cares rca...@gmail.com wrote: Hi to all, howto can get the actual file name and line in a file, just like the info presented by GLib.warning function (main.vala:14). Hi, http://valadoc.org/#!api=glib-2.0/GLib.Log.FILE http://valadoc.org/#!api=glib-2.0/GLib.Log.LINE -- www.debian.org - The Universal Operating System ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Get file name of function
Thanks El vie, 06-07-2012 a las 12:23 +0200, Luca Bruno escribió: On Fri, Jul 6, 2012 at 1:20 AM, Rodrigo Cares rca...@gmail.com wrote: Hi to all, howto can get the actual file name and line in a file, just like the info presented by GLib.warning function (main.vala:14). Hi, http://valadoc.org/#!api=glib-2.0/GLib.Log.FILE http://valadoc.org/#!api=glib-2.0/GLib.Log.LINE -- www.debian.org - The Universal Operating System ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] gee version
On 07/06/2012 09:18 AM, andreas graeper wrote: i.e. when i try to install valadoc it requires gee-1.0 but top is 0.7.2 what installs a gee-0.8.pc and gee-documentation tells about gee-1.0, too ?! There are two branches of Libgee, with two slightly different APIs. libgee-0.7.2 is the current version of gee-0.8 libgee-0.6.4 is the current version of gee-1.0 ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] interfaces
On 07/06/2012 08:56 AM, andreas graeper wrote:
following compiles without warning/error but at runtime it tells me
(process:6285): GLib-GObject-WARNING **: cannot add interface type
`JJJ' to type `BBB' which does not conform to prerequisite `III'
[snip]
is there actually need to declare all interfaces in class-declaration, i.e.
interface i1 {} ; interface i2:i1 {} ... interface i99:i98 {}
class C : i99,...,i1 {}
???
Yes, you need to declare all interfaces. This is the way Vala and
GObject were designed.
The order in which you list interfaces in the class declaration matters:
class BBB : AAA,III,JJJ {
will work.
This is arguably a (minor) bug. It was reported last year:
https://bugzilla.gnome.org/show_bug.cgi?id=656204
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Help with Memory Leak
Hello all,
I am encountering a memory leak in an appindicator menu. The menu is made
up of several RadioMenuItems that have their labels updated once per
second. I have tracked the memory leak down to the following code, but
cannot seem to be able to make any additional headway. The method update
is called from several sources, and specifies the radio item and the values
to update via a const array of FORMAT statements. If I comment out the
code that sets the radio menu item label and un-comment the printf
statement, the leak disappears. The leak is minor -- on the order of about
20 to 30 bytes per invocation -- but over time it adds up.
I'm not sure if this is the correct forum for asking for help, or whether
this is a problem with the gtk+-3.0 or appindicator3-0.1 packages, but I
thought I'd see if anyone has any ideas in the Vala community first.
Thanks,
Bruce
//
-
// Make results more readable by appending the appropriate metric unit to
the data
//
-
private const string suffix [] = { bytes, KiB, MiB, GiB, TiB,
PiB, EiB, ZiB };
private string readable (float bytes) {
foreach (string s in suffix) {
if (bytes 1024.0) {
var format = (s == bytes) ? %.0f %s : %.1f %s;
return format.printf (bytes, s);
}
bytes = bytes / 1024.0f;
}
return %.1f YiB.printf (bytes);
}
//
-
// Menu update
//
-
public void update (int item, float pct, float val1, float? val2 = 0.0f) {
var text = (item == 0) ? FORMAT [item].printf (val1)
: FORMAT [item].printf (readable (val1),
readable (val2));
radioItem [item].label = (owned) text; // Leaky?
//stdout.printf (text + \n);
var ptr = (int) (pct * 10.0f);
if (selected == item) appIcon.set_icon_full (icons [ptr], NAME);
}
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Help with Memory Leak
On 07/06/2012 08:27 PM, Bruce Reidenbach wrote:
Hello all,
I am encountering a memory leak in an appindicator menu. The menu is made
up of several RadioMenuItems that have their labels updated once per
second. I have tracked the memory leak down to the following code, but
cannot seem to be able to make any additional headway. The method update
is called from several sources, and specifies the radio item and the values
to update via a const array of FORMAT statements. If I comment out the
code that sets the radio menu item label and un-comment the printf
statement, the leak disappears. The leak is minor -- on the order of about
20 to 30 bytes per invocation -- but over time it adds up.
[snip]
-
// Menu update
//
-
public void update (int item, float pct, float val1, float? val2 = 0.0f) {
var text = (item == 0) ? FORMAT [item].printf (val1)
: FORMAT [item].printf (readable (val1),
readable (val2));
radioItem [item].label = (owned) text; // Leaky?
//stdout.printf (text + \n);
var ptr = (int) (pct * 10.0f);
if (selected == item) appIcon.set_icon_full (icons [ptr], NAME);
}
I don't claim to actually understand the object model, but I have an idea:
It stands to reason that the label string is not properly freed. It
looks like, though ownership is transferred to radioItem, it does not
know about this, and no code to free the string is around.
Try adding a line
string old_text = (owned) radioItem [item].label;
This should have Vala take care of it?
Thomas
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Help with Memory Leak
Thomas, Thanks for the quick response. When I add the statement you mentioned, I get the following compilation error: SystemIndicator.vala:128.23-128.52: error: No reference to be transferred string old_text = (owned) radioItem [item].label; ^^ ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Help with Memory Leak
On Fri, 2012-07-06 at 14:27 -0400, Bruce Reidenbach wrote:
Hello all,
I am encountering a memory leak in an appindicator menu. The menu is made
up of several RadioMenuItems that have their labels updated once per
second. I have tracked the memory leak down to the following code, but
cannot seem to be able to make any additional headway. The method update
is called from several sources, and specifies the radio item and the values
to update via a const array of FORMAT statements. If I comment out the
code that sets the radio menu item label and un-comment the printf
statement, the leak disappears. The leak is minor -- on the order of about
20 to 30 bytes per invocation -- but over time it adds up.
I'm not sure if this is the correct forum for asking for help, or whether
this is a problem with the gtk+-3.0 or appindicator3-0.1 packages, but I
thought I'd see if anyone has any ideas in the Vala community first.
Thanks,
Bruce
//
-
// Make results more readable by appending the appropriate metric unit to
the data
//
-
private const string suffix [] = { bytes, KiB, MiB, GiB, TiB,
PiB, EiB, ZiB };
private string readable (float bytes) {
foreach (string s in suffix) {
if (bytes 1024.0) {
var format = (s == bytes) ? %.0f %s : %.1f %s;
return format.printf (bytes, s);
}
bytes = bytes / 1024.0f;
}
return %.1f YiB.printf (bytes);
}
//
-
// Menu update
//
-
public void update (int item, float pct, float val1, float? val2 = 0.0f) {
var text = (item == 0) ? FORMAT [item].printf (val1)
: FORMAT [item].printf (readable (val1),
readable (val2));
radioItem [item].label = (owned) text; // Leaky?
Get rid of (owned). That is used to transfer ownership of a reference,
but g_menu_item_set_label doesn't steal the reference you pass it, so
what ends up happening here is that GTK+ will copy the string you pass
it, and since you told Vala that you want to transfer ownership it will
not free the string when it goes out of scope, and you end up leaking
it.
-Evan
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Help with Memory Leak
On Fri, 2012-07-06 at 13:21 -0700, Evan Nemerson wrote: Get rid of (owned). That is used to transfer ownership of a reference, but g_menu_item_set_label doesn't steal the reference you pass it, so what ends up happening here is that GTK+ will copy the string you pass it, and since you told Vala that you want to transfer ownership it will not free the string when it goes out of scope, and you end up leaking it. While (owned) is definitely useless here, this should not cause a memory leak, and in a quick test valac appears to handle this correctly. Bruce, if you can provide a self-contained test case, I'll take a closer look. Regards, Jürg ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
