gmane.comp.programming.vala

Re: [Vala] memory management with structs [Solved]

Donn — 2013-05-19T08:37:51

Thanks!

\d

Re: [Vala] Vala and Cairo 1.12

Donn — 2013-05-19T08:33:56

Noted. Thanks for the help.

\d

[Vala] Why do we keep static fields in GObject derived classes?

Geert Jordaens — 2013-05-19T06:57:06

Why do we keep static fields in GObject derived classes?

There is currently no way of correctly accessing static class members 
unless at least one object is instantiated.
Moreover the initialisation of the fields depends on the variable type 
(valuetype/reftype).

     public class ClassA : Object {
         public static int int_value_a = 7;                    // <= 
Initialised in outside GObject class
         public static string string_value_a = "7";  // <= Initialised 
within the GObject class *_class_init
     }

     void main() {
         stdout.printf("Access to static member ClassA.int_value_a == 
%d\n",ClassA.int_value_a);
         stdout.printf("Access to static member ClassA.string_value_a == 
%s\n",ClassA.string_value_a);
         var a = new ClassA();
         stdout.printf("After first ClassA object instatiation\n");
         stdout.printf("Access to static member ClassA.int_value_a == 
%d\n",ClassA.int_value_a);
         stdout.printf("Access to static member ClassA.string_value_a == 
%s\

Re: [Vala] Vala and Cairo 1.12

Jonas Kulla — 2013-05-18T14:57:16

2013/5/15 Donn <donn.ingle-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>


It's basically the same as declaring foreign functions in C.
Let's say you want to use the function 'int cairo_do_foo()' from Vala,
you would write something like:

namespace Cairo {
    [CCode (cname="cairo_do_foo")]
    extern int do_foo();
}

The 'CCode' part is a directive to valac for how it should
output the C code. We tell it the actual C function name
to use.

Jonas

Re: [Vala] memory management with structs (OT a bit)

Jonas Kulla — 2013-05-18T14:46:26

2013/5/18 Donn <donn.ingle-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>


I'm pretty sure he was simply referring to B. As he mentioned,
compact classes aren't exactly meant to be used in newly written
Vala code, but rather exist to make the writing of bindings easier.

i.e. How do you create a class that does *not* inherit from GObject?


By not specifying a parent class, ie. just "class MyKlass { ... }".

Jonas

Re: [Vala] memory management with structs (OT a bit)

Donn — 2013-05-18T13:26:34

Okay, but did that answer the question? I'm not sure.

It was:
Are such classes the:
A) [Compact] classes
or
B) is any class that does not specify a parent class automatically a
"light" class?

i.e. How do you create a class that does *not* inherit from GObject?

\d

Re: [Vala] memory management with structs (OT a bit)

Jonas Kulla — 2013-05-18T11:40:15

2013/5/18 Donn <donn.ingle-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>

Hi,

no, compact classes are even simpler than non-Gobject classes. The latter
still have reference count and can be extended,
whereas compact classes are mostly "classified" structs without ref count
which also cannot be extended in subclasses.

Re: [Vala] memory management with structs (OT a bit)

Donn — 2013-05-18T11:12:11

Are such classes the [Compact] classes, or is any class that does not 
specify a parent class automatically a "light" class?

\d

Re: [Vala] memory management with structs

Luca Bruno — 2013-05-18T10:15:13


They aren't ref counted. Structs are value types, they are always either
shallow copied or deep copied (depends on ownership).
Beware the only difference is with nullable structs. Unfortunately the
semantics there is a little different (it's a bug). Nullable structs are
allocated on the heap and are not copied.



Yes, should be possible, int, double, etc. are vala structs.



You can use classes that don't inherit from GObject, which are lighter.



Compact classes are used for bindings, they aren't well supported when
writing new vala code.



As above, they're especially suited for bindings. Compact classes are
usually non-ref counted. If it's not a struct and it's not a GTypeInstance,
it's probably a compact class.

[Vala] memory management with structs

rastersoft — 2013-05-18T09:41:28

Hi all:

How is the memory management in vala when using structs instead of 
classes? I presume they are not ref-counted...

The real questions are:

   * is it possible to use structs as elements in a Gee list without 
running into memory management problems?
   * How to avoid them, in case there are such problems? Or so Imust use 
true classes?
   * Can I use instead compact classes inside Gee lists adding them the 
memory management decorator?
   * In case the last answer is true, how are presented the compact 
classes outside Vala? (for programs using gobject-introspection). Is it 
possible to work with them from C?

Thanks.

Re: [Vala] Help with Memory Leak

Nor Jaidi Tuah — 2013-05-18T01:17:15

That's too bad; we don't know whom to compliment.
Any way, thanks for sharing the good news.

Nice day
Nor Jaidi Tuah




PRIVILEGED/CONFIDENTIAL information may be contained in this message. If you are neither the addressee (intended recipient) nor an authorised recipient of the addressee, and have received this message in error, please destroy this message (including attachments) and notify the sender immediately. STRICT PROHIBITION: This message, whether in part or in whole, should not be reviewed, retained, copied, reused, disclosed, distributed or used for any purpose whatsoever. Such unauthorised use may be unlawful and may contain material protected by the Official Secrets Act (Cap 153) of the Laws of Brunei Darussalam. DISCLAIMER: We/This Department/The Government of Brunei Darussalam, accept[s] no responsibility for loss or damage arising from the use of this message in any manner whatsoever. Our mes
 sages are checked for viruses but we do not accept liability for any viruses which may be transmit

Re: [Vala] Help with Memory Leak

Bruce Reidenbach — 2013-05-17T11:23:06

As they like to say, "old thread is old".

I never was able to get a satisfactory answer from the gtk-app-devel list,
the only response being that the memory allocation/destruction model for
gtk was considered good enough.

But then something curious happened.  I compiled the code for the latest
Ubuntu (13.04) and the problem went away!  The memory footprint is solid as
a rock, after several days of running.  I know there's way too many
variables to figure out what happened (new kernal, new gtk, new valac), but
it appears the problem somehow was cured.  I really doubt that the new
version of valac had anything to do with it since previously I could cause
the heap fragmentation to disappear if I commented out the command to
update the menu label.

On Tue, Jul 17, 2012 at 7:18 AM, Bruce Reidenbach <bereiden-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>wrote:

Re: [Vala] Vala and Cairo 1.12

Donn — 2013-05-15T13:30:46

Great, thanks.

I'm also using gtk, and I see a deps file that specifies 'cairo' - this
is all in /usr/share/vala/vapi directory.
If I use the --vapidir option will it know to override the ref to
'cairo' in that deps file?

All of this I will likely encounter as soon as I get an afternoon to
code in. I want to try the cairo recording surface - so thanks a tonne
for making that vapi!!!

(Bows)
:D

\d

Re: [Vala] Vala and Cairo 1.12

Evan Nemerson — 2013-05-15T13:05:54

In the valac git repository:

https://git.gnome.org/browse/vala/plain/vapi/cairo.vapi


Usually you would just copy it into your project (as cairo.vapi) and
pass a --vapidir option to valac so it knows where to look for it.
Overwriting files from packages is generally not advisable.


-Evan

Re: [Vala] Vala and Cairo 1.12

Donn — 2013-05-15T08:29:57

Okay, thanks. I didn't know this. I was wondering how the appropriate 
cairo_destroy stuff got into my code when I never call these functions 
from Vala.

It seems Evan Nemerson is on the case - yay! - but I'd like to know a 
little more about this inline thing. Do you have an example so I can get 
the picture? (I'm a Pythoner who tripped over Vala and I'm still rubbing 
my chin.)


I will do that, the cairo.vapi has me curious. Thanks.

\d

Re: [Vala] Vala and Cairo 1.12

Donn — 2013-05-15T08:26:26

Thanks Evan, however I'm not sure where these bindings can be found online.

Once fetched, would I simply drop them over my current file:
/usr/share/vala-0.18/vapi/cairo.vapi
?

Or, would I create cairo112.vapi alongside - but then how to use that in 
Vala?

Newbs! So many dumb questions! :D

\d

Re: [Vala] Posix Vala

mirek — 2013-05-15T07:41:58



Yes, exactly, no linking, re-using the codebase. It feels like a good start for your project.

Mirek Rusin

Re: [Vala] Posix Vala

pancake — 2013-05-15T07:07:41

Didnt knew eglib, but for me, the Posix backend should not add any dependency by default. 

But i'm sure some code can be ripped from eglib to extend posixvala feature list

About libev..i already thought about adding vala bindings to libuv. To use a nodejs-like API in Vala, anyone did anything on this topic?

On May 13, 2013, at 22:09, mirek <mirek-BUHhN+a2lJ4< at >public.gmane.org> wrote:

Re: [Vala] Vala and Cairo 1.12

Evan Nemerson — 2013-05-15T00:23:11

I just pushed a bunch of changes to the vala cairo bindings.  If
something is still missing, please file a bug.


-Evan

Re: [Vala] Vala and Cairo 1.12

Jonas Kulla — 2013-05-14T17:59:10

2013/5/14 Donn <donn.ingle-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>


Hi,

some vapis are auto-generated (mostly for glib based libraries I think),
but most are hand written and maintained AFAIK.

Are there a lot of new functions in 1.12 that you need? If not,
you could just inline the function signatures in your vala code
until someone updates the official vapi.

You can take a look at the current vapi to get a feel for
how they're written. If you have specific questions,
feel free to ask them here.

Jonas

[Vala] Vala and Cairo 1.12

Donn — 2013-05-14T12:32:15

Hi,
Vapi files mystify me. Does anyone know where I can get a vapi (and 
anything else I'd need) such that I can use Cairo 1.12?

Or, perhaps someone can help me generate it?

BTW - The valadoc.org/cairo seems to be about version 1.0 of cairo - so 
it's also out of date.

\d